Bug 1303315 - Optimiser produces incorrect code for x86 builds since gcc 6 upgrade
Optimiser produces incorrect code for x86 builds since gcc 6 upgrade
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jakub Jelinek
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2016-01-30 12:30 EST by Tom Hughes
Modified: 2016-02-08 10:39 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-02-08 10:39:45 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Test case (880 bytes, application/gzip)
2016-01-30 13:07 EST, Tom Hughes
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
GNU Compiler Collection 69570 None None None 2016-01-30 15:04 EST

  None (edit)
Description Tom Hughes 2016-01-30 12:30:33 EST
Description of problem:

Optimiser produces incorrect code for x86 builds since gcc 6 upgrade.

I have a test case extracted from a package that is failing it's self tests on x86 since gcc 6 entered rawhide.

If you unpack the attached archive and run make in the directory it will build a shared library and a test executable that invokes it, in both 32  and 64 bit mode. Running the 64 bit version gets the correct result:

rawhide [~/rgb2hsl] % ./main64
h = 0.333333
s = 1
l = 0.25098

Running the 32 bit version wrongly reports h as zero:

rawhide [~/rgb2hsl] % ./main32
h = 0
s = 1
l = 0.25098

Reducing the optimisation level of the shared library from O2 to O1 fixes it, as does removing -fPIC from the shared library build.

The problem is the rgb_to_hsl function in rgb2hsl.cpp and having followed through the generated code everything seems to be fine up to the end of this line:

        s = l > 0.5 ? delta / (2.0 - gamma) : delta / gamma;

After that it seems to get confused compiling the rest of that if block - in particular it seems to forget it has put "max" on the FPU stack and therefore generated the body of the next statement with an off-by-one error for FPU values.

That's about as far as I've got with diagnosing it so far. Trying to follow through what the optimiser has done gets tricky...

Version-Release number of selected component (if applicable):

Comment 1 Jakub Jelinek 2016-01-30 13:06:20 EST
Can you please provide the testcase?  I don't see any attachments.
Comment 2 Tom Hughes 2016-01-30 13:07 EST
Created attachment 1119657 [details]
Test case

Sorry, not sure what happened there... I'm sure I had attached it...
Comment 3 Jakub Jelinek 2016-02-08 10:39:45 EST
It was agreed that the testcase is invalidly assuming FP equality which is not guaranteed if excess precision is allowed.  That said, with current gcc snapshots it should work as before, but it might change any time in the future.

Note You need to log in before you can comment on or make changes to this bug.