https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63459
Martin Sebor changed:
What|Removed |Added
Status|NEW |WAITING
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63459
--- Comment #7 from Marc Glisse glisse at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #0)
It would be nice to use the fact that the default
operator new throw exception instead of returning NULL in out of memory case.
Note that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63459
--- Comment #5 from Jan Hubicka hubicka at ucw dot cz ---
Hi,
does something like this make sense (I also updated the DECL_BY_REFERENCE
check.
We allow to put variable at address NULL with -fno-delete-null-pointer-checks
that IMO can let me to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63459
--- Comment #6 from Jan Hubicka hubicka at ucw dot cz ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63459
--- Comment #5 from Jan Hubicka hubicka at ucw dot cz ---
Hi,
does something like this make sense (I also updated the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63459
--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org ---
I think a method call always has this != NULL so you'd infer this != NULL
after the call with a ASSERT_EXPR.
With the pattern stuff you can't really write any call with some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63459
--- Comment #1 from Marc Glisse glisse at gcc dot gnu.org ---
VRP already optimizes this, doesn't it?
Adding an implicit __attribute__((nonnull(1))) to all C++ member functions
might be good, but it also sounds a bit scary to me...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63459
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63459
--- Comment #3 from Marc Glisse glisse at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #2)
I wonder if we can fold this earlier, for instance FRE1 has all info to do
the job, too.
Note that this is also done in fold-const.c
