[Bug target/65979] internal compiler error: in make_edges, at tree-cfg.c:923

[Bug target/65979] internal compiler error: in make_edges, at tree-cfg.c:923

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #1 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Created attachment 35441
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35441&action=edit
Preprocessed source files for gcc-5

[Bug target/65979] New: internal compiler error: in make_edges, at tree-cfg.c:923

[glaubitz at physik dot fu-berlin.de]

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

            Bug ID: 65979
           Summary: internal compiler error: in make_edges, at
                    tree-cfg.c:923
           Product: gcc
           Version: 5.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: glaubitz at physik dot fu-berlin.de
  Target Milestone: ---
              Host: sh4-linux-gnu
            Target: sh*-*-*

Created attachment 35440
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35440&action=edit
Full build log for gcc-5 on sh4-linux-gnu (gzip-compressed)

Hello!

gcc-5 has hit Debian now and I had my first go at attempting to build it on
sh4. Unfortunately, the build fails at some point with the following error:

configure:3467: $? = 1
configure:3655: checking for suffix of object files
configure:3677: /«PKGBUILDDIR»/build/./gcc/xgcc -B/«PKGBUILDDIR»/build/./gcc/
-B/usr/sh4-linux-gnu/bin/ -B/usr/sh4-linux-gnu/lib/ -isystem /usr/sh4-linux
-gnu/include -isystem /usr/sh4-linux-gnu/sys-include -isystem
/«PKGBUILDDIR»/build/sys-include    -c -g -O2  conftest.c >&5
conftest.c: In function 'main':
conftest.c:11:1: internal compiler error: in make_edges, at tree-cfg.c:923
 main ()
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-5/README.Bugs> for instructions.
Preprocessed source stored into /tmp/ccrZ8ce7.out file, please attach this to
your bugreport.

Attaching the build log as well as the preprocessed source. As always, please
ping me if you need more input.

Cheers,
Adrian
>From gcc-bugs-return-485230-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat May 02 08:22:04 2015
Return-Path: <gcc-bugs-return-485230-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 87380 invoked by alias); 2 May 2015 08:22:04 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 87349 invoked by uid 48); 2 May 2015 08:22:00 -0000
From: "trippels at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/65973] segmentation fault when compiling C++14 code
Date: Sat, 02 May 2015 08:22:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: trippels at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on cc short_desc everconfirmed cf_known_to_fail bug_severity
Message-ID: <bug-65973-4-256wcwDC0a@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65973-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65973-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-05/txt/msg00070.txt.bz2
Content-length: 3013

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

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-05-02
                 CC|                            |trippels at gcc dot gnu.org
            Summary|Current gcc 6 snapshot      |segmentation fault when
                   |fails with segmentation     |compiling C++14 code
                   |fault when compiling C++14  |
                   |code                        |
     Ever confirmed|0                           |1
      Known to fail|                            |5.1.0, 6.0
           Severity|blocker                     |normal

--- Comment #1 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
markus@x4 tmp % cat test.ii
class foo {
  constexpr foo() noexcept { __PRETTY_FUNCTION__; };
};

markus@x4 tmp % g++ -c -std=c++14 test.ii
test.ii: In constructor ‘constexpr foo::foo()’:
test.ii:2:51: internal compiler error: Segmentation fault
   constexpr foo() noexcept { __PRETTY_FUNCTION__; };
                                                   ^
0xc834af crash_signal
        ../../gcc/gcc/toplev.c:380
0x7c6cf4 tsi_stmt
        ../../gcc/gcc/tree-iterator.h:92
0x7c6cf4 build_constexpr_constructor_member_initializers
        ../../gcc/gcc/cp/constexpr.c:550
0x7c6cf4 massage_constexpr_body
        ../../gcc/gcc/cp/constexpr.c:680
0x7d0a7b register_constexpr_fundef(tree_node*, tree_node*)
        ../../gcc/gcc/cp/constexpr.c:783
0x5fa005 maybe_save_function_definition
        ../../gcc/gcc/cp/decl.c:14110
0x5fa005 finish_function(int)
        ../../gcc/gcc/cp/decl.c:14234
0x6e91b9 cp_parser_function_definition_after_declarator
        ../../gcc/gcc/cp/parser.c:23473
0x6ec82c cp_parser_late_parsing_for_member
        ../../gcc/gcc/cp/parser.c:24150
0x6c7901 cp_parser_class_specifier_1
        ../../gcc/gcc/cp/parser.c:20041
0x6c7901 cp_parser_class_specifier
        ../../gcc/gcc/cp/parser.c:20067
0x6c7901 cp_parser_type_specifier
        ../../gcc/gcc/cp/parser.c:14707
0x6dac5f cp_parser_decl_specifier_seq
        ../../gcc/gcc/cp/parser.c:11938
0x6ebf71 cp_parser_simple_declaration
        ../../gcc/gcc/cp/parser.c:11515
0x6e5b73 cp_parser_block_declaration
        ../../gcc/gcc/cp/parser.c:11462
0x6efac9 cp_parser_declaration
        ../../gcc/gcc/cp/parser.c:11359
0x6ee15a cp_parser_declaration_seq_opt
        ../../gcc/gcc/cp/parser.c:11245
0x6ee46f cp_parser_translation_unit
        ../../gcc/gcc/cp/parser.c:4107
0x6ee46f c_parse_file()
        ../../gcc/gcc/cp/parser.c:33173
0x826152 c_common_parse_file()
        ../../gcc/gcc/c-family/c-opts.c:1057
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
>From gcc-bugs-return-485231-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat May 02 08:47:29 2015
Return-Path: <gcc-bugs-return-485231-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 108077 invoked by alias); 2 May 2015 08:47:28 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 108035 invoked by uid 48); 2 May 2015 08:47:24 -0000
From: "glaubitz at physik dot fu-berlin.de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/65979] internal compiler error: in make_edges, at tree-cfg.c:923
Date: Sat, 02 May 2015 08:47:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.1.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: glaubitz at physik dot fu-berlin.de
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65979-4-3qBnr6Pv71@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65979-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65979-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-05/txt/msg00071.txt.bz2
Content-length: 358

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide979

--- Comment #2 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Additional comment:

There seem to be multiple (unrelated?) errors which prevent the built but all
of them, including the one I reported seem to relate to conftest.c. So I'll
rename the bug title accordingly.

Adrian

[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu

[kkojima at gcc dot gnu.org]

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

Kazumoto Kojima <kkojima at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kkojima at gcc dot gnu.org

--- Comment #3 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #1)
> Created attachment 35441 [details]
> Preprocessed source files for gcc-5

ccLfmF03.out
ccrZ8ce7.out
internal compiler error: in make_edges, at tree-cfg.c:923

Looks your build compiler has some wrong code problem.  Perhaps
reducing optimization level for the build compiler or changing
the build compiler may help.

cc13zIkw.out
ccY9XfBa.out
ccQG4ZY9.out
ccln30GZ.out
error: unable to find a register to spill in class 'R0_REGS'
against some atomic constructs.

Looks a known issue which unfortunately we have no solution
with the current register allocator.
You can try new register allocator with new -mlra option.
AFAIK, new register allocator (LRA) doesn't cause this error.
I can't see these failures on my cross builds of gcc-5, though.
It could be a problem of the build compiler too.

[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu

[kkojima at gcc dot gnu.org]

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

--- Comment #4 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #3)
> I can't see these failures on my cross builds of gcc-5, though.
> It could be a problem of the build compiler too.

Although I can't see them in my cross builds, I've confirmed that the given
testcase fails with cross gcc-5 compilers and it doesn't fail with -mlra.

[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #5 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
> I can't see these failures on my cross builds of gcc-5, though.
> It could be a problem of the build compiler too.

I am manually building the latest gcc-4.9.2 snapshot we have in Debian now and
then give it another shot building gcc-5 with the updated compiler. The latest
gcc-4.9.2 contains lots of fixes regarding the code generation and maybe it
also contains the decisive fixes for this case.

Adrian

[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #7 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #6)
> To be followed up.

Just built with gcc-4.9_4.9.2-7 which previously successfully built
gcc-4.9_4.9.2-10 [1] but fails to build gcc-4.9_4.9.2-16 [2].

Any suggestions? I am testing with "nostrap" now and will use this compiler to
build the package again. Otherwise I am currently out of ideas.

Adrian

> [1] http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-4.9&arch=sh4&ver=4.9.2-10&stamp=1421945369
> [2] http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-4.9&arch=sh4&ver=4.9.2-16&stamp=1431119505

[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu

[kkojima at gcc dot gnu.org]

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

--- Comment #8 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #7)
> Just built with gcc-4.9_4.9.2-7 which previously successfully built
> gcc-4.9_4.9.2-10 [1] but fails to build gcc-4.9_4.9.2-16 [2].

It seems that latest 4.9 and 5.0 have some wrong code problem on
this target.  We should pin point it.  My sh4 board has only 64MB
RAM and it takes a week to get stage2 compiler for gcc-5.  A reduced
testcase for the cross compiler is deadly needed.
It looks there are not so many target changes between
  http://http.debian.net/debian/pool/main/g/gcc-4.9/gcc-4.9_4.9.2-10.diff.gz
and
  http://http.debian.net/debian/pool/main/g/gcc-4.9/gcc-4.9_4.9.2-16.diff.gz

2015-03-26  Oleg Endo  <olegendo@gcc.gnu.org>

        Backport from mainline
        2015-03-26  Oleg Endo  <olegendo@gcc.gnu.org>

        * config/sh/t-sh (MULTILIB_EXCEPTIONS): Handle default endian.

2015-03-10  Oleg Endo  <olegendo@gcc.gnu.org>

        PR target/53988
        * config/sh/sh.md (*tst<mode>_t_zero): Remove insns.

2015-03-03  Kaz Kojima  <kkojima@gcc.gnu.org>

        PR target/65249
        * config/sh/sh.md (symGOT_load): Use R0 reg for operands[2] when
        called for __stack_chk_guard symbol.

2015-02-25  Kaz Kojima  <kkojima@gcc.gnu.org>

        Backport from mainline
        2015-02-23  Kaz Kojima  <kkojima@gcc.gnu.org>

        PR target/65153
        * config/sh/sh.md (movsicc_true+3): Remove peephole.
        * config/sh/sh-protos.h (replace_n_hard_rtx): Don't declare.
        * config/sh/sh.c (replace_n_hard_rtx): Remove.

2015-02-23  Oleg Endo  <olegendo@gcc.gnu.org>

        Backport from mainline
        2015-02-23  Oleg Endo  <olegendo@gcc.gnu.org>

        PR target/65163
        * config/sh/sh.md (swapbsi2, related peephole2): Use const_int -65536
        instead of const_int 4294901760.

2015-01-08  Christian Bruel  <christian.bruel@st.com>

        PR target/64507
        * config/sh/sh-mem.cc (sh_expand_cmpnstr): Check 0 length.

of which revision number in FSF gcc svn are
r221686, r221305, r221166, r220957, r220917, r219258
respectively.
You can revert the above changes to see what happens.  Looks safe
changes to me, but some changes could reveal hidden problems.
If the issue remains even if all those changes are reverted,
there will be no easy way to narrow down.

[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #9 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Kazumoto Kojima from comment #8)
> You can revert the above changes to see what happens.  Looks safe
> changes to me, but some changes could reveal hidden problems.
> If the issue remains even if all those changes are reverted,
> there will be no easy way to narrow down.

Ah, I was actually just about to compile a list with the changes that went into
gcc-4.9 after -10 which was still working, so thanks for that.

I haven't worked with the gcc code base before, so any suggestions on how to
work through the code?

I would just checkout the code from git://gcc.gnu.org/git/gcc.git now and
revert change after change to see if that fixes it.

Adrian

[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #10 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #9)
> I haven't worked with the gcc code base before, so any suggestions on how to
> work through the code?

Ah, I just realized Matthias put all these changes into handy patches which I
can just remove one by handy. That's easy :).

Will take some time but report back.

Adrian

[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #11 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
So, I have tried disabling some of the patches but it seems that these depend
on each other. Thus, I will probably have to checkout gcc from source via git
and revert the patches using git.

Unless there is a better suggestion?

PS: For the time being, I rebuild gcc-4.9_4.9.2-10 with a forged -16+sh4
version number such that we have a working gcc on sh4 again.

Adrian

[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu

[kkojima at gcc dot gnu.org]

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

--- Comment #12 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
I've looked into which stage2 object was miscompiled with bisecting
on objects for 5.1.0 and found tree-cfg.o is the one of them.
5.1.0 cross compiler miscompiles it too and I've got which change
causes the problem with bisecting on changes.
Surprisingly, it's r220922 for PR target/65153.  With reverting it
and applying the patch in the trail #c7 in PR65153, stage2 compiler
can pass conftest.c issues during configuring target libraries.
That patch simply removes a peephole and looked to be safe
from wrong code problem.  It means that there is another problem
elsewhere.  I've compared the outputs for tree-cfg.c w/wo that
peephole and found that is_ctrl_stmt was miscompiled without that
peephole.  I'll attach a reduced testcase.

[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu

[kkojima at gcc dot gnu.org]

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

--- Comment #13 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 35572
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35572&action=edit
reduced testcase

>From rtl dumps for 5.1.0 cc1plus against the testcase, the wrong
peephole transformation makes

(insn 92 14 15 3 (set (reg:SI 1 r1 [orig:171 D.2078 ] [171])
        (reg:SI 2 r2 [172])) 252 {movsi_ie}
     (expr_list:REG_DEAD (reg:SI 2 r2 [172])
        (nil)))
(insn 93 16 83 3 (set (reg:SI 2 r2)
        (const_int 66602 [0x1042a])) 252 {movsi_ie}
     (nil))
(insn 83 93 18 3 (set (reg:SI 147 t)
        (eq:SI (and:SI (reg:SI 1 r1 [orig:171 D.2078 ] [171])
                (reg:SI 2 r2))
            (const_int 0 [0]))) 1 {tstsi_t}
     (expr_list:REG_DEAD (reg:SI 2 r2)
        (expr_list:REG_DEAD (reg:SI 1 r1 [orig:171 D.2078 ] [171])
            (nil))))

into

(insn 112 14 113 3 (set (reg:SI 2 r2)
        (const_int 66602 [0x1042a])) -1
     (nil))
(insn 113 112 114 3 (set (reg:SI 147 t)
        (eq:SI (and:SI (reg:SI 2 r2)
                (reg:SI 2 r2))
            (const_int 0 [0]))) -1
     (nil))
(insn 114 113 18 3 (const_int 0 [0]) -1
     (nil))

This peephole transformation is done by

;;      mov.w   @(18,r1),r0 (r0 = HImode)
;;      mov     r0,r1       (r0 = r1 = HImode)          mov.w   @(18,r1),r0
;;      ...     ..,r13      (r13 = SImode)      ->      ...     ..,r13
;;      tst     r1,r13                                  tst     r0,r13
(define_peephole2
  [(set (match_operand 0 "arith_reg_dest")
        (match_operand 1 "arith_reg_dest"))
   (set (match_operand:SI 2 "arith_reg_dest")
        (match_operand:SI 3))
   (set (reg:SI T_REG)
        (eq:SI (and:SI (match_operand:SI 4 "arith_reg_operand")
                       (match_operand:SI 5 "arith_reg_operand"))
               (const_int 0)))]
  "TARGET_SH1
   && peep2_reg_dead_p (3, operands[0])
   && !reg_overlap_mentioned_p (operands[0], operands[3])
   && (REGNO (operands[0]) == REGNO (operands[4])
       || REGNO (operands[0]) == REGNO (operands[5]))
   && (REGNO (operands[2]) == REGNO (operands[4])
       || REGNO (operands[2]) == REGNO (operands[5]))"
  [(const_int 0)]
{
  sh_check_add_incdec_notes (emit_move_insn (operands[2], operands[3]));
  emit_insn (gen_tstsi_t (operands[2],
                          gen_rtx_REG (SImode, (REGNO (operands[1])))));
})

Looks that this doesn't work when the operand 1 is equal to the operand 2
which is the case for the above insns 92, 93 and 83.  The peephole
removed with the fix in PR65153 transformed these insns prior to
the above peephole so to avoid the problem.  The patch below fixes
this case.  It looks there are similar peephole patterns,though.
Oleg, if you get the spare time, could you look into these peepholes?

--
diff --git a/config/sh/sh.md b/config/sh/sh.md
index 27f0074..5bc3401 100644
--- a/config/sh/sh.md
+++ b/config/sh/sh.md
@@ -14750,6 +14750,7 @@ label:
   "TARGET_SH1
    && peep2_reg_dead_p (3, operands[0])
    && !reg_overlap_mentioned_p (operands[0], operands[3])
+   && !reg_overlap_mentioned_p (operands[1], operands[2])
    && (REGNO (operands[0]) == REGNO (operands[4])
        || REGNO (operands[0]) == REGNO (operands[5]))
    && (REGNO (operands[2]) == REGNO (operands[4])

[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu

[olegendo at gcc dot gnu.org]

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

Oleg Endo <olegendo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-05-20
     Ever confirmed|0                           |1

--- Comment #14 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #13)
> Looks that this doesn't work when the operand 1 is equal to the operand 2
> which is the case for the above insns 92, 93 and 83.  The peephole
> removed with the fix in PR65153 transformed these insns prior to
> the above peephole so to avoid the problem.  The patch below fixes
> this case.  It looks there are similar peephole patterns,though.
> Oleg, if you get the spare time, could you look into these peepholes?
> 
> --
> diff --git a/config/sh/sh.md b/config/sh/sh.md
> index 27f0074..5bc3401 100644
> --- a/config/sh/sh.md
> +++ b/config/sh/sh.md
> @@ -14750,6 +14750,7 @@ label:
>    "TARGET_SH1
>     && peep2_reg_dead_p (3, operands[0])
>     && !reg_overlap_mentioned_p (operands[0], operands[3])
> +   && !reg_overlap_mentioned_p (operands[1], operands[2])
>     && (REGNO (operands[0]) == REGNO (operands[4])
>         || REGNO (operands[0]) == REGNO (operands[5]))
>     && (REGNO (operands[2]) == REGNO (operands[4])


Sorry for the long chain of trouble and pain.

Adding the !reg_overlap_mentioned_p (operands[1], operands[2]) condition should
fix the problem.  However, the peephole is actually meant to transform

(insn 92 14 15 3 (set (reg:SI 1 r1 [orig:171 D.2078 ] [171])
        (reg:SI 2 r2 [172])) 252 {movsi_ie}
     (expr_list:REG_DEAD (reg:SI 2 r2 [172])
        (nil)))
(insn 93 16 83 3 (set (reg:SI 2 r2)
        (const_int 66602 [0x1042a])) 252 {movsi_ie}
     (nil))
(insn 83 93 18 3 (set (reg:SI 147 t)
        (eq:SI (and:SI (reg:SI 1 r1 [orig:171 D.2078 ] [171])
                (reg:SI 2 r2))
            (const_int 0 [0]))) 1 {tstsi_t}
     (expr_list:REG_DEAD (reg:SI 2 r2)
        (expr_list:REG_DEAD (reg:SI 1 r1 [orig:171 D.2078 ] [171])
            (nil))))

into

(insn 93 16 83 3 (set (reg:SI 2 r1)
        (const_int 66602 [0x1042a])) 252 {movsi_ie}
     (nil))
(insn 83 93 18 3 (set (reg:SI 147 t)
        (eq:SI (and:SI (reg:SI 1 r1 [orig:171 D.2078 ] [171])
                (reg:SI 2 r2))
            (const_int 0 [0]))) 1 {tstsi_t}
     (expr_list:REG_DEAD (reg:SI 2 r2)
        (expr_list:REG_DEAD (reg:SI 1 r1 [orig:171 D.2078 ] [171])
            (nil))))

I think the check operands[1] / operands[2] check should go into the
preparation statement.  operands[0] is dying after this peephole, so I guess
this should work:

{
  if (reg_overlap_mentioned_p (operands[1], operands[2]))
    std::swap (operands[0], operands[2])

  sh_check_add_incdec_notes (emit_move_insn (operands[2], operands[3]));
  emit_insn (gen_tstsi_t (operands[2],
                          gen_rtx_REG (SImode, (REGNO (operands[1])))));
}

I guess that the following peephole (sh.md line 14733) will also have a similar
problem.

[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu

[olegendo at gcc dot gnu.org]

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

--- Comment #15 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #14)
> 
> I think the check operands[1] / operands[2] check should go into the
> preparation statement.  operands[0] is dying after this peephole, so I guess
> this should work:
> 

I have confirmed that the following fixes the test case in attachment 35572:

Index: gcc/config/sh/sh.md
===================================================================
--- gcc/config/sh/sh.md (revision 223416)
+++ gcc/config/sh/sh.md (working copy)
@@ -14721,6 +14721,9 @@
        || REGNO (operands[2]) == REGNO (operands[5]))"
   [(const_int 0)]
 {
+  if (reg_overlap_mentioned_p (operands[1], operands[2]))
+    std::swap (operands[0], operands[2]);
+
   sh_check_add_incdec_notes (emit_move_insn (operands[2], operands[3]));
   emit_insn (gen_tstsi_t (operands[2],
                          gen_rtx_REG (SImode, (REGNO (operands[1])))));

However, I think that the emit_move_insn could also be a source of hidden
problems.  For instance, if the captured insn

   (set (match_operand:SI 2 "arith_reg_dest")
        (match_operand:SI 3))

is not a move insn, but some computation like (set (reg) (plus:SI ... )).  I'm
not sure what emit_move_insn is going to do in this case.  Maybe a better way
would be to copy/re-emit the captured original insn in a different way.

[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu

[kkojima at gcc dot gnu.org]

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

--- Comment #16 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #15)
Thanks for a quick look!

> However, I think that the emit_move_insn could also be a source of hidden
> problems.  For instance, if the captured insn

Also arguments of emit_move_insn must have the same integer modes.

  if (reg_overlap_mentioned_p (operands[1], operands[2]))
    std::swap (operands[0], operands[2]);

  sh_check_add_incdec_notes (emit_move_insn (operands[2], operands[3]));

might ICE if operands[0] and operands[2] have different modes and
swap happens, though I'm not sure whether such insns are real or not.

[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #17 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Thanks a lot guys for working on this! I'm really glad you're doing this :).

[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu

[olegendo at gcc dot gnu.org]

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

--- Comment #18 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #16)
> 
> Also arguments of emit_move_insn must have the same integer modes.
> 
>   if (reg_overlap_mentioned_p (operands[1], operands[2]))
>     std::swap (operands[0], operands[2]);
> 
>   sh_check_add_incdec_notes (emit_move_insn (operands[2], operands[3]));
> 
> might ICE if operands[0] and operands[2] have different modes and
> swap happens, though I'm not sure whether such insns are real or not.

Yes, that is true.  However, because op0, op1, op2 are all "arith_reg_dest" the
peephole will only match if those are GP regs.  Each captured insn will only
reference a single GP reg, because DImode moves should have been smashed into
SImode moves before the peephole2 pass.  Thus, I think it should be safe to
just force the mode of op0 to SImode.  I'll try it out.

[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu

[kkojima at gcc dot gnu.org]

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

--- Comment #20 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #19)
> Could you guys please test this patch?  Actually, now it looks quite obvious
> I think.

gen_rtx_SET functions required SImode as their first argument.
Tests are running with that change on 5.1.0, though I agree
that it's an obvious fix.

[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu

[olegendo at gcc dot gnu.org]

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

--- Comment #21 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #20)
> (In reply to Oleg Endo from comment #19)
> > Could you guys please test this patch?  Actually, now it looks quite obvious
> > I think.
> 
> gen_rtx_SET functions required SImode as their first argument.
> Tests are running with that change on 5.1.0, though I agree
> that it's an obvious fix.

Please commit if it looks OK.

[Bug target/65979] [4.9/5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[kkojima at gcc dot gnu.org]

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

Kazumoto Kojima <kkojima at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Multiple issues in          |[4.9/5/6 Regression] [SH]
                   |conftest.c prevent build on |Wrong code is generated
                   |sh4-linux-gnu               |with stage1 compiler

--- Comment #22 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #21)

OK, I'll commit your patch when all tests are done.
BTW, I'd like to change the summary of the PR to clarify that this is
a 4.9/5/6 regression.

[Bug target/65979] [4.9/5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[kkojima at gcc dot gnu.org]

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

--- Comment #23 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Ouch.  The peephole in problem was added at gcc-5 not at 4.9.  The above
patch should fix the original conftest.c issue, but debien 4.9-16 problem
would be an another issue.  Sorry for my confusion.

[Bug target/65979] [4.9/5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #24 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Kazumoto Kojima from comment #23)
> Ouch.  The peephole in problem was added at gcc-5 not at 4.9.  The above
> patch should fix the original conftest.c issue, but debien 4.9-16 problem
> would be an another issue.  Sorry for my confusion.

I am partially to be blamed for that. I initially reported the gcc-5 issue
here, then saw gcc-4.9 failed to build as well and then assumed both were the
same problem.

But in any case, I am super happy you guys are fixing this. I will be back in
Japan in October, so if I have a chance to meet either of you, I owe you some
beer/sake/wine etc :).

Thanks!

[Bug target/65979] [4.9/5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[olegendo at gcc dot gnu.org]

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

--- Comment #25 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #24)
> 
> I am partially to be blamed for that. I initially reported the gcc-5 issue
> here, then saw gcc-4.9 failed to build as well and then assumed both were
> the same problem.

So, if I understand correctly ...
- 4.9.something doesn't bootstrap because of something unknown
- 5.something doesn't bootstrap because of c#19

... right?

Adrian, which compiler do you use to build the SH native compiler(s)?
Last time I've tried to do a native GCC 5 build on the SH4 debian box, vanilla
GCC would not build and I gave up.  Sorry for my impatience.

> But in any case, I am super happy you guys are fixing this. I will be back
> in Japan in October, so if I have a chance to meet either of you, I owe you
> some beer/sake/wine etc :).

Will trade beer for Mohnkuchen.
Will trade many other things for an SH4A-X4 8-core board with 2+ GB RAM.

[Bug target/65979] [4.9/5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[kkojima at gcc dot gnu.org]

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

--- Comment #26 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #25)
> So, if I understand correctly ...
> - 4.9.something doesn't bootstrap because of something unknown
> - 5.something doesn't bootstrap because of c#19
> 
> ... right?

You are right.  I've missed the reason of debian 4.9.2-16 bootstrap
failure described in #c6.  It's a stage2/3 comparison failure of
gcc/d/ctfeexpr.dmd.o which means debian adds D lang to FSF GCC tree.
BTW, warnings for cc1*-checksum.o would mean that Adrian's board
enables randomize_va_space feature which I always make it disable
with 'sudo echo 0 >/proc/sys/kernel/randomize_va_space' on my GCC
work.  I don't know why/how debian packages D lang together with
the vanilla GCC.  It seems 4.9.2-16 could bootstrap without D lang.

[Bug target/65979] [4.9/5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #28 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
> It doesn't bootstrap because the D compiler fails the compare test. This
> happens both on gcc-4.8 and gcc-4.9, here's the excerpt from 4.8 [1]:
> 
> Comparing stages 2 and 3
> warning: gcc/cc1objplus-checksum.o differs
> warning: gcc/cc1-checksum.o differs
> warning: gcc/cc1plus-checksum.o differs
> warning: gcc/cc1obj-checksum.o differs
> Bootstrap comparison failure!
> gcc/d/ctfeexpr.dmd.o differs

Hmm, now I'm confused. The comparision actually also failed before but the
build was still successful [1] for gcc_4.8.4-1:

Comparing stages 2 and 3
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
Comparison successful.

For gcc_4.8.4-2, the problem is not ignored [2] and the build therefore fails:

Comparing stages 2 and 3
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
Bootstrap comparison failure!

Interesting. So apparently this is _not_ a regression. Maybe we should split
the comparison failure of stage 2 and stage 3 into a different bug report.

Adrian

> [1] http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-4.8&arch=sh4&ver=4.8.4-1&stamp=1422178262
> [2] http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-4.8&arch=sh4&ver=4.8.4-2&stamp=1432515052

[Bug target/65979] [4.9/5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[olegendo at gcc dot gnu.org]

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

--- Comment #29 from Oleg Endo <olegendo at gcc dot gnu.org> ---
BTW, there is still one unresolved known problem which can silently generate
wrong code: PR 56451
Although the testsuite FAIL might have disappeared, the issue hasn't been
actually fixed, as far as I know.  In the worst case, delay slot stuffing can
be disabled with -fno-delayed-branch.

[Bug target/65979] [4.9/5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[kkojima at gcc dot gnu.org]

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

--- Comment #30 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Author: kkojima
Date: Tue May 26 22:32:11 2015
New Revision: 223721

URL: https://gcc.gnu.org/viewcvs?rev=223721&root=gcc&view=rev
Log:
PR target/65979
* config/sh/sh.md (tstsi_t peephole2): Use gen_rtx_SET and take into
  account the case that operands[1] and operands[2] are the same register.


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

[Bug target/65979] [4.9/5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[kkojima at gcc dot gnu.org]

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

--- Comment #31 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Author: kkojima
Date: Tue May 26 22:37:06 2015
New Revision: 223722

URL: https://gcc.gnu.org/viewcvs?rev=223722&root=gcc&view=rev
Log:
PR target/65979
* config/sh/sh.md (tstsi_t peephole2): Use gen_rtx_SET and take into
  account the case that operands[1] and operands[2] are the same register.


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

[Bug target/65979] [5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[kkojima at gcc dot gnu.org]

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

Kazumoto Kojima <kkojima at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.9/5/6 Regression] [SH]   |[5/6 Regression] [SH] Wrong
                   |Wrong code is generated     |code is generated with
                   |with stage1 compiler        |stage1 compiler

--- Comment #32 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #28)
I should have been more clear about these comparison messages.
Warning is warning and doesn't cause failure.  gcc/cc1*-checksum.o
objects depend on the virtual addresses of executables.  If
randomize-va-space feature of kernel on the target machine is used,
then stage2/3 cc1*-checksum.o differs without any compiler problem.
These differences are warned but aren't handled as errors for that reason.
It looks that the log for 4.8.4-2 includes
 gcc/d/ctfeexpr.dmd.o differs
line just after its 'Bootstrap comparison failure!' line.  It looks that
that is the cause of failure and is a differnt issue.

For the original PR, I've apply the fix on 5/6 in behalf of Oleg after
the regtest on trunk which has become possible because 66181 is fixed.

[Bug target/65979] [5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #33 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Kazumoto Kojima from comment #32)
> (In reply to John Paul Adrian Glaubitz from comment #28)
> I should have been more clear about these comparison messages.
> Warning is warning and doesn't cause failure.  gcc/cc1*-checksum.o
> objects depend on the virtual addresses of executables.  If
> randomize-va-space feature of kernel on the target machine is used,
> then stage2/3 cc1*-checksum.o differs without any compiler problem.
> These differences are warned but aren't handled as errors for that reason.

Aha, that would explain that, indeed as it. Checking on two of the buildds:

root@tirpitz:~> cat /proc/sys/kernel/randomize_va_space 
2
root@tirpitz:~> 

yamashiro:~# cat /proc/sys/kernel/randomize_va_space 
2
yamashiro:~#


> It looks that the log for 4.8.4-2 includes
>  gcc/d/ctfeexpr.dmd.o differs
> line just after its 'Bootstrap comparison failure!' line.  It looks that
> that is the cause of failure and is a differnt issue.

Ah, thanks for spotting that. Now, should we move this into a new bug report
then?

> For the original PR, I've apply the fix on 5/6 in behalf of Oleg after
> the regtest on trunk which has become possible because 66181 is fixed.

Great. Can't wait for the new gcc-5 package to arrive in Debian. Will report
back as soon as I know more.

Adrian

[Bug target/65979] [5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[olegendo at gcc dot gnu.org]

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

--- Comment #34 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #33)
> 
> > It looks that the log for 4.8.4-2 includes
> >  gcc/d/ctfeexpr.dmd.o differs
> > line just after its 'Bootstrap comparison failure!' line.  It looks that
> > that is the cause of failure and is a differnt issue.
> 
> Ah, thanks for spotting that. Now, should we move this into a new bug report
> then?

If 4.8.something doesn't bootstrap, it would be a "4.8 Regression" type of bug.
 I'd move it to a new PR.

[Bug target/65979] [5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[olegendo at gcc dot gnu.org]

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

--- Comment #36 from Oleg Endo <olegendo at gcc dot gnu.org> ---
It seems the tstsi peephole is still wrong.  While working on AMS the following
example:

int test (char* x, char* y, int z)
{
  return ((x[2] & x[3]) == 0) + z;
}

silently produced wrong code by omitting one of the two mem loads.  After an
update to the current trunk it results in

sh_tmp.cpp: In function 'int test(char*, char*, int)':
sh_tmp.cpp:6:1: error: insn does not satisfy its constraints:
 }
 ^
(insn 88 69 89 2 (set (reg:SI 1 r1)
        (sign_extend:SI (mem:QI (plus:SI (reg/v/f:SI 4 r4 [orig:169 x ] [169])
                    (const_int 3 [0x3])) [0 MEM[(char *)x_1(D) + 3B]+0 S1
A8]))) sh_tmp.cpp:5 232 {*extendqisi2_compact_mem_disp}
     (nil))

which I think is the same as PR 66611.  The tstsi related peephole at line
14709 is causing the trouble.

[Bug target/65979] [5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[olegendo at gcc dot gnu.org]

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

--- Comment #37 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #36)
> It seems the tstsi peephole is still wrong.  While working on AMS the
> following example:
> 
> int test (char* x, char* y, int z)
> {
>   return ((x[2] & x[3]) == 0) + z;
> }
> 
> silently produced wrong code by omitting one of the two mem loads.  After an
> update to the current trunk it results in
> 
> sh_tmp.cpp: In function 'int test(char*, char*, int)':
> sh_tmp.cpp:6:1: error: insn does not satisfy its constraints:
>  }
>  ^
> (insn 88 69 89 2 (set (reg:SI 1 r1)
>         (sign_extend:SI (mem:QI (plus:SI (reg/v/f:SI 4 r4 [orig:169 x ]
> [169])
>                     (const_int 3 [0x3])) [0 MEM[(char *)x_1(D) + 3B]+0 S1
> A8]))) sh_tmp.cpp:5 232 {*extendqisi2_compact_mem_disp}
>      (nil))
> 
> which I think is the same as PR 66611.  The tstsi related peephole at line
> 14709 is causing the trouble.

The peephole in question can't be used for code sequences that include QImode
or HImode mem loads of the operands.  The following fixes the issue by matching
the resulting insn pattern and the constraints while emitting the new peephole
insns.  I think it's good to do those full checks as opposed to checking for
the currently known problematic mem loads.  This way we an be sure that
whatever the "emit_insn (gen_rtx_SET ..." produces is actually valid code.

The problem exists on the 5 branch and on trunk.

Kaz, could you please add this to your test runs?  For me it's a bit difficult
to do proper testing at the moment.

Index: gcc/config/sh/sh.md
===================================================================
--- gcc/config/sh/sh.md (revision 224565)
+++ gcc/config/sh/sh.md (working copy)
@@ -14727,8 +14727,19 @@
   if (REGNO (operands[1]) == REGNO (operands[2]))
       operands[2] = gen_rtx_REG (SImode, REGNO (operands[0]));

-  sh_check_add_incdec_notes (emit_insn (gen_rtx_SET (operands[2],
-                                                    operands[3])));
+  // We don't know what the new set insn will be in detail.  Just make sure
+  // that it still can be recognized and the constraints are satisfied.
+  rtx_insn* i = emit_insn (gen_rtx_SET (operands[2], operands[3]));
+                                                    
+  recog_data_d prev_recog_data = recog_data;
+  bool i_invalid = insn_invalid_p (i, false); 
+  recog_data = prev_recog_data;
+  
+  if (i_invalid)
+    FAIL;
+    
+  sh_check_add_incdec_notes (i);
+
   emit_insn (gen_tstsi_t (operands[2],
                          gen_rtx_REG (SImode, (REGNO (operands[1])))));
 })
@@ -14755,8 +14766,19 @@
        || REGNO (operands[2]) == REGNO (operands[5]))"
   [(const_int 0)]
 {
-  sh_check_add_incdec_notes (emit_insn (gen_rtx_SET (operands[2],
-                                                    operands[3])));
+  // We don't know what the new set insn will be in detail.  Just make sure
+  // that it still can be recognized and the constraints are satisfied.
+  rtx_insn* i = emit_insn (gen_rtx_SET (operands[2], operands[3]));
+
+  recog_data_d prev_recog_data = recog_data;
+  bool i_invalid = insn_invalid_p (i, false); 
+  recog_data = prev_recog_data;
+  
+  if (i_invalid)
+    FAIL;
+    
+  sh_check_add_incdec_notes (i);
+  
   emit_insn (gen_tstsi_t (operands[2],
                          gen_rtx_REG (SImode, (REGNO (operands[1])))));
 })

[Bug target/65979] [5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[kkojima at gcc dot gnu.org]

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

--- Comment #38 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #37)
> Kaz, could you please add this to your test runs?  For me it's a bit
> difficult to do proper testing at the moment.

I'm testing the patch now.  I'll report back when it's done.

[Bug target/65979] [5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[kkojima at gcc dot gnu.org]

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

--- Comment #39 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #38)
> I'm testing the patch now.  I'll report back when it's done.

Done.  No new failures for the top level "make -k check".

[Bug target/65979] [5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #40 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Kazumoto Kojima from comment #39)
> Done.  No new failures for the top level "make -k check".

So, chances are gcc-5 would build now?

[Bug target/65979] [5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[kkojima at gcc dot gnu.org]

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

--- Comment #41 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #40)
> So, chances are gcc-5 would build now?

Maybe.  Trying it with Oleg's patch is a good idea.

[Bug target/65979] [5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[kkojima at gcc dot gnu.org]

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

--- Comment #43 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #42)
> Is it applied yet? Otherwise I really will have to look into building gcc-5
> from SVN myself.

It's not.

[Bug target/65979] [5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[olegendo at gcc dot gnu.org]

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

--- Comment #44 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Author: olegendo
Date: Thu Jun 25 23:12:07 2015
New Revision: 224988

URL: https://gcc.gnu.org/viewcvs?rev=224988&root=gcc&view=rev
Log:
gcc/
        PR target/65979
        PR target/66611
        * config/sh/sh.md (tstsi_t peephole2): Use insn_invalid_p to check if
        the replacement insn will work.

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

[Bug target/65979] [5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[olegendo at gcc dot gnu.org]

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

--- Comment #45 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Kaz, I wanted to backport the patch to GCC 5.  It doesn't apply because on
trunk gen_rtx_SET doesn't take a machine_mode arg.  Since SET rtx is always
VOIDmode, it has been removed.  In GCC 5 though, SImode is used for gen_rtx_SET
(see your comment #20).   Why is that SImode?  It should be VOIDmode, shouldn't
it?

[Bug target/65979] [5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[kkojima at gcc dot gnu.org]

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

--- Comment #46 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #45)
> Kaz, I wanted to backport the patch to GCC 5.  It doesn't apply because on
> trunk gen_rtx_SET doesn't take a machine_mode arg.  Since SET rtx is always
> VOIDmode, it has been removed.  In GCC 5 though, SImode is used for
> gen_rtx_SET (see your comment #20).   Why is that SImode?  It should be
> VOIDmode, shouldn't it?

You are right.  I should be VOIDmode, though SImode will work for these cases.

[Bug target/65979] [5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[olegendo at gcc dot gnu.org]

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

--- Comment #47 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Author: olegendo
Date: Sat Jun 27 00:46:58 2015
New Revision: 225094

URL: https://gcc.gnu.org/viewcvs?rev=225094&root=gcc&view=rev
Log:
gcc/
        Backport from mainline
        2015-06-25  Oleg Endo  <olegendo@gcc.gnu.org>

        PR target/65979
        PR target/66611
        * config/sh/sh.md (tstsi_t peephole2): Use insn_invalid_p to check if
        the replacement insn will work.

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

[Bug target/65979] [5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[olegendo at gcc dot gnu.org]

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

--- Comment #48 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Can we close this as fixed?

[Bug target/65979] [5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #49 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Oleg Endo from comment #48)
> Can we close this as fixed?

Yes.

[Bug target/65979] [5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[olegendo at gcc dot gnu.org]

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

Oleg Endo <olegendo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #50 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Fixed.