Hello fellow LLVMers and Clangstas, We want to make Clang great, and we need your help! Helping is easy: just build Clang on your platform and start using it as your main compiler for LLVM and Clang development. Much of the Clang team has been living on Clang for at least several weeks already, and we've found it to be quite stable for development. If you run into problems---poor diagnostics, poor debugging experience, compiler crashes, rejecting valid code, whatever---please file Bugzillas so we can get them fixed. Steps to living on Clang: - Make sure you're getting a good revision of Clang/LLVM from Subversion by checking the Buildbots (http://google1.osuosl.org:8011/console). The clang-*-selfhost builds have passed self-host + testing and are good candidates. - Build Clang as part of LLVM (http://clang.llvm.org/get_started.html). I suggest a Release build, since Debug builds tend to be very slow. - Install Clang + LLVM somewhere that isn't where you do your normal LLVM/Clang development. - Configure with the environment variables CC=/path/to/clang CXX=/path/to/clang++, which works with either autoconf configure or CMake cmake/ccmake. - Build LLVM and Clang as normal. - Report your experiences to help us improve Clang! - Doug
On 04/14/2010 11:51 PM, Douglas Gregor wrote:> Hello fellow LLVMers and Clangstas, > > We want to make Clang great, and we need your help! > > Helping is easy: just build Clang on your platform and start using it as your main compiler for LLVM and Clang development.I'd love to, but this bug is a blocker for me: http://llvm.org/bugs/show_bug.cgi?id=6795 Best regards, --Edwin
On Apr 14, 2010, at 2:02 PM, Török Edwin wrote:> On 04/14/2010 11:51 PM, Douglas Gregor wrote: >> Hello fellow LLVMers and Clangstas, >> >> We want to make Clang great, and we need your help! >> >> Helping is easy: just build Clang on your platform and start using it as your main compiler for LLVM and Clang development. > > I'd love to, but this bug is a blocker for me: > http://llvm.org/bugs/show_bug.cgi?id=6795Thanks; we didn't know it was blocking anyone. I've marked it as such and we'll try to get it fixed. - Doug
I've been hoping to use Clang both for Mac OS X/iPhone OS development, as well as for embedded ARM development. My ARM tools currently are arm-elf-gcc and friends. Is it possible to build Clang & LLVM to target this platform? Note that I don't actually need ELF, it's an intermediate step toward a raw binary that gets downloaded to the device. I've been trying, with very limited success, to target ARM. I'm still not clear on where the divisions in the process really lie. What I'm hoping for (someday) is a "GNU-free" toolsuite based on Clang and LLVM. But for now, I can live with arm-elf-as and -ld, if that's the right way to go. I still don't know how LTO works into that. TIA, -- Rick On Apr 14, 2010, at 13:51:51, Douglas Gregor wrote:> Hello fellow LLVMers and Clangstas, > > We want to make Clang great, and we need your help! > > Helping is easy: just build Clang on your platform and start using it as your main compiler for LLVM and Clang development. Much of the Clang team has been living on Clang for at least several weeks already, and we've found it to be quite stable for development. If you run into problems---poor diagnostics, poor debugging experience, compiler crashes, rejecting valid code, whatever---please file Bugzillas so we can get them fixed. > > Steps to living on Clang: > > - Make sure you're getting a good revision of Clang/LLVM from Subversion by checking the Buildbots (http://google1.osuosl.org:8011/console). The clang-*-selfhost builds have passed self-host + testing and are good candidates. > > - Build Clang as part of LLVM (http://clang.llvm.org/get_started.html). I suggest a Release build, since Debug builds tend to be very slow. > > - Install Clang + LLVM somewhere that isn't where you do your normal LLVM/Clang development. > > - Configure with the environment variables CC=/path/to/clang CXX=/path/to/clang++, which works with either autoconf configure or CMake cmake/ccmake. > > - Build LLVM and Clang as normal. > > - Report your experiences to help us improve Clang! > > - Doug > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
2010/4/15 Douglas Gregor <dgregor at apple.com>:> - Report your experiences to help us improve Clang!I switched to Clang, and I got 49 new unexpected failures on Linux. Is this normal? (New, as in, there were no unexpected failures when compiled the same source with GCC.) -- Seo Sanghyeon
Hi, On Apr 14, 2010, at 10:51 PM, Douglas Gregor wrote:> Hello fellow LLVMers and Clangstas, > > We want to make Clang great, and we need your help! > > Helping is easy: just build Clang on your platform and start using it as your main compiler for LLVM and Clang development. Much of the Clang team has been living on Clang for at least several weeks already, and we've found it to be quite stable for development. If you run into problems---poor diagnostics, poor debugging experience, compiler crashes, rejecting valid code, whatever---please file Bugzillas so we can get them fixed.Been there, done that: http://rene.rebe.de/2010-02-16/llvm-clang-support-in-t2-sde-linux/ And reported C++ issues spotted while at it. I plan to further extend the testing and potentially default to Clang (without GCC) in a future T2 Linux revision.> Steps to living on Clang: > > - Make sure you're getting a good revision of Clang/LLVM from Subversion by checking the Buildbots (http://google1.osuosl.org:8011/console). The clang-*-selfhost builds have passed self-host + testing and are good candidates. > > - Build Clang as part of LLVM (http://clang.llvm.org/get_started.html). I suggest a Release build, since Debug builds tend to be very slow. > > - Install Clang + LLVM somewhere that isn't where you do your normal LLVM/Clang development. > > - Configure with the environment variables CC=/path/to/clang CXX=/path/to/clang++, which works with either autoconf configure or CMake cmake/ccmake. > > - Build LLVM and Clang as normal. > > - Report your experiences to help us improve Clang! > > - Doug-- René Rebe, ExactCODE GmbH, Jaegerstr. 67, DE-10117 Berlin http://exactcode.com | http://t2-project.org | http://rene.rebe.de
I can't switch to clang on my project until it can handle boost headers. On Thu, Apr 15, 2010 at 2:17 AM, Rene Rebe <rene at exactcode.de> wrote:> Hi, > > On Apr 14, 2010, at 10:51 PM, Douglas Gregor wrote: > >> Hello fellow LLVMers and Clangstas, >> >> We want to make Clang great, and we need your help! >> >> Helping is easy: just build Clang on your platform and start using it as your main compiler for LLVM and Clang development. Much of the Clang team has been living on Clang for at least several weeks already, and we've found it to be quite stable for development. If you run into problems---poor diagnostics, poor debugging experience, compiler crashes, rejecting valid code, whatever---please file Bugzillas so we can get them fixed. > > Been there, done that: http://rene.rebe.de/2010-02-16/llvm-clang-support-in-t2-sde-linux/ > > And reported C++ issues spotted while at it. I plan to further extend the testing and potentially default to Clang (without GCC) in a future T2 Linux revision. > >> Steps to living on Clang: >> >> - Make sure you're getting a good revision of Clang/LLVM from Subversion by checking the Buildbots (http://google1.osuosl.org:8011/console). The clang-*-selfhost builds have passed self-host + testing and are good candidates. >> >> - Build Clang as part of LLVM (http://clang.llvm.org/get_started.html). I suggest a Release build, since Debug builds tend to be very slow. >> >> - Install Clang + LLVM somewhere that isn't where you do your normal LLVM/Clang development. >> >> - Configure with the environment variables CC=/path/to/clang CXX=/path/to/clang++, which works with either autoconf configure or CMake cmake/ccmake. >> >> - Build LLVM and Clang as normal. >> >> - Report your experiences to help us improve Clang! >> >> - Doug > > -- > René Rebe, ExactCODE GmbH, Jaegerstr. 67, DE-10117 Berlin > http://exactcode.com | http://t2-project.org | http://rene.rebe.de > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
> We want to make Clang great, and we need your help!Doug, I don't see any type of selfbuild target in the LLVM top level makefile. This would be a useful way to automate the self build process. I've used similar mechanisms before on other compilers, where you can trivially invoke a three phase build (first you do a full build with your system compiler, then you use your built compiler to do another full build, and then take that most recent build compiler to build yet again...). The build options of the last two phases are identical, and the object files from those last two passes are compared to ensure that they are identical. Ideally you can control the build options of the initial build and last two builds independently (e.g. build a compiler without optimizations and with assertions, and then do the last two builds with assertions disabled, and optimizations on) - I'm not sure how easy this is with the autoconfig based system LLVM/clang use, if at all. Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 8614 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100415/9ef6e874/attachment.bin>
On Apr 15, 2010, at 2:27 PM, Lacey, Mark wrote:>> We want to make Clang great, and we need your help! > > Doug, > > I don't see any type of selfbuild target in the LLVM top level makefile. > This would be a useful way to automate the self build process. > > I've used similar mechanisms before on other compilers, where you can > trivially invoke a three phase build (first you do a full build with your > system compiler, then you use your built compiler to do another full build, > and then take that most recent build compiler to build yet again...). The > build options of the last two phases are identical, and the object files > from those last two passes are compared to ensure that they are identical.Yes, we would love to have this, but nobody has taken the time to write the Makefile/CMake magic to make it happen. - Doug
How about building this in the CMake or auto* level we build a separate build script for it? I attache a simple version here. It does seem to work here. It's a shell script, which uses cmake for the building but it seems the second stage file works. I am not really sure why a third stage is needed, but it can be added quite easily. A windows version should be trivial to write (next week). A few rants about clang: This is the first time I was able to bootstrap the whole compiler. Which is great, don't get me wrong. But it was painfully slow, and the CPU of my machine became *really* hot unlike with gcc. The whole building process took more then 4 hours on this old cual core machine, while stage one took an hour more or less (I need to do a test again, without ccache). [elcuco at pinky ~/src/llvm] ls bootstrap-stage-2/bin/ -ltr total 262708 -rwxrwxr-x. 1 elcuco elcuco 5641794 2010-04-19 03:12 tblgen -rwxrwxr-x. 1 elcuco elcuco 985416 2010-04-19 04:41 FileCheck -rwxrwxr-x. 1 elcuco elcuco 6374 2010-04-19 04:41 count -rwxrwxr-x. 1 elcuco elcuco 122992 2010-04-19 04:41 not -rwxrwxr-x. 1 elcuco elcuco 24101 2010-04-19 05:34 llvm-config -rwxrwxr-x. 1 elcuco elcuco 18325933 2010-04-19 05:36 opt -rwxrwxr-x. 1 elcuco elcuco 7705301 2010-04-19 05:36 llvm-as -rwxrwxr-x. 1 elcuco elcuco 6671138 2010-04-19 05:36 llvm-dis -rwxrwxr-x. 1 elcuco elcuco 31626605 2010-04-19 05:37 llvm-mc -rwxrwxr-x. 1 elcuco elcuco 32630459 2010-04-19 05:38 llc -rwxrwxr-x. 1 elcuco elcuco 6814656 2010-04-19 05:38 llvm-ranlib -rwxrwxr-x. 1 elcuco elcuco 6875243 2010-04-19 05:38 llvm-ar -rwxrwxr-x. 1 elcuco elcuco 6827605 2010-04-19 05:38 llvm-nm -rwxrwxr-x. 1 elcuco elcuco 14608549 2010-04-19 05:39 llvm-ld -rwxrwxr-x. 1 elcuco elcuco 7506306 2010-04-19 05:39 llvm-prof -rwxrwxr-x. 1 elcuco elcuco 8310633 2010-04-19 05:39 llvm-link -rwxrwxr-x. 1 elcuco elcuco 25527057 2010-04-19 05:40 lli -rwxrwxr-x. 1 elcuco elcuco 8217315 2010-04-19 05:40 llvm-extract -rwxrwxr-x. 1 elcuco elcuco 18994379 2010-04-19 05:42 bugpoint -rwxrwxr-x. 1 elcuco elcuco 1011333 2010-04-19 05:43 llvm-bcanalyzer -rwxrwxr-x. 1 elcuco elcuco 6468 2010-04-19 05:43 llvm-stub -rwxrwxr-x. 1 elcuco elcuco 42747 2010-04-19 07:28 c-index-test -rwxrwxr-x. 1 elcuco elcuco 60447800 2010-04-19 07:29 clang lrwxrwxrwx. 1 elcuco elcuco 51 2010-04-19 07:29 clang++ -> /home/elcuco/src/llvm/bootstrap-stage-2/bin/./clang On Fri, Apr 16, 2010 at 12:27 AM, Lacey, Mark <mark.lacey at intel.com> wrote:> > We want to make Clang great, and we need your help! > > Doug, > > I don't see any type of selfbuild target in the LLVM top level makefile. > This would be a useful way to automate the self build process. > > I've used similar mechanisms before on other compilers, where you can > trivially invoke a three phase build (first you do a full build with your > system compiler, then you use your built compiler to do another full build, > and then take that most recent build compiler to build yet again...). The > build options of the last two phases are identical, and the object files > from those last two passes are compared to ensure that they are identical. > > Ideally you can control the build options of the initial build and last two > builds independently (e.g. build a compiler without optimizations and with > assertions, and then do the last two builds with assertions disabled, and > optimizations on) - I'm not sure how easy this is with the autoconfig based > system LLVM/clang use, if at all. > > Mark > > > _______________________________________________ > 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/20100419/45b20edf/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: bootstrap-clang.sh Type: application/x-sh Size: 372 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100419/45b20edf/attachment.sh>
> > A windows version should be trivial to write (next week). > > Comparing the object files on Windows may be tricky, because IIRC they > contain timestamps.This could be worked around by adding a hack (enabled by command-line options of various tools) to zero out the time/date stamp in the MS COFF header. Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 8614 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100419/a8502624/attachment.bin>
On Mon, Apr 19, 2010 at 4:52 PM, Óscar Fuentes <ofv at wanadoo.es> wrote:> The third stage is for comparing the output of clang (as compiled by > gcc) against clang (as compiled by clang). The whole process is: > > Stage 1: build clang with gcc > > Stage 2: build clang with the clang created by gcc > > Stage 3: build clang with the clang created by clang. > > Final test: compare the object files geneated on Stage 2 with the object > files generated on Stage 3. >This is the first time stage3 has been built, I am happy (up until now, stage3 was failing at the first compilation): [elcuco at pinky ~/src/llvm] ls -l bootstrap-stage-*/bin/clang -rwxrwxr-x. 1 elcuco elcuco 23594232 2010-05-06 22:56 bootstrap-stage-1/bin/clang -rwxrwxr-x. 1 elcuco elcuco 24391566 2010-05-06 23:10 bootstrap-stage-2/bin/clang -rwxrwxr-x. 1 elcuco elcuco 24395343 2010-05-06 23:32 bootstrap-stage-3/bin/clang I already know that stage2 and stage3 are different, which means something is not really working. Does anyone have a clue about this? Is this a known issue, or should I report this? Now lets test if bash compiles. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100507/73a33693/attachment.html>
On May 6, 2010, at 2:19 PM, Diego Iastrubni wrote:> On Mon, Apr 19, 2010 at 4:52 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: > The third stage is for comparing the output of clang (as compiled by > gcc) against clang (as compiled by clang). The whole process is: > > Stage 1: build clang with gcc > > Stage 2: build clang with the clang created by gcc > > Stage 3: build clang with the clang created by clang. > > Final test: compare the object files geneated on Stage 2 with the object > files generated on Stage 3. > > This is the first time stage3 has been built, I am happy (up until now, stage3 was failing at the first compilation): > > [elcuco at pinky ~/src/llvm] ls -l bootstrap-stage-*/bin/clang > -rwxrwxr-x. 1 elcuco elcuco 23594232 2010-05-06 22:56 bootstrap-stage-1/bin/clang > -rwxrwxr-x. 1 elcuco elcuco 24391566 2010-05-06 23:10 bootstrap-stage-2/bin/clang > -rwxrwxr-x. 1 elcuco elcuco 24395343 2010-05-06 23:32 bootstrap-stage-3/bin/clang > > > I already know that stage2 and stage3 are different, which means something is not really working. Does anyone have a clue about this? Is this a known issue, or should I report this?It's known that we differ, but nobody has investigated why. Please go ahead and file a Bugzilla. - Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100506/ff0eb3f0/attachment.html>