From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16784 invoked by alias); 15 Nov 2012 17:05:43 -0000 Received: (qmail 16652 invoked by uid 48); 15 Nov 2012 17:05:21 -0000 From: "kl4yfd at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/44578] GCC generates MMX instructions but fails to generate "emms" Date: Thu, 15 Nov 2012 17:05:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: kl4yfd at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-11/txt/msg01433.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44578 --- Comment #6 from kl4yfd at gmail dot com 2012-11-15 17:05:16 UTC --- (In reply to comment #5) > Using mmX as global registers variables is a user bug if you ever call > something that might be using FPU stack, because the registers can't be > preserved across that. Don't do that. When running x86 in protected mode, you are right. User-error. This is not for an error within the binary, rather an issue with the processor state left-over after executable is finished. For those of us not running in a protected mode / OS environment, ending a binary execution that calls mmX instructions and does not issue emms leaves the FPU essentially disabled. One should never have to manually insert the opcodes 0F 77 into the binary for proper inter-binary execution in a non-protected mode x86 environment and the FPU being enabled should be the default assumption. The example file is only to show that gcc has 3 bugs in its current mmx handling: - will auto-generate mmX opcodes, then not auto-generate the emms OP. - mmX opcodes were generated without the -mmmx flag. - when -mmmx flag is used, emms OP is not inserted by default before return. OK. Why not? -- Implementing this would be a great catch-all solution for many problems associated with drivers, embedded, or the compiler using mmx OPs/registers/inline-asm then not inserting an emms OP before returning. ^^ this will probably require some discussion ^^ If GCC is going to allow neat-features like global register variables, then it needs to be checked to ensure they are properly used. ---------------------- - This is part of the fix (mostly real code...) - Also a similar check is needed whereever something that generates mmX OPs is used. (like scoped mmX register variables) etc - This does not address the fact that no emms is generated. That should be covered by the catch-all -mmmx flag usage auto-inserts emms opcode @ binary end. -- If that ends up being the solution. === From gcc/varasm.c | line:1209 | gcc 4.7.2 === /* First detect errors in declaring global registers. */ if (reg_number == -1) error ("register name not specified for %q+D", decl); /// New PsuedoCode else if (MMX_REGNO_P(reg_number) ) { if ( !(-mmmx) ) error ("mmx register usage requires -mmmx flag for %q+D", decl); if ( !(-mfpmath=sse) ) error ("mmx register usage requires -mfpmath=sse flag for %q+D", decl); /// } else if (reg_number < 0) error ("invalid register name for %q+D", decl); else if (mode == BLKmode) error ("data type of %q+D isn%'t suitable for a register", decl);