https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #10 from alalaw01 at gcc dot gnu.org ---
The stores are getting optimized out because equal_mem_array_ref_p considers
equal pairs of MEM_REFS like
fmcom.x[_168] and fmcom.x[_208]
That is, a ARRAY_REF whose first operand is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #20 from alalaw01 at gcc dot gnu.org ---
Hmmm, hang on. In unport.fppized.f, shouldn't we be using the 'F2C/GCC COMPILER
ON PC RUNNING UNIX (LINUX,BSD386,ETC)' version? In which case X has size (1)
everywhere?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
alalaw01 at gcc dot gnu.org changed:
What|Removed |Added
Resolution|DUPLICATE |FIXED
--- Comment #23 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
alalaw01 at gcc dot gnu.org changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #27 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #32 from alalaw01 at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #31)
>
> Thus a "fix" for the case where treating a[i] as a[0] is the issue
> would be
>
&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
alalaw01 at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #37 from alalaw01 at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #36)
> As Richard said, you can do similar (invalid too) stuff in C too, say:
> struct S { int a[1]; } s;
> in one TU and
> struct S { i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #39 from alalaw01 at gcc dot gnu.org ---
Created attachment 37726
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37726&action=edit
Proposed patch (without flag).
Here's a prototype patch, that sets TYPE_SIZE to N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #43 from alalaw01 at gcc dot gnu.org ---
Yeah, I plan to add a fortran-specific option for this, it's easy enough, but I
can't run the gfortran testsuite with that, because there are lots of C files
in there too, for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #53 from alalaw01 at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #44)
> I don't have access to SPEC, so I can only guess... Is there maybe an
> equivalence involved, something like
Turns out the COMMON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #77 from alalaw01 at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #72)
>
> Patch as posted passed bootstrap & regtest. Adjusted according to
> comments but not tested otherwise - please some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #79 from alalaw01 at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #78)
>
> That would pessimize it too much IMHO.
I'm not sure how to evaluate the pessimization, given it's thought to be a
widesprea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66877
alalaw01 at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65963
alalaw01 at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #82 from alalaw01 at gcc dot gnu.org ---
For those who haven't seen it, I've put forward this patch on the mailing list:
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01746.html based on a suggestion
from Jakub. (Unli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60632
alalaw01 at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #84 from alalaw01 at gcc dot gnu.org ---
Bah. Do you normally use -fno-aggressive-loop-optimizations? With
-funknown-commons, did you try with/out aggressive loop opts?
Powerpc{,64}{be,le} ?
The unknown-commons testcase I included in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #87 from alalaw01 at gcc dot gnu.org ---
Great, many thanks for the tests, I was worried if we had hit another distinct
issue. (Of course this would be better on gcc-patches!)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70013
alalaw01 at gcc dot gnu.org changed:
What|Removed |Added
CC||alalaw01 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70013
--- Comment #5 from alalaw01 at gcc dot gnu.org ---
Prior to SRA, we have
d = *.LC0;
d$0$f0_7 = MEM[(struct S0[2] *)&*.LC0].f0;
e$f0_9 = MEM[(struct S0[2] *)&d + 3B].f0;
_3 = (int) d$0$f0_7;
c = _3;
_5 = (int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70013
--- Comment #6 from alalaw01 at gcc dot gnu.org ---
Ugh, initializing the scalar replacement for the first half of d, with a value
read from the first half of d (should be from the first half of *.LC0).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70013
--- Comment #7 from alalaw01 at gcc dot gnu.org ---
*second* half, sorry. grp_to_be_replaced is here true, but
grp_unscalarized_data is false, so handle_unscalarized_data_in_subtree sets
sad->refreshed=UDH_LEFT and we build the access to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70013
--- Comment #9 from alalaw01 at gcc dot gnu.org ---
In analyze_access_subtree (since r147980, "New implementation of SRA", 2009):
else if (root->grp_write || TREE_CODE (root->base) == PARM_DECL)
root->grp_unscalariz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67681
--- Comment #3 from alalaw01 at gcc dot gnu.org ---
So in the not-vectorized case (-DFOO=1), we get for the inner loop:
:
# i_27 = PHI
_8 = (long unsigned int) i_27;
_9 = _8 * 4;
_11 = data_10(D) + _9;
_13 = *_11;
_14 = _13 + j_23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67681
--- Comment #4 from alalaw01 at gcc dot gnu.org ---
loopinit introduces the exit phi in much the same way for both -DFOO=0 and
-DFOO=1, so the difference is in sccp.
In the -DFOO=0 case, sccp does this (removing TODO_cleanup_cfg from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70013
--- Comment #10 from alalaw01 at gcc dot gnu.org ---
Hmmm, so this fixes the ICE, generating:
SR.5_12 = MEM[(struct S0[2] *)&*.LC0].f0;
MEM[(struct S0[2] *)&*.LC0].f0 = SR.5_12;
d = *.LC0;
d$3$f0_14 = MEM[(struct S0[2] *)&*.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67681
--- Comment #5 from alalaw01 at gcc dot gnu.org ---
In the -DFOO=0 case, we have peeled an extra copy of the inner loop condition,
i <= max_7, above the loop. scalar evolution (final_value_replacement_loop)
works, because it sees the inner l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67681
--- Comment #7 from alalaw01 at gcc dot gnu.org ---
Looking at where the peeling happens. In both -DFOO=0 and -DFOO=1 cases,
107.ch2 peels the inner loop header, so there is an i<=max test in the outer
loop before the inner loop. However, in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67681
--- Comment #8 from alalaw01 at gcc dot gnu.org ---
Indeed, the -DFOO=1 case vectorizes with -fno-tree-dominator-opts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70013
--- Comment #12 from alalaw01 at gcc dot gnu.org ---
Thanks, Martin - yes, I see.
Patch posted at https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00680.html after
full regtest.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70013
--- Comment #13 from alalaw01 at gcc dot gnu.org ---
Author: alalaw01
Date: Fri Mar 11 12:08:01 2016
New Revision: 234138
URL: https://gcc.gnu.org/viewcvs?rev=234138&root=gcc&view=rev
Log:
Fix PR/70013
gcc:
PR tree-optimizati
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: alalaw01 at gcc dot gnu.org
Target Milestone: ---
Following PR/63679 (r232506), gimplify.c (gimplify_init_constructor) uses lots
of heuristics to choose between pushing initializers out to the constant pool
(by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
alalaw01 at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
alalaw01 at gcc dot gnu.org changed:
What|Removed |Added
Assignee|alalaw01 at gcc dot gnu.org|unassigned at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60825
--- Comment #3 from alalaw01 at gcc dot gnu.org ---
Author: alalaw01
Date: Mon Jun 23 12:46:52 2014
New Revision: 211892
URL: https://gcc.gnu.org/viewcvs?rev=211892&root=gcc&view=rev
Log:
PR/60825 Make float64x1_t in arm_neon.h a prope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60825
--- Comment #4 from alalaw01 at gcc dot gnu.org ---
Author: alalaw01
Date: Mon Jun 23 14:07:42 2014
New Revision: 211894
URL: https://gcc.gnu.org/viewcvs?rev=211894&root=gcc&view=rev
Log:
PR/60825 Make {int,uint}64x1_t in arm_neon.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65506
alalaw01 at gcc dot gnu.org changed:
What|Removed |Added
CC||alalaw01 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33394
--- Comment #4 from alalaw01 at gcc dot gnu.org ---
Author: alalaw01
Date: Wed Mar 25 15:46:58 2015
New Revision: 221666
URL: https://gcc.gnu.org/viewcvs?rev=221666&root=gcc&view=rev
Log:
PR libstdc++/33394
* testsuite/21
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: alalaw01 at gcc dot gnu.org
Starting with r221532
(https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01064.html),
void
test (void)
{
__asm__ ("@ %c0" : : "S" (&test + 4));
}
fails to compile at -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65689
--- Comment #1 from alalaw01 at gcc dot gnu.org ---
Problem stems from parse_input_constraint (in stmt.c):
if (reg_class_for_constraint (cn) != NO_REGS
|| insn_extra_address_constraint (cn))
*allows_reg = true;
else if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65689
alalaw01 at gcc dot gnu.org changed:
What|Removed |Added
Priority|P1 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65689
--- Comment #6 from alalaw01 at gcc dot gnu.org ---
Whilst I think this probably would fix the problem - surely this will change
the meaning of loads of constraints, on loads of platforms? I will of course
defer to the release manager(s) (!), but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65689
--- Comment #8 from alalaw01 at gcc dot gnu.org ---
Well, meaning/behaviour. But thanks for the patch - I've bootstrapped and
check-gcc'd on AArch64 and arm hf (Cortex-A15 + Neon) with no regressions.
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: alalaw01 at gcc dot gnu.org
Target: aarch64_be
Testcase:
void
test_vst2_lane_s32 (int32x2x2_t vals)
{
int32_t buf[2];
vst2_lane_s32 (buf, vals, 0);
for (int i = 0; i < 2; i++)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64134
--- Comment #3 from alalaw01 at gcc dot gnu.org ---
Author: alalaw01
Date: Mon Apr 20 10:29:26 2015
New Revision: 29
URL: https://gcc.gnu.org/viewcvs?rev=29&root=gcc&view=rev
Log:
[AArch64] PR/64134: Make aarch64_expand_vector_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35226
alalaw01 at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: alalaw01 at gcc dot gnu.org
Target Milestone: ---
Target: x86_64
This testcase:
#define N 32
int a[N], b[N];
int
foo ()
{
for (int i = 0; i < N ; i++)
{
in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65946
alalaw01 at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: alalaw01 at gcc dot gnu.org
Target Milestone: ---
This testcase:
int a[32];
int main(int argc, char **argv)
{
int res = 3;
for (int i = 0; i < 32; i++)
if (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65947
alalaw01 at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: alalaw01 at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
This loop:
void
foo (long *arr)
{
for (int i = 0; i < 256
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: alalaw01 at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
typedef struct {
int a, b, c, d;
} my_struct;
my_struct *array;
my_struct *ptrs[4];
void
loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65951
--- Comment #3 from alalaw01 at gcc dot gnu.org ---
Yes you are right, we have no V2DI multiply. We do have V2DI shifts + add,
however, which would work well for some constants, e.g. the multiply by 16 in
PR/65952; perhaps the vectorizer does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65952
--- Comment #4 from alalaw01 at gcc dot gnu.org ---
Hmmm. Yes. Well, x * 16 = x << 4, of course. Or, in theory something like VRP
could let us see that
# i_12 = PHI
# ivtmp_18 = PHI
_5 = (long unsigned int) i_12;
_6 = _5 * 16
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: alalaw01 at gcc dot gnu.org
Target Milestone: ---
This does not vectorize at -O3 on x86_64/-mavx or aarch64:
int
loop (int *data)
{
int tot = 0;
for (int i = 0; i < 256; i++)
d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65962
--- Comment #1 from alalaw01 at gcc dot gnu.org ---
I believe this is a known issue, but have not identified an existing PR.
missed-optimization
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: alalaw01 at gcc dot gnu.org
Target Milestone: ---
This testcase does not vectorize at -O3 on x86_64/-mavx or AArch64:
void
loo
-optimization
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: alalaw01 at gcc dot gnu.org
Target Milestone: ---
Testcase:
void
test(int *__restrict__ a, int *__restrict__ b)
{
a[0] = b[0];
a[1] = b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65951
--- Comment #5 from alalaw01 at gcc dot gnu.org ---
I believe the definitive algorithm for converting multiply-by-constant into
adds+shifts(+etc.) lives in expmed.c. I don't at present have a plan for how to
reuse that, but if we could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65947
--- Comment #3 from alalaw01 at gcc dot gnu.org ---
Yeah, you're right, it's not commutative, but then, it doesn't need to be.
If f(x,y) is "(a[x] ? 7 : y)", then f(0, f(1, ...)) = f(1, f(0, ...))
(associative but not c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46029
alalaw01 at gcc dot gnu.org changed:
What|Removed |Added
CC||alalaw01 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57558
alalaw01 at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67439
alalaw01 at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63870
--- Comment #10 from alalaw01 at gcc dot gnu.org ---
Author: alalaw01
Date: Tue Sep 8 19:43:39 2015
New Revision: 227557
URL: https://gcc.gnu.org/viewcvs?rev=227557&root=gcc&view=rev
Log:
ARM/AArch64 Testsuite] Add float16 lane_f16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67283
--- Comment #13 from alalaw01 at gcc dot gnu.org ---
Author: alalaw01
Date: Fri Sep 18 10:55:11 2015
New Revision: 227901
URL: https://gcc.gnu.org/viewcvs?rev=227901&root=gcc&view=rev
Log:
completely_scalarize arrays as well as recor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65965
--- Comment #4 from alalaw01 at gcc dot gnu.org ---
(In reply to Richard Biener from comment #3)
> Fixed for GCC 6.
Indeed. I note that the same testcase does _not_ SLP/vectorize if I use
consecutive indices:
void
test (int*__restrict a,
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: alalaw01 at gcc dot gnu.org
Target Milestone: ---
The inner loop here:
void addlog2 (int *data)
{
int i = 1;
for (int j=0; j<=30; j++) {
int max = 1 << j;
if
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: alalaw01 at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
This code:
void
test (int*__restrict a, int*__restrict b
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: alalaw01 at gcc dot gnu.org
Blocks: 53947
Target Milestone: ---
This testcase:
void test (unsigned char *data, int max)
{
unsigned short val = 0xcdef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67681
--- Comment #2 from alalaw01 at gcc dot gnu.org ---
Being stupid here, but why does the outer loop having multiple exits matter -
it's the inner loop that should be vectorized?
FOO was a macro used to selectively make the test i>max d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57558
--- Comment #4 from alalaw01 at gcc dot gnu.org ---
Here's another example, extracted from another benchmark - it vectorizes if
INDEX is defined to 'long' but not if INDEX is 'short':
#include
unsigned char *t_run_test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67683
alalaw01 at gcc dot gnu.org changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68112
--- Comment #2 from alalaw01 at gcc dot gnu.org ---
So (a << CONSTANT) is not equivalent to a * (1<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68112
--- Comment #4 from alalaw01 at gcc dot gnu.org ---
Sure, but gcc exploits undefinedness of multiply, so rewriting shift to
multiply is not equivalent in the general case :(.
One way forward might be to make definedness of overflow a bit finer
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: alalaw01 at gcc dot gnu.org
Target Milestone: ---
I believe these two C functions are equivalent:
typedef float __attribute__((__vector_size__ (2 * sizeof(float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68165
alalaw01 at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56118
alalaw01 at gcc dot gnu.org changed:
What|Removed |Added
CC||alalaw01 at gcc dot gnu.org
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: alalaw01 at gcc dot gnu.org
Target Milestone: ---
Host: x86_64
Target: x86_64
Preprocessed source attached; command-line
$ /work/alalaw01/build/./gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68182
--- Comment #1 from alalaw01 at gcc dot gnu.org ---
Created attachment 36636
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36636&action=edit
Preprocessed source (compressed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65963
--- Comment #2 from alalaw01 at gcc dot gnu.org ---
Author: alalaw01
Date: Thu Nov 5 18:39:38 2015
New Revision: 229825
URL: https://gcc.gnu.org/viewcvs?rev=229825&root=gcc&view=rev
Log:
[PATCH] tree-scalar-evolution.c: Handle L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65963
--- Comment #4 from alalaw01 at gcc dot gnu.org ---
I confirm the testcase fails execution on armeb-none-eabi (also at -O0), but it
does so both with and without the patch to tree-scalar-evolution.c, which did
not change codegen (at -O2 -ftree
Assignee: unassigned at gcc dot gnu.org
Reporter: alalaw01 at gcc dot gnu.org
Target Milestone: ---
Target: arm-none-eabi
Created attachment 36738
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36738&action=edit
Reduced testcase
Starting with r230365, build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68549
alalaw01 at gcc dot gnu.org changed:
What|Removed |Added
CC||alalaw01 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63870
--- Comment #7 from alalaw01 at gcc dot gnu.org ---
I'm doing some of the ARM work atm, but not sure how far I'll get before stage
4 starts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64893
alalaw01 at gcc dot gnu.org changed:
What|Removed |Added
CC||alalaw01 at gcc dot gnu.org
Assignee: unassigned at gcc dot gnu.org
Reporter: alalaw01 at gcc dot gnu.org
Testcase:
#include
#define force_simd(V1) asm volatile ("mov %d0, %1.d[0]" \
: "=w"(V1) \
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64997
alalaw01 at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64997
--- Comment #2 from alalaw01 at gcc dot gnu.org ---
Author: alalaw01
Date: Wed Feb 25 14:20:13 2015
New Revision: 220969
URL: https://gcc.gnu.org/viewcvs?rev=220969&root=gcc&view=rev
Log:
[AArch64] Fix illegal assembly 'e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64997
alalaw01 at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61114
--- Comment #9 from alalaw01 at gcc dot gnu.org ---
Author: alalaw01
Date: Mon Oct 27 14:04:43 2014
New Revision: 216736
URL: https://gcc.gnu.org/viewcvs?rev=216736&root=gcc&view=rev
Log:
[Vectorizer] Make REDUC_xxx_EXPR tree codes p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61114
--- Comment #10 from alalaw01 at gcc dot gnu.org ---
Author: alalaw01
Date: Mon Oct 27 14:20:52 2014
New Revision: 216737
URL: https://gcc.gnu.org/viewcvs?rev=216737&root=gcc&view=rev
Log:
Add new optabs for reducing vectors to scalars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59843
alalaw01 at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: alalaw01 at gcc dot gnu.org
Testcase
#include
int8x8_t
f_vld1_lane (int8_t * p, int8x8_t v)
{
int8x8_t res;
res = vld1_lane_s8 (p, v, 1);
return res;
}
$ aarch64-none-elf-gcc -S test.c
In file included from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63870
--- Comment #3 from alalaw01 at gcc dot gnu.org ---
Author: alalaw01
Date: Tue Dec 9 20:23:36 2014
New Revision: 218536
URL: https://gcc.gnu.org/viewcvs?rev=218536&root=gcc&view=rev
Log:
[AArch64]Remove be_checked_get_lane, check bou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63950
alalaw01 at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63870
alalaw01 at gcc dot gnu.org changed:
What|Removed |Added
CC||alalaw01 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59843
--- Comment #6 from alalaw01 at gcc dot gnu.org ---
Author: alalaw01
Date: Tue Jul 8 10:32:57 2014
New Revision: 212355
URL: https://gcc.gnu.org/viewcvs?rev=212355&root=gcc&view=rev
Log:
Backport r211502: PR target/59843 Fix arm_neon.h
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: alalaw01 at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
Created attachment 36900
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36900&action=edit
tree-vect-details dump
Since
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: alalaw01 at gcc dot gnu.org
Target Milestone: ---
Target: aarch64, arm
Created attachment 36928
--> https://gcc.gnu.org/bugzi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68707
--- Comment #1 from alalaw01 at gcc dot gnu.org ---
Created attachment 36929
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36929&action=edit
tree-vect-details dump (after patch, with SLP)
1 - 100 of 154 matches
Mail list logo
