Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#9407 closed bug (fixed)

Program produces different output when compiled with -O

Reported by: arotenberg Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.8.3
Keywords: Cc:
Operating System: Windows Architecture: x86_64 (amd64)
Type of failure: Incorrect result at runtime Test Case: numeric/should_run/T9407
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

When compiled and run as

ghc Subtlety.hs
Subtlety

the attached program generates the correct output of

Just (Vec3 0.0 0.0 1.0)

but when compiled and run using

ghc -O Subtlety.hs
Subtlety

the program's output is

Just (Vec3 0.0 0.9805806756909202 0.19611613513818404)

Furthermore, subtle changes to the source code (like removing the strictness on the Vec3 type's fields) can alter the behavior of the compiled program.

I am using GHC 7.8.3 x86-64 from Haskell Platform 2014.2.0.0 RC2 on Windows 8.

Attachments (2)

Subtlety.hs (1.6 KB) - added by arotenberg 5 years ago.
Source file to reproduce issue
GHC output.zip (89.8 KB) - added by arotenberg 5 years ago.
Output of compiling with -dverbose-core2core -ddump-occur-anal -ddump-rule-rewrites -ddump-inlinings

Download all attachments as: .zip

Change History (13)

Changed 5 years ago by arotenberg

Attachment: Subtlety.hs added

Source file to reproduce issue

comment:1 Changed 5 years ago by rwbarton

How odd. I can't reproduce on GHC 7.8.3 x86-64 on Debian.

Note that the output of the optimized program is normalized (Vec3 0 5 1), so it looks like some of the x/y/z-coordinates are getting mixed up somehow.

comment:2 Changed 5 years ago by simonpj

I can't reproduce the behaviour either, though I am not using precisely 7.8.3. Can other people reproduce?

Can you compile both ways with -dverbose-core2core -ddump-occur-anal -ddump-rule-rewrites -ddump-inlinings and attach the results?

Simon

comment:3 Changed 5 years ago by simonpj

Note to self: however with HEAD (but not with 7.8) I get

WARNING: file compiler/simplCore/SimplCore.lhs, line 629
    Simplifier bailing out after 4 iterations [584, 82, 104, 18]
      Size = {terms: 655, types: 264, coercions: 12}

so I'm getting more simplifier iterations apparently. Not related to the issue at hand, though.

Simon

comment:4 Changed 5 years ago by arotenberg

I have verified that I can consistently recreate the issue on another computer running Windows 7 x86-64 with GHC 7.8.3. I believe the issue was also present in 7.8.2, since I upgraded to 7.8.3 with the express purpose of seeing if this issue had been fixed.

Changed 5 years ago by arotenberg

Attachment: GHC output.zip added

Output of compiling with -dverbose-core2core -ddump-occur-anal -ddump-rule-rewrites -ddump-inlinings

comment:5 Changed 5 years ago by arotenberg

I have now also verified that this problem does not occur on 32-bit Windows nor when using 32-bit GHC on 64-bit Windows. But you should be able to reproduce it if you use 64-bit Windows and 64-bit GHC 7.8.3.

comment:6 Changed 5 years ago by simonpj

OK so it seems likely to be something to do with 64-bit floating-point arithmetic.

I wonder if it makes a difference whether you use the native code generator or LLVM?

Does anyone feel able to investigate? The program isn't very big, and has no dependencies other than Prelude.

Simon

comment:7 Changed 4 years ago by rdragon

It looks like this issue has been fixed in GHC 7.10.2 or before. I can reproduce the problem with GHC 7.8.3, but not with 7.10.2. In both cases I use the 64-bit version.

comment:8 Changed 4 years ago by Thomas Miedema <thomasmiedema@…>

In 225afc4a/ghc:

Add test T9407 (Windows)

Add test for #9407. The test is only run on Windows 64bit, as this is
where the problem occurred.

Reviewed by: thomie

Differential Revision: https://phabricator.haskell.org/D1806

comment:9 in reply to:  7 Changed 4 years ago by thomie

Resolution: fixed
Status: newclosed
Test Case: numeric/should_run/T9407

Replying to rdragon:

It looks like this issue has been fixed in GHC 7.10.2 or before. I can reproduce the problem with GHC 7.8.3, but not with 7.10.2. In both cases I use the 64-bit version.

Since bisecting pre-7.10 commit ranges is rather difficult, I say we leave it at this. Let's hope it's really fixed! If someone really wants to investigate further, they can of course do so, and reopen this ticket.

comment:10 Changed 4 years ago by rwbarton

I wonder if this might have been the same bug as #10521. If so then it should be broken in 7.8 and 7.10.1 but not 7.6 or 7.10.2. I have no specific theory about why it would be Windows-only though.

If someone would care to test 7.10.1 and 7.6 on Windows, I would be curious to know the results.

comment:11 in reply to:  10 Changed 4 years ago by rdragon

Replying to rwbarton:

If someone would care to test 7.10.1 and 7.6 on Windows, I would be curious to know the results.

I tested with GHC 7.6.3 and 7.10.1 on Windows 64bit. The issue was already present in 7.6.3 (I got the wrong output), but was already fixed in 7.10.1. Looks like a different bug, I'm afraid.

Note: See TracTickets for help on using tickets.