similar to: FreeBSD user willing to try fix a unit test?

The clang-i686-freebsd-selfhost-rel buildbot is failing APIntTest.i33_Count on the first run, but the stage 2 test is passing. It looks like it could be a miscompilation by the system gcc. We should upgrade the system gcc on that machine, or stop testing the stage 1 llvm. The tester is not useful as is. It is failing constantly. Who owns this machine? Can the system be upgraded? /jakob

On 2010-09-09 23:44, Jakob Stoklund Olesen wrote: > The clang-i686-freebsd-selfhost-rel buildbot is failing APIntTest.i33_Count on the first run, but the stage 2 test is passing. > > It looks like it could be a miscompilation by the system gcc. Yes, unfortunately on FreeBSD the first stage should be compiled using "-O2 -fno-strict-aliasing" instead of the default optimization

Eric, Attached are patches for llvm and clang that implement this. I've made 'none' a component that must be added explicitly (i.e. don't turn arm-eabi into arm--none-eabi, but rather turn it into arm--unknown-eabi) to try to reduce surprises. It also keeps the normalization logic a bit simpler than it would otherwise have to be. SPIR triples were one place where I was

> On Jan 4, 2017, at 9:49 AM, Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > TL;DR - I want this. For the most part, +1 from me too. A few comments though. > > On Wed, Jan 4, 2017 at 6:11 AM Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > ## Matchers > > To start off, it

On Dec 22, 7:34 pm, Talin <viri... at gmail.com> wrote: > (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. I think this is a great idea! As Keir already noted, I would also agree with LLVM

Misha Brukman wrote: > On Dec 22, 7:34 pm, Talin <viri... at gmail.com> wrote: > >> (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. >> > > I think

Thanks for the clarifications, Bob! I’ve spent some time with the head of the llvm.org repo, and I now understand a lot better what Renato and Tim were talking about re. the architecture aliases. The patch to add v6l, therefore, seems simple enough. I haven’t been able to test it in my usual flow, because that involves the whole swift stack. I’m considering creating a program that links to

Hi, I am trying to replace a c-style function with another function with same signature. Consider the following code: std::stringstream main_c; main_c <<"#include <stdio.h>\n" <<"extern \"C\" { \n" <<"int print1()\n" <<"{\n" <<" printf(\"Inside

The attached patch prevents MappedMemoryTest.BasicWrite and MappedMemoryTest.MultipleWrite (both in unittests/Support/MemoryTest.cpp) from running if the correct protection flags for memory allocation are not set. Without this patch, the two tests fail when I run "make check-all" on a mips octeon board. The problem with the current code is that it allocates a block of memory without

The clang-i686-freebsd-selfhost-rel buildbot is failing APIntTest.i33_Count on the first run, but the stage 2 test is passing. It looks like it could be a miscompilation by the system gcc. We should upgrade the system gcc on that machine, or stop testing the stage 1 llvm. The tester is not useful as is. It is failing constantly. Who owns this machine? Can the system be upgraded? /jakob

On Fri, Dec 26, 2008 at 8:06 PM, Misha Brukman <brukman at gmail.com> wrote: > On Dec 22, 7:34 pm, Talin <viri... at gmail.com> wrote: > > (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

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

Hi all- I am mostly doing work in Clang (and am new there), so I apologize if this isn't the proper place to mention this. I appreciate guidance in advance. I was looking 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:

Look good. -Andy From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Akira Hatanaka Sent: Tuesday, December 04, 2012 1:33 PM To: LLVM Developers Mailing List Subject: [LLVMdev] [PATCH][Review request] MappedMemoryTest: Prevent tests from running if read flag is not set. The attached patch prevents MappedMemoryTest.BasicWrite and

A long time ago I suggested that we might want to add gmock to compliment the facilities provided by gtest in LLVM's unittests. It didn't go over well: 1) There was concern over the benefit vs. the cost 2) Also concern about what the facilities would look like in practice and whether they would actually help 3) At the time, I didn't have good, large examples of what these things might

Sorry for the inline-comment format being weird, I haven't figured out yet how to do '>' stuff in outlook yet :/ Hopefully this is clear enough. -----Original Message----- From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] Sent: Wednesday, August 24, 2016 10:55 AM To: Keane, Erich <erich.keane at intel.com> Cc: llvm-dev at lists.llvm.org Subject: Re:

Hi all, I experienced some test failures under Linux, probably caused by r232936: In the test SanitizerCommon-Unit :: Sanitizer-i386-Test/MemoryMappingLayout.CodeRange the temporary test file was opened write-only, but was read from, what subsequently failed: Note: Google Test filter = MemoryMappingLayout.CodeRange [==========] Running 1 test from 1 test case. [----------] Global test

(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

Duncan, I'm tracking down an infinite recursion problem when calling toInt. The problem seems to be that in the call to toInt, we call compareTo which, in turn, calls toInt in one of its paths. This does not happens on 64bit Scaled numbers. I'm trying to work out a fix, but maybe you'll spot the problem quicker. Here's a unittest that triggers the problem. I ran into it with

Just a curiosity question, why push for gtest vs Boost Test or a different test suite? I normally use Boost, and their test suite, so I'm more familiar with that. So I was wondering is one better then the other, or is it just that someone makes a patch for it? Regards Mark Kromis On Dec 27, 2008, at 12:26 AM, Keir Mierle wrote: > > > On Fri, Dec 26, 2008 at 8:06 PM, Misha