This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [patch, libgfortran] Fix PR20257 End of record occurs when writing large arrays
- From: Paul Thomas <paulthomas2 at wanadoo dot fr>
- To: Jerry DeLisle <jvdelisle at verizon dot net>
- Cc: Fortran List <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Sat, 22 Apr 2006 07:26:17 +0200
- Subject: Re: [patch, libgfortran] Fix PR20257 End of record occurs when writing large arrays
- References: <444816A5.3030100@verizon.net>
Jerry,
:REVIEWMAIL:
The patch is OK to commit, except:
You will notice an absurd unit number being assigned to internal
units. It turns out that the stderr unit number is zero. To avoid
mistaking an internal unit as preconnected I set it to 135790. This
also eliminates a case of accessing an uninitialized value pointed out
by valgrind.
In my experience, "absurd" numbers ALWAYS come back to bite you. Use
something determinable, like 2^31. This needs to be documented and,
preferably, an attempt to open unit = what_ever_you_chose should produce
a warning that this is reserved internally.
The final patch has been regression tested on i686, NIST tested, many
I/O tested and checked with valgrind on a few cases that valgrind
noted had problems. All looks solid on this end. (I even got a
little progress on tonto-1.0 with it)
Yes, it regtests OK on FC5 and I too got the little bit of progress on
tonto. It does not stop the segfault in FLUSH on non-trivial molecular
tests, however.
OK for trunk and then later 4.1.1?
Yup.
Paul