This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: non-volatile automatic variables in setjmp tests


On Mon, 8 Apr 2019 14:45:17 +0200
Richard Biener <richard.guenther@gmail.com> wrote:

> On Mon, Apr 8, 2019 at 2:31 PM Michael Matz <matz@suse.de> 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 genuine bug in the
> > middle-end observed only on msp430; but we do want to make this situation
> > work generally, as required by ISO C, not like how it's spelled in our
> > manual.  
> 
> Yes, and there's at least one existing bug, PR57067 for which it was
> observed the scheduler genrates wrong-code.
> 
> Richard.
> 
> >
> > Ciao,
> > Michael.  

Thank you both for the information.

I'm still digging to find the cause of the failure, but I think it's a bug in
reload rather than an earlier pass having issues with setjmp/longjmp. The RTL
up to reload looks good to me. Also when I managed to coerce a build of GCC to
complete with LRA enabled for msp430, the test passed.

It was r255136 that exposed the failure by replacing usage of a variable with
a constant. Taking that optimization into account I'm now trying to find
which earlier commit exposed/caused the failure, as the test works with
r247017 when GCC8 development started on trunk. But that might just be because
the RTL when we get to reload is different, and doesn't expose the bug.

I'll file a bugzilla once I have more concrete details.

Jozef


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]