search for: flt_min

Hi folks, I just "fixed" a bug on ARM LNT regarding lowering of a VMUL.f32 as NEON and not VFP. The former is not IEEE 754 compliant, while the latter is, and that was failing TSVC. The question is: * is this a problem with the test, that shouldn't be expecting values below FLT_MIN, or * is it a bug in the lowering, that should only be lowering to NEON's VMUL when unsafe-math is on, or * neither, and people should disable that when they want correctness? The bugs in question... Possible unsafe maths bug in NEON VMUL.f32 http://llvm.org/bugs/show_bug.cgi?id=15546 Mult...

...gt; I just "fixed" a bug on ARM LNT regarding lowering of a VMUL.f32 as NEON and not VFP. The former is not IEEE 754 compliant, while the latter is, and that was failing TSVC. > > The question is: > * is this a problem with the test, that shouldn't be expecting values below FLT_MIN, or > * is it a bug in the lowering, that should only be lowering to NEON's VMUL when unsafe-math is on, or > * neither, and people should disable that when they want correctness? > > The bugs in question... > > Possible unsafe maths bug in NEON VMUL.f32 > http://llvm.o...

#include <float.h> should define DBL_MIN and FLT_MIN, as well as DBL_MIN_EXP and FLT_MIN_EXP (such that 10eFLT_MIN_EXP is a valid float) This is a standard header file. But gcc now hides it away (mine was in /usr/lib/gcc-lib/i386-linux/<compiler-version>/include/ ) BTW - any corrections for my surf.chimie.uqam.ca/~kruus/vorbis/ stuff? Erik...

Hi, | The question is: | * is this a problem with the test, that shouldn't be expecting values below FLT_MIN, or | * is it a bug in the lowering, that should only be lowering to NEON's VMUL when unsafe-math is on, or | * neither, and people should disable that when they want correctness? Note that if you go for the second option, IMO unsafe-math is _far_ too "aggressive" an option to contro...

Hi, I was doing some speed and compression comparisons with various apodization/windowing functions, and found out that the definitions for the bartlett and bartlett_hann window in the FLAC codebase have been wrong since their introduction. The attached patch fixes that. Furthermore, I found some peculiar behaviour of the gauss apodization that seems to expose bug. Using different windows

A reworked version of 3 out of 4 patches mentioned earlier. [1/4]: Fixes nearly all piglit vertprog testcases, due to now being able to pass the results on to the fragment shader. V2: rename samplers to texcoords. [2/4]: Fixes shader compiler assertion errors, as some source registers do not exist for certain operations. Fixes several piglit tests when mesa is compiled with --enable-debug [3/4]:

If we compare the "common" subdirectory between nbdkit @ 6b4178d0fdfe ("ci: Temporarily disable perl in MacOS", 2023-02-27) and libnbd @ d05cd8f384a7 ("Version 1.15.11.", 2023-02-28), we find differences. We can categorize these differences along two (orthogonal) axes: - Intentional or unintentional. Intentional differences are for example when one of the libnbd

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Perhaps there was a day when those were different, but that day is not today. src/gallium/drivers/nouveau/nv30/nv30_context.c | 1 - src/gallium/drivers/nouveau/nv30/nv30_context.h | 1 - src/gallium/drivers/nouveau/nv30/nvfx_fragprog.c | 20 ++++++++++---------- src/gallium/drivers/nouveau/nv30/nvfx_vertprog.c | 8 ++++---- 4