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 (;;) ; }
Looks like mixing of pic and non pic is causing the issue.
(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
(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
start FAIL r218767
Similar to PR64412, it looks to me that this PR needs similar treatment. Adding CC.
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.
(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. */
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?
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
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.
Created attachment 34855 [details] 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.
(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.
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
So, can the reporter or anyone else still reproduce a problem in this area or can it be considered fixed?
(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
Fixed then.