Bug#719484: [pkg-boost-devel] Bug#719484: boost1.54: FTBFS
Thorsten Glaser writes: Steve M. Robbins dixit: Interesting, but this is an entirely different bug. Also, this new bug is in gcc, not boost. Sorry, right. I’m just amazed that the boost compilation is still continuing, and replied to the mail “thread” we already had so we have the information in one place. I’ll follow this up on debian-68k@l.d.o for now, so you’re not “spammed” with this particular thing. Mikael: I could reproduce this with a crosscompiler with -g -O3 -fPIC where -fPIC is the culprit. Lowering to -O1 also let us get rid of the ICE whereas removing -g had no effect, so the minimum to trigger it is -O2 -fPIC. bye, //mirabilos The GCC ICE bug is now fixed on GCC trunk by r204224, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58369#c5. That patch backports trivially to gcc-4.8.2 and fixes the ICE there too. I'll try to get it into the gcc-4.8.3 release, but that's about half a year or so away. I've tested it extensively on m68k, x86_64, armv5tel, sparc64, and powerpc64 without problems. /Mikael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711558: gcc-4.8: [m68k] patch set 2
Mikael Pettersson writes: 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.) Both patches have now been submitted to the gcc-patches mailing list. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711558: gcc-4.8: [m68k] patch set 2
On Wed, 21 Aug 2013 23:11:34 + (UTC), Thorsten Glaser t...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711558: PR52306 (was Re: Bug#711558: gcc-4.8: [m68k] patch set 2)
On Thu, 22 Aug 2013 22:26:51 + (UTC), Thorsten Glaser t...@mirbsd.de wrote: Matthias Klose dixit: yes, I do reject this. I see. Would you please=E2=80=A6 =E2=80=9Cfor the time being=E2=80=9D? If so, would you accept a patch that just disables -fauto-inc-dec on m68k *always*, even in the cases where it doesn=E2=80=99t ICE? (one-liner) answer whether this would be considerable? (Untested, but should have the desired effect, right Mikael?) --- a/src/gcc/common.opt +++ b/src/gcc/common.opt @@ -858,7 +858,7 @@ Common Report Var(flag_asynchronous_unwi Generate unwind tables that are exact at each instruction boundary =20 fauto-inc-dec -Common Report Var(flag_auto_inc_dec) Init(1) +Common Report Var(flag_auto_inc_dec) Init(0) Generate auto-inc/dec instructions =20 ; -fcheck-bounds causes gcc to generate array bounds checks. Or maybe this one (although it=E2=80=99s got the malus that it can=E2=80=99= t be re-enabled for testing): --- a/src/gcc/config/m68k/m68k.c +++ b/src/gcc/config/m68k/m68k.c @@ -663,6 +663,8 @@ m68k_override_options_after_change (void flag_schedule_insns_after_reload =3D 0; flag_modulo_sched =3D 0; } + /* PR52306 */ + flag_auto_inc_dec =3D 0; } =20 /* Generate a macro of the form __mPREFIX_cpu_NAME, where PREFIX is the Tweaking the option so that it defaults to OFF for m68k, but still can be enabled, would be preferable. I haven't looked at how to achieve that in gcc's options machinery. /Mikael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#500358: resolving X Server crashes on SPARC (bugs #488669 and #500358)
Gaudenz Steinlin writes: Hi Joss assigned me these two bugs[1] (currently merged) for the bug sprint[2]. As I lack proper SPARC hardware to investigate this myself, I need your help. The two bugs are about X Server Crashes on SPARCs with PCI ATI Mach64 cards. The most probable cause of the crash is an incompatible kernel change introduced with kernel 2.6.26. For #500358 I'm quite sure that it' caused by the kernel change. For #488669 I'm not quite sure if it's really the same bug, because the original reporter ran kernel 2.6.24 which predates the kernel change. For more information about the kernel change see: http://marc.info/?t=12124785781r=1w=2 If the crash is really caused by the kernel change, the real bug is in the X server. But to fix it, we would have to upgrade to xserver-xorg-core 1.5. I don't think that this is really an option. The other options would be to revert the kernel change or to release with a non-working X server for some SPARC machines. Unless of course we find someone willing and able to fix the X server in lenny to work with the kernel change. A simple backport of the changes in 1.5 doesn't seem to be possible. I would like you to test two things: 1. Install the kernel package from http://people.debian.org/~gaudenz/sparc and test if this fixes the problem. This is the same kernel as currently in unstable with the problematic change removed. Please also test this kernel if you are not affected by the change to see if the removal of the problematic change has any ill side effects. 2. Install xserver-xorg-core and xserver-xorg-video-mach64 from experimental and run this on a kernel 2.6.26 or later without removing the change. This should also fix the problem. I'm the one who started the kernel thread mentioned above. I run Aurora not Debian on my Ultra5 so I can't really test your Debian packages. However, I have been using a private forward-port of a patch to revert the problematic SPARC kernel change in the 2.6.26 and 2.6.27 kernels, and at least for me reverting the change fixes the X server but hasn't caused any ill effects. /Mikael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
