similar to: [LLVMdev] RegAllocSimple.cpp

Hi Chris, I saw this potential memory leak in RegAllocSimple.cpp. The PhysRegsEverUsed was being allocated but never freed. -bw Index: RegAllocSimple.cpp =================================================================== RCS file: /var/cvs/llvm/llvm/lib/CodeGen/RegAllocSimple.cpp,v retrieving revision 1.66 diff -a -u -r1.66 RegAllocSimple.cpp --- RegAllocSimple.cpp 22 Jan 2006 23:39:54 -0000

Hi Bill, I don't think it's dead code, per se -- AFAIK there are still clients of LLVM which use the shadow stack as part of their garbage collection implementation. HLVM is probably the most visible such project. My own project now has its own GC plugin to emit stack maps, rather than relying on the shadow stack. But for what it's worth, I found the shadow stack to be a useful

Hi, I've been looking at all of the uses of the 'unwind' instruction, and ShadowStackGC.cpp is the last pass which actually creates 'unwind' instructions. The thing is, this pass seems to be dead. It hasn't been updated in any meaningful way since ~79000. Should this pass go the way of the dodo? -bw -------------- next part -------------- A non-text attachment was

The ARM binaries seem to be corrupt. Although correctly signed, the xz file seems to be truncated arm7% unxz < clang+llvm-3.5.0-rc3-armv7a-linux-gnueabihf.tar.xz | wc -c unxz: (stdin): Unexpected end of input 133214381 M.E.O. On Aug 21, 2014, at 10:56 AM, Bill Wendling <isanbard at gmail.com> wrote: > Ahem. And now for the correct URL: > >

On May 25, 2008, at 1:39 PM, Marcel Moolenaar wrote: > On May 25, 2008, at 12:58 AM, Bill Wendling wrote: > >> Could you try this (massively hacky) patch out to see if it fixes >> your >> problem? >> >> > Alas, it didn't fix the problem: > Crumbs. I think that the analysis I told you before wasn't fully correct. I think I mentioned something

Hi, The add.with.overflow instrinsics don't seem to work with constant arguments, i.e. changing the call in add-with-overflow.ll to: %t = call {i32, i1} @llvm.sadd.with.overflow.i32(i32 0, i32 0) causes the following exception when running the codegen tests: llc: DAGCombiner.cpp:646: void<unnamed>::DAGCombiner::Run(llvm::CombineLevel): Assertion `N->getValueType(0) ==

On Nov 6, 2007, at 5:45 PM, Bill Wendling wrote: > $ more testcase.c.t03.generic > Qux () > { > static char C.0[11] = {0}; > char Bar[11]; > > Bar = C.0; > } > > Anyway, it turns out that the gimplifier was generating the correct > alignment, but it was being overridden in assemble_variable(): > > /* On some machines, it is good to increase alignment

FYI: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-October/066389.html Please read and let me know you comments. -bw On Oct 11, 2013, at 2:47 PM, Dmitry Babokin <babokin at gmail.com> wrote: > Looking forward to these changes! Thanks for working on it. > > > On Fri, Oct 11, 2013 at 10:32 PM, Bill Wendling <isanbard at gmail.com> wrote: > Hi Dmitry, > > I

On Nov 6, 2007, at 6:07 PM, Dale Johannesen wrote: > > On Nov 6, 2007, at 5:45 PM, Bill Wendling wrote: >> $ more testcase.c.t03.generic >> Qux () >> { >> static char C.0[11] = {0}; >> char Bar[11]; >> >> Bar = C.0; >> } >> >> Anyway, it turns out that the gimplifier was generating the correct >> alignment, but it was

Yes, this is me. I'll look at this tonight when I have access to a machine. Evan On Jan 27, 2008, at 1:01 AM, Bill Wendling <isanbard at gmail.com> wrote: > Hi all, > > In the last few days, some change introduced an internal compiler > error. On my G4 (PPC), I'm getting this: > > $ cat testcase.i > struct A {}; > struct B { > struct A c[0]; > };

Looking forward to these changes! Thanks for working on it. On Fri, Oct 11, 2013 at 10:32 PM, Bill Wendling <isanbard at gmail.com> wrote: > Hi Dmitry, > > I can try my best, but it would be a bit tricky to get it all finished by > then... > > -bw > > On Oct 11, 2013, at 4:10 AM, Dmitry Babokin <babokin at gmail.com> wrote: > > Bill, > > Are there

Hi all, In the last few days, some change introduced an internal compiler error. On my G4 (PPC), I'm getting this: $ cat testcase.i struct A {}; struct B { struct A c[0]; }; extern const struct B *pB; void bork(void) { const struct A *pA = pB->c; } $ /Users/wendling/llvm/llvm-gcc-4.2.obj/./gcc/xgcc -B/Users/wendling/ llvm/llvm-gcc-4.2.obj/./gcc/ -B/Users/wendling/llvm/llvm-

Applied. Thanks, Zoltan! -bw On Tue, Dec 9, 2008 at 1:12 PM, Zoltan Varga <vargaz at gmail.com> wrote: > Hi, > > Attached is the final version of the patch, adding the requested > FIXME. If this is ok, can > somebody check it in ? > > thanks > > Zoltan > > On Tue, Dec 9, 2008 at 9:58 PM,

I didn't see swapcontext in the list in gcc's special_function_p function... -bw On May 26, 2010, at 2:20 PM, Alistair Lynn wrote: > Hello- > > Shouldn't this catch swapcontext as well? > > Alistair > > On 26 May 2010, at 22:14, Dale Johannesen wrote: > >> >> On May 26, 2010, at 2:05 PMPDT, Dan Gohman wrote: >> >>> vfork and

Hi Marcelo, That should be fixed now at r184239. Sorry about the failure! -bw On Jun 17, 2013, at 6:16 AM, Marcelo Sousa <marceloabsousa at gmail.com> wrote: > Hello, > > I'm getting an error when running opt with what seems to be a valid bytecode file compiled from one the Linux Kernel files. > The error is: > opt: /home/scratch/llvm/lib/IR/Attributes.cpp:119:

Hi Bill, With the latest llvm version I'm getting the following error: opt -instnamer < core-device.c.bc > core-device.o.bc Attribute 'nobuiltin' only applies to functions! void (%struct.fw_csr_iterator*, i32*)* @fw_csr_iterator_init Broken module found, compilation aborted! 0 opt 0x0000000001914bf1 llvm::sys::PrintStackTrace(_IO_FILE*) + 38 1 opt

Hi Bill, I committed a fix already as r355743 [1], and it fixes `test2` as well. I believe we should merge this into 8.0. /Eric [1] https://github.com/llvm/llvm-project/commit/680e865c313a80b6ec329abde61e1f0c66bdc103 On Fri, Mar 8, 2019 at 5:46 PM Bill Wendling <isanbard at gmail.com> wrote: > Hi Eric, > > The attached patch may help matters, though it now fails because

On Tue, Feb 3, 2009 at 2:45 PM, Dale Johannesen <dalej at apple.com> wrote: > > On Feb 3, 2009, at 2:35 PMPST, Mike Stump wrote: > >> On Feb 3, 2009, at 2:28 PM, Kasra wrote: >>> I was looking around the LLVM instruction set and I failed to find >>> ROL and ROR instructions. Is there any plans on adding these >>> instructions to LLVM? >>

The third 3.5 release candidate is now available. Please pick up sources and binaries here: https://llvm.org/pre-release/3.5 Run it through its phases and report any bugs you find! Share and enjoy! -bw

On Sep 24, 2007, at 3:15 PM, Dale Johannesen wrote: > > On Sep 24, 2007, at 3:07 PM, Bill Wendling wrote: > >> A debug or release build? >> >> -bw > > Both, actually. Weird. I see a potential problem, though. The code is like this: void dumpToDOUT(SparseBitVector<> *bitmap) { dump(*bitmap, DOUT); } where dump expects an llvm::OStream& for the