search for: _alloca

>Win95. Unfortunately, the encoder_example segfaults. I get the same >results from Cygwin as well. Problem solved! (Or rather, worked around...) The problem with the segfault appears to have indeed been with alloca. There is a function _alloca in libgcc.a that comes with the mingw32 distribution of gcc-2.95.2. After examining the generated assembly code from envelope.c (and others), I found that when I left the #define alloca(x) (_alloca(x)) in os.h, it would link to this function. If you #ifdef the define out, it would simply subt...

Hello, Scott. > Checking the assembly from llc, the first alloca call is to allocate > local vars in _main. Is this just the state of the code at 2.0 when > built with vs.net, or is there something that I've managed to > mis-build locally? _alloca is used to probe the stack, if you asks for locals of size more that 4k. This is pretty ugly, but the names of this functions differs for mingw32 variant (_alloca) and something like chkstk (vcpp). For mingw32 it's exported in libgcc, dunno about vcpp (probably from some runtime libraries). S...

...uilt with mingw I guess) to compile a .c file that is my language runtime, llvm-link'ing that with my frontend's .ll, and using an vcpp-built lli to run the resulting bytecode. This caused the special case in X86RegisterInfo::emitPrologue for "main" to try to align the stack using _alloca which caused the problem, because it felt that target was CygMing. Hacking the output of llvc-gcc from target triple="mingw32" to "win32" makes it "work". Is that generally dangerous, or should it be OK? I suppose I'll have to battle with msys/bison/m4 again, but t...

...ess) to compile a .c > file that is my language runtime, llvm-link'ing that with my frontend's .ll, > and using an vcpp-built lli to run the resulting bytecode. This caused the > special case in X86RegisterInfo::emitPrologue for "main" to try to align the > stack using _alloca which caused the problem, because it felt that target > was CygMing. Hacking the output of llvc-gcc from target triple="mingw32" to > "win32" makes it "work". Is that generally dangerous, or should it be OK? I > suppose I'll have to battle with msys/bison/...

Hi When using lli on Win32 (vs.net-built), on any non-trivial code, I get the following abort ERROR: Program used external function '_alloca' which could not be resolved! Checking the assembly from llc, the first alloca call is to allocate local vars in _main. Is this just the state of the code at 2.0 when built with vs.net, or is there something that I've managed to mis-build locally? thanks, scott -------------- next part --...

...c=alloca(order*sizeof(*lpc)); will produce a cast error (not a warning) and I have to change to: float *lpc=(float *)alloca(order*sizeof(*lpc)); The same goes for int* etc.. I've looked in the lcc definition file to see how is declared alloca() and it's like this: void * _alloca(size_t); #define alloca _alloca - The type definition wasn't correct for LCC, so I used the following instead, which should be correct: typedef long long ogg_int64_t; typedef int ogg_int32_t; typedef unsigned int ogg_uint32_t; typedef short ogg_int16_t; Ok, once all tha...

Hello, Chuck. > "Error, Program used external function _alloca which could not be resolved!" I think the problem is the same. But... Cygwin is handled separately, because it's really more unix-like, that e.g. mingw32. Even more, it uses "unix" variant of libSystem. Probably you have to introduce the same hook (as for mingw32 / vcpp) there....

...-- Index: lib/System/Win32/DynamicLibrary.inc =================================================================== --- lib/System/Win32/DynamicLibrary.inc (revision 51993) +++ lib/System/Win32/DynamicLibrary.inc (working copy) @@ -134,6 +134,21 @@ #if defined(__MINGW32__) EXPLICIT_SYMBOL_DEF(_alloca); EXPLICIT_SYMBOL_DEF(__main); + EXPLICIT_SYMBOL_DEF(__ashldi3); + EXPLICIT_SYMBOL_DEF(__ashrdi3); + EXPLICIT_SYMBOL_DEF(__cmpdi2); + EXPLICIT_SYMBOL_DEF(__divdi3); + EXPLICIT_SYMBOL_DEF(__eprintf); + EXPLICIT_SYMBOL_DEF(__fixdfdi); + EXPLICIT_SYMBOL_DEF(__fixsfdi); + E...

-----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: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJSlZK/AAoJEOs4Jb6SI2CwQDcIAKGk45RjPmcu4zwgZslFATk8 0vRxrdNmmfO+kOfd+ugh7AYkxUnD94uWVYn3uIxMu1hBXPAo1H74ItFP9TX9D3qg ELJzCN4DpZt8...

...t;endbit; // } //////////////////////////////////////////////////// 2.) undefined under win32 so define them: #define M_PI (3.14159265359) #define rint(x) (floor((x)+0.5)) // is this correct? 3.) thousands of tons things like that had become double out[winsize/2]; to double *out=(double *) _alloca((winsize/2)*sizeof(double)); 4.) I found different behaviour between gcc and msvc when dividing very small doubles (like 2.13e-312) void _vs_residue_quantize(double *data,double *curve, vorbis_info *vi,int n){ /* The following is temporary, hardwired bullshit *...

...t;endbit; // } //////////////////////////////////////////////////// 2.) undefined under win32 so define them: #define M_PI (3.14159265359) #define rint(x) (floor((x)+0.5)) // is this correct? 3.) thousands of tons things like that had become double out[winsize/2]; to double *out=(double *) _alloca((winsize/2)*sizeof(double)); 4.) I found different behaviour between gcc and msvc when dividing very small doubles (like 2.13e-312) void _vs_residue_quantize(double *data,double *curve, vorbis_info *vi,int n){ /* The following is temporary, hardwired bullshit *...

Hi,I have been trying some different sample rate and bitrate combinations to get a feel for how CELT behaves,too, like Andrew Lentvorski. But I want to use VBR option.I want to ask a question about VBR in CELT codec.Can we use VBR option in CELT ??? "byte_per_packet" variable in code means constant bit rate, does not it ?In this code : bytes_per_packet is constant.len =

The following modification is needed in os.h to compile under C++Builder. It has the alloca prototype in malloc.h. #ifndef __GNUC__ #ifdef _WIN32 # ifdef __BORLANDC__ # include <malloc.h> # else # define alloca(x) (_alloca(x)) # endif # define rint(x) (floor((x)+0.5)) #endif #endif Encoding a full range pure tone (500Hz) seems to cause a domain error in sqrt(). Can anyone confirm that under Linux? Chris --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/

The following block in os.h needs to be changed for vorbis to work under Borland: Original: #ifndef __GNUC__ #ifdef _WIN32 # define alloca(x) (_alloca(x)) # define rint(x) (floor((x)+0.5)) #endif #endif New: #ifndef __GNUC__ #ifdef _WIN32 # ifdef __BORLANDC__ # include <malloc.h> # else # define alloca(x) (_alloca(x)) # endif # define rint(x) (floor((x)+0.5)) #endif #endif Sqrt domain errors still occur when encoding a fu...

...No such file: No such file or directory Normally crt*.o files are built during normal gcc build process (llvm-gcc as well). However, mingw32 runtime has its own crt*.o files, which are included with binary distribution of llvm-gcc4 (mingw32 variant). > ERROR: Program used external function '_alloca' which could not be resolved! Right. _alloca is inside runtime code, not bytecode. lli was not touched to get mingw32 compatibility. I'll take a look. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

...eveal their location. There is a crtend.c file however and some other static libraries with crt in their names. I figured that just copying the mingw crt*.o files would not be a good idea. Perhaps I downloaded an incomplete llvm gcc binary? > > ERROR: Program used external function '_alloca' which could not be resolved! > /Right. _alloca is inside runtime code, not bytecode. lli was not touched to get mingw32 compatibility. I'll take a look. /I figured as much. It would be great to get the mingw branch on windows working, since it avoids the cygwin dll and some restri...

...tml> post. However, I am getting several "undefined symbol" linking errors that do not make sense to me. According to the error message, these all appear to be part of mdct.obj. But looking at the code in mdct.c, there is no reference to "alloca". Nor have I defined "USE_ALLOCA" since the TI complier does not support it. Can anyone spot an error on my part, or is this yet another quirk of the CCS4 suite (there have been many). Here's a listing of the console error messages. undefined first referenced symbol in file ---------...

...can't see a scenario > where we would need those routines in compiler-rt. What's the purpose of __chkstk_ms() then, implemented in compiler-rt? 1. LLVM does NOT create calls to __chkstk_ms(); 2. both the MSVC and the MinGW runtime provide their own __chkstk() as well as their own __alloca() routines. --- llvm.c --- int main(int argc) { int stack[1111]; return _alloca(argc); } --- EOF --- Compiled with "-target i386-mingw" this generates the following code (see <https://godbolt.org/z/yPk4Jo>): _main: # @main push ebp mov ebp, esp mov eax, 4...

...__chkstk"; - else { + if (STI.isTargetCygMing()) { + StackProbeSymbol = "___chkstk_ms"; + } else { StackProbeSymbol = "__chkstk"; - isSPUpdateNeeded = true; } } else if (STI.isTargetCygMing()) StackProbeSymbol = "_alloca"; @@ -657,15 +655,15 @@ void X86FrameLowering::emitPrologue(MachineFunction &MF) const { .addReg(X86::EFLAGS, RegState::Define | RegState::Implicit) .setMIFlag(MachineInstr::FrameSetup); - // MSVC x64's __chkstk does not adjust %rsp itself. - // It also does not c...

FYI, I have checked in a few interesting things. One is a speedup to the decoder (about 15% improvement in overall decode time). Another is a new interface to FLAC file metadata. If you're curious look at include/FLAC/metadata.h. It is basically a collection of object manipulation routines and iterators that make it pretty easy to add/edit/delete FLAC metadata in files efficiently. The