atanasyan added a comment. In https://reviews.llvm.org/D50850#1250285, @wzssyqa wrote:
> This is really for Clang. I guess you mean that compiler-rt directory also > need to be patched. If you take a look at the previous version of this patch https://reviews.llvm.org/D50850?id=167419, you see that it changed LLVM files. Probably you attached another diff. As to `compiler-rt` - the Phabricator replace `R6` symbols by the `https://reviews.llvm.org/source/compiler-rt/` links. So my statement was "Could you attach an actual patch brings `R6` support to the Clang driver?". ================ Comment at: lib/Driver/ToolChains/Gnu.cpp:2093 BiarchTripleAliases.append(begin(MIPSELTriples), end(MIPSELTriples)); - BiarchTripleAliases.append(begin(MIPSTriples), end(MIPSTriples)); + BiarchLibDirs.append(begin(MIPSN32ELLibDirs), end(MIPSN32ELLibDirs)); + BiarchTripleAliases.append(begin(MIPSN32ELTriples), end(MIPSN32ELTriples)); ---------------- wzssyqa wrote: > atanasyan wrote: > > Ditto > As a question: why MIPSTriples here? > the above mips64 lines don't include any EL Triples. I do not remember exact answer, although I might be an author if this code. Maybe it handle some complicated directories tree from multi-arch toolchains. Are all tests passed if you remove this line? ================ Comment at: lib/Driver/ToolChains/Gnu.cpp:2437 if (getTriple().getEnvironment() == llvm::Triple::GNUABI64 || - getTriple().isAndroid() || - getTriple().isOSFreeBSD() || + getTriple().getEnvironment() == llvm::Triple::GNUABIN32 || + getTriple().isAndroid() || getTriple().isOSFreeBSD() || ---------------- wzssyqa wrote: > atanasyan wrote: > > Are you sure that integrated LLVM assembler is ready to support N32 code > > generation? Anyway this change is for a separate patch. > I didn't have so many test, while helloworld programs really works. > > You created a patch that teaches the Clang driver to understand (pass arguments to backend, find includes and libraries etc) N32 ABI better. Now I can compile "hello world". And after that you decided that LLVM backend does not have any MIPS N32 ABI related problems. I think we can enable the integrated assembler when a) it's possible to recursively build Clang with N32 ABI, b) all tests from LLVM test suite (https://llvm.org/docs/TestSuiteGuide.html) are passed in N32 ABI mode, c) we check that LLVM produces correct DWARF for N32. https://reviews.llvm.org/D50850 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
