public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Alan Modra <amodra@bigpond.net.au>
To: Keith Pickens <ksp@securelogix.com>,
	Geoff Keating <geoffk@geoffk.org>,
	David Edelsohn <dje@watson.ibm.com>
Cc: binutils@sources.redhat.com, bug-binutils@gnu.org
Subject: Re: Powerpc Linux build fails
Date: Wed, 19 May 2004 03:30:00 -0000	[thread overview]
Message-ID: <20040519033008.GC12690@bubble.modra.org> (raw)
In-Reply-To: <3A3FC75F7C72D711A7DC009027AC9C4B1788D9@jupiter>

On Tue, May 18, 2004 at 11:06:00AM -0500, Keith Pickens wrote:
> 
> Sorry, I wasn't saying the change was wrong but rather that it
> has a side effect that broke builds that have worked for a
> long time.
[snip]

You're correct.  You're also using the correct -mcpu option to enable
AltiVec.  The trouble is that gcc doesn't pass -maltivec or -m7400 on to
gas, but instead just passes -mppc.  See gcc/config/rs6000/rs6000.h
ASM_CPU_SPEC.  Fixing gcc to pass the right options is probably the
right thing to do, but in the meantime we have released versions of
gcc that should work with newer binutils.  I'm inclined to make gas
behave as if -many was given, ie. accept any recognizable powerpc
instruction.

Geoff, what do you think?

opcodes/ChangeLog
	* ppc-opc.c (insert_fxm): Enable two operand mfcr when -many as
	well as when -mpower4.
gas/ChangeLog
	* config/tc-ppc.c (parse_cpu): Set PPC_OPCODE_ANY on all valid
	options besides a new -mstrict option.
	(md_show_usage): Update.  Correct capitalization.
	(ppc_arch): Expand comment.
	* doc/c-ppc.texi (PowerPC-Opts): Update.

Index: opcodes/ppc-opc.c
===================================================================
RCS file: /cvs/src/src/opcodes/ppc-opc.c,v
retrieving revision 1.70
diff -u -p -r1.70 ppc-opc.c
--- opcodes/ppc-opc.c	5 May 2004 13:43:36 -0000	1.70
+++ opcodes/ppc-opc.c	19 May 2004 03:21:05 -0000
@@ -1004,8 +1004,13 @@ insert_fxm (unsigned long insn,
 
   /* If only one bit of the FXM field is set, we can use the new form
      of the instruction, which is faster.  Unlike the Power4 branch hint
-     encoding, this is not backward compatible.  */
-  else if ((dialect & PPC_OPCODE_POWER4) != 0 && (value & -value) == value)
+     encoding, this is not backward compatible.  Do not generate the
+     new form unless -mpower4 has been given, or -many and the two
+     operand form of mfcr was used.  */
+  else if ((value & -value) == value
+	   && ((dialect & PPC_OPCODE_POWER4) != 0
+	       || ((dialect & PPC_OPCODE_ANY) != 0
+		   && (insn & (0x3ff << 1)) == 19 << 1)))
     insn |= 1 << 20;
 
   /* Any other value on mfcr is an error.  */
Index: gas/config/tc-ppc.c
===================================================================
RCS file: /cvs/src/src/gas/config/tc-ppc.c,v
retrieving revision 1.88
diff -u -p -r1.88 tc-ppc.c
--- gas/config/tc-ppc.c	6 May 2004 11:01:48 -0000	1.88
+++ gas/config/tc-ppc.c	19 May 2004 03:20:55 -0000
@@ -913,10 +913,18 @@ parse_cpu (const char *arg)
     ppc_cpu = PPC_OPCODE_COMMON | PPC_OPCODE_32;
   /* -many means to assemble for any architecture (PWR/PWRX/PPC).  */
   else if (strcmp (arg, "any") == 0)
-    ppc_cpu |= PPC_OPCODE_ANY;
+    ;
+  /* -mstrict is the inverse of -many.  All other cpu options set
+     PPC_OPCODE_ANY, so this should be specified last.  */
+  else if (strcmp (arg, "strict") == 0)
+    {
+      ppc_cpu &= ~PPC_OPCODE_ANY;
+      return 1;
+    }
   else
     return 0;
 
+  ppc_cpu |= PPC_OPCODE_ANY;
   return 1;
 }
 
@@ -1100,14 +1108,15 @@ PowerPC options:\n\
 -mbooke64		generate code for 64-bit PowerPC BookE\n\
 -mbooke, mbooke32	generate code for 32-bit PowerPC BookE\n\
 -mpower4		generate code for Power4 architecture\n\
--mcom			generate code Power/PowerPC common instructions\n\
--many			generate code for any architecture (PWR/PWRX/PPC)\n"));
+-mcom			generate code Power/PowerPC common instructions\n"));
   fprintf (stream, _("\
 -maltivec		generate code for AltiVec\n\
 -me500, -me500x2	generate code for Motorola e500 core complex\n\
 -mspe			generate code for Motorola SPE instructions\n\
--mregnames		Allow symbolic names for registers\n\
--mno-regnames		Do not allow symbolic names for registers\n"));
+-many			accept instructions for other cpus\n\
+-mstrict		do not accept instructions for other cpus\n\
+-mregnames		allow symbolic names for registers\n\
+-mno-regnames		do not allow symbolic names for registers\n"));
 #ifdef OBJ_ELF
   fprintf (stream, _("\
 -mrelocatable		support for GCC's -mrelocatble option\n\
@@ -1156,7 +1165,8 @@ ppc_set_cpu ()
     }
 }
 
-/* Figure out the BFD architecture to use.  */
+/* Figure out the BFD architecture to use.  This function and ppc_mach
+   are called well before md_begin, when the output file is opened.  */
 
 enum bfd_architecture
 ppc_arch ()
Index: gas/doc/c-ppc.texi
===================================================================
RCS file: /cvs/src/src/gas/doc/c-ppc.texi,v
retrieving revision 1.4
diff -u -p -r1.4 c-ppc.texi
--- gas/doc/c-ppc.texi	22 Nov 2003 06:14:48 -0000	1.4
+++ gas/doc/c-ppc.texi	19 May 2004 03:20:56 -0000
@@ -77,7 +77,12 @@ Generate code for Power4 architecture.
 Generate code Power/PowerPC common instructions.
 
 @item -many
-Generate code for any architecture (PWR/PWRX/PPC).
+Accept instructions for cpus other than the current -m option in
+force.  This is the default.
+
+@item -mstrict
+Do no accept instructions for cpus other than the current -m option in
+force.  This must be specified after other code generation options.
 
 @item -mregnames
 Allow symbolic names for registers.

> > -----Original Message-----
> > From: Ian Lance Taylor
> > Sent: Monday, May 17, 2004 12:04 PM
> > To: Keith Pickens
> > Cc: 'bug-binutils@gnu.org'
> > Subject: Re: Powerpc Linux build fails
> > 
> > 
> > Keith Pickens <ksp@securelogix.com> writes:
> > 
> > > A recent change to opcodes/ppc-opc.c breaks powerpc kernel builds:
> > > 
> > > 2004-05-05  Alan Modra  <amodra@bigpond.net.au>
> > > 
> > >         PR 146.

Oops, actually PR 147.

> > >         * ppc-opc.c (PPCVEC): Remove PPC_OPCODE_PPC.
> > > 
> > > This change appears to remove the default AltiVec support 
> > which is required
> > > for ppc
> > > kernel builds.
> > 
> > How is your compiler configured?
> > 
> > Altivec instructions shouldn't be supported by default, since they are
> > not supported on all PowerPC chips.  You can use -maltivec to turn on
> > Altivec support, or you can use a toolchain for which the default CPU
> > includes Altivec support.  There may be a bug, of course, but Alan's
> > specific change appears clearly correct.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

       reply	other threads:[~2004-05-19  3:30 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3A3FC75F7C72D711A7DC009027AC9C4B1788D9@jupiter>
2004-05-19  3:30 ` Alan Modra [this message]
2004-05-19  4:27   ` Geoff Keating
2004-05-19  5:10     ` Alan Modra
2004-05-19 16:24       ` Kumar Gala
2004-05-20  0:44         ` Alan Modra
     [not found] <44D2755E.9020600@us.ibm.com>
2006-08-04  1:30 ` Link problems with section anchors Alan Modra
2006-08-04  9:04   ` Richard Sandiford
2006-08-04 13:53     ` Steven Munroe
2006-08-04 13:54     ` David Edelsohn
2006-08-04 14:01       ` Richard Sandiford
2006-08-04 14:12         ` David Edelsohn
     [not found] <087e01c3b5da$77d658e0$0202040a@catdog>
2003-11-29  1:42 ` ppc problem with .rodata.str1.4. binutils requirement for gcc 3.3.1? Alan Modra
2003-11-29 18:14   ` Kris Warkentin
2001-12-31 19:09 Compiling kernel 2.4.17 fails at link stage Krishnakumar B
2002-01-04  3:50 ` Alan Modra
2002-01-04 12:39   ` [Linux-ia64] " Alan Modra
  -- strict thread matches above, loose matches on Subject: below --
2001-10-24 18:26 Release 2.12 Hans-Peter Nilsson
2001-10-24 18:38 ` Alan Modra
2001-10-24 18:43   ` David O'Brien
2001-10-24 19:30     ` Alan Modra
2001-10-24 19:35       ` MMIX (was: Re: Release 2.12) Hans-Peter Nilsson
2001-10-24 21:45       ` Release 2.12 Eric Christopher
2001-10-25  8:41         ` H . J . Lu
2001-10-25  8:47       ` H . J . Lu
2001-10-24 18:49   ` Daniel Jacobowitz
2001-10-24 19:43     ` Alan Modra
2001-10-24 20:10       ` Daniel Jacobowitz
2001-10-24 20:35         ` Alan Modra
2001-10-24 20:44           ` Daniel Jacobowitz
2001-10-25  5:09         ` Christopher C. Chimelis
2001-10-25  1:56       ` Philip Blundell
2001-10-25  8:30         ` H . J . Lu
2001-10-25  8:47           ` David O'Brien
     [not found]       ` <amodra@bigpond.net.au>
2002-01-04 17:42         ` [Linux-ia64] Compiling kernel 2.4.17 fails at link stage Grant Grundler
2002-01-04 17:59           ` H . J . Lu
2002-01-04 20:37             ` Grant Grundler
2002-01-04 22:39               ` H . J . Lu
2002-01-07 12:52                 ` Grant Grundler
2002-01-04 19:21           ` Alan Modra
2003-11-29  2:33         ` ppc problem with .rodata.str1.4. binutils requirement for gcc 3.3.1? David Edelsohn
2003-11-29  3:05           ` Alan Modra
2003-11-29  4:06         ` David Edelsohn
2003-11-29  4:10           ` Andrew Pinski
2003-11-29  4:20             ` David Edelsohn
2003-11-29  6:47               ` Alan Modra
2003-11-29 19:40         ` David Edelsohn
2004-05-19 15:19         ` Powerpc Linux build fails David Edelsohn
2004-05-20  0:39           ` Alan Modra
2004-05-20  1:24             ` Alan Modra
2004-05-20  1:46               ` Alan Modra
2004-05-20  2:29         ` David Edelsohn
2004-05-20  3:10           ` Alan Modra
2006-08-04  1:49         ` Link problems with section anchors David Edelsohn
2006-08-04  2:04           ` Alan Modra
2001-10-24 19:37   ` Release 2.12 Russ Allbery
2001-10-24 19:52     ` Alan Modra
2001-10-25  0:46 ` H . J . Lu
2001-10-25  8:57   ` David O'Brien
2001-10-25  9:38     ` H . J . Lu
2001-10-25  9:44       ` H . J . Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040519033008.GC12690@bubble.modra.org \
    --to=amodra@bigpond.net.au \
    --cc=binutils@sources.redhat.com \
    --cc=bug-binutils@gnu.org \
    --cc=dje@watson.ibm.com \
    --cc=geoffk@geoffk.org \
    --cc=ksp@securelogix.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).