similar to: [LLVMdev] function overload in C

Hi, I'm trying to compile the latest clang/llvm SVN versions and I get this error on multiple systems : (Compiling with gcc): llvm[4]: Compiling cc1_main.cpp for Debug+Asserts build llvm[4]: Compiling cc1as_main.cpp for Debug+Asserts build llvm[4]: Compiling driver.cpp for Debug+Asserts build llvm[4]: Linking Debug+Asserts executable clang

Hello, I worked on a code size analysis tool for a 'week of code' project and think that it might be useful enough to upstream. The tool is inspired by bloaty (https://github.com/google/bloaty), but tries to do more to attribute code size in actionable ways. For example, it can calculate how many bytes inlined instances of a function added to a binary. In its diff mode, it can show how

> On Oct 1, 2018, at 3:16 PM, David Blaikie <dblaikie at gmail.com> wrote: > > (my vote, somewhat biased - is that I'd love to see more investment in Bloaty (to keep all these sort of size analysis tools and tricks in one place), but sort of accept folks are probably going to keep building more infrastructure for this sort of thing in LLVM directly) I get where that comes

> On Oct 1, 2018, at 3:25 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Mon, Oct 1, 2018 at 3:24 PM JF Bastien <jfbastien at apple.com <mailto:jfbastien at apple.com>> wrote: >> On Oct 1, 2018, at 3:16 PM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote: >> >> (my vote, somewhat biased - is that

On Oct 25, 2011, at 6:09 AM, Marcello Maggioni wrote: > Hi, I'm trying to compile the latest clang/llvm SVN versions and I get > this error on multiple systems : Linking, not compiling, but still. I am getting a similar error when building this morning. > Undefined symbols for architecture x86_64: > "clang::Sema::checkPseudoObjectRValue(clang::Expr*)", referenced

Hello, I was trying to use __attribute__((overloadable)) for functions accepting enumerated types but hadn't succeeded so far. Clang 3.1 and 3.2 failed to compile the following example. /* clang -x c foo.cpp */ typedef enum __One {DUMMY_1} One; typedef enum {DUMMY_2} Two; enum Three {DUMMY_3}; __attribute__((overloadable)) void foo(One); __attribute__((overloadable)) void foo(Two);

Thanks Amara very much! I will take a look! On Mon, Jan 8, 2018 at 12:01 PM, Amara Emerson via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 8 Jan 2018, at 19:41, Linchuan Chen <chenlinc at cse.ohio-state.edu> > wrote: > > Thanks Amara so much for the info! > > One more question: what do people usually do if they want to generate > vectorized code for some

Thanks Amara so much for the info! One more question: what do people usually do if they want to generate vectorized code for some existing c/c++ code? Do they usually do C/C++ source level transformation, or do at LLVM's IR level? I know clang supports auto vectorizations, such as loop vectorization and SLP, but they are not flexible enough if we want to do more custom vectorizations or

Hi Craig, Thank you very much for your answer. I did not want to discuss exactly the semantic and name of one operation but instead raise the question "would it be beneficial to have more vector builtins?". You wrote that the compiler will recognize a pattern and replace it by __builtin_ia32_haddps when possible, but how can I be sure of that? I would have to disassemble the generated

On 7 November 2011 22:00, Bill Wendling <wendling at apple.com> wrote: > We are starting on our third (and hopefully last) round of testing for LLVM 3.0. Please visit: > >        http://llvm.org/pre-releases/3.0/rc3/ > > for the sources. There are also binaries for Darwin up there, with > more to come during the week. Please build this release candidate, > test it out

Hi LLVM, clang, I'm trying to write a portable version of __builtin_add_overflow() it a way that the compiler would recognize the pattern and use the add_overflow intrinsic / the best possible machine instruction. Here are docs about these builtins: https://clang.llvm.org/docs/LanguageExtensions.html#checked-arithmetic-builtins . With unsigned types this is easy: int uaddo_native(unsigned

> The vast majority of the time people will rely on source level pragmas [1], > LLVM IR is designed to be machine friendly, not something intended for > users to manually edit themselves. You can do it, but it’s tedious and > error prone. If you need more control over the vectorisation than the > pragmas allow, then the C intrinsics are the best choice. >

On 7 November 2011 22:00, Bill Wendling <wendling at apple.com> wrote: > We are starting on our third (and hopefully last) round of testing for LLVM 3.0. Please visit: > >        http://llvm.org/pre-releases/3.0/rc3/ > > for the sources. There are also binaries for Darwin up there, with more to come during the week. Please build this release candidate, test it out on your

How can I tell at compile time through predefined macros whether libc++ includes/supports the C++14 header file shared_mutex ? Given that I have identified that libc++ is being used, will this work ? : #if __cplusplus >= 201402 // Header file shared_mutex supported #endif or do I need to check something else ?

*Hi, I am considering a language extension to Clang for optimizing GPU programs. This extension will allow the compiler to use different optimization strategies for divergent and non-divergent branches (to be explained below). We have observed significant performance gain by leveraging this proposed extension, so I want to discuss it here to see how the community likes/dislikes the idea. I will

On Fri, Jan 21, 2011 at 4:32 PM, Aaron Myles Landwehr <snaphat at gmail.com> wrote: > Hypothetically, suppose I have a generic system with multiple address spaces > such that each address space is accessed using different instructions. > Now suppose, I wanted to add a new keywords 'foo' and 'bar' to the front of > c variables and function return types such that

Hi all, Hypothetically, suppose I have a generic system with multiple address spaces such that each address space is accessed using different instructions. Now suppose, I wanted to add a new keywords 'foo' and 'bar' to the front of c variables and function return types such that the following would be valid: foo void* a; foo void* somefunc(){...} bar int b; int somefunc2(bar

> On 8 Jan 2018, at 19:41, Linchuan Chen <chenlinc at cse.ohio-state.edu> wrote: > > Thanks Amara so much for the info! > > One more question: what do people usually do if they want to generate vectorized code for some existing c/c++ code? > Do they usually do C/C++ source level transformation, or do at LLVM's IR level? > > I know clang supports auto

Good day, LLVMers! We are starting on our third (and hopefully last) round of testing for LLVM 3.0. Please visit: http://llvm.org/pre-releases/3.0/rc3/ for the sources. There are also binaries for Darwin up there, with more to come during the week. Please build this release candidate, test it out on your projects, and let us know if you find any regressions from the 2.9 release. Please keep

In our experience, as Owen also suggests, a pragma or a language extension can be avoided by a combination of static and dynamic analysis. We prefer this approach in our compiler ;) Regards, Vinod On Sat, Jan 24, 2015 at 12:09 AM, Owen Anderson <resistor at mac.com> wrote: > Hi Jingyue, > > Have you considered using dynamic uniformity checks? In my experience you > can