similar to: [LLVMdev] LLVM compilation problem

I must not be asking clearly. I have a machine on which I have placed the tarballs - but no internet access. How do I use the *src.tar.gz files from the llvm 3.4 downloads page? I understand the layout produced by the svn actions, but if I have just the tarballs, do I simply replace "svn co" with "tar -xvzf" in the sequence? How do the names of the tarballs map to the names

Hi Bryan, On 26 November 2013 20:08, Bryan Ewbank <Bryan.Ewbank at sas.com> wrote: > I am using gcc 3.4.6 to build LLVM, and am encountering overloaded/ambiguous > errors in several files… I can't say anything about your specific errors, but there are definite plans that LLVM 3.4 will require GCC 4.7.x to compile (since it'll use C++11 features). Regardless, 3.4 is ancient.

Hi All, I am trying to compile latest llvm code using xlc 12.1 on AIX and got the following error. I am trying to debug the issue. Has anybody seen the issue on linux/gcc or is it just xlc specific ? [ 0%] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/YAMLTraits.cpp.o "/llvm/version2/llvm/include/llvm/Support/YAMLTraits.h", line 264.20: 1540-0118 (S) A class name is

I'm have a [PATCH] isDereferenceablePointer: look through gc.relocates and I want to know how to test this patch. So far, I've found one candiate: speculative execution in SimplifyCFG (test/Transforms/SimplifyCFG/SpeculativeExec.ll). However, it's somewhat involved to show that SimplifyCFG does kick in for gc.relocate. Is there a better way to directly test it? Signed-off-by:

Philip Reames wrote: > T.M.K., there's no direct way to test it. There is. See the 'unittests/' directory which contains the C++ unit tests. See unittests/IR/UserTest.cpp for an example that builds up IR from a .ll-in-a-C-string then queries C++ API operations on it. Nick You have to construct a > transformation which happens with the information you added and not >

Dear All, How can the height of a leaf be extracted from a dendrogram? Sure, I can print it, but I am not able to, say, store it in an object. I think I understand that the height is a property of the split, not the leaf itself, but the printing functions display a "height" or "h" (which changes with "hang") and that is what I want. Obviously, the info is there

I am using the source distribution, and the first puzzle is that it doesn't seem to match with the installation instructions from svn. E.g., svn talks about llvm, cfe, compiler-rt, etc; however, the source is in many differently named *.tar.gz files: clang-3.4.src.tar.gz libcxx-3.4.src.tar.gz polly-3.4.src.tar.gz clang-tools-extra-3.4.src.tar.gz lld-3.4.src.tar.gz

Hi Folks, I am trying to figure out how to install LLVM as a user on a *NIX machine rather than as root. Is there any reference to doing this successfully? I keep running into problems with locations not writeable or obsolete versions of tools on which LLVM is dependent. Thank you for any pointers or references, --Bryan Ewbank, Software Language Developer. www.sas.com<http://www.sas.com>

I'm trying to parse a simple JSON file, and am having problems with using YAMLIO. FWIW, I see the unit test YAMLIOTest.cpp is disabled with a #if 0. Anyway, the JSON file yaml.json contains: { "bool_test": true, "directory": ".", "suffix": "_test", "int_test": 4 } The test program when run shows: YAML:5:15: error: invalid

Been having a bit of a problem with dyn_cast: Suppose I have a class A that inherits from two base classes, both of which support dyn_cast. In order to use dyn_cast on A, I need to do a bunch of extra work: 1) Since dyn_cast uses reinterpret_cast rather than static_cast, the pointer value won't get adjusted by the cast operation, making the pointer invalid. I end up having to redefine

I am adding -D k=v to yaml2obj, similar to clang -D. This makes it easy to generate {32-bit,64-bit} x {big-endian,little-endian} tests. --- !ELF FileHeader: Class: ELFCLASS[[BITS]] Data: ELFDATA2[[ENCODE]] Type: ET_DYN Machine: EM_X86_64 # RUN: yaml2obj -D BITS=32 -D ENCODE=LSB %s -o %t.32le # RUN: yaml2obj -D BITS=32 -D ENCODE=MSB %s -o %t.32le # RUN: yaml2obj

Hi all, I am a newbie in LLVM and I am trying to replace the function like: old function || new function ======================================= int haha(int a) { int haha(int a, char* ID) { ===> } } Of course in the newly replaced function "int haha(int,

Some doxygen annotations are attached to the wrong entry, which can be misleading. This patch fixes the mistake everywhere I could find it. --- include/llvm/InstrTypes.h | 54 ++++++++++++++++++++-------------------- include/llvm/MC/MCDirectives.h | 42 +++++++++++++++--------------- include/llvm/Pass.h | 10 +++--- 3 files changed, 53 insertions(+), 53 deletions(-) diff

?The idea itself is indeed good. Regarding to escaping: I think we should have it. Imagine the following example (I've took it from D73828). --- !ELF FileHeader: Class: ELFCLASS[[BITS]] Data: ELFDATA2LSB Type: ET_EXEC Machine: EM_386 # RUN: yaml2obj %s --docnum=4 -D BITS=32 -o %t-32bit.o # RUN: yaml2obj %s --docnum=4 -D BITS=64 -o %t-64bit.o Without escaping it would

On Thu, Oct 17, 2019 at 7:44 PM Andrey Konovalov <andreyknvl at google.com> wrote: > > Currently kcov can only collect coverage for syscalls that are issued > from the current process. This patch adds support for KCOV_REMOTE_ENABLE, > that makes it possible to collect coverage for arbitrary parts of the > kernel code, provided that this part is annotated with kcov_remote_start

All, As of today, LLVM will be built with the -Woverloaded-virtual option turned on. This means that warnings will be generated for ambiguous overloads of C++ sub-classes. Typically this means you forgot to override an overloaded virtual in a subclass. Currently, LLVM is "overloaded virtual" clean. We intend to keep it that way. If you are modifying LLVM and start to see warning

Hi GlobalISel interested parties, A recent bug report (https://bugs.llvm.org/show_bug.cgi?id=40968) on AArch64 exposed a problem with our modeling of intrinsic semantics when dealing with type overloaded calls. The crux of the matter is that because GlobalISel’s LowLevelTypes only carry size and vector layout information, and not any information about whether a type is integer or fp, we lose

Hi all, Sorry for the inconvenient about the previous post. The files were not attached. So I put them here again. I am a newbie in LLVM and I am trying to replace the function like: old function || new function ============================== ========= int haha(int a) { int haha(int a, char* ID) { ===> }

The old patch works, it's just that when you pass "0, 0, 0" for size, align and offset the compiler can't decide which method to call since "0" can be either a pointer or an integer. I can produce a new patch if you like, but I'm having trouble thinking of good names for the new methods. Alternatively, I suppose we could re-arrange the order of the parameters

The immediate change I have in mind is in CallGraph; our implementation of LowerCall in AMDGPU currently relies on the the callee arguments being lowered before the call is lowered, and we simply do not support indirect calls. However, we should be able to support these bitcast calls, as they are effectively direct for our purposes, but the CallGraph does not seem to consider them (it uses