egcs fails to build libio
Byeong-ryeol Kim
jinbo21@soback.kornet21.net
Tue Dec 22 10:17:00 GMT 1998
On Tue, 22 Dec 1998, Franz Sirl wrote:
...
> At 12:38 22.12.98 , Horst von Brand wrote:
> >Richard Ketchersid <ketchers@math.berkeley.edu> said:
> >> Here is what happens while trying to compile libio.
> >> This has happened for the last few snapshots, at least since egcs-2.92.28.
> >> ========================================================================
> >>
> >> test x"yes" != xyes || \
> >> /usr/src/BUILD/egcs/gcc/xgcc -B/usr/src/BUILD/egcs/gcc/
> >> -B/usr/i486-pc-linux-gnu/bin/ -c -D_GNU_SOURCE -g1 -pipe -O2
> >> -fvtable-thunks -fvtable-thunks -D_GNU_SOURCE -fno-implicit-templates
> >> -I. -I/usr/src1/CVS/EGCS/egcs/libio -nostdinc++ -D_IO_MTSAFE_IO
> >> -fpic /usr/src1/CVS/EGCS/egcs/libio/builtinbuf.cc -o pic/builtinbuf.o
> >> In file included from /usr/include/bits/stdio-lock.h:20,
> >> from /usr/src1/CVS/EGCS/egcs/libio/libio.h:166,
> >> from /usr/src1/CVS/EGCS/egcs/libio/streambuf.h:36,
> >> from /usr/src1/CVS/EGCS/egcs/libio/builtinbuf.h:32,
> >> from /usr/src1/CVS/EGCS/egcs/libio/builtinbuf.cc:29:
> >> /usr/include/pthread.h:451: Internal compiler error.
...
> >> cpp: output pipe has been closed
> >> make: *** [builtinbuf.o] Error 1
> >
> >Exactly what I see in i586-linux-gnu, glibc-2.0.108, binutils-2.9.1.0.19a,
> >linux-2.1.131ac13. The failure happens with, eg:
> >
> >extern void *f(unsigned int) throw();
>
> Hmm, I get a similar failure (reported ~1 week ago) on glibc-2.0.106
> powerpc-unknown-linux-gnu. The core dump showed that cpp crashed in
> fileno_unlocked, because fileno_unlocked was handed a NULL (? no longer
> 100% sure about that) pointer. I thought cpp got miscompiled on PPC cause
> the contruct looked so simple: fileno(stdout). But now I'm no longer sure
> about that.
....
I currently using kernel-2.1.131ac13, glibc-2.0.108, egcs-1.1.1(patched
with HJL's latest libgcc.map patch), binutils-2.9.1.0.19a,
autoconf-2.12.2(cvs version), libg++-2.8.1.2a-19981218 on Pentium MMX
166 box with 64 MB EDO RAM.(if necessary, ASUS P/I-P55T2P4 rev. 3.10,
BIOS 0207, Quantumn F/B 1.28G and 5.1G HDD)
I saw partly the same result as above report plus subsequent 2 more
error after modifying 434, 435 line of pthread.h.(Here I merely cut &
pasted relevant passages. Please, note that I used '-O9' as usual in
compiling egcs.)
....
test x"yes" != xyes || \
/usr/src/redhat/BUILD/obj-egcs-19981220/gcc/xgcc
-B/usr/src/redhat/BUILD/obj-e
gcs-19981220/gcc/ -B/home/jinbo21/egcs/i586-pc-linux-gnu/bin/ -c -O9
-mcpu=pentium -march=pentium -fomit-frame-pointer -pipe -fvtable-thunks
-D_GNU_SOURCE -fno-implicit-templates -I. -I../../../egcs-19981220/libio
-nostdinc++ -D_IO_MTSAFE_IO -fpic
../../../egcs-19981220/libio/parsestream.cc -o pic/parsestream.o
In file included from ../../../egcs-19981220/libio/parsestream.cc:32:
/usr/include/stdlib.h:470: Internal compiler error.
....
/usr/src/redhat/BUILD/obj-egcs-19981220/gcc/xgcc
-B/usr/src/redhat/BUILD/obj-egcs-19981220/gcc/
-B/home/jinbo21/egcs/i586-pc-linux-gnu/bin/ -c -O9 -mcpu=pentium
-march=pentium -fomit-frame-pointer -pipe -fvtable-thunks -D_GNU_SOURCE
-fno-implicit-templates -I. -I../../../egcs-19981220/libio -nostdinc++
-D_IO_MTSAFE_IO -fpic ../../../egcs-19981220/libio/builtinbuf.cc -o
pic/builtinbuf.o
from ../../../egcs-19981220/libio/libio.h:166,
from ../../../egcs-19981220/libio/streambuf.h:36,
from ../../../egcs-19981220/libio/builtinbuf.h:32,
from ../../../egcs-19981220/libio/builtinbuf.cc:29:
/usr/include/pthread.h:434: Internal compiler error.
...
/usr/src/redhat/BUILD/obj-egcs-19981220/gcc/xgcc
-B/usr/src/redhat/BUILD/obj-egcs-19981220/gcc/
-B/home/jinbo21/egcs/i586-pc-linux-gnu/bin/ -c -O9 -mcpu=pentium
-march=pentium -fomit-frame-pointer -pipe -fvtable-thunks -D_GNU_SOURCE
-fno-implicit-templates -I. -I../../../egcs-19981220/libio -nostdinc++
-D_IO_MTSAFE_IO -fpic ../../../egcs-19981220/libio/parsestream.cc -o
pic/parsestream.o
In file included from /usr/include/stdlib.h:488,
from ../../../egcs-19981220/libio/parsestream.cc:32:
/usr/include/alloca.h:33: Internal compiler error.
....
This problem is similar to that which appeared 2-3 month ago between
glibc-2.0.95(6?) and egcs devel version, when glibc-2.0.95(6?)
changed its code of libio to fully support execption handling. But,
the differnece is that this probelm comes first from egcs part.
I could compile egcs-2.92.32(19981220 ss) by modifying relevant
part of /usr/include/{pthread,stdlib,alloca}.h.
It was simple. Just to replace '__P' to '__PMT' at lines above
mentioned will do. Of course, it is not for practical use, it was done
only for compiler's sake as a experiment.
BTW, I want to know more deeply about this problem and true
causes and solution.
So, I read ChangeLogs of egcs-19981220, and compare important files such
as stddef.h or so, but I didn't find out something remarkable except
following passage and 'typeinfo'
...
Wed Dec 16 17:30:35 1998 Nick Clifton <nickc@cygnus.com>
* toplev.c (main): Disable optimize_size if a specific
optimization level is requested. Always set optimization
level to 2 if -Os is specified.
...
--- /usr/lib/gcc-lib/i586-pc-linux-gnu/egcs-2.91.60/include/typeinfo
Wed Dec 16 04:24:32 1998
+++
/home/jinbo21/egcs/lib/gcc-lib/i586-pc-linux-gnu/egcs-2.92.32/include/typein
fo Tue Dec 22 05:41:18 1998
@@ -1,5 +1,5 @@
// RTTI support for -*- C++ -*-
-// Copyright (C) 1994, 1995, 1996 Free Software Foundation
+// Copyright (C) 1994, 95-97, 1998 Free Software Foundation
#ifndef __TYPEINFO__
#define __TYPEINFO__
@@ -10,9 +10,7 @@
extern "C++" {
-#ifdef __HONOR_STD
namespace std {
-#endif
class type_info {
private:
@@ -21,7 +19,7 @@
type_info (const type_info&);
protected:
- type_info (const char *n): _name (n) { }
+ explicit type_info (const char *n): _name (n) { }
const char *_name;
@@ -54,9 +52,7 @@
virtual ~bad_typeid () { }
};
-#ifdef __HONOR_STD
} // namespace std
-#endif
} // extern "C++"
#endif
....
These change is not documented well. Moreover, changes of 'typeinfo'
seems not to documented at all.(I recall '__HONOR_STD' was not the
default before egcs-2.92.32 due to instability of SGI STL code, but it
seems to be unconditional at the side of egcs, and accordingly
compells various C++ applications to use namespaces compliant
libstdc++-2.9.x now)
And, features.h of glibc-2.0.8 defines '__USE_EXTERN_INLINES__' as
follows:
...
/* Decide whether we can define 'extern inline' functions in headers.
*/
#if defined __GNUC__ && (__GNUC__ > 2 || __GNUC__ == 2 && __GNUC_MINOR__
>= 7)\
&& defined __OPTIMIZE__ && !defined __OPTIMIZE_SIZE__
# define __USE_EXTERN_INLINES 1
#endif
...
Here, I tended to be suspicious about 'optimize_size' change
of egcs-2.92.32, and tested 2 cases as follows:
First, I tried to compile builtinbuf.cc without optimization, but the
result was the same.(failure)
I did 'make -k check-targe-libio' after inserting similar macro
to above example into /usr/include/{pthread,stdlib,alloca}.h and
replacing '-O2'(or -O9) with '-Os' in egcs-19981220/gcc/libio/Makefile
as a experiment.
For example,
...
#if defined __OPTIMIZE__ && !defined __OPTIMIZE_SIZE__
extern __ptr_t malloc __PMT ((size_t __size));
#else
extern __ptr_t malloc __P ((size_t __size));
#endif
...
It seems to work now. the results of 'make -k check' was as usual.
But, if I removed the inserted macro defines(ie., restored orinal header
files) and used only '-Os', egcs-2.92.32 could not pass testsuites of
libio and libg++, g++ successfully.(results of gcc, g77, libobjc were
not affected by any case. This problem ocurrus in relation with libio,
libstdc++, libg++)
In short, the result of g++ tests as follows:
........................................................................
1. a case of success after relevant header files of glibc-2.0.108
=== libio Summary ===
# of expected passes 40
=== libstdc++ Summary ===
# of expected passes 30
=== libg++ Summary ===
# of expected passes 72
=== gcc Summary ===
# of expected passes 4782
# of unexpected failures 4
# of unexpected successes 1
# of expected failures 86
# of untested testcases 7
=== g++ Summary ===
# of expected passes 4782
# of unexpected failures 4
# of unexpected successes 1
# of expected failures 86
# of untested testcases 7
=== g77 Summary ===
# of expected passes 465
=== objc Summary ===
# of unexpected failures 19
# of untested testcases 19
/usr/src/redhat/BUILD/obj-egcs-19981220/gcc/testsuite/../xgcc version
egcs-2.92.32 19981220 (gcc2 ss-980609 experimental)
2. a case of failed test with orignal header files of glibc-2.0.108
=== libio Summary ===
# of expected passes 7
# of unexpected failures 11
# of expected failures 22
=== libstdc++ Summary ===
# of expected passes 6
# of unexpected failures 8
# of expected failures 16
=== libg++ Summary ===
# of expected passes 15
# of unexpected failures 19
# of expected failures 38
=== gcc Summary ===
# of expected passes 7811
# of unexpected failures 28
# of expected failures 13
# of unsupported tests 12
=== g++ Summary ===
# of expected passes 4674
# of unexpected failures 64
# of unexpected successes 1
# of expected failures 85
# of untested testcases 7
=== g77 Summary ===
# of expected passes 465
=== objc Summary ===
# of unexpected failures 19
# of untested testcases 19
/usr/src/redhat/BUILD/obj-egcs-19981220/gcc/testsuite/../xgcc version
egcs-2.92.32 19981220 (gcc2 ss-980609 experimental)
.......................................................................
Anyhow, I temporarily concluded as follows:
1. Latest egcs is trying to more strictly compliant to ISO C9X,
and transient conflicts between glibc2 and egcs has exposed.
But, I dont't know current changes of egcs-2.92.32 is accurate and
adequate, though it seems to go to the accurate direction in rough
sense.
2. Even before more thourough solution comes out, a workaround
would be helpful. I hope a macro, ie., '__GNUC_TEENY__' as is
similar thing in XFree86's linux.cf, would be helpful in such
transient situation. If such thing is present, above situation
is easy to sove. Just to change above relevant codes to
#if defined __GNUC__ && (__GNUC__ >= 2 && \
__GNUC_MINOR__ >= 92 && __GNUC_TEENY__ >= 32))'
extern ... __PMT((...));
#else
extern ... __P ((...));
#endif
would be temporarily helpful workaround.
3. I didn't test whether egcs-2.92.32 could compile successfully and
pass given testsuites ok or not, if we configured it without
'--enable-threads' and used only '-Os'
4. It might be the time for glibc-2.0.109 to be born. :-)
PS: I didn't try to compile anything with newly compiled egcs-2.92.32.
So, it woulnd't be the time for me to say it is good or not.
--
"Where there is a will, there is a way." jinbo21@soback.kornet21.net
kbeyl@kids.kotel.co.kr
For the future of you and me! hitel: jinbo21
More information about the Libc-alpha
mailing list