Hi Jerry, hi all,
sorry for the slow patch review. I also still want to review your other
inquire patch.
Jerry DeLisle wrote:
The fundamental problem: if the variable containing the unit number in
an INQUIRE statement is of type KIND greater than 4 and the value is
outside the range of a KIND=4 we cannot test for it within the
run-time library. Unit numbers are passed to the run-time in the
IOPARM structures as a KIND=4. KIND=8 are cast into the KIND=4. The
test case gfortran.dg/negative_unit_int8.f illustrates a case where a
bogus unit number can get passed to the library.
Regression tested on x86-64 and Joost's case in the PR now works as
expected.
OK for trunk?
Mostly OK, however, some remarks are below.
2015-01-18 Jerry DeLisle <jvdeli...@gcc.gnu.org>
PR fortran/61933
* trans-io.c (set_parameter_value): Delete use of has_iostat.
Redefine to not generate any runtime error check calls.
(set_parameter_value_chk): Rename of the former
set_parameter_value with the runtimr error checks and fix
whitespace. (gfc_trans_io_inquire_check): New function that
builds a runtime conditional block to set the INQUIRE
common parameter block unit number to -2 when unit numbers
exceed positive KIND=4 limits. (set_parameter_value_inquire):
New function that builds the conditional expressions and calls
gfc_trans_io_inquire_check. (gfc_trans_open): Whitespace. For
unit, use the renamed set_parameter_value_chk.
(gfc_trans_close): Likewise use renamed function.
(build_filepos): Whitespace and use renamed function.
(gfc_trans_inquire): Whitespace and for unit use
set_parameter_value and set_parameter_value_inquire.
(gfc_trans_wait): Remove p->iostat from call to
set_parameter_value. Use new set_parameter_value_chk for unit.
(build_dt): Use the new set_parameter_value without p->iostat
and fix whitespace. Use set_parameter_value_chk for unit.
2015-01-18 Jerry DeLisle <jvdeli...@gcc.gnu.org>
PR libgfortran/61933
* io/inquire.c (inquire_via_unit): Set existing to true for
any negative unit that is currently connected and any positive
units within range of KIND=4 value. The unit value for any out
of range case that may occur if the user is using a KIND=8 will
have been set to -2 which is reserved and can never be opened,
and therefore the unit does not exist.
[...]
+ /* The unit number -2 is reserved. No units can ever have this
+ value. It is used here to signal to the runtime library that the
+ inquire unit number is outside the allowable range and so cannot
+ exist. It is needed when -fdefault-integer-8 is uesed. */
I don't know where this number is used, but I really should be a
#define; if it is shared with libgfortran, it belongs to libgfortran.h.
You wrote that -1 is also reserved and used; is the -1 somewhere
defined? [Disclaimer: I have only browsed the other patch and do not
recall whether it add, handles or #defines -1 - or whether -1 is already
defined somewhere.]
+ /* UNIT numbers should be greater than zero. */
+ i = gfc_validate_kind (BT_INTEGER, 4, false);
+ cond = build2_loc (input_location, LT_EXPR, boolean_type_node,
+ se.expr,
+ fold_convert (TREE_TYPE (se.expr),
+ integer_zero_node));
+ gfc_trans_io_inquire_check (cond, var, &se.pre);
+
+ /* UNIT numbers should be less than the max. */
+ val = gfc_conv_mpz_to_tree (gfc_integer_kinds[i].huge, 4);
+ cond = build2_loc (input_location, GT_EXPR, boolean_type_node,
+ se.expr,
+ fold_convert (TREE_TYPE (se.expr), val));
+ gfc_trans_io_inquire_check (cond, var, &se.pre);
The conditions could be combined with a
fold_build2_loc(...,TRUTH_AND_EXPR,...).
Thanks for the patch!
Cheers,
Tobias
