This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug target/33532] bogus escape

------- Comment #8 from wilson at tuliptree dot org  2007-09-26 22:11 -------
Subject: Re:  bogus escape

On Tue, 2007-09-25 at 17:36 +0000, kai-gcc-bugs at khms dot westfalen
dot de wrote:
> Furthermore, this is most definitely undocumented (and I'd guess unintentional)
> behaviour. The docs seem to be pretty clear: the contents of a brace block is a
> piece of C, period.

It is unintentional.  The original syntax was friendly to lisp parsers,
and we had only quoted-strings in define_insns, as lisp parsers can't
parse C code.  Later we added braced-strings in define_insns as a
simplification, which is no longer lisp friendly.  When this was done,
there was no change to the handling of escapes.  Internal to gcc, this
is still handled as if it is a string, it just doesn't start and end
with quote characters anymore.

The treatment of escapes is simple.  \" always simplifies to ",
regardless of whether you are inside or outside a string.  This is
because, originally, we were always inside a string here, and the
current code still behaves that way, even when using a braced-string.

> Really, I think calling this an enhancment request is wrong: it is plainly a
> bug. Not necessarily a severe bug, and one can certainly argue why it's there
> and what would be the correct solution, but I am firmly convinced that the
> status quo is NOT correct.

Except that the current behaviour causes no problems at any point in a
gcc build.  You can only see a problem because you have an external
program looking at md files.  This doesn't necessarily make it a gcc
bug.  It could be fixed just as easily in your program by changing how
you handle quoted characters.

I can create an artifical example that shows a gcc bug though.  If I add
this to the end of the file:

(define_insn "artificial"
  [(unspec [(const_int 0)] 9999)]
  return ".section .artificial,\"r\",@progbits";
  [(set_attr "itanium_class" "ignore")
   (set_attr "predicable" "no")])

and then try to build it, I get an error building insn-output.o
../../gcc/gcc/config/ia64/ error: expected â??;â?? before â??râ??
This is because gcc translated this line to
  return ".section .artificial,"r",@progbits";
which is not valid C.  I can make this work by doubling the \
characters, but that is awkward.  We could declare this to be a real gcc
bug, file a PR for it, and then make this one depend on the new bug.
When this new bug gets fixed, this current bug will be exposed as a gcc
build failure, and will have to be fixed.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]