This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH]: Fix java failure and ada bootstrap failure
- From: Eric Botcazou <ebotcazou at libertysurf dot fr>
- To: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Sat, 8 Jan 2005 01:59:35 +0100
- Subject: Re: [PATCH]: Fix java failure and ada bootstrap failure
- References: <10501060220.AA06447@vlsi1.ultra.nyu.edu>
> Can you take a look at that for me if you get a chance?
Sure.
> It was passing at one point and something in the last few months broke it.
> I was sort of hoping it would go away as other code generation problems
> that showed up in the ACATS were fixed, but there aren't that many left, so
> it might be something unique to it. But I don't know the tasking RTS at
> all ...
There is a problem in s-tpobop.adb:PO_Service_Entries, specifically with:
Object.Entry_Bodies (
Object.Find_Body_Index (Object.Compiler_Info, E)).Action (
Object.Compiler_Info, Entry_Call.Uninterpreted_Data, E);
This indirect call gets compiled as
call *%ecx
on x86 and invokes c953002__main_po__e095bE.1014. Now this routine expects
%ecx to contain the static chain pointer on entry, so it passes a bogus
pointer to c953002__holding_pen__releaseP.1354, which in turns passes a bogus
pointer to system__tasking__protected_objects__entries__lock_entries, which
raises an exception.
With the 3.4.x compiler, the indirect call gets compiled as
call *%eax
and %ecx is loaded with the value right before the call.
I must say that I'm a bit puzzled at this point: how do we arrange for this to
work with the 3.4.x compiler? Do we trick every function in libgnarl into
thinking that they have child functions?
--
Eric Botcazou