RE: cross target report on gcc 3.1-20020423

RE: cross target report on gcc 3.1-20020423

[Rekha Deshmukh]

Dear Joel!

As per this report, I came to know that you were able to build the target sh-elf for gcc 3.1,binutis-2.12. 
I am too trying the same build, but is failing for me. 
Can you please tell me the build machine, native gcc configuration you used?  
I tried on RH 6.2 where it gives me the error that the 'gcc is  having buggy 64 bit support'. So I tried on the RH 7.2 it goes further this error but fails somewhere in the make. 
Kindly provide the native gcc version you used so that I can upgrade my gcc. 

Thanks & Regards
Rekha Bhintade

-----Original Message-----
From: Joel Sherrill [mailto:joel.sherrill@OARcorp.com]
Sent: Thursday, April 25, 2002 7:22 PM
To: gcc@gcc.gnu.org
Subject: cross target report on gcc 3.1-20020423



Hi,

I have done a round of cross target testing for about 38 targets
and gcc 3.1.  PR6445 on the i386 is the single highest priority 
problem  (to me) in this list.  The hppa ICE bothers me since it
probably will show up on HP-UX but that is unconfirmed so far.
And sparc-elf not building is bothersome as well.

Here is the summary.

GCC: gcc 3.1-20020423 
Newlib: CVS
binutils: 2.12

configure command:
    if *-rtems 
       configure --target=arm-rtems --enable-threads=rtems \
         --prefix=/opt/rtems --with-gnu-as --with-gnu-ld --with-newlib
--verbose    else
      configure --target=XXX --prefix=/opt/gnucross --with-gnu-as \
        --with-gnu-ld --with-newlib --verbose

If the target has a simulator in gdb, then my script went ahead and
ran and reported results to gcc-testresults.  I don't have 
DejaGNU GCC testing setup for *-rtems targets and don't have a way
yet to automatically report build success/failure if there is
no simulator to run scripts on.   

a29k-coff       - Fortran requires exact FP representation
a29k-rtems      - Fortran requires exact FP representation
arc-elf         - PR35997 old crtinit/fini problem 
arm-elf         - BUILT test results reported
arm-rtems       - BUILT
avr-elf         - failed compiling libobjc/sendmsg.c
d30v-elf        - ICE compiling libstdc++-v3/strstream.c at flow.c:1880
fr30-elf        - g77 requires exact FP representation
h8300-coff      - BUILT test results reported
h8300-rtems     - g77 says "gcc doesn't define all the built in types"
Why?
hppa1.1-proelf  - newlib/libc/machine/hppa still has .subspa
                - /newlib/libc/stdlib/ldtoa.c:652: ICE in
propagate_one_insn,
                        at flow.c:1615
                - /newlib/libc/stdio/findfp.c:179: ICE in
propagate_one_insn,
                        at flow.c:1615
hppa1.1-rtems   - see hppa1.1-proelf
i386-elf        - BUILT
i386-rtems      - PR6445 failed compiling libobj/sendmsg.c: at
reg-stack.c:990
i960-coff       - libobjc/encoding.c:887 XFmode undeclared.
i960-rtems      - thr-objc.c 
i960-elf        - libgloss/libnosys/write.c section attributes not
supported.
m32r-elf        - BUILT test results report
m68k-coff       - BUILT
m68k-elf        - BUILT
m68k-rtems      - BUILT
mcore-elf       - ICE at /libstdc++-v3/include/iomanip:146 in
expr.c:2768
mips64orion-elf - BUILT test results reported
mips64orion-rtems       - BUILT
mips-elf        - BUILT test results reported
mips-rtems      - BUILT
mn10200-elf     - ICE compiling unwind-sjlj.c:135
mn10300-elf     - BUILT test results reported
powerpc-eabi    - BUILT
powerpc-rtems   - BUILT
sh-coff         - BUILT test results reported   
sh-rtems        - BUILT
sh-elf          - BUILT
sh-rtemself     - BUILT
sparc-elf       - boehm-gc/typd_mlc.c: include/private/gcconfig.h:394:
                        parse error before -- token
sparc-rtems     - BUILT
v850-elf        - BUILT test results reported
xscale-elf      - BUILT


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985

Re: cross target report on gcc 3.1-20020423

[Joel Sherrill]

Rekha Deshmukh wrote:
> 
> Dear Joel!
> 
> As per this report, I came to know that you were able to build the target sh-elf for gcc 3.1,binutis-2.12.
> I am too trying the same build, but is failing for me.
> Can you please tell me the build machine, native gcc configuration you used?
> I tried on RH 6.2 where it gives me the error that the 'gcc is  having buggy 64 bit support'. So I tried on the RH 7.2 it goes further this error but fails somewhere in the make.
> Kindly provide the native gcc version you used so that I can upgrade my gcc.

I have used RH 5.2, 6.2 and 7.2 over the years to build this.  I install 
binutils by itself first to say /opt/crosstools.  Put that in your PATH.
Then I untar newlib and gcc and move the libgloss and newlib 
subdirectories from newlib-XXX to gcc-XXX.  Then configure using the 
--enable-newlib option.  I use this configure command:

 ../gcc-to-merge/configure --target=sh-elf --prefix=/opt/gnucross
--with-gnu-as
 --with-gnu-ld --with-newlib --verbose 
make
make install

It just works. :)


> Thanks & Regards
> Rekha Bhintade
> 
> -----Original Message-----
> From: Joel Sherrill [mailto:joel.sherrill@OARcorp.com]
> Sent: Thursday, April 25, 2002 7:22 PM
> To: gcc@gcc.gnu.org
> Subject: cross target report on gcc 3.1-20020423
> 
> Hi,
> 
> I have done a round of cross target testing for about 38 targets
> and gcc 3.1.  PR6445 on the i386 is the single highest priority
> problem  (to me) in this list.  The hppa ICE bothers me since it
> probably will show up on HP-UX but that is unconfirmed so far.
> And sparc-elf not building is bothersome as well.
> 
> Here is the summary.
> 
> GCC: gcc 3.1-20020423
> Newlib: CVS
> binutils: 2.12
> 
> configure command:
>     if *-rtems
>        configure --target=arm-rtems --enable-threads=rtems \
>          --prefix=/opt/rtems --with-gnu-as --with-gnu-ld --with-newlib
> --verbose    else
>       configure --target=XXX --prefix=/opt/gnucross --with-gnu-as \
>         --with-gnu-ld --with-newlib --verbose
> 
> If the target has a simulator in gdb, then my script went ahead and
> ran and reported results to gcc-testresults.  I don't have
> DejaGNU GCC testing setup for *-rtems targets and don't have a way
> yet to automatically report build success/failure if there is
> no simulator to run scripts on.
> 
> a29k-coff       - Fortran requires exact FP representation
> a29k-rtems      - Fortran requires exact FP representation
> arc-elf         - PR35997 old crtinit/fini problem
> arm-elf         - BUILT test results reported
> arm-rtems       - BUILT
> avr-elf         - failed compiling libobjc/sendmsg.c
> d30v-elf        - ICE compiling libstdc++-v3/strstream.c at flow.c:1880
> fr30-elf        - g77 requires exact FP representation
> h8300-coff      - BUILT test results reported
> h8300-rtems     - g77 says "gcc doesn't define all the built in types"
> Why?
> hppa1.1-proelf  - newlib/libc/machine/hppa still has .subspa
>                 - /newlib/libc/stdlib/ldtoa.c:652: ICE in
> propagate_one_insn,
>                         at flow.c:1615
>                 - /newlib/libc/stdio/findfp.c:179: ICE in
> propagate_one_insn,
>                         at flow.c:1615
> hppa1.1-rtems   - see hppa1.1-proelf
> i386-elf        - BUILT
> i386-rtems      - PR6445 failed compiling libobj/sendmsg.c: at
> reg-stack.c:990
> i960-coff       - libobjc/encoding.c:887 XFmode undeclared.
> i960-rtems      - thr-objc.c
> i960-elf        - libgloss/libnosys/write.c section attributes not
> supported.
> m32r-elf        - BUILT test results report
> m68k-coff       - BUILT
> m68k-elf        - BUILT
> m68k-rtems      - BUILT
> mcore-elf       - ICE at /libstdc++-v3/include/iomanip:146 in
> expr.c:2768
> mips64orion-elf - BUILT test results reported
> mips64orion-rtems       - BUILT
> mips-elf        - BUILT test results reported
> mips-rtems      - BUILT
> mn10200-elf     - ICE compiling unwind-sjlj.c:135
> mn10300-elf     - BUILT test results reported
> powerpc-eabi    - BUILT
> powerpc-rtems   - BUILT
> sh-coff         - BUILT test results reported
> sh-rtems        - BUILT
> sh-elf          - BUILT
> sh-rtemself     - BUILT
> sparc-elf       - boehm-gc/typd_mlc.c: include/private/gcconfig.h:394:
>                         parse error before -- token
> sparc-rtems     - BUILT
> v850-elf        - BUILT test results reported
> xscale-elf      - BUILT
> 
> --
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel@OARcorp.com                 On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>    Support Available             (256) 722-9985

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985

Re: cross target report on gcc 3.1-20020423

[Hans-Peter Nilsson]

On Mon, 29 Apr 2002, Joel Sherrill wrote:
> Rekha Deshmukh wrote:
> >
> > Dear Joel!
> >
> > As per this report, I came to know that you were able to build the target sh-elf for gcc 3.1,binutis-2.12.
> > I am too trying the same build, but is failing for me.
> > Can you please tell me the build machine, native gcc configuration you used?
> > I tried on RH 6.2 where it gives me the error that the 'gcc is  having buggy 64 bit support'. So I tried on the RH 7.2 it goes further this error but fails somewhere in the make.
> > Kindly provide the native gcc version you used so that I can upgrade my gcc.
>
> I have used RH 5.2, 6.2 and 7.2 over the years to build this.

Have you tried a recent binutils with RH 6.2?  Since the change
to 64-bit BFD for sh-* (requested by gdb folks for reasons
related to sh64), you can't build on stock RH 6.2.  BFD
configure disallows it, because the egcs-1.1.2 compiler is too
buggy in 64-bit matters.  Installing gcc-2.95.3 somewhere and
setting CC to it at least when building 64-bit toolchains is one
remedy.

brgds, H-P

Re: cross target report on gcc 3.1-20020423

[Joel Sherrill]

Hans-Peter Nilsson wrote:
> 
> On Mon, 29 Apr 2002, Joel Sherrill wrote:
> > Rekha Deshmukh wrote:
> > >
> > > Dear Joel!
> > >
> > > As per this report, I came to know that you were able to build the target sh-elf for gcc 3.1,binutis-2.12.
> > > I am too trying the same build, but is failing for me.
> > > Can you please tell me the build machine, native gcc configuration you used?
> > > I tried on RH 6.2 where it gives me the error that the 'gcc is  having buggy 64 bit support'. So I tried on the RH 7.2 it goes further this error but fails somewhere in the make.
> > > Kindly provide the native gcc version you used so that I can upgrade my gcc.
> >
> > I have used RH 5.2, 6.2 and 7.2 over the years to build this.
> 
> Have you tried a recent binutils with RH 6.2?  Since the change
> to 64-bit BFD for sh-* (requested by gdb folks for reasons
> related to sh64), you can't build on stock RH 6.2.  BFD
> configure disallows it, because the egcs-1.1.2 compiler is too
> buggy in 64-bit matters.  Installing gcc-2.95.3 somewhere and
> setting CC to it at least when building 64-bit toolchains is one
> remedy.

I don't have any 6.2 machines at this point.   So this comment
was purely historical.

And my RH 5.2 machine doesn't grok our current RPMs but that isn't
the current specs. :(

> brgds, H-P

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985

Re: cross target report on gcc 3.1-20020423

[Eric Christopher]

> Actually, now that I thought about this some more, I remembered that
> there is another solution.  The i960 has the same problem as ia64 here,
> long double is 80 bits, but it has 128 bit size/alignment in memory.  We
> can borrow the same solution that was used for ia64, which means
> defining the macro INTEL_EXTENDED_IEEE_FORMAT, plus other changes to
> make this work.  With this change, long double will use TFmode instead
> of XFmode, and then objc build problem will go away.   I think objc will
> still fail to work because of the overloading of TFmode onto _C_DBL I
> mentioned above, but at least it will build.  I vaguely recall Eric
> Christopher working on this patch, because i960 problems showed up
> inside Red Hat when we tried building it once, but I don't recall what
> happened.  Maybe he didn't finish writing the patch, or maybe I lost it.
>  This patch risks introducing ABI changes if done wrong, and would take
> some time to write and test if we don't already have it.
> 

I'm stunned. I actually have an old version of the patch around. Barring
the changes that were required to real.c and real.h (which i think were
already done) at least.

If this is the one you were wanting I can probably bring it up to current
FSF sources, as you can tell, it's quite old :)

-eric


-- 
A fire drill does not demand
a fire.

Index: configure.in
===================================================================
RCS file: /cvs/cvsfiles/devo/gcc/configure.in,v
retrieving revision 1.368.2.5
diff -u -p -w -r1.368.2.5 configure.in
--- configure.in	2000/12/08 21:08:03	1.368.2.5
+++ configure.in	2001/05/21 16:43:09
@@ -1989,14 +1989,17 @@ changequote([,])dnl
 	i960-*-coff*)
 		tm_file="${tm_file} dbxcoff.h i960/i960-coff.h libgloss.h"
 		tmake_file=i960/t-960bare
+		float_format=i386
 		use_collect2=yes
 		;;
 	i960-*-rtems)
 		tmake_file="i960/t-960bare t-rtems"
 		tm_file="${tm_file} dbxcoff.h i960/rtems.h"
+		float_format=i386
 		use_collect2=yes
 		;;
 	i960-*-*)			# Default i960 environment.
+		float_format=i386
 		use_collect2=yes
 		;;
 	ia64*-*-elf*)
Index: config/i960/i960.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gcc/config/i960/i960.c,v
retrieving revision 1.53.56.2
diff -u -p -w -r1.53.56.2 i960.c
--- i960.c	2001/03/01 20:38:34	1.53.56.2
+++ i960.c	2001/05/21 16:43:14
@@ -1018,13 +1018,13 @@ i960_output_ldconst (dst, src)
       output_asm_insn ("ldconst	%1,%0", operands);
       return "";
     }
-  else if (mode == XFmode)
+  else if (mode == TFmode)
     {
       REAL_VALUE_TYPE d;
       long value_long[3];
       int i;
 
-      if (fp_literal_zero (src, XFmode))
+      if (fp_literal_zero (src, TFmode))
 	return "movt	0,%0";
 
       REAL_VALUE_FROM_CONST_DOUBLE (d, src);
@@ -1409,6 +1409,44 @@ i960_function_name_declare (file, name, 
     }
 }
 \f
+
+
+/* ??? Fixing GR->FR TFmode moves during reload is hard.  You need to go
+   through memory plus an extra GR scratch register.  Except that you can
+   either get the first from SECONDARY_MEMORY_NEEDED or the second from
+   SECONDARY_RELOAD_CLASS, but not both.
+
+   We got into problems in the first place by allowing a construct like
+   (subreg:TF (reg:TI)), which we got from a union containing a long double.
+   This solution attempts to prevent this situation from ocurring.  When
+   we see something like the above, we spill the inner register to memory. */
+
+rtx
+spill_tfmode_operand (in, force)
+     rtx in;
+     int force;
+{
+  if (GET_CODE (in) == SUBREG
+      && GET_MODE (SUBREG_REG (in)) == TImode
+      && GET_CODE (SUBREG_REG (in)) == REG)
+    {
+      rtx mem = gen_mem_addressof (SUBREG_REG (in), NULL_TREE);
+      return gen_rtx_MEM (TFmode, copy_to_reg (XEXP (mem, 0)));
+    }
+  else if (force && GET_CODE (in) == REG)
+    {
+      rtx mem = gen_mem_addressof (in, NULL_TREE);
+      return gen_rtx_MEM (TFmode, copy_to_reg (XEXP (mem, 0)));
+    }
+  else if (GET_CODE (in) == MEM
+	   && GET_CODE (XEXP (in, 0)) == ADDRESSOF)
+    {
+      return change_address (in, TFmode, copy_to_reg (XEXP (in, 0)));
+    }
+  else
+    return in;
+}
+\f
 /* Compute and return the frame size.  */
 
 int
@@ -2423,7 +2461,7 @@ hard_regno_mode_ok (regno, mode)
 	case DImode: case DFmode:
 	  return (regno & 1) == 0;
 
-	case TImode: case XFmode:
+	case TImode: case TFmode:
 	  return (regno & 3) == 0;
 
 	default:
@@ -2434,7 +2472,7 @@ hard_regno_mode_ok (regno, mode)
     {
       switch (mode)
 	{
-	case SFmode: case DFmode: case XFmode:
+	case SFmode: case DFmode: case TFmode:
 	case SCmode: case DCmode:
 	  return 1;
 
@@ -2612,14 +2650,7 @@ i960_arg_size_and_align (mode, type, siz
     size = (GET_MODE_SIZE (mode) + UNITS_PER_WORD - 1) / UNITS_PER_WORD;
 
   if (type == 0)
-    {
-      /* ??? This is a hack to properly correct the alignment of XFmode
-	 values without affecting anything else.  */
-      if (size == 3)
-	align = 4;
-      else
 	align = size;
-    }
   else if (TYPE_ALIGN (type) >= BITS_PER_WORD)
     align = TYPE_ALIGN (type) / BITS_PER_WORD;
   else
@@ -2711,9 +2742,7 @@ i960_output_long_double (file, value)
   REAL_VALUE_TO_TARGET_LONG_DOUBLE (value, value_long);
   REAL_VALUE_TO_DECIMAL (value, "%.20g", dstr);
 
-  fprintf (file,
-	   "\t.word\t0x%08lx\t\t# %s\n\t.word\t0x%08lx\n\t.word\t0x%08lx\n",
-	   value_long[0], dstr, value_long[1], value_long[2]);
+  fprintf (file, "\t.word\t0x%08lx\t\t# %s\n\t.word\t0x%08lx\n\t.word\t0x%08lx\n", value_long[0], dstr, value_long[1], value_long[2]);
   fprintf (file, "\t.word\t0x0\n");
 }
 
Index: config/i960/i960.h
===================================================================
RCS file: /cvs/cvsfiles/devo/gcc/config/i960/i960.h,v
retrieving revision 1.68.24.2
diff -u -p -w -r1.68.24.2 i960.h
--- i960.h	2001/04/18 01:12:46	1.68.24.2
+++ i960.h	2001/05/21 16:43:17
@@ -423,21 +423,13 @@ extern int target_flags;
 /* Width in bits of a pointer.  See also the macro `Pmode' defined below.  */
 #define POINTER_SIZE 32
 
-/* Width in bits of a long double.  Define to 96, and let
-   ROUND_TYPE_ALIGN adjust the alignment for speed. */
-#define	LONG_DOUBLE_TYPE_SIZE (TARGET_LONG_DOUBLE_64 ? 64 : 96)
-
-/* ??? This must be a constant, because real.c and real.h test it with #if.  */
-#undef LONG_DOUBLE_TYPE_SIZE
-#define LONG_DOUBLE_TYPE_SIZE 96
-
-/* Define this to set long double type size to use in libgcc2.c, which can
-   not depend on target_flags.  */
-#if defined(__LONG_DOUBLE_64__)
-#define LIBGCC2_LONG_DOUBLE_TYPE_SIZE 64
-#else
-#define LIBGCC2_LONG_DOUBLE_TYPE_SIZE 96
-#endif
+/* A C expression for the size in bits of the type `long double' on the target
+   machine.  If you don't define this, the default is two words.  */
+#define LONG_DOUBLE_TYPE_SIZE 128
+
+/* Tell real.c that this is the 80-bit Intel extended float format
+   packaged in a 128-bit entity.  */
+#define INTEL_EXTENDED_IEEE_FORMAT
 
 /* Allocation boundary (in *bits*) for storing pointers in memory.  */
 #define POINTER_BOUNDARY 32
@@ -481,12 +473,6 @@ extern int target_flags;
    ? i960_object_bytes_bitalign (int_size_in_bytes (TREE_TYPE (EXP)))	    \
    : (ALIGN))
 
-/* Make XFmode floating point quantities be 128 bit aligned.  */
-#define DATA_ALIGNMENT(TYPE, ALIGN)					\
-  (TREE_CODE (TYPE) == ARRAY_TYPE					\
-   && TYPE_MODE (TREE_TYPE (TYPE)) == XFmode				\
-   && (ALIGN) < 128 ? 128 : (ALIGN))
-
 /* Macros to determine size of aggregates (structures and unions
    in C).  Normally, these may be defined to simply return the maximum
    alignment and simple rounded-up size, but on some machines (like
@@ -590,7 +576,7 @@ extern int target_flags;
 
 /* Value is 1 if hard register REGNO can hold a value of machine-mode MODE.
    On 80960, the cpu registers can hold any mode but the float registers
-   can only hold SFmode, DFmode, or XFmode.  */
+   can only hold SFmode, DFmode, or TFmode.  */
 #define HARD_REGNO_MODE_OK(REGNO, MODE) hard_regno_mode_ok ((REGNO), (MODE))
 
 /* Value is 1 if it is a good idea to tie two pseudo registers
Index: config/i960/i960.md
===================================================================
RCS file: /cvs/cvsfiles/devo/gcc/config/i960/i960.md,v
retrieving revision 1.42
diff -u -p -w -r1.42 i960.md
--- i960.md	2000/06/01 17:04:21	1.42
+++ i960.md	2001/05/21 16:43:17
@@ -1470,6 +1470,13 @@
   "cvtir	%1,%0"
   [(set_attr "type" "fpcvt")])
 
+(define_insn "floatsitf2"
+  [(set (match_operand:TF 0 "register_operand" "=d*f")
+	(float:TF (match_operand:SI 1 "register_operand" "d")))]
+  "TARGET_NUMERICS"
+  "cvtir	%1,%0"
+  [(set_attr "type" "fpcvt")])
+
 ;; Convert a float to an actual integer.
 ;; Truncation is performed as part of the conversion.
 ;; The i960 requires conversion from DFmode to DImode to make
@@ -1496,6 +1503,13 @@
   "cvtzri	%1,%0"
   [(set_attr "type" "fpcvt")])
 
+(define_insn "fixunstfsi"
+  [(set (match_operand:TF 0 "register_operand" "=f")
+	(unsigned_float:TF (match_operand:SI 1 "register_operand" "f")))]
+  "TARGET_NUMERICS"
+  "cvtzri       %1,%0"
+  [(set_attr "type" "fpcvt")])
+
 (define_expand "fixuns_truncdfsi2"
   [(set (match_operand:SI 0 "register_operand" "")
 	(unsigned_fix:SI (fix:DF (match_operand:DF 1 "fp_arith_operand" ""))))]
@@ -2036,10 +2050,10 @@
 \f
 ;; Tetra (16 byte) float support.
 
-(define_expand "cmpxf"
+(define_expand "cmptf"
   [(set (reg:CC 36)
-	(compare:CC (match_operand:XF 0 "register_operand" "")
-		    (match_operand:XF 1 "nonmemory_operand" "")))]
+	(compare:CC (match_operand:TF 0 "register_operand" "")
+		    (match_operand:TF 1 "nonmemory_operand" "")))]
   "TARGET_NUMERICS"
   "
 {
@@ -2050,27 +2064,27 @@
 
 (define_insn ""
   [(set (reg:CC 36)
-	(compare:CC (match_operand:XF 0 "register_operand" "f")
-		    (match_operand:XF 1 "nonmemory_operand" "fGH")))]
+	(compare:CC (match_operand:TF 0 "register_operand" "f")
+		    (match_operand:TF 1 "nonmemory_operand" "fGH")))]
   "TARGET_NUMERICS"
   "cmpr %0,%1"
   [(set_attr "type" "fpcc")])
 
-(define_expand "movxf"
-  [(set (match_operand:XF 0 "general_operand" "")
-	(match_operand:XF 1 "fpmove_src_operand" ""))]
+(define_expand "movtf"
+  [(set (match_operand:TF 0 "general_operand" "")
+	(match_operand:TF 1 "fpmove_src_operand" ""))]
   ""
   "
 {
-  if (emit_move_sequence (operands, XFmode))
+  if (emit_move_sequence (operands, TFmode))
     DONE;
 }")
 
 (define_insn ""
-  [(set (match_operand:XF 0 "general_operand" "=r,f,d,d,m")
-	(match_operand:XF 1 "fpmove_src_operand" "r,GH,F,m,d"))]
-  "register_operand (operands[0], XFmode)
-   || register_operand (operands[1], XFmode)"
+  [(set (match_operand:TF 0 "general_operand" "=r,f,d,d,m")
+	(match_operand:TF 1 "fpmove_src_operand" "r,GH,F,m,d"))]
+  "register_operand (operands[0], TFmode)
+   || register_operand (operands[1], TFmode)"
   "*
 {
   switch (which_alternative)
@@ -2092,9 +2106,9 @@
 }"
   [(set_attr "type" "move,move,load,fpload,fpstore")])
 
-(define_insn "extendsfxf2"
-  [(set (match_operand:XF 0 "register_operand" "=f,d")
-	(float_extend:XF
+(define_insn "extendsftf2"
+  [(set (match_operand:TF 0 "register_operand" "=f,d")
+	(float_extend:TF
 	 (match_operand:SF 1 "register_operand" "d,f")))]
   "TARGET_NUMERICS"
   "@
@@ -2102,9 +2116,9 @@
   movre	%1,%0"
   [(set_attr "type" "fpmove")])
 
-(define_insn "extenddfxf2"
-  [(set (match_operand:XF 0 "register_operand" "=f,d")
-	(float_extend:XF
+(define_insn "extenddftf2"
+  [(set (match_operand:TF 0 "register_operand" "=f,d")
+	(float_extend:TF
 	 (match_operand:DF 1 "register_operand" "d,f")))]
   "TARGET_NUMERICS"
   "@
@@ -2112,85 +2126,106 @@
   movre	%1,%0"
   [(set_attr "type" "fpmove")])
 
-(define_insn "truncxfdf2"
+(define_insn "trunctfdf2"
   [(set (match_operand:DF 0 "register_operand" "=d")
 	(float_truncate:DF
-	 (match_operand:XF 1 "register_operand" "f")))]
+	 (match_operand:TF 1 "register_operand" "f")))]
   "TARGET_NUMERICS"
   "movrl	%1,%0"
   [(set_attr "type" "fpmove")])
 
-(define_insn "truncxfsf2"
+(define_insn "trunctfsf2"
   [(set (match_operand:SF 0 "register_operand" "=d")
 	(float_truncate:SF
-	 (match_operand:XF 1 "register_operand" "f")))]
+	 (match_operand:TF 1 "register_operand" "f")))]
   "TARGET_NUMERICS"
   "movr	%1,%0"
   [(set_attr "type" "fpmove")])
 
-(define_insn "floatsixf2"
-  [(set (match_operand:XF 0 "register_operand" "=f")
-	(float:XF (match_operand:SI 1 "register_operand" "d")))]
+(define_insn "floatditf2"
+  [(set (match_operand:TF 0 "register_operand" "=f")
+	(float:TF (match_operand:DI 1 "register_operand" "d")))]
   "TARGET_NUMERICS"
   "cvtir	%1,%0"
   [(set_attr "type" "fpcvt")])
 
-(define_insn "fix_truncxfsi2"
+(define_insn "fix_trunctfsi2"
   [(set (match_operand:SI 0 "register_operand" "=d")
-	(fix:SI (fix:XF (match_operand:XF 1 "register_operand" "f"))))]
+	(fix:SI (fix:TF (match_operand:TF 1 "register_operand" "f"))))]
   "TARGET_NUMERICS"
   "cvtzri	%1,%0"
   [(set_attr "type" "fpcvt")])
 
-(define_insn "fixuns_truncxfsi2"
+(define_insn "fixuns_trunctfsi2"
   [(set (match_operand:SI 0 "register_operand" "=d")
-	(unsigned_fix:SI (fix:XF (match_operand:XF 1 "register_operand" "f"))))]
+	(unsigned_fix:SI (fix:TF (match_operand:TF 1 "register_operand" "f"))))]
+  "TARGET_NUMERICS"
+  "cvtzri	%1,%0"
+  [(set_attr "type" "fpcvt")])
+
+(define_insn "fix_trunctfdi2"
+  [(set (match_operand:DI 0 "register_operand" "=d")
+	(fix:DI (fix:TF (match_operand:TF 1 "register_operand" "f"))))]
+  "TARGET_NUMERICS"
+  "cvtzri	%1,%0"
+  [(set_attr "type" "fpcvt")])
+
+(define_insn "fixuns_trunctfdi2"
+  [(set (match_operand:DI 0 "register_operand" "=d")
+	(unsigned_fix:DI (fix:TF (match_operand:TF 1 "register_operand" "f"))))]
+  "TARGET_NUMERICS"
+  "cvtzri	%1,%0"
+  [(set_attr "type" "fpcvt")])
+
+(define_insn "fixunstfdi"
+  [(set (match_operand:TF 0 "register_operand" "=f")
+	(unsigned_float:TF (match_operand:DI 1 "register_operand" "f")))]
   "TARGET_NUMERICS"
   "cvtzri	%1,%0"
   [(set_attr "type" "fpcvt")])
 
-(define_insn "addxf3"
-  [(set (match_operand:XF 0 "register_operand" "=f")
-	(plus:XF (match_operand:XF 1 "nonmemory_operand" "%fGH")
-		 (match_operand:XF 2 "nonmemory_operand" "fGH")))]
+(define_insn "addtf3"
+  [(set (match_operand:TF 0 "register_operand" "=f")
+	(plus:TF (match_operand:TF 1 "nonmemory_operand" "%fGH")
+		 (match_operand:TF 2 "nonmemory_operand" "fGH")))]
   "TARGET_NUMERICS"
   "addr	%1,%2,%0"
   [(set_attr "type" "fpadd")])
 
-(define_insn "subxf3"
-  [(set (match_operand:XF 0 "register_operand" "=f")
-	(minus:XF (match_operand:XF 1 "nonmemory_operand" "fGH")
-		  (match_operand:XF 2 "nonmemory_operand" "fGH")))]
+(define_insn "subtf3"
+  [(set (match_operand:TF 0 "register_operand" "=f")
+	(minus:TF (match_operand:TF 1 "nonmemory_operand" "fGH")
+		  (match_operand:TF 2 "nonmemory_operand" "fGH")))]
   "TARGET_NUMERICS"
   "subr	%2,%1,%0"
   [(set_attr "type" "fpadd")])
 
-(define_insn "mulxf3"
-  [(set (match_operand:XF 0 "register_operand" "=f")
-	(mult:XF (match_operand:XF 1 "nonmemory_operand" "%fGH")
-		 (match_operand:XF 2 "nonmemory_operand" "fGH")))]
+(define_insn "multf3"
+  [(set (match_operand:TF 0 "register_operand" "=f")
+	(mult:TF (match_operand:TF 1 "nonmemory_operand" "%fGH")
+		 (match_operand:TF 2 "nonmemory_operand" "fGH")))]
   "TARGET_NUMERICS"
   "mulr	%1,%2,%0"
   [(set_attr "type" "fpmul")])
 
-(define_insn "divxf3"
-  [(set (match_operand:XF 0 "register_operand" "=f")
-	(div:XF (match_operand:XF 1 "nonmemory_operand" "fGH")
-		(match_operand:XF 2 "nonmemory_operand" "fGH")))]
+(define_insn "divtf3"
+  [(set (match_operand:TF 0 "register_operand" "=f")
+	(div:TF (match_operand:TF 1 "nonmemory_operand" "fGH")
+		(match_operand:TF 2 "nonmemory_operand" "fGH")))]
   "TARGET_NUMERICS"
   "divr	%2,%1,%0"
   [(set_attr "type" "fpdiv")])
 
-(define_insn "negxf2"
-  [(set (match_operand:XF 0 "register_operand" "=f")
-	(neg:XF (match_operand:XF 1 "register_operand" "f")))]
+(define_insn "negtf2"
+  [(set (match_operand:TF 0 "register_operand" "=f")
+	(neg:TF (match_operand:TF 1 "register_operand" "f")))]
   "TARGET_NUMERICS"
   "subr	%1,0f0.0,%0"
   [(set_attr "type" "fpadd")])
 
-(define_insn "absxf2"
-  [(set (match_operand:XF 0 "register_operand" "=f")
-	(abs:XF (match_operand:XF 1 "register_operand" "f")))]
+(define_insn "abstf2"
+  [(set (match_operand:TF 0 "register_operand" "=f")
+	(abs:TF (match_operand:TF 1 "register_operand" "f")))]
   "(TARGET_NUMERICS)"
   "cpysre	%1,0f0.0,%0"
   [(set_attr "type" "fpmove")])
Index: config/i960/t-960bare
===================================================================
RCS file: /cvs/cvsfiles/devo/gcc/config/i960/t-960bare,v
retrieving revision 1.17
diff -u -p -w -r1.17 t-960bare
--- t-960bare	1999/10/05 08:07:42	1.17
+++ t-960bare	2001/05/21 16:43:17
@@ -21,8 +21,8 @@ xp-bit.c: $(srcdir)/config/fp-bit.c
 	echo '#define EXTENDED_FLOAT_STUBS' > xp-bit.c
 	cat $(srcdir)/config/fp-bit.c >> xp-bit.c
 
-MULTILIB_OPTIONS=mnumerics/msoft-float mlong-double-64
-MULTILIB_DIRNAMES=float soft-float ld64
+MULTILIB_OPTIONS=mnumerics/msoft-float
+MULTILIB_DIRNAMES=float soft-float
 MULTILIB_MATCHES=mnumerics=msb mnumerics=msc mnumerics=mkb mnumerics=mkc mnumerics=mmc mnumerics=mcb mnumerics=mcc mnumerics=mjf msoft-float=msa msoft-float=mka msoft-float=mca msoft-float=mcf
 
 LIBGCC = stmp-multilib

RE: cross target report on gcc 3.1-20020423

[Rekha Deshmukh]

Hi !
Thanks for the replies. It will surely help me.
Yes, I am using a recent binutils, i.e. binutils-2.12. 
I thought so, that I would have to use the newer gcc for that. But after reading the report I just wanted to confirm whether that is the only solution or am I missing something.
Thank you very much. 
I will  now try using the gcc-2.95.3. 
Thanks & Regards
Rekha Bhintade


-----Original Message-----
From: Hans-Peter Nilsson [mailto:hp@bitrange.com]
Sent: Tuesday, April 30, 2002 12:57 AM
To: Joel Sherrill
Cc: Rekha Deshmukh; gcc@gcc.gnu.org
Subject: Re: cross target report on gcc 3.1-20020423


On Mon, 29 Apr 2002, Joel Sherrill wrote:
> Rekha Deshmukh wrote:
> >
> > Dear Joel!
> >
> > As per this report, I came to know that you were able to build the target sh-elf for gcc 3.1,binutis-2.12.
> > I am too trying the same build, but is failing for me.
> > Can you please tell me the build machine, native gcc configuration you used?
> > I tried on RH 6.2 where it gives me the error that the 'gcc is  having buggy 64 bit support'. So I tried on the RH 7.2 it goes further this error but fails somewhere in the make.
> > Kindly provide the native gcc version you used so that I can upgrade my gcc.
>
> I have used RH 5.2, 6.2 and 7.2 over the years to build this.

Have you tried a recent binutils with RH 6.2?  Since the change
to 64-bit BFD for sh-* (requested by gdb folks for reasons
related to sh64), you can't build on stock RH 6.2.  BFD
configure disallows it, because the egcs-1.1.2 compiler is too
buggy in 64-bit matters.  Installing gcc-2.95.3 somewhere and
setting CC to it at least when building 64-bit toolchains is one
remedy.

brgds, H-P

Re: cross target report on gcc 3.1-20020423

[Joel Sherrill]

Hans-Peter Nilsson wrote:
> 
> On Thu, 25 Apr 2002, Joel Sherrill wrote:
> > h8300-rtems     - g77 says "gcc doesn't define all the built in types"
> > Why?
> 
> Because the h8300 port doesn't have a "double" larger than
> "single".  It should be in the mailing list archive at a time
> near the (original, non-rtems) commit for disabling libf2c for
> it.

I understand the root of the failure.  You must have missed the 
discussion that the h8300-coff was OK.  This was a configurery
problem where *-*-rtems* did not catch h8300*-*-* which disabled
fortran libraries.

This kind of goes back to the issue of how to generically
disable languages for certain CPUs.  I think this would be
a good idea which as Jim Wilson points out could have unfortunate
side-effects for sloppy ports which don't support all languages.
Conversely, we have added languages untested on all ports
so we are perpetuating the problem.

> brgds, H-P

--joel

Re: cross target report on gcc 3.1-20020423

[Joel Sherrill]

Jim Wilson wrote:
> 
> >a29k is officially deprecated so I lean to disabling Fortran for it
> >and let it go.  How does one disable a language for a particular CPU?
> >Where is the configurery magic?  It must be inside the gcc directory
> >instead of the top level one.
> 
> I think the best option would be to stop building and testing the a29k port.

:)  Actually this is my thinking but I wanted to know that the compiler
was in a clean buildable state when we deprecated it.

> As for disabling a language for a particular CPU, there isn't a supported way
> to do this.  We used to do this by adding a LANGUAGES= line to a target
> Makefile fragment, but this was never elegant, and is no longer supported.
> 
> Current mechanism for users is to use --enable-language when configuring to
> choose which languages they want to build.  We can specify in target specific
> docs that the user should use this to avoid building Fortran, but that isn't
> very elegant.
> 
> Better would be to have some sort of unsupported_language variable that a
> target can set, but not the user.  We can then warn about unsupported languages
> and avoid configuring them.  If the user gives a --enable-language configure
> option that conflicts with the target dependent unsupported_language then
> we give an error.

This would be a nice features but I agree with your argument below in
spite
of the fact that CPUs like the h8 don't support enough memory to truly
be
useful for some languages.

> The problem with allowing unsupported_languages is that some people may use
> this as an excuse to do incomplete ports.  If they don't care about C++, then
> they just mark it as an unsupported_language.  So we may not want to support
> this feature.  That takes us back to documenting that the a29k port is broken
> for Fortran, and askin g the user to specify --enable-languages at configure
> time

I kind of agree but think that not supporting a language should be a
documented
thing and that the error must point you to something that explains the 
rationale.  One of the only downsides to the multi-language gcc source
tree is that some languages are not supported by all ports.  Some can't
be
(h8) and some port communities simply don't care about some languages.
I think that the existing state must be documented and unfortunately
that
does allow future porters an out.  At least when a new port is accepted,
we can require them to document the state of all languages and the 
configurery can point out that information until it is believed to be
supported.  

Right now, one can be cynical and point out that Ada was
added and that most of the ports have not been even been compiled for
Ada yet.  :)

> >>i960-coff       - libobjc/encoding.c:887 XFmode undeclared.
> >This is beyond my area of expertise but I have a comment below. :)
> 
> There are really only two practical choices here.
> 
> 1) Stop building objc for i960.

IMO this is perfectly reasonable.  If there was a general way to
note the port/language status.  When someone cares, they can fix it.
Otherwise, people have to simply know which ports are broken for
which languages and avoid them.  FWIW this is why I often test
with only C/C++ and that isn't enough to survive builds on all CPUs.

> 2) Apply a hack that makes the build failure go away, while accepting the
>    fact that this won't make objc work.

Hacks like this are bad.

> The first one works only if we tell the user to use --enable-languages at
> configure time.  The second one is not too hard, and is probably what I will
> try to do.

That's fine with me but long-term, I am not so unsure that adding a way
to avoid languages for a CPU isn't bad.  We already avoid run-time
libraries
on a per CPU basis.  Why force languages on CPUs when no one is
interested.
Fortran on the i960 may be a text book example. :)

> Jim

--joel

Re: cross target report on gcc 3.1-20020423

[Hans-Peter Nilsson]

On Thu, 25 Apr 2002, Joel Sherrill wrote:
> h8300-rtems     - g77 says "gcc doesn't define all the built in types"
> Why?

Because the h8300 port doesn't have a "double" larger than
"single".  It should be in the mailing list archive at a time
near the (original, non-rtems) commit for disabling libf2c for
it.

brgds, H-P

Re: cross target report on gcc 3.1-20020423

[Stan Shebs]

Jim Wilson wrote:
> 
> libobjc has only decoders.  I had to use grep to find the encoder.  It is
> in gcc/objc/objc-act.c, in the function encode_type.  Curiously, it does not
> use the objc-api.h file.  It just hard codes all of the constant values.
> Also curiously, it converts both DFmode and TFmode to 'd' (aka _C_DBL) which
> can't be right, and it doesn't handle XFmode at all.  If we add a _C_LDBL
> macro, then we would have to change this to use _C_LDBL for both XFmode and
> TFmode, which should be OK because I don't know of any port that uses both.
> While we are at it, it wouldn't hurt to add some aborts to this function so
> that unknown types get a compile time error instead of silently being ignored.
> However, as above, adding new codes seems to be an API change, and would
> require comment from an Objective C person.

Codes are effectively a dynamic-dispatching version of C++ mangling.
Changed codes for existing types could potentially affect backwards
compatibility, and since it's dynamic, it would manifest at runtime
rather than compile time.  New codes for unhandled types would be OK.

> Or we could just disable Objective C for i960.  It is pretty unlikely that
> anyone cares about this particular combination of features.

That would be my vote.  The situation is a mess, and not easily
fixed for an imminent release.  I'm anticipating some libobjc
work in the near future, could address it better then.

Stan

Re: cross target report on gcc 3.1-20020423

[Jim Wilson]

>a29k is officially deprecated so I lean to disabling Fortran for it
>and let it go.  How does one disable a language for a particular CPU?
>Where is the configurery magic?  It must be inside the gcc directory
>instead of the top level one.

I think the best option would be to stop building and testing the a29k port.

As for disabling a language for a particular CPU, there isn't a supported way
to do this.  We used to do this by adding a LANGUAGES= line to a target
Makefile fragment, but this was never elegant, and is no longer supported.

Current mechanism for users is to use --enable-language when configuring to
choose which languages they want to build.  We can specify in target specific
docs that the user should use this to avoid building Fortran, but that isn't
very elegant.

Better would be to have some sort of unsupported_language variable that a
target can set, but not the user.  We can then warn about unsupported languages
and avoid configuring them.  If the user gives a --enable-language configure
option that conflicts with the target dependent unsupported_language then
we give an error.

The problem with allowing unsupported_languages is that some people may use
this as an excuse to do incomplete ports.  If they don't care about C++, then
they just mark it as an unsupported_language.  So we may not want to support
this feature.  That takes us back to documenting that the a29k port is broken
for Fortran, and asking the user to specify --enable-languages at configure
time.

>>i960-coff       - libobjc/encoding.c:887 XFmode undeclared.
>This is beyond my area of expertise but I have a comment below. :)

There are really only two practical choices here.

1) Stop building objc for i960.
2) Apply a hack that makes the build failure go away, while accepting the
   fact that this won't make objc work.

The first one works only if we tell the user to use --enable-languages at
configure time.  The second one is not too hard, and is probably what I will
try to do.

Jim

Re: cross target report on gcc 3.1-20020423

[Joel Sherrill]

Jim Wilson wrote:
> 
> I'd be happy to give up the a29k and/or i960 maintainer role to any interested
> party.  I have no interest in a29k anymore, and only the smallest of interest
> in i960.
> 
> >a29k-coff       - Fortran requires exact FP representation
> >a29k-rtems      - Fortran requires exact FP representation
> 
> I have no interest in looking at this.  a29k was EOL'ed by AMD in 1995.
> If someone else cares about a29k, let them fix it.

a29k is officially deprecated so I lean to disabling Fortran for it
and let it go.  How does one disable a language for a particular CPU?
Where is the configurery magic?  It must be inside the gcc directory
instead of the top level one.

> >i960-coff       - libobjc/encoding.c:887 XFmode undeclared.
> 
> This is an objc bug, not an i960 bug.  This will require an objc person to
> look at the problem.
> 
> I don't have a convenient tree I can use to reproduce this.  The "Cygnus"
> tree unfortunately doesn't have libobjc in it.  I'll have to check out a
> copy of the uberbaum tree.  I have a copy on my home machine, but my home
> machine is not on the net yet.  However, I can see the problem by inspection.
> 
> libobjc/encoding uses internal GCC macros that it shouldn't be using.
> This is a known problem.  It defines other gcc internal macros as a hack to
> make this work.  It needs one more for i960: XFmode.  The ideal solution would
> be something like this:

This is beyond my area of expertise but I have a comment below. :)

> Index: encoding.c
> ===================================================================
> RCS file: /cvs/gcc/gcc/libobjc/encoding.c,v
> retrieving revision 1.13
> diff -p -r1.13 encoding.c
> *** encoding.c  23 Apr 2002 02:04:20 -0000      1.13
> --- encoding.c  27 Apr 2002 00:16:40 -0000
> *************** Boston, MA 02111-1307, USA.  */
> *** 67,72 ****
> --- 67,73 ----
>   #define TYPE_MODE(TYPE) *(TYPE)
> 
>   #define DFmode          _C_DBL
> + #define XFmode                _C_LDBL
> 
>   #define get_inner_array_type(TYPE)      ((TYPE) + 1)
> 
> However, this is no good, because there is no _C_LDBL macro.  Using _C_DBL
> here won't work, as that will get structure layout wrong for any structure
> using a double.  These macros are defined in libobjc/objc/objc-api.h by the
> way.  Adding a _C_LDBL macro here is apparently an API change, and hence
> may not be wise.  We could try using an unused character for XFmode, but
> this is OK only if an objective C program never uses long double, which seems
> like an unsafe assumption.
> 
> libobjc has only decoders.  I had to use grep to find the encoder.  It is
> in gcc/objc/objc-act.c, in the function encode_type.  Curiously, it does not
> use the objc-api.h file.  It just hard codes all of the constant values.
> Also curiously, it converts both DFmode and TFmode to 'd' (aka _C_DBL) which
> can't be right, and it doesn't handle XFmode at all.  If we add a _C_LDBL
> macro, then we would have to change this to use _C_LDBL for both XFmode and
> TFmode, which should be OK because I don't know of any port that uses both.
> While we are at it, it wouldn't hurt to add some aborts to this function so
> that unknown types get a compile time error instead of silently being ignored.
> However, as above, adding new codes seems to be an API change, and would
> require comment from an Objective C person.
> 
> Or we could just disable Objective C for i960.  It is pretty unlikely that
> anyone cares about this particular combination of features.
> 
> Actually, now that I thought about this some more, I remembered that there
> is another solution.  The i960 has the same problem as ia64 here, long double
> is 80 bits, but it has 128 bit size/alignment in memory.  We can borrow the
> same solution that was used for ia64, which means defining the macro
> INTEL_EXTENDED_IEEE_FORMAT, plus other changes to make this work.  With this
> change, long double will use TFmode instead of XFmode, and then objc build
> problem will go away.   I think objc will still fail to work because of the
> overloading of TFmode onto _C_DBL I mentioned above, but at least it will
> build.  I vaguely recall Eric Christopher working on this patch, because
> i960 problems showed up inside Red Hat when we tried building it once, but
> I don't recall what happened.  Maybe he didn't finish writing the patch, or
> maybe I lost it.  This patch risks introducing ABI changes if done wrong,
> and would take some time to write and test if we don't already have it.
> 
> >i960-rtems      - thr-objc.c
> >i960-elf        - libgloss/libnosys/write.c section attributes not supported.
> 
> These will have to wait until I can reproduce them.
> 
> Curious that neither one of these hit the libobj/sendmsg.c problem.  I would
> expect all i960 configurations to fail there.  The i960-rtems problem goes
> away if we stop building Objective C for i960.  The i960-elf problem could
> be either a binutils or gcc problem.  libgloss is using a section attribute,
> and gcc is then emiting a .section pseudo-op that gas doesn't like.

i960-rtems does fail in the same place.  I misread a warning on
thr-objc.c
as the failure.  

i960-elf is failing before it gets to libobjc.

> Jim

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985

Re: cross target report on gcc 3.1-20020423

[Jim Wilson]

I'd be happy to give up the a29k and/or i960 maintainer role to any interested
party.  I have no interest in a29k anymore, and only the smallest of interest
in i960.

>a29k-coff       - Fortran requires exact FP representation
>a29k-rtems      - Fortran requires exact FP representation

I have no interest in looking at this.  a29k was EOL'ed by AMD in 1995.
If someone else cares about a29k, let them fix it.

>i960-coff       - libobjc/encoding.c:887 XFmode undeclared.

This is an objc bug, not an i960 bug.  This will require an objc person to
look at the problem.

I don't have a convenient tree I can use to reproduce this.  The "Cygnus"
tree unfortunately doesn't have libobjc in it.  I'll have to check out a
copy of the uberbaum tree.  I have a copy on my home machine, but my home
machine is not on the net yet.  However, I can see the problem by inspection.

libobjc/encoding uses internal GCC macros that it shouldn't be using.
This is a known problem.  It defines other gcc internal macros as a hack to
make this work.  It needs one more for i960: XFmode.  The ideal solution would
be something like this:

Index: encoding.c
===================================================================
RCS file: /cvs/gcc/gcc/libobjc/encoding.c,v
retrieving revision 1.13
diff -p -r1.13 encoding.c
*** encoding.c	23 Apr 2002 02:04:20 -0000	1.13
--- encoding.c	27 Apr 2002 00:16:40 -0000
*************** Boston, MA 02111-1307, USA.  */
*** 67,72 ****
--- 67,73 ----
  #define TYPE_MODE(TYPE) *(TYPE)
  
  #define DFmode          _C_DBL
+ #define XFmode		_C_LDBL
  
  #define get_inner_array_type(TYPE)      ((TYPE) + 1)
  
However, this is no good, because there is no _C_LDBL macro.  Using _C_DBL
here won't work, as that will get structure layout wrong for any structure
using a double.  These macros are defined in libobjc/objc/objc-api.h by the
way.  Adding a _C_LDBL macro here is apparently an API change, and hence
may not be wise.  We could try using an unused character for XFmode, but
this is OK only if an objective C program never uses long double, which seems
like an unsafe assumption.

libobjc has only decoders.  I had to use grep to find the encoder.  It is
in gcc/objc/objc-act.c, in the function encode_type.  Curiously, it does not
use the objc-api.h file.  It just hard codes all of the constant values.
Also curiously, it converts both DFmode and TFmode to 'd' (aka _C_DBL) which
can't be right, and it doesn't handle XFmode at all.  If we add a _C_LDBL
macro, then we would have to change this to use _C_LDBL for both XFmode and
TFmode, which should be OK because I don't know of any port that uses both.
While we are at it, it wouldn't hurt to add some aborts to this function so
that unknown types get a compile time error instead of silently being ignored.
However, as above, adding new codes seems to be an API change, and would
require comment from an Objective C person.

Or we could just disable Objective C for i960.  It is pretty unlikely that
anyone cares about this particular combination of features.

Actually, now that I thought about this some more, I remembered that there
is another solution.  The i960 has the same problem as ia64 here, long double
is 80 bits, but it has 128 bit size/alignment in memory.  We can borrow the
same solution that was used for ia64, which means defining the macro
INTEL_EXTENDED_IEEE_FORMAT, plus other changes to make this work.  With this
change, long double will use TFmode instead of XFmode, and then objc build
problem will go away.   I think objc will still fail to work because of the
overloading of TFmode onto _C_DBL I mentioned above, but at least it will
build.  I vaguely recall Eric Christopher working on this patch, because
i960 problems showed up inside Red Hat when we tried building it once, but
I don't recall what happened.  Maybe he didn't finish writing the patch, or
maybe I lost it.  This patch risks introducing ABI changes if done wrong,
and would take some time to write and test if we don't already have it.

>i960-rtems      - thr-objc.c 
>i960-elf        - libgloss/libnosys/write.c section attributes not supported.

These will have to wait until I can reproduce them.

Curious that neither one of these hit the libobj/sendmsg.c problem.  I would
expect all i960 configurations to fail there.  The i960-rtems problem goes
away if we stop building Objective C for i960.  The i960-elf problem could
be either a binutils or gcc problem.  libgloss is using a section attribute,
and gcc is then emiting a .section pseudo-op that gas doesn't like.

Jim

Re: cross target report on gcc 3.1-20020423

[Joel Sherrill]

Jakub Jelinek wrote:
> 
> On Fri, Apr 26, 2002 at 08:16:11AM -0500, Joel Sherrill wrote:
> > ===================================================================
> > RCS file: /cvs/gcc/gcc/configure.in,v
> > retrieving revision 1.119.2.11
> > diff -u -r1.119.2.11 configure.in
> > --- configure.in      22 Apr 2002 16:28:47 -0000      1.119.2.11
> > +++ configure.in      26 Apr 2002 13:18:46 -0000
> > @@ -636,6 +636,12 @@
> >      ;;
> >    *-*-rtems*)
> >      noconfigdirs="$noconfigdirs target-libgloss ${libgcj}"
> > +    case ${target} in
> > +     h8300*-*-* | h8500-*-*)
> > +       noconfigdirs="$noconfigdirs ${libgcj} target-libf2c"
> > +          ;;
> > +        *) ;;
> > +    esac
> 
> Why are you adding ${libgcj} twice for h8[35]00*-*-rtems*?

Sloppy cut and paste.  It ignores it twice. :)  I have fixed
it in the version I am sending to gcc-patches.  Thanks.

Really the whole organization of this logic is broken.
There are directories to ignore because of CPU and directories
to ignore because of OS/full tuples.  The logic needs
to be broken into two switches.  But even the discussion of
that is beyond the scope of a 3.1 patch.


>         Jakub

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985

Re: cross target report on gcc 3.1-20020423

[Jakub Jelinek]

On Fri, Apr 26, 2002 at 08:16:11AM -0500, Joel Sherrill wrote:
> ===================================================================
> RCS file: /cvs/gcc/gcc/configure.in,v
> retrieving revision 1.119.2.11
> diff -u -r1.119.2.11 configure.in
> --- configure.in	22 Apr 2002 16:28:47 -0000	1.119.2.11
> +++ configure.in	26 Apr 2002 13:18:46 -0000
> @@ -636,6 +636,12 @@
>      ;;
>    *-*-rtems*)
>      noconfigdirs="$noconfigdirs target-libgloss ${libgcj}"
> +    case ${target} in
> +	h8300*-*-* | h8500-*-*)
> +	  noconfigdirs="$noconfigdirs ${libgcj} target-libf2c"
> +          ;;
> +        *) ;;
> +    esac

Why are you adding ${libgcj} twice for h8[35]00*-*-rtems*?

	Jakub

Re: cross target report on gcc 3.1-20020423

[David S. Miller]

   From: Joel Sherrill <joel.sherrill@OARcorp.com>
   Date: Fri, 26 Apr 2002 08:16:11 -0500

   "David S. Miller" wrote:
   > I can approve it.  Please rebuild the configure file properly
   > and make sure that is a part of your patch too.
   
   The top level configure script (gcc-VERSION/configure) does not 
   appear to be automatically generated.  Is this correct?  If yes, 
   is it OK for me to commit it or do you want to?
   
   If so, then this is my complete patch for configure.in at this point:
   
   2002-04-26	Joel Sherrill <joel@OARcorp.com>
   
   	* configure.in (h8300*-*-rtems*): Disable libf2c and libgcj.
   	(sparc-*-elf*, sparc64-*-elf*): Disable libgcj.

The patch looks OK, but I am actually out of my juristiction
to approve it for the 3.1 branch.  That requires approval
by Mark.  As release manager he is requiring his approval
for 3.1 branch checkins at this point.

Please repost the problem + patch to gcc-patches and CC:
mark@codesourcery.com asking for 3.1 branch approval.

Thanks.

Re: cross target report on gcc 3.1-20020423

[Joel Sherrill]

"David S. Miller" wrote:
> 
>    From: Joel Sherrill <joel.sherrill@OARcorp.com>
>    Date: Fri, 26 Apr 2002 06:19:22 -0500
> 
>    I am testing a fix for this locally.  Who approves check-ins on
>    configure.in?
>    I now have two patches for it.
> 
> I can approve it.  Please rebuild the configure file properly
> and make sure that is a part of your patch too.

The top level configure script (gcc-VERSION/configure) does not 
appear to be automatically generated.  Is this correct?  If yes, 
is it OK for me to commit it or do you want to?


If so, then this is my complete patch for configure.in at this point:

2002-04-26	Joel Sherrill <joel@OARcorp.com>

	* configure.in (h8300*-*-rtems*): Disable libf2c and libgcj.
	(sparc-*-elf*, sparc64-*-elf*): Disable libgcj.

===================================================================
RCS file: /cvs/gcc/gcc/configure.in,v
retrieving revision 1.119.2.11
diff -u -r1.119.2.11 configure.in
--- configure.in	22 Apr 2002 16:28:47 -0000	1.119.2.11
+++ configure.in	26 Apr 2002 13:18:46 -0000
@@ -636,6 +636,12 @@
     ;;
   *-*-rtems*)
     noconfigdirs="$noconfigdirs target-libgloss ${libgcj}"
+    case ${target} in
+	h8300*-*-* | h8500-*-*)
+	  noconfigdirs="$noconfigdirs ${libgcj} target-libf2c"
+          ;;
+        *) ;;
+    esac
     ;;
   *-*-vxworks*)
     noconfigdirs="$noconfigdirs target-newlib target-libgloss
${libgcj}"
@@ -996,11 +1002,13 @@
     if [ x${is_cross_compiler} != xno ] ; then
 	   target_configdirs="${target_configdirs} target-libstub
target-cygmon"     fi
+    noconfigdirs="$noconfigdirs ${libgcj}"
     ;;
   sparc64-*-elf*)
     if [ x${is_cross_compiler} != xno ] ; then
 	   target_configdirs="${target_configdirs} target-libstub
target-cygmon"     fi
+    noconfigdirs="$noconfigdirs ${libgcj}"
     ;;
   sparclite-*-*)
     if [ x${is_cross_compiler} != xno ] ; then


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985

Re: cross target report on gcc 3.1-20020423

[David S. Miller]

   From: Joel Sherrill <joel.sherrill@OARcorp.com>
   Date: Fri, 26 Apr 2002 06:19:22 -0500
   
   I am testing a fix for this locally.  Who approves check-ins on
   configure.in?
   I now have two patches for it.

I can approve it.  Please rebuild the configure file properly
and make sure that is a part of your patch too.

Re: cross target report on gcc 3.1-20020423

[Joel Sherrill]

"David S. Miller" wrote:
> 
>    From: Joel Sherrill <joel.sherrill@OARcorp.com>
>    Date: Thu, 25 Apr 2002 08:52:02 -0500
> 
>    sparc-elf       - boehm-gc/typd_mlc.c: include/private/gcconfig.h:394:
>                            parse error before -- token
> 
> Fixing this requires some work, and thought.
> 
> The location of the bottom of the stack on Sparc is very very
> OS dependant.  What is the OS for sparc-elf and how could we
> determine the appropriate value of STACKBOTTOM for boehm-gc
> on it?

For sparc-elf and any other *-elf or *-coff target, there
is no OS.  So the question is why is sparc-elf special
and fail in boehm-gc.  And it appears that the answer is
pretty simple.  For some reason, the sparc*-*elf*
and sparc64*-*-elf* targets there do not include the 
variable ${libgcj} in their noconfigdir list but sparclite-elf*
does.  You can see this in this fragment:

  sparc-*-elf*)
    if [ x${is_cross_compiler} != xno ] ; then
           target_configdirs="${target_configdirs} target-libstub
target-cygmon"
    fi
    ;;
  sparc64-*-elf*)
    if [ x${is_cross_compiler} != xno ] ; then
           target_configdirs="${target_configdirs} target-libstub
target-cygmon"
    fi
    ;;
  sparclite-*-*)
    if [ x${is_cross_compiler} != xno ] ; then
           target_configdirs="${target_configdirs} target-bsp
target-libstub tar
get-cygmon"
    fi
    noconfigdirs="$noconfigdirs ${libgcj}"
    ;;              

I am testing a fix for this locally.  Who approves check-ins on
configure.in?
I now have two patches for it.
                        
-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985

Re: cross target report on gcc 3.1-20020423

[David S. Miller]

   From: Joel Sherrill <joel.sherrill@OARcorp.com>
   Date: Thu, 25 Apr 2002 08:52:02 -0500

   sparc-elf       - boehm-gc/typd_mlc.c: include/private/gcconfig.h:394:
                           parse error before -- token

Fixing this requires some work, and thought.

The location of the bottom of the stack on Sparc is very very
OS dependant.  What is the OS for sparc-elf and how could we
determine the appropriate value of STACKBOTTOM for boehm-gc
on it?

cross target report on gcc 3.1-20020423

[Joel Sherrill]

Hi,

I have done a round of cross target testing for about 38 targets
and gcc 3.1.  PR6445 on the i386 is the single highest priority 
problem  (to me) in this list.  The hppa ICE bothers me since it
probably will show up on HP-UX but that is unconfirmed so far.
And sparc-elf not building is bothersome as well.

Here is the summary.

GCC: gcc 3.1-20020423 
Newlib: CVS
binutils: 2.12

configure command:
    if *-rtems 
       configure --target=arm-rtems --enable-threads=rtems \
         --prefix=/opt/rtems --with-gnu-as --with-gnu-ld --with-newlib
--verbose    else
      configure --target=XXX --prefix=/opt/gnucross --with-gnu-as \
        --with-gnu-ld --with-newlib --verbose

If the target has a simulator in gdb, then my script went ahead and
ran and reported results to gcc-testresults.  I don't have 
DejaGNU GCC testing setup for *-rtems targets and don't have a way
yet to automatically report build success/failure if there is
no simulator to run scripts on.   

a29k-coff       - Fortran requires exact FP representation
a29k-rtems      - Fortran requires exact FP representation
arc-elf         - PR35997 old crtinit/fini problem 
arm-elf         - BUILT test results reported
arm-rtems       - BUILT
avr-elf         - failed compiling libobjc/sendmsg.c
d30v-elf        - ICE compiling libstdc++-v3/strstream.c at flow.c:1880
fr30-elf        - g77 requires exact FP representation
h8300-coff      - BUILT test results reported
h8300-rtems     - g77 says "gcc doesn't define all the built in types"
Why?
hppa1.1-proelf  - newlib/libc/machine/hppa still has .subspa
                - /newlib/libc/stdlib/ldtoa.c:652: ICE in
propagate_one_insn,
                        at flow.c:1615
                - /newlib/libc/stdio/findfp.c:179: ICE in
propagate_one_insn,
                        at flow.c:1615
hppa1.1-rtems   - see hppa1.1-proelf
i386-elf        - BUILT
i386-rtems      - PR6445 failed compiling libobj/sendmsg.c: at
reg-stack.c:990
i960-coff       - libobjc/encoding.c:887 XFmode undeclared.
i960-rtems      - thr-objc.c 
i960-elf        - libgloss/libnosys/write.c section attributes not
supported.
m32r-elf        - BUILT test results report
m68k-coff       - BUILT
m68k-elf        - BUILT
m68k-rtems      - BUILT
mcore-elf       - ICE at /libstdc++-v3/include/iomanip:146 in
expr.c:2768
mips64orion-elf - BUILT test results reported
mips64orion-rtems       - BUILT
mips-elf        - BUILT test results reported
mips-rtems      - BUILT
mn10200-elf     - ICE compiling unwind-sjlj.c:135
mn10300-elf     - BUILT test results reported
powerpc-eabi    - BUILT
powerpc-rtems   - BUILT
sh-coff         - BUILT test results reported   
sh-rtems        - BUILT
sh-elf          - BUILT
sh-rtemself     - BUILT
sparc-elf       - boehm-gc/typd_mlc.c: include/private/gcconfig.h:394:
                        parse error before -- token
sparc-rtems     - BUILT
v850-elf        - BUILT test results reported
xscale-elf      - BUILT


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985