Apparent GNU Assembler v2.19 Bug(s)

[Bruce Waggoner]

 

Greetings -

 

We are using Atmel's AVR32 Studio to write assembly code for Atmel AVR32 processors.  AVR32 Studio uses the GNU toolchain, including assembler and linker.  We have GNU assembler (for AVR32) v2.19.

 

The assembler has been working great, on multiple projects, until today, when it started "losing its mind" in response to adding 1-3 extra lines of source code ("nop" instructions).

 

I think you can agree that no assembler should ever crash as a result of adding a single extra "nop" instruction in the source code, but that is exactly what is happening here.

 

The assembler's typical response when it gets "upset" is to generate dozens of bogus error messages, for lines of code which have assembled just fine dozens of times previously.

 

Judging from some of the error messages we have seen, it appears as though some internal buffers or tables or variables are overflowing, and/or pointers are being corrupted.  The report copy below does not illustrate this well, but it does make mention of an "internal error" and an "assertion error", so is good in that respect.

 

Here is an example error printout generated 2011-2-2 by GNU Assembler v2.19:

 

**** Internal Builder is used for build               ****
avr32-as -mpart=uc3a0256 -oPCIe-SDV.o ..\PCIe-SDV.s
..\PCIe-SDV.s: Assembler messages:
..\PCIe-SDV.s:4152: Error: missing ')'
..\PCIe-SDV.s:4162: Error: missing ')'
..\PCIe-SDV.s:4241: Error: missing ')'
..\PCIe-SDV.s:4242: Error: unrecognized instruction `mose)'
..\PCIe-SDV.s:4268: Error: junk at end of line, first unrecognized character is `)'
..\PCIe-SDV.s:4268: Internal error!
Assertion failure in ignore_rest_of_line at /home/mingwbuild/avr32src/binutils/gas/read.c line 3537.
Please report this bug.
Build error occurred, build is stopped
Time consumed: 812  ms.

 

The source text file is about 839KB in size (lots of comments).

 

The output binary file is about 27KB (last good assembly before it started crashing).

 

The Assembler output file says "Please report this bug.", so that's what we are doing via this e-mail.

 

We are dead in the water until this bug gets fixed, or we find some way around it.

 

Any helpful hints (other than switching to the "C" programming language which is probably the source of this problem) for circumventing this "issue" would be very much appreciated.

 

Bruce Waggoner

Adrienne Electronics Corporation

Las Vegas, Nevada USA