| Message ID | 4C4420F2.5010807@codesourcery.com |
|---|---|
| State | New |
| Headers | show |
On 07/19/10 03:54, Bernd Schmidt wrote: > On 07/15/2010 07:13 PM, Bernd Schmidt wrote: > >> On 07/15/2010 12:28 AM, Jeff Law wrote: >> >>> On 07/14/10 15:30, Bernd Schmidt wrote: >>> >>>> If necessary I can try to test for a single insn with single_set and >>>> push it to the sequence otherwise. >>>> >>>> >>> For the mn103, the conversions were single insns... >>> >>> Ultimately, I think you have to peek at the insn(s) and see what >>> registers they set/clobber. >>> >> How's this? Bootstrapped and tested on i686-linux. ARM tests in progress. >> > This seems to have caused a bootstrap failure on hppa. A QImode value > is passed in a SImode reg and then should get extended to DImode; we > must make sure we use a qidi extension. The following patch does that; > I've not heard back whether it fixes the hppa bootstrap, but it seems to > work on arm-linux (one extra testsuite failure caused by an unrelated > change in the same tree). Also bootstrapped on i686-linux. Ok? > Assuming John confirms it fixes the PA failure. OK. jeff
On 07/19/2010 06:51 PM, Jeff Law wrote:
> Assuming John confirms it fixes the PA failure. OK.
Yeah, it didn't, and I think I missed a gen_lowpart in there anyway :-(
Now trying to do something with the compilefarm PA machine, although
I'm not sure it's a 64-bit one (is it?)
Bernd
On 07/19/2010 09:52 AM, Bernd Schmidt wrote: > On 07/19/2010 06:51 PM, Jeff Law wrote: >> Assuming John confirms it fixes the PA failure. OK. > > Yeah, it didn't, and I think I missed a gen_lowpart in there anyway :-( > Now trying to do something with the compilefarm PA machine, although > I'm not sure it's a 64-bit one (is it?) It's 64-bit hw running a 32-bit os, so... no, not really. r~
On 07/19/10 10:52, Bernd Schmidt wrote: > On 07/19/2010 06:51 PM, Jeff Law wrote: > >> Assuming John confirms it fixes the PA failure. OK. >> > Yeah, it didn't, and I think I missed a gen_lowpart in there anyway :-( > Now trying to do something with the compilefarm PA machine, although > I'm not sure it's a 64-bit one (is it?) > No clue. What does config.guess report? If it reports hppa2.0w, then it's running in 64bit mode. hppa2.0 is the same hardware running in 32bit mode. My hppa2.0w machine is extremely flakey; last I tried, I couldn't get it to run long enough to get through stage1, so I can't be much direct help. Jeff
Index: function.c =================================================================== --- function.c (revision 162277) +++ function.c (working copy) @@ -2940,18 +2940,18 @@ assign_parm_setup_reg (struct assign_par First, we try to emit an insn which performs the necessary conversion. We verify that this insn does not clobber any hard registers. */ - + enum machine_mode entry_mode = data->nominal_mode; enum insn_code icode; rtx op0, op1; - icode = can_extend_p (promoted_nominal_mode, data->passed_mode, + icode = can_extend_p (promoted_nominal_mode, entry_mode, unsignedp); op0 = parmreg; op1 = validated_mem; if (icode != CODE_FOR_nothing && insn_data[icode].operand[0].predicate (op0, promoted_nominal_mode) - && insn_data[icode].operand[1].predicate (op1, data->passed_mode)) + && insn_data[icode].operand[1].predicate (op1, entry_mode)) { enum rtx_code code = unsignedp ? ZERO_EXTEND : SIGN_EXTEND; rtx insn, insns; @@ -2959,7 +2959,7 @@ assign_parm_setup_reg (struct assign_par start_sequence (); insn = gen_extend_insn (op0, op1, promoted_nominal_mode, - data->passed_mode, unsignedp); + entry_mode, unsignedp); emit_insn (insn); insns = get_insns ();