On 9/6/2012 12:52 AM, Weddington, Eric wrote: >> 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?
I agree that there's no end to it if we start adding bits for the options. But I was thinking more in terms of certain characteristics than the options that drive it. I first noticed some incompatibility problem reported by a user when he tried linking to a library - enum xyz as formal parameter causing bad stack, caused by -mshort-enum used by the user but not by the library. I think such incompatibility issues will remain to be a problem for people who build libraries. I agree it's not so common that a user uses different flags for different modules. But that will question why we encode the ISA variation (-march) in the e_flags (the only use that we have is allowing cross compatibility among archs), Though I could presume it's because bfd_arch_info_type requires a routine that checks for compatibility. Regards VP _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list