From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10181 invoked by alias); 3 Dec 2007 14:32:21 -0000 Received: (qmail 10124 invoked by uid 48); 3 Dec 2007 14:32:06 -0000 Date: Mon, 03 Dec 2007 14:32:00 -0000 Message-ID: <20071203143206.10123.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug tree-optimization/34265] Missed optimizations 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: 2007-12/txt/msg00203.txt.bz2 ------- Comment #27 from dominiq at lps dot ens dot fr 2007-12-03 14:32 ------- I have had a look at the failure of gfortran.dg/array_1.f90 with patch #5. The following reduced code gives the same failure: ! { dg-do run } ! PR 15553 : the array used to be filled with garbage ! this problem disappeared between 2004-05-20 and 2004-09-15 program arrpack implicit none double precision x(10,10), tmp(6,5) integer i, j x = -1 do i=1,6 do j=1,5 x(i,j) = i+j*10 end do end do tmp(:,:) = x(1:6, 1:5) print '(6F8.2)', tmp end program arrpack With -O3 and patch #5, the output is 11.00 12.00 13.00 14.00 15.00 16.00 -1.00 -1.00 -1.00 -1.00 21.00 22.00 23.00 24.00 25.00 26.00 -1.00 -1.00 -1.00 -1.00 31.00 32.00 33.00 34.00 35.00 36.00 -1.00 -1.00 -1.00 -1.00 instead of 11.00 12.00 13.00 14.00 15.00 16.00 21.00 22.00 23.00 24.00 25.00 26.00 31.00 32.00 33.00 34.00 35.00 36.00 41.00 42.00 43.00 44.00 45.00 46.00 51.00 52.00 53.00 54.00 55.00 56.00 I am amaze that it is the only failure of this kind for the several 1000 tests I have passed! I'll attach the the results of -fdump-tree-optimize for with and without patch #5. I have also looked at the gcc failures. Most of them are missed vectorizations or new ones. So this is already reported. Is *.[0-9][0-9][0-9]t.vect supposed to exist if the vectorization is missed? If yes, this explaina few failures. Concerning the failures with *.[0-9][0-9][0-9]t.cunroll, I see *cunroll1/2, but no cunroll. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34265