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:
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.
--
[email protected]
pgpKULRO7cAWt.pgp
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
