tree-ssa-cvs corrupt

tree-ssa-cvs corrupt

[Andreas Jaeger]

Jason,

it seems that your latest patch to the tree-ssa branch has corrupted
the testsuite.

I got lots of failures in the testsuite due to missing first characters.

Note the missing "/" at the beginning of the line:
arthur:/cvs/gcc-tree-ssa-20020619-branch/gcc/testsuite/gcc.c-torture/compile:[0]
$ head 20001226-1.c
* This testcase exposed two branch shortening bugs on powerpc.  */

$ cvs status 20001226-1.c
===================================================================
File: 20001226-1.c      Status: Up-to-date

   Working revision:    1.1.26.1
   Repository revision: 1.1.26.1        /cvs/cvs-mirror-rsync/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/20001226-1.c,v
   Sticky Tag:          tree-ssa-20020619-branch (branch: 1.1.26)
   Sticky Date:         (none)
   Sticky Options:      (none)

$ cvs diff -D yesterday  20001226-1.c 
Index: 20001226-1.c
===================================================================
RCS file: /cvs/cvs-mirror-rsync/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/20001226-1.c,v
retrieving revision 1.1
retrieving revision 1.1.26.1
diff -u -p -r1.1 -r1.1.26.1
--- 20001226-1.c        27 Dec 2000 11:01:03 -0000      1.1
+++ 20001226-1.c        25 Nov 2002 04:25:27 -0000      1.1.26.1
@@ -1,4 +1,4 @@
-/* This testcase exposed two branch shortening bugs on powerpc.  */
+* This testcase exposed two branch shortening bugs on powerpc.  */
 
 #define C(a,b) \
   if (a > b)  goto gt; \

Jason, can you check your latest commit again, please?
Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: tree-ssa-cvs corrupt

[Diego Novillo]

On Fri, 03 Jan 2003, Andreas Jaeger wrote:

> I got lots of failures in the testsuite due to missing first characters.
> 
> Note the missing "/" at the beginning of the line:
> arthur:/cvs/gcc-tree-ssa-20020619-branch/gcc/testsuite/gcc.c-torture/compile:[0]
> $ head 20001226-1.c
>
This one is on purpose.  I added an explicit syntax error to
avoid blowing up memory usage.  When building SSA we start
allocating more and more memory until eventually timing out and
thrashing the machine to death.

I couldn't XFAIL it because the harness still tries to compile
the testcase first.

Odd that you just got the update today.  This explicit syntax
error has been there for a few months.


Diego.

Re: tree-ssa-cvs corrupt

[Diego Novillo]

On Fri, 03 Jan 2003, Diego Novillo wrote:

> Odd that you just got the update today.  This explicit syntax
> error has been there for a few months.
> 
s/months/weeks/

Re: tree-ssa-cvs corrupt

[Andreas Jaeger]

Diego Novillo <dnovillo@redhat.com> writes:

> On Fri, 03 Jan 2003, Andreas Jaeger wrote:
>
>> I got lots of failures in the testsuite due to missing first characters.
>> 
>> Note the missing "/" at the beginning of the line:
>> arthur:/cvs/gcc-tree-ssa-20020619-branch/gcc/testsuite/gcc.c-torture/compile:[0]
>> $ head 20001226-1.c
>>
> This one is on purpose.  I added an explicit syntax error to
> avoid blowing up memory usage.  When building SSA we start
> allocating more and more memory until eventually timing out and
> thrashing the machine to death.
>
> I couldn't XFAIL it because the harness still tries to compile
> the testcase first.
>
> Odd that you just got the update today.  This explicit syntax
> error has been there for a few months.

I see.  Thanks for the clarification.  I got this on a number of files
and was confused to see it - the last runs I haven't looked in detail
at the results and was surprised to see those failures now.

Ok, let's ignore this for now,
Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: tree-ssa-cvs corrupt

[Mike Stump]

In the C++ testsuite, we found a need for this, and the functionality 
is:

	FIXME - bla bla bla (such as, this test case fails and eats the 
machine alive).

Just thought I'd share, as it is fairly obscure, but as times, useful.

On Friday, January 3, 2003, at 08:29 AM, Diego Novillo wrote:
> This one is on purpose.  I added an explicit syntax error to
> avoid blowing up memory usage.  When building SSA we start
> allocating more and more memory until eventually timing out and
> thrashing the machine to death.
>
> I couldn't XFAIL it because the harness still tries to compile
> the testcase first.

Re: tree-ssa-cvs corrupt

[Phil Edwards]

On Fri, Jan 03, 2003 at 11:29:12AM -0500, Diego Novillo wrote:
> On Fri, 03 Jan 2003, Andreas Jaeger wrote:
> 
> > I got lots of failures in the testsuite due to missing first characters.
> > 
> > Note the missing "/" at the beginning of the line:
> > arthur:/cvs/gcc-tree-ssa-20020619-branch/gcc/testsuite/gcc.c-torture/compile:[0]
> > $ head 20001226-1.c
> >
> This one is on purpose.  I added an explicit syntax error to
> avoid blowing up memory usage.  When building SSA we start
> allocating more and more memory until eventually timing out and
> thrashing the machine to death.
> 
> I couldn't XFAIL it because the harness still tries to compile
> the testcase first.

Might I suggest a self-documenting way of causing an immediate syntax error?

    CRASH NOW, there are memeory problems blah blah blah
    /* This testcase exposed two branch shortening bugs on powerpc.  */

    ...



:-)

Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002

Re: tree-ssa-cvs corrupt

[Zack Weinberg]

Phil Edwards <phil@jaj.com> writes:

> Might I suggest a self-documenting way of causing an immediate syntax error?
>
>     CRASH NOW, there are memeory problems blah blah blah
>     /* This testcase exposed two branch shortening bugs on powerpc.  */

A distant voice on the wind whispers "#error ..."

zw

Re: tree-ssa-cvs corrupt

[Diego Novillo]

On Sat, 04 Jan 2003, Zack Weinberg wrote:

> Phil Edwards <phil@jaj.com> writes:
> 
> > Might I suggest a self-documenting way of causing an immediate syntax error?
> >
> >     CRASH NOW, there are memeory problems blah blah blah
> >     /* This testcase exposed two branch shortening bugs on powerpc.  */
> 
> A distant voice on the wind whispers "#error ..."
> 
The wind replies "we still try to compile the file anyway ..."

I remember trying #error before.  It's odd, because the very
first thing we do in optimize_function_tree() is

  /* Don't bother doing anything if the program has errors.  */
  if (errorcount || sorrycount)
    return;


Is there any other error flag we could check?


Thanks.  Diego.

Re: tree-ssa-cvs corrupt

[Neil Booth]

Diego Novillo wrote:-

> On Sat, 04 Jan 2003, Zack Weinberg wrote:
> 
> > Phil Edwards <phil@jaj.com> writes:
> > 
> > > Might I suggest a self-documenting way of causing an immediate syntax error?
> > >
> > >     CRASH NOW, there are memeory problems blah blah blah
> > >     /* This testcase exposed two branch shortening bugs on powerpc.  */
> > 
> > A distant voice on the wind whispers "#error ..."
> > 
> The wind replies "we still try to compile the file anyway ..."

Yeah, #error should stop compilation like the standard requires.  I've
never gotten round to fixing it.  CPP would need a way to stop it lexing
any more tokens (not too hard), and a way to signal to the front end to
not do any more work.

Neil.

Re: tree-ssa-cvs corrupt

[Zack Weinberg]

Neil Booth <neil@daikokuya.co.uk> writes:

>> > A distant voice on the wind whispers "#error ..."
>> > 
>> The wind replies "we still try to compile the file anyway ..."
>
> Yeah, #error should stop compilation like the standard requires.  I've
> never gotten round to fixing it.  CPP would need a way to stop it lexing
> any more tokens (not too hard), and a way to signal to the front end to
> not do any more work.

The trouble is that #error causes cpplib's parse_in.errors to be
bumped, but that doesn't propagate back to errorcount until
cpp_finish() is called, from c_common_finish.

We can't just change that line you quoted to

  if (errorcount || sorrycount || cpp_errors (&parse_in))

because that will screw over non-C front ends.  Ideas?

zw

Re: tree-ssa-cvs corrupt

[Neil Booth]

Zack Weinberg wrote:-

> Neil Booth <neil@daikokuya.co.uk> writes:
> 
> >> > A distant voice on the wind whispers "#error ..."
> >> > 
> >> The wind replies "we still try to compile the file anyway ..."
> >
> > Yeah, #error should stop compilation like the standard requires.  I've
> > never gotten round to fixing it.  CPP would need a way to stop it lexing
> > any more tokens (not too hard), and a way to signal to the front end to
> > not do any more work.
> 
> The trouble is that #error causes cpplib's parse_in.errors to be
> bumped, but that doesn't propagate back to errorcount until
> cpp_finish() is called, from c_common_finish.
> 
> We can't just change that line you quoted to
> 
>   if (errorcount || sorrycount || cpp_errors (&parse_in))
> 
> because that will screw over non-C front ends.  Ideas?

Merge the diagnostic handlers.

Neil.

Re: tree-ssa-cvs corrupt

[Zack Weinberg]

Neil Booth <neil@daikokuya.co.uk> writes:

> Zack Weinberg wrote:-
>> The trouble is that #error causes cpplib's parse_in.errors to be
>> bumped, but that doesn't propagate back to errorcount until
>> cpp_finish() is called, from c_common_finish.
>
> Merge the diagnostic handlers.

A good idea, but I'm beginning to worry about cpplib ceasing to be
useful as a standalone library.  I already have plans for using it
independently, and there's a project called 'synopsis' that wants
it too...

zw

Re: tree-ssa-cvs corrupt

[Neil Booth]

Zack Weinberg wrote:-

> A good idea, but I'm beginning to worry about cpplib ceasing to be
> useful as a standalone library.  I already have plans for using it
> independently, and there's a project called 'synopsis' that wants
> it too...

Why?  It would still do all the meat; and it could provide its own
default handlers.

Neil.

Re: tree-ssa-cvs corrupt

[Zack Weinberg]

Neil Booth <neil@daikokuya.co.uk> writes:

> Zack Weinberg wrote:-
>
>> A good idea, but I'm beginning to worry about cpplib ceasing to be
>> useful as a standalone library.  I already have plans for using it
>> independently, and there's a project called 'synopsis' that wants
>> it too...
>
> Why?  It would still do all the meat; and it could provide its own
> default handlers.

I'm probably over-worrying.  This is not something I'm going to get to
anytime soon, as I want to concentrate on performance issues right
now; go ahead and do the patch and then let's discuss stuff like this.

For the record, though, the thing I want to do as soon as cpplib moves
to its own directory is write a simple 'makedepend' clone around that
-- and use it to autogenerate header-file dependencies for the gcc
subdirectory.  Diagnostics are not critical for this, but recognizing
command line options *might* be (haven't thought it through yet).

zw

Re: tree-ssa-cvs corrupt

[Gabriel Dos Reis]

Zack Weinberg <zack@codesourcery.com> writes:

| Neil Booth <neil@daikokuya.co.uk> writes:
| 
| > Zack Weinberg wrote:-
| >> The trouble is that #error causes cpplib's parse_in.errors to be
| >> bumped, but that doesn't propagate back to errorcount until
| >> cpp_finish() is called, from c_common_finish.
| >
| > Merge the diagnostic handlers.
| 
| A good idea, but I'm beginning to worry about cpplib ceasing to be
| useful as a standalone library. 

Not just because cpplib uses diagnostic.[ch] means it would cease being
a standalone library.  Improvement may be applied to both sides.

-- Gaby

Re: tree-ssa-cvs corrupt

[Geoff Keating]

Zack Weinberg <zack@codesourcery.com> writes:

> Neil Booth <neil@daikokuya.co.uk> writes:
> 
> > Zack Weinberg wrote:-
> >> The trouble is that #error causes cpplib's parse_in.errors to be
> >> bumped, but that doesn't propagate back to errorcount until
> >> cpp_finish() is called, from c_common_finish.
> >
> > Merge the diagnostic handlers.
> 
> A good idea, but I'm beginning to worry about cpplib ceasing to be
> useful as a standalone library.  I already have plans for using it
> independently, and there's a project called 'synopsis' that wants
> it too...

Perhaps cpplib could add some callbacks to inform its caller of
errors, and have the caller print the actual message?  A
general-purpose library really shouldn't be dumping stuff to stderr
anyway.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: tree-ssa-cvs corrupt

[Neil Booth]

Geoff Keating wrote:-

> Zack Weinberg <zack@codesourcery.com> writes:
> 
> > Neil Booth <neil@daikokuya.co.uk> writes:
> > 
> > > Zack Weinberg wrote:-
> > >> The trouble is that #error causes cpplib's parse_in.errors to be
> > >> bumped, but that doesn't propagate back to errorcount until
> > >> cpp_finish() is called, from c_common_finish.
> > >
> > > Merge the diagnostic handlers.
> > 
> > A good idea, but I'm beginning to worry about cpplib ceasing to be
> > useful as a standalone library.  I already have plans for using it
> > independently, and there's a project called 'synopsis' that wants
> > it too...
> 
> Perhaps cpplib could add some callbacks to inform its caller of
> errors, and have the caller print the actual message?  A
> general-purpose library really shouldn't be dumping stuff to stderr
> anyway.

That's what I meant by merging the diagnostics.

Neil.

Re: tree-ssa-cvs corrupt

[Richard Henderson]

On Fri, Jan 03, 2003 at 11:29:12AM -0500, Diego Novillo wrote:
> This one is on purpose.  I added an explicit syntax error to
> avoid blowing up memory usage.

Might consider using #error instead.  ;-)


r~

Re: tree-ssa-cvs corrupt

[Richard Henderson]

On Mon, Jan 06, 2003 at 05:31:17PM -0800, Richard Henderson wrote:
> Might consider using #error instead.  ;-)

Boy am I behind....


r~

Re: tree-ssa-cvs corrupt

[Diego Novillo]

On Mon, 06 Jan 2003, Richard Henderson wrote:

> On Fri, Jan 03, 2003 at 11:29:12AM -0500, Diego Novillo wrote:
> > This one is on purpose.  I added an explicit syntax error to
> > avoid blowing up memory usage.
> 
> Might consider using #error instead.  ;-)
> 
You *really* should read the rest of the thread :)


Diego.

Re: tree-ssa-cvs corrupt

[Neil Booth]

Bonzini wrote:-

> Also, wouldn't doing errorcount++ make it work well enough for tree-ssa's
> needs?

errorcount is not linked into cpplib's image.  This issue vanishes
once cpplib uses the client's supplied diagnostic routines.

Neil.

Re: tree-ssa-cvs corrupt

[Bonzini]

> Yeah, #error should stop compilation like the standard requires.  I've
> never gotten round to fixing it.  CPP would need a way to stop it lexing
> any more tokens (not too hard), and a way to signal to the front end to
> not do any more work.

Probably a stupid answer... but to quote Zack "A distant voice on the wind
whispers longjmp..." :-)

Also, wouldn't doing errorcount++ make it work well enough for tree-ssa's
needs?

|_  _  _ __
|_)(_)| ),'
------- '---

Re: tree-ssa-cvs corrupt

[Jason Merrill]

On Fri, 03 Jan 2003 17:06:16 +0100, Andreas Jaeger <aj@suse.de> wrote:

> Jason,
>
> it seems that your latest patch to the tree-ssa branch has corrupted
> the testsuite.
>
> I got lots of failures in the testsuite due to missing first characters.
>
> Note the missing "/" at the beginning of the line:
> arthur:/cvs/gcc-tree-ssa-20020619-branch/gcc/testsuite/gcc.c-torture/compile:[0]
> $ head 20001226-1.c
> * This testcase exposed two branch shortening bugs on powerpc.  */

Diego removed the initial "/" from that testcase on 25 November, so that
the test would fail immediately with a syntax error rather than after
eating tens of minutes of CPU time.  What other testcases are you having
trouble with?

Jason