similar to: [LLVMdev] Guidance on using pointers vs. references for function arguments

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 discussed before but I can’t find a reference to it. I could have sworn this was in the coding convention at some point. Here’s what I remember: during early LLVM development there was an effort to

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

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

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

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

On May 26, 2014, at 9:15 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Mon, May 26, 2014 at 8:45 PM, Chris Lattner <clattner at apple.com> wrote: > Chandler, Andy's recollection is correct. > > I was personally infatuated by this idea and pushed it through a ton of the LLVM IR APIs (this was many years ago, (in the pre-1.0 days, and then again early

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 >

Please include the mailing list on replies. It looks like you're running configure directly in the LLVM source directory(?) I'm not sure if that works for cross builds like this. Try a separate build directory and see if that helps. -Jim On Oct 19, 2011, at 10:57 AM, Artyom Baloyan wrote: > hi > thank you, but i have this problem > > artyom at splab:~/llvm/llvm-2.7$ sudo

> 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

include/llvm/Support/Casting.h:194: typename cast_retty<Instruction, Value *>::ret_type llvm::cast(llvm::Value *const &): Assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible type!"' failed. 0 clang 0x00000000019867cf 1 clang 0x0000000001986ce9 2 libpthread.so.0 0x00007f6921e2f060 3 libc.so.6 0x00007f69211113a5 gsignal + 53 4 libc.so.6

thanks for these info. 2009/3/19 Artyom Mikhailov <artyom.mikhailov at gmail.com> > Hi there, > > Great project you have - NUT, thx for the development! > I just thought it might be usefull to let you know that APC SC1500I ups can > be found supported by NUT. > I used the following settings: > [sc1500i] > driver = apcsmart > port = /dev/ttyUSB0

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,

Hi, I'm trying to call the function main passing arbitrary parameters. My code is something like: Please note that MyInterpreter extends Interpreter StringRef filename = argv[1]; std::unique_ptr<Module> m(parseIRFile(filename, error, context)); MyInterpreter * v = new MyInterpreter(std::move(m)); v->finalizeObject(); errs() << "Done\n";

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

Hi Anton, Thanks for the tip. I’ve moved some common code from the patch: https://reviews.llvm.org/D50784 <https://reviews.llvm.org/D50784> https://reviews.llvm.org/D50856 <https://reviews.llvm.org/D50856> https://reviews.llvm.org/D50858 <https://reviews.llvm.org/D50858> but the backend itself is still quite large. Anything more I can do to simplify reviewing? > On 15 Aug

Hi! Recently I have installed Samba 2.0.5a on SCO OpenServer 5.0.2c with numerous patches. And now have upgraded to 2.0.6. But problem remains. I have OS/2 Warp Servers and several subnetworks with routers and I try to use samba for access UNIX files and name resolution ( w/WINS) . It works. But domain names registers in wins.dat with ip-address 255.255.255.255 instead of domain controller