Hello, I was trying to reproduce issue #11297 (CmmSwitchTest is broken on 32-bit platforms ) from Newcomers page and seems to stuck. I would like to ask for help here, but if there is a more suitable place to ask, please let me know. I've built current master (8c33cd4) stage2 compiler, removed "when(wordsize(32), expect_broken(11297))" from testsuite/tests/codeGen/should_run/all.T to see same errors as in issue and got this (unrelated?) assertion: =====> CmmSwitchTest(normal) 1 of 1 [0, 0, 0] cd ./codeGen/should_run && "/home/avd/ghc/inplace/test spaces/ghc-stage2" -o CmmSwitchTest CmmSwitchTest.hs -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fshow-warning-groups -fno-ghci-history > CmmSwitchTest.comp.stderr 2>&1 Compile failed (status 256) errors were: [1 of 1] Compiling Main ( CmmSwitchTest.hs, CmmSwitchTest.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160419 for i386-unknown-linux): ASSERT failed! CallStack (from HasCallStack): assertPprPanic, called at compiler/basicTypes/Literal.hs:224:75 in ghc:Literal 18446744073709551615 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for CmmSwitchTest(normal) Is there anything I can do with this? Is it because that test has 64-bit unboxed integers and I'm running it on 32-bit VM? Thanks, Alex
Hi Alex, welcome on ghc-dev. Am Donnerstag, den 21.04.2016, 23:22 +0300 schrieb Alex Dzyoba:
I was trying to reproduce issue #11297 (CmmSwitchTest is broken on 32-bit platforms ) from Newcomers page and seems to stuck. I would like to ask for help here, but if there is a more suitable place to ask, please let me know.
This is the right place!
I've built current master (8c33cd4) stage2 compiler, removed "when(wordsize(32), expect_broken(11297))" from testsuite/tests/codeGen/should_run/all.T to see same errors as in issue and got this (unrelated?) assertion:
I don’t think it is entirely unrelated, but there is a separate ticket about this: https://ghc.haskell.org/trac/ghc/ticket/10246 It even proposes a fix. But if you want to be unblocked in implementing #11297, simply comment out the assertion in Literal.hs (just for you), or compile without -DDEBUG.
Is there anything I can do with this? Is it because that test has 64-bit unboxed integers and I'm running it on 32-bit VM?
Right, but that is the point of #11297: The test case is tailored to 64 bit, and the task is to create a second test case with 32 bit numbers. Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org
On Thu, Apr 21, 2016 at 10:50:14PM +0200, Joachim Breitner wrote:
I don’t think it is entirely unrelated, but there is a separate ticket about this: https://ghc.haskell.org/trac/ghc/ticket/10246 It even proposes a fix.
But if you want to be unblocked in implementing #11297, simply comment out the assertion in Literal.hs (just for you), or compile without -DDEBUG.
Without asserts it's reproducing. Thanks a lot!
Is there anything I can do with this? Is it because that test has 64-bit unboxed integers and I'm running it on 32-bit VM?
Right, but that is the point of #11297: The test case is tailored to 64 bit, and the task is to create a second test case with 32 bit numbers.
Yes, I saw that it's tricking integer overflow but only for 64 bit. I will come back later with the new test. Thanks, Alex
participants (2)
-
Alex Dzyoba -
Joachim Breitner