I think I would stop right there. Why can't the i370 port support
64-bit integers? Plenty of 32-bit hosts support them.
It got an internal error. I don't have the skills to get that to work,
but I do have the skills to bypass it one way or another (and I
demonstrated what I am doing now, but I know that that
intrusive code will break everything else, so want to back it out,
without losing the functionality that I want).
A failure in your target is not a reason to change target-independent
code.
Well I found out what was causing this - the adddi3 definition.
Commenting that out allowed the target to be built the normal
way.
However, when doing the host build, I wanted everything done
by the (ansi) book so that I end up with code that can be compiled
with a C90 compiler, be it IBM's C/370 or Borland C++.
I found that I could achieve that by making my dummy cross-compile
script introduce the -ansi -pedantic-errors options.
However, that triggered off some more changes to configure like this ...
Index: gccnew/libiberty/configure
diff -c gccnew/libiberty/configure:1.1.1.3 gccnew/libiberty/configure:1.25
*** gccnew/libiberty/configure:1.1.1.3^ISun Nov 15 19:41:46 2009
--- gccnew/libiberty/configure^IWed Dec 2 17:18:07 2009
***************
*** 4190,4196 ****
#if defined (__stub_$ac_func) || defined (__stub___$ac_func)
choke me
#else
! char (*f) () = $ac_func;
#endif
#ifdef __cplusplus
}
--- 4190,4196 ----
#if defined (__stub_$ac_func) || defined (__stub___$ac_func)
choke me
#else
! char (*f) () = (char (*)())$ac_func;
#endif
#ifdef __cplusplus
}
***************
*** 4199,4205 ****
int
main ()
{
! return f != $ac_func;
;
return 0;
}
--- 4199,4205 ----
int
main ()
{
! return f != (char (*)())$ac_func;
;
return 0;
}
I still haven't found the wild pointer in my GCC 3.2.3 port that gets
masked with xcalloc. It's a tough one because the problem keeps
on disappearing whenever I try to introduce debug info and I haven't
found a technique yet.
So I'm working on 3.2.3, 3.4.6 and 4.4 at any particular time. :-)
BFN. Paul..
