https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #29 from Martin Jambor ---
(In reply to Jakub Jelinek from comment #28)
> So fixed for GCC 11 now?
Yes, it should be fixed in GCC 11.
We talked about backporting the patches to GCC 10 with Richi on IRC today and
decided to wait for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #28 from Jakub Jelinek ---
So fixed for GCC 11 now?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #27 from CVS Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:f225c6b0c50dc472e0b73b440b572a3bf1514020
commit r11-7817-gf225c6b0c50dc472e0b73b440b572a3bf1514020
Author: Martin Jambor
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #25 from Martin Jambor ---
I have proposed a patch for the IPA-CP part on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566333.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #24 from Martin Jambor ---
*** Bug 99194 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
Richard Biener changed:
What|Removed |Added
Assignee|rguenth at gcc dot gnu.org |jamborm at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #22 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:1a2a7096e5e20d736c6138179470b21aa5a74864
commit r11-7296-g1a2a7096e5e20d736c6138179470b21aa5a74864
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #21 from rguenther at suse dot de ---
On Fri, 19 Feb 2021, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
>
> --- Comment #20 from Jakub Jelinek ---
> I think you don't want variably_modified_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #20 from Jakub Jelinek ---
I think you don't want variably_modified_type_p, that returns true even for
pointers to VLAs (and references etc., perhaps many times indirectly).
I think those should be fine, they are used fairly often unl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #19 from Martin Jambor ---
(In reply to Richard Biener from comment #17)
> there's variably_modified_type_p (you can pass NULL_TREE for the fndecl)
> which is more to the point. Otherwise it looks reasonable. Does IPA CP
> do things
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #18 from Richard Biener ---
Created attachment 50220
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50220&action=edit
patch
I am testing the following for the inline issue for the last testcase, leaving
the IPA CP one to you.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #17 from Richard Biener ---
(In reply to Martin Jambor from comment #16)
> For the IPA-CP ICE, I am still running some tests, but I am currently
> leaning towards the following. It might in theory disable IPA-CP in some
> strange K&R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #16 from Martin Jambor ---
For the IPA-CP ICE, I am still running some tests, but I am currently leaning
towards the following. It might in theory disable IPA-CP in some strange K&R
corner cases (I am searching for those with the tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #15 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:7ee164dcfe390fc030028db9112d44255637b1aa
commit r11-7278-g7ee164dcfe390fc030028db9112d44255637b1aa
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #14 from Martin Jambor ---
Like with the following, which seems to work as far as inlining is concerned,
but the latest Jakub's example ICEs when cloning for IPA-CP :-/ (I am also not
sure if the predicate to identify VLAs is the bes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #13 from Martin Jambor ---
I think that you want to disable inlining in the case when the callee has a
formal parameter which is a VLA (as opposed to a VLA actual argument of a
call), probably in inline_forbidden_p. When just the cal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #12 from Jakub Jelinek ---
E.g.
static int foo ();
int
bar (int n)
{
return foo (n, 2.0);
}
static inline int
foo (int n, struct T { char a[n]; } b)
{
int r = 0, i;
for (i = 0; i < n; i++)
r += b.a[i];
return r;
}
ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #11 from Jakub Jelinek ---
And one case is not covered, callee like foo in #c2, but caller passing non-VLA
argument (whatever, a double, struct S { char a[4]; }, int, etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #10 from Richard Biener ---
Like with
diff --git a/gcc/ipa-fnsummary.c b/gcc/ipa-fnsummary.c
index e32e69cd3ad..ac85be741b1 100644
--- a/gcc/ipa-fnsummary.c
+++ b/gcc/ipa-fnsummary.c
@@ -2775,7 +2775,12 @@ analyze_function_body (stru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #9 from Richard Biener ---
(In reply to Jakub Jelinek from comment #2)
> Another, still undefined, but perhaps slightly less so, testcase is:
> static int foo ();
>
> int
> bar (int n)
> {
> struct S { char a[n]; } x;
> __builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
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=99122
--- Comment #7 from Jakub Jelinek ---
(In reply to Martin Jambor from comment #6)
> > For punting on inlining these, I couldn't find any spot that would try to
> > verify at least remote compatibility of the passed in arguments and the
> > argume
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #6 from Martin Jambor ---
(In reply to Jakub Jelinek from comment #5)
> That could perhaps work for the #c0 testcase where the function actually has
> a non-VL parameter and so garbage in garbage out.
> But would that work also for #c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #5 from Jakub Jelinek ---
That could perhaps work for the #c0 testcase where the function actually has a
non-VL parameter and so garbage in garbage out.
But would that work also for #c2?
If one dumps the #c2 testcase with -O2 -fno-inl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #4 from Martin Jambor ---
With the patch from comment #3, the following sequence with the problematic
call:
x.1_26 = __builtin_alloca_with_align (_24, 8);
g (WITH_SIZE_EXPR <*x.1_26, _22>, WITH_SIZE_EXPR <*x.1_26, _22>);
__buil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #3 from Martin Jambor ---
Looking at how expr.c deals with WITH_SIZE_EXPR, perhaps we should do something
like the following:
diff --git a/gcc/tree-inline.c b/gcc/tree-inline.c
index a710fa59027..cdabeb6bafd 100644
--- a/gcc/tree-inl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #2 from Jakub Jelinek ---
Another, still undefined, but perhaps slightly less so, testcase is:
static int foo ();
int
bar (int n)
{
struct S { char a[n]; } x;
__builtin_memset (x.a, 0, n);
return foo (n, x);
}
static inline in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2021-02-16
Ever confirmed|0
29 matches
Mail list logo
