[Patch, fortran] PR25289 Cannot handle record numbers large than huge(0_4)
FX Coudert
fxcoudert@gmail.com
Wed Jun 28 07:13:00 GMT 2006
Hi Jerry,
I don't have time right now to review that patch. Here are my comments:
> This patch
> borrows code from trans-types.c to determine whether or not a target
> supports integer 8 or not. A new function is added to make this
> determination.
I think we should use a constant to store that integer kind defined as
"8 if integer(8) exists and 4 otherwise", to avoid calling a function
each time we need it. We already have a constant gfc_max_integer_kind in
place, we could either
- use that gfc_max_integer_kind, because it is also known from the
library, as GFC_INTEGER_LARGEST
- use similar code than the one defining gfc_max_integer_kind to
define gfc_large_integer_kind as "8 if possible, 4 otherwise"
Index: trans-types.c
===================================================================
--- trans-types.c (revision 114972)
+++ trans-types.c (working copy)
@@ -86,6 +86,7 @@
int gfc_default_integer_kind;
int gfc_max_integer_kind;
+int gfc_large_integer_kind;
int gfc_default_real_kind;
int gfc_default_double_kind;
int gfc_default_character_kind;
@@ -143,6 +144,13 @@
/* Set the maximum integer kind. Used with at least BOZ constants. */
gfc_max_integer_kind = gfc_integer_kinds[i_index - 1].kind;
+ if (saw_i8)
+ gfc_large_integer_kind = 8;
+ else if (saw_i4)
+ gfc_large_integer_kind = 4;
+ else
+ gfc_large_integer_kind = gfc_integer_kinds[i_index - 1].kind;
+
for (r_index = 0, mode = MIN_MODE_FLOAT; mode <= MAX_MODE_FLOAT; mode++)
{
const struct real_format *fmt = REAL_MODE_FORMAT (mode);
These are two different choices of our prefered type to transfer
record-length. My opinion is that we'd better stick with the second
approach for now.
> On the library side I am sticking with gfc_offset which I think is being
> handled correctly. If it is preferred that I do further work on the
> runtime library side, let me know.
We have this occasion to make the library/front-end "interface" cleaner,
so I'd expect we use it fully and use the according type in
libgfortran. For example, add in libgfortran.h:
#ifdef HAVE_GFC_INTEGER_8
# define GFC_LARGE_INTEGER GFC_INTEGER_8
#else
# ifdef HAVE_GFC_INTEGER_4
# define GFC_LARGE_INTEGER GFC_INTEGER_4
# else
# define GFC_LARGE_INTEGER GFC_INTEGER_LARGEST
# endif
#endif
which exactly corresponds to the front-end code (second option) I have
written above.
About the IOPARM code in itself, I'm not sure how we should handle
padding at the end of the structure. Have you take this into consideration?
FX
More information about the Gcc-patches
mailing list