Follow-up Comment #3, bug #30363 (project avr-libc):
But should <util/delah.h> be using autonconfig information directly to
determine if __built_avr_delay_cycles() is available?
Why not require it to be told this information at compile time (by
<avr/builtins.h> ) and in the absence of being told whether these functions
are built in, assume that they are not?
Why can't <util/delay.h> include <avr/builtins.h> directly?
rather than attempt to figure it out on its own?
And if it can't always include that header, have auto configure determine if
it can include this file or not and then <util/delay.h> could disable the
built in delay cycles function
instead of including the header if the user didn't explicitly do an
override.
The ideal fix for something like this is to fix GCC itself to create defines
for all built in functions.
gcc could define __BUILTIN_XXX or __HAS_XXX whenever the internal function
XXX is defined. The MIPS gcc compiler creates these defines for every single
builtin function manually on its own. The correct thing to do is to fix gcc
upstream by adding the single function call to the function that creates
internal defines each time the function to create an internal/builtin gcc
function is called. It is a single call and would then work across *ALL*
compilers.
That way every time an internal/builtin function is created, the compiler
would create a corresponding define.
It is literally a single function call that needs to be added to the compiler
to make this happen.
This would allow the preprecessor to have access to a well known define name
for every built in gcc function regardless of CPU architecture.
This is so simple and would help solve this type of issue for everyone
forever going forward.
--- bill
_______________________________________________________
Reply to this item at:
<http://savannah.nongnu.org/bugs/?30363>
_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/
_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
