This is the mail archive of the gcc-regression@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: new FAILs on HEAD


On Tue, Jan 13, 2004 at 12:13:23PM +0100, Arnaud Charlet wrote:
> > If you send me brief instructions how to manually compile that testcase, I can
> > try to run the command and capture the output. From there I can start to debug
> > the crash and at least get a backtrace from gcc. Maybe this is some kind of
> > uninitialized variable that only wreaks havoc for this particular amount of
> > RAM (256M) I have in the machine due to GC happening at an unfavourable time.
> 
> I have added more traces in the acats.log file, where this info is
> now logged (extra compilation command used). I'll also add a few more
> checks against other kind of errors (e.g. file system or kernel errors causing
> creation or change of directory to fail).

I just got my hands on a compiler that had previously FAILed the test.  I
manually built and ran the test with the same compiler that reported the FAIL
and it passed repeatedly.

Now, this is wierd: The log says
PASS:   cd90001
BUILD
FAIL:   cd92001
splitting /usr/gcc/compile/gcc/HEAD/gcc/testsuite/ada/acats/tests/cd/cd92001.a into:
   cd92001.adb
splitting /usr/gcc/compile/gcc/HEAD/gcc/testsuite/ada/acats/tests/cd/cda201a.ada into:
   cda201a.adb
BUILD cda201a.adb

that's all. I didn't look closely at your script, but what I notice is that
1/ the FAIL is output even before the splitting is done
2/ there is no filename after "BUILD" on the line before the fail.

I assume that the "BUILD" line mentioned in 2/ is output by line 209 of
run_all.sh. So that means that $main is empty at this time.
This fits nicely with lines 217-222 that output "FAIL" if $main is empty.

The things I don't understand
1/ why is it splitting the file only after outputting the FAIL. It should
have happened on line 203 if I'm correct.
2/ why is this apparently nondeterministic?

I will upgrade the system to the latest debian unstable. Maybe it was an error
in bash that has been fixed since my last upgrade.

If that doesn't help, I will try "set -x" in run_all.sh.

Michael


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]