[Bug c/16259] New: gcc pass unconditionaly "-many" to the assembler

[Bug c/16259] New: gcc pass unconditionaly "-many" to the assembler

[jdubois at mc dot com]

I generated a gcc crosscompiler for PPC 7400 using a sparc Solaris 2.8 system 
as the host. For the record, in order to compile the all tool chain I used Dan 
kegel "crosstool" script (crosstool-0.28-rc25). This script applies some 
patches to GCC 3.4.0. in particular it applies a patch to 
gcc/config/rs6000/rs6000.h where it adds (amon other things) an unconditional 
-many option to be passed to the assembler. By browsing the GCC CVS it appears 
that this patch is now part of mainline. 
 
I selected the following components to build my crosstool chain: 
GCC 3.4.O 
BINUTILS 2.14 
GLIBC 2.3.2 
 
My crosstool chain was configured with the following "configure" command: 
 
/export/home/jdubois/crosstool-0.28-rc25/build/powerpc-7400-linux-gnu/gcc-3.4.0-glibc-2.3.2/gcc-3.4.0/configure 
--target=powerpc-7400-linux-gnu --host=sparc-host_sun-solaris2.8 
--prefix=/vobs/target_tools/sparc-unknown-solaris-gnu/powerpc-7400-linux-gnu/gcc-3.4.0-glibc-2.3.2 
--with-cpu=7400 --enable-altivec 
--with-headers=/vobs/target_tools/sparc-unknown-solaris-gnu/powerpc-7400-linux-gnu/gcc-3.4.0-glibc-2.3.2/powerpc-7400-linux-gnu/include 
--with-local-prefix=/vobs/target_tools/sparc-unknown-solaris-gnu/powerpc-7400-linux-gnu/gcc-3.4.0-glibc-2.3.2/powerpc-7400-linux-gnu 
--disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit 
--enable-languages=c,c++ --enable-shared --enable-c99 --enable-long-long 
Thread model: posix 
gcc version 3.4.0 
 
When compiling the Linux kernel (2.6.2) with this crosstool chain from Solaris 
for PPC 7400 target, the compilation will fail on arch/ppc/kernel/time.c. This 
is because the get_tbl() and get_tbu() functions (defined in 
include/asm-ppc/time.h) are PPC specific. They are defiend as follow: 
 
extern __inline__ unsigned long get_tbl(void) { 
        unsigned long tbl; 
#if defined(CONFIG_403GCX) 
        asm volatile("mfspr %0, 0x3dd" : "=r" (tbl)); 
#else 
        asm volatile("mftb %0" : "=r" (tbl)); 
#endif 
        return tbl; 
} 
 
extern __inline__ unsigned long get_tbu(void) { 
        unsigned long tbl; 
#if defined(CONFIG_403GCX) 
        asm volatile("mfspr %0, 0x3dc" : "=r" (tbl)); 
#else 
        asm volatile("mftbu %0" : "=r" (tbl)); 
#endif 
        return tbl; 
} 
 
These function are "translated" in the .i file as follow: 
 
extern __inline__ __attribute__((always_inline)) unsigned long get_tbl(void) { 
 unsigned long tbl; 
 
 asm volatile("mftb %0" : "=r" (tbl)); 
 
 return tbl; 
} 
 
extern __inline__ __attribute__((always_inline)) unsigned long get_tbu(void) { 
 unsigned long tbl; 
 
 asm volatile("mftbu %0" : "=r" (tbl)); 
 
 return tbl; 
} 
 
And then the .s file generated from this will contain some fragments looking as 
follow: 
 
#APP 
        mftb 0 
#NO_APP 
 
.... 
 
#APP 
        mftbu 0 
        mftb 6 
        mftbu 11 
#NO_APP 
 
So it looks like the "mftbX" opcode are not valid on PPC403. When compiling the 
Linux kernel for PPC7400, the "mftbX" version of the functions are selected and 
the resulting assembly code (generated by cc1) is passed to the assembler with 
the following options: "-mppc -maltivec -many". The 2 first options are OK but 
the last one seems to prevent the assembler to interpret the "mftbX" opcode and 
the assembler will fail with some messages similar to this: 
 
time.s: Assembler messages: 
time.s:158: Error: Unrecognized opcode: `mftb' 
time.s:376: Error: Unrecognized opcode: `mftb' 
time.s:500: Error: Unrecognized opcode: `mftb' 
time.s:685: Error: Unrecognized opcode: `mftb' 
time.s:802: Error: Unrecognized opcode: `mftb' 
time.s:1016: Error: Unrecognized opcode: `mftbu' 
time.s:1017: Error: Unrecognized opcode: `mftb' 
time.s:1018: Error: Unrecognized opcode: `mftbu' 
 
I regenerated the GCC 3.4.0 tool chain without the -many and the compiler was 
then able to compile the time.c file. 
 
So while the official GCC 3.4 tool chain should not contain this "fix" it seems 
to be quite an official one anyway as it is now part of mainline (3.5?). 
However it seems to me it causes some trouble in the Linux kernel compilation 
for PPC when the C code select itself the assembly code to use for a function. 
 
Therefore, I'd like to ask if this unconditional "-many" is really required. If 
it is, is there some kind of incompatibilty/misbehavior in the 2.14 binutils I 
selscted for the task? 
 
I don't see a way to attach the .c, .i or .s to this web form. So please let me 
know where/how to send it and I'll do it.

-- 
           Summary: gcc pass unconditionaly "-many" to the assembler
           Product: gcc
           Version: 3.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jdubois at mc dot com
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: sparc-solaris-2.8
  GCC host triplet: sparc-solaris-2.8
GCC target triplet: powerpc-7400-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16259

[Bug c/16259] gcc pass unconditionaly "-many" to the assembler

[jdubois at mc dot com]

------- Additional Comments From jdubois at mc dot com  2004-06-29 10:14 -------
Created an attachment (id=6646)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=6646&action=view)
files that fail to compile on GCC 3.4 + -many patch

These are the source code (with genrated .i and .s files) that show the bug.
They are From Linux 2.6.2 source tree.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16259

[Bug target/16259] gcc pass unconditionaly "-many" to the assembler

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-06-29 14:08 -------
Not a gcc bug, there was a bug in binutils before 2.15 which causes gas to change what was accepted 
for -many.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
          Component|c                           |target
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16259

[Bug target/16259] gcc pass unconditionaly "-many" to the assembler

[jdubois at mc dot com]

------- Additional Comments From jdubois at mc dot com  2004-06-29 14:22 -------
(In reply to comment #2) 
> Not a gcc bug, there was a bug in binutils before 2.15 which causes gas to 
change what was accepted  
> for -many. 
 
Then, I think gcc 3.4 should refuse to build against a binutils version lesser 
than 2.15. So there is still a bug and configure should check for this. 
 
Also, I would gladly use binutils 2.15 but the binaries generated on my Solaris 
2.8 system for the cross tools are crashing on me. So I had to downgrade to 
2.14 to get something working. OK, this is my problem and not a gcc bug but 
still... 
 
Also, please, note also that removing the -many from the argument passed to gas 
makes the all thing work correctly even with 2.14. So what is the rational for 
adding this flag when it seems to cause trouble with all but one version of 
binutils. 
 
 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16259

[Bug target/16259] gcc pass unconditionaly "-many" to the assembler

[amodra at bigpond dot net dot au]

------- Additional Comments From amodra at bigpond dot net dot au  2004-06-29 15:25 -------
See http://gcc.gnu.org/ml/gcc-patches/2004-05/msg01244.html

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16259

[Bug target/16259] gcc pass unconditionaly "-many" to the assembler

[jdubois at mc dot com]

------- Additional Comments From jdubois at mc dot com  2004-06-29 15:48 -------
(In reply to comment #4) 
> See http://gcc.gnu.org/ml/gcc-patches/2004-05/msg01244.html 
 
This is the patch that is applied (automatically) to GCC 3.4.0 in Dan kegel's 
crosstool and I am fine with all of it except the last unconditional "-many" 
that cause trouble to (at least) gas 2.14. BTW the "comment" in the applied 
patch file is as follow: 
 
<quote> 
(I'm not so sure about the unconditional -many it sends to binutils; 
that seems redundant?) 
</quote> 
 
It seems that gas 2.14 will reduce the number of valid instruction opcode to a 
"common" subset when -many is passed to it even if -mppc is passed prior to it. 
Therefore gas fails to interpret the mftbX opcodes. 
 
If the answer is: use 2.15 because we know 2.14 has a bug, and 2.15 handles the 
"-mppc -maltivec -many" correctly, I am fine with this (even if I will now have 
to find out why 2.15 crashes on me :( ). But then we should try to check this 
condition in the configure script and prevent gcc 3.4.0 (and later) to build 
against 2.14 or prior. 
 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16259

[Bug target/16259] gcc pass unconditionaly "-many" to the assembler

[jdubois at mc dot com]

------- Additional Comments From jdubois at mc dot com  2004-07-05 22:01 -------
(In reply to comment #5)

This is just to give a status on my progress in case it could help somebody else.

I upgraded my tool selection (for crosstool.sh) to:

gcc 3.4.1
binutils 2.15
glibc 2.3.2

In order to get binutils to run on Solaris 2.8 without crashing, I had to apply
the patch described on the following link (now part of CVS):

 http://sources.redhat.com/ml/binutils/2004-06/msg00114.html

Once done I was able to cross compile a Linux 2.6.7 kernel for PPC on my Solaris
2.8 host (with few additional patches to the Linux source tree).

It still seems to me that binutils 2.14 should not be a valid choice (at
configure time) for gcc 3.4.0 and above.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16259