From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69108 invoked by alias); 22 Nov 2016 13:37:59 -0000 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 Received: (qmail 69094 invoked by uid 89); 22 Nov 2016 13:37:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 22 Nov 2016 13:37:57 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4C9183B70D; Tue, 22 Nov 2016 13:37:56 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-204-19.brq.redhat.com [10.40.204.19]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uAMDbsYJ000396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 22 Nov 2016 08:37:55 -0500 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id uAMDbrVU014492; Tue, 22 Nov 2016 14:37:53 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id uAMDbpTP014491; Tue, 22 Nov 2016 14:37:51 +0100 Date: Tue, 22 Nov 2016 13:37:00 -0000 From: Jakub Jelinek To: Bernd Schmidt Cc: vogt@linux.vnet.ibm.com, David Malcolm , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] (v2) Add a "compact" mode to print_rtx_function Message-ID: <20161122133750.GR3541@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <43d4ec20-5f84-2533-22e4-e16c779f6162@redhat.com> <1476304646-39819-1-git-send-email-dmalcolm@redhat.com> <20161122131836.GA7025@linux.vnet.ibm.com> <48811c08-6412-2e8b-2763-b163c358afe3@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48811c08-6412-2e8b-2763-b163c358afe3@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2016-11/txt/msg02212.txt.bz2 On Tue, Nov 22, 2016 at 02:32:39PM +0100, Bernd Schmidt wrote: > On 11/22/2016 02:18 PM, Dominik Vogt wrote: > > >>@@ -284,7 +292,7 @@ print_rtx_operand_code_i (const_rtx in_rtx, int idx) > >> if (INSN_HAS_LOCATION (in_insn)) > >> { > >> expanded_location xloc = insn_location (in_insn); > >>- fprintf (outfile, " %s:%i", xloc.file, xloc.line); > >>+ fprintf (outfile, " \"%s\":%i", xloc.file, xloc.line); > > > >Was this change intentional? We've got to update a scan-assembler > >statement in an s390 test to reflect the additional double quotes > >in the output string. Not a big deal, just wanted to make sure > >this is not an accident. > > The idea was to make the output less ambiguous for file names with spaces. Can't it be done only if xloc.file contains any fancy characters? If it does (where fancy should be anything other than [a-zA-Z/_0-9.-] or some other reasonable definition, certainly space, quotes, backslash, etc. would count), shouldn't we adjust it (e.g. use \" instead of ", handle control characters etc.)? Jakub