[Bug testsuite/31846] New: Logs are not being parsed correctly by testsuite and "test_summary" scripts.

[Bug testsuite/31846] New: Logs are not being parsed correctly by testsuite and "test_summary" scripts.

[rob1weld at aol dot com]

In the first place the .log files are not being created correctly by the
testsuite in all cases.

This results in the "test_summary" script failing to mail all the errors that
could be reported.


Problem 1):

The boehm-gc tests are not included by the "test_summary", script (and never
were previously, to my recolection).

This is likely because "make -i check" does not create a .log file (but does
test boehm-gc). I saved the screen output and here is what I see:


make[3]: Leaving directory
`/opt/gcc-4_2-build/i686-pc-linux-gnu/boehm-gc/include'
make[3]: Entering directory `/opt/gcc-4_2-build/i686-pc-linux-gnu/boehm-gc'
/bin/sh ./libtool --mode=link /opt/gcc-4_2-build/./gcc/xgcc
-B/opt/gcc-4_2-build/./gcc/ -B/usr/i686-pc-linux-gnu/bin/ -$
/opt/gcc-4_2-build/./gcc/xgcc -B/opt/gcc-4_2-build/./gcc/
-B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ -$
tests/test.o: In function `mktree':
/root/downloads/gcc-4_2-branch/boehm-gc/tests/test.c:798: undefined reference
to `GC_local_malloc'
/root/downloads/gcc-4_2-branch/boehm-gc/tests/test.c:807: undefined reference
to `GC_local_malloc_atomic'
tests/test.o: In function `local_cons':
/root/downloads/gcc-4_2-branch/boehm-gc/tests/test.c:264: undefined reference
to `GC_local_malloc'
/root/downloads/gcc-4_2-branch/boehm-gc/tests/test.c:267: undefined reference
to `GC_local_gcj_malloc'
collect2: ld returned 1 exit status
make[3]: [gctest] Error 1 (ignored)
make "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CFLAGS=-O2 -g -O2 " "CXXFLAGS=-g -O2 
-D_GNU_SOURCE" "CFLAGS_FOR_BUILD=-g -O2" "$
make[4]: Entering directory `/opt/gcc-4_2-build/i686-pc-linux-gnu/boehm-gc'
/bin/sh ./libtool --mode=link /opt/gcc-4_2-build/./gcc/xgcc
-B/opt/gcc-4_2-build/./gcc/ -B/usr/i686-pc-linux-gnu/bin/ -$
/opt/gcc-4_2-build/./gcc/xgcc -B/opt/gcc-4_2-build/./gcc/
-B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ -$
tests/test.o: In function `mktree':
/root/downloads/gcc-4_2-branch/boehm-gc/tests/test.c:798: undefined reference
to `GC_local_malloc'
/root/downloads/gcc-4_2-branch/boehm-gc/tests/test.c:807: undefined reference
to `GC_local_malloc_atomic'
tests/test.o: In function `local_cons':
/root/downloads/gcc-4_2-branch/boehm-gc/tests/test.c:264: undefined reference
to `GC_local_malloc'
/root/downloads/gcc-4_2-branch/boehm-gc/tests/test.c:267: undefined reference
to `GC_local_gcj_malloc'
collect2: ld returned 1 exit status
make[4]: [gctest] Error 1 (ignored)
/bin/sh: line 8: /root/downloads/gcc-4_2-branch/boehm-gc/gctest: No such file
or directory
FAIL: gctest
===================
1 of 1 tests failed
===================
make[4]: [check-TESTS] Error 1 (ignored)
make[4]: Leaving directory `/opt/gcc-4_2-build/i686-pc-linux-gnu/boehm-gc'


Problem 2):

The testsuite scripts fails in the parsing of the libstdc+-v3 .log file.

There is some breakage in grabbing the .log file that results in the compiler
output filling up part of the logs. 

The other difficulty is that the "expect" is unprepared for the "libstdc++-v3
check-abi Summary". It's final output is in a format that seems compatable with
the "test_summary" script but it's result is not included in mail to
gcc-testresults@gcc.gnu.org .

Here is what it looks like in
i686-pc-linux-gnu/libstdc++-v3/testsuite/libstdc++.log :

                === libstdc++-v3 check-abi Summary ===

# of added symbols:              114
# of missing symbols:            46
# of incompatible symbols:       92


My last "make -i check" (with notes at the end) is here:
http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00314.html


-- 
           Summary: Logs are not being parsed correctly by testsuite and
                    "test_summary" scripts.
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: testsuite
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: rob1weld at aol dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31846

[Bug testsuite/31846] Logs are not being parsed correctly by testsuite and "test_summary" scripts.

[rob1weld at aol dot com]

------- Comment #1 from rob1weld at aol dot com  2007-05-18 03:57 -------
A recent compile of 4.2.1 with complaints about log file parsing at the end is
here: http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00812.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31846

[Bug testsuite/31846] Logs are not being parsed correctly by testsuite and "test_summary" scripts.

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2007-05-18 04:13 -------
(In reply to comment #1)
> A recent compile of 4.2.1 with complaints about log file parsing at the end is
> here: http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00812.html

I bet you are using a bad expect which can cause some failures to show up when
they are not failures.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31846

[Bug testsuite/31846] Logs are not being parsed correctly by testsuite and "test_summary" scripts.

[rob1weld at aol dot com]

------- Comment #3 from rob1weld at aol dot com  2007-05-26 19:17 -------
# runtest --version
Expect version is       5.43.0
Tcl version is          8.4
Framework version is    1.4.99


I use Debian GNU/Linux. That version is the newest that "apt-get update",
"apt-get upgrade" will pull.

I _definately_ do NOT want to be submitting false reports and driving people
crazy trying to track down the trouble ...


Would it be an idea to have a new testsuite to produce "WARNING" lines that
listed the version of the tools used in the tests. EG: tcl dejagnu expect ...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31846

[Bug testsuite/31846] Logs are not being parsed correctly by testsuite and "test_summary" scripts.

[manu at gcc dot gnu dot org]

------- Comment #4 from manu at gcc dot gnu dot org  2010-02-20 21:56 -------
Rob, this is very old. Is it still a problem?


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu dot org
             Status|UNCONFIRMED                 |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31846

[Bug testsuite/31846] Logs are not being parsed correctly by testsuite and "test_summary" scripts.

[rob1weld at aol dot com]

------- Comment #5 from rob1weld at aol dot com  2010-04-12 02:23 -------
(In reply to comment #4)
> Rob, this is very old. Is it still a problem?

Thank you kindly for being the one to reply to my Report.

Due to the fact that it often takes a year for some replies, and in this case
three years, I am working with another group that is producing a free Operating
System rather than sitting idle.

It is _great_ of you to go through these old reports and try to close (resolve)
them. I have done that job previously and know that sometimes it can be
frustrating.

Some three years later we might expect I am unable to assist further and might
focus my efforts where they are more productive.

Thanks,
Rob


Reporter:  Changing status from "Waiting" to "New" (since I can not choose
"Old") and you are welcome to change the Resolution to "Wontfix" (since you can
not choose "Abandoned"). :)


-- 

rob1weld at aol dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |UNCONFIRMED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31846

[Bug testsuite/31846] Logs are not being parsed correctly by testsuite and "test_summary" scripts.

[manu at gcc dot gnu dot org]

------- Comment #6 from manu at gcc dot gnu dot org  2010-04-12 06:41 -------
(In reply to comment #5)
> 
> Some three years later we might expect I am unable to assist further and might
> focus my efforts where they are more productive.

Sorry about that. I totally understand your frustration. Lack of resources and
focus on the most visible/severe bugs explain in part the appearance of
inaction.The time delay totally depends on the bug.


Thanks anyway for the report and sorry again.


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WORKSFORME


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31846