avr32-as.exe still "broken" in Atmel Studio 7

1 post / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Seems they have yet to fix the bug in avr32-as.exe

 

Clean AVR32 GCC executable project. -nostdlib and cleaned out everything before creating a single source file: main.s

.public _start
_start:
	mov		R0, 0
	ld.weq	R8, R0[IRAM_TESTVAR]

.data
IRAM_TESTVAR:	.word	0x00000000

Produces "Internal error!":

------ Build started: Project: GccApplication1, Configuration: Debug AVR ------
Build started.
Project "GccApplication1.cproj" (default targets):
Target "PreBuildEvent" skipped, due to false condition; ('$(PreBuildEvent)'!='') was evaluated as (''!='').
Target "CoreBuild" in file "C:\Program Files (x86)\Atmel\Studio\7.0\Vs\Compiler.targets" from project "C:\Users\norleif.slettebo\Documents\Atmel Studio\7.0\GccApplication1\GccApplication1.cproj" (target "Build" depends on it):
	Using "RunCompilerTask" task from assembly "C:\Program Files (x86)\Atmel\Studio\7.0\Extensions\Application\AvrGCC.dll".
	Task "RunCompilerTask"
		Shell Utils Path C:\Program Files (x86)\Atmel\Studio\7.0\shellUtils
		C:\Program Files (x86)\Atmel\Studio\7.0\shellUtils\make.exe all 
		Building file: .././main.s
		Invoking: AVR32/GNU Assembler : 4.4.7
		"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr32\avr32-gnu-toolchain\bin\avr32-as.exe" -mpart=uc3c164c -g   -o "main.o" ".././main.s" 
		.././main.s: Assembler messages:
C:\Users\norleif.slettebo\Documents\Atmel Studio\7.0\GccApplication1\main.s(4,1): error: Internal error!
		Assertion failure in finish_insn at /data2/home/toolsbuild/jenkins-mcu-knuth/workspace/avr32-gnu-toolchain/src/binutils/gas/config/tc-avr32.c line 3601.
		Please report this bug.
		make: *** [main.o] Error 1
	Done executing task "RunCompilerTask" -- FAILED.
Done building target "CoreBuild" in project "GccApplication1.cproj" -- FAILED.
Done building project "GccApplication1.cproj" -- FAILED.

Build FAILED.
========== Build: 0 succeeded or up-to-date, 1 failed, 0 skipped ==========

The bug is in how the assembler parses the conditional load word with displacement instruction using a symbol defined in the .data section. a normal, unconditional, load word with displacement instruction works fine. Replacing the symbol (IRAM_TESTVAR) with a numeric expression (0x0004) works for the conditional instruction, but complicates memory allocation.

Using symbols declared by .equ or .equiv works fine for the conditional instructions, as long as they don't reference .data section symbols.