> On Jan 23, 2015, at 9:25 AM, David Majnemer <[email protected]> wrote:
>
> On Fri, Jan 23, 2015 at 12:25 AM, John McCall <[email protected]
> <mailto:[email protected]>> wrote:
> > On Jan 22, 2015, at 4:52 PM, Rafael Espíndola <[email protected]
> > <mailto:[email protected]>> 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.
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
