Jim Brain <br...@jbrain.com> wrote: >> *which* relocations are truncated?
> It moved around, depending on how much code I compiled in. The last > batch were EEPROM routine references. That basically rules out the -lm issue. >> What are your compiler commandline options? I hope you didn't use the >> silly -mshort-calls option. This option would better not exist at >> all. > *hangs head in shame* Yes, I did. Sheesh, I wish this option had not invented at all. I'm tempted to open a GCC PR requesting its immediate removal. > After removal, compilation is back > to normal. Good to know. > In my (somewhat lame) defense, I believe I copied this Makefile from a > Tiny2313 project (it started life on a Tiny), and was trying to keep > code size at a bare minimum. It wouldn't have changed a bit. As the ATtiny2313 does not have long jumps/calls anyway, code generation for it always uses RJMP/RCALL. Only on devices with more than 8 KiB of flash, the code generation uses JMP/CALL. The way to shorten the jumps and calls afterwards is not to force the compiler not issuing them in the first place (now, you ought to know why this is not the correct way, Jim ;-), but to use the -mrelax option. (Yes, Jan, I know it has its own set of issues.)+ That lets the linker decide which jumps or calls are real candidates for being shortened. You are not alone. Even AVR Studio offers that nonsensical option (while leaving out more important things). Another common nonsensical option is to apply -fpack-struct: as the AVR has no alignment requirements beyond a single byte, structs on the AVR are always packed as tight as possible. -- 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
