> > 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
