Support for MIPS r5900

"Jürgen Urban" JuergenUrban@gmx.de
Tue Jan 8 22:49:00 GMT 2013


> > IIRC we defined doubles as 32bits wide in our old port.  We simply 
> > didn't support 64bit wide doubles.  I don't remember what mechanism we 
> > used to make this happen.
> 
> Ah, yeah.

I think limiting wide doubles would be good.

> >>> I tried to disable dmult and ddiv (see mips.md). Disabling worked, but
> >>> now muldi3 calls itself in libgcc2. I thought this should work,
> because
> >>> I got this working with GCC 4.3, but the latest GCC version is a
> >>> problem. multi3 is calling muldi3, so that muldi3 should be able to
> use
> >>> mulsi3, because it is the same C code in libgcc2. Can someone get me
> >>> some hints or comments? How can this be debugged?
> >>
> >> Not sure, sorry.
> > IIRC I simply disabled muldi3_internal2 and I think we defined away 
> > everything related to timode except register-register moves.

@Jeff: I think you know the stringent copyright rules for GCC. I want to use the code from the original patch, but I don't know how many people were involved. So I can't use it without copyright problems. Can you please tell me which code can I use without encountering copyright problems? I plan to submit the code for fixing the r5900 short loop bug in GCC.

> AIUI the problem that Jürgen's hitting is that _muldi3.o
> in libgcc actually contains __multi3 on 64-bit targets,
> because LIBGCC2_UNITS_PER_WORD == 8.  Presumably _mulsi3.o would
> then contain __muldi3 where needed, but that file doesn't exist.
> So he was trying to add it.

Yes, this is exactly what happened.

Best regards
Jürgen



More information about the Gcc-patches mailing list