search for: expect_eq

...argetABI = ARM_ABI_AAPCS; else TargetABI = ARM_ABI_APCS; Index: unittests/ADT/TripleTest.cpp =================================================================== --- unittests/ADT/TripleTest.cpp (revision 211122) +++ unittests/ADT/TripleTest.cpp (working copy) @@ -123,12 +123,6 @@ EXPECT_EQ(Triple::UnknownOS, T.getOS()); EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment()); - T = Triple("arm-none-none-eabi"); - EXPECT_EQ(Triple::arm, T.getArch()); - EXPECT_EQ(Triple::UnknownVendor, T.getVendor()); - EXPECT_EQ(Triple::UnknownOS, T.getOS()); - EXPECT_EQ(Triple::...

Hi all In unittests/ADT/APIntTest.cpp I came across this test: // XFAIL this test on FreeBSD where the system gcc-4.2.1 seems to miscompile it. #if defined(__llvm__) || !defined(__FreeBSD__) TEST(APIntTest, i33_Count) { APInt i33minus2(33, static_cast<uint64_t>(-2), true); EXPECT_EQ(0u, i33minus2.countLeadingZeros()); EXPECT_EQ(32u, i33minus2.countLeadingOnes()); EXPECT_EQ(33u, i33minus2.getActiveBits()); EXPECT_EQ(1u, i33minus2.countTrailingZeros()); EXPECT_EQ(32u, i33minus2.countPopulation()); EXPECT_EQ(-2, i33minus2.getSExtValue()); EXPECT_EQ(((uint64_t)-2)&...

[+llvmdev, -llvm-dev] (Oopsies, llvmdev doesn't have a hyphen in it like all the others do) On 6/17/14, 10:45 AM, Jonathan Roelofs wrote: > [+llvm-dev, cfe-dev] > > Was "Re: [PATCH] ARM: allow inline atomics on Cortex M" > > On 6/17/14, 10:42 AM, Jonathan Roelofs wrote: >> >> >> On 6/17/14, 9:35 AM, Renato Golin wrote: >>> On 17 June 2014

...ts.llvm.org>> wrote: > > ## Matchers > > To start off, it is important to understand that there are two components to what gmock offers. The first has very little to do with "mocks". It is actually a matcher language and system for writing test predicates: > > EXPECT_EQ(expected, actual); > EXPECT_NE(something, something); > > Become instead: > > EXPECT_THAT(actual, Eq(expected)); > EXPECT_THAT(actual, Ne(not-expected)); For the cases where you have containers and other non-trivial objects, I completely agree that this is compelling. How...

...lt;llvm/foo.h> * You should use the same format for gtest headers * If reverse iteration isn't supported, you should either have an ASSERT_DEATH() on the decrement, or not have the code there (that's commented out) at all. * Instead of this: EXPECT_TRUE(uintMap[0] == 1); you should use EXPECT_EQ() * Instead of this: EXPECT_TRUE(uintMap.find(0u) == uintMap.begin()); is it possible to use EXPECT_EQ() as well? * In this test: TEST_F(DenseMapTest, IterationTest) { you use the array "int numbers[100];" as an array of booleans; why not make it "bool visited[100];" to make c...

...t;) .Cases("v6z", "v6zk", "v6kz") Index: unittests/ADT/TripleTest.cpp =================================================================== --- unittests/ADT/TripleTest.cpp (revision 257090) +++ unittests/ADT/TripleTest.cpp (working copy) @@ -851,6 +851,10 @@ EXPECT_EQ("arm1136jf-s", Triple.getARMCPUForArch()); } { + llvm::Triple Triple("armv6l-unknown-eabi"); + EXPECT_EQ("arm1136jf-s", Triple.getARMCPUForArch()); + } + { llvm::Triple Triple("armv6j-unknown-eabi"); EXPECT_EQ("arm1136jf-s",...

...gt; * If reverse iteration isn't supported, you should either have an > ASSERT_DEATH() on the decrement, or not have the code there (that's > commented out) at all. > I'll probably just remove it. > * Instead of this: > EXPECT_TRUE(uintMap[0] == 1); > you should use EXPECT_EQ() > Sure. > * Instead of this: > EXPECT_TRUE(uintMap.find(0u) == uintMap.begin()); > is it possible to use EXPECT_EQ() as well? > In order to use EXPECT_EQ, both arguments have to be printable, although you can make anything printable by adding the necessary stream operator o...

...rectly and execute them as well, e.g: //check the print1f is behaving properly llvm::Function *print1f = main->getFunction( "print1" ); ASSERT_NE( print1f, nullptr ); void *print1fPtr = ee->getPointerToFunction( print1f ); int ret = ((int(*)(void))(print1fPtr))(); EXPECT_EQ(0xdeadbeef, ret); However, when i try to replace the use of print1 with print2, it doesn't seem to work correctly. This is the sequence of steps that I am following: llvm::Function *print2f = main->getFunction( "print2" ); print2f->takeName( print1f ); llvm::Functi...

...benefit from it. And I think I have compelling examples. ## Matchers To start off, it is important to understand that there are two components to what gmock offers. The first has very little to do with "mocks". It is actually a matcher language and system for writing test predicates: EXPECT_EQ(expected, actual); EXPECT_NE(something, something); Become instead: EXPECT_THAT(actual, Eq(expected)); EXPECT_THAT(actual, Ne(not-expected)); This pattern moves the *matcher* out of the *macro*, giving it a proper C++ API. With that, we get two huge benefits: extensibility and composabilit...

(Forwarding this to llvm-dev) This patch adds a unit test framework to LLVM, along with a sample unit test for DenseMap. I don't expect this patch to be accepted as-is, this is mainly a trial balloon and proof of concept. Some notes about the patch: 1) For the testing framework, I went with Google Test, since it's the one I have the most experience with. I fully expect an extended

...cpp (line 101) TEST_P(MappedMemoryTest, BasicWrite) { // This test applies only to writeable combinations if (Flags && !(Flags & Memory::MF_WRITE)) return; MemoryBlock M1 = Memory::allocateMappedMemory(sizeof(int), 0, Flags, EC); ... int *a = (int*)M1.base(); *a = 1; EXPECT_EQ(1, *a); // This line segfaults. ... } -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121204/67fd4245/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name:...

...same format for gtest headers > > * If reverse iteration isn't supported, you should either have an > ASSERT_DEATH() on the decrement, or not have the code there (that's > commented out) at all. > > * Instead of this: > EXPECT_TRUE(uintMap[0] == 1); > you should use EXPECT_EQ() > > * Instead of this: > EXPECT_TRUE(uintMap.find(0u) == uintMap.begin()); > is it possible to use EXPECT_EQ() as well? > > * In this test: > TEST_F(DenseMapTest, IterationTest) { > you use the array "int numbers[100];" as an array of booleans; why not > make...

...ooking into some of the unit tests, and noticed that the ArrayRefTest.InitializerList, and thus the InitializerList constructor of ArrayRef (under normal use-case) hit undefined behavior. The test does the following: ArrayRef<int> A = { 0, 1, 2, 3, 4 }; for (int i = 0; i < 5; ++i) EXPECT_EQ(i, A[i]); For those unfamiliar, ArrayRef is a T* Data/size_t Length pair-type with a std::initializer_list Ctor that simply copies the initializer_list::begin into Data. The issue is that after the assignment, the initializer-list temporary goes out of scope (since it is a temporary), creating a...

...cpp (line 101) TEST_P(MappedMemoryTest, BasicWrite) { // This test applies only to writeable combinations if (Flags && !(Flags & Memory::MF_WRITE)) return; MemoryBlock M1 = Memory::allocateMappedMemory(sizeof(int), 0, Flags, EC); ... int *a = (int*)M1.base(); *a = 1; EXPECT_EQ(1, *a); // This line segfaults. ... } -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121205/a503d7e4/attachment.html>

...---------- diff --git a/unittests/Support/ScaledNumberTest.cpp b/unittests/Support/ScaledNumberTest.cpp index 3872155..2f38b2a 100644 --- a/unittests/Support/ScaledNumberTest.cpp +++ b/unittests/Support/ScaledNumberTest.cpp @@ -556,4 +556,9 @@ TEST(ScaledNumberHelpersTest, arithmeticOperators) { EXPECT_EQ(ScaledNumber<uint64_t>(1, 4), ScaledNumber<uint64_t>(1, 3) << 1); } +TEST(ScaledNumberHelpersTest, toIntBug) { + ScaledNumber<uint32_t> n(1, 0); + EXPECT_EQ(1u, (n * n).toInt<uint32_t>()); +} + } // end namespace

...some of the unit tests, and noticed that the ArrayRefTest.InitializerList, and thus the InitializerList constructor of ArrayRef (under normal use-case) hit undefined behavior. The test does the following: > ArrayRef<int> A = { 0, 1, 2, 3, 4 }; > for (int i = 0; i < 5; ++i) > EXPECT_EQ(i, A[i]); > > For those unfamiliar, ArrayRef is a T* Data/size_t Length pair-type with a std::initializer_list Ctor that simply copies the initializer_list::begin into Data. > > The issue is that after the assignment, the initializer-list temporary goes out of scope (since it is a tem...

...a/lib/sanitizer_common/tests/sanitizer_libc_test.cc b/lib/sanitizer_common/tests/sanitizer_libc_test.cc index 689c6ed..a304458 100644 --- a/lib/sanitizer_common/tests/sanitizer_libc_test.cc +++ b/lib/sanitizer_common/tests/sanitizer_libc_test.cc @@ -85,7 +85,7 @@ TEST(SanitizerCommon, FileOps) { EXPECT_EQ(len2, internal_write(fd, str2, len2)); internal_close(fd); - openrv = OpenFile(tmpfile, WrOnly); + openrv = OpenFile(tmpfile, RdWr); EXPECT_FALSE(internal_iserror(openrv)); fd = openrv; uptr fsize = internal_filesize(fd); @@ -134,7 +134,7 @@ TEST(SanitizerCommon, InternalMmapWithOffs...

...same format for gtest headers > > * If reverse iteration isn't supported, you should either have an > ASSERT_DEATH() on the decrement, or not have the code there (that's > commented out) at all. > > * Instead of this: > EXPECT_TRUE(uintMap[0] == 1); > you should use EXPECT_EQ() > > * Instead of this: > EXPECT_TRUE(uintMap.find(0u) == uintMap.begin()); > is it possible to use EXPECT_EQ() as well? > > * In this test: > TEST_F(DenseMapTest, IterationTest) { > you use the array "int numbers[100];" as an array of booleans; why not > make...

> You assume triples make sense. That's the first mistake everyone does > when thinking about triples. :) I know they don't make sense in many corner cases, but I think discarding logic where it *does* exist is a mistake. > AFAIK, "ARMv7B" is only used by HighBank, which is no more. But that, > too, was "ARMv7A big endian". I believe it's what any

On Wed, Jul 13, 2016 at 04:48:51PM +0200, Sedat Dilek via llvm-dev wrote: > [ CCed all people who were involved in this thread ] > > Hi Tom, > > personally, I am interested to test the prebuilt-toolchains for > Ubuntu/xenial alias 16.04 LTS and Debian/Jessie v8.5.0 AMD64. > The available toolchains are incomplete and thus useless. > > Just as a fact: There is still no