This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: failuer to build uberbaum --target=m68k-elf
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