AVR101, weird compiler error (avr-gcc)

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am using the latest AVR-Toolchain (bundled with AS6.1), optimization: OS

Working from the code example accompanying AVR101, I came up with the following functions:

#define EE_PARAM_BUFFER_SIZE	8
#define EE_STATUS_BUFFER_SIZE	EE_PARAM_BUFFER_SIZE

void findCurrentEepromAddr(uint8_t *eeBufPtr) {
	uint8_t temp;
	uint16_t eeBufEnd;

	*eeBufPtr += EE_PARAM_BUFFER_SIZE;				//Point to the status buffer
	eeBufEnd = *eeBufPtr + EE_STATUS_BUFFER_SIZE;	//The first address outside the buffer

	//Identify the last written element of the status buffer
	do {
		temp = eeprom_read_byte(eeBufPtr);
		(*eeBufPtr)++;
		if(*eeBufPtr == eeBufEnd) {					//break if end of buffer (don't compare out of bounds)
			break;
		}
	}while(eeprom_read_byte(eeBufPtr) == (temp + 1));

	*eeBufPtr -= (EE_PARAM_BUFFER_SIZE + 1);		//Point to the last used element of the parameter buffer
}
//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
void eeWriteBuffer(uint16_t parameter, uint8_t *addr, uint8_t data) {
	uint8_t eeOldStatusValue;

	//Store the old status value and move pointer to the next element in the buffer
	eeOldStatusValue = eeprom_read_byte(addr + EE_PARAM_BUFFER_SIZE);

	(addr)++;

	if(*addr == (parameter + EE_PARAM_BUFFER_SIZE)) {
		*addr = parameter;	//Wrap around (if necessary)
	}

	eeprom_update_byte(addr, data);	//Update the parameter in the EEPROM buffer
	eeprom_update_byte((addr + EE_PARAM_BUFFER_SIZE), (eeOldStatusValue + 1));
}

Unfortunately, when I try to compile, I am getting an error I've never seen before:

Error	1	unable to find a register to spill in class 'POINTER_REGS'	
Error	2	this is the insn:	\eepWearLevel.c	39	1	
Error	3	confused by earlier errors, bailing out

The offending line is the last line in eeWriteBuffer. If I comment it out, the code compiles normally. Unfortunately, I cannot figure out what is wrong with the final line -- i.e., why it would cause a fault. Am I being dense, or is this a bug in avr-gcc? A quick google search indicated that this may be a bug in avr-gcc...

Edit:
see here:
https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=864628
and here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39212

Science is not consensus. Science is numbers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Follow up: changed optimization settings:
-0s --> Does not work
-O1 --> Works
-O2 --> Does not work
-O3 --> Does not work

For the record, I do not know the details of the different optimization settings. I have always used -Os, because size was most important to me, and the old AVR Studio recommended -Os for speed.

Mods: I apologize if this is in the wrong forum. If necessary, please move to the gcc forum.

Science is not consensus. Science is numbers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

An internal compiler error is always a bug in the compiler itself, no
matter what.

The PR you are referring to has been closed as "works for me", but it's
been for a much older GCC version anyway, so your problem is unlikely the
same as that one (even though you are getting the same message).

The usual procedure: strip down your project to a minimum where it can be
reproduced (which might be a challenge in cases like this), then open a
GCC bug report, with the *preprocessed* sourcecode attached.

Errm, before you might meaningfully submit it to the GCC project, you
should probably cross-check that the error also happens with a *stock* GCC
version, rather than the Atmel one only. If it only happens with the Atmel
version, you have to ask Atmel support for help.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If I cut out everything except the function eeWriteBuffer() and add

#include 
#include 

and compile with

avr-gcc -mmcu=atmega328p -Wall -Os -c test.c

I get the same error with Atlmel toolchain 3.4.2 (gcc 4.7.2) and with stock (no Atmel patches) 4.7.2 and 4.8.0. But no error with an old 4.3.4.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Since the offending line appears to be the call to eeprom_update_byte, how could I check that with a "stock" gcc? Doesn't it have to be an avr-gcc to include that function?

What would be the next step here? I have never filed a bug report before...

Science is not consensus. Science is numbers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Recorded as PR58545. You can CC to the issue if you like.

gcc(dot)gnu(dot)org/PR58545

The compile passes with -fno-caller-saves

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

check that with a "stock" gcc

He means an avr-gcc built from the generic source not Atmel's attempt to build it (which has been known to have problems and this could well be another one).

SprinterSB knows how to build GCC "properly" and if you find his posts his sign-line has a link to some avr-gcc builds he's made for Windows.

try one of those instead. If the problem persists it is a generic GCC fault and should be reported to the Bugzilla as Joerg advised. If the problem is not seen there then it is an Atmel local build problem and they should be told (they don't participate in open development but "go it alone").

I read Snigelen's post to suggest it *is* a generic fault so it should likely be reported to the GCC Bugzilla.