similar to: [LLVMdev] GCC/LLVM frame pointer incompatibility on ARM

On 07/16/2014 11:45 AM, Tim Northover wrote: >>> As has been mentioned several times (*), LLVM and GCC setup frame pointer to >> point to different stack slots on ARM. GCC's fp points to stack slot holding >> lr while LLVM's fp points at the next slot. > > This looks flipped from my tests. Both create an { fp, lr } struct; > GCC sets current fp to the address

Hi all, I'm debugging a crash in the guts of libunwind that started occuring when I changed the ASan runtime to use _Unwind_Backtrace() on OSX to report errors. The crash happens for every test case that has an ASan report in it, so I'm suspecting something's wrong with the unwind info generated by the Xcode Clang, which I'm using to build my Clang and the ASan runtime library

On Thu, Dec 18, 2014 at 11:05 PM, Yury Gribov <y.gribov at samsung.com> wrote: > > On 12/19/2014 01:14 AM, Nick Lewycky wrote: > >> On 12/16/2014 02:43 AM, Yury Gribov wrote: >> >>> On 12/15/2014 10:24 PM, Ismail Pazarbasi wrote: >>> >>>> s.d = 42.0; >>>> if (s.l > 100) // fire here >>>> >>>

Inviting Paul to the party (he wrote the libstdc++ sort checker <https://gcc.gnu.org/svn/gcc/branches/google/gcc-4_9/libstdc++-v3/include/bits/stl_algo.h> ). On Tue, Jan 12, 2016 at 11:09 PM, Yury Gribov <y.gribov at samsung.com> wrote: > On 01/13/2016 10:08 AM, Yury Gribov wrote: > >> On 01/13/2016 09:57 AM, Kostya Serebryany wrote: >> >>> On Tue, Jan 12,

On 01/13/2016 09:57 AM, Kostya Serebryany wrote: > On Tue, Jan 12, 2016 at 10:28 PM, Yury Gribov <y.gribov at samsung.com> wrote: > >> On 01/13/2016 03:10 AM, Kostya Serebryany wrote: >> >>> FTR, here is one way to implement this in the library: >>> >>> https://gcc.gnu.org/svn/gcc/branches/google/gcc-4_9/libstdc++-v3/include/bits/stl_algo.h

On 12/16/2014 02:43 AM, Yury Gribov wrote: > On 12/15/2014 10:24 PM, Ismail Pazarbasi wrote: >> s.d = 42.0; >> if (s.l > 100) // fire here > > Note that code like this is frequently used to convert integers to > floats so you'll get tons of false positives. True positives. The fix is to use memcpy instead. Emitting error for > accessing differently

Would they be willing to have a flag? Would we be willing to have a flag? Or should we conditionalize this on OS and say, on Linux, do the gcc thing, and on OS X, do the LLVM thing? On Thu, Jul 17, 2014 at 6:10 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 17 July 2014 12:49, Yury Gribov <y.gribov at samsung.com> wrote: > > Well, their logic is that as long as

> By the way, locally, I now have just over half the ASan test suite > passing ARM-Linux via QEMU. Greg, Do you mean that you've added support for QEMU-based testing to sanitizer CMakeLists? That would be super-cool. -Y

> We considered adding "%run" to all binary invocations, > but dropped this idea. I don't remember the details, but IIRC %run is > just not general enough. IMHO this is where simplicity of lit approach starts to fail - important information (environment variables, dependent shared libs, expected test status, etc.) is buried inside arbitrarily complex runstrings. -Y

Sorry for the slow replies. I'm out on vacation this week. Alexey wrote: > If you want to test the sanitizer runtiume library "during development", > you should verify that it works with the Clang at hand. I want to test an implementation of libraries, not that clang links a library in its install directory. We only need one clang test for the latter (not 100) and that

On 01/13/2016 03:10 AM, Kostya Serebryany wrote: > FTR, here is one way to implement this in the library: > https://gcc.gnu.org/svn/gcc/branches/google/gcc-4_9/libstdc++-v3/include/bits/stl_algo.h > Search for "check sort predicate for strict weak ordering" Nice, although this wouldn't catch violations of transitivity (which is probably the most important type of bug).

On 09/25/2015 11:53 AM, Jakub Jelinek via llvm-dev wrote: > On Fri, Sep 25, 2015 at 01:19:48AM -0700, Renato Golin wrote: >> After long talks with lots of people, I think we have a winning >> strategy to deal with the variable nature of VMA address in AArch64. >> It seems that the best way forward is to try the dynamic calculation >> at runtime, evaluate the performance,

Hi Thierry, Thanks for the patch. I applied on top of linux-next-2017-12-14. Different output this time. [ 11.862495] WARNING: CPU: 1 PID: 254 at drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgf100.c:391 gf100_vmm_new_+0x60/0x128 [nouveau] [ 11.863458] tegra-dpaux 155c0000.dpaux: 155c0000.dpaux supply vdd not found, using dummy regulator [ 11.866197] tegra-sor 15580000.sor: failed to probe

> This is a public interface. But ASan runtime (and test-suite) strongly depends on > the instrumentation pass in Clang. How do you feel about adding a runtime init check of a version number defined by asan_interface.h? -Greg On Tue, Apr 22, 2014 at 11:16 AM, Alexey Samsonov <samsonov at google.com> wrote: > > On Tue, Apr 22, 2014 at 10:43 AM, Greg Fitzgerald <garious at

> Does %run support ssh-based testing? Yes, %run is configured by the user. I configure it to call a shell script that calls qemu-arm. It could just as easily ssh or "adb push && adb shell". -Greg On Wed, Apr 16, 2014 at 11:44 PM, Yury Gribov <y.gribov at samsung.com> wrote: > Greg, > > >> Clever, but I hope we can try to avoid the symlink hackery.

On 24 November 2015 at 13:06, Maxim Ostapenko <m.ostapenko at partner.samsung.com> wrote: > On 23/11/15 16:46, Jay Foad wrote: >> >> In LowerGET_DYNAMIC_AREA_OFFSET() you're calling >> MFI->getMaxCallFrameSize(), but it looks like that doesn't return useful >> information until after the PrologEpilogInserter's >>

Hello, Commit 2541626cfb79 breaks GM20B probe with the following kernel log: [ 2.153892] ------------[ cut here ]------------ [ 2.153897] WARNING: CPU: 1 PID: 36 at drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgf100.c:273 gf100_vmm_valid+0x2c4/0x390 [ 2.153916] Modules linked in: [ 2.153922] CPU: 1 PID: 36 Comm: kworker/u8:1 Not tainted 6.1.0+ #1 [ 2.153929] Hardware name: Google

On 04/20/2016 02:58 PM, Renato Golin via llvm-dev wrote: > Hi Derek, > > I'm not an expert in any of these topics, but I'm excited that you > guys are doing it. It seems like a missing piece that needs to be > filled. > > Some comments inline... > > > On 17 April 2016 at 22:46, Derek Bruening via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >>

On Tue, Jan 12, 2016 at 10:27 PM, Yury Gribov via cfe-dev < cfe-dev at lists.llvm.org> wrote: > > As for C++11, it has for e.g. srtd::sort: > > "Requires: operator< (for the version with no arguments) or comp (for the > version with a comparison argument) defines a strict weak ordering (25.4)." > > which also sounds like UB. Exactly correct. If your

Thanks to Thierry for finding this - applying index e14643615698..00eeaaffeae5 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c +++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c @@ -2369,7 +2369,7 @@ nv13b_chipset = { .imem = gk20a_instmem_new, .ltc = gp100_ltc_new, .mc = gp10b_mc_new, - .mmu = gf100_mmu_new, + .mmu = gp10b_mmu_new,