similar to: [LLVMdev] problems building googletest for 2.5

On Feb 4, 2009, at 9:10 PM, Tanya Lattner wrote: > Ideally, configure should detect what version of gcc you have and > either use those CPP FLAGS or not (it will output warnings with > 3.X). Or, we just disable building Google Test by default. > Can anyone help with this? Here is a Makefile fragment that will dynamically test gcc and add flags, if the flag is supported.

On Feb 4, 2009, at 9:26 PM, Mike Stump wrote: > On Feb 4, 2009, at 9:10 PM, Tanya Lattner wrote: >> Ideally, configure should detect what version of gcc you have and >> either use those CPP FLAGS or not (it will output warnings with >> 3.X). Or, we just disable building Google Test by default. > >> Can anyone help with this? > > Here is a Makefile fragment that

What is googletest ? Its aufully messy warnings wise on Cygwin. Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090219/8de0a211/attachment.html>

> What is googletest ? Framework for units tests in llvm. http://code.google.com/p/googletest/ > Its aufully messy warnings wise on Cygwin. If you have gcc 3.X you are going to get a bunch of warnings. What gcc are you using? -Tanya

Chris and Bill, I have tested the proposed patch from... http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-August/016490.html under i686-apple-darwin9 and it solves the problems building gfortran from llvm svn. The resulting compiler works fine so can we get that patch in before 2.4 is release? Jack ps We do have one oddity left in llvm-gfortran from current llvm svn. I find

On Feb 4, 2009, at 9:39 PM, Chris Lattner wrote: > Putting it into the one directory (utils/unittest) that needs it > should be fine. Can you please test and apply a patch to mainline? Sure, but I'm skeptical this will actually help gcc 3.X. I checked in the code, and tested on a gcc 4.2 system. Someone else would have to try 3.X.

> Someone else would have to > try 3.X. It works for me. I can now build LLVM on Cygwin with GCC 3.4.4, where I used to fall over this problem before. Thanks, Jay.

On Oct 30, 2008, at 11:02 PM, Chris Lattner wrote: > On Oct 30, 2008, at 5:23 PM, Jack Howarth wrote: >> ps We do have one oddity left in llvm-gfortran from current llvm >> svn. I find everytime I compile something with llvm-gfortran that >> I get a series of warning messages... >> >> f951: warning: command line option "-Wformat" is valid for C/C++/

On Oct 30, 2008, at 5:23 PM, Jack Howarth wrote: > ps We do have one oddity left in llvm-gfortran from current llvm > svn. I find everytime I compile something with llvm-gfortran that > I get a series of warning messages... > > f951: warning: command line option "-Wformat" is valid for C/C++/ > ObjC/ObjC++ but not for Fortran > f951: warning: command line option

I haven't scheduled time to investigate this yet. My guess is that GoogleTest config is getting confused on Microsoft vs POSIX mkdir when going through autoconf: llvm[3]: Compiling gtest-filepath.cc for Release-Asserts build g:\mingw32\bin\../lib/gcc/mingw32/4.2.1-dw2/../../../../include/io.h: In member function 'bool testing::internal::FilePath::CreateFolder() const':

On 24 July 2011 10:59, Duncan Sands <baldrick at free.fr> wrote: > Hi Edward, > >> Building of llvm with gcc-4.5.2-1 gives these warnings: >> >> 1) Building FileManagerTest >> >> "llvm[4]: Compiling FileManagerTest.cpp for Debug+Asserts build >> C:/Programming/VersionControl/llvm/tools/clang/unittests/Basic/FileManagerTest.cpp: >> In

Hi Jay, >> yes, they are annoying aren't they. They all come from google's unittest >> library. I think it is best to fix them upstream at google. > > We're using googletest 1.5.0. These warnings seem to be fixed in > 1.6.0, so here's a patch to upgrade us. Disclaimer: I've only tested > this by doing "make check-all" on Linux/x86_64. >

Thanks Cole, unfortunately I'm a n00b in this area so your response just raised many more questions for me :/ * what are the config file names for libxl, libvirt and virt-manager * where are they located in the respective source trees * are the build flags defined in those config files? * libxl is part of xen 4.5.0 distro (xen/tools/libxl after untarring). But no config file is in

On 11/15/13 03:52 AM, Chandler Carruth wrote: > > I'm not trying to make LLVM use unittests everywhere, I'm just trying > to get a tool added to the toolbox so that a unittest I'm already > writing can be written more simply and in a more maintainable fashion. You're welcome to ignore me and keep writing eloquent emails, but you still haven't shown an exact use

> I think the cost of carrying it around is essentially zero. I'm happy to do > any of the maintenance. People who don't know how to use it or want to learn > how to use it don't need to use it. If it isn't making their job of writing > tests sufficiently easier to justify, then they don't use it. I see this as > a good pattern. That is not the case. If the test

I downloaded and untarred the deb package and grepped for 'configure', but none of the hits were configure commands. Is there a better way to find it? Wayne On Mon, Mar 2, 2015 at 3:08 PM, Cole Robinson <crobinso@redhat.com> wrote: > On 03/02/2015 01:39 PM, Wayne Mills wrote: > > Thanks Cole, unfortunately I'm a n00b in this area so your response just > >

On Wed, Jul 6, 2016 at 1:21 PM, Mehdi Amini via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On Jun 23, 2016, at 11:15 AM, Cristianno Martins via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Hi Vivek, > > you can also include these lines below to your ~/.bash_profile: > > LLVM_BUILD="/Developer/llvm/build" # Path to your build directory

Hello all, I am writing test cases which are dedicated to be executed by llvm-lit. Most of my test cases have the same logic but different types. For example: // RUN: %clang_cc1 -fsyntax-only func (int a) { a = 3; } // RUN: %clang_cc1 -fsyntax-only func (char a) { a = 3; } // RUN: %clang_cc1 -fsyntax-only func (unsigned a) { a = 3; } Now I put them in three different test cases but it

On Thu, Mar 15, 2018 at 9:09 PM, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > +Chandler who might have some thoughts on this. > > Could you provide an example here of the motivation for the feature you're > missing? Might help motivate the discussion (and/or we'll end up nitpicking > how it could be done differently without that feature... - which

On Nov 14, 2013, at 3:16 AM, Chandler Carruth <chandlerc at google.com> wrote: > Personally, I rather not do this, without very clear and compelling reasons. > > I understand that this could be very useful for your bringup (and so could be very useful locally), but once the passmanager is the default, it will get lost of in-tree testing by just about everything in the compiler.