Re: armv4l bootstrap problem in libstdc++-v3

[Nick Clifton <nickc at redhat dot com>]

Hi Richard,

: 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
last month:

  http://gcc.gnu.org/ml/gcc-bugs/2000-12/msg00461.html

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.

Cheers
	Nick