Boost logo

Boost Users :

Subject: Re: [Boost-users] [Interval] Help debugging compiler optimization
From: Nathan Ernst (nathan.ernst_at_[hidden])
Date: 2018-03-07 02:43:46


I'm not really an expert in this space, but the one (rather tedious)
exercise I could suggest is that for each differing option between -O0 and
-O2, add the corresponding explicit option until you get the deviation
you're exhibiting.

I did do a diff on your settings, and I didn't really see anything that
stood out to me, hence why I'm suggesting the switch-by-switch test.

I'm not a boost contributor just a user and rare bug reporter. This does
feel like a floating-point optimization switch, though, at least to me.

Regards,
Nate

On Sat, Mar 3, 2018 at 2:08 PM, Tim van Erven <tim_at_[hidden]> wrote:

> Hi Nate,
>
> Thanks for your help.
>
> Below is the output from gcc 7.2.0 on mac os. Apparently the difference
> already happens between -O0 and -O1.
> To summarize:
> - gcc on linux with boost 1.58
> - clang and gcc 7.2.0 on mac os with boost 1.66
> all give wrong (or at least inconsistent) output depending on optimization
> options.
> (Since third1 and third2 are both < 1/3, multiplying them by 3 should give
> an interval with lower end-point < 1, but it sometimes doesn't.)
>
> I am attaching the outputs of
> g++-7 -Q -O0 --help=optimizers > o0.txt
> $ g++-7 -Q -O1 --help=optimizers > o1.txt
>
> $ g++-7 foo.cpp -o foo
> $ ./foo
> third1 = 0.333333333333333314829616256247390992939472198486328125000000
> 0000
> third2 = 0.333333333333333314829616256247390992939472198486328125000000
> 0000
> v1 = (0.999999999999999888977697537484345957636833190917968750000000
> 0000,1.0000000000000000000000000000000000000000000000000000000000000000)
> v2 = (0.999999999999999888977697537484345957636833190917968750000000
> 0000,1.0000000000000000000000000000000000000000000000000000000000000000)
>
> $ g++-7 -O1 foo.cpp -o foo
> ./foo
> third1 = 0.333333333333333314829616256247390992939472198486328125000000
> 0000
> third2 = 0.333333333333333314829616256247390992939472198486328125000000
> 0000
> v1 = (0.999999999999999888977697537484345957636833190917968750000000
> 0000,1.0000000000000000000000000000000000000000000000000000000000000000)
> v2 = (1.000000000000000000000000000000000000000000000000000000000000
> 0000,1.0000000000000000000000000000000000000000000000000000000000000000)
>
> Best,
> Tim
>
>
>
> On 02/03/2018 18:23, Nathan Ernst wrote:
>
> I'm not sure what's going on (seems like maybe a fast but error prone
> floating point rounding), but comparing the optimization flags enabled
> between -O0 and -O2 might help shed some light on it.
>
> You can get the explicit optimization flags enabled for your compiler via:
> g++ -Q -O2 --help=optimizers
> g++ -Q -O0 --help=optimizers
>
> Regards,
> Nate
>
> On Fri, Mar 2, 2018 at 10:17 AM, Tim van Erven via Boost-users <
> boost-users_at_[hidden]> wrote:
>
>> Dear all,
>>
>> I am trying to understand why I am getting different numerical results
>> with the interval library depending on the optimization level of the
>> compiler.
>>
>> I am attaching the smallest example I have been able to create:
>>
>> # On my Mac laptop
>> Apple LLVM version 9.0.0 (clang-900.0.39.2)
>> boost 1.66 (installed via homebrew)
>> $ g++ foo.cpp -o foo
>> $ ./foo
>> third1 = 0.3333333333333333148296162562473909929394721984863281250000
>> 000000
>> third2 = 0.3333333333333333148296162562473909929394721984863281250000
>> 000000
>> v1 = (0.999999999999999888977697537484345957636833190917968750000
>> 0000000,1.00000000000000000000000000000000000000000000000000
>> 00000000000000)
>> v2 = (0.999999999999999888977697537484345957636833190917968750000
>> 0000000,1.00000000000000000000000000000000000000000000000000
>> 00000000000000)
>>
>> $ g++ -O2 foo.cpp -o foo
>> $ ./foo
>> third1 = 0.3333333333333333148296162562473909929394721984863281250000
>> 000000
>> third2 = 0.3333333333333333148296162562473909929394721984863281250000
>> 000000
>> v1 = (1.000000000000000000000000000000000000000000000000000000000
>> 0000000,1.00000000000000000000000000000000000000000000000000
>> 00000000000000)
>> v2 = (1.000000000000000000000000000000000000000000000000000000000
>> 0000000,1.00000000000000000000000000000000000000000000000000
>> 00000000000000)
>>
>> I would expect to get the same output in both cases, but the lower
>> end-points are different in the second case, and seem wrong to me since
>> third2 * 3.0 < 1.0.
>>
>> # On my Linux machine the effect is different:
>> gcc version 5.4.0 20160609
>> boost 1.58 on Ubuntu 16.04.9
>>
>> $ g++ foo.cpp -o foo
>> $ ./foo
>> third1 = 0.3333333333333333148296162562473909929394721984863281250000
>> 000000
>> third2 = 0.3333333333333333148296162562473909929394721984863281250000
>> 000000
>> v1 = (0.999999999999999888977697537484345957636833190917968750000
>> 0000000,1.00000000000000000000000000000000000000000000000000
>> 00000000000000)
>> v2 = (0.999999999999999888977697537484345957636833190917968750000
>> 0000000,1.00000000000000000000000000000000000000000000000000
>> 00000000000000)
>>
>> $ g++ -O2 foo.cpp -o foo
>> $ ./foo
>> third1 = 0.3333333333333333148296162562473909929394721984863281250000
>> 000000
>> third2 = 0.3333333333333333148296162562473909929394721984863281250000
>> 000000
>> v1 = (0.999999999999999888977697537484345957636833190917968750000
>> 0000000,1.00000000000000000000000000000000000000000000000000
>> 00000000000000)
>> v2 = (1.000000000000000000000000000000000000000000000000000000000
>> 0000000,1.00000000000000000000000000000000000000000000000000
>> 00000000000000)
>>
>> Can anyone explain what is going on?
>>
>> Thanks in advance,
>>
>> Tim
>>
>> --
>> Tim van Erven <tim_at_[hidden]> <tim_at_[hidden]>www.timvanerven.nl
>>
>>
>> _______________________________________________
>> Boost-users mailing list
>> Boost-users_at_[hidden]
>> https://lists.boost.org/mailman/listinfo.cgi/boost-users
>>
>>
>
> --
> Tim van Erven <tim_at_[hidden]> <tim_at_[hidden]>www.timvanerven.nl
>
>



Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net