https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118377
--- Comment #9 from Tejas Belagod ---
I agree it's best to have feature-parity with Clang and a widening divide is
better than rejecting it outright.
Technically, as this is not a regression, can we fix this to sorry more
gracefully for GCC15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118377
--- Comment #7 from Tejas Belagod ---
Sorry for the delay in replying. Though variable-length(VLA) SVE vector types
behave as GNU vectors for C/C++ operator semantics, there is currently no
support for decomposing them into scalar operation sequ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114108
Tejas Belagod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114108
--- Comment #9 from Tejas Belagod ---
This seems to be the issue:
... VECITYPE is the vector form of PATTERN_STMT's result type. */
static gimple *
vect_convert_output (vec_info *vinfo, stmt_vec_info stmt_info, tree type,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114108
--- Comment #8 from Tejas Belagod ---
I find this transformation a bit odd:
...
pr114108.c:11:21: note: add new stmt: vect_patt_32.15_181 = .ABD
(vect__3.11_177, vect__7.14_180);
pr114108.c:11:21: note: -->vectorizing statement: patt_31 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113780
Tejas Belagod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112577
Tejas Belagod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113780
--- Comment #1 from Tejas Belagod ---
Testing a fix as we speak..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113780
Tejas Belagod changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113780
Tejas Belagod changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |belagod at gcc dot
gnu.org
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: belagod at gcc dot gnu.org
Target Milestone: ---
For this piece of code:
void fail(void (*f)(int, int, int, int))
{
f(1, 2, 3, 4);
}
compiled with -mcpu=cortex-m85 -mbranch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112375
--- Comment #3 from Tejas Belagod ---
Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112375
Tejas Belagod changed:
What|Removed |Added
CC||belagod at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112577
Tejas Belagod changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112577
--- Comment #1 from Tejas Belagod ---
Confirmed. Testing a fix.
|NEW
Assignee|unassigned at gcc dot gnu.org |belagod at gcc dot
gnu.org
Last reconfirmed||2024-01-16
CC||belagod at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96339
Tejas Belagod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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
|1
Status|UNCONFIRMED |NEW
CC||belagod at gcc dot gnu.org
--- Comment #1 from Tejas Belagod ---
Confirmed.
(insn 11 10 12 2 (set (reg:V8QI 92 [ _1 ])
(mult:V8QI (reg:V8QI 100)
(reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101609
Tejas Belagod changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101609
Tejas Belagod changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101543
Tejas Belagod changed:
What|Removed |Added
Status|ASSIGNED|UNCONFIRMED
Ever confirmed|1
|1
Last reconfirmed||2021-07-29
CC||belagod at gcc dot gnu.org
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
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=101428
Tejas Belagod changed:
What|Removed |Added
CC||belagod at gcc dot gnu.org
Last
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=96339
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71607
Tejas Belagod changed:
What|Removed |Added
CC||belagod at gcc dot gnu.org
--- Comment
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
||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=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
||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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64443
Tejas Belagod changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=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=64231
Tejas Belagod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=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=64438
Tejas Belagod changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=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=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=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=64473
Tejas Belagod changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58739
Tejas Belagod changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
||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=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
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
Tejas Belagod changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
||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=64475
--- Comment #1 from Tejas Belagod ---
Fails on AArch32 too.
: 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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64472
--- Comment #1 from Tejas Belagod ---
Only fails for -fPIC.
: 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
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
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?
>
>
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.
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 #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
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
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
: 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
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=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
--- 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 } ?
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=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?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64032
Tejas Belagod changed:
What|Removed |Added
CC||belagod at gcc dot gnu.org
--- Comment
||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=64240
Tejas Belagod changed:
What|Removed |Added
Summary|[5.0 Regression][AArch64] |[5.0 Regression][AArch64]
: 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=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
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 #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 #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=58692
Tejas Belagod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=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=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 #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
Tejas Belagod changed:
What|Removed |Added
Target||aarch64
Status|UNCONFIRMED
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.
: 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
-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)
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=58692
Tejas Belagod changed:
What|Removed |Added
CC||belagod at gcc dot gnu.org
--- Comment
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
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 #1 from Tejas Belagod ---
Sorry I meant it fixes this on aarch64_be.
FAIL: gcc.dg/vect/no-scevccp-outer-7.c execution test
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
-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
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.
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
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
: 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
1 - 100 of 119 matches
Mail list logo
