This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [3.3 regression?] flag_hosted and back-ends
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Geoff Keating <geoffk at geoffk dot org>
- Cc: Richard dot Earnshaw at arm dot com, thorpej at wasabisystems dot com, gcc at gcc dot gnu dot org
- Date: Mon, 17 Mar 2003 10:13:55 +0000
- Subject: Re: [3.3 regression?] flag_hosted and back-ends
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
> > Date: Sat, 15 Mar 2003 13:27:17 +0000
> > From: Richard Earnshaw <rearnsha at arm dot com>
>
> > My inclination would be to say that taking the address of a nested
> > function should only be supported in a hosted environment, since it
> > requires OS support.
>
> I think you're redefining the word 'hosted' here in a confusing way.
>
> I would prefer to rephrase this as "nested functions should only be
> supported in environments that can support nested functions"... which
> is obviously correct.
>
But not very useful.
1) It's not nested functions per se that we can't support generically,
it's taking the address of one and passing it to a function that doesn't
know that the pointer is any different from an ordinary
pointer-to-function.
2) In some circumstances taking the address of a nested function requires
support from out-of-line routines which may involve a call into the OS.
> Of course, you don't need GCC changes to achieve this. In these
> environments, users will get a link error.
Sure, and that's precisely my point. We should document that taking the
address of a nested function may require library calls to support it, and
that if that is the case, then it may not work in a non-hosted environment.
R.