From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24476 invoked by alias); 27 Mar 2007 21:53:11 -0000 Received: (qmail 24468 invoked by uid 22791); 27 Mar 2007 21:53:10 -0000 X-Spam-Check-By: sourceware.org Received: from ug-out-1314.google.com (HELO ug-out-1314.google.com) (66.249.92.173) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 27 Mar 2007 22:53:08 +0100 Received: by ug-out-1314.google.com with SMTP id s2so24694uge for ; Tue, 27 Mar 2007 14:53:04 -0700 (PDT) Received: by 10.67.97.7 with SMTP id z7mr1565355ugl.1175032384574; Tue, 27 Mar 2007 14:53:04 -0700 (PDT) Received: from ?192.168.0.5? ( [82.239.100.53]) by mx.google.com with ESMTP id 54sm107321ugp.2007.03.27.14.53.01; Tue, 27 Mar 2007 14:53:02 -0700 (PDT) In-Reply-To: <46098BB2.3080902@codesourcery.com> References: <46098BB2.3080902@codesourcery.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: fortran@gcc.gnu.org, gcc-patches@gcc.gnu.org Content-Transfer-Encoding: 7bit From: FX Coudert Subject: Re: RFC: gfc_simplify_transfer implementation. Date: Tue, 27 Mar 2007 22:05:00 -0000 To: Brooks Moses X-Mailer: Apple Mail (2.752.2) Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2007-03/txt/msg01795.txt.bz2 First, congratulations on the good work! > Meanwhile, the target-memory.c functions are in a sort of > preliminary state which assumes that the host and target have the > same memory representations, and thus don't work correctly on cross- > compilers. They are, however, written in a way that should make it > relatively easy to improve them and include proper target > representations. And they do function properly for a native compiler. Have you or Paul actually checked that they don't work correctly on cross-compilers? I think that at least the integer and real constants are stored in tress in host endianess (and thus, probably the logical and complex also work)... For characters, there's a target hook to convert from host charset: it's lang_hooks.to_target_charset (see uses in trans-expr.c and in the middle-end). For derived types, I don't know. > I think the best plan is to do a little more polishing work on this > as it stands, and then commit it to mainline on the grounds that > it's at least a distinct improvement over the current form, even if > it's wrong for cross-compilers. Well, I think we should really know exactly where we stand on the cross-compiler ground before commiting. Otherwise, we'll end up discovering the worst in a long time from now, and it will be one of these vicious wrong-code bugs :) > I will then work on implementing the "right" sort of memory > transfer functions that don't piggyback off the host's memory > representation. I don't think we gain so much from exposure by commiting early. The patch is not that large, I guess. Of course, as I'm not volunteering to do the hard job (sorry guys) I'm not opposing to whatever you decide. > +static size_t > +size_float (int kind) > +{ > + return kind; > +} So I take it it's a byte size, right? Why not make it a bit size, are we sure there's never a bit size involved? (hum, maybe not until bitfields are added as F2008, perhaps) Also, we should really be getting those from the bit_size field of the gfc_{integer,logical}_info structures for integer and logical, and we should also add a similar field in the gfc_real_info structure. I think that otherwise, you can get the real(kind=10) size wrong, no? FX