[Bug libfortran/19303] Unformatted record header is 4-bytes on 32-bit targets
--- Comment #22 from tkoenig at gcc dot gnu dot org 2006-03-22 19:09 --- Subject: Bug 19303 Author: tkoenig Date: Wed Mar 22 19:09:11 2006 New Revision: 112290 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112290 Log: 2006-03-22 Thomas Koenig [EMAIL PROTECTED] PR fortran/19303 * gfortran.h (gfc_option_t): Add record_marker. * lang.opt: Add -frecord-marker=4 and -frecord-marker=8. * trans-decl.c: Add gfor_fndecl_set_record_marker. (gfc_build_builtin_function_decls): Set gfor_fndecl_set_record_marker. (gfc_generate_function_code): If we are in the main program and -frecord-marker was provided, call set_record_marker. * options.c (gfc_handle_option): Add handling for -frecord-marker=4 and -frecord-marker=8. * invoke.texi: Document -frecord-marker. 2006-03-22 Thomas Koenig [EMAIL PROTECTED] PR fortran/19303 * libgfortran.h (compile_options_t): Add record_marker. * runtime/compile_options.c (set_record_marker): New function. * io/open.c: If we have four-byte record markers, use GFC_INTEGER_4_HUGE as default record length. * io/file_pos.c (unformatted_backspace): Handle different size record markers. * io/transfer.c (us_read): Likewise. (us_write): Likewise. (next_record_r): Likewise. (write_us_marker): Likewise. (next_record_w): Likewise. 2006-03-22 Thomas Koenig [EMAIL PROTECTED] PR fortran/19303 * gfortran.dg/record_marker_1.f90: New test case. * gfortran.dg/record_marker_2.f: New test case. * gfortran.dg/record_marker_3.f90: New test case. Added: trunk/gcc/testsuite/gfortran.dg/record_marker_1.f90 trunk/gcc/testsuite/gfortran.dg/record_marker_2.f trunk/gcc/testsuite/gfortran.dg/record_marker_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/lang.opt trunk/gcc/fortran/options.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/io/file_pos.c trunk/libgfortran/io/open.c trunk/libgfortran/io/transfer.c trunk/libgfortran/libgfortran.h trunk/libgfortran/runtime/compile_options.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
[Bug libfortran/19303] Unformatted record header is 4-bytes on 32-bit targets
--- Comment #21 from patchapp at dberlin dot org 2006-03-15 22:30 --- Subject: Bug number PR 19303 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/2006-03/msg00980.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
[Bug libfortran/19303] Unformatted record header is 4-bytes on 32-bit targets
--- Comment #20 from tkoenig at gcc dot gnu dot org 2006-03-13 17:53 --- I'll take this, implementing the simplistic approach (generating an error for 2GB record sizes). This should keep the complexity down. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-02-05 20:01:55 |2006-03-13 17:53:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
[Bug libfortran/19303] Unformatted record header is 4-bytes on 32-bit targets
--- Comment #19 from tkoenig at gcc dot gnu dot org 2006-01-27 21:17 --- (In reply to comment #18) Created an attachment (id=10564) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10564action=view) [edit] patch against gcc-4.1-20051223 As requested, I am posting Rob's patch which goes against the Dec 23 snapshot. I didn't change reverse_memcpy() which I think I should, but maybe the one who added it should be more appropriate person to do it. Your patch works only on little-endian systems. I am currently thinking of making this a compile-time option. Thomas -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
[Bug libfortran/19303] Unformatted record header is 4-bytes on 32-bit targets
--- Comment #18 from milan at cmm dot ki dot si 2005-12-29 07:34 --- Created an attachment (id=10564) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10564action=view) patch against gcc-4.1-20051223 As requested, I am posting Rob's patch which goes against the Dec 23 snapshot. I didn't change reverse_memcpy() which I think I should, but maybe the one who added it should be more appropriate person to do it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
[Bug libfortran/19303] Unformatted record header is 4-bytes on 32-bit targets
--- Comment #17 from milan at cmm dot ki dot si 2005-12-26 15:54 --- (In reply to comment #16) Created an attachment (id=10296) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10296action=view) [edit] Patch to change delimitters to 4 bytes for unformatted records This is nearly the same patch that I posted before except for the head of the subversion repository. I tried this one, but is now already out of date. I just made a hand patch of 4.1.0-beta20051223 and it seems to be OK. When will this be in the 4.1 snapshots, so I don't need to patch it by hand? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
[Bug libfortran/19303] Unformatted record header is 4-bytes on 32-bit targets
--- Comment #15 from milan at cmm dot ki dot si 2005-11-19 19:09 --- I didn 't know how to compile gcc-4.1... so I couldn't reply before. I realised I have to install both mpfr and gmp libraries for gcc to compile. It complains only about gmp :-( Yes, this patch works OK. I had to patch the gcc-4.1-20051112 snapshot myself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
[Bug libfortran/19303] Unformatted record header is 4-bytes on 32-bit targets
--- Comment #16 from rrr6399 at futuretek dot com 2005-11-19 20:24 --- Created an attachment (id=10296) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10296action=view) Patch to change delimitters to 4 bytes for unformatted records This is nearly the same patch that I posted before except for the head of the subversion repository. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
[Bug libfortran/19303] Unformatted record header is 4-bytes on 32-bit targets
--- Comment #14 from rrr6399 at futuretek dot com 2005-10-18 04:31 --- Created an attachment (id=10015) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10015action=view) changes unformatted record delimitters to 4 bytes for compatibility with other compilers I modified gfortran to produce unformatted records with 4 byte delimitters so the binaries would be compatible with the other Linux Fortran compilers such as Intel's and Portland Group's. I uploaded the patch just in case anybody needed the same capability and perhaps as a start to a more general patch. (Let me know if I screwed up on creating the patch...I just did a cvs diff on the related directory.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
[Bug libfortran/19303] Unformatted record header is 4-bytes on 32-bit targets
--- Comment #13 from rrr6399 at futuretek dot com 2005-10-08 16:37 --- FYI: The latest Cray, IRIX64 and Solaris fortran compilers all use 4 byte record markers in their unformatted files and are hence interoperable. FWIW, I think the Intel solution should be considered to support record lengths greater than 2GB. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
[Bug libfortran/19303] Unformatted record header is 4-bytes on 32-bit targets
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11 14:27 --- *** Bug 23814 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||rrr6399 at futuretek dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
[Bug libfortran/19303] Unformatted record header is 4-bytes on 32-bit targets
--- Additional Comments From rrr6399 at futuretek dot com 2005-09-12 02:20 --- FYI: Here's what Intel did for to address the record sizes larger than 2 GB: http://www.intel.com/software/products/compilers/flin/docs/main_for/mergedProjects/bldaps_for/format_of_record_types_.htm The nice thing about this approach is that the files are compatible with files generated by f77/g77 and other vendors' f90/f95 compilers. The tradeoff is that it makes the i/o logic a little more complicated. I believe that PGI (Portland Group) compiler generates f77 compliant unformatted files as well. I haven't found their approach yet for dealing with 2GB record sizes, but the docs are at http://www.pgroup.com/resources/docs.htm I'm going to check Cray, SGI and Sun as well to see what format they output. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
[Bug libfortran/19303] Unformatted record header is 4-bytes on 32-bit targets
--- Additional Comments From milan at cmm dot ki dot si 2005-05-31 08:41 --- Great work! Thanks a million! Somehow I also have a problem with the name of the option, since g77 has exactly the same problem. When I compile with the g77 I get 8 byte headers on AMD64, so the name g77 doesn't really correspond to always get 4 byte headers. But this is very minor thing especially if it is documented how it works, the name shouldn't really matter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
[Bug libfortran/19303] Unformatted record header is 4-bytes on 32-bit targets
--- Additional Comments From blime at cox dot net 2005-05-31 14:04 --- Subject: Re: Unformatted record header is 4-bytes on 32-bit targets I second the thanks a million, and also don't think g77 belongs in the option name. I have been using a very fast sort program for large files written in C++ (not by me) , and compiled with gcc-3.3.2 (c++) which produces a binary file that is read using Fortran code compiled with g77, and have not experienced any problems. I was testing this very large simulation using gcc-4.0 (c++) and g95 when I ran into the problem -- the binary file created with gcc-4.0 (c++) could not be read by g95 compiled code -- incompatible record markers (32 bit vice 64 bit). blime milan at cmm dot ki dot si wrote: --- Additional Comments From milan at cmm dot ki dot si 2005-05-31 08:41 --- Great work! Thanks a million! Somehow I also have a problem with the name of the option, since g77 has exactly the same problem. When I compile with the g77 I get 8 byte headers on AMD64, so the name g77 doesn't really correspond to always get 4 byte headers. But this is very minor thing especially if it is documented how it works, the name shouldn't really matter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
[Bug libfortran/19303] Unformatted record header is 4-bytes on 32-bit targets
--- Additional Comments From bdavis9659 at comcast dot net 2005-05-31 02:37 --- proposed patch that should fix this problem: http://gcc.gnu.org/ml/fortran/2005-05/msg00431.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
[Bug libfortran/19303] Unformatted record header is 4-bytes on 32-bit targets
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-31 02:45 --- *** Bug 21621 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||P dot Schaffnit at access ||dot rwth-aachen dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
[Bug libfortran/19303] Unformatted record header is 4-bytes on 32-bit targets
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21 13:53 --- *** Bug 21673 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
[Bug libfortran/19303] Unformatted record header is 4-bytes on 32-bit targets
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14 23:05 --- *** Bug 21570 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||blime at cox dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
[Bug libfortran/19303] Unformatted record header is 4-bytes on 32-bit targets
--- Additional Comments From jblomqvi at cc dot hut dot fi 2005-02-18 23:42 --- Somewhat related patch here: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01085.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
[Bug libfortran/19303] Unformatted record header is 4-bytes on 32-bit targets
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-06 23:46 --- As I said before this really should be 64bit on all targets instead as we should support LFS (large file support) (which is deafualt really on all *BSD, darwin is included with this *BSD). -- What|Removed |Added GCC target triplet||all (except for *bsd and ||*darwin) Summary|Unformatted record header is|Unformatted record header is |8-bytes on 64-bit targets |4-bytes on 32-bit targets Version|unknown |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
