Re: Failing Test Cases in HEAD
`devel2` compiles GHC with extra assertions and `./validate` doesn't do that. There's `./validate --slow` that enables extra assertions. AFAIK harbormaster (and most ghc-devs) only does `./validate` which explains how failures like this can sneak in. We used to have a travis build that did `./validate --slow`, but it looks like travis currently fails at configure with: configure: error: GHC version 8.0 or later is required to compile GHC. Some more details here: https://ghc.haskell.org/trac/ghc/wiki/TestingPatches Cheers, Bartosz 2017-08-14 14:51 GMT+01:00 Shayan Najd : > In a freshly cloned GHC code base (c6462ab0...), in my system,`make test > TEST="T13780c T13822"` fails. > That is while `./validate` passes. > > I am rather new to GHC code base, and not so familiar with its build and > testing system. > So I was wondering whether this is an intended behaviour (e.g., some test > cases are intentionally left out of `./validate`). > > Specifically, I follow the following steps: > (1) `git clone --recursive git://git.haskell.org/ghc.git` > (2) `cd ghc` > (3) `cp mk/build.mk.sample mk/build.mk` > (4) set `BuildFlavour = devel2` and then > (5) ./boot > (6) ./configure > (7) make -j4 > (8) make test TEST="T13780c T13822" > > I build in a variant of the docker image for GHC development on Linux (64 > bit), if it matters. > > As it seems, Alan also gets the similar result on his system. > > I am investigating this, since my development of Growable ASTs is stalled > due to some "GHC panic bug" when validating. > (In my repo[1], I can successfully build with steps (2)-(7) above but > `./validate` (and `make test TEST="T13780c T13822"`) fails) > > Thanks, > Shayan > > [1] https://github.com/shayan-najd/GrowableGHC > > > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: failing
Simon Peyton Jones writes: > Can you? With comment etc. > Of course. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: failing
Can you? With comment etc. Simon | -Original Message- | From: Ben Gamari [mailto:b...@smart-cactus.org] | Sent: 12 October 2016 13:38 | To: Simon Peyton Jones ; Simon Peyton Jones via | ghc-devs ; Ben Gamari | Cc: ghc-devs@haskell.org | Subject: Re: failing | | On October 12, 2016 8:27:24 AM EDT, Simon Peyton Jones via ghc-devs | wrote: | >Ben: all builds are failing | >https://phabricator.haskell.org/harbormaster/ | >What’s up? I see a perf failure on T1969. Does not happen for me; | and | >is only in residency, so just bump it? | > | >Simon | > | > | >- | -- | >- | > | >___ | >ghc-devs mailing list | >ghc-devs@haskell.org | >https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail. | ha | >skell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devs&data=01%7C01%7Csimo | >npj%40microsoft.com%7C666f491b93a2430e990b08d3f29ca1d4%7C72f988bf86f1 | 41 | >af91ab2d7cd011db47%7C1&sdata=BiH9cQXWJiiyYhh9SlX4QOGDhYXusSUpwOxZa3f% | 2F | >nhg%3D&reserved=0 | | Oh dear, this doesn't fail for me either. I suppose the best option | for the time being is to simply bump it, but this does reiterate the | need to do something about our performance test cases. | | Cheers, | | - Ben ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: failing
On October 12, 2016 8:27:24 AM EDT, Simon Peyton Jones via ghc-devs wrote: >Ben: all builds are failing >https://phabricator.haskell.org/harbormaster/ >What’s up? I see a perf failure on T1969. Does not happen for me; and >is only in residency, so just bump it? > >Simon > > > > >___ >ghc-devs mailing list >ghc-devs@haskell.org >http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs Oh dear, this doesn't fail for me either. I suppose the best option for the time being is to simply bump it, but this does reiterate the need to do something about our performance test cases. Cheers, - Ben ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Failing tests: literals T5681 annotations
On Tue, Dec 2, 2014 at 5:58 PM, Joachim Breitner
wrote:
> Hi,
>
>
> Am Sonntag, den 30.11.2014, 20:01 +0100 schrieb Joachim Breitner:
> > I’m still seeing this failure:
> >
> > Compile failed (status 256) errors were:
> > /tmp/ghc16123_0/ghc16123_5.s: Assembler messages:
> >
> > /tmp/ghc16123_0/ghc16123_5.s:26:0:
> > Error: can't resolve `.rodata' {.rodata section} -
> `Main_zdwwork_info$def' {.text section}
> >
> > /tmp/ghc16123_0/ghc16123_5.s:46:0:
> > Error: can't resolve `.rodata' {.rodata section} -
> `Main_work_info$def' {.text section}
> >
> > /tmp/ghc16123_0/ghc16123_5.s:66:0:
> > Error: can't resolve `.rodata' {.rodata section} -
> `Main_main1_info$def' {.text section}
> >
> > /tmp/ghc16123_0/ghc16123_5.s:86:0:
> > Error: can't resolve `.rodata' {.rodata section} -
> `Main_main_info$def' {.text section}
> >
> > /tmp/ghc16123_0/ghc16123_5.s:106:0:
> > Error: can't resolve `.rodata' {.rodata section} -
> `Main_main2_info$def' {.text section}
> >
> > /tmp/ghc16123_0/ghc16123_5.s:126:0:
> > Error: can't resolve `.rodata' {.rodata section} -
> `ZCMain_main_info$def' {.text section}
> >
> > *** unexpected failure for T5681(optllvm)
> >
> >
> > https://s3.amazonaws.com/archive.travis-ci.org/jobs/42557559/log.txt
> >
> > Any ideas?
>
> is it possible that this is due the llvm version used? Do we support 3.4
> in GHC HEAD?
>
>Using LLVM tools
> llc : /usr/local/clang-3.4/bin/llc
> opt : /usr/local/clang-3.4/bin/opt
>
This appears to affect all programs built with llvm-3.4. I filed a ticket (
http://ghc.haskell.org/trac/ghc/ticket/9929).
Regards,
Reid Barton
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Failing tests: literals T5681 annotations
Hi,
Am Sonntag, den 30.11.2014, 20:01 +0100 schrieb Joachim Breitner:
> I’m still seeing this failure:
>
> Compile failed (status 256) errors were:
> /tmp/ghc16123_0/ghc16123_5.s: Assembler messages:
>
> /tmp/ghc16123_0/ghc16123_5.s:26:0:
> Error: can't resolve `.rodata' {.rodata section} -
> `Main_zdwwork_info$def' {.text section}
>
> /tmp/ghc16123_0/ghc16123_5.s:46:0:
> Error: can't resolve `.rodata' {.rodata section} - `Main_work_info$def'
> {.text section}
>
> /tmp/ghc16123_0/ghc16123_5.s:66:0:
> Error: can't resolve `.rodata' {.rodata section} - `Main_main1_info$def'
> {.text section}
>
> /tmp/ghc16123_0/ghc16123_5.s:86:0:
> Error: can't resolve `.rodata' {.rodata section} - `Main_main_info$def'
> {.text section}
>
> /tmp/ghc16123_0/ghc16123_5.s:106:0:
> Error: can't resolve `.rodata' {.rodata section} - `Main_main2_info$def'
> {.text section}
>
> /tmp/ghc16123_0/ghc16123_5.s:126:0:
> Error: can't resolve `.rodata' {.rodata section} -
> `ZCMain_main_info$def' {.text section}
>
> *** unexpected failure for T5681(optllvm)
>
>
> https://s3.amazonaws.com/archive.travis-ci.org/jobs/42557559/log.txt
>
> Any ideas?
is it possible that this is due the llvm version used? Do we support 3.4
in GHC HEAD?
Using LLVM tools
llc : /usr/local/clang-3.4/bin/llc
opt : /usr/local/clang-3.4/bin/opt
Greetings,
Joachim
--
Joachim “nomeata” Breitner
m...@joachim-breitner.de • http://www.joachim-breitner.de/
Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F
Debian Developer: nome...@debian.org
signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Failing tests: literals T5681 annotations
Hi,
I’m still seeing this failure:
Compile failed (status 256) errors were:
/tmp/ghc16123_0/ghc16123_5.s: Assembler messages:
/tmp/ghc16123_0/ghc16123_5.s:26:0:
Error: can't resolve `.rodata' {.rodata section} - `Main_zdwwork_info$def'
{.text section}
/tmp/ghc16123_0/ghc16123_5.s:46:0:
Error: can't resolve `.rodata' {.rodata section} - `Main_work_info$def'
{.text section}
/tmp/ghc16123_0/ghc16123_5.s:66:0:
Error: can't resolve `.rodata' {.rodata section} - `Main_main1_info$def'
{.text section}
/tmp/ghc16123_0/ghc16123_5.s:86:0:
Error: can't resolve `.rodata' {.rodata section} - `Main_main_info$def'
{.text section}
/tmp/ghc16123_0/ghc16123_5.s:106:0:
Error: can't resolve `.rodata' {.rodata section} - `Main_main2_info$def'
{.text section}
/tmp/ghc16123_0/ghc16123_5.s:126:0:
Error: can't resolve `.rodata' {.rodata section} - `ZCMain_main_info$def'
{.text section}
*** unexpected failure for T5681(optllvm)
https://s3.amazonaws.com/archive.travis-ci.org/jobs/42557559/log.txt
Any ideas?
Greetings,
Joachim
--
Joachim “nomeata” Breitner
m...@joachim-breitner.de • http://www.joachim-breitner.de/
Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F
Debian Developer: nome...@debian.org
signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Failing tests: literals T5681 annotations
Hi,
Am Samstag, den 22.11.2014, 11:35 +0100 schrieb Joachim Breitner:
> I currently observe
>
> Unexpected results from:
> TEST="literals T5681 annotations"
this has improved to just
TEST="T5681 annotations"
but still this needs some investigation. Maybe a problem with parallel
test runs and temporary files cleaned out too quickly?
>
> Details:
>
> Compile failed (status 256) errors were:
> /tmp/ghc13786_0/ghc13786_5.s: Assembler messages:
>
> /tmp/ghc13786_0/ghc13786_5.s:26:0:
> Error: can't resolve `.rodata' {.rodata section} -
> `Main_zdwwork_info$def' {.text section}
>
> /tmp/ghc13786_0/ghc13786_5.s:46:0:
> Error: can't resolve `.rodata' {.rodata section} - `Main_work_info$def'
> {.text section}
>
> /tmp/ghc13786_0/ghc13786_5.s:66:0:
> Error: can't resolve `.rodata' {.rodata section} - `Main_main1_info$def'
> {.text section}
>
> /tmp/ghc13786_0/ghc13786_5.s:86:0:
> Error: can't resolve `.rodata' {.rodata section} - `Main_main_info$def'
> {.text section}
>
> /tmp/ghc13786_0/ghc13786_5.s:106:0:
> Error: can't resolve `.rodata' {.rodata section} - `Main_main2_info$def'
> {.text section}
>
> /tmp/ghc13786_0/ghc13786_5.s:126:0:
> Error: can't resolve `.rodata' {.rodata section} -
> `ZCMain_main_info$def' {.text section}
>
> *** unexpected failure for T5681(optllvm)
> *** unexpected failure for annotations(normal)
>
> Wrong exit code (expected 0 , actual 2 )
> Stdout:
>
> Stderr:
> /usr/bin/ld: reopening literals.o: No such file or directory
>
> /usr/bin/ld:literals.o: bfd_stat failed: No such file or directory
> /usr/bin/ld: reopening literals.o: No such file or directory
>
> /usr/bin/ld: BFD (GNU Binutils for Ubuntu) 2.22 internal error, aborting at
> ../../bfd/merge.c line 873 in _bfd_merged_section_offset
>
> /usr/bin/ld: Please report this bug.
>
> collect2: ld returned 1 exit status
> make[3]: *** [literals] Error 1
>
> *** unexpected failure for literals(normal)
Thanks,
Joachim
--
Joachim “nomeata” Breitner
m...@joachim-breitner.de • http://www.joachim-breitner.de/
Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F
Debian Developer: nome...@debian.org
signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Failing ASSERT in ghci044 and ghci047
Thanks. These are tests that over-ride one instance declaration with another, something that really wasn't working before. I have no idea what is going on in Linker.hs It's the weekend so I'm not going to have a chance to look at this for a bit -- and oddly it seems to work anyway. But asserts should not fail. If someone had time to make it an ASSERT2 and print out the relevant entrails (toplev_only, nms, and the context of ce_in (not the HValue component, obviously)), that would be helpful. Simon | -Original Message- | From: Edward Z.Yang [mailto:ezy...@cs.stanford.edu] | Sent: 01 August 2014 18:41 | To: ghc-devs | Cc: Simon Peyton Jones | Subject: Failing ASSERT in ghci044 and ghci047 | | CC'd Simon because you were touching these test-cases recently. | | You'll need to run with -DDEBUG, which is probably why validate didn't | catch these. Maybe the ASSERT is out of date? | | => ghci044(ghci) 1719 of 4065 [0, 0, 0] | [72/1822] | cd ./ghci/scripts && HC='/home/hs01/ezyang/ghc-validate/inplace/bin/ghc- | stage2' HC_OPTS='-dcore-lint - | dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci- | history ' '/home/hs01/ezyang/ghc-va | lidate/inplace/bin/ghc-stage2' --interactive -v0 -ignore-dot-ghci -dcore- | lint -dcmm-lint -dno-debug-ou | tput -no-user-package-db -rtsopts -fno-ghci-history ghci044.run.stdout 2>ghci044. | run.stderr | Actual stderr output differs from expected: | --- ./ghci/scripts/ghci044.stderr 2014-07-31 11:00:16.433141666 - | 0700 | +++ ./ghci/scripts/ghci044.run.stderr 2014-08-01 10:38:17.352234466 - | 0700 | @@ -6,3 +6,12 @@ |instance C a => C [a] -- Defined at :8:10 | In the expression: f [4 :: Int] | In an equation for ‘it’: it = f [4 :: Int] | +*** Exception: ASSERT failed! file compiler/ghci/Linker.lhs, line 907 | +*** Exception: ASSERT failed! file compiler/ghci/Linker.lhs, line 907 | +*** Exception: ASSERT failed! file compiler/ghci/Linker.lhs, line 907 | +*** Exception: ASSERT failed! file compiler/ghci/Linker.lhs, line 907 | + | +:15:1: | +No instance for (C Bool) arising from a use of ‘f’ | +In the expression: f [True] | +In an equation for ‘it’: it = f [True] | Actual stdout output differs from expected: | | => ghci047(ghci) 1723 of 4065 [0, 1, 0] | cd ./ghci/scripts && HC='/home/hs01/ezyang/ghc-validate/inplace/bin/ghc- | stage2' HC_OPTS='-dcore-lint - | dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci- | history ' '/home/hs01/ezyang/ghc-va | lidate/inplace/bin/ghc-stage2' --interactive -v0 -ignore-dot-ghci -dcore- | lint -dcmm-lint -dno-debug-ou | tput -no-user-package-db -rtsopts -fno-ghci-history ghci047.run.stdout 2>ghci047. | run.stderr | Actual stderr output | Actual stderr output differs from expected: | --- ./ghci/scripts/ghci047.stderr 2014-05-28 15:38:19.608946057 - | 0700 | +++ ./ghci/scripts/ghci047.run.stderr 2014-08-01 10:38:17.658906746 - | 0700 | @@ -1,16 +1,14 @@ | +*** Exception: ASSERT failed! file compiler/ghci/Linker.lhs, line 907 | +*** Exception: ASSERT failed! file compiler/ghci/Linker.lhs, line 907 | | | Cheers, | Edward ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Failing test
OK i’ve fixed these. will push when I have valiated From: Iavor Diatchki [mailto:iavor.diatc...@gmail.com] Sent: 14 January 2013 18:40 To: Simon Peyton-Jones Cc: ghc-devs@haskell.org Subject: Re: Failing test Hello, On Mon, Jan 14, 2013 at 9:52 AM, Simon Peyton-Jones mailto:simo...@microsoft.com>> wrote: Are these four failures the result of your changes? Should we fix the tests? (sorry, this went to the fun-dep thread so it probably got buried among the other e-mails). About the tests: When I ran the type-checker tests, I got these 3 failures that I am not sure how to fix: Unexpected failures: should_compile tc226 [exit code non-0] (hpc,optasm) should_compile tc235 [exit code non-0] (normal,hpc,optasm) should_fail T5684 [stderr mismatch] (normal) - tc226 appears to be completely unrelated to my changes, so I imagine it is about something else? - tc235 is a program that is now rejected. I am not sure how to fix this test as the program inside seems incorrect at many levels (e.g., it violates the FD of the class, but it also uses ambiguous methods). I also couldn't figure out what it is testing. - T5684 is still rejected but with a different error, because one of the instances violates the FD of the class. However, this test appears to be carefully designed to test something else, but I didn't quite follow exactly what, so I left it as is for the moment. Would you mind taking a look and advising on what to do? I think that the new behavior is correct for tc235 and T5684, but it would be nice to preserve whatever was originally tasted there (unless it was an artifact of the lax checking of the FDs) Should the error message say “The instance decl is inconsistent with the fundeps”? And maybe be more precise about which fundep. We could do that. The current message replaces "the Coverage Condition fails for one of the functional dependencies", because I thought that it is more descriptive. The way the tests is written---both the coverage condition, and the new one---they return just a boolean, but I could probably to return the FD that is being violated. I'll have a go at it. I’m a bit confused. About which part? Here is an example of what we are checking for: class C a b | a -> b instance C Int b -- bad instance The instance violated the FD on the class because it implies that both `C Int Int` and `C Int Char` hold, which violated the FD. This is what I meant by "multiple uses of the instance may violate the functional dependency". The reason I opted to go for "may" in the message is because strictly speaking the test is incomplete (i.e., there are somewhat contrived examples that are consistent with the FD, but would be rejected, I can send one if it'd be useful?). -Iavor ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Failing test
Hello, On Mon, Jan 14, 2013 at 9:52 AM, Simon Peyton-Jones wrote: > > Are these four failures the result of your changes? > > Should we fix the tests? > (sorry, this went to the fun-dep thread so it probably got buried among the other e-mails). About the tests: When I ran the type-checker tests, I got these 3 failures that I am not sure how to fix: Unexpected failures: should_compile tc226 [exit code non-0] (hpc,optasm) should_compile tc235 [exit code non-0] (normal,hpc,optasm) should_fail T5684 [stderr mismatch] (normal) - tc226 appears to be completely unrelated to my changes, so I imagine it is about something else? - tc235 is a program that is now rejected. I am not sure how to fix this test as the program inside seems incorrect at many levels (e.g., it violates the FD of the class, but it also uses ambiguous methods). I also couldn't figure out what it is testing. - T5684 is still rejected but with a different error, because one of the instances violates the FD of the class. However, this test appears to be carefully designed to test something else, but I didn't quite follow exactly what, so I left it as is for the moment. Would you mind taking a look and advising on what to do? I think that the new behavior is correct for tc235 and T5684, but it would be nice to preserve whatever was originally tasted there (unless it was an artifact of the lax checking of the FDs) > ** > > Should the error message say “The instance decl is inconsistent with the > fundeps”? And maybe be more precise about which fundep. > > ** > We could do that. The current message replaces "the Coverage Condition fails for one of the functional dependencies", because I thought that it is more descriptive. The way the tests is written---both the coverage condition, and the new one---they return just a boolean, but I could probably to return the FD that is being violated. I'll have a go at it. > I’m a bit confused. > About which part? Here is an example of what we are checking for: class C a b | a -> b instance C Int b -- bad instance The instance violated the FD on the class because it implies that both `C Int Int` and `C Int Char` hold, which violated the FD. This is what I meant by "multiple uses of the instance may violate the functional dependency". The reason I opted to go for "may" in the message is because strictly speaking the test is incomplete (i.e., there are somewhat contrived examples that are consistent with the FD, but would be rejected, I can send one if it'd be useful?). -Iavor ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
