Modify

Opened 8 years ago

Closed 7 years ago

#6815 closed defect (fixed)

gcc 4.2.4 for AVR32 generates wrong code

Reported by: czietz@… Owned by: kaloz
Priority: high Milestone: Backfire 10.03.1
Component: toolchain Version: Kamikaze trunk
Keywords: gcc Cc:

Description

While compiling software for the AVR32 architecture with gcc 4.2.4 (the version included in the OpenWRT tool-chain for AVR32), I noticed that under some circumstances wrong code is being generated when using optimization ("-O1" and higher).

For example, the attached program gcc-bug.c when built for and run on AVR32 will print "Y = 257" instead of the correct result "Y = 1" when optimization is enabled. This is due to the line

v = x & 0xff;

being silently dropped during the machine dependent reorganization pass of the compile process.

I attached a patch agains Kamikaze trunk to solve this problem. The patch creates ./toolchain/gcc/patches/4.2.4/902-fix_avr32_optimization.patch which in turn when applied fixes the gcc bug.

Attachments (2)

gcc-bug.c (264 bytes) - added by czietz@… 8 years ago.
Test case for gcc bug
fix-avr32-optimization.patch (1.4 KB) - added by czietz@… 8 years ago.
Patch against Kamikaze trunk

Download all attachments as: .zip

Change History (6)

Changed 8 years ago by czietz@…

Test case for gcc bug

Changed 8 years ago by czietz@…

Patch against Kamikaze trunk

comment:1 follow-up: Changed 8 years ago by thepeople

  • Milestone changed from Kamikaze to Backfire 10.03
  • Owner changed from developers to kaloz
  • Priority changed from normal to high
  • Status changed from new to assigned

comment:2 in reply to: ↑ 1 Changed 7 years ago by anonymous

Check http://www.netrino.com/node/80 (How to Use C's volatile Keyword)
The first item of the list "Have you experienced any of the following in your C or C++ embedded code?" is exactly "Code that works fine--until you enable compiler optimizations"

comment:3 Changed 7 years ago by czietz@…

No, anonymous, the link you gave does not describe the problem. Firstly, the document you cited deals with variables not declared volatile by mistake, not with variables which are declared volatile as in my test case. Secondly, my test case is perfectly valid C code, this is definitely a compiler bug.

Should anyone doubt this, I can easily provide a test case which doesn't use volatile. (Basically this is achieved by not declaring x as volatile but loading it from the command line via

x = atoi(argv[1]);

and then calling the program with 257 as command line argument.)

comment:4 Changed 7 years ago by kaloz

  • Resolution set to fixed
  • Status changed from assigned to closed

trunk uses gcc 4.3.5 for avr32

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.