[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.  */