------- Comment #12 from jakub at gcc dot gnu dot org  2008-11-20 15:08 -------
I think the primary question is, is libgfortran in 4.4 supposed to stay at
libgfortran.so.3?  If yes, then it must be backwards compatible with 4.3.

Looking at the 4.3 to 4.4 io.h changes, I see several problems.
The st_parameter_open changes look good to me.
st_parameter_inquire changes are wrong, io.h has:
@@ -299,6 +339,15 @@ typedef struct
   CHARACTER1 (write);
   CHARACTER2 (readwrite);
   CHARACTER1 (convert);
+  GFC_INTEGER_4 flags2;
+  CHARACTER1 (asynchronous);
+  CHARACTER2 (decimal);
+  CHARACTER1 (encoding);
+  CHARACTER2 (pending);
+  CHARACTER1 (round);
+  CHARACTER2 (sign);
+  GFC_INTEGER_4 *size;
+  GFC_INTEGER_4 *id;
 }
 st_parameter_inquire;

but ioparm.def has:
@@ -54,6 +59,17 @@ IOPARM (inquire, read,               1 << 27, char2)
 IOPARM (inquire, write,                1 << 28, char1)
 IOPARM (inquire, readwrite,    1 << 29, char2)
 IOPARM (inquire, convert,       1 << 30, char1)
+IOPARM (inquire, flags2,       1 << 31, int4)
+IOPARM (inquire, asynchronous, 1 << 0,  char1)
+IOPARM (inquire, decimal,      1 << 1,  char2)
+IOPARM (inquire, encoding,     1 << 2,  char1)
+IOPARM (inquire, pending,      1 << 3,  pint4)
+IOPARM (inquire, round,                1 << 4,  char1)
+IOPARM (inquire, sign,         1 << 5,  char2)
+IOPARM (inquire, size,         1 << 6,  pint4)
+IOPARM (inquire, id,           1 << 7,  pint4)
+IOPARM (wait,    common,       0,       common)
+IOPARM (wait,    id,           1 << 7,  pint4)
 #ifndef IOPARM_dt_list_format
 #define IOPARM_dt_list_format          (1 << 7)
 #define IOPARM_dt_namelist_read_mode   (1 << 8)

Look at pending, the types don't match.  Either it is a char2 (i.e. int length
followed by char *), but then it should be char2 in both places, or it is pint4
(i.e. a int *), but then it should be pint4 in both places and everything
adjusted, so that there aren't unneeded gaps.

st_parameter_dt changes are unfortunately worse.  Putting the FE filled new
fields into the union is definitely a bad idea, and as gfc_transfer_init clears
the whole u.pad, it is ABI incompatible anyway (4.3 compiled programs reserve
just 192 (32-bit) resp. 256 (64-bit) bytes for the padding, it will result in
writes after end of allocated st_parameter_dt variables in 4.3 running against
4.4 libgfortran.  The fix is easy.  Either move the newly added fields at the
end of the structure and decrease size of pad back to 16 * sizeof (char *) + 32
* sizeof (int), after all, there is plenty of space for new stuff left in there
and apparently no new libgfortran internal fields were added to u.p during 4.4.
 (this is my preferred solution) or, move the newly added FE filled fields
before the union and decrease size of the u.pad accordingly, then find out at
runtime where to put say the u.p.value field (it could overlap the newly added
FE filled fields if none of them are used, or if they are used, could be after
the current padding.

I'll work on a patch, but would like to hear first 1) whether 4.4 libgfortran
is really meant to be backward compatible with 4.3 (I hope so) and 2) what type
should pending in INQUIRE have.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jvdelisle at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37839

Reply via email to