[avr-gcc-list] [Bug] Initialization for _delay_loop_2 Optimized Out

[Dave Hansen]

Joerg Wunsch wrote:
> As "Dave Hansen" <iddw at hotmail.com> wrote:
>
> > #define CLOCKS_PER_US   ((U16)(OSC_FREQ/1000000))
> > #define CLOCKS_PER_LOOP 4
>
> You remember that all these calculations are done using the `int' data
> type, i. e. a 16-bit one, unless you force it to become long, do you?
> So unless your OSC_FREQ macro has an `L' added somewhere, the above
> division might become 0.

No.  From n869 6.4.4.1p5:

  "The type of an integer constant is the first of the corresponding list 
in which its value can
   be represented."

There follows a table showing the resulting types of integer constants.  For 
a decimal constant with no suffix, the list is "int, long int, long long 
int."  So 1000000 is a long, even without the suffix.  Same for OSC_FREQ, 
which, if you look more closely at the supplied code, is 12000000.  The 
division is performed in long arithmetic, and the result (12) is converted 
to U16.

> > static inline void
> > my_delay_loop(unsigned int __count)
>
> Identifiers with leading underscores are reserved (for ``the
> implementation'') by the C standard.  Please stay away from them
> inside your application, or you might risk a name clash with the
> compiler or library.

True.  But if you're worried about portability, you might as well scold me 
for using "asm."  As I said in my earlier post, my_delay_loop is an exact 
copy of _delay_loop_2 (which is part of "the implementation") with some 
additional code added, and is included as an illustration.  It appears to be 
safe on this implementation (avr-gcc) for the following reasons:

  1) The scope of the symbol is local to the function
  2) The function doesn't use the library (though it does use the asm 
extension)
  3) The implementation does not use the symbol as a macro or keyword
  4) The implementation uses the same symbol in the same manner
  5) The code using my_delay_function *works*.

Which, again, is the whole point of the bug report.  I haven't tried it (I 
don't have the time right now), but I suspect the following:

  #include <avr/delay.h>
  int main (void)
  {
     while(1)
        _delay_loop_2(3);

     return 0;
  }

Would generate incorrect code.  Regards,
  -=Dave

_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail