Re: [PATCH] Fix pr69012 ICE on building libgfortran for mips

On 05.01.2016 21:41, Richard Sandiford wrote: > Matthew Fortune writes: >> Bernd Edlinger writes: >>> Yes, I agree, it _should_ be a no-op, but given the complexity of >>> mips_compute_frame_info it is probably better to use cached values

RE: [PATCH] Fix pr69012 ICE on building libgfortran for mips

Bernd Edlinger writes: > Hi, > > On 30.12.2015 15:31, Richard Sandiford wrote: > > I think the problem is deeper than that though. The instructions that > > are triggering the ICE are only generated by the prologue, so this > > means that we're trying to lay out the

Re: [PATCH] Fix pr69012 ICE on building libgfortran for mips

Matthew Fortune writes: > Bernd Edlinger writes: >> On 30.12.2015 15:31, Richard Sandiford wrote: >> > I think the problem is deeper than that though. The instructions that >> > are triggering the ICE are only generated by the prologue, so

Re: [PATCH] Fix pr69012 ICE on building libgfortran for mips

Hi, On 30.12.2015 15:31, Richard Sandiford wrote: > I think the problem is deeper than that though. The instructions that > are triggering the ICE are only generated by the prologue, so this > means that we're trying to lay out the frame again after the prologue > has been generated, whereas

Re: [PATCH] Fix pr69012 ICE on building libgfortran for mips

Bernd Edlinger writes: > Hi, > > > the build of libgfortran and glibc for mips currently fails because we > now evaluate mips_compute_frame_info more often than before. If any > instruction uses the predicate cprestore_save_slot_operand or > cprestore_load_slot_operand

[PATCH] Fix pr69012 ICE on building libgfortran for mips

Hi, the build of libgfortran and glibc for mips currently fails because we now evaluate mips_compute_frame_info more often than before. If any instruction uses the predicate cprestore_save_slot_operand or cprestore_load_slot_operand the function mips_cprestore_address_p calls