[Bug lto/64412] New: [regression] ICE in offload compiler: in extract_insn, at recog.c:2327

[Bug lto/64412] New: [regression] ICE in offload compiler: in extract_insn, at recog.c:2327

[iverbin at gcc dot gnu.org]

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

            Bug ID: 64412
           Summary: [regression] ICE in offload compiler: in extract_insn,
                    at recog.c:2327
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: iverbin at gcc dot gnu.org
                CC: bernds at gcc dot gnu.org, hubicka at gcc dot gnu.org,
                    kyukhin at gcc dot gnu.org, tschwinge at gcc dot gnu.org

After fixing PR lto/64043 (r218767) the offload target compiler began crashing
while reading intermediate bytecode.

FAIL: libgomp.c/examples-4/e.53.5.c (internal compiler error)
FAIL: libgomp.c/for-3.c (internal compiler error)
FAIL: libgomp.c++/for-11.C (internal compiler error)
FAIL: libgomp.fortran/examples-4/e.53.3.f90   -O2  (internal compiler error)
etc.


To reproduce using Intel Xeon Phi emulation:
1. Build offload and host compilers as described in
https://gcc.gnu.org/wiki/Offloading#How_to_try_offloading_enabled_GCC
2. Run make check-target-libgomp RUNTESTFLAGS="c.exp=e.53.5.c"


libgomp/testsuite/libgomp.c/examples-4/e.53.5.c: In function 'accum._omp_fn.1':
libgomp/testsuite/libgomp.c/examples-4/e.53.5.c:53:13: error: unrecognizable
insn:
     #pragma omp parallel for reduction(+:tmp)
             ^
(insn 176 66 177 4 (set (reg:DI 0 ax)
        (symbol_ref:DI ("Q") <var_decl 0x7fb57ffcb900 Q>)) -1
     (nil))
libgomp/testsuite/libgomp.c/examples-4/e.53.5.c:53:13: internal compiler error:
in extract_insn, at recog.c:2327
0xbadaf7 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
        gcc/rtl-error.c:110
0xbadb38 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
        gcc/rtl-error.c:118
0xb60522 extract_insn(rtx_insn*)
        gcc/recog.c:2327
0xb60221 extract_constrain_insn(rtx_insn*)
        gcc/recog.c:2228
0xb6e973 copyprop_hardreg_forward_1
        gcc/regcprop.c:773
0xb701db execute
        gcc/regcprop.c:1279
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.
mkoffload-intelmic: fatal error:
x86_64-pc-linux-gnu-accel-x86_64-intelmicemul-linux-gnu-gcc returned 1 exit
status
compilation terminated.
lto-wrapper: fatal error: accel/x86_64-intelmicemul-linux-gnu/mkoffload
returned 1 exit status
compilation terminated.
ld: lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug lto/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2014-12-26
                 CC|                            |hjl.tools at gmail dot com
     Ever confirmed|0                           |1

--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to iverbin from comment #0)
> After fixing PR lto/64043 (r218767) the offload target compiler began
> crashing while reading intermediate bytecode.
> 
> FAIL: libgomp.c/examples-4/e.53.5.c (internal compiler error)
> FAIL: libgomp.c/for-3.c (internal compiler error)
> FAIL: libgomp.c++/for-11.C (internal compiler error)
> FAIL: libgomp.fortran/examples-4/e.53.3.f90   -O2  (internal compiler error)
> etc.
> 
> 
> To reproduce using Intel Xeon Phi emulation:
> 1. Build offload and host compilers as described in
> https://gcc.gnu.org/wiki/Offloading#How_to_try_offloading_enabled_GCC
> 2. Run make check-target-libgomp RUNTESTFLAGS="c.exp=e.53.5.c"

Can you create a stanalone testcase for the Intel Xeon Phi offload
cross compiler?  It will be easier to debug.

[Bug lto/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327

[iverbin at gcc dot gnu.org]

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

--- Comment #2 from iverbin at gcc dot gnu.org ---
(In reply to H.J. Lu from comment #1)
> (In reply to iverbin from comment #0)
> > To reproduce using Intel Xeon Phi emulation:
> > 1. Build offload and host compilers as described in
> > https://gcc.gnu.org/wiki/Offloading#How_to_try_offloading_enabled_GCC
> > 2. Run make check-target-libgomp RUNTESTFLAGS="c.exp=e.53.5.c"
> 
> Can you create a stanalone testcase for the Intel Xeon Phi offload
> cross compiler?  It will be easier to debug.

The offload model in GCC implies 2 compilers: one produces IR for OpenMP target
regions, and another compiles this IR for Intel Xeon Phi.
There is no single compiler, which could stream offload IR out, then stream it
in, and then compile.
I can reduce e.53.5.c testcase, not sure whether this is helpful.

[Bug target/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to iverbin from comment #2)
> (In reply to H.J. Lu from comment #1)
> > (In reply to iverbin from comment #0)
> > > To reproduce using Intel Xeon Phi emulation:
> > > 1. Build offload and host compilers as described in
> > > https://gcc.gnu.org/wiki/Offloading#How_to_try_offloading_enabled_GCC
> > > 2. Run make check-target-libgomp RUNTESTFLAGS="c.exp=e.53.5.c"
> > 
> > Can you create a stanalone testcase for the Intel Xeon Phi offload
> > cross compiler?  It will be easier to debug.
> 
> The offload model in GCC implies 2 compilers: one produces IR for OpenMP
> target regions, and another compiles this IR for Intel Xeon Phi.
> There is no single compiler, which could stream offload IR out, then stream
> it in, and then compile.
> I can reduce e.53.5.c testcase, not sure whether this is helpful.

Can you use "gcc -v -save-temps" to see what is passed to the offload
compiler and feed them to the offload compiler directly?

[Bug target/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327

[iverbin at gcc dot gnu.org]

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

--- Comment #5 from iverbin at gcc dot gnu.org ---
Created attachment 34350
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34350&action=edit
Source code

[Bug target/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327

[iverbin at gcc dot gnu.org]

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

--- Comment #4 from iverbin at gcc dot gnu.org ---
(In reply to H.J. Lu from comment #3)
> (In reply to iverbin from comment #2)
> > (In reply to H.J. Lu from comment #1)
> > > (In reply to iverbin from comment #0)
> > > > To reproduce using Intel Xeon Phi emulation:
> > > > 1. Build offload and host compilers as described in
> > > > https://gcc.gnu.org/wiki/Offloading#How_to_try_offloading_enabled_GCC
> > > > 2. Run make check-target-libgomp RUNTESTFLAGS="c.exp=e.53.5.c"
> > > 
> > > Can you create a stanalone testcase for the Intel Xeon Phi offload
> > > cross compiler?  It will be easier to debug.
> > 
> > The offload model in GCC implies 2 compilers: one produces IR for OpenMP
> > target regions, and another compiles this IR for Intel Xeon Phi.
> > There is no single compiler, which could stream offload IR out, then stream
> > it in, and then compile.
> > I can reduce e.53.5.c testcase, not sure whether this is helpful.
> 
> Can you use "gcc -v -save-temps" to see what is passed to the offload
> compiler and feed them to the offload compiler directly?

Yes, this is possible.
However, the function preload_common_nodes, modified in r218767, is used for
both IN/OUT streaming, therefore the IR should be produced and consumed by
compilers built from the same sources.

Here are the reduced testcase and corresponding IR for: gcc -fopenmp -O1 -S
pr64412.c

To reproduce the error:
1. Configure and make gcc with:
--enable-as-accelerator-for=x86_64-unknown-linux
--host=x86_64-intelmicemul-linux --build=x86_64-intelmicemul-linux
--target=x86_64-intelmicemul-linux
2. Run: as pr64412.s -o pr64412.o &&
x86_64-unknown-linux-accel-x86_64-intelmicemul-linux-gnu-gcc -xlto -fopenmp -O1
-shared -fPIC pr64412.o

[Bug target/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327

[iverbin at gcc dot gnu.org]

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

--- Comment #6 from iverbin at gcc dot gnu.org ---
Created attachment 34351
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34351&action=edit
pr64412.s

[Bug target/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #7 from H.J. Lu <hjl.tools at gmail dot com> ---
Confirmed.

[Bug target/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |5.0

[Bug target/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu <hjl.tools at gmail dot com> ---
Created attachment 34357
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34357&action=edit
A patch

Can you try this?

[Bug target/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327

[iverbin at gcc dot gnu.org]

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

--- Comment #11 from iverbin at gcc dot gnu.org ---
Created attachment 34360
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34360&action=edit
pr64412_2.s

[Bug target/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327

[iverbin at gcc dot gnu.org]

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

--- Comment #10 from iverbin at gcc dot gnu.org ---
Created attachment 34359
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34359&action=edit
pr64412_2.c

[Bug target/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #34357|0                           |1
        is obsolete|                            |

--- Comment #12 from H.J. Lu <hjl.tools at gmail dot com> ---
Created attachment 34361
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34361&action=edit
A new patch

Please try the new patch.

[Bug middle-end/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327

[ubizjak at gmail dot com]

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |middle-end

--- Comment #13 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to H.J. Lu from comment #12)
> Created attachment 34361 [details]
> A new patch
> 
> Please try the new patch.

No, this approach is wrong. ix86_fixup_binary_operands should not be used to
legitimize PIC address. The -fpic expansion is already wrong, since it
produces:

;; ivtmp.9_4 = (unsigned long) _37;

(insn 59 58 0 (parallel [
            (set (reg:DI 123 [ ivtmp.9 ])
                (plus:DI (reg:DI 124 [ D.3980 ])
                    (symbol_ref:DI ("G")  <var_decl 0x7f8c6facc900 G>)))
            (clobber (reg:CC 17 flags))
        ]) -1
     (nil))

This is similar to:

--cut here--
typedef __SIZE_TYPE__ size_t;

extern char G[8];

char *a (size_t z)
{
  return &G[z];
}
--cut here--

Without -fpic, the compiler expands to:

    6: {r90:DI=r89:DI+`G';clobber flags:CC;}

Compare this with -fpic expansion:

    6: r92:DI=[const(unspec[`G'] 2)]
    7: r91:DI=r92:DI
      REG_EQUAL `G'
    8: {r90:DI=r89:DI+r91:DI;clobber flags:CC;}

Looking at the above, it looks the problem is in the middle-end, where symbol
address should be legitimized through ix86_legitimize_address (a.k.a
TARGET_LEGITIMIZE_ADDRESS).
>From gcc-bugs-return-471929-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Dec 30 13:13:33 2014
Return-Path: <gcc-bugs-return-471929-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 17795 invoked by alias); 30 Dec 2014 13:13:32 -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 17762 invoked by uid 48); 30 Dec 2014 13:13:28 -0000
From: "colin.pitrat+gcc at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/64442] -O1 modify output of a simple computation with rounding
Date: Tue, 30 Dec 2014 13:13: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: 4.9.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: colin.pitrat+gcc at gmail dot com
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:
Message-ID: <bug-64442-4-mx7LChdIWF@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64442-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64442-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: 2014-12/txt/msg02936.txt.bz2
Content-length: 377

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

--- Comment #2 from Colin Pitrat <colin.pitrat+gcc at gmail dot com> ---
Yes I'm building on i686.

But I thought -O1 and -O2 were safe optimization that weren't supposed to
change the behaviour.

Moreover, I'm surprised that providing the list of -f flags -O1 is supposed to
enable doesn't allow me to reproduce the issue.

[Bug middle-end/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327

[hjl.tools at gmail dot com]

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

--- Comment #14 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Uroš Bizjak from comment #13)
> (In reply to H.J. Lu from comment #12)
> > Created attachment 34361 [details]
> > A new patch
> > 
> > Please try the new patch.
> 
> No, this approach is wrong. ix86_fixup_binary_operands should not be used to
> legitimize PIC address. The -fpic expansion is already wrong, since it
> produces:

> --cut here--
> typedef __SIZE_TYPE__ size_t;
> 
> extern char G[8];
> 
> char *a (size_t z)
> {
>   return &G[z];
> }
> --cut here--
> 
> Without -fpic, the compiler expands to:
> 
>     6: {r90:DI=r89:DI+`G';clobber flags:CC;}
> 
> Compare this with -fpic expansion:
> 
>     6: r92:DI=[const(unspec[`G'] 2)]
>     7: r91:DI=r92:DI
>       REG_EQUAL `G'
>     8: {r90:DI=r89:DI+r91:DI;clobber flags:CC;}
> 

This is generated in the backend:

Starting program: /export/build/gnu/gcc/build-x86_64-linux/gcc/cc1
-fpreprocessed /tmp/x.i -quiet -dumpbase x.i -mtune=generic -march=x86-64
-auxbase x -version -fPIC -o x.s
GNU C11 (GCC) version 5.0.0 20141228 (experimental) (x86_64-unknown-linux-gnu)
    compiled by GNU C version 4.8.3 20140911 (Red Hat 4.8.3-7), GMP version
5.1.2, MPFR version 3.1.2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C11 (GCC) version 5.0.0 20141228 (experimental) (x86_64-unknown-linux-gnu)
    compiled by GNU C version 4.8.3 20140911 (Red Hat 4.8.3-7), GMP version
5.1.2, MPFR version 3.1.2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: e92c7e019abbedeeeac36edef3dbfdca

Breakpoint 6, legitimize_pic_address (orig=0x7ffff19c8840, reg=0x0)
    at /export/gnu/import/git/gcc/gcc/config/i386/i386.c:13565
13565      rtx addr = orig;
(gdb) bt
#0  legitimize_pic_address (orig=0x7ffff19c8840, reg=0x0)
    at /export/gnu/import/git/gcc/gcc/config/i386/i386.c:13565
#1  0x0000000001082cf2 in ix86_expand_move (mode=DImode, 
    operands=0x7fffffffc840)
    at /export/gnu/import/git/gcc/gcc/config/i386/i386.c:17311
#2  0x00000000011a2c3f in gen_movdi (operand0=0x7ffff19c88b8, 
    operand1=0x7ffff19c8840)
    at /export/gnu/import/git/gcc/gcc/config/i386/i386.md:1938
#3  0x000000000084471f in insn_gen_fn::operator() (
    this=0x1a82330 <insn_data+201136>, a0=0x7ffff19c88b8, a1=0x7ffff19c8840)
    at /export/gnu/import/git/gcc/gcc/recog.h:303
#4  0x000000000091cb20 in emit_move_insn_1 (x=0x7ffff19c88b8, y=0x7ffff19c8840)
    at /export/gnu/import/git/gcc/gcc/expr.c:3529
#5  0x000000000091cf74 in emit_move_insn (x=0x7ffff19c88b8, y=0x7ffff19c8840)
    at /export/gnu/import/git/gcc/gcc/expr.c:3624
...
(gdb) call debug_rtx (orig)
(symbol_ref:DI ("G") [flags 0x40] <var_decl 0x7ffff189e900 G>)
(gdb)
>From gcc-bugs-return-471931-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Dec 30 13:41:02 2014
Return-Path: <gcc-bugs-return-471931-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29385 invoked by alias); 30 Dec 2014 13:41:02 -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 29364 invoked by uid 48); 30 Dec 2014 13:40:58 -0000
From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/64443] New std::string implementation breaks tests on AArch64.
Date: Tue, 30 Dec 2014 13:41:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pinskia at gcc dot gnu.org
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:
Message-ID: <bug-64443-4-7qbsFfq2Bv@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64443-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64443-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: 2014-12/txt/msg02938.txt.bz2
Content-length: 221

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>This commit seems to be breaking libstdc++-v3 runs on AArch64.

Is this under Linux or with newlib?

[Bug middle-end/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327

[ubizjak at gmail dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 3062 bytes --]

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

--- Comment #15 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to H.J. Lu from comment #14)

> This is generated in the backend:

Yes, but the question is, why somehow similar testcase legitimizes the address
correctly with -fpic, while the original testcase doesn't.
>From gcc-bugs-return-471935-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Dec 30 14:36:46 2014
Return-Path: <gcc-bugs-return-471935-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 20174 invoked by alias); 30 Dec 2014 14:36:46 -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 20147 invoked by uid 48); 30 Dec 2014 14:36:42 -0000
From: "nagl46 at web dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/64445] New: virtual functions polymorphism
Date: Tue, 30 Dec 2014 14:36: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.7.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: nagl46 at web dot de
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 attachments.created
Message-ID: <bug-64445-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: 2014-12/txt/msg02942.txt.bz2
Content-length: 960

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

            Bug ID: 64445
           Summary: virtual functions polymorphism
           Product: gcc
           Version: 4.7.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: nagl46 at web dot de

Created attachment 34364
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id4364&actioníit
example of described bug

A base class "base" has two virtual functions

virtual void Y( float xx );
virtual void Y( int xx);

A new class "ext" that inherits from base class re-implements the function

virtual void Y( float xx );

Calling function Y(float) on a pointer "base *" pointing to an ext instance
results in a call to "base::Y(int)".

I would expect a call to the "ext::Y(float)" function. Is it a bug or is it my
mistake?

It's the same behavior in gcc 4.7.2 and gcc 5.0.0.

[Bug middle-end/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327

[hjl.tools at gmail dot com]

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

--- Comment #16 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Uroš Bizjak from comment #15)
> (In reply to H.J. Lu from comment #14)
> 
> > This is generated in the backend:
> 
> Yes, but the question is, why somehow similar testcase legitimizes the
> address correctly with -fpic, while the original testcase doesn't.

My impressions are most of PIC addresses like:

    6: r92:DI=[const(unspec[`G'] 2)]
    7: r91:DI=r92:DI
      REG_EQUAL `G'
    8: {r90:DI=r89:DI+r91:DI;clobber flags:CC;}

is generated by x86 backend vi ix86_expand_move and x86 backend was never
presented with other opportunities before.  X86 backend isn't prepared to
handle some RTL expansions from offload.
>From gcc-bugs-return-471941-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Dec 30 15:30:26 2014
Return-Path: <gcc-bugs-return-471941-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 20985 invoked by alias); 30 Dec 2014 15:30:25 -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 20564 invoked by uid 48); 30 Dec 2014 15:30:20 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/64368] [5 Regression] Several libstdc++ test failures on darwin and others after r218964.
Date: Tue, 30 Dec 2014 15:30: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.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: NEW
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-64368-4-etzb5y7mjt@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64368-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64368-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: 2014-12/txt/msg02948.txt.bz2
Content-length: 260

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

--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Apologies, I should read emails more carefully when I'm ill, or not respond at
all!

I plan to spend time on this later this week. HNY all!

[Bug middle-end/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327

[ubizjak at gmail dot com]

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

--- Comment #17 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to H.J. Lu from comment #16)
> > > This is generated in the backend:
> > 
> > Yes, but the question is, why somehow similar testcase legitimizes the
> > address correctly with -fpic, while the original testcase doesn't.
> 
> My impressions are most of PIC addresses like:
> 
>     6: r92:DI=[const(unspec[`G'] 2)]
>     7: r91:DI=r92:DI
>       REG_EQUAL `G'
>     8: {r90:DI=r89:DI+r91:DI;clobber flags:CC;}
> 
> is generated by x86 backend vi ix86_expand_move and x86 backend was never
> presented with other opportunities before.  X86 backend isn't prepared to
> handle some RTL expansions from offload.

The x86 backend did survive many years just fine, so I think offload should be
fixed to follow approach that generic middle-end takes. The testcase I posted
expands without problems; in this case middle-end knows that symbol address has
to be moved to a register. It looks like offload bypasses generic expansion
functions (that would magically fix this issue).
>From gcc-bugs-return-471944-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Dec 30 15:34:02 2014
Return-Path: <gcc-bugs-return-471944-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 24427 invoked by alias); 30 Dec 2014 15:34:02 -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 24400 invoked by uid 48); 30 Dec 2014 15:33:58 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/64443] New std::string implementation breaks tests on AArch64.
Date: Tue, 30 Dec 2014 15:34:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
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:
Message-ID: <bug-64443-4-fPMfnavwR9@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64443-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64443-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: 2014-12/txt/msg02951.txt.bz2
Content-length: 214

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

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Probably the same issue as PR 64368 so it's probably a problem with the non-gnu
clocale model.

[Bug middle-end/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327

[iverbin at gcc dot gnu.org]

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

--- Comment #18 from iverbin at gcc dot gnu.org ---
(In reply to Uroš Bizjak from comment #17)
> The x86 backend did survive many years just fine, so I think offload should
> be fixed to follow approach that generic middle-end takes. The testcase I
> posted expands without problems; in this case middle-end knows that symbol
> address has to be moved to a register. It looks like offload bypasses
> generic expansion functions (that would magically fix this issue).

It seems that the problem with offload is that -fPIC option is passed to the
offload compiler, but not passed to the host compiler. If I add -fPIC to the
host compiler as well, everything is ok.

Offload RTL for pic host, pic offload:
  (insn 8 6 9 4 (set (reg:DI 88)
          (mem/u/c:DI (const:DI (unspec:DI [
                          (symbol_ref:DI ("G")  <var_decl 0x7f2c78238c60 G>)
                      ] UNSPEC_GOTPCREL)) [0  S8 A8])) addr.c:6 -1
       (nil))

Offload RTL for nonpic host, pic offload:
  (insn 8 6 9 4 (set (reg:CC 17 flags)
          (compare:CC (mem/f/c:DI (plus:DI (reg/f:DI 82 virtual-stack-vars)
                      (const_int -8 [0xfffffffffffffff8])) [0 p+0 S8 A64])
              (symbol_ref:DI ("G")  <var_decl 0x7f5546a88c60 G>))) addr.c:6 -1
       (nil))

I don't know how -fPIC option affects IR before streaming out,
-fdump-tree-optimized are identical for pic/nonpic cases, but
.gnu.offload_lto_.decls sections are different. However debug_tree
(vnode->decl) for "G" in ipa_write_summaries are identical for pic/nonpic
cases.

So, the question is, how to figure out what is different in G's declaration in
IR, and how it can affect further expansion?
>From gcc-bugs-return-471989-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Dec 31 12:59:27 2014
Return-Path: <gcc-bugs-return-471989-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 14020 invoked by alias); 31 Dec 2014 12:59:27 -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 13987 invoked by uid 48); 31 Dec 2014 12:59:23 -0000
From: "hjl.tools at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/64447] [5 Regression] FAIL: gcc.dg/vect/slp-9.c
Date: Wed, 31 Dec 2014 12:59:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ipa
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: blocker
X-Bugzilla-Who: hjl.tools at gmail dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-64447-4-FVYaJ3ztQv@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64447-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64447-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: 2014-12/txt/msg02996.txt.bz2
Content-length: 425

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

H.J. Lu <hjl.tools at gmail dot com> changed:

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

--- Comment #7 from H.J. Lu <hjl.tools at gmail dot com> ---
Fixed by r219120.

[Bug middle-end/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327

[iverbin at gcc dot gnu.org]

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

--- Comment #19 from iverbin at gcc dot gnu.org ---
(In reply to iverbin from comment #18)
> It seems that the problem with offload is that -fPIC option is passed to the
> offload compiler, but not passed to the host compiler. If I add -fPIC to the
> host compiler as well, everything is ok.
> 
> I don't know how -fPIC option affects IR before streaming out,
> -fdump-tree-optimized are identical for pic/nonpic cases, but
> .gnu.offload_lto_.decls sections are different. However debug_tree
> (vnode->decl) for "G" in ipa_write_summaries are identical for pic/nonpic
> cases.
> 
> So, the question is, how to figure out what is different in G's declaration
> in IR, and how it can affect further expansion?

The regression is caused by LTO streaming of TARGET_OPTIMIZE_NODE:
https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00376.html

[Bug middle-end/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
http://gcc.gnu.org/ml/gcc-patches/2014-11/msg02654.html seems to fix all these.

[Bug middle-end/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327

[jakub at gcc dot gnu.org]

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

--- Comment #21 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Fri Jan  9 21:38:00 2015
New Revision: 219410

URL: https://gcc.gnu.org/viewcvs?rev=219410&root=gcc&view=rev
Log:
    PR middle-end/64412
    * lto-streamer.h (lto_stream_offload_p): New declaration.
    * lto-streamer.c (lto_stream_offload_p): New variable.
    * cgraphunit.c (ipa_passes): Set lto_stream_offload_p
    at the same time as section_name_prefix.
    * lto-streamer-out.c (hash_tree): Don't hash TREE_TARGET_OPTION
    if lto_stream_offload_p.
    * tree-streamer-out.c (streamer_pack_tree_bitfields): Don't
    stream TREE_TARGET_OPTION if lto_stream_offload_p.
    (write_ts_function_decl_tree_pointers): Don't
    stream DECL_FUNCTION_SPECIFIC_TARGET if lto_stream_offload_p.
    * tree-streamer-in.c (unpack_value_fields): Don't stream
    TREE_TARGET_OPTION in if ACCEL_COMPILER.
    (lto_input_ts_function_decl_tree_pointers): Don't stream
    DECL_FUNCTION_SPECIFIC_TARGET in if ACCEL_COMPILER.
    * lto-opts.c (lto_write_options): Use lto_stream_offload_p
    instead of section_name_prefix string comparisons.
lto/
    * lto.c (read_cgraph_and_symbols): Set lto_stream_offload_p
    if ACCEL_COMPILER.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cgraphunit.c
    trunk/gcc/lto-opts.c
    trunk/gcc/lto-streamer-out.c
    trunk/gcc/lto-streamer.c
    trunk/gcc/lto-streamer.h
    trunk/gcc/lto/ChangeLog
    trunk/gcc/lto/lto.c
    trunk/gcc/tree-streamer-in.c
    trunk/gcc/tree-streamer-out.c

[Bug middle-end/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Should be fixed now.