Re: GIN FailedAssertions on Itanium2 with Intel compiler
От | Sergey E. Koposov |
---|---|
Тема | Re: GIN FailedAssertions on Itanium2 with Intel compiler |
Дата | |
Msg-id | Pine.LNX.4.64.0609031937050.18490@lnfm1.sai.msu.ru обсуждение исходный текст |
Ответ на | Re: GIN FailedAssertions on Itanium2 with Intel (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: GIN FailedAssertions on Itanium2 with Intel
|
Список | 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 по дате отправления: