public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "jakub at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libfortran/37839] st_parameter_dt has unwanted padding, is out of sync with compiler
Date: Thu, 20 Nov 2008 15:09:00 -0000	[thread overview]
Message-ID: <20081120150821.16315.qmail@sourceware.org> (raw)
In-Reply-To: <bug-37839-3107@http.gcc.gnu.org/bugzilla/>



------- 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


  parent reply	other threads:[~2008-11-20 15:09 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-15 17:54 [Bug libfortran/37839] New: " sje at cup dot hp dot com
2008-10-15 23:10 ` [Bug libfortran/37839] " janis at gcc dot gnu dot org
2008-10-16 10:02 ` burnus at gcc dot gnu dot org
2008-10-16 15:24 ` sje at cup dot hp dot com
2008-10-16 15:33 ` dominiq at lps dot ens dot fr
2008-10-17  3:42 ` jvdelisle at gcc dot gnu dot org
2008-10-19  4:01 ` jvdelisle at gcc dot gnu dot org
2008-10-19 12:02 ` burnus at gcc dot gnu dot org
2008-10-20 15:04 ` sje at cup dot hp dot com
2008-10-28 18:28 ` sje at cup dot hp dot com
2008-11-01 12:18 ` jvdelisle at gcc dot gnu dot org
2008-11-06 14:04 ` dominiq at lps dot ens dot fr
2008-11-20 15:09 ` jakub at gcc dot gnu dot org [this message]
2008-11-21 12:44 ` howarth at nitro dot med dot uc dot edu
2008-11-21 12:45 ` jakub at gcc dot gnu dot org
2008-11-22  5:23 ` jvdelisle at gcc dot gnu dot org
2008-11-22  8:13 ` jakub at gcc dot gnu dot org
2008-11-22  8:32 ` jakub at gcc dot gnu dot org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081120150821.16315.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).