From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9952 invoked by alias); 2 Nov 2008 12:05:28 -0000 Received: (qmail 30987 invoked by uid 48); 2 Nov 2008 12:04:08 -0000 Date: Sun, 02 Nov 2008 12:05:00 -0000 Message-ID: <20081102120408.30986.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug tree-optimization/37991] [4.4 Regression] excessive memory consumption - possible hang In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "rguenth 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-11/txt/msg00116.txt.bz2 ------- Comment #5 from rguenth at gcc dot gnu dot org 2008-11-02 12:04 ------- More reduced: typedef int Int32; void use_it(int); void FindAndReadSignature(int processedSize) { int numPrevBytes = 1; for (;;) { int numBytesInBuffer = numPrevBytes + processedSize; Int32 numTests = numBytesInBuffer - 1; use_it (numTests); numPrevBytes = numBytesInBuffer - numTests; } } to not oscillate we rely on numTests _not_ be varying. It happens to be with the typedef as we forget to strip useless conversions. Otherwise we oscillate numPrevBytes (loop entry vs. back edge) between 1 and varying. Which may hint at that the speedup brought up by Danny (not processing a use further if it got varying) is even a correctness thing... I have a patch for this particular case. -- rguenth at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dberlin at gcc dot gnu dot | |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37991