> -----Original Message----- > From: avr-gcc-list-bounces+eric.weddington=atmel....@nongnu.org [mailto:avr- > gcc-list-bounces+eric.weddington=atmel....@nongnu.org] On Behalf Of Joerg > Wunsch > Sent: Wednesday, September 05, 2012 2:05 AM > To: avr-gcc-list@nongnu.org > Subject: Re: [avr-gcc-list] EF_AVR_LINKRELAX_PREPARED bit in e_flags > > In article <5046e9de.2060...@gjlay.de> you write: > > >If you introduce a compatibility check then any usage of libgcc or > >AVR-Libc will trigger a diagnose because these libraries are build > >with the default ABI and none of these options is a multilib option. > > Which, in turn, I think would be a really good idea. ;-) > > I always thought specifying that -ffoobar nonsense is a poor idea from > the beginning: "char", "signed char", and "unsigned char" must never > be mixed in portable code anyway, so the code should work the same > regardless of any -f option. (For small integer numbers rather than > printable characters, using C99 uint8_t/int8_t is much preferrable.) > Short enums should be declared by the respective attribute rather than > implying them by a compiler option. Structure packing is a no-op on > the AVR as it only requires an 8-bit alignment for everything anyway. > > So yes, I think encoding them in the object format, and make the > linker warn about mixing differently encoded object modules is a nice > idea.
It's a nice idea, but is it a solution looking for a problem? We haven't had any (to my knowledge) issues reported about users linking together incompatible modules. For the most part, an application is built altogether at the same time, using the same compiler flags. Rarely do one set of modules, compiled with one set of compiler flags, get linked to another set of modules, compiled with a different, incompatible set of compiler flags. Let's make sure we're solving real problems, rather than made-up ones. If we start including those compiler flags, where does it end? How many should we include and check for? Eric Weddington _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list