Feature Request: __builtin_undefined()

I would like to request a feature, __builtin_undefined()

This would serve multiple purposes, it would be similar to __builtin_unreachable, but can be used to specify that the behavior upon reaching it it undefined (not necessarily that it can’t be reached.)

For example, in pseudo code “T my_array::operator[](size_t n) { if (n >= this->internal_size) __builtin_undefined(); … }”

So this would indicate that a user has invoked undefined behavior, and -fsanitize=undefined would trap this behavior, and additionally, when debugging is disabled, the compiler could use __builtin_undefined() as an optimization hint.

I like to distinguish my proposed __builtin_undefined() from __builtin_unreachable() in that __builtin_unreachable() should really be unreachable. (Even if the user e.g. uses an invalid input index?) (i.e., it should indicate a bug in the code that uses __builtin_unreachable() rather than in the calling code)

I recognize that the distinction is probably not substantial, but being able to explicitly specify certain behavior as undefined might prove useful when developing libraries as compilers develop more advanced optimizations.

Why can't you use __builtin_trap() for this purpose?


I don't think I see the distinction at all, I'm afraid:

  + UBSan already instruments calls to __builtin_unreachable.
  + Reaching it already counts as UB as far as LLVM is concerned.
  + Optimizations already exploit it.
  + The caller/callee mistake distinction doesn't really exist once
inlining happens.

Do you have any concrete examples where some part of LLVM
could/would/should treat them differently? Would something permitted
of forbidden by this new intrinsic? I can't even really tell which way
it'd go.