similar to: Check for alloca() in <malloc.h> as well as <alloca.h>

On Mon, Sep 14, 2015 at 8:49 PM, Jeroen Ooms <jeroen.ooms at stat.ucla.edu> wrote: > I tested this hypothesis by replacing '__GNUC__ <= 4' with '__GNUC__ > <= 5' and rebuilding R, but this introduces a whole lot of problems > that were not there before. In particular R crashes when using the > graphics device, which it did not without this fix. I found

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 AFAIK, alloca.h is not POSIX. Here's a patch that includes alloca.h only when it's really there. It also includes malloc.h, which is where mingw-w64 defines the alloca() macro, mapping it to gcc __builtin_alloca() or to msvcrt _alloca(). - -- O< ascii ribbon - stop html email! - www.asciiribbon.org -----BEGIN PGP SIGNATURE----- Version:

Dear list, During the last two months, I spent a lot of time trying to remove the following warnings of my package randtoolbox: congruRand.c:180:3: warning: ISO C does not support the 'I64' ms_scanf length modifier [-Wformat=] sscanf(params[0], "%" PRIu64 "\n", &inp_mod); Please see

On Tue, Nov 26, 2013 at 10:35 PM, LRN <lrn1986 at gmail.com> wrote: > AFAIK, alloca.h is not POSIX. Here's a patch that includes alloca.h > only when it's really there. > It also includes malloc.h, which is where mingw-w64 defines the > alloca() macro, mapping it to gcc __builtin_alloca() or to msvcrt > _alloca(). This whole path is only triggered when the compiler is

On Wed, Jan 7, 2015 at 8:00 AM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > > This version includes only minor updates to the tools. I indicated last summer that I was hoping to update GCC from the current version 4.6.3 before the R 3.2.0 release, but this now looks unlikely, unless someone else with experience building it can help. I have been looking into this a bit over

On 2015-01-08 02:31, Duncan Murdoch wrote: > On 07/01/2015 5:20 PM, Jeroen Ooms wrote: >> On Wed, Jan 7, 2015 at 8:00 AM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: >>> >>> This version includes only minor updates to the tools. I indicated last summer that I was hoping to update GCC from the current version 4.6.3 before the R 3.2.0 release, but this now

On Fri, Jan 9, 2015 at 12:19 PM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > On 09/01/2015 10:56 AM, Henric Winell wrote: >> On 2015-01-08 02:31, Duncan Murdoch wrote: >> >>> On 07/01/2015 5:20 PM, Jeroen Ooms wrote: >>>> On Wed, Jan 7, 2015 at 8:00 AM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: >>>>>

Dale Johannesen wrote: > On Oct 6, 2007, at 9:14 AM, Jon Sargeant wrote: > >> If <NumElements> is zero, what is the behavior of malloc() and >> alloca()? >> Can I call free() using the pointer that malloc() returns? > > alloca is not standard. > The behavior of malloc is covered in 7.20.3p1: > > If the size of the space requested is zero, the

On 07/01/2015 5:20 PM, Jeroen Ooms wrote: > On Wed, Jan 7, 2015 at 8:00 AM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: >> >> This version includes only minor updates to the tools. I indicated last summer that I was hoping to update GCC from the current version 4.6.3 before the R 3.2.0 release, but this now looks unlikely, unless someone else with experience building

According to the LLVM manual, for both malloc and alloca: "If a constant alignment is specified, the value result of the allocation is guaranteed to be aligned to at least that boundary. If not specified, or if zero, the target can choose to align the allocation on any convenient boundary." I don't see the rationale for the second sentence, because it means that alloca and malloc

Matt Giuca wrote: > OK thanks for the replies. > > Yes, I was planning to use a garbage collector. This is for a > functional language, so there's no real way to determine when memory > needs to be freed without one. > >> Firstly, the pointer has to not make it into any function call at all, since any function might in turn call free(). Then we need to do escape

On Oct 6, 2007, at 9:14 AM, Jon Sargeant wrote: > If <NumElements> is zero, what is the behavior of malloc() and > alloca()? > Can I call free() using the pointer that malloc() returns? alloca is not standard. The behavior of malloc is covered in 7.20.3p1: If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or

I'm trying to determine what is the best approach to using AllocA. Currently I just allocate all my variables at the beginning of the function but wondering if they should rather be done closer to the scope they are used. This would also require a way to do a free on the allocated structure, but there doesn't appear to be such a function. Is it the intent that all stack variables are

On 03/04/2016 9:44 PM, Ray Donnelly wrote: > Hi, > > Apologies for breaking the threading on this, I've only just signed up to > the list and the last email was from September 2015. > > I've started to look into building R for Windows using MSYS2 as both the > build environment and tools + libraries provider (where possible). I've > managed to get the testsuite

Hi John, In my setup OBJDIR is SRCDIR. I'm looking at the config.h and not config.h.in. Yes, defining HAVE_ALLOCA_H to 1 fixed the compilation. Moreover, I also defined HAVE_ALLOCA to 1 in the config.h: -------------------- /* Define to 1 if you have `alloca', as a function or macro. */ /* #undef HAVE_ALLOCA */ #define HAVE_ALLOCA 1 /*Henrik:*/ /* Define to 1 if you have

We don't have any such optimization. Firstly, the pointer has to not make it into any function call at all, since any function might in turn call free(). Then we need to do escape analysis as you pointed out, but that's not difficult. We do similar analysis to determine pointer capture already. Matt Giuca wrote: > I have a compiler which generates a lot of malloc instructions for

Hi As shown below, the .\configure script found a version of alloca(): --------------------- configure:20831: checking for working alloca.h configure:20853: gcc -o conftest -g -O2 conftest.c -ldl >&5 configure:20856: $? = 0 configure:20859: test -s conftest configure:20862: $? = 0 configure:20873: result: yes configure:20883: checking for alloca configure:20925: gcc -o conftest -g -O2

The r.dll crash is easy - you need to be using gcc-ar for ar, and gcc-ranlib for ranlib. I also posted a patch to fix the check failure for stack probing, as lto optimizes away the stack probing code, as it should. yes, lto build's speed gain is very impressive. ------------------------------ On Thu, Jan 8, 2015 2:01 PM GMT Henric Winell wrote: >On 2015-01-08 14:18, Avraham Adler

If <NumElements> is zero, what is the behavior of malloc() and alloca()? Can I call free() using the pointer that malloc() returns? Also, I'm assuming that free()ing a null pointer is a legal NOP? Regards, Jon

> On Mon, 2003-06-16 at 17:33, John Criswell wrote: > > What would be better yet is to modify the code so that it does not use > > alloca() at all. There seems to be little reason to use it aside from > > convenience (but perhaps I have missed something). > > I think the idea is that alloca can give (probably significant) > performance gains when used properly.