Hi All, This patch addresses issues introduced by r292564. Specifically it makes `align_val_t.pass.cpp` pass in C++17 even if the system doesn't support aligned new/delete.
Because r292564 was merged into 4.0, this should be as well. @Marshall can you OK this? /Eric On Thu, Jan 19, 2017 at 11:27 PM, Eric Fiselier via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Author: ericwf > Date: Fri Jan 20 00:27:34 2017 > New Revision: 292582 > > URL: http://llvm.org/viewvc/llvm-project?rev=292582&view=rev > Log: > Still expose std::align_val_t in C++17 even if we don't have aligned > new/delete. > > r292564 disabled the aligned new/delete overloads on platforms without > posix_memalign. Unfortunately that patch also disabled the align_val_t > definition in C++17 as well. > > This patch causes align_val_t to be exposed in C++17 regardless > of if we have the new/delete overloads. > > Modified: > libcxx/trunk/include/new > > Modified: libcxx/trunk/include/new > URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/ > new?rev=292582&r1=292581&r2=292582&view=diff > ============================================================ > ================== > --- libcxx/trunk/include/new (original) > +++ libcxx/trunk/include/new Fri Jan 20 00:27:34 2017 > @@ -145,7 +145,7 @@ public: > > #endif // defined(_LIBCPP_BUILDING_NEW) || (_LIBCPP_STD_VER > 11) > > -#ifndef _LIBCPP_HAS_NO_ALIGNED_ALLOCATION > +#if !defined(_LIBCPP_HAS_NO_ALIGNED_ALLOCATION) || _LIBCPP_STD_VER > 14 > #ifndef _LIBCPP_CXX03_LANG > enum class _LIBCPP_ENUM_VIS align_val_t : size_t { }; > #else > > > _______________________________________________ > cfe-commits mailing list > cfe-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits