https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98771
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot
Uni-Bielefeld.DE> ---
> --- Comment #2 from Martin Sebor <msebor at gcc dot gnu.org> ---
> I can't reproduce these failures with my solaris2.11 cross. The dump and the
Please note that the failure only occurs for i386-pc-solaris2.11 and
sparc-sun-solaris2.11 compilers with -m64.
> warnings indicate that it's only the strncmp calls with a bound of SIZE_MAX
> that aren't folded in your environment, like this one:
>
> void f (void)
> {
> if (!(0 > __builtin_strncmp ("123", "12345", __SIZE_MAX__)))
> __builtin_abort (); // should be eliminated
> }
I've used that testcase for my further attempts.
> All other calls, including those with SIZE_MAX - 1, are folded successfully.
> The folding happens in fold_const_call() in fold-const-call.c:
[...]
> I wonder if the host_size_t_cst_p() test passes for you. If the native GCC's
It doesn't: the function always returns false. Further debugging is
impossible right now, though: all attempts to access the args are
greeted with
dwarf2_find_location_expression: Corrupted DWARF expression.
by gdb 10.1. Yet another boon of the DWARF-5 switch, I guess ;-(
> size_t is a 32-bit type then that might explain why it would fail, but then
> I'm
Of course it is (unsigned int), just as on i686-pc-linux-gnu. What else
would it be in a 32-bit environment?
> not sure what lets the calls with SIZE_MAX - 1 be folded.
Indeed, and beyond that it's strange that the failure doesn't occur on
other multilibbed 32-bit targets (e.g. on i686-pc-linux-gnu with -m64).
