https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #22 from Jonathan Wakely ---
N.B. in case somebody does want to backport it, the fix for this depends on the
fix for PR 78448.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #20 from Marc Glisse ---
I created bug 90436 about the excessive checking so it does not distract from
the warning that this bug is about (and doesn't get lost either).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #19 from Jonathan Wakely ---
Fixed on trunk so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #18 from Jonathan Wakely ---
Author: redi
Date: Wed Oct 10 15:39:33 2018
New Revision: 265021
URL: https://gcc.gnu.org/viewcvs?rev=265021=gcc=rev
Log:
PR libstdc++/87544 limit max_size() to PTRDIFF_MAX / sizeof(T)
The C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #17 from Marc Glisse ---
(In reply to Martin Sebor from comment #16)
> The warning code considers just the argument to the call. It doesn't know
> (and in the constant case can't tell) where the argument came from. It
> would need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #16 from Martin Sebor ---
The warning code considers just the argument to the call. It doesn't know (and
in the constant case can't tell) where the argument came from. It would need
to be reworked to tell the difference (e.g.,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #15 from Jonathan Wakely ---
Thanks Martin and Marc for the explanations. The warning sounds a lot more
definite than "there is some possible execution where the value is too large".
The phrasing of the warning makes it look like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #14 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #11)
> Why does it think we're calling it with max_size()?
_M_check_len contains a path (hopefully not taken, but gcc doesn't see that)
where it returns max_size(),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #13 from Martin Sebor ---
There is a call to malloc(SIZE_MAX - 15) in GIMPLE, as a result of the
conditional and I believe jump threading. Just after thread1 we see this in
the vrp1 dump:
[local count: 32272892]:
# _91 = PHI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #12 from Jonathan Wakely ---
(In reply to Martin Sebor from comment #3)
> At the same time, since the call malloc(SIZE_MAX) is guaranteed to fail, GCC
> could fold it to zero
But there is no call to malloc(SIZE_MAX), GCC is confused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #11 from Jonathan Wakely ---
I can make these changes to libstdc++, but why is the compiler warning anyway?
It says:
In function ‘T* my_allocator::allocate(std::size_t, const void*) [with T =
int]’,
inlined from ‘void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #10 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #9)
> Do we want something like this as well? (and for malloc_allocator too)
I think so. Changing allocator_traits as LWG seems likely to agree won't help
much until
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #9 from Jonathan Wakely ---
Do we want something like this as well? (and for malloc_allocator too)
--- a/libstdc++-v3/include/ext/new_allocator.h
+++ b/libstdc++-v3/include/ext/new_allocator.h
@@ -130,7 +130,13 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #8 from Jonathan Wakely ---
(In reply to Marc Glisse from comment #6)
> I think the standard specifies the fallback value in allocator_traits for
> allocators that do not provide max_size (we could open an issue asking for
> more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #7 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #5)
>static size_type
>_S_max_size(const _Tp_alloc_type& __a) _GLIBCXX_NOEXCEPT
>{
> - const size_t __diffmax =
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #6 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #4)
> But the standard explicitly requires the
> allocator to be stupid, so I'm not sure what more libstdc++ can do here.
I think the standard specifies the fallback
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #5 from Jonathan Wakely ---
Maybe this:
--- a/libstdc++-v3/include/bits/stl_vector.h
+++ b/libstdc++-v3/include/bits/stl_vector.h
@@ -1726,7 +1726,11 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
static size_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #4 from Jonathan Wakely ---
> allocator::max_size() is worse than useless
Fixed that for you.
https://cplusplus.github.io/LWG/lwg-active.html#3044
https://cplusplus.github.io/LWG/lwg-closed.html#197
For PR 78448 I recently changed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #2 from Gael Guennebaud ---
Indeed, if I redefine max_size as follows instead of relying on std::allocator
then the warning is gone:
size_type max_size() const {
return std::numeric_limits::max()/sizeof(T);
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
Marc Glisse changed:
What|Removed |Added
Component|c++ |libstdc++
--- Comment #1 from Marc Glisse
22 matches
Mail list logo
