cgal
cgal copied to clipboard
Different corefinement output in debug vs. release
Corefinement functions seem to produce different outputs in debug vs. release builds.
The following example produces a substantial diff:
g++ -stdlib=libc++ -std=c++1y -lgmp -lmpfr repro.cc -o repro && ./repro > debug.off
g++ -O2 -stdlib=libc++ -std=c++1y -lgmp -lmpfr repro.cc -o repro && ./repro > release.off
diff debug.off release.off
(same output w/ -O2
& -O3
though)
- Apple clang version 13.0.0 (clang-1300.0.29.30), Target: x86_64-apple-darwin21.3.0
- CGAL 5.4
repro.cc
:
// Copyright 2021 Google LLC.
// SPDX-License-Identifier: Apache-2.0
#include <CGAL/Exact_predicates_exact_constructions_kernel.h>
#include <CGAL/Polygon_mesh_processing/corefinement.h>
#include <CGAL/Surface_mesh.h>
#include <fstream>
int main(int argc, char *argv[])
{
typedef CGAL::Epeck Kernel;
typedef CGAL::Surface_mesh<CGAL::Point_3<Kernel>> Mesh;
auto read = [&](auto&mesh, auto source) {
std::stringstream ss;
ss << source;
ss >> mesh;
assert(CGAL::is_closed(mesh));
assert(CGAL::is_valid_halfedge_graph(mesh, /* verb */ true));
};
Mesh lhs, rhs;
// cube(1);
read(lhs, "OFF\n\
8 12 0\n\
\n\
0 0 1\n\
1 0 1\n\
1 1 1\n\
0 1 1\n\
0 1 0\n\
1 1 0\n\
1 0 0\n\
0 0 0\n\
3 3 0 1\n\
3 7 4 5\n\
3 0 7 6\n\
3 1 6 5\n\
3 2 5 4\n\
3 3 4 7\n\
3 1 2 3\n\
3 5 6 7\n\
3 6 1 0\n\
3 5 2 1\n\
3 4 3 2\n\
3 7 0 3\n\
");
// translate([0.5, 0, 0]) cube(1);
read(rhs, "OFF\n\
8 12 0\n\
\n\
0.5 0 1\n\
1.5 0 1\n\
1.5 1 1\n\
0.5 1 1\n\
0.5 1 0\n\
1.5 1 0\n\
1.5 0 0\n\
0.5 0 0\n\
3 3 0 1\n\
3 7 4 5\n\
3 0 7 6\n\
3 1 6 5\n\
3 2 5 4\n\
3 3 4 7\n\
3 1 2 3\n\
3 5 6 7\n\
3 6 1 0\n\
3 5 2 1\n\
3 4 3 2\n\
3 7 0 3\n\
");
auto result = CGAL::Polygon_mesh_processing::corefine_and_compute_union(lhs, rhs, lhs);
assert(result);
std::cout << lhs;
}
Note that the output looks like this (input model in OpenSCAD = cube(1); translate([0.5, 0, 0]) cube(1);
):

I suspect that std::unordered_map
and boost::unordered_map
have different ordering with and without optimization.