<html>#2426: g++-10 possibly miscompiles parts of Carpet
<table style='border-spacing: 1ex 0pt; '>
<tr><td style='text-align:right'> Reporter:</td><td>Roland Haas</td></tr>
<tr><td style='text-align:right'> Status:</td><td>new</td></tr>
<tr><td style='text-align:right'>Milestone:</td><td></td></tr>
<tr><td style='text-align:right'> Version:</td><td></td></tr>
<tr><td style='text-align:right'> Type:</td><td>bug</td></tr>
<tr><td style='text-align:right'> Priority:</td><td>major</td></tr>
<tr><td style='text-align:right'>Component:</td><td>Other</td></tr>
</table>
<p>Comment (by Roland Haas):</p>
<p>Changing all users was too much for me, so to test this suspicion I added an almost-iterator class to bboxsset2 (with an ugly hack for <code>end()</code>) that is in here: <a data-is-external-link="true" href="https://bitbucket.org/eschnett/carpet/branch/rhaas/pseudoiterator" rel="nofollow">https://bitbucket.org/eschnett/carpet/branch/rhaas/pseudoiterator</a> it makes the failing test (and the other testsuites) pass so seems to confirm the suspicion that the memoization is causing issues.</p>
<p>An alternative to changing callers might be to have all non-const members of bboxset2 explicitly clear the memoized state (instead of doing in in <code>begin()</code>) and only re-serialize in <code>begin()</code> if the state is not already serialized. I.e. change tracking in bboxset2. This would however, in contrast to changing the callers, keep the serialised state around even after it is no longer needed (just like the current implementation).</p>
<p>Finally one could (possibly) keep track of how many iterators exist (essentially using a counter in bboxset2 objects that count how many iterators exist) by having the iterators keep a pointer to their “parent” and only re-serialise once all iterators have been destroyed. This also means that in becomes possible to track if the parent bboxset2 is modified while there are const-iterators in existence (which is technically allowed I assume, the only non-allowed action is likely <em>doing</em> anything with the iterators after their parent has been modified).</p>
<p>I have never really had to worry about (correctly) implementing iterators so cannot say what the best approach would be.</p>
<p>I do not know if this bug has the chance to fail non-catastrophically (ie without users noticing). However it seems serious enough to me to backport a fix to the current release branch, or at the very least document using <code>CARPET_DISABLE_BBOXSET2</code> as workaround, which however then requires that <a data-is-external-link="true" href="https://bitbucket.org/eschnett/carpet/pul
<p>--<br/>
Ticket URL: <a href='https://bitbucket.org/einsteintoolkit/tickets/issues/2426/g-10-possibly-miscompiles-parts-of-carpet'>https://bitbucket.org/einsteintoolkit/tickets/issues/2426/g-10-possibly-miscompiles-parts-of-carpet</a></p>
</html>