User account creation filtered due to spam.

Bug 31409 - [4.1 only, regression] Reading after ERROR_SHORT_RECORD
Summary: [4.1 only, regression] Reading after ERROR_SHORT_RECORD
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: libfortran (show other bugs)
Version: 4.3.0
: P3 normal
Target Milestone: 4.1.3
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks: 19292
  Show dependency treegraph
 
Reported: 2007-03-31 10:42 UTC by Thomas Koenig
Modified: 2007-05-11 06:41 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
Test case (388 bytes, text/plain)
2007-04-01 04:25 UTC, Jerry DeLisle
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Koenig 2007-03-31 10:42:06 UTC
See

http://gcc.gnu.org/ml/fortran/2007-03/msg00565.html

which also contains a patch.

Strictly speaking, this isn't a wrong-code because
the standard doesn't impose any requirements after
an error condition.  However, we do want to fix this.
Comment 1 Jerry DeLisle 2007-03-31 18:59:31 UTC
The patch does not appear to fix this on 4.3
Comment 2 Jerry DeLisle 2007-04-01 04:25:33 UTC
Created attachment 13313 [details]
Test case
Comment 3 Jerry DeLisle 2007-04-01 04:45:53 UTC
I believe gfortran 4.3 is correctly handling this test case.  There should be two error messages from trying to read the larger B(4) array from a record that contains a smaller A(2) array, thus reading past end of record in those cases.  After the errors, gfortran positions correctly to read the next available record.

Gfortran behavior matches ifort.  It would be interesting to see what other compilers do.

I have not checked gfortran 4.2 yet.  However, reviewing the code in transfer.c (read_block_direct) I suspect 4.2 is OK.  The code we have now in 4.2 and 4.3 is as follows:

	      /* Let's make sure the file position is correctly set for the
		 next read statement.  */

	      next_record_r_unf (dtp, 0);
	      us_read (dtp, 0);
	      generate_error (&dtp->common, ERROR_SHORT_RECORD, NULL);
	      return;

This is very similar to Georgy's patch with a call to next_record to correctly position the file for the following record,

Clearly, from Georgy's data, 4.1.2 is failing

I think the fix we have now in 4.2 and 4.3 (or similar) should be backported to the 4.1 branch.
Comment 4 Francois-Xavier Coudert 2007-04-18 06:45:45 UTC
(In reply to comment #3)
> Gfortran behavior matches ifort.  It would be interesting to see what other
> compilers do.

Sun does the same as gfortran and Intel.

> I have not checked gfortran 4.2 yet.  However, reviewing the code in transfer.c
> (read_block_direct) I suspect 4.2 is OK.

I tested gfortran-4.2 and it has the same behavior as gfortran-mainline. 4.1.2 gives different results, however. I'm adding the outputs of different version as an attached tar file.

> I think the fix we have now in 4.2 and 4.3 (or similar) should be backported to
> the 4.1 branch.

Keeping this open.
Comment 5 Jerry DeLisle 2007-05-11 06:40:59 UTC
Subject: Bug 31409

Author: jvdelisle
Date: Fri May 11 05:40:37 2007
New Revision: 124612

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124612
Log:
2007-05-10  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

	PR libfortran/31409
	* io/transfer.c (read_block_direct): Backport from 4.3 trunk.

Modified:
    branches/gcc-4_1-branch/libgfortran/ChangeLog
    branches/gcc-4_1-branch/libgfortran/io/transfer.c

Comment 6 Jerry DeLisle 2007-05-11 06:41:53 UTC
Fixed on 4.1.  Not a bug on 4.2 or 4.3