[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-gcc-list] avr-gcc: Add --with-avrlibc configure option for AVR-
Re: [avr-gcc-list] avr-gcc: Add --with-avrlibc configure option for AVR-Libc cooperation?
Mon, 27 Aug 2012 18:20:18 +0000
> -----Original Message-----
> From: address@hidden [mailto:avr-
> address@hidden On Behalf Of Georg-
> Johann Lay
> Sent: Sunday, August 26, 2012 4:10 AM
> To: address@hidden
> Subject: [avr-gcc-list] avr-gcc: Add --with-avrlibc configure option for AVR-
> Libc cooperation?
> for historical reasons, AVR-Libc implements functions that
> GCC expects to live in libgcc, namely float functions like
> Currently, avr-gcc is not configurable to accommodate that
> situation which leads to performance problems if the float
> support functions from libgcc are used.
> This happens at least in the following situations:
> * The user does not specify -lm. -lm should only be needed
> if function from math.h are used, not for language core
> features like int i = (int) float.
> * The application is LTO compiled, i.e. linked with -flto.
> The plugin machinery passes lgcc -lc lgcc through to the
> linker by means of -plugin-opt=-pass-through=-lgcc etc.
> so that -lgcc is linked prior to -lm.
> * The user uses fixed <-> float conversion routines from
> libgcc. These routines refer float functions, and the linker
> resolves these function in libgcc if they are there.
> * avr-g++ is used as linker driver.
Yes, we definitely want to make sure all the above are working.
> In order to fix all of these cases, at least two changes
> are needed in the compiler.
> 1) Remove respective functions from libgcc
> 2) libm.a is not a "math library", it is a "libgcc supplement".
> Thus, -lm has to be treated like libgcc.
Joerg Wunsch and I have talked for years about the idea of integrating libm
into libc, so that way there was only one library to deal with. Would this be a
good point to do that as well? Would that make all the linker flag stuff easier
to deal with?