On 6/20/22 07:05, Jakub Jelinek wrote:
> On Fri, Jun 17, 2022 at 05:20:02PM -0400, Jason Merrill wrote:
>> Related to PR104642, the current situation where we get less return checking
>> with just -fsanitize=unreachable than no sanitize flags seems undesirable; I
>> propose that we do return checking when -fsanitize=unreachable.
> 
> __builtin_unreachable itself (unless turned into trap or
> __ubsan_handle_builtin_unreachable) is not any kind of return checking, it
> is just an optimization.

Yes, but I'm talking about "when -fsanitize=unreachable".

>> Looks like clang just traps on missing return if not -fsanitize=return, but
>> the approach in this patch seems more helpful to me if we're already
>> sanitizing other should-be-unreachable code.
>>
>> I'm assuming that the difference in treatment of SANITIZE_UNREACHABLE and
>> SANITIZE_RETURN with regard to loop optimization is deliberate.
> 
> return and unreachable are separate sanitizers and such silent one way
> implication can have quite unexpected consequences, especially with
> -fsanitize-trap=.
> Say with -fsanitize=unreachable -fsanitize-trap=unreachable, both current
> trunk and clang will link without -lubsan, because the only enabled UBSan
> sanitizers use __builtin_trap () which doesn't need library.
> With -fsanitize=unreachable silently meaning -fsanitize=unreachable,return
> the above would link in -lubsan, because while SANITIZE_UNREACHABLE uses
> __builtin_trap, SANITIZE_RETURN doesn't.
> Similarly, one has no_sanitize attribute, one could in certain function
> __attribute__((no_sanitize ("unreachable"))) and because on the command
> line using -fsanitize=unreachable assume other sanitizers aren't enabled,
> but the silent addition of return sanitizer would break that.

Ah, true.  How about this approach instead?