search for: martinwguy

...averickCrunch FPU on the ep9312 armv4t chip, which doesn't handle denormalized values so floats only have a precision of 2^-126 instead of 2^-149, I get 9237 Happy-crunch.ogg (yes, 9k!) All these ARM .oggs decode to files of the correct length containing silence and are visible under http://martinwguy/co/uk/martin/libvorbis Compiling it on a system with a VFP FPU and appropriate flags instead seems to produce a working encoder. Following the idea that it's precision-related, I recompiled -Dfloat=double and got something non-silent and recognizable but garbled. It sounds like a filtered noi...

Hi, This mozilla bug report is a crash triggered by a Vorbis file with corrupt headers: https://bugzilla.mozilla.org/show_bug.cgi?id=481601 The patch to fix the crash adds a new vorbis_dsp_init() function to libvorbis, and calls that from fs_vorbis_init() in libfishsound: https://bug481601.bugzilla.mozilla.org/attachment.cgi?id=366150 The public function it adds is: void

Hi The fix is very simple: the defaulting of this macro to 0 in gcc/config/arm/arm.h, present in 2.2 has been omitted in 2.5. The attached patch puts the defaulting clause back, the same as it was in 2.2 M -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-arm-default-MACHO_DYNAMIC_NO_PIC_P.patch Type: text/x-diff Size: 385 bytes Desc: not available

Thanks. Do you have fixes for the other ARM bloopers? This is the forthcoming Debian version and it's now dying on arm-gnueabi when it links cc2-dummy saying libbackend.a(arm.o): In function `current_file_function_operand': /home/martin/arm/llvm-gcc-4.2-2.5/build-gcc/gcc/../../llvm-gcc-4.2-2.5/gcc/config/arm/arm.c:3506: undefined reference to `ENCODED_SHORT_CALL_ATTR_P'

A related question: GCC does the same for 64-bit args in two 32-bit registers, but always uses (Rn, Rn+1) pairs and is incapable of scheduling the two 32-bit move instructions independently, since the two are output at the very last minute by the last part of the machine-dependent backend/ This is slow when moving such a 2x32-bit value to a 64-bit register in one the ARM FPUs, since two 32-bit

> I've tried arm-2008q3-72, > arm-2009 and arm-2010q1-202 from code-sourcery with little success - > arm2010q1 fails to compile, arm-2009 take an age to link and arm-2008q3 > seems to work but only when compiled with -O0. Does anyone have any > advice on the matter? CS's release series is renowned for being bug-ridden. To be fair, this is probably because CS do

On 8/3/09, Anton Korobeynikov <anton at korobeynikov.info> wrote: > > Thanks. Do you have fixes for the other ARM bloopers? This is the > > forthcoming Debian version and it's now dying on arm-gnueabi when it > > links cc1-dummy saying > > Please use the current Top-of-the-Tree version. Sorry, that's not an option as I'm trying to fix the Debian