[gdal-dev] Slightly-off failing tests on i686
Greg Troxel
gdt at lexort.com
Wed Oct 29 05:59:53 PDT 2025
yosh via gdal-dev <gdal-dev at lists.osgeo.org> writes:
> I'm currently in the process of updating libgdal for void linux. In the
> process, I actually added the test suite to the package, and it seems to be
> failing on i686/32bit:
>
> https://github.com/void-linux/void-packages/actions/runs/18897850572/job/53938975118?pr=57703#step:7:7606
>
> in case github actions culls this sooner than expected:
> https://0x0.st/K_pP.txt
>
> It seems to be ever so slightly off the expected results for numerical
> stuff. is this known/expected behavior and/or a supported configuration? Mainly
> wondering if it'd be better to skip the tests for i686 or not.
Not 100% diagnosed, but proj tests fail on NetBSD/i386, unless I use
compiler options to limit doubles to exactly IEEE754, instead of the
i387's 80-bit extended floating point registers. I would not be
surprised if this is the same sort of thing.
In particular, one of proj's test seems numerically questionable, using
a coordinate pair to define a rotated projection, but with very small
coordinate differences (1E-8 degrees, IIRC), and this resulted in a 5m
difference on i386. It's on my infinite todo list to propose adjusting
the test to not push the numerical limits so hard -- 1E-8 degrees is
only a mm.
I would suggest:
- Build with CFLAGS to tell the compiler not to allow 80-bit floats
and see what happens. perhaps just rebuild proj.
- Run "paranoia" with the same CFLAGS you use for gdal and proj to see
how that goes.
- Think about whether gdal/proj have a requirement for IEEE754
floating point specifically, which is beyond C/C++ standards, and
would exclude important CPU architectures like VAX :-) But
seriously, tests being sensitive to exactly IEEE754 instead of very
close seems suboptimal, and it may be a simple matter of adjusting
the close-enough thresholds to consider what's happening a pass, or
to change the test cases to not push the limits so hard, if that
pushing is disconnected from real world usage.
More information about the gdal-dev
mailing list