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

[Weddington, Eric]

> -----Original Message-----
> From: Georg-Johann Lay
> Sent: Thursday, January 12, 2012 2:55 PM
> To: Weddington, Eric
> Cc: Joerg Wunsch; address@hidden
> Subject: Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are
> incorrect
> 
> 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.

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.

 
> 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?


> > The thing is, is if the AVR backend knew how to optimize away these
> > superfluous promotions, then I really don't think that -mint8 would
ever
> > really be needed. Why should a user have to specify a switch to get
the
> > compiler to do the right thing?
> >
> > How can we get to this point?
> 
> Raise AVR #2

Sure. ;-)

All joking aside, though, I'd like to see that happen, but I know it's
going to take time.

Eric