[Users] Compiler warnings

[Erik Schnetter]

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
> hand.

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
> debug.

I was speaking about the shadowing warnings in Vectors, not about
const warnings.

Regarding const, restrict etc: This leads to a warning in C:

double * restrict * x = malloc(...);
free(x);

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.
>
> Frank
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIcBAEBCAAGBQJPrUKzAAoJEOkzpip+I59kr8YQAK+KbOIMGN4hsvljJFcCfeOt
> 29BUXBZEzzp6tiYqjcs2+CDG3JsrsUycjTDx1j9mbjDggN5CrsFKLplKm7MjBNy9
> dwgF26F1s/vCrEQZUncHQ00hEJWtZrqmX5j3SZ/lQocSE375hhQCsULW1TIK56M8
> gFsCHloax7Tss1Ucv2z7TAhUYsDHx4MeCqYorj7cE1iNImIcOyXKU1l1Q9hXlyiw
> KycVlq7oMZW7cfeiUojLcHRMfqSgUi0nvSVthP94Zl1E+wa88agMg12P9dVws3e0
> 3nEXFIGn68vHFF++81YMLgXUXxcU6QXjTVTD9f1ks2CWhcmwDq7ysvz4IdDj/TlG
> W9x6FMIntuvlq2xoLVkos0RdEQFVxUHz2cRy1MfrIgNsAizeuV5ImMCytG7YIyTN
> Qlg3Ch0ZpYgxvEHgIMarAFmPUYXYaCjWpjZM5E09OK3SkZdEP69hjINm570iTAM1
> i84Mdaj99gegjL9/kIsoCSGdxO6b8DjazXkta3YNXd4VIcGluvNhkKedsAZEd65d
> d/gQ9fb7lNSzX5vK3kTFRzqtAxR9JmHNdpHxQXlXWq208c20vO45QU5dm7RtfxFc
> Kkr/7wpueKvYSI8B5Abknm4O1+/TGZ6x/TE76xM840cAEkEkEMQ/BF1RQbULth3n
> LTLdwOEZdHRyZwqmOZex
> =bB8F
> -----END PGP SIGNATURE-----
>



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