From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2820 invoked by alias); 3 Oct 2008 22:24:26 -0000 Received: (qmail 2637 invoked by uid 48); 3 Oct 2008 22:23:06 -0000 Date: Fri, 03 Oct 2008 22:24:00 -0000 Message-ID: <20081003222306.2636.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-10/txt/msg00293.txt.bz2 ------- Comment #13 from dominiq at lps dot ens dot fr 2008-10-03 22:23 ------- > Happily, I have come to the conclusion that the code is invalid no matter which > order the declarations come in; > .... > (a) a restricted expression or > (b) a variable whose properties inquired about are not > the TRANSFER (x, [1]) argument is manifestly not consistent with (b) and should > fail by (a) with exactly the g95 message. After having knotted my neurones, I agree with that: size(transfer(x, [1])) is not a "restricted expression". > I will make it so. Good! > In fact the ICE is precisely due to the argument not being a restricted > expression, since the size of x and its kind are unavailable to the caller and > the interfacing cannot be made to work. This is why restricted expressions > only permit dummy, host- or use-associated or common variables and why my > attempts to evaluate the transfer are failing. However I disagree with this part of the analysis: size(transfer(real(1.0,kind(x)), [1_1])) is a "restricted expression" (happily accepted by gfortran) that uses exactly the same information as size(transfer(x, [1])) as shown by the following code: program main print *, foo() print *, size(transfer(real(1.0,kind(x)), [1_1])),& size(transfer(x, [1_1])) if (size(foo()) /= kind(x)) call abort() contains function foo() integer foo(size(transfer(real(1.0,kind(x)), [1_1]))) real x foo=transfer(real(1.0,kind(x)), [1_1]) end function end program giving on intel machines (without the patch in comment #6) 0 0 -128 63 4 4 (with the patch the second line is 4 1) or 0 0 0 0 0 0 -16 63 8 8 when compiled with -fdefault-real-8. On ppc I get 63 -128 0 0 4 4 and 63 -16 0 0 0 0 0 0 8 8 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35680