#I'm surprised that code gen is the

1 messages · Page 1 of 1 (latest)

worn spindle
#

We see the failure with 5.3.2 and gcc 13.2.0. I isolated it to the small change documented in #10298. Comparing the generated code between the failure case with the assignment and the non-failing case without the assignment, there was a very large difference in the stack frame layout. This led me to conclude that I was looking at a code gen error. Moving the line causing the failure worked around the problem. That moving the line made no change to the semantics of the source code again demonstrated that it was a code gen problem.

With 5.4.1 the compiler changes to gcc 14.2.0. With the workaround in place, the failure returned. Entirely reverting to the code before the workaround, it fails. Removing the protection change you had made that initially triggered the failure also fails.

#

I don't point the finger at gcc lightly.

azure bronze
#

it's probably due to the nlr_push

#

since it does the double return craziness

#

I wonder why newer gcc makes it worse

worn spindle
#

That's something Dan and I explored. For a test, I integrated the upstream Micropython changes to nlr that replace the generic C code with a Risc-V assembly implementation. It made no difference.