[Bug bootstrap/43399] [4.5 Regression] bootstrap failure in stage1

ramana at gcc dot gnu dot org gcc-bugzilla@gcc.gnu.org
Thu Mar 18 09:25:00 GMT 2010



------- Comment #8 from ramana at gcc dot gnu dot org  2010-03-18 09:25 -------
(In reply to comment #7)
> BTW, if the PRE_MODIFY representation doesn't work well, I'd say just using a
> PARALLEL with what the insn really does and checking that in the match_parallel
> predicate probably wouldn't clash with anything else.  If it would, you'd need
> to insert one UNSPEC somewhere.


The PRE_MODIFY representation wouldn't work because you still have the assert
in var-tracking.c under the check for PRE_MODIFY that this is a BLKmode. The
problem is more the BLKmode on the address. 

> The comments say that currently the pattern looks like:
>        (parallel [
>            (set (mem:BLK (pre_dec:BLK (reg:SI sp)))
>                 (unspec:BLK [(reg:SI r4)] UNSPEC_PUSH_MULT))
>            (use (reg:SI 11 fp))
>            (use (reg:SI 12 ip))
>            (use (reg:SI 14 lr))
>            (use (reg:SI 15 pc))
>         ])
> with the REG_FRAME_RELATED_EXPR:
>       (sequence [
>            (set (reg:SI sp) (plus:SI (reg:SI sp) (const_int -20)))
>            (set (mem:SI (reg:SI sp)) (reg:SI r4))
>            (set (mem:SI (plus:SI (reg:SI sp) (const_int 4))) (reg:SI fp))
>            (set (mem:SI (plus:SI (reg:SI sp) (const_int 8))) (reg:SI ip))
>            (set (mem:SI (plus:SI (reg:SI sp) (const_int 12))) (reg:SI lr))
>         ])
> So, would a parallel like:
>        (parallel [
>            (set (mem:SI (plus:SI (reg:SI sp) (const_int -20))) (reg:SI r4))
>            (set (mem:SI (plus:SI (reg:SI sp) (const_int -16))) (reg:SI fp))
>            (set (mem:SI (plus:SI (reg:SI sp) (const_int -12))) (reg:SI ip))
>            (set (mem:SI (plus:SI (reg:SI sp) (const_int -8))) (reg:SI lr))
>            (set (mem:SI (plus:SI (reg:SI sp) (const_int -4))) (reg:SI pc))
>            (set (reg:SI sp) (plus:SI (reg:SI sp) (const_int -20)))
>         ])
> be unique?  match_parallel would verify the form (that the first sp offset
> matches the negative stack adjustment, that it is multiple of reg size, that
> the
> last adjustment is -word size, that the offsets are consecutive etc.
> Alternatively surround the first set's RHS reg into UNSPEC. 

Actually the comment is out of date and needs to be corrected. It need not be
fp, sp, pc, and lr but any 4 integer registers that we choose to store using
the push_multi scheme in the prologue. Let me go stare at the backend.



-- 

ramana at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |bootstrap
           Priority|P1                          |P3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43399



More information about the Gcc-bugs mailing list