On Tue, 2016-11-22 at 14:37 +0100, Jakub Jelinek wrote:
> 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.
Sorry about the breakage.
How widespread is the problem?
> > 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.)?
The idea was that quotes also make the output somewhat easier for the
RTL frontend to parse, though reading the latest version of the RTL
frontend patches, it looks like I don't make use of them yet.
Another approach would be to only use the quotes when the dump is in
"compact" mode, since compact mode is the format that the RTL frontend
parses: the RTL dumps emitted by DejaGnu don't use it, instead using
the older style.
