Re: Bug in strlen on old MIPS CPUs

[Corinna Vinschen <vinschen at redhat dot com>]

On Jan 10 10:44, Steve Legg wrote:
> > Wouldn't it be better to add a nop, like this?
> > [...]
> That works too - GCC generates exactly this code anyway (which is why
> I prefer just using the C version ;).  But yes, either patch will work
> (btw if someone you are committing this then it's definitely worth
> adding a check for __R2000 too because it would in theory have the
> exact same problem and GCC does support it so it's possible to build
> such a configuration).

As for the actual condition, looking into the GCC sources I found this:

/* Which processor to schedule for.  Since there is no difference between
   a R2000 and R3000 in terms of the scheduler, we collapse them into
   just an R3000. [...] */

This means, there's no default definitions for the R2000, just for the
R3000 ("R3000" and "_R3000").

Additionally:

  /* True if the result of a load is not available to the next instruction.
     A nop will then be needed between instructions like "lw $4,..."
     and "addiu $4,$4,1".  */
  #define ISA_HAS_LOAD_DELAY      (ISA_MIPS1                              \
				   && !TARGET_MIPS3900                    \
				   && !TARGET_MIPS16)

and

  static const struct mips_cpu_info mips_cpu_info_table[] = {
    [...]
    /* MIPS I processors.  */
    { "r3000", PROCESSOR_R3000, 1, 0 },
    { "r2000", PROCESSOR_R3000, 1, 0 },
    { "r3900", PROCESSOR_R3900, 1, 0 },
    [...]

So, apparently all CPUs with mips1 ISA with the exception of R3900 are
affected, which just leaves R2000 and R3000.

Consequentially just using `#ifdef _R3000' should cover this situation,
shouldn't it?


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat