<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.32.2"> </HEAD> <BODY> On Sat, 2011-12-10 at 12:24 -0800, Keith Packard wrote: <BLOCKQUOTE TYPE=CITE> <PRE> On Sat, 10 Dec 2011 14:16:59 -0500, Gaetan Nadon <<A HREF="mailto:memsize@videotron.ca">memsize@videotron.ca</A>> 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: </PRE> </BLOCKQUOTE> It looks like we are reviewing XORG_COMPILER_FLAGS macro, so I'll let the author answer. <A HREF="http://cgit.freedesktop.org/xorg/util/macros/commit/?id=b406f730d64dfb8b699631ffb3ee5f3a1f0db8c4">http://cgit.freedesktop.org/xorg/util/macros/commit/?id=b406f730d64dfb8b699631ffb3ee5f3a1f0db8c4</A> 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: <BLOCKQUOTE> # 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. </BLOCKQUOTE> There is no urgency, I can drop #1 and resubmit #3 using CWARNFLAGS until the review comes to a conclusion. <BLOCKQUOTE TYPE=CITE> <PRE> 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. </PRE> </BLOCKQUOTE> </BODY> </HTML>