Re: GIN FailedAssertions on Itanium2 with Intel

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Teodor Sigaev <teodor(at)sigaev(dot)ru>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, pgsql-hackers(at)postgresql(dot)org, "Sergey E(dot) Koposov" <math(at)sai(dot)msu(dot)ru>
Subject: Re: GIN FailedAssertions on Itanium2 with Intel
Date: 2006-09-03 01:54:33
Message-ID: 200609030154.k831sXK00200@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Teodor Sigaev wrote:
> > What does that option do? Is it practical to enable it for the entire
> > backend?
> From docs:
> Disables inline expansion of standard library or intrinsic functions.
>
> > And isn't this a straightforward compiler bug they should be notified
> > about?
> What's a choice? Now I see 3:
> 1) -O1
> 2) "volatile"
> 3) -nolib_inline
>
> IMHO, only -O1 is guarantee for other possible places... But I'm not familiar
> enough with such kinds of bugs.

My guess is that the compiler writers saw you calling a libc function,
and assumed that library could not modify the file static variable,
forgetting that the libc function can call back into the original file.

Can you detect the Itanium compiler and optimization levels via
preprocessor symbols, and test for that, and throw an #error?

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2006-09-03 02:24:58 ecpg regression broken
Previous Message Joshua D. Drake 2006-09-03 01:54:02 Re: Postgres tracking - the pgtrack project