[Users] Compiler warnings
schnetter at cct.lsu.edu
Fri May 11 12:06:35 CDT 2012
On Fri, May 11, 2012 at 12:47 PM, Frank Loeffler <knarf at cct.lsu.edu> wrote:
> On Fri, May 11, 2012 at 07:57:35AM -0400, Erik Schnetter wrote:
>> 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.
> It would help to make other, potentially dangerous warnings more
> visible. At the moment almost everything is just drowned in
> 'unimportant' warnings which tends to make people ignore all of them.
> I hope Ian can manage to remove most of them. Most of that code is
> auto-generated anyway. We don't have to go in and remove all of them by
As I mentioned (cut from your quote): Using CCTK_DECLARE_UNUSED will
make these warnings go away.
>> 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.
> I believe you that they are harmless. I wonder whether we can find a way
> which makes the compiler happier and doesn't introduce problems.
> Disabling warnings like globally this isn't really an option, because as
> you pointed out they can help to find common mistakes in code.
>> Maybe these warnings should be disabled?
> That would mean that a cast from const to not const wouldn't be detected
> anymore which can potentially lead to problems which are really hard to
I was speaking about the shadowing warnings in Vectors, not about
Regarding const, restrict etc: This leads to a warning in C:
double * restrict * x = malloc(...);
because the call to free (implicitly) casts away the "restrict". It is
really difficult to get around these warnings.
>> 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?
> Maybe. Which warnings to enable and to disable is more often than not a
> matter of taste.
> Given that we will setup a regular build at LSU soon anyway, we will
> capture the build log as well and produce these graphs from them. When
> we get that for a few different configurations (compilers ect), we
> should have a good way to see how far we are off that target.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> -----END PGP SIGNATURE-----
Erik Schnetter <schnetter at cct.lsu.edu>
More information about the Users