[Users] Compiler warnings

[Erik Schnetter]

Frank

Many of the warnings in auto-generated thorns are harmless, e.g. about
unused variables. While it would be possible to remove unused
variables from auto-generated thorns, this wouldn't really help -- (1)
the compiler already removes them, and (2) the warning is meant to
remind people about potential programming errors, which doesn't apply
in our case since we checked the code. Maybe using
CCTK_ATTRIBUTE_UNUSED would be a better approach, or using
CCTK_DECLARE_INIT to declare and initialise the variables.

The shadowing errors come from thorn Vectors, which uses macros to
implement vectorisation. I tried using inline functions, but this made
the code unbearably slow except when optimising, and also led to other
problems with some compilers (although gcc and Intel were fine). The
macros are well-crafted, and these warning regarding shadowing are
harmless in this case. To avoid these warnings, one needs to use a
unique prefix in each macro for each local variable there, which would
make the code quite tedious to read and write.

The warnings regarding casting qualifiers probably relate to const and
restrict. It is really difficult, if not impossible, to avoid such
warnings if one has pointers to pointers. Maybe introducing manual
casts from and to void* (or void const*) may help here, but this would
probably only make things worse -- a warning about qualifiers is
relatively harmless, but if using void*, then even basic type
correctness isn't checked any more. Maybe these warnings should be
disabled?

The next warnings about uninitialised variables is the first one that
looks dangerous. (The warnings above may also point to errors, but
since we have to many false positives it is difficult to tell.)

You used the warning options "-Wall -Wshadow -Wpointer-arith
-Wcast-qual -Wcast-align -Wstrict-prototypes -Wmissing-declarations
-Wbad-function-cast -Wsign-compare", which is very exhaustive. Should
we use "-Wall" instead by default?

The Intel compiler produces many fewer warnings by default, which
isn't ideal either. I think our goal should be to have clean code for
"gcc -Wall", or for a slight variation thereof.

-erik

On Fri, May 11, 2012 at 12:43 AM, Frank Loeffler <knarf at cct.lsu.edu> wrote:
> Hi,
>
> While compiling a fresh checkout of the upcoming release I noticed (yet
> again) the high number of compiler warnings scrolling by. I captured
> them into a file and got 280k lines in 38MB this way!
>
> I parsed this and produced a graph showing how many and which warnings
> are produced for each thorn.  Of course this is highly dependent on the
> compiler, it's version and flags. In this case I used numrel-gcc.cfg
> from simfactory.
>
> As you can see from the graph at
> http://www.cct.lsu.edu/~knarf/ET_stats/warnings.pdf there are a few
> thorns which by far dominate the picture (notice the log-x scale). These
> three thorns are all auto-generated. Could we do something to reduce
> these numbers, and possibly also a few of the others?
>
> The build log can be found here:
> http://www.cct.lsu.edu/~knarf/ET_stats/build.log.xz
>
> Frank
>
> Note: the color-coding in the lower plot is a _linear_ ratio, while the
> overall size of the bars is log-x.
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIcBAEBCAAGBQJPrJjkAAoJEOkzpip+I59kVFUP/i9cHC8cAJ4wdB0/Ws4+dkTR
> rXafmXl+dJBY94USdXCkhBqD5vSKrO8rAdGoC6KARZUrZKHSSQztlZ8Ff1K3eAtE
> N1rURcd/8zNPvVVQ4RR67fKGVYWj96Rvxo6Dfst4G7SpC7Sd8DM7CJjsR+T7vITg
> tn34iwYWVmv9PQhfrprNJeoptTE2DuGoJMnOthCbNpyhfXdCwiVOAhglL5j547W/
> nMTt1NGOYR7LkRmxnPc3JFjNzG3QavZqJD6J0AQIMVikSrQH8/2w6NQLAdtMlXwh
> SZTfVOwgej8gDRkSJ4BEiDsf+WpiVawbmKPrMw+gU+JzBBMNRKKeTZl6e5vpu9TV
> MwzgA0o0vWNAcTBNbMd7VW+QRj04sy2d7bJeHrn/SKUWPeVs7oP43sjDdoRL9ECb
> OLV7kGj3/vCi8ZRTrGfEn4ofuOYoS2LnLrExkxJH4mJLliAuiEJhTFmynRqf80JR
> Bqpvh7rJLemxn7X6LASI90TuW0T2i5q5aOeMoIfkPjENgtMakwq4ecu1+Di3Aajx
> 07VFQZq09K9kawpe7OaEDnrcQIACTIK7M27JeUz3lxiG8XVIlxu+HH9if39h8TaK
> YORdBO96IgZ0LzctIx7p0a5d/OcKNCmbWGqVxornBRZ/bBitnWbKt4oXfQmm2ByP
> PkFIi1UM46kKMMIeVsIC
> =XeWo
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Users mailing list
> Users at einsteintoolkit.org
> http://lists.einsteintoolkit.org/mailman/listinfo/users
>



-- 
Erik Schnetter <schnetter at cct.lsu.edu>
http://www.perimeterinstitute.ca/personal/eschnetter/