[llvm-commits] [llvm-gcc-4.2] r71287 - in /llvm-gcc-4.2/trunk: build_gcc gcc/ChangeLog.apple gcc/config/arm/arm.c gcc/cp/mangle.c gcc/objc/ChangeLog.apple gcc/objc/objc-act.c gcc/testsuite/ChangeLog.apple gcc/testsuite/g++.apple/anon-1.C gcc/testsuite/gcc.apple/weak.c gcc/testsuite/objc.dg/property-16.m gcc/tree-eh.c gcc/version.c

Duncan Sands baldrick at free.fr
Mon May 11 00:18:31 PDT 2009


On Monday 11 May 2009 08:58:01 am Mike Stump wrote:
> On May 8, 2009, at 11:37 PM, Duncan Sands wrote:
> >> +      /* APPLE LOCAL begin weak variables 6822086 */
> >> +    case VAR_DECL:
> >> +      /* Assume that weak variables may trap.  */
> >> +      if (DECL_WEAK (expr))
> >> +	return true;
> >> +      return false;
> >> +      /* APPLE LOCAL end weak variables 6822086 */
> >
> > shouldn't this only be needed for weak references
> > (gets turned into ExternalWeakLinkage in LLVM)?
> I don't know why that would be the case.  Also, chosen for symmetry  
> with the case just before it.  I don't see why one can't have a weak  
> definition that winds up not being used that turns out to be not  
> defined as runtime, thus, being 0.  Anything prevent that case?

isn't that exactly what ExternalWeakLinkage is about?  A variable that
ends up with WeakLinkage in LLVM is always defined.  The definition may
change at link time, but it always has one.  Its address is non-null.
On the other hand a variable with ExternalWeakLinkage may never get a
definition at all, and its address will be null if it is never defined.
I'm not sure what this trapping logic is about exactly, but I guessed
it was referring to this last case.  If so, that means that returning
"true" for anything with DECL_WEAK set is not wrong, but suboptimal.



More information about the llvm-commits mailing list