[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc

["tg at mirbsd dot org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111165

--- Comment #18 from Thorsten Glaser <tg at mirbsd dot org> ---
I cannot, unfortunately. But I have found _another_ “mitigation”:

varsub() is static and has only one caller:
https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=alioth/mksh.git;a=blob;f=eval.c;h=cb959b1d1104229ead20a698ff2dc974b8da3b10;hb=35563a7897b98de2743233c5f3340a14bea6ebf2#l400

By making varsub…
https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=alioth/mksh.git;a=blob;f=eval.c;h=cb959b1d1104229ead20a698ff2dc974b8da3b10;hb=35563a7897b98de2743233c5f3340a14bea6ebf2#l1238
… not static, the bug *also* goes away. (Probably because varsub is not
inlined.)

Now we see that…
 399                                 sp = cstrchr(sp, '\0') + 1;
 400                                 type = varsub(&x, varname, sp, &stype,
&slen);
… the varsub call is *directly* below the strchr/strlen line, *and* it gets
passed the sp variable. (Inside varsub, the variable is also modified.)

My suspicion here is that, somehow only triggerable on x32+dietlibc, something
about the multiple modifications of sp (just before and within varsub) confuses
GCC?

And indeed. Adding -O2, -O1, -O0 to the GCC command line doesn’t help, but
-fno-inline again does.

As does adding an attribute to the function prototype:
static int varsub(Expand *, const char *, const char *, unsigned int *, int *)
__attribute__((noinline));

Could we somehow debug there further? I really don’t see a way to reproduce
this on x32/glibc or amd64…