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