[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #69 from Andrew Pinski --- *** Bug 49444 has been marked as a duplicate of this bug. ***
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.10.0, 4.8.3, 4.9.2 Resolution|--- |FIXED Target Milestone|4.10.0 |4.9.2 Known to fail|4.8.3 |4.9.1 --- Comment #68 from Richard Biener --- Fixed.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #67 from Richard Biener --- Author: rguenth Date: Wed Aug 6 11:42:22 2014 New Revision: 213662 URL: https://gcc.gnu.org/viewcvs?rev=213662&root=gcc&view=rev Log: 2014-08-06 Richard Biener PR tree-optimization/61320 * tree-ssa-loop-ivopts.c (may_be_unaligned_p): Properly handle misaligned loads. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/tree-ssa-loop-ivopts.c
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #66 from Richard Biener --- Author: rguenth Date: Wed Aug 6 11:41:13 2014 New Revision: 213661 URL: https://gcc.gnu.org/viewcvs?rev=213661&root=gcc&view=rev Log: 2014-08-06 Richard Biener PR tree-optimization/61320 * tree-ssa-loop-ivopts.c (may_be_unaligned_p): Properly handle misaligned loads. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-loop-ivopts.c
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #65 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #61 from Eric Botcazou --- [...] >> can you test and apply that patch? > > I think that it needs to be applied on both mainline and 4.9 branch then. Testing on the 4.9 branch also completed successfully, so from my POV the patch is good to go in both mainline and branch. Thanks. Rainer
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 wangzheyu changed: What|Removed |Added CC||tony.wang at arm dot com --- Comment #64 from wangzheyu --- > > Fix: > > Index: gcc/tree-ssa-loop-ivopts.c > === > --- gcc/tree-ssa-loop-ivopts.c (revision 213050) > +++ gcc/tree-ssa-loop-ivopts.c (working copy) > @@ -1704,6 +1704,8 @@ may_be_unaligned_p (tree ref, tree step) > return false; > >unsigned int align = TYPE_ALIGN (TREE_TYPE (ref)); > + if (GET_MODE_ALIGNMENT (TYPE_MODE (TREE_TYPE (ref))) > align) > +align = GET_MODE_ALIGNMENT (TYPE_MODE (TREE_TYPE (ref))); > >unsigned HOST_WIDE_INT bitpos; >unsigned int ref_align; > > can you test and apply that patch? Also run into a similar regression on arm target, which will generate unaligned memory access on target which don't support unaligned data access. This patch does fix this regression. Thx
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #63 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #62 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> --- [...] > With the patch, SPARC bootstrap concluded on mainline. I'm seeing two > different regressions with this patch in tree: > > * on i386-pc-solaris2.10, gcc.dg/pch/import-[12].c FAILs (SEGV in cc1 > due to unaligned movaps destination) > > * on sparc-sun-solaris2.*, many 64-bit gfortran.dg tests (starting with > gfortran.dg/allocate_class_3.f90) FAIL at -O1 and above > > I'd like to make sure those are not related to your patch first. It turned out that both failures are unrelated. I'll start reghunting now. >From my POV, the patch is good to go. I'll next try it on the 4.9 branch as Eric asked. Rainer
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #62 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #60 from Richard Biener --- [...] > Fix: > > Index: gcc/tree-ssa-loop-ivopts.c > === > --- gcc/tree-ssa-loop-ivopts.c (revision 213050) > +++ gcc/tree-ssa-loop-ivopts.c (working copy) > @@ -1704,6 +1704,8 @@ may_be_unaligned_p (tree ref, tree step) > return false; > >unsigned int align = TYPE_ALIGN (TREE_TYPE (ref)); > + if (GET_MODE_ALIGNMENT (TYPE_MODE (TREE_TYPE (ref))) > align) > +align = GET_MODE_ALIGNMENT (TYPE_MODE (TREE_TYPE (ref))); > >unsigned HOST_WIDE_INT bitpos; >unsigned int ref_align; > > can you test and apply that patch? With the patch, SPARC bootstrap concluded on mainline. I'm seeing two different regressions with this patch in tree: * on i386-pc-solaris2.10, gcc.dg/pch/import-[12].c FAILs (SEGV in cc1 due to unaligned movaps destination) * on sparc-sun-solaris2.*, many 64-bit gfortran.dg tests (starting with gfortran.dg/allocate_class_3.f90) FAIL at -O1 and above I'd like to make sure those are not related to your patch first. Rainer
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #61 from Eric Botcazou --- > Ok, I suppose > > lduh[%g3], %g4 ! MEM[base: ptr_110, offset: 0B], min_line > > is not an instruction that works with unaligned %g3. Right, every load must be aligned. > ;; min_line_106 = (int) _215; > > (insn 921 920 922 (set (reg:HI 482) > (mem:HI (reg/v/f:SI 185 [ ptr ]) [0 MEM[base: ptr_110, offset: 0B]+0 > S2 A8])) /vol/gcc/src/hg/trunk/local/gcc/java/jcf-parse.c:1622 -1 > (nil)) > > a (mem:HI ...) with A8. I wonder if we should ICE somewhere if such kind > of MEM is in the RTL instruction stream on a STRICT_ALIGNMENT platform? No, it's undefined behavior at run time only. > Ah, so the issue is that may_be_unaligned does > > 1706 unsigned int align = TYPE_ALIGN (TREE_TYPE (ref)); > 1707 > 1708 unsigned HOST_WIDE_INT bitpos; > 1709 unsigned int ref_align; > 1710 get_object_alignment_1 (ref, &ref_align, &bitpos); > 1711 if (ref_align < align > 1712 || (bitpos % align) != 0 > 1713 || (bitpos % BITS_PER_UNIT) != 0) > 1714return true; > > thus it queries TYPE_ALIGN (TREE_TYPE (ref)) which is 8 - and _not_ > mode alignment which is what matters on STRICT_ALIGNMENT targets. Yes, and that's what the original implementation actually did, see: https://gcc.gnu.org/ml/gcc-patches/2014-01/msg00717.html > Fix: > > Index: gcc/tree-ssa-loop-ivopts.c > === > --- gcc/tree-ssa-loop-ivopts.c (revision 213050) > +++ gcc/tree-ssa-loop-ivopts.c (working copy) > @@ -1704,6 +1704,8 @@ may_be_unaligned_p (tree ref, tree step) > return false; > >unsigned int align = TYPE_ALIGN (TREE_TYPE (ref)); > + if (GET_MODE_ALIGNMENT (TYPE_MODE (TREE_TYPE (ref))) > align) > +align = GET_MODE_ALIGNMENT (TYPE_MODE (TREE_TYPE (ref))); > >unsigned HOST_WIDE_INT bitpos; >unsigned int ref_align; > > can you test and apply that patch? I think that it needs to be applied on both mainline and 4.9 branch then.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 Richard Biener changed: What|Removed |Added Status|WAITING |ASSIGNED --- Comment #60 from Richard Biener --- Ok, I suppose lduh[%g3], %g4 ! MEM[base: ptr_110, offset: 0B], min_line is not an instruction that works with unaligned %g3. ;; min_line_106 = (int) _215; (insn 921 920 922 (set (reg:HI 482) (mem:HI (reg/v/f:SI 185 [ ptr ]) [0 MEM[base: ptr_110, offset: 0B]+0 S2 A8])) /vol/gcc/src/hg/trunk/local/gcc/java/jcf-parse.c:1622 -1 (nil)) a (mem:HI ...) with A8. I wonder if we should ICE somewhere if such kind of MEM is in the RTL instruction stream on a STRICT_ALIGNMENT platform? The TARGET_MEM_REF is created via #0 create_mem_ref_raw (type=type@entry=0x75401000, alias_ptr_type=alias_ptr_type@entry=, addr=addr@entry=0x7fffd560, verify=verify@entry=true) at /space/rguenther/tramp3d/trunk/gcc/tree-ssa-address.c:401 #1 0x00c3b464 in create_mem_ref (gsi=gsi@entry=0x7fffd600, type=, addr=addr@entry=0x7fffd640, alias_ptr_type=, iv_cand=iv_cand@entry=, base_hint=base_hint@entry=, speed=speed@entry=true) at /space/rguenther/tramp3d/trunk/gcc/tree-ssa-address.c:721 #2 0x00c96f9a in rewrite_use_address (use=use@entry=0x18b8a10, cand=cand@entry=0x1a26f50, data=, data=) at /space/rguenther/tramp3d/trunk/gcc/tree-ssa-loop-ivopts.c:6471 #3 0x00c97513 in rewrite_use (cand=0x1a26f50, use=0x18b8a10, data=0x7fffd9c0) at /space/rguenther/tramp3d/trunk/gcc/tree-ssa-loop-ivopts.c:6539 #4 rewrite_uses (data=data@entry=0x7fffd9c0) at /space/rguenther/tramp3d/trunk/gcc/tree-ssa-loop-ivopts.c:6568 #5 0x00c9cb35 in tree_ssa_iv_optimize_loop (loop=, data=0x7fffd9c0) at /space/rguenther/tramp3d/trunk/gcc/tree-ssa-loop-ivopts.c:6894 #6 tree_ssa_iv_optimize () at /space/rguenther/tramp3d/trunk/gcc/tree-ssa-loop-ivopts.c:6926 Ah, so the issue is that may_be_unaligned does 1706 unsigned int align = TYPE_ALIGN (TREE_TYPE (ref)); 1707 1708 unsigned HOST_WIDE_INT bitpos; 1709 unsigned int ref_align; 1710 get_object_alignment_1 (ref, &ref_align, &bitpos); 1711 if (ref_align < align 1712 || (bitpos % align) != 0 1713 || (bitpos % BITS_PER_UNIT) != 0) 1714return true; thus it queries TYPE_ALIGN (TREE_TYPE (ref)) which is 8 - and _not_ mode alignment which is what matters on STRICT_ALIGNMENT targets. Fix: Index: gcc/tree-ssa-loop-ivopts.c === --- gcc/tree-ssa-loop-ivopts.c (revision 213050) +++ gcc/tree-ssa-loop-ivopts.c (working copy) @@ -1704,6 +1704,8 @@ may_be_unaligned_p (tree ref, tree step) return false; unsigned int align = TYPE_ALIGN (TREE_TYPE (ref)); + if (GET_MODE_ALIGNMENT (TYPE_MODE (TREE_TYPE (ref))) > align) +align = GET_MODE_ALIGNMENT (TYPE_MODE (TREE_TYPE (ref))); unsigned HOST_WIDE_INT bitpos; unsigned int ref_align; can you test and apply that patch? Thx. With that patch I get ldub[%g3+1], %g2! MEM[(unsigned char *)ptr_110], MEM[(unsigned char *)ptr_110] ldub[%g3], %g1 ! MEM[(unsigned char *)ptr_110], MEM[(unsigned char *)ptr_110] sll %g1, 8, %g1 ! MEM[(unsigned char *)ptr_110],, tmp462 or %g2, %g1, %g1 ! MEM[(unsigned char *)ptr_110], tmp462, min_line
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #59 from Rainer Orth --- Configure binutils with configure \ --target sparc-solaris2.11 and gcc with configure \ --prefix=/var/gcc/cross/sparc-solaris2.11 \ --target sparc-solaris2.11 \ --with-gmp=/vol/gcc \ --with-gnu-as \ --disable-multilib \ --enable-languages=c++ Then compile jcf-parse.ii with cc1plus -fpreprocessed jcf-parse.ii -quiet -mcpu=v9 -g -O2 -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -fno-common -o jcf-parse.s Rainer
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #58 from Rainer Orth --- Created attachment 33181 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33181&action=edit preprocessed input
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 Richard Biener changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #57 from Richard Biener --- Waiting for preprocessed source and configure instructions.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #56 from Richard Biener --- (In reply to rguent...@suse.de from comment #55) > On July 17, 2014 6:13:14 PM CEST, "thopre01 at gcc dot gnu.org" > wrote: > >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 > > > >--- Comment #53 from thopre01 at gcc dot gnu.org --- > >(In reply to thopre01 from comment #52) > >> (In reply to Eric Botcazou from comment #51) > >> > > >> > TARGET_MEM_REF is supposed to be a valid memory access for the > >target though > >> > and, by definition, an unaligned access is not valid for a strict > >alignment > >> > target (unless you have a movmisalign pattern), so the problem is > >the > >> > TARGET_MEM_REF. > >> > >> So we just need to identify what changes the MEM_REF that bswap > >introduce > >> into a TARGET_MEM_REF without taking alignment into account. > >> > >> After bswap it's only a MEM_REF: > >> > >> load_dst_215 = MEM[(unsigned char *)load_src_277]; > > > >So it changes from a MEM_REF to a TARGET_MEM_REF in ivopts from a quick > >grep. I > >don't know how much this system but I can take a look after Cauldron > >where does > >this happen and bring the right person into this discussion. > > You need to fix may_be_unaligned (or similar) in ivopts. So actually that function now looks completely sane (thanks Eric). So I still need preprocessed source and a target triplet to configure a cross for. There must be missing may_be_unaligned_p calls in IVOPTs.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #55 from rguenther at suse dot de --- On July 17, 2014 6:13:14 PM CEST, "thopre01 at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 > >--- Comment #53 from thopre01 at gcc dot gnu.org --- >(In reply to thopre01 from comment #52) >> (In reply to Eric Botcazou from comment #51) >> > >> > TARGET_MEM_REF is supposed to be a valid memory access for the >target though >> > and, by definition, an unaligned access is not valid for a strict >alignment >> > target (unless you have a movmisalign pattern), so the problem is >the >> > TARGET_MEM_REF. >> >> So we just need to identify what changes the MEM_REF that bswap >introduce >> into a TARGET_MEM_REF without taking alignment into account. >> >> After bswap it's only a MEM_REF: >> >> load_dst_215 = MEM[(unsigned char *)load_src_277]; > >So it changes from a MEM_REF to a TARGET_MEM_REF in ivopts from a quick >grep. I >don't know how much this system but I can take a look after Cauldron >where does >this happen and bring the right person into this discussion. You need to fix may_be_unaligned (or similar) in ivopts.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #54 from rguenther at suse dot de --- On July 17, 2014 5:50:44 PM CEST, "ebotcazou at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 > >--- Comment #51 from Eric Botcazou --- >> Ah, we also expand one from a TARGET_MEM_REF: >> >> ;; basic block 76, loop depth 2 >> ;;pred: 79 >> load_dst_215 = MEM[base: ptr_110, offset: 0B]; >> >> and TARGET_MEM_REF only handles the movmisalign case. So it's either >IVOPTs >> not punting properly here (it does for unaligned accesses - grep for >> STRICT_ALIGNMENT) or we need to put a bitfield extraction case into >> TARGET_MEM_REF expansion (IMHO that's missing anyway, IVOPTs is too >much >> pessimized by not considering this). > >TARGET_MEM_REF is supposed to be a valid memory access for the target >though >and, by definition, an unaligned access is not valid for a strict >alignment >target (unless you have a movmisalign pattern), so the problem is the >TARGET_MEM_REF. Ivopts does not change the memory addresses, so even when not using a target_men_ref the access will be unaligned. It's only that we had no way of specifying whether an access is unaligned or not. The addressing mode costs may not reflect reality though. Richard. > >If you want to make IVOPTS generate unaligned TARGET_MEM_REFs, you'll >need to >make sure that the costs are properly adjusted and benchmark the >result.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #53 from thopre01 at gcc dot gnu.org --- (In reply to thopre01 from comment #52) > (In reply to Eric Botcazou from comment #51) > > > > TARGET_MEM_REF is supposed to be a valid memory access for the target though > > and, by definition, an unaligned access is not valid for a strict alignment > > target (unless you have a movmisalign pattern), so the problem is the > > TARGET_MEM_REF. > > So we just need to identify what changes the MEM_REF that bswap introduce > into a TARGET_MEM_REF without taking alignment into account. > > After bswap it's only a MEM_REF: > > load_dst_215 = MEM[(unsigned char *)load_src_277]; So it changes from a MEM_REF to a TARGET_MEM_REF in ivopts from a quick grep. I don't know how much this system but I can take a look after Cauldron where does this happen and bring the right person into this discussion.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #52 from thopre01 at gcc dot gnu.org --- (In reply to Eric Botcazou from comment #51) > > TARGET_MEM_REF is supposed to be a valid memory access for the target though > and, by definition, an unaligned access is not valid for a strict alignment > target (unless you have a movmisalign pattern), so the problem is the > TARGET_MEM_REF. So we just need to identify what changes the MEM_REF that bswap introduce into a TARGET_MEM_REF without taking alignment into account. After bswap it's only a MEM_REF: load_dst_215 = MEM[(unsigned char *)load_src_277];
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #51 from Eric Botcazou --- > Ah, we also expand one from a TARGET_MEM_REF: > > ;; basic block 76, loop depth 2 > ;;pred: 79 > load_dst_215 = MEM[base: ptr_110, offset: 0B]; > > and TARGET_MEM_REF only handles the movmisalign case. So it's either IVOPTs > not punting properly here (it does for unaligned accesses - grep for > STRICT_ALIGNMENT) or we need to put a bitfield extraction case into > TARGET_MEM_REF expansion (IMHO that's missing anyway, IVOPTs is too much > pessimized by not considering this). TARGET_MEM_REF is supposed to be a valid memory access for the target though and, by definition, an unaligned access is not valid for a strict alignment target (unless you have a movmisalign pattern), so the problem is the TARGET_MEM_REF. If you want to make IVOPTS generate unaligned TARGET_MEM_REFs, you'll need to make sure that the costs are properly adjusted and benchmark the result.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|thopre01 at gcc dot gnu.org|rguenth at gcc dot gnu.org --- Comment #50 from Richard Biener --- Ah, we also expand one from a TARGET_MEM_REF: ;; basic block 76, loop depth 2 ;;pred: 79 load_dst_215 = MEM[base: ptr_110, offset: 0B]; and TARGET_MEM_REF only handles the movmisalign case. So it's either IVOPTs not punting properly here (it does for unaligned accesses - grep for STRICT_ALIGNMENT) or we need to put a bitfield extraction case into TARGET_MEM_REF expansion (IMHO that's missing anyway, IVOPTs is too much pessimized by not considering this). I'll fix it somewhen after the cauldron unless somebody beats me to it.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #49 from thopre01 at gcc dot gnu.org --- (In reply to Richard Biener from comment #48) > > From what Thomas says in comment #46 it looks like for some unknown > reason a HI load from a 1-byte aligned address is emitted: Yep that's it. Just look at log for expand in the archive Rainer posted the link to on this bug report and search for :1622. In the last step of gimple (optimized) we can just see a single load. The log doesn't show the alignment of a given load but from the code it should be correct. Best regards.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #48 from Richard Biener ---
Please provide preprocessed source for jcf-parse.c and instructions on how
to configure a cross compiler from x86_64-linux. Please also provide
disassembly around the failing place with enough context to spot it
in a cc1 generated output - best with an explanation what's wrong.
>From what Thomas says in comment #46 it looks like for some unknown
reason a HI load from a 1-byte aligned address is emitted:
(insn 688 687 689 (set (reg:HI 482)
(mem:HI (reg/v/f:SI 189 [ ptr ]) [0 MEM[base: ptr_110, offset: 0B]+0 S2
A8])) /vol/gcc/src/hg/trunk/local/gcc/java/jcf-parse.c:1622 -1
(nil))
but as the bswap pass emits a plain MEM_REF with an aligned type we should
go through the following path in expand:
if (modifier != EXPAND_WRITE
&& modifier != EXPAND_MEMORY
&& !inner_reference_p
&& mode != BLKmode
&& align < GET_MODE_ALIGNMENT (mode))
{
if ((icode = optab_handler (movmisalign_optab, mode))
!= CODE_FOR_nothing)
{
struct expand_operand ops[2];
/* We've already validated the memory, and we're creating a
new pseudo destination. The predicates really can't fail,
nor can the generator. */
create_output_operand (&ops[0], NULL_RTX, mode);
create_fixed_operand (&ops[1], temp);
expand_insn (icode, 2, ops);
temp = ops[0].value;
}
else if (SLOW_UNALIGNED_ACCESS (mode, align))
temp = extract_bit_field (temp, GET_MODE_BITSIZE (mode),
0, TYPE_UNSIGNED (TREE_TYPE (exp)),
(modifier == EXPAND_STACK_PARM
? NULL_RTX : target),
mode, mode);
that is, go through extract_bit_field (supposed sparc doesn't have
movmisalign and is SLOW_UNALIGNED_ACCESS for HImode and 8-bit align).
So we need to figure out why we don't go the above path or why
extract_bit_field gets things wrong.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #47 from Rainer Orth --- Thomas, any progress on this one? SPARC bootstrap has been broken for almost two months now (yes, there's an out-of-tree workaround, but still). Thanks. Rainer
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #46 from thopre01 at gcc dot gnu.org --- After expand, the newly created 16bit big endian load becomes: (insn 688 687 689 (set (reg:HI 482) (mem:HI (reg/v/f:SI 189 [ ptr ]) [0 MEM[base: ptr_110, offset: 0B]+0 S2 A8])) /vol/gcc/src/hg/trunk/local/gcc/java/jcf-parse.c:1622 -1 (nil)) (insn 689 688 690 (set (reg:SI 483) (ashift:SI (subreg:SI (reg:HI 482) 0) (const_int 16 [0x10]))) /vol/gcc/src/hg/trunk/local/gcc/java/jcf-parse.c:1622 -1 (nil)) (insn 690 689 0 (set (reg/v:SI 185 [ min_line ]) (lshiftrt:SI (reg:SI 483) (const_int 16 [0x10]))) /vol/gcc/src/hg/trunk/local/gcc/java/jcf-parse.c:1622 -1 (expr_list:REG_EQUAL (zero_extend:SI (reg:HI 482)) (nil))) I don't understand why those two loads. Also, the HI load is not split into 2 QI ones.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #45 from thopre01 at gcc dot gnu.org --- I only looked at differences in bswap so far and it all looks ok. It correctly detects three patterns of 16bit big endian load and replace them by 16bit unsigned loads and cast the results to int as was done in the original pattern.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #44 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #43 from thopre01 at gcc dot gnu.org --- > Thanks. In the stage before the one that fails, could you add > -fdump-tree-all-details -fdump-rtl-all-details to the command line when > compiling that jcf-parse.c file and send me an archive with all the generated > files? Another archive with trunk + Richard Biener's patch might help but > given > the time to bootstrap gcc on SPARC I'll try to find the problem only with the > broken gcc and will come back at you if I need more. I happened to have run another bootstrap with Richard's workaround patch, so I can easily include both. I'm not sure I you'll find something useful, though: jcf-parse.c is compiled during stages 2 and 3 only, and when I tried the failing java/lang/Class.java compilation with the stage2 jc1, it failed just the same. Anyway, I've placed the dumps from the stage2 compilations of jcf-parse.c at http://www.cebitec.uni-bielefeld.de/~ro/files/jcf-parse.dumps.good.tar.bz2 resp. http://www.cebitec.uni-bielefeld.de/~ro/files/jcf-parse.dumps.bad.tar.bz2 because the files are way too large (36 MB each) to upload to bugzilla. Rainer
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #43 from thopre01 at gcc dot gnu.org --- Thanks. In the stage before the one that fails, could you add -fdump-tree-all-details -fdump-rtl-all-details to the command line when compiling that jcf-parse.c file and send me an archive with all the generated files? Another archive with trunk + Richard Biener's patch might help but given the time to bootstrap gcc on SPARC I'll try to find the problem only with the broken gcc and will come back at you if I need more. Best regards.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #42 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #41 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> --- >> --- Comment #40 from thopre01 at gcc dot gnu.org --- >> Alright, change commited (r211778). Can you try another bootstrap with trunk >> to >> see if your Bus error was this bug or another one still? > > One bootstrap is already running, but I'm about to leave for a short > vacation. I'll get back to you when I've returned next tuesday. I've just started another bootstrap with the workaround omitted, and it fails again as it did before. Rainer
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #41 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #40 from thopre01 at gcc dot gnu.org --- > Alright, change commited (r211778). Can you try another bootstrap with trunk > to > see if your Bus error was this bug or another one still? One bootstrap is already running, but I'm about to leave for a short vacation. I'll get back to you when I've returned next tuesday. Rainer
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #40 from thopre01 at gcc dot gnu.org --- Alright, change commited (r211778). Can you try another bootstrap with trunk to see if your Bus error was this bug or another one still? Thanks a lot.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #39 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #38 from thopre01 at gcc dot gnu.org --- > I've just wrote a patch that solve a bug that can lead to the kind of issue > you > are running into. I'm doing more testing right now and will let you know when > it's commited if you don't mind trying another bootstrap. Thanks for your > patience. Fine. For the moment, I'm running with Richard's workaround patch to keep Solaris/SPARC bootstrapping. Thanks. Rainer
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #38 from thopre01 at gcc dot gnu.org --- I've just wrote a patch that solve a bug that can lead to the kind of issue you are running into. I'm doing more testing right now and will let you know when it's commited if you don't mind trying another bootstrap. Thanks for your patience.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #37 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #36 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> --- >> --- Comment #35 from thopre01 at gcc dot gnu.org --- >> Now that PR61306 and the bswap-2 test issue are fixed in trunk, could you try >> again a bootstrap without any of the patch you applied locally? I would >> like to >> see if this bug is a duplicate of PR61306 as supposed by Richard. > > Sure, sparc-sun-solaris2.11 bootstrap in progress. ... and fails just the same as before. Rainer
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #36 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #35 from thopre01 at gcc dot gnu.org --- > Now that PR61306 and the bswap-2 test issue are fixed in trunk, could you try > again a bootstrap without any of the patch you applied locally? I would like > to > see if this bug is a duplicate of PR61306 as supposed by Richard. Sure, sparc-sun-solaris2.11 bootstrap in progress. Rainer
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #35 from thopre01 at gcc dot gnu.org --- Now that PR61306 and the bswap-2 test issue are fixed in trunk, could you try again a bootstrap without any of the patch you applied locally? I would like to see if this bug is a duplicate of PR61306 as supposed by Richard.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #34 from Thomas Preud'homme --- Ok, committed then.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #33 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #32 from Thomas Preud'homme ---
[...]
> Are you sure the patch was applied to this test? Line 78 I have "bfin.inval =
> (struct ok) { 0x83, 0x85, 0x87, 0x89 };"
>
> The next abort about this line is under a "if (out == 0x89878583)" so would
> not
> abort either. By the way, no need to do a bootstrap again or run the whole
> testsuite to try this patch, only this test was changed.
Sorry, I've been dreaming: I'd only applied
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00294.html
and
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00295.html
With the correct patch for bswap-2.c, the test passes for
sparc-sun-solaris2.11 (both 32 and 64-bit).
Sorry for the noise.
Rainer
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #32 from Thomas Preud'homme ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #31)
> > --- Comment #30 from Thomas Preud'homme
> > ---
> > Can you run the test manually under gdb and tell me what is the value for
> > the
> > "out" variable in hex format?
>
> Sure: the -O0 test aborts at line 78, where out is
>
> (gdb) p/x out
> $11 = 0x44434241
> (gdb) p (char[4])out
> $12 = "DCBA"
>
> Rainer
Are you sure the patch was applied to this test? Line 78 I have "bfin.inval =
(struct ok) { 0x83, 0x85, 0x87, 0x89 };"
The next abort about this line is under a "if (out == 0x89878583)" so would not
abort either. By the way, no need to do a bootstrap again or run the whole
testsuite to try this patch, only this test was changed.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #31 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #30 from Thomas Preud'homme --- > Can you run the test manually under gdb and tell me what is the value for the > "out" variable in hex format? Sure: the -O0 test aborts at line 78, where out is (gdb) p/x out $11 = 0x44434241 (gdb) p (char[4])out $12 = "DCBA" Rainer
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #30 from Thomas Preud'homme --- Can you run the test manually under gdb and tell me what is the value for the "out" variable in hex format?
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #29 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #28 from Thomas Preud'homme --- > (In reply to r...@cebitec.uni-bielefeld.de from comment #22) >> > --- Comment #21 from Thomas Preud'homme > > com> --- >> > >> > There is a patch for bswap-2.c ready [0]. I'm just waiting for Andreas to >> > confirm me it works for him on m68k. I'd be interested in knowing if that >> > solves your issue as well. >> > >> > [0] https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02519.html >> >> I'm giving both patches combined a try right now, though SPARC bootstrap >> will take 7+ hours to complete. > > Did it work? The bootstrap did, but the bswap-2.c execution failures remain, although I applied both of your patches. Rainer
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #28 from Thomas Preud'homme --- (In reply to r...@cebitec.uni-bielefeld.de from comment #22) > > --- Comment #21 from Thomas Preud'homme > > --- > > > > There is a patch for bswap-2.c ready [0]. I'm just waiting for Andreas to > > confirm me it works for him on m68k. I'd be interested in knowing if that > > solves your issue as well. > > > > [0] https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02519.html > > I'm giving both patches combined a try right now, though SPARC bootstrap > will take 7+ hours to complete. Did it work?
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #27 from Richard Biener --- (In reply to Thomas Preud'homme from comment #23) > (In reply to Eric Botcazou from comment #20) > > > > > Maybe a better solution for sparc would be to add a switch for this pass > > > and > > > disable it by default on sparc. What do you think about that? > > > > There is nothing special about SPARC, it's the same for every strict > > alignment architecture supported by GCC and SLOW_UNALIGNED_ACCESS is a valid > > predicate. > > My point was two fold: > > 1) Even if the pass does nothing for unaligned access on target where this > is slow, a bunch of code is still executed to determine that the access is > unaligned (in fact most of the pass is executed before the address of the > access is known). > > 2) For some unaligned access the rewrite might be interesting, like > rewriting this: > > tab[1] | (tab [2] << 8) | (tab[3] << 16) | (tab[4] << 24) > > into this: > > *((uint32_t *) &tab[1]) > > (considering tab[0] to be 4 byte aligned) which could end up doing one 32 > bit load at addresses &tab[0], one shift and one byte load at address > &tab[4]. Yes, I think that the load may be written in non-optimal way and the expander has a better chance to produce optimal code (considering insv availability). I fear that if we install this workaround we'll never get at the actual issue (which might be just PR61306?)
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #26 from Thomas Preud'homme --- (In reply to r...@cebitec.uni-bielefeld.de from comment #25) > > Ah, I see: write-after-approval maintainers do get bugzilla write > access, but your not according to the MAINTAINERS file. Oups, my mistake, I forgot to update the file. Will do it now, thanks for reminding me.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #25 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #24 from Thomas Preud'homme --- [...] >> Please remember to add proposed patches to the URL field of the PR, >> otherwise they are easily overlooked. > > Sorry I'm not very familiar with bugzilla yet and I didn't know this was > possible. It doesn't seem I can edit anything in the PR beyond my subscription > to it and adding comments though. Have I missed something? Ah, I see: write-after-approval maintainers do get bugzilla write access, but your not according to the MAINTAINERS file. Sorry for the noise. Rainer
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #24 from Thomas Preud'homme --- (In reply to r...@cebitec.uni-bielefeld.de from comment #22) > > I'm giving both patches combined a try right now, though SPARC bootstrap > will take 7+ hours to complete. Great, thanks. > > Please remember to add proposed patches to the URL field of the PR, > otherwise they are easily overlooked. Sorry I'm not very familiar with bugzilla yet and I didn't know this was possible. It doesn't seem I can edit anything in the PR beyond my subscription to it and adding comments though. Have I missed something?
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #23 from Thomas Preud'homme --- (In reply to Eric Botcazou from comment #20) > > > Maybe a better solution for sparc would be to add a switch for this pass and > > disable it by default on sparc. What do you think about that? > > There is nothing special about SPARC, it's the same for every strict > alignment architecture supported by GCC and SLOW_UNALIGNED_ACCESS is a valid > predicate. My point was two fold: 1) Even if the pass does nothing for unaligned access on target where this is slow, a bunch of code is still executed to determine that the access is unaligned (in fact most of the pass is executed before the address of the access is known). 2) For some unaligned access the rewrite might be interesting, like rewriting this: tab[1] | (tab [2] << 8) | (tab[3] << 16) | (tab[4] << 24) into this: *((uint32_t *) &tab[1]) (considering tab[0] to be 4 byte aligned) which could end up doing one 32 bit load at addresses &tab[0], one shift and one byte load at address &tab[4].
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #22 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #21 from Thomas Preud'homme --- > (In reply to r...@cebitec.uni-bielefeld.de from comment #19) >> >> I've now regtested that patch on sparc-sun-solaris2.11 (compared to a >> bootstrap without java before) and i386-pc-solaris2.11. No regressions, >> but gcc.c-torture/execute/bswap-2.c is still failing on sparc. > > There is a patch for bswap-2.c ready [0]. I'm just waiting for Andreas to > confirm me it works for him on m68k. I'd be interested in knowing if that > solves your issue as well. > > [0] https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02519.html I'm giving both patches combined a try right now, though SPARC bootstrap will take 7+ hours to complete. Please remember to add proposed patches to the URL field of the PR, otherwise they are easily overlooked. Thanks. Rainer
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #21 from Thomas Preud'homme --- (In reply to r...@cebitec.uni-bielefeld.de from comment #19) > > I've now regtested that patch on sparc-sun-solaris2.11 (compared to a > bootstrap without java before) and i386-pc-solaris2.11. No regressions, > but gcc.c-torture/execute/bswap-2.c is still failing on sparc. There is a patch for bswap-2.c ready [0]. I'm just waiting for Andreas to confirm me it works for him on m68k. I'd be interested in knowing if that solves your issue as well. [0] https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02519.html
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #20 from Eric Botcazou --- > Also if the expression was loading a 32 bit value byte by byte then the > transformation would be useful. I'm already working on a patch to add a cost > model but this will just add more code to execute before taking the > decision. It will however prevent rewriting statements if the result will > execute slower on the target. That sounds like the right direction to me. > Maybe a better solution for sparc would be to add a switch for this pass and > disable it by default on sparc. What do you think about that? There is nothing special about SPARC, it's the same for every strict alignment architecture supported by GCC and SLOW_UNALIGNED_ACCESS is a valid predicate.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #12 from Richard Biener --- > (In reply to Eric Botcazou from comment #11) >> > So I am testing the patch right now and should be able to send it tomorrow. >> > However, the code already shall already mark the load with the actual >> > alignment the access is being done with. Therefore it seems to me that >> > something in the backend fails to split the unaligned load into several >> > aligned load. >> >> But what would be the point of this round trip exactly? > > I'd say > > Index: tree-ssa-math-opts.c > === > --- tree-ssa-math-opts.c(revision 211170) > +++ tree-ssa-math-opts.c(working copy) > @@ -2149,7 +2149,8 @@ bswap_replace (gimple stmt, gimple_stmt_ >unsigned align; > >align = get_object_alignment (src); > - if (bswap && SLOW_UNALIGNED_ACCESS (TYPE_MODE (load_type), align)) > + if (align < GET_MODE_ALIGNMENT (TYPE_MODE (load_type)) > + && SLOW_UNALIGNED_ACCESS (TYPE_MODE (load_type), align)) > return false; > >/* Compute address to load from and cast according to the size > > is obvious (and pre-approved). I've now regtested that patch on sparc-sun-solaris2.11 (compared to a bootstrap without java before) and i386-pc-solaris2.11. No regressions, but gcc.c-torture/execute/bswap-2.c is still failing on sparc. Since it seems a non-workaround patch is now forthcoming, I'll hold off on installing it, but instead keep it local for the moment. Thanks. Rainer
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #18 from Thomas Preud'homme ---
(In reply to Eric Botcazou from comment #16)
> > unsigned int foo (unsigned short *x)
> > {
> > return x[0] << 16 | x[1];
> > }
> >
> > [...]
> > gets you
> >
> > foo:
> > lduh[%o0], %g1
> > lduh[%o0+2], %o0
> > sll %g1, 16, %g1
> > jmp %o7+8
> > or %o0, %g1, %o0
> >
> > which looks perfect to me.
>
> Indeed, but after having gone through a perfectly useless transformation and
> wasted cycles. This reminds me of the ipa-split + inlining round trip.
>
> Really SPARC machines aren't fast enough to allow such a silliness...
Fair enough but the information about alignment is only available late in the
pass so that most of the code is already executed. Only when the whole OR
expression has been processed do we know what is the lowest address and the
range of the memory access and therefore whether that access is aligned or not.
Also if the expression was loading a 32 bit value byte by byte then the
transformation would be useful. I'm already working on a patch to add a cost
model but this will just add more code to execute before taking the decision.
It will however prevent rewriting statements if the result will execute slower
on the target.
Maybe a better solution for sparc would be to add a switch for this pass and
disable it by default on sparc. What do you think about that?
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #17 from Thomas Preud'homme --- (In reply to Richard Biener from comment #12) > > I'd say > > Index: tree-ssa-math-opts.c > === > --- tree-ssa-math-opts.c(revision 211170) > +++ tree-ssa-math-opts.c(working copy) > @@ -2149,7 +2149,8 @@ bswap_replace (gimple stmt, gimple_stmt_ >unsigned align; > >align = get_object_alignment (src); > - if (bswap && SLOW_UNALIGNED_ACCESS (TYPE_MODE (load_type), align)) > + if (align < GET_MODE_ALIGNMENT (TYPE_MODE (load_type)) > + && SLOW_UNALIGNED_ACCESS (TYPE_MODE (load_type), align)) > return false; > >/* Compute address to load from and cast according to the size > > is obvious (and pre-approved). Alright but tests need to be modified to add an xfail for target impacted by this. I did such a change and also rewrote the tests to use aligned variable as much as possible so that they are more meaningful on STRICT_ALIGNMENT targets. I'll post it for review today (at least for the changes in the testsuite).
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #16 from Eric Botcazou ---
> unsigned int foo (unsigned short *x)
> {
> return x[0] << 16 | x[1];
> }
>
> [...]
> gets you
>
> foo:
> lduh[%o0], %g1
> lduh[%o0+2], %o0
> sll %g1, 16, %g1
> jmp %o7+8
> or %o0, %g1, %o0
>
> which looks perfect to me.
Indeed, but after having gone through a perfectly useless transformation and
wasted cycles. This reminds me of the ipa-split + inlining round trip.
Really SPARC machines aren't fast enough to allow such a silliness...
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #15 from Richard Biener ---
Btw, unpatched and with a cross to sparc-linux (didn't figure out a working
solaris triplet that builds) and
unsigned int foo (unsigned short *x)
{
return x[0] << 16 | x[1];
}
I see
32 bit load in host endianness found at: _8 = (int) load_dst_11;
foo (short unsigned int * x)
{
short unsigned int _3;
int _4;
int _5;
short unsigned int _6;
int _7;
int _8;
unsigned int _9;
short unsigned int * load_src_10;
unsigned int load_dst_11;
:
_3 = *x_2(D);
_4 = (int) _3;
_5 = _4 << 16;
_6 = MEM[(short unsigned int *)x_2(D) + 2B];
_7 = (int) _6;
load_src_10 = x_2(D);
load_dst_11 = MEM[(short unsigned int *)load_src_10];
_8 = (int) load_dst_11;
_9 = (unsigned int) _8;
return _9;
expanding from
:
load_dst_11 = MEM[(short unsigned int *)x_2(D)];
return load_dst_11;
gets you
foo:
lduh[%o0], %g1
lduh[%o0+2], %o0
sll %g1, 16, %g1
jmp %o7+8
or %o0, %g1, %o0
which looks perfect to me.
So it must be sth else that breaks the libjava case?
Can someone please provide preprocessed source for jcf-parse.c and
point out the error in the assembly at least?
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #14 from Richard Biener --- (In reply to Richard Biener from comment #12) > (In reply to Eric Botcazou from comment #11) > > > So I am testing the patch right now and should be able to send it > > > tomorrow. > > > However, the code already shall already mark the load with the actual > > > alignment the access is being done with. Therefore it seems to me that > > > something in the backend fails to split the unaligned load into several > > > aligned load. > > > > But what would be the point of this round trip exactly? > > I'd say > > Index: tree-ssa-math-opts.c > === > --- tree-ssa-math-opts.c(revision 211170) > +++ tree-ssa-math-opts.c(working copy) > @@ -2149,7 +2149,8 @@ bswap_replace (gimple stmt, gimple_stmt_ >unsigned align; > >align = get_object_alignment (src); > - if (bswap && SLOW_UNALIGNED_ACCESS (TYPE_MODE (load_type), align)) > + if (align < GET_MODE_ALIGNMENT (TYPE_MODE (load_type)) > + && SLOW_UNALIGNED_ACCESS (TYPE_MODE (load_type), align)) > return false; > >/* Compute address to load from and cast according to the size > > is obvious (and pre-approved). obvious as a workaround, that is.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #13 from Richard Biener --- (In reply to Thomas Preud'homme from comment #10) > So I am testing the patch right now and should be able to send it tomorrow. > However, the code already shall already mark the load with the actual > alignment the access is being done with. Therefore it seems to me that > something in the backend fails to split the unaligned load into several > aligned load. Could you break after the line align = get_object_alignment > (src); in tree-ssa-math-opts.c when compiling gcc/java/jcf-parse.c in stage > 1 (I suppose it breaks in stage 2)? > > What does print align gives? What about print load_type->type_common.align ? > > Best regards. The question is more like what happens in expand_assignment, that is, why don't we go the extract_bit_field codepath.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #12 from Richard Biener --- (In reply to Eric Botcazou from comment #11) > > So I am testing the patch right now and should be able to send it tomorrow. > > However, the code already shall already mark the load with the actual > > alignment the access is being done with. Therefore it seems to me that > > something in the backend fails to split the unaligned load into several > > aligned load. > > But what would be the point of this round trip exactly? I'd say Index: tree-ssa-math-opts.c === --- tree-ssa-math-opts.c(revision 211170) +++ tree-ssa-math-opts.c(working copy) @@ -2149,7 +2149,8 @@ bswap_replace (gimple stmt, gimple_stmt_ unsigned align; align = get_object_alignment (src); - if (bswap && SLOW_UNALIGNED_ACCESS (TYPE_MODE (load_type), align)) + if (align < GET_MODE_ALIGNMENT (TYPE_MODE (load_type)) + && SLOW_UNALIGNED_ACCESS (TYPE_MODE (load_type), align)) return false; /* Compute address to load from and cast according to the size is obvious (and pre-approved).
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #11 from Eric Botcazou --- > So I am testing the patch right now and should be able to send it tomorrow. > However, the code already shall already mark the load with the actual > alignment the access is being done with. Therefore it seems to me that > something in the backend fails to split the unaligned load into several > aligned load. But what would be the point of this round trip exactly?
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #10 from Thomas Preud'homme --- So I am testing the patch right now and should be able to send it tomorrow. However, the code already shall already mark the load with the actual alignment the access is being done with. Therefore it seems to me that something in the backend fails to split the unaligned load into several aligned load. Could you break after the line align = get_object_alignment (src); in tree-ssa-math-opts.c when compiling gcc/java/jcf-parse.c in stage 1 (I suppose it breaks in stage 2)? What does print align gives? What about print load_type->type_common.align ? Best regards.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #9 from Thomas Preud'homme --- Sorry, I didn't realize it was preventing bootstrap. I have a small patch that disable the optimization for STRICT_ALIGNMENT target but was reluctant to use it as is because this effectively disable this optimization for ARM. But given the situation the patch could be applied temporarily to avoid the bootstrap failure and a better solution be commited later.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #8 from Eric Botcazou --- > Sure, I'll push a patch for this as soon as I finish fixing the regressions > that poped up due to the change I made to the bswap pass. While you're at it, could you change all the references in the code (as well as the ChangeLog) to "host endianness", which is mightily confusing in a compiler? By definition a compiler generates code for a target, not for a host.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> --- >> --- Comment #1 from Richard Biener --- >> gcc/java/jcf.h:#define GET_u2(PTR) (((PTR)[0] << 8) | ((PTR)[1])) >> >> smells like >> >> 2014-05-23 Thomas Preud'homme >> >> PR tree-optimization/54733 >> * tree-ssa-math-opts.c (nop_stats): New "bswap_stats" structure. >> ... > > I've now confirmed that this patch is indeed the culprit. Thomas, any progress on fixing this regression? SPARC bootstrap is broken for a week now. Thanks. Rainer
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #6 from Thomas Preud'homme --- Sure, I'll push a patch for this as soon as I finish fixing the regressions that poped up due to the change I made to the bswap pass.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE --- Thomas, btw, I noticed that you use duplicate dg-options in gcc.dg/optimize-bswapsi-[12].c. Please use dg-additional-options for the s390-*-* case to avoid the duplication. Thanks. Rainer
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Richard Biener --- > gcc/java/jcf.h:#define GET_u2(PTR) (((PTR)[0] << 8) | ((PTR)[1])) > > smells like > > 2014-05-23 Thomas Preud'homme > > PR tree-optimization/54733 > * tree-ssa-math-opts.c (nop_stats): New "bswap_stats" structure. > ... I've now confirmed that this patch is indeed the culprit. Rainer
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-26 Ever confirmed|0 |1 --- Comment #3 from Eric Botcazou --- > The load may be converted to unaligned - does sparc-solaris properly handle > unaligned (non-vector) loads? No, all SPARC-based platforms are strict-alignment.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #2 from Richard Biener --- The load may be converted to unaligned - does sparc-solaris properly handle unaligned (non-vector) loads?
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 Richard Biener changed: What|Removed |Added CC||thomas.preudhomme at arm dot com --- Comment #1 from Richard Biener --- gcc/java/jcf.h:#define GET_u2(PTR) (((PTR)[0] << 8) | ((PTR)[1])) smells like 2014-05-23 Thomas Preud'homme PR tree-optimization/54733 * tree-ssa-math-opts.c (nop_stats): New "bswap_stats" structure. ...
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 Rainer Orth changed: What|Removed |Added Target Milestone|--- |4.10.0
