https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118529
--- Comment #7 from Tamar Christina ---
(In reply to rguent...@suse.de from comment #6)
> On Fri, 17 Jan 2025, tnfchris at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118529
> >
> > -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118529
--- Comment #5 from Tamar Christina ---
(In reply to Richard Biener from comment #4)
> Confirmed.
> OTOH the initial choice of mask mode for the compare by the vectorizer
> is a bit odd. We get there from vect_recog_bool_pattern handling
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113257
Tamar Christina changed:
What|Removed |Added
Version|14.0|13.0
--- Comment #11 from Tamar Chris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118451
Tamar Christina changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118472
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118472
--- Comment #3 from Tamar Christina ---
reducer:
typedef int a;
typedef struct {
a b __attribute__((__vector_size__(8)))
} c;
typedef a d __attribute__((__vector_size__(8)));
c e, f, g;
d h, j;
void k() {
c l;
l.b[1] = 0;
c m = l;
|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
--- Comment #2 from Tamar Christina ---
(In reply to Richard Biener from comment #1)
> Confirmed with -O3 -fopenmp-simd. The operand_equal_p code isn't good:
>
> 3745 /* BIT_INSERT_EXPR has an implict opera
|ASSIGNED
Last reconfirmed||2025-01-14
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
--- Comment #5 from Tamar Christina ---
I'll add the guards.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118464
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118451
--- Comment #4 from Tamar Christina ---
Yeah the testcase was broken before, it was failing but not because of the
reason the author intended.
Anyway I have a patch to add the effective test but have been away.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110901
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113257
--- Comment #8 from Tamar Christina ---
> ./install/bin/gcc -xc -S -o - - -march=native < /dev/null
.arch
armv8-a+flagm2+lse+dotprod+rdma+crc+aes+sha3+fp16fml+jscvt+fcma+rcpc2+frintts+i8mm+bf16+sb+ssbs+pauth
patch works, will regtest an
|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
Last reconfirmed||2025-01-10
Ever confirmed|0 |1
--- Comment #7 from Tamar Christina ---
Confirmed,
The reason -mcpu=native doesn't work is because it's a big.LITTLE s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116126
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 118211, which changed state.
Bug 118211 Summary: tree-vectorize: vectorize input.cc, find_end_of_line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118211
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118211
Tamar Christina changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118407
Tamar Christina changed:
What|Removed |Added
Last reconfirmed||2025-01-10
Ever confirmed|0
: testsuite-fail
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: tnfchris at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
Target Milestone: ---
the loop unroller messes up loop profiling when loops with early breaks are
unrolled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118211
Tamar Christina changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118188
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116773
Bug 116773 depends on bug 118188, which changed state.
Bug 118188 Summary: aarch64: worse code with -mtune=grace (vs -mtune=generic)
in TSVC s4115
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118188
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118348
Tamar Christina changed:
What|Removed |Added
Last reconfirmed||2025-1-9
--- Comment #4 from Tamar Ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118358
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
CC: wilco at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*
There is a 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118348
--- Comment #3 from Tamar Christina ---
(In reply to Andrew Pinski from comment #2)
> I suspect this can be reproduced before with -fno-vect-cost since that
> revision is a cost model change.
No it's the commit that enables the conditional stor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118348
--- Comment #1 from Tamar Christina ---
Thanks for the report, taking a look
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114932
Tamar Christina changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118272
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118273
Tamar Christina changed:
What|Removed |Added
Target Milestone|--- |15.0
-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: tnfchris at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
Target Milestone: ---
#pragma GCC target ("+sve")
extern char __attribute__ ((simd, const)) fn3 (sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118272
Tamar Christina changed:
What|Removed |Added
Component|tree-optimization |middle-end
Target Milestone|---
-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: tnfchris at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
Target Milestone: ---
#pragma GCC target ("+sve")
extern char __attribute__ ((simd, con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118188
--- Comment #3 from Tamar Christina ---
This is an existing bug that's due to the backend not having been expanded to
support costing of emulated gathers and scatters.
Basically Adv. Simd has no gather and scatters and the vectorizer emulated t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118211
--- Comment #3 from Tamar Christina ---
(In reply to Richard Biener from comment #2)
> Looks like the alignment peeling enablement for early break didn't go in in
> time? That should have fixed this by peeling scalar iterations until 's' is
> a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117875
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463
--- Comment #35 from Tamar Christina ---
(In reply to Richard Biener from comment #34)
> Possibly first computing a lattice val for each SSA name whether its origin
> is a "real" or a "imag" component of a complex load could get us meta but
> ev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463
--- Comment #32 from Tamar Christina ---
(In reply to Richard Biener from comment #31)
> (In reply to Tamar Christina from comment #29)
> > (In reply to Tamar Christina from comment #27)
> > > > >
> > > > > We DO already impose any order on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463
--- Comment #30 from Tamar Christina ---
Created attachment 59779
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59779&action=edit
pattern.dot
digraph of resulting pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463
--- Comment #29 from Tamar Christina ---
(In reply to Tamar Christina from comment #27)
> > >
> > > We DO already impose any order on them, but the other operand is oddodd,
> > > so
> > > the overall order ends up being oddodd because any know
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463
--- Comment #28 from Tamar Christina ---
(In reply to Tamar Christina from comment #27)
> > >
> > > We DO already impose any order on them, but the other operand is oddodd,
> > > so
> > > the overall order ends up being oddodd because any know
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117890
--- Comment #7 from Tamar Christina ---
(In reply to Hu Lin from comment #5)
> Seems that commit (d2f9159cfe7ea904e6476cabefea0c6ac9532e29) fixed this
> issue. The wrong pattern is no longer generated, although I don't understand
> why for the m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463
--- Comment #27 from Tamar Christina ---
> >
> > We DO already impose any order on them, but the other operand is oddodd, so
> > the overall order ends up being oddodd because any known permute overrides
> > unknown ones.
>
> So what's the des
||tnfchris at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2024-12-03
Ever confirmed|0 |1
--- Comment #12 from Tamar Christina ---
Sending respun patches today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117890
--- Comment #6 from Tamar Christina ---
(In reply to Hu Lin from comment #5)
> Seems that commit (d2f9159cfe7ea904e6476cabefea0c6ac9532e29) fixed this
> issue. The wrong pattern is no longer generated, although I don't understand
> why for the m
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*
The following example:
#include
uint16x8_t foo(const
||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=116583
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
Ever confirmed|0 |1
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 116759, which changed state.
Bug 116759 Summary: [15 Regression] ~2.5% exec time slowdown of 538.imagick_r
on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116759
What|Removed |A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117270
--- Comment #1 from Tamar Christina ---
*** Bug 116759 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116759
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117830
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 117557, which changed state.
Bug 117557 Summary: [15 Regression] gcc_r miscompiles in SPECCPU 2017 with SVE2
since g:3d498cfe022f6e035ff24e0d78ff744da83ebf42
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117557
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117557
--- Comment #14 from Tamar Christina ---
I've confirmed that the bug is indeed in the predicate usage in find_reloads.
reducing a testcase and will work on a fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117557
--- Comment #13 from Tamar Christina ---
(In reply to Richard Biener from comment #12)
> (In reply to Richard Biener from comment #11)
> > (In reply to Richard Biener from comment #6)
> > > Today 502.gcc_r runfailed on me with
> > >
> > > gcc-p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117557
--- Comment #10 from Tamar Christina ---
The remaining failure I think is in find_reloads,
where the mask feeding into the store gets ANDed with the wrong mask.
Before it was using the mask coming from w1 < 0, and new one from w0 < 0;
So it lo
|ASSIGNED
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
--- Comment #8 from Tamar Christina ---
Testcase:
#include
#include
#define N 8
#define L 8
void f(const uint8_t * restrict seq1,
const uint8_t *idx, uint8_t *seq_out) {
for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117557
--- Comment #7 from Tamar Christina ---
The codegen in GCC 15 is:
ld1bz30.h, p6/z, [x0]
lsl z30.h, z30.h, #2
uunpkhi z29.s, z30.h
uunpklo z30.s, z30.h
ld1wz31.s, p3/z, [x23, z29.s, sxtw]
ld1wz29.s, p7/z, [x23, z30.s, sxtw]
st1w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117557
Tamar Christina changed:
What|Removed |Added
Summary|[15 Regression] gcc_r |[15 Regression] gcc_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463
--- Comment #24 from Tamar Christina ---
(In reply to rguent...@suse.de from comment #23)
> > Am 23.11.2024 um 13:20 schrieb tnfchris at gcc dot gnu.org
> > :
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463
--- Comment #22 from Tamar Christina ---
Ok, so the problem with the ones on trunk isn't necessarily the
canonicalization itself but that our externals handling is a bit shallow.
On externals we determine that we have no information on the DF a
|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
--- Comment #21 from Tamar Christina ---
will wait a week or so for backporting to GCC 14, looking at the complex add
failures on trunk now. Have an idea but need to work out on paper if sound.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463
--- Comment #19 from Tamar Christina ---
The failing tests on the branch are:
#include
#define TYPE double
#define N 200
void fms180snd(_Complex TYPE a[restrict N], _Complex TYPE b[restrict N],
_Complex TYPE c[restrict N]) {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117557
--- Comment #4 from Tamar Christina ---
Able to reproduce with just SVE. Still there today so will continue to reduce.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117557
--- Comment #2 from Tamar Christina ---
It looks like after the change we vectorize
c[b[a]] = d[b[a]]
but I wonder if the resulting code doesn't need an alias check that c != d.
I don't see any added, let me try to bisect the loop and reduce.
: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*
The gcc_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463
--- Comment #18 from Tamar Christina ---
I can provide a GCC 14 fix during Stage 3 while I fix the GCC 15 one if that's
easier.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117395
--- Comment #4 from Tamar Christina ---
(In reply to Andrew Pinski from comment #1)
> It is a slight regression from GCC 14 though.
>
> Which produced:
> ```
> foo:
> ldr q31, [x0, 32]
> sub sp, sp, #128
> add
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
Target Milestone: ---
The following example:
#include
#include
int16x4_t foo(const int16_t *src, int16x8_t c) {
int16x8_t s[8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117176
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117176
--- Comment #5 from Tamar Christina ---
Have added more lowering to gcond handling and now we vectorize this as well:
ptrue p7.b, all
fmovz30.d, #1.0e+0
ld1dz31.d, p7/z, [sp, #1, mul vl]
fcmlt p15.d,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117140
Tamar Christina changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
--- Comment #4 from Tamar Christina ---
(In reply to Richard Biener from comment #3)
> Confirmed. SLP early-exit vect related.
>
> (gdb) p operand
> $1 = 1
> (gdb) p debug (slp_node)
> t.c:9:5: note: node 0x4e46ac0 (max_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117140
--- Comment #9 from Tamar Christina ---
(In reply to rguent...@suse.de from comment #8)
> On Wed, 16 Oct 2024, tnfchris at gcc dot gnu.org wrote:
> > diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc
> > index 8727246c2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117140
--- Comment #7 from Tamar Christina ---
For this statement somehow the location of the gsi ends up having
first == last, so gsi_insert_before just silently ignores the insert.
The ICE happens because for this one BB, no vector statement is ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116064
--- Comment #13 from Tamar Christina ---
(In reply to Li Pan from comment #12)
> Looks RISC-V backend still has this issue, can you reproduce this?
>
> /opt/gcc-master//bin/g++ --version
> g++ (GCC) 15.0.0 20241014 (experimental)
>
> /opt/gcc-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117140
--- Comment #6 from Tamar Christina ---
Ok, mine then.
It looks like it's this loop:
int n_3_TYPE1_int64_t = 32;
int32_t x_3_int32_t = 233;
int32_t x2_3_int32_t = 78;
int64_t y_3_int64_t = 1234;
int32_t f_3_int32_t[33 * 2 +
||2024-10-15
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
--- Comment #5 from Tamar Christina ---
Ok, mine then.
It looks like it's this loop:
int n_3_TYPE1_int64_t = 32;
in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116956
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117012
Tamar Christina changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117012
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117031
--- Comment #7 from Tamar Christina ---
Indeed, checking this in get_group_load_store_type gets the result I am after.
I'll clean this up if that's OK with you?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117031
Tamar Christina changed:
What|Removed |Added
Summary|increasing VF during SLP|Inefficient codegen of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117031
--- Comment #3 from Tamar Christina ---
(In reply to Richard Biener from comment #2)
> (In reply to Tamar Christina from comment #0)
> > GCC seems to miss that there is no gap between the group accesses and that
> > stride == 1.
> > test3 is vec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117032
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
Target Milestone: ---
The following testcase:
---
void
test1 (unsigned short *x, double *y, int n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117012
--- Comment #6 from Tamar Christina ---
(In reply to Andrew Pinski from comment #2)
> But it is still only a GCC 15 regression.
>
> GCC 14 produced:
> ```
> cmltv0.16b, v0.16b, #0
> adrpx0, .LC0
> ldr q31, [x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117012
--- Comment #1 from Tamar Christina ---
bisect landed on
g:aac00d09859cc5934bd0f7493d537b8430337773 is the first bad commit
commit aac00d09859cc5934bd0f7493d537b8430337773
Author: liuhongt
Date: Thu Jun 20 12:41:13 2024 +0800
Optimize a
: wrong-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*
The following example:
#include
#include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116855
--- Comment #6 from Tamar Christina ---
> Actually, what I wish is that we could allow vectorization on early break
> case for arbitrary address pointer (knowing nothing about alignment and
> bound) based on some sort of assumption specified via
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116956
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116855
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
Target Milestone: ---
consider the following testcase extracted from a library:
#include
#include
void func1(uint32_t n, const float32_t *a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116817
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
--- Comment #33 from Tamar Christina ---
Many Thanks Mikael!
I see the functions being inlined now!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116817
--- Comment #5 from Tamar Christina ---
Waiting for regression testing to finish and will submit.
The condition used before to check for loop invariant is !internal_def.
This of course fails when it's a reduction, which is what happened here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116817
--- Comment #4 from Tamar Christina ---
I see,
I haven't checked that the value being compared is actually loop invariant.
In this case it's a reduction value and it can't be lifted out of the loop.
Basically in GCC 14 and earlier this was a
|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
--- Comment #3 from Tamar Christina ---
mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116812
Tamar Christina changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116817
Tamar Christina changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116812
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
1 - 100 of 1156 matches
Mail list logo
