This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH]: Fix java failure and ada bootstrap failure

> Can you take a look at that for me if you get a chance?


> 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]