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

[Vadim Zeitlin]

On Sun, 10 May 2020 23:38:03 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2020-05-10 22:12, Vadim Zeitlin wrote:
GC> > 
GC> >  I couldn't help myself and decided to test compilation of lmi in C++20
GC> > mode as soon as g++ 10.1, implementing support for C++20, became available
GC> > in Debian.
GC> 
GC> This must be pc-linux-gnu or whatever it's called, as opposed to msw,

 Yes, it's the x86_64-pc-linux-gnu version (in 32 bits it would be
i686-pc-linux-gnu).

GC> because even debian unstable still has only
GC>   mingw-w64 (7.0.0-4), which depends upon
GC>   g++-mingw-w64 (9.3.0-8+22)

 I don't know when did it appear there, but there is g++-mingw-w64-i686 ~10
in experimental. We obviously shouldn't use it for anything serious, but
it's a good sign as it means that it might migrate to unstable relatively
soon and then I would at least be able to test it conveniently (I do use
some packages from experimental from time to time, but I prefer not to do
it unless it's really needed -- or I'm really dying from curiosity, and in
this case I think I'll be able to restrain myself for a bit longer).

GC> It's good that we can use native linux gcc to stay ahead of MinGW-w64
GC> and fix problems preemptively.

 Indeed. I'm also pretty impressed with the speed of both gcc and clang
updates in Debian unstable, it definitely wasn't always like this, but the
maintainers are doing a great job with them now.

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

 Exactly.

GC> > - sigfpe.cpp:78:8: error: compound assignment with ‘volatile’-qualified 
left operand is deprecated [-Werror=volatile]
GC> >    78 |     d2 *= dm;
GC> >       |     ~~~^~~~~
GC> >    (...same...)
GC> >    85 |     d2 /= dm;
GC> >       |     ~~~^~~~~
GC> > 
GC> >   I have no idea what is this code trying to do, but just using
GC> >   non-compound assignments allows to avoid this error without, hopefully,
GC> >   breaking the intention of the code, whatever it is.
GC> 
GC> I had recently read about deprecation of 'volatile' in most cases:
GC>   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1152r0.html
GC> and didn't (and still don't) expect significant problems with lmi,
GC> where 'volatile' is used mostly to prevent a clever compiler from
GC> optimizing away a consistency test that I want to perform although
GC> (because) it "cannot" fail. This:
GC> 
GC>     double volatile dm = DBL_MAX;
GC>     double volatile d2;
GC> [...]
GC>   // FPU arithmetic overflow. TODO ?? Is this right, and does it work?
GC>     d2 = dm;
GC>     d2 *= dm;
GC> 
GC> attempts to trigger an FP overflow signal.

 Yes, I gathered that much, I just didn't really understand why and, more
importantly from pragmatic point of view, how could I test this, i.e. check
that my changes didn't change the behaviour of this code. Now that I think
about it again, I realize I could have compared the generated assembly...

GC> I wrote "volatile" because I really want the compiler to set a variable
GC> to DBL_MAX, and multiply it by itself, at run time.

 I _think_ that this is still bound to happen with the new version, but I
could check it if you think it's worth it.

GC> Does gcc-9.3 have a usable <filesystem> library?

 Yes! I haven't done any really extensive checks yet, but the not
completely trivial example of using the library at
https://en.cppreference.com/w/cpp/filesystem/exists#Example does run now,
provided you remove/skip/ignore the error from the symlink creation, under
MSW. So we can (finally) proceed to the replacement of Boost.Filesystem
with std::filesystem.

GC> It would be really good to get rid of that boost code.

 Note that both of these problems are in Boost.Regex, not Boost.Filesystem,
and unfortunately we're still stuck with this one. As you know, I'm open to
just about any proposals for rewriting test_coding_rules.cpp that wouldn't
involve using Boost.Regex...

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

 Great, TIA!
VZ

pgpSJJ3VtK_JV.pgp
Description: PGP signature