similar to: [LLVMdev] llvm-ld (instruction combine) breaking for this test.

Morten, I've applied these patches. Thanks for the updates! Reid. On Mon, 2004-11-15 at 01:26, Morten Ofstad wrote: > Hi, > > when I updated the sources today there were several small problems that > stopped the windows version from compiling, here are the patches > > m. > > > ______________________________________________________________________ > Index:

Hi, when I updated the sources today there were several small problems that stopped the windows version from compiling, here are the patches m. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: win32patches.txt URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041115/34634455/attachment.txt>

This patch is still not creating elf32_x86_64 objects. No idea why. :( It does however, fix elf_x86_64 (-m64) code generation on x32 hosts which is nice. :) --- ./tools/clang/include/clang/Driver/Options.td.orig 2013-05-16 21:51:51.286129820 +0000 +++ ./tools/clang/include/clang/Driver/Options.td 2013-05-16 21:53:24.875004239 +0000 @@ -841,6 +841,7 @@ HelpText<"Enable hexagon-qdsp6

Clang patch for X32 support. Applies against current trunk. --- ./tools/clang/include/clang/Driver/Options.td.orig 2013-05-16 21:51:51.286129820 +0000 +++ ./tools/clang/include/clang/Driver/Options.td 2013-05-16 21:53:24.875004239 +0000 @@ -841,6 +841,7 @@ HelpText<"Enable hexagon-qdsp6 backward compatibility">; def m3dnowa : Flag<["-"], "m3dnowa">,

Hi all! I gave a shot at compiling core llvm with a Solaris 9 machine. The compiler is FSF gcc 3.4.6. I am building trunk in the release version. So far I did not run tests (no dejagnu installed). Here are my findings: 0) Configuring. I had to suppress the solaris tools by: env AR=/opt/gnu/bin/ar NM=/opt/gnu/bin/nm RANLIB=/opt/gnu/bin/ranlib STRIP=/opt/gnu/bin/strip ../llvm/configure

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 { >

I don't think this is right. According to llvm documentation: The index types specified for the 'getelementptr' instruction depend on the pointer type that is being indexed into. Pointer and array types can use a 32-bit or 64-bit integer type but the value will always be sign extended to 64-bits. Structure and packed structure types require i32 constants. Evan On Jul 10,

Hi, I have a doubt with GEP transformation in the instruction-combiner. Consider below test-case: struct ABC { int A; int B[100]; struct XYZ { int X; int Y[100]; } OBJ; }; void Setup(struct ABC *); int foo(int offset) { struct ABC *Ptr = malloc(sizeof(struct ABC)); Setup(Ptr); return Ptr->OBJ.X + Ptr->OBJ.Y[33]; } Generated IR for the test-case: define i32 @foo(i32

I'm not sure what the usual "ping time" is for llvm-dev, but may I ask if there are any updates on this? It appears that the following lines are the root cause of the reordering (https://github.com/llvm/llvm-project/blob/fdcb27105537f77c78c4473d4f7c47146ddbab69/llvm/lib/Transforms/InstCombine/InstructionCombining.cpp#L2175): // Handle gep(bitcast x) and gep(gep x, 0, 0, 0). Value

I am working on a custom LLVM backend for a 16 bit architecture. For my architecture, I need smaller array alignments for arrays created on the stack. For example, consider the following code at the start of a C function: char localBuff[20]; char localBuff2[6]; this gets converted by Clang into this: %localBuff = alloca [20 x i8], align 16 %localBuff2 = alloca [6 x i8], align 1 Note

Hi, I'm working on bringing up complete coverage for a Gentoo x32 "desktop" system. I've been cooking up quite a few patches for various packages to push upstream, but right now, the biggest blocker is the lack of support for building with/codegen targeting x32 in llvm/clang. Since the x32 patches were sent last year, I see support code has landed in LLVM, and basic handling of

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

Send CentOS-announce mailing list submissions to centos-announce at centos.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request at centos.org You can reach the person managing the list at centos-announce-owner at centos.org When

...even when I do the "factory reset" (4-6-8-* then 456). I tried using FTP and TFTP, but even though the phone uploads the log, I get these errors: 0927211350|app1 |3|00|Time has been set from 0.us.pool.ntp.org(69.60.124.59). 0927211350|cfg |4|00|Could not get all 512 bytes of the header. 0927211351|cfg |4|00|Could not get all 512 bytes of the header. 0927211422|app1 |4|00|Loaded

I have an annoying little issue that perhaps someone can explain to me. I installed zenoss (very cool, http://www.zenoss.org) and things are OK. when I use emacs or when somethings like a cron job execute, I get notice of an error... emacs: /opt/zenoss/lib/libpng12.so.0: no version information available (required by emacs) or /usr/bin/webalizer: /opt/zenoss/lib/libpng12.so.0: no version

Hello, There''s another problem in ld-linux.so (and the a.out linker ld.so, too): it is possible to trick the linker into loading old version of a library if several versions are installed. This means that if you have upgraded your libc (or libdb, etc) after a security hole was discovered, updated /etc/ld.so.cache with ldconfig, and made sure the new version is used, it still might be

Any one seen ld-linux segfault? I just noticed this in the log file today. eth0: link down. eth0: link up. ld-linux-x86-64[32199]: segfault at 34e908ff18 rip 55555555b985 rsp 7fffdf3baf00 error 4 ld-linux-x86-64[32200]: segfault at 34e908ff18 rip 55555555b985 rsp 7fffe65c5c40 error 4 ld-linux-x86-64[32201]: segfault at 34bdb1cb66 rip 55555555cf9c rsp 7fff5c19fa00 error 4 ld-linux-x86-64[32202]:

My polycom phone is now hanging at Running "sip.ld". I modified it's config via the web interface to register with my asterisk box. I have tried to restore the default settings wth 468* and it doesn't seem to work. Any ideas? -jonathan

Hi. I have run across this old problem: http://www.syslinux.org/archives/2010-November/015753.html when compiling 4.05 on an x86_64 RHEL 5.5 systems with nasm v2.10 and GNU ld 2.17.50.0.6-14.el5 20061020. The exact symptom is the linker (ld) improperly loads pxelinux.o, created by nasm, to pxelinux.elf. The pfx_* symbols in the .prefix section end up being filled with 0's in pxelinux.elf.