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. Of course, object files produced without any of the -f options should have the respective bits cleard (indicating the default behaviour), so any old object file that has been compiled using the default behaviour would not be marked incompatible with a future object module. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
