Re: Anonymous Namespaces

[Chris Lattner <sabre at nondot dot org>]

On 1 Feb 2004, Gabriel Dos Reis wrote:

> Chris Lattner <sabre@nondot.org> writes:
>
> | On 1 Feb 2004, Gabriel Dos Reis wrote:
> |
> | > Chris Lattner <sabre@nondot.org> writes:
> | > | The "right" solution I mention above, would involve the C++ parser setting
> | > | TREE_PUBLIC to false for entities in anonymous namespaces, and using some
> | > | other (C++ specific) flag to control name lookup functions.  I am guessing
> | > | that this is unlikely to fly though, because it would require changing
> | > | more of the C++ front-end.  As such, I am specifically not suggesting
> | > | this.
> | >
> | > Ahem.
> |
> | What does 'ahem' mean?
>
> I asked:
>
>    So, exactly what are you suggesting with respect to the "unnamed
>    namespace" as far as GCC is concerned?
>
> You went on a very loooong story, only to conclude that
>
>    As such, I am specifically not suggesting  this.
>
> "Ahem" was an elliptic interjection for: Okaayyy, what do you suggest then?!?

I was suggesting my first proposed solution to it, not to the "right"
solution I proposed, which you quoted.

> You went on a very loooong story,

Sorry for being verbose: before that you didn't "get" it.

> | What are you talking about?  LLVM?  LLVM has no bearing on the description
> | I just gave!
>
> I'm talking about your use of "internal linkage".

I'm sorry if I'm confusing in that respect, I will try to be extremely
clear what I mean in the future, especially when terminology means
different things in different contexts.

> What if you take it granted that what LLVM does
> is the last of my preoccupations as far as GCC is concerned?  I'm

Actually, I would prefer that.  This conversation started out with me
explaining what we did in LLVM, and as such, LLVMisms crept in.  Sorry.

> | > | > So, the question is what are you transforming according to what
> | > | > semantics and what are you demonstrating?
> | > |
> | > | The point is that what LLVM does is irrelevant to this discussion, as GCC
> | > | is not LLVM.
> | >
> | > Oh, really, I would have sweared the contrary :-}
> |
> | I'm not really sure what you're getting at here.  LLVM has, as one
>
> Just pointing out some of your self-contradictory positions that make
> it very hard to see where you're driving at -- no mentioning standard
> phrase transmutation.  If what LLVM does has nothing to do with this
> discussion, why did you bring it into the picture in the first place?

As explained above, my involvement in the thread started out by telling
you that we do implement this in the LLVM version of G++, and I tried to
explain how we did it.  In the example you quoted above, you specifically
made a comment about LLVM, so I responded.  Note that the comment (and the
response) really had nothing to do with the thread, so I can't see how it
would confuse you.

> I'm pretty sure, it has something to do with the discussion, but I
> suspect that some laws about flip-flop ought to be respected, which I
> guess might explain why you flip-flop :-/

I am perfectly willing to leave LLVM out of this.  The whole point of me
getting involved with the thread is to make GCC not do stupid things with
an idiom that I commonly use.  Specifically, you have shot this down as
impossible in the past and I haven't said anything, so I figured that it
would get shot down again unless I did.  The fact that LLVM already
performs these optimizations is secondary to the discussion.

> | >   > Yes. The second phase of two-phase name lookup ignores functions with
> | >   > internal linkages.  Also, entities with internal linkage cannot be
> | >   > used as template arguments.
> | >
> | >   With the LLVM G++ front-end, all entities declared in an anonymous
> | >   namespace are emitted with internal linkage, including any related RTTI
> | >   info, vtables, etc.
> |
> | I don't understand what you're saying here.
>
> The last tree lines are your words.

Ah, that definitely was not clear.

> You were supposed to reply to the nested quote -- which specifically was
> talking about interaction between intenal linkage and name lookup.  You
> brought what "LLVM does" in the discussion, in a context where you were
> using "internal linkage" with a totally different meaning.

I'm sorry.  I thought it was clear that a C++ front-end does not emit C++
code (it parses it).  Thus if it _emits_ an entity with internal linkage,
that would mean that, in this case, the generated LLVM code would have the
object marked internal.  If this were a standard G++, the emitted object
would not have external linkage, same thing.  I don't think that this was
ambiguous, but I can see how it could be confusing.

> In other circumstances, I owuld have characterized it as fraud.

That's lovely but I have no idea what it has to do with this thread.

So, finally, to clear this mess up, do you acknowledge that this is
possible to implement in GCC (and in fact, should not be hard)?  Like
Kevin, I would really like to see this go into 3.4, but I would understand
if it only made it into 3.4.1.  As I have no copyright assignment on file,
I cannot implement this.  Would you be willing to do it?

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/