[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