Failure in eckit_test_geo_area_polygon

[DJDavies2]

What happened?

Compiling eckit with gcc 12.2.0 results in this failure in eckit_test_geo_area_polygon:

Running section "clipping: vertix/vertices outside the clipping polygon (5)" ...
Running section "clipping: completely outside the clipping polygon" ...
Running section "clipping: concave polygon where part is clipped but part remains inside." ...
Running section "clipping: polygon intersection" ...
�[31mTest "Polygon (section: clipping: polygon intersection)" failed: Condition failed: poly == expected @ (/home/users/david.davies/cylc-run/mo-bundle-817/share/mo-bundle/eckit/tests/geo/area_polygon.cc:531 test_162)�[0m
Completed case 1: Polygon
FAILED: Polygon (section: clipping: polygon intersection)
1 tests failed out of 2.

What are the steps to reproduce the bug?

Build with gcc 12.2.0 and run ctests.

Version

1.32.3 (and develop)

Platform (OS and architecture)

Linux

Relevant log output

Accompanying data

No response

Organisation

Met Office

[DJDavies2]

Comparing the failing build config with a build config where the test passes, the difference I am seeing seems to be in the call to emplace_back_point here:

emplace_back_point(E.first + A * cross(B, C) * (1. / D));

from Polygon::emplace_back_point_at_intersection

For the passing case the expression passed to emplace_back_point evaluates in emplace_back_point to:

P = {0, 1}

whereas for the failing case I get:

P = {5.55112e-17, 1}

If I print the result of the expression in emplace_back_point_at_intersection just before the call to emplace_back_point I get {0, 1} in both cases.

[DJDavies2]

My output statements are in https://github.com/DJDavies2/eckit/tree/bugfix/234

[pmaciel]

Good catch -- I'm not sure what is going wrong, because the calling hierarchy should be

•     EXPECT(poly == expected); // (tests/geo/area_polygon.cc:531)
  

•         if (!points_equal(operator[]((i + k) % n), other[(j + k) % n])) { // (geo/polygon/Polygon.cc:68)
  

• return types::is_approximately_equal(c.lon, d.lon, eps) && types::is_approximately_equal(c.lat, d.lat, eps); // (src/eckit/geo/PointLonLat.cc:105)

where eps = 1e-9 -- So it's safely out of failing comparison.

There might be different resulting paths depending how the linker symbols are resolved but this is the intention. I'll have a further look.

[pmaciel]

On our platforms x86_64 + gcc/12.2.0 and CMake build types Debug, RelWithDebInfo and Release I'm not reproducing the error (this is not saying it doesn't exist).

For Release, the most likely configuration for this problem, an example compilation line is
[260/262] /usr/local/apps/gcc/12.2.0/bin/g++ -Deckit_geo_EXPORTS -I/perm/mapm/git/eckit/src -I/perm/mapm/build/eckit/src -pipe -Wall -Wextra -Wno-unused-parameter -Wno-unused-variable -Wno-sign-compare -O3 -DNDEBUG -std=gnu++17 -fPIC -MD -MT src/eckit/geo/CMakeFiles/eckit_geo.dir/Grid.cc.o -MF src/eckit/geo/CMakeFiles/eckit_geo.dir/Grid.cc.o.d -o src/eckit/geo/CMakeFiles/eckit_geo.dir/Grid.cc.o -c /perm/mapm/git/eckit/src/eckit/geo/Grid.cc

and linking
[262/262] cd /perm/mapm/build/eckit/tests/geo && /usr/bin/cmake -E remove EXE_FILENAME-NOTFOUND && cd /perm/mapm/build/eckit && /usr/local/apps/gcc/12.2.0/bin/g++ -pipe -Wall -Wextra -Wno-unused-parameter -Wno-unused-variable -Wno-sign-compare -O3 -DNDEBUG -Wl,--disable-new-dtags tests/geo/CMakeFiles/eckit_test_geo_area_polygon.dir/area_polygon.cc.o -o tests/geo/eckit_test_geo_area_polygon -Wl,-rpath,/perm/mapm/build/eckit/lib lib/libeckit_geo.so lib/libeckit_maths.so lib/libeckit_codec.so lib/libeckit.so -lm /usr/lib64/librt.so -lpthread -ldl && :

Can you check if your compilation is using fast-math or like options? (-O3 doesn't seem to be an issue, as above).

[DJDavies2]

The compile options are:

-Deckit_geo_EXPORTS -I/home/users/david.davies/cylc-run/eckit-234/share/mo-bundle/eckit/src -I/home/users/david.davies/cylc-run/eckit-234/share/make_mo_base__ex_gnu/eckit/src -isystem /home/users/david.davies/cylc-run/eckit-234/share/mobbs/util/ex_gnu/include/eigen3 -I/opt/cray/pe/mpich/8.1.26/ofi/gnu/9.1/include -DUSE_BOOST_REGEX -pipe -Wall -Wextra -Wno-unused-parameter -Wno-unused-variable -Wno-sign-compare -O3 -DNDEBUG -std=gnu++17 -fPIC -MD -MT eckit/src/eckit/geo/CMakeFiles/eckit_geo.dir/Grid.cc.o -MF eckit/src/eckit/geo/CMakeFiles/eckit_geo.dir/Grid.cc.o.d -o eckit/src/eckit/geo/CMakeFiles/eckit_geo.dir/Grid.cc.o -c /home/users/david.davies/cylc-run/eckit-234/share/mo-bundle/eckit/src/eckit/geo/Grid.cc

The link options are:

-I/opt/cray/pe/mpich/8.1.26/ofi/gnu/9.1/include -DUSE_BOOST_REGEX -pipe -Wall -Wextra -Wno-unused-parameter -Wno-unused-variable -Wno-sign-compare -O3 -DNDEBUG -L/opt/cray/pe/mpich/8.1.26/ofi/gnu/9.1/lib -lmpich -lgfortran -lquadmath -Wl,--disable-new-dtags -Wl,--dependency-file=eckit/tests/geo/CMakeFiles/eckit_test_geo_area_polygon.dir/link.d eckit/tests/geo/CMakeFiles/eckit_test_geo_area_polygon.dir/area_polygon.cc.o -o eckit/tests/geo/eckit_test_geo_area_polygon -Wl,-rpath,/home/users/david.davies/cylc-run/eckit-234/share/make_mo_base__ex_gnu/lib lib/libeckit_geo.so lib/libeckit_maths.so lib/libeckit_codec.so lib/libeckit.so -lm /usr/lib64/librt.so -ldl

I don't think fast-math is being used.

[DJDavies2]

I experimented with some options; using build type = none instead of Release but putting -O3 (or indeed -O2) in the CXX compile flags reproduced the error on the platform where it fails. However if I compile with -O3 or -O2 with -fno-expensive-optimizations with ctest worked. So maybe it is -fexpensive-optimizations that is the issue? Not that that is very helpful, as the manual page doesn't give much information on what that option actually does:

https://gcc.gnu.org/onlinedocs/gcc-12.5.0/gcc/Optimize-Options.html