[cfe-dev] Reaching the end of a value-returning function in C++

[Argyrios Kyrtzidis]

On Oct 14, 2012, at 5:26 PM, Richard Smith <richard at metafoo.co.uk> wrote:

> On Sun, Oct 14, 2012 at 4:07 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> On Fri, Oct 12, 2012 at 7:07 PM, Argyrios Kyrtzidis <kyrtzidis at apple.com> wrote:
> On Oct 4, 2012, at 4:56 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> 
> > As of r165273, clang produces 'unreachable' if we flow off the end of a value-returning function (without returning a value) in C++. This is undefined behavior, but we used to just return undef, instead of trying to exploit it. Please let me know if this causes problems for you, and we can weaken it to an acceptable level.
> 
> FYI, this caused some libc++ tests to crash (or not terminate). To highlight one example, there was this method:
> 
> > template <class _CharT, class _Traits>
> > inline _LIBCPP_INLINE_VISIBILITY
> > basic_filebuf<_CharT, _Traits>&
> > basic_filebuf<_CharT, _Traits>::operator=(basic_filebuf&& __rhs)
> > {
> >     close();
> >     swap(__rhs);
> > }
> 
> Notice the absence of a "return *this".
> 
> At the test (test/input.output/file.streams/fstreams/filebuf.assign/move_assign.pass.cpp) the method was used like this:
> 
>  std::filebuf f2;
>  f2 = move(f);
> 
> Notice that the returned value from 'operator=' is ignored.
> 
> There was a crash with a stack trace showing bad access inside "libunwind.dylib`_Unwind_Resume"; the stack trace didn't provide much hint at what the culprit is.
> 
> I don't think producing 'unreachable' always by default is a good idea; this is too aggressive to do at the frontend level and it makes debugging (on a "-O0 -g" build) a nightmare.
> 
> Yeah, we were worried that this might be a problem for people who don't use -Wreturn-type. How would you feel about inserting a call to llvm.trap before the unreachable if we're building without optimizations? 
> 
> I've implemented this in r165914. We can tune this further if there are still debugability problems.

Stepping back a bit, could you elaborate on the real benefit of the initial change and with what kind of source code you saw it ?

Unless I'm missing something, this will benefit functions that are not checked with -Wreturn-type and are supposed to be unreachable in some path but are not marked as such.
I'd prefer that these functions are actually marked as 'unreachable' in source code, instead of depending on the compiler implicitly assuming that in order to get such an optimization.
If you operate on source code with such a policy, the usefulness of the initial change becomes questionable.

> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121015/bdff8636/attachment.html>