https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106833
--- Comment #8 from Kewen Lin ---
Created attachment 53542
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53542=edit
Specially handle opaque type in verify_type
(In reply to Segher Boessenkool from comment #7)
> (In reply to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106833
--- Comment #5 from Kewen Lin ---
> > I'm quoting tree.def, emphasis mine:
> >
> > /* This is for types that will use MODE_OPAQUE in the back end. They are
> > meant
> >to be able to go in a register of some sort but are _EXPLICITLY NOT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106833
--- Comment #4 from Kewen Lin ---
(In reply to Richard Biener from comment #2)
> (In reply to Kewen Lin from comment #1)
> > IMHO this is an omission when we were adding supports for opaque type, const
> > __vector_quad and __vector_quad should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106833
Kewen Lin changed:
What|Removed |Added
Keywords||ice-checking
CC|
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
This is from one encountered ICE when using const type:
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600751.html
As the above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106682
Kewen Lin changed:
What|Removed |Added
Component|target |testsuite
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736
Kewen Lin changed:
What|Removed |Added
Attachment #53513|0 |1
is obsolete|
|1
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
Last reconfirmed||2022-08-29
--- Comment #2 from Kewen Lin ---
Confirmed, I can reproduce it with cfarm machine gcc110, the issue is exactly
like what its comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106682
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=106736
--- Comment #7 from Kewen Lin ---
(In reply to Peter Bergner from comment #5)
> (In reply to Kewen Lin from comment #4)
> > Thanks for the comments! One patch guarding these types is attached, it can
> > fix the ICE.
>
> That won't work,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736
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=106736
Kewen Lin changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888
--- Comment #11 from Kewen Lin ---
Oops, the reference links in #c10 are:
[1] https://gcc.gnu.org/pipermail/gcc-patches/2016-September/458210.html
[2] https://gcc.gnu.org/pipermail/gcc-patches/2016-September/458287.html
[3]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888
--- Comment #10 from Kewen Lin ---
By searching the history of this feature, I found its initial versions only
proposed to place nops after the function entry, such as: v2[1], then it's
requested to be more generic to handle some "exploited
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #49 from Kewen Lin ---
Hi Richi,
One thing I'm not sure about is that if we want to backport this to gcc-11 and
gcc-10? Although the failure got exposed by .MULH pattern recog which is only
in gcc-12, IMHO the underlying issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103353
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106516
--- Comment #7 from Kewen Lin ---
(In reply to Peter Bergner from comment #6)
> (In reply to Kewen Lin from comment #5)
> > Created attachment 53492 [details]
> > Adjust pr104992.c with vect_int_mod
> >
> > > So it sounds like we want a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106516
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=106680
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106516
Kewen Lin changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106681
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106345
--- Comment #9 from Kewen Lin ---
(In reply to Michael Meissner from comment #8)
> Note, the gcc.target/powerpc/pr92398.p9-.c test fails when the compiler is
> configured for either --with-cpu=power9 or --with-cpu=power10. No
> --with-tune=
at gcc dot gnu.org |linkw at gcc dot gnu.org
--- Comment #2 from Kewen Lin ---
By checking the related materials and discussions, I think the original issue
does still exist even if the recent trunk makes the linking error gone because
of comdat flag being introduced onto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
Kewen Lin changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #45 from Kewen Lin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99889
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
Ever confirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888
--- Comment #6 from Kewen Lin ---
(In reply to Fangrui Song from comment #5)
> * There is a restriction on the number of instructions between the function
> label and the .localentry directive.
> * For -fpatchable-function-entry=N[,M], M nops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #44 from Kewen Lin ---
(In reply to Richard Biener from comment #43)
> (In reply to Richard Biener from comment #42)
> > I think this goes wrong in vectorizable_operation which does
> >
> > if (using_emulated_vectors_p
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #41 from Kewen Lin ---
(In reply to Kewen Lin from comment #40)
> > >diff --git a/gcc/internal-fn.cc b/gcc/internal-fn.cc
> > >index d666f67..7d8b4ac2200 100644
> > >--- a/gcc/internal-fn.cc
> > >+++ b/gcc/internal-fn.cc
> > >@@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #40 from Kewen Lin ---
> >diff --git a/gcc/internal-fn.cc b/gcc/internal-fn.cc
> >index d666f67..7d8b4ac2200 100644
> >--- a/gcc/internal-fn.cc
> >+++ b/gcc/internal-fn.cc
> >@@ -3750,7 +3750,12 @@ static bool
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #38 from Kewen Lin ---
Created attachment 53428
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53428=edit
untested patch
A untested patch which can make it pass.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #37 from Kewen Lin ---
(In reply to Andrew Pinski from comment #36)
> You might need to do -O2 -fPIE -pie to reproduce the issue as debian is
> configured with --enable-default-pie
Thanks for the hint! I can reproduce this but it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #32 from Kewen Lin ---
(In reply to Mathieu Malaterre from comment #30)
> (In reply to Martin Liška from comment #29)
> > (In reply to Kewen Lin from comment #28)
> > > Sorry for the breakage, I'll have a look tomorrow.
> > >
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
Kewen Lin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
||linkw at gcc dot gnu.org
Summary|[rs6000] sub-optimal|[rs6000] sub-optimal 64bit
|constant generation |constant generation for P10
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888
--- Comment #4 from Kewen Lin ---
(In reply to Segher Boessenkool from comment #3)
> Your second option isn't correct: all these nops should be consecutive. Your
> option 1 is fine :-)
Good point! It's lucky that I chose option 1. :)
||linkw at gcc dot gnu.org
Last reconfirmed||2022-08-04
Status|UNCONFIRMED |NEW
--- Comment #2 from Kewen Lin ---
Confirmed, this is a test issue, power10 and up specific.
The difference comes from the function thud, it aims
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888
--- Comment #2 from Kewen Lin ---
Created attachment 53405
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53405=edit
untested patch
With the attached patch, for -fpatchable-function-entry=5,2 it gets:
foo:
.LFB0:
.cfi_startproc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106069
--- Comment #23 from Kewen Lin ---
> Ideally we would avoid semantic difference of RTL depending on the target.
> If that's not avoidable there should be target macros/hooks that specify
> the desired semantics.
Not sure, IMHO it seems it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106069
--- Comment #21 from Kewen Lin ---
I didn't look into this in details, but something in the culprit commit caught
my eyes, take altivec_vmrghh as example:
Before the patch, the pattern
[(set (match_operand:V8HI 0 "register_operand" "=v")
|--- |WORKSFORME
CC||linkw at gcc dot gnu.org
--- Comment #3 from Kewen Lin ---
Marked resolved as Arseny's latest comment.
|1
CC||linkw at gcc dot gnu.org
Last reconfirmed||2022-08-03
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
--- Comment #1 from Kewen Lin ---
cat test.c
extern int a;
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106091
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106419
--- Comment #9 from Kewen Lin ---
(In reply to Segher Boessenkool from comment #8)
> So for which pseudo and which hard register did this ICE, and what did the
> code look like at that point?
The culprit pseudo is r133, the values of those
|--- |DUPLICATE
CC||linkw at gcc dot gnu.org
--- Comment #4 from Kewen Lin ---
See comment 1 of PR106345, it's due to incorrect effective target checking.
*** This bug has been marked as a duplicate of bug 106345 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106345
Kewen Lin changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106419
Kewen Lin changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106419
Kewen Lin changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #5 from Kewen Lin ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106415
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106419
--- Comment #3 from Kewen Lin ---
(In reply to Arseny Solokha from comment #2)
> I don't set --enable-default-pie anymore when configuring gcc, so here's the
> difference. Therefore, it stops ICEing if I add -fPIE or -fPIC when
> compiling the
|1
Status|UNCONFIRMED |WAITING
CC||linkw at gcc dot gnu.org
--- Comment #1 from Kewen Lin ---
I wasn't able to reproduce this with cross build compiler w/i either latest
trunk or the mentioned snapshot. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106010
Kewen Lin changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106396
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106378
--- Comment #2 from Kewen Lin ---
(In reply to Richard Biener from comment #1)
> Created attachment 53330 [details]
> patch
>
> I am testing this on x86_64-linux.
I confirmed this attachment can make two case above to get expected optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106365
--- Comment #14 from Kewen Lin ---
> I think that DSE doesn't handle the store IFNs yet - maybe adding handling
> to initialize_ao_ref_for_dse would be enough - but I think it cannot yet
> handle a "conservative" start (for .MASK_STORES), but
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org, rsandifo at gcc dot gnu.org,
segher at gcc dot gnu.org
Depends on: 106365
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106365
--- Comment #12 from Kewen Lin ---
(In reply to Richard Biener from comment #9)
> Created attachment 53328 [details]
> patch
>
Thanks! Sorry that I didn't see this attachment when posting the above
comment.
> + MEM [(int *) + 16B] = { 4,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106365
--- Comment #10 from Kewen Lin ---
(In reply to Richard Biener from comment #7)
> Created attachment 53323 [details]
> prototype
>
> I'm testing this - for .LEN_STORE you mainly have to compute pd.rhs_off,
> pd.offset, pd.size and do a single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106365
--- Comment #6 from Kewen Lin ---
(In reply to Richard Biener from comment #5)
> I will try to add handling for .MASK_STORE, hopefully that will be good
> enough to massage the code for .LEN_STORE (which IIRC is "easier" since it's
> a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106365
--- Comment #3 from Kewen Lin ---
(In reply to Richard Biener from comment #2)
> What's the semantic of .LEN_STORE? I can't find documentation for this :/
> There's docs for the len_store optab but how 'mask' and 'bias' relate to its
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106365
Kewen Lin changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org,
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
In regression testing for the patch to add unroll factor suggestion to
vectorizer for port rs6000, one failure got exposed on Power10 (with partial
vector in length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106345
--- Comment #2 from Kewen Lin ---
Two more failures related to required tuning setting:
PASS->FAIL: gcc.target/powerpc/compress-float-ppc.c scan-assembler lfs
PASS->FAIL: gcc.target/powerpc/compress-float-ppc-pic.c scan-assembler lfs
at gcc dot gnu.org |linkw at gcc dot gnu.org
Ever confirmed|0 |1
CC||linkw at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Kewen Lin ---
Thanks for reporting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106091
--- Comment #3 from Kewen Lin ---
Created attachment 53268
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53268=edit
tested patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106091
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105940
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105940
--- Comment #8 from Kewen Lin ---
(In reply to Kewen Lin from comment #6)
> (In reply to Kewen Lin from comment #4)
> > (In reply to Richard Biener from comment #2)
> > > (In reply to Kewen Lin from comment #1)
> > > > Created attachment 53126
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105940
Kewen Lin changed:
What|Removed |Added
Attachment #53126|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105940
--- Comment #6 from Kewen Lin ---
(In reply to Kewen Lin from comment #4)
> (In reply to Richard Biener from comment #2)
> > (In reply to Kewen Lin from comment #1)
> > > Created attachment 53126 [details]
> > > move_applying
> >
> > LGTM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105940
--- Comment #4 from Kewen Lin ---
(In reply to Richard Biener from comment #2)
> (In reply to Kewen Lin from comment #1)
> > Created attachment 53126 [details]
> > move_applying
>
> LGTM (maybe the suggested unroll factor should be only
|1
Last reconfirmed||2022-06-13
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
CC||rguenth at gcc dot gnu.org,
||rsandifo at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105940
--- Comment #1 from Kewen Lin ---
Created attachment 53126
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53126=edit
move_applying
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
I tried to evaluate if we can get some performance gains by setting
suggested_unroll_factor on Power, but met one ICE coming from the line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105818
--- Comment #3 from Kewen Lin ---
The different flag bit is OPTION_MASK_SAVE_TOC_INDIRECT.
if ((rs6000_isa_flags_explicit & OPTION_MASK_SAVE_TOC_INDIRECT) == 0
&& flag_shrink_wrap_separate
&& optimize_function_for_speed_p (cfun))
|1
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
CC||linkw at gcc dot gnu.org
Target|powerpc-e300c3-linux-gnu|powerpc*-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103320
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105459
--- Comment #12 from Kewen Lin ---
Created attachment 53068
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53068=edit
tested patch
Once the optimization node of the caller has changed, we need to rebuild the
target node in the context of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105459
--- Comment #11 from Kewen Lin ---
(In reply to Kewen Lin from comment #9)
> inline_call will force reload global optimization.
>
> /* Reload global optimization flags. */
> if (reload_optimization_node && DECL_STRUCT_FUNCTION (to->decl)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105744
Kewen Lin changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105744
Kewen Lin changed:
What|Removed |Added
CC||tuliom at ascii dot art.br
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105744
--- Comment #2 from Kewen Lin ---
This exposes one bug in glibc strncpy power9 implementation
In
https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=sysdeps/powerpc/powerpc64/le/power9/strncpy.S
lbz r0,0(r4)
stb
||linkw at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2022-05-27
--- Comment #1 from Kewen Lin ---
Can be reproduced without cross build compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105459
--- Comment #10 from Kewen Lin ---
(In reply to Kewen Lin from comment #8)
> (In reply to Kewen Lin from comment #7)
> > I wonder if it's fine to move init_function_start downward after
> > execute_all_ipa_transforms call? the testing is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104482
Kewen Lin changed:
What|Removed |Added
URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105627
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105706
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105706
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=105706
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105459
--- Comment #9 from Kewen Lin ---
inline_call will force reload global optimization.
/* Reload global optimization flags. */
if (reload_optimization_node && DECL_STRUCT_FUNCTION (to->decl) == cfun)
set_cfun (cfun, true);
It looks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105459
--- Comment #8 from Kewen Lin ---
(In reply to Kewen Lin from comment #7)
> I wonder if it's fine to move init_function_start downward after
> execute_all_ipa_transforms call? the testing is ongoing.
This proposed patch was bootstrapped and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103515
--- Comment #6 from Kewen Lin ---
(In reply to Peter Bergner from comment #5)
> (In reply to CVS Commits from comment #4)
> > The master branch has been updated by Kewen Lin :
>
> Kewen, can we mark this as FIXED?
Sorry, no. The issue isn't
at gcc dot gnu.org |linkw at gcc dot gnu.org
--- Comment #2 from Kewen Lin ---
Thanks for reporting and triaging.
Although loops in function rs6000_analyze_swaps only handles NONDEBUG_INSN_P
insns, when doing unionfind_union it's still possible to union with debug insn,
as some def reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105648
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105459
--- Comment #7 from Kewen Lin ---
I wonder if it's fine to move init_function_start downward after
execute_all_ipa_transforms call? the testing is ongoing.
--- a/gcc/cgraphunit.cc
+++ b/gcc/cgraphunit.cc
@@ -1817,7 +1817,6 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105459
Kewen Lin changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
,
||linkw at gcc dot gnu.org
--- Comment #2 from Kewen Lin ---
> Would it be correct to move this test from g++.dg/tsan to g++.target/powerpc
> ? (Or, do I need to move pr69667.C back to its original location? Or, do I
> need to update the path within pr88018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105586
Kewen Lin changed:
What|Removed |Added
CC||jskumari at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105485
--- Comment #4 from Kewen Lin ---
Created attachment 52949
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52949=edit
untested patch
This attached patch can get it fixed. Will test it further and add one test
case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105485
--- Comment #3 from Kewen Lin ---
This issue can happen for any bif which supports overloading.
for example, same ICE for:
typedef __attribute__ ((altivec (vector__))) signed int T;
template void __builtin_vec_splats ();
T b (T i)
{
return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105485
Kewen Lin changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #2 from Kewen Lin
401 - 500 of 894 matches
Mail list logo
