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

[Georg-Johann Lay]

Weddington, Eric wrote:
> Ok, so there are historical reasons why we (avr-libc maintainers) did it
> that way. Today, it may be different.

The historical reason might have been that some guys were unsure about the
implementation and the implementation (avr-gcc) is not well documented: You
will have to read the sources to see the sizeof(int) = 2
> 
> Personally, I would like to see -mint8 go away. As we keep stating: it
> breaks the standard. That's a good enough reason for me. I'd rather not

sizeof(double) = 4 also breaks the standard...

> keep around non-standard stuff, which breaks avr-libc anyway. AIUI,
> though, there are people who want the best code density, which *may*
> require -mint8. But there aren't *that* many people who use the switch.
> I think that as soon as we have enough confidence in the code generation
> of the AVR backend, then we should seriously consider getting rid of it.

As -mint8 affect sizeof(int) it also affects promotion rules, i.e. if you do a
shift you will always have the result at least at sizeof(int) no matter if you
cast down the result to a bits. This is different if int=char because bits
8..15 of the shift result of char are undefined and the code need not care.

Similar applies for division, a commonly needed feature that's very expensive
on AVR with respect to time and code consumption. The needed resources can be
cut down by using -mint8 and many of the optimization cannot be done by
perfectly optimizing compiler because of promotion rules.

I agree that -mint8 is superfluous nowadays in many cases, e.g. promotion of
return types. But this is more of an inconsistency between the AVR ABI and the
way avr-gcc actually behaves (it does not promote char to int since 4.3).

IMHO, the issue with -mint8 it rather that there is no code to test the feature.

> I think it does make certain sense to change the typedefs of our
> stdint.h to make them straightforward C like Johann shows above. GCC
> modes are very much specific to GCC. Yes, the backend defines the sizes
> of those types, and the backend doesn't change on a whim. We don't have
> enough backend developers to be worried about "whimsy". ;-)

As aid above int is implementation defined so the implementation has to state
what it is. It's rather an issue of documentation and ABI and sticking to it,
and from that you will know the sizes of int, short and long, etc. and can rely
on it. Otherwise it's a compiler bug.

> Johann, you've been working on the GCC backend *a lot*. You probably
> have the best sense of where it stands. When do you think we can remove
> the -mint8 switch? Do you think that the backend codegen is good enough
> now to warrant this? 

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

The issue with -mint8 is rather that it is broken quite some time now, see 
PR46261.