https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117229
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Thomas Schwinge from comment #2)
> OK, that's going to be "fun":
> During "manual bisecting", I found that I can, for example, also make it
> PASS this way:
The h array is
const unsigned char h[] = {
#embed __FILE__ suffix (, 0)
};
and so includes the whole source of the testcase, so any changes in the source
change
the content of the array (and sometimes the length too).
That said, if strstr is properly implemented in the library and if the h array
is properly initialized, then I don't see how any such changes could affect
the non-NULL result from those calls, those 2 substrings must be trivially
found in
the source at least (in the second case only at) the place where those calls
are done.
So, to debug this, if you can run the testcase under debugger, see if h array
content looks sane and if it has those two substrings.
Or if it helps, cp embed-1.c embed-100.c and replace
#embed __FILE__ suffix (, 0)
in embed-1.c with
#embed "embed-100.c" suffix (, 0)
That way, you can change the testcase without changing the content of the h
array.
> --- gcc/testsuite/c-c++-common/cpp/embed-1.c
> +++ gcc/testsuite/c-c++-common/cpp/embed-1.c
> @@ -258,9 +258,11 @@ main ()
> abort ();
> if (g.a != 'H' || g.b != 'e' || g.c != 'n' || g.d != 'r')
> abort ();
> +#if 1
> if (!strstr ((const char *) h, "imprisonétur")
> || !strstr ((const char *) h, "blah blah"))
> abort ();
> +#endif
> if (v.a != 42 || v.b.a != 'H' || v.b.b.a != 'e'
> || v.b.c != 'n' || v.c != 'r' || v.d != -42)
> abort ();
