This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


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

Re: MIPS libstdc++-v3 x86-x-mips-elf doesn't build



Well, whatever. 

I would prefer to have the mips port work like all the other ports. 
Having some of the ports use this header file, and define _MIPS_ISA or 
__mips, or whatever is bogus. There's got to be something consistent that 
the configure scripts can use to figure out what the eventual target is.

Eric, I've cc'd you because I believe you are the mips maintainer. If you 
can think of a way to do this, or can suggest a sane alternative, please 
advise.

In the meantime, the configure.target bits that turn on mips atomicity.h 
are being reverted. Sorry, HJ.

(In addition, the generic bits in mips/bits/atomicity.h have been excised.)

2001-07-30  Benjamin Kosnik  <bkoz@redhat.com>

        * configure.target: Remove mips from cpu table.
        * config/cpu/mips/bits/atomicity.h: Remove generic
        versions. Comment sgidefs include.
 
-benjamin



On Mon, 30 Jul 2001, H . J . Lu wrote:

> On Mon, Jul 30, 2001 at 10:45:39AM -0700, Benjamin Kosnik wrote:
> > 
> > > All targets which define _MIPS_ISA have sgidefs.h.
> > 
> > Can you find a way to differentiate between the two without _MIPS_ISA or 
> > sgidefs.h?
> 
> The whole idea of config/cpu/mips/bits/atomicity.h is to use the MIPS
> II instructions when gcc is generating code to run on MIPS II or above. 
> The only reliable way I know of to detect it in the preprocessor is to
> check _MIPS_ISA. If a target doesn't define _MIPS_ISA, which requires
> sgidefs.h, it doesn't make any senses to use a mips specific
> atomicity.h since the only thing it does is to support _MIPS_ISA.
> 
> BTW, some mips targets have
> 
> %{mips4:-U__mips -D__mips=4 -D__mips64}
> 
> But there is nothing for -mips2. If we want to add it for other mipss
> target, I'd suggest
> 
> http://gcc.gnu.org/ml/gcc-patches/2001-07/msg01937.html
> 
> 
> > 
> > Again, what is the intent here? Why can't something like the sparc 
> > configuration process be used?
> 
> You lost me here. I am not familiar with the sparc configuration
> process.
> 
> 
> H.J.
> 


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