https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101919
Mikael Morin <mikael at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mikael at gcc dot gnu.org
--- Comment #8 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to anlauf from comment #7)
> (In reply to anlauf from comment #4)
> > This fixes comment#2:
> >
> > diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
>
> However, it does not fix the following even simpler example:
>
> subroutine foo (d, e)
> implicit none
> character(len=10) :: d
> character(len=*) :: e
> integer :: i = 0
> d = '1234567890'(6 :10+i) ! Warning
> d = '1234567890'(6+0*i:10+i) ! Warning
> d = '1234567890'(6+1*i:10+i) ! OK
> e = '1234567890'(6 :10+i) ! OK
> end
>
> The code appears to work as expected, but I cannot find a way to suppress
> the warning at -flto -O0.
This is a known problem, not limited to fortran.
With -O0, dead code is not removed, and can trigger warnings, even if there is
a branch guarding it that prevents its execution.
Similarly, in comment #6, len_trim is not inlined, so the compiler can make no
assumption on the value it may return. But for the actual value that it will
actually return, the branches of code triggering the warning won't be executed.
(In reply to Martin Sebor from comment #1)
> Confirmed with 11 and top of trunk. I think there are two problems: 1)
> -Wstringop-overread is a C/C++ only option that shouldn't be issued for
> FORTRAN code, and 2) the code the warning triggers for in the IL does look
> invalid:
>
> <bb 3> [local count: 536870913]:
> _8 = _gfortran_string_len_trim (100, &c);
> _9 = (integer(kind=4)) _8;
> _10 = (integer(kind=8)) _9;
> if (_10 <= 111)
> goto <bb 4>; [50.00%]
> else
> goto <bb 5>; [50.00%]
>
> <bb 5> [local count: 268435456]:
> __builtin_memmove (&c, &c[13]{lb: 1 sz: 1}, 100); <<< warning here
>
> If I'm reading the FORTRAN code right, c is an array of 100 characters. The
> memmove call copies 100 characters from &c[13], which would make the copy
> out of bounds.
>
That's true, but _gfortran_string_len_trim won't return more than 100, so bb5
is unreachable.
I don't think there is wrong code here.
