avr-gcc-list
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]