This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: C++ Issue on GCC 3.0 branch
- To: mark at codesourcery dot com, gcc at gcc dot gnu dot org
- Subject: Re: C++ Issue on GCC 3.0 branch
- From: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- Date: Sat, 28 Apr 2001 13:43:11 -0400 (EDT)
Forwarded message:
>From dave Sat Apr 28 13:36:47 EDT 2001
Subject: Re: C++ Issue on GCC 3.0 branch
To: law@redhat.com
Date: Sat, 28 Apr 2001 13:36:47 -0400 (EDT)
From: "John David Anglin" <dave@hiauly1>
In-Reply-To: <6087.988477036@slagheap.cygnus.com> from "law@redhat.com" at Apr 28, 2001 09:57:16 am
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 3844
> In message <200104272214.SAA06753@hiauly1.hia.nrc.ca>you write:
> > I think we need to define builtin_setjmp_receiver to restore r19. The
> > default exception method I believe is exceptions via longjmp, so we need
> > this. However, I have no idea whether or not this will fix the problem
> > with rethrow1.C.
> Yes, we probably need to restore %r19, but I'm 99.9 certain that's not the
> problem with the rethrow test since they fail with static libraries.
>
>
> > I also noticed a while back that exception_receiver uses a stack offset
> > of -32 to restore the pic offset table register. This won't work on
> > the 64-bit target. I think we should restore from the
> > PIC_OFFSET_TABLE_SAVE_RTX. However, we need to wait for it to be
> > initialized.
My test run with this revision is nearly complete. The good news is
that the gcc results with and without "-fPIC" are now identical (39
FAILS under hppa1.1-hp-hpux10.20).
The bad news is that there have been a few g++ regressions (total of
19 FAILS in g++ testsuite with -fPIC). I started looking at one of
them (cxa_vec.C) this morning. I am afraid that there are still problems
with respect to r19. In this particular case, I can see that the save
of r19 after various longjmp calls is being deleted in the jump pass.
The program has a segmentation call in the stub to call __start_cp_handler.
This is the calling code:
0x7ae94b20 <__cxa_vec_ctor+504>: bl 0x7ae9489c <__sjthrow>,rp
0x7ae94b24 <__cxa_vec_ctor+508>: stws r21,4(sr0,r20)
0x7ae94b28 <__cxa_vec_ctor+512>: bl 0x7ae948d4 <__start_cp_handler>,rp
0x7ae94b2c <__cxa_vec_ctor+516>: nop
0x7ae94b30 <__cxa_vec_ctor+520>: ldw -f8(sr0,sp),r19
As you can see, r19 isn't being restored after the call to __sjthrow.
The program dies here:
(gdb) run
Program received signal SIGSEGV, Segmentation fault0x7ae948d8 in __start_cp_handler ()
at ../../../../libstdc++-v3/libsupc++/vec.cc:130
(gdb) disass
0x7ae948d4 <__start_cp_handler>: addil 9000,r19
0x7ae948d8 <__start_cp_handler+4>: ldw -62c(sr0,r1),r21
(gdb) bt
#0 0x7ae948d8 in __start_cp_handler ()
at ../../../../libstdc++-v3/libsupc++/vec.cc:130
#1 0x7ae94b30 in __cxa_vec_ctor (array_address=0x40004874, element_count=5,
element_size=1, constructor=0x4000148a <DINFINITY+242>,
destructor=0x40001482 <DINFINITY+234>)
at ../../../../libstdc++-v3/libsupc++/vec.cc:149
nfo reg r1 r19
r1 4000a000
r19 40001000
Another slightly strange thing is that the longjmp calls are actual calls
to the library longjmp function. On the otherhand, we are using the
builtin version for sjlj exceptions. I wonder if it is a good idea to
be mixing the two.
I have looked at the placement of the pic offset table register save
in functions both with and without parameters. This seems ok. The above
problem seems to be a somewhat different problem although it still
involves the management of r19. Should I install the current patch
or wait until there is a solution to the above issue?
2001-04-27 John David Anglin <dave@hiauly1.hia.nrc.ca>
* pa.c (hppa_init_pic_save): Update last_parm_insn after emitting
pic save insn.
--- pa.c.orig Tue Apr 17 14:36:50 2001
+++ pa.c Fri Apr 27 14:11:02 2001
@@ -3359,7 +3359,8 @@
/* Emit the insn at the beginning of the function after the prologue. */
push_topmost_sequence ();
- emit_insn_after (insn, last_parm_insn ? last_parm_insn : get_insns ());
+ last_parm_insn =
+ emit_insn_after (insn, last_parm_insn ? last_parm_insn : get_insns ());
pop_topmost_sequence ();
}
It definitely is a major step forward even if it isn't the complete
solution.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)