Strange dimension errors in a custom matrix class

I'm working with the package PSOPT ( http://www.psopt.org/ ), I haven't found much evidence in its user group of anyone compiling its custom matrix class using Clang - which is a little bit surprising considering OS X Mavericks. I was able to put together a Homebrew formula to get the package to compile using Apple clang on OS X 10.9 with all of its prerequisites, but 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

For some reason building with clang (from package clang-3.3 on Ubuntu 13.10, or with Xcode CLT in OS X 10.9), the DMatrix colon() operator results in different dimensions at an intermediate iteration of the for loop at line 67 of dmtest.cxx. All dimensions are expected to remain constant, but according to lldb/gdb they are not. Is there a bug in one of the DMatrix class operators that's resulting in incorrect or undefined behavior that just gets lucky with g++, or what? I'm stumped at this point. I hope this is the right place to ask this kind of question (aside from the user group and developers of the PSOPT package, where I made a post earlier today https://groups.google.com/forum/#!topic/psopt-users-group/Psxeb1nVg_4 ), if there's anything else I can provide please let me know.

Regards,
Tony

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 & fn1 ()
{
}

{
}

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? 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?

Thanks,
Tony

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.

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.

Thank you very much for the insight. Interestingly this extremely-reduced
case succeeds on OS X with Apple clang-500.2.79. Since I didn’t get the
"control reaches end of non-void function" warning in the real program,
I suspect this is a case of over-aggressive reduction by creduce. Next
time I'll tell creduce not to accept code that the compiler warns about.

Thanks to Tomasz Miąsko I was able to solve the original problem. The
DMatrix::operator& was taking argument by value and creating unsafe
temporaries. Replacing uses of that operator with the by-reference
elemProduct avoided the dimension errors I was getting.

-Tony