[patch][pr22217] Use the most recent decl for mangling

[John McCall]

> On Jan 23, 2015, at 9:25 AM, David Majnemer <david.majnemer at gmail.com> wrote:
> 
> On Fri, Jan 23, 2015 at 12:25 AM, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> wrote:
> > On Jan 22, 2015, at 4:52 PM, Rafael Espíndola <rafael.espindola at gmail.com <mailto:rafael.espindola at gmail.com>> wrote:
> >
> > Sent the email a bit early.
> >
> >
> >>> That is not what I am seeing with gcc. Given
> >>>
> >>> int pr22217_foo;
> >>> int *b = &pr22217_foo;
> >>> extern int pr22217_foo __attribute__((section("zed")));
> 
> This should be an error in both C and C++.  I see absolutely no reason to allow a declaration following a definition (even a tentative definition) to add a section attribute.  We should not be afraid to reject stupidly-written code when it abuses language extensions, even when they’re not “our” extensions.
> 
> There are fair arguments against our current emit-as-you-go IRGen model, but allowing us to more perfectly emulate GCC’s bugs is not one of them.  Nor is there a need to exactly copy GCC’s visibility model in every conceivable case.  One very nice incidental advantage of emit-as-you-go is that it encourages us to ensure that language decisions are made locally by the declarations involved, which — beyond simply being better language design in and of itself — also means that they’re not susceptible to random breakage by differences in module import.
> 
> Some of my argument against eagerly emitting IR comes stems from how we handle the following:
> struct S;
> 
> typedef void (*FP)(struct S);
> 
> void f(FP x) { }
> 
> struct S { int i; };
> 
> void g() { f(0); }
> 
> When we are emitting f, we decide that FP should have IR type {}*.
> However, the definition of 'S' is available when we are emitting 'g' and so we decide that FP have IR type void (i32)*.
> 
> The fact that types change from under us is very surprising.

Global values changing types is, unfortunately, inevitable, because it is not currently possible to give a global variable an arbitrary IR type when it has a constant initializer, and global variables can have references to each other, even cyclically.  It is not actually difficult to deal with; it's good practice to hold persistent references with a value handle anyway.

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