4 ms·

This is a corner of C I'm not familiar with, but does the standard say anything about functions that never return? If it doesn't say that implementations may as

This is a corner of C I'm not familiar with, but does the standard say anything about functions that never return? If it doesn't say that implementations may assume functions return then that sounds more like a compiler bug than taking advantage of UB.

oconnor663 7y ago
This seems contrary to how (I believe) the compiler works with atomics. If I call some opaque function foo(), the compiler has to assume that foo() could perform sequentially consistent atomic operations, and it cannot move other reads or writes across that function call. Why isn't it also required to assume that a function could terminate the program or longjump out?
- aw1621107 7y ago
  Yeah, I think you're right. I guess a more general statement would be that the example optimization may not be valid because that function may contain unknown side effects, including program termination.
madmax96 7y ago
Previously, I saw discussion around a similar bug where the community accepted that it is not legal for compilers to optimize with the assumption that a function never returns [1]. Obviously, if a compiler can prove a function always returns, it is a perfectly reasonable optimization. Unfortunately, one of the folks who filed a bug report against GCC submitted an obviously incorrect reproduction procedure [2]. The GCC folks closed the false bug report and the developers worked around the true bug. Some time later, a developer attempted to reproduce the bug with GCC 4.4 and succeeded, but could not reproduce it with versions 4.6 or 4.8 [3]. In my mind, this fact strongly supports the community's conclusion that the optimization is incorrect. Finally, the intuition described in the stack overflow discussion is pretty sound: it must be possible to use control flow to avoid undefined behavior. [1]https://stackoverflow.com/questions/20059532/are-all-functions-in-c-c-assumed-to-return/ https://stackoverflow.com/questions/20059532/are-all-functio... [2]https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29968 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29968 [3]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616180 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616180
- aw1621107 7y ago
  Interesting, thanks for the links!
shakna 7y ago
> This is a corner of C I'm not familiar with, but does the standard say anything about functions that never return? A few things, but not a lot of detail. > A function declared with a_Noreturn function specifier shall not return to its caller 6.7.4-8 It is recommended, but not enforced, that the implementation warns if this might not be the case. > The implementation should produce a diagnostic message for a function declared with a_Noreturn function specifier that appears to be capable of returning to its caller 6.7.4-9 They do provide some example code that explicitly says that non-returning functions, that are marked as such, need to be explicit that they don't return. (As C implicitly attempts to return if given the opportunity). Not doing so is Undefined Behaviour. _Noreturn void f () { abort(); //ok } _Noreturn void g (int i) { //causes undefined behavior if i<=0 if (i > 0) abort(); } So a compiler should be able to assume that a _Noreturn function either loops forever or terminates. Anything else would appear to be UB. The compiler can't assume that a function always returns.

oconnor663 7y ago

This seems contrary to how (I believe) the compiler works with atomics. If I call some opaque function foo(), the compiler has to assume that foo() could perform sequentially consistent atomic operations, and it cannot move other reads or writes across that function call. Why isn't it also required to assume that a function could terminate the program or longjump out?

aw1621107 7y ago
Yeah, I think you're right. I guess a more general statement would be that the example optimization may not be valid because that function may contain unknown side effects, including program termination.

madmax96 7y ago

Previously, I saw discussion around a similar bug where the community accepted that it is not legal for compilers to optimize with the assumption that a function never returns [1]. Obviously, if a compiler can prove a function always returns, it is a perfectly reasonable optimization. Unfortunately, one of the folks who filed a bug report against GCC submitted an obviously incorrect reproduction procedure [2]. The GCC folks closed the false bug report and the developers worked around the true bug. Some time later, a developer attempted to reproduce the bug with GCC 4.4 and succeeded, but could not reproduce it with versions 4.6 or 4.8 [3]. In my mind, this fact strongly supports the community's conclusion that the optimization is incorrect. Finally, the intuition described in the stack overflow discussion is pretty sound: it must be possible to use control flow to avoid undefined behavior. [1]https://stackoverflow.com/questions/20059532/are-all-functions-in-c-c-assumed-to-return/ https://stackoverflow.com/questions/20059532/are-all-functio... [2]https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29968 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29968 [3]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616180 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616180

aw1621107 7y ago
Interesting, thanks for the links!

shakna 7y ago

> This is a corner of C I'm not familiar with, but does the standard say anything about functions that never return? A few things, but not a lot of detail. > A function declared with a_Noreturn function specifier shall not return to its caller 6.7.4-8 It is recommended, but not enforced, that the implementation warns if this might not be the case. > The implementation should produce a diagnostic message for a function declared with a_Noreturn function specifier that appears to be capable of returning to its caller 6.7.4-9 They do provide some example code that explicitly says that non-returning functions, that are marked as such, need to be explicit that they don't return. (As C implicitly attempts to return if given the opportunity). Not doing so is Undefined Behaviour. _Noreturn void f () { abort(); //ok } _Noreturn void g (int i) { //causes undefined behavior if i<=0 if (i > 0) abort(); } So a compiler should be able to assume that a _Noreturn function either loops forever or terminates. Anything else would appear to be UB. The compiler can't assume that a function always returns.