This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: armv4l bootstrap problem in libstdc++-v3
- To: Nick Clifton <nickc at redhat dot com>
- Subject: Re: armv4l bootstrap problem in libstdc++-v3
- From: Richard Earnshaw <rearnsha at arm dot com>
- Date: Wed, 10 Jan 2001 18:50:30 +0000
- Cc: stewart at nexus dot carleton dot ca, bkoz at redhat dot com, jason at redhat dot com, mark at codesourcery dot com, stewart at netwinder dot org, gcc-bugs at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org
- Cc: rearnsha at arm dot com
- Organization: ARM Ltd.
- Reply-To: rearnsha at arm dot com
> 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
Yes, but it would appear that that wasn't acceptable to the C++
maintainers.
> 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.
Indeed. I cannot force someone else to fix the problem, and if they won't
accept your patch either, there is very little I can do at this point in
time -- I have neither the knowledge to fix the problem quickly nor the
time to work out what would need to be done to fix it along the lines
suggested.
Most importantly I don't believe we can leave the ARM tree in a
non-bootable state any longer, give the impending release -- we really
need to test and fix other things, which isn't possible if the C++
libraries won't build out of the box. I'm disappointed that it has come
to this, but it is out of my control.
> : 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.
Unfortunately, no other port has a builtin with that signature, and when I
attempted to build a test case with the same signature as say, ffs or
memcopy, the code compiled correctly. So I've either mis-understood the
problem, or I've missed something subtle. If someone can devise a test
case that demonstrates the bug, that would be ideal -- we could then check
it into the test suite and the automated test system could whinge about it
until it were fixed.
R.