Re: 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