Bug 91699 - [10 Regression] Bogus Wstringop-overflow in Fotran with -flto after revision r274997
Summary: [10 Regression] Bogus Wstringop-overflow in Fotran with -flto after revision ...
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 10.0
: P1 normal
Target Milestone: 10.0
Assignee: Not yet assigned to anyone
Keywords: diagnostic, lto
Depends on:
Blocks: Wstringop-overflow
  Show dependency treegraph
Reported: 2019-09-07 12:42 UTC by Dominique d'Humieres
Modified: 2020-01-17 15:34 UTC (History)
2 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2019-09-20 00:00:00


Note You need to log in before you can comment on or make changes to this bug.
Description Dominique d'Humieres 2019-09-07 12:42:35 UTC
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
Comment 1 Iain Sandoe 2019-09-20 20:05:42 UTC
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=]
Comment 2 Iain Sandoe 2019-09-20 20:07:15 UTC
NOTE: the test passes without -flto, but fails with (although it's not shown in the options summary)
Comment 3 Martin Sebor 2019-09-20 20:24:47 UTC
-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:

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.
Comment 4 Iain Sandoe 2019-09-20 20:44:14 UTC
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?
Comment 5 Martin Sebor 2019-09-20 21:03:49 UTC
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.
Comment 6 Martin Sebor 2020-01-17 15:34:54 UTC
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?).