Re: compile warning - Mailing list pgsql-hackers
From | Andrew Dunstan |
---|---|
Subject | Re: compile warning |
Date | |
Msg-id | 009501c39013$33420950$6401a8c0@DUNSLANE Whole thread Raw |
In response to | Re: compile warning (Bruce Momjian <pgman@candle.pha.pa.us>) |
Responses |
Re: compile warning
Re: compile warning |
List | pgsql-hackers |
----- Original Message ----- From: "Bruce Momjian" <pgman@candle.pha.pa.us> To: "Andrew Dunstan" <andrew@dunslane.net> Cc: "PostgreSQL Hackers Mailing List" <pgsql-hackers@postgresql.org> Sent: Saturday, October 11, 2003 11:26 AM Subject: Re: [HACKERS] compile warning > Andrew Dunstan wrote: > > > > I have a fix for this which I will post to patches - essentially you cast > > the pointers to (void *) and the compiler doesn't complain. It would be a > > pity to turn off strict aliasing altogether, as it is known to improve > > performance in some cases. > > > > Tested on Cygwin/GCC 3.3.1 > > I am not sure about the patch. I know it fixes it, but is the compiler > actually reporting a valid concern, or is it broken? Is it complaining > about passing a struct pointer of one type to another? Don't we do that > all over the place? > > I hate to add a patch just to fix a buggy version of a compiler. If we > do apply this patch, I think we should cast to (void *), then to the > valid type, and add a comment in each instance about its purpose. > This is not a compiler bug. The compiler is behaving perfectly correctly. See http://www.gnu.org/software/gcc/bugs.html#nonbugs_c. See also http://mail-index.netbsd.org/tech-kern/2003/08/11/0001.html for more info. Actually, the fact that we get so few warnings on this is a monument to how clean our code is, although the warnings are not guaranteed to catch every instance of illegal type-punning. If you look through the code you will see that we are casting to void * all over the place. (I count 772 instances of the string "void *" in the code). AFAIK this patch will inhibit the compiler from making type alias assumptions which could result in nasty reordering of operations, but I could be wrong. The other problem could be pointer misalignment, but if so we would surely have seen it from straight casts by now - I'd be more worried about operation reordering than misalignment, but maybe this would need to be tested on a platform with heavier alignment restrictions than any machine I have (a SPARC, say?). If you don't want to do this we could turn off strict-aliasing. You might take a performance hit, though - see http://www.freetype.org/pipermail/devel/2003-June/009452.html for info on what the FreeType people found. There are more fundamental ways of addressing this, but they are far more intrusive to the code, and presumably we don't want that at this stage in the cycle. Incidentally, I understand that other compilers than gcc are starting to implment this part of the standard, so even if we turn it off for gcc we'll have to deal with it eventually. cheers andrew cheers andrew
pgsql-hackers by date: