X-Authentication-Warning:	delorie.com: mail set sender to djgpp-workers-bounces using -f
X-Recipient:	djgpp-workers AT delorie DOT com
Message-ID:	<4A744D8F.6030309@iki.fi>
Date:	Sat, 01 Aug 2009 17:13:35 +0300
From:	Andris Pavenis <andris DOT pavenis AT iki DOT fi>
User-Agent:	Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2
MIME-Version:	1.0
To:	djgpp-workers AT delorie DOT com
Subject:	Re: Some patches to DJGPP v2.04 (GCC-4.4.1 related)
References:	<4A73E13E DOT 3050700 AT iki DOT fi> <647fe9b10908010147j1cc16f97o7dc9ff609387cc3 AT mail DOT gmail DOT com>
In-Reply-To:	<647fe9b10908010147j1cc16f97o7dc9ff609387cc3@mail.gmail.com>
Reply-To:	djgpp-workers AT delorie DOT com

01.08.2009 11:47, Ozkan Sezer kirjoitti:
> On Sat, Aug 1, 2009 at 9:31 AM, Andris Pavenis<andris DOT pavenis AT iki DOT fi>  wrote:
>> At first fighting with strict aliasing violation warnings from emu387.cc
>> could be rather big work. Perhaps it is easier to tell GCC not to
>> complain. The option -fno-strict-aliasing is available beginning from
>> gcc-2.8.0 if I remember correctly. So unless somebody terribly
>> wants to build DJGPP v2.04pre with really ancient gcc-2.7.2.1, I guess
>> it should be OK to apply the patch. Am I right?
>>
>> There also was type punning related warning from src/compat/mntent/mntent.c.
>> Does the related patch seem OK?
>>
>> I already applied some other small patches.
>>
>> After that (+ telling gcc to stay silent about conflicting parameters
>> for some builtin functions in libm and using command line option -m32
>> for building host tools) all seems to build OK using gcc-4.4.1 under
>> Fedora 11 x86_64.
>>
>> Andris
>>
>
> Patches seem OK.  Although you may want to build using
> -Wstrict-aliasing=2 before finishing your work, because gcc
> seems to hide some of the warnings _and_ may generate
> bad code, and in some worse cases may not warn even
> with that warning flag and still generate bad code which
> happened to me once (that was with gcc-4.5, though..)
> My 2 cents.

I was not going to simply silence GCC warnings with -Wno-strict-aliasing, but
to forbid performing the optimization which could cause wring code in case
of strict aliasing violations using option -fno-strict-aliasing.

So I do not see why I should additionally enable again these warnings.

Andris

PS: Ideally it would be of course better to fix these aliasing violations. It is
     however faster to just disable corresponding optimization. I'm afraid however
     that it will be for a long time.

- Raw text -