This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/50788] [4.7 Regression] ICE: in merge_overlapping_regs, at regrename.c:318 with -mavx -fpeel-loops -fstack-protector-all and __builtin_ia32_maskloadpd256
- From: "ebotcazou at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sun, 23 Oct 2011 11:27:22 +0000
- Subject: [Bug target/50788] [4.7 Regression] ICE: in merge_overlapping_regs, at regrename.c:318 with -mavx -fpeel-loops -fstack-protector-all and __builtin_ia32_maskloadpd256
- Auto-submitted: auto-generated
- References: <bug-50788-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50788
--- Comment #6 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-10-23 11:27:22 UTC ---
> It is OK for expanders to have match_dup. We just don't want to have
> post-reload passes to trip on double-output to the same register.
No disagreement. I just wanted to state the argument for the + approach, but
the manual clearly points to the match_operand approach here instead.
> BTW: There is another spot with similar problem:
>
> @@ -8011,7 +8011,8 @@
> [(set (mem:V16QI (match_operand:P 0 "register_operand" "D"))
> (unspec:V16QI [(match_operand:V16QI 1 "register_operand" "x")
> (match_operand:V16QI 2 "register_operand" "x")
> - (mem:V16QI (match_dup 0))]
> + (mem:V16QI
> + (match_operand:P 3 "register_operand" "0"))]
> UNSPEC_MASKMOV))]
> "TARGET_SSE2"
> "%vmaskmovdqu\t{%2, %1|%1, %2}"
>
> While compilation won't break here, IMO we should tell the reload that we have
> matching constraint.
Indeed.