Hi, Try this: delay_wrapper (const int ticks).... Because in new versions _delay_... functions want parameter as constant, so maybe this can be root of problem... But it is shot to dark :) I've noticed this warning message when using delay functions some time ago, but I do not think that is a bug. I suspect, that developers wanted make delays more precise, so when parameter is constant, it can be calculated more precisely (no variables, one solution), especially in _delay_us() where every cycle counts. Martin
2014-09-23 3:28 GMT+02:00 Britton Kerin <[email protected]>: > I just rebuilt binutils/gcc/avrlibc stack using the latest. Its my > first time trying this. > > I now get a weird behavior trying to compile some code that uses > _delay_us(). > This file: > > #include <util/delay.h> > > // Pause for exactly ticks ticks. > static void > delay_wrapper (int ticks) > { > _delay_us (ticks); > } > > void > wrapper_caller (void); > > void > wrapper_caller (void) > { > delay_wrapper (42); > delay_wrapper (43); > delay_wrapper (44); > //delay_wrapper (45); > } > > Compiles cleanly this way: > > avr-gcc -DF_CPU=16000000 -I. -std=gnu99 -fshort-enums > -mmcu=atmega328p -Os -Werror -Wall -Wextra -Winline > -Wmissing-prototypes -Wredundant-decls -Winit-self -Wstrict-prototypes > -c test.c -o test.o > > But uncommenting that last delay_wrapper() call causes that same compile > command to fail like this: > > In file included from test.c:1:0: > /home/bkerin/opt/avr/avr/include/util/delay.h: In function > ‘delay_wrapper’: > /home/bkerin/opt/avr/avr/include/util/delay.h:245:28: error: > __builtin_avr_delay_cycles expects a compile time integer constant > __builtin_avr_delay_cycles(__ticks_dc); > ^ > > I suspect that the extra call causes the compiler to not inline > delay_wrapper(), which in turn triggers this error. If I change the > declaration for delay_wrapper to 'static inline void', the compiler > complains > that inlineing has failed with that fourth call, otherwise it doesn't, > which seems to support this theory. > > Is this likely to be a symptom of a bad binutils/gcc/avrlibc build? > Genuine > bug? > > _______________________________________________ > AVR-chat mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/avr-chat >
_______________________________________________ AVR-chat mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/avr-chat
