Re: Problem with insn-conditions.c

[Zack Weinberg <zack at codesourcery dot com>]

Will Pugh <willpugh@gmail.com> writes:

> Hi,
>
> I'm really new to compiling GCC, and ran into a problem where
> insn-conditions.c contained illegal characters in some of the strings
> it generated.
>
> It looked like the problem was that genconditions.c did not take into
> account that the souce file was using windows line endings rather than
> just \n

That sounds like a genuine bug that you've found, although it's
curious that no one else has encountered it (to my knowledge).

> Have other people run into this problem?  I fixed it by just having
> genconditions.c escape \r (although it might have been a better idea
> to just have it ignore \r)

I'm not sure whether that's the right fix.  We have to be careful
about the strings written to insn-conditions.o, because they're
compared literally against strings read from the machine description.
If they don't match, maybe_eval_c_test will abort.

A better fix might be to change read_quoted_string and
read_braced_string (in read-rtl.c) to strip \r from the strings they
process.  Then the generated files _should_ become independent of the
line endings in use ... I'm not sure if fputs(string, stdout) on
Windows will convert \n to \r\n when it's in the middle of the string,
but it sure ought to.

> 151,152d150
> <       else if (*p == '\r')
> <       fputs ("\\r", stdout);

Please use diff -u or diff -c when submitting patches.  Also, you got
the files in the wrong order -- the newer file goes second.

zw