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

[Manfred Hollstein]

On Thu, 18 March 1999, 02:10:15, jparmele@wildbear.com wrote:

 > 
 > 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.

How did you actually call 1. configure and 2. make?

 > 
 > libg++ configure sets a symbolic link from src/rx.h to /usr/include/rx.h,
 > which is a libc5 header in our configuration.

This is indicating you're using a wrong CC/CXX when calling configure.

 > 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.

I wouldn't say, the scripts are fool-proof, but most of the time
such errors occur in "home-brew" mixed Linux/GNU systems with more than
one libc but not the proper cross compilers.

 > 
 > 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
 > 
 > 
 >