Re: compile warning - Mailing list pgsql-hackers
From | Andrew Dunstan |
---|---|
Subject | Re: compile warning |
Date | |
Msg-id | 00bb01c39016$c9134770$6401a8c0@DUNSLANE Whole thread Raw |
In response to | Re: compile warning (Bruce Momjian <pgman@candle.pha.pa.us>) |
List | pgsql-hackers |
It has just been pointed out to me that the Freetype guy misconfigured his test settings, so the performance gain was not great. See http://www.freetype.org/pipermail/devel/2003-June/009453.html the other points are valid, though. I think we should be proud of the fact we can do this :-) - other projects have just given up on it and use -fno-strict-aliasing. cheers andrew ----- Original Message ----- From: "Andrew Dunstan" <andrew@dunslane.net> To: "PostgreSQL Hackers Mailing List" <pgsql-hackers@postgresql.org> Sent: Saturday, October 11, 2003 12:17 PM Subject: Re: [HACKERS] compile warning > > ----- 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 > > > > ---------------------------(end of broadcast)--------------------------- > TIP 8: explain analyze is your friend
pgsql-hackers by date: