https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480
--- Comment #19 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:09a0affdb0598a54835ac4bb0dd6b54122c12916
commit r12-4319-g09a0affdb0598a54835ac4bb0dd6b54122c12916
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480
Richard Biener changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480
Richard Biener changed:
What|Removed |Added
Target Milestone|11.2|11.3
--- Comment #15 from Richard Bien
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480
--- Comment #14 from Richard Biener ---
diff --git a/gcc/gimple.c b/gcc/gimple.c
index 863bc0d17f1..e085d9de49a 100644
--- a/gcc/gimple.c
+++ b/gcc/gimple.c
@@ -1516,12 +1516,12 @@ gimple_call_fnspec (const gcall *stmt)
&& DECL_IS_OPERATO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480
--- Comment #13 from Richard Biener ---
In PR98130 I suggested "..o " for delete and it would be "m " for new (does
a C++ new expression really set/clobber errno?).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480
--- Comment #12 from Richard Biener ---
That was because of PR98130 it seems.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480
--- Comment #11 from rguenther at suse dot de ---
On Mon, 19 Jul 2021, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480
>
> Jonathan Wakely changed:
>
>What|Removed |Add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480
--- Comment #10 from Jens Maurer ---
I agree with Jonathan here: The difference is that "malloc" comes with the
compiler/library and cannot be replaced (within the scope of the C or C++
standards), but "operator new" is expressly specified to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480
--- Comment #8 from Jonathan Wakely ---
But operator new is not defined in the runtime here, it's a replaceable global
allocation function. The assumption seems unsafe for replaceable functions that
users can define in their own code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480
--- Comment #7 from Richard Biener ---
(In reply to Richard Biener from comment #6)
> As Jakub said the behavior is the same for malloc() since years.
>
...
> So it might work to disable the new/delete/malloc/free optimization when
> we see a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480
--- Comment #6 from Richard Biener ---
As Jakub said the behavior is the same for malloc() since years.
When you split the testcase like
> cat t.C
#include
#include
bool flag = false;
class C
{
bool prev;
public:
C() : prev(flag)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480
Volker Schmidt changed:
What|Removed |Added
CC||volker.schmidt at factset dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480
--- Comment #3 from Jens Maurer ---
"We treat the global operator new as not reading from global memory"
If I implement my own global "operator new" afresh, certainly it'll need to
access global memory, e.g. to read a global pointer to the heap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480
Richard Biener changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480
Jonathan Wakely changed:
What|Removed |Added
Known to work||10.3.0
Keywords|
20 matches
Mail list logo
