This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/20717] [4.1 Regression] Many C++ testsuite failures on ia64-hpux
- From: "wilson at specifixinc dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 5 Apr 2005 19:44:13 -0000
- Subject: [Bug target/20717] [4.1 Regression] Many C++ testsuite failures on ia64-hpux
- References: <20050401163650.20717.jsm28@gcc.gnu.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From wilson at specifixinc dot com 2005-04-05 19:44 -------
Subject: Re: [4.1 Regression] Many C++ testsuite failures
on ia64-hpux
jh at suse dot cz wrote:
> This sounds like reason for the failure. What precisely is the
> behaviour of FDESC_ADDR? (ie should I behave same way as if I see
> ADDR_EXPR - assume that address of the function has been taken and thus
> it is neccesary?).
On IA-64, the address of a function is a two-word function descriptor,
one word is the function entry point, and one word is the function's gp
value. FDESC_EXPR is used to represent this. FDESC_EXPR must be used
in places where the difference matters, e.g. in initializers for
vtables. According to the docs in tree.def, operand0 of FDESC_EXPR is
always a function, so it should be possible to handle FDESC_EXPR exactly
the same as ADDR_EXPR if you don't care about the difference. That is
what the untested patch I added to the PR does. It seems to work for
the testcase. There is also the question of whether there are other
places that need the same fix. I haven't looked.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20717