CGAL / cgal

The public CGAL repository, see the README below
https://github.com/CGAL/cgal#readme
Other
4.96k stars 1.38k forks source link

Different corefinement output in debug vs. release #6363

Open ochafik opened 2 years ago

ochafik commented 2 years ago

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)

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);):

image
sloriot commented 2 years ago

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