similar to: [LLVMdev] make check where host != target

The dejagnu tests are mostly compile tests and / or grep'ing for patterns in generated code. It shouldn't matter if host != target. Evan On Jun 24, 2009, at 8:08 AM, Sandeep Patel wrote: > Is make check supposed to work in cases where host != target? I'm > seeing a ton of problems where the makefiles are testing $(OS) and > trying to test the properties of the target OS,

I'm not currently setup to be able to run the A/B comparison tests that test-suite relies upon. Fhourstones-3.1 looks to be the simplest. If you can send me the two .o files from either EABI or Darwin, I can dig into why this went wrong for you. deep On Thu, Feb 26, 2009 at 3:53 PM, Evan Cheng <echeng at apple.com> wrote: > Sorry I haven't gotten back to you earlier. I have

After wasting an inordinate amount of time trying to get test-suite to run on arm-apple-darwin so I could reproduce your results, attached is a patch that fixes the small copy&paste error of having 8-byte alignment for stack-allocated f64s instead of the proper 4-byte. I've updated the patch to the top of trunk changes as well. deep On Fri, Feb 27, 2009 at 8:31 PM, Sandeep Patel

On Apr 16, 2009, at 2:52 AM, Sandeep Patel wrote: > After wasting an inordinate amount of time trying to get test-suite to > run on arm-apple-darwin so I could reproduce your results, attached is > a patch that fixes the small copy&paste error of having 8-byte > alignment for stack-allocated f64s instead of the proper 4-byte. I've > updated the patch to the top of trunk

This time with the test cases actually attached. deep On Tue, Feb 17, 2009 at 4:41 PM, Sandeep Patel <deeppatel1987 at gmail.com> wrote: > On Mon, Feb 16, 2009 at 11:00 AM, Evan Cheng <evan.cheng at apple.com> wrote: >> /// Information about how the value is assigned. >> - LocInfo HTP : 7; >> + LocInfo HTP : 6; >> >> Do you know why this change

Done! Sandeep, this is really a great change. I had seen the discussion of it but hadn't looked at the details until now. Thanks a lot for contributing this. While I was reviewing it, I found some a few small nit-picky things to clean up (mostly in comments and whitespace). Sorry -- I'm a bit compulsive that way! I will commit those changes in a few minutes. Other than

Thanks. More questions :-) /// Information about how the value is assigned. - LocInfo HTP : 7; + LocInfo HTP : 6; Do you know why this change is needed? Are we running out of bits? - NeededStackSize = 4; - break; - case MVT::i64: - case MVT::f64: - if (firstGPR < 3) - NeededGPRs = 2; - else if (firstGPR == 3) { - NeededGPRs = 1; - NeededStackSize = 4; -

Sorry I haven't gotten back to you earlier. I have been busy. I ran some MultiSource/Benchmark earlier today. Looks like there are some failures: Fhourstones-3.1, Fhourstones, McCat/08-main, MiBench/ consumer-lame, Olden/Power, Olden/voronoi, mafft/pairlocalign, and sim. Are you able to test them on your end? Evan On Feb 17, 2009, at 4:42 PM, Sandeep Patel wrote: > This time with

On Mon, Feb 16, 2009 at 11:00 AM, Evan Cheng <evan.cheng at apple.com> wrote: > /// Information about how the value is assigned. > - LocInfo HTP : 7; > + LocInfo HTP : 6; > > Do you know why this change is needed? Are we running out of bits? HTP was't using all of these bits. I needed the hasCustom bit to come from somewhere unless we wanted to grow this struct, so I

Sure. Updated patches attached. deep On Fri, Feb 13, 2009 at 5:47 PM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Feb 13, 2009, at 4:25 PM, Sandeep Patel wrote: > >> ARMTargetLowering doesn't need case #1, but it seemed like you and Dan >> wanted a more generic way to inject C++ code into the process so I >> tried to make the mechanism a bit more

Sorry left a small bit of cruft in ARMCallingConv.td. A corrected patch it attached. deep On Fri, Feb 13, 2009 at 6:41 PM, Sandeep Patel <deeppatel1987 at gmail.com> wrote: > Sure. Updated patches attached. > > deep > > On Fri, Feb 13, 2009 at 5:47 PM, Evan Cheng <evan.cheng at apple.com> wrote: >> >> On Feb 13, 2009, at 4:25 PM, Sandeep Patel wrote:

On Dec 18, 2008, at 7:05 PM, Sandeep Patel wrote: > Since there have been no answers, I will have to start at the > beginning. > > One of the first changes I'd like to try is adding the additional > registers and the AAPCS VFP variant calling conventions. Is there a > reason why the ARM Target isn't using the CCState machinery? Please clarify. I am not sure what you

ARMTargetLowering doesn't need case #1, but it seemed like you and Dan wanted a more generic way to inject C++ code into the process so I tried to make the mechanism a bit more general. deep On Fri, Feb 13, 2009 at 2:34 PM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Feb 13, 2009, at 2:20 PM, Sandeep Patel wrote: > >> On Fri, Feb 13, 2009 at 12:33 PM, Evan Cheng

On Fri, Feb 13, 2009 at 12:33 PM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Feb 12, 2009, at 6:21 PM, Sandeep Patel wrote: > >> Although it's not generally needed for ARM's use of CCCustom, I return >> two bools to handle the four possible outcomes to keep the mechanism >> flexible: >> >> * if CCCustomFn handled the arg or not >>

Although it's not generally needed for ARM's use of CCCustom, I return two bools to handle the four possible outcomes to keep the mechanism flexible: * if CCCustomFn handled the arg or not * if CCCustomFn wants to end processing of the arg or not I placed the "unsigned i" outside those loops because i is used after the loop. If there's a better index search pattern, I'd

I think I've got all the cases handled now, implementing with CCCustom<"foo"> callbacks into C++. This also fixes a crash when returning i128. I've also included a small asm constraint fix that was needed to build newlib. deep On Mon, Jan 19, 2009 at 10:18 AM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Jan 16, 2009, at 5:26 PM, Sandeep Patel wrote:

On Feb 13, 2009, at 4:25 PM, Sandeep Patel wrote: > ARMTargetLowering doesn't need case #1, but it seemed like you and Dan > wanted a more generic way to inject C++ code into the process so I > tried to make the mechanism a bit more general. Ok. Since ARM doesn't need it and it's the only client, I'd much rather have CCCustomFn just return a single bool indicating

Hi all, When using "make check" with the DejaGNU test collection, I encounter two unexpected failures (they seem to be closely related). My question: are they well known, and if so what's the problem and how can I fix it? This is the error text I get: FAIL: /var/data/common/trunk/llvm/test/FrontendC/2008-05-19-AlwaysInline.c Failed with exit(1) at line 1 while running:

On Feb 13, 2009, at 2:20 PM, Sandeep Patel wrote: > On Fri, Feb 13, 2009 at 12:33 PM, Evan Cheng <evan.cheng at apple.com> > wrote: >> >> On Feb 12, 2009, at 6:21 PM, Sandeep Patel wrote: >> >>> Although it's not generally needed for ARM's use of CCCustom, I >>> return >>> two bools to handle the four possible outcomes to keep

On Feb 12, 2009, at 6:21 PM, Sandeep Patel wrote: > Although it's not generally needed for ARM's use of CCCustom, I return > two bools to handle the four possible outcomes to keep the mechanism > flexible: > > * if CCCustomFn handled the arg or not > * if CCCustomFn wants to end processing of the arg or not +/// CCCustomFn - This function assigns a location for Val,