This is the mail archive of the
mailing list for the GCC project.
[Bug target/33532] bogus escape
- From: "wilson at tuliptree dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 26 Sep 2007 22:11:31 -0000
- Subject: [Bug target/33532] bogus escape
- References: <email@example.com/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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 ia64.md file:
[(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/ia64.md:6430: 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.