This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Powerpc Linux build fails


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]