This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/77691] [7/8 regression] experimental/memory_resource/resource_adaptor.cc FAILs
- From: "ro at CeBiTec dot Uni-Bielefeld.DE" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 07 Jun 2017 14:18:08 +0000
- Subject: [Bug libstdc++/77691] [7/8 regression] experimental/memory_resource/resource_adaptor.cc FAILs
- Auto-submitted: auto-generated
- References: <bug-77691-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE <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
sparcv9 8 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 <stddef.h>:
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