Bug 1303315

Summary: Optimiser produces incorrect code for x86 builds since gcc 6 upgrade
Product: [Fedora] Fedora Reporter: Tom Hughes <tom>
Component: gccAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: davejohansen, jakub, jwakely, law, mpolacek
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-02-08 15:39:45 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Test case none

Description Tom Hughes 2016-01-30 17:30:33 UTC
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):

gcc-6.0.0-0.5.fc24.x86_64

Comment 1 Jakub Jelinek 2016-01-30 18:06:20 UTC
Can you please provide the testcase?  I don't see any attachments.

Comment 2 Tom Hughes 2016-01-30 18:07:45 UTC
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 15:39:45 UTC
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.