From: | "Sergey E(dot) Koposov" <math(at)sai(dot)msu(dot)ru> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Teodor Sigaev <teodor(at)sigaev(dot)ru>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: GIN FailedAssertions on Itanium2 with Intel compiler |
Date: | 2006-09-03 15:44:32 |
Message-ID: | Pine.LNX.4.64.0609031937050.18490@lnfm1.sai.msu.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)sai(dot)msu(dot)ru
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2006-09-03 15:44:52 | Re: [COMMITTERS] pgsql: Second try committing the path |
Previous Message | Joshua D. Drake | 2006-09-03 15:01:37 | Re: Postgres tracking - the pgtrack project |