Avr-gcc 4.3 long int bug

Support Robots
1

Be careful guys!

avr-gcc (aka “gcc-avr”)

  • Version 4.3.0 has a major bug which affects multiplication of long int’s. This is the default version in Ubuntu Intrepid (8.10). Check using “avr-gcc --version” and upgrade if necessary.
2

Thanks!

Any idea if this bug affects WinAVR 20080610? I believe it uses GCC 4.3.0, but I’m not entirely clear on the interdependence of all of the open source AVR projects.

-Adam

3

Thanks for the note, epokh! Here is the bug report in case anyone wants to see the details of the bug, which are presented in assembly language. It looks like GCC 4.3.1 should be okay. Adam, can you confirm that WinAVR 20080610 is really based on GCC 4.3.0? That would be unfortunate, since GCC 4.3.1 was actually released (a few days) before 2008-06-10.

-Paul

4

Thanks for tracking down the bug report, I’m trying to figure out if this affects any of my compiled programs.

-Adam

5

So I’m a little confused about the actual effect of this bug, but I never really learned AVR assembler. When I compile the sample code from the bug report and run it in simulation, I get the correct value.

I guess what I’m trying to figure out is, can this bug actually produce a mathematically incorrect result when multiplying a long int and a constant, does it do something else that’s seriously wrong, or does it just do everything mathematically and computationally correctly, but in a sub-optimal way (in which case I can stop giving myself an ulcer over it).

-Adam

6

Okay, this is VERY strange.

When I command-line compile (not using AVR Studio at all) the test code from the bug report using WinAVR20080610 and the report’s example arguments, I get very similar assembly outputs for the ATTiny25 the ATMega16, the ATMega168 and the ATMega324p. The three Mega outputs are the same, and the only difference between these and the Tiny output is that the Tiny uses “rcall __mulsi3” while the Megas use “call __mulsi3”, which is no biggie. The four lines of loading the 150 constant values into various registers, which are missing in the bug report’s ATTiny16 “incorrect” example output, are present in all of the files I just generated.

I wonder if the bug was addressed by the WinAVR team when they built that release. All of the complaints about it I find on-line are from people using AVR GCC 4.3.0 directly under Linux.

-Adam

7

I’m still learning the terminology here, but I think I’ve got this straight now:

The long-int multiplied by a constant bug, AVR-GCC bug #35872 is “dependent” on bug #35519, which “blocks” the multiplication bug when fixed.

WinAVR-20080430, WinAVR-20080512, WinAVR-20080610, and WinAVR-20081205 were all built with a patch that fixes bug #35519, which therefore prevents bug #35872.

WinAVR-20090313 is based on GCC 4.3.2, which doesn’t suffer from bug #35519 in the first place.

Looks like I dodged a bullet here!

-Adam