[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#711558: gcc-4.8: [m68k] patch set 2



On Wed, 21 Aug 2013 23:11:34 +0000 (UTC), Thorsten Glaser <tg@mirbsd.de> wrote:
> Matthias Klose dixit:
> 
> >Which of these are applied upstream, and if not, why?
> 
> libffi-m68k.diff is applied.
> 
> m68k-revert-pr45144.diff is not applied upstream yet,
> maybe Mikael knows why?

This revert fixed miscompilation of gnat on m68k with gcc 4.6.
My notes say "with gcc-4.7 other changes mask the issue", so
I've dropped it from my gcc 4.7 and 4.8 patch kits.  I know that
4.7 with gnat works very well on m68k without this revert.

> pr49847.diff is not applied yet even though it seems
> to be clear =E2=80=93 I=E2=80=99ve prodded them again a month ago
> and have not received any response yet; maybe just
> nobody feels responsible?

I was hoping for some gcc maintainer to speak up and say
"yeah that's good" but nothing happended and the patch was
left in limbo.  It's absolutely required, though.

There is another required HAVE_cc0 regression fix, see
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835#c55>.
I'll submit both after a round of testing in 4.9.

(The other HAVE_cc0 fix is also in my 4.8 patch kit mentioned below,
as gcc-4.8.0-m68k-ada-pr48835-2.patch.)

> pr52306-retry-hack.diff is not intended to ever be
> applied upstream as-is (and depends on another Debian
> patch) but only a stopgap allowing us to proceed to
> compile things until the problem is fixed for real
> (although we now at least seem to know where it is).

It's a reload bug: it mistransforms an insn with a valid
auto-increment addressing mode into an insn that both assigns
to and auto-increments the same register (it coalesced the
original destination register with the non-LIVE_OUT auto-inc
address register without cancelling the auto-inc addressing
mode), which cselib then rightfully ICEs on.  M68K is just
the innocent bystander who happens to trigger it.

The intersection of (people affected by this bug) and
(people able to fix it) appears to be the empty set, so
there is no fix in sight yet.  Maybe a switch to LRA will
avoid it?  (But LRA on m68k triggers other bugs, sigh.)

-fno-auto-inc-dec is the appropriate workaround for now.

> pr52714.diff is not applied yet because Mikael didn=E2=80=99t
> submit it as he didn=E2=80=99t understand why the 4.6 version
> of the code (which we revert to the 4.5 version) has
> the problem, even though it definitely is an issue.

Correct.

> There=E2=80=99s also m68k-ada.diff in gcc in Debian already,
> which will probably applied when it=E2=80=99s ready enough
> and working with 4.8 (I think both Mikael upstream
> and the GNAT people in Debian do most of the Ada
> related work on 4.6), maybe in combination with the
> pr49847.diff one?

Ada on M68K in gcc 4.8 also needs a patch for PR51483, which is
a blatant upstream bug they refuse to fix.

You can get refeshed and tested gcc-4.8 M68K patches from
<http://user.it.uu.se/~mikpe/linux/patches/gcc/gcc-4.8.1-patches/patches1/>.
Old patches in various gcc BZ entries may be stale.

I must say I'm surprised at the rush to switch to gcc 4.8; there is
a scary number of new and still unfixed gcc 4.8/4.9 wrong-code bugs,
especially on x86.  I personally wouldn't use 4.8 in production on x86 yet.
4.7 (+ patches) OTOH is very solid IMO.

/Mikael


Reply to: