This is an archive of the discontinued LLVM Phabricator instance.

[libcxx] [test] Fix experimental/memory.resource.adaptor.mem/db_deallocate on Windows
ClosedPublic

Authored by mstorsjo on Jul 13 2021, 10:00 AM.

Details

Summary

The checks within the libc++experimental memory_resource class uses this
limit:

_MaxAlign = _LIBCPP_ALIGNOF(max_align_t);

Therefore, only use max_align_t for this limit instead of using
__STDCPP_DEFAULT_NEW_ALIGNMENT__ if available.

Alternatively, we could make _MaxAlign in memory_resource be defined
using __STDCPP_DEFAULT_NEW_ALIGNMENT__ if available.

Diff Detail

Event Timeline

mstorsjo requested review of this revision.Jul 13 2021, 10:00 AM
mstorsjo created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptJul 13 2021, 10:00 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript
mstorsjo updated this revision to Diff 358360.Jul 13 2021, 11:16 AM

Rebase past CI config changes

Quuxplusone requested changes to this revision.Jul 13 2021, 12:46 PM

Looking at the git history of <experimental/memory_resource>, I can see that the calculation has always been

    static const size_t _MaxAlign = alignof(max_align_t);
[...]
    size_t __max_size() const _NOEXCEPT {
        return numeric_limits<size_t>::max() - _MaxAlign;
    }

Obviously __STDCPP_DEFAULT_NEW_ALIGNMENT__ has never been relevant to this behavior, and shouldn't have been mentioned in its tests.

This particular bogus test code was introduced by @joerg in D73245. It might be worth (either @joerg or @mstorsjo) auditing all other places where D73245 changed test code, to see whether they're also referring to __STDCPP_DEFAULT_NEW_ALIGNMENT__ in counterfactual ways. Alternatively, maybe resource_adaptor::_MaxAlign should be updated to actually care about __STDCPP_DEFAULT_NEW_ALIGNMENT__, in which case the test would become correct.

Requesting "changes" in the form of investigation/discussion. If the result of investigation ends up being "yeah, _MaxAlign should continue not referring to __STDCPP_DEFAULT_NEW_ALIGNMENT__, and this is the only affected test case," then I'd happily approve this PR in its current form, since it's just bringing the test suite into line with libc++'s actual behavior.

This revision now requires changes to proceed.Jul 13 2021, 12:46 PM

@ldionne - What’s your opinion on this one?

@ldionne - What’s your opinion on this one?

std::pmr::memory_resource is clearly spec'd to use std::max_align_t, so I agree this is the intended behavior (http://eel.is/c++draft/mem.res#class.general-1).

I audited D73245, and the following changes don't look right to me in retrospect:

libcxx/test/std/containers/sequences/array/size_and_alignment.pass.cpp (I don't see what __STDCPP_DEFAULT_NEW_ALIGNMENT__ has to do with the alignment in std::array)
libcxx/test/std/language.support/support.types/max_align_t.pass.cpp (I think we should remove `#ifdef __STDCPP_DEFAULT_NEW_ALIGNMENT__`)

What do you both think?

@ldionne - What’s your opinion on this one?

std::pmr::memory_resource is clearly spec'd to use std::max_align_t, so I agree this is the intended behavior (http://eel.is/c++draft/mem.res#class.general-1).

Thanks!

I audited D73245, and the following changes don't look right to me in retrospect:

libcxx/test/std/containers/sequences/array/size_and_alignment.pass.cpp (I don't see what __STDCPP_DEFAULT_NEW_ALIGNMENT__ has to do with the alignment in std::array)
libcxx/test/std/language.support/support.types/max_align_t.pass.cpp (I think we should remove `#ifdef __STDCPP_DEFAULT_NEW_ALIGNMENT__`)

What do you both think?

Can someone else than me pick up moving forward with those - separately from this patch? I presume this particular patch could be OK'd then?

ldionne accepted this revision.Jul 16 2021, 12:46 PM
This revision was not accepted when it landed; it landed in state Needs Revision.Jul 16 2021, 1:03 PM
This revision was automatically updated to reflect the committed changes.