similar to: CMake version specific tweaks in compiler-rt

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

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.

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.

> 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! 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).

The trouble is that the sanitizer tests are not really compiler-rt tests. The original compiler-rt tests are, but not the sanitizer tests. The sanitizer tests are "compiler-rt tests via clang". The sanitizer runtime is a C++ library requiring only a C++ compiler to build it (and to *unit* test it). The ASan lit tests, however, require clang, because they are testing those C++

On Thu, Feb 6, 2014 at 7:57 PM, Jean-Daniel Dupas <devlists at shadowlab.org>wrote: > > Le 6 févr. 2014 à 16:20, Brad King <brad.king at kitware.com> a écrit : > > > On 02/06/2014 08:12 AM, Alexey Samsonov wrote: > >> Please note that it makes a lot of sense to built compiler-rt (and > sanitizers) with just-built > >> Clang. In fact, even though we

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.

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

> > Replicating ExternalProject would be a lot of work... > One approach commonly used with CMake modules that change frequently upstream is for the project to keep a local copy and have a check in place to use CMake's version if new enough. For instance, in llvm's source tree: cmake/modules/ExternalProject.cmake: if(CMAKE_VERSION VERSION_LESS "3.5.1")

On 02/06/2014 08:12 AM, Alexey Samsonov wrote: > Please note that it makes a lot of sense to built compiler-rt (and sanitizers) with just-built > Clang. In fact, even though we should support building it with another compilers (gcc, MSVC), > using just-built-Clang should be a default scenario, like it is in configure+make build. This is possible with CMake using the ExternalProject

On 28 May 2014 17:44, Justin Bogner <mail at justinbogner.com> wrote: > In the autoconf system, I'm pretty sure compiler-rt's build is triggered > by a Makefile in clang, tools/clang/runtime/compiler-rt/Makefile. This > Makefile comments "We currently only try to generate runtime libraries > on x86", so I guess that's the place to start if you want to get it

Hi Brad, I have a few questions regarding ExternalProject_Add. For me it doesn't really work as expected. I add the following code to the tools/clang/runtime/CMakeLists.txt to configure compiler-rt as external project: ExternalProject_Add(compiler-rt #DEPENDS clang clang++ llvm-config PREFIX ${CMAKE_BINARY_DIR}/projects/compiler-rt SOURCE_DIR ${COMPILER_RT_SRC_ROOT}

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.

On 20 December 2013 10:43, Alexey Samsonov <samsonov at google.com> wrote: > There are simply no CMake build rules for building compiler-rt > libraries targeting ARM (see compiler-rt/lib/CMakeLists.txt). > Hi Alexey, I've added the ARM files on that CMake file but I got nothing compiled on ARM. Am I missing something? About the sanitizers, is there anyone that is known to