This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch] Fix PR 21275, PR21597 cygwin/mingw32 bootstrap regressions on trunk
- From: Richard Henderson <rth at redhat dot com>
- To: dannysmith at users dot sourceforge dot net
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Christopher Faylor <me at cgf dot cx>, Gerrit Haase <gp at familiehaase dot de>
- Date: Wed, 3 Aug 2005 11:16:26 -0700
- Subject: Re: [Patch] Fix PR 21275, PR21597 cygwin/mingw32 bootstrap regressions on trunk
- References: <20050802085330.55806.qmail@web50904.mail.yahoo.com>
On Tue, Aug 02, 2005 at 08:53:29PM +1200, Danny Smith wrote:
> In varasm.c, uses the DECL_DLLIMPORT flag to test whether ADDR_EXPR's
> of both function and var decls are constant. I have removed
> the test for DECL_NON_ADDR_CONST_P/DECL_DLLIMPORT in tree.c:staticp
> (case VAR_DECL), since I have not been able to construct a testcase
> where this is necessary. Maybe I misunderstand what staticp means, but
> dllimported vars do have static storage -- it's just that we don't know
> their addresses until the library is loaded and the fixups to the import
> address table are made. If we do need to keep a test for
> DECL_DLLIMPORT in staticp, then we also need to treat dllimports like
> thread local variables in tree.c:recompute_tree_invarant_for_addr_expr.
Yes, I do think you misunderstand staticp. The fact that you don't
know the final address of a variable until after runtime relocation
is immaterial. The important point is that (1) it *is* resolved
before we actually begin execution and (2) it never changes afterward.
DLLIMPORT is no different from ELF dynamic relocation in this respect.
This differs from thread-local variables because TLS variables fail
test (2) above -- the value changes for every thread.
r~