Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

[Jeff Law <law at redhat dot com>]

On 12/17/2016 02:55 PM, Martin Sebor wrote:
> On 12/17/2016 01:01 PM, Markus Trippelsdorf wrote:
>
> I agree that these warnings should probably not be issued, though
> it's interesting to see where they come from.  The calls are in
> the code emitted by GCC, are reachable, and end up taking place
> with the right Ubsan runtime recovery options.  It turns out that
> Ubsan transforms calls to nonnull functions into conditional
> branches testing the argument for null, like so:
>
>     if (s == 0)
>       __builtin___ubsan_handle_nonnull_arg();
>     n = strlen (s);
>
> and GCC then transforms those into
>
>     if (s == 0)
>       {
>         __builtin___ubsan_handle_nonnull_arg();
>         n = strlen (NULL);
>       }
>
> When the ubsan_handle_nonnull_arg function returns to the caller
> the call to strlen(NULL) is made.
So I'd like to see more complete dumps here.

> This doesn't happen when -fno-sanitize-recover=undefined is used
> when compiling the file because then Ubsan inserts calls to
> __builtin___ubsan_handle_nonnull_arg_abort instead which is declared
> noreturn.
Right.  That's what I would expect.  If we're going to halt the process 
at first UB, then we want to abort.  Obviously in that case we're 
calling a noreturn function and the strlen never executes.

Otherwise the strlen still needs to be called and whateve action strlen 
has when passed a NULL must be preserved.

So the only question in my mind is what was the larger context so that 
we can look at why we isolated the paths (which brings the strlen into 
the conditional rather than leaving it at the merge point).

jeff