mps32 was Re: upcoming snapshot and 4.6.2

[gregory.menke at gsfc.nasa.gov]

Ralf Corsepius writes:
 > On Tue, 2004-09-28 at 17:14, gregory.menke at gsfc.nasa.gov wrote:
 > > Ralf Corsepius writes:
 > >  > 
 > >  > The essential question to me is:
 > >  > Is -mips32 compiled code compatible to -mips1 compiled code?
 > >  > 
 > > 
 > > IIRC, the changes are principally #ifdefs to influence cpu_asm related
 > > register stuff, not gcc code generation issues.  The mips32 question
 > > arises infrequently enough that I keep forgetting the details.
 > AFAIS from the patches in GNATS, you remember correctly.
 > 
 > >   I
 > > think the upshot is -mips1 or -mips3 is still required to make gcc do
 > > the right stuff, mips32 is there to force R4000 registers in cases
 > > where they're required.  Anyone, please correct me if I'm
 > > mis-remembering.
 > Well, I suspect a compatibility problem between "gcc -mips32" rsp
 > "-arch=mips32" and your patches.

I think this means we have an unfortunate coincidence in naming.  

 
 > Your patches rely on "#define __mips32". Current mips-rtems-gcc only
 > supports and implies -mips1.
 > => If I understand correctly, you assume using gcc -mips1 -D__mips32.
 > 
 > "gcc -mips32" rsp. "gcc -arch=mips32" implicitly changes code generation
 > to mips32 and #defines __mips32 rsp. #defines __mips32__.
 > 
 > So, what I actually was asking is: Does the mips-RTEMS code with your
 > changes applied support -mips32?

The mips32 people need to weigh in on this one.  My understanding was
that normal gcc code generation was sufficient- meaning no -mips32.


 > If so, it would be worth considering adding a -mips32 multilib variant
 > to gcc (at least for rtems4.7), if not, I'd prefer to see your patches
 > changed to not using -D__mips32, because this can be ambiguous and might
 > conflict with the flags being implied by "gcc -mips32"
 > 
 > (All defines starting with double underscores are reserved)

Agreed.  Since its half done with PR601, would it be reasonable to get
all the __mips32 stuff in, then change it all to something else?


 > 
 > PS: All PM, I tried send to your GSFC email address bounce. Until now
 > I've tried 3 different sending addresses (even trying to notify your
 > postmaster fails). I'd therefore suggest you to refrain from using your
 > GSFC email address in public in future, because people can't reply to
 > you. Sorry, but I feel saying this is inevitable.

I was hoping it was a transient problem.  I just called the GSFC
networking people, they would like a copy of the bounce.  If you could
email it w/ headers to "gregm-news at toadmail.com", I'll forward it to
them and we can do some diagnostics on this end.  Apparently, this
shouldn't be happening....  Sorry for the bother.

Gregm