[Bug c/65151] New: Internal compiler error when trying to build libav 11.2 on sh4

[Bug c/65151] New: Internal compiler error when trying to build libav 11.2 on sh4

[glaubitz at physik dot fu-berlin.de]

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

            Bug ID: 65151
           Summary: Internal compiler error when trying to build libav
                    11.2 on sh4
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: glaubitz at physik dot fu-berlin.de
            Target: sh*-*-*

Hi!

I just ran into another regression with gcc on SuperH, this time while trying
to compile libav 11.2 on gcc-4.9.2:

/«PKGBUILDDIR»/libavcodec/dpxenc.c: In function 'encode_frame':
/«PKGBUILDDIR»/libavcodec/dpxenc.c:176:1: internal compiler error: in
elimination_costs_in_insn, at reload1.c:3638
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.9/README.Bugs> for instructions.
Preprocessed source stored into /tmp/cchMsw9Z.out file, please attach this to
your bugreport.
/«PKGBUILDDIR»/Makefile:44: recipe for target 'libavcodec/dpxenc.o' failed
make[1]: *** [libavcodec/dpxenc.o] Error 1

I am attaching the preproccesed source file cchMsw9Z.out to this bugreport.

Full log can be found in [1].

Adrian

> [1] http://buildd.debian-ports.org/status/fetch.php?pkg=libav&arch=sh4&ver=6%3A11.2-1&stamp=1424475495
>From gcc-bugs-return-478032-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Feb 21 03:54:57 2015
Return-Path: <gcc-bugs-return-478032-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 5396 invoked by alias); 21 Feb 2015 03:54:56 -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 5378 invoked by uid 48); 21 Feb 2015 03:54:53 -0000
From: "bugger_gcc at interia dot pl" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/65152] New: Several friend function definitions break lookup
Date: Sat, 21 Feb 2015 05:13:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bugger_gcc at interia dot pl
X-Bugzilla-Status: UNCONFIRMED
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_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-65152-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-02/txt/msg02364.txt.bz2
Content-length: 1259

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

            Bug ID: 65152
           Summary: Several friend function definitions break lookup
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bugger_gcc at interia dot pl

When there is more than one class defining a friend function, name lookup fails
in the enclosing scope.

Live example: http://goo.gl/gwA3ej (also pasted at the bottom).

If either friend function definition at line 7 or 12 is commented out, the code
compiles and the call at line 18 correctly resolves to the global function.
However, with two friend functions defined the call results in compilation
error. The call is also resolved properly with the using declaration at line 17
uncommented, but this shouldn't be necessary since the friend functions
shouldn't alter the visibility of the global function and should only be
accessible via ADL.

The code:

void test(int);

namespace N {

struct A
{
  friend void test(A); // line 7
};

struct B
{
  friend void test(B); // line 12
};

void f()
{
  //using ::test;  // line 17
  test(0); // line 18
}

}

[Bug target/65151] Internal compiler error when trying to build libav 11.2 on sh4

[olegendo at gcc dot gnu.org]

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

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

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

--- Comment #1 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #0)
> 
> I am attaching the preproccesed source file cchMsw9Z.out to this bugreport.
> 

There are no attachments in this PR.  Could you please check again?

[Bug target/65151] Internal compiler error when trying to build libav 11.2 on sh4

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #2 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Created attachment 34822
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34822&action=edit
Pre-compiled source file for libav 11.2

[Bug target/65151] [SH][4.9 Regression] Internal compiler error when trying to build libav 11.2 on sh4

[olegendo at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-02-21
            Summary|Internal compiler error     |[SH][4.9 Regression]
                   |when trying to build libav  |Internal compiler error
                   |11.2 on sh4                 |when trying to build libav
                   |                            |11.2 on sh4
     Ever confirmed|0                           |1

--- Comment #3 from Oleg Endo <olegendo at gcc dot gnu.org> ---
I was able to reproduce the problem on 4.9 branch sh-elf with -m4 -ml -O3.
On trunk (GCC 5) it seems not to happen.

[Bug target/65151] [SH][4.9 Regression] Internal compiler error when trying to build libav 11.2 on sh4

[olegendo at gcc dot gnu.org]

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

--- Comment #5 from Oleg Endo <olegendo at gcc dot gnu.org> ---
The problem is the following insn:

(insn 45 11 12 2 (set (reg:HI 168 [ x ])
        (subreg/s/u:HI (reg:SI 147 t) 0)) cchMsw9Z.out:9 -1
     (expr_list:REG_DEAD (reg:SI 147 t)
        (nil)))

which is not in sh.md.
The insn is created by the asmcons pass.

[Bug target/65151] [SH][4.9 Regression] Internal compiler error when trying to build libav 11.2 on sh4

[olegendo at gcc dot gnu.org]

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

--- Comment #6 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #5)
> The problem is the following insn:
> 
> (insn 45 11 12 2 (set (reg:HI 168 [ x ])
>         (subreg/s/u:HI (reg:SI 147 t) 0)) cchMsw9Z.out:9 -1
>      (expr_list:REG_DEAD (reg:SI 147 t)
>         (nil)))
> 
> which is not in sh.md.
> The insn is created by the asmcons pass.

More precisely, it's 'emit_move_insn' in gcc/function.c in function
match_asm_constraints_1 at line 7152.
BTW, the test case from attachment 34825 also fails at -O1, -O2 and -Os.


On current trunk (GCC 5), the problem doesn't happen due to the treg_set_expr
stuff that has been recently added, it seems.

After combine, the insns are:

(insn 11 8 12 2 (parallel [
            (set (reg/v:SI 163 [ x ])
                (eq:SI (reg:SI 6 r6 [ bits_per_component ])
                    (const_int 10 [0xa])))
            (clobber (reg:SI 147 t))
        ]) 410 {any_treg_expr_to_reg}
     (expr_list:REG_UNUSED (reg:SI 147 t)
        (expr_list:REG_DEAD (reg:SI 6 r6 [ bits_per_component ])
            (nil))))
(insn 12 11 13 2 (set (reg:HI 170 [ x ])
        (asm_operands:HI ("swap.b %0,%0") ("=r") 0 [
                (subreg/s/v:HI (reg/v:SI 163 [ x ]) 0)
            ]
             [
                (asm_input:HI ("0") cchMsw9Z.out:8)
            ]
             [] cchMsw9Z.out:8)) cchMsw9Z.out:8 -1
     (expr_list:REG_DEAD (reg/v:SI 163 [ x ])
        (nil)))

Which is then converted by the treg_set_expr splitter code during the split1
pass into:

(insn 52 8 53 2 (set (reg:SI 147 t)
        (eq:SI (reg:SI 6 r6 [ bits_per_component ])
            (const_int 10 [0xa]))) -1
     (nil))
(insn 53 52 12 2 (set (reg/v:SI 163 [ x ])
        (reg:SI 147 t)) -1
     (expr_list:REG_UNUSED (reg:SI 147 t)
        (nil)))
(insn 12 53 13 2 (set (reg:HI 170 [ x ])
        (asm_operands:HI ("swap.b %0,%0") ("=r") 0 [
                (subreg/s/v:HI (reg/v:SI 163 [ x ]) 0)
            ]
             [
                (asm_input:HI ("0") cchMsw9Z.out:8)
            ]
             [] cchMsw9Z.out:8)) cchMsw9Z.out:8 -1
     (expr_list:REG_DEAD (reg/v:SI 163 [ x ])
        (nil)))

In asmcons, emit_move_insn then adds the following insn:

(insn 58 53 12 2 (set (reg:HI 170 [ x ])
        (subreg/s/v:HI (reg/v:SI 163 [ x ]) 0)) cchMsw9Z.out:8 -1
     (nil))

from there on everything works out.

[Bug target/65151] [SH][4.9 Regression] Internal compiler error when trying to build libav 11.2 on sh4

[olegendo at gcc dot gnu.org]

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

--- Comment #7 from Oleg Endo <olegendo at gcc dot gnu.org> ---
The following fixes the problem:

Index: gcc/config/sh/sh.c
===================================================================
--- gcc/config/sh/sh.c    (revision 220889)
+++ gcc/config/sh/sh.c    (working copy)
@@ -12049,6 +12049,9 @@
 bool
 sh_hard_regno_mode_ok (unsigned int regno, enum machine_mode mode)
 {
+  if (regno == T_REG)
+    return mode == SImode || mode == HImode || mode == QImode;
+
   if (SPECIAL_REGISTER_P (regno))
     return mode == SImode;

Index: gcc/config/sh/sh.md
===================================================================
--- gcc/config/sh/sh.md    (revision 220889)
+++ gcc/config/sh/sh.md    (working copy)
@@ -11224,6 +11224,13 @@
   "movt    %0"
   [(set_attr "type" "arith")])

+(define_insn "*movt"
+  [(set (match_operand:QIHI 0 "arith_reg_dest" "=r")
+    (match_operand:QIHI 1 "t_reg_operand"))]
+  "TARGET_SH1"
+  "movt    %0"
+  [(set_attr "type" "arith")])
+
 (define_insn "movrt"
   [(set (match_operand:SI 0 "arith_reg_dest" "=r")
     (xor:SI (match_operand:SI 1 "t_reg_operand" "") (const_int 1)))]


However, I've not tested it for any further side effects.

[Bug target/65151] [SH][4.9 Regression] Internal compiler error when trying to build libav 11.2 on sh4

[olegendo at gcc dot gnu.org]

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

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

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

--- Comment #8 from Oleg Endo <olegendo at gcc dot gnu.org> ---
I've also tried to see if the movrt pattern on SH2A has the same problem.  But
the only thing that seems to trigger it is a movt.  The patch in c#7 could also
be applied to trunk, just in case.  But I'm not sure if we should do so,
because on trunk the problem doesn't happen and I actually don't like the hunk
for sh_hard_regno_mode_ok, as everything in the backend treats T_REG as SImode.
Kaz, do you have any opinions?

[Bug target/65151] [SH][4.9 Regression] Internal compiler error when trying to build libav 11.2 on sh4

[kkojima at gcc dot gnu.org]

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

--- Comment #9 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #8)
> I've also tried to see if the movrt pattern on SH2A has the same problem. 
> But the only thing that seems to trigger it is a movt.  The patch in c#7
> could also be applied to trunk, just in case.  But I'm not sure if we should
> do so, because on trunk the problem doesn't happen and I actually don't like
> the hunk for sh_hard_regno_mode_ok, as everything in the backend treats
> T_REG as SImode.
> Kaz, do you have any opinions?

I have no idea other than that.

[Bug target/65151] [SH][4.9 Regression] Internal compiler error when trying to build libav 11.2 on sh4

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4
   Target Milestone|---                         |4.9.3

[Bug target/65151] [SH][4.9 Regression] Internal compiler error when trying to build libav 11.2 on sh4

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.3 has been released.

[Bug target/65151] [SH][4.9 Regression] Internal compiler error when trying to build libav 11.2 on sh4

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.3                       |4.9.4

[Bug target/65151] [SH][4.9 Regression] Internal compiler error when trying to build libav 11.2 on sh4

[thomas.petazzoni@free-electrons.com]

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

Thomas Petazzoni <thomas.petazzoni@free-electrons.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thomas.petazzoni@free-elect
                   |                            |rons.com

--- Comment #11 from Thomas Petazzoni <thomas.petazzoni@free-electrons.com> ---
(In reply to Jakub Jelinek from comment #10)
> GCC 4.9.3 has been released.

This problem still occurs with GCC 4.9.3, as far as I can see.

[Bug target/65151] [SH][4.9 Regression] Internal compiler error when trying to build libav 11.2 on sh4

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #12 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Thomas Petazzoni from comment #11)
> (In reply to Jakub Jelinek from comment #10)
> > GCC 4.9.3 has been released.
> 
> This problem still occurs with GCC 4.9.3, as far as I can see.

I'm actually not sure. There have been many changes to the SH backend ever
since and as Debian moved from libav to ffmpeg as the default library, I
haven't had a chance to test-build libav for a long time.

That will happen in the near future though, so thanks for reminding us of this
bug.

Adrian

[Bug target/65151] [SH][4.9 Regression] Internal compiler error when trying to build libav 11.2 on sh4

[thomas.petazzoni@free-electrons.com]

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

--- Comment #13 from Thomas Petazzoni <thomas.petazzoni@free-electrons.com> ---
(In reply to John Paul Adrian Glaubitz from comment #12)
> (In reply to Thomas Petazzoni from comment #11)
> > (In reply to Jakub Jelinek from comment #10)
> > > GCC 4.9.3 has been released.
> > 
> > This problem still occurs with GCC 4.9.3, as far as I can see.
> 
> I'm actually not sure. There have been many changes to the SH backend ever
> since and as Debian moved from libav to ffmpeg as the default library, I
> haven't had a chance to test-build libav for a long time.

I am quite sure, see
http://autobuild.buildroot.org/results/09b/09b08d329e632365dd8371371706dbeaa10539a3/build-end.log:

libavcodec/dpxenc.c: In function 'encode_frame':
libavcodec/dpxenc.c:162:1: internal compiler error: in
elimination_costs_in_insn, at reload1.c:3638

The toolchain, available at
http://autobuild.buildroot.org/toolchains/tarballs/br-sh4-full-2015.05-496-g85945aa.tar.bz2,
uses gcc 4.9.3.