Since we seem to be rejecting patches that introduce clang warnings on
Peter Maydell's OSX configuration, I felt like I should detail the long
list of errors we currently have that prevent me from thoroughly testing
with clang in 3.5.0.
There are five classes of errors that currently plague our fair project:
-Wunknown-attributes currently complains about the many instances of
__alloc_size__ used about the code, because clang ignores this
attribute. We can stifle this warning with -Wno-unknown-attributes as
Stefan tried to, but this apparently causes further warnings and errors
in versions of clang/gcc that do not recognize this option.
-Wunused-command-line-argument currently complains about the many
include flags passed to each CC incantation -- presumably this is not
really fixable, because we'd have to fix our Makefile to be a lot
smarter than it is. We probably need to stifle these warnings
conditionally like unknown-attributes, above.
-Wparentheses-equality complains about functions like our QLIST
functions, because once values get wrapped by a few macros, they have
many unnecessary parentheses. Since that's "good practice" with macros,
I think there's no way around needing to disable this warning.
-Wself-assign complains about many functions within softmmu_template.h,
because of our TGT_LE macro which is a no-op on my machine. Clang gets
upset about "x = (x)" as a worthless self assignment. Maybe we can avoid
these errors by using a standard macro instead of one we rolled
ourselves, but otherwise this error needs to get quieted, too.
-Wtautological-compare also comes up a few times, because we
occasionally use macros to check if one symbolic value is equivalent to
another. When both values are bound at preprocessor time to the same
symbol, runtime conditionals become tautological comparisons.
In qemu/target-mips/translate.c:1965:166, there's an instance of
FOP_CONDNS being expanded with ifmt = 'FMT_D', so when we get to this
conditional: 'if (ifmt == FMT_D)', we trigger the tautological
comparison error.
This is a particular error we probably don't want to disable, but we'll
need to rework some of these macros to avoid runtime checking of
compile-time constructs.
Input on which errors should be quieted and which errors should be fixed
in code is welcome. My hunch is to ignore #1, #2, #3. We might be able
to fix #4 in code, but it should also be safe to ignore. #5 I suspect we
really want to fix in code, because the tautological comparison is a
good warning for type mismatches and we wouldn't want to miss those.
Thanks,
--js
