similar to: unable to compile llvm with gcc 4.7.4

+pcc who added the NativeObjectStream class Looks like a known gcc bug, fixed in 4.8: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53613 Not sure what we do in cases like this, if it is a gcc bug. On Mon, Oct 10, 2016 at 2:50 AM, via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Sat, Oct 08, 2016 at 11:02:37AM +0000, sylvain.bertrand at gmail.com > wrote: > > Hi, >

Hello, http://llvm.org/docs/GettingStarted.html#software lists "GCC >=4.7.0" among requirements for building LLVM. However, my attempt of building LLVM+Clang with gcc 4.7.3 has failed with a multitude of errors, such as: lib/LTO/Caching.cpp:74:7: error: looser throw specifier for 'virtual llvm::lto::localCache(std::string, llvm::lto::AddFileFn)::<lambda(unsigned int,

Thank you very much for the references, we've missed this discussion from last week. Seeing that the RFC hasn’t got any new responses since Wed 12th, is now the time to declare that the community has accepted the proposal, and to update the docs? Or is there any formal deadline for objections to be raised? -----Original Message----- From: meinersbur at googlemail.com [mailto:meinersbur at

On Thu, Mar 17, 2016 at 11:45 AM, Sedat Dilek <sedat.dilek at gmail.com> wrote: > On Thu, Mar 17, 2016 at 10:05 AM, Sedat Dilek <sedat.dilek at gmail.com> wrote: >> On Mon, Mar 14, 2016 at 5:30 PM, Chris Bieneman <cbieneman at apple.com> wrote: >> [ brutal-snip ] >> ... >>> [ TODO#S: Before doing a 2nd build (and in a 3rd run using more >>>

Op 20-3-2018 om 12:40 schreef Evgeny Leviant: > This one triggers an assertion in calculateSEHStateNumbers due to weird catchpad instruction > in @_island_debug_invoke and many other functions. The code expects either pointer to a filter > function or null in first operand, while you're passing pointer to structure: > > catchpad within %80 [{i8*, i8*}* anon..., ...] > >

hello, I am trying to build LLVM with default options. I am getting the following error message after make. [100%] Building C object tools/llvm-c-test/CMakeFiles/llvm-c-test.dir/metadata.c.o [100%] Building C object tools/llvm-c-test/CMakeFiles/llvm-c-test.dir/module.c.o [100%] Building C object tools/llvm-c-test/CMakeFiles/llvm-c-test.dir/object.c.o [100%] Building C object

At a guess that looks like your llvm and lld checkouts are not quite in synch. It will be worth updating llvm and lld to top of trunk. I've rebased the consolidated patch https://reviews.llvm.org/D34634 this morning, it might be worth trying that if you are seeing problems. Peter On 29 June 2017 at 22:09, Alessandro Pistocchi <apukfreelance at gmail.com> wrote: > Hi, I tried

Various options for reducing memory usage when building LLVM: * Don't use bfd-ld, at least use gold, probably use lld if you have it available * With Ninja and/or CMake there's some way to specify the maximum number of concurrent linkactions - lower this to fit in your available memory * If you're building with debug info: Use Split DWARF On Thu, Jan 2, 2020 at 5:21 AM Kókai Péter

The bottom of the bug has the revision numbers (e.g. D34035). That one corresponds to e.g. https://reviews.llvm.org/D34035 There's also https://reviews.llvm.org/D34634 which contains all of Peter's patches, but it's not going to rebase cleanly once the individual patches start going in. On 6/28/17, 10:56 AM, "Alessandro Pistocchi" <apukfreelance at gmail.com> wrote:

The last time this came up, we agreed something should be done to fix the defaults, but nobody picked it up and ran with it. I think there was consensus, it just needs legwork now. On Thu, Jan 2, 2020 at 11:58 AM Aaron Smith via llvm-dev < llvm-dev at lists.llvm.org> wrote: > There was a recent thread on reducing memory: >

Tobias, The most recent commits at svn revision 240868 have broken the Polly build on x86_64 on darwin... [ 57%] Building C object tools/polly/lib/CMakeFiles/Polly.dir/External/isl/isl_int_sioimath.c.o /sw/src/fink.build/llvm37-3.7.0-100/llvm-3.7.0.src/tools/polly/lib/External/isl/isl_int_sioimath.c:1:10: fatal error: 'malloc.h' file not found #include <malloc.h> ^ 1

> On 27 Jun 2017, at 13:25, Peter Smith <peter.smith at linaro.org> wrote: > > Hello Alessandro, > > Despite the statement in the HowToCrossCompileLLVM guide "If you’re > using Clang as the cross-compiler, there is a problem in the LLVM ARM > back-end that is producing absolute relocations on > position-independent code (R_ARM_THM_MOVW_ABS_NC), so for now, you

Hi, I've just tagged the 4.0.1 -rc1 release. Testers can start testing and uploading the binaries. If you still have bug fixes you want to get into the 4.0.1 release, you have until May 22 to submit merge requests. -Tom

Oh, so it looks like I hit a bit of a wall there :-) I’ll take a look thanks. That bug talks about R_ARM_THM_CALL which I assume are thumb related. Will your implementation fix also R_ARM_CALL errors? > On 28 Jun 2017, at 17:15, Peter Smith <peter.smith at linaro.org> wrote: > > Hello Alessandro, > > The LLD ARM port doesn't currently support range extension thunks,

This one triggers an assertion in calculateSEHStateNumbers due to weird catchpad instruction in @_island_debug_invoke and many other functions. The code expects either pointer to a filter function or null in first operand, while you're passing pointer to structure: catchpad within %80 [{i8*, i8*}* anon..., ...] ________________________________________ От: Carlo Kok <ck at

Op 16-3-2018 om 20:16 schreef Evgeny Leviant: > Hello Carlo, > > I tried your reproducer and faced different problem from one you described > (I'm using MacOS Sierra and lld built from trunk on Mar, 15). The crash happens > when SelectionDAGBuilder::lowerInvokable tries to access EH info of this function: > >

It looks the problem lies in how your compiler generates debug info. LLVM doesn't expect DIDerivedType scope to be an instance of DICompileUnit. Here is a quick fix: DIE *DwarfUnit::getOrCreateContextDIE(const DIScope *Context) { - if (!Context || isa<DIFile>(Context)) + if (!Context || isa<DIFile>(Context) || isa<DICompileUnit>(Context)) However, I suggest talking to

Hello, Maybe this is not a bugs. But i fail to install llvm many times and different machine(debian os). First, i follow the instruction: http://cilium.readthedocs.io/en/latest/bpf/#llvm But during in compiling, i alway get: ... /home/yubo/git/llvm/tools/clang/lib/Basic/VirtualFileSystem.cpp: In member function ‘virtual llvm::ErrorOr<std::unique_ptr<clang::vfs::File> >

> On Oct 10, 2016, at 8:01 AM, via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Mon, Oct 10, 2016 at 06:58:36AM -0700, Teresa Johnson wrote: >> +pcc who added the NativeObjectStream class >> >> Looks like a known gcc bug, fixed in 4.8: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53613 >> >> Not sure what we do in cases like this, if

Hi, I tried to build LLVM 4.0.1 on a Slackware Linux box with 3 GB of RAM using gcc-7.1.0. Near the end of the build process, I hit the following error: [ 89%] Linking CXX shared library ../../lib/libLTO.so collect2: fatal error: ld terminated with signal 9 [Killed] compilation terminated. tools/lto/CMakeFiles/LTO.dir/build.make:269: recipe for target 'lib/libLTO.so.4.0.1' failed