Thanks to Jakob's work on Sparcv9 ABI in Clang and recent changes to Sparc code generator, I am happy to announce that Clang can self host itself on Linux/Sparc64 and on FreeBSD/Sparc64. However, it still fails on a few unit tests and nightly tests, primarily due to misaligned memory accesses in the code (See bugs 18482, 18500, 18502, 18536, 18693). Unlike other architectures, misaligned loads/stores cause bus errors in Sparc. To catch bugs specific to Sparc such as the misalignment bugs, it would be great to get some buildbots running on Sparc machines. I see that there are buildbot slaves already running on Sparc machines in GCC compile farm (for example, gcc63, gcc64, listed at http://lab.llvm.org:8011/buildslaves). Is it possible to start running builders on them? If so, what are the procedures to do that? Note that clang still does not work when it is build as a 32-bit binary, mainly due to the alignment issues in Clang. Also, Clang does not work out of box on Solaris/Sparc yet, due to the lack of support for its toolchain. Thanks, Venkatraman
That's really cool! Should we add note to Release Notes? On Sun, Feb 2, 2014 at 8:05 PM, Venkatraman Govindaraju <venkatra at cs.wisc.edu> wrote:> Thanks to Jakob's work on Sparcv9 ABI in Clang and recent changes to > Sparc code generator, I am happy to announce that Clang can self host > itself on Linux/Sparc64 and on FreeBSD/Sparc64. > > However, it still fails on a few unit tests and nightly tests, > primarily due to misaligned memory accesses in the code (See bugs > 18482, 18500, 18502, 18536, 18693). Unlike other architectures, > misaligned loads/stores cause bus errors in Sparc. > > To catch bugs specific to Sparc such as the misalignment bugs, it > would be great to get some buildbots running on Sparc machines. I see > that there are buildbot slaves already running on Sparc machines in > GCC compile farm (for example, gcc63, gcc64, listed at > http://lab.llvm.org:8011/buildslaves). Is it possible to start running > builders on them? If so, what are the procedures to do that? > > Note that clang still does not work when it is build as a 32-bit > binary, mainly due to the alignment issues in Clang. Also, Clang does > not work out of box on Solaris/Sparc yet, due to the lack of support > for its toolchain. > > Thanks, > Venkatraman > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
On Sun, Feb 2, 2014 at 11:50 AM, Anton Korobeynikov <anton at korobeynikov.info> wrote:> That's really cool! Should we add note to Release Notes?Definitely. I will add a note mentioning about this in ReleaseNotes.rst.> > On Sun, Feb 2, 2014 at 8:05 PM, Venkatraman Govindaraju > <venkatra at cs.wisc.edu> wrote: >> Thanks to Jakob's work on Sparcv9 ABI in Clang and recent changes to >> Sparc code generator, I am happy to announce that Clang can self host >> itself on Linux/Sparc64 and on FreeBSD/Sparc64. >> >> However, it still fails on a few unit tests and nightly tests, >> primarily due to misaligned memory accesses in the code (See bugs >> 18482, 18500, 18502, 18536, 18693). Unlike other architectures, >> misaligned loads/stores cause bus errors in Sparc. >> >> To catch bugs specific to Sparc such as the misalignment bugs, it >> would be great to get some buildbots running on Sparc machines. I see >> that there are buildbot slaves already running on Sparc machines in >> GCC compile farm (for example, gcc63, gcc64, listed at >> http://lab.llvm.org:8011/buildslaves). Is it possible to start running >> builders on them? If so, what are the procedures to do that? >> >> Note that clang still does not work when it is build as a 32-bit >> binary, mainly due to the alignment issues in Clang. Also, Clang does >> not work out of box on Solaris/Sparc yet, due to the lack of support >> for its toolchain. >> >> Thanks, >> Venkatraman >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > -- > With best regards, Anton Korobeynikov > Faculty of Mathematics and Mechanics, Saint Petersburg State University
On Sun, Feb 2, 2014 at 8:05 AM, Venkatraman Govindaraju < venkatra at cs.wisc.edu> wrote:> Thanks to Jakob's work on Sparcv9 ABI in Clang and recent changes to > Sparc code generator, I am happy to announce that Clang can self host > itself on Linux/Sparc64 and on FreeBSD/Sparc64. > > However, it still fails on a few unit tests and nightly tests, > primarily due to misaligned memory accesses in the code (See bugs > 18482, 18500, 18502, 18536, 18693). Unlike other architectures, > misaligned loads/stores cause bus errors in Sparc. > > To catch bugs specific to Sparc such as the misalignment bugs, it > would be great to get some buildbots running on Sparc machines. I see > that there are buildbot slaves already running on Sparc machines in > GCC compile farm (for example, gcc63, gcc64, listed at > http://lab.llvm.org:8011/buildslaves). Is it possible to start running > builders on them? If so, what are the procedures to do that? >You'll probably want to ask the owners and submit a patch (perhaps you can ask the owners by way of a code review of the patch) for the zorg repository where the buildbot configurations are kept. Once submitted, email Galina to have the buildmaster updated.> > Note that clang still does not work when it is build as a 32-bit > binary, mainly due to the alignment issues in Clang. Also, Clang does > not work out of box on Solaris/Sparc yet, due to the lack of support > for its toolchain. > > Thanks, > Venkatraman > _______________________________________________ > 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/20140203/ecac6e62/attachment.html>