> On 3 Jan 2023, at 02:14, Sam James wrote: > > > >> On 2 Jan 2023, at 06:10, Paul Eggert wrote: >> >> This is a serious bug in Clang: it generates incorrect machine code. >> >> [snip] >> >> My guess is that Clang got confused because dfaerror is declared _Noreturn, so Clang mistakenly assumed that dfawarn is also _Noreturn, which it is not. >> >> I worked around the Clang bug by installed the attached patch into Gnulib. Please give it a try with Gawk. > > Confirmed this mitigates the problem. I had to apply it manually to support/ as I couldn't immediately see how to sync gnulib myself, but that's no big deal. > >> >> Incorrect code generation is a serious bug in Clang; can you please report it to the Clang folks? I am considering using a bigger hammer, and doing this: >> > > Kenton's done this at https://github.com/llvm/llvm-project/issues/59792 now. > >> #define _Noreturn /*empty*/ >> >> whenever Clang is used, until the bug is fixed. >> > > maskray's analysis so far at https://github.com/llvm/llvm-project/issues/59792#issuecomment-1369314436 agrees with yours, which would mean > this is likely a good idea. > By the way, when I ran gnulib's test suite following https://sourceware.org/glibc/wiki/Testing/Gnulib, I didn't get any failures with Clang. I was expecting to get one (before your commit) for DFA. Maybe we should shoehorn a similar ternary expression into tests/test-dfa-match-aux.c so we're guaranteed a test failure with bad compilers if someone uses the DFA module?