Re: [avr-gcc-list] EF_AVR_LINKRELAX_PREPARED bit in e_flags

[Georg-Johann Lay]

Weddington, Eric:
> Joerg Wunsch:
> > Of course, it would have been nice if people wouldn't have started
> > using these ABI-incompatibility options in the first place, but 
> > they do.  Yes, I'm partially guilty for spreading them around :) by
> > not thoroughly thinking about what has once been distributed with 
> > Mfile. I feel quite sorry for that.
>
> Oh, geez, then we're both guilty of doing that 10 years ago. That's 
> why I asked if this was even a real problem; 10 years and no 
> complaints or issues about this area. (Pretty good track record, 
> IMHO.)
>
> > We might perhaps concentrate on the more severe of those flags 
> > (-mint8 [cough, cough]
>
> :-P (When can we get rid of it?.....)

It's just been fixed to operate again.  It would be embarrassing to
remove an option because it is broken, better repair it and then
remove it with heads held high.

> > and -fshort-enums immediately come to mind, as they affect the size
> > of certain objects).
>
> Point. Should we compile avr-libc with -fshort-enums?

I don't think.  That's an ABI change.  The defaults for these options
are determined by the ABI.  Because there was never a proper ABI
document, the GCC default is used.

Does AVR-Libc expose enums, for example in FILE?

I don't think we should change the ABI too often (if at all).

If a user changes the ABI it's up to him to ensure that everything works
well.  The more ABI aspects he clobbers, the more likely he will run
into problems.  And I still think it's a bug if a IDE sets options that
change the ABI per *default* and without user interaction.  That's rude.

> That one is a useful flag. I know that -fpack-struct is a nop. And
> -funsigned-char just kind of levels the playing field for those users
> who aren't used to using <stdint.h>.

We have currently 16 multilib variants:

$ avr-gcc -print-multi-lib
.;
avr25;@mmcu=avr25
avr3;@mmcu=avr3
avr31;@mmcu=avr31
avr35;@mmcu=avr35
avr4;@mmcu=avr4
avr5;@mmcu=avr5
avr51;@mmcu=avr51
avr6;@mmcu=avr6
avrxmega2;@mmcu=avrxmega2
avrxmega4;@mmcu=avrxmega4
avrxmega5;@mmcu=avrxmega5
avrxmega6;@mmcu=avrxmega6
avrxmega7;@mmcu=avrxmega7
tiny-stack;@msp8
avr25/tiny-stack;@address@hidden

Every new multilib switch like on/off -f/-fno- will double that number.

If one of these options is *really* needed to be properly supported,
then the only reasonable approach is to promote the option to a
multilib option -- Reasonable modulo the number of multilibs.
Notice that libgcc comes with 1e3..1e4 support functions.

Anything else will flood users with zillions of warnings because the
ABI is changed per option, and I don't see a reason why to flood
users that write code that complies to the ABI by turning the libs
non-ABI.

The only solution to avoid these warnings is to support compatibility,
i.e. inflate the number of multilibs again and again.

The only reasonable additional multilib options are IMO -mint8 and
-fno-short-double, maybe -Os/-Ospeed, but they are pointless at the
moment because AVR-Libc does not support them, except -Os in the C
bits.  Moreover, each multilib option like -msp8 has to be hard
coded in AVR-Libc, because its build machinery does not depict
the multilib layout from gcc, AFAIK.

Johann