https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
Kewen Lin changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #43 from Kewen Lin ---
Created attachment 56899
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56899&action=edit
Previously reduced case for comment 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #42 from Kewen Lin ---
(In reply to Richard Biener from comment #41)
> What's the "other" testcase? Do we know that doesn't suffer from the same
> uninitialized issue?
For "other" test cases, I guessed he referred to my comment #c3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #41 from Richard Biener ---
(In reply to Mathieu Malaterre from comment #40)
> (In reply to Richard Biener from comment #39)
> > (In reply to Kewen Lin from comment #38)
> > > I found this has been marked as resolved but it seems tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #40 from Mathieu Malaterre ---
(In reply to Richard Biener from comment #39)
> (In reply to Kewen Lin from comment #38)
> > I found this has been marked as resolved but it seems that the patch in
> > comment #34 hasn't been pushed, i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #39 from Richard Biener ---
(In reply to Kewen Lin from comment #38)
> I found this has been marked as resolved but it seems that the patch in
> comment #34 hasn't been pushed, is it intended? or did I miss something that
> one commi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #38 from Kewen Lin ---
I found this has been marked as resolved but it seems that the patch in comment
#34 hasn't been pushed, is it intended? or did I miss something that one commit
was pushed but wasn't associated to this PR?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
Richard Biener changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #36 from Mathieu Malaterre ---
(In reply to Kewen Lin from comment #32)
[...]
> So IMHO #c1 test case is problematic, hi @Mathieu, could you have a double
> check?
I vaguely recall crafting this test-case with cvise with gcc-13. Thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
Richard Biener changed:
What|Removed |Added
Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
Richard Biener changed:
What|Removed |Added
Attachment #56175|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #33 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:97094d2ffd7d00261e6d7cc5d4a62dc7c2c89b64
commit r14-6481-g97094d2ffd7d00261e6d7cc5d4a62dc7c2c89b64
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #32 from Kewen Lin ---
> case pass, but the original test case (#c1) can't pass with this, it can't
> pass with -fstack-reuse=none + -fno-strict-aliasing + -O2 either, I think
> the original case still suffers another latent bug.
We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #31 from Kewen Lin ---
Thanks for the explanation from both of you!
(In reply to Richard Biener from comment #30)
> Created attachment 56175 [details]
> prototype patch
I confirmed that this fix can make test case (#c9 + #c10) and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #30 from Richard Biener ---
Created attachment 56175
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56175&action=edit
prototype patch
This is an (untested) fix, API wise needs some cleanup still. It's the most
simple fix that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
Richard Biener changed:
What|Removed |Added
Assignee|linkw at gcc dot gnu.org |rguenth at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #28
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #27 from Richard Biener ---
(In reply to Kewen Lin from comment #26)
> (In reply to Richard Biener from comment #25)
> > (In reply to Kewen Lin from comment #24)
[...]
> > Ah, probably the alias-set is determined from the unmangled r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #26 from Kewen Lin ---
(In reply to Richard Biener from comment #25)
> (In reply to Kewen Lin from comment #24)
> > (In reply to Richard Biener from comment #22)
> > > I see the mems properly get their base adjusted:
> > >
> > > (in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
Richard Biener changed:
What|Removed |Added
CC||matz at suse dot de
--- Comment #25 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #24 from Kewen Lin ---
(In reply to Richard Biener from comment #22)
> I see the mems properly get their base adjusted:
>
> (insn 384 383 0 (set (mem/c:V2DI (plus:DI (reg/f:DI 112 virtual-stack-vars)
> (const_int 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #23 from Richard Biener ---
A less strict patch would remember whether all accesses to the decls coalesced
have accesses compatible with a common effective type (just checking whether
all decls have the same type isn't enough, even w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #22 from Richard Biener ---
I see the mems properly get their base adjusted:
(insn 384 383 0 (set (mem/c:V2DI (plus:DI (reg/f:DI 112 virtual-stack-vars)
(const_int 16 [0x10])) [7 MEM[(struct Vec128D.30433 *)_10]+0
S1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #21 from Kewen Lin ---
For optimized IR:
a$raw$3_220 = D.39813.rawD.30221[3];
vect_a_raw_4_70.539_1584 = MEM [(short intD.20
*)&D.39813 + 8B];
_1640 = a$raw$0_221 & 255;
_1649 = a$raw$1_74 & 255;
_1658 = a$raw$2_264 & 255
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #20 from Kewen Lin ---
(In reply to Richard Biener from comment #19)
> So maybe it's the same issue as PR90348 (you can verify the RTL expansion
> dump on whether the two involved decls are coalesced and see whether that's
> valid).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #19 from Richard Biener ---
So maybe it's the same issue as PR90348 (you can verify the RTL expansion dump
on whether the two involved decls are coalesced and see whether that's valid).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #18 from Kewen Lin ---
(In reply to Richard Biener from comment #17)
> it stores to a different object - but seeing the CLOBBERs, does
> -fstack-reuse=none fix the issue? Is r1 the stack pointer?
Just tried with -fstack-reuse=none,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #17 from Richard Biener ---
it stores to a different object - but seeing the CLOBBERs, does
-fstack-reuse=none fix the issue? Is r1 the stack pointer?
ref-all is carried to RTL by MEM_ALIAS_SET == 0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #16 from Kewen Lin ---
Tracing down it with template specialization, the aborting happens on
auto vn_b = Load(dn, in_b.get());
HWY_ASSERT_VEC_EQ(
dw, vw_signed_max,
SatWidenMulPairwiseAdd(
dw, InterleaveLow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
Kewen Lin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #14 from Richard Biener ---
(In reply to Kewen Lin from comment #13)
> Thanks again for the reduced test case and the information!
>
> I tried to bisect it but encountered some build failures on _Float32 error
> etc., through greppi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
Kewen Lin changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #13 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #12 from Mathieu Malaterre ---
For reference
malat@perotto ~/pr2 % g++-11 --version
g++-11 (Debian 11.4.0-4) 11.4.0
malat@perotto ~/pr2 % g++-12 --version
g++-12 (Debian 12.3.0-9) 12.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #11 from Mathieu Malaterre ---
(In reply to Kewen Lin from comment #6)
> Confirmed, thanks for reporting.
>
> I noticed that the reduced test case in #c1 can make gcc-13 complain with:
>
> test.cc:67:16: error: expected type-specif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #10 from Mathieu Malaterre ---
Created attachment 55993
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55993&action=edit
widen_mul_test.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #9 from Mathieu Malaterre ---
Created attachment 55992
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55992&action=edit
foo.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #8 from Kewen Lin ---
(In reply to Richard Biener from comment #7)
> I suppose it works with -fno-tree-vectorize ontop of the flags?
Appending -fno-tree-vectorize at the end of the given flags in #c1
(-mstrict-align version), it sti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
Kewen Lin changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
Mathieu Malaterre changed:
What|Removed |Added
Known to work||11.4.0
--- Comment #5 from Mathieu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
Mathieu Malaterre changed:
What|Removed |Added
Known to work||10.5.0
--- Comment #4 from Mathieu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #3 from Mathieu Malaterre ---
I can make the upstream code fails using g++-11 / g++-12 version (Debian/sid).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
Richard Biener changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #2 from Ri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #1 from Mathieu Malaterre ---
Created attachment 55989
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55989&action=edit
cvise reduced test case
% g++ -std=c++11 -o works -DHWY_COMPILE_ONLY_EMU128 -DHWY_BROKEN_EMU128=0
-maltive
44 matches
Mail list logo
