[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-gcc-list] Where report ICE in WinAVR?
From: |
Georg-Johann Lay |
Subject: |
Re: [avr-gcc-list] Where report ICE in WinAVR? |
Date: |
Tue, 27 Jan 2009 00:14:17 +0100 |
User-agent: |
Mozilla Thunderbird 1.0.7 (Windows/20050923) |
Weddington, Eric schrieb:
Well, no wonder. Your test case shows this function:
void put_sfrac16 (data16_t q)
{
unsigned char i;
for (i=0; i < 2; i++)
{
register data16_t digit asm ("r24");
digit.asByte[1] = 0;
digit.asByte[0] = q.asByte[0];
digit = mac10 (digit);
q.asByte[0] = digit.asByte[0];
}
}
The first parameter to any function will be passed in r24, so why are you
attempting to reserve it for the variable 'digit'?
Yes, this code served in former compiler versions to get small and fast
code. I put digit in r24 for /exactly/ that reason: because avr-gcc uses
this reg to pass the first arg if it's 8 or 16 bit and return a
function's value.
The avr-libc user manual, FAQ #13, shows the ABI:
<http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_reg_usage>
Yes, I am well aware of that.
But in the above code, without the asm("r24") (the original code is more
complex), gcc would reload digit not into r24. This is strange, because
digit just serves /only/ as first arg to the called func and as return
value which immediately after the call is reused as first argument again.
I would not have wondered if older gcc versions reported a problem.
There are other more appropriate registers to choose from, if you really think you need to put that variable in a register. If you are trying to speed up the whole routine, and you chose r24 for 'digit' because it would make it faster to call your mac10() function, then you need to change your strategy, and have mac10 be an inline function and let GCC decide where to put the 'digit' variable.
Unless you have some valid reason for doing this, I'm tempted to close this bug
as invalid.
It was ok if the compiler complained about the asm or that he could not
do some fwprop optimisation. But IMHO it should not throw an ICE and
should behave just as kind as 4.3.0 or older versions.
Regards, Georg-Johann