similar to: Is GCC 4.7 still supported?

Hi, Encounter a compilation issue related to c++. Software versions: - gcc 4.7.4 - llvm git commit 98a1ca117e6743dd7f2d505443a96f591d083eab Build log: Scanning dependencies of target LLVMLTO [ 53%] Building CXX object lib/LTO/CMakeFiles/LLVMLTO.dir/Caching.cpp.o /tmp/pkgs/llvm/lib/LTO/Caching.cpp: In lambda function: /tmp/pkgs/llvm/lib/LTO/Caching.cpp:74:7: error: looser throw specifier for

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

+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, >

Oops, I neglected to reply-all…. The current stable branch at github still has it: https://github.com/apple/swift-llvm/blob/stable/include/llvm/Support/ARMTargetParser.def#L106 <https://github.com/apple/swift-llvm/blob/stable/include/llvm/Support/ARMTargetParser.def#L106> Should I get the head of the non-swift repository and generate a new diff? Also, I suspect that it’s not a good idea

Thanks for the clarifications, Bob! I’ve spent some time with the head of the llvm.org repo, and I now understand a lot better what Renato and Tim were talking about re. the architecture aliases. The patch to add v6l, therefore, seems simple enough. I haven’t been able to test it in my usual flow, because that involves the whole swift stack. I’m considering creating a program that links to

> You assume triples make sense. That's the first mistake everyone does > when thinking about triples. :) I know they don't make sense in many corner cases, but I think discarding logic where it *does* exist is a mistake. > AFAIK, "ARMv7B" is only used by HighBank, which is no more. But that, > too, was "ARMv7A big endian". I believe it's what any

Hello, About a month ago, I submitted a set of patches for review on llvm-commit. The most controversial of the patches, http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20150622/d104ea7 1/attachment-0009.obj deals with the fact that before ARMv8, the rGPR RegClass in Thumb encodings didn't include SP; but from ARMv8 onwards, it does include it. RegClass membership is

Taking the suggestions of the group under consideration, I’ve generated a new diff. The thing to note is that armv6l is now treated identically to armv6hl. I’ve also added a unit test. This seems to me to be the least invasive method, and holds to existing conventions as closely as possible. Thoughts? -------------- next part -------------- A non-text attachment was scrubbed... Name:

>> Going back through SVN history, I cannot find any evidence that ARMv6L ever existed. > > Oh, my bad!! I was thinking of ARMv7l... :/ > > Nevertheless, I'll leave you guys to review this one, as I lost touch with the parser a while ago. Ah, I see: ARMv7L is now an alias for ARMv7A. So, if William has to add support for ARMv6L, I'd suggest he adds it as an alias, and

This buildbot seems to have been failing for a while (though it's hard for me to identify the root cause in the logs, as I mentioned in another thread, so it's hard to say if it's the same failure, or if the failure is consistent, etc) - anyone watching it/caring aobut it? ---------- Forwarded message ---------- From: <llvm.buildmaster at lab.llvm.org> Date: Wed, Sep 30, 2015 at

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..., ...] > >

>> However, because the DefaultTargetTriple is armv6l-unknown-linux-gnueabihf, >> and llvm didn’t know about v6l, it would fail to match and canonicalize to armv6. >> I added the notion of v6l to llvm to address this. > > ARMv6l was definitely there once. I'm not sure what happened. > > I'm copying the ARM folks that did most of the recent changes in hope

On May 26, 2014, at 8:21 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Mon, May 26, 2014 at 7:41 PM, Andrew Trick <atrick at apple.com> wrote: > On May 26, 2014, at 5:02 PM, Chandler Carruth <chandlerc at google.com> wrote: > >> >> On Mon, May 26, 2014 at 4:43 PM, Andrew Trick <atrick at apple.com> wrote: >> This has been

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

Hi I want to cross-compile llvm  for  arm board , running llvm on  Ububtu Server 11.04  x86_64  thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111017/178ae8fe/attachment.html>

Hi, <This issue was previously posted in R-help, but advised to post here as a more relevant group> I was trying to install RQuantLib in my Ubuntu machine which failed with below information : *> install.packages('RQuantLib', repos='http://cran.rstudio.com/ <http://cran.rstudio.com/>', INSTALL_opts = c('--no-lock'))* *Installing package into

I'm trying to compile LLVM with musl libc library. The compilation process fails on the following: x86_64-linux-musl-g++ -DGTEST_HAS_RTTI=0 -DLLVM_BUILD_GLOBAL_ISEL -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Support -I../lib/Support -Iinclude -I../include -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -Wall -W -Wno-unused-parameter

Hi, IMO we should support this, even though if given the option I'd have asked the linux guys not to invent a new triple. It's in linux now, and `uname -a` is a very standard way of obtaining the host's triple. James On Tue, 5 Jan 2016 at 08:34 Tim Northover via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 4 January 2016 at 14:42, Artyom Skrobov via llvm-dev >