similar to: [LLVMdev] llvm test results for FreeBSD platform

Displaying 20 results from an estimated 600 matches similar to: "[LLVMdev] llvm test results for FreeBSD platform"

2004 Jun 21
4
[LLVMdev] llvm test results for FreeBSD platform
Is it ok sending this results for FreeBSD5.1 at daily/weekly based to this mail list? Now results. Big improvement in llvm tests results from last test result sended. New regressions: Regression.Assembler.ConstantExprFold : FAIL , expected PASS Regression.CodeGen.Generic.2004-04-09-SameValueCoalescing: FAIL , expected PASS Regression.Transforms.PRE.basictest : FAIL
2004 Jun 20
0
[LLVMdev] llvm test results for FreeBSD platform
Thanks Vladimir. That's great! Glad you got it working. BTW, the failures you're seeing have been experienced by Chris and I as well. Chris is diligently working on making the LLVM processing more consistent so he track down the problem. A week ago or so, these tests passed at 100%. Reid. On Sun, 2004-06-20 at 15:50, Vladimir Merzliakov wrote: > In attached file. > > Vladimir
2004 Jun 21
0
[LLVMdev] llvm test results for FreeBSD platform
On Mon, 21 Jun 2004, Vladimir Merzliakov wrote: > Is it ok sending this results for FreeBSD5.1 at daily/weekly based to this > mail list? A better list for it would be the llvmbugs list for now. I beginning to think that we need a new test results mailing list. We have 3 instances of the nightly tester going now (x86/linux, sparc, ppc) and may have more in the future. The nightly tester
2004 May 25
1
[LLVMdev] ATTENTION: SymbolTable Change!!
LLVMers, On the way to resolving bug 122, I am committing my SymbolTable rewrite. If you are working on anything that uses the SymbolTable, I suggest you read the documentation in include/llvm/SymbolTable.h. The changes I've committed reduce the use of Type::TypeTy. This static member will go away in the future, so please do not propagate new code that uses it. There is no reason to use it
2013 May 31
4
[LLVMdev] [POLLY] fix Bug 15817
The attached patch eliminates http://llvm.org/bugs/show_bug.cgi?id=15817 by removing the remaining "; XFAIL:*" added in http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130415/171812.html. The Isl/CodeGen/scevcodegen-1.ll testcase in polly appears as an XPASS in current llvm/polly 3.3 and trunk svn for both x86_64-apple-darwin* and x86_64 Fedora 15 when built against isl
2013 May 31
2
[LLVMdev] [POLLY] fix Bug 15817
On 05/31/2013 10:11 AM, Sebastian Pop wrote: > Sebastian Pop wrote: >> Sebastian Pop wrote: >>> Jack Howarth wrote: >>>> The attached patch eliminates http://llvm.org/bugs/show_bug.cgi?id=15817 by removing the remaining >>>> "; XFAIL:*" added in http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130415/171812.html. >>>>
2013 Jun 05
2
[LLVMdev] [POLLY] fix Bug 15817
On 05/31/2013 01:09 PM, Jack Howarth wrote: > On Fri, May 31, 2013 at 10:59:52AM -0700, Tobias Grosser wrote: >> On 05/31/2013 10:11 AM, Sebastian Pop wrote: >>> Sebastian Pop wrote: >>>> Sebastian Pop wrote: >>>>> Jack Howarth wrote: >>>>>> The attached patch eliminates http://llvm.org/bugs/show_bug.cgi?id=15817 by removing the
2009 Sep 02
1
[LLVMdev] XPASS forAsmBlocksComplexJumpTarget.c (-fasm-blocks)
Building r80796 of the "release_26" branch on Ubuntu 9.04, I'm getting an XPASS on: ssen at ssen:~/llvm/build$ make TESTONE=FrontendC/2009-08-11- AsmBlocksComplexJumpTarget.c check-one make[1]: Entering directory `/home/ssen/llvm/build/test' Making a new site.exp file... XPASS: /home/ssen/llvm/test/FrontendC/2009-08-11- AsmBlocksComplexJumpTarget.c make[1]: Leaving directory
2013 Jun 05
2
[LLVMdev] [POLLY] fix Bug 15817
On Wed, Jun 05, 2013 at 08:47:03AM -0400, Jack Howarth wrote: > On Tue, Jun 04, 2013 at 11:51:31PM -0700, Tobias Grosser wrote: > > On 05/31/2013 01:09 PM, Jack Howarth wrote: > >> On Fri, May 31, 2013 at 10:59:52AM -0700, Tobias Grosser wrote: > >>> On 05/31/2013 10:11 AM, Sebastian Pop wrote: > >>>> Sebastian Pop wrote: > >>>>>
2013 May 31
2
[LLVMdev] [POLLY] fix Bug 15817
Sebastian Pop wrote: > Jack Howarth wrote: > > The attached patch eliminates http://llvm.org/bugs/show_bug.cgi?id=15817 by removing the remaining > > "; XFAIL:*" added in http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130415/171812.html. > > The Isl/CodeGen/scevcodegen-1.ll testcase in polly appears as an XPASS in current llvm/polly 3.3 > >
2015 Nov 26
2
Opus 1.1.1 is out!
Hi everyone, After much waiting, Opus 1.1.1 is finally here. The main changes are: - x86 SSE, SSE2 and SSE4.1 optimizations contributed by Cisco, - MIPS optimizations contributed by Imagination Technologies, - ARM Neon optimizations contributed by Linaro and ARM, - many architecture-independent optimizations, - memory footprint reductions, and - several minor bug fixes. The quality of the
2013 May 31
0
[LLVMdev] [POLLY] fix Bug 15817
On Fri, May 31, 2013 at 10:59:52AM -0700, Tobias Grosser wrote: > On 05/31/2013 10:11 AM, Sebastian Pop wrote: >> Sebastian Pop wrote: >>> Sebastian Pop wrote: >>>> Jack Howarth wrote: >>>>> The attached patch eliminates http://llvm.org/bugs/show_bug.cgi?id=15817 by removing the remaining >>>>> "; XFAIL:*" added in
2013 May 18
2
[LLVMdev] Unsupported MCJIT tests on ARM?
On 18 May 2013 09:56, Tim Northover <t.p.northover at gmail.com> wrote: > According to Amara that assertion was a bit of paranoia so we'd know > if someone tried emitting .rel relocations and sending the result > through MCJIT. However, now we routinely re-relocate using explicit > addends so as he says it can probably just be removed. > Hi Tim, Sorry, I saw that thread
2013 May 31
0
[LLVMdev] [POLLY] fix Bug 15817
On 05/31/2013 06:02 AM, Jack Howarth wrote: > The attached patch eliminates http://llvm.org/bugs/show_bug.cgi?id=15817 by removing the remaining > "; XFAIL:*" added in http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130415/171812.html. > The Isl/CodeGen/scevcodegen-1.ll testcase in polly appears as an XPASS in current llvm/polly 3.3 > and trunk svn for both
2013 Jun 05
0
[LLVMdev] [POLLY] fix Bug 15817
On Tue, Jun 04, 2013 at 11:51:31PM -0700, Tobias Grosser wrote: > On 05/31/2013 01:09 PM, Jack Howarth wrote: >> On Fri, May 31, 2013 at 10:59:52AM -0700, Tobias Grosser wrote: >>> On 05/31/2013 10:11 AM, Sebastian Pop wrote: >>>> Sebastian Pop wrote: >>>>> Sebastian Pop wrote: >>>>>> Jack Howarth wrote: >>>>>>>
2009 Feb 25
0
[LLVMdev] [PATCH] Parallelized make check
On Wed, Feb 25, 2009 at 10:26:02AM -0800, Chris Lattner wrote: > > On Feb 24, 2009, at 10:03 PM, Julien Lerouge wrote: > > > On Tue, Feb 24, 2009 at 06:24:17PM -0800, Julien Lerouge wrote: > >> I haven't tested with objdir != srcdir. > > > > Ok, that was broken. Attached is a smaller diff that should work in > > all > > cases. > > This
2017 Jan 28
2
make check error (opus 1.1.4)
Hi I am not sure if this issue has been resolved, but on the latest opus 1.1.4, * I downloaded the tarball, * ran ./configure followed by * make and then * make check Can you please help? Thank you make[3]: Entering directory `/prj/avspw/karthikr/Development/BFamily/Broadcast/SDM845/Opus/opus-1.1.4/doc' doxygen Warning: ignoring unsupported tag
2009 Feb 25
2
[LLVMdev] [PATCH] Parallelized make check
On Feb 24, 2009, at 10:03 PM, Julien Lerouge wrote: > On Tue, Feb 24, 2009 at 06:24:17PM -0800, Julien Lerouge wrote: >> I haven't tested with objdir != srcdir. > > Ok, that was broken. Attached is a smaller diff that should work in > all > cases. This sounds really cool Julien! Two questions: 1) does it preserve the checking that the existing tcl stuff does, which
2013 Jun 06
0
[LLVMdev] [POLLY] fix Bug 15817
On 06/05/2013 06:24 AM, Jack Howarth wrote: > On Wed, Jun 05, 2013 at 08:47:03AM -0400, Jack Howarth wrote: >> On Tue, Jun 04, 2013 at 11:51:31PM -0700, Tobias Grosser wrote: >>> On 05/31/2013 01:09 PM, Jack Howarth wrote: >>>> On Fri, May 31, 2013 at 10:59:52AM -0700, Tobias Grosser wrote: >>>>> On 05/31/2013 10:11 AM, Sebastian Pop wrote:
2017 Jul 24
1
[PATCH] common/mlstdutils: Fix parallel builds of bytes.ml.
From: "Richard W.M. Jones" <rjones@redhat.com> With OCaml < 4.02 when using the alternate Bytes module, this module would be compiled twice during parallel builds, resulting in occasional corruption. The reason for this is that the ocamldep file mentions ‘bytes.cmo’ whereas the ‘$(OCAML_BYTES_COMPAT_ML)’ macro expands to ‘../../common/mlstdutils/bytes.ml’. Make doesn't