Re: bison-1.875: workarounds for gcc compiler bug on Alpha

[Nelson H. F. Beebe]

In response to my demonstration of a compiler code generation bug with
gcc on Alpha in src/scan-gram.c, Paul Eggert wrote:

>> ...
>> Here's a guess: there's a bug in scan-skel.l, or a bug in flex and/or
>> the DEC native compilers, which manifests itself on that platform, but
>> only when a single lex token is larger than an input buffer and the
>> buffers need to be reallocated.
>> 
>> Does this compiler define __STDC__ to 0 in user code, and leave
>> __cplusplus undefined?  If so, that might explain the problem.  Can
>> you please try inserting the following lines at the top of
>> src/scan-skel.c?
>> 
>> #define YY_USE_PROTOS
>> #define YY_USE_CONST
>> 
>> and then "rm src/scan-skel.o src/scan-gram.o", and then "make".
>> ...

I tried that, but output was still incorrect:

  #line 16 "\377\037\272'HP\275#\215"

>> ...
>> I assume that HAVE_STDLIB_H and HAVE_UNISTD_H are 1 in config.h?
>> If not, that might also explain the problem.
>> ...

Yes, both are 1 in config.h

>> ...
>> If defining those two symbols doesn't solve the problem, can you
>> please try this workaround instead?  It modifies scan-skel.l so that
>> large lex tokens are much less likely.  You'll need 'flex' installed
>> to generate scan-skel.c.  I'm using flex 2.5.4.
>> 
>> --- scan-skel.l      3 Jan 2003 21:56:01 -0000       1.22
>> +++ scan-skel.l      4 Jan 2003 00:31:28 -0000       1.23
>> @@ -76,7 +76,7 @@ int skel_lex (void);
>>  
>>  "@"    abort ();
>>  \n     lineno++; ECHO;
>> address@hidden          ECHO;
>> address@hidden          ECHO;
>>  
>>  <<EOF>>        xfclose (yyout); free (outname); return EOF;
>>  %%
>> ...

I too have flex-2.5.4 everywhere.  I installed the patch, reran make,
and the test, and still got the same erroneous #line directive.

I also tried linking with Bruce Perens' Electric Fence library earlier
today, to see whether there might be some deviant pointers in
malloc'ed memory, but none were reported.

I'm going to start a build of gdb on this system before heading home
for the night.  If that succeeds, maybe I can make some progress
in identifying the problem more precisely.

-------------------------------------------------------------------------------
- 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  -
-------------------------------------------------------------------------------