https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
Sam James changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #35 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:27778979c9a1e32a6ca74e5b5f377385225449b1
commit r15-5595-g27778979c9a1e32a6ca74e5b5f377385225449b1
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #34 from rguenther at suse dot de ---
On Fri, 15 Nov 2024, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
>
> --- Comment #33 from Jakub Jelinek ---
> (In reply to Richard Biener from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #33 from Jakub Jelinek ---
(In reply to Richard Biener from comment #32)
> See PR101480 for a reason why to not do this.
That testcase would be fine with "mP" rather than "mC".
Sure, that PR is a reason not to do the stronger (C) ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #32 from Richard Biener ---
(In reply to Jakub Jelinek from comment #31)
> I believe to match clang++ behavior the needed change would be:
> --- gcc/gimple.cc.jj 2024-11-14 18:26:16.877459015 +0100
> +++ gcc/gimple.cc 2024-11-15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #31 from Jakub Jelinek ---
I believe to match clang++ behavior the needed change would be:
--- gcc/gimple.cc.jj2024-11-14 18:26:16.877459015 +0100
+++ gcc/gimple.cc 2024-11-15 13:40:43.484711373 +0100
@@ -1605,7 +1605,7 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #30 from Jakub Jelinek ---
I had further look and I must say I really don't know what if anything is
clang++'s -fassume-sane-operator-new vs. -fno-assume-sane-operator-new option
doing.
Initially when that option has been added the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #29 from Jan Hubicka ---
For completeness note that we can also stick info into FUNCTION_DECLs (i.e. by
an attribute) to avoid flags pollution. Then it could be TU sensitive since
lto-symtab knows that in certain cases it should not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #27 from Jan Hubicka ---
This is somewhat weird testcase which makes two allocations which compiler can
track as non-escaping and tests its ability to disambiguate them:
int test3(int *data)
{
int *val = new int;
*va
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #28 from Jan Hubicka ---
We could make -fassume-sane-operator-new optimization attribute, but then we
would need to prevent inlining functions with insane operators to functions
with sane operators, or drop the sanity on caller.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #26 from rguenther at suse dot de ---
On Thu, 31 Oct 2024, jason at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
>
> --- Comment #25 from Jason Merrill ---
> (In reply to Jakub Jelinek from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #25 from Jason Merrill ---
(In reply to Jakub Jelinek from comment #24)
> Well, to be precise, it would need to be a per-call property if we want to
> allow people to redefine those and don't use those call flags within the TUs
> whe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #24 from Jakub Jelinek ---
(In reply to Jason Merrill from comment #22)
> But as Jonathan says in comment 10, the replaceable operator new is shared
> by the whole program, so I don't see why we would need a per-call flag for
> the g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #23 from Jakub Jelinek ---
I've just tried:
int i, j, k;
void *
foo ()
{
i = 1;
j = 2;
void *p = __builtin_operator_new (32);
j = 3;
k = i;
return p;
}
void *
bar ()
{
i = 1;
j = 2;
void *p = __builtin_malloc (32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #22 from Jason Merrill ---
But as Jonathan says in comment 10, the replaceable operator new is shared by
the whole program, so I don't see why we would need a per-call flag for the
global memory aliasing property; either the function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #21 from Jason Merrill ---
(In reply to Richard Biener from comment #20)
> It still uses/clobbers global memory though.
Hmm, I guess that's a separate issue from being able to elide the calls
entirely, which is what CALL_FROM_NEW_OR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #20 from Richard Biener ---
Whether a call clobbers or uses memory is controlled by fnspec these days
and a malloc attribute does _not_ indicate this. It works for malloc/free
because we make it so via the builtins in builtin_fnspec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #19 from Jason Merrill ---
As I was suggesting on IRC, I think CALL_FROM_NEW_OR_DELETE_P already has the
semantics we want, we could also set it on direct calls when assuming sane op
new/delete. And maybe rename it to something like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
Sam James changed:
What|Removed |Added
Keywords||patch
--- Comment #17 from Sam James ---
(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #16 from user202729 ---
Hi,
I tried to implement patches that fix the two issues mentioned. Comments would
be appreciated.
1. The operator new flag with many of the mentioned issues fixed:
https://gcc.gnu.org/pipermail/gcc-patches/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #15 from Jan Hubicka ---
> As pointed out in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110035#c13 ,
> gcc
> already assume operator new's retuned pointer cannot alias any existing
> pointer. So no change is needed there.
Seems yo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #14 from user202729 ---
Regarding alias analysis. The current implementaion is such that:
compiler | flag | can alias?| can modify global?|
gcc | sane | no| no| << NEW
> Is the option supposed to be only about the standard global scope operator
> new/delete (_Znam etc.) or also user operator new/delete class methods? If
> the
> former, then I agree it is a global property (or at least a per shared
> library/binary property, one can arrange stuff with symbol vis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #13 from Jan Hubicka ---
> Is the option supposed to be only about the standard global scope operator
> new/delete (_Znam etc.) or also user operator new/delete class methods? If
> the
> former, then I agree it is a global property
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #12 from Jakub Jelinek ---
Is the option supposed to be only about the standard global scope operator
new/delete (_Znam etc.) or also user operator new/delete class methods? If the
former, then I agree it is a global property (or at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #11 from Jonathan Wakely ---
If a program really does need to ensure a particular TU assumes new can modify
global memory (e.g. in the TU defining operator new, which makes use of some
data structure) then that TU should probably be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #10 from Jonathan Wakely ---
But replacing operator new is a global property of the program. It seems to me
that any translation unit claiming that operator new is sane must imply that
it's sane globally.
It doesn't make sense for a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #9 from Jan Hubicka ---
Doing global flag has a problem since with LTO or using optimize
attribute user may mix code compiled with and without sane operator new.
When function with insane operator new gets inlined to a function wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #8 from user202729 ---
(In reply to Jonathan Wakely from comment #7)
> Thanks for the patch, but patch review happens on the mailing list, not in
> bugzilla. Please repost to gcc-patches as documented in the submission
> guidelines,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #7 from Jonathan Wakely ---
Thanks for the patch, but patch review happens on the mailing list, not in
bugzilla. Please repost to gcc-patches as documented in the submission
guidelines, thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
user202729 changed:
What|Removed |Added
CC||user202729 at protonmail dot
com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #5 from rguenther at suse dot de ---
On Wed, 2 Aug 2023, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
>
> --- Comment #4 from Jonathan Wakely ---
> Why would that depend on this new option?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #4 from Jonathan Wakely ---
Why would that depend on this new option? It's a requirement of the standard,
it has to be true always.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #3 from AK ---
1. clang also has noalias on nothrow versions of operator new. will
`-fassume-sane-operator-new` enable that as well?
2. as per: http://eel.is/c++draft/basic.stc.dynamic#allocation-2
"""If the request succeeds, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
CC|jwakely at redha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
Richard Biener changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
37 matches
Mail list logo
