From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13618 invoked by alias); 29 Oct 2010 21:59:06 -0000 Received: (qmail 13490 invoked by uid 22791); 29 Oct 2010 21:59:05 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,MISSING_MID X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 29 Oct 2010 21:59:01 +0000 From: "joseph at codesourcery dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/46186] Clang creates code running 1600 times faster than gcc's X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: minor X-Bugzilla-Who: joseph at codesourcery dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Fri, 29 Oct 2010 21:59:00 -0000 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: 2010-10/txt/msg02528.txt.bz2 Message-ID: <20101029215900.3PcO3ZyMgf6aa3tHD35BbKHuRgezTExMr83G_nmhYW4@z> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186 --- Comment #24 from joseph at codesourcery dot com 2010-10-29 21:58:46 UTC --- On Fri, 29 Oct 2010, sebpop at gmail dot com wrote: > here is a preliminary patch (not tested yet other that the PR testcase). How does this patch deal with needing to compute in a wider type to avoid losing high bits before the division - is that covered by some existing code? It could certainly do with execution testcases that verify cases where computing everything naively in the original type would yield an incorrect result (and those were computing in a type of double the width would still have overflow, etc.).