From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16105 invoked by alias); 23 Jun 2011 08:00:44 -0000 Received: (qmail 16095 invoked by uid 22791); 23 Jun 2011 08:00:44 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mel.act-europe.fr (HELO mel.act-europe.fr) (194.98.77.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 23 Jun 2011 08:00:29 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id EF389CB0397; Thu, 23 Jun 2011 10:00:28 +0200 (CEST) Received: from mel.act-europe.fr ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zddeiLMg4zw1; Thu, 23 Jun 2011 10:00:26 +0200 (CEST) Received: from [192.168.1.2] (bon31-9-83-155-120-49.fbx.proxad.net [83.155.120.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mel.act-europe.fr (Postfix) with ESMTP id C6798CB0393; Thu, 23 Jun 2011 10:00:25 +0200 (CEST) From: Eric Botcazou To: Easwaran Raman Subject: Re: Mark variables addressable if they are copied using libcall in RTL expander Date: Thu, 23 Jun 2011 10:00:00 -0000 User-Agent: KMail/1.9.9 Cc: Richard Guenther , gcc-patches@gcc.gnu.org References: <201106221613.09011.ebotcazou@adacore.com> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <201106231000.14474.ebotcazou@adacore.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-06/txt/msg01744.txt.bz2 > Is the following patch a reasonable fix for this case? The lines should be moved to within the first branch of the subsequent "if". They aren't needed if the second branch is taken because, in this case, we're back to the usual caller-copied scheme where we pass the address of the copy. > I assume I should add similar code inside emit_library_call_value_1. Yes, we need the same treatment for 'val' in the MEM_P (val) && !must_copy case as the one applied in emit_block_move_hints. But these problems show that there is a slight discrepancy between what dse.c really needs (is the address of the variable taken?) and what may_be_aliased answers (might the variable be indirectly modified?). Another viewpoint is to say that there is a slight discrepancy between Tree and RTL level when it comes to the address-taken property. Not clear what to do about it so I think that we should try this kludgy way and see how it fares. -- Eric Botcazou