Re: [avr-libc-dev] How to handle builtin functions?

[E. Weddington]

On 2 Sep 2002 at 15:58, Joerg Wunsch wrote:

> I noticed <math.h> has the following:
> 
> extern double fabs(double) __ATTR_CONST__;
> #if 0
> /* fabs seems to be built in already */
> extern inline double fabs( double __x )
>   { double __res;
>     __asm__ __volatile__ ("andi %D0,0x7F \n\t"
>                 : "=d" (__res) : "0" (__x) );
>     return __res;
>   }
> #endif
> 
> Surprisingly enough, when linking one of my projects, the linker
> complained about an undefined reference to fabs().
> 
> So i investigated a bit.  It seems all the various *abs* functions are
> indeed builtins for gcc.  Thus, the inline functions for abs() and
> labs() in <stdlib.h> can go away as well.  However, the usual exposed
> names for these functions are disabled when using -ffreestanding.
> Using this option makes some sense for the AVR (we don't really have
> an environment, so we have a freestanding implementation in the sense
> of the C standard), e. g. it allows to use "void main(void)" which
> quite makes some sense in our case (main() is not really supposed to
> ever return).  Yet, i think we should provide those builtin functions
> that are applicable even in the -ffreestanding case.
> 
> One option would be to always override all of the builtins we want to
> use like this:
> 
> #define abs(x) __builtin_abs(x)
> #define labs(x) __builtin_labs(x)
> #define fabs(x) __builtin_fabs(x)
> 
> The other options would be to just declare those functions the
> usual way, and then encapsulate the above redirect #defines into
> #if !__STDC_HOSTED (which is set to 0 when using -ffreestanding).
> 
> Opinions?
>

It makes sense to make avrlibc work with as many of gcc's switches as 
possible. Hence a project should compile and link correctly when 
using -freestanding. It sounds like you have an implementation in 
mind which sounds fine to me.

If you don't go ahead and write it up, we should at least put it on 
the TODO list.

Eric