[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516

--- Comment #28 from Peter Bergner  ---
I totally agree, especially since the work in progress patch we did have to fix
the glibc build had so much fallout.

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #27 from Jeffrey A. Law  ---
Joseph's last comment indicates glibc is building, which means the issue in c#6
is no longer a problem.

I think if we find further problems we ought to open a new BZ.

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516

--- Comment #26 from joseph at codesourcery dot com  ---
As of r244815 I don't see the ICE building glibc.  193 FAILs in gcc.sum, 
60 in g++.sum, which is comparable to the results I reported with the LRA 
patches.  I don't get ICEs from either of the previous .i files either.  
So while I don't know what fixed the LRA issue(s) or caused them to go 
latent, I see no sign of them being visible at present.

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #25 from Jeffrey A. Law  ---
Sorry, I thought all the issues had been fixed.  Reopening.

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516

--- Comment #24 from Peter Bergner  ---
(In reply to Jeffrey A. Law from comment #23)
> Fixed by patches on the trunk.

We only have a fix for the ICE in the first comment.  We still do not have a
proper fix for the ICE in Comment 6.  Since you've closed this bug, I assume
you prefer a new bugzilla entry for that ICE rather than working on it here?

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #23 from Jeffrey A. Law  ---
Fixed by patches on the trunk.

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||law at redhat dot com

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516

--- Comment #22 from Peter Bergner  ---
Author: bergner
Date: Thu Jan 19 02:23:35 2017
New Revision: 244609

URL: https://gcc.gnu.org/viewcvs?rev=244609=gcc=rev
Log:
PR target/78516
* config/rs6000/spe.md (mov_si_e500_subreg0): Fix constraints.
Use the evmergelohi instruction.
(mov_si_e500_subreg4_2_le): Likewise.
(mov_sitf_e500_subreg8_2_be): Likewise.
(mov_sitf_e500_subreg12_2_le): Likewise.
(mov_si_e500_subreg0_2_le): Fix constraints.
(mov_si_e500_subreg4_2_be): Likewise.
(mov_sitf_e500_subreg8_2_le): Likewise.
(mov_sitf_e500_subreg12_2_be): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/spe.md

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516

--- Comment #21 from Peter Bergner  ---
(In reply to Peter Bergner from comment #20)
> Vlad, for the following change in the hunk above:
> 
> >   new_reg != NULL_RTX ? sreg : src,
> 
> shouldn't that always be just "sreg"?  Ie, why are we testing for new_reg !=
> NULL_RTX and sometimes passing in "src"?

Well we still ICE even with that, so this will take more digging.

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516

--- Comment #20 from Peter Bergner  ---
(In reply to Peter Bergner from comment #19)
>   emit_insn (GEN_FCN (sri.icode) (new_reg != NULL_RTX ? new_reg : dest,
>   new_reg != NULL_RTX ? sreg : src,
>   scratch_reg));
> }
[snip]
> That subreg for operand1 does not look correct to me.


Vlad, for the following change in the hunk above:

>   new_reg != NULL_RTX ? sreg : src,

shouldn't that always be just "sreg"?  Ie, why are we testing for new_reg !=
NULL_RTX and sometimes passing in "src"?

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516

--- Comment #19 from Peter Bergner  ---
(In reply to Peter Bergner from comment #18)
> With the patch Vlad attached minus the one unwanted line/typo, I'm getting
> an ICE on a powerpc64le-linux bootstrap.  Looking into it.

Here's a minimal test case:

bergner@genoa:~/gcc/BUGS/PR78516$ cat libgcc2.i
float
fn1 (__int128 a)
{
  if ((unsigned)a == a)
return a;
}
bergner@genoa:~/gcc/BUGS/PR78516$
/home/bergner/gcc/build/gcc-fsf-mainline-pr78516/./gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-pr78516/./gcc/ -O2 -S libgcc2.i 
libgcc2.i: In function ‘fn1’:
libgcc2.i:6:1: internal compiler error: in lra_set_insn_recog_data, at
lra.c:965
 }
 ^
0x10a8eaaf lra_set_insn_recog_data(rtx_insn*)
/home/bergner/gcc/gcc-fsf-mainline-pr78516/gcc/lra.c:963

We have the following insn after IRA:

(insn 13 12 31 4 (set (reg:SF 157 [  ])
(float:SF (subreg:DI (reg/v:TI 158 [ aD.2516 ]) 0))) "libgcc2.i":5 407
{floatdisf2_fcfids}
 (expr_list:REG_DEAD (reg/v:TI 158 [ aD.2516 ])
(nil)))

With pseudo 157 being assigned to fp reg fr1 and pseudo 158 being assigned to
r3.  The floatdisf2_fcfids pattern looks like:

(define_insn "floatdisf2_fcfids"
  [(set (match_operand:SF 0 "gpc_reg_operand" "=f,wy")
(float:SF (match_operand:DI 1 "gpc_reg_operand" "d,wi")))]
  "TARGET_HARD_FLOAT && TARGET_FPRS && TARGET_SINGLE_FLOAT
   && TARGET_DOUBLE_FLOAT && TARGET_FCFIDS"
  "@
   fcfids %0,%1
   xscvsxdsp %x0,%x1"
  [(set_attr "type" "fp")])

...so pseudo 158 does not match the pattern's constraints. 
check_and_process_move() doesn't handle this type of insn, so it returns false
and eventually, we generate the following two insns (haven't tracked down where
they come from yet):

(insn 38 12 13 4 (set (reg:DI 165)
(subreg:DI (reg/v:TI 158 [ a ]) 0)) "libgcc2.i":5 582
{*movdi_internal64}
 (nil))

(insn 13 38 31 4 (set (reg:SF 157 [  ])
(float:SF (reg:DI 165))) "libgcc2.i":5 407 {floatdisf2_fcfids}
 (expr_list:REG_DEAD (reg/v:TI 158 [ a ])
(nil)))

This maybe looks ok (?), except for the REG_DEAD on insn 13 should have been
removed and added to the new insn 38.

Later, check_and_process_move() is called again, this time for the new insn 38
and this is where we end up ICEing.  We end up seeing:

(gdb) pr dest
(reg:DI 165)
(gdb) pr dreg
(reg:DI 165)
(gdb) p dclass
$54 = FLOAT_REGS
(gdb) p dregno
$55 = 165

(gdb) pr src
(subreg:DI (reg/v:TI 158 [ a ]) 0)
(gdb) pr sreg
(reg/v:TI 158 [ a ])
(gdb) p sregno
$56 = -1
(gdb) p sclass
$57 = BASE_REGS

(gdb) p secondary_class 
$58 = NO_REGS

Due to the above, new_reg == NULL_RTX and sri.icode ==
CODE_FOR_reload_vsx_from_gprti.  This pushes us down the else clause of the
following if:

  if (sri.icode == CODE_FOR_nothing)
lra_emit_move (new_reg, sreg);
  else
{
  enum reg_class scratch_class;

  scratch_class = (reg_class_from_constraints
   (insn_data[sri.icode].operand[2].constraint));
  scratch_reg = (lra_create_new_reg_with_unique_value
 (insn_data[sri.icode].operand[2].mode, NULL_RTX,
  scratch_class, "scratch"));
  emit_insn (GEN_FCN (sri.icode) (new_reg != NULL_RTX ? new_reg : dest,
  new_reg != NULL_RTX ? sreg : src,
  scratch_reg));
}

We then up calling gen_reload_vsx_from_gprti() via the emit_insn() with:
op0, op1 and op2 as:

(gdb) pr operand0
(reg:DI 165)
(gdb) pr operand1
(subreg:DI (reg/v:TI 158 [ a ]) 0)
(gdb) pr operand2
(reg:IF 166)

That subreg for operand1 does not look correct to me.

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516

--- Comment #18 from Peter Bergner  ---
With the patch Vlad attached minus the one unwanted line/typo, I'm getting an
ICE on a powerpc64le-linux bootstrap.  Looking into it.

/home/bergner/gcc/gcc-fsf-mainline-pr78516/libgcc/libgcc2.c: In function
‘__floatuntisf’:
/home/bergner/gcc/gcc-fsf-mainline-pr78516/libgcc/libgcc2.c:1819:1: internal
compiler error: in lra_set_insn_recog_data, at lra.c:965
 }
 ^
0x10a8eaaf lra_set_insn_recog_data(rtx_insn*)
/home/bergner/gcc/gcc-fsf-mainline-pr78516/gcc/lra.c:963
0x10a8b8d7 lra_get_insn_recog_data
/home/bergner/gcc/gcc-fsf-mainline-pr78516/gcc/lra-int.h:487
0x10a9142f lra_update_insn_regno_info(rtx_insn*)
/home/bergner/gcc/gcc-fsf-mainline-pr78516/gcc/lra.c:1585
0x10a91e4f lra_push_insn_1
/home/bergner/gcc/gcc-fsf-mainline-pr78516/gcc/lra.c:1736
0x10a91eb3 lra_push_insn(rtx_insn*)
/home/bergner/gcc/gcc-fsf-mainline-pr78516/gcc/lra.c:1744
0x10a92113 push_insns
/home/bergner/gcc/gcc-fsf-mainline-pr78516/gcc/lra.c:1787
0x10a92447 lra_process_new_insns(rtx_insn*, rtx_insn*, rtx_insn*, char const*)
/home/bergner/gcc/gcc-fsf-mainline-pr78516/gcc/lra.c:1835
0x10aa7ecb check_and_process_move
/home/bergner/gcc/gcc-fsf-mainline-pr78516/gcc/lra-constraints.c:1261
0x10ab11f3 curr_insn_transform
/home/bergner/gcc/gcc-fsf-mainline-pr78516/gcc/lra-constraints.c:3709
0x10ab5bf3 lra_constraints(bool)
/home/bergner/gcc/gcc-fsf-mainline-pr78516/gcc/lra-constraints.c:4705
0x10a9435b lra(_IO_FILE*)
/home/bergner/gcc/gcc-fsf-mainline-pr78516/gcc/lra.c:2377
0x10a0fb2f do_reload
/home/bergner/gcc/gcc-fsf-mainline-pr78516/gcc/ira.c:5400
0x10a10363 execute
/home/bergner/gcc/gcc-fsf-mainline-pr78516/gcc/ira.c:5584

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516

--- Comment #17 from joseph at codesourcery dot com  ---
On Tue, 20 Dec 2016, bergner at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516
> 
> --- Comment #16 from Peter Bergner  ---
> (In reply to Vladimir Makarov from comment #15)
> > Sorry, I applied your changes manually and did a typo.  The line
> > 
> > SET_SRC (curr_insn_set) = new_reg;
> > 
> > should be removed.
> > 
> > I tested this patch with the typo on x86-64 and no new failures occurred. 
> > Strange.
> 
> That would suggest on x86-64, SET_SRC (curr_insn_set) is never a subreg for 
> the
> insns that we process here.  As they say, better to be lucky than good! :-) 
> With the SPE, we're just not lucky as shown by Joseph's last run.  I'm sure it
> will pass after removing the unwanted line above.

With this fix, my build completes OK and the number of FAILs is down from 
105 to 62 in g++.sum and from 246 to 188 in gcc.sum (again, this is a 
rough comparison with a build from a month ago rather than an exact 
comparison against unmodified current mainline).

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516

--- Comment #16 from Peter Bergner  ---
(In reply to Vladimir Makarov from comment #15)
> Sorry, I applied your changes manually and did a typo.  The line
> 
> SET_SRC (curr_insn_set) = new_reg;
> 
> should be removed.
> 
> I tested this patch with the typo on x86-64 and no new failures occurred. 
> Strange.

That would suggest on x86-64, SET_SRC (curr_insn_set) is never a subreg for the
insns that we process here.  As they say, better to be lucky than good! :-) 
With the SPE, we're just not lucky as shown by Joseph's last run.  I'm sure it
will pass after removing the unwanted line above.

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516

--- Comment #15 from Vladimir Makarov  ---
(In reply to Peter Bergner from comment #13)
> (In reply to Vladimir Makarov from comment #11)
> > Created attachment 40372 [details]
> > The proposed patch
> 
> Agreed your additions to my change looks good.  However, I'm not so sure
> about this last hunk:
> 
> -SET_SRC (curr_insn_set) = new_reg;
> +{
> +  SET_SRC (curr_insn_set) = new_reg;
> +  if (SUBREG_P (src))
> + SUBREG_REG (SET_SRC (curr_insn_set)) = new_reg;
> +  else
> + SET_SRC (curr_insn_set) = new_reg;
> +}
> 
> Specifically, I don't think you meant to leave the following code as part of
> that:
> 
> +  SET_SRC (curr_insn_set) = new_reg;
> 
>

Sorry, I applied your changes manually and did a typo.  The line

SET_SRC (curr_insn_set) = new_reg;

should be removed.

I tested this patch with the typo on x86-64 and no new failures occurred. 
Strange.

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516

--- Comment #14 from Peter Bergner  ---
(In reply to Joseph S. Myers from comment #12)
> Created attachment 40373 [details]
> fnmatch.i preprocessed source
> 
> With that new LRA patch (plus the previous gcc-pr78516.v2.diff) I get an ICE
> building glibc again.  Preprocessed source attached.  Compile with:

Joseph, can you retry but with removing the one line I said I don't think we
want from Vlad's patch?  I'm pretty sure that is probably causing your ICE.  So
the last hunk should look like:

+{
+  if (SUBREG_P (src))
+   SUBREG_REG (SET_SRC (curr_insn_set)) = new_reg;
+  else
+   SET_SRC (curr_insn_set) = new_reg;
+}

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516

--- Comment #13 from Peter Bergner  ---
(In reply to Vladimir Makarov from comment #11)
> Created attachment 40372 [details]
> The proposed patch

Agreed your additions to my change looks good.  However, I'm not so sure about
this last hunk:

-SET_SRC (curr_insn_set) = new_reg;
+{
+  SET_SRC (curr_insn_set) = new_reg;
+  if (SUBREG_P (src))
+   SUBREG_REG (SET_SRC (curr_insn_set)) = new_reg;
+  else
+   SET_SRC (curr_insn_set) = new_reg;
+}

Specifically, I don't think you meant to leave the following code as part of
that:

+  SET_SRC (curr_insn_set) = new_reg;

since after we execute that, SET_SRC (curr_insn_set) won't be
a subreg anymore and the following:

+   SUBREG_REG (SET_SRC (curr_insn_set)) = new_reg;

won't end well.  I think we want your patch minus that one line.

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[jsm28 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516

--- Comment #12 from Joseph S. Myers  ---
Created attachment 40373
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40373=edit
fnmatch.i preprocessed source

With that new LRA patch (plus the previous gcc-pr78516.v2.diff) I get an ICE
building glibc again.  Preprocessed source attached.  Compile with:

powerpc-linux-gnuspe-gcc -S -std=gnu11 -fgnu89-inline  -O2
-fmerge-all-constants -g -mlong-double-128 -ftls-model=initial-exec fnmatch.i

In file included from fnmatch.c:321:0:
fnmatch_loop.c: In function 'internal_fnwmatch':
fnmatch_loop.c:999:1: internal compiler error: Segmentation fault
0x8784a4a crash_signal
/scratch/jmyers/glibc/pe500-mainline/src/gcc-mainline/gcc/toplev.c:333
0x861e590 lra_eliminate_reg_if_possible(rtx_def**)
   
/scratch/jmyers/glibc/pe500-mainline/src/gcc-mainline/gcc/lra-eliminations.c:1385
0x860dd08 in_class_p
   
/scratch/jmyers/glibc/pe500-mainline/src/gcc-mainline/gcc/lra-constraints.c:257
0x8613721 process_alt_operands
   
/scratch/jmyers/glibc/pe500-mainline/src/gcc-mainline/gcc/lra-constraints.c:2239
0x8619052 curr_insn_transform
   
/scratch/jmyers/glibc/pe500-mainline/src/gcc-mainline/gcc/lra-constraints.c:3720
0x861be7a lra_constraints(bool)
   
/scratch/jmyers/glibc/pe500-mainline/src/gcc-mainline/gcc/lra-constraints.c:4706
0x8606dbe lra(_IO_FILE*)
/scratch/jmyers/glibc/pe500-mainline/src/gcc-mainline/gcc/lra.c:2377
0x85bdf74 do_reload
/scratch/jmyers/glibc/pe500-mainline/src/gcc-mainline/gcc/ira.c:5400
0x85bdf74 execute
/scratch/jmyers/glibc/pe500-mainline/src/gcc-mainline/gcc/ira.c:5584
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516

--- Comment #11 from Vladimir Makarov  ---
Created attachment 40372
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40372=edit
The proposed patch

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516

--- Comment #10 from Vladimir Makarov  ---
(In reply to Peter Bergner from comment #8)

> where "src" is the subreg:SI ..., so the new_reg mode will be SImode and we
> then replace the whole SET_SRC (curr_insn_set) which is the subreg:SI
> (reg:DF ...) which doesn't seem correct.
> 
> Vlad, should we have never got this far into check_and_process_move() with
> this type of insn?  Adding an ugly hack that creates an early out for this
> insn (ie, set (reg:SI) (subreg:SI (reg:DF))) seems to make us compile.
> 

I believe we should process this insn in check_and_process_move.  It is the
single place to check secondary reload hooks and insns.

> If we are supposed to still process this insn, then how about something like
> the following patch that creates a new_reg with the mode of the src register
> and not the subreg and then replacing that instead of the entire subreg src?
> This too eliminates the SEGV/ICE.

I think creating a new reg from the register instead of the sub-register is
safer.  Also it results in a better code too, if the subregister is a
paradoxical one,  So the patch idea is right.  But I believe it is not
finished.  I am attaching a new version of the patch.  If it is ok, I can
commit it after your confirmation.

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516

--- Comment #9 from joseph at codesourcery dot com  ---
That LRA patch (on top of the previous patch) allows the glibc build to 
complete.  Now running gcc/g++/libstdc++ testsuites (I haven't run them 
with an unmodified copy of the same GCC version, so this will only provide 
a rough comparison against results from my previous testing of older trunk 
on 23 November).

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516

Peter Bergner  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #8 from Peter Bergner  ---
Adding Vlad as this seems like it may be a LRA bug...or we at least need his
input about what we should be doing.

We have the following "fixed" pattern from the updated fix patch attached
above:

(define_insn "*mov_si_e500_subreg0_2_be"
  [(set (match_operand:SI 0 "int_reg_or_mem_operand" "=r,m")
(subreg:SI (match_operand:SPE64TF 1 "gpc_reg_operand" "+r,") 0))]
  "WORDS_BIG_ENDIAN
   && ((TARGET_E500_DOUBLE && (mode == DFmode || mode == TFmode))
   || (TARGET_SPE && mode != DFmode && mode != TFmode))"
  "@
   evmergelohi %0,%1,%1
   evmergelohi %1,%1,%1\;stw%U0%X0 %1,%0"
  [(set_attr "length" "4,8")])

After IRA, we have the following rtl dump results, with pseudo 192 not getting
a color and pseudo 283 getting assigned to the CTR (hard reg 66 ...ick!):

(insn 223 222 51 2 (set (reg/v:DF 192 [ tD.1744 ])
(mem/u/c:DF (reg/f:SI 339) [1  S8 A64])) "q.i":28 2031
{*movdf_e500_double}
 (expr_list:REG_DEAD (reg/f:SI 339)
(expr_list:REG_EQUIV (const_double:DF 0.0 [0x0.0p+0])
(nil
...
(insn 113 97 234 2 (set (reg:SI 283)
(subreg:SI (reg/v:DF 192 [ tD.1744 ]) 0)) "q.i":9 1975
{*mov_sidf_e500_subreg0_2_be}
 (nil))
...
(insn 111 107 116 2 (set (reg:DF 278)
(mult:DF (reg/v:DF 192 [ tD.1744 ])
(reg:DF 279))) "q.i":28 2038 {spe_muldf3}
 (expr_list:REG_DEAD (reg:DF 279)
(expr_list:REG_DEAD (reg/v:DF 192 [ tD.1744 ])
(nil

In lra-constraints.c:check_and_process_move() with curr_insn == insn 113, we
end up modifying insn 113 and emitting an insn before 113 that looks like:

(insn 273 97 113 2 (set (reg:SI 345)
(subreg:SI (reg/v:DF 192 [ t ]) 0)) "q.i":9 1975
{*mov_sidf_e500_subreg0_2_be}
 (nil))

(insn 113 273 234 2 (set (reg:SI 283)
(reg:SI 345)) "q.i":9 1975 {*mov_sidf_e500_subreg0_2_be}
 (nil))

Notice that the new insn 273 looks just like the old insn 113 and now insn 113
is invalid since this is a SImode reg to SImode reg copy without the subreg
which won't match the mov_sidf_e500_subreg0_2_be pattern, which leads us to
SEGV during check_rtl()'s call to constrain_operands() via
extract_constrain_insn().

The invalid insn 113 modification occurs due to the following code near the
bottom of check_and_process_move():

  if (new_reg != NULL_RTX)
SET_SRC (curr_insn_set) = new_reg;

In this case, new_reg was created by:

  if (secondary_class != NO_REGS)
new_reg = lra_create_new_reg_with_unique_value (GET_MODE (src), NULL_RTX,
secondary_class,
"secondary");

where "src" is the subreg:SI ..., so the new_reg mode will be SImode and we
then replace the whole SET_SRC (curr_insn_set) which is the subreg:SI (reg:DF
...) which doesn't seem correct.

Vlad, should we have never got this far into check_and_process_move() with this
type of insn?  Adding an ugly hack that creates an early out for this insn (ie,
set (reg:SI) (subreg:SI (reg:DF))) seems to make us compile.

If we are supposed to still process this insn, then how about something like
the following patch that creates a new_reg with the mode of the src register
and not the subreg and then replacing that instead of the entire subreg src? 
This too eliminates the SEGV/ICE.

Joseph, in the mean time, can you try the patch below to see if you get farther
into your glibc build?

Index: lra-constraints.c
===
--- lra-constraints.c   (revision 243444)
+++ lra-constraints.c   (working copy)
@@ -1237,12 +1237,12 @@ check_and_process_move (bool *change_p,
   *change_p = true;
   new_reg = NULL_RTX;
   if (secondary_class != NO_REGS)
-new_reg = lra_create_new_reg_with_unique_value (GET_MODE (src), NULL_RTX,
+new_reg = lra_create_new_reg_with_unique_value (GET_MODE (sreg), NULL_RTX,
secondary_class,
"secondary");
   start_sequence ();
   if (sri.icode == CODE_FOR_nothing)
-lra_emit_move (new_reg, src);
+lra_emit_move (new_reg, sreg);
   else
 {
   enum reg_class scratch_class;
@@ -1259,7 +1259,12 @@ check_and_process_move (bool *change_p,
   end_sequence ();
   lra_process_new_insns (curr_insn, before, NULL, "Inserting the move");
   if (new_reg != NULL_RTX)
-SET_SRC (curr_insn_set) = new_reg;
+{
+  if (SUBREG_P (src))
+   SUBREG_REG (SET_SRC (curr_insn_set)) = new_reg;
+  else
+   SET_SRC (curr_insn_set) = new_reg;
+}
   else
 {
   if (lra_dump_file != NULL)

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516

--- Comment #7 from Peter Bergner  ---
(In reply to Joseph S. Myers from comment #6)
> With the "updated fix" gcc-pr78516.v2.diff applied I get an ICE building
> glibc.  Preprocessed source attached.  Compile with:
> powerpc-linux-gnuspe-gcc -S -fgnu89-inline -O2 -fmerge-all-constants
> -mlong-double-128 s_sincos.i

I have it recreated and I'm digging into it.

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[jsm28 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516

--- Comment #6 from Joseph S. Myers  ---
Created attachment 40329
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40329=edit
Preprocessed source

With the "updated fix" gcc-pr78516.v2.diff applied I get an ICE building glibc.
 Preprocessed source attached.  Compile with: powerpc-linux-gnuspe-gcc -S
-fgnu89-inline -O2 -fmerge-all-constants -mlong-double-128 s_sincos.i

In file included from ../sysdeps/ieee754/ldbl-opt/s_sincos.c:2:0:
../sysdeps/ieee754/dbl-64/s_sincos.c: In function '__sincos':
../sysdeps/ieee754/dbl-64/s_sincos.c:108:1: internal compiler error:
Segmentation fault
0x8781cfa crash_signal
/scratch/jmyers/glibc/pe500-mainline/src/gcc-mainline/gcc/toplev.c:333
0x86dfb56 constrain_operands(int, unsigned long long)
/scratch/jmyers/glibc/pe500-mainline/src/gcc-mainline/gcc/recog.c:2594
0x86e050f extract_constrain_insn(rtx_insn*)
/scratch/jmyers/glibc/pe500-mainline/src/gcc-mainline/gcc/recog.c:2212
0x8600fc8 check_rtl
/scratch/jmyers/glibc/pe500-mainline/src/gcc-mainline/gcc/lra.c:2109
0x8605488 lra(_IO_FILE*)
/scratch/jmyers/glibc/pe500-mainline/src/gcc-mainline/gcc/lra.c:2517
0x85bbfe4 do_reload
/scratch/jmyers/glibc/pe500-mainline/src/gcc-mainline/gcc/ira.c:5400
0x85bbfe4 execute
/scratch/jmyers/glibc/pe500-mainline/src/gcc-mainline/gcc/ira.c:5584
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516

Peter Bergner  changed:

   What|Removed |Added

  Attachment #40317|0   |1
is obsolete||

--- Comment #5 from Peter Bergner  ---
Created attachment 40321
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40321=edit
Updated fix

(In reply to Peter Bergner from comment #4)
>  (define_insn "*mov_si_e500_subreg0_2_be"
> -  [(set (match_operand:SI 0 "rs6000_nonimmediate_operand" "+r,m")
> -   (subreg:SI (match_operand:SPE64TF 1 "register_operand" "+r,") 0))]
> +  [(set (match_operand:SI 0 "rs6000_nonimmediate_operand" "=r,")
> +   (subreg:SI (match_operand:SPE64TF 1 "register_operand" "r,r") 0))]
>"WORDS_BIG_ENDIAN
> && ((TARGET_E500_DOUBLE && (mode == DFmode || mode ==
> TFmode))
> || (TARGET_SPE && mode != DFmode && mode != TFmode))"
>"@
> -   evmergehi %0,%0,%1
> +   evmergelohi %0,%1,%1
> evmergelohi %1,%1,%1\;stw%U0%X0 %1,%0"
>[(set_attr "length" "4,8")])

Of course now that I've had time to think of this, I think the correct thing
here isn't to move the earlyclobber to the 'm' constraint, but to add the '+'
modifier to the '' constraint to show that is is not only an input, but it is
modified as well.
...and '+' has to be at the beginning of the constraint string, hence why it
was located where it was originally. :-)

So that leaves us with this smaller change:

 (define_insn "*mov_si_e500_subreg0_2_be"
-  [(set (match_operand:SI 0 "rs6000_nonimmediate_operand" "+r,m")
+  [(set (match_operand:SI 0 "rs6000_nonimmediate_operand" "=r,m")
(subreg:SI (match_operand:SPE64TF 1 "register_operand" "+r,") 0))]
   "WORDS_BIG_ENDIAN
&& ((TARGET_E500_DOUBLE && (mode == DFmode || mode == TFmode))
|| (TARGET_SPE && mode != DFmode && mode != TFmode))"
   "@
-   evmergehi %0,%0,%1
+   evmergelohi %0,%1,%1
evmergelohi %1,%1,%1\;stw%U0%X0 %1,%0"
   [(set_attr "length" "4,8")])

Joseph, ignore the last patch and try this one.

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516

--- Comment #4 from Peter Bergner  ---
Created attachment 40317
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40317=edit
Potential fix to spe.md

(In reply to Peter Bergner from comment #2)
> So we're hitting this code in lra-assigns.c:lra_assign():1612:
> 
>   if (flag_checking && !flag_ipa_ra)
> for (i = FIRST_PSEUDO_REGISTER; i < max_regno; i++)
>   if (lra_reg_info[i].nrefs != 0 && reg_renumber[i] >= 0
>   && lra_reg_info[i].call_p
>   && overlaps_hard_reg_set_p (call_used_reg_set,
>   PSEUDO_REGNO_MODE (i),
> reg_renumber[i]))
> gcc_unreachable ();
> 
> Our pseudo (i == 184) had been assigned to r9 (a call clobbered reg) and yet
> lra_reg_info[184].call_p is true, leading to the assert.
> 
> Looking through the rtl dumps, pseudo 184 is live only over two consecutive
> insns, so clearly call_p should not be true here.  I'm tracking down where
> that is getting set.

This ends up being a bug in the spe.md:*mov_sidf_e500_subreg0_2_be pattern's
constraints (ditto from some other patterns).

The problem RTL is below.  We have a call followed later in the same basic
block, by a set of pseudo 184 and then its only use closely thereafter:

(call_insn 13 10 14 2 (parallel [
(call (mem:SI (symbol_ref:SI ("bar") [flags 0x41] ) [0 barD.1674 S4 A32])
(const_int 0 [0]))
(use (const_int 0 [0]))
(clobber (reg:SI 65 lr))
]) "pr78516.i":5 654 {*call_nonlocal_sysvsi}
 (nil)
(nil))
...
(insn 16 15 17 2 (set (reg:SI 184)
(subreg:SI (reg:DF 155 [ neg0.0_1 ]) 0)) "pr78516.i":7 1975
{*mov_sidf_e500_subreg0_2_be}
 (expr_list:REG_DEAD (reg:DF 155 [ neg0.0_1 ])
(nil)))
...
(insn 19 18 20 2 (set (reg:CC 167)
(compare:CC (reg:SI 184)
(const_int 0 [0]))) "pr78516.i":7 678 {*cmpsi_signed}
 (expr_list:REG_DEAD (reg:SI 184)
(nil)))

So pseudo 184 (assigned to a call clobber reg) is not live across the call, but
lra-lives.c:process_bb_lives() thinks it is, so it triggers the above assert. 
It seems IRA uses the gcc df infrastructure to determine liveness and this
tells IRA is can assign a call clobbered register to pseudo 184 and it does
(r9).  lra-lives.c has its own liveness analysis code which does not make use
of df (should it?) and its analysis finds the pseudo 184's live range extends
up to the call and beyond.  This is due to lra-lives.c uses an insn's recog
data to see what operands are defined and used in an insn and computes liveness
from that.  The "bug" is that the *mov_sidf_e500_subreg0_2_be pattern has
incorrect constraints and the defined pseudo is marked as a OP_INOUT operand,
so it what makes pseudo 184 live range extend up to the top of the block and
across the call leading to the ICE.  The pattern is:

(define_insn "*mov_si_e500_subreg0_2_be"
  [(set (match_operand:SI 0 "rs6000_nonimmediate_operand" "+r,m")
(subreg:SI (match_operand:SPE64TF 1 "register_operand" "+r,") 0))]
  "WORDS_BIG_ENDIAN
   && ((TARGET_E500_DOUBLE && (mode == DFmode || mode == TFmode))
   || (TARGET_SPE && mode != DFmode && mode != TFmode))"
  "@
   evmergehi %0,%0,%1
   evmergelohi %1,%1,%1\;stw%U0%X0 %1,%0"
  [(set_attr "length" "4,8")])

There are multiple problems with the first alternative.  First, op1 is marked
as an input/output operand, but it clearly only an input.

Secondly, op0 is also marked as a input/output operand (and this is what leads
to our ICE) since it is used as an input to the evmergehi instruction. 
However, the purpose of the pattern is to simply copy the high word of op1 and
place it into the low word of op0.  In that case, that case, the source operand
%0 here could be any register, since it's value will be unused (since we're
writing a SImode reg).  That means op0 really should only be an output operand.
 To simplify things, so changed the instruction for the first alternative to be
the same as the second alternative, since they're performing the same function,
except that alternative 1 also stores the value to memory.

For the second alternative, I moved the earlyclobber constraint modifier to the
output operand to quiet the following message I was getting after my changes:

/home/bergner/gcc/gcc-fsf-mainline-pr78516/gcc/config/rs6000/spe.md:2561:1:
earlyclobber operands may not be read-only in alternative 1

Therefore, the "fixed" pattern which eliminates the ICE, looks like:

 (define_insn "*mov_si_e500_subreg0_2_be"
-  [(set (match_operand:SI 0 "rs6000_nonimmediate_operand" "+r,m")
-   (subreg:SI (match_operand:SPE64TF 1 "register_operand" "+r,") 0))]
+  [(set (match_operand:SI 0 "rs6000_nonimmediate_operand" "=r,")
+   (subreg:SI (match_operand:SPE64TF 1 "register_operand" "r,r") 0))]
   "WORDS_BIG_ENDIAN
&& ((TARGET_E500_DOUBLE && (mode == DFmode || mode == TFmode))
|| (TARGET_SPE && mode != DFmode && mode != TFmode))"
   "@
-   

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516

Peter Bergner  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |bergner at gcc dot 
gnu.org

--- Comment #3 from Peter Bergner  ---
Here is a smaller test case which still fails at -O0 and -O1:

bergner@genoa:~/gcc/BUGS/PR78516$ cat pr78516.i 
extern void bar (void);
double
foo (double one, double arg)
{
  bar ();
  volatile double neg0 = arg;
  return __builtin_copysign (one, neg0);
}

bergner@genoa:~/gcc/BUGS/PR78516$
/home/bergner/gcc/build/gcc-fsf-mainline-pr78516-base-debug/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-pr78516-base-debug/gcc -m32 -O1
pr78516.i 
pr78516.i: In function ‘foo’:
pr78516.i:8:1: internal compiler error: in lra_assign, at lra-assigns.c:1616
 }
 ^
0x10aa1aa7 lra_assign()
/home/bergner/gcc/gcc-fsf-mainline-pr78516-base/gcc/lra-assigns.c:1616
0x10a96e03 lra(_IO_FILE*)
/home/bergner/gcc/gcc-fsf-mainline-pr78516-base/gcc/lra.c:2422
0x10a123d7 do_reload
/home/bergner/gcc/gcc-fsf-mainline-pr78516-base/gcc/ira.c:5400
0x10a12c0b execute
/home/bergner/gcc/gcc-fsf-mainline-pr78516-base/gcc/ira.c:5584

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516

--- Comment #2 from Peter Bergner  ---
So we're hitting this code in lra-assigns.c:lra_assign():1612:

  if (flag_checking && !flag_ipa_ra)
for (i = FIRST_PSEUDO_REGISTER; i < max_regno; i++)
  if (lra_reg_info[i].nrefs != 0 && reg_renumber[i] >= 0
  && lra_reg_info[i].call_p
  && overlaps_hard_reg_set_p (call_used_reg_set,
  PSEUDO_REGNO_MODE (i), reg_renumber[i]))
gcc_unreachable ();

Our pseudo (i == 184) had been assigned to r9 (a call clobbered reg) and yet
lra_reg_info[184].call_p is true, leading to the assert.

Looking through the rtl dumps, pseudo 184 is live only over two consecutive
insns, so clearly call_p should not be true here.  I'm tracking down where that
is getting set.

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-07
 CC||aldyh at gcc dot gnu.org,
   ||bergner at gcc dot gnu.org,
   ||meissner at gcc dot gnu.org,
   ||segher at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Aldy Hernandez  ---
Confirmed.

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0