This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Stricter semantics for renaming pragmas

Ian Lance Taylor <> writes:

>> 2) If #pragma extern_prefix is in effect and a declaration occurs with
>>    an __asm__ name, __asm__ wins.  No warning issues.
> Sounds reasonable (and is an exception to case 1 in that no warning is
> issued).
>> 3) If #pragma extern_prefix is in effect, all pending #pragma
>>    redefine_extname operations are ignored; a warning does issue.
> Sounds reasonable (and is implied by case 1).  Since the two #pragmas
> exist to support the system header files on two different systems, I
> don't think the semantics of using both of them together are very
> important.

These are not really exceptions to case 1.  #pragma extern_prefix is
different from the other two ways of renaming symbols - its effect is
"tack this string on the beginning of every external symbol name
declared from this point forward."  Case 2 is about

#pragma extern_prefix "__zork_"
extern void foo(void) __asm__("gribble");
  // symbol is "gribble", not "__zork_foo" or "__zork_gribble"

Case 3 is about 

#pragma extern_prefix "__zork"
#pragma redefine_extname foo gribble
extern void foo(void);

Now I think about it some more, though, I got case 3 backward;
redefine_extname should win in this case (same as asm()).

#pragma extern_prefix can hit case 1 with constructs like 

extern void foo(void);
#pragma extern_prefix "__zork_"
extern void foo(void);

... detecting that is going to be difficult, because of lazy
instantiation of DECL_ASSEMBLER_NAME, but it should be possible

>> 4) The "source name" for #pragma redefine_extname is the DECL_NAME,
>>    *not* the DECL_ASSEMBLER_NAME.  (Current code is inconsistent -
>>    it's the DECL_NAME if the #pragma occurs after the declaration, the
>>    DECL_ASSEMBLER_NAME if the #pragma occurs before the declaration.
> The #pragma is supposed to appear in the source code before the
> declaration.  It shouldn't be applied to declarations which appear
> before the #pragma.  I may misunderstand what you are saying.
> Applying to the DECL_NAME sounds right in any case.

GCC supports it in either order; the #pragma handler goes and looks
for a preexisting decl with that name (using identifier_global_value).

>> 5) In C++:
>> 5a) Applying __asm__("name") to a declaration silently makes it extern "C".
> Sounds right--that doesn't change the calling convention in any way,
> right?  It just changes the name.

That is my understanding, although Gabriel seems to think
differently... I would like to know exactly what he means by "it
affects types", ideally spelled out in simple terms with an example; I
am not a C++ guru.

>> 5b) #pragma redefine_extname is ignored, with a warning, if applied to
>>     a declaration which is not extern "C".
> I don't think this is right.  I think that this usage of #pragma
> redefine_extname ought to be like applying __asm__("name")--it should
> change the declaration to effectively be extern "C".
>> 5c) #pragma extern_prefix silently applies only to declarations which
>>     are extern "C".
> I don't think this is right either.  I think that it should apply to
> all external names, or at the very least it should issue a warning.

These may not be the abstract right things to do, but they are the
only things which will work.  Actually, it's worse - we can't even
warn about #pragma redefine_extname being applied to a declaration
which is not extern "C", not reliably.  The problem, in a nutshell,
is overloads.  Given

void foo(int);
void foo(float);
#pragma redefine_extname foo bar

(or the same thing with the pragma before the declarations) how do we
know which of _Z3fooi and _Z3foof is meant to be renamed, and what
should be the result?  "_Z3bar[if]"? "bar" (twice)?

The existing behavior of the above construct is that if the #pragma
comes after both declarations it's ignored because
identifier_global_value spits back an OVERLOAD node; if it comes
before both declarations it's ignored because neither of the
declarations has a bare "foo" for its DECL_ASSEMBLER_NAME (but you can
write "#pragma redefine_extname _Z3fooi bar" and get foo(int)
renamed); and if it comes *between* the declarations it silently
applies only to void foo(int).

I think this is a can of worms we do not want to open.  Much better to
avoid the entire problem and say "no, you don't get to use this stuff
except with extern "C" declarations" - where overloads cannot occur.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]