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