https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80645
Jeffrey A. Law <law at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |law at redhat dot com
Summary|[8 regression] FAIL: |FAIL:
|gfortran.dg/elemental_subro |gfortran.dg/elemental_subro
|utine_3.f90 -O1 (test |utine_3.f90 -O1 (test
|for excess errors) |for excess errors)
--- Comment #8 from Jeffrey A. Law <law at redhat dot com> ---
I concur with Martin's analysis here in c#4 WRT the original report.
We're reading 16 bytes from an object that only has 12 bytes in it.
AFAICT either the test is bogus or the Fortran front-end is generating invalid
code. I have a gcc-6.3 handy and its .original output is equivalent for the
key elements.
I'm not versed in F90 to say if it's the test that is bogus or a goof in the
front-end. But either way the warning is pointing out a legitimate error that
is unlikely to be a regression.
The report in c#1 I don't see triggering on my tree, but I can see what Richi's
discusses in the dumps. AFAICT the paths leading to the allocation/memcpy in
question do not provide any useful range data for ubound.2_35. While there are
conditionals on ubound.2_35 which would normally provide range info -- there is
a merge point prior to the block Richi points out.
As a result there are no useful bounds on the allocation or memcpy (and I agree
we should be using the same object for both sizes, but don't).
So there's clearly either a testcase issue or front-end issue (per the original
report). But neither of those appear to be a regression to me.
If we want to look at the issues raised in c#2/c#3 further, we should do so as
a separate BZ rather than here.
I'm removing the regression marker, but keeping the BZ open because of the
testsuite/front-end bug.
