[cfe-commits] r133450 - in /cfe/trunk: lib/CodeGen/CodeGenModule.cpp lib/Sema/SemaDecl.cpp test/CodeGen/attr-weak-import.c

jahanian fjahanian at apple.com
Wed Jun 22 15:15:42 PDT 2011

On Jun 22, 2011, at 1:58 PM, Douglas Gregor wrote:

> On Jun 20, 2011, at 10:50 AM, Fariborz Jahanian wrote:
>> Author: fjahanian
>> Date: Mon Jun 20 12:50:03 2011
>> New Revision: 133450
> This is really unfortunate, because it's intended that a declaration's linkage is an invariant in the AST. We don't depend on weak vs. non-weak so much in semantic analysis, so it's not as damaging as changing internal vs. external linkage would be, but it still causes weird breakage. For example, note how lib/AST/ExprConstant.cpp's EvalPointerValueAsBool checks for weak imports: this routine will now return different results in different parts of the translation unit, if we end up trying to evaluate the address of a variable after the first declaration and then again after it's had weak_import attribute added to it.
> I know we're mimicking GCC behavior here, but I think this is a GCC bug that we should not emulate. Instead, we should complain (via a warning) that an already-declared variable cannot be made a weak_import in a subsequent declaration, and drop the WeakImportAttr from the later declaration. The motivating Radar refers to "an obscure linker test", so it's unlikely that any real code will be affected (and the warning makes sure that there's no silent breakage). 
> What do you think?

In r133654. Please read the comment in code and let me know what you think.

- Thanks, Fariborz

> 	- Doug

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20110622/a8b0e002/attachment.html>

More information about the cfe-commits mailing list