https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97025
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97025
--- Comment #5 from Mikhail Kremniov ---
I see. So this is not considered a bug then?
P.S. it seems that -faligned-new=8 can be used as a workaround in this case,
even in pre-c++17 modes, so the issue doesn't look that bad in the end.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97025
--- Comment #4 from Jonathan Wakely ---
The change to max_align_t was done in r240248 in 2016, glibc's malloc was
changed some time after.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97025
--- Comment #3 from Jonathan Wakely ---
operator new just gets its memory from malloc.
GCC changed the alignment of max_align_t on x86 targets, but if you don't have
a newer malloc then it won't know about that change and so disagrees with GCC's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97025
--- Comment #2 from Mikhail Kremniov ---
(In reply to Andrew Pinski from comment #1)
> malloc is not controlled by gcc.
Yeah, I shouldn't have mentioned malloc because there seems to be no
requirement for it to align the returned addresses by al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97025
--- Comment #1 from Andrew Pinski ---
malloc is not controlled by gcc.