Re: [avr-chat] broken compiler/avrlibc build symptom?

[Martin Stejskal]

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 <address@hidden>:

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
address@hidden
https://lists.nongnu.org/mailman/listinfo/avr-chat