egcs-1.1.2 build/test results for i586-linux-gnu

[Joseph Parmelee <jparmele at wildbear dot com>]

Environ:    Intel pentium 133
            glibc-2.0.7pre6
            binutils-2.9.1.0.15
            Linux kernel 2.0.30
            dejagnu-971222
            libg++-2.8.1.3

This machine has gcc-2.7.2.2/libc-5.4.46/binutils-2.8.1.0.1 as the default
installation.  Egcs-1.1.2/glibc-2.0.7pre6/binutils-2.9.1.0.15 was installed
under --prefix=/usr/i586-linuxglibc2 as an alternate system in preparation
for updating to a dual-development system running on Linux 2.2.

Necessary environment overrides to accomplish this non-standard build were
passed in on the make command line in shell scripts.

Configure/make problems discovered and overcome:

"make install" installs libg2c.a and symbolic links libg++.so and libg++.a
in /usr/i586-linuxglibc2/lib/gcc-lib/i586-linuxglibc2 instead of in
/usr/i586-linuxglibc2/lib/gcc-lib/i586-linuxglibc2/egcs-2.91.66.  Our
install shell script moves them after installation.

libg++ configure sets a symbolic link from src/rx.h to /usr/include/rx.h,
which is a libc5 header in our configuration.  This had to be overridden in
a script file to point the link at /usr/i586-linuxglibc2/include/regex.h to
get libg++ to pick up the new headers.  Otherwise, as expected, libg++
builds but crashes totally on execute tests.  Our configure script first
runs configure, then makes the configure-target-libg++ target, then corrects
the errant link which that configure produces.

It really would be much more convenient to do all the configures at the
outset so that problems with the Makefiles can be seen and corrected before
a lot of compile time is burned.  This one change would have saved me
personally at least a week in this whole process.  This "make it all at
once" thing tries to be too smart for its own good.  It ends up being a real
nuisance when something doesn't work as expected.

Template instantiation did not fully occur because of interface and/or
implement #pragma directive problems in the libstdc++ code.  Enabling the
-fexternal-template option gives a printout of the problems.  A quick fix to
get all templates (with some multiple instantiation) is to override the
-fno-implicit-templates option by specifying LIBCXXFLAGS on the make command
line.  Otherwise, libstdc++ is missing two template variables, and one
template function:

    __default_alloc_template<true,0>::__node_allocator_lock
    __default_alloc_template<true,0>::free_list
    __default_alloc_template<true,0>::refill(unsigned int)


check-gcc:  We observed the usual errors:

    gcc.c-torture/execute/980526-1.c execution,  -O2 -fomit-frame-pointer
    -finline-functions
    gcc.c-torture/execute/ieee/980619-1.c execution,  -O1
    gcc.c-torture/execute/ieee/980619-1.c execution,  -O2
    gcc.c-torture/execute/ieee/980619-1.c execution,  -O2 -fomit-frame-pointer
    -finline-functions
    gcc.c-torture/execute/ieee/980619-1.c execution,  -O2 -fomit-frame-pointer
    -finline-functions -funroll-loops
    gcc.c-torture/execute/ieee/980619-1.c execution,  -O2 -fomit-frame-pointer
    -finline-functions -funroll-all-loops
    gcc.c-torture/execute/ieee/980619-1.c execution,  -O2 -g
    gcc.c-torture/execute/ieee/980619-1.c execution,  -Os
    gcc.dg/980626-1.c (test for excess errors)

These are caused either by improper optimizations run canonically by the
c-torture series or by problems with the test harness (980626-1).  They
don't appear to actually indicate a failure in gcc.


    gcc.dg/clobbers.c execution test

There seems to be some confusion as to just what the asm clobbers feature is
supposed to do.  I would prefer that asm clobbers informed the compiler that
the asm block modifies registers (or memory) other than those appearing
explicitly as output arguments (which should always be assumed clobbered). 
Whoever wrote the clobbers test obviously had the same notion.  The test
confirms that asm clobbers, under that definition, remain broken.


check-g++:  1 unexpected failure:

    g++.mike/p6610a.C  Execution test

This appears to be a real bug.  The executable should return 0 status; it
returns 1, indicating the struct B constructor either didn't run at all,
picked up the wrong version of the f member function, or the wrong this
pointer.


check-g77:  All tests passed.


check-target-libstdc++:  All tests passed.


check-target-libio:  1 unexpected failure:

    tfformat.c  Execution test
    Fails 1955 of 3989 tests

This test sprintf's floating arguments with lots of digits, sscanf's them
back, and compares with the original binary argument.  These failures are
the result of discrepancies in the least significant bit.

This appears to be a real bug.  When the tfformat.c program is linked
directly against the libio in glibc, it passes.  Even more interesting is
linking it against the newly-built libstdc++ (without libio.a); libstdc++
only supplies the data element _IO_stderr_; the code elements _IO_fprintf,
_IO_sprintf, and _IO_sscanf are still being supplied by glibc. 
Nevertheless, the test fails here also.  To make matters even wierder, only
201 of these failures remain after that same libstdc++ is installed and the
test run again.  All of the 201 remaining errors involve improper rounding
of small numbers to zero.

When this set of tests is performed on the old libc5 system, they all pass.

We also saw this problem with egcs-1.1.1.

Is this behavior indicative of an uninitialized floating point control word? 
Are others seeing this problem?  Any idea what this is about?

Please CC me directly as I am not subscribed to the list.


Regards,

Joe Parmelee
Wild Bear Systems
jparmele@wildbear.com