[Bug lto/64374] [5.0 regression] LTO ICE in extract_insn, at recog.c:2327
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.0 regression] LTO ICE in extract_insn, at recog.c:2327
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64374 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Uroš Bizjak ubizjak at gmail dot com --- Similar to PR64412, it looks to me that this PR needs similar treatment. Adding CC.
[Bug lto/64374] [5.0 regression] LTO ICE in extract_insn, at recog.c:2327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64374 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- 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.
[Bug lto/64374] [5.0 regression] LTO ICE in extract_insn, at recog.c:2327
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
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
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
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
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
