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
next prev 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: linkBe 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).