search for: float_t

...sh Coalson - * - * - * For an explanation of the concepts and the basic algorithms involved, go to: - * http://www.replaygain.org/ - */ - -/* - * Here's the deal. Call - * - * InitGainAnalysis ( long samplefreq ); - * - * to initialize everything. Call - * - * AnalyzeSamples ( const Float_t* left_samples, - * const Float_t* right_samples, - * size_t num_samples, - * int num_channels ); - * - * as many times as you want, with as many or as few samples as you want. - * If mono, pass the sample buffer in...

The replay gain code has dos line endings in CVS, which causes problems for the Sun compiler, among others. Attached is a patch for the lazy, but it's probably easier to fix locally and commit. -r

...trying to build current git on i386, but it fails with the following error: make[3]: Entering directory '/tmp/flac/src/share' CC grabbag/replaygain.lo In file included from grabbag/replaygain.c:38:0: ../../include/share/replaygain_analysis.h:45:15: error: conflicting types for 'float_t' typedef float float_t; /* Type used for filtering */ ^ In file included from /usr/include/math.h:45:0, from grabbag/replaygain.c:25: /usr/include/bits/mathdef.h:35:21: note: previous declaration of 'float_t' was here typedef long double float...

On Thu, Jun 19, 2014 at 07:28:11PM +1000, Erik de Castro Lopo wrote: > Miroslav Lichvar wrote: > > In file included from /usr/include/math.h:45:0, > > from grabbag/replaygain.c:25: > > /usr/include/bits/mathdef.h:35:21: note: previous declaration of 'float_t' was here > > typedef long double float_t; /* `float' expressions are evaluated as > > What distro? What package and what version of the what package installed > that file? Fedora rawhide, glibc-headers-2.19.90-21.fc21.1.i686. Looking at the file in an older Fedora, it doe...

Erik de Castro Lopo wrote: > lvqcl wrote: > > > Some projects/makefiles add both 'include' and 'include/share' > > to the list of additional include directories. > > I think that is suboptimal. > > > For example, src/share/utf8/utf8.c includes 'include/share/alloc.h' > > as "share/alloc.h" but

...annot build 32-bit flac with MinGW: > > <-------------------------------------------------------------> > CC grabbag/replaygain.lo > In file included from grabbag/replaygain.c:38:0: > ../../include/share/replaygain_analysis.h:45:17: error: conflicting types for > 'float_t' > typedef float float_t; /* Type used for filtering */ > ^ > In file included from grabbag/replaygain.c:25:0: > D:/MSYS/mingw/i686-w64-mingw32/include/math.h:329:21: note: previous declaration > of 'float_t' was here > typedef long doub...

...omponents); > @@ -1029,6 +1035,11 @@ builtin_variable_generator::generate_varyings() > "gl_ClipDistance"); > } > > + if (state->is_version(450, 0) || state->ARB_cull_distance_enable) { > + ADD_VARYING(VARYING_SLOT_CULL_DIST0, array(float_t, 0), > + "gl_CullDistance"); > + } > + > if (compatibility) { > ADD_VARYING(VARYING_SLOT_TEX0, array(vec4_t, 0), "gl_TexCoord"); > ADD_VARYING(VARYING_SLOT_FOGC, float_t, "gl_FogFragCoord"); > diff --git a/src/...

...> +#define MAX_SAMPLES_PER_WINDOW (size_t) (2401) >> +#define UINT32_T_FORTE 12000.0 /* Used in Unit32_t code below. */ >> +#endif >> #define PINK_REF 64.82 /* 298640883795 */ >> /* calibration value */ >> >> static Float_t linprebuf [MAX_ORDER * 2]; >> @@ -142,8 +149,13 @@ >> static double lsum; >> static double rsum; >> static int freqindex; >> +#ifndef __sun >> static Uint32_t A [(size_t)(STEPS_per_dB * MAX_dB)]; >> static Uin...

...des on a per function or code block granularity.) > > and i don't think it's a good idea to change FLT_EVAL_METHOD with non-precise > arithmetic modes, because it is used to decide if excess range and precision is > available, but arithmetic changes don't affect that. (e.g. float_t is still same as > float). > > > > > > > Thanks in advance for any opinions and suggestions. > > > > -Andy > > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > https...

...change the other modes on a per function or code block granularity.) and i don't think it's a good idea to change FLT_EVAL_METHOD with non-precise arithmetic modes, because it is used to decide if excess range and precision is available, but arithmetic changes don't affect that. (e.g. float_t is still same as float). > > > Thanks in advance for any opinions and suggestions. > > -Andy > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Hi all, I'm trying to put together a set of rules for how the various floating point semantic modes should be handled in clang. A lot of this information will be relevant to other front ends, but the details are necessarily bound to a front end implementation so I'm framing the discussion here in terms of clang. Other front ends can choose to follow clang or not. The existence of this set

This patch series adds the needed support for this extension to the various parts of mesa to finally enable it for nvc0. Dave Airlie (1): glsl: lower cull_distance into cull_distance_mesa Tobias Klausmann (10): glapi: add GL_ARB_cull_distance mesa/main: add support for GL_ARB_cull_distance mesa/prog: Add varyings for arb_cull_distance mesa/st: add support for GL_ARB_cull_distance

Hi Ulrich, I am interested in knowing if the current proposals also take into account the FP_CONTRACT pragma and the ability to implement options that imply a specific value for the FLT_EVAL_METHOD macro. Additionally, I am not aware of the IR being able to represent the potentially deferred loss of precision that the C language semantics provide; in particular, applying such semantics to the

Hello, at the recent EuroLLVM developer meeting in Bristol I held a BoF session on the topic "Towards implementing #pragma STDC FENV_ACCESS". I've also had a number of follow-on discussions both on-site in Bristol and online since. This post is intended as a summary of my current understanding set of requirements and implementation details covering the overall topic. I'm