Re: ghc 8.6.x release clearly fails validate or even make test, some help please!

2018-11-19 Thread Ben Gamari 


On November 20, 2018 2:06:55 AM GMT+00:00, Carter Schonwald 
 wrote:
>Hey Everyone ...
>I'm concerned, it looks like ghc 8.6.2 on OSX doens't pass validate or
>even
>a rudimentary `make test`
>
>I'm not sure how to make  heads or tails of all these errors, and it
>looks
>like a huge amount of dev work over time has accumulated some failures
>
>
I can't reproduce this. The binary distributions are produced by CircleCI , 
which runs the test suite.

Can you be more specific about how you are running this test? 

Cheers, 

- Ben 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

ghc 8.6.x release clearly fails validate or even make test, some help please!

2018-11-19 Thread Carter Schonwald 
Hey Everyone ...
I'm concerned, it looks like ghc 8.6.2 on OSX doens't pass validate or even
a rudimentary `make test`

I'm not sure how to make  heads or tails of all these errors, and it looks
like a huge amount of dev work over time has accumulated some failures 

could the code owners on these sub systems at least help me make heads or
tails of these errors?


SUMMARY for test run started at Mon Nov 19 19:48:18 2018 EST
 0:28:32 spent to go through
6516 total tests, which gave rise to
   25425 test cases, of which
   18538 were skipped

  41 had missing libraries
6380 expected passes
  92 expected failures

   2 caused framework failures
   0 caused framework warnings
   0 unexpected passes
 365 unexpected failures
   7 unexpected stat failures

Unexpected failures:
   backpack/cabal/bkpcabal05/bkpcabal05.run bkpcabal05 [bad
stderr] (normal)
   backpack/cabal/bkpcabal02/bkpcabal02.run bkpcabal02 [bad
stderr] (normal)
   backpack/cabal/bkpcabal06/bkpcabal06.run bkpcabal06 [bad
stderr] (normal)
   backpack/cabal/bkpcabal04/bkpcabal04.run bkpcabal04 [bad
stderr] (normal)
   backpack/cabal/bkpcabal07/bkpcabal07.run bkpcabal07 [bad
stderr] (normal)
   backpack/cabal/bkpcabal03/bkpcabal03.run bkpcabal03 [bad
stderr] (normal)
   backpack/cabal/T14304/T14304.run T14304 [bad
stderr] (normal)
   cabal/T12485/T12485.run  T12485 [bad
stderr] (normal)
   backpack/cabal/bkpcabal01/bkpcabal01.run bkpcabal01 [bad
stderr] (normal)
   cabal/cabal04/cabal04.runcabal04 [bad
stderr] (normal)
   cabal/T12733/T12733.run  T12733 [bad
stderr] (normal)
   cabal/cabal01/cabal01.runcabal01 [bad
stderr] (normal)
   cabal/cabal09/cabal09.runcabal09 [bad
stderr] (normal)
   cabal/cabal03/cabal03.runcabal03 [bad
stderr] (normal)
   codeGen/should_compile/T2578.run T2578 [bad
stderr] (normal)
   cabal/cabal08/cabal08.runcabal08 [bad
stderr] (normal)
   codeGen/should_compile/debug.run debug [bad
stderr] (normal)
   cabal/cabal05/cabal05.runcabal05 [bad
stderr] (normal)
   cabal/cabal06/cabal06.runcabal06 [bad
stderr] (normal)
   deSugar/should_run/T5522.run T5522 [stderr
mismatch] (optasm)
   driver/driver062a.rundriver062a [bad
stderr] (normal)
   driver/driver062b.rundriver062b [bad
stderr] (normal)
   driver/driver062c.rundriver062c [bad
stderr] (normal)
   driver/driver062d.rundriver062d [bad
stderr] (normal)
   driver/driver062e.rundriver062e [bad
stderr] (normal)
   driver/driver081a.rundriver081a [bad
stderr] (normal)
   driver/driver081b.rundriver081b [bad
stderr] (normal)
   driver/rtsopts002.runrtsopts002 [bad
stderr] (normal)
   driver/T3674.run T3674 [bad
stderr] (normal)
   driver/rtsopts001.runrtsopts001 [bad
stderr] (normal)
   driver/withRtsOpts.run   withRtsOpts
[bad stderr] (normal)
   driver/T703.run  T703 [bad
stderr] (normal)
   driver/T5313.run T5313 [bad exit
code] (normal)
   driver/T9938.run T9938 [bad
stderr] (normal)
   driver/T9938B.runT9938B [bad
stderr] (normal)
   driver/T12971.runT12971 [bad
stderr] (normal)
   driver/T10320.runT10320 [bad
stderr] (normal)
   driver/T7835/T7835.run   T7835 [bad
stderr] (normal)
   driver/T437/T437.run T437 [bad
stderr] (normal)
   driver/T13914/T13914.run T13914 [bad
stderr] (normal)
   driver/T1959/T1959.run   T1959 [bad
stderr] (normal)
   driver/dynamic_flags_001/dynamic_flags_001.run
 dynamic_flags_001 [bad stderr] (normal)
   driver/dynamicToo/dynamicToo001/dynamicToo001.rundynamicToo001
[bad stderr] (normal)
   driver/recomp001/recomp001.run   recomp001 [bad
stderr] (normal)
   driver/linkwhole/linkwhole.run   linkwhole [bad
stderr] (normal)
   driver/T3007/T3007.run   T3007 [bad
stderr] (normal

Re: split_marker crash

2018-11-19 Thread Ben Gamari 
Phyx  writes:

> On Mon, Nov 19, 2018 at 8:33 PM Ben Gamari  wrote:
>
>> Andreas Klebinger  writes:
>>
>> > Hello,
>> >
>> > I'm fine with reverting for now. But could you give me a way to
>> > reproduce this error?
>> >
>> > I've not seen crashes on either linux and windows in various configs.
>> >
>> I suspect that Simon is building with SplitObjects enabled. To be
>> honest, I would really like to remove this feature; SplitSections is
>> better in nearly every regard. However, we have been stalled since
>> SplitSections doesn't quite work yet on Windows (or, IIRC, the toolchain
>> is prohibitively slow when it's used). I believe Tamar was working on
>> fixing this.
>>
>
> SplitObjects has been off in favor of SplitSections on Windows since Aug.
> https://github.com/ghc/ghc/commit/23774c98f1368b41515cbd5223b87ea6dbf644e1
>
Ahh, I had forgotten about this. I'll need to check this when I'm back
home but I suspect this means that we can finally rip out (or at least
deprecate) split object support for 8.8.

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: split_marker crash

2018-11-19 Thread Ben Gamari 
Simon Peyton Jones via ghc-devs  writes:

> I do indeed have SplitObs=YES in my validate.mk.
>
Ahh, so perhaps Andreas's finding isn't the culprit afterall. Looking at
the source it looks like `split_marker_entry` is indeed emitted for split
objects support.c

> In the past at least, that made binaries quite a bit smaller.
> Happy to change it to SplitSections=YES if that is more kosher these days?
>
We generally recommend SplitSections at this point. Not only is it
simpler, but it may reduce build times, result in smaller binaries, and
generally stays closer to what C compilers do, avoiding toolchain bugs.

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: split_marker crash

2018-11-19 Thread Phyx 
On Mon, Nov 19, 2018 at 8:53 PM Simon Peyton Jones 
wrote:

> I do indeed have SplitObs=YES in my validate.mk.
>
> In the past at least, that made binaries quite a bit smaller.
>
> Happy to change it to SplitSections=YES if that is more kosher these days?
>

Yes, SplitObjs is no longer supported, will also cause an extremely slow
compilation depending on your optimization level and ways.
Removing the line should let the compiler default to the best choice, in
this case it should go to SplitSections on its
own when compiling stage2.

Regards,
Tamar


>
> Simon
>
>
>
> *From:* Andreas Klebinger 
> *Sent:* 19 November 2018 20:38
> *To:* Ben Gamari 
> *Cc:* Phyx ; Simon Peyton Jones <
> simo...@microsoft.com>; ghc-devs@haskell.org
> *Subject:* Re: split_marker crash
>
>
>
> I might already have found the specific cause.
>
> It seems with split sections we generate a dummy CmmProc, which has as
> entry label
> > error (split_sections_entry)
>
> My patch likely introduces strictness on that field where it was lazy
> before.
> If this is the cause I expect to have a patch up in a hour or two and will
> merge
> it after it validates.
>
> Cheers,
> Andreas
>
> Ben Gamari schrieb:
>
> Andreas Klebinger   
> writes:
>
>
>
> Hello,
>
>
>
> I'm fine with reverting for now. But could you give me a way to
>
> reproduce this error?
>
>
>
> I've not seen crashes on either linux and windows in various configs.
>
>
>
> I suspect that Simon is building with SplitObjects enabled. To be
>
> honest, I would really like to remove this feature; SplitSections is
>
> better in nearly every regard. However, we have been stalled since
>
> SplitSections doesn't quite work yet on Windows (or, IIRC, the toolchain
>
> is prohibitively slow when it's used). I believe Tamar was working on
>
> fixing this.
>
>
>
> Cheers,
>
>
>
> - Ben
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: split_marker crash

2018-11-19 Thread Phyx 
On Mon, Nov 19, 2018 at 8:33 PM Ben Gamari  wrote:

> Andreas Klebinger  writes:
>
> > Hello,
> >
> > I'm fine with reverting for now. But could you give me a way to
> > reproduce this error?
> >
> > I've not seen crashes on either linux and windows in various configs.
> >
> I suspect that Simon is building with SplitObjects enabled. To be
> honest, I would really like to remove this feature; SplitSections is
> better in nearly every regard. However, we have been stalled since
> SplitSections doesn't quite work yet on Windows (or, IIRC, the toolchain
> is prohibitively slow when it's used). I believe Tamar was working on
> fixing this.
>

SplitObjects has been off in favor of SplitSections on Windows since Aug.
https://github.com/ghc/ghc/commit/23774c98f1368b41515cbd5223b87ea6dbf644e1

SplitObjects is not usable on Windows anymore so it was disabled
https://ghc.haskell.org/trac/ghc/ticket/15051


> Cheers,
>
> - Ben
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: split_marker crash

2018-11-19 Thread Simon Peyton Jones via ghc-devs 
I do indeed have SplitObs=YES in my validate.mk.
In the past at least, that made binaries quite a bit smaller.
Happy to change it to SplitSections=YES if that is more kosher these days?

Simon

From: Andreas Klebinger 
Sent: 19 November 2018 20:38
To: Ben Gamari 
Cc: Phyx ; Simon Peyton Jones ; 
ghc-devs@haskell.org
Subject: Re: split_marker crash

I might already have found the specific cause.

It seems with split sections we generate a dummy CmmProc, which has as entry 
label
> error (split_sections_entry)

My patch likely introduces strictness on that field where it was lazy before.
If this is the cause I expect to have a patch up in a hour or two and will merge
it after it validates.

Cheers,
Andreas

Ben Gamari schrieb:


Andreas Klebinger  
writes:



Hello,



I'm fine with reverting for now. But could you give me a way to

reproduce this error?



I've not seen crashes on either linux and windows in various configs.



I suspect that Simon is building with SplitObjects enabled. To be

honest, I would really like to remove this feature; SplitSections is

better in nearly every regard. However, we have been stalled since

SplitSections doesn't quite work yet on Windows (or, IIRC, the toolchain

is prohibitively slow when it's used). I believe Tamar was working on

fixing this.



Cheers,



- Ben

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: split_marker crash

2018-11-19 Thread Ben Gamari 
Andreas Klebinger  writes:

> I might already have found the specific cause.
>
> It seems with split sections we generate a dummy CmmProc, which has as 
> entry label
>  > error (split_sections_entry)
>
> My patch likely introduces strictness on that field where it was lazy
> before. If this is the cause I expect to have a patch up in a hour or
> two and will merge it after it validates.
>
Ahhh, yes, that sounds like it may be the culprit. Good sleuthing!

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

Force-push

2018-11-19 Thread Simon Peyton Jones via ghc-devs 
Devs
When I rebase wip/T15809 (which has about 40 patches on it), and force-push, it 
generate a lot of Trac mail.  Sorry about this.  I don't know how I can make 
that not-happen.  You can safely delete it!
Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: split_marker crash

2018-11-19 Thread Andreas Klebinger 

I might already have found the specific cause.

It seems with split sections we generate a dummy CmmProc, which has as 
entry label

> error (split_sections_entry)

My patch likely introduces strictness on that field where it was lazy 
before.
If this is the cause I expect to have a patch up in a hour or two and 
will merge

it after it validates.

Cheers,
Andreas

Ben Gamari schrieb:

Andreas Klebinger  writes:


Hello,

I'm fine with reverting for now. But could you give me a way to
reproduce this error?

I've not seen crashes on either linux and windows in various configs.


I suspect that Simon is building with SplitObjects enabled. To be
honest, I would really like to remove this feature; SplitSections is
better in nearly every regard. However, we have been stalled since
SplitSections doesn't quite work yet on Windows (or, IIRC, the toolchain
is prohibitively slow when it's used). I believe Tamar was working on
fixing this.

Cheers,

- Ben


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: split_marker crash

2018-11-19 Thread Ben Gamari 
Andreas Klebinger  writes:

> Hello,
>
> I'm fine with reverting for now. But could you give me a way to
> reproduce this error?
>
> I've not seen crashes on either linux and windows in various configs.
>
I suspect that Simon is building with SplitObjects enabled. To be
honest, I would really like to remove this feature; SplitSections is
better in nearly every regard. However, we have been stalled since
SplitSections doesn't quite work yet on Windows (or, IIRC, the toolchain
is prohibitively slow when it's used). I believe Tamar was working on
fixing this.

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: split_marker crash

2018-11-19 Thread Andreas Klebinger 

Hello,

I'm fine with reverting for now. But could you give me a way to 
reproduce this error?


I've not seen crashes on either linux and windows in various configs.

Cheers,
Andreas

Ben Gamari schrieb:

Simon Peyton Jones via ghc-devs  writes:


OK I have verified that

   *   This split_marker crash happens on a clean HEAD build
   *   Reverting "NCG: New code layout algorithm.", 
575515b4909f3d77b3d31f2f6c22d14a92d8b8e0, solves the problem.
Andreas: I propose to revert in HEAD unless you have a rapid fix, or believe 
that is somehow my fault.
(Or maybe someone else can revert.)


Simon, are you using split-objs by any chance?

Regardless, yes, let's revert until we work out what is going on here.

Cheers,

- Ben


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: split_marker crash

2018-11-19 Thread Ben Gamari 
Simon Peyton Jones via ghc-devs  writes:

> OK I have verified that
>
>   *   This split_marker crash happens on a clean HEAD build
>   *   Reverting "NCG: New code layout algorithm.", 
> 575515b4909f3d77b3d31f2f6c22d14a92d8b8e0, solves the problem.
> Andreas: I propose to revert in HEAD unless you have a rapid fix, or believe 
> that is somehow my fault.
> (Or maybe someone else can revert.)

Simon, are you using split-objs by any chance?

Regardless, yes, let's revert until we work out what is going on here.

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: split_marker crash

2018-11-19 Thread Simon Peyton Jones via ghc-devs 
OK I have verified that

  *   This split_marker crash happens on a clean HEAD build
  *   Reverting "NCG: New code layout algorithm.", 
575515b4909f3d77b3d31f2f6c22d14a92d8b8e0, solves the problem.
Andreas: I propose to revert in HEAD unless you have a rapid fix, or believe 
that is somehow my fault.
(Or maybe someone else can revert.)
Simon

From: Simon Peyton Jones
Sent: 19 November 2018 14:53
To: 'ghc-devs@haskell.org' 
Subject: split_marker crash

Urrgh. I have this panic in a clean validate (sh validate -fast) on my branch 
wip/T15809.

ghc-stage1: panic! (the 'impossible' happened)

  (GHC version 8.7.20181119 for x86_64-unknown-linux):

   split_marker_entry



Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug



libraries/ghc-prim/ghc.mk:4: recipe for target 
'libraries/ghc-prim/dist-install/build/GHC/Types.o' failed
Yes, it's a branch not identical to HEAD, but I have done nothing concerning 
split_markers.
Sigh. What should I do?
Simon

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

split_marker crash

2018-11-19 Thread Simon Peyton Jones via ghc-devs 
Urrgh. I have this panic in a clean validate (sh validate -fast) on my branch 
wip/T15809.

ghc-stage1: panic! (the 'impossible' happened)

  (GHC version 8.7.20181119 for x86_64-unknown-linux):

   split_marker_entry



Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug



libraries/ghc-prim/ghc.mk:4: recipe for target 
'libraries/ghc-prim/dist-install/build/GHC/Types.o' failed
Yes, it's a branch not identical to HEAD, but I have done nothing concerning 
split_markers.
Sigh. What should I do?
Simon

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs