[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Greg Chicares
Subject: Re: [lmi] How to suppress this gcc-9 diagnostic?
Date: Wed, 29 Apr 2020 21:34:39 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]