> On 3 Jan 2023, at 02:14, Sam James <s...@gentoo.org> wrote: > > > >> On 2 Jan 2023, at 06:10, Paul Eggert <egg...@cs.ucla.edu> 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?
signature.asc
Description: Message signed with OpenPGP
