[Bug fortran/31201] Too large unit number generates wrong code
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-05-06 23:28 --- Subject: Bug 31201 Author: jvdelisle Date: Sun May 6 22:28:31 2007 New Revision: 124479 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124479 Log: 2007-05-06 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/31201 * runtime/error.c (runtime_error_at): New function. (generate_error): Export this function. * gfortran.map: Add _gfortran_generate_error and _gfortran_runtime_error_at. * libgfortran.h: Add comment to reference error codes in front end. (library_start): Locate prototype with library_end macro and add a new comment. Add prototype for runtime_error_at. Export prototype for generate_error. * io/lock.c (library_start): Fix check for error condition. * io/transfer.c (data_transfer_init): Add library check. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/gfortran.map trunk/libgfortran/io/lock.c trunk/libgfortran/io/transfer.c trunk/libgfortran/libgfortran.h trunk/libgfortran/runtime/error.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31201
[Bug fortran/31201] Too large unit number generates wrong code
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2007-05-06 23:32 --- Subject: Bug 31201 Author: jvdelisle Date: Sun May 6 22:32:33 2007 New Revision: 124480 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124480 Log: 2007-05-06 Jerry DeLisle [EMAIL PROTECTED] Francois-Xavier Coudert [EMAIL PROTECTED] PR fortran/31201 * gfortran.h: Add runtime error codes from libgfortran.h. Define MAX_UNIT_NUMBER. * trans.c (gfc_trans_runtime_check): Update the format of runtime error messages to match library runtime errors. Use call to new library function runtime_error_at(). * trans.h: Add prototype for new function gfc_trans_io_runtime_check. Add declaration for library functions runtime_error_at and generate_error. * trans_io.c (gfc_trans_io_runtime_check): New function. (set_parameter_value): Add error checking for UNIT numbers. (set_parameter_ref): Initialize the users variable to zero. (gfc_trans_open): Move setting of unit number to after setting of common flags so that runtime error trapping can be detected. (gfc_trans_close): Likewise. (build_filepos): Likewise. (gfc_trans_inquire): Likewise. (build_dt): Likewise. * trans-decl.c: Add declarations for runtime_error_at and generate_error. (gfc_build_builtin_function_decls): Build function declarations for runtime_error_at and generate_error. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-io.c trunk/gcc/fortran/trans.c trunk/gcc/fortran/trans.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31201
[Bug fortran/31201] Too large unit number generates wrong code
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2007-05-06 23:37 --- Subject: Bug 31201 Author: jvdelisle Date: Sun May 6 22:37:27 2007 New Revision: 124481 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124481 Log: 2007-05-06 Jerry DeLisle [EMAIL PROTECTED] PR fortran/31201 * gfortran.dg/large_unit_1.f90: New. * gfortran.dg/large_unit_2.f90: New. * gfortran.dg/iostat_4.f90: New * gfortran.dg/bounds_check_fail_1.f90: Updated. Added: trunk/gcc/testsuite/gfortran.dg/iostat_4.f90 trunk/gcc/testsuite/gfortran.dg/large_unit_1.f90 trunk/gcc/testsuite/gfortran.dg/large_unit_2.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/bounds_check_fail_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31201
[Bug fortran/31201] Too large unit number generates wrong code
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2007-05-07 00:04 --- Fixed on mainline. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31201
[Bug fortran/31201] Too large unit number generates wrong code
--- Comment #8 from patchapp at dberlin dot org 2007-04-14 19:15 --- Subject: Bug number PR31201 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00863.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31201
[Bug fortran/31201] Too large unit number generates wrong code
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-04-03 14:50 --- I have a patch testing -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31201
[Bug fortran/31201] Too large unit number generates wrong code
--- Comment #7 from patchapp at dberlin dot org 2007-04-04 05:55 --- Subject: Bug number PR31201 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00126.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31201
[Bug fortran/31201] Too large unit number generates wrong code
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-03-17 13:01 --- (In reply to comment #3) The front end is converting the integer8 to integer4 and not checking the range of the number first. Every time a unit number is used, there should be a check to be sure it's in the integer4 range, and otherwise emit an error. Thanks for taking it, Jerry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31201
[Bug fortran/31201] Too large unit number generates wrong code
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-03-18 02:22 --- Heres the real problem: Try compiling this with and without -fno-range-check. integer*8 :: k= 68719476746 integer*8 :: k2 = 2_8**36 + 10 print *, k=,k, k2, int(k2, kind=8), int(k2, kind=4) end With checking: overflow.f:1.34: integer*8 :: k= 68719476746 1 Error: Integer too big for its kind at (1) Without checking: $ gfc -fno-range-check overflow.f $ ./a.out k= 68719476746 68719476746 68719476746 10 So our range checking does not catch the case when too big integer is hidden in some arithmetic and conversion of kinds does not either. I don't think we want integer kind conversion to catch this, its no different then a cast. The programmer needs to be aware of what they are doing. In tha case of the overly large unit number, We do catch non disguised cases. Any opinions on whether we need to really 'fix' this? (I am not taking sides here, the answer too my question has broader implications, ie int intrinsics) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31201
[Bug fortran/31201] Too large unit number generates wrong code
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-16 20:29 --- Unit numbers are passed and stored internally as GFC_INTEGER_4, but we don't error out on too large numbers (like the one that don't fit inside a GFC_INTEGER_4). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||4.1.3 4.2.0 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-03-16 20:29:34 date|| Summary|wrong code generated with |Too large unit number |gfortran|generates wrong code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31201
[Bug fortran/31201] Too large unit number generates wrong code
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-03-16 23:01 --- I will fix this one. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-03-16 20:29:34 |2007-03-16 23:01:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31201
[Bug fortran/31201] Too large unit number generates wrong code
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-03-17 06:28 --- The front end is converting the integer8 to integer4 and not checking the range of the number first. The integer value gets wrapped around and the library sees unit=10 for this test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31201
