From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13825 invoked by alias); 1 Feb 2008 15:32:33 -0000 Received: (qmail 13182 invoked by uid 48); 1 Feb 2008 15:31:49 -0000 Date: Fri, 01 Feb 2008 15:32:00 -0000 Message-ID: <20080201153149.13181.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug fortran/19925] Implied do-loop in an initialization expression is broken 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: 2008-02/txt/msg00062.txt.bz2 ------- Comment #20 from dominiq at lps dot ens dot fr 2008-02-01 15:31 ------- With the patch in comment #18, on a Core2Duo 2.16Ghz I get: 5000 0.54 secs 10000 1.82 20000 6.74 40000 36.5 60000 206 65535 258 65536 68 <-- Error: Initialization expression didn't reduce (1) 80000 149 Ditto 100000 281 Ditto So the threshold seems to be 2**16. While the timings in comment #18 seem more or less cubic in n, on the Core2duo, they start more or less quadratic in n up to 20000, then grow up much faster with n, as if they were the addition of one quadratic behavior and one cubic (or faster) with prefactors depending on the processor. Note that the patch in #18, is not needed below some value of n: n=10000 pass on unpatched ppc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19925