------- Comment #1 from burnus at gcc dot gnu dot org 2010-07-01 14:53 -------
I think it is not really a regression in terms of the code path. gfortran
checks bounds of the form (tree dump)
procedure(&result,...)
but not of the form
procedure(&tmp)
result = tmp
Thus, gfortran also misses (all versions):
a(i:1) = f(b)*1.0
Thus, the RHS = LHS check is missing at some point (i.e. the call to
gfc_trans_array_bound_check) - if there is an array temporary involved.
Vaguely related: PR 32454.
There is actually some bounds check for line 7. First, one for the LHS ("is
a(i:1) in the range?"), which works just fine, and then for the RHS (simplified
dump):
D.1609 = size(b)
D.1611 = D.1609
if (D.1611 > 0 && D.1609 <= 0)
if (D.1611 > 0 && D.1611 <= 0)
if (D.1611 > 0 && D.1611 > D.1609)
atmp.14.data = __builtin_malloc (MAX_EXPR <D.1611, 1>);
Thus - not surprisingly, the temporary is conforming with the the required
size.
Actually, I wonder why we generate checking code if it is known that the size
fits, e.g. "a(i:1)" does not need a check as both in the declaration and in
the usage, the bound is an integer constant; the optimizer should be able to
fix this, but I think one can handle this already in the front end - at least
for the lbound, one often knows the bounds. Something involving INTEGER_CST_P
with TREE_INT_CST_HIGH and/or TREE_INT_CST_LOW should do ...
Expected: If there is a temporary, one should not compare (uselessly) whether
the temporary has the right size but whether the RHS matches the LHS.
--
burnus at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
OtherBugsDependingO| |27766
nThis| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44744
