Re: [lmi] New CI breakage due to gcc 12 updates

[Greg Chicares]

On 7/25/22 14:48, Vadim Zeitlin wrote:
[...]
>  It seems to be a compiler bug because I can reproduce it in a simple
> example by just compiling it (it won't link, of course, due to the missing
> function) with "-O2 -Wnull-dereference":
> 
> ---------------------------------- >8 --------------------------------------
> #include <algorithm>
> #include <iterator>
> #include <string>
> #include <vector>
> 
> std::vector<std::string> const& cell_parms();
> 
> int main() {
>     std::vector<std::string> all;
> 
>     for(auto const& i : cell_parms()) {
>         all.push_back(i);
>     }
> 
>     std::vector<std::string> unique;
>     std::insert_iterator iin(unique, unique.begin());
>     std::sort(all.begin(), all.end());
>     std::unique_copy(all.begin(), all.end(), iin);
> }
> ---------------------------------- >8 --------------------------------------
> 
>  However trying to further minimize this example (which I couldn't really
> do), I've accidentally found a simple workaround: moving std::sort() before
> insert_iterator creation somehow avoids the warning.

Wow. The compiler would be allowed to move the std::sort() invocation
that way itself, under the as-if rule.

> I wouldn't usually
> propose such a change just to work around a bug, but in this case it
> actually makes sense to me: I think it's more natural to sort the vector
> immediately after initializing it, rather than at some later time.

I'd naturally write it that way because I think of 'sort -u' as an idiom.
But code that doesn't give a warning about UB is preferable to code that
does, even if in theory both ways should just work, so I'm all in favor
of this revision.

> And the
> following simple diff

Committed locally, to be pushed after the next nychthemeral test.

> P.S. Also, just FYI, I've still reported this to gcc developers:
> 
>       https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106434

Thanks.