After revision r274997 I see the following failures FAIL: gfortran.dg/argument_checking_1.f90 -g -O3 -fwhole-program -flto (test for excess errors) FAIL: gfortran.dg/argument_checking_8.f90 -g -O3 -fwhole-program -flto (test for excess errors) FAIL: gfortran.dg/arrayio_derived_1.f90 -g -O3 -fwhole-program -flto (test for excess errors) FAIL: gfortran.dg/dtio_25.f90 -g -O3 -fwhole-program -flto (test for excess errors) FAIL: gfortran.dg/dtio_28.f03 -g -O3 -fwhole-program -flto (test for excess errors) FAIL: gfortran.dg/dtio_30.f03 -g -O3 -fwhole-program -flto (test for excess errors) FAIL: gfortran.dg/pr39865.f90 -g -O3 -fwhole-program -flto (test for excess errors) % /opt/gcc/gcc10p-274996p1/bin/gfortran /opt/gcc/_clean/gcc/testsuite/gfortran.dg/argument_checking_1.f90 -O3 -flto % /opt/gcc/gcc10p-274997p1/bin/gfortran /opt/gcc/_clean/gcc/testsuite/gfortran.dg/argument_checking_1.f90 -O3 -flto In function 'copy2', inlined from 'MAIN__' at /opt/gcc/_clean/gcc/testsuite/gfortran.dg/argument_checking_1.f90:13:0, inlined from 'main' at /opt/gcc/_clean/gcc/testsuite/gfortran.dg/argument_checking_1.f90:18:0: /opt/gcc/_clean/gcc/testsuite/gfortran.dg/argument_checking_1.f90:28: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] 28 | out(1:2,1:5) = in(1:2,1:5) | Note that pr39865.f90 requires -fwhole-program in order to give the warning. This is not fixed by the patch at https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00425.html
similar effects are repeatable on x86_64-linux-gnu and powerpc64-linux-gnu. e.g. on x86-64-linux-gnu: In function 'copy2', inlined from 'MAIN__' at /home/iains/gcc-trunk/src/gcc/testsuite/gfortran.dg/argument_checking_1.f90:13:0, inlined from 'main' at /home/iains/gcc-trunk/src/gcc/testsuite/gfortran.dg/argument_checking_1.f90:18:0: /home/iains/gcc-trunk/src/gcc/testsuite/gfortran.dg/argument_checking_1.f90:28: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] FAIL: gfortran.dg/argument_checking_1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) Excess errors: /home/iains/gcc-trunk/src/gcc/testsuite/gfortran.dg/argument_checking_1.f90:28:0: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
NOTE: the test passes without -flto, but fails with (although it's not shown in the options summary)
-Wstringop-overflow is only enabled for the C family plus LTO and with pr80545 resolved should now be disabled for Fortran, so something in the command line option handling is still not working right. My guess is the LTO setting in the warning entry in gcc/c-family/c.opt is behind it: Wstringop-overflow= C ObjC C++ LTO ObjC++ Joined RejectNegative UInteger Var(warn_stringop_overflow) Init(2) Warning LangEnabledBy(C ObjC C++ LTO ObjC++, Wall, 2, 0) IntegerRange(0, 4) The LTO handling of late warning options aside, I also suspect the warning code itself isn't dealing with the "special" MEM_REFs emitted for Fortran arrays quite right. I recently fixed a -Warray-bounds false positive for Fortran (pr91584) and it wouldn't surprise me if the code -Wstringop-overflow had a similar bug.
hmm that seems quite tricky, as if we are missing a more selective infrastructure for deciding whether a warning applies. Or do you expect to make it work for Fortran too?
I don't yet fully understand the interplay between LTO and the late warning (or other middle-end) options to tell how difficult that problem might be to fix. At Cauldron Jeff mentioned other problems in this area, such as LTO suppressing -Wall even when it's on the command line during compilation, or different translation units (or even functions via #pragma GCC diagnostic) being compiled with different warning options that LTO is expected to somehow merge when inlining. It does sound tricky. But -Wstringop-truncation shouldn't be any more noisy for Fotran code than it is for C, so the most expedient "fix"for this bug will probably be to correct the warning to handle the Fortran MEM_REFs (if it's wrong). This shouldn't be too hard if I can reproduce the problem without LTO (even without the warning itself). The checker still runs, it just doesn't emit any warnings (without LTO), so I can work with that. The general issue of the interaction between middle-end warning options and LTO can be dealt with separately.
I don't see these failures in recent test results for aarch64,powerpc64,x86_64}-linux so I'm going to resolve this as working. Dominique and/or Iain, please confirm and reopen if the failures persist on your targets (which ones?).