similar to: [LLVMdev] Regression on <4 x i1>?

Duncan, could this be related to your recent work? Chuck, this is unlikely to be a x86 specific problem. Please file a bug. Thanks! Evan On Dec 6, 2007, at 5:06 PM, Chuck Rose III wrote: > Hola LLVMers, > > One of the corner-case features of the Hydra language I work on are > Boolean vectors of length 2, 3, or 4 which I’ve been representing as > either <2 x i1> or

Dear LLVM members. I am compiling coreutils-7.4 package for ARM linux using LLVM 2.5 version. When i compiled 'od' program in coreutils package using LLVM 2.5, i could see the error message on llc processing. > llvm-gcc -emit-llvm ./od.c -c -o ./od.bc -other-options... > llc -march=arm ./od.bc -f -o ./od.s llc:

Unlike llvm itself, llvm-gcc needs to be configured for a particular target architecture. It looks like you're using a copy of llvm-gcc that was built to generate x86 code. On Sep 30, 2009, at 6:27 AM, Jin Gu Kang wrote: > Dear LLVM members. > > I am compiling coreutils-7.4 package for ARM linux using LLVM 2.5 > version. > > When i compiled 'od' program in

Hi Jin-Gu Kang! It are possible that the problem you are experiencing have already been solved in the current llvm 2.6 release tree and the current svn trunk. So try using llc from llvm 2.6 release branch or llvm pre2.7 svn trunk! It would be helpful if you could open a bugreport for this issue and attach the problematic od.bc since we need a testcase from the bitcode that exposes the bug inorder

Hi Bob! I could not find llvm file for ARM target in llvm-gcc 4.2 front end source code. $llvm-gcc-src/gcc/config.gcc file alpha*-*-*) cpu_type=alpha need_64bit_hwint=yes # LLVM LOCAL begin out_cxx_file=alpha/llvm-alpha.cpp # LLVM LOCAL end ;; ... arm*-*-*) cpu_type=arm extra_headers="mmintrin.h" ;; ... i[34567]86-*-*) cpu_type=i386 # LLVM LOCAL begin

That is from 2.5, and just because there is nothing special listed in config.gcc does not mean it doesn't work. For 2.5, the ARM port of llvm-gcc did not require a separate llvm-arm.cpp source file, so nothing needed to be added to config.gcc. It worked fine as far as I know. For 2.6, you will see that there are some ARM-related changes to config.gcc in llvm-gcc. On Sep 30, 2009,

On Apr 21, 2007, at 6:12 PM, Reid Spencer wrote: > On Sat, 2007-04-21 at 18:07 -0500, Christopher Lamb wrote: >> I'm getting a regression after my fixes that's coming from >> getABIAlignment not finding an alignment to use for a <float x1> >> type, >> is this a bug? > > It could be. <float x 1> isn't a useful vector so it probably

On Sat, 2007-04-21 at 18:28 -0500, Christopher Lamb wrote: > On Apr 21, 2007, at 6:12 PM, Reid Spencer wrote: > > > On Sat, 2007-04-21 at 18:07 -0500, Christopher Lamb wrote: > >> I'm getting a regression after my fixes that's coming from > >> getABIAlignment not finding an alignment to use for a <float x1> > >> type, > >> is this a

Hello, I noticed a bit of a gap in the current code for unions: a ConstantUnion cannot be written out to .ll. Hopefully I'm not stepping on Talin's toes by posting this, it's a fairly straightforward adaptation of the code for structs just above. Tim. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. --------------

Hi all, I'm fiddling around a bit with programmatically created GEP instructions, which is failing when using i64 for any indix, except the first. The reason behind this, is that StructureType::indexValid only accepts Value* that are constant ints of width 32. I can't really see why this limitation is here. SequentialType solves this slightly differently, it allows for both 32 and 64

Hi all, I just found that TargetData also contains a similar assert, and that I forgot a "return" in my previous patch. Here's an updated patch, which allows to use any integer to index a CompositeType. It seems this enables GEP to work with any integer value as well, I tested indexing a struct with a i16 an i64 (also through llc). This should still be adressed somewhere, unless we

Hi all, any comments about this patch? I'd like to get it out of my working copy :-) Gr. Matthijs > Index: lib/VMCore/Type.cpp > =================================================================== > --- lib/VMCore/Type.cpp (revision 53136) > +++ lib/VMCore/Type.cpp (working copy) > @@ -394,9 +394,8 @@ > > bool StructType::indexValid(const Value *V) const { >

On Mon, 22 May 2017, Dr. ERDI Gergo wrote: > Actually, tracking down the sequence of function calls, it turns out that '8' > is ultimately coming from the following call in DataLayout::getAlignment: > > getAlignmentInfo(AGGREGATE_ALIGN, 0, abi_or_pref, Ty); > > this seems to return 8 with the following datalayout string: > >

On Mon, Mar 15, 2010 at 11:51:47AM +0000, Tim Northover wrote: > Hello, > > I noticed a bit of a gap in the current code for unions: a > ConstantUnion cannot be written out to .ll. I've been continuing plugging gaps as I find them, which might not be the best way to solve this problem, but it has produced something that seems to do roughly what I expect. I've split it into

All, I should have chimed in earlier, but have been working on two more side-channel variants of this conversation. At the beginning the PNaCl team was strongly pushing for trying to keep platform ABI compatibility on all platforms while taking one portable bitcode stream as input. During the discussions we've had over the past few weeks it became obvious that that is simply not tractable,

I'm in the process of teaching the Verifier to validate that the size of debug info variable and the described value matches (already caught a couple of bugs, both in my frontend and in LLVM itself). However, I've run into the following: size of passed value (80) does not match size of declared variable (128) call void @llvm.dbg.declare(metadata x86_fp80* %x, metadata !11, metadata

Hi! Has made as is said in Printing Support in Samba 2.2.x #rpcclient hydra -U root%******** -c "enumprinters" Domain = [AZCHER] OS = [Unix] Server = [Samba 2.2.2] flags: [0x800000] name: [\\ HYDRA\fax] description: [HYDRA \\ HYDRA\fax,] comment: [] flags: [0x800000] name: [\\ HYDRA\PrintServer] description: [HYDRA \\

We have this situation: System A (running openSUSE 11.0 with samba-3.2.3-0.1) exports user home shares (e.g. for user sledz). On system B (running openSUSE 11.0 with samba-3.2.3-0.1) user hydra mounts the home share from sledz at system A with this command: sudo mount -t cifs -o user=sledz,uid=hydra //A/sledz localdir A subdir of this directory seen from A looks like this: sledz@A> ls

That was essentially part of my question. The DWARF standard says: If the value of an object of the given type does not fully occupy the > storage described by a byte size attribute, the base type entry may also > have a DW_AT_bit_size and a DW_AT_data_bit_offset attribute, both of whose > values are integer constant values (see Section 2.19). The bit size > attribute describes the

Hi, I've been hacking around something missing in the assemble for the mingw-w64 targets the tfloat variable. I did some research into the llvm sources and did see x86_fp80 which seems to be the same thing. Can we support the .tfloat variable or the alternative ? Or is it under another name? I've tried using .x86_fp80 instead but to no avail. :/ Here is how tfloat is being used in