On Sat, 2011-12-10 at 12:24 -0800, Keith Packard wrote: > On Sat, 10 Dec 2011 14:16:59 -0500, Gaetan Nadon <[email protected]> wrote: > > > We would be back to square one. It would only be a macro name change. > > Can you explain what the plan was for these patches? For my own use, I'd > like to see us have three sets of flags:
It looks like we are reviewing XORG_COMPILER_FLAGS macro, so I'll let the author answer. http://cgit.freedesktop.org/xorg/util/macros/commit/?id=b406f730d64dfb8b699631ffb3ee5f3a1f0db8c4 What triggered the series is that the Xi examples needed to add -fno-strict-aliasing in one of the examples (bug report) so I used the new XORG_COMPILER_FLAGS macro rather than the deprecated CWARNFLAGS as outlined in the comment: # This function is deprecated because it defines -fno-strict-aliasing # which alters the code generated by the compiler. If -fno-strict-aliasing # is needed, then it should be added explicitly in the module when # it is updated to use BASE_CFLAGS. There is no urgency, I can drop #1 and resubmit #3 using CWARNFLAGS until the review comes to a conclusion. > > 1) compiler flags -- things that affect code generation, like > -fno-strict-aliasing and -std=gnu99. These should never be disabled > for any reason. > > 2) default warning flags -- things that we expect people to listen to, > and for which we would expect code to not violate. Anything built > with these flags "shouldn't" generate any warnings today. These > should be things that mark likely bugs, or at least unsafe coding > styles. Patches to reduce these warnings should be treated like > regular bug fixes. > > 3) verbose warning flags. In our ideal world, none of our code would > generate any of these warnings. Depending on the platform, this > may not be achievable though. New code and patches should not > generate any of these warnings, as far as is practical given the > potential platform issues. > > > That's a possibility, if they also ignore the aliasing warnings. > > Making sure that the warnings we enable by default don't bury people in > data will help this a lot, of course. > > > Note that only 13 drivers use CWARNFLAGS. All others don't have > > -fno-strict-aliasing. They don't even get the warnings about breaking > > aliasing rules! > > Yeah, drivers are not the most likely problem here; it's code dealing > with the wire protocol, which often means client-side code. Ideally, > I'd like to see warnings about possible aliasing rule violations, but > have the code generated under the traditional C rules. > > > Perhaps a different macro for xserver + any other modules deemed to be > > in need of -fno-strict-aliasing. I don't think we have a definite list > > of such modules. > > I don't know why you'd ever compile without -fno-strict-aliasing. >
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
