similar to: examples / ParallelJIT

2017-05-02 0:50 GMT+02:00 Eugene Zelenko via llvm-dev <llvm-dev at lists.llvm.org>: > On Mon, May 1, 2017 at 3:27 PM, Michael Kruse <llvmdev at meinersbur.de> wrote: >> 2017-05-01 20:16 GMT+02:00 Eugene Zelenko via llvm-dev >> <llvm-dev at lists.llvm.org>: >>> Hi, Hongbin! >>> >>> On Mon, May 1, 2017 at 11:06 AM, Hongbin Zheng

2017-05-01 20:16 GMT+02:00 Eugene Zelenko via llvm-dev <llvm-dev at lists.llvm.org>: > Hi, Hongbin! > > On Mon, May 1, 2017 at 11:06 AM, Hongbin Zheng <etherzhhb at gmail.com> wrote: >> Hi Eugene, >> >> It is strange, I also do a clean build with CMake+make with r301734 and it >> is ok. Could you provide more details? >> >> Thanks >>

2017-04-29 0:49 GMT+02:00 Eugene Zelenko via llvm-dev <llvm-dev at lists.llvm.org>: > Hi! > > I encounter problem with Polly build (in-tree, libraries are linked > statically). It appeared ~ 2 days agor for first time. > > include/llvm/IR/Attributes.h:73:14: fatal error: > 'llvm/IR/Attributes.gen' file not found > #include

Hi! If I'm not mistaken old makefiles are not supported in 3.8. If this is a case, i think till be good idea to remove them before 3.8 branching. Eugene.

Hi! I encounter problem with Polly build (in-tree, libraries are linked statically). It appeared ~ 2 days agor for first time. include/llvm/IR/Attributes.h:73:14: fatal error: 'llvm/IR/Attributes.gen' file not found #include "llvm/IR/Attributes.gen" It seems that dependencies on IR are not set properly. Eugene.

> On Sep 7, 2016, at 4:50 PM, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Wed, Sep 07, 2016 at 04:30:01PM -0700, Eugene Zelenko via llvm-dev wrote: >> What should be used for type declarations: typedef or using? typedef >> is there because of historical reasons, but LLVM code based is C++11 >> now. >> >> LLVM Coding

Hi Eugene, It is strange, I also do a clean build with CMake+make with r301734 and it is ok. Could you provide more details? Thanks Hongbin On Mon, May 1, 2017 at 10:58 AM, Eugene Zelenko via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, Michael! > > On Sun, Apr 30, 2017 at 2:06 PM, Michael Kruse <llvmdev at meinersbur.de> > wrote: > > 2017-04-29 0:49

Hi! What should be used for type declarations: typedef or using? typedef is there because of historical reasons, but LLVM code based is C++11 now. LLVM Coding Standards are not clear on this matter. Eugene. Clang-tidy has modernize-use-using, but fix-it functionality is not perfect (https://llvm.org/bugs/show_bug.cgi?id=28334).

Hi! compiler-rt's CMakeLists.txt still contains tweaks for CMake version 2.8. Pre-2.8.12 are definitely irrelevant for CMake 3.4.3, but may be post-2.8.12 tweaks are irrelevant too? Eugene.

Any chance I could beg a couple of week extension on the removal? We're tracking ToT and ran into some minor snags getting switched over to cmake. Having an extra couple of weeks would be really useful. Philip On 01/07/2016 10:54 AM, Eric Christopher via llvm-dev wrote: > They're deprecated in 3.8. Chris and I are making plans for when > (after branch) the removal happens. >

Hi! There is surge of spam bug reports with support phone numbers of various companies. I remember couple of such reports made ~ 2-3 weeks ago. I think will be good idea to block IP-addresses or their range, if Bugzilla support this, since a-mails are different. Eugene.

Hi! There are a lot of accepted but not closed revisions in Differential. Many of them were actually committed, but without Differential revision link or when it was specified in wrong way. I think will be good idea to create script which will match committed revisions with those in Differential: file list should be same and hashes of changed line could be calculated for each file. In case of

Hi! Company behind PVS-Studio analyzed relatively recent version of LLVM and some results are reported in http://www.viva64.com/en/b/0446/. Eugene.

Hi! There were several new spam entries in Bugizlla, created from previously created accounts. I think will be good idea to delete them as well as block spammers accounts : Report IDs: 30192, 30191, 30187, 30186, 30185, 30182, 28766, 28717, 28715, 28714. Eugene.

Hi, I would like to propose, based on a previous discussion on llvm-dev, the following change. https://reviews.llvm.org/D56337 The main motivation for annotating member functions of ADT clases with LLVM_ALWAYS_INLINE was that of speeding up `check-llvm` at `-O0`. Turns out this significantly degrades the debuggability of fundamental classes in llvm itself, e.g. StringRef or SmallVector. After

On Mon, Mar 16, 2015 at 1:54 AM, Davide Italiano <davide at freebsd.org> wrote: > > Shankar's parallel for per-se didn't introduce any performance benefit > (or regression). > If the change I propose is safe, I would like to see Shankar's change > in (and this on top of it). > I have other related changes coming next, but I would like to tackle > them one at

With the correct list this time. On Wed, Sep 9, 2015 at 6:59 PM, Davide Italiano <davide at freebsd.org> wrote: > Hi, > in the last month I spent some time implementing the missing MachO > specific features in llvm-readobj, and converting all the remaining > tests that used macho-dump to the new format. > llvm-readobj should have all the functionality that macho-dump had. If

While playing with sanitizer in a downstream project, I found out this. /Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/tools/llvm-mc-assemble-fuzzer/llvm-mc-assemble-fuzzer.cpp:207:32: error: reference to type 'std::unique_ptr<MCCodeEmitter>' could not bind to an lvalue of type 'llvm::MCCodeEmitter *' UseDwarfDirectory, IP, CE, MAB, ShowInst));

I'm not entirely sure whether this is worth an RFC, but, just in case. On bugzilla Eli pointed out we currently match a specific sequence of instructions to cls ( https://reviews.llvm.org/rL206079), and given how fragile this is, it could be better to just introduce an intrinsic for it (and presumably, teach peephole optimizations to lower a sequence to that intrinsic). I wonder what folks are

Reid Spencer-2 wrote: > > > Looks to me like you're not configured correctly. Either that or > llvm-config doesn't know how to construct the objdir directory properly. > That error message should have a path > like: /.../Release/lib/libLLVMTransforms.a > > To verify, try this command: > > llvm-config --obj-root > llvm-config --libfiles > > These