Re: [lmi] How to suppress this gcc-9 diagnostic?

[Greg Chicares]

On 2020-04-29 13:06, Vadim Zeitlin wrote:
> On Wed, 29 Apr 2020 12:44:59 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> /opt/lmi/src/lmi/financial_test.cpp:194:16: error: potential null pointer 
> dereference [-Werror=null-dereference]
> GC>   194 |     accum_p[0] = p[0] * one_plus_i;
[...]
> GC> The code is:
> GC> 
> GC>     std::vector<double> p0(7);       // Payments.
> GC> [...]
> GC>     static double const one_plus_i = 1.0 + i;
> GC>     std::vector<double> accum_p(p.size());
> GC>     accum_p[0] = p[0] * one_plus_i;
> GC> 
> GC> AFAICT, if line 194 is reached, then both 'p0' and 'accum_p'
> GC> must be vectors with seven elements, so dereferencing their
> GC> first elements is valid.
> 
>  I didn't have time to test this myself yet, but this definitely looks like
> an optimizer bug, i.e. I'm pretty sure that the warning wouldn't happen
> when compiling without -O2. I couldn't find anything relevant in gcc bug
> tracker, but I'll try to search more thoroughly a bit later.
> 
>  Of course, even if I do find a bug, it won't really help much. Disabling
> the warning explicitly using pragmas diagnostic push/pop should work, but

That's what I've done in as-yet-unpushed commit a9d9e02b6d.

> the real question is whether the generated code is actually correct.

Well, it's unit test that compares the result of a future-value function
fv() to a manual calculation, much as we might assert that pow(z,2) is
equal to z*z within some tolerance. If the generated code for the manual
calculation (which occurs only in the unit test) is incorrect, then the
unit test will fail, and we'll have found an astonishing code-generation
defect.

But with the disable-this-warning pragma added, the test compiles, runs,
and succeeds with gcc-9, so the generated code does produce the correct
answer. And of course gcc doesn't complain about the production fv()
function that's being tested here.

>  Another potential workaround could be to use "optimise" pragma to turn off
> optimization for this function (as it's just a test, it might not be a
> problem to compile it without optimizations).

But that could mask an actual code-generation error, so I think it's
much better to disable the warning.