On Mon, 8 Apr 2019 14:00:39 +0100
Jozef Lawrynowicz wrote:
> I'll file a bugzilla once I have more concrete details.
>
> Jozef
I filed BZ90032 for what I believe to be a bug during the reload pass.
Jozef
On Mon, 8 Apr 2019 14:45:17 +0200
Richard Biener wrote:
> On Mon, Apr 8, 2019 at 2:31 PM Michael Matz wrote:
> >
> > Hi,
> >
> > On Mon, 8 Apr 2019, Richard Biener wrote:
> >
> > > Not sure if in this case we run into an RTL optimization that breaks
> > > things
> > > (PRE / scheduling / inva
On Mon, Apr 8, 2019 at 2:31 PM Michael Matz wrote:
>
> Hi,
>
> On Mon, 8 Apr 2019, Richard Biener wrote:
>
> > Not sure if in this case we run into an RTL optimization that breaks things
> > (PRE / scheduling / invariant motion are candidates).
>
> That's true, what Josef sees might point to a gen
Hi,
On Mon, 8 Apr 2019, Richard Biener wrote:
> Not sure if in this case we run into an RTL optimization that breaks things
> (PRE / scheduling / invariant motion are candidates).
That's true, what Josef sees might point to a genuine bug in the
middle-end observed only on msp430; but we do want
On Fri, Apr 5, 2019 at 6:25 PM Michael Matz wrote:
>
> Hello,
>
> On Fri, 5 Apr 2019, Jozef Lawrynowicz wrote:
>
> > Some setjmp/longjmp tests[1] depend on the value of an auto set before
> > setjmp
> > to to be retained after returning from the longjmp. As I understand, this
> > behaviour is act
Hello,
On Fri, 5 Apr 2019, Jozef Lawrynowicz wrote:
> Some setjmp/longjmp tests[1] depend on the value of an auto set before setjmp
> to to be retained after returning from the longjmp. As I understand, this
> behaviour is actually undefined, according to the gccint manual.
>
> Section 3 "Interf
Some setjmp/longjmp tests[1] depend on the value of an auto set before setjmp
to to be retained after returning from the longjmp. As I understand, this
behaviour is actually undefined, according to the gccint manual.
Section 3 "Interfacing to GCC Output" of gccint says:
If you use longjmp, bewar
