similar to: [LLVMdev] GCC DejaGNU regressions

I've built a debug build of llvm 2.6, and llvm-gcc 2.6 for arm-elf with --enable-checking=yes. On the attached test case (which is g++.dg/expr/bitfield4.C from the GCC 4.2 testsuite) I get: $ cc1plus bitfield4.ii -emit-llvm-bc -o bitfield4.o -quiet cc1plus: /home/foad/svn/antix/toolchain/branches/w/foad/2757llvm26/toolchain/llvm/llvm-gcc/gcc/llvm-convert.cpp:999: llvm::Value*

On Oct 14, 2008, at 1:54 PM, Eli Friedman wrote: > Maybe... although note that with gcc vector intrinsics, this violates > strict aliasing. gcc does allow you to use a slightly more elaborate > workaround with a union, though. Hum what's your take on this then: /* The Intel API is flexible enough that we must allow aliasing with other vector types, and their scalar

On Oct 14, 2008, at 4:30 PM, Mike Stump wrote: > On Oct 14, 2008, at 1:54 PM, Eli Friedman wrote: >> Maybe... although note that with gcc vector intrinsics, this violates >> strict aliasing. gcc does allow you to use a slightly more elaborate >> workaround with a union, though. > > Hum what's your take on this then: > > /* The Intel API is flexible enough

Hi there, I've recently encountered a piece of code that uses some SSE2 intrinsics and builds with gcc46, but not clang: clang can't find _mm_movpi64_epi64(), while gcc46 defines it in its lib/gcc46/gcc/.../4.6.3/include/emmintrin.h: extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__, __artificial__)) _mm_movpi64_epi64 (__m64 __A) { return _mm_set_epi64

On Oct 14, 2008, at 5:41 PM, Chris Lattner wrote: > On Oct 14, 2008, at 4:30 PM, Mike Stump wrote: >> On Oct 14, 2008, at 1:54 PM, Eli Friedman wrote: >>> Maybe... although note that with gcc vector intrinsics, this >>> violates >>> strict aliasing. gcc does allow you to use a slightly more >>> elaborate >>> workaround with a union,

I've finished adding the -rundejagnu option to the nightly tester script, which was the last step to fully support Dejagnu. I think now is the appropriate time to discuss keeping QMTest or switching to Dejagnu. A lot of work went into using QMTest, so I think we should make this decision carefully and before the 1.4 release. Here are the pros and cons in my eyes, please feel free to add your

Tanya Lattner wrote: > I've finished adding the -rundejagnu option to the nightly tester script, > which was the last step to fully support Dejagnu. I think now is the > appropriate time to discuss keeping QMTest or switching to Dejagnu. A lot > of work went into using QMTest, so I think we should make this decision > carefully and before the 1.4 release. > > Here are the

Hello, Nicolas > Thanks a lot for the heads up. I hadn't run into any problems yet with my > hack because I haven't used other callee-saved registers so far. Anyway, I'm > looking forward to your fix! I've commited the first series of patches to ToT to unbreak win64, basically: 1. Honour register save area 2. Enable proper passing of __m128 and __m64 arguments 3. Minor

On Dec 28, 2010, at 4:02 PM, drizzle drizzle wrote: > Hi > Is there a way to enforce a different alignment on vales on stack > as compared to other basic types. Particularly, i would like > characters to be stored at 2 byte boundary. > Check out examples in the lib/Target/* directories. For instance in X86CallingConv.td, we have things like this: def CC_X86_64_C :

Thanks for the answer.. A followup question - Is this already taken into consideration when generating address calculation offset etc or would this need to be specially taken care? I am assuming all load/stores also would need to be custom lowered. thanks dz On Wed, Dec 29, 2010 at 5:45 AM, Bill Wendling <wendling at apple.com> wrote: > On Dec 28, 2010, at 4:02 PM, drizzle drizzle

Hi, I've been giving a look at the archives of the mailing list and I've seen that you have rewritten a lot of functions using mmx to make them faster. I'm currently trying to optimize some code, but I'm have some problems, because I work with 16 bit per component and not 8 like theora. I know that it is off topic, but I'm posting to ask you a little help. I've got

I recently diagnosed a bug in someone else's software, which turned out to be due to incorrect MMX intrinsics usage: if you use any of the x86 intrinsics that accept or return __m64 values, then you, the *programmer* are required to call _mm_empty() before using any x87 floating point instructions or leaving the function. I was aware that this was required at the assembly-level, but not that

On Tue, Oct 14, 2008 at 1:34 PM, Daniel M Gessel <gessel at apple.com> wrote: > In Joe programmer language (i.e. C ;) ), are we basically talking > about disallowing: > > float4 a; > float* ptr_z = &a.z; > > ? That's my reading as well; the argument for not allowing it is just to make optimization easier. We don't allow addressing individual bits either,

On Mon, 2004-11-08 at 00:16, Vladimir Merzliakov wrote: > > I'm asking for people (especially those running nightly testers) to give > > Dejagnu a try. > > I will do. > > But last 2 days (after > http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041101/020279.html ) > LLVM broken at FreeBSD: > > In file included from Path.cpp:27: >

On Mon, 08 Nov 2004 00:29:46 -0800 Reid Spencer <reid at x10sys.com> wrote: > On Mon, 2004-11-08 at 00:16, Vladimir Merzliakov wrote: > > > I'm asking for people (especially those running nightly testers) to give > > > Dejagnu a try. > > > > I will do. > > > > But last 2 days (after > >

> I've tested this with srcdir=objdir and srcdir!=objdir, and on both linux > and on sparc. I'd appreciate the help testing this on additional platforms > such as Darwin and FreeBSD. Please let me know if you have any problems or > questions. I check in src==obj case at FreeBSD, files attached. -------------- next part -------------- A non-text attachment was scrubbed...

Hi all, This is just to announce that I have a FreeBSD x86 machine running the test suite more or less continuously: http://kinoko.c.u-tokyo.ac.jp/~builddonkey/ Of note is that it now runs Dejagnu tests. (Thanks, tonic+co!) I'm also tracking CVS breakage (internally, for now). At some later point, I'll make available more real-time information on "is CVS alive and if not,

On Wed, 24 Aug 2005, Michael McCracken wrote: > I'm mostly up to date, but not completely current with CVS. Is this > something that's been fixed recently, or is it a problem on my end? Try rerunning configure. For some reason, configure decided you didn't have runtest/expect. rerun configure, and if it still doesn't work, please send your config.log to llvmbugs. Thx,

OK, that explains it. I probably didn't have runtest installed the last time I ran configure, and re-syncing with CVS also caused it to reconfigure, solving the problem but confusing me. Thanks, -mike On 8/24/05, Chris Lattner <sabre at nondot.org> wrote: > On Wed, 24 Aug 2005, Michael McCracken wrote: > > I'm mostly up to date, but not completely current with CVS. Is this

All passes: # of expected passes 1415 # of expected failures 31 Evan