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.