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 |