On Sun, Sep 2, 2012 at 12:17 PM, Georg-Johann Lay <a...@gjlay.de> wrote: > Gabriel Dos Reis schrieb: >> >> On Sun, Sep 2, 2012 at 8:56 AM, Georg-Johann Lay <a...@gjlay.de> wrote: >>> >>> Weddington, Eric schrieb: >>>>> >>>>> On Behalf Of Georg-Johann Lay >>>>> >>>>> for historical reasons, AVR-Libc implements functions that >>>>> GCC expects to live in libgcc, namely float functions like >>>>> __fixsfsi. >>>>> >>>>> 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? >>> >>> >>> If there are plans to integrate libm into libc then this should >>> be done *before* GCC supports --with-avrlibc configure option. >>> >>> Otherwise, AVR-Libc would knock out itself making the linker throw >>> a "cannot find -lm" or similar linker error which would make that >>> configure option obsolete... >>> >>> The preferred way would be *not* to move libm to libc so >>> that the library layout is stable and the configure option >>> works across various versions of AVR-Libc, even older ones. >>> >>> The intersection between libgcc and AVR-Libc is stable and >>> did not change often, if I see correctly. Changing the layout >>> just now might be not helpful; except in the case there is >>> a dummy libm.a that prevents "cannot find -lm" link error. >> >> >> How about just having the driver add -lm (unless specifically >> instructed not to) systematically? > > > Could you explain this? > > specs like LIBGCC_SPEC and LINK_GCC_C_SEQUENCE_SPEC work on the > driver level. > > The fixed-point issue shows that -lm is not enough and some functions > have to be removed from libgcc.a if the compiler is to be used with > AVR-Libc so that a new configure option is needed no matter what in > order to get best performance.
My point was manyfold: -- From the original message, the fact that users did not specify -lm should never be an issue. In fact, users should never have to specify -lm. We have at least 2 decades of practice under the belt in the libstdc++ land :-) -- have the driver pass -lm before -lgcc. This is internal to GCC. It should never be user problem. Unless user says "please don't; I have my own ideas about this." Then user takes full responsability for the fallout. This should fix the -flto problem. -- The libgcc problems to me means that we have a "layering" problem to address at the libgcc level. Maybe we should have libmath-core for the core-math (actually conversions) functions that libgcc assumes. In many ways, this looks like the libsupc++ stuff we have in the libstdc++ land. -- Gaby _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list