similar to: [LLVMdev] Testing documentation and terminology

On May 23, 2008, at 5:06 AM, Matthijs Kooijman wrote: > Hi all, > > as you might have seen, I just did some restructuring on the testing > documentation. Since the changes are only documentation and mostly > text > movement, I took the liberty of committing without posting a patch > first. Was > that appropriate?. Yep, if you consider it to be obvious, it can be

Hi All, I've finally implemented my proposed changes to the testing documentation. I think I fixed up the naming everywhere, but I did only a single pass over the document, so I might have missed something. Review welcome :-) It is now recommended to put the test suite in "projects/test-suite" instead of "projects/llvm-test". I've also updated the configure script and

> > >> Currently, the first is called the "LLVM test suite" (which is the >> subject of >> the testing documentation). The second is called the DejaGNU tests, >> code >> fragment tests or llvm/test. The last one is the most confusing, >> it's called >> the whole program tests, test-suite (named after the svn directory >> it is in,

Great! To really finish this work, the nightly tester script needs to be updated. Its currently full of llvm-test references. Would you be willing to modify this as well? Thanks, Tanya On Tue, 24 Jun 2008, Matthijs Kooijman wrote: > Hi All, > > I've finally implemented my proposed changes to the testing documentation. I > think I fixed up the naming everywhere, but I did only

Hi Dan, > Oh, ok. So code that takes an alloca, bitcasts the address to a higher > alignment, Since alignment is not a property of a type, I don't think you can "bitcast to a higher alignment" as such. I still understand what you mean, though :-) > and then does a load or store at the higher alignment, is > invoking undefined behavior. The alignment attribute on a load

Hello, people I'm developing a small code analysis project with LLVM (I hope I can concentrate on it next semester and make it a really functional tool, but, for now, it's an college end course project, and I'm more focused on theoretical issues than on the implementation). I'm using Ubuntu Linux and had a lot of trouble starting the project by copping the "sample

2 more roadblocks for Visual Studio users are the inability to compile gcc and the inability to compile and run the test suite. I would not want to submit a change unless I could still compile/run gcc and pass the test suite. (Testing before submission is the way we do it where I come from - I am assuming it's the same here). On a related note, has anyone gotten the LLVM test suite working

Hi, I think I have quite an identical patch lying around somewhere here, but I thought that the AutoRegen.sh was something someone wrote here in-house, so I never bothered to send it somewhere. I do remember someone saying (on this list) one should really not use another version of autoconf, but in my experience 2.6 works just as fine for building an addon project (but perhaps not for rebuilding

Hi Dan, > Changing PromoteCastOfAllocation to not replace aggregate allocas with > non-aggregate allocas if they have GEP users sounds reasonable to me. This sounds reasonable indeed, but still a bit arbitrary. Haven't figured out anything better yet, though. > Finding the maximum alignment is sometimes still useful though, so > it would be nice to update the alignment field of

As we begin designing the proposed validation process, we should think about what the criteria for a successful validation should be. In the initial proposal I suggested the "make check" on llvm should pass as should the tests in llvm-test. According to Tanya, not all of llvm-test passes. Do we have a sense of how far away from a full passing llvm-test we are? I also know that a

On Sep 23, 2008, at 4:16 AM, Matthijs Kooijman wrote: > >> and then does a load or store at the higher alignment, is >> invoking undefined behavior. The alignment attribute on a load or >> store >> is an assertion about the actual alignment of the memory. > Should this undefined behaviour be caught by the verifier, or is it > ok for it > to exist? I

On 12 Oct 2007, at 07:07, Evan Cheng wrote: >>In order to test the tail call optimization i created quite a few >>.ll files and added them to the SingleSource directory in the >>test-suite. For example >>llvm-test/SingleSource/Tailcall/tailcall1-2.ll. >Shouldn't these be dejagnu tests instead? There is one test in dejagnu that tests whether tail call optimization

Hi Kenneth, If the LLVM project is switching to CMake, then CTest might be the framework of choice to use rather than scripting up something in Bash. --Sam --- On Wed, 7/30/08, Kenneth Boyd <zaimoni at zaimoni.com> wrote: > From: Kenneth Boyd <zaimoni at zaimoni.com> > Subject: Re: [LLVMdev] Is there room for another build system? > To: "LLVM Developers Mailing

Jonathan Brumley wrote: > > 2 more roadblocks for Visual Studio users are the inability to compile > gcc and the inability to compile and run the test suite. I would not > want to submit a change unless I could still compile/run gcc and pass > the test suite. (Testing before submission is the way we do it where > I come from - I am assuming it's the same here). >

Thanks, Stuart. Sorry, I had some left-over editing cruft in my email. >From Googling runtest, I had found dejagnu, which I'd heard some folks were using over there, so I used the local package manager to install it. But from what you said I went ahead and got the dejagnu sources and built it, but had problems in running make install, which is trying to put it /usr/local/bin rather than

Hi, just a quick email. I've been working on a patch to simplifycfg last week and want to test its performance. I've ran the test-suite succesfully, both with the patched and unpatched versions. However, I could find no easy way to compare both results. I see that the web pages of the nightly tester provide nice results (changes compared to the day before, together with percentages and

Hi, I've been toying around with the testsuite for a bit, and after recompiling llvm-gcc a bunch of times and fixing a nasty bashism bug, I actually got it to run and pass most tests. When running, I noticed a very long runtime on the lemon test. At first I suspected an infinite loop, but it turned out the test simply needed around 1000 seconds to run. Some investigation turned out that the

TL;DR: I am proposing to add the GCC C Torture suite [1], as an additional external source of tests for the “nightly” test suite. If you are willing to review the patch, it is here: https://reviews.llvm.org/D66887 Background: While working on the RISC-V backend, we have found it useful to use additional test suites beyond the in-tree Clang and LLVM tests and the LLVM nightly tests, in order to

I found that it was runtest.exp which referenced to the internal exp_debug function. For testing purposes I disabled the reference and ran a new: make check VERBOSE=1 which gave me this: ------------------ if test -d "/C/projects/build/MinGW/llvm-2-1/test" ; then \ if test -f "/C/projects/build/MinGW/llvm-2-1/test/Makefile" ; then \ echo llvm[0]: Running test suite ; \

On Sat, Oct 11, 2008 at 7:30 AM, Kenneth Boyd <zaimoni at zaimoni.com> wrote: > At the absolute minimum, simple counting of the success/failure/internal > error results requires three different exit codes, and a test driver > capable of tallying them up and reporting all failures (unexpected > success, unexpected failure, and internal errors with a designated > distinct exit