From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id 967DD3857C4E for ; Fri, 25 Sep 2020 11:37:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 967DD3857C4E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rguenther@suse.de X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 91AE3AD25; Fri, 25 Sep 2020 11:37:16 +0000 (UTC) Date: Fri, 25 Sep 2020 13:37:16 +0200 (CEST) From: Richard Biener Sender: rguenther@c653.arch.suse.de To: Jakub Jelinek cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] c++/97197 - support TARGET_MEM_REF in C/C++ error pretty-printing In-Reply-To: <20200925112030.GU2176@tucnak> Message-ID: References: <20200925112030.GU2176@tucnak> User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2020 11:37:18 -0000 On Fri, 25 Sep 2020, Jakub Jelinek wrote: > On Fri, Sep 25, 2020 at 01:11:37PM +0200, Richard Biener wrote: > > This adds rough support to avoid "'target_mem_ref' not supported by" > > in diagnostics. There were recent patches by Martin to sanitize > > dumping of MEM_REF so I'm not trying to interfere with this here. > > Is that correct? > I mean, TARGET_MEM_REF encodes more than what MEM_REF encodes, > so printing it like MEM_REF will ignore many things from there. > I'd say we should print it like: > *(type *)(BASE + STEP * INDEX + INDEX2 + OFFSET) > rather than how we print MEM_REFs as > *(type *)(BASE + OFFSET) > (with skipping whatever is NULL in there). > So instead of adding case MEM_REF: in the second and last hunk > copy and edit it (perhaps kill the probably unnecessary > part that checks for *&foo and prints it as foo, because who would > create TARGET_MEM_REF when MEM_REF could have been used in that case). See my comment above for Martins attempts to improve things. I don't really want to try decide what to do with those late diagnostic IL printing but my commit was blamed for showing target-mem-ref unsupported. I don't have much time to spend to think what to best print and what not, but yes, printing only the MEM_REF part is certainly imprecise. I'll leave the PR to FE folks. Thanks, Richard. > > > > Bootstrap & regtest pending. > > > > OK? > > > > 2020-09-25 Richard Biener > > > > PR c++/97197 > > cp/ > > * error.c (dump_expr): Handle TARGET_MEM_REF as if it > > were MEM_REF. > > > > c-family/ > > * c-pretty-print.c (c_pretty_printer::postfix_expression): > > Handle TARGET_MEM_REF as expression. > > (c_pretty_printer::expression): Handle TARGET_MEM_REF as > > unary_expression. > > (c_pretty_printer::unary_expression): Handle TARGET_MEM_REF > > as if it were MEM_REF. > > Jakub > > -- Richard Biener SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imend