Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect

[Georg-Johann Lay]

Weddington, Eric wrote:
> 
>> From: Georg-Johann Lay
>> Weddington, Eric schrieb:
>>>> sizeof(double) = 4 also breaks the standard...
>>> Hence, one of the reasons to have correct doubles added to the
>>> backend.
>> Would a patch for 4.7 be supported by avr maintainers?
>>
>> Patch would look like:
>>
>> - depend DOUBLE_TYPE_SIZE, LONG_DOUBLE_TYPE_SIZE on short-double
>> - raise -fshort-double to a multilib option
>> - adapt multilibs generation (doubles numer of libs' incarnations)
> 
> I'd rather not have to do the last step if we can get away with it.

The last is inevitable as -fshort-double will change the ABI.

> I would also think that we need to coordinate avr-gcc and avr-libc, to
> make sure that we have math routines for float and the corrected double
> size. That could take some time. Because of that, I'm ok if the double
> patch went into 4.8.

avr-libc can stay as is, I will work out a solution that won't require any
avr-libc changes (under the assumption that avr-libc if fine with being
non-standard compliant with respect to double).

>> The backend is too late to fix it. It can be done but it rather clutters
>> up backend with ugly code like for http://gcc.gnu.org/PR29560
>> Similar problems arise in http://gcc.gnu.org/PR18065
>>
>> The front end says: "I must comply to the standards"
>> The middle ends crunch the code and don't have the big picture.
>> The back end is left with the bad code and hacks on it but cannot
>> really fix it because it's too late.
>>
>> So you need someone to dive into the tree optimization passes and does
>> the changes for our irrelevant architecture there.
> 
> Rats.
> 
> Stupid question, because I'm not a compiler expert: Could any of this be
> done with peephole (or in gcc parlance peephole2) optimizations?

peep2 is not will suited for that. Sometimes you don't have the relevant
information and in other cases cutting down the operation does not help: what
you'd actually need is also to optimize the code that lead to the situation or
that uses the cut-down result. So you also want to optimize code around the
promote-spot. You always need certain amount of context to properly optimize.
Moreover, registers already have been allocated in peep2, so if you need less
registers you cannot roll back.

Johann