Re: GIN FailedAssertions on Itanium2 with Intel - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: GIN FailedAssertions on Itanium2 with Intel
Date
Msg-id 200609030154.k831sXK00200@momjian.us
Whole thread Raw
In response to Re: GIN FailedAssertions on Itanium2 with Intel compiler  (Teodor Sigaev <teodor@sigaev.ru>)
Responses Re: GIN FailedAssertions on Itanium2 with Intel compiler  ("Sergey E. Koposov" <math@sai.msu.ru>)
List 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@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Postgres tracking - the pgtrack project
Next
From: Andrew Dunstan
Date:
Subject: ecpg regression broken