[Bug lto/64374] New: [5.0 regression] LTO ICE in extract_insn, at recog.c:2327

[Bug lto/64374] New: [5.0 regression] LTO ICE in extract_insn, at recog.c:2327

[dimhen at gmail dot com]

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

            Bug ID: 64374
           Summary: [5.0 regression] LTO ICE 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: dimhen at gmail dot com

r218764 PASS
r218817 FAIL, r218991 FAIL

Fedora 21 / x86_64

gcc -fpreprocessed -O3 -flto -c a.i -fPIC -DPIC -o a.o
g++ -fpreprocessed -O3 -flto -c b.ii -fPIC -DPIC -o b.o
g++ -fpreprocessed -O3 -flto -c e.ii -o e.o
g++ -flto -o x a.o b.o e.o

e.ii: In function ‘main’:
e.ii:10:1: error: unrecognizable insn:
 }
 ^
(insn 52 13 16 3 (set (reg/f:DI 5 di [orig:98 D.3984 ] [98])
        (plus:DI (reg:DI 0 ax [97])
            (symbol_ref:DI ("mOID_Params") [flags 0x2] <var_decl 0x7fe0f905f900
mOID_Params>))) a.i:13 -1
     (nil))
e.ii:10:1: internal compiler error: in extract_insn, at recog.c:2327
0xb230b8 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
    /home/dimhen/src/gcc_current/gcc/rtl-error.c:110
0xb23148 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
    /home/dimhen/src/gcc_current/gcc/rtl-error.c:118
0xad96f8 extract_insn(rtx_insn*)
    /home/dimhen/src/gcc_current/gcc/recog.c:2327
0xad97a7 extract_insn_cached(rtx_insn*)
    /home/dimhen/src/gcc_current/gcc/recog.c:2218
0x86f8c9 cleanup_subreg_operands(rtx_insn*)
    /home/dimhen/src/gcc_current/gcc/final.c:3124
0xad51b9 split_insn
    /home/dimhen/src/gcc_current/gcc/recog.c:2937
0xadd3ad split_all_insns()
    /home/dimhen/src/gcc_current/gcc/recog.c:2991
0xadd4c8 rest_of_handle_split_after_reload
    /home/dimhen/src/gcc_current/gcc/recog.c:3938
0xadd4c8 execute
    /home/dimhen/src/gcc_current/gcc/recog.c:3967
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.
lto-wrapper: fatal error: /usr/local/gcc_current/bin/g++ returned 1 exit status
compilation terminated.
/usr/bin/ld: fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status

$ /usr/local/gcc_current/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc_current/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc_current/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/dimhen/src/gcc_current/configure
--prefix=/usr/local/gcc_current/ --enable-checking=yes,df,rtl
--enable-languages=c,c++,lto --enable-plugin=yes --enable-static
Thread model: posix
gcc version 5.0.0 20141220 (experimental) [trunk revision 218991] (GCC) 

$ cat a.i
typedef struct {const int m} s;
s ms[];
int i;

int *Create ( )
{
  for ( ; ms[i].m; i++ )
    f1 ( &ms[i] );
}

$ cat b.ii
extern "C" {
  typedef unsigned CPCCreate_t(int *, int);
  CPCCreate_t CPCCreate;
  int *Create();
}

unsigned CPCCreate(int *, int)
{
  Create();
}

$ cat e.ii
extern "C" {
  typedef unsigned CPCCreate_t(int, int);
  CPCCreate_t CPCCreate;
}
main() {
  CPCCreate(0, 0);
  for (;;)
    ;
}
>From gcc-bugs-return-471535-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Dec 22 08:54:27 2014
Return-Path: <gcc-bugs-return-471535-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25473 invoked by alias); 22 Dec 2014 08:54: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 25424 invoked by uid 48); 22 Dec 2014 08:54:23 -0000
From: "dimhen at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/63805] ICE: in extract_insn, at recog.c:2327 with -mcpu=power8
Date: Mon, 22 Dec 2014 08:54: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: dimhen at gmail dot com
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-63805-4-Ts7DbYiNoU@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63805-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63805-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/msg02542.txt.bz2
Content-length: 297

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

--- Comment #3 from Dmitry G. Dyachenko <dimhen at gmail dot com> ---
(In reply to Dmitry G. Dyachenko from comment #2)
> I have similar error in LTO/x86_64, but stack is slightly different.

Its different issue (now PR64374)

Sorry for noise.

[Bug lto/64374] [5.0 regression] LTO ICE in extract_insn, at recog.c:2327

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Looks like mixing of pic and non pic is causing the issue.

[Bug lto/64374] [5.0 regression] LTO ICE in extract_insn, at recog.c:2327

[dimhen at gmail dot com]

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

--- Comment #2 from Dmitry G. Dyachenko <dimhen at gmail dot com> ---
(In reply to Andrew Pinski from comment #1)
> Looks like mixing of pic and non pic is causing the issue.

May be one more issue :
-- without '-O3' during compilation there are no error

[Bug lto/64374] [5.0 regression] LTO ICE in extract_insn, at recog.c:2327

[dimhen at gmail dot com]

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

--- Comment #3 from Dmitry G. Dyachenko <dimhen at gmail dot com> ---
(In reply to Dmitry G. Dyachenko from comment #0)
Oh, I edit files after copy/paste error message.
The correct one is the following:

e.ii: In function ‘main’:
e.ii:9:1: error: unrecognizable insn:
 }
 ^
(insn 52 13 16 3 (set (reg/f:DI 5 di [orig:98 D.3982 ] [98])
        (plus:DI (reg:DI 0 ax [97])
            (symbol_ref:DI ("ms") [flags 0x2] <var_decl 0x7f9b26cb4900 ms>)))
a.i:8 -1
     (nil))
e.ii:9:1: internal compiler error: in extract_insn, at recog.c:2327
0xb230b8 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
    /home/dimhen/src/gcc_current/gcc/rtl-error.c:110
0xb23148 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
    /home/dimhen/src/gcc_current/gcc/rtl-error.c:118
0xad96f8 extract_insn(rtx_insn*)
    /home/dimhen/src/gcc_current/gcc/recog.c:2327
0xad97a7 extract_insn_cached(rtx_insn*)
    /home/dimhen/src/gcc_current/gcc/recog.c:2218
0x86f8c9 cleanup_subreg_operands(rtx_insn*)
    /home/dimhen/src/gcc_current/gcc/final.c:3124
0xad51b9 split_insn
    /home/dimhen/src/gcc_current/gcc/recog.c:2937
0xadd3ad split_all_insns()
    /home/dimhen/src/gcc_current/gcc/recog.c:2991
0xadd4c8 rest_of_handle_split_after_reload
    /home/dimhen/src/gcc_current/gcc/recog.c:3938
0xadd4c8 execute
    /home/dimhen/src/gcc_current/gcc/recog.c:3967
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.
lto-wrapper: fatal error: /usr/local/gcc_current/bin/g++ returned 1 exit status
compilation terminated.
/usr/bin/ld: fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status
>From gcc-bugs-return-471545-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Dec 22 12:21:45 2014
Return-Path: <gcc-bugs-return-471545-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15021 invoked by alias); 22 Dec 2014 12:21:44 -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 14977 invoked by uid 48); 22 Dec 2014 12:21:39 -0000
From: "asolokha at gmx dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/62231] [4.8/4.9 regression] Exception handling broken on powerpc-e500v2-linux-gnuspe
Date: Mon, 22 Dec 2014 12:21: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: 4.8.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: asolokha at gmx dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P4
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.5
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-62231-4-AuoIWxROp3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62231-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62231-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/msg02552.txt.bz2
Content-length: 206

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

--- Comment #9 from Arseny Solokha <asolokha at gmx dot com> ---
Sure it has. The fix wasn't committed to the tree, otherwise it would be
reported here.

[Bug lto/64374] [5.0 regression] LTO ICE in extract_insn, at recog.c:2327

[rguenth at gcc dot gnu.org]

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

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

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

[Bug lto/64374] [5.0 regression] LTO ICE in extract_insn, at recog.c:2327

[dimhen at gmail dot com]

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

--- Comment #4 from Dmitry G. Dyachenko <dimhen at gmail dot com> ---
start FAIL r218767

[Bug lto/64374] [5.0 regression] LTO ICE in extract_insn, at recog.c:2327

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-01-13
     Ever confirmed|0                           |1

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #6)
> It can't have the same resolution though, that PR was resolved by not
> streaming the target nodes at all for offloading.  In this case there is no
> offloading.  If flag_pic is recorded somewhere in target node (where,
> x86_isa_flags, somewhere else?), then supposedly during LTO reading that
> should be updated from global flag_pic.  I think it doesn't make sense to
> have flag_pic only in some routines and not in others, so flag_pic should be
> treated as a global flag.

All flags that we still merge in lto-wrapper (see append_compiler_options)
need this treatment.

Honza, can you please make sure that for flags lto-wrapper puts on the
linker command-line we override the info in the nodes?  Though I wonder
why flag_pic ends up in either TARGET or OPTIMZIATION nodes at all.

In fact - it isn't there!

But I can confirm the ICE.

Note that instead of funnily "merging" mismatching fPIC settings at
compile-time
we maybe should error out in merge_and_complain instead as the comment says:

        case OPT_fPIC:
        case OPT_fpic:
        case OPT_fPIE:
        case OPT_fpie:
        case OPT_fcommon:
        case OPT_fexceptions:
        case OPT_fnon_call_exceptions:
        case OPT_fgnu_tm:
          /* Do what the old LTO code did - collect exactly one option
             setting per OPT code, we pick the first we encounter.
             ???  This doesn't make too much sense, but when it doesn't
             then we should complain.  */

[Bug lto/64374] [5.0 regression] LTO ICE in extract_insn, at recog.c:2327

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, the problem is in a mismatch between flag_pic and ix86_cmodel.
The former is a global flag, the latter is TargetSave, and
ix86_option_override_internal updates the ix86_cmodel flag based on whether
flag_pic is globally set or not.

Thus, I think we need to arrange for ix86_option_override_internal (or its
subset, at least related to ix86_cmodel flag) to be invoked during LTO reading.
 Honza, do we want a new target hook for that?

[Bug lto/64374] [5.0 regression] LTO ICE in extract_insn, at recog.c:2327

[hubicka at gcc dot gnu.org]

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

--- Comment #9 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
This is ugly issue indeed, I will look more into it tomorrow.
Optimally of course we should be able to handle -fPIC per symbol basis, but
that is hard to do. I guess having it handled via ix86_option_override_internal
is not a bad temporary plan.

Out of the options lto-wrapper handles, I think the following can be now
dropped:
        case OPT_fexceptions:
        case OPT_fnon_call_exceptions:
        case OPT_fshort_double:
        case OPT_fmath_errno:
        case OPT_fsigned_zeros:
        case OPT_ftrapping_math:
        case OPT_fwrapv:
        case OPT_ftrapv:
        case OPT_fstrict_overflow:
        case OPT_foffload_abi_:
        case OPT_O:
        case OPT_Ofast:
        case OPT_Og:
        case OPT_Os:

But that can probalby wait for stage1, they are harmless (I would not be
affraid to drop them now)

I think I missed the following in my weekend's common.opt update. It should be
Optimization.
        case OPT_fpcc_struct_return:
        case OPT_ffp_contract_:

I however think there are couple other options that may be wroth merging, like
-fdata-sections that does not go via optimization machinery.


Honza

[Bug lto/64374] [5 Regression] LTO ICE in extract_insn, at recog.c:2327

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I see another issue.  When we stream in OPTIMIZATION_NODE/TARGET_OPTIONS_NODE,
we don't use build_optimization_node/build_target_option_node and thus we don't
merge identical nodes by hashing them together in between different streamed in
TUs (or does it happen somehow else)?  If it doesn't happen, then it
unnecessarily slows down lto1, because it needs to reinitialize the backend
more often and switch in between different target options even when they are
effectively the same.
Though, of course, if we'd hash them together, we'd need to call some target
hook to resync the streamed in options with the global state before hashing
them together, because they can't be changed while they are in the hash table.

[Bug lto/64374] [5 Regression] LTO ICE in extract_insn, at recog.c:2327

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 34855
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34855&action=edit
gcc5-pr64374.patch

Untested fix.

Unfortunately I really can't reproduce it now, so can't verify the patch.
The testcase in #c0 looks very much broken, lots of undefined results, missing
f1 definition, so it really can't link successfully.  But I don't get an ICE at
all here.

[Bug lto/64374] [5 Regression] LTO ICE in extract_insn, at recog.c:2327

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #10)
> I see another issue.  When we stream in
> OPTIMIZATION_NODE/TARGET_OPTIONS_NODE, we don't use
> build_optimization_node/build_target_option_node and thus we don't merge
> identical nodes by hashing them together in between different streamed in
> TUs (or does it happen somehow else)?  If it doesn't happen, then it
> unnecessarily slows down lto1, because it needs to reinitialize the backend
> more often and switch in between different target options even when they are
> effectively the same.
> Though, of course, if we'd hash them together, we'd need to call some target
> hook to resync the streamed in options with the global state before hashing
> them together, because they can't be changed while they are in the hash
> table.

As discussed with Richard on IRC, this is likely non-issue - while the nodes
won't be merged using the normal hash table, they will be merged through LTO
tree merging.

[Bug lto/64374] [5 Regression] LTO ICE in extract_insn, at recog.c:2327

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Wed Feb 25 06:46:22 2015
New Revision: 220958

URL: https://gcc.gnu.org/viewcvs?rev=220958&root=gcc&view=rev
Log:
    PR lto/64374
    * target.def (target_option_stream_in): New target hook.
    * tree-streamer-in.c (streamer_read_tree_bitfields): Invoke
    targetm.target_option.post_stream_in if non-NULL.
    * doc/tm.texi.in: Add @hook TARGET_OPTION_POST_STREAM_IN.
    * doc/tm.texi: Updated.
    * config/i386/i386.c (ix86_function_specific_post_stream_in): New
    function.
    (TARGET_OPTION_POST_STREAM_IN): Redefine.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.c
    trunk/gcc/doc/tm.texi
    trunk/gcc/doc/tm.texi.in
    trunk/gcc/target.def
    trunk/gcc/tree-streamer-in.c

[Bug lto/64374] [5 Regression] LTO ICE in extract_insn, at recog.c:2327

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, can the reporter or anyone else still reproduce a problem in this area or
can it be considered fixed?

[Bug lto/64374] [5 Regression] LTO ICE in extract_insn, at recog.c:2327

[dimhen at gmail dot com]

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

--- Comment #15 from Dmitry G. Dyachenko <dimhen at gmail dot com> ---
(In reply to Jakub Jelinek from comment #14)
> So, can the reporter or anyone else still reproduce a problem in this area
> or can it be considered fixed?

last FAIL for me r219878
first PASS for me r219927
r220888 PASS for me

original issue with unreduced code go away starting r219927

[Bug lto/64374] [5 Regression] LTO ICE in extract_insn, at recog.c:2327

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed then.