search for: latom

...Fiselier via llvm-dev <llvm-dev at lists.llvm.org> wrote: > So it seems that libatomic went missing between build #1379 and #1380, so I don't think this is related to the -std=c++11 failure. Instead it seems likely that the compile test for -std=c++11 is failing due to mis-configuring -latomic. > > Can you confirm the bot has libatomic installed? You shouldn't need it on x86-64. The issue there is that cmake is reporting, incorrectly: -- Performing Test LIBCXX_HAVE_CXX_ATOMICS_WITHOUT_LIB -- Performing Test LIBCXX_HAVE_CXX_ATOMICS_WITHOUT_LIB - Failed despite that previous...

So it seems that libatomic went missing between build #1379 and #1380, so I don't think this is related to the -std=c++11 failure. Instead it seems likely that the compile test for -std=c++11 is failing due to mis-configuring -latomic. Can you confirm the bot has libatomic installed? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161211/6eb14df6/attachment-0001.html>

...g/split/notypes/nostandalone/projects/compiler-rt/lib/xray/tests/unit/XRayFDRLoggingTest-x86_64 -Wl,-allow-shlib-undefined -m64 -lstdc++ -lm -lpthread -lpthread -L/usr/local/google/home/blaikie/dev/llvm/build/clang/debug/split/notypes/nostandalone/./lib/clang/5.0.0/lib/linux -lclang_rt.xray-x86_64 -latomic -ldl -lrt /usr/local/google/home/blaikie/install/bin/../lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../include/c++/6.1.0/system_error:197: error: undefined reference to 'std::_V2::generic_category()' /usr/local/google/home/blaikie/install/bin/../lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../....

...kc/llvm-project/build/lib -I /h >>> ome/bryanpkc/llvm-project/openmp/runtime/test/ompt >>> /home/bryanpkc/llvm-project/openmp/runtime/test/api/has_openmp.c -o >>> /home/bryanpkc/llvm-project/build/projects/openmp/runtime/test/api/Output/has_openmp.c.tmp >>> -lm -latomic && >>> /home/bryanpkc/llvm-project/build/projects/openmp/runtime/test/api/Output/has_openmp.c.tmp >>> -- >>> Exit Code: 1 >>> >>> Command Output (stdout): >>> -- >>> $ ":" "RUN: at line 1" >>> $ &q...

...> llvm-dev at lists.llvm.org> wrote: > > So it seems that libatomic went missing between build #1379 and #1380, > so I don't think this is related to the -std=c++11 failure. Instead it > seems likely that the compile test for -std=c++11 is failing due to > mis-configuring -latomic. > > > > Can you confirm the bot has libatomic installed? > > You shouldn't need it on x86-64. The issue there is that cmake is > reporting, incorrectly: > -- Performing Test LIBCXX_HAVE_CXX_ATOMICS_WITHOUT_LIB > -- Performing Test LIBCXX_HAVE_CXX_ATOMICS_WITHOUT_LI...

Hi lists, I am encountering a large number of check-clang failures after building Clang/LLVM with -DLLVM_USE_SANITIZER=Address. I have reported the issue on Bugzilla (https://bugs.llvm.org/show_bug.cgi?id=47678). I cannot even compile helloworld.c with the resulting clang tool without a lot of false positives from ASan. Is it because I am not supposed to use GCC's AddressSanitizer when

started with http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fuzzer/builds/1380 (Fri Dec 9 18:42:04 2016) The previous one (Fri Dec 9 17:41:56 2016) was fine. There was just one revision between these runs (mine), but reverting it does not help. Maybe an update in Ubuntu 14.04 broke this? On Sat, Dec 10, 2016 at 3:35 PM, Eric Fiselier <eric at efcs.ca> wrote: > I can't

Hi, I've tagged 10.0.1-final. Testers, please begin uploading your binaries. Thanks, Tom

Hi, I've tagged the 10.0.1-rc2 release, please test the release and report any issues. Thanks, Tom

...ips-linux-gnu.tar.xz (sha1sum: f286149dbb2ea7e194c5c3719b6cded476f6e65f) All ok (aside from non-regression failures in check-all). There were two kinds of check-all failure: * mips64 sanitizers. Not a regression since mip64 sanitizers didn't ship in 3.7.1 * atomic tests fail due to missing -latomic on link. Not a regression since _no_ libc++ tests ran in 3.7.1 (this was obscured by the -s on llvm-lit). Failing Tests (76): AddressSanitizer-mips64-linux :: TestCases/Posix/coverage-direct-activation.cc AddressSanitizer-mips64-linux :: TestCases/Posix/coverage-direct-large.cc Ad...

...86_64-linux-gnu/4.8/../../.. -L/usr/local/google/home/dberris/xray/llvm-build/bin/../lib -L/lib -L/usr/lib -whole-archive /usr/local/google/home/dberris/xray/llvm-build/bin/../lib/clang/3.9.0/lib/linux/libclang_rt.xray-x86_64.a -no-whole-archive /tmp/test-03d46e.o --no-as-needed -lpthread -lrt -lm -latomic -ldl -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/4.8/crtend.o /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crtn.o --->8 clang invocation 8<--- The test.cc is simply: --->8 test.cc 8<--- #include &...

Dear testers, Release Candidate 3 has just been tagged [1]. Please build, test, and upload to the sftp. If there are no regressions from previous release candidates, this will be the last release candidate before the final release. Release notes can still go into the branch. Thanks again for all your work! Hans [1] http://lists.llvm.org/pipermail/llvm-branch-commits/2016-February/009866.html

.../.. > -L/usr/local/google/home/dberris/xray/llvm-build/bin/../lib -L/lib > -L/usr/lib -whole-archive > /usr/local/google/home/dberris/xray/llvm-build/bin/../lib/clang/3.9.0/lib/linux/libclang_rt.xray-x86_64.a > -no-whole-archive /tmp/test-03d46e.o --no-as-needed -lpthread -lrt -lm > -latomic -ldl -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc > --as-needed -lgcc_s --no-as-needed > /usr/lib/gcc/x86_64-linux-gnu/4.8/crtend.o > /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crtn.o > --->8 clang invocation 8<--- > > The test.cc is simply: > &gt...

...4c5c3719b6cded476f6e65f) > All ok (aside from non-regression failures in check-all). > There were two kinds of check-all failure: > * mips64 sanitizers. Not a regression since mip64 sanitizers didn't ship in 3.7.1 > * atomic tests fail due to missing -latomic on link. Not a regression since _no_ libc++ tests ran in 3.7.1 (this was obscured by the -s on llvm-lit). > Failing Tests (76): > AddressSanitizer-mips64-linux :: TestCases/Posix/coverage-direct-activation.cc > AddressSanitizer-mips64-linux :: TestCases/Po...

Hmm. Odd. I just rebuilt from scratch and it seems to work with the test/CodeGen/X86/xray-attribute-instrumentation.ll test case outputing straight to obj: llc -filetype=obj -o ~/a.o -mtriple=x86_64-apple-macosx < test/CodeGen/X86/xray-attribute-instrumentation.ll What test case are you using? In any case, the issue appears to be that llvm doesn't realize that the target address is

On Wed, Jun 22, 2016 at 6:05 AM Nirav Davé <niravd at google.com> wrote: > This appears to work: > > auto Target = OutContext.createLinkerPrivateTempSymbol(); > > with > > auto Target = OutContext.createTempSymbol(); > > -Nirav > > Thanks Nirav -- I tried this but I'm still getting a "jmpq <address>" with this incantation when I load and