[Users] Compiler warnings

[Frank Loeffler]

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.

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

> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20120511/cbbab4c6/attachment.bin