[Bug libstdc++/104395] ext/bitmap_allocator.h is not C++98 friendly when using with -faligned-new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104395 --- Comment #10 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:03d3aeb0e0fa7dec9bd702cabf57ef73cdc32704 commit r15-1714-g03d3aeb0e0fa7dec9bd702cabf57ef73cdc32704 Author: Jonathan Wakely Date: Wed Jun 26 14:09:07 2024 +0100 libstdc++: Do not use C++11 alignof in C++98 mode [PR104395] When -faligned-new (or Clang's -faligned-allocation) is used our allocators try to support extended alignments, gated on the __cpp_aligned_new macro. However, because they use alignof(_Tp) which is not a keyword in C++98 mode, using -std=c++98 -faligned-new results in errors from and other headers. We could change them to use __alignof__ instead of alignof, but that would potentially alter the result of the conditions, because e.g. alignof(long long) != __alignof__(long long) on some targets. That's probably not an issue for any types with extended alignment, so maybe it would be a safe change. For now, it seems acceptable to just disable the extended alignment support in C++98 mode, so that -faligned-new enables std::align_val_t and the corresponding operator new overloads, but doesn't affect std::allocator, __gnu_cxx::__bitmap_allocator etc. libstdc++-v3/ChangeLog: PR libstdc++/104395 * include/bits/new_allocator.h: Disable extended alignment support in C++98 mode. * include/bits/stl_tempbuf.h: Likewise. * include/ext/bitmap_allocator.h: Likewise. * include/ext/malloc_allocator.h: Likewise. * include/ext/mt_allocator.h: Likewise. * include/ext/pool_allocator.h: Likewise. * testsuite/ext/104395.cc: New test.
[Bug libstdc++/104395] ext/bitmap_allocator.h is not C++98 friendly when using with -faligned-new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104395 Jonathan Wakely changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-June/65 ||5842.html Last reconfirmed||2024-06-27 Keywords||patch Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #9 from Jonathan Wakely --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655842.html
[Bug libstdc++/104395] ext/bitmap_allocator.h is not C++98 friendly when using with -faligned-new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104395 Jonathan Wakely changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #8 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #7) > It doesn't seem very helpful for GCC and Clang to accept enum class > align_val_t in C++98 mode, but not accept alignof in system headers. It would only need to be accepted when -faligned-new / -faligned-allocation is active, which is already requesting a non-standard extension to C++98.
[Bug libstdc++/104395] ext/bitmap_allocator.h is not C++98 friendly when using with -faligned-new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104395 --- Comment #7 from Jonathan Wakely --- It doesn't seem very helpful for GCC and Clang to accept enum class align_val_t in C++98 mode, but not accept alignof in system headers. We could change all these uses to __alignof instead of alignof, which would work with C++98. But the semantics of alignof and __alignof are slightly different. Maybe the difference only matters for long long, and not for any overaligned types, but I'm not sure. I think the simple answer is that you should not use -faligned-new in C++98 mode.
[Bug libstdc++/104395] ext/bitmap_allocator.h is not C++98 friendly when using with -faligned-new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104395 --- Comment #6 from cqwrteur --- (In reply to Andrew Pinski from comment #5) > GCC's option is -faligned-new -fsized-deallocation -std=c++98 yeah gcc does not work either.
