Assignee: unassigned at gcc dot gnu.org
Reporter: belagod at gcc dot gnu.org
On the trunk, gfortran(f951) ICEs when compiled with
.../obj/gcc/f951 .../gcc/gcc/testsuite/gfortran.dg/coarray/alloc_comp_2.f90
-fcoarray=lib -O2
__copy_parent_coarray_component_Child
.../gcc/gcc
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: belagod at gcc dot gnu.org
Hi,
This patch (http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01588.html) seems to
uncover a bug in the vectorizer where it fails to spot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59651
--- Comment #2 from belagod at gcc dot gnu.org ---
Something simliar happens on aarch64, but later goes ahead and vectorizes it
anyway. How about trying to vectorize on x86 with -fno-vect-cost-model?
pr.c:13:7: note
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59651
--- Comment #4 from belagod at gcc dot gnu.org ---
Thanks for looking at this.
Just to clarify, do you mean loop versioning happens in the up-counting loop?
Because in the down-counting loop, a partition seems to be happening with 2
iterations of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59651
--- Comment #6 from belagod at gcc dot gnu.org ---
Thanks for the patch. It fixes this particular test case regression. I've
kicked off a full regression and will let you know the results soon.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59651
--- Comment #7 from Tejas Belagod ---
AArch64 regressions came back OK. Thanks!
Assignee: unassigned at gcc dot gnu.org
Reporter: belagod at gcc dot gnu.org
Target Milestone: ---
For this piece of code:
void foo ()
{
*((long long*)0x2000213F) = 0;
}
when compiled with
$ arm-none-eabi-gcc -S -march=armv7-a /tmp/strd.c -O0 -marm -o -
It generates an
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: belagod at gcc dot gnu.org
Target Milestone: ---
This piece of code:
#include
std::array arr;
int foo (int i)
{
return arr[i];
}
When compiled with:
$ arm-none-eabi-g++ -march=armv7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71607
Tejas Belagod changed:
What|Removed |Added
CC||belagod at gcc dot gnu.org
--- Comment
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: belagod at gcc dot gnu.org
When this piece of code is compiled with
int foo ()
{
short i;
int sum = 0;
for (i=0;i<16;i++)
sum += i;
return sum;
}
cc1 -O2 -ftree-vectorize -fno-tree-s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61114
--- Comment #1 from Tejas Belagod ---
Sorry I meant it fixes this on aarch64_be.
FAIL: gcc.dg/vect/no-scevccp-outer-7.c execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61114
--- Comment #3 from Tejas Belagod ---
Thanks for the clarification. In that case, what element does bit positions
96..127 correspond to in { 120, 0, 0, 0 }?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61114
--- Comment #5 from Tejas Belagod ---
So, does that mean the folded value 120 is in the wrong place? The fix that I'm
testing swaps the first and last elements of the const vector {120, 0, 0, 0}.
PS: Sorry, my statement "The final folded value is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58692
Tejas Belagod changed:
What|Removed |Added
CC||belagod at gcc dot gnu.org
--- Comment
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: belagod at gcc dot gnu.org
Permuted loads/stores implemented in the aarch64 backend do not conform to
AArch64 ABI for bigendian. The ABI states that
"... On a little e
: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
Assignee: unassigned at gcc dot gnu.org
Reporter: belagod at gcc dot gnu.org
On AArch64, when gcc.c-torture/compile/simd-3.c is compiled with -O1, it
generates an ICE.
tempf
Analyzing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59915
--- Comment #1 from Tejas Belagod ---
This regression was introduced with I committed a more relaxed version of
CANNOT_CHANGE_MODE_CLASS for aarch64.
2014-01-20 Tejas Belagod
* config/aarch64/aarch64-protos.h
(aarch64_cannot_change_mo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59959
--- Comment #1 from Tejas Belagod ---
My aarch64-none-linux-gnu-gfortran is configrued with:
/src/gcc/configure --target=aarch64-none-linux-gnu --prefix=
--with-sysroot=/aarch64-none-linux-gnu/libc
--with-build-sysroot=/workdir/rhe5x86_64/aarch64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59959
--- Comment #2 from Tejas Belagod ---
Looks like the same LRA issues are causing libgomp.fortran tests to ICE:
/aarch64-none-linux-gnu/obj/gcc4/gcc/xgcc
-B/aarch64-none-linux-gnu/obj/gcc4/gcc/
src/gcc/libgomp/testsuite/libgomp.fortran/vla3.f90
-B
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: belagod at gcc dot gnu.org
Hi,
On AArch64, I'm seeing a fortran regression that I get when I compile:
.../aarch64-none-linux-gnu/obj/gcc4/gcc/testsuite/gfor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60079
--- Comment #1 from Tejas Belagod ---
Created attachment 32053
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32053&action=edit
Reduced test case for LRA ICE.
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: belagod at gcc dot gnu.org
When the attached case is compiled with -O2 for AArch64, LRA ICEs thus:
$ ../install/bin/aarch64-none-elf-gcc -O2 besttry.c -c
besttry.c: In function 'ripemd160_block_data_order':
bes
||2015-11-18
CC||belagod at gcc dot gnu.org,
||jason at redhat dot com
Ever confirmed|0 |1
--- Comment #1 from Tejas Belagod ---
Confirmed on arm-none-eabi with
: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: belagod at gcc dot gnu.org
This patch:
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01780.html
causes UNSUPPORTED tests to get compiled on AArch64.
FAIL: 21_strings
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: belagod at gcc dot gnu.org
This commit seems to be breaking libstdc++-v3 runs on AArch64.
Author: redi
Date: Fri Dec 19 18:16:39 2014 +
New std::string implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64438
--- Comment #2 from Tejas Belagod ---
(In reply to Jonathan Wakely from comment #1)
> That's strange, it should only affect targets that define
> _GLIBCXX_HAVE_BROKEN_VSWPRINTF i.e. only mingw
>
> What are the full errors in the libstdc++-v3/tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64443
--- Comment #3 from Tejas Belagod ---
(In reply to Andrew Pinski from comment #1)
> >This commit seems to be breaking libstdc++-v3 runs on AArch64.
>
> Is this under Linux or with newlib?
newlib. When run on a fast-model(simulator) they fail by
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: belagod at gcc dot gnu.org
This new pattern
Author: mpolacek
Date: Wed Dec 17 11:48:33 2014 +
PR middle-end/63568
match.pd: Add (x & ~m) | (y & m) -> ((x ^ y) &
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64443
--- Comment #4 from Tejas Belagod ---
(In reply to Andrew Pinski from comment #1)
> >This commit seems to be breaking libstdc++-v3 runs on AArch64.
>
> Is this under Linux or with newlib?
It works fine under Linux.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64443
--- Comment #5 from Tejas Belagod ---
(In reply to Tejas Belagod from comment #3)
> (In reply to Andrew Pinski from comment #1)
> > >This commit seems to be breaking libstdc++-v3 runs on AArch64.
> >
> > Is this under Linux or with newlib?
>
>
Assignee: unassigned at gcc dot gnu.org
Reporter: belagod at gcc dot gnu.org
This new test fails for BE:
FAIL: gcc.dg/vect/pr64252.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/pr64252.c execution test
but it is fixed by this patch series:
https://gcc.gnu.org/ml/gcc
: unassigned at gcc dot gnu.org
Reporter: belagod at gcc dot gnu.org
This new test added by r219108 fails on AArch64.
NA->FAIL: gcc.dg/ipa/inline-7.c scan-tree-dump-times einline "Inlining a into
m" 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64472
--- Comment #1 from Tejas Belagod ---
Only fails for -fPIC.
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: belagod at gcc dot gnu.org
NA->UNRESOLVED: 22_locale/money_get/get/char/14.cc compilation failed to
produce executable
PASS->NA: 22_locale/money_get/get/char/14.cc execution t
: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: belagod at gcc dot gnu.org
backref regresses on AArch64.
PASS->FAIL: 28_regex/algorithms/regex_match/ecma/char/backref.cc execution test
$
.../builds/fsf-trunk/fsf-tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64475
--- Comment #1 from Tejas Belagod ---
Fails on AArch32 too.
||belagod at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #2 from Tejas Belagod ---
(In reply to Tim Northover from comment #0)
> While investigating bug #56024, we discovered this problem in the same area.
> Essentially, GCC has semi-s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56025
Tejas Belagod changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56025
--- Comment #4 from Tejas Belagod ---
The ABI does not define an internal type name for scalar poly types -
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf.
This will need an ABI update.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56025
--- Comment #5 from Tejas Belagod ---
ACLE states that
"poly8_t and poly16_t are defined as unsigned integer types. It is unspecified
whether these are the same type as uint8_t and uint16_t for overloading and
mangling purposes"
Presently, pol
||belagod at gcc dot gnu.org
Resolution|FIXED |---
--- Comment #4 from Tejas Belagod ---
It looks like this still fails on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58739
Tejas Belagod changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64473
Tejas Belagod changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64231
--- Comment #13 from Tejas Belagod ---
(In reply to Sandra Loosemore from comment #12)
> I'm using a 4.7.3 based gcc as the host compiler (built from one of our own
> CodeBench release branches).
>
> Regardless of whether the actual failure is r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64231
--- Comment #14 from Tejas Belagod ---
Also, I'm unable to build x-gcc with glibc at
1400983e04d7b4b5a92db79ab27b0d0ec7d8bdef due to an error:
bin-trunk-linux/obj/glibc/intl/hash-string.os
plural.c:182:5: error: conflicting types for ‘__gettext
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63971
--- Comment #6 from Tejas Belagod ---
Author: belagod
Date: Thu Jan 15 18:17:23 2015
New Revision: 219674
URL: https://gcc.gnu.org/viewcvs?rev=219674&root=gcc&view=rev
Log:
2015-01-15 Tejas Belagod
PR target/63971
* gcc.target/aarch6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63971
Tejas Belagod changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64438
Tejas Belagod changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63971
--- Comment #9 from Tejas Belagod ---
Author: belagod
Date: Mon Jan 19 12:57:48 2015
New Revision: 219838
URL: https://gcc.gnu.org/viewcvs?rev=219838&root=gcc&view=rev
Log:
2015-01-19 Tejas Belagod
PR target/63971
* gcc.target/aarch6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64231
--- Comment #18 from Tejas Belagod ---
Author: belagod
Date: Mon Feb 2 15:54:59 2015
New Revision: 220348
URL: https://gcc.gnu.org/viewcvs?rev=220348&root=gcc&view=rev
Log:
2015-02-02 Tejas Belagod
Andrew Pinski
Jakub Jelin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64231
Tejas Belagod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #27 from Tejas Belagod ---
We'd want to scalarize this early preferably in SRA as it gives a chance to
passes like vectorization to vectorize more loops. I checked that
sra-max-scalarization-Osize{-Ospeed} had no effect on scalarizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #29 from Tejas Belagod ---
(In reply to rguent...@suse.de from comment #28)
> On Mon, 9 Feb 2015, belagod at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
> >
> > --- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64443
Tejas Belagod changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: belagod at gcc dot gnu.org
This piece of code:
int __attribute__ ((noinline))
foo ()
{
const int a[8] = { 0, 1, 2, 3, 4, 5, 6, 7 };
int i, sum;
sum = 0;
for (i = 0; i < sizeof (a) / sizeof (*a)
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: belagod at gcc dot gnu.org
When this piece of code is compiled with -O3 -mgeneral-regs-only
int __attribute__ ((noinline))
foo ()
{
const int a[8] = { 0, 1, 2, 3, 4, 5, 6, 7 };
int i, sum;
sum = 0;
for (i = 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63677
--- Comment #1 from Tejas Belagod ---
There is similar behaviour on aarch64. So, it doesn't look like a backend
issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
Tejas Belagod changed:
What|Removed |Added
Target||aarch64
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #2 from Tejas Belagod ---
foo.c.optimized:
5.0:
;;prev block 0, next block 1, flags: (NEW, REACHABLE)
;;pred: ENTRY [100.0%] (FALLTHRU,EXECUTABLE)
# .MEM_4 = VDEF <.MEM_3(D)>
aD.1380 = *.LC0D.1387;
# VUSE <.MEM_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #3 from Tejas Belagod ---
When I try 5.0 with -fno-tree-vectorize, I get:
;; basic block 2, loop depth 0
;;pred: ENTRY
# .MEM_4 = VDEF <.MEM_3(D)>
aD.2496 = *.LC0D.2503;
# VUSE <.MEM_4>
_10 = aD.2496[0];
# VUSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #5 from Tejas Belagod ---
>
> Index: passes.def
> ===
> --- passes.def (revision 217035)
> +++ passes.def (working copy)
> @@ -255,7 +255,7 @@
>NEXT_PASS (pas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58692
--- Comment #2 from Tejas Belagod ---
Committed fix r217405 and r217406.
r217406 | belagod | 2014-11-12 08:46:05 + (Wed, 12 Nov 2014) | 14 lines
[AArch64] Remove unnec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58692
Tejas Belagod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #7 from Tejas Belagod ---
I tried this, but it still doesn't seem to fold for aarch64.
So, here is the DOM trace for aarch64:
Optimizing statement a = *.LC0;
LKUP STMT a = *.LC0 with .MEM_3(D)
LKUP STMT *.LC0 = a with .MEM_3(D)
Opti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #11 from Tejas Belagod ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Tejas Belagod from comment #7)
> > I tried this, but it still doesn't seem to fold for aarch64.
> >
> > So, here is the DOM trace for aarch64:
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #13 from Tejas Belagod ---
(In reply to rguent...@suse.de from comment #12)
> On Fri, 21 Nov 2014, belagod at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
> >
> > --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #17 from Tejas Belagod ---
> -
> /* Do a block move either if the size is so small as to make
> each individual move a sub-unit move on average, or if it
> -is so large as to make individual moves in
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: belagod at gcc dot gnu.org
When sms-3 is compiled with -fPIC for aarch64, the test itself segfaults during
execution.
../../bin/install/bin/aarch64-unknown-linux-gnu-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64240
Tejas Belagod changed:
What|Removed |Added
Summary|[5.0 Regression][AArch64] |[5.0 Regression][AArch64]
||2014-12-11
CC||belagod at gcc dot gnu.org
Resolution|DUPLICATE |---
Ever confirmed|0 |1
--- Comment #4 from Tejas Belagod ---
aarch64-none-elf-gcc -fno-diagnostics-show-caret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64032
Tejas Belagod changed:
What|Removed |Added
CC||belagod at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64231
--- Comment #8 from Tejas Belagod ---
Hi Sandra, I'm unable to reproduce this SEGV with a x-build of
aarch64-linux-gcc/native gcc with -O2 on the attached prepocessed test case.
Are there any other options I'm missing?
Assignee: unassigned at gcc dot gnu.org
Reporter: belagod at gcc dot gnu.org
FAIL: gcc.dg/addr_equal-1.c execution test
$ aarch64-none-elf-gcc
/work/dev/arm/src/gcc/gcc/testsuite/gcc.dg/addr_equal-1.c -O2 -lm -mcmodel=tiny
-fPIC -o foo.exe
fails on AArch64. This test was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64328
--- Comment #3 from Tejas Belagod ---
(In reply to Jan Hubicka from comment #2)
> Indeed, the testcase is meant to be nopic. I will check how to test for
> that in dg.
>
> Honza
{ dg-require-effective-target nonpic } ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64328
--- Comment #4 from Tejas Belagod ---
Author: belagod
Date: Wed Dec 17 12:15:36 2014
New Revision: 218817
URL: https://gcc.gnu.org/viewcvs?rev=218817&root=gcc&view=rev
Log:
PR testsuite/64328
* gcc.dg/addr_equal-1.c: Not supported for -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64328
Tejas Belagod changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60079
--- Comment #4 from Tejas Belagod ---
(In reply to ktkachov from comment #3)
> I can't reproduce this with current trunk either.
> Tejas, do you think this can be closed?
I remember the ICE was quite sensitive to any small change to the test cas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64818
--- Comment #3 from Tejas Belagod ---
Author: belagod
Date: Thu Dec 10 17:13:47 2015
New Revision: 231531
URL: https://gcc.gnu.org/viewcvs?rev=231531&root=gcc&view=rev
Log:
gcc/ChangeLog.arm:
2015-12-10 Tejas Belagod
Backport from Mainli
||belagod at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #4 from Tejas Belagod ---
Fixed in r222306.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67548
--- Comment #14 from Tejas Belagod ---
Author: belagod
Date: Wed Dec 16 22:33:51 2015
New Revision: 231724
URL: https://gcc.gnu.org/viewcvs?rev=231724&root=gcc&view=rev
Log:
Backport from Mainline
PR lto/67548
* lto-plugi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48628
Summary: ICE in reload
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48628
--- Comment #1 from belagod at gcc dot gnu.org 2011-04-15 17:40:38 UTC ---
Created attachment 24002
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24002
test case with complex expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48628
--- Comment #4 from belagod at gcc dot gnu.org 2011-04-21 10:53:26 UTC ---
Sorry for the delay: this is my gcc -v:
arm-eabi-gcc
COLLECT_LTO_WRAPPER=.../trunk/2011-04-20/install-a9softfpneon/bin/../libexec/gcc/arm-eabi/4.7.0/lto-wrapper
Target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45805
--- Comment #3 from belagod at gcc dot gnu.org 2010-09-28 10:58:31 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > Created attachment 21897 [details] [details]
> > Fix register specifier in instruction template fo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45805
--- Comment #5 from belagod at gcc dot gnu.org 2010-09-28 16:25:37 UTC ---
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > (In reply to comment #1)
> > > > Created attac
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45847
belagod at gcc dot gnu.org changed:
What|Removed |Added
CC||belagod at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45805
--- Comment #8 from belagod at gcc dot gnu.org 2010-10-07 16:00:13 UTC ---
Author: belagod
Date: Thu Oct 7 16:00:06 2010
New Revision: 165122
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165122
Log:
2010-10-07 Tejas Belagod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45805
belagod at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45847
belagod at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46038
Summary: Vectorizer generates misaligned address for vld1 qn,
[rn:alignment]
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96339
Tejas Belagod changed:
What|Removed |Added
CC||belagod at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96339
Tejas Belagod changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106339
Tejas Belagod changed:
What|Removed |Added
CC||belagod at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96339
--- Comment #3 from Tejas Belagod ---
> Are you still working on this PR ? If not, can I assign it to myself ?
Yes I am - its almost done - just been busy with a few higher priority things.
I'll find some time to clean it up, test it and post it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101428
Tejas Belagod changed:
What|Removed |Added
CC||belagod at gcc dot gnu.org
Last
|1
CC||belagod at gcc dot gnu.org
Status|UNCONFIRMED |NEW
--- Comment #2 from Tejas Belagod ---
As you rightly point out, vhsr3 pattern name seems to be using the wrong
iterator. With the right iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101609
--- Comment #3 from Tejas Belagod ---
> .. but still doesn't generate 'vector code' for the example shown here.
Actually, it does. I was looking in the wrong place.
|1
Last reconfirmed||2021-07-29
CC||belagod at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101543
Tejas Belagod changed:
What|Removed |Added
Status|ASSIGNED|UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101609
Tejas Belagod changed:
What|Removed |Added
Status|NEW |ASSIGNED
1 - 100 of 119 matches
Mail list logo
