Re: failuer to build uberbaum --target=m68k-elf

[Joel Sherrill <joel.sherrill@OARcorp.com>]

Jim Wilson wrote:
> 
> On Wed, 2003-02-26 at 09:27, Joel Sherrill wrote:
> > Is this PR8343?
> 
> No.  PR 8343 was already fixed by a patch from Jan Hubicka, and the
> patch is already in both trunk and the gcc-3.3 branch.  He added it to
> the branch yesterday.  I see the PR refers to gcc-3.2.  Do you need the
> patch added to the gcc-3.2 branch?  If someone tests the patch with the
> gcc-3.2 branch I am willing to do that.  I don't have any convenient way
> to do that at the moment; I don't even have a copy checked out.

I can test it against 3.2 if you check it in. Is it sufficient to say
that
the compiler does not ICE?

Doing a search on m68 I see that there are a handful of PRs citing
places
close together for ICEs.  Maybe this fixes more than 1 PR.  Could
someone
check that it didn't also fix:

  PR9389 - [3.2/3.3 regression] [m68k] ICE in
instantiate_virtual_regs_1, at function.c:4134
  PR9248 - [m68k] compiling C++ file from ACE causes ICE on m68k-rtems
target
  
Also in looking at m68k PRs, I see that PR3794 no longer applies since
it
is against 3.0 and m68k toolsets could be built on the 3.2 branch.  This
is a problem when building newlib.  

Ditto for PR4634 and PR1795.  They have to be fixed in newer versions
since
m68k-elf, m68k-coff, m68k-rtems, and (I have to believe) m68k-linux have
been
built on 3.2.

There are others but I can't tell about them.  We might be able to close
a bunch.

> I don't know if there is a PR for the combine problem.

I think 9255 may be it since that is the most recent m68k one I have
filed
and I am fairly certain Peter sent me the patch in response to queries
on the list about failures building 3.3 without it.

> Jim

--joel