> 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