https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119323
--- Comment #14 from GCC Commits ---
The releases/gcc-15 branch has been updated by Robert Dubner
:
https://gcc.gnu.org/g:ddf7357af4bfbabb1b77d26e2eacbb3602e59845
commit r15-10132-gddf7357af4bfbabb1b77d26e2eacbb3602e59845
Author: Robert Dubner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119323
--- Comment #13 from David Binderman ---
(In reply to Robert Dubner from comment #11)
> But I really wonder if it's possible to come up with an example where using
> ++it is actually faster, in some significant way, than using it++.
Putting sle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119323
Sam James changed:
What|Removed |Added
Target Milestone|--- |16.0
--- Comment #12 from Sam James ---
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119323
--- Comment #11 from Robert Dubner ---
I suspect that the preference for prefix notation is an historical oddity.
And it is not hard to write pseudo code that demonstrates extra temporary
variables might be needed.
And it's always fun to look
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119323
--- Comment #10 from David Binderman ---
(In reply to Robert Dubner from comment #9)
> This was an interesting exercise.
Good.
> cppcheck was a bit snide about using ++/-- prefix notation for iterators
> rather than the postfix notation, givin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119323
Robert Dubner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119323
--- Comment #8 from GCC Commits ---
The master branch has been updated by Robert Dubner :
https://gcc.gnu.org/g:54e4f75b7d57e02bba79cd67332bbfdc37d1b321
commit r16--g54e4f75b7d57e02bba79cd67332bbfdc37d1b321
Author: Robert Dubner
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119323
James K. Lowden changed:
What|Removed |Added
CC||jklowden at gcc dot gnu.org
Last re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119323
--- Comment #6 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #5)
> // Update the list of compiler-maintained enabled exceptions.
> extern "C"
> void
> __gg__stash_exceptions( size_t nec, cbl_enabled_exception_t *ecs )
> {
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119323
--- Comment #5 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #2)
> More important than the missing self-assignment check and the missing copy
> constructor, there's no destructor.
>
> The missing check and copy ctor only ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119323
--- Comment #2 from Jonathan Wakely ---
More important than the missing self-assignment check and the missing copy
constructor, there's no destructor.
The missing check and copy ctor only matter if the type actually is assigned to
itself or cop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119323
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> Why is the new array allocated for 1 + input.nec items?
Ah, I bet it's to handle the case where input.nec == 0. But that's not needed,
C++ allows new T[n] e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119323
--- Comment #1 from Jonathan Wakely ---
(In reply to David Binderman from comment #0)
> 4.
>
> libgcobol/libgcobol.cc:11072:33: warning: 'operator=' should check for
> assignment to self to avoid problems with dynamic memory. [operatorEqToSelf]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119323
--- Comment #3 from Jonathan Wakely ---
The assignment operator does:
if( nec == input.nec ) {
if( nec == 0 || 0 == memcmp(ecs, input.ecs, nbytes()) ) return *this;
}
if( nec < input.nec ) {
if( nec > 0 ) delete[] ecs;
ecs =
14 matches
Mail list logo
