On Wed, Nov 21, 2012 at 12:00 PM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 21 Nov 2012, at 17:52, Erik Schnetter schnetter@cct.lsu.edu wrote:
On Thu, Nov 15, 2012 at 11:49 PM, Frank Loeffler knarf@cct.lsu.edu wrote:
On Mon, Nov 12, 2012 at 08:56:10AM -0800, Roland Haas wrote:
Next release:
- query on cactususers for suggestions for next release goal
We also talked about trying to look into the number of compiler warnings that are generated. I produced a graph showing the status as of the last release [1], parsed from the output of a build [2]. Most of the warnings are produced from auto-generated code, for shadowed and/or unused variables; and Ian Hinder has some ideas about how to fix this. Others will have to be looked into by hand.
I have begun to look into the reported warnings. Most are harmless and can be corrected very easily. Some point to cases where an error check in the code is missing. Other are difficult to avoid, e.g. when "const" or "restrict" is involved.
And in one case I found an actual error in RotatingSymmetry90. Tensor indices where calculated in the wrong way. This concerns "dd" tensors, i.e. 3x3 tensors without symmetry. I believe we don't use these, so the error went undetected.
I have eliminated a few thousand warnings (those from Kranc-generated code) as well as in a few other places. As Erik said, these are usually about adding an error check. We now have about 1000 warnings remaining. Of these, 340 come from one particular repeated macro call in LocalReduce. I couldn't see a quick fix for this because the code is a little bit involved (as usual with macro code). I expect that many of these come from repetitive code which can be fixed in a batch rather than having to investigate and solve 1000 different problems.
I may have mentioned before that LocalReduce has many problems. The highly repetitive nature of the code is the most obvious; it also contains errors in the definitions of the reduction operators, at least for complex numbers. I suggest to not try and fix it, as this would require analysing the thorn to ensure that the warnings are actually harmless. (I obviously object to simply "papering over" warnings to make them go away.) Using C++ and templates would lead to a much smaller, simpler thorn.
-erik