[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