Re: [eigen] Eigen code gets optimized away by avr-g++ - what to do?

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

Since your warning fix mentions integer overflow, while we're on the
topic of integer overflow, I recently learned that the standard allows
the compiler to do ANYTHING on signed integer overflow --- including,
removing code. Indeed, this is undefined behavior, and some compilers
are stupid enough to take the spec literally on this and actually
break code.

So to debug this, I would use this tool,
  http://embed.cs.utah.edu/ioc/
to discover any integer overflow in Eigen code, and fix them, and see
if that fixes your issue.

We should probably run that tool on all the Eigen unit tests, too.

Benoit



2012/6/29 Ryan Pavlik <rpavlik@xxxxxxxxxxx>:
> All,
>
> Hoping for a little help with an interesting issue. As I need to do some
> small matrix/vector math on the Arduino, and in the interest of using a
> well-tested, efficient library I'm already using elsewhere, I've "ported"
> Eigen to the Arduino/AVR.  I've uploaded my example repo/testcase
> here: https://github.com/rpavlik/eigen-avr-testcase
>
> Really, there was not much to the port - one warning fix
> here https://github.com/rpavlik/eigen-avr-testcase/commit/864bb30ecac75044264b0c7b4c250a36268851a8 because
> ptrdiff_t is 16-bits, improvements to the AVR/Arduino uClibc++ port
> here https://github.com/rpavlik/StandardCplusplus, and one "dummy" header
> file to cope with the Arduino IDE's way of implicitly indicating you want to
> use a library, as well as to work around a few small compile
> issues https://github.com/rpavlik/eigen-avr-testcase/blob/master/libraries/Eigen30/Eigen30.h ;.
>
> However, I am now seeing quite strange behavior. It looks like Eigen code
> (and possibly the rest of the function in which it is used?) gets optimized
> out of the compiled binary.  (It's so efficient, it doesn't have any code!
> :D )  When built by the IDE, it uses -Os optimization (which is -O2 without
> the ones deemed to potentially enlarge the code) which triggers the issue..
> -O1 optimization doesn't seem to trigger it (by looking at the disassembly,
> I actually see a call to sqrtf when my test program calls .norm() on a
> vector) though I haven't actually run that code on a device.
>
> In the testcase repo I posted above, there are instructions on how to build
> this on the command line with varying optimization values and automatically
> do the disassembly. I've also attached the disassembled contents from my
> machine: building with avr-gcc as included in Ubuntu 10.04 x64 (4.3.4) -
> similar results occur with the compiler bundled with Arduino Linux x64 and
> Arduino for Windows, as well as with avr-gcc 4.7.0 on Windows.  The O2 and
> Os files are basically identical, but you can see the change from O1 to Os
> beyond just memory locations: a big chunk near the top is removed.
>
> So, what I'm hoping someone might be able to do is take a look at this and
> offer suggestions of why this might be occurring (assumptions in Eigen? bug
> in the AVR backend for GCC?). I'd also appreciate some guidance if the
> "warning fix" I mentioned above makes any sense, or if there's something
> else I should do to properly resolve that issue, and also whether the
> workarounds/fixes in the dummy header should be moved into the main Eigen
> tree or otherwise resolved at that level.
>
> (FWIW, I also tried 3.1 with similar results)
>
> Thanks for any help you might be able to offer!
>
> Ryan
>
> --
> Ryan Pavlik
> HCI Graduate Student
> Virtual Reality Applications Center
> Iowa State University
>
> rpavlik@xxxxxxxxxxx
> http://academic.cleardefinition.com