Follow-up Comment #2, bug #50811 (project avr-libc):
Ok, with printf("foo: %d\n, 42), the program is indeed smaller with by 264
bytes when -Wl,-u,vfprintf -lprintf_min is used than when none of the printf
linker flags are used.
I guess this is a wishlist item really: it would be nice if using
Follow-up Comment #4, bug #50811 (project avr-libc):
You're correct, there's no reason when printf isn't being used to use those
linker options. However:
* realistically at least some linker options are at least somewhat black magic
to many users.
* printf() is particularly likely to go from
Follow-up Comment #3, bug #50811 (project avr-libc):
Using _Wl,-u,vfprintf is essentially forcing the symbol vfprintf to be
undefined and added to the program. This is what's causing your code size to
increase when not otherwise using vfprintf.
It isn't clear to me why that option should be
Follow-up Comment #6, bug #50811 (project avr-libc):
Well, the fact that the -u vfprintf needs to be forced is
an unfortunate side effect of libprintf_min.a *only* containing
a different definition of vfprintf(), but not e.g. for printf()
or other members of the family.
Thus, if you only add
Follow-up Comment #7, bug #50811 (project avr-libc):
If that's the case, why provide an optimized version of printf() for constant
strings at all? I guess maybe it happens inevitably due to compiler
machinations.
Anyway, at least one person (me) hit this issue and it took me some time to
find
As Raul Sanchez wrote:
> Just wanted to report the following observations in generated code.
> Target: __AVR_ATtiny85__Version: AVR gcc 4.6.4Optimization level: -Os
Besides your code missing linefeeds so it's barely readable: sorry,
GCC code optimization is nothing we could do anything about.
