This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: IA64 HP-UX patch for C++ (Modified)
- From: Mike Stump <mrs at apple dot com>
- To: Steve Ellcey <sje at cup dot hp dot com>
- Cc: gcc-patches at gcc dot gnu dot org, rth at redhat dot com
- Date: Mon, 30 Sep 2002 12:45:37 -0700
- Subject: Re: IA64 HP-UX patch for C++ (Modified)
On Monday, September 30, 2002, at 10:17 AM, Steve Ellcey wrote:
This is a resubmit of an earlier patch and uses build_c_cast instead of
build1 on a change needed for the HP-UX 32 bit IA64 g++ compiler. I
also added a second change that I missed the first time to use
TARGET_VTABLE_DATA_ENTRY_DISTANCE instead of 1 in
add_vcall_offset_vtbl_entries_1. For other platforms this macro is set
to 1 by default and they will not be affected by this change.
So, I am wondering if we should use the new abi flag to select which
abi to compile for. If we do, what would mean that =0 would produce
code that would be compatible with some future version of the HP
compiler, and tm.h can choose an older version to be compatible with.
This also means that we should add space in the numbering scheme for
some important older versions, and that this type of code should key of
such of the abi flag directly. A bonus point is that if one if
interested in abi issues, they can M-x grep and find them all, easily.
I've started down the path of doing that for some code here. For
example, the old compiler instantiates rtti in each place it might be
needed, and newer compilers instantiate rtti along with the out of line
virtual, but, we have a feature whereby those types of names aren't
seen across dynamic lib boundaries and for our next release, we have to
be compatible with it. :-(
Thoughts?
Can I add some space between the numbers, even if we don't get such
hack-around for abi compatibility back in the the main compiler? I can
see if now, what do you mean you want compatibility with the 3.1
compiler, the first one we promised was 3.2... :-(