search for: vit9696

I’ll fix the bogus `std::move`. That being said, how up to date is your checkout of clang-tools-extra? > On Mar 29, 2018, at 00:31, vit9696 <vit9696 at avp.su> wrote: > > Hi, > > Thanks for a quick reply. I included the compilation log in the attachment for clarity. Just in case the compiler is the latest clang from Xcode 9.2. > > $ clang --version > Apple LLVM version 9.0.0 (clang-900.0.39.2) > Target:...

Hello, May I ask anyone responsible to either fix or revert r326109 and r326110, which effectively broke LLVM compilation with clang? Str is const now (https://reviews.llvm.org/D43436#C985082NL45 <https://reviews.llvm.org/D43436#C985082NL45>), and later on a move constructor on const is performed (https://reviews.llvm.org/D43436#C985082NL64

...t or not. > > 3. No, not really. If you manage to allocate shadow and origin, which > must be the same size as the application-accessible region each, and > define a mapping function between them, it should be possible to make > MSan work. > > On Thu, Feb 22, 2018 at 6:38 AM, vit9696 via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Hello, >> >> I am currently porting memory sanitizer to a custom platform, and discovered >> some strange things in the existing implementation. >> >> 1. clang/llvm currently hardcode the list of su...

...nder the impression that ppc support in lld is anywhere near ready for use. I had it linking hello world on ppc64 some time ago, and it's not clear that ppc is even that far. I'd not adjust anything in LLVM based on ppc support in lld right now. > > -Hal > On 10/04/2017 11:03 AM, vit9696 via llvm-dev wrote: >> Hello, >> >> I am currently facing an issue at linking stage when compiling basic C code for an embedded PPC32 platform and linking with LLD. For external symbol linkage LLVM appears to use PLT which results in generating a R_PPC_PLTREL24 relocation, that i...

Can you be more specific? What version of clang are you using to build LLVM? And what exactly is the error that you’re seeing? > On Mar 28, 2018, at 23:38, vit9696 via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello, > > May I ask anyone responsible to either fix or revert r326109 and r326110, which effectively broke LLVM compilation with clang? > > Str is const now (https://reviews.llvm.org/D43436#C985082NL45 <https://rev...

Hello, I am currently switching to ldd from ld.bfd on a cross-platform embedded project and am facing a behaviour difference when using the same linker scripts with ld.bfd and ldd. Could anybody please give me a more reliable direction I should go with to get the same behaviour from both of the linkers? Target binary format is a 32-bit ELF executable, which is expected to consist of a single RWX

...MSan is not going to work, blacklist or not. 3. No, not really. If you manage to allocate shadow and origin, which must be the same size as the application-accessible region each, and define a mapping function between them, it should be possible to make MSan work. On Thu, Feb 22, 2018 at 6:38 AM, vit9696 via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hello, > > I am currently porting memory sanitizer to a custom platform, and discovered > some strange things in the existing implementation. > > 1. clang/llvm currently hardcode the list of supported platforms and > disa...

Hello, I am currently facing an issue at linking stage when compiling basic C code for an embedded PPC32 platform and linking with LLD. For external symbol linkage LLVM appears to use PLT which results in generating a R_PPC_PLTREL24 relocation, that is not support by LDD. Therefore even such a basic example cannot be built: /* s.c */ int f() { return 0; } /* t.c */ int f(); int _start() {

Hello, I am currently porting memory sanitizer to a custom platform, and discovered some strange things in the existing implementation. 1. clang/llvm currently hardcode the list of supported platforms and disallow the use of a standalone msan implementation. I suppose the solution here is to submit a patch similar to https://reviews.llvm.org/D18865 <https://reviews.llvm.org/D18865>, which

Hello, Recently I have stumbled across an almost double performance decrease in one of my codebases when compiling with clang instead of gcc. I was testing with the currently latest 3.9.1 as well as 4.0.0 rc2 targeting x86-64 darwin with -Ofast, and after some investigation was able to narrow down the code to the following snippet: __attribute__ ((noinline)) bool calculate(double c) { uint32_t