https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477
--- Comment #10 from Martin Sebor ---
You're right that the #pragma can be a little flakey with inlining. This is a
recurring issue that can be made worse by LTO. A fix I submitted for GCC 11
got deferred to GCC 12 (see pr98465 comment 12). I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477
--- Comment #9 from andysem at mail dot ru ---
(In reply to Martin Sebor from comment #8)
>
> Submitting a bug for the LTO problem is only helpful if it comes with a test
> case to reproduce it. I have heard about problems suppressing warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477
--- Comment #8 from Martin Sebor ---
The PTRDOIFF_MAX limit is a general restriction implied by the language
requirement that the difference between any two pointers must be representable
in ptrdiff_t. In practical terms, GCC internally represe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477
--- Comment #7 from andysem at mail dot ru ---
(In reply to Martin Sebor from comment #6)
> In C/C++ the size of the largest object is PTRDIFF_MAX - 1 bytes. This is
> necessary so that the difference between the address of its first byte and
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477
--- Comment #6 from Martin Sebor ---
In C/C++ the size of the largest object is PTRDIFF_MAX - 1 bytes. This is
necessary so that the difference between the address of its first byte and that
just past its last byte fits in ptrdiff_t. A number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477
--- Comment #5 from andysem at mail dot ru ---
(In reply to Martin Sebor from comment #4)
> The case of _size being very large and n very small may be handled correctly
> by the original code thanks to the check for _capacity but because its valu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477
Martin Sebor changed:
What|Removed |Added
Blocks||88443
--- Comment #4 from Martin Sebor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477
--- Comment #3 from andysem at mail dot ru ---
To put it another way, the case of _size being large and n small is valid, and
memset (and resize in general) do behave correctly in this case. Which is why
the warning is bogus and the suggested ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477
andysem at mail dot ru changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
10 matches
Mail list logo
