[cfe-dev] Strange dimension errors in a custom matrix class

David Blaikie dblaikie at gmail.com
Sun Feb 9 00:59:03 PST 2014


On Sun, Feb 9, 2014 at 12:33 AM, Tony Kelman <kelman at berkeley.edu> wrote:

> I'm seeing some strange runtime errors that don't occur when the same code
>> is built with g++. I've tried to cut down the class in question and reduce
>> the error to a small test case, and posted the result at
>> https://gist.github.com/8875125
>>
>
> Following up here. I've found and figured out how to use the absolutely
> amazing tool C-Reduce (http://embed.cs.utah.edu/creduce/) which I imagine
> this list is familiar with. The result is the following:
>
>
>
> class A
> {
> public:
>    A (const A &);
>    ~A ();
> };
>
> A::A (const A &)
> {
> }
>
> A & fn1 ()
> {
> }
>
> A::~A ()
> {
> }
>
> A a = fn1 ();
> int
> main ()
> {
> }
>
>
>
> $ g++ -g -o dmtest-g++ dmtest.cxx && ./dmtest-g++
> succeeds silently, while
> $ clang++ -g -o dmtest-clang dmtest.cxx && ./dmtest-clang
> gives a warning "control reaches end of non-void function" during
> compilation, and a runtime error "Illegal instruction (core dumped)". This
> comparison was on Ubuntu 13.10 as it was the easiest platform for me to get
> C-Reduce running on.
>
> Is this difference in behavior between the two compilers expected and/or
> intended, or is this a bug in Clang?


This behavior is intended. Your program exhibits undefined behavior
(control falls off the end of a non-void returning function rather than
exiting via a return statement with an appropriate object).

Clang provides no guarantees for this code above -O0 (no code is emitted,
execution may fall into the following function, etc - nasal demons, etc),
but does generously provide an illegal instruction at -O0 so you can find
this bug a bit more easily. The warning is also there to help.

In short: make sure you return things from your non-void returning
functions. Don't let them fall off the end.


> If the former, does anyone have any suggestions for how to translate this
> back into a workaround for the purposes of the real code that originally
> ran into this difference?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140209/cf65933c/attachment.html>


More information about the cfe-dev mailing list