similar to: [LLVMdev] [LNT][Patch] Bug 16261 - lnt incorrectly builds timeit-target when one is using a simulator

The issues seems to be this line in the tools Makefile timeit-target: timeit.c $(LD_ENV_OVERRIDES) $(LCC) -o $@ $< $(LDFLAGS) $(CFLAGS) $(TARGET_FLAGS) -O3 It should not add target flags if we are simulating the target on the host. On 06/06/2013 06:59 PM, reed kotler wrote: > I want to get lnt to use qemu for the execution. > > In that case, RHOST= is not set. > > But I

Hi Jim, There is no "target independent" code in these patches. It's all Mips specific. There is something I'm proposing for AP/NO_APP wrappers but that will just make the stubs look nicer (without the clutter of those wrappers). That is purely a cosmetic issue of the .s files being produced. The discussion has moved back to the main thread so I'll continue there.

I want to get lnt to use qemu for the execution. In that case, RHOST= is not set. But I change the Arch because I am going to run in cross mode. Then I'm setting RUNUNDER to be a script which runs qemu. In this case it builds timeit-target as a Mips which fails because this is running on x86. ~/mysandbox/bin/lnt runtest nt --sandbox ~/mysandbox --cc /local/llvmpb_a/install/bin/clang

On Tue, Jun 4, 2013 at 5:52 PM, Renato Golin <renato.golin at linaro.org>wrote: > On 4 June 2013 22:08, Reed Kotler <rkotler at mips.com> wrote: > >> is test-suite being run still by itself (independent of llvm)? >> > > AFAIK, yes. http://llvm.org/docs/lnt/quickstart.html > > > if so, are there public build bots for this? >> > > We have

I have run "make check", the "test-suite" on x86 and all internal mips flavors with this patch and no problems arose. On 11/04/2012 11:07 AM, Reed Kotler wrote: > The main idea is to distinguish between emitting normal labels and debug > labels. This is the nomenclature chosen by the gcc people working on > this same problem. > > I have just added one

I hit the same problems as you did when I tried it a few weeks ago. Haven't bothered with it since. There is a way to run tests without using lnt. You can use the Makefiles directly in your test-suite build directory. For running nightly tests, you can do: make report.html TEST=nightly That will generate a html file with the test results in. Amara On 26 October 2012 22:53, Renato Golin

On Fri, Oct 26, 2012 at 2:53 PM, Renato Golin <rengolin at systemcall.org> wrote: > Hi, > > I'm trying to setup the test-suite and am getting short of running it... > > Following the steps here: > > http://llvm.org/docs/lnt/quickstart.html > > I got as far as getting lnt installed, but when I run the "lnt runtest > nt" it fails: > >

Hi, I'm trying to setup the test-suite and am getting short of running it... Following the steps here: http://llvm.org/docs/lnt/quickstart.html I got as far as getting lnt installed, but when I run the "lnt runtest nt" it fails: compilers.py:81: error: unable to determine compiler version: 'clang++': 'clang version 3.2 ' Seems my string doesn't have a

On 4 June 2013 22:08, Reed Kotler <rkotler at mips.com> wrote: > is test-suite being run still by itself (independent of llvm)? > AFAIK, yes. http://llvm.org/docs/lnt/quickstart.html if so, are there public build bots for this? > We have one: http://lab.llvm.org:8011/builders/clang-native-arm-lnt Setting it up was just copy&paste on Zorg's config (and fixing the bugs

Hello everyone, I am working to run the LLVM Nightly Testsuite on embedded arm devices. Not all of these devices can mount NFS to share a common directory tree. To mitigate this I have patched test-suite/RunSafely.sh (attached) to create a temporary directory, run the test remotely, collect the output, and cleanup after itself. The patch breaks compatibility with the current remote device model

On 17 June 2013 19:01, Daniel Dunbar <daniel at zuster.org> wrote: > There are several individual users who still use the full Makefile > infrastructure. I think we pretty much use LNT exclusively for automated > runs now, but for development purposes the Makefile setup still has various > features that make it more amenable to incremental development. > Hi Daniel, I have

Hi, I'm new to llvm and am trying to run benchmarks from the test-suite using lnt to check loop-vectorization for various benchmarks. Test are compiling and executing fine, but I am not getting optimization remarks while using flags like -Rpass-missed=loop-vectorize and -Rpass-analysis=loop-vectorize I've tried running it like this: lnt runtest test-suite --sandbox SANDBOX --cc

Most of the selections, like "console" for example, do not work when I click on them. On 03/27/2013 03:57 PM, Michael Gottesman wrote: > Hello LLVM Dev and Clang Dev! > > David Dean and I just finished bringing up a new build master on > lab.llvm.org <http://lab.llvm.org/>, llvmlab, which is located at the > url http://lab.llvm.org:8013

Hi all, The LLVM benchmarking system produces very noisy results even on quiet machines. One of the sources of inaccuracy is the timing tool we are using. Because it is a user-space tool, the OS can context switch it and we will get an outlier result. Perf stat uses SW_TASK_CLOCK counter in kernel to measure time, therefore more accurate. It also does not get context switched. I've

On 16 May 2014 18:08, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Yi Kong" <kongy.dev at gmail.com> >> To: "Hal Finkel" <hfinkel at anl.gov>, "Renato Golin" <renato.golin at linaro.org>, "Tobias Grosser" <tobias at grosser.es> >> Cc: "LLVM Dev" <llvmdev at

I've set up a public LNT server to show the result of perf stat. There is a huge improvement compared with timeit tool. http://parkas16.inria.fr:8000/ Patch is updated to pin the process to a single core, the readings are even more accurate. It's hard coded to run everything on core 0, so don't run parallel testing with it for now. The tool now depends on Linux perf and schedtool.

On 16 May 2014 18:40, "Chandler Carruth" <chandlerc at google.com> wrote: > > Why not use the cycle count which perf exposes from hardware? That would seem even better to me, but data would be better. =] That's an interesting idea. However I'm concerned if that will miss some aspects of compiler optimization. For example frequent cache misses would have much smaller

Hi, I follow quick-start guide http://llvm.org/docs/lnt/quickstart.html to run LLVM test-suite. It looks like I either make a mistake or the guide is not correct. Here is the command used to run nightly test: [[ $ lnt runtest nt --sandbox=$PWD/test-suite.bld \ --small --test-style=nightly \ --cc=$PWD/llvm.bld/Release+Asserts/bin/clang \ --cxx=$PWD/llvm.bld/Release+Asserts/bin/clang++

On 06/23/2013 11:12 PM, Star Tan wrote: > Hi all, > > > When we compare two testings, each of which is run with three samples, how would LNT show whether the comparison is reliable or not? > > > I have seen that the function get_value_status in reporting/analysis.py uses a very simple algorithm to infer data status. For example, if abs(self.delta) <= (self.stddev *

The run page problem were triggered by one of my commits (sorry) and should be mitigated now, see the thread at http://lists.llvm.org/pipermail/llvm-dev/2017-July/115971.html <http://lists.llvm.org/pipermail/llvm-dev/2017-July/115971.html> I don't know about the submission problems, could they just an occasional network problem or are they a common phenomenon? Chris did some