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

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

[glaubitz at physik dot fu-berlin.de]

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

            Bug ID: 67657
           Summary: [SH][5]: internal compiler error: in
                    cselib_record_set, at cselib.c:2396 when compiling
                    libjpeg-turbo
           Product: gcc
           Version: 5.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: glaubitz at physik dot fu-berlin.de
                CC: kkojima at gcc dot gnu.org, olegendo at gcc dot gnu.org
  Target Milestone: ---
            Target: sh*-*-*

Created attachment 36354
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36354&action=edit
Preprocessed source for cselib.c

Hi!

Just ran into another ICE which occurs when compiling libjpeg-turbo on SH:

jidctflt.c: In function 'jpeg_idct_float':
jidctflt.c:237:1: internal compiler error: in cselib_record_set, at
cselib.c:2396
 }
 ^
0x5fffc1 cselib_record_set
        ../../src/gcc/cselib.c:2396
0x5fffc1 cselib_record_sets
        ../../src/gcc/cselib.c:2613
0x600553 cselib_process_insn(rtx_insn*)
        ../../src/gcc/cselib.c:2686
0xa2da0b vt_initialize
        ../../src/gcc/var-tracking.c:10132
0xa31bd9 variable_tracking_main_1
        ../../src/gcc/var-tracking.c:10331
0xa31bd9 variable_tracking_main()
        ../../src/gcc/var-tracking.c:10384
0xa31bd9 execute
        ../../src/gcc/var-tracking.c:10421
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <file:///usr/share/doc/gcc-5/README.Bugs> for instructions.
Preprocessed source stored into /tmp/ccHHXJkq.out file, please attach this to
your bugreport.

This definitely looks like a regression as the same upstream version 1.4.1 of
libjpeg-turbo previously built fine with gcc-4.9 [1].

Attaching the pre-processed C sources with this bug report. The full build log
can be found in [2].

Adrian

> [1] https://buildd.debian.org/status/fetch.php?pkg=libjpeg-turbo&arch=sh4&ver=1%3A1.4.1-1&stamp=1438090332
> [2] https://buildd.debian.org/status/fetch.php?pkg=libjpeg-turbo&arch=sh4&ver=1%3A1.4.1-2&stamp=1442742941

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

[olegendo at gcc dot gnu.org]

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

--- Comment #1 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #0)
> Created attachment 36354 [details]
> Preprocessed source for cselib.c

Thanks for reporting.  I was a bit confused ... the attached source is not
cselib.c (which is a GCC file) but rather the problematic jidctflt.c

I've tried compiling it with sh-elf trunk and GCC 5 compilers with

-O2 -g -fPIE -fstack-protector-strong -m4 -ml -matomic-model=soft-gusa,strict

and with

-m4 -ml -matomic-model=soft-gusa,strict -g -O2 -fstack-protector-strong
-ffloat-store -fPIC -frandom-seed=0 -fdump-noaddr

but can't reproduce it.

[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 <kkojima at gcc dot gnu.org> ---
Created attachment 36356
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36356&action=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/67657] [SH][5]: internal compiler error: in cselib_record_set, at cselib.c:2396 when compiling libjpeg-turbo

[olegendo at gcc dot gnu.org]

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

--- Comment #3 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #2)
> Created attachment 36356 [details]
> reduced test case
> 
> I can reproduce it with trunk rev. 227929 but can't with 227887.
> Clearly very fragile.
> ...
> into the insn 2292.  Oleg, could you take a look?

Hm .. the peephole looks OK, but maybe emit_move_insn doesn't handle post-inc
properly and thus expands into the parallel.  I'll have a look.

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

[olegendo at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-09-21
     Ever confirmed|0                           |1

--- Comment #4 from Oleg Endo <olegendo at gcc dot gnu.org> ---
I can reproduce it with r227929 and "-x c -std=gnu99".  Funnily, it doesn't
happen with "-x c -std=c11" (which I usually use).

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

[olegendo at gcc dot gnu.org]

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

--- Comment #5 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #4)

Just for reference, those are the exact options:

-x c -std=gnu99 -m4 -ml -g -O2 -ffloat-store -fPIC

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

[olegendo at gcc dot gnu.org]

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

--- Comment #6 from Oleg Endo <olegendo at gcc dot gnu.org> ---
The peephole outputs this:

(insn 2292 0 0 (set (reg/v/f:SI 2 r2 [orig:320 outptr ] [320])
        (mem/f:SI (post_inc:SI (reg:SI 2 r2)) [2 MEM[base: _145, offset: 0B]+0
S4 A32])) -1
     (expr_list:REG_INC (reg:SI 2 r2)
        (nil)))


i.e.
      mov.l   @r2+,r2

and then things seem to go wrong.  Disabling the peephole shows the following
code in the output:

.L119:
        add     #64,r0
        mov.l   @(0,r0),r2
        add     #4,r2
        mov.l   r2,@(0,r0)
        add     #-4,r2         <<<
        mov.l   @r2+,r0        <<<
        mov     r0,r2          <<<
        mov.w   .L81,r0
        add     r15,r0
        mov.l   @(16,r0),r0
        add     r0,r2

The peephole should convert it to
        add     #-4,r2
        mov.l   @r2,r2

I'll come up with something.

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

[olegendo at gcc dot gnu.org]

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

--- Comment #7 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Created attachment 36357
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36357&action=edit
Proposed patch

Although a "mov @r2+,r2" is actually possible and valid (r2 will contain the
value loaded from memory, AFAIR), it doesn't make sense to keep the post-inc,
as the result will be overwritten anyway.  The patch catches those cases in the
peepholes and removes the post-inc.  I'm now testing this on sh-elf.

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

[olegendo at gcc dot gnu.org]

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

--- Comment #8 from Oleg Endo <olegendo at gcc dot gnu.org> ---
BTW, I'd recommend not specifying -ffloat-store on SH.  It doesn't affect FP
precision (unlike on x86) and just creates slower code.

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

[olegendo at gcc dot gnu.org]

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

--- Comment #9 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #7)
> Created attachment 36357 [details]
> Proposed patch
> 
> Although a "mov @r2+,r2" is actually possible and valid (r2 will contain the
> value loaded from memory, AFAIR), it doesn't make sense to keep the
> post-inc, as the result will be overwritten anyway.  The patch catches those
> cases in the peepholes and removes the post-inc.  I'm now testing this on
> sh-elf.

No new failures on sh-elf for make -k check
RUNTESTFLAGS="--target_board=sh-sim\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"

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

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #10 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Oleg Endo from comment #1)
> Thanks for reporting.  I was a bit confused ... the attached source is not
> cselib.c (which is a GCC file) but rather the problematic jidctflt.c

Oops, my bad, sorry!

(In reply to Oleg Endo from comment #8)
> BTW, I'd recommend not specifying -ffloat-store on SH.  It doesn't affect FP
> precision (unlike on x86) and just creates slower code.

Ok, I will send a bug report to the maintainers of libjpeg-turbo regarding
this, using your comment as reference.

(In reply to Oleg Endo from comment #9)
> No new failures on sh-elf for make -k check
> RUNTESTFLAGS="--target_board=sh-sim\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-
> mb,-m4a/-ml,-m4a/-mb}"

Sounds good, thanks!

Adrian

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

[olegendo at gcc dot gnu.org]

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

--- Comment #11 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #10)
> (In reply to Oleg Endo from comment #1)
> > Thanks for reporting.  I was a bit confused ... the attached source is not
> > cselib.c (which is a GCC file) but rather the problematic jidctflt.c
> 
> Oops, my bad, sorry!

No problem.

> 
> (In reply to Oleg Endo from comment #8)
> > BTW, I'd recommend not specifying -ffloat-store on SH.  It doesn't affect FP
> > precision (unlike on x86) and just creates slower code.
> 
> Ok, I will send a bug report to the maintainers of libjpeg-turbo regarding
> this, using your comment as reference.

Instead, they might want to try -ffast-math for the FP code...

> (In reply to Oleg Endo from comment #9)
> > No new failures on sh-elf for make -k check
> > RUNTESTFLAGS="--target_board=sh-sim\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-
> > mb,-m4a/-ml,-m4a/-mb}"
> 
> Sounds good, thanks!

I'd be surprised if it caught anything.  After all, this bug has not been
detected by the testsuite nor by the GCC 5 bootstrap.  I guess I'll just commit
it to trunk and GCC 5 branch.

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

[olegendo at gcc dot gnu.org]

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

--- Comment #12 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Author: olegendo
Date: Mon Sep 21 12:57:31 2015
New Revision: 227969

URL: https://gcc.gnu.org/viewcvs?rev=227969&root=gcc&view=rev
Log:
gcc/
        PR target/67657
        * config/sh/sh.c (sh_remove_overlapping_post_inc,
        sh_peephole_emit_move_insn): Add new functions.
        * config/sh/sh-protos.h (sh_remove_overlapping_post_inc,
        sh_peephole_emit_move_insn): Declere them.
        * config/sh/sh.md: Use them in various peephole2 patterns.

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/67657] [SH][5/6 Regression]: internal compiler error: in cselib_record_set, at cselib.c:2396 when compiling libjpeg-turbo

[olegendo at gcc dot gnu.org]

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

--- Comment #13 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Author: olegendo
Date: Mon Sep 21 13:14:45 2015
New Revision: 227970

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

        PR target/67657
        * config/sh/sh.c (sh_remove_overlapping_post_inc,
        sh_peephole_emit_move_insn): Add new functions.
        * config/sh/sh-protos.h (sh_remove_overlapping_post_inc,
        sh_peephole_emit_move_insn): Declere them.
        * config/sh/sh.md: Use them in various peephole2 patterns.

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

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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |5.3

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.

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

[olegendo at gcc dot gnu.org]

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

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

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

--- Comment #15 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #14)
> Fixed.

I was actually waiting for feedback/confirmation from Adrian... but well ..
yeah, I guess it can be closed.

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

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #16 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Oleg Endo from comment #15)
> (In reply to Richard Biener from comment #14)
> > Fixed.
> 
> I was actually waiting for feedback/confirmation from Adrian... but well ..
> yeah, I guess it can be closed.

A fixed version of gcc-5 on sh4 hasn't been built yet. We have currently
gcc-5_5.2.1-17 which was built on 2015-09-17, so before the change was
committed.

I'll let you know once we have a newer snapshot built and I can re-test
libjpeg-turbo.

Adrian