Support for MIPS r5900
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,
> >>> 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
> >>> 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.
More information about the Gcc-patches