Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 9 Nov 2012 17:45:41 +0100
From:      Roman Divacky <rdivacky@freebsd.org>
To:        Steve Kargl <sgk@troutmask.apl.washington.edu>
Cc:        Konstantin Belousov <kostikbel@gmail.com>, freebsd-current@freebsd.org
Subject:   Re: clang and static linking?
Message-ID:  <20121109164541.GA34499@freebsd.org>
In-Reply-To: <20121109164304.GA61011@troutmask.apl.washington.edu>
References:  <20121108231349.GA79485@troutmask.apl.washington.edu> <20121108234932.GA56820@troutmask.apl.washington.edu> <20121109120012.GB73505@kib.kiev.ua> <20121109164304.GA61011@troutmask.apl.washington.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Nov 09, 2012 at 08:43:04AM -0800, Steve Kargl wrote:
> On Fri, Nov 09, 2012 at 02:00:12PM +0200, Konstantin Belousov wrote:
> > On Thu, Nov 08, 2012 at 03:49:32PM -0800, Steve Kargl wrote:
> > > 
> > > This appears to fix the problem.  Don't know if this is
> > > th right way to handle it.
> > > 
> > > Index: src/s_isnan.c
> > > ===================================================================
> > > --- src/s_isnan.c	(revision 242701)
> > > +++ src/s_isnan.c	(working copy)
> > > @@ -40,7 +40,6 @@
> >
> > Is this patch against src/msun ?
> 
> Yes.
> 
> > This is only a workaround, which break ABI and older binaries.
> 
> Which leads to an interest question.  With the major upheavel
> of switching to clang, are there any ABI breaking changes that
> would be desirable to commit?  This would entail a major library
> version bump.  For starters, libc/gen/isnan.c could be removed.
> 
> > The bug is apparently in clang, which inserts the undef reference
> > into the resulting object file, when weak alias references undefined
> > symbol. Gnu as does not have the bug.
> > 
> > There is some magic switch to reduce amount of clang bugs, like
> > -fno-integrated-as. Please try to compile the problematic .o with the
> > switch.
> 
> I'll try this shortly.  Does this mean that we need to build
> all *.a libraries where a weak reference may occur with this
> switch?

No, this has nothing to do with llvm integrated asm.

So far it looks like gcc always inline "isnan" even at O0 while
clang does not. We are trying to figure out the solution.

Maybe use __builtin_isnan instead of isnan in the isnan macro expansion?

Roman



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121109164541.GA34499>