From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8332 invoked by alias); 3 Oct 2008 12:14:17 -0000 Received: (qmail 5885 invoked by uid 48); 3 Oct 2008 12:12:56 -0000 Date: Fri, 03 Oct 2008 12:14:00 -0000 Message-ID: <20081003121256.5884.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: "pault 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-10/txt/msg00240.txt.bz2 ------- Comment #12 from pault at gcc dot gnu dot org 2008-10-03 12:12 ------- (In reply to comment #11) Happily, I have come to the conclusion that the code is invalid no matter which order the declarations come in; In a restricted expression... (7.1.6.2): (7) A reference to an intrinsic function that is (a) an array inquiry function (13.11.15) other than ALLOCATED, ....SIZE in this case.... .... and where each argument of the function is (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. I will make it so. 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. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35680