similar to: Compilation issues

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

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

Hi, 1. No, there is no custom triple for the platform. It currently uses Linux triple, and I do not think there is a possibility of upstreaming not so many changes in such a way. On the other side Apple uses the mllvm asan option to implement KASAN in XNU, so I think it will be fine to upstream a similar option, which I guess, could also be used for debugging, and may be helpful to other people

Hal, I very well understand that LDD may not be in a good state for PPC32, and it would definitely need some improvements sooner or later. In fact I even submitted a patch adding a relocation to ldd just a few hours ago. However, this particular case is not related to LDD, it is a design issue and furthermore a regression in LLVM itself. I checked gcc, and neither does it try to use PLT and

Hi Chandler, I feel like this conversation has come full circle. So to ask again: how does one force CMOV to be emitted? You suggested “__builtin_unpredictable()” but that gets lost in various optimization passes. Given other architectures have CMOV like instructions, and given the usefulness of the instruction for performance tuning, it seems like a direct intrinsic would be best. What am I

Hello, #define likely(x) __builtin_expect((x),1) // switch like char * b(int e) { if (likely(e == 0)) return "0"; else if (e == 1) return "1"; else return "f"; } GCC correctly prefers the first case: b(int): mov eax, OFFSET FLAT:.LC0 test edi, edi jne .L7 ret But Clang seems to ignore _builtin_expect hints in this case.

Hi Dávid, Looks like you can defeat the switch conversion by adding a dummy asm(“”): #define likely(x) __builtin_expect((x),1) // switch like char * b(int e) { if (likely(e == 0)) return "0"; asm(""); if (e == 1) return "1"; else return "f"; } Dave > On May 9, 2018, at 2:33 PM, Dávid Bolvanský via llvm-dev

I did https://bugs.llvm.org/show_bug.cgi?id=37368 2018-05-09 20:33 GMT+02:00 Dávid Bolvanský <david.bolvansky at gmail.com>: > I did > > https://bugs.llvm.org/show_bug.cgi?id=37368 > > 2018-05-09 20:29 GMT+02:00 David Zarzycki <dave at znu.io>: > >> I’d wager that the if-else chain is being converted to a "switch >> statement” during an optimization

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

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

I’m struggling to find cases where __builtin_unpredictable() works at all. Even if we ignore cmp/br into switch conversion, it still doesn’t work: int test_cmov(int left, int right, int *alt) { return __builtin_unpredictable(left < right) ? *alt : 999; } Should generate: test_cmov: movl $999, %eax cmpl %esi, %edi cmovll (%rdx), %eax retq But currently generates: test_cmov: movl $999,

Hi, 1. This patch adds an internal (-mllvm) option, which is basically meant for debugging. If your custom platform has a target triple, you could submit changes to llvm, clang and compiler-rt to specify any platform-specific offsets and other details. 2. Blacklist is meant to disable checking for bugs in certain functions, not to remove all instrumentation. With ASan, these are the same. With

Hi James, Non-Apple people can’t “see radar”. Do you work at Apple? In either case, the clang development email list would be the right start for this. Also, if you work at Apple, please consider reaching out to the DevTools department directly. Dave > On Mar 19, 2018, at 12:21, James Gregurich via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > hi. > > Is there interest

hi. Is there interest in enhancing the objc++ compiler to make objc mechanisms friendly to the newer features of c++? For instance... 1) making blocks movable so that they can capture things like unique_ptr<> and still be moved off the stack 2) making @property declarations work with move-only types like unique_ptr<> 3) enabling std::weak_ptr<> to weakly store an objc pointer

The title says it all. I get this every time I try to clone the repo. I don't know how to get past it...I'm not even sure what it's complaining about... $ git clone https://github.com/llvm/llvm-project.git Cloning into 'llvm-project'... remote: Enumerating objects: 2558, done. remote: Counting objects: 100% (2558/2558), done. remote: Compressing objects: 100% (90/90),

How is -mmacosx-version-min=10.9 being set? LLVM_COMPILE_FLAGS? Or CMAKE_CXX_COMPILE? > On May 2, 2018, at 19:22, Vedant Kumar via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I described this off-list to Zac, but for anyone else who is following, simply specifying the target triple is not enough to have the build system set an older macOS deployment target. I.e the 6.0.0-rc1

As first discussed in the giant "New LLVM git repository conversion prototype" thread, I've pushed a git tag that allows git-describe to be used for generating human readable commit names on master. The tag is "llvmorg-10-init", to be interpreted as "the initial commit with major version number 10". The idea is to add similar tags along with future version bumps.

I do agree that sign-extension is the right thing to do. Unlike bit-fields, llvm::PointerIntPair has asserts checking that the int value is within range. So if you assign an out of range value, it should fail with an assertion: llvm::PointerIntPair<SomeType*, 3, int> pip; pip.setInt(7); // can be made to fail as the valid range // of signed 3-bit values is [-4:3] The above