On Mon, 8 Apr 2019 14:45:17 +0200 Richard Biener <richard.guent...@gmail.com> wrote:
> On Mon, Apr 8, 2019 at 2:31 PM Michael Matz <m...@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
