Re: grep-3.8.11-908f on AIX 7.2

[Jeffrey Walton]

On Mon, Jan 2, 2023 at 9:38 AM Bruno Haible <bruno@clisp.org> wrote:
>
> On AIX 7.2, with xlc as compiler, all tests pass.
>
> BUT: On AIX 7.2, with xlclang as compiler, I'm seeing two test failures:
>
> FAIL: empty-line
> FAIL: skip-read
>
> Find the logs attached.
>
> Let me concentrate on the 'skip-read' test:
>
> 1) Line 12 'for file in /dev/null no-such-file; do' is merely a repetition,
> since $file is never used. The test could be simplified by eliminating the
> lines 12 and 17, I guess.
>
> 2) The 4 invocations that crash are:
>
> $ src/grep -L -f /dev/null /dev/null > out
> Trace/BPT trap (core dumped)
> $ src/grep -L -f /dev/null -E /dev/null > out
> Trace/BPT trap (core dumped)
> $ src/grep -L -v "" /dev/null > out
> Trace/BPT trap (core dumped)
> $ src/grep -L -v "" -E /dev/null > out
> Trace/BPT trap (core dumped)
>
> The stack traces are, respectively:
>
> (gdb) where
> #0  dfamust (d=0x100011798 <dfaparse+280>) at ../../lib/dfa.c:4220
> #1  0x0000000100010b4c in IPRA.$kwsmusts (dc=0x1000021a8 
> <get_nondigit_option+136>) at ../../src/dfasearch.c:69
> #2  0x00000001000104c8 in GEAcompile (pattern=0x9001000a0c01950 
> <_ccq9xhiE.rw_+160> "", size=<unknown type>, syntax_bits=<unknown type>, 
> exact=150999040) at ../../src/dfasearch.c:330
> #3  0x0000000100001094 in main (argc=0, argv=0x0) at ../../src/grep.c:2975
>
> (gdb) where
> #0  dfamust (d=0x100011798 <dfaparse+280>) at ../../lib/dfa.c:4220
> #1  0x0000000100010b4c in IPRA.$kwsmusts (dc=0x1000021a8 
> <get_nondigit_option+136>) at ../../src/dfasearch.c:69
> #2  0x00000001000104c8 in GEAcompile (pattern=0x9001000a0c01950 
> <_ccq9xhiE.rw_+160> "", size=<unknown type>, syntax_bits=<unknown type>, 
> exact=150999040) at ../../src/dfasearch.c:330
> #3  0x0000000100001094 in main (argc=0, argv=0x0) at ../../src/grep.c:2975
>
> (gdb) where
> #0  dfamust (d=0x100011798 <dfaparse+280>) at ../../lib/dfa.c:4220
> #1  0x0000000100010b4c in IPRA.$kwsmusts (dc=0x10004aae0 <fwrite+864>) at 
> ../../src/dfasearch.c:69
> #2  0x00000001000104c8 in GEAcompile (pattern=0x9001000a0c01950 
> <_ccq9xhiE.rw_+160> "", size=<unknown type>, syntax_bits=<unknown type>, 
> exact=150999040) at ../../src/dfasearch.c:330
> #3  0x0000000100001094 in main (argc=0, argv=0x0) at ../../src/grep.c:2975
>
> (gdb) where
> #0  dfamust (d=0x100011798 <dfaparse+280>) at ../../lib/dfa.c:4220
> #1  0x0000000100010b4c in IPRA.$kwsmusts (dc=0x10004aae0 <fwrite+864>) at 
> ../../src/dfasearch.c:69
> #2  0x00000001000104c8 in GEAcompile (pattern=0x9001000a0c01950 
> <_ccq9xhiE.rw_+160> "", size=<unknown type>, syntax_bits=<unknown type>, 
> exact=150999040) at ../../src/dfasearch.c:330
> #3  0x0000000100001094 in main (argc=0, argv=0x0) at ../../src/grep.c:2975
>
> 3) Paul's fix from yesterday
>   
> <https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=8805a44cf04253f63bce160054e2fbf21ab9beb1>
> does not fix the test failures.
>
> 4) Commenting out the _Noreturn marker before dfaerror does not fix the test
> failures either.
>
> 5) But recompiling dfa.c with no optimizations (removing -O2 from CFLAGS)
> fixes the test failures.
>
> In summary, it looks like an xlclang compiler bug to me, that occurs when
> compiling dfa.c, but I can't say where exactly.

Regarding (5), two other options you might try to tease out what Clang
is thinking... First, try -fsanitize=undefined to see if Clang is
removing code because it believes the UB.

Second, try -fsanitize=unreachable to see if Paul's problem is a trend
and not a one-off. We recently got bit with this using GCC. I had to
use -fno-devirtualize to work around the compiler removing live code
in a C++ project.

Jeff