another bootstrap failure on sparc-sun-solaris28 in cp/xref.o

another bootstrap failure on sparc-sun-solaris28 in cp/xref.o

[lucier]

I'm getting a lot of strange bootstrap failures on sparc today.  This one has the
message:

../../gcc/cp/xref.c: In function `GNU_xref_member':
../../gcc/cp/xref.c:599: parse error before "value"
../../gcc/cp/xref.c:602: parse error before "confg"

This is building stage2 with the stage1 compiler with make -j 12 bootstrap after
a generic configure.

The code in question is indeed nonsense, see lines 9125-9126 of

http://www.math.purdue.edu/~lucier/xref.i

It has something to do with the macro exansion of 

  if (TREE_CODE (fld) == FUNCTION_DECL && DECL_CONST_MEMFUNC_P(fld))
    confg = 1;

Brad Lucier

Re: another bootstrap failure on sparc-sun-solaris28 in cp/xref.o

[Rainer Orth]

lucier@math.purdue.edu writes:

> I'm getting a lot of strange bootstrap failures on sparc today.  This one has the
> message:
> 
> ../../gcc/cp/xref.c: In function `GNU_xref_member':
> ../../gcc/cp/xref.c:599: parse error before "value"
> ../../gcc/cp/xref.c:602: parse error before "confg"
> 
> This is building stage2 with the stage1 compiler with make -j 12 bootstrap after
> a generic configure.

same here, though different files are affected:

gcc/reload.c: In function `strict_memory_address_p':
gcc/reload.c:2016: parse error before ']' token
gcc/reload.c:2475:1: directives may not be used inside a macro argument
gcc/reload.c:2473:26: unterminated argument list invoking macro "XCEXP"
gcc/reload.c:2475:2: warning: traditional C ignores #ifdef with the # indented

Wrong macro expansion seems to be the culprit here, too.  This happened
(though in different files) both before and after an update to

2001-09-26  Neil Booth  <neil@daikokuya.demon.co.uk>

        * cpphash.h (struct _cpp_buff, _cpp_get_buff, _cpp_release_buff,

I'm about to do a binary search to determine the patch: bootstrapping cvs
update -D 20010924 was successful (up to ChangeLog revision 1.11398), -D
20010925 (1.11410) is in progress.

I'll have to continue the search tomorrow, time to go to bed now :-)

alpha-dec-osf5.1 and i386-pc-solaris2.9 bootstrap from the same tree.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University

Email: ro@TechFak.Uni-Bielefeld.DE

Re: another bootstrap failure on sparc-sun-solaris28 in cp/xref.o

[Neil Booth]

lucier@math.purdue.edu wrote:-

> I'm getting a lot of strange bootstrap failures on sparc today.
> This one has the message:

> ../../gcc/cp/xref.c: In function `GNU_xref_member':
> ../../gcc/cp/xref.c:599: parse error before "value"
> ../../gcc/cp/xref.c:602: parse error before "confg"
> 
> This is building stage2 with the stage1 compiler with make -j 12 bootstrap after
> a generic configure.
> 
> The code in question is indeed nonsense, see lines 9125-9126 of
> 
> http://www.math.purdue.edu/~lucier/xref.i
> 
> It has something to do with the macro exansion of 
> 
>   if (TREE_CODE (fld) == FUNCTION_DECL && DECL_CONST_MEMFUNC_P(fld))
>     confg = 1;

Hmm.  Is this 3.1?  This must be related to my changes.  Does this
include my patch with ChangeLog starting

	* cpphash.h (struct _cpp_buff, _cpp_get_buff, _cpp_release_buff,
	_cpp_extend_buff, _cpp_free_buff): New.
	(struct cpp_reader): New member free_buffs.
	* cppinit.c (cpp_destroy): Free buffers.

?  This had a silly bug in it, but I don't think it can cause
something to be preprocessed wrongly, it just used more memory than it
should.  But maybe not...

Anyway, could you try the latest version; I just committed an update.

I've bootstrapped many many times in the last 72 hours, including
xref.c, so I don't understand what could be wrong.  Maybe an
uninitialized variable or something that shows up more easily on a
different O/S.  Unfortunately, bugs in long macro expansions like that
one are really hard to debug, particularly remotely.

Let me know if it's OK with the current sources.

Neil.

Am I the only one having trouble with the gcc.gnu.org server recently?
It's been tremendously sluggish, to the point of being unusable, over
the last two days or so.

Re: another bootstrap failure on sparc-sun-solaris28 in cp/xref.o

[Rainer Orth]

[-- Attachment #1: Type: text/plain, Size: 2209 bytes --]

Neil,

your patch identified below causes a bootstrap failure on
sparc-sun-solaris2.8. 

> lucier@math.purdue.edu writes:
> 
> > I'm getting a lot of strange bootstrap failures on sparc today.  This one has the
> > message:
> > 
> > ../../gcc/cp/xref.c: In function `GNU_xref_member':
> > ../../gcc/cp/xref.c:599: parse error before "value"
> > ../../gcc/cp/xref.c:602: parse error before "confg"
> > 
> > This is building stage2 with the stage1 compiler with make -j 12 bootstrap after
> > a generic configure.
> 
> same here, though different files are affected:
> 
> gcc/reload.c: In function `strict_memory_address_p':
> gcc/reload.c:2016: parse error before ']' token
> gcc/reload.c:2475:1: directives may not be used inside a macro argument
> gcc/reload.c:2473:26: unterminated argument list invoking macro "XCEXP"
> gcc/reload.c:2475:2: warning: traditional C ignores #ifdef with the # indented
> 
> Wrong macro expansion seems to be the culprit here, too.  This happened
> (though in different files) both before and after an update to
> 
> 2001-09-26  Neil Booth  <neil@daikokuya.demon.co.uk>
> 
>         * cpphash.h (struct _cpp_buff, _cpp_get_buff, _cpp_release_buff,
> 
> I'm about to do a binary search to determine the patch: bootstrapping cvs
> update -D 20010924 was successful (up to ChangeLog revision 1.11398), -D
> 20010925 (1.11410) is in progress.
> 
> I'll have to continue the search tomorrow, time to go to bed now :-)

couldn't get off again ;-(

But I've found the patch causing this: -D 20010925 was successfull, -D
'20010925 00:55' fails to bootstrap:

gcc/dependence.c: In function `find_induction_variable':
gcc/dependence.c:487: parse error before 'd'
gcc/dependence.c:489: `__t' undeclared (first use in this function)
gcc/dependence.c:489: (Each undeclared identifier is reported only once
gcc/dependence.c:489: for each function it appears in.)
gcc/dependence.c:489: parse error before ')' token

I've included the diff between dependence.i from the successful and failed
builds below.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University

Email: ro@TechFak.Uni-Bielefeld.DE



[-- Attachment #2: depencence.i.udif.gz --]
[-- Type: application/x-gzip, Size: 1767 bytes --]

Re: another bootstrap failure on sparc-sun-solaris28 in cp/xref.o

[Neil Booth]

Rainer Orth wrote:-

> your patch identified below causes a bootstrap failure on
> sparc-sun-solaris2.8. 

OK.  Could you try the latest?  If that doesn't work, I'm stumped, so
I'll have to back everything out.  FWIW the regression tester hasn't
complained to me, either.

> I've included the diff between dependence.i from the successful and failed
> builds below.

Your diff shows #pragma ident lines to be different.  But they look
identical to me.  How are they different?

I have no chance of debugging that scary mess of a macro expansion at
the bottom unless I can reproduce it :-(.

Neil.

Re: another bootstrap failure on sparc-sun-solaris28 in cp/xref.o

[Brad Lucier]

> 
> Rainer Orth wrote:-
> 
> > your patch identified below causes a bootstrap failure on
> > sparc-sun-solaris2.8. 
> 
> OK.  Could you try the latest?

Bootstrap on sparc gets past this problem now, thanks.  Bootstrap still fails
with the month-old problem diagnosed with a proposed fix in this patch

http://gcc.gnu.org/ml/gcc-patches/2001-09/msg00488.html

which has not yet been reviewed to my knowledge.

Brad Lucier

Unreviewed patch (was: another bootstrap failure onsparc-sun-solaris28in cp/xref.o)

[Gerald Pfeifer]

On Wed, 26 Sep 2001, Brad Lucier wrote:
> Bootstrap still fails with the month-old problem diagnosed with a
> proposed fix in this patch
>
> http://gcc.gnu.org/ml/gcc-patches/2001-09/msg00488.html
>
> which has not yet been reviewed to my knowledge.

Could someone please review this patch?  The problem seems to hurt a
number of people (including GCC developers and testers).

Excerpt: Attempting to bootstrap on Solaris SPARC fails with:

  /usr/local/build/sparc-sun-solaris2.7/GNU/gcc-current/gcc/xgcc
  -B/usr/local/build/sparc-sun-solaris2.7/GNU/gcc-current/gcc/
  -B/usr/local/sparc-sun-solaris2.7/bin/
  -B/usr/local/sparc-sun-solaris2.7/lib/ -isystem
  /usr/local/sparc-sun-solaris2.7/include -fgnu-runtime -c -I.
  -I../../../../../../src/GNU/gcc-current/libobjc -g -O2 -DHAVE_GTHR_DEFAULT
  -DIN_GCC -DIN_TARGET_LIBS
  -I../../../../../../src/GNU/gcc-current/libobjc/objc
  -I../../../../../../src/GNU/gcc-current/libobjc/../gcc
  -I../../../../../../src/GNU/gcc-current/libobjc/../gcc/config -I../../gcc
  -I../../../../../../src/GNU/gcc-current/libobjc/../include
  ../../../../../../src/GNU/gcc-current/libobjc/linking.m -o linking.o
  /usr/ccs/bin/as: "/var/tmp//ccwjdWLL.s", line 171: error: cannot use v9 instructions in a non-v9 target binary
  make[2]: *** [linking.lo] Error 1

  due to gcc outputing .uaxword which the Sun assembler dislikes when
  targeting the 32 bit instruction set.
  [...]
  Wed Sep 12 22:50:19 EDT 2001  John Wehle  (john@feith.com)

        * dwarf2asm.c (unaligned_integer_asm_op): Delete.
        (dw2_asm_output_data): Use assemble_integer in place
        of unaligned_integer_asm_op.
        (dw2_asm_output_delta): Likewise.
        (dw2_asm_output_offset): Likewise.
        (dw2_asm_output_pcrel): Likewise.
        (dw2_asm_output_addr): Likewise.
        (dw2_asm_output_addr_rtx): Likewise.
        (dw2_asm_output_encoded_addr_rtx): Likewise.
        * sparc/sysv4.h (UNALIGNED_DOUBLE_INT_ASM_OP): Use
        only if TARGET_ARCH64.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: another bootstrap failure on sparc-sun-solaris28 in cp/xref.o

[Rainer Orth]

Neil Booth writes:

> Rainer Orth wrote:-
> 
> > your patch identified below causes a bootstrap failure on
> > sparc-sun-solaris2.8. 
> 
> OK.  Could you try the latest?  If that doesn't work, I'm stumped, so
> I'll have to back everything out.  FWIW the regression tester hasn't
> complained to me, either.

With this patch

2001-09-26  Neil Booth  <neil@daikokuya.demon.co.uk>

        * cpphash.h (struct cpp_pool): Remove locks and locked.

at the head of gcc/ChangeLog, bootstrap went past the make compare stage.
With the previous one

2001-09-26  Neil Booth  <neil@daikokuya.demon.co.uk>

        * cpphash.h (struct _cpp_buff, _cpp_get_buff, _cpp_release_buff,
        _cpp_extend_buff, _cpp_free_buff): New.

it was still broken yesterday night.

> Your diff shows #pragma ident lines to be different.  But they look
> identical to me.  How are they different?

There's a trailing blank on the second lines.

	Rainer

-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University

Email: ro@TechFak.Uni-Bielefeld.DE

Re: Unreviewed patch (was: another bootstrap failure onsparc-sun-solaris28 in cp/xref.o)

[Richard Henderson]

On Thu, Sep 27, 2001 at 09:41:01AM +0200, Gerald Pfeifer wrote:
> > http://gcc.gnu.org/ml/gcc-patches/2001-09/msg00488.html
> >
> > which has not yet been reviewed to my knowledge.

Oh yes.  I keep meaning to look at this one in detail.

>   due to gcc outputing .uaxword which the Sun assembler dislikes when
>   targeting the 32 bit instruction set.

I suspect that one can simply do

#define UNALIGNED_DOUBLE_INT_ASM_OP  (TARGET_ARCH64 ? ".uaxword" : NULL)

but the patch didn't describe what caused the problem.


r~