: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: kugan at gcc dot gnu.org
Target Milestone: ---
Created attachment 60058
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60058&action=edit
testcase
ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117782
kugan at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117782
--- Comment #9 from kugan at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #8)
> Can you try again now that PR 117350 has actually been pushed?
Thanks. This fixes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117782
--- Comment #6 from kugan at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #5)
> Specifically see
> https://inbox.sourceware.org/gcc-patches/20241031204043.3231740-1-ak@linux.
> intel.com/T/#u .
>
> You need to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117782
--- Comment #2 from kugan at gcc dot gnu.org ---
--- a/gcc/cp/mangle.cc
+++ b/gcc/cp/mangle.cc
@@ -1194,6 +1194,7 @@ write_unscoped_name (const tree decl)
in a local function scope. A lambda can also be mangled in the
scope of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117782
--- Comment #1 from kugan at gcc dot gnu.org ---
Created attachment 59705
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59705&action=edit
profile gcov
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kugan at gcc dot gnu.org
Target Milestone: ---
Created attachment 59704
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59704&action=edit
testcase
(gdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117050
kugan at gcc dot gnu.org changed:
What|Removed |Added
CC||kugan at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116785
--- Comment #14 from kugan at gcc dot gnu.org ---
(In reply to Richard Biener from comment #13)
> Did it help?
Thanks for the quick Fix. This commit brings back most of the regression.
Please note that the current trunk seems to be broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116785
--- Comment #10 from kugan at gcc dot gnu.org ---
Created attachment 59186
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59186&action=edit
reduced test (second attempt)
Sorry about the test case. Here is another attempt at reducing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116785
--- Comment #2 from kugan at gcc dot gnu.org ---
Created attachment 59155
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59155&action=edit
creduce reduced file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116785
--- Comment #1 from kugan at gcc dot gnu.org ---
Created attachment 59154
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59154&action=edit
preprocessed file
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kugan at gcc dot gnu.org
Target Milestone: ---
Some of the loops in RAJAPerf are not vectored with the change. This results in
~64% regression for this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115258
kugan at gcc dot gnu.org changed:
What|Removed |Added
CC||kugan at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116626
--- Comment #1 from kugan at gcc dot gnu.org ---
Looks duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116569
Assignee: unassigned at gcc dot gnu.org
Reporter: kugan at gcc dot gnu.org
Target Milestone: ---
Created attachment 59057
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59057&action=edit
testcase
For a partally reduced code, I am seeing:
t.cpp:350:12: internal compile
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: kugan at gcc dot gnu.org
Target Milestone: ---
typedef int real_t;
extern __attribute__((aligned(64))) real_t a[32000],b[32000],c[32000],d[32000];
void s4117()
{
for (int i = 0; i
Assignee: unassigned at gcc dot gnu.org
Reporter: kugan at gcc dot gnu.org
Target Milestone: ---
See:
typedef float real_t;
extern __attribute__((aligned(64))) real_t a[32000];
real_t not_woring(struct args_t *func_args) {
int k, index;
int inc = 1;
real_t max, chksum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116338
--- Comment #5 from kugan at gcc dot gnu.org ---
(In reply to Richard Biener from comment #4)
> You can try to see whether adding a SSA copy would make this supported, it
> seems not allowing a PHI is simply a missed feature.
We now f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116338
--- Comment #3 from kugan at gcc dot gnu.org ---
(In reply to Richard Biener from comment #2)
> The issue is the recurrence
>
>[local count: 10737416]:
> x_10 = b[31999];
> y_11 = b[31998];
>
>[local count: 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
--- Comment #20 from kugan at gcc dot gnu.org ---
(In reply to Richard Sandiford from comment #19)
> (In reply to Richard Biener from comment #14)
> > Usually targets do have a limit on the actual length
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kugan at gcc dot gnu.org
Target Milestone: ---
reduced test case:
typedef float real_t;
extern __attribute__((aligned(64))) real_t a[32000], b[32000];
void s255()
{
real_t x, y;
x = b[32000 -1
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: kugan at gcc dot gnu.org
Target Milestone: ---
For:
extern __attribute__((aligned(64))) int a[32000],b[32000];
void s1112(void)
{
for (int i = 32000 - 1; i >= 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115450
--- Comment #2 from kugan at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #1)
> >[r15-1006-gd93353e6423eca] Do single-lane SLP discovery for reductions
>
>
> Interesting because PR 115256 bisect it to an earlier p
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kugan at gcc dot gnu.org
Target Milestone: ---
5022.gcc is meicompiling for aarch64 with -O3 -Wl,-z,muldefs -lm
-fallow-argument-mismatch -fpermissive -fstack-arrays -flto
-Wl,--sort-section=name -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115383
--- Comment #6 from kugan at gcc dot gnu.org ---
(In reply to kugan from comment #5)
> (In reply to Richard Biener from comment #4)
> > Created attachment 58378 [details]
> > patch
> >
> > I'm testing this, bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115383
--- Comment #5 from kugan at gcc dot gnu.org ---
(In reply to Richard Biener from comment #4)
> Created attachment 58378 [details]
> patch
>
> I'm testing this, but I do not have hardware to test correctness (and qemu
> not
Assignee: unassigned at gcc dot gnu.org
Reporter: kugan at gcc dot gnu.org
Target Milestone: ---
Patch [PATCH 1/4] Relax COND_EXPR reduction vectorization SLP restriction seem
to cause ICE while building TSVC_2
Reduced test:
cat tsvc_vec.i
void dummy();
void s331() {
int j
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
--- Comment #18 from kugan at gcc dot gnu.org ---
Also, can we set INT_MAX when there is no explicit safelen specified in OMP.
Something like:
--- a/gcc/omp-low.cc
+++ b/gcc/omp-low.cc
@@ -6975,14 +6975,11 @@ lower_rec_input_clauses (tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
--- Comment #12 from kugan at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #11)
> (In reply to kugan from comment #9)
> > Looking at the options, looks to me that making loop->safelen a poly_in is
> > the way t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
--- Comment #10 from kugan at gcc dot gnu.org ---
Created attachment 57946
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57946&action=edit
patch
patch to make loop->safelen a poly_int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
--- Comment #9 from kugan at gcc dot gnu.org ---
Looking at the options, looks to me that making loop->safelen a poly_in is the
way to go. (In reply to Jakub Jelinek from comment #4)
> The OpenMP safelen clause argument is a scalar integ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 114653, which changed state.
Bug 114653 Summary: Not vectorizing the loop with openmp reduction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114653
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
kugan at gcc dot gnu.org changed:
What|Removed |Added
CC||kugan at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114653
kugan at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114653
--- Comment #5 from kugan at gcc dot gnu.org ---
ddd for the :
ref_a:
_57 = D.4803[_20];
ref_b:
D.4803[_20] = _ifc__174;
We get DDR_ARE_DEPENDENT (ddr) == chrec_dont_know. Hence apply_safelen ().
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114653
--- Comment #4 from kugan at gcc dot gnu.org ---
This particular loop has loop->safelen set to 16. Does this mean this can never
be loop vectorized for VLA?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114653
--- Comment #3 from kugan at gcc dot gnu.org ---
For SVE mode in vect_analyze_loop_2, we have
(gdb) p min_vf
$15 = {coeffs = {4, 4}}
(gdb) p max_vf
$16 = 16
Thus maybe_lt (max_vf, min_vf)) is false. This results in bad data dependence.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114653
--- Comment #2 from kugan at gcc dot gnu.org ---
Thanks. I see the following in the log:
test.cpp:33:53: missed: not vectorized: relevant stmt not supported: _54 =
.MASK_LOAD (_53, 32B, _171);
test.cpp:22:19: missed: bad operation or
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: kugan at gcc dot gnu.org
Target Milestone: ---
Created attachment 57910
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57910&action=edit
testcase
Main loop in the attached test case is not vectoriz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #5 from kugan at gcc dot gnu.org ---
-O3 -fno-tree-vectorize and -O3 -fno-tree-vrp works. I looked at the ever
dump and it is not doing anything suspicious. Looks like range_info usage in
vectoriser is causing the problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113698
--- Comment #4 from kugan at gcc dot gnu.org ---
Thanks for looking into this. The main reason we ere seeing performance issue
turned out to be due to glibc malloc issue in
https://sourceware.org/bugzilla/show_bug.cgi?id=30945
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: kugan at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Created attachment 57275
--> https://gcc.gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47785
kugan at gcc dot gnu.org changed:
What|Removed |Added
CC||kugan at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91468
kugan at gcc dot gnu.org changed:
What|Removed |Added
CC||kugan at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88834
--- Comment #21 from kugan at gcc dot gnu.org ---
(In reply to Christophe Lyon from comment #20)
> Hi Kugan,
>
> The new test fails with -mabi=ilp32:
> FAIL: gcc.target/aarch64/pr88834.c scan-assembler-times \\tld2w\\t{z[0-9]+.s
&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88838
--- Comment #6 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Thu Jun 13 03:34:28 2019
New Revision: 272233
URL: https://gcc.gnu.org/viewcvs?rev=272233&root=gcc&view=rev
Log:
gcc/ChangeLog:
2019-06-13 Kugan Vivekana
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88834
--- Comment #19 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Thu Jun 13 03:18:54 2019
New Revision: 272232
URL: https://gcc.gnu.org/viewcvs?rev=272232&root=gcc&view=rev
Log:
gcc/ChangeLog:
2019-06-13 Kugan Vivekana
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88834
--- Comment #17 from kugan at gcc dot gnu.org ---
(In reply to Wilco from comment #16)
> (In reply to kugan from comment #15)
> > (In reply to Wilco from comment #11)
> > > There is also something odd with the way the loop iter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88834
--- Comment #15 from kugan at gcc dot gnu.org ---
(In reply to Wilco from comment #11)
> There is also something odd with the way the loop iterates, this doesn't
> look right:
>
> whilelo p0.s, x3, x4
> incw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88834
--- Comment #14 from kugan at gcc dot gnu.org ---
Created attachment 46104
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46104&action=edit
testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88834
kugan at gcc dot gnu.org changed:
What|Removed |Added
Attachment #46040|0 |1
is obsolete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88834
--- Comment #12 from kugan at gcc dot gnu.org ---
(In reply to rsand...@gcc.gnu.org from comment #10)
> (In reply to kugan from comment #9)
> > Created attachment 46040 [details]
> > patch
>
> Wasn't sure whether this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89862
--- Comment #4 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Sat Mar 30 04:28:51 2019
New Revision: 270031
URL: https://gcc.gnu.org/viewcvs?rev=270031&root=gcc&view=rev
Log:
2019-03-29 Kugan Vivekanandarajah
Backp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89862
--- Comment #3 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Sat Mar 30 04:24:22 2019
New Revision: 270030
URL: https://gcc.gnu.org/viewcvs?rev=270030&root=gcc&view=rev
Log:
2019-03-29 Kugan Vivekanandarajah
Eric
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89862
--- Comment #2 from kugan at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #1)
> Can you try this instead?
>
> Index: rtl.h
> ===
> --- rtl.h (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88834
kugan at gcc dot gnu.org changed:
What|Removed |Added
Attachment #45686|0 |1
is obsolete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88834
--- Comment #8 from kugan at gcc dot gnu.org ---
(In reply to rsand...@gcc.gnu.org from comment #7)
> Thanks for looking at this.
>
> (In reply to kugan from comment #6)
> > cmp w3, 0
> > ble .L1
>
Assignee: unassigned at gcc dot gnu.org
Reporter: kugan at gcc dot gnu.org
Target Milestone: ---
Created attachment 46039
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46039&action=edit
patch
With the commit:
commit 67c18bce7054934528ff5930cca283b4ac967dca
Author: eb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88838
--- Comment #5 from kugan at gcc dot gnu.org ---
Created attachment 46000
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46000&action=edit
RFC patch
RFC patch fixes this for review.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88836
--- Comment #2 from kugan at gcc dot gnu.org ---
Created attachment 45795
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45795&action=edit
RFC patch
AFIK, we need to:
1. Change the whilelo pattern in backend
2. Change RTL CSE
- Add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88838
--- Comment #4 from kugan at gcc dot gnu.org ---
sorry wr(In reply to kugan from comment #3)
> Created attachment 45794 [details]
> RFC patch
Oops wrong place, it should be for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88836
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88838
--- Comment #3 from kugan at gcc dot gnu.org ---
Created attachment 45794
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45794&action=edit
RFC patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88838
kugan at gcc dot gnu.org changed:
What|Removed |Added
CC||kugan at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88834
--- Comment #6 from kugan at gcc dot gnu.org ---
>
> Note the difference in mode for aarch64_classify_address. Not sure if this
> is because of the way my patch changes ivopt.
Yes, it ws my mistake in iv-use. with attached patch,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88834
kugan at gcc dot gnu.org changed:
What|Removed |Added
Attachment #45661|0 |1
is obsolete
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kugan at gcc dot gnu.org
Target Milestone: ---
void test_func(void) {
int loop; // uninitialized and "garbage"
while (!loop) {
loop = get_a_value(); // <- must be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88834
--- Comment #4 from kugan at gcc dot gnu.org ---
Created attachment 45661
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45661&action=edit
ivopt patch v1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88834
--- Comment #3 from kugan at gcc dot gnu.org ---
I added iv-use for MASKED_LOAD_LANE and the result is
cmp w3, 0
ble .L1
sub w5, w3, #1
mov x4, 0
lsr w5, w5, 1
add w5, w5, 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88834
kugan at gcc dot gnu.org changed:
What|Removed |Added
CC||kugan at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88333
kugan at gcc dot gnu.org changed:
What|Removed |Added
CC||kugan at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88350
kugan at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88350
kugan at gcc dot gnu.org changed:
What|Removed |Added
Alias|PR88333 |
--- Comment #2 from kugan at
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: kugan at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kugan at gcc dot gnu.org
Target Milestone: ---
When compiling the following on aarch64 with -O2:
#include
void g(int32_t *p, int32x2x2_t val, int x)
{
vst2_lane_s32(p,val,0);
}
generates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86677
--- Comment #13 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Mon Nov 12 23:43:56 2018
New Revision: 266039
URL: https://gcc.gnu.org/viewcvs?rev=266039&root=gcc&view=rev
Log:
gcc/ChangeLog:
2018-11-13 Kugan Vivekana
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87528
--- Comment #7 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Mon Nov 12 23:43:56 2018
New Revision: 266039
URL: https://gcc.gnu.org/viewcvs?rev=266039&root=gcc&view=rev
Log:
gcc/ChangeLog:
2018-11-13 Kugan Vivekana
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87469
--- Comment #5 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Mon Oct 29 22:02:45 2018
New Revision: 265605
URL: https://gcc.gnu.org/viewcvs?rev=265605&root=gcc&view=rev
Log:
gcc/testsuite/ChangeLog:
2018-10-29 Kugan Vivekana
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87469
--- Comment #4 from kugan at gcc dot gnu.org ---
In the loop here, the value defined in the loop (e) is used outside the loop
hence this should not be detected as popcount (AFIK). I will have a look at
fixing this.
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: kugan at gcc dot gnu.org
Target Milestone: ---
Python-2.7.15
Steps to reproduce error
In Python src directory:
./configure
make
./python Lib/test/regrtest.py -v test_ctypes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86677
--- Comment #2 from kugan at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> The kernel simply has to provide __popcount{s,d}i2 like it provides other
> libgcc functions if it chooses to not link against libgcc.
Yes, I c
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: kugan at gcc dot gnu.org
Target Milestone: ---
Linux kernel build for arm/aarch64 (and possibly other targets) which does not
provide appropriate patterns in the backend will break the kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86544
--- Comment #4 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Wed Jul 18 22:11:24 2018
New Revision: 262864
URL: https://gcc.gnu.org/viewcvs?rev=262864&root=gcc&view=rev
Log:
gcc/ChangeLog:
2018-07-18 Kugan Vivekana
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86544
--- Comment #2 from kugan at gcc dot gnu.org ---
Patch posted at https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00975.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86544
--- Comment #1 from kugan at gcc dot gnu.org ---
(In reply to ktkachov from comment #0)
> Great to see that GCC now detects the popcount loop in PR 82479!
> I am seeing some curious differences between gcc and g++ though.
> int
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86489
--- Comment #7 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Fri Jul 13 05:25:47 2018
New Revision: 262622
URL: https://gcc.gnu.org/viewcvs?rev=262622&root=gcc&view=rev
Log:
gcc/ChangeLog:
2018-07-13 Kugan Vivekana
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86489
--- Comment #3 from kugan at gcc dot gnu.org ---
(In reply to Richard Biener from comment #2)
> gimple *phi = SSA_NAME_DEF_STMT (b_11);
> if (gimple_code (phi) != GIMPLE_PHI
> || (gimple_assign_lhs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86489
--- Comment #1 from kugan at gcc dot gnu.org ---
Sorry about the breakage, I am trying to reproduce it on x86-64. Please let me
know if you have testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82479
--- Comment #13 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Sat Jun 16 21:39:31 2018
New Revision: 261682
URL: https://gcc.gnu.org/viewcvs?rev=261682&root=gcc&view=rev
Log:
gcc/ChangeLog:
2018-06-16 Kugan Vivekana
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64946
--- Comment #24 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Sat Jun 16 21:34:29 2018
New Revision: 261681
URL: https://gcc.gnu.org/viewcvs?rev=261681&root=gcc&view=rev
Log:
gcc/ChangeLog:
2018-06-16 Kugan Vivekana
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78387
kugan at gcc dot gnu.org changed:
What|Removed |Added
CC||kugan at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82555
kugan at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82555
--- Comment #5 from kugan at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #4)
> Actually PR 78387 seems exactly this issue. Please test with a newer
> version of gfortran.
Thanks Andrew. Looks like this is the issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82555
--- Comment #1 from kugan at gcc dot gnu.org ---
My gcc is slightly old.
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/kugan.vivekanandarajah/install/test/usr/local/bin/../libexec/gcc/aarch64-unknown-linux-gnu/8.0.0/lto
Assignee: unassigned at gcc dot gnu.org
Reporter: kugan at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Wrf_s is hanging or deadlocks when run on 48 threads (cores). It doesnt always
happen and I have to run with --iterations=111 and it will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82479
--- Comment #4 from kugan at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #2)
> Confirmed. How useful this optimization is questionable.
This code is part of spec2017/deepsjeng. There is some gain if we can.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82479
--- Comment #1 from kugan at gcc dot gnu.org ---
gcc trunk generates:
PopCount:
mov w2, 0
cbz x0, .L1
.p2align 3
.L3:
sub x1, x0, #1
add w2, w2, 1
andsx0, x0, x1
bne
-end
Assignee: unassigned at gcc dot gnu.org
Reporter: kugan at gcc dot gnu.org
Target Milestone: ---
gcc does not have support to detect builtin pop count. As a results, gcc
generates bad code for
int PopCount (long b) {
int c = 0;
while (b) {
b &= b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81558
--- Comment #2 from kugan at gcc dot gnu.org ---
> Does LLVM do a runtime alias check here? For foo1 GCC adds a runtime alias
> check
> (BB vectorization cannot version for aliasing).
Yes. LLVM does not seem to be unrolling the inner
Assignee: unassigned at gcc dot gnu.org
Reporter: kugan at gcc dot gnu.org
Target Milestone: ---
For the testcase:
struct I
{
int opix_x;
int opix_y;
};
//#define R
#define R __restrict__
extern struct I * R img;
extern unsigned short ** R imgY_org;
extern unsigned short orig_blocks
1 - 100 of 276 matches
Mail list logo
