This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/51821] [4.5/4.6/4.7 Regression] 64bit > 32bit conversion produces incorrect results with optimizations
- From: "ubizjak at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 11 Jan 2012 22:34:41 +0000
- Subject: [Bug rtl-optimization/51821] [4.5/4.6/4.7 Regression] 64bit > 32bit conversion produces incorrect results with optimizations
- Auto-submitted: auto-generated
- References: <bug-51821-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51821
Uros Bizjak <ubizjak at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |NEW
--- Comment #8 from Uros Bizjak <ubizjak at gmail dot com> 2012-01-11 22:34:41 UTC ---
It looks like target issue after all. I'm preparing a patch with following
comment to a peephole2 that calls ix86_split_ashl:
Index: i386.md
===================================================================
--- i386.md (revision 183054)
+++ i386.md (working copy)
@@ -8939,11 +8939,17 @@
;; values are manipulated, registers are already at a premium. But if
;; we have one handy, we won't turn it away.
+;; ??? Immediate operands should not be allowed for operand 1 predicate.
+;; In case one of high/low registers in register pair is unused, then
+;; nothing prevents peephole2 pass from allocating this unused register
+;; as scratch register. Output register pair always matches operand 1
+;; input register pair, so register_operand operand 1 predicate is safe.
+
(define_peephole2
[(match_scratch:DWIH 3 "r")
(parallel [(set (match_operand:<DWI> 0 "register_operand" "")
(ashift:<DWI>
- (match_operand:<DWI> 1 "nonmemory_operand" "")
+ (match_operand:<DWI> 1 "register_operand" "")
(match_operand:QI 2 "nonmemory_operand" "")))
(clobber (reg:CC FLAGS_REG))])
(match_dup 3)]