From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4982 invoked by alias); 23 Jun 2011 10:06:00 -0000 Received: (qmail 4971 invoked by uid 22791); 23 Jun 2011 10:05:59 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-ww0-f51.google.com (HELO mail-ww0-f51.google.com) (74.125.82.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 23 Jun 2011 10:05:38 +0000 Received: by wwj26 with SMTP id 26so1593921wwj.8 for ; Thu, 23 Jun 2011 03:05:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.174.69 with SMTP id s5mr1743400wbz.80.1308823536856; Thu, 23 Jun 2011 03:05:36 -0700 (PDT) Received: by 10.227.36.212 with HTTP; Thu, 23 Jun 2011 03:05:36 -0700 (PDT) In-Reply-To: <201106231000.14474.ebotcazou@adacore.com> References: <201106221613.09011.ebotcazou@adacore.com> <201106231000.14474.ebotcazou@adacore.com> Date: Thu, 23 Jun 2011 10:32:00 -0000 Message-ID: Subject: Re: Mark variables addressable if they are copied using libcall in RTL expander From: Richard Guenther To: Eric Botcazou Cc: Easwaran Raman , gcc-patches@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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/msg01748.txt.bz2 On Thu, Jun 23, 2011 at 10:00 AM, Eric Botcazou wro= te: >> Is the following patch a reasonable fix for this case? > > The lines should be moved to within the first branch of the subsequent "i= f". > They aren't needed if the second branch is taken because, in this case, w= e're > back to the usual caller-copied scheme where we pass the address of the c= opy. > >> 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_cop= y case > as the one applied in emit_block_move_hints. > > > But these problems show that there is a slight discrepancy between what d= se.c > really needs (is the address of the variable taken?) and what may_be_alia= sed > answers (might the variable be indirectly modified?). =A0Another viewpoin= t is to > say that there is a slight discrepancy between Tree and RTL level when it= comes > to the address-taken property. =A0Not clear what to do about it so I thin= k that > we should try this kludgy way and see how it fares. Yeah, I agree. Unless we want to really do alias analysis on RTL (and not = just export what the tree level has in some way) let's go forward with this. So, what's the patch(es) that need approval now? Thanks, Richard. > -- > Eric Botcazou >