Instead, we warn where this optimization might cause a problem!
This was included for historic reasons and has persisted to the point of now
infecting all X.org modules. Historically, it was just present in these
modules before adding XORG_CWARNFLAGS to XORG_DEFAULT_OPTIONS:
libICE
libSM
libX11
On Tue, Feb 2, 2010 at 5:44 PM, Jeremy Huddleston
wrote:
> Instead, we warn where this optimization might cause a problem!
>
> This was included for historic reasons and has persisted to the point of now
> infecting all X.org modules. Historically, it was just present in these
> modules before ad
Resurrecting this thread as I just realized it was never actually fixed.
I propose we actually follow up on these changes. We should remove
-fno-strict-aliasing from XORG_CWARNFLAGS and only add them to the modules that
actually require it. We can start out consercatively by adding it to the
On Sun, 2010-10-31 at 15:54 -0700, Jeremy Huddleston wrote:
> Resurrecting this thread as I just realized it was never actually
> fixed.
>
> I propose we actually follow up on these changes. We should remove
> -fno-strict-aliasing from XORG_CWARNFLAGS and only add them to the
> modules that actu
On Oct 31, 2010, at 18:39, Gaetan Nadon wrote:
> On Sun, 2010-10-31 at 15:54 -0700, Jeremy Huddleston wrote:
>
>> Resurrecting this thread as I just realized it was never actually
>> fixed.
>>
>> I propose we actually follow up on these changes. We should remove
>> -fno-strict-aliasing from XO
On Son, 2010-10-31 at 15:54 -0700, Jeremy Huddleston wrote:
> Resurrecting this thread as I just realized it was never actually fixed.
>
> I propose we actually follow up on these changes. We should remove
> -fno-strict-aliasing from XORG_CWARNFLAGS and only add them to the
> modules that actuall
> From: Michel =?ISO-8859-1?Q?D=E4nzer?=
> Date: Mon, 01 Nov 2010 08:18:51 +0100
>
> On Son, 2010-10-31 at 15:54 -0700, Jeremy Huddleston wrote:
> > Resurrecting this thread as I just realized it was never actually fixed.
> >
> > I propose we actually follow up on these changes. We should remov
On Mon, 2010-11-01 at 11:32 +0100, Mark Kettenis wrote:
> I may be somewhat overcautious, but I would keep -fno-strict-aliasing
> as a default. And I'd only enable -fstrict-aliasing for particular
> bits of code where it has a significant performance benefit, and
> people have done a careful anal
>> I still haven't seen any measurements showing any benefits from making
>> this change. Are there any?
>
> I think Michael is asking a very good question here. The strict
> aliasing rules introduced in C99 have always been somewhat
> controversial. They get in the way for lots of low-level pr
On Nov 1, 2010, at 05:48, Gaetan Nadon wrote:
> On Mon, 2010-11-01 at 11:32 +0100, Mark Kettenis wrote:
>
>> I may be somewhat overcautious, but I would keep -fno-strict-aliasing
>> as a default. And I'd only enable -fstrict-aliasing for particular
>> bits of code where it has a significant per
On Mon, 2010-11-01 at 12:17 -0700, Jeremy Huddleston wrote:
> 1) It is *NOT* a warning flag. Using CWARNFLAGS should *only* enable
> warnings, not change the resulting assembly.
>
> 2) It was never intended to be in all of the modules. It landed there
> by accident when the code was copy/pasted
On Mon, 2010-11-01 at 15:59 -0400, Gaetan Nadon wrote:
> > 1) It is *NOT* a warning flag. Using CWARNFLAGS should *only*
> > enable warnings, not change the resulting assembly.
> >
> > 2) It was never intended to be in all of the modules. It landed
> > there by accident when the code was copy/p
On Mon, 2010-11-01 at 12:33 -0700, Jeremy Huddleston wrote:
> On Nov 1, 2010, at 05:48, Gaetan Nadon wrote:
>
> > On Mon, 2010-11-01 at 11:32 +0100, Mark Kettenis wrote:
> >
> >> I may be somewhat overcautious, but I would keep -fno-strict-aliasing
> >> as a default. And I'd only enable -fstric
On Nov 1, 2010, at 13:18, Gaetan Nadon wrote:
> On Mon, 2010-11-01 at 12:33 -0700, Jeremy Huddleston wrote:
>
>> On Nov 1, 2010, at 05:48, Gaetan Nadon wrote:
>>
>>> On Mon, 2010-11-01 at 11:32 +0100, Mark Kettenis wrote:
>>>
I may be somewhat overcautious, but I would keep -fno-strict-al
On Mon, 2010-11-01 at 13:40 -0700, Jeremy Huddleston wrote:
> I don't think that's the correct model. -fstrict-aliasing is on by
> default (for many users), and -fno-strict-aliasing should be what is
> opted into in order to disable optimizations that rely on correctly
> written C code.
>
> >> X
On Nov 1, 2010, at 14:46, Gaetan Nadon wrote:
> Sorry, I got confused. I forgot -O brings strict aliasing by default. We
> need one new variable for "real warnings" and one variable for
> -fno-strict-aliasing. Modules would typically use the new "real
> warnings" variable and some would pick the n
On Mon, 2010-11-01 at 16:34 -0700, Jeremy Huddleston wrote:
> So... basically what I said originally... ? ;)
>
End result is the same. I failed to recognize this level of
indirection:
XORG_CWARNFLAGS would be updated to call these two and set
CWARNFLAGS="$(CFLAGS_WARNINGS) $(
On 11/01/2010 12:18 AM, Michel Dänzer wrote:
On Son, 2010-10-31 at 15:54 -0700, Jeremy Huddleston wrote:
Resurrecting this thread as I just realized it was never actually fixed.
I propose we actually follow up on these changes. We should remove
-fno-strict-aliasing from XORG_CWARNFLAGS and only
On 11/01/2010 02:46 PM, Gaetan Nadon wrote:
...elision by patrick ...
Sorry, I got confused. I forgot -O brings strict
aliasing by default. We need one new variable for
"real warnings" and one variable for
-fno-strict-aliasing. Modules would typically use the
new "real warnings" variable and
19 matches
Mail list logo
