[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 fortran/23815] Add -byteswapio flag
--- Comment #15 from rrr6399 at futuretek dot com 2005-11-11 13:26 --- I think the approach of having multiple ways of changing the behavior is a good one. Many Unix programs do this kind of thing to allow the user to choose the best way to accomplish the goal. I've found each approach useful in the past. The environment variable approach also allows the same executable to be used for different scenarios. The only negative I see is if the executable was compiled by a different compiler (ifort, pgf95, etc.). A user might expect that the behavior will change with an environment variable setting and then wonder why it didn't. Perhaps the same environment variable names used by ifort could be used by gfortran to limit this issue a bit? (In reply to comment #14) Thomas, I'm not in favor of environmental variables, which I think would also be Paul Brook's position. It's too easy to have the variables set or unset at the wrong time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23815
[Bug fortran/23815] Add -byteswapio flag
--- Comment #9 from rrr6399 at futuretek dot com 2005-11-02 18:17 --- I imagine code from g95 could be leveraged to support this feature couldn't it? This is a really important feature, especially in corporate environments where there is usually mix of big-endian and little-endian machines. (Of course, the current 64 bit record delimitters for unformatted files eliminates any hope of interoperability with other fortran compilers.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23815
[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 fortran/23815] Add -byteswapio flag
--- Comment #6 from rrr6399 at futuretek dot com 2005-10-11 19:20 --- Many compilers, like the Intel and PGI ones for instance, simply have a -byteswap flag that is set at compile time. That way any unformatted data that is input or output is expected to be switched to Little or Big Endian all the time. This is typically what we've needed over the years. I haven't really seen a case to only byteswap certain files. A run time option would work as well as long as people remember to set the environment variable or whatever. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23815
[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 fortran/23814] unformatted files from gfortran are incompatible with g77 unformatted files and solaris f95 unformatted files
--- Additional Comments From rrr6399 at futuretek dot com 2005-09-11 13:24 --- I believe it really is critical since myself and many others who may use gfortran need to interoperate with data generated by legacy codes on the same system that were compiled with g77 or on other systems (Sun, SGI) compiled with their native f77 or f90/f95 compilers. Some of the codes are proprietary, many are from other third parties, it isn't really feasible to force them to use another binary file library. Plus, I've been working with unformatted FORTRAN files for 15 years and this is the first time I've had this type of issue with the structure of an unformatted file. So given the current situtation, I'll have to write a format convertor for unformatted data from any gfortran code to the standard g77 format in order to interoperate. I would've thought that the FORTRAN spec would've covered this kind of thing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23814
[Bug fortran/23814] unformatted files from gfortran are incompatible with g77 unformatted files and solaris f95 unformatted files
--- Additional Comments From rrr6399 at futuretek dot com 2005-09-11 20:47 --- Well, just to warn you, you're going to have a lot of steamed engineers on your hands when they discover that they either have to recompile all of their FORTRAN codes on every platform with gfortran, write all of their data (50 - 1000MB binaries and larger) as ASCII, or convert their files to the traditional g77 format to interoperate with the rest of their processes. What will actually happen is that users will get burnt once and then they'll drop gfortran like a hot potato and put in a request to purchase a commercial compiler from Intel or PGI. Another reason that this feature is so painful is that engineers tend to pipeline their unformatted files from one process to the next. There can literally be 10 or more programs in a process that will read from or write to a given unformatted file. Any program in the process that was compiled with gfortran will break the process and probably in such a subtle way that it'll take each user hours to figure out what went wrong. (I spent four hours on it yesterday discovering what the problem was in my process and that's with knowing how to read the output from od.) Furthermore, when one writes binary in C, you get exactly what your variables are sized to in your code. If the platform is a 32 bit machine and is IEEE compliant, you pretty much know that a short is 16bit, an int is 32 bit, a long is 32 bit and a long long is 64 bit. Typically, many times developers even define macros or new types that guarantee that the variables are the same lengths independent of 32 bit or 64 bit architectures. There are also compiler switches many times that govern the length of the various primitive types. So if portability of the data is important to you, the resulting binary file is interoperable except for big-Endian versus little-Endian issues...(that can be worked with a flag at the top or always writing in one endianess.) With C binary files, of course, you don't have to worry about the the silly record markers either that muck up the works. I think the goal of allowing record lengths 2GB is a good long time target, but having been in the field for many years, I imagine that the current use cases for record lengths 2GBs are very very few compared to those involving interoperability with other compilers and platforms. The few users requiring 2GB record lengths can easily modify their write statement to output multiple records as well rather than one large one. Hopefully, once there is a compiler switch in place, everybody will be happy. :-) p.s. It is too bad the FORTRAN spec (even the 2003) threw in the towel on interoperable binary files. It forces everybody to deal with these issues in different ways using various third party libaries or ad hoc cobbled-together solutions. As shown by the CORBA standard and others, the specification of interoperable binary files is completely doable. I imagine the FORTRAN vendors will continue to ensure that their binary file format can be completely specified by the user just to meet the needs of their customers even though the spec doesn't force them to. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23814
[Bug fortran/23814] unformatted files from gfortran are incompatible with g77 unformatted files and solaris f95 unformatted files
--- Additional Comments From rrr6399 at futuretek dot com 2005-09-11 23:22 --- I'm not sure why I'm getting so much pushback on this silly thing. I realize that disagreeing with the assumptions made during the design may be regarded by some as rants, but what I was attempting to do (perhaps poorly) is illustrate why simple decisions that might seem fairly benign can have huge efficiency impacts on a large population of users. There has been a pattern of these decisions made over the years that have wasted thousands (if not millions) of hours of people's precious time. (Big Endian vs. Little Endian, \ versus /, CR vs CR/LF vs LF, 8 byte vs 4 byte markers, etc.) If you read some of the previous comments, you'll see that some don't think it's an issue. It really is a problem that should take high priority. I know Bud is going to apply a variation of the patch he wrote a few months ago soon and I'm happy about that. I hope there isn't any pushback from the rest of the developers. I think the default should actually be 4 byte markers, but that's just my humble opinion. BTW, I think both spellings of FORTRAN (FORmula TRANslation) are correct actually: http://www.ibiblio.org/pub/languages/fortran/ch1-1.html http://www.engin.umd.umich.edu/CIS/course.des/cis400/fortran/fortran.html (Not that it really matters in the big scheme of things.) I'll also post a small C program to convert to the g77 format soon as a temporary fix until the patch is in place. (I'm completely hammered with work right now, but I'll try to contribute more in the future. I've already sent in some code snippets on the little endian/big endian issue.) Also, if I wanted to be condescended to I'd go talk to my wife. :-) I hope that we can all keep this professional in the future and respect people's time (development, trouble shooting and bug reporting) that they put into this to help make a better product for everybody. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23814
[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 fortran/23814] New: unformatted files from gfortran are incompatible with g77 unformatted files and solaris f95 unformatted files
I ran into a problem with unformatted files with gfortran. It appears that it is padding the delimitters to 8 byte boundaries (or the delimitters are 64 bit longs) rather than the normal 4 byte delimitter approach. For instance, I have a program that does this: write(1) 1 end g77 and solaris f95 returns (ignoring the byteswapping issues): od -x fort.1: 000 0004 0001 0004 gfortran returns: 000 0004 0001 0004 020 is there a flag to make the delimitters 4 bytes rather than 8 bytes? -- Summary: unformatted files from gfortran are incompatible with g77 unformatted files and solaris f95 unformatted files Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: critical Priority: P1 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rrr6399 at futuretek dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23814
[Bug fortran/23814] unformatted files from gfortran are incompatible with g77 unformatted files and solaris f95 unformatted files
--- Additional Comments From rrr6399 at futuretek dot com 2005-09-11 04:07 --- I just found this discussion: http://gcc.gnu.org/ml/fortran/2005-05/msg00431.html It doesn't look like from the docs that it was implemented in the main-line yet, is it available somehow else? It seems to me that unformatted files on 32 bit machines should be compatible. I don't know of any other fortran compiler that assumes 64 bit record markers. We really need a flag to change the behavior if it is not available already. BTW, it is pretty typical that aero engineers involved in CFD (computational fluid dynamics) need to ship around large (50-1000 MB) binary files between various machines without having to reformat them. Typically they generate files that are all big-endian using a compiler switch to avoid having to byte swap as well. So, while we're at it, it'd be great to have a compiler switch that reversed the byte order of integers (2, 4, 8 byte) and floating point numbers (4, 8 byte) when they are read from or written to an unformatted file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23814
[Bug fortran/23815] New: Add -byteswapio flag
It is pretty typical that aero engineers involved in CFD (computational
fluid dynamics) need to ship around large (50-1000 MB) binary files between
various big-endian and little-endian machines without having to reformat them.
Typically they generate files that are all big-endian using a compiler switch to
avoid having to byte swap as well. So it'd be great to have a compiler switch
that reversed the byte order of integers (2, 4, 8 byte) and floating point
numbers (4, 8 byte) when they are read from or written to an unformatted file.
For instance if you had an 4 byte int stored as an array of chars,
you might swap it using this simple approach:
for (i = 0; i 4; i++ ) {
swappedBytes[i] = bytes[3-i];
}
or if you want to do the bit shifting thing, you do do it this way:
return (((buf [ 3 ] 0xff) 24) | ((buf [ 2 ] 0xff) 16) |
((buf [ 1 ] 0xff) 8) | (buf [ 0 ] 0xff));
(I grabbed this code from converToInt() in:
gcc-4.1-20050909/libjava/classpath/gnu/CORBA/CDR/LittleEndianInputStream.java)
--
Summary: Add -byteswapio flag
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P1
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rrr6399 at futuretek dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23815
[Bug fortran/23798] New: gfortran hangs while parsing subroutine
It appears that the latest version (and older versions) of gfortran hang while compiling the attached fortran code. It looks like it is related to the character strings being dimensioned by a length parameter passed in the arguments of the subroutine. If I hard code the length to a constant, the parser works fine. -- Summary: gfortran hangs while parsing subroutine Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: critical Priority: P1 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rrr6399 at futuretek dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23798
[Bug fortran/23798] gfortran hangs while parsing subroutine
--- Additional Comments From rrr6399 at futuretek dot com 2005-09-09 16:20 --- Created an attachment (id=9703) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9703action=view) subroutine that causes gfortran -c to hang during parsing uncomment the 10th line and comment the 9th line to compile the code successfully. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23798
