https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65131
--- Comment #8 from H.J. Lu ---
(In reply to Andrew Pinski from comment #1)
> The ABI says for all 32bit ABIs you cannot allocate more than half of the
> address space.
X32 can allocate more than 2GB via malloc and ILP32 on ARM64 may also be abl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65131
--- Comment #7 from Francois Fayard ---
I agree. Thanks for your comments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65131
--- Comment #6 from Jonathan Wakely ---
It seems like a waste of time. The internals of the standard library are not
the right place to dissuade people from their mistaken beliefs. Simply trying
to allocate such an array should be evidence enough
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65131
--- Comment #5 from Francois Fayard ---
They are so many people out there who claim that using an unsigned integer
(std::size_t) as an array index was a good choice because you can allocate
larger arrays than with the signed integer of the same s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65131
Jonathan Wakely changed:
What|Removed |Added
Severity|major |normal
--- Comment #4 from Jonathan Wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65131
--- Comment #3 from Francois Fayard ---
Thanks for the info. It would be nice to reflect that in max_size().
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65131
--- Comment #2 from Andrew Pinski ---
https://gcc.gnu.org/ml/gcc/2011-08/msg00221.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65131
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
