On Jan 4, 2017, Richard Biener <richard.guent...@gmail.com> wrote: > On Tue, Jan 3, 2017 at 6:29 AM, Alexandre Oliva <aol...@redhat.com> wrote: >> If we include them in the ICF hash, they may cause congruence_groups to >> be processed in a different order due to different hashes, which in turn >> causes different funcdef_nos to be assigned to functions. Since these >> numbers are included in -fcompare-debug dumps, they cause failures.
> Is this because ICF simply compares all optimize/target options? > So it boils down to -g implying -fvar-tracking but -g0 not? Not quite. It would be the same if -g or any other option that shouldn't affect the executable code output were used to compute that hash. -g is not among those flags, why should flags that adds detail to it be? (Really, -fvar-tracking should have been a -g subflag rather than an -f one) > I don't think this is ok -- 'Optimization' doesn't really mean optimization > but sth we can control per-function. You essentially remove the ability > to disable var-tracking just for a single (bad) function. I see the proposed patch does that indeed. There are other ways to accomplish that (disabling var-tracking for a single function), but I suppose a direct way is important. So I guess we need some alternate PerFunction option flag that makes it per-function, but not part of the ICF hash? -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
