Tobias Burnus
2018-10-12 14:35:01 UTC
In the front-end optimization for matmul, we call lbound() for each matrix
argument to obtain the shift to the 0-based loop variables.
If the first argument is a PARAMETER, it appears initially as EXPR_VARIABLE
and has associated ref->u.ar for the AR_FULL and ref->u.ar.as contains the
bounds.
Running gfc_simplify_expr() on the generated lbound() will simplify the
array argument to an EXPR_ARRAY, which always has a lower bound of 1.
The problem starts as soon as the PARAMETER array has bounds which do not
start with 1 but, e.g., with 0 as with the test case: gfortran generates
than code which is off by one (reads the wrong element and beyond array
bounds).
Fixed by explicitly preventing this during gfc_simplify_expr. I hope that's
the only place where matters and that it doesn't cause missed optimizations.
Build and regtested on x86-64-linux.
OK for the trunk and - after a grace time - for GCC 6, 7 and 8?
Tobias
argument to obtain the shift to the 0-based loop variables.
If the first argument is a PARAMETER, it appears initially as EXPR_VARIABLE
and has associated ref->u.ar for the AR_FULL and ref->u.ar.as contains the
bounds.
Running gfc_simplify_expr() on the generated lbound() will simplify the
array argument to an EXPR_ARRAY, which always has a lower bound of 1.
The problem starts as soon as the PARAMETER array has bounds which do not
start with 1 but, e.g., with 0 as with the test case: gfortran generates
than code which is off by one (reads the wrong element and beyond array
bounds).
Fixed by explicitly preventing this during gfc_simplify_expr. I hope that's
the only place where matters and that it doesn't cause missed optimizations.
Build and regtested on x86-64-linux.
OK for the trunk and - after a grace time - for GCC 6, 7 and 8?
Tobias