[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
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