From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21926 invoked by alias); 23 Aug 2005 20:48:21 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 21902 invoked by uid 48); 23 Aug 2005 20:48:17 -0000 Date: Tue, 23 Aug 2005 20:56:00 -0000 Message-ID: <20050823204817.21901.qmail@sourceware.org> From: "rth at gcc dot gnu dot org" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20041226201629.19161.rth@gcc.gnu.org> References: <20041226201629.19161.rth@gcc.gnu.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug target/19161] No emms or femms emitted between MMX and FP instructions X-Bugzilla-Reason: CC X-SW-Source: 2005-08/txt/msg02731.txt.bz2 List-Id: ------- Additional Comments From rth at gcc dot gnu dot org 2005-08-23 20:48 ------- So, I fixed another case in which we could die in create_pre_exit having to do with complex return values. But past that, there are failures that are completely within optimize_mode_switching, e.g. execute/20050604-1.c. $ ./cc1 -m32 -march=pentium4 z.c foo z.c: In function ‘foo’: z.c:28: error: unable to find a register to spill in class ‘MMX_REGS’ z.c:28: error: this is the insn: (insn 14 63 15 2 (set (reg:V4HI 61 [ D.1620 ]) (mem/s/j:V4HI (symbol_ref:SI ("u") ) [0 u.v+0 S8 A64])) 994 {*movv4hi_internal} (nil) (nil)) The problem is that we have a CFG like +--+ v | 1->2->3->4 and we place the efpu insn in block 2, but the emms insn in block 4. Aside from being Less Than Ideal, this results in BOTH mmx and fpu registers live around the loop, which means we can't allocate anything. Uros, you should bootstrap i386 with --with-arch=foo, where foo is whatever machine you have that supports at least mmx. Otherwise, you're not actually testing this new code on i386 except for the few test cases that force an -march or -mmx option. I'll keep looking at it for a bit to see if its something simple, but we're not going to overhaul optimize_mode_switching for 4.1 if it's something complicated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19161