On 2012/8/30 02:44 AM, Richard Sandiford wrote: > Chung-Lin Tang <clt...@codesourcery.com> writes: >> On 2012/7/6 02:23 PM, Richard Sandiford wrote: >>> Richard Sandiford <rdsandif...@googlemail.com> writes: >>>>> (3) Also related to libraries, I edited CRT_CALL_STATIC_FUNCTION to emit >>>>> a 32-bit code sequence under both MIPS/MIPS16 mode (under O32). >>>>> >>>>> As you can see in the original Feb. patch, I had changes to emit a >>>>> MIPS16 version of these static calls, but with the changes in (2) above, >>>>> they will not work with the usual situation of a 32-bit MIPS built /lib >>>>> (.init/.fini will have 32/16-bit code improperly concatenated). >>>>> >>>>> The CodeSourcery builds use an independent mips16 sysroot for this, so a >>>>> MIPS16 CRT_CALL_STATIC_FUNCTION works there. For the usual case, I think >>>>> making it 32-bit is the compatible choice. >>>> >>>> Yeah, I agree that sounds like the right call. Please do the same >>>> for the n32/n64 version (i.e. explicitly make it nomips16 rather >>>> than add the #error). >>> >>> BTW, doing this has removed my main concern about having dead code. >>> The original patch had a separate MIPS16 implementation that (as things >>> stood) could never be used by stock sources. That would make it difficult >>> to maintain. >>> >>> Now that the MIPS16 library support is purely adding nomips16 attributes >>> to code that is obviously nomips16, those parts are OK on their own, thanks. >>> (I.e. the mips.h change, the libgcc change, and the libgomp change.) >>> Feel free to drop the multilib thing if you don't want to implement >>> --with-multilib-list. >> >> Hi Richard, just FYI, I just committed the said approved parts. >> gcc/config/mips/t-linux64 had one additional change, adding >> ../lib/mips16 to the corresponding MULTILIB_OSDIRNAMES, or else we end >> with a weird option-named directory for the mips16 libraries. > > Sorry, but the t-linux64 stuff wasn't approved. It was just the mips.h > change, the libgcc change and the libgomp change. > > Please revert the patch to t-linux64. My original objection to adding > mips16 unconditionally still stands: it isn't correct for people who > configure for processors that don't have the MIPS16 ASE (such as Octeon).
I have reverted that part. Maybe a list of proper march=XXX/mips16 added to MULTILIB_EXCLUSIONS will do what you're mentioning, though I haven't tried testing that for now. Thanks, Chung-Lin
