From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13470 invoked by alias); 14 Apr 2007 08:28:24 -0000 Received: (qmail 13452 invoked by uid 22791); 14 Apr 2007 08:28:23 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate6.de.ibm.com (HELO mtagate6.de.ibm.com) (195.212.29.155) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 14 Apr 2007 09:28:21 +0100 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.8/8.13.8) with ESMTP id l3E8SIje266808; Sat, 14 Apr 2007 08:28:18 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l3E8SITR3240036; Sat, 14 Apr 2007 10:28:18 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l3E8SIdY001139; Sat, 14 Apr 2007 10:28:18 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l3E8SIcu001134; Sat, 14 Apr 2007 10:28:18 +0200 In-Reply-To: <46208558.2040405@myrealbox.com> Subject: Re: Call to arms: testsuite failures on various targets To: tprince@computer.org Cc: "fortran@gcc.gnu.org List" , FX Coudert , gcc@gcc.gnu.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Dorit Nuzman Date: Sat, 14 Apr 2007 15:50:00 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2007-04/txt/msg00481.txt.bz2 > FX Coudert wrote: > > Hi all, > > > > I reviewed this afternoon the postings from the gcc-testresults > > mailing-list for the past month, and we have a couple of gfortran > > testsuite failures showing up on various targets. Could people with > > access to said targets (possibly maintainers) please file PRs in > > bugzilla for each testcase, reporting the error message and/or > > backtrace? (I'd be happy to be added to the Cc list of these) > > > > * ia64-suse-linux-gnu: gfortran.dg/vect/vect-4.f90 > FAIL: gfortran.dg/vect/vect-4.f90 -O scan-tree-dump-times Alignment of > access > forced using peeling 1 > FAIL: gfortran.dg/vect/vect-4.f90 -O scan-tree-dump-times Vectorizing > an unali > gned access 1 > These tests should xfail on "vect_no_align" targets. On targets that support misaligned accesses we use peeling to align two datarefs, and generate a misaligned memory-access for a third dataref. But on targets that do not support misaligned accesses I expect we just use versioning with runtime alignment test. Does the following pass for you (I just added "{ xfail vect_no_align }" to the two failing tests)? Index: vect-4.f90 =================================================================== --- vect-4.f90 (revision 123409) +++ vect-4.f90 (working copy) @@ -10,7 +10,7 @@ END ! { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } } -! { dg-final { scan-tree-dump-times "Alignment of access forced using peeling" 1 "vect" } } -! { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 1 "vect" } } +! { dg-final { scan-tree-dump-times "Alignment of access forced using peeling" 1 "vect" { xfail vect_no_align } } } +! { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 1 "vect" { xfail vect_no_align } } } ! { dg-final { scan-tree-dump-times "accesses have the same alignment." 1 "vect" } } ! { dg-final { cleanup-tree-dump "vect" } } > This happens on all reported ia64 targets, including mine. What is > expected here? There is no vectorization on ia64, no reason for > peeling. apparently there is vectorization taking place because the first test passes: 'scan-tree-dump-times "vectorized 1 loops" 1 "vect" ' dorit > The compilation has no problem, and there is no report > generated. As far as I know, the vectorization options are ignored. > Without unrolling, of course, gfortran doesn't optimize the loop at all, > but I assume that's a different question.