--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-08-19 02:40
---
Closing as invalid. If anyone sees a reason to re-open, please let me know.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from kargl at gcc dot gnu dot org 2008-08-17 19:53 ---
(In reply to comment #4)
> I agree there is legacy g77 behavior involved here. I did a test here, and a
> very simple patch will enable this feature. At least for the test case I get
> the exact same results as g77.
--- Comment #5 from burnus at gcc dot gnu dot org 2008-08-17 17:59 ---
For completeness, I tested the program with a couple of compilers, which all
generated a run-time error message:
- Intel ifort 10 and 11beta
- Sun Studio 12 sunf95
- g95
- Portland pgf77 7.1
- Open64 openf95
- Pathsca
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-08-16 22:48
---
I agree there is legacy g77 behavior involved here. I did a test here, and a
very simple patch will enable this feature. At least for the test case I get
the exact same results as g77. I just disable this check
--- Comment #3 from kargl at gcc dot gnu dot org 2008-08-15 18:59 ---
(In reply to comment #2)
> (In reply to comment #1)
>
> Is there a Fortran 77 compatible work-around that will do what this program
> was
> doing (i.e.: write out a mixed set of 4 byte integers and 8 byte floats to a
--- Comment #2 from huwaldtj at saic dot com 2008-08-15 16:58 ---
(In reply to comment #1)
Is there a Fortran 77 compatible work-around that will do what this program was
doing (i.e.: write out a mixed set of 4 byte integers and 8 byte floats to a
binary file with a specific format sinc
--- Comment #1 from kargl at gcc dot gnu dot org 2008-08-15 16:53 ---
(In reply to comment #0)
> It appears that gfortran does not interpret recl=1 the way many historic
> compilers, including g77, did. So, this bug report is to request that recl=1
> be interpreted to mean that the com
