https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872
--- Comment #24 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Sergei Trofimovich from comment #23) [...] > Why did `gcc` generate unconditional NULL dereference here? I suspect it > somehow inferred that `__pyx_t_6 = NULL;` in that branch, but not before > comparison. That's what happens if we isolate an unreachable path because of a NULL dereference (like if exposed by jump-threading). We make the NULL dereference volatile so it stays but DCE/DSE can cleanup code on the path leading to it. If you run into such path the this might suggest that jump-threading triggered a problem with the setjmp/longjmp, so it's then likely some condition that's evaluated in a wrong way after the longjmp, either because a dependent value wasn't properly preserved or by GCC breaking that. Seeing stack memory arguments used on a call in a previous comment I wondered if POSIX suggests that even non-register variables need to be made volatile and thus whether SRA or FRE might impose problems with code using setjmp/longjmp.
