[Bug libstdc++/77691] [7/8 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 --- Comment #20 from Rainer Orth --- Xfailed for 7.4, too.
[Bug libstdc++/77691] [7/8 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 --- Comment #19 from Rainer Orth --- Author: ro Date: Thu Mar 22 17:42:32 2018 New Revision: 258778 URL: https://gcc.gnu.org/viewcvs?rev=258778=gcc=rev Log: xfail experimental/memory_resource/resource_adaptor.cc on 32-bit Solaris/x86 (PR libstdc++/77691) PR libstdc++/77691 * testsuite/experimental/memory_resource/resource_adaptor.cc: xfail execution on 32-bit Solaris/x86. Modified: branches/gcc-7-branch/libstdc++-v3/ChangeLog branches/gcc-7-branch/libstdc++-v3/testsuite/experimental/memory_resource/resource_adaptor.cc
[Bug libstdc++/77691] [7/8 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 --- Comment #18 from Rainer Orth --- Xfailed for GCC 8.1. I'm leaving the PR open for the underlying issue.
[Bug libstdc++/77691] [7/8 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 --- Comment #17 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #14 from Jonathan Wakely --- > We *could* make the libstdc++ operator new call malloc repeatedly until it > gets > something aligned to max_align_t, so that operator new and the C++ allocators > meet the alignment requirements. > > But that seems quite horrible. Indeed, and I'd rather not avoid that penalty for a corner case. To achieve this, one could instead use aligned_alloc instead, which is only in Solaris 11.4, however. Rainer
[Bug libstdc++/77691] [7/8 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 --- Comment #16 from Rainer Orth --- Author: ro Date: Thu Mar 22 13:33:29 2018 New Revision: 258766 URL: https://gcc.gnu.org/viewcvs?rev=258766=gcc=rev Log: xfail experimental/memory_resource/resource_adaptor.cc on 32-bit Solaris/x86 (PR libstdc++/77691) PR libstdc++/77691 * testsuite/experimental/memory_resource/resource_adaptor.cc: xfail execution on 32-bit Solaris/x86. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/experimental/memory_resource/resource_adaptor.cc
[Bug libstdc++/77691] [7/8 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 Rainer Orth changed: What|Removed |Added Status|NEW |ASSIGNED URL||https://gcc.gnu.org/ml/gcc- ||patches/2018-03/msg01162.ht ||ml Assignee|unassigned at gcc dot gnu.org |ro at gcc dot gnu.org --- Comment #15 from Rainer Orth --- Mine, patch posted.
[Bug libstdc++/77691] [7/8 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 --- Comment #14 from Jonathan Wakely --- We *could* make the libstdc++ operator new call malloc repeatedly until it gets something aligned to max_align_t, so that operator new and the C++ allocators meet the alignment requirements. But that seems quite horrible.
[Bug libstdc++/77691] [7/8 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 --- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #12 from joseph at codesourcery dot com dot com> --- > On Wed, 21 Mar 2018, ro at CeBiTec dot Uni-Bielefeld.DE wrote: > >> Joseph, any suggestions? You mentioned that older versions of glibc >> didn't provide 16-byte alignment in i386 malloc; maybe there are other >> systems with the same issue that could equally benefit from some fix? > > The fix in glibc was to increase malloc alignment for i386. This is an > area where properly supporting a feature (_Float128 and _Decimal128, both > of which are 16-byte aligned on i386) requires cooperation between the > compiler and library - in this case, even without other library support > for those types, users can still legitimately expect memory from malloc to > be suitably aligned for them, and for max_align_t to have suitable > alignment for them. I see. So I'll go ahead and xfail the current testcase (unless Jonathan prefers to move the failing max_align_t part to a separate testcase) and pursue increasing i386 malloc alignment and the __float128 addition to max_align_t (for non-Studio compilers only, I guess) in Solaris. Thanks. Rainer
[Bug libstdc++/77691] [7/8 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 --- Comment #12 from joseph at codesourcery dot com --- On Wed, 21 Mar 2018, ro at CeBiTec dot Uni-Bielefeld.DE wrote: > Joseph, any suggestions? You mentioned that older versions of glibc > didn't provide 16-byte alignment in i386 malloc; maybe there are other > systems with the same issue that could equally benefit from some fix? The fix in glibc was to increase malloc alignment for i386. This is an area where properly supporting a feature (_Float128 and _Decimal128, both of which are 16-byte aligned on i386) requires cooperation between the compiler and library - in this case, even without other library support for those types, users can still legitimately expect memory from malloc to be suitably aligned for them, and for max_align_t to have suitable alignment for them.
[Bug libstdc++/77691] [7/8 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 --- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #10 from Jonathan Wakely --- > (In reply to Jonathan Wakely from comment #9) >> So GCC's definition of max_align_t is not consistent with malloc in Solaris > > Oh, I'm assuming here that the definition of max_align_t is coming from GCC's > . Thanks for that reminder: I'd completely forgotten about gcc/ginclude/stddef.h and only looked at the system header. That header includes /* _Float128 is defined as a basic type, so max_align_t must be sufficiently aligned for it. This code must work in C++, so we use __float128 here; that is only available on some architectures, but only on i386 is extra alignment needed for __float128. */ #ifdef __i386__ __float128 __max_align_f128 __attribute__((__aligned__(__alignof(__float128; #endif (which of course doesn't have), introduced in https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00652.html > Wherever that max_align_t definitions comes from, it should match what malloc > does. I don't think that's necessarily true: * According to the i386 psABI, p.8, Table 2.1, support for __float128 is optional. * Studio 12.6 cc doesn't support it: https://docs.oracle.com/cd/E77782_01/html/E77792/gqexw.html#OSGCCgqexp * Thus neither does the system malloc. Even if this could be changed for (say) Solaris 11.5 (I'll check about this once discussion of this bug is finished), that leaves us with older Solaris versions. As an experiment, I've disabled the __float128/i386 part of the max_align_t definition in gcc/ginclude/stdlib.h. Not unexpectedly, the current test PASSes now: -FAIL: experimental/memory_resource/resource_adaptor.cc execution test while another FAILs: +FAIL: gcc.dg/float128-align.c (test for excess errors) Excess errors: /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/floatn-align.h:17:1: error: static assertion failed: "max_align_t must be at least as aligned as _Float* types" I'm uncertain how to deal with this: of course we could xfail the current test and be done with it, but perhaps there are other options? Joseph, any suggestions? You mentioned that older versions of glibc didn't provide 16-byte alignment in i386 malloc; maybe there are other systems with the same issue that could equally benefit from some fix? Rainer
[Bug libstdc++/77691] [7/8 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 --- Comment #10 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #9) > So GCC's definition of max_align_t is not consistent with malloc in Solaris Oh, I'm assuming here that the definition of max_align_t is coming from GCC's . Wherever that max_align_t definitions comes from, it should match what malloc does.
[Bug libstdc++/77691] [7/8 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 --- Comment #9 from Jonathan Wakely --- This doesn't seem like a libstdc++ bug. malloc must return memory suitably aligned for any type of object with a fundamental alignment, i.e. <= _Alignof(max_align_t). So GCC's definition of max_align_t is not consistent with malloc in Solaris 12, which means that GCC and malloc don't agree on the maximum fundamental alignment for the target.
[Bug libstdc++/77691] [7/8 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 Richard Biener changed: What|Removed |Added Target Milestone|7.3 |7.4 --- Comment #8 from Richard Biener --- GCC 7.3 is being released, adjusting target milestone.
[Bug libstdc++/77691] [7/8 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 Richard Biener changed: What|Removed |Added Target Milestone|7.2 |7.3
[Bug libstdc++/77691] [7/8 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 Richard Biener changed: What|Removed |Added Target Milestone|7.2 |7.3 --- Comment #8 from Richard Biener --- GCC 7.2 is being released, adjusting target milestone.
[Bug libstdc++/77691] [7/8 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 --- Comment #7 from Rainer Orth --- Created attachment 41491 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41491=edit test program
[Bug libstdc++/77691] [7/8 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
I've digged a bit further now.
Running the testcase under gdb, I find that p at the failing assertion
is 0x806fda8, i.e. not aligned to 16 bytes but to 8 bytes instead. It's
ultimately returned from malloc in libsupc++/new_op.cc (operator new
(std::size_t sz)).
With test attached testcase and gcc 7.1.0, I find:
alignof long long long double double _Complex
std::max_align_t
i386 8 4 8 16
amd64 8 16 8 16
sparc 8 8 8 8
sparcv98 16 8 16
However, this changed from gcc 6 to 7:
i386/gcc6 8 4 8 8
i386/gcc7 8 4 8 16
where the gcc6 value matches what one would expect from :
typedef struct {
#if defined(__clang__) || defined(__llvm__)
long long __clang_max_align_nonce1 _ALIGNMENT(long long);
long double __clang_max_align_nonce2 _ALIGNMENT(long, double);
#elif defined(__GNUC__)
long long __max_align_ll _ALIGNMENT(long, long);
long double __max_align_ld _ALIGNMENT(long, double);
#else
__ATOMIC long long __max_align_ll;
__ATOMIC long double __max_align_ld;
#if defined(__i386) || defined(__amd64)
__ATOMIC double __COMPLEX __max_align_d;
#endif /* defined(__i386) || defined(__amd64) */
#endif /* defined(__clang__) || defined(__llvm__) */
} max_align_t;
#endif /* _MAX_ALIGN_T */
Rainer
[Bug libstdc++/77691] [7/8 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 Jakub Jelinek changed: What|Removed |Added Target Milestone|7.0 |7.2 --- Comment #5 from Jakub Jelinek --- GCC 7.1 has been released.
