Re: compile warning

From: "Andrew Dunstan" <andrew(at)dunslane(dot)net>
To: "PostgreSQL Hackers Mailing List" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: compile warning
Date: 2003-10-11 16:43:22
Message-ID: 00bb01c39016$c9134770$6401a8c0@DUNSLANE
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)dunslane(dot)net>
To: "PostgreSQL Hackers Mailing List" <pgsql-hackers(at)postgresql(dot)org>
Sent: Saturday, October 11, 2003 12:17 PM
Subject: Re: [HACKERS] compile warning

>
> ----- Original Message -----
> From: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>
> To: "Andrew Dunstan" <andrew(at)dunslane(dot)net>
> Cc: "PostgreSQL Hackers Mailing List" <pgsql-hackers(at)postgresql(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2003-10-11 17:01:55 Re: pg_resetxlog fixed
Previous Message Alvaro Herrera 2003-10-11 16:42:09 Re: compile warning