[PATCH xserver 1/4] Replace deprecated CWARNFLAGS with BASE_CFLAGS and NO_STRICT_ALIASING_CFLAG

[Gaetan Nadon]

On Sat, 2011-12-10 at 12:24 -0800, Keith Packard wrote:

> On Sat, 10 Dec 2011 14:16:59 -0500, Gaetan Nadon <memsize at videotron.ca> 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.
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20111210/e746b6e8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg-devel/attachments/20111210/e746b6e8/attachment.pgp>