From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6348 invoked by alias); 20 Nov 2008 15:09:45 -0000 Received: (qmail 16316 invoked by uid 48); 20 Nov 2008 15:08:21 -0000 Date: Thu, 20 Nov 2008 15:09:00 -0000 Message-ID: <20081120150821.16315.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libfortran/37839] st_parameter_dt has unwanted padding, is out of sync with compiler In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "jakub at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-11/txt/msg01676.txt.bz2 ------- 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