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.
On 11 May 2012, at 06:43, Frank Loeffler 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?
A lot of these warnings don't appear when I usually compile, possibly because I usually use the Intel compiler and possibly because of the compiler options. I can take a look at fixing the unused variables in the Kranc-generated thorns next week. I think they come about because Kranc defines constants for every floating point fraction that appears in any finite differencing operator, not just the ones used in a given calculation.
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.
See also https://trac.einsteintoolkit.org/ticket/874.
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@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@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
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
On Fri, May 11, 2012 at 12:47 PM, Frank Loeffler knarf@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-----
users@lists.einsteintoolkit.org
-
Erik Schnetter -
Frank Loeffler -
Ian Hinder