https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71885
--- Comment #26 from Markus Trippelsdorf ---
For future reference here is a nice, short example from Bernd Edlinger:
markus@x4 tmp % cat lifetime-dse.cpp
#include
#include
#include
struct A {
A() {}
void *operator new(size_t s) {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71885
--- Comment #25 from Manuel López-Ibáñez ---
(In reply to Kern Sibbald from comment #23)
> That said, I still think the project made a bad decision on this one, and
The "project" doesn't make decisions. Individuals submit patches and other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71885
--- Comment #24 from hyc at symas dot com ---
(In reply to Manuel López-Ibáñez from comment #21)
> (In reply to hyc from comment #19)
> > That's all well and good. But, somebody had to go out of their way to
> > develop the code to identify this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71885
--- Comment #23 from Kern Sibbald ---
In response to the last post of Jonathan Wakely.
Thanks, that is the first time someone on the gcc side has said something that
makes sense. Of course, possibly I missed or misunderstood previous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71885
--- Comment #22 from Jonathan Wakely ---
(In reply to hyc from comment #14)
> "If no initialization is performed" - this is the constructor, whose job is
> to create and initialize the object, and you're preventing that
> initialization from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71885
--- Comment #21 from Manuel López-Ibáñez ---
(In reply to hyc from comment #19)
> That's all well and good. But, somebody had to go out of their way to
> develop the code to identify this case of new as being a dead store. Why was
> this worth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71885
--- Comment #20 from Jonathan Wakely ---
(In reply to Kern Sibbald from comment #17)
> It is pretty difficult to argue with the developers because they know the
> "rules", better than most programmers. However, here in my opinion they
> used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71885
--- Comment #19 from hyc at symas dot com ---
(In reply to Manuel López-Ibáñez from comment #18)
> (In reply to Kern Sibbald from comment #17)
> > The g++ developers could have realized that in especially in "undefined"
> > territory where they
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71885
--- Comment #18 from Manuel López-Ibáñez ---
(In reply to Kern Sibbald from comment #17)
> The g++ developers could have realized that in especially in "undefined"
> territory where they knew they would break code the conservative way to do
> it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71885
--- Comment #17 from Kern Sibbald ---
It is pretty difficult to argue with the developers because they know the
"rules", better than most programmers. However, here in my opinion they used
very poor judgement, by implementing a change that they
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71885
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=71885
--- Comment #15 from hyc at symas dot com ---
(In reply to Markus Trippelsdorf from comment #3)
> See https://gcc.gnu.org/gcc-6/porting_to.html (More aggressive optimization
> of -flifetime-dse).
>
> You're invoking undefined behavior;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71885
hyc at symas dot com changed:
What|Removed |Added
CC||hyc at symas dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71885
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71885
--- Comment #12 from Kern Sibbald ---
Yes, I clearly understand your point. My responses were meant for the project
were not directed at you. Hopefully someone will consider taking your advice of
not making this the default. It may be difficult
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71885
Markus Trippelsdorf changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71885
--- Comment #10 from Kern Sibbald ---
Thanks for your definition of "undetermined" behavior. The problem here is
that at the time the compiler applied its optimization we were just in the
process of creating the object as is permitted by the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71885
--- Comment #9 from Eric Bollengier ---
Thanks for the "behavior is undefined" explanation. I understand a bit better
why the GCC team did this choice.
However, here, we don't talk about such kind of objects. In my case for
example, objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71885
--- Comment #8 from Markus Trippelsdorf ---
See Initializers 8.6.12:
When storage for an object with automatic or dynamic storage duration is
obtained, the object has an indeterminate value, and if no initialization is
performed for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71885
--- Comment #7 from Kern Sibbald ---
Just to be clear:
- This change might be appropriate for higher level of optimization, but is not
appropriate as a default for -O2 and -O1.
- There is no undefined behavior here. We override the new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71885
--- Comment #6 from Markus Trippelsdorf ---
For the record, I was against enabling this optimization by default.
(Because the potential gain doesn't justify the possible confusion it may
cause.
And -fsanitize=undefined doesn't catch these issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71885
Kern Sibbald changed:
What|Removed |Added
CC||kern at sibbald dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71885
--- Comment #4 from Eric Bollengier ---
I don't know exactly when someone decided that a doing memset(buf, 0,
sizeof(buf)); leads to an "undefined behavior", but it's how C and C++ work
since quite long time. And it's also why the operator new()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71885
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
24 matches
Mail list logo
