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

[Keith Packard]

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:

 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.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20111210/7aaea2ff/attachment.pgp>