From patchwork Sun Jul 20 20:59:13 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Botcazou X-Patchwork-Id: 371942 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 5CC62140114 for ; Mon, 21 Jul 2014 07:02:21 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:date:message-id:mime-version:content-type :content-transfer-encoding; q=dns; s=default; b=NE+oE27xGGtze2VC jGWlHY8BOXxuljgwaHkuGRNiJU4Iibxlh4J0FuiHcuh/8Dm4ZQzegk7aW2QEHsdR fk8mpKLEfiURErxz3VurDkUFqu837JLZfuGya9bSOi+DbOgwWYEXy0HHJlanQxXn JoXE6JpGew7BptcQY1f6nzISRC4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:date:message-id:mime-version:content-type :content-transfer-encoding; s=default; bh=CtnDmpw16ysprIcVUmuZZi sh51Y=; b=gtPK8eOA4TkRICPf+ObtCs8YEVu5I2E8OS2ADVZ/+mTAOPmiwjiwLS TmIHjXuruLgFPJlM27uEL111PJisxDynRKVww8mz/uDCj/m1o5qGZItqEzSK1Qef KQK3XZ8pqcUElCSKEcFGUtDsD3h0SR25ntmhwfIHCIVTv+7ZE5aRE= Received: (qmail 20306 invoked by alias); 20 Jul 2014 21:02:13 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 20277 invoked by uid 89); 20 Jul 2014 21:02:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL, BAYES_00 autolearn=ham version=3.3.2 X-HELO: smtp.eu.adacore.com Received: from mel.act-europe.fr (HELO smtp.eu.adacore.com) (194.98.77.210) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Sun, 20 Jul 2014 21:02:09 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 33107272E5A3 for ; Sun, 20 Jul 2014 23:02:06 +0200 (CEST) Received: from smtp.eu.adacore.com ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgW3mupIA9LO for ; Sun, 20 Jul 2014 23:02:06 +0200 (CEST) Received: from polaris.localnet (bon31-6-88-161-99-133.fbx.proxad.net [88.161.99.133]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.eu.adacore.com (Postfix) with ESMTPSA id 17FD4272E5A2 for ; Sun, 20 Jul 2014 23:02:06 +0200 (CEST) From: Eric Botcazou To: gcc-patches@gcc.gnu.org Subject: Fix RTL load motion bug with -fnon-call-exceptions Date: Sun, 20 Jul 2014 22:59:13 +0200 Message-ID: <11623327.7xI96XU0YT@polaris> User-Agent: KMail/4.7.2 (Linux/3.1.10-1.29-desktop; KDE/4.7.2; x86_64; ; ) MIME-Version: 1.0 We have a testcase that is miscompiled at -O3 by our GCC 4.9-based compiler, although it isn't by the pristine GCC 4.9 compiler. You need a specific combination of events (aggressive inlining, -fnon-call-exceptions, memory accesses marked MEM_NOTRAP_P) which causes RTL load motion to wrongly delete a MEM_NOTRAP_P load because there is another load from the same address but without MEM_NOTRAP_P, the root cause being that simple_mem will return true for the former but false for the latter. Setting MEM_NOTRAP_P is a best effort thing so not setting it should not lead to wrong code. Tested on x86-64/Linux, applied on the mainline. 2014-07-20 Eric Botcazou * cse.c (exp_equiv_p) : For GCSE, return 0 for expressions with different trapping status if -fnon-call-exceptions is enabled. Index: cse.c =================================================================== --- cse.c (revision 212833) +++ cse.c (working copy) @@ -2687,6 +2687,13 @@ exp_equiv_p (const_rtx x, const_rtx y, i the same attributes share the same mem_attrs data structure. */ if (MEM_ATTRS (x) != MEM_ATTRS (y)) return 0; + + /* If we are handling exceptions, we cannot consider two expressions + with different trapping status as equivalent, because simple_mem + might accept one and reject the other. */ + if (cfun->can_throw_non_call_exceptions + && (MEM_NOTRAP_P (x) != MEM_NOTRAP_P (y))) + return 0; } break;