Re: Calling a MIPS maintainer (was Re: GCC build failed for mips-elf with your patch on 2002-06-18T19:37:45Z.)

[Daniel Jacobowitz <drow at mvista dot com>]

On Tue, Jun 18, 2002 at 08:16:43PM -0400, Phil Edwards wrote:
> On Tue, Jun 18, 2002 at 10:18:25PM +0000, GCC regression checker wrote:
> > /tmp/ccGfgrTh.s:7081: Error: opcode not supported on this processor: R3000 (MIPS1) `ll $4,-4($3)'
> > /tmp/ccGfgrTh.s:7083: Error: opcode not supported on this processor: R3000 (MIPS1) `sc $5,-4($3)'
> > make[3]: *** [complex_io.lo] Error 1
> > make[3]: Leaving directory `/anubis/mummy/tbox/mips-elf/build/mips-elf/libstdc++-v3/src'
> 
> Mea culpa, but I'd like a decision from the MIPS maintainers on what to do.
> 
> The regression checker doesn't keep the configure output (the screen output,
> I mean, not the config.log) for the last good build, but in the libstdc++-v3
> config, the build log currently says:
> 
>     ....
>     CPU config directory is cpu/mips
>     OS config directory is os/generic
>     ....
> 
> and I'll bet that it used to say
> 
>     CPU config directory is cpu/generic
>     OS config directory is os/generic
> 
> The problem is that we have a libstdc++-v3/config/cpu/mips/ directory,
> but the shell fragements to use that directory were reverted.  (H.J. Lu
> had #include'd a file, or something.)  So by default, mips used the generic
> CPU settings, even though the configury files were still present.
> 
> Then, earlier today, I made the v3 configury "smarter" (sigh), and now
> it will use cpu/mips for a mips target unless told otherwise.  (The file
> doesn't tell it otherwise because the /previous/ version didn't, and I
> was unaware that the mips CPU config directory was in fact unused.)
> 
> 
> So, MIPS maintainers:  I can just override the default and force the generic
> CPU settings for MIPS; this goes back to the way we were yesterday, but
> note that the generic CPU atomicity routines aren't actually atomic, i.e.,
> generic == not actually working.  The other choice is:  the file presently
> in the MIPS directory can be fixed by one of you.  :-)  What should I do?

FWIW, I'd recommend forcing the use of ll/sc (via .set push/.set
mips2/.set pop).  I don't know how various embedded MIPS-I systems will
like that, though...

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer