Re: fix for strict-alias warnings
От | Andrew Dunstan |
---|---|
Тема | Re: fix for strict-alias warnings |
Дата | |
Msg-id | 002901c39247$7e720200$6401a8c0@DUNSLANE обсуждение исходный текст |
Ответ на | Re: fix for strict-alias warnings (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: fix for strict-alias warnings
|
Список | pgsql-patches |
----- Original Message ----- From: "Tom Lane" <tgl@sss.pgh.pa.us> > > I have to agree now with Andrew's last mail that -fno-strict-aliasing is > the only safe solution. Since gcc isn't even pretending that it can > warn in all cases where the optimization might break things, I'm not > sure we could ever responsibly enable this optimization. I do not feel > this is our problem; it is the compiler hackers' fault if they need to > make unsupportable, untestable assumptions about application code. > > Basically, ISO broke the language here, and I say it's a screwup up with > which we need not put. > You and Linus Torvalds ;-) I recall seeing almost this exact discussion on the kernel hackers list a few years ago. Of course, the linux kernel is aimed at a limited set of compilers - as I understand it basically gcc although it has been made to build with Intel compilers - which makes things somewhat easier for them. What is our target set of compilers? What is our target version of C? (being unsure on these issues I gave my initdb.c a tour through "gcc -ansi -pedantic" at one stage). Also note that uninhibited casting between types can still cause alignment problems, quite apart from the strict aliasing issue (That was what confused Bruce, I think - the email on the netbsd list referred to both strict aliasing issues and misalignment issues). Still, that apparently hasn't been a problem up to now so we are probably OK on this one. cheers andrew
В списке pgsql-patches по дате отправления: