armv4l bootstrap problem in libstdc++-v3
Wed Jan 10 10:38:00 GMT 2001
: It is with some reluctance that I am committing the following patch.
: My reasons for doing so are as follows:
: 1) Building the ARM compiler has been broken because of this for over a
: month now
: 2) There is no apparent sign that a patch for the C++ front end is
: forthcoming from a C++ mainatiner, even though the bug lies there and not
: in the ARM back-end.
: 3) I have insufficient understanding of the tree system to fix the front
: end myself, or, given the anticipated time-scales for the release, time to
: acquire that knowledge.
: Given that we have a major release coming up, to remain in this state is
: unacceptable. So I've decided that we will have to disable the XScale
: builtins until such time as the problem is fixed -- at this point I
: consider being able to build and install the C++ libraries more important
: than supporting the newlib builds for Xscale (which I believe will now
: fail as a result of this).
Isn't the cause of this problem the one that I outlined in my post
which describes the cause as:
[...] the problem is that the type hashing function used in tree.c
does not take into account the fact that C++ uses the unsigned_flag
field in the tree node of the first parameter in a list to indicate
a parameter list instead of an expression list.
This means that when arm_init_builtins() creates a "void (char *)"
function type (without the TREE_PARMLIST bit set on its arguments)
this type is cached. Then later on when the G++ compiler is
compiling strstream.cc it sees the declaration of _M_free, creates
another "void (char *)" type for it (but this time with
TREE_PARMLIST set), passes this to build_function_type, which hashes
it, matches the type created by arm_init_builtins, and so returns
the older type, now with TREE_PARMLIST unset.
There has been some discussion by the C++ guys, but I do not know if a
fix was ever committed to the sources. My post did contain a
workaround, but that was never applied either.
: I have tried to produce, but have been unsuccessful, a test case which
: causes a similar problem with one of the standard built-ins. This
: probably means I still don't fully understand the failure fully.
In theory any builtin which has a type of "void (char *)" should
trigger this problem. Or in fact any backend created builtin with a
type that matches the type of a C++ builtin function.
More information about the Libstdc++