Re: Anonymous Namespaces

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Chris Lattner <sabre@nondot.org> writes:

| Fine, again, _when_ this is an issue, it can be dealt with.

An issue *where*?  A suggestion has been to modify GCC in a way  that
will make it reject valid programs.  I've pointed out why that
modification is not correct and suggested alternative.  And I think
the C++ maintainers understand the issue enough to see the point.

| > | That is exactly what I'm talking about.  I'm very confused here.  In LLVM,
| > | the source-level notion of internal linkage is very different from the
| > | LLVM notion of internal linkage.
| >
| > But then use a difference terminology if you don't want to confuse
| > yourself  (or a C++ programmer talking with you).  A C++ programmer knows
| > what "static" and "internal linkage" means in C++.  If you change
| > those phrases to mean something different from what they do in a C++
| > programme source, you better accurately state their meanings.  Using a
| > different word is far better.
| 
| I'm sorry, but I'm not confused.  The LLVM notion of internal linkage is
| the standard one, and corresponds exactly to what the 'static' keyword
| does at global scope.

There is no distinction between "static" at global scope or at any
other namespace scope. And replacing "being declared in an unnamed
space" with "being declared as static" (with static meaning what is
means in C and C++), changes the meaning of well-defined programs.

If your notion of internal linkage corresponds to the meaning of
static, then why did you state:

   In LLVM, the source-level notion of internal linkage is very
   different from the LLVM notion of internal linkage.

?

You've gotten a consistency problem to revolve with yourself.


| Unnamed namespaces are NOT the same as internal linkage, but can be
| transformed to be implemented in terms of it in this  case.

"In this case" meaning precisely?  I've provided sufficient details
showing in which ways the two notions differ and affect the meaning of
programs.

[...]

| > |  For example, if a (nonvirtual) method is only called from one
| > | call site, and its class is in an anonymous namespace, it _should be
| > | inlined_ into that call site, (almost) regardless of how big it is.
| > | There are many other examples of this kind of thing.  How do you achieve
| > | this without anonymous namespaces behaving sanely?
| >
| > But an unnamed namespace does not guarantee that an entity defined in it
| > does not escape!  See the example above.
| 
| Again, you are confusing notions in the C++ front-end with notions in the
| optimizer/code generator.

No, I'm confusing nothing. 

However, you are confuse many distinct things.  (And last time, you
have a discussion with someone on linkage, you did the same).
 
| > | Transforming objects in unnamed namespaces to use LLVM internal linkage
| > | cannot cause any regressions from an unmodified G++ front-end.  In the
| > | future, the addition of export may not make this true, but if so, it can
| > | be dealt with then.  Also, it does not appear to me that export will be
| > | added to g++ anytime in the near future.  I find it ridiculous that you
| > | advocate non-LLVM G++ to generate pessimal code in the meantime.
| >
| > What is ridiculous is you not understanding how unnamed namespace and
| > C++ name lookup rules work and saying I'm ridiculous when I'm telling
| > you that your statement does not match C++ rules -- not mentioning your
| > use of "static" and "internal linkage" in totally different and
| > undefined way.
| 
| When you made this statement, you were confused.  If you still are,
| please reask, and I will respond.
| 
| > You're free to implement whatever you like in your research compiler.
| 
| *sigh*, LLVM's goals are for it to be as stable and reliable as a
| commercial grade compiler, not for it to be "research quality".  Please do

You're confused.  I did not say "research quality".  I said
"research compiler".

And stating a goal is one thing.  What happens in reality is another.
Sometimes, they match, sometimes they don't.

| not sling insults unless you've _actually tried it out_.  Thanks.  In

It is an insult in your mind only after you managed to read "reaserch
compiler" as "research quality".

| fact, I think if you did, you would find it optimizes C++ programs
| _substantially_ better than GCC does, and takes less time to do so.  Your
| example is just one case, there are many others.

You're confused.  My example is not about how fast is the compiler,
rather how correct it is.  As I said, if the only thing you measure is
speed, then you may not get the point.

| > What, however, is not correct is your using "static" and "internal
| > linkage" in very sneaky ways to mean totally different things in a
| > discussion where people are already confused about the semantics of
| > unnamed namespaces and static.
| 
| Uh, okay... I did not realize I was being sneaky!
| 
| > And, I'm not advocating people generate pessimal code.  I'm telling
| > people that they should teach the inliner about unnamed namespaces
| > instead of transmuting meanings of well-defined codes.
| 
| Again, as I said before, the inliner is not the only thing that cares,
| please read the examples I gave in my previous email.

I did read them and even give a description of what you after (which
is not static).

-- Gaby