On 24/08/20 23:19 -0300, Alexandre Oliva wrote:
On Aug 24, 2020, Jonathan Wakely <jwak...@redhat.com> wrote:
OK for trunk, thanks.
Given the approval and the lack of significant changes, I'll put this in
unless there are objections in the next 48 hours. Thanks for the review!
Thanks. There's a new FAIL due to a bad merge.
Erhm... Weird, I don't recall any manual adjustments to
packaged_task/cons/alloc.cc. Indeed, the changes look exactly the same
that Corentin had proposed before. Maybe the constraints were already
there, but hte unintended effects were not noticeable before the change
to the default?
You're right, it's not a bad merge (just a bad change I should have
noticed in the review :-)
My change to prevent it running for C++17 was done May 2019 with
9a0af7e3fb425ae2c0e044d044feb81ef493ce2c so that was already there
before Corentin's original patch.
Anyway, thanks for fixing the failure. That said, I confess I don't get
how this test will (or should) ever be run in C++14 mode, being given an
explicit -std=gnu++11. Is this really the right way to go about it?
The medium term plan is to run libstdc++ tests with several different
-std options, as is done for g++ tests. At that point we can drop most
(but not all) explicit -std options in the tests. But until then, this
test won't run at all if we don't put an explicit -std there, because
it gets skipped with the default -std=gnu++17.
Testing with -std=gnu++11 is better than not testing at all, and the
code being tested is identical for C++11 and C++14 so it's not a
problem that it isn't tested for C++14.
Now and then I manually remove all -std options from the tests and run
them with multiple -std permutations, so it does get tested with C++14
mode, just not automatically.
