This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][RFH] (3/3) Vectorize some builtins on x86_64 by using libgcc-math

On Fri, 17 Nov 2006, Joseph S. Myers wrote:

> On Fri, 17 Nov 2006, Paolo Bonzini wrote:
> > 
> > > If this is a shared library, then the link command line (generated by gcc
> > > when linking with -ftree-vectorize) should at least use --as-needed
> > > -lgcc-math --no-as-needed (if USE_LD_AS_NEEDED) to avoid dependencies on
> > > libgcc-math for programs that don't in fact need it.
> > >   
> > 
> > This would still require libgcc-math.a to be present in order to do the
> > linking, right?
> Yes.  If the compiler is configured with libgcc-math then it should know 
> to link against it.  If not, it should know not to try linking against it.

It uses --as-needed -lgcc-math --no-as-needed, see this hunk of the patch:

Index: config/i386/linux64.h
*** config/i386/linux64.h       (revision 118884)
--- config/i386/linux64.h       (working copy)
*************** Boston, MA 02110-1301, USA.  */
*** 74,79 ****
--- 74,86 ----
        %{" SPEC_64 ":%{!dynamic-linker:-dynamic-linker " 

+ #undef  LIB_SPEC
+ #define LIB_SPEC \
+   "%{pthread:-lpthread} \
+    %{shared:-lc} \
+    %{!shared:%{mieee-fp:-lieee} %{profile:-lc_p}%{!profile:-lc}} \
+    %{ftree-vectorize:--as-needed -lgcc-math --no-as-needed}"
  /* Similar to standard Linux, but adding -ffast-math support.  */
  #undef  ENDFILE_SPEC
  #define ENDFILE_SPEC \

(I'm just assuming that all linux64 targets have --as-needed support here)

> > OTOH, it would not need to be connected to -ftree-vectorize, but it could be
> > in the default target specs for targets that have --as-needed.
> Indeed, not needing -ftree-vectorize at link time would be better.

I tried to do this, but didn't find a suitable place to handle an extra
library like this in the specs.  libgcc handling seems to be very special
and libgcc-math would be similar here.  On the other hand, adding a
library conditional on a flag was simple...

(hints appreciated - though enabling it globally still needs to solve
the problem of linking in the testsuites where I didn't spot the place
we handle libgcc specially, we just seem to assume it's placed where
the backends live - until toplevel libgcc will hit us)


Richard Guenther <>
Novell / SUSE Labs

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]