[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bison-1.875: build feedback: HP/Compaq/DEC OSF/1 5.1
From: |
Nelson H. F. Beebe |
Subject: |
Re: bison-1.875: build feedback: HP/Compaq/DEC OSF/1 5.1 |
Date: |
Fri, 3 Jan 2003 15:53:03 -0700 (MST) |
Paul Eggert <address@hidden> writes on Fri, 3 Jan 2003 08:55:26
-0800 (PST) with a suggestion on how to track down the bug that we are
seeing in bison-1.875 tests on Alpha platforms with gcc:
>> ...
>> >
>> > -#line 10 "\377\037\272'HP\275#\215"
>> > +#line 18 "\377\037\272'HP\275#\215"
>>
>> That's strange. Not only is the line number wrong, but also the file
>> name is corrupted. A similar problem occurred in the other test case
>> failure on this platform.
>>
>> Possibly this is related to the compiler bug that you mentioned in
>> another message. Another possibility is a portability problem in
>> lib/quotearg.c, but I don't see offhand what it would be.
>>
>> In scan-skel.l, suppose you replace this:
>>
>> #define QPUTS(String) \
>> fputs (quotearg_style (c_quoting_style, (String)), yyout);
>>
>> with something like this:
>>
>> #define QPUTS(String) \
>> (fputc ("\"", yyout), \
>> fputs (String, yyout), \
>> fputc ("\"", yyout))
>>
>> Does this work around the problem? This is not a real fix; it's just
>> an attempt to see whether the problem is in quotearg.c, or in its
>> caller.
>> ...
[Actually, those two fputc() calls should be fputs(). I made that
change.]
I have now dug into this further, and found that there is a compiler
code generation error that is causing the garbage in the output
directive in tests/testsuite.dir/034/input.c:
#line 10 "\377\037\272'HP\275#\215
There is no gdb on this system, and dbx cannot read gcc's symbol
tables, so isolating the bug is difficult. This particular bug is not
present on the OSF/1 4.0 system where I do have gdb, but that gdb
won't run on OSF/1 5.1.
However, I found that when I recompiled bison with CFLAGS=-g instead
of the default CFLAGS='-g -O2', the previously-failing test #34 now
passed.
I then set up a script to delete one .o file at a time, rebuild bison
with CFLAGS='-g -O2', and rerun the test. Output remained correct
until scan-gram.c was recompiled. I let the script complete, so that
all code is now back at the -O2 level, then deleted scan-gram.o,
recompiled with -g, and reran the test: output was again correct.
I also tried -O1 (bison then core dumped) and -O3 (same erroneous
output as with -O2).
I think we should simply document this one, and move on. The gcc
folks have moved well beyond the 2.9-gnupro-99r1 release (whatever gcc
2.x.y version THAT was derived from), and are unlikely to be
interested in a bug report. Since I still cannot build any gcc-3.x
release successfully on this system, the only choice is to remain with
native compilers.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- Center for Scientific Computing FAX: +1 801 581 4148 -
- University of Utah Internet e-mail: address@hidden -
- Department of Mathematics, 110 LCB address@hidden address@hidden -
- 155 S 1400 E RM 233 address@hidden -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe -
-------------------------------------------------------------------------------