Clang scan-build warns in some expansions of RB_GENERATE_STATIC
that it has a "Dereference of null pointer". It also warns that
"The left operand of '==' is a garbage value" strangely. Simply
suppress these since this is third-party code anyway.
The Clang scanbuild tool warns:
Utilities/cmliblzma/liblzma/simple/x86.c:106:23: warning:
The result of the '<<' expression is undefined
src = dest ^ ((1u << (32 - i * 8)) - 1);
~~~^~~~~~~~~~~~~~~
AFAIK overflow of a left shift on an unsigned type is well-defined.
We first suppressed this in commit v3.1.0-rc1~647^2 (CTestCustom:
Suppress warnings about rand() and srand() on OpenBSD, 2014-04-12).
Add another variant of the warning wording.
Our `cmake.version.manifest` file uses a "compatibility" element for
Windows 10 support. Older MS tools warn about it being unknown, so
suppress the warning.
On Solaris the system `/usr/include/floatingpoint.h` header contains
typedef float single;
so the GNU compiler warns that uses of the name `single` shadow it.
Just suppress the warning because our uses of this name would become
less readable with a different name.
The HP compiler on HP-UX 11.11 warns:
Warning (anachronism) 823: ".../test_INT_format.h", line 194 # Redundant
preprocessing concatenation operation results in two valid preprocessing
tokens. Depending on this implementation defined behavior will result in
non-portable code.
TEST_C(INT32_C, -0x55000000, i32, int32_t, uint32_t)
^^^^^^
Warning (anachronism) 823: ".../test_INT_format.h", line 196 # Redundant
preprocessing concatenation operation results in two valid preprocessing
tokens. Depending on this implementation defined behavior will result in
non-portable code.
TEST_C(INT64_C, -0x5500000000000000, i64, int64_t, uint64_t)
^^^^^^
There is likely a subtle problem with the way one of the system-provided type
macros is defined but the test passes despite the warning. Simply suppress it.
We don't do crypto here, so a "poor" random doesn't matter. In fact we have API
to allow people to get a repeatable sequence by setting a specific seed.
Since we compile command implementations in large batches the
translation units get too big for MIPSpro optimization limits.
Suppress the warnings it produces:
Warning: Olimit was exceeded on function ...
Warning: To override Olimit for all functions in file, use -OPT:Olimit=3201
Ancient versions of CMake required else(), endif(), and similar block
termination commands to have arguments matching the command starting the
block. This is no longer the preferred style.
Run the following shell code:
for c in else endif endforeach endfunction endmacro endwhile; do
echo 's/\b'"$c"'\(\s*\)(.\+)/'"$c"'\1()/'
done >convert.sed &&
git ls-files -z -- bootstrap '*.cmake' '*.cmake.in' '*CMakeLists.txt' |
egrep -z -v '^(Utilities/cm|Source/kwsys/)' |
egrep -z -v 'Tests/CMakeTests/While-Endwhile-' |
xargs -0 sed -i -f convert.sed &&
rm convert.sed
"argument unused during compilation" -- well, thanks, but ...
If somebody has a fix to eliminate this warning entirely, rather
than simply suppressing it from our dashboard results, I'm all
ears.
The clang and icc compilers see two lines of warning with
essentially the same message. But the second line does not
say qglobal.h, so remove that part of the warning exclusion
regex. See parent commit for further comments regarding this
warning exclusion.
Qt 4.7 and earlier produce a "This version of Mac OS X is unsupported"
warning on Lion, even though they work fine once built. We'll upgrade
this machine to use Qt 4.8 when it's officially released. Until then,
suppress this warning so that we don't miss other "more real" warnings
on the dashboard.
The warning appears everywhere we use static_cast to explicitly truncate
an integer width. It appears in the form
cc-3968 CC: WARNING File = ..., Line = ...
implicit conversion of a 64-bit integral type to a smaller
integral type (potential portability problem)
static_cast<...>(...);
^
which is strange because a "static_cast" is not implicit. It also
appears in system library code.