[v3, 3.4 & HEAD] set cpu_include_dir for mips*-*-linux* and arm*-linux-* targets, update baseline file

[Matthias Klose]

Ok here is the updated patch, arm included as well. IIRC the baseline
is the the same for mips64{,el} and mips{,el}, and we don't care about
the emotion engine (please see mail exchange below). Ok to checkin?

Index: configure.host
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/configure.host,v
retrieving revision 1.21.6.2
diff -u -r1.21.6.2 configure.host
--- configure.host	18 Mar 2004 17:36:12 -0000	1.21.6.2
+++ configure.host	26 Aug 2004 23:46:47 -0000
@@ -221,22 +221,27 @@
 # Set any OS-dependent and CPU-dependent bits.
 # THIS TABLE IS SORTED.  KEEP IT THAT WAY.
 case "${host}" in
-  mips*-*-linux*)
-    atomicity_dir="cpu/mips"
-    ;;
-  x86_64-*-linux*)
-    abi_baseline_pair="x86_64-linux-gnu"
-    ;;
   alpha*-*-freebsd5*)
     abi_baseline_pair="alpha-freebsd5"
     ;;
+  arm*-*-linux*)
+    abi_baseline_pair="arm-linux-gnu"
+    ;;
   i*86-*-freebsd4*)
     abi_baseline_pair="i386-freebsd4"
     ;;
   i*86-*-freebsd5*)
     abi_baseline_pair="i386-freebsd5"
     ;;
+  mips*-*-linux*)
+    cpu_include_dir="cpu/mips"
+    atomicity_dir="cpu/mips"
+    abi_baseline_pair="mips-linux-gnu"
+    ;;
   sparc*-*-freebsd5*)
     abi_baseline_pair="sparc-freebsd5"
     ;;
+  x86_64-*-linux*)
+    abi_baseline_pair="x86_64-linux-gnu"
+    ;;
 esac

Thiemo Seufer writes:
> Matthias Klose wrote:
> > Eric Christopher writes:
> > > On Tue, 2004-08-24 at 13:08, Matthias Klose wrote:
> > > > The mips*-*-linux* targets are currently recognised as "generic".
> > > > This seems to be wrong, as there is an old mips-linux-gnu baseline
> > > > file. The following patch explicitely overwrites the configuration for
> > > > the mips*-*-linux* in the last case statement.
> 
> I haven't seen the proposed patch, but I'd say it should include
> something like this (unless we do an additional feature test for the
> non-linux case):
> 
> --- configure.host      11 Jul 2004 07:46:21 -0000      1.27
> +++ configure.host      26 Aug 2004 09:11:57 -0000
> @@ -89,7 +89,14 @@ case "${host_cpu}" in
>      # Of course, there is no sane way to test for this, no ABI macro,
>      # and no consistent host_cpu name differentiation. Therefore, only
> -    # use it where it is known to be safe, ie it runs linux (see below).
> +    # use it where it is known to be safe, ie it runs linux.
> -    try_cpu=generic
> +    case "${host_os}" in
> +      linux*)
> +       try_cpu=mips
> +       ;;
> +      *)
> +       try_cpu=generic
> +       ;;
> +    esac
>      ;;
>    m680[246]0)
>      try_cpu=m68k
> @@ -238,9 +245,6 @@ esac
>  # Set any OS-dependent and CPU-dependent bits.
>  # THIS TABLE IS SORTED.  KEEP IT THAT WAY.
>  case "${host}" in
> -  mips*-*-linux*)
> -    atomicity_dir="cpu/mips"
> -    ;;
>    x86_64-*-linux*)
>      abi_baseline_pair="x86_64-linux-gnu"
>      ;;
> 
> Btw, the comment about ABI macros is misleading, there is _MIPS_ISA as
> well as __mips.
> 
> > > The main reason from what I recall is that the atomicity file was only
> > > useful for mips2 and above processors (and also support atomic
> > > instructions). The current "workaround" of setting mips2 in the file is
> > > only marginally useful, and only when you don't explicitly set cpu and
> > > set abi.
> 
> It is more useful than that, because the mips-linux kernel emulates
> ll/sc for MIPS I CPUs.
> 
> > > It _does_ break mips1 cpus and cpus without atomic instructions (like
> > > the emotion engine).
> > 
> > Thiemo, is this an issue for us?
> 
> The ps2linux on the EE is the odd one out. It doesn't emulate ll/sc but
> uses a different method (look if a certain value in k1 got destroyed,
> which means there was an interrupt in the meanwhile). This doesn't work
> for SMP, and the userland is incompatible to the mips-linux one.
> 
> For this reason, the ps2linux is pretty much irrelevant for this
> discussion, they do their own stuff anyway.
> 
> > > That said, as long as the patch doesn't break mips64-linux i don't much
> > > care other than the limitation should be documented.
> > 
> > documented where?
> > 
> > > A feature test
> > > (perhaps by assembly of the instructions)
> 
> At least gas will happily assemble ll/sc for any CPU which claims to
> do MIPS II, so this isn't better than testing some compiler defines.
> 
> > > to find out whether or not
> > > ll/sc are supported might be a good idea.
> 
> #if defined(__mips) && (__mips > 1)
>   /* use ll/sc */
> #else
>   /* use generic */
> #endif
> 
> works for GCC, and should IIRC also work for the IRIX cc.
> 
> > Thiemo Seufer, one guy doing work on Debian mips, seems to be away,
> > and I don't know, how to write this test. If I understand you right,
> > then a patch to only use the architecture specific files and baseline
> > is to limit the test to mips-*-linux*|mipsel-*-linux* in these cases?
> 
> I don't see why mips and mips64 should be handled differently.
> 
> 
> Thiemo