I don't know if this ever has an effect on an output of gcc(are C variable names ever different from C++ ones?), but there are two different trees which should be equal: example1: extern "C"{ extern int a; } extern "C"{ int a; } example2: extern "C"{ extern int a; } int a; those should be equal I think, but "a" is not DECL_EXTERN_C_P for example2. if "a" is a function it is DECL_EXTERN_C_P in both examples.
I don't know if there is a bug here or not. But note normal variables in the global namespace are not mangled either.
Also the only use of DECL_EXTERN_C_P for variable decls is when mangling (this is unlike functions). So what are you trying to do here? I would suspect there is a bug, but a very latent bug which does not show up in the normaling compiling of things.
I totally agree that this is not important. I just don't know gcc good enough to forecast the possible effects of that minor bug so I thought it'd be interesting. please close the bug if you are sure it doesn't have any effects on compilation.
(In reply to comment #3) Or might it be nearly just as easy to place all in the same tree initially, and eliminate the potential ambiguity now that it's been identified?
I think I was wrong, this is a bug _and_ has effects on compilation: in example2(see above) int a is not extern "C" in the tree, AND it is C++ mangled in compiler output! std 7.5.7 states that a once declared extern "C" function is extern "C" even if defined without linkage specification. I can't find the same for variables, but since this is a redeclaration that must be the true: extern "C"{ extern int a; } int a; extern "C"{ int a; } I've attached a simple test case. link it and you'll get an undefined reference to "a".
Created attachment 8111 [details] reference to a in c.c shouldn't be undefined
Actually the code is invalid, see PR 6548 which this is a dup of. *** This bug has been marked as a duplicate of 6548 ***