* #pragma redefine_extname and local declarations
@ 2004-09-21 3:34 Mark Mitchell
2004-09-21 16:11 ` Joseph S. Myers
0 siblings, 1 reply; 3+ messages in thread
From: Mark Mitchell @ 2004-09-21 3:34 UTC (permalink / raw)
To: zack; +Cc: gcc, Joseph S. Myers
Joseph, Zack --
Given:
#pragma redefine_extname f g
int main () {
extern int f();
f();
}
we do not rename "f" to "g". Perhaps even more dramatic is the case
where there is no declaration of "f" at all; because that results in an
implicit local declarations we get the same behavior.
This did not work in GCC 3.4 either, so I don't think it had anything to
do with Zack's changes to redefine_extname in GCC 4.0. But, I'd be
curious as to whether or not you think that this behavior is as
desired. If you don't think this is the desired behavior, then perhaps
we should be calling maybe_apply_renaming_pragma more often -- after
every function declaration with external linkage in finish_decl, rather
than just those with global scope.
Thoughts?
--
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: #pragma redefine_extname and local declarations
2004-09-21 3:34 #pragma redefine_extname and local declarations Mark Mitchell
@ 2004-09-21 16:11 ` Joseph S. Myers
2004-09-22 4:34 ` Mark Mitchell
0 siblings, 1 reply; 3+ messages in thread
From: Joseph S. Myers @ 2004-09-21 16:11 UTC (permalink / raw)
To: Mark Mitchell; +Cc: zack, gcc
On Mon, 20 Sep 2004, Mark Mitchell wrote:
> This did not work in GCC 3.4 either, so I don't think it had anything to do
> with Zack's changes to redefine_extname in GCC 4.0. But, I'd be curious as to
> whether or not you think that this behavior is as desired. If you don't think
> this is the desired behavior, then perhaps we should be calling
> maybe_apply_renaming_pragma more often -- after every function declaration
> with external linkage in finish_decl, rather than just those with global
> scope.
I think the pragma should apply to all external function declarations (and
this should probably be the case for extern_prefix as well), explicit and
implicit. This also appears to be what the Solaris 9 compiler does.
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
http://www.srcf.ucam.org/~jsm28/gcc/#c90status - status of C90 for GCC 4.0
jsm@polyomino.org.uk (personal mail)
jsm28@gcc.gnu.org (Bugzilla assignments and CCs)
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: #pragma redefine_extname and local declarations
2004-09-21 16:11 ` Joseph S. Myers
@ 2004-09-22 4:34 ` Mark Mitchell
0 siblings, 0 replies; 3+ messages in thread
From: Mark Mitchell @ 2004-09-22 4:34 UTC (permalink / raw)
To: Joseph S. Myers; +Cc: zack, gcc
Joseph S. Myers wrote:
>On Mon, 20 Sep 2004, Mark Mitchell wrote:
>
>
>
>>This did not work in GCC 3.4 either, so I don't think it had anything to do
>>with Zack's changes to redefine_extname in GCC 4.0. But, I'd be curious as to
>>whether or not you think that this behavior is as desired. If you don't think
>>this is the desired behavior, then perhaps we should be calling
>>maybe_apply_renaming_pragma more often -- after every function declaration
>>with external linkage in finish_decl, rather than just those with global
>>scope.
>>
>>
>
>I think the pragma should apply to all external function declarations (and
>this should probably be the case for extern_prefix as well), explicit and
>implicit. This also appears to be what the Solaris 9 compiler does.
>
>
Indeed. I am testing a patch to fix this bug.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2004-09-21 22:36 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-09-21 3:34 #pragma redefine_extname and local declarations Mark Mitchell
2004-09-21 16:11 ` Joseph S. Myers
2004-09-22 4:34 ` Mark Mitchell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).