From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21509 invoked by alias); 4 Oct 2008 11:57:25 -0000 Received: (qmail 21377 invoked by uid 48); 4 Oct 2008 11:56:05 -0000 Date: Sat, 04 Oct 2008 11:57:00 -0000 Message-ID: <20081004115605.21376.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/msg00324.txt.bz2 ------- Comment #14 from pault at gcc dot gnu dot org 2008-10-04 11:56 ------- (In reply to comment #13) > > 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 The real transfer(real(1.0,kind(x)) simplifies to a constant, which is why it can be evaluated. size(transfer(x, [1])) needs the variable, 'x'; even though the inquiry function does not need the value. My attempts to bypass this produced all manner of regressions. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35680