mips cc1 spec vs. fp reg defines vs. assembly code

[cgd@broadcom.com]

So, i've been tracking down a bunch of target mipsisa64-elf failures
when run under a mipsisa64-elf sim (mips-sim-idt64 target board,
slightly hacked to use the -mips64 flag/multilib to compile code).

So, as it turns out what's happening is:

* compiling the test itself, a .c file, "-mips64" causes "-mfp64" to
  be set via CC1_SPEC, which in turn causes the compiler to emit, for
  instance, double ops using odd FP regs.  OK.

* compiling libgloss's crt0.c, which sets the SR:FR value to enable
  use of 64-bit registers, I found that it was being compiled so that
  SR:FR = 0 (old-style FPU, i.e., no double ops on odd FP regs), via
  code like:

#if (__mips < 3) || (__mips_fpr==32)
#define STATUS_MASK (SR_CU1|SR_PE)
#else   
# For mips3 or mips4, turn on 64-bit addressing and additional float regs
#define STATUS_MASK (SR_CU1|SR_PE|SR_FR|SR_KX|SR_SX|SR_UX)
#endif
        li      v0, STATUS_MASK
        mtc0    v0, C0_SR

  (not quite correct for mips32, but that's not the problem here 8-).


Looking through the specs, i figured, ahh, OK, sane thing to do here
would be to cause __mips_fpr to be set via the new
TARGET_CPU_CPP_BUILTINS / builtin_define mechanism.

I did that like:

#define TARGET_CPU_CPP_BUILTINS()                       \ 
  do                                                    \
    {                                                   \
      if (TARGET_FLOAT64)                               \
        builtin_define ("__mips_fpr=64");               \  
      else                                              \
        builtin_define ("__mips_fpr=32");               \
    }                                                   \  
  while (0)


But in fact it wasn't so sane after all:

* -mfp64 wasn't being passed to cc1 -- I'd guess because it was doing
   preprocessed assembly, and the -mfp64 was specified in CC1_SPEC --
   and therefore TARGET_FLOAT64 wasn't true.

* __mips_fpr wasn't being defined _at all_, I guess because
  TARGET_CPU_CPP_BUILTINS wasn't being invoked for preprocessed
  assembly?


I didn't trace through the code so i'm not 100% sure that I understand
what's going on, but my hypothesis fits my data.  8-)

Does this sound plausable?  is TARGET_CPU_CPP_BUILTINS expected to be
used for preprocessed assembly?  What should one do with things that
used to be in CC1_SPEC that drive decisions that need to be put into
CPP defines (even for preprocessed asm)?  put those things into
CPP_SPEC?



thanks,

chris