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

From Sergey E. Koposov
Subject Re: GIN FailedAssertions on Itanium2 with Intel compiler
Date
Msg-id Pine.LNX.4.64.0609031937050.18490@lnfm1.sai.msu.ru
Whole thread Raw
In response to Re: GIN FailedAssertions on Itanium2 with Intel  (Bruce Momjian <bruce@momjian.us>)
Responses Re: GIN FailedAssertions on Itanium2 with Intel  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Sat, 2 Sep 2006, Bruce Momjian wrote:

> 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?

No, it's impossible.
Unfortunately the __OPTIMIZE__ preproc. symbol of icc doesn't allow to 
distinguish between different optimization levels. (only between -O0 and 
anything else).

Regards,    Sergey

*******************************************************************
Sergey E. Koposov
Max Planck Institute for Astronomy/Sternberg Astronomical Institute
Tel: +49-6221-528-349
Web: http://lnfm1.sai.msu.ru/~math
E-mail: math@sai.msu.ru


pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Postgres tracking - the pgtrack project
Next
From: Andrew Dunstan
Date:
Subject: Re: [COMMITTERS] pgsql: Second try committing the path