Hi Woon Yung, Woon yung Liu <ysai...@yahoo.com> writes: > Thank you for your feedback. > > New changes in this updated version: > > gcc/config/mips/mips.c:added a check against the use of both -mips16 and > -march=r5900. > libgcc/configure.ac:added a check for the support of -mips16 by the > target. > libgcc/config.host: replaced all explicit checks for the r5900 arch with > a test for libgcc_cv_mips16, when checking for whether the MIPS16 ASE is > supported. > > > > I have tested the mechanism by replacing the test for -mips16 with -mno- > mips16, and I can see the test result for libgcc_cv_mips16 within > config.host getting changed. > > > Please feel free to give further comments.
Sorry for the delay, I was waiting for trunk to open and then go side tracked. With a tweak to the new check in mips.c I think this is looking OK. Do you have GCC FSF copyright assignment in place? Your change might be small enough not to need it but it assignment would make it easier. I can find copyright assignment from Joergen who was original author of this which is good news. I assume you are planning on submitting your work on r5900 vector support which will certainly need copyright assignment so this could be a good time to sort it out. Sorry for not checking this earlier so this could already be in progress. Let me know and I'll send the forms. Thanks, Matthew > > Thanks and regards, > -W Y > > > On Tuesday, February 23, 2016 5:09 PM, Matthew Fortune > <matthew.fort...@imgtec.com> wrote: > Woon yung Liu <ysai...@yahoo.com> wries > > Bump! Sorry, but could I please get an answer? I'm willing to update > > the patch without credit, if necessary. > > Hi WY, > > Apologies for exceptionally slow response. > > The patch you referenced is mostly OK but I would like to get the MIPS16 > check changed to a configure time check for MIPS16 support rather than > checking for r5900. I.e. I think we should have GCC raise an error for - > march=r5900 -mips16 and then a configure time check using just -mips16 > would fail. That can then be used to choose whether to build the mips16 > code instead of this: > > + if test x$with_arch != xr5900; then > + tmake_file="$tmake_file mips/t-mips16" > + fi > > This change should also make it possible to have mips.exp simply skip > the mips16 tests for r5900 without having to tell it explicitly about > r5900. > > Thanks, > Matthew > > > > The patch is working for the R5900 hard-fp mode. I've also used the > > same, patched copy of GCC, to build the toolchain for the IOP (MIPS > > R3000A, 32-bit MIPS I with no FPU) and it also builds correctly. > > > > If I should be writing to someone else specifically, could someone > > please tell me who I should be writing to instead? > > > > > > Thanks and regards, > > -W Y > > > > > > > > On Tuesday, January 26, 2016 5:41 PM, Woon yung Liu > <ysai...@yahoo.com> wrote: > > Hi, > > > > I refer to the previous message by Juergen, regarding his patch to > libgcc. > > https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01725.html > > > > As of now, libgcc (of GCC v5.3.0) still has the problem of building > > support for both soft and hard floats, when there is no support for > > hard floats by the R5900 (and hence resulting in the generation of > recursive functions like extendsfdf2). > > > > That patch doesn't seem to have been committed. I would very much like > > to help to see it get committed because GCC's support for the R5900 is > > currently not suitable for PlayStation 2 development; > > software-floating point emulation is severely detrimental to > performance. > > What else needs to be done first, before it can be accepted? > > > > Thanks and regards, > > -W Y
