[Bug c++/28718] New: Call to -lgcc added prior to user libraries

[Bug c++/28718] New: Call to -lgcc added prior to user libraries

[j at uriah dot heep dot sax dot de]

When calling avr-g++, the linker driver adds a call to -lgcc before any
of the user libraries entered on the command-line.

On the AVR, this causes the wrong math function implementations taken from
libgcc.a rather than the (user-supplied) libm.a.

This is different from the C compiler driver, why?

Given (any) C++ file foo.cc, using avr-gcc:

% avr-gcc -v foo.cc
Using built-in specs.
Target: avr
Configured with: ./configure --prefix=/tools/i686 --target=avr --disable-libssp
--with-dwarf2
Thread model: single
gcc version 4.1.0
 /tools/i686/libexec/gcc/avr/4.1.0/cc1plus -quiet -v foo.cc -quiet -dumpbase
foo.cc -auxbase foo -version -fno-rtti -fno-enforce-eh-specs -fno-exceptions -o
/tmp/cc7jbBxg.s
ignoring nonexistent directory
"/tools/i686/lib/gcc/avr/4.1.0/../../../../include/c++/4.1.0"
ignoring nonexistent directory
"/tools/i686/lib/gcc/avr/4.1.0/../../../../include/c++/4.1.0/avr"
ignoring nonexistent directory
"/tools/i686/lib/gcc/avr/4.1.0/../../../../include/c++/4.1.0/backward"
ignoring nonexistent directory
"/tools/i686/lib/gcc/avr/4.1.0/../../../../avr/sys-include"
#include "..." search starts here:
#include <...> search starts here:
 /tools/i686/lib/gcc/avr/4.1.0/include
 /tools/i686/lib/gcc/avr/4.1.0/../../../../avr/include
End of search list.
GNU C++ version 4.1.0 (avr)
        compiled by GNU C version 3.2.3 20030502 (Red Hat Linux 3.2.3-49).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: e56ae0f62a848350ccb9716b24fc3bd9
 /tools/i686/lib/gcc/avr/4.1.0/../../../../avr/bin/as -o /tmp/ccyX7jFq.o
/tmp/cc7jbBxg.s
 /tools/i686/lib/gcc/avr/4.1.0/../../../../avr/bin/ld -m avr2
/tools/i686/lib/gcc/avr/4.1.0/../../../../avr/lib/crts8515.o
-L/tools/i686/lib/gcc/avr/4.1.0
-L/tools/i686/lib/gcc/avr/4.1.0/../../../../avr/lib /tmp/ccyX7jFq.o -lgcc -lc
-lgcc

Using avr-g++ instead of avr-gcc:

% avr-g++ -v foo.cc
Using built-in specs.
Target: avr
Configured with: ./configure --prefix=/tools/i686 --target=avr --disable-libssp
--with-dwarf2
Thread model: single
gcc version 4.1.0
 /tools/i686/libexec/gcc/avr/4.1.0/cc1plus -quiet -v foo.cc -quiet -dumpbase
foo.cc -auxbase foo -version -fno-rtti -fno-enforce-eh-specs -fno-exceptions -o
/tmp/ccbXCZLa.s
ignoring nonexistent directory
"/tools/i686/lib/gcc/avr/4.1.0/../../../../include/c++/4.1.0"
ignoring nonexistent directory
"/tools/i686/lib/gcc/avr/4.1.0/../../../../include/c++/4.1.0/avr"
ignoring nonexistent directory
"/tools/i686/lib/gcc/avr/4.1.0/../../../../include/c++/4.1.0/backward"
ignoring nonexistent directory
"/tools/i686/lib/gcc/avr/4.1.0/../../../../avr/sys-include"
#include "..." search starts here:
#include <...> search starts here:
 /tools/i686/lib/gcc/avr/4.1.0/include
 /tools/i686/lib/gcc/avr/4.1.0/../../../../avr/include
End of search list.
GNU C++ version 4.1.0 (avr)
        compiled by GNU C version 3.2.3 20030502 (Red Hat Linux 3.2.3-49).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: e56ae0f62a848350ccb9716b24fc3bd9
 /tools/i686/lib/gcc/avr/4.1.0/../../../../avr/bin/as -o /tmp/ccSHVtCa.o
/tmp/ccbXCZLa.s
 /tools/i686/lib/gcc/avr/4.1.0/../../../../avr/bin/ld -m avr2
/tools/i686/lib/gcc/avr/4.1.0/../../../../avr/lib/crts8515.o
-L/tools/i686/lib/gcc/avr/4.1.0
-L/tools/i686/lib/gcc/avr/4.1.0/../../../../avr/lib /tmp/ccSHVtCa.o -lgcc -lm
-lgcc -lc -lgcc


-- 
           Summary: Call to -lgcc added prior to user libraries
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: j at uriah dot heep dot sax dot de
  GCC host triplet: *-*-*
GCC target triplet: avr-*-*


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28718

[Bug c++/28718] Call to -lgcc added prior to user libraries

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2006-08-14 13:18 -------
Wait the user did say to link against -lm anyways.  This comes from the specs. 
What kind of wrong math functions are being used anyways?  If soft-fp, then you
are to think you can override them in libm.a because that is not the job of
libm.a.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28718

[Bug c++/28718] Call to -lgcc added prior to user libraries

[j at uriah dot heep dot sax dot de]

------- Comment #2 from j at uriah dot heep dot sax dot de  2006-08-14 14:13 -------
I know that the current situation for the AVR is suboptimal, there really
are overrides in libm.a for functions that are already present in libgcc.a.
However, this is not so easy to change for a number of logistical reasons
(the functions in question are highly tied into the remaining FP library
framework, but they offer much more optimal code for the user).

However, the main question here is: shouldn't all user-supplied -lXXX options
*always* be processed before any internally added -lgcc options, and why is
the behaviour different when the user calls the compiler "avr-g++" rather
than "avr-gcc"?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28718

[Bug c++/28718] Call to -lgcc added prior to user libraries

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2006-08-14 14:15 -------
-lm was not an user supplied option as shown by your commands.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28718

[Bug c++/28718] Call to -lgcc added prior to user libraries

[j at uriah dot heep dot sax dot de]

------- Comment #4 from j at uriah dot heep dot sax dot de  2006-08-14 14:28 -------
(In reply to comment #3)
> -lm was not an user supplied option as shown by your commands.
>

Oh no, sorry for the confusion: it *is* a user-supplied library.

Sorry, I now see that I somehow copy&pasted the wrong sequence. :-(

OK, here's the essence again, now with the correct commands:

% avr-gcc -v foo.cc -lm
...
/tools/i686/lib/gcc/avr/4.1.0/../../../../avr/bin/ld [...] /tmp/cc6mvtc6.o -lm
-lgcc -lc -lgcc

% avr-g++ -v foo.cc -lm
...
/tools/i686/lib/gcc/avr/4.1.0/../../../../avr/bin/ld [...] /tmp/cck5jSBR.o
-lgcc -lm -lgcc -lc -lgcc

I hope that makes my question clearer now.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28718

[Bug c++/28718] Call to -lgcc added prior to user libraries

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2006-08-15 18:24 -------
Also libm is not supposed to be overriding stuff in libgcc really, it is only
supposed to be including the C math functions.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28718

[Bug c++/28718] Call to -lgcc added prior to user libraries

[bjoern dot m dot haase at web dot de]

------- Comment #6 from bjoern dot m dot haase at web dot de  2006-09-06 16:51 -------
To clear up the issues.

1.) libgcc provides a fp emulation based on compiled c functions that is to my
very best knowledge untested for avr and extremely inefficient.
2.) avr-libc provides fp emulation that is hand-tuned assembly and on a less
restrictive license than GPL. IIRC, the person who wrote them is no longer
active in the field.
3.) the functions supplied by avr-libc are as basic as "single float add 3",
"single float multiply 3", "single float convert to integer 2" ...
4.) the hand-tuned assembly routines should really replace the libgcc ones, but
that's not easily feasible. Partly due to licensing issues (modified free bsd
for avr-libc), partly because it is very very difficult for us developers to
get code integrated into mainline gcc.
5.) the externally supplied functions in libm need the hand-tuned assembly
versions in order to operate properly and will failed with the untested libgcc
variants.
5.) There is only one single libc and libm implementation available for avr
that cooperates with gcc: avr-libc.

The suggestion of Joerg Wunsch is, thus, in line with the needs of gcc users
for the avr target.

Bjoern.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28718

[Bug c++/28718] Call to -lgcc added prior to user libraries

[pinskia at gcc dot gnu dot org]

------- Comment #7 from pinskia at gcc dot gnu dot org  2006-09-12 08:06 -------
(In reply to comment #6)
> The suggestion of Joerg Wunsch is, thus, in line with the needs of gcc users
> for the avr target.
But not in the line with the rest of GCC.  Really if you cannot get a patch
applied to GCC, there is a maintainer problem with the avr target inside GCC. 
And second GCC's soft-fp should be correct indepdent of the libc.
So this is not a bug.  Also if libm is only the normal math library and should
not include the soft-fp but those should be in libgcc as they are support
functions needed for GCC to work even without a libc.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28718

[Bug c++/28718] Call to -lgcc added prior to user libraries

[j at uriah dot heep dot sax dot de]

------- Comment #8 from j at uriah dot heep dot sax dot de  2006-09-12 08:52 -------
(In reply to comment #7)

> So this is not a bug.  Also if libm is only the normal math library and should
> not include the soft-fp but those should be in libgcc as they are support
> functions needed for GCC to work even without a libc.

The bug is that libstdc++ (in our case: libgcc, as the AVR implementation
doesn't have a libstdc++) and libm are linked *before* any user-supplied
-l options in C++ mode.  This doesn't happen in C mode.  This also happens
for non-AVR targets, so it appears to be a generic bug to me.

This is violating the principle of least astonishment at least.

The AVR user can for sure live (by now) with the artefacts caused by there
not-really-GCC-standard libm.a implementation, as long as they've got
reasonable control about when the GCC-internal libraries are getting
linked in (so the user always gets a chance to override).


-- 

j at uriah dot heep dot sax dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28718

[Bug driver/28718] Call to -lgcc added prior to user libraries

[abnikant dot singh at atmel dot com]

------- Comment #9 from abnikant dot singh at atmel dot com  2009-08-19 15:32 -------
This is because libstdc++ is not build in case of avr(8 bit),I did check it in
avr32 there I get flags in the sequence : -lstdc++ -lm -lgcc


-- 

abnikant dot singh at atmel dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |abnikant dot singh at atmel
                   |                            |dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28718