[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

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

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  -

reply via email to

[Prev in Thread] Current Thread [Next in Thread]