<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 26, 2013 at 9:04 PM, Jonathan Roelofs <span dir="ltr"><<a href="mailto:jonathan@codesourcery.com" target="_blank">jonathan@codesourcery.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":7ab" style="overflow:hidden">Hi,<br>
<br>
I noticed that the Linux toolchain also adds the default multilib to the search path when targeting the "other" multilib that the biarch gcc installation supports.  For example, in a gcc installation providing two multilibs: '.;@m32' and '64;@m64', when -m64 is specified on the clang command line, both <gcc>/<triple>/<ver>/64/ and <gcc>/<triple>/<ver>/ are added to the search paths (There's a couple of tests for this specific case in clang/test/Driver/linux-ld.c:<u></u>109 and clang/test/Driver/cross-linux.<u></u>c:57).<br>

<br>
Is this correct for the opposite case (i.e. gcc providing '.;@m64' and '32;@m32' with -m32 on the command line) for which there don't seem to be any tests for or against it? How about on PPC64?<br></div>
</blockquote></div><br>A long time ago, I built GCC installs and created as many directories as I could (even if empty) to try to test all of the search paths that it ended up using. It *appeared* at the time that this was intentional, and it made everything more complex to be asymmetrical here. I would rather keep the symmetry to simplify the code and logic unless doing so breaks something really horrible.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Similarly, I'm hoping desperately that we can have the same biarch search pattern for PPC, x86, mips, and whatever other biarch toolchains we end up with. I don't want to start having different logic for each cpu type...</div>
</div>