https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71892
dnahrblock changed:
What|Removed |Added
CC||howunijemu at crypemail dot
info
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71892
Manuel López-Ibáñez changed:
What|Removed |Added
CC|manu at gcc dot gnu.org|
--- Comment #14 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71892
--- Comment #13 from Manuel López-Ibáñez ---
(In reply to Kern Sibbald from comment #9)
> (In reply to Manuel López-Ibáñez from comment #7)
> Your wipppesnapper comments that are personally insulting are not at all
> helpful.
I'm not sure which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71892
--- Comment #12 from anton at mips dot complang.tuwien.ac.at ---
Given that they suffer from a lack of time, and have no way to know which gcc
versions you tested with, I guess most packagers would prefer it if the
configure script tells them the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71892
--- Comment #11 from Kern Sibbald ---
I recently discussed both of these "optimizations" with Bjarne Stroustrup and
his comment about deleting the memset() when overriding the new() functions
was:
Looks like a bug to me
His comment about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71892
--- Comment #10 from Kern Sibbald ---
(In reply to anton from comment #8)
It is not productive or conductive to good relations for me to tell packagers
how to do their job. The fact is that very few of them never test the packages
they release
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71892
--- Comment #9 from Kern Sibbald ---
(In reply to Manuel López-Ibáñez from comment #7)
Your wipppesnapper comments that are personally insulting are not at all
helpful.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71892
anton at mips dot complang.tuwien.ac.at changed:
What|Removed |Added
CC||anton at mips
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71892
--- Comment #7 from Manuel López-Ibáñez ---
(In reply to Kern Sibbald from comment #6)
> As you say, everything has been said and in any case, it is clear that you
> are going to stick with the current compiler behavior. What you have failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71892
--- Comment #6 from Kern Sibbald ---
As you say, everything has been said and in any case, it is clear that you are
going to stick with the current compiler behavior. What you have failed to
understand is that I do very well understand that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71892
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71892
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71892
--- Comment #3 from Jonathan Wakely ---
Both examples you give are undefined behaviour according to the C++ standard.
You can claim the code is valid, but that doesn't make it true.
You seem to be confusing "it worked OK until now" with "this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71892
--- Comment #2 from Kern Sibbald ---
Yes, we are aware of the option and how to fix the problem. The issue is that
this optimization at low levels of -O1 and -O2 is not reasonable, and it is
unreasonable and irresponsible to make such changes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71892
--- Comment #1 from Andrew Pinski ---
There is an option to disable both of these. Also the null pointer one had
always been there. Just it got smarter.
15 matches
Mail list logo
