On 2 Jun 2015 2:04 pm, "Jonathan Roelofs" <jonathan at codesourcery.com> wrote:> > > > On 6/2/15 2:38 PM, Duncan P. N. Exon Smith wrote: >> >> >>> On 2015-Jun-01, at 19:47, Chris Bieneman <beanz at apple.com> wrote: >>> >>>> If we drop support for building compiler-rt with GCC, this gets evensimpler. Compiler-rt is *Clang's* runtime library, after all.>>> >>> >>> I don’t know if it is on the table to drop supporting compiler-rt withGCC, but that would dramatically simplify things.>> >> >> Weird, I'd assumed building compiler-rt with something other than >> clang was unsupported. Maybe I'm missing something, but shouldn't >> the only supported configuration be building with the just-built >> clang? > > > The current default for an in-tree build is to build compiler-rt withwhatever compiler is being used to build Clang... sometimes that compiler is GCC.> > I agree though. We should always use the just-built Clang, and have thatbehavior be opt-out (if folks need it), instead of opt-in as it is now. What would the build system do for a cross compile of Clang?> > Jon > > >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > -- > Jon Roelofs > jonathan at codesourcery.com > CodeSourcery / Mentor Embedded > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150602/09aee900/attachment.html>
> On Jun 2, 2015, at 6:29 PM, Richard Smith <richard at metafoo.co.uk> wrote: > > On 2 Jun 2015 2:04 pm, "Jonathan Roelofs" <jonathan at codesourcery.com <mailto:jonathan at codesourcery.com>> wrote: > > > > > > > > On 6/2/15 2:38 PM, Duncan P. N. Exon Smith wrote: > >> > >> > >>> On 2015-Jun-01, at 19:47, Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote: > >>> > >>>> If we drop support for building compiler-rt with GCC, this gets even simpler. Compiler-rt is *Clang's* runtime library, after all. > >>> > >>> > >>> I don’t know if it is on the table to drop supporting compiler-rt with GCC, but that would dramatically simplify things. > >> > >> > >> Weird, I'd assumed building compiler-rt with something other than > >> clang was unsupported. Maybe I'm missing something, but shouldn't > >> the only supported configuration be building with the just-built > >> clang? > > > > > > The current default for an in-tree build is to build compiler-rt with whatever compiler is being used to build Clang... sometimes that compiler is GCC. > > > > I agree though. We should always use the just-built Clang, and have that behavior be opt-out (if folks need it), instead of opt-in as it is now. > > What would the build system do for a cross compile of Clang? >This is the big question right? If we decide to only support building compiler-rt with the just-built clang that inherently means that you always have to build a clang that can run on host, so cross-compiling clang means building for host first, then the target. I don’t think that is the behavior we want. I suspect the behavior we probably want is to use the just-built clang by default unless you are cross-compiling, in which case use the host compiler. Whether or not the host compiler needs to be clang, or any version restrictions we want to apply is a separate issue. -Chris> > > > Jon > > > > > >> _______________________________________________ > >> LLVM Developers mailing list > >> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/> > >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev> > >> > > > > -- > > Jon Roelofs > > jonathan at codesourcery.com <mailto:jonathan at codesourcery.com> > > CodeSourcery / Mentor Embedded > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/> > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150603/e61f7f23/attachment.html>
Duncan P. N. Exon Smith
2015-Jun-03 20:42 UTC
[LLVMdev] [RFC] Ideas on improving Compiler-RT CMake
> On 2015-Jun-03, at 12:57, Chris Bieneman <beanz at apple.com> wrote: > > >> On Jun 2, 2015, at 6:29 PM, Richard Smith <richard at metafoo.co.uk> wrote: >> >> On 2 Jun 2015 2:04 pm, "Jonathan Roelofs" <jonathan at codesourcery.com> wrote: >> > >> > >> > >> > On 6/2/15 2:38 PM, Duncan P. N. Exon Smith wrote: >> >> >> >> >> >>> On 2015-Jun-01, at 19:47, Chris Bieneman <beanz at apple.com> wrote: >> >>> >> >>>> If we drop support for building compiler-rt with GCC, this gets even simpler. Compiler-rt is *Clang's* runtime library, after all. >> >>> >> >>> >> >>> I don’t know if it is on the table to drop supporting compiler-rt with GCC, but that would dramatically simplify things. >> >> >> >> >> >> Weird, I'd assumed building compiler-rt with something other than >> >> clang was unsupported. Maybe I'm missing something, but shouldn't >> >> the only supported configuration be building with the just-built >> >> clang? >> > >> > >> > The current default for an in-tree build is to build compiler-rt with whatever compiler is being used to build Clang... sometimes that compiler is GCC. >> > >> > I agree though. We should always use the just-built Clang, and have that behavior be opt-out (if folks need it), instead of opt-in as it is now. >> >> What would the build system do for a cross compile of Clang? >> > This is the big question right? If we decide to only support building compiler-rt with the just-built clang that inherently means that you always have to build a clang that can run on host, so cross-compiling clang means building for host first, then the target. > > I don’t think that is the behavior we want.Why not?> I suspect the behavior we probably want is to use the just-built clang by default unless you are cross-compiling, in which case use the host compiler.This sounds reasonable (and would obviously be a big improvement), but I'm interested in what the arguments are against the above/below. Another option that seems superficially reasonable to me: - Only support building compiler-RT with the "matching" clang. - When cross-compiling clang, only support the same version of clang as the host (and use the host compiler). In other words, when cross-compiling, only support a two-stage build, where the first stage builds a host clang, and the second stage builds the cross clang. - When not cross-compiling, always use the just-built clang.> Whether or not the host compiler needs to be clang, or any version restrictions we want to apply is a separate issue.