similar to: [LLVMdev] test-suite strange output

On 8/2/13 6:03 PM, reed kotler wrote: > Turns out that in my latest upgrade to Ubuntu 12.x, it reassigned > > /bin/sh -> /bin/dash and LLVM needs /bin/sh to be /bin/bash I would think that using bash specific features in a /bin/sh shell script is a bug. I remembering ferreting these sorts of problems out in the early days. Does LLVM now consider it okay to assume that /bin/sh is

Turns out that in my latest upgrade to Ubuntu 12.x, it reassigned /bin/sh -> /bin/dash and LLVM needs /bin/sh to be /bin/bash On 08/02/2013 03:45 PM, reed kotler wrote: > Has anyone ever seen this message in the test-suite output: > > /bin/sh: 7: test: 0: unexpected operator > > I'm getting a lot of them but otherwise it seems to be working just fine.

The first one failed on a diff: ******************** TEST (simple) 'sse.expandfft' FAILED! ******************** Execution Context Diff: /home/rkotler/llvmpb3/build/projects/test-suite/tools/fpcmp: Compared: 1.139094e-07 and 1.159249e-07 abs. diff = 2.015500e-09 rel.diff = 1.738626e-02 Out of tolerance: rel/abs: 1.600000e-02/0.000000e+00 ******************** TEST (simple)

I have an approved target independent putback and i've run all that we have at Mips as well as on x86 " make TEST=simple" Is there anything else that is easy to run that I can do before doing the commit? The patch touches a number of basic classes so I'm just trying to err on the side of caution.

I use the 'make TEST=simple' as a pre-commit test. I think that everybody should run these tests before committing to LLVM. On Dec 12, 2012, at 5:06 PM, reed kotler <rkotler at mips.com> wrote: > when I create the report, there are no failures in it. so maybe these are being filtered for known failures. > > On 12/12/2012 05:03 PM, reed kotler wrote: >> The first

when I create the report, there are no failures in it. so maybe these are being filtered for known failures. On 12/12/2012 05:03 PM, reed kotler wrote: > The first one failed on a diff: > ******************** TEST (simple) 'sse.expandfft' FAILED! > ******************** > Execution Context Diff: > /home/rkotler/llvmpb3/build/projects/test-suite/tools/fpcmp: Compared: >

We have a modified version of projects/test-suite that we can run cross using Qemu. We would like to put that back so that other people can test MIPS before putting back. Well, this would be easily modifiable for ARM and other targets that are supported by QEMU. But in this case, we would need to check in a version of QEMU and also the needed pieces of a MIPS tool chain for assembly,

On Sat, Dec 15, 2012 at 12:33 PM, Reed Kotler <rkotler at mips.com> wrote: > I have an approved target independent putback and i've run all that we > have at Mips as well as on x86 " make TEST=simple" > > Is there anything else that is easy to run that I can do before doing the > commit? > > The patch touches a number of basic classes so I'm just

On 12/15/2012 12:53 PM, Chandler Carruth wrote: > On Sat, Dec 15, 2012 at 12:33 PM, Reed Kotler <rkotler at mips.com > <mailto:rkotler at mips.com>> wrote: > > I have an approved target independent putback and i've run all > that we have at Mips as well as on x86 " make TEST=simple" > > Is there anything else that is easy to run that I

On 12/15/2012 12:53 PM, Chandler Carruth wrote: > On Sat, Dec 15, 2012 at 12:33 PM, Reed Kotler <rkotler at mips.com > <mailto:rkotler at mips.com>> wrote: > > I have an approved target independent putback and i've run all > that we have at Mips as well as on x86 " make TEST=simple" > > Is there anything else that is easy to run that I

I'm trying to run test-suite for x86 in order to verify a target independent patch before I put it back. The patch has been approved. What is the best way to run it in order to get maximum coverage and have results where I can tell that I have not regressed anything (as well as the test-suite can help with that)? I've already tested it against the Mips compiler but we have a slightly

On 11/07/2011 02:29 PM, Eli Friedman wrote: > On Mon, Nov 7, 2011 at 2:11 PM, reed kotler<rkotler at mips.com> wrote: >> We have a modified version of projects/test-suite that we can run cross >> using Qemu. >> >> We would like to put that back so that other people can test MIPS >> before putting back. >> Well, this would be easily modifiable for ARM

is test-suite being run still by itself (independent of llvm)? if so, are there public build bots for this? is lnt going to replace test-suite as the normal mechanism for running test-suite? Tia. Reed

I see what my problem is here.... I'll continue to move further. Seems like Richards fix is still okay. On 02/25/2014 02:42 PM, Eric Christopher wrote: > On Tue, Feb 25, 2014 at 2:41 PM, reed kotler <rkotler at mips.com> wrote: >> On 02/25/2014 02:38 PM, Eric Christopher wrote: >>> On Tue, Feb 25, 2014 at 2:32 PM, reed kotler <rkotler at mips.com> wrote:

On 02/25/2014 02:38 PM, Eric Christopher wrote: > On Tue, Feb 25, 2014 at 2:32 PM, reed kotler <rkotler at mips.com> wrote: >> On 02/25/2014 09:30 AM, Richard Sandiford wrote: >>> reed kotler <rkotler at mips.com> writes: >>>> On 02/24/2014 04:42 PM, Eric Christopher wrote: >>>>> On Mon, Feb 24, 2014 at 4:40 PM, reed kotler <rkotler at

On 12/12/2012 10:18 AM, Nadav Rotem wrote: > I run the test suite by CD-ing into /projects/test-suite and running "make TEST=simple -j 4". > > > On Dec 12, 2012, at 10:13 AM, Reed Kotler <rkotler at mips.com> wrote: > >> I'm trying to run test-suite for x86 in order to verify a target independent patch before I put it back. >> The patch has been

Well, you are an mclinker contributor and Google uses mclinker and now it's broken as the result of your change. I still don't see any justification to making a change in a public interface that is used by other non LLVM projects to fix some issue with clang warnings. People should be able to derive from those classes. I can't understand your reasoning as to why these classes must

If you can't make an executable test from C or C++ code then how do you know something works. Just by examination of the .s? On 09/30/2014 03:18 PM, Reed Kotler wrote: > If I wanted to call this function that they generated by hand, from C or > C+ code, how would that be done? > > if have seen cases where a real boolean gets generated but it was > something fairly involved.

I run the test suite by CD-ing into /projects/test-suite and running "make TEST=simple -j 4". On Dec 12, 2012, at 10:13 AM, Reed Kotler <rkotler at mips.com> wrote: > I'm trying to run test-suite for x86 in order to verify a target independent patch before I put it back. > The patch has been approved. > > What is the best way to run it in order to get maximum

On 03/19/2015 09:24 AM, David Blaikie wrote: > > > On Thu, Mar 19, 2015 at 9:18 AM, Reed Kotler <reed.kotler at imgtec.com > <mailto:reed.kotler at imgtec.com>> wrote: > > Well, you are an mclinker contributor > > > Me personally? Not that I know of. Sorry. I thought i had seen your name in an mclinker commit. > > and Google uses mclinker >