similar to: asan link failure when configuring with -DBUILD_SHARED_LIBS=ON

+Alexey On Thu, Feb 25, 2016 at 5:30 AM, Diego Novillo <dnovillo at google.com> wrote: > > I'm getting this link failure when running ninja check on Linux. I'm > configuring with shared libraries enabled, so I'm not sure why asan is > looking for .a archives. > > $ cmake -G Ninja -DCMAKE_BUILD_TYPE=Debug -DLLVM_BUILD_TESTS=ON > -DCLANG_INCLUDE_DOCS=ON

Looking On Thu, Feb 25, 2016 at 9:13 PM, Kostya Serebryany <kcc at google.com> wrote: > +Alexey > > On Thu, Feb 25, 2016 at 5:30 AM, Diego Novillo <dnovillo at google.com> > wrote: > >> >> I'm getting this link failure when running ninja check on Linux. I'm >> configuring with shared libraries enabled, so I'm not sure why asan is >>

Fixed by LLVM r262063, thanks for reporting this! On Fri, Feb 26, 2016 at 11:35 AM, Alexey Samsonov <vonosmas at gmail.com> wrote: > Looking > > On Thu, Feb 25, 2016 at 9:13 PM, Kostya Serebryany <kcc at google.com> wrote: > >> +Alexey >> >> On Thu, Feb 25, 2016 at 5:30 AM, Diego Novillo <dnovillo at google.com> >> wrote: >>

Evgeniy, I'm getting this error while building on ARM: clang (LLVM option parsing): Unknown command line argument '-asan-instrument-assembly'. Try: 'clang (LLVM option parsing) -help' clang (LLVM option parsing): Did you mean '-asan-instrument-atomics'? [6/32] Generating ASAN_INST_TEST_OBJECTS.asan_asm_test.cc.arm-inline.o This doesn't happen on x86_64, so

Hi, I'm trying to run the ASAN tests on ARM (to fix the CMake RT bot we have) and I'm hitting a different bug on my Chomebook than I have on the bots: [6/32] Generating ASAN_INST_TEST_OBJECTS.asan_interface_test.cc.arm-inline.o ... clang-3.6: warning: argument unused during compilation: '-march=armv7-a' clang (LLVM option parsing): Unknown command line argument

I've finished my initial set of patches to make 32-byte shadow granularity work on x86. Here is a summary of the changes from last week: - As discussed, I added a full redzone after every stack variable. - We discussed adding a -fsanitize-address-granularity=N flag, but I found the following existing flag has been sufficient for my purposes: -asan-mapping-scale N. If anyone thinks I

[Sorry about the crosspost. Since this is a clang build question but the build is invoked from the top-level LLVM directory I'm not sure where the question should go.] I've got a clang build against libstdc++ on Linux but I would really like one built against libc++/libc++abi. In other words I'd like to rebuild clang/llvm with clang using libc++ and libc++abi on Linux. I looked at

Just to follow-up, I'm now encountering this as well. I'm doing this on Linux. It seems that when linking with the most-recently built clang, the unit tests are taking a while to complete. It's notably not using more than 1 thread, and if using `lld` I would have expected the linker to still be running in parallel. I'm doing this on a debug build, so that might help narrow it

Hello, There is a problem in the compiler-rt project regarding a new change I need to make. The change is that in extended gcc syntax, when the same register is in the input/output list and in the clobber list, there is a conflict and llvm should produce an error. Until now, it didn't produce an error. In compiler-rt's tests, there's a test which shouldn't generate an error but

Following a blend of instructions on 3 web pages, I have succeeded in getting LLVM 3.2 (with clang, extras, and compiler-rt) building - but not testing - on Xcode. I used CMake 2.8.10 GUI to create the Xcode project file. Below are my notes. First, I believe CMake ends up setting things up so that Xcode has 1 warning after scanning the project having to do with hires images or some such… it takes

Those look like the linker is being passed the same .o file built twice, ex: ../Objects-normal/x86_64/asan_globals_test.o ../lib/asan/tests/asan_globals_test.cc.asan.o So, the symbols are colliding. Something is set up wrong in the xcode project. -Nick On Dec 19, 2012, at 9:48 AM, Relph, Richard wrote: > Following a blend of instructions on 3 web pages, I have succeeded in getting LLVM

Hi Richard! On Thu, Dec 20, 2012 at 12:48 AM, Nick Kledzik <kledzik at apple.com> wrote: > Those look like the linker is being passed the same .o file built twice, > ex: > ../Objects-normal/x86_64/asan_globals_test.o > ../lib/asan/tests/asan_globals_test.cc.asan.o > > So, the symbols are colliding. Something is set up wrong in the xcode > project. > > -Nick

Different, but still failing (this time with Xcode 4.4…) /Users/rrelph/llvm/tot/xcode/bin/Debug/clang sanitizer_allocator_test.cc.i386.o sanitizer_common_test.cc.i386.o sanitizer_flags_test.cc.i386.o sanitizer_libc_test.cc.i386.o sanitizer_list_test.cc.i386.o sanitizer_printf_test.cc.i386.o sanitizer_stackdepot_test.cc.i386.o sanitizer_test_main.cc.i386.o gtest-all.cc.i386.o

+ more asan folks, please CC them to the code reviews. Also please make sure llvm-commits is CC-ed (cfe-commits for clang changes) On Tue, Oct 31, 2017 at 2:29 PM, Walter Lee <waltl at google.com> wrote: > I've prepared a preliminary set of patches that makes ASan work with > 32-byte shadow granularity, and I would like to get some feedback on > those patches as well as my

Does this give correct results for special floats (0, infs)? We tried to improve (for single floats) x86 rcp in llvmpipe with newton-raphson, but unfortunately not being able to give correct results for these two cases (without even more additional code) meant it got all disabled in the end (you can still see that code in the driver) since the problems are at least as bad as those due to bad

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Untested beyond compiling a few shaders to see if they look like they might work. nvdisasm agrees with envydis's decoding of these things. Will definitely get ahold of a G200 to run tests on before pushing this. .../drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp | 94 ++++++++++++++++++---

This is parallel to the pre-SM50 change which does this. Adjusts the shuffles / quadops to make the values correct relative to lane 0, and then splat the results to all lanes for the final move into the target register. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Entirely untested beyond compilation. Should check bin/tex-miplevel-selection textureGrad Cube

Unfortuantely we don't know if a particular load is a real 2d image (as would be a cube face or 2d array element), or a layer of a 3d image. Since we pass in the TIC reference, the instruction's type has to match what's in the TIC (experimentally). In order to properly support bindless images, this also can't be done by looking at the current bindings and generating appropriate

Hi, On Wed, Mar 26, 2014 at 6:27 PM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > On 3/26/2014 8:04 AM, İsmail Dönmez wrote: > >> >> Recent trunk has a lot of failures on PPC64/Linux. One seems to be crash >> with a backtrace like: >> > > Is this with "make check"? I can try it on my G5/FreeBSD box when I get > home make

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: "10.2" <mesa-stable at lists.freedesktop.org> --- Not 100% sure of the significance of this code, but this seems like the correct thing to do... will definitely run it through a full piglit run before pushing out. src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 2 ++ 1 file changed, 2 insertions(+) diff --git