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. > > >> XORG_CWARNFLAGS would be updated to call these two and set > CWARNFLAGS="$(CFLAGS_WARNINGS) $(CFLAGS_NO_STRICT_ALIASING)" > > > > Nope. Our good old CWARNFLAGS would remain untouched for eternity > and > > will eventually fall off the radar screen. > > Well, I think that in the spirit of abstraction and code-reuse, it > would be best to have it call the two new macros... but I guess that > is contingent on our dispute over opting-in to -fno-strict-aliasing > versus -fstrict-aliasing. > > ... > > >> For modules that did have it historically, we'll leave them alone > initially. > >> As we audit them, we'll change CWARNFLAGS to either CFLAGS_WARNINGS > or CFLAGS_WARNINGS CFLAGS_NO_STRICT_ALIASI. > >> This will help us keep track of what has been audited to determine > what really needs > >> the flag versus what might've inherited it by accident. > > > > Those modules would use both the new CFLAGS_WARNINGS and the new > > CFLAGS_STRICT_ALIASING, under an opt-in principle > > I'm confused now. If they actually *NEED* -fno-strict-aliasing, how > are you proposing adding -fno-strict-aliasing? This is why I was > suggesting a CFLAGS_NO_STRICT_ALIASING >
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 new "-fno-strict-aliasing" variable (the server and drivers for example). The CWARNFLAGS is untouched for backward compatibility. I hope I got it right :-) For the server, it would be $(CFLAGS_WARNINGS) + $(CFLAGS_NO_STRICT_ALIASING) For libXxf86vm, it would be $(CFLAGS_WARNINGS)
signature.asc
Description: This is a digitally signed message part
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
