similar to: non-standard alloca.h

Full_Name: Rainer Hurling Version: R-2.1.0 OS: FreeBSD6-CURRENT from May 19 2005 Submission from: (NULL) (213.54.77.26) /configure does well in FreeBSD6-CURRENT. When typing 'make' after a while I get: ------------------------------------- [...snip...] gcc -export-dynamic -L/usr/local/lib -o R.bin Rmain.o CConverters.o CommandLineArgs.o Rdynload.o Renviron.o RNG.o apply.o

Dear R-users, is there anyone else with problems to get R-2.1.0 compiled on FreeBSD6-CURRENT? After typing '.configure' and then 'make' I get the following output: ------------------------------------- [...snip...] gcc -export-dynamic -L/usr/local/lib -o R.bin Rmain.o CConverters.o CommandLineArgs.o Rdynload.o Renviron.o RNG.o apply.o arithmetic.o apse.o array.o attrib.o

Dear R-users, is there anyone else with problems to get R-2.1.0 compiled on FreeBSD6-CURRENT? After typing '.configure' and then 'make' I get the following output: ------------------------------------- [...snip...] gcc -export-dynamic -L/usr/local/lib -o R.bin Rmain.o CConverters.o CommandLineArgs.o Rdynload.o Renviron.o RNG.o apply.o arithmetic.o apse.o array.o attrib.o

I downloaded the latest R-2.1.0 tarball from cran (the one of 18/4/05) to compile it under FreeBSD. Take into account that I compiled R-2.0.1 in the same machine and OS like a charme, flawlessly and at the very fiirst shot. Now with R-2.1.0, ./configure doesn't seem to say anything alarming but make stops. Here an extract of both ./configure and make: # ./configure

https://bugzilla.samba.org/show_bug.cgi?id=7015 Summary: Build problems on HP-UX, Tru64 -- alloca, -Wno-unused- parameter Product: rsync Version: 3.0.6 Platform: Other OS/Version: Other Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned at samba.org

NetBSD does not have alloca.h, so CBackend.cpp need to handle NetBSD in the same way as FreeBSD and OpenBSD, as in the attached patch. /Krister -------------- next part -------------- Index: CBackend.cpp =================================================================== --- CBackend.cpp (revision 45865) +++ CBackend.cpp (working copy) @@ -1323,7 +1323,7 @@ static void

Full_Name: Eric van Gyzen Version: 2.1.0 OS: FreeBSD 5.4 Submission from: (NULL) (152.3.22.33) R-2.1.0 fails to compile on the newest release of FreeBSD, complaining about undefined references to __builtin_alloca. On FreeBSD, alloca() is declared in stdlib.h, not alloca.h as the R sources expect. Therefore, HAVE_DECL_ALLOCA does not get set, so the R sources declare alloca() after it has

Interestingly, in the .i file there are 2 __builtin_alloca, and EmitBuiltinAlloca is only being called once. Andrew On 2/16/08, Andrew Lenharth <andrewl at lenharth.org> wrote: > libcpp/charset.c:631 turns into: > > %tmp16 = tail call i64 @strlen( i8* %to ) nounwind readonly > ; <i64> [#uses=1] > %tmp18 = tail call i64 @strlen( i8* %from ) nounwind

Hi, I'm trying to understand how __builtin_setjmp/longjmp are supposed to interact with the frame pointer on x86_64. In particular, what is the expected behavior when the compiler chooses not to use rsp or rbp to address local variables? When built with Clang, the following program will segfault, but it is fine when built with GCC. The target is x86_64 linux. int main(int argc, char

Andrew Lenharth wrote: > Interestingly, in the .i file there are 2 __builtin_alloca, and > EmitBuiltinAlloca is only being called once. > > Hmm, here EmitBuiltinAlloca gets called twice, but it looks like validate_arglist is rejecting the args both times. I have 2 calls to alloca generated: $ grep alloca x.bc|grep call %tmp21 = call i8* @alloca( i64 %tmp20 ) nounwind

On Sat, 11 Sep 2004 13:53:11 -0700 Reid Spencer <reid at x10sys.com> wrote: > On Sat, 2004-09-11 at 12:49, Jeff Cohen wrote: > > > > ===================== MultiSource/Applications/sgefa > > > sgefa is a known XFAIL. See the nightly test results over the last > several months. Actually, you should compare your test results with the > 1.3 release test results

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

libcpp/charset.c:631 turns into: %tmp16 = tail call i64 @strlen( i8* %to ) nounwind readonly ; <i64> [#uses=1] %tmp18 = tail call i64 @strlen( i8* %from ) nounwind readonly ; <i64> [#uses=1] %tmp19 = add i64 %tmp16, 2 ; <i64> [#uses=1] %tmp20 = add i64 %tmp19, %tmp18 ; <i64> [#uses=1] %tmp21 = tail

PR1711 is an x86 codegen problem that is blocking adoption of llvm-gcc by people using linux on x86-64 boxes. Could someone with access to one of these boxes take a look? I'll help try to debug this, but I don't have access to a machine. I bet it's a small tweak required in the x86 backend. Thanks! -Chris

On Sat, 2004-09-11 at 12:49, Jeff Cohen wrote: > For the heck of it I tried upgrading to gcc 3.4.2 (from 3.3.3). It > didn't make a difference. So here are the failures for llvm-test. All > diffs are against the "native" output. > > ===================== MultiSource/Applications/sgefa > > cbe failed differently from jit/llc. First cbe: > > 84c84

See the bug for a reduction and the gimple trees. validate_arglist definately is rejecting the arglist in EmitBuiltinAlloca. (try: bool TreeToLLVM::EmitBuiltinAlloca(tree exp, Value *&Result) { tree arglist = TREE_OPERAND(exp, 1); if (!validate_arglist(arglist, INTEGER_TYPE, VOID_TYPE)) { debug_tree(arglist); return false; } Value *Amt = Emit(TREE_VALUE(arglist), 0); Amt =

This has the advantage of being more efficient than the included routines and allows distros to centralize crypto mainteniance on a few libraries. --- configure.ac | 4 +- m4/ax_check_openssl.m4 | 124 +++++++++++++++++++++++++++++++++++++ src/libFLAC/Makefile.am | 2 +- src/libFLAC/include/private/md5.h | 8 ++- src/libFLAC/md5.c

I have a new problem: Register RBP is used in a function foo. (I am not allocating RBP to any virtual register, the instances of RBP in function foo are in the machine code when my register allocator starts.) Function foo calls function bar. Register RBP is not saved across the call, though it is live after the call. Function bar includes a virtual register. The code that I'm using to

On 11/30/2012 6:36 PM, Lang Hames wrote: > > > RBP is used as the frame pointer on x86 (hence its automatic > appearance in your code), and shouldn't be allocated to any vreg in > function bar. Loading/saving RBP should be managed by the stack frame > setup/teardown code. > If it doesn't already, your allocator should filter out reserved > registers (See