similar to: [LLVMdev] 2.6 request - Bug 4879

On Sep 7, 2009, at 2:27 PM, Michael Lyle wrote: First-- thanks to Daniel Dunbar for reporting this issue from my > earlier coarse report on IRC and to Devang Patel for fixing it. > > I'm writing to request that this fix (r81058) find its way into the > 2.6 release. Code compiled with clang that uses VLAs is horribly > broken without r81058 (at least on x86-64). I don't

On Sep 7, 2009, at 9:19 PM, Chris Lattner wrote: > On Sep 7, 2009, at 2:27 PM, Michael Lyle wrote: > First-- thanks to Daniel Dunbar for reporting this issue from my >> earlier coarse report on IRC and to Devang Patel for fixing it. >> >> I'm writing to request that this fix (r81058) find its way into the >> 2.6 release. Code compiled with clang that uses VLAs

On Sep 8, 2009, at 2:53 PM, Chris Lattner wrote: > > On Sep 8, 2009, at 2:05 PM, Tanya Lattner wrote: >> This can not go into 2.6, because r79742 is not in 2.6: >> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090817/085284.html >> >> Should this really be a release candidate? Its changing quite a bit >> and its not causing a regression. >

On Sep 8, 2009, at 3:01 PM, Devang Patel wrote: > > On Sep 8, 2009, at 2:53 PM, Chris Lattner wrote: > >> >> On Sep 8, 2009, at 2:05 PM, Tanya Lattner wrote: >>> This can not go into 2.6, because r79742 is not in 2.6: >>> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090817/085284.html >>> >>> Should this really be a release

On Sep 8, 2009, at 2:05 PM, Tanya Lattner wrote: > This can not go into 2.6, because r79742 is not in 2.6: > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090817/085284.html > > Should this really be a release candidate? Its changing quite a bit > and its not causing a regression. No, the bigger patch should not go into 2.6. Devang, can you please prepare a

I'm not someone who thinks VLAs are automatically bad and unlike Linux kernel code they can sometimes be used safely in userspace. However for an internet exposed server there is an argument that they might cause some kind of exploitable situation especially if the code is compiled without other stack hardening features. Also in highly multithreaded code with limited stack sizes (as nbdkit

Duncan Sands wrote: >> As noted in the GEP FAQ, GEPs don't support variable-length arrays; > > that's not quite right. The problem is only with arrays of variable length > arrays, and more generally with arrays where the element type has variable > size (this occurs with Ada, which has all kinds of funky variable sized types, > for example). You're right, though

Hi Preston, >>> As noted in the GEP FAQ, GEPs don't support variable-length arrays; >> >> that's not quite right. The problem is only with arrays of variable length >> arrays, and more generally with arrays where the element type has variable >> size (this occurs with Ada, which has all kinds of funky variable sized types, >> for example). > >

Hello, Chris > 2010/3/20 Chris Lattner <clattner at apple.com> > > >> On Mar 19, 2010, at 2:40 PM, Louis Gerbarg wrote: >> >> >>> What do you mean by "variable sized pointers"? What does: >>> >>> struct S {void *X; }; >>> >>> return for sizeof(struct S); ? >>> >> >> It doesn't, at

On Fri, Mar 19, 2010 at 3:47 PM, Chris Lattner <clattner at apple.com> wrote: > > On Mar 19, 2010, at 11:08 AM, 琬菁楊 wrote: > > > Hello Tristan and all, > > I have already know that if I want to do this feature(c -> EFI Byte code) > for GCC > I should further modify the GCC front end(parser) to solve the problem (the > size > of pointer is determined at

On Mon, Jan 27, 2020 at 4:31 PM Eli Friedman <efriedma at quicinc.com> wrote: > I assume by “drop support”, you mean reject it in the bitcode reader/IR > parser? We can’t reasonably support a complex feature like inalloca if > nobody is testing it. If we can’t reasonably upgrade it, and we don’t think > there are any users other than clang targeting 32-bit Windows, probably

For a long time we have had code for custom lowering of adjustments to the stack pointer. But until recently we did not realise that we were handling only places that provided a fixed-value for such adjustments, and the ISD nodes 'ADJCALLSTACKDOWN' and 'ADJCALLSTACKUP' are only described in our TableGen descriptions for immediates. This hasn't previous mattered as LLVM

Hi, is there a convenient way to get all allocations popped from the stack by llvm.stackrestore? Is this even decidable at compile time? Thanks Marc

In preparation to enabling -Wvla, remove VLA. In this particular case directly use macro NVKM_MSGQUEUE_CMDLINE_SIZE instead of local variable cmdline_size. Also, remove cmdline_size as it is not actually useful anymore. The use of stack Variable Length Arrays needs to be avoided, as they can be a vector for stack exhaustion, which can be both a runtime bug or a security flaw. Also, in general, as

On 14 March 2018 at 21:08, Thierry Reding <thierry.reding at gmail.com> wrote: > On Tue, Mar 13, 2018 at 11:24:11AM -0500, Gustavo A. R. Silva wrote: >> In preparation to enabling -Wvla, remove VLA. In this particular >> case directly use macro NVKM_MSGQUEUE_CMDLINE_SIZE instead of local >> variable cmdline_size. Also, remove cmdline_size as it is not >> actually

Hi all, the language reference for the alloca instruction states: The ‘alloca‘ instruction allocates memory on the stack frame of the currently executing function, to be automatically released when this function returns to its caller. when using come c code like void myfunc(void){ int i=4; double d[i]; } the ir shows enclosing llvm.stackSave & restore constructs, enclosing the alloca

On Thu, Apr 26, 2018 at 4:25 PM, Kees Cook <keescook at chromium.org> wrote: > On Thu, Mar 15, 2018 at 7:05 PM, Ben Skeggs <skeggsb at gmail.com> wrote: >> On 14 March 2018 at 21:08, Thierry Reding <thierry.reding at gmail.com> wrote: >>> On Tue, Mar 13, 2018 at 11:24:11AM -0500, Gustavo A. R. Silva wrote: >>>> In preparation to enabling -Wvla,

On Sun, Feb 24, 2002 at 09:04:03AM +0100, Ricardo Galli wrote: > Sorry, didn't explain well. > > Nagle's algorithm (rfc896) buffers user data until there is no pending acks > or it can send a full segment (rfc1122). > > icecast doesn't need it at all, because it already sends large buffers and > the time to send the next buffers is relatively very long. IMO

Thanks all. David why do you say it is particularly bad IR (other than not having gone through SROA). Is it the multiple blocks for early returns? That is how I'm supporting early returns in the middle of a basic block. I couldn't find any other way. On Sun, Apr 5, 2015 at 6:24 AM, David Jones <djones at xtreme-eda.com> wrote: > Data point: > > I use (rarely) alloca in

> On Jan 30, 2017, at 6:18 AM, Martin J. O'Riordan via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > For a long time we have had code for custom lowering of adjustments to the stack pointer. But until recently we did not realise that we were handling only places that provided a fixed-value for such adjustments, and the ISD nodes ‘ADJCALLSTACKDOWN’ and ‘ADJCALLSTACKUP’ are