From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25125 invoked by alias); 3 May 2006 01:51:45 -0000 Received: (qmail 25062 invoked by uid 48); 3 May 2006 01:51:42 -0000 Date: Wed, 03 May 2006 01:51:00 -0000 Message-ID: <20060503015142.25061.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug fortran/17298] gfortran ICE: Not Implemented: Scalarization of non-elemental intrinsic: __transfer1 In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "RNMcLean at yahoo dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-05/txt/msg00242.txt.bz2 List-Id: ------- Comment #23 from RNMcLean at yahoo dot com 2006-05-03 01:51 ------- (In reply to comment #2) > Let me stress the importance of fixing this bug: it occurs in Basic Linear > Algebra Subprograms (BLAS), in program dcabs1.f: > > double precision function dcabs1(z) > double complex z > double precision t(2) > t=transfer(z,t) > dcabs1 = dabs(t(1)) + dabs(t(2)) > return > end > I'm unfamiliar with Bugzilla, so if I annoy anyone, apologies. This routine is a puzzle, or else I have completely misunderstood it. The TRANSFER is obviously spurious, as it merely allows the sort of renaming that used to be possible with the deprecated EQUIVALENCE statement, were it to be allowed for parameters. But, why not dcabs1 = abs(real(z)) + abs(aimag(z)) relying on proper precision selection (or, supply d prefixes). Of course, in general the TRANSFER function should work. Best wishes, RNMcLean somewhere by yahoo.com -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17298