On Thu, 22 Nov 2018 at 10:21, Ben Gamari wrote:
> Steven Shaw writes:
>
> > Curious if the GHC libraries _are_ still built with the `-split-objs`
> flag,
> > as pointed out in the latest documentation.
> >
> Good catch; the build system uses split sections by default if
> supported. If not it in
Steven Shaw writes:
> Curious if the GHC libraries _are_ still built with the `-split-objs` flag,
> as pointed out in the latest documentation.
>
Good catch; the build system uses split sections by default if
supported. If not it instead uses split objects, if supported. I do not
believe there ar
Curious if the GHC libraries _are_ still built with the `-split-objs` flag,
as pointed out in the latest documentation.
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/phases.html?highlight=split-objs#ghc-flag--split-objs
___
ghc-devs mai
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.
>>
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 bina
>
>
>
> *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
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
;
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.
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
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
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
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
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
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 fau
14 matches
Mail list logo
