search for: cgblock

Hi list, Does LLVM provide support for Apple-style blocks? Or is that all implemented in clang using LLVM primitives? I'm looking at the IR that clang generates, and it sure seems confusing to me. I'm hoping there's a builder that can help me implement them. Thanks! -- Rick

You'll want to look at clang/lib/CodeGen/CGBlocks.[cpp, h]. -eric On Thu, Jan 17, 2013 at 7:26 PM, Rick Mann <rmann at latencyzero.com> wrote: > Hi list, > > Does LLVM provide support for Apple-style blocks? Or is that all > implemented in clang using LLVM primitives? I'm looking at the IR that > clang generates, and...

On Jan 17, 2013, at 19:33 , Eric Christopher <echristo at gmail.com> wrote: > You'll want to look at clang/lib/CodeGen/CGBlocks.[cpp, h]. Thanks. I think proper blocks are way over my head for my little project. I'll try to implement something "block-like" using function pointers. -- Rick

...y the code in MCModule.cpp to cope with the implementation of "lower_bound" in VS 2008. Personally I just went for (1), i.e. switching to Visual Studio 2010, as it was the most straightforward. Doing so, I also had to add "#include <string>" to the file "lib/CodeGen/CGBlocks.cpp" so that llvm/clang can compile with said compiler, because of some obscure external template usage. Regards, -- Benoit PERROT -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130704/b6e3eae5/attac...

...Visual Studio 2010, as > it was the most straightforward. > (3) Fixed in r185676. Requiring VS 2010 for a minor problem like this (even though there are more like it) isn’t warranted I think. Doing so, I also had to add "#include <string>" to the file > "lib/CodeGen/CGBlocks.cpp" so that llvm/clang can compile with said > compiler, because of some obscure external template usage. > <string> is already included, at least by StringRef.h, so I’m curious: what is this obscure thing that needs including it again? Thanks, -- Ahmed Bougacha > Regards...

...e parts, but I haven't had time to investigate. * OpenMP does not support i386-freebsd, so I have to disable it there * Last but not least: the host compiler on FreeBSD 10.x is clang 3.4.1 (the last version that can build without C++11 support), and it crashes with a segfault during building of CGBlocks.cpp. I'll need to find some way to work around this failure, since we cannot upgrade the compiler easily on FreeBSD 10.x. I also had to hack the test-release.sh script to fix a number of problems that I encountered during the 3.7.1 release, but haven't gotten to upstreaming them. E.g. t...

...me twiddling, I remember that (most of) the tests ran correctly. I will at least try to do builds for x86_64. >> * Last but not least: the host compiler on FreeBSD 10.x is clang 3.4.1 (the last version that can build without C++11 support), and it crashes with a segfault during building of CGBlocks.cpp. I'll need to find some way to work around this failure, since we cannot upgrade the compiler easily on FreeBSD 10.x. > > This sounds like the biggest problem. Is there a PR for the crash? I > suppose the alternatives are either to try not to tickle the crash in > our source,...

(cc'ing non-legacy llvm-dev this time; apologies if you get this twice. Please don't reply-all to the first one.) On Tue, Jan 19, 2016 at 3:47 PM, Hans Wennborg <hans at chromium.org> wrote: > Dear testers, > > Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at > r258223. (It took a little longer than I'd planned, sorry about that.) > > There

I'm not advocating AAA. However this is a proposal for more modern thinking regarding the permissiveness of auto in LLVM codebases. Currently the rule on the use of auto is here: https://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable It is quite strict. It allows the use of auto for * lambdas * iterators because they are long to type * casts to