Program produces different output when compiled with -O

changed weight to 5

Attached file Subtlety.hs ($1009).

Source file to reproduce issue

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.

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

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

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.

Attached file GHC output.zip (download).

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

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.

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

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.

mentioned in commit 225afc4a

closed

Replying to [ticket:9407#comment:112603 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.

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed
Test case	- → numeric/should_run/T9407

I wonder if this might have been the same bug as #10521 (closed). 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.

Replying to [ticket:9407#comment:114640 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.

added incorrect runtime result label

added Pnormal label

Trac field	Value
Version	7.8.3
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

Program produces different output when compiled with -O

Child items ...

Activity