Bug 27968 - gcc emits (undefined) ffreep opcode which is not understood by Solaris' /usr/ccs/bin/as when tuning for Athlon or Opteron CPUs
Summary: gcc emits (undefined) ffreep opcode which is not understood by Solaris' /usr/...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.1.1
: P3 normal
Target Milestone: 4.2.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-06-08 23:58 UTC by Eric Northup
Modified: 2006-10-05 15:44 UTC (History)
1 user (show)

See Also:
Host: i386-pc-solaris2.11
Target: i386-pc-solaris2.11
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Northup 2006-06-08 23:58:05 UTC
GCC emits the (undefined) instruction ffreep when TARGET_USE_FFREEP is set (which happens when -mtune opteron or -mtune athlon is passed on the command line.

As of the latest available build, Solaris' /usr/ccs/bin/as doesn't understand this opcode and barfs.

The use of ffreep seems to have been introduced and discussed in this thread: http://gcc.gnu.org/ml/gcc-patches/2002-11/msg01386.html.
Comment 1 Andrew Pinski 2006-06-09 00:05:07 UTC
One thing is to use GNU binutil's as instead.  The other thing to do is to file a bug with Sun (which is better anyways).
Comment 2 Andrew Pinski 2006-06-09 05:37:59 UTC
First off this instruction has been in x87 since at least 287, see
http://www.sandpile.org/post/msgs/20000234.htm.
Comment 3 Eric Northup 2006-06-10 18:01:18 UTC
Subject: Re:  gcc emits (undefined) ffreep opcode which
	is not understood by Solaris' /usr/ccs/bin/as when tuning for Athlon or
	Opteron CPUs

> ------- Comment #1 from pinskia at gcc dot gnu dot org  2006-06-09 00:05 -------
> One thing is to use GNU binutil's as instead.  The other thing to do is to file
> a bug with Sun (which is better anyways).

I have filed a bug with Sun.  But I think it would be good to fix gcc too.

Jan Hubicka's comment on the adding the ffreep support to gcc was:

"The instruction is not documented by IA-32 description, but all CPUs in existence support it and majorty of assemblers seems to know it too.  In case we will hit assembler that don't I will add configure script code for that."


I also question if it is a mistake for gcc to emit this opcode so readily.  Quoting the Intel IA-32 manual: "all blanks in the opcode map are reserved and should not be used.  Do not depend on the operation on these undefined opcodes" (this is below the opcode map, where the row for ffreep is blank).

-Eric

Comment 4 Roger Sayle 2006-07-07 00:13:23 UTC
Subject: Bug 27968

Author: sayle
Date: Fri Jul  7 00:13:14 2006
New Revision: 115237

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115237
Log:

	PR target/27968
	* configure.ac (HAVE_AS_IX86_FFREEP): On x86 targets check whether 
	the configured assembler supports the x87's ffreep mnemonic.
	* configure: Regenerate.
	* config.in: Regenerate.

	* config/i386/i386.c (output_387_ffreep): New function.
	(output_fp_compare): Use output_387_ffreep to emit ffreep insns.
	(output_387_reg_move): Likewise.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config.in
    trunk/gcc/config/i386/i386.c
    trunk/gcc/configure
    trunk/gcc/configure.ac

Comment 5 Andrew Pinski 2006-10-05 15:44:06 UTC
Fixed.