Re: [lmi] PATCH: Building lmi with gcc 10 and C++20

[Greg Chicares]

On 2020-05-10 22:12, Vadim Zeitlin wrote:
> 
>  I couldn't help myself and decided to test compilation of lmi in C++20
> mode as soon as g++ 10.1, implementing support for C++20, became available
> in Debian.

This must be pc-linux-gnu or whatever it's called, as opposed to msw,
because even debian unstable still has only
  mingw-w64 (7.0.0-4), which depends upon
  g++-mingw-w64 (9.3.0-8+22)
It's good that we can use native linux gcc to stay ahead of MinGW-w64
and fix problems preemptively.

>  This didn't work completely out of the box, but the problems were not
> difficult to fix:
> 
> - There were some errors in wxWidgets due to the new comparison operator
>   semantics and deletion of std::ostream::operator<< overloads for wchar_t
>   and "const wchar_t*". PR https://github.com/wxWidgets/wxWidgets/pull/1851
>   fixes those and I'll merge it in wxWidgets soon.

We'll have to upgrade wx ere long anyway, for the new wxGrid code.

> - sigfpe.cpp:78:8: error: compound assignment with ‘volatile’-qualified left 
> operand is deprecated [-Werror=volatile]
>    78 |     d2 *= dm;
>       |     ~~~^~~~~
>    (...same...)
>    85 |     d2 /= dm;
>       |     ~~~^~~~~
> 
>   I have no idea what is this code trying to do, but just using
>   non-compound assignments allows to avoid this error without, hopefully,
>   breaking the intention of the code, whatever it is.

I had recently read about deprecation of 'volatile' in most cases:
  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1152r0.html
and didn't (and still don't) expect significant problems with lmi,
where 'volatile' is used mostly to prevent a clever compiler from
optimizing away a consistency test that I want to perform although
(because) it "cannot" fail. This:

    double volatile dm = DBL_MAX;
    double volatile d2;
[...]
  // FPU arithmetic overflow. TODO ?? Is this right, and does it work?
    d2 = dm;
    d2 *= dm;

attempts to trigger an FP overflow signal. I wrote "volatile"
because I really want the compiler to set a variable to DBL_MAX,
and multiply it by itself, at run time.

> - pdf_command_wx.cpp:2458:53: error: implicit capture of ‘this’ via ‘[=]’ is 
> deprecated in C++20 [-Werror=deprecated]
[...]
>   Same thing as above, except that there was really no reason to ever use
>   implicit capture in the first place here.

Looks good.

> - I left the last and the least pleasant one for the end: there are also
>   errors in Boost.Regex when using C++20. The error messages are too long
>   for it to be useful to paste them here, but basically we need to disable
>   -Wdeprecated-copy for gcc 10 too, as it was already done by clang, in
>   boost_regex.hpp and we also need to define BOOST_NO_STD_ALLOCATOR in
>   addition to BOOST_NO_AUTO_PTR to compile it to prevent it from using
>   std::allocator::const_reference, which was already deprecated in C++17
>   and is removed completely in C++20.

That sounds good.

Does gcc-9.3 have a usable <filesystem> library? It would be really
good to get rid of that boost code.

>  I've collected all the changes needed to fix lmi compilation with gcc 10
> in C++20 mode in https://github.com/vadz/lmi/pull/142 and I think there is
> no real reason not to apply them, even if we're probably not going to
> upgrade to gcc 10 any time soon yet, as they shouldn't have any drawbacks
> when using the existing compiler neither.

Okay, I'll try to review that this week.

>  As you probably noticed, I've committed one change to master too, to make
> it possible to build lmi successfully when using autotools, hopefully you
> don't mind even if it added a couple of "MD5 !!" markers -- but they
> just parallel those already present in objects.make.

Thanks, that all looks perfect.