https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120747
--- Comment #13 from Filip Kastl <pheeck at gcc dot gnu.org> --- My theory is that the "miscompiled" functions are actually two: inl1100 and inl1120. If I compile these two functions with r16-1549 and the rest of innerf.f with r16-1550, I get the same gromacs output as when compiling the entire gromacs with r16-1549. My approach in greater detail: I patched r16-1550 so that I can turn off Andrew's changes using debug counters (thanks to the people that suggested this to me). diff --git a/gcc/dbgcnt.def b/gcc/dbgcnt.def index ac23a85567e..bd5477dbc5b 100644 --- a/gcc/dbgcnt.def +++ b/gcc/dbgcnt.def @@ -163,6 +163,7 @@ DEBUG_COUNTER (dse) DEBUG_COUNTER (dse1) DEBUG_COUNTER (dse2) DEBUG_COUNTER (ext_dce) +DEBUG_COUNTER (foo_counter) DEBUG_COUNTER (form_fma) DEBUG_COUNTER (gcse2_delete) DEBUG_COUNTER (gimple_unroll) diff --git a/gcc/value-range.cc b/gcc/value-range.cc index 5e97fdb7691..43d613d6697 100644 --- a/gcc/value-range.cc +++ b/gcc/value-range.cc @@ -31,6 +31,9 @@ along with GCC; see the file COPYING3. If not see #include "fold-const.h" #include "gimple-range.h" +#include "dbgcnt.h" +#include "print-tree.h" + // Return the bitmask inherent in a range : TYPE [MIN, MAX]. // This use to be get_bitmask_from_range (). @@ -2442,7 +2445,10 @@ irange::set_range_from_bitmask () // Make sure we call intersect, so do it first. changed = intersect (mask_range) | changed; // Npw make sure each subrange endpoint matches the bitmask. - changed |= snap_subranges (); + if (!dbg_cnt (foo_counter)) + changed |= snap_subranges (); + else + debug_tree(cfun->decl); return changed; } So if I do gfortran -std=legacy -c -o innerf.o -Ofast -g -march=native -mtune=native innerf.f -fdbg-cnt=foo_counter:662-679:716-733 between 662th and 679th trigger of the debug counter, the call to snap_subranges() is skipped and the same between 716th and 733th trigger. Thanks to debug_tree(cfun->decl) I know that these skips happen while compiling inl1100 and inl1120. When I link gromacs with innerf.o compiled in this way, the output (gromacs.out) is -3.23724e+05 3.09998e+02 1.06630e+10 which is the same as when I compile gromacs with r16-1549. Btw, compiling gromacs purely with r16-1550: -3.23364e+05 3.12012e+02 1.06604e+10 the reference values: -3.22397e+05 3.07684e+02 1.06621e+10 compiling gromacs with -fdbg-cnt=foo_counter:662-679: -3.22599e+05 3.07123e+02 1.06713e+10 compiling gromacs with -fdbg-cnt=foo_counter:716-733: -3.22302e+05 3.08683e+02 1.06655e+10 This is why I think that the "miscompilation" is both in inl1100 and inl1120.
