Feature Request: __builtin_undefined()

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Feature Request: __builtin_undefined()

Eric Fiselier via cfe-dev
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<T>::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.
--
Ryan Nicholl
(678)-358-7765

Sent with ProtonMail Secure Email.


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Feature Request: __builtin_undefined()

Eric Fiselier via cfe-dev
On Sat, Oct 07, 2017 at 01:10:44PM -0400, Ryan Nicholl via cfe-dev wrote:
> 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.)

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

Joerg
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Feature Request: __builtin_undefined()

Eric Fiselier via cfe-dev
In reply to this post by Eric Fiselier via cfe-dev
On 7 October 2017 at 10:10, Ryan Nicholl via cfe-dev
<[hidden email]> wrote:
> 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 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.

Cheers.

Tim.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev