From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22449 invoked by alias); 29 Sep 2008 20:26:52 -0000 Received: (qmail 22154 invoked by uid 48); 29 Sep 2008 20:25:31 -0000 Date: Mon, 29 Sep 2008 20:26:00 -0000 Message-ID: <20080929202531.22153.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug fortran/35680] [4.3/4.4 regression] ICE on invalid transfer in variable declaration In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "dominiq at lps dot ens dot fr" 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-09/txt/msg02964.txt.bz2 ------- Comment #9 from dominiq at lps dot ens dot fr 2008-09-29 20:25 ------- Although I am not familiar with the gfortran code, gfc_array_size (mold, &tmp)I think the reason why gfortran.dg/transfer_array_intrinsic_4.f90 fails with the patch in comment #6, is because gfc_array_size (mold, &tmp) looks at the size of mold, while the relevant part of the TRANSFER definition is: If SIZE is absent but MOLD is an array (of any size or shape), the result is a one-dimensional array of the minimum length needed to contain the entirety of the bitwise representation of SOURCE. So I think tmp should contain (number_of_bytes_in_SOURCE+size_in_bytes_of_a_MOLD_element-1)/size_in_bytes_of_a_MOLD_element. Note that it would be interesting to test the code for [1_1], [1_2], [1_8], and -fdefault-integer-8 to rule out side effects. BTW I think the code in comment #0 is valid for both statement order: if 'real x' is before TRANSFER, it value is not defined, but not necessary to get the size; if 'real x' is after TRANSFER, x is implicitely defined as real and I think it is legal to confirm it by the 'real x' statement. At least the following code real :: y=epsilon(x) real :: x print *, y end is accepted by gfortran, ifort, and g95. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35680