> On Jan 23, 2015, at 5:43 AM, Rafael Espíndola <[email protected]>
> wrote:
> On 23 January 2015 at 03:25, 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.
>
>
> Not sure if that is viable fight on our side, but we can try making it an
> error and see.
How is it not a viable fight? Is the section attribute coming from a
completely different place? Or are you suggesting that it is never viable to
tell people that they ought to fix their code, no matter how unnecessarily
perverse it is? A section should be an intrinsic part of an definition, saying
that you can’t define the same thing in multiple inconsistent ways is not even
slightly unreasonable.
> 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.
>
> So, the case in pr16187 is one where I think there is no question that our
> answer is worse than gcc's. The *same* type shows up as both hidden and
> default. If this was a new language we were designing, it is hard to imagine
> a worse compromise.
>
> The reason we got there is that we tried and failed to enforce a stricter
> models. First one that says that we can compute the type early and then one
> that says we can compute it on first "use". Both have failed to build real
> world software, which IMHO is a fundamental requirement for clang.
“Build everything GCC can without modification” has never been a fundamental
requirement for clang, though, and that appears to be your standard.
PR16187 is an example that I would feel fairly comfortable diagnosing. You
could certainly construct a more challenging example, though.
> The case of "typedef struct {...} foo;" doesn't look as widespread, but it is
> unfortunately a core part of the language (not a gcc extension) that we
> cannot currently implement.
You’ll need to remind me what it is that we can’t implement here.
Also, I don’t think there’s ever a case where we initiate IRGen during the
parsing of a top-level declaration (we even take this to unnecessary extremes,
e.g. with namespaces), and if there is, it should not be too difficult to avoid
doing so.
John.
> 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.
>
> An interesting language design advice, but given the requirement that clang
> continues to build real c++ code, it is important to ask if we are not
> pushing ourselves to solutions that are worse than what gcc does (which I am
> sure is the case in pr16187).
>
> Cheers,
> Rafael
>
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
