[PATCH] D56624: [Sanitizers] UBSan unreachable incompatible with ASan in the presence of `noreturn` calls

[Julian Lettner via Phabricator via cfe-commits]

yln added a comment.

@lebedev.ri
Thanks for the clarifications!
I will split this up into multiple patches once we settled on a design.

In D56624#1369635 <https://reviews.llvm.org/D56624#1369635>, @vsk wrote:

> What are the advantages of a generalized expect_noreturn attribute, vs. a narrower attribute or intrinsic? The expect_noreturn semantics do not provide strong guarantees, and are not really orthogonal from the pre-existing cold attribute.


@eugenis Do you want to chime in here?
I think they convey different meanings even if their treatment by the optimizer is similar. The `cold` attribute says nothing about whether or not a function is expected to return.

> In particular, expect_noreturn doesn't even seem strong enough to allow ASan to unpoison its stack.

I am not sure I understand this part. Can you elaborate?

For context:

  ``cold``
    This attribute indicates that this function is rarely called. When
    computing edge weights, basic blocks post-dominated by a cold
    function call are also considered to be cold; and, thus, given low
    weight.
  ``noreturn``
    This function attribute indicates that the function never returns
    normally. This produces undefined behavior at runtime if the
    function ever does dynamically return.
  ``expect_noreturn``
    This function attribute indicates that the function is unlikely to return
    normally, but that it is still allowed to do so. This is useful in cases
    for which ``noreturn`` is too strong a guarantee.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56624/new/

https://reviews.llvm.org/D56624