Fix to #5549 breaks integerConstantFolding
The fix to #5549 (closed) makes integerConstantFolding
break (on x86 and x86_64 linux at least).
=====> integerConstantFolding(normal) 1229 of 3047 [3, 4, 0]
cd ./lib/integer && $MAKE -s --no-print-directory integerConstantFolding </dev/null >integerConstantFolding.run.stdout 2>integerConstantFolding.run.stderr
Actual stdout output differs from expected:
--- ./lib/integer/integerConstantFolding.stdout 2011-09-26 12:57:40.214838002 +0200
+++ ./lib/integer/integerConstantFolding.run.stdout 2011-10-22 14:00:27.814342001 +0200
@@ -1,3 +1,10 @@
+Unfolded values found
+lvl9_r2gC = __integer 100060
+lvl13_r2gH = __integer 100059
+quotRemInteger didn't constant fold
+quotRemInteger didn't constant fold
+divModInteger didn't constant fold
+divModInteger didn't constant fold
plusInteger: 200007
timesInteger: 683234160
minusIntegerN: -991
*** unexpected failure for integerConstantFolding(normal)
On x86_64, building without changeset:ca380cd1 makes T5549
fail,
bytes allocated 12228725064 is more than maximum allowed 8000000000
*** unexpected failure for T5549(normal)
On x86 linux, T5549 fails with too good stats (3362960220 allocated, less than minimum allowed 5000000000 for current HEAD, 3362960124 for ghc-7.3.20110913, HEAD without ca380cd1 currently building). The patch doesn't make much difference there for the test case, apparently (seems to make a difference on x86/Darwin, though?).
Can we get good constant folding without losing too much sharing?
Trac metadata
Trac field | Value |
---|---|
Version | 7.3 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | Compiler |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |