| Message ID | 4D9A50F2.7040404@codesourcery.com |
|---|---|
| State | New |
| Headers | show |
> The patch below fixes the testcase in the PR. I'll test > tonight/tomorrow, probably on mips64-elf. Ok if that passes? I get back the comparison failure with it on IA-64/Linux: Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs warning: gcc/cc1plus-checksum.o differs Bootstrap comparison failure! gcc/ada/a-elchha.o differs gcc/ada/butil.o differs gcc/ada/elists.o differs gcc/ada/fmap.o differs gcc/ada/ali.o differs gcc/ada/fname.o differs gcc/ada/fname-uf.o differs gcc/ada/g-speche.o differs gcc/ada/g-u3spch.o differs gcc/ada/lib-util.o differs gcc/ada/osint-c.o differs gcc/ada/namet.o differs gcc/ada/output.o differs gcc/ada/osint.o differs gcc/ada/s-os_lib.o differs gcc/build/genhooks.o differs gcc/build/genchecksum.o differs libcpp/directives.o differs libcpp/expr.o differs libcpp/files.o differs libcpp/lex.o differs libcpp/mkdeps.o differs libcpp/traditional.o differs libdecnumber/decimal32.o differs libdecnumber/decNumber.o differs libiberty/pic/simple-object-coff.o differs libiberty/pic/simple-object-elf.o differs libiberty/pic/simple-object-mach-o.o differs libiberty/pic/cplus-dem.o differs libiberty/pic/cp-demangle.o differs libiberty/pic/pex-common.o differs libiberty/simple-object-coff.o differs libiberty/simple-object-elf.o differs libiberty/simple-object-mach-o.o differs libiberty/cplus-dem.o differs libiberty/md5.o differs libiberty/sha1.o differs libiberty/cp-demangle.o differs libiberty/pex-common.o differs lto-plugin/.libs/lto-plugin.o differs zlib/libz_a-compress.o differs zlib/libz_a-uncompr.o differs This is an --enable-checking build. For libiberty/pex-common.o: @@ -1,5 +1,5 @@ -stage2-libiberty/pex-common.o: file format elf64-ia64-little +stage3-libiberty/pex-common.o: file format elf64-ia64-little Disassembly of section .text: @@ -1097,15 +1097,15 @@ 167c: 08 00 84 00 br.ret.sptk.many b0;; 0000000000001680 <pex_input_pipe>: - 1680: 18 40 35 14 80 05 [MMB] alloc r40=ar.pfs,13,10,0 - 1686: c0 80 33 7e 46 00 adds r12=-16,r12 - 168c: 00 00 00 20 nop.b 0x0 - 1690: 01 70 c0 40 00 21 [MII] adds r14=48,r32 - 1696: 70 02 00 62 00 20 mov r39=b0 - 169c: 05 08 00 84 mov r41=r1;; - 16a0: 09 70 00 1c 10 10 [MMI] ld4 r14=[r14] - 16a6: 00 00 00 02 00 60 nop.m 0x0 - 16ac: 84 01 01 84 adds r35=24,r32;; + 1680: 08 40 35 14 80 05 [MMI] alloc r40=ar.pfs,13,10,0 + 1686: c0 80 33 7e 46 e0 adds r12=-16,r12 + 168c: 04 00 c4 00 mov r39=b0 + 1690: 09 70 c0 40 00 21 [MMI] adds r14=48,r32 + 1696: 90 02 04 00 42 60 mov r41=r1 + 169c: 84 01 01 84 adds r35=24,r32;; + 16a0: 09 00 00 00 01 00 [MMI] nop.m 0x0 + 16a6: e0 00 38 20 20 00 ld4 r14=[r14] + 16ac: 00 00 04 00 nop.i 0x0;; 16b0: 11 30 00 1c 87 31 [MIB] cmp4.lt p6,p7=0,r14 16b6: 00 00 00 02 00 03 nop.i 0x0 16bc: 70 00 00 43 (p06) br.cond.dpnt.few 1720 <pex_input_pipe+0xa0>;; @@ -1427,15 +1427,15 @@ 1d3c: 00 00 04 00 nop.i 0x0 0000000000001d40 <pex_get_status>: - 1d40: 18 30 31 10 80 05 [MMB] alloc r38=ar.pfs,12,8,0 - 1d46: c0 80 33 7e 46 00 adds r12=-16,r12 - 1d4c: 00 00 00 20 nop.b 0x0 + 1d40: 08 30 31 10 80 05 [MMI] alloc r38=ar.pfs,12,8,0 + 1d46: c0 80 33 7e 46 a0 adds r12=-16,r12 + 1d4c: 04 00 c4 00 mov r37=b0 1d50: 09 18 01 41 00 21 [MMI] adds r35=64,r32 - 1d56: 40 82 81 00 42 a0 adds r36=48,r32 - 1d5c: 04 00 c4 00 mov r37=b0;; - 1d60: 09 70 00 46 18 10 [MMI] ld8 r14=[r35] - 1d66: 00 00 00 02 00 e0 nop.m 0x0 - 1d6c: 04 08 00 84 mov r39=r1;; + 1d56: 40 82 81 00 42 e0 adds r36=48,r32 + 1d5c: 04 08 00 84 mov r39=r1;; + 1d60: 09 00 00 00 01 00 [MMI] nop.m 0x0 + 1d66: e0 00 8c 30 20 00 ld8 r14=[r35] + 1d6c: 00 00 04 00 nop.i 0x0;; 1d70: 11 38 00 1c 06 39 [MIB] cmp.eq p7,p6=0,r14 1d76: 00 00 00 02 80 03 nop.i 0x0 1d7c: 00 01 00 43 (p07) br.cond.dpnt.few 1e70 <pex_get_status+0x130>;;
On 04/05/2011 04:32 PM, Eric Botcazou wrote: >> The patch below fixes the testcase in the PR. I'll test >> tonight/tomorrow, probably on mips64-elf. Ok if that passes? > > I get back the comparison failure with it on IA-64/Linux: Looking into it. I ran into PR48441, I assume you were using the patch from that as well? Bernd
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/05/11 09:54, Bernd Schmidt wrote: > On 04/05/2011 04:32 PM, Eric Botcazou wrote: >>> The patch below fixes the testcase in the PR. I'll test >>> tonight/tomorrow, probably on mips64-elf. Ok if that passes? >> >> I get back the comparison failure with it on IA-64/Linux: > > Looking into it. I ran into PR48441, I assume you were using the patch > from that as well? Bernd, Any comparison failures with --disable-checking or - --enable-checking=release configured trees should be sent my way. There's a bug in a change of mine from last week which will cause these kinds of problems. No sense in you duplicating the work I've already done to track those problems down. jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNmz5lAAoJEBRtltQi2kC7drwH/RnGeuX9h35n6N0tn9J0tWsy iIM83r1Okh/1+YfT4MIpYAStY/tPMgvKoppiqXrqgB8lBHoEcY0I4E58GWjt2fI6 +rbhwPR3Fpc3Fn9/FM0K+ulHhFjPhgdvag/OI6PBXQzfXCdnS4gLUd2c5dEXDOFz FnSjp6yPYP7GtTfaVJOj7vKvzYsvECI5FB+VJgSTDB1PNlhjTIDSU9VxDTWxvdXj ywrwZiNr3fXrVMb9rJVrOk0nXVjkPaKq7GEmDxHeIaXxNZqOXc1il014/zObVDHe aIaRLewui/19MX3OtJFPYeFCM9MqsAaip4JwgF/peSp9pjD+IzNct6k4k9riWwI= =IBZn -----END PGP SIGNATURE-----
On 04/05/2011 06:08 PM, Jeff Law wrote: > On 04/05/11 09:54, Bernd Schmidt wrote: >> On 04/05/2011 04:32 PM, Eric Botcazou wrote: >>>> The patch below fixes the testcase in the PR. I'll test >>>> tonight/tomorrow, probably on mips64-elf. Ok if that passes? >>> >>> I get back the comparison failure with it on IA-64/Linux: > >> Looking into it. I ran into PR48441, I assume you were using the patch >> from that as well? > Bernd, > > Any comparison failures with --disable-checking or > --enable-checking=release configured trees should be sent my way. > There's a bug in a change of mine from last week which will cause these > kinds of problems. No sense in you duplicating the work I've already > done to track those problems down. Well, I need to test the scheduler patch posted three messages or so previously, on either mips64 or ia64, so might as well try to bootstrap on gcc60. Bernd
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/05/11 10:10, Bernd Schmidt wrote: > On 04/05/2011 06:08 PM, Jeff Law wrote: >> On 04/05/11 09:54, Bernd Schmidt wrote: >>> On 04/05/2011 04:32 PM, Eric Botcazou wrote: >>>>> The patch below fixes the testcase in the PR. I'll test >>>>> tonight/tomorrow, probably on mips64-elf. Ok if that passes? >>>> >>>> I get back the comparison failure with it on IA-64/Linux: >> >>> Looking into it. I ran into PR48441, I assume you were using the patch >>> from that as well? >> Bernd, >> >> Any comparison failures with --disable-checking or >> --enable-checking=release configured trees should be sent my way. >> There's a bug in a change of mine from last week which will cause these >> kinds of problems. No sense in you duplicating the work I've already >> done to track those problems down. > > Well, I need to test the scheduler patch posted three messages or so > previously, on either mips64 or ia64, so might as well try to bootstrap > on gcc60. In which case, if you're not using checking, you'll want the attached patch to avoid comparison failures with --disable-checking. I felt like a bloody idiot when I finally saw what I'd done... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNm0AgAAoJEBRtltQi2kC7UloH/1Z+zEV26u9m6FZ++57nXJbE TedMoL+C/Kvefd2HBpIdN+Jgz+bsEgauOIyCbAuodhHbqkODDuIbdHmx6f5xn+V1 SjMWzCaxNiJdCinPYFqe/Mb1+hHz3s7iEsPjhj4EQ91Tx7/Xv/qPbU8qimSL6zhy 51l2RH+jNMgapHw+7QhMwVfY6oCI0hvbHMY6+Ly2oG16yxPt9RKJyp8o+q2zlFB1 WVD7EvkoaMg+wQAlXnV8scslKeoUE/aJOnGfOXnuaiEWPterE7Ku4JE8xz0P+PWA k4JoBeII+vR89ofpXjeG1Ei0vzXQjFHKgPUxkfmNiWMhM6uioQ+PK/GVYW0YPkw= =tiZC -----END PGP SIGNATURE----- Index: tree-ssa-threadupdate.c =================================================================== *** tree-ssa-threadupdate.c (revision 171989) --- tree-ssa-threadupdate.c (working copy) *************** determine_bb_domination_status (struct l *** 665,671 **** edge_iterator ei; edge e; - #ifdef ENABLE_CHECKING /* This function assumes BB is a successor of LOOP->header. If that is not the case return DOMST_NONDOMINATING which is always safe. */ --- 665,670 ---- *************** determine_bb_domination_status (struct l *** 684,690 **** if (!ok) return DOMST_NONDOMINATING; } - #endif if (bb == loop->latch) return DOMST_DOMINATING; --- 683,688 ----
On Tue, 2011-04-05 at 17:54 +0200, Bernd Schmidt wrote: > On 04/05/2011 04:32 PM, Eric Botcazou wrote: > >> The patch below fixes the testcase in the PR. I'll test > >> tonight/tomorrow, probably on mips64-elf. Ok if that passes? > > > > I get back the comparison failure with it on IA-64/Linux: > > Looking into it. I ran into PR48441, I assume you were using the patch > from that as well? > > > Bernd Hm, I just tried a bootstrap build on IA64 HP-UX using the haifa-sched.c patch and r171988 and I got this error during stage 2: /proj/opensrc_nobackup/sje/reg/src/trunk/gcc/genautomata.c: In function 'create_ automata': /proj/opensrc_nobackup/sje/reg/src/trunk/gcc/genautomata.c:6678:1: internal comp iler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. make[3]: *** [build/genautomata.o] Error 1 make[3]: Leaving directory `/proj/opensrc_nobackup/sje/reg/build-ia64-hp-hpux11. 23-trunk/obj_gcc/gcc' make[2]: *** [all-stage2-gcc] Error 2 I added Jeff Law's patch to tree-ssa-threadupdate.c but that didn't change this error. I don't seem to be able to reproduce this on IA64 Linux. Steve Ellcey sje@cup.hp.com
On Tue, 2011-04-05 at 09:41 -0700, Steve Ellcey wrote: > Hm, I just tried a bootstrap build on IA64 HP-UX using the haifa-sched.c > patch and r171988 and I got this error during stage 2: > > > /proj/opensrc_nobackup/sje/reg/src/trunk/gcc/genautomata.c: In function 'create_ > automata': > /proj/opensrc_nobackup/sje/reg/src/trunk/gcc/genautomata.c:6678:1: internal comp > iler error: Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See <http://gcc.gnu.org/bugs.html> for instructions. > make[3]: *** [build/genautomata.o] Error 1 > make[3]: Leaving directory `/proj/opensrc_nobackup/sje/reg/build-ia64-hp-hpux11. > 23-trunk/obj_gcc/gcc' > make[2]: *** [all-stage2-gcc] Error 2 > > I added Jeff Law's patch to tree-ssa-threadupdate.c but that didn't change this > error. > > I don't seem to be able to reproduce this on IA64 Linux. I was able to reproduce it on my Linux system. I thought my build had already gotten past the point where this was happening but it hadn't. I get this on IA64 HP-UX and Linux with the proposed haifa-sched.c change. Steve Ellcey sje@cup.hp.com
> Looking into it. I ran into PR48441, I assume you were using the patch > from that as well? It's yesterday's tree + your 2 patches to haifa-sched.c, so without Steven's patch... at least it was supposed to be, but I screwed up, sorry about that. After having done another round of testing, let me recap: 1. yesterday's pristine tree yields the bootstrap comparison failure on the IA-64/Linux machine, 2. yesterday's pristine tree + your 2 patches to haifa-sched.c successfully bootstraps on the IA-64/Linux machine.
On Tue, 2011-04-05 at 19:48 +0200, Eric Botcazou wrote: > > Looking into it. I ran into PR48441, I assume you were using the patch > > from that as well? > > It's yesterday's tree + your 2 patches to haifa-sched.c, so without Steven's > patch... at least it was supposed to be, but I screwed up, sorry about that. > > After having done another round of testing, let me recap: > 1. yesterday's pristine tree yields the bootstrap comparison failure on the > IA-64/Linux machine, > 2. yesterday's pristine tree + your 2 patches to haifa-sched.c successfully > bootstraps on the IA-64/Linux machine. What are the two patches to haifa-sched.c? I have one patch to schedule_block from http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00271.html but that patch (alone or with the Jeff Law patch) isn't working for me on IA64 Linux. Is there a second haifa-sched.c patch I should also have? Steve Ellcey sje@cup.hp.com
> What are the two patches to haifa-sched.c? I have one patch to > schedule_block from > http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00271.html > but that patch (alone or with the Jeff Law patch) isn't working for me > on IA64 Linux. Is there a second haifa-sched.c patch I should also > have? No, the important point is that I'm using yesterday's tree, so the first patch is Bernd's patch from yesterday (r171942).
On Tue, 2011-04-05 at 20:18 +0200, Eric Botcazou wrote: > > What are the two patches to haifa-sched.c? I have one patch to > > schedule_block from > > http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00271.html > > but that patch (alone or with the Jeff Law patch) isn't working for me > > on IA64 Linux. Is there a second haifa-sched.c patch I should also > > have? > > No, the important point is that I'm using yesterday's tree, so the first patch > is Bernd's patch from yesterday (r171942). OK, I was using a newer tree and I think the problem I ran into was PR 48441 which is now fixed in ToT. I just updated my tree and that problem seems to be fixed but now I can't compile dbxout.c (unused variable error) so I still haven't managed a good bootstrap. Steve Ellcey sje@cup.hp.com /proj/opensrc_nobackup/sje/reg/src/trunk/gcc/dbxout.c:107:12: error: 'debug_nesting' defined but not used [-Werror=unused-variable] /proj/opensrc_nobackup/sje/reg/src/trunk/gcc/dbxout.c:109:14: error: 'symbol_queue' defined but not used [-Werror=unused-variable] /proj/opensrc_nobackup/sje/reg/src/trunk/gcc/dbxout.c:110:12: error: 'symbol_queue_index' defined but not used [-Werror=unused-variable] /proj/opensrc_nobackup/sje/reg/src/trunk/gcc/dbxout.c:111:12: error: 'symbol_queue_size' defined but not used [-Werror=unused-variable] cc1: all warnings being treated as errors
On 04/05/2011 07:48 PM, Eric Botcazou wrote: >> Looking into it. I ran into PR48441, I assume you were using the patch >> from that as well? > > It's yesterday's tree + your 2 patches to haifa-sched.c, so without Steven's > patch... at least it was supposed to be, but I screwed up, sorry about that. > > After having done another round of testing, let me recap: > 1. yesterday's pristine tree yields the bootstrap comparison failure on the > IA-64/Linux machine, > 2. yesterday's pristine tree + your 2 patches to haifa-sched.c successfully > bootstraps on the IA-64/Linux machine. So, no problems with the extra haifa-sched.c patch from this thread? My results are (today's tree + StevenB's patch from PR48441 + a revert for froydnj's dbxout changes + my patch from this thread) yields comparison failures. It sounds like you're saying these failures are likely caused by something else? Bernd
On Tue, 2011-04-05 at 22:31 +0200, Bernd Schmidt wrote: > On 04/05/2011 07:48 PM, Eric Botcazou wrote: > >> Looking into it. I ran into PR48441, I assume you were using the patch > >> from that as well? > > > > It's yesterday's tree + your 2 patches to haifa-sched.c, so without Steven's > > patch... at least it was supposed to be, but I screwed up, sorry about that. > > > > After having done another round of testing, let me recap: > > 1. yesterday's pristine tree yields the bootstrap comparison failure on the > > IA-64/Linux machine, > > 2. yesterday's pristine tree + your 2 patches to haifa-sched.c successfully > > bootstraps on the IA-64/Linux machine. > > So, no problems with the extra haifa-sched.c patch from this thread? > > My results are (today's tree + StevenB's patch from PR48441 + a revert > for froydnj's dbxout changes + my patch from this thread) yields > comparison failures. It sounds like you're saying these failures are > likely caused by something else? > > > Bernd I think you need Jeff Law's patch too to fix the comparision failures. http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00367.html Steve Ellcey sje@cup.hp.com
> > After having done another round of testing, let me recap: > > 1. yesterday's pristine tree yields the bootstrap comparison failure on > > the IA-64/Linux machine, > > 2. yesterday's pristine tree + your 2 patches to haifa-sched.c > > successfully bootstraps on the IA-64/Linux machine. > > So, no problems with the extra haifa-sched.c patch from this thread? Yes, with the 2 haifa-sched.c patches (r171942 + your patch from this thread) applied to yesterday's tree, IA-64/Linux bootstraps for me. Without them, I get the comparison failures; with the first but not the second, I get the ICE on errors.c that Steve reported. > My results are (today's tree + StevenB's patch from PR48441 + a revert > for froydnj's dbxout changes + my patch from this thread) yields > comparison failures. It sounds like you're saying these failures are > likely caused by something else? Yes, possibly, and there is still the other issue that Jeff is working on. Given my results and that your patch from this thread apparently only restores the old behaviour, I'd install this patch.
On Tue, 2011-04-05 at 23:06 +0200, Eric Botcazou wrote: > Yes, possibly, and there is still the other issue that Jeff is working on. > > Given my results and that your patch from this thread apparently only restores > the old behaviour, I'd install this patch. I finally got a good bootstrap on IA64 HP-UX. I used this patch, Jeff's patch for PR 48444 (already checked in) and Nathan's patch for PR 48471. So yes, I'd like to see this patch checked in too. Steve Ellcey sje@cup.hp.com
On 04/06/2011 12:15 AM, Steve Ellcey wrote: > I finally got a good bootstrap on IA64 HP-UX. I used this patch, Jeff's > patch for PR 48444 (already checked in) and Nathan's patch for PR 48471. > So yes, I'd like to see this patch checked in too. Done. Bernd
Index: haifa-sched.c =================================================================== --- haifa-sched.c (revision 171954) +++ haifa-sched.c (working copy) @@ -3230,10 +3230,12 @@ schedule_block (basic_block *target_bb) if (recog_memoized (insn) >= 0) { + memcpy (temp_state, curr_state, dfa_state_size); cost = state_transition (curr_state, insn); if (!flag_sched_pressure) gcc_assert (cost < 0); - cycle_issued_insns++; + if (memcmp (temp_state, curr_state, dfa_state_size) != 0) + cycle_issued_insns++; asm_p = false; } else