https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105769
--- Comment #15 from rguenther at suse dot de ---
On Tue, 17 Jan 2023, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105769
>
> --- Comment #14 from Jakub Jelinek ---
> Dunno, bet we really want to introduce C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105769
--- Comment #14 from Jakub Jelinek ---
Dunno, bet we really want to introduce CLOBBER(bol) and only consider bol and
eol clobbers for the stack reuse (or e.g. the tree-ssa-live.cc *live_vars*
handling).
Wonder what amount of work it would be to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105769
--- Comment #13 from rguenther at suse dot de ---
On Tue, 17 Jan 2023, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105769
>
> --- Comment #12 from Jakub Jelinek ---
> (In reply to Richard Biener from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105769
--- Comment #12 from Jakub Jelinek ---
(In reply to Richard Biener from comment #10)
> I think that's the usual pattern for the two other stack-slot sharing PRs we
> have. The liveness analysis makes wrong assumptions about CLOBBER and
> CLOBBE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105769
--- Comment #11 from Jakub Jelinek ---
struct S { S *p; S *q; S () {} ~S (); };
void bar (S *);
void
foo ()
{
S a, b;
bar (nullptr);
{
S c;
c.p = &a;
c.q = &b;
bar (&c);
}
bar (nullptr);
}
at -O2 gets roughly the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105769
--- Comment #10 from Richard Biener ---
(In reply to Jakub Jelinek from comment #9)
> And just statements that refer to those 3 variables that (incorrectly) share
> the stack slot + basic block boundaries.
> grep 'bias\|D.5698\|D.5681\|:' /tmp/0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105769
Jakub Jelinek changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105769
--- Comment #8 from Jakub Jelinek ---
Using last night's trunk, it is:
#include
#include
#include
template
struct vec {
T dat[n];
vec() {}
explicit vec(const T& x) { for(size_t i = 0; i < n; i++) dat[i] = x; }
T& operator [](size_t i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105769
--- Comment #7 from Jakub Jelinek ---
Ah, the crash is actually when destructing the map_t temporary (D.5613) and
because it shares the stack slot with bias, it isn't surprising. So now to
figure out why the stack sharing happens and why even -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105769
--- Comment #6 from Jakub Jelinek ---
The expand dump shows:
Partition 4: size 64 align 16
cov_jn
Partition 0: size 48 align 16
D.5642 biasD.5613
Partition 1: size 32 align 16
D.5615
Partition 2: size 32 align 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105769
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105769
--- Comment #4 from Martin Liška ---
Can't reproduce with huge param value with the revision before it was removed:
gcc-bisect.py 'g++ pr105769.ii -flto -O1 -ftree-vectorize --param
slp-max-insns-in-bb=1 && ./a.out' -e
16ad9ae85bb5b9acf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105769
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105769
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.4
Known to work|
14 matches
Mail list logo
