similar to: [LLVMdev] [PATCH][RFC] upgrade to googletest 1.6.0 (was Re: Build of latest llvm gives warning and error)

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 member function 'virtual void<unnamed>::FileManagerTest_NoVirtualDirectoryExistsBeforeAVirtualFileIsAdded_Test::TestBody()':

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

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 member function 'virtual >

Hi Kees, You added some support for Minix to LLVM's copy of googletest: http://llvm.org/viewvc/llvm-project?view=rev&revision=100895 Is it still being used? If so, would you mind pushing these patches upstream to the googletest project: http://code.google.com/p/googletest/ Otherwise we may drop them, because it makes it harder to import new releases of googletest into the LLVM

Nice! This looks good to me but probably Chris or someone else should sign off on it. There were two minor warnings on Darwin: -- In file included from /Volumes/Data/Users/ddunbar/llvm/lib/Support/regexec.c:81: /Volumes/Data/Users/ddunbar/llvm/lib/Support/regengine.inc: In function 'sbackref': /Volumes/Data/Users/ddunbar/llvm/lib/Support/regengine.inc:665: warning: control reaches end of

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

Thanks. The motivating example can be seen in this review: https://reviews.llvm.org/D44382. In that review, I am unit testing .debug_line parsing, specifically, the behaviour when the parser is fed a malformed section. Most of the code under test goes through some slight variations in the code path, depending on a) the DWARF version (interesting cases are 3, 4 and 5), and b) whether the DWARF is

I'm seeing some test failures for unit tests for msan (check-msan) happening in googletest, which I find weird. I'm on Arch Linux, with r342711. Below is one type of error that I see. The full log is 416MB (!) big. My guess is that those errors are related, but if anyone needs the full log, I'll provide it. Here is a reduced log from the end:

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>

+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 is sort of where I'm going with this. Combinatorial test case expansion does seem a bit suspicious to me - I'd hope we

Hi all, I'm currently writing some unit tests for some debug line error handling code I'm working on (see e.g. https://reviews.llvm.org/D44382), and I just ran into an annoying disabled feature in gtest, specifically the "Combine" feature for use in combinatorially generating parameterised tests. A FIXME comment in ProfileData\CoverageMappingTest.cpp suggests that I'm not

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.

Hello Jay, At the time I submitted those patches I also submitted them to googletest. As far as I know they got accepted, although I didn't verify that. I am no longer working on the Minix project, but since the Minix project is most definitely using llvm, I am cc:-ing this to the Minix developers mailing list. Perhaps they want to respond to this. -- Kees On 27 Jul 2011, at 11:43, Jay

> 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

On 30 June 2014 16:16, Shankar Easwaran <shankare at codeaurora.org> wrote: > I think you are hitting a bug, the Observer pattern was added a few weeks > back, and may be there is some sort of uninitialized variable ? This is my back-trace at "-O2 -g" (since -O1 pass): operator() (file=<optimized out>, __closure=0x7fffffffde40) at

All, Jay - and Kees -, thank you for notifying us of this move. Yes, as Kees wrote we certainly are using llvm/gtest, but are prepared to submit our changes to gtest directly if they haven't taken them yet. I'll take it up with my GSOC student, who is working on submitting many other minix-specific patches to maintainers of packages in our third-party package repository. =Ben

Here's the version of the unit test patch, incorporating the feedback I have received so far. Some notes on the patch: - This patch doesn't include googletest itself, that will need to be checked in separately. The source distribution will live in llvm/utils/unittest/googletest. (The reason for the extra directory level is so that the LLVM-specific makefiles can live in

Hi Paul, You added some support for Haiku to LLVM's copy of googletest: http://llvm.org/viewvc/llvm-project?view=rev&revision=83823 http://llvm.org/viewvc/llvm-project?view=rev&revision=106620 Is it still being used? If so, would you mind pushing these patches upstream to the googletest project: http://code.google.com/p/googletest/ Otherwise we may drop them, because it makes it

$(llvm-config --libs | tr " " "\n" | grep gtest) returns: -lgtest_main -lgtest instead of non-valid: -lLLVMgtest_main -lLLVMgtest It also fixes: $(ld): cannot find -lLLVMgtest $(ld): cannot find -lLLVMgtest_main --- unittests/Makefile.unittest | 2 +- utils/llvm-build/llvmbuild/componentinfo.py | 4 ++-- utils/llvm-build/llvmbuild/main.py |

On Thu, Mar 15, 2018 at 11:10 AM David Blaikie via llvm-dev < llvm-dev at lists.llvm.org> wrote: > +Chandler who might have some thoughts on this. > FWIW, I have no concerns about updating to a modern googletest. More modern the better IMO if someone is willing to do the work to make sure it works on all our platforms, etc. However: > Could you provide an example here of the