RE: Trunk build failure on Itanium

["Boehm, Hans" <hans_boehm at hp dot com>]

I now have a patch of sorts for this in my tree, which I'd be happy to
share.  However, I'm not at all convinced it's optimal or even complete.
I've been waiting to post it, since it turns out there are a bunch of other
problems that prevent a complete IA64 build of the trunk:

- There's a problem with return_address_pointer_rtx, which I described in an
earlier message, and which was in fact also pointed out by another message
long before that.  I have a fix for this one which looks plausible to me.
(Split this into two rtx nodes, one of which points to the hard register,
and one of which points to the current save location.)

- Some C++ mangling confusion.  Names are marked with '@' for small data,
and '*' for explicit assembly names.  Some emd up prefixed with "@*", but
nothing is prepared for that.  The symptom is an "*" in an identifier name
in the .s file.  I have a patch which prevents "@*" from occuring, meaning
that some things don't end up in small data when they should.

- Unwind problems.  But I don't think that ever worked right.  I have
patches, but one of them is really ugly, and probably not yet right.

- A long double problem in building the C++ library.  I commented out that
part of the library for now.  Someone needs to look at it.

- Some Java-specific (?) problems I'm still tracking down.

I'd be more than happy to share what I have.

Hans

> -----Original Message-----
> From: Janis Johnson [mailto:janis187@us.ibm.com]
> Sent: Monday, August 13, 2001 4:17 PM
> To: gcc@gcc.gnu.org; hans_boehm@hp.com
> Subject: Re: Trunk build failure on Itanium
> 
> 
> Hans Boehm wrote on August 9, 2001:
> > I looked at this (see 
http://gcc.gnu.org/ml/gcc/2001-08/msg00555.html) a
> little bit more.
> 
> It appears that propagate_one_insn is trying to (erroneously I think)
delete
> the instruction that restores ar.pfs before a sibcall.  It correctly
notices
> the error because sibcall_epilogue_contains(insn) returns 1 . 
> 
> The preceding call to insn_dead_p returned true because pbi->reg_live
failed
> to include ar.pfs, even though it's considered live at the end of the
basic
> block.  I would guess that the liveness information for ar.pfs is no
longer
> propagated correctly through the sibcall?
> 
> Could someone who knows this code have a look at this, please?

> This problem has existed for at least a month.  Andrew Macleod started
> discussing possible fixes in gcc-patches and gcc-bugs on July 26, with
> feedback from Richard Henderson, but the last mail on the subject was
> August 1.  The problem still exists today.

> Janis