[Bug target/79462] [7 Regression] sh: Stack smashing detected when building __ashrdi3 in libgcc

[kkojima at gcc dot gnu.org]

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

Kazumoto Kojima  changed:

   What|Removed |Added

 CC||kkojima at gcc dot gnu.org

--- Comment #3 from Kazumoto Kojima  ---
I've tested the patch with the top "make -k check" on sh4-unknown-linux-gnu
and there are no regressions.

[Bug target/79112] [SH] libgo/go/exp/terminal/util.go:70:23: error: integer constant overflow

[kkojima at gcc dot gnu.org]

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

--- Comment #5 from Kazumoto Kojima  ---
It seems that the error message says all.  TIOCGWINSZ is defined as

#define TIOCGWINSZ0x80087468  /* _IOR('t', 104, struct winsize) */

in the SH kernel header asm/ioctls.h.  Perhaps you could change it to

#define TIOCGWINSZ (int)0x80087468 /* _IOR('t', 104, struct winsize) */

so to avoid that error.  I'm not sure that this is go problem or
usual SH kernel header problem.  And I'm not sure that go can work
well on SH even if it can be built.  I guess 32-bit ports without
split stack can run small go applications only.  The patch is welcome,
of course.

[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

[kkojima at gcc dot gnu.org]

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

--- Comment #20 from Kazumoto Kojima  ---
I've applied a quick fix.  I'd like to keep this open for further
checks.

[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

[kkojima at gcc dot gnu.org]

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

--- Comment #19 from Kazumoto Kojima  ---
Author: kkojima
Date: Tue Jan 17 04:07:51 2017
New Revision: 244516

URL: https://gcc.gnu.org/viewcvs?rev=244516=gcc=rev
Log:
PR target/78633
* config/sh/sh.md (cmpeqsi_t+1): Call copy_rtx to avoid invalid
RTL sharing.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.md

[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

[kkojima at gcc dot gnu.org]

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

--- Comment #14 from Kazumoto Kojima  ---
No problem.  I can continue nightly build with a minimal change

diff --git a/gcc/config/sh/sh.md b/gcc/config/sh/sh.md
index c6956a0..edadba7 100644
--- a/gcc/config/sh/sh.md
+++ b/gcc/config/sh/sh.md
@@ -858,7 +858,8 @@
 operands of the tstsi_t insn, which is generally the case.  */
   if (dump_file)
fprintf (dump_file, "cmpeqsi_t: replacing with tstsi_t\n");
-  emit_insn (gen_tstsi_t (XEXP (op.set_src, 0), XEXP (op.set_src, 1)));
+  emit_insn (gen_tstsi_t (copy_rtx (XEXP (op.set_src, 0)),
+ copy_rtx (XEXP (op.set_src, 1;
   DONE;
 }

added to my local git tree so as not to miss other breakages on trunk.

[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

[kkojima at gcc dot gnu.org]

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

--- Comment #12 from Kazumoto Kojima  ---
Hmm...  From
https://gcc.gnu.org/onlinedocs/gccint/Sharing.html#Sharing
the above patch looks wrong.  Perhaps the splitter in problem
might have to take care of subreg case even when referencing
a reg rtx in the input operands.

[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

[kkojima at gcc dot gnu.org]

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

--- Comment #11 from Kazumoto Kojima  ---
Created attachment 40271
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40271=edit
reduce testcase

With -O1, sh4-linux compiler makes insns

(insn 67 150 165 5 (set (reg:SI 239)
(and:SI (subreg:SI (reg/v:DI 163 [ high ]) 0)
(const_int 1 [0x1]))) "test.c":34 88 {*andsi_compact}
 (nil))
(insn 165 67 74 5 (set (reg:SI 147 t)
(eq:SI (and:SI (subreg:SI (reg/v:DI 163 [ high ]) 0)
(const_int 1 [0x1]))
(const_int 0 [0]))) "test.c":34 -1
 (nil))

and two (subreg:SI (reg/v:DI 163 [ high ]) 0) are shared.

emit-rtl.c:verify_rtl_sharing calls verify_insn_sharing for these
insns and verify_insn_sharing marks rtxes with verify_rtx_sharing.
SUBREG rtx is always marked as used with verify_rtx_sharing.  Then
the second subreg is reported as erroneous because it's already
marked as used.  I think that this is a false positive.  It seems
to me that SUBREG should be handled specially.

diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
index 4650540..4fa4773 100644
--- a/gcc/emit-rtl.c
+++ b/gcc/emit-rtl.c
@@ -2714,6 +2714,9 @@ verify_rtx_sharing (rtx orig, rtx insn)
 case SCRATCH:
   /* SCRATCH must be shared because they represent distinct values.  */
   return;
+case SUBREG:
+  verify_rtx_sharing (SUBREG_REG (x), insn);
+  return;
 case CLOBBER:
   /* Share clobbers of hard registers (like cc0), but do not share pseudo
reg
  clobbers or clobbers of hard registers that originated as pseudos.

I could be totally wrong about that, though.

[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

[kkojima at gcc dot gnu.org]

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

--- Comment #10 from Kazumoto Kojima  ---
Ah, don't mind.  Your patch accidentally hides this PR.  Now
the SH build failure comes back on trunk :-)

[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

[kkojima at gcc dot gnu.org]

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

--- Comment #6 from Kazumoto Kojima  ---
I've tried a bi-sect on git tree.  The ICE went away with

commit c95f3fa2db12f22bbb2158d18c95f6714b4292b8
Author: krebbel 
Date:   Fri Dec 2 08:32:40 2016 +

Do not simplify "(and (reg) (const bit)" to if_then_else.

which corresponds to

2016-12-02  Dominik Vogt  

* combine.c (combine_simplify_rtx):  Suppress replacement of
"(and (reg) (const_int bit))" with "if_then_else".

on svn.  The ICE pops up again with reverting it on HAED.
I don't get what was going on without it, though.

[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

[kkojima at gcc dot gnu.org]

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

--- Comment #4 from Kazumoto Kojima  ---
Now I can't reproduce the ICEs for the revision 243217.  They failed
for the revision 243091.  I'm not sure whether the issue is false
positive or not.  I'd like to keep this PR for a while.

[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

[kkojima at gcc dot gnu.org]

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

--- Comment #2 from Kazumoto Kojima  ---
Looks not enough.  Even with the patch, I got a similar ICE for lto case
in testsuite:

FAIL: gcc.dg/atomic/stdatomic-op-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (internal compiler error)

gcc.log says

/exp/ldroot/dodes/ORIG/trunk/gcc/testsuite/gcc.dg/atomic/stdatomic-op-1.c: In
function 'main':
/exp/ldroot/dodes/ORIG/trunk/gcc/testsuite/gcc.dg/atomic/stdatomic-op-1.c:341:1:
error: invalid rtl sharing found in the insn
(insn 1527 292 294 23 (set (reg:SI 147 t)
(eq:SI (subreg:SI (reg:QI 559) 0)
(const_int 0 [0])))
"/exp/ldroot/dodes/ORIG/trunk/gcc/testsuite/gcc.dg/atomic/stdatomic-op-1.c":94
-1
 (nil))
/exp/ldroot/dodes/ORIG/trunk/gcc/testsuite/gcc.dg/atomic/stdatomic-op-1.c:341:1:
error: shared rtx
(subreg:SI (reg:QI 559) 0)
/exp/ldroot/dodes/ORIG/trunk/gcc/testsuite/gcc.dg/atomic/stdatomic-op-1.c:341:1:
internal compiler error: internal consistency failure
0x829cca7 verify_rtx_sharing
../../ORIG/trunk/gcc/emit-rtl.c:2743

and it went away with the patch below.

diff --git a/config/sh/sh.md b/config/sh/sh.md
index c6956a0..667a9a5 100644
--- a/config/sh/sh.md
+++ b/config/sh/sh.md
@@ -607,7 +607,7 @@
{
  if (dump_file)
fprintf (dump_file, "tstsi_t: converting to cmpeqsi_t\n");
- emit_insn (gen_cmpeqsi_t (eop0.use_as_extended_reg (curr_insn),
+ emit_insn (gen_cmpeqsi_t (copy_rtx(eop0.use_as_extended_reg
(curr_insn)),
const0_rtx));
  DONE;
}

[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

[kkojima at gcc dot gnu.org]

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

Kazumoto Kojima  changed:

   What|Removed |Added

 CC||olegendo at gcc dot gnu.org

--- Comment #1 from Kazumoto Kojima  ---
Here is a trial patch

diff --git a/config/sh/sh.md b/config/sh/sh.md
index c6956a0..c83bf08 100644
--- a/config/sh/sh.md
+++ b/config/sh/sh.md
@@ -858,7 +858,8 @@
 operands of the tstsi_t insn, which is generally the case.  */
   if (dump_file)
fprintf (dump_file, "cmpeqsi_t: replacing with tstsi_t\n");
-  emit_insn (gen_tstsi_t (XEXP (op.set_src, 0), XEXP (op.set_src, 1)));
+  emit_insn (gen_tstsi_t (copy_rtx (XEXP (op.set_src, 0)),
+ XEXP (op.set_src, 1)));
   DONE;
 }

Oleg, could you take a look at the issue?  Although the patch fixes
the ICE, I'm not sure if it's OK and enough.

[Bug target/78633] New: [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

[kkojima at gcc dot gnu.org]

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

Bug ID: 78633
   Summary: [7 Regression] [SH] libgcc/fp-bit.c:944:1: error:
invalid rtl sharing found in the insn
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kkojima at gcc dot gnu.org
  Target Milestone: ---
Target: sh*-*-*

Build fails during compiling libgcc.

../../../ORIG/trunk/libgcc/fp-bit.c: In function '__muldf3':
../../../ORIG/trunk/libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in
the insn
 }
 ^
(insn 804 311 318 28 (set (reg:SI 147 t)
(eq:SI (and:SI (subreg:SI (reg/v:DI 205 [ high ]) 0)
(const_int 1 [0x1]))
(const_int 0 [0]))) "../../../ORIG/trunk/libgcc/fp-bit.c":881 -1
 (nil))
../../../ORIG/trunk/libgcc/fp-bit.c:944:1: error: shared rtx
(subreg:SI (reg/v:DI 205 [ high ]) 0)
../../../ORIG/trunk/libgcc/fp-bit.c:944:1: internal compiler error: internal
consistency failure
0x8386b17 verify_rtx_sharing
../../ORIG/trunk/gcc/emit-rtl.c:2743
0x8386a28 verify_rtx_sharing
../../ORIG/trunk/gcc/emit-rtl.c:2758
0x8386a28 verify_rtx_sharing
../../ORIG/trunk/gcc/emit-rtl.c:2758
0x8386a28 verify_rtx_sharing
../../ORIG/trunk/gcc/emit-rtl.c:2758
0x8386feb verify_insn_sharing
../../ORIG/trunk/gcc/emit-rtl.c:2829
0x838b256 verify_rtl_sharing()
../../ORIG/trunk/gcc/emit-rtl.c:2852
0x8606233 execute_function_todo
../../ORIG/trunk/gcc/passes.c:1982
0x8606a9b do_per_function
../../ORIG/trunk/gcc/passes.c:1649
0x8606c1d execute_todo
../../ORIG/trunk/gcc/passes.c:2015

It looks that re-enabled RTL sharing verification reveals some rtl sharing
issue of this target.

[Bug target/78426] [7 Regression] wrong code with strncmp on SH

[kkojima at gcc dot gnu.org]

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

--- Comment #5 from Kazumoto Kojima  ---
Fixed on 5/6 branches too.

[Bug target/78426] [7 Regression] wrong code with strncmp on SH

[kkojima at gcc dot gnu.org]

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

--- Comment #4 from Kazumoto Kojima  ---
Author: kkojima
Date: Tue Nov 29 23:23:30 2016
New Revision: 242982

URL: https://gcc.gnu.org/viewcvs?rev=242982=gcc=rev
Log:
Backported from mainline
2016-11-19  Kaz Kojima  

PR target/78426
* config/sh/sh-mem.cc (sh_expand_cmpnstr): Use copy_to_mode_reg
instead of force_reg.
(sh_expand_setmem): Likewise.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/sh/sh-mem.cc

[Bug target/78426] [7 Regression] wrong code with strncmp on SH

[kkojima at gcc dot gnu.org]

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

--- Comment #3 from Kazumoto Kojima  ---
Author: kkojima
Date: Tue Nov 29 23:20:28 2016
New Revision: 242981

URL: https://gcc.gnu.org/viewcvs?rev=242981=gcc=rev
Log:
Backported from mainline
2016-11-19  Kaz Kojima  

PR target/78426
* config/sh/sh-mem.cc (sh_expand_cmpnstr): Use copy_to_mode_reg
instead of force_reg.
(sh_expand_setmem): Likewise.


Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/sh/sh-mem.cc

[Bug target/66358] [5/6/7 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232

[kkojima at gcc dot gnu.org]

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

--- Comment #24 from Kazumoto Kojima  ---
(In reply to David Binderman from comment #23)
> Problem seems to have gone away with gcc version 6.1.1, dated 20160621

Thanks for your report.  I've confirmed that the testcases don't
fail with the head of 5/6/7 branches on sh4-unknown-linux-gnu.
I think that now the issue is latent on those branches, though.
Register allocation has the unstable nature and we could see
the issue again when R0 is allocated with the old RA like in the way
which #14 describes.

[Bug target/78426] [7 Regression] wrong code with strncmp on SH

[kkojima at gcc dot gnu.org]

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

--- Comment #1 from Kazumoto Kojima  ---
Author: kkojima
Date: Sat Nov 19 13:59:47 2016
New Revision: 242622

URL: https://gcc.gnu.org/viewcvs?rev=242622=gcc=rev
Log:
PR target/78426
* config/sh/sh-mem.cc (sh_expand_cmpnstr): Use copy_to_mode_reg
instead of force_reg.
(sh_expand_setmem): Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh-mem.cc

[Bug target/78426] New: [7 Regression] wrong code with strncmp on SH

[kkojima at gcc dot gnu.org]

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

Bug ID: 78426
   Summary: [7 Regression] wrong code with strncmp on SH
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kkojima at gcc dot gnu.org
  Target Milestone: ---
Target: sh-*-*

Execution fails for gcc.c-torture/execute/20050218-1.c here:

  if (strncmp (x + j, a[i], strlen (a[i])) != 0)
return 2;
  j += strlen (a[i]);

It looks that sh_expand_cmpnstr clobbers the length result of the 1st
strlen which is shared with the result of 2nd strlen.  I'm preparing
a patch.

[Bug target/77610] [sh] memcpy is wrongly inlined even for large copies

[kkojima at gcc dot gnu.org]

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

--- Comment #3 from Kazumoto Kojima  ---
Created attachment 39642
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39642=edit
patch to add default threshold

256 sounds reasonable to me.  Does the attached patch work for you?

[Bug target/77610] [sh] memcpy is wrongly inlined even for large copies

[kkojima at gcc dot gnu.org]

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

Kazumoto Kojima  changed:

   What|Removed |Added

 CC||kkojima at gcc dot gnu.org

--- Comment #1 from Kazumoto Kojima  ---
(In reply to Rich Felker from comment #0)

Do you have any idea for reasonable size?  Or do you prefer some options
like -mno-prefer-expand-block-move / -mexpand-block-move-threshold= ?

[Bug target/71045] [SH] gcc.dg/torture/pr68264.c -O0 and -Os failures

[kkojima at gcc dot gnu.org]

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

--- Comment #1 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #0)
> Kaz, do you know what's going wrong there?  Some silent wrong code related
> to fenv maybe?

Maybe, though I have no idea for what is going on.
You can see that those tests fail on several other targets:

powerpc-ibm-aix7.1.0.0
https://gcc.gnu.org/ml/gcc-testresults/2016-05/msg00925.html
x86_64-unknown-freebsd9.3
https://gcc.gnu.org/ml/gcc-testresults/2016-05/msg00932.html
i386-unknown-freebsd10.3
https://gcc.gnu.org/ml/gcc-testresults/2016-05/msg00919.html

[Bug target/70416] [SH]: error: 'asm' operand requires impossible reload when building ruby2.3

[kkojima at gcc dot gnu.org]

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

--- Comment #12 from Kazumoto Kojima  ---
Created attachment 38105
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38105=edit
reduced test case for -O2 -fpic

reload1.c:reload_as_needed function generates the error message with
error_for_asm when checking if reload insns are valid.  The problematic
reload insn is:

(gdb) fr 1
#1  0x08636702 in reload_as_needed (live_known=live_known@entry=1)
at ../../ORIG/trunk/gcc/reload1.c:4698
4698 "impossible reload");
(gdb) call debug_rtx(p) 
(insn 516 508 510 18 (set (reg:SI 0 r0)
(plus:SI (reg:SI 2 r2)
(const_int 4 [0x4]))) xxx.i:100 67 {*addsi3}
 (nil))

which is invalid.  Looks that that complex asm expression requires
an invalid add insn on SH to reload its operand of that asm insn.
Unfortunately I have no idea to fix this issue.

[Bug target/70216] [SH] Implement __builtin_trap

[kkojima at gcc dot gnu.org]

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

--- Comment #2 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #1)
> For sh4-linux this option should be enabled by default with some useful trap
> number value.  Which trap number should be used in this case?

I think that # less than 0x20 are reserved by kernel, gdb uses 0x20
and 0xc3 and gcc uses 0x33 for profiling.  Perhaps 0x54 (ascii 'T')
or something?

[Bug middle-end/23868] [4.9/5/6 regression] builtin_apply uses wrong mode for multi-hard-register return values

[kkojima at gcc dot gnu.org]

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

--- Comment #29 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #28)
> Can anybody comment on the state of this problem here?  Were the two commits
> in comment #2 and comment #3 merged into mainline at some point?

AFAIK, those patches weren't merged.  I guess that other changes for
apply/return buitins fix the failure, though I'm not sure if the original
issue went away completely.

[Bug rtl-optimization/29854] reload_combine looses track of uses

[kkojima at gcc dot gnu.org]

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

--- Comment #7 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #6)
> Looking at the current code in postreload.c, it seems that the patch somehow
> made it into mainline at some point.  Although some of the lines now look a
> bit different.  Can we close this PR as "works for me"?

That sounds reasonable.

[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat

[kkojima at gcc dot gnu.org]

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

--- Comment #19 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #17)
> Kaz, what do you think?

LGTM and looks like we have no choice for 5/4.9.

[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat

[kkojima at gcc dot gnu.org]

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

--- Comment #16 from Kazumoto Kojima  ---
(In reply to Rich Felker from comment #15)

Maybe.  There are other cases of address computations which could be
shared or simplified, as you know.  Again very restrictive branches
and loads will make things hard.

[Bug target/69713] Invalid code of optimization in SH

[kkojima at gcc dot gnu.org]

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

--- Comment #6 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #5)
> Anyway, I think this could be applied to GCC 5 and GCC 6.  Kaz, what do you
> think?

Looks fine to me.  Please go ahead.

[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat

[kkojima at gcc dot gnu.org]

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

--- Comment #14 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #13)
> Good question indeed.  Kaz, maybe you remember anything?

With my vague recollection, they were already there when I had looked
into them for the first time.

I guess that SH jump stuff was built with stacking many things so to
avoid strong restrictions of ISA.  Rewriting them from a current view
of gcc is a good thing, though perhaps it'll be a big hummer.

[Bug target/68277] [5/6 Regression] [SH]: error: insn does not satisfy its constraints when compiling erlang

[kkojima at gcc dot gnu.org]

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

--- Comment #11 from Kazumoto Kojima  ---
(In reply to Kazumoto Kojima from comment #10)
> I'll report back when the regression test currently running is done.

I've confirmed that there are no new failures with the new patch on
sh4-unknown-linux-gnu.
BTW, the ICE for gcc.dg/atomic/c11-atomic-exec-4.c -Os pops up again
even with the unmodified tree.  So we have no regressions at all.

[Bug target/68277] [5/6 Regression] [SH]: error: insn does not satisfy its constraints when compiling erlang

[kkojima at gcc dot gnu.org]

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

--- Comment #10 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #9)
> At the current (lack of) pace I don't know when all of that will be done. 
> So my idea was to at least reduce the R0 problem for users by making LRA the
> default in GCC 6.  If we have to add the 2nd postreload temporarily, so be
> it.  When the other solutions become more mature and stable, we can remove
> the 2nd postreload thing again.

I don't object.  Please go ahead.

I'll report back when the regression test currently running is done.

[Bug target/68277] [5/6 Regression] [SH]: error: insn does not satisfy its constraints when compiling erlang

[kkojima at gcc dot gnu.org]

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

--- Comment #7 from Kazumoto Kojima  ---
(In reply to Kazumoto Kojima from comment #6)
I've changed the predicate of the 2nd operand to arith_operand instead
of const_int_operand in your patch and run testsuite.  There is one new
failure:

FAIL: gfortran.dg/pr65450.f90   -O3 -g  execution test

which is

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Weird.  I'm afraid that even my first patch makes wrong codes silently,
though it doesn't fail for the above test.

[Bug target/68277] [5] [SH]: error: insn does not satisfy its constraints when compiling erlang

[kkojima at gcc dot gnu.org]

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

--- Comment #1 from Kazumoto Kojima  ---
Created attachment 36686
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36686=edit
reduced test case for -O1

It fails on trunk too.  It seems that the problematic add insn

(insn 765 764 300 46 (set (reg:SI 10 r10)
(plus:SI (reg:SI 1 r1)
(const_int 4 [0x4]))) add3i.c:7 66 {*addsi3}
 (nil))

is generated with the old reload to load a memory address of
the complex atomic_compare_and_swapsi_soft_gusa insn and
postreload complains about that insn.

[Bug target/68277] [5/6 Regression] [SH]: error: insn does not satisfy its constraints when compiling erlang

[kkojima at gcc dot gnu.org]

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

Kazumoto Kojima  changed:

   What|Removed |Added

Summary|[5] [SH]: error: insn does  |[5/6 Regression] [SH]:
   |not satisfy its constraints |error: insn does not
   |when compiling erlang   |satisfy its constraints
   ||when compiling erlang

--- Comment #2 from Kazumoto Kojima  ---
Here is a workaround.  It changes the total text size of CSiBE
from 3310543 to 3310579 which looks simply noise.

diff --git a/gcc/config/sh/sh.md b/gcc/config/sh/sh.md
index 557a0f0..ad39a3c 100644
--- a/gcc/config/sh/sh.md
+++ b/gcc/config/sh/sh.md
@@ -2236,6 +2236,23 @@
 }
   [(set_attr "type" "arith")])

+;; Old reload might generate add insns directly for the memory address
+;; of complex insns like synchronization insns when reloading.
+(define_insn_and_split "*addsi3"
+  [(set (match_operand:SI 0 "arith_reg_dest" "=r")
+   (plus:SI (match_operand:SI 1 "arith_reg_operand" "r")
+(match_operand:SI 2 "const_int_operand" "I08")))]
+  "TARGET_SH1 && !sh_lra_p ()
+   && reload_completed
+   && !reg_overlap_mentioned_p (operands[0], operands[1])"
+  "#"
+  "&& reload_completed"
+  [(set (match_dup 0) (match_dup 1))
+   (set (match_dup 0) (plus:SI (match_dup 0) (match_dup 2)))]
+{
+}
+  [(set_attr "type" "arith")])
+
 (define_insn_and_split "*addsi3"
   [(set (match_operand:SI 0 "arith_reg_dest" "=r,r")
(plus:SI (match_operand:SI 1 "arith_reg_operand" "%0,r")

though I'm not sure that it's ok to add that hack to fix this corner
case.  There are two "new" failures with gcc testsuite:

FAIL: gcc.dg/atomic/c11-atomic-exec-4.c   -Os  (internal compiler error)
FAIL: gcc.dg/atomic/c11-atomic-exec-4.c   -Os  (test for excess errors)

which is not really new because these errors have popped up randomly
in our testresults.  After all, unfortunately, some SH synchronization
insns are too complex for the old reload.  You can avoid this PR and
c11-atomic-exec-4.c ICE with -mlra.
Oleg, do you have any ideas?

[Bug target/68277] [5/6 Regression] [SH]: error: insn does not satisfy its constraints when compiling erlang

[kkojima at gcc dot gnu.org]

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

--- Comment #4 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #3)
> I haven't read reload.*, but my speculation is that if something in reload
> instantiates that rtx with an imm8 constant to calculate addresses, it might
> also try to instantiate it with reg = reg + reg if the constant doesn't fit
> into imm8.  Maybe we just don't hit the case (yet).  So it's probably safer
> to allow reg = reg + reg, too.

Sounds reasonable.

> I guess those "new" failures are R0 related?

Yep, spill failure in R0.  Our old friend.

[Bug target/68277] [5/6 Regression] [SH]: error: insn does not satisfy its constraints when compiling erlang

[kkojima at gcc dot gnu.org]

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

--- Comment #6 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #5)
> Could you please add it to your nightly test run and commit it if there no
> other new failures?  I'll be away for a few days...

OK, will do.

> Hm ... so maybe for now we should enable -mlra by default and add a 2nd
> postreload CSE pass as you have tried in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67732#c2 ?

I think that that trial and AMS show the backend like SH requires
something even for the old reload, though I'm not sure that
the 2nd postreload_cse is the right thing for that.

[Bug target/68091] [6 Regression] [SH] internal compiler error: in expand_vec_cond_expr, at optabs.c:5391

[kkojima at gcc dot gnu.org]

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

--- Comment #3 from Kazumoto Kojima  ---
Author: kkojima
Date: Mon Oct 26 11:30:11 2015
New Revision: 229336

URL: https://gcc.gnu.org/viewcvs?rev=229336=gcc=rev
Log:
[config/sh/sh.c] Fix PR68091: Return false for non shmedia targets in
sh_vector_mode_supported_p

PR target/68091
* config/sh/sh.c (sh_vector_mode_supported_p): Use
TARGET_SHMEDIA_FPU instead of TARGET_FPU_ANY.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.c

[Bug target/68091] [6 Regression] [SH] internal compiler error: in expand_vec_cond_expr, at optabs.c:5391

[kkojima at gcc dot gnu.org]

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

--- Comment #2 from Kazumoto Kojima  ---
OK, I'll commit it as a quick fix if the usual tests done successfully.

[Bug target/68091] New: [6 Regression] [SH] internal compiler error: in expand_vec_cond_expr, at optabs.c:5391

[kkojima at gcc dot gnu.org]

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

Bug ID: 68091
   Summary: [6 Regression] [SH] internal compiler error: in
expand_vec_cond_expr, at optabs.c:5391
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kkojima at gcc dot gnu.org
  Target Milestone: ---
Target: sh4*-*-*

The recent change of middle-end for vector operations causes some new
ICEs in the testsuite on sh4.  A Typical one is:

trunk/gcc/testsuite/g++.dg/ext/vector27.C:12:16: internal compiler error: in
expand_vec_cond_expr, at optabs.c:5391
0x877369f expand_vec_cond_expr(tree_node*, tree_node*, tree_node*, tree_node*,
rtx_def*)
../../ORIG/trunk/gcc/optabs.c:5390
0x8588a0e do_store_flag
../../ORIG/trunk/gcc/expr.c:11052
0x8588a0e expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../ORIG/trunk/gcc/expr.c:9010
0x846bb89 expand_gimple_stmt_1
../../ORIG/trunk/gcc/cfgexpand.c:3617

It seems that the middle-end change reveals a target problem that
sh_vector_mode_supported_p returns true even the target has no mov
insns for some vector modes.

 bool
 sh_vector_mode_supported_p (machine_mode mode)
 {
   if (TARGET_FPU_ANY
   && ((mode == V2SFmode)
  || (mode == V4SFmode)
  || (mode == V16SFmode)))
 return true;
   ...

It looks that this TARGET_FPU_ANY should be TARGET_SHMEDIA_FPU in
the first place, because all movv* patterns in sh.md are written for
SHMEDIA only.  The ICEs seen only on sh4 went away with replacing
TARGET_FPU_ANY with TARGET_SHMEDIA_FPU in sh_vector_mode_supported_p.
Although I know that we shouldn't add the new sh5 hunks, I think
that this change is rather a preparation to zap them out.

[Bug target/67732] [SH] Strange LRA addsi3 usage

[kkojima at gcc dot gnu.org]

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

--- Comment #2 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #1)
> There are some improvements with LRA, but the regression in teem-1.6.0-src
> 
>  total:   1105728 -> 1122288+16560 / +1.497656 %
> 
> outweighs all of the improvements.

teem shows problems with -mlra.  I'm not sure whether all of them
are pure RA issues or not, though.  Typical inflation with LRA in
teem would be oparations against float matrices.  An example

void
foo (float mat[])
{
  float *p = [16];

  *--p = 0.0;  *--p = 0.0;  *--p = 0.0;  *--p = 0.0;
  *--p = 0.0;  *--p = 0.0;  *--p = 0.0;  *--p = 0.0;
}

shows ~20% code size regression with -O2.  At .ira, it looks like:

r165 := 0.0
...
r167 := r162 + 56
mem[r167] := r165
r170 := r162 + 52
mem[r170] := r165
r173 := r162 + 48
mem[r173] := r165
...

and the old reload generates:

fr1 := 0.0
...
r1 := r4
r1 := r1 + 56
mem[r1] := fr1
r1 := r4
r1 := r1 + 52
mem[r1] := fr1
r1 := r4
r1 := r1 + 48
mem[r1] := fr1
...

Then postreload fixes it up to

fr1 := 0.0
...
r1 := r1 + 56
mem[r1] := fr1
r1 := r1 - 4
mem[r1] := fr1
r1 := r1 - 4
mem[r1] := fr1
...

OTOH, LRA generates:
fr1 := 0.0
...
r1 := r4 + 56
mem[r1] := fr1
r1 := r4 + 52
mem[r1] := fr1
r1 := r4 + 48
mem[r1] := fr1
...

Unfortunately postreload doesn't fix it up and split2 makes it
into the similar code generated with the old reload.
I've run postreload_cse again just after pass_split_after_reload
and got same text size with the old reload for the above example
at -mlra.  The CSiBE total sizes are:

3303471  -mno-lra without 2nd postreload_cse
3315689  -mlra without 2nd postreload_cse
3293271  -mno-lra with 2nd postreload_cse
3299813  -mlra with 2nd postreload_cse

and teem only comparison is:

1079932  -mno-lra without 2nd postreload_cse
1094468  -mlra without 2nd postreload_cse
1073104  -mno-lra with 2nd postreload_cse
1082764  -mlra with 2nd postreload_cse

[Bug target/67716] [5] [SH]: Miscompiles libraw: Assembler: unaligned opcodes detected in executable segment

[kkojima at gcc dot gnu.org]

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

--- Comment #20 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #19)

I have no objection.  I thought that the fix for PR67723 on trunk is first,
though either way will be fine.

[Bug target/67716] [5] [SH]: Miscompiles libraw: Assembler: unaligned opcodes detected in executable segment

[kkojima at gcc dot gnu.org]

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

--- Comment #17 from Kazumoto Kojima  ---
Author: kkojima
Date: Tue Sep 29 05:36:01 2015
New Revision: 228228

URL: https://gcc.gnu.org/viewcvs?rev=228228=gcc=rev
Log:
PR target/67716
* [SH] Implement targetm.override_options_after_change hook
  so to avoid resetting loop, jump and function alignment values with
  function-wise optimization flags.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.c

[Bug target/67716] [5] [SH]: Miscompiles libraw: Assembler: unaligned opcodes detected in executable segment

[kkojima at gcc dot gnu.org]

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

--- Comment #18 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #16)
> Regardless of those, Kaz, can you please commit attachment 36397 [details]? 
> Then I can handle the other cases on top of that.

Done.

[Bug target/67391] [SH] Convert clrt addc to normal add insn

[kkojima at gcc dot gnu.org]

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

--- Comment #29 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #26)
> OK, I'll commit attachment 36400 [details] to trunk then.  Do you think it's
> safe for GCC 5 branch, too?  Or shall we test it on the branch?

I think so, though we should test it on 5-branch.  I'm running tests
on 5-branch now.

[Bug target/67391] [SH] Convert clrt addc to normal add insn

[kkojima at gcc dot gnu.org]

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

--- Comment #25 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #24)
> Could you please re-run that test with attachment 36400 [details]?

Yes, 36400 fixes that failure:
PASS: gcc.c-torture/compile/sync-3.c   -O1   (test for warnings, line )

[Bug target/67391] [SH] Convert clrt addc to normal add insn

[kkojima at gcc dot gnu.org]

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

--- Comment #31 from Kazumoto Kojima  ---
(In reply to Kazumoto Kojima from comment #29)

Tests for 5-branch with/without -mlra completed with no new failures
on sh4-unknown-linux-gnu.

[Bug target/67391] [SH] Convert clrt addc to normal add insn

[kkojima at gcc dot gnu.org]

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

--- Comment #23 from Kazumoto Kojima  ---
My tests are done.  Only
gcc.c-torture/compile/sync-3.c   -O1  (internal compiler error)
for -mno-lra is the new test that fails.

[Bug target/67391] [SH] Convert clrt addc to normal add insn

[kkojima at gcc dot gnu.org]

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

--- Comment #17 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #16)
> Kaz, does this patch fix the issue in c#11 ?

Yep, it fixes that ICE.  Thanks!
My 36387 trial patch can cause a similar problem with PR64533 when sp
is taken as the scratch register.  I've modified your patch with

diff --git a/config/sh/sh.md b/config/sh/sh.md
index 3e6a244..8e08d0b 100644
--- a/config/sh/sh.md
+++ b/config/sh/sh.md
@@ -2197,7 +2197,7 @@
   [(set (match_operand:SI 0 "arith_reg_dest" "=r,,")
(plus:SI (match_operand:SI 1 "arith_reg_operand" "%0,r,r")
 (match_operand:SI 2 "arith_or_int_operand" "rI08,r,n")))
-   (clobber (match_scratch:SI 3 "=X,X,"))]
+   (clobber (match_scratch:SI 3 "=X,X,"))]
   "TARGET_SH1"
   "@
add %2,%0

Now the full tests on sh4-unknown-linux-gnu are running.  I'll report
the results when completed.

[Bug target/67716] [5] [SH]: Miscompiles libraw: Assembler: unaligned opcodes detected in executable segment

[kkojima at gcc dot gnu.org]

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

--- Comment #11 from Kazumoto Kojima  ---
Created attachment 36397
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36397=edit
patch for targetm.override_options_after_change

Could you try this patch?

What is going on:

1. align_jumps (global_options.x_align_jumps) is set to 1 as the default value.
2. sh_override_option changes it to 2.
3. pragma handling saves it and sets it back to the default value 1.
4. compile function where align_jumps is 1.
   This results a bad code with wrong alignments.
5. Restore align_jumps at the end of compilation of this unit.

I've noticed that other targets define TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE
and avoid this issue of pragma for optimization.  See aarch64 or alpha's
*_override_options_after_change for example.

[Bug target/67716] [5] [SH]: Miscompiles libraw: Assembler: unaligned opcodes detected in executable segment

[kkojima at gcc dot gnu.org]

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

--- Comment #9 from Kazumoto Kojima  ---
Created attachment 36395
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36395=edit
reduced test case

This one fails with the same asm error with my sh-elf c++ for -g -O1.
It looks that
#pragma GCC optimize("no-aggressive-loop-optimizations")
causes unaligned insn after jump table data:

.align 2
.L4:
.byte   .L3-.L5
.byte   .L2-.L5
.byte   .L2-.L5
.byte   .L2-.L5
.byte   .L6-.L5
.byte   .L2-.L5
.byte   .L6-.L5
.byte   .L2-.L5
.byte   .L2-.L5
.byte   .L2-.L5
.byte   .L7-.L5
.L3:
mov.l   .L16,r1<<<- not aligned!

[Bug target/67716] [5] [SH]: Miscompiles libraw: Assembler: unaligned opcodes detected in executable segment

[kkojima at gcc dot gnu.org]

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

--- Comment #13 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #12)
> Maybe we should move some
> more of the sh_option_override things sh_override_options_after_change?  I
> don't know ...

I thought the same thing too.  From the implementations for other targets,
the align related flags are enough, I guess.  I could be wrong, though.

[Bug target/67716] [5] [SH]: Miscompiles libraw: Assembler: unaligned opcodes detected in executable segment

[kkojima at gcc dot gnu.org]

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

--- Comment #15 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #14)
> Yes, there are issues.  I've created PR 67723.

Ah, you are right.  I forgot -m optimization options at all.

[Bug target/67391] [SH] Convert clrt addc to normal add insn

[kkojima at gcc dot gnu.org]

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

--- Comment #21 from Kazumoto Kojima  ---
No new failures with -mlra here too.  The test without -mlra is still
running, though there is a new failure:

/home/ldroot/dodes/xsh-gcc/gcc/xgcc -B/home/ldroot/dodes/xsh-gcc/gcc/
-fno-diagnostics-show-caret -fdiagnostics-color=never -O1 -ffat-lto-objects -c
-o sync-3.o
/exp/ldroot/dodes/LOCAL/trunk/gcc/testsuite/gcc.c-torture/compile/sync-3.c
/exp/ldroot/dodes/LOCAL/trunk/gcc/testsuite/gcc.c-torture/compile/sync-3.c: In
function 'test_op_ignore':
/exp/ldroot/dodes/LOCAL/trunk/gcc/testsuite/gcc.c-torture/compile/sync-3.c:75:3:
note: '__sync_fetch_and_nand' changed semantics in GCC 4.4
/exp/ldroot/dodes/LOCAL/trunk/gcc/testsuite/gcc.c-torture/compile/sync-3.c: In
function 'test_fetch_and_op':
/exp/ldroot/dodes/LOCAL/trunk/gcc/testsuite/gcc.c-torture/compile/sync-3.c:164:1:
error: insn does not satisfy its constraints:
(insn 729 728 42 2 (set (reg:SI 7 r7)
(plus:SI (reg:SI 0 r0)
(const_int 0 [0])))
/exp/ldroot/dodes/LOCAL/trunk/gcc/testsuite/gcc.c-torture/compile/sync-3.c:104
66 {*addsi3}
 (nil))
/exp/ldroot/dodes/LOCAL/trunk/gcc/testsuite/gcc.c-torture/compile/sync-3.c:164:1:
internal compiler error: in extract_constrain_insn, at recog.c:2200
0x85f822f _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../LOCAL/trunk/gcc/rtl-error.c:109
0x85f8258 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../LOCAL/trunk/gcc/rtl-error.c:120
0x85c5430 extract_constrain_insn(rtx_insn*)
../../LOCAL/trunk/gcc/recog.c:2200
0x85a6935 reload_cse_simplify_operands
../../LOCAL/trunk/gcc/postreload.c:408
0x85a7e9a reload_cse_simplify
../../LOCAL/trunk/gcc/postreload.c:194
0x85a7e9a reload_cse_regs_1
../../LOCAL/trunk/gcc/postreload.c:233
0x85a7fda reload_cse_regs
../../LOCAL/trunk/gcc/postreload.c:81
0x85a7fda execute
../../LOCAL/trunk/gcc/postreload.c:2350

[Bug target/67716] [5] [SH]: Miscompiles libraw: Assembler: unaligned opcodes detected in executable segment

[kkojima at gcc dot gnu.org]

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

--- Comment #1 from Kazumoto Kojima  ---
(In reply to John Paul Adrian Glaubitz from comment #0)
> I have taken the build directory as is and created a compressed tar ball
> from it which can be downloaded here:

Could you send .i and .s files with adding -save-temps to the problematic
compilation as usual?  The build directory is useful only for the same
debian environment.

[Bug target/67391] [SH] Convert clrt addc to normal add insn

[kkojima at gcc dot gnu.org]

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

--- Comment #14 from Kazumoto Kojima  ---
Created attachment 36387
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36387=edit
a trial

Although a bit ugly, how about adding pattern using scratch reg?
Does it get the original clrt+addc issue back again?

[Bug target/67391] [SH] Convert clrt addc to normal add insn

[kkojima at gcc dot gnu.org]

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

--- Comment #6 from Kazumoto Kojima  ---
(In reply to Kazumoto Kojima from comment #5)
> Yes, this is clearly a 5/6 regression.  My test has passed C and C++ part
> with no new failures.  I'll report back when test completed.

Test completed with no new failures on sh4-unknown-linux-gnu.

[Bug target/67391] [SH] Convert clrt addc to normal add insn

[kkojima at gcc dot gnu.org]

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

--- Comment #11 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #10)
> The core issue should be fixed.  I'd like to keep this PR open though for a
> while.

I've got

/exp/ldroot/dodes/INTEST/trunk/gcc/testsuite/gfortran.dg/matmul_6.f90:19:0:
Error: could not split insn
(insn 2778 2779 94 (set (reg:SI 3 r3)
(plus:SI (reg:SI 3 r3 [316])
(const_int 372 [0x174])))
/exp/ldroot/dodes/INTEST/trunk/gcc/testsuite/gfortran.dg/matmul_6.f90:20 64
{*addsi3_compact}
 (nil))

in my local tree.  Clearly it was hidden by the wrong extra checks.

[Bug target/67391] [SH] Convert clrt addc to normal add insn

[kkojima at gcc dot gnu.org]

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

--- Comment #3 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #1)
> Kaz, do you have any memory of the extra checks?  Isn't it enough to just
> accept the addsi3 pattern as "rC = rA + {rB|imm}" and insert the reg-reg
> copy after register allocation via split2, as it's already done?  Why are
> the reg overlap checks needed during matching of the patterns?

Ugh, those checks look just wrong and I can't remind why I've
added them.  33707 didn't do that and checked overlapping at
the split condition only.  Perhaps I mixed up the final patch
with the one of test codes to collect CSiBE results.  You can
install the above patch as the rather obvious one, though I'm
running "make -k check" on sh4-unknown-linux-gnu.  Sorry for
adding that thinko.

[Bug target/67391] [SH] Convert clrt addc to normal add insn

[kkojima at gcc dot gnu.org]

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

--- Comment #5 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #4)
> I've just checked, the code is also present in GCC 5.  Because of the funny
> side effects even with LRA disabled (this PR) I'd like to backport this to
> the GCC 5 branch, too.

Yes, this is clearly a 5/6 regression.  My test has passed C and C++ part
with no new failures.  I'll report back when test completed.

[Bug target/67573] [SH] wrong code generated for libstdc++-v3/src/c++11/cxx11-shim_facets.cc at -mlra

[kkojima at gcc dot gnu.org]

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

--- Comment #11 from Kazumoto Kojima  ---
Author: kkojima
Date: Sun Sep 20 23:54:03 2015
New Revision: 227953

URL: https://gcc.gnu.org/viewcvs?rev=227953=gcc=rev
Log:
PR target/67573
* config/sh/sh.md: Add early clobber to scratch operand of *call_*pcrel
insn_and_split so to avoid CSEd scratch reg.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/sh/sh.md

[Bug target/67657] [SH][5]: internal compiler error: in cselib_record_set, at cselib.c:2396 when compiling libjpeg-turbo

[kkojima at gcc dot gnu.org]

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

--- Comment #2 from Kazumoto Kojima  ---
Created attachment 36356
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36356=edit
reduced test case

I can reproduce it with trunk rev. 227929 but can't with 227887.
Clearly very fragile.
It looks that the insn

(insn:TI 2292 1994 1995 11 (parallel [
(set (reg/v/f:SI 2 r2 [orig:320 outptr ] [320])
(mem/f:SI (reg:SI 2 r2) [2 MEM[base: _145, offset: 0B]+0 S4
A32]))
(set (reg:SI 2 r2)
(plus:SI (reg:SI 2 r2)
(const_int 4 [0x4])))
]) foo.c:61 253 {movsi_ie}
 (expr_list:REG_UNUSED (reg:SI 2 r2)
(expr_list:REG_INC (reg:SI 2 r2)
(nil

makes cselib unhappy.  It looks wrong anyway.

It seems that

;;  mov.l   @(r0,r9),r1
;;  mov r1,r0   ->  mov @(r0,r9),r0
(define_peephole2
  [(set (match_operand:SI 0 "arith_reg_dest")
(match_operand:SI 1 "general_movsrc_operand"))
   (set (match_operand:SI 2 "arith_reg_dest")
(match_dup 0))]
  "TARGET_SH1 && peep2_reg_dead_p (2, operands[0])"
  [(const_int 0)]
{
  sh_check_add_incdec_notes (emit_move_insn (operands[2], operands[1]));
})

took 2 insns

(insn 595 1951 1954 20 (set (reg:SI 0 r0)
(mem/f:SI (post_inc:SI (reg:SI 2 r2)) [2 MEM[base: _145, offset: 0B]+0
S4 A32])) foo.c:61 253 {movsi_ie}
 (expr_list:REG_UNUSED (reg:SI 2 r2)
(expr_list:REG_INC (reg:SI 2 r2)
(nil

(insn 1954 595 1994 20 (set (reg/v/f:SI 2 r2 [orig:320 outptr ] [320])
(reg:SI 0 r0)) foo.c:61 253 {movsi_ie}
 (expr_list:REG_DEAD (reg:SI 0 r0)
(nil)))

into the insn 2292.  Oleg, could you take a look?

[Bug target/67573] [SH] wrong code generated for libstdc++-v3/src/c++11/cxx11-shim_facets.cc at -mlra

[kkojima at gcc dot gnu.org]

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

--- Comment #10 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #9)
> I think this should be backported to GCC 5.  Even if it might not be
> triggered often, there is a possibility for silent wrong-code bugs.

OK, will do.

[Bug target/66609] [sh] Relative address expressions bind at as-time, even if symbol is weak

[kkojima at gcc dot gnu.org]

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

--- Comment #6 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #5)
> Kaz, do you think it's OK to backport this to GCC 5?  It looks like the
> patch is not so intrusive...

Changing relocation is always intrusive, I think.  I won't
object to backport it, though.  The patch does the right thing
and will affect only very limited cases.

[Bug target/67573] [SH] wrong code generated for libstdc++-v3/src/c++11/cxx11-shim_facets.cc at -mlra

[kkojima at gcc dot gnu.org]

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

--- Comment #5 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #4)
> Maybe FPSCR_STAT_REG should be in the clobber list, too?  Otherwise stores
> of FP exception bits etc (get_fpscr builtin) could be wrongly CSE'd across
> function calls... However, I don't know if this is a problem at the moment.

I'm not sure whether it's a problem or not ATM too.  The original
issue happens with the aggressive allocation by LRA.
If the scenario for FPSCR_MODES_REG is real, it could be seen
with the old RA already.

[Bug target/67573] [SH] wrong code generated for libstdc++-v3/src/c++11/cxx11-shim_facets.cc at -mlra

[kkojima at gcc dot gnu.org]

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

Kazumoto Kojima  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Kazumoto Kojima  ---
Fixed on trunk.
Oleg, now we can propose to make -mlra default on trunk.

[Bug target/67573] [SH] wrong code generated for libstdc++-v3/src/c++11/cxx11-shim_facets.cc at -mlra

[kkojima at gcc dot gnu.org]

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

--- Comment #6 from Kazumoto Kojima  ---
Author: kkojima
Date: Thu Sep 17 00:12:57 2015
New Revision: 227837

URL: https://gcc.gnu.org/viewcvs?rev=227837=gcc=rev
Log:
PR target/67573
* config/sh/sh.md: Add early clobber to scratch operand of *call_*pcrel
insn_and_split so not to CSE scratch reg.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.md

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
Bug 55212 depends on bug 67573, which changed state.

Bug 67573 Summary: [SH] wrong code generated for 
libstdc++-v3/src/c++11/cxx11-shim_facets.cc at -mlra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67573

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug target/67573] [SH] wrong code generated for libstdc++-v3/src/c++11/cxx11-shim_facets.cc at -mlra

[kkojima at gcc dot gnu.org]

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

--- Comment #2 from Kazumoto Kojima  ---
It seems that LRA allocates r7 for the scratch reg at

(define_insn_and_split "call_value_pcrel"
  [(set (match_operand 0 "" "=rf")
(call (mem:SI (match_operand:SI 1 "symbol_ref_operand" ""))
  (match_operand 2 "" "")))
   (use (reg:SI FPSCR_MODES_REG))
   (use (reg:SI PIC_REG))
   (clobber (reg:SI PR_REG))
   (use (match_scratch:SI 3 "=r"))]

in the problematic case and the insn

(call_insn 208 207 209 22 (parallel [
(set (reg:SI 0 r0)
(call (mem:SI (symbol_ref:SI
("_ZNKSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE4copyEPwjj") [flags
0x41]  ) [0 copy S4 A32])
(const_int 0 [0])))
(use (reg:SI 154 fpscr0))
(use (reg:SI 12 r12))
(clobber (reg:SI 146 pr))
(clobber (reg:SI 7 r7 [357]))
]) fa.cc:484 322 {call_value_pcrel}
 (expr_list:REG_EH_REGION (const_int 4 [0x4])
(expr_list:REG_CALL_DECL (symbol_ref:SI
("_ZNKSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE4copyEPwjj") [flags
0x41]  )
(nil)))
(expr_list:SI (use (reg:SI 4 r4))
(expr_list:SI (use (reg:SI 5 r5))
(expr_list:SI (use (reg:SI 6 r6))
(expr_list:SI (use (reg:SI 7 r7))
(nil))

made the following passes confused.

[Bug target/67573] [SH] wrong code generated for libstdc++-v3/src/c++11/cxx11-shim_facets.cc at -mlra

[kkojima at gcc dot gnu.org]

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

--- Comment #3 from Kazumoto Kojima  ---
I've wrongly cut call_value_pcrel.  It's

(define_insn_and_split "call_value_pcrel"
  [(set (match_operand 0 "" "=rf")
(call (mem:SI (match_operand:SI 1 "symbol_ref_operand" ""))
  (match_operand 2 "" "")))
   (use (reg:SI FPSCR_MODES_REG))
   (use (reg:SI PIC_REG))
   (clobber (reg:SI PR_REG))
   (clobber (match_scratch:SI 3 "="))]
   ...

I think that the last clobber should be

   (clobber (match_scratch:SI 3 "="))]

i.e. the scratch register is early clobbered.  With that change,
it looks the wrong code go away.  I'll come up with the tested
patch for all similar *call_*pcrel insns.

[Bug target/67573] [SH] wrong code generated for libstdc++-v3/src/c++11/cxx11-shim_facets.cc at -mlra

[kkojima at gcc dot gnu.org]

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

--- Comment #1 from Kazumoto Kojima  ---
Created attachment 36333
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36333=edit
test case

[Bug target/67573] New: [SH] wrong code generated for libstdc++-v3/src/c++11/cxx11-shim_facets.cc at -mlra

[kkojima at gcc dot gnu.org]

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

Bug ID: 67573
   Summary: [SH] wrong code generated for
libstdc++-v3/src/c++11/cxx11-shim_facets.cc at -mlra
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kkojima at gcc dot gnu.org
CC: olegendo at gcc dot gnu.org
Blocks: 55212
  Target Milestone: ---
Target: sh*-*-*

Wrong code is generated with sh-linux/sh-elf compilers for
void std::__facet_shims::__moneypunct_fill_cache<wchar_t,
true>(std::integral_constant<bool, true>, std::locale::facet const*,
std::__moneypunct_cache<wchar_t, true>*)
at "-m4 -ml -O2 -fPIC -mlra -std=gnu++11".

It uses __copy inline function and __copy calls
std::__cxx11::basic_string<wchar_t, std::char_traits,
std::allocator >::copy(wchar_t*, unsigned int, unsigned int)

with the wrong code

mov r11,r4
mov.l   .L1122,r7
mov r0,r5
mov.l   @r15,r6
mov r10,r4
bsrfr7
.LPCS203:
mov.l   r0,@(4,r15)
...
.L1122:
.long  
_ZNKSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE4copyEPwjj@PLT-(.LPCS203+2-.)

where r7 should be 0 as the last argument.  With -mno-lra,
the corresponding code is:

mov.l   .L1050,r1
mov r0,r14
mov #0,r7
mov r13,r6
mov r0,r5
bsrfr1
.LPCS191:
mov r10,r4
...

It seems that dse/dce removes mov #0, r7.

.pro_and_epilogue:

(insn 204 831 830 22 (set (reg:SI 7 r7)
(const_int 0 [0])) fa.cc:484 253 {movsi_ie}
 (nil))

.dse2 marks r7 unused:

(insn 204 831 830 22 (set (reg:SI 7 r7)
(const_int 0 [0])) fa.cc:484 253 {movsi_ie}
 (expr_list:REG_UNUSED (reg:SI 7 r7)
(nil)))

.jump2 eliminates insn 204:

DCE: Deleting insn 204
deleting insn with uid = 204.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
[Bug 55212] [SH] Switch to LRA

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #111 from Kazumoto Kojima  ---
(In reply to Kazumoto Kojima from comment #110)

It seems that those failures are the latent wrong code problem
triggered with -mlra accidentally.  I've filed it as PR67573.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #103 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #102)
> Ah!  I always wondered why those failures disappeared from your nightly
> tests.  Did you do this locally in your setup, or has this been committed at
> some time?

I did nothing.  Looks simply fragile like as other reload ICEs.
libstdc++-v3 conftest catches it, (un)fortunately.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #110 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #109)
> Maybe it also fixes the std::locale issues.  Kaz, could
> you please have a look?

It doesn't fix those failures.  I'll try to bisect that issue.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #101 from Kazumoto Kojima  ---
> Perhaps the both codes are ok, though something odd happens
> on atomic things anyway.

I've forgotten that some atomic builtins fail with spill_failure
in class 'R0_REGS' for old RA.  So libstdc++-v3 was configured
so to undefine _GLIBCXX_ATOMIC_BUILTINS for old RA and we see
the above difference.  I've tried to disable it on LRA build
and rebuild libstdc++-v3 libs.  14.exe still fails and it looks
very sensitive with code/option changes.  Weird.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #98 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #97)
> I've compared the results of r227512 without LRA and r227682 with LRA. 
> Below are the new failures.

A typical example of pr64661-x.c regressions is:
[LRA]
test_37_1:
stc gbr,r3  ! 22store_gbr   [length = 2]
mova1f,r0   ! 6 atomic_add_fetchqi_soft_tcb [length = 20]
mov #(0f-1f),r1
.align 2
mov.l   r0,@(128,gbr)
0:  mov.b   @(4,r3),r0
...

[no-LRA]
test_37_1:
mova1f,r0   ! 6 atomic_add_fetchqi_soft_tcb [length = 20]
mov #(0f-1f),r1
.align 2
mov.l   r0,@(128,gbr)
0:  mov.b   @(4,gbr),r0
...

where

(define_insn_and_split "atomic_fetch__soft_tcb"
  [(set (match_operand:QIHISI 0 "arith_reg_dest" "=")
(match_operand:QIHISI 1 "atomic_mem_operand_1" "=SraSdd"))
   ...
   (clobber (reg:SI R0_REG))
   (clobber (reg:SI R1_REG))]
  "TARGET_ATOMIC_SOFT_TCB"
{
  return "\rmova1f,r0"  "\n"
 "  .align 2"   "\n"
 "  mov #(0f-1f),r1""\n"
 "  mov.l   r0,@(%O3,gbr)"  "\n"
 "0:mov.   %1,r0"  "\n"
 ...

The .ira dump shows

(insn 6 5 7 2 (parallel [
(set (reg:QI 167)
(plus:QI (mem/v:QI (plus:SI (reg:SI 144 gbr)
(const_int 4 [0x4])) [-1  S1 A8])
(const_int 1 [0x1])))
(set (mem/v:QI (plus:SI (reg:SI 144 gbr)
(const_int 4 [0x4])) [-1  S1 A8])
(unspec:QI [
(plus:QI (mem/v:QI (plus:SI (reg:SI 144 gbr)
(const_int 4 [0x4])) [-1  S1 A8])
(const_int 1 [0x1]))
] UNSPEC_ATOMIC))
...

which looks the code generated with the old RA.  It seems that
old RA passes gbr+4 addressing as is but LRA spills gbr with r3
according to the constraint SraSdd.  Perhaps LRA is more strict
in this regard.
I guess that these pr64661-x.c regressions are not so problem, though.
I'm not sure whether hiconst.c regression is serious or not.
The serious one would be

Running target sh-sim/-m2/-mb
FAIL: gcc.c-torture/execute/20040709-2.c   -Os  execution test

My sh4-unknown-linux-gnu test also shows another execution
errors for libstdc++-v3.

New tests that FAIL:

22_locale/money_get/get/wchar_t/14.cc execution test
22_locale/money_get/get/wchar_t/19.cc execution test
22_locale/money_get/get/wchar_t/22131.cc execution test
22_locale/money_get/get/wchar_t/38399.cc execution test
22_locale/money_get/get/wchar_t/39168.cc execution test
22_locale/money_get/get/wchar_t/6.cc execution test
22_locale/money_get/get/wchar_t/8.cc execution test
22_locale/money_get/get/wchar_t/9.cc execution test
22_locale/money_put/put/wchar_t/39168.cc execution test
22_locale/money_put/put/wchar_t/5.cc execution test
22_locale/money_put/put/wchar_t/6.cc execution test

These tests compiled with -mlra don't fail with libstdc++-v3
library compiled with -mno-lra, i.e. libstdc++-v3 is miscompiled
with -mlra.  These wrong code problems should be resolved before
witch to LRA.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #95 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #94)
> Kaz, do you think we can enable LRA by default for GCC 6?

I think that it's OK to make LRA default on trunk, even if it's
better with your R0 pre-allocating pass.
The last time I tested -mlra, there are some regressions, though.
I'd like to test it again.  Could you see any serious problems on
sh-elf with -mlra?

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #100 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #99)
> Hm .. those don't fail on sh-elf ... maybe something related to the atomics?
> Atomics are off by default for sh-elf, but on for sh-linux.

Maybe.  It could be something atomic related.
For 14.cc case, replacing locale.o and cxx11-shim_facets.o with
ones from non-LRA build fixes the failure.
For example, std::locale::locale(std::locale const&) is compiled
very differently in LRA/non-LRA builds.  Strangely, the problem
can't be reproduced with recompiling these objects with -mlra in
non-LRA builds.  The above constructor is compiled to

[LRA build]
   0:   c6 2f   mov.l   r12,@-r15
   2:   0b c7   mova30 <_ZNSt6localeC1ERKS_+0x30>,r0
   4:   0a dc   mov.l   30 <_ZNSt6localeC1ERKS_+0x30>,r12   ! 0
<_ZNSt6localeC1ERKS_>
   6:   0c 3c   add r0,r12
   8:   52 62   mov.l   @r5,r2
   a:   0a d0   mov.l   34 <_ZNSt6localeC1ERKS_+0x34>,r0! 0
<_ZNSt6localeC1ERKS_>
   c:   ce 01   mov.l   @(r0,r12),r1
   e:   18 21   tst r1,r1
  10:   09 8d   bt.s26 <_ZNSt6localeC1ERKS_+0x26>
  12:   22 24   mov.l   r2,@r4
  14:   02 c7   mova20 <_ZNSt6localeC1ERKS_+0x20>,r0
  16:   f3 61   mov r15,r1
  18:   fa ef   mov #-6,r15
  1a:   22 63   mov.l   @r2,r3
  1c:   01 73   add #1,r3
  1e:   32 22   mov.l   r3,@r2
  20:   13 6f   mov r1,r15
  22:   0b 00   rts 
  24:   f6 6c   mov.l   @r15+,r12
  26:   22 61   mov.l   @r2,r1
  28:   01 71   add #1,r1
  2a:   12 22   mov.l   r1,@r2
  2c:   0b 00   rts 
  2e:   f6 6c   mov.l   @r15+,r12
...
30: R_SH_GOTPC  _GLOBAL_OFFSET_TABLE_
34: R_SH_GOT32  __pthread_key_create
[non-LRA build]
   0:   c6 2f   mov.l   r12,@-r15
   2:   0b c7   mova30 <_ZNSt6localeC1ERKS_+0x30>,r0
   4:   0a dc   mov.l   30 <_ZNSt6localeC1ERKS_+0x30>,r12   ! 0
<_ZNSt6localeC1ERKS_>
   6:   22 4f   sts.l   pr,@-r15
   8:   0c 3c   add r0,r12
   a:   52 61   mov.l   @r5,r1
   c:   09 d0   mov.l   34 <_ZNSt6localeC1ERKS_+0x34>,r0! 0
<_ZNSt6localeC1ERKS_>
   e:   ce 02   mov.l   @(r0,r12),r2
  10:   28 22   tst r2,r2
  12:   07 8d   bt.s24 <_ZNSt6localeC1ERKS_+0x24>
  14:   12 24   mov.l   r1,@r4
  16:   13 64   mov r1,r4
  18:   07 d1   mov.l   38 <_ZNSt6localeC1ERKS_+0x38>,r1! 1a
  1a:   03 01   bsrfr1
  1c:   01 e5   mov #1,r5
  1e:   26 4f   lds.l   @r15+,pr
  20:   0b 00   rts 
  22:   f6 6c   mov.l   @r15+,r12
  24:   12 62   mov.l   @r1,r2
  26:   01 72   add #1,r2
  28:   22 21   mov.l   r2,@r1
  2a:   26 4f   lds.l   @r15+,pr
  2c:   0b 00   rts 
  2e:   f6 6c   mov.l   @r15+,r12
...
30: R_SH_GOTPC  _GLOBAL_OFFSET_TABLE_
34: R_SH_GOT32  __pthread_key_create
  38:   1a 00   sts macl,r0
38: R_SH_PLT32  _ZN9__gnu_cxx12__atomic_addEPVii
...

Perhaps the both codes are ok, though something odd happens
on atomic things anyway.

[Bug target/67506] [5/6 Regression][SH]: error: unrecognizable insn when compiling texlive-binaries

[kkojima at gcc dot gnu.org]

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

--- Comment #5 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #4)
> Could you please test it?

It fixes all test cases for the cross trunk sh4-unknown-linux-gnu compiler.
There is no new failures with the top level "make -k check".

[Bug target/67506] [5/6 Regression][SH]: error: unrecognizable insn when compiling texlive-binaries

[kkojima at gcc dot gnu.org]

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

--- Comment #2 from Kazumoto Kojima  ---
Created attachment 36309
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36309=edit
reduced test case

It looks that some problem happens in tstsi_t splitter.
The insns before splitting are:

(insn 124 123 125 13 (set (reg:HI 262 [ *_48 ])
(zero_extend:HI (reg:QI 263 [ *_48 ]))) tfoo.c:41 223
{zero_extendqihi2}
 (expr_list:REG_DEAD (reg:QI 263 [ *_48 ])
(nil)))
(note 125 124 126 13 NOTE_INSN_DELETED)
(insn 126 125 127 13 (set (reg:SI 197 [ *_48 ])
(zero_extend:SI (reg:HI 262 [ *_48 ]))) tfoo.c:42 220
{*zero_extendhisi2_compact}
 (nil))
(insn 127 126 128 13 (set (reg:SI 147 t)
(zero_extract:SI (subreg:SI (reg:HI 262 [ *_48 ]) 0)
(const_int 1 [0x1])
(const_int 7 [0x7]))) tfoo.c:42 516 {*zero_extract_0}
 (nil))

and the last insn is splitted into

(insn 478 126 479 16 (set (reg:SI 147 t)
(eq:SI (and:SI (subreg:SI (reg:HI 262 [ *_48 ]) 0)
(const_int 128 [0x80]))
(const_int 0 [0]))) tfoo.c:42 -1
 (nil))

with *zero_extract_0 splitter.  Then it seems that tstsi_t splitter
replaces (subreg:SI (reg:HI 262 [ *_48 ]) 0) with (reg:HI 262 [ *_48 ])
as the result of eop0.use_as_extended_reg and we got

(insn 480 126 481 16 (set (reg:SI 147 t)
(eq:SI (and:SI (reg:HI 262 [ *_48 ])
(const_int 128 [0x80]))
(const_int 0 [0]))) tfoo.c:42 -1
 (nil))

Oleg, could you please look at this?

[Bug target/67506] [5/6 Regression][SH]: error: unrecognizable insn when compiling texlive-binaries

[kkojima at gcc dot gnu.org]

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

Kazumoto Kojima  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Known to work||4.9.4
Summary|[SH][5]: error: |[5/6 Regression][SH]:
   |unrecognizable insn when|error: unrecognizable insn
   |compiling texlive-binaries  |when compiling
   ||texlive-binaries
  Known to fail||5.2.1, 6.0

--- Comment #1 from Kazumoto Kojima  ---
Cross trunk compiler fails with the same ICE.

[Bug target/66609] [sh] Relative address expressions bind at as-time, even if symbol is weak

[kkojima at gcc dot gnu.org]

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

--- Comment #4 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
Author: kkojima
Date: Mon Aug 24 23:23:00 2015
New Revision: 227155

URL: https://gcc.gnu.org/viewcvs?rev=227155root=gccview=rev
Log:
PR target/66609
* [SH] Take into account weak symbols for pc relative calls/sibcalls.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh-protos.h
trunk/gcc/config/sh/sh.c
trunk/gcc/config/sh/sh.md

[Bug target/66609] [sh] Relative address expressions bind at as-time, even if symbol is weak

[kkojima at gcc dot gnu.org]

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

Kazumoto Kojima kkojima at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kkojima at gcc dot gnu.org

--- Comment #1 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
Created attachment 36246
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36246action=edit
patch

.long foo@PCREL-(.LPCS0+2-.)

looks to be reasonable.  It seems that sh backend shouldn't
use UNSPEC_SYMOFF for that case in the first place.  Does
the patch attached work for you?

[Bug target/66609] [sh] Relative address expressions bind at as-time, even if symbol is weak

[kkojima at gcc dot gnu.org]

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

--- Comment #3 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
(In reply to Rich Felker from comment #2)

Thanks for the confirmation.  I'll commit the patch after the undergoing
additional test done.

[Bug target/67002] [5] [SH]: Bootstrap stage 2/3 comparison failure - gcc/real.o differs

[kkojima at gcc dot gnu.org]

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

--- Comment #23 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
Author: kkojima
Date: Fri Aug  7 20:41:25 2015
New Revision: 226726

URL: https://gcc.gnu.org/viewcvs?rev=226726root=gccview=rev
Log:
PR target/67002
* config/sh/sh.c (sh_recog_treg_set_expr): Return false during
expand phase to avoid codegen differences with -g.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/sh/sh.c

[Bug target/67002] [5] [SH]: Bootstrap stage 2/3 comparison failure - gcc/real.o differs

[kkojima at gcc dot gnu.org]

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

--- Comment #24 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
Author: kkojima
Date: Fri Aug  7 08:11:45 2015
New Revision: 226715

URL: https://gcc.gnu.org/viewcvs?rev=226715root=gccview=rev
Log:
PR target/67002
* config/sh/sh.c (sh_recog_treg_set_expr): Return false during
expand phase to avoid codegen differences with -g.


Modified:
branches/trunk/gcc/ChangeLog
branches/trunk/gcc/config/sh/sh.c

[Bug target/67002] [5] [SH]: Bootstrap stage 2/3 comparison failure - gcc/real.o differs

[kkojima at gcc dot gnu.org]

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

--- Comment #21 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #20)
 Yes, that looks OK.  treg_set_expr-something recog matching is actually only
 required during combine.  The simpler forms like (reg:SI T_REG) could also
 be required during expansion.

Thanks.  I'll commit it when the usual test is done.

 Hm ... actually it should work.  The temporary rtx insn is not used for
 anything else, so that assigned insn uid will never appear anywhere. 
 However, it's probably better to have one static rtx_insn to avoid
 constructing the temporary rtx over and over again.  Unfortunately the
 gen_rtx* functions allocate rtx objects always on the GC heap.

Yes, it works.  I'm uncomfortable with it because the current use of
crtl-emit.x_cur_insn_uid aka cur_insn_uid is limitted to emit-rtl.c.
I think that the use of that field outside of emit-rtl.c is unexpected.
Also it doesn't sound good to add a new interface to access that field
there.  After all, your static rtx_insn is the right thing to do.

[Bug target/67002] [5] [SH]: Bootstrap stage 2/3 comparison failure - gcc/real.o differs

[kkojima at gcc dot gnu.org]

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

--- Comment #19 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
(In reply to Kazumoto Kojima from comment #18)
In the problematic situation, get_max_insn_count returns the false
value after

  if (MAY_HAVE_DEBUG_INSNS)
expand_debug_locations ();

in pass_expand::execute (function *fun).  expand_debug_locations
calls sh_recog_treg_set_expr indirectly at this very early stage
to compute rtx costs.  sh_recog_treg_set_expr makes some set insns
and they cause the differences of cur_insn_uid with -g.  Oleg, how
about the patch below?  My first trial was --cur_insn_uid just
after make_insn_raw there but I'm afraid that it will make another
surprise.

diff --git a/config/sh/sh.c b/config/sh/sh.c
index f429193..450d634 100644
--- a/config/sh/sh.c
+++ b/config/sh/sh.c
@@ -14165,6 +14165,12 @@ sh_recog_treg_set_expr (rtx op, machine_mode mode)
   if (!can_create_pseudo_p ())
 return false;

+  /* expand_debug_locations may call this to compute rtx costs at
+ very early stage.  In that case, don't make new insns here to
+ avoid codegen differences with -g. */
+  if (currently_expanding_to_rtl)
+return false;
+
   /* We are going to invoke recog in a re-entrant way and thus
  have to capture its current state and restore it afterwards.  */
   recog_data_d prev_recog_data = recog_data;

[Bug target/67002] [5] [SH]: Bootstrap stage 2/3 comparison failure - gcc/real.o differs

[kkojima at gcc dot gnu.org]

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

--- Comment #18 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
(In reply to Michael Karcher from comment #15)
The first different line of diff of the .pre dumps of Michael's
test case with/without -g is:

 Expression hash table (53 buckets, 12 entries)
---
 Expression hash table (51 buckets, 12 entries)

It means that gcse.c:alloc_hash_table allocates the table with
different number of buckets with -g.
It looks emit_rtl.c:get_max_insn_count returns different values
with/without -g at rtl_pre pass.  This shouldn't happen.
The comment of get_max_insn_count says:

  /* The table size must be stable across -g, to avoid codegen
 differences due to debug insns, and not be affected by
 -fmin-insn-uid, to avoid excessive table size and to simplify
 debugging of -fcompare-debug failures.  */

[Bug target/67002] [5] [SH]: Bootstrap stage 2/3 comparison failure - gcc/real.o differs

[kkojima at gcc dot gnu.org]

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

--- Comment #14 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
Created attachment 36117
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36117action=edit
reduced test case

 Michael Karcher, who previously helped smashing some bugs in gcc for the SH
 target, had a go at this and he discovered that the difference between stage2
 and stage3 is the -gtoggle switch.

I've confirmed it even with cross 5/6 compilers.  The above reduced
C++ test case fails with -S -O2 -fcompare-debug on my 5/6 cross
sh4-linux/sh-elf g++.  It means that the generated insns differ
with/without -g.  It looks to me a target independent issue, though
I could be wrong about it.  With a quick look, rtl_pre pass behaves
differently with -g.  I've found PRs for -fcompare-debug like 63315,
65874, 65980, 66688 and 67043.

[Bug target/67049] sh64-elf: internal compiler error: in df_uses_record, at df-scan.c:3001

[kkojima at gcc dot gnu.org]

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

--- Comment #3 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
Author: kkojima
Date: Fri Jul 31 22:19:51 2015
New Revision: 226457

URL: https://gcc.gnu.org/viewcvs?rev=226457root=gccview=rev
Log:
PR target/67049
* config/sh/sh.md (GOTaddr2picreg): Fix typo added with the last change.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.md

[Bug target/67049] sh64-elf: internal compiler error: in df_uses_record, at df-scan.c:3001

[kkojima at gcc dot gnu.org]

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

--- Comment #4 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
Author: kkojima
Date: Fri Jul 31 22:25:57 2015
New Revision: 226458

URL: https://gcc.gnu.org/viewcvs?rev=226458root=gccview=rev
Log:
PR target/67049
* config/sh/sh.md (GOTaddr2picreg): Fix typo added with the last change.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/sh/sh.md

[Bug target/67049] sh64-elf: internal compiler error: in df_uses_record, at df-scan.c:3001

[kkojima at gcc dot gnu.org]

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

Kazumoto Kojima kkojima at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
Fixed.

[Bug target/67061] sh64-elf: internal compiler error: in sh_find_set_of_reg, at config/sh/sh-protos.h:235

[kkojima at gcc dot gnu.org]

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

--- Comment #2 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #1)
 Hm ..
 
   for (result.insn = stepfunc (insn); result.insn != NULL_RTX;
previnsn = result.insn, result.insn = stepfunc (result.insn))
 
 that previnsn = ...  in sh_find_set_of_reg looks broken.  I wonder how/why
 it never showed up for normal SH targets (normal = non-SH64).  I'll have a
 look at this.

SHCOMPACT target uses different ABI for the function calls.
It looks that that makes sh_find_set_of_reg unhappy.
k_cos.c case is here:

...
(call_insn/i 29 28 30 3 (parallel [
(set (reg:SI 2 r2)
(call (mem:SI (reg/f:SI 509) [0  S4 A32])
(const_int 0 [0])))
(const_int 1610612736 [0x6000])
(use (reg:SI 0 r0))
(use (reg:SI 1 r1))
(use (reg:SI 154 fpscr0))
(clobber (reg:SI 146 pr))
]) ...k_cos.c:78 323 {call_value_compact}
 (expr_list:REG_DEAD (reg:SI 154 fpscr0)
(expr_list:REG_DEAD (reg:SI 1 r1)
(expr_list:REG_DEAD (reg:SI 0 r0)
(expr_list:REG_CALL_DECL (symbol_ref:SI (__fixdfsi) [flags
0x41])
(expr_list:REG_EH_REGION (const_int -2147483648
[0x8000])
(nil))
(expr_list (use (reg:SI 2 r2))
(expr_list (use (mem/c:DF (reg/f:SI 508) [1  S8 A64]))
(nil
(note 30 29 31 3 NOTE_INSN_DELETED)
(insn 31 30 32 3 (set (reg:SI 147 t)
(eq:SI (reg:SI 2 r2)
(const_int 0 [0]))) ...k_cos.c:78 12 {cmpeqsi_t}
 (expr_list:REG_DEAD (reg:SI 2 r2)
(nil)))
...

and the problem happens at the call of sh_find_set_of_reg

Breakpoint 2, sh_find_extending_set_of_reg (reg=0xb7e95e24, 
curr_insn=curr_insn@entry=0xb7e99480)
at /exp/ldroot/dodes/xsh64-elf-combined/combined/gcc/config/sh/sh.c:13925
13925   sh_find_set_of_reg (reg, curr_insn, prev_nonnote_insn_bb,
true);

where reg is r2 and curr_insn is the insn 31.  sh_find_set_of_reg is
stepping backward from the insn 31 but the call_insn 29 is missed.

Does the patch below work?

Oleg, it's the same one we've discussed, I think.  Thought?

diff --git a/config/sh/sh-protos.h b/config/sh/sh-protos.h
index 5a552e2..3b725ba 100644
--- a/config/sh/sh-protos.h
+++ b/config/sh/sh-protos.h
@@ -198,7 +198,8 @@ sh_find_set_of_reg (rtx reg, rtx_insn* insn, F stepfunc,
 {
   if (BARRIER_P (result.insn))
break;
-  if (!NONJUMP_INSN_P (result.insn))
+  if (!NONJUMP_INSN_P (result.insn)
+  !(REGNO (reg)  FIRST_PSEUDO_REGISTER  CALL_P (result.insn)))
continue;
   if (reg_set_p (reg, result.insn))
{

[Bug target/67002] [5] [SH]: Bootstrap stage 2/3 comparison failure - gcc/real.o differs

[kkojima at gcc dot gnu.org]

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

--- Comment #7 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
(In reply to John Paul Adrian Glaubitz from comment #6)
 And here is the diff from the disassembly:

A rare indeterminacy of the register choice.  Both codes are valid.
It seems very hard to find where has this indeterminacy come from.
Please follow Oleg's suggestion #c1.

[Bug target/67049] sh64-elf: internal compiler error: in df_uses_record, at df-scan.c:3001

[kkojima at gcc dot gnu.org]

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

--- Comment #1 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
My bad.  Could you please try this patch?

diff --git a/config/sh/sh.md b/config/sh/sh.md
index a86eaad..387ffe3 100644
--- a/config/sh/sh.md
+++ b/config/sh/sh.md
@@ -10597,7 +10597,7 @@ label:
   if (TARGET_SHMEDIA)
 {
   rtx tr = gen_rtx_REG (Pmode, TR0_REG);
-  rtx pic = operands[0];
+  rtx pic = operands[1];
   rtx lab = PATTERN (gen_call_site ());
   rtx insn, equiv;

[Bug target/66780] [4.9 Regression] Compiling with -fstack-protector-strong causes binary to segfault

[kkojima at gcc dot gnu.org]

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

Kazumoto Kojima kkojima at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
Fixed.

[Bug target/66930] [5 Regression]: gengtype.c is miscompiled during stage2

[kkojima at gcc dot gnu.org]

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

--- Comment #15 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #13)
 This would be OK for hardregs (which are clobbered by calls).  When working
 on pseudos, it's actually OK to ignore calls.  Maybe it'd be a good idea to
 extend sh_find_set_of_reg to check for call clobbered hardregs only.  This
 will make the function easier to use.

I see.  Thanks for your explanation.

[Bug target/66930] [5 Regression]: gengtype.c is miscompiled during stage2

[kkojima at gcc dot gnu.org]

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

--- Comment #14 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
(In reply to Kazumoto Kojima from comment #12)
 The toplevel make -k check on sh4-unknown-linux-gnu is running.
 I'll report back when it completes.

I've confirmed that there are no new failures with the patch in c#10.