This is the mail archive of the
mailing list for the GCC project.
Re: PATCH - Restore TREE_STATIC flag of previous decl when C99 6.2.7p2 rule is enforced.
- From: Andrew Pinski <apinski at apple dot com>
- To: mark at codesourcery dot com
- Cc: Andrew Pinski <apinski at apple dot com>, gcc-patches at gcc dot gnu dot org, Fariborz Jahanian <fjahanian at apple dot com>, Richard Henderson <rth at redhat dot com>
- Date: Wed, 12 Nov 2003 10:09:57 -0800
- Subject: Re: PATCH - Restore TREE_STATIC flag of previous decl when C99 6.2.7p2 rule is enforced.
- References: <FCC646FE-1532-11D8-96DA-000393B9ED88@apple.com> <firstname.lastname@example.org>
On Nov 12, 2003, at 9:08 AM, Mark Mitchell wrote:
Yes, I followed above documentation. Next question which I raised in
patch was what if back-end checks on this
flag to decide certain style of address generation? This is being done
in darwin.c as well as winnt.c. In my original test case,
this flag for the FUNCTION_DECL entry was unset (function not yet
defined), so address for function call is generated as relocatable.
Then this flag is set when C99 rule is enforced. So, I preserve the
flag (unset) on the original call so
proper stub is generated at the end. If I cannot do this, then I agree
with Richard that this flag should not be used in
darwin.c on a per function basis, as its final value is not known
the whole TU is seen.
In the medium term, we will go to unit-at-a-time mode, and then all
kind of information will be correct and complete by the time the back
end sees it.
Until that point, the Darwin back end should probably remember for
functions it needs to generate stubs and generate them at the end of
I do not think your patch to c-decl.c is appropriate, because it will
suboptimal in unit-at-a-time mode.
So my patch: <http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00327.html>,
(which was approved by Keating)
is the right thing to do?