[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Georg-Johann Lay
Subject: Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect
Date: Thu, 12 Jan 2012 22:54:40 +0100
User-agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)

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)

As said above, it's not only about optimization as such but also about
promotion rules that cannot be optimized away in all situation. So if
you are on a target were each byte counts I guess developers will very

much appreciate -mint8, be it blessed by standard or not...


One of the biggest complaints from users has to do with promotion rules
being overly enforced during a set of operations, and then the result is
stored in some variable, typically of a smaller size (typically an
unsigned 8-bit variable), thereby truncating the value. In these
particular cases the enforcement of the promotion rules has no bearing
on the final outcome of the operations, but it does cause an unnecessary
increase in code size.

In these cases, is there a way to optimize the code such that these
promotion rules aren't strictly followed *when it does not affect the
outcome of the operation*?

The problem that I have with -mint8 is:
- it doesn't follow the standard
- it breaks avr-libc (or rather, avr-libc isn't adapted to it)
- people use it, because the backend hasn't been taught how to do the
right thing.

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.

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

reply via email to

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