--- 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
--- 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
--- 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=10015&action=view)
changes unformatted record delimitters to 4 bytes for compatibility with other
compilers
I modified gfor
--- 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-e
--- 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 app
--- 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=10296&action=view)
Patch to change delimitters to 4 bytes for unformatted records
This is nearly the same patch that I
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
--- 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=9703&action=view)
subroutine that causes gfortran -c to hang during parsing
uncomment the 10th line and comment
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
--- 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 see
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
--- 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
--- 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,
--- 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
--- 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
15 matches
Mail list logo
