https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406
--- Comment #10 from Tamar Christina ---
Just finished second bisect and reduce. Came out to this commit as well.
---
module brute_force
integer, parameter :: r=9
integer sudoku1(1, r)
contains
subroutine brute
integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406
Tamar Christina changed:
What|Removed |Added
Priority|P3 |P1
Summary|[14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406
--- Comment #6 from Tamar Christina ---
First reduction:
typedef struct {
int red
} MagickPixelPacket;
GetImageChannelMoments_image, GetImageChannelMoments_image_0,
GetImageChannelMoments___trans_tmp_1, GetImageChannelMoments_M11_0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406
Tamar Christina changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406
--- Comment #2 from Tamar Christina ---
(In reply to Richard Biener from comment #1)
> Possibly the same as PR112359?
Some were yeah, looks like there are still 2 ICEs in imagick and exchange, I'll
start reducing those.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406
Bug ID: 112406
Summary: [14 Regression] Several SPECCPU 2017 benchmarks fail
with internal compiler error: in expand_insn, at
optabs.cc:8305
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112404
Tamar Christina changed:
What|Removed |Added
Last reconfirmed||2023-11-6
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111950
--- Comment #9 from Tamar Christina ---
Right, I've tried to apply that patch to my early break patch series and many
of the tests fail, all the same way in compute_live_loop_exits.
I guess we'll have a conflict here. So I'll post my patches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111878
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=112282
--- Comment #8 from Tamar Christina ---
Thanks for the report, that's very odd..
It looks like loop control is broken and `u` never gets incremented. It's even
more strange since the structures getting lowered are both unused so should not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111950
--- Comment #4 from Tamar Christina ---
> turning c_I_lsm.18_38 into a fully invariant reduction def which likely isn't
supported - we had bugs here in the past with not relevant but live stmts.
But if-conversion also performs the (now valid)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111950
--- Comment #3 from Tamar Christina ---
(In reply to Richard Biener from comment #2)
> For the epilog LC-SSA we lack the correct SSA name for the skip edge:
>
>
> [local count: 16140304]:
> # prephitmp_78 = PHI
> # c_I_lsm.18_79 = PHI
> #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112105
Tamar Christina changed:
What|Removed |Added
Keywords||missed-optimization
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112105
Bug ID: 112105
Summary: [14 Regression] vector by lane operation costing
broken since
g:21416caf221fae4351319ef8ca8d41c0234bdfa7
Product: gcc
Version: 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
--- Comment #15 from Tamar Christina ---
(In reply to Mikael Morin from comment #14)
> Created attachment 56313 [details]
> inline minloc with mask
>
> This patch adds support for {min,max}loc with mask.
Awesome, thank you!
> It is not 100%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111860
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111860
--- Comment #21 from Tamar Christina ---
patch submitted
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633734.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111866
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111866
--- Comment #4 from Tamar Christina ---
patch submitted
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633713.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111860
--- Comment #20 from Tamar Christina ---
(In reply to David Binderman from comment #19)
> Created attachment 56154 [details]
> C source code
>
> You might like to have a go at getting the attached code working:
>
> $ ~/gcc/results/bin/gcc -c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111860
Tamar Christina changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111860
Tamar Christina changed:
What|Removed |Added
CC||zsojka at seznam dot cz
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111877
Tamar Christina changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111877
Tamar Christina changed:
What|Removed |Added
Last reconfirmed||2023-10-19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111860
Tamar Christina changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111860
--- Comment #13 from Tamar Christina ---
Patch posted https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633569.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111866
--- Comment #3 from Tamar Christina ---
ok, so the crash looks like it's due to rgroups_control being empty during
prologue peeling.
It looks like the loop isn't masked so LOOP_VINFO_LENS (loop_vinfo) is being
used in this case, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111860
--- Comment #12 from Tamar Christina ---
yes, patch was tested on both aarch64 and x86, but I did not test libgomp
indeed.
In any case, waiting for regression run to finish and will submit patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111868
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111860
Tamar Christina changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111866
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=111866
--- Comment #1 from Tamar Christina ---
Thanks for reporting! I'll debug.
I suspect another case where the vectorized and scalar loop were sneakily
swapped.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111860
--- Comment #6 from Tamar Christina ---
Ok, so the problem is that the loop never creates memory references, and so
after redirecting the edges when we update the new references we do so by
trying to update the PHI nodes.
But since the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111860
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111860
Tamar Christina changed:
What|Removed |Added
Priority|P3 |P1
Version|unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111860
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
--- Comment #12 from Tamar Christina ---
(In reply to Mikael Morin from comment #11)
> Created attachment 56094 [details]
> Improved patch
>
> This improved patch (still single argument only) passes the fortran
> regression testsuite.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111770
Bug ID: 111770
Summary: predicated loads inactive lane values not modelled
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
--- Comment #9 from Tamar Christina ---
(In reply to Mikael Morin from comment #8)
> Created attachment 56091 [details]
> Rough patch
>
> Here is a rough patch to make the scalarizer support minloc calls.
> It regresses on minloc_1.f90 at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111370
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89967
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95958
Bug 95958 depends on bug 88212, which changed state.
Bug 88212 Summary: IRA Register Coalescing not working for the testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88212
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88212
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106346
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 106346, which changed state.
Bug 106346 Summary: [11/12/13/14 Regression] Potential regression on
vectorization of left shift with constants since r11-5160-g9fc9573f9a5e94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110625
--- Comment #18 from Tamar Christina ---
Hi, here's the reduced case:
> cat analyse.i
double x264_weights_analyse___trans_tmp_1;
float x264_weights_analyse_ref_mean;
x264_weights_analyse() {
x264_weights_analyse___trans_tmp_1 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110625
--- Comment #16 from Tamar Christina ---
(In reply to Hao Liu from comment #15)
> Ah, I see.
>
> I've sent out a quick fix patch for code review. I'll investigate more
> about this and find out the root cause.
Thanks! I can reduce a testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110625
--- Comment #14 from Tamar Christina ---
Or rather, info_for_reduction looks at the original statement if it's a
pattern, whereas vect_is_reduction only looks at the direct statement.
You'll probably want to check vect_orig_stmt if using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110625
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106346
Tamar Christina changed:
What|Removed |Added
Target Milestone|11.5|14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109156
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86486
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #65 from Tamar Christina ---
> >
> > In which case ifcvt could move the cond to just before the first shared
> > statement?
>
> I don't think PRE "knows" where the operation was created from since it's
> transforms from a global
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #63 from Tamar Christina ---
> > It looks like `-fno-tree-pre` does the trick, but then of course, messes up
> > elsewhere. The conditional statement seem to stay in the most complicated
> > form possible in scalar code.
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #61 from Tamar Christina ---
(In reply to Richard Biener from comment #60)
> (In reply to Tamar Christina from comment #59)
> > after ifcvt we end up with:
> >
> > _162 = chrg_init_70 * iftmp.8_76;
> > _164 = ABS_EXPR <_162>;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #59 from Tamar Christina ---
I've sent two patches upstream this morning to fix the remaining ifcvt issues:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623848.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #33 from Tamar Christina ---
(In reply to Sam James from comment #32)
> I'll tentatively reopen as IIRC tamar mentioned they've had some ideas about
> this, apologies if I'm misremembering.
Hello, yes I have a patch locally that I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110336
Bug ID: 110336
Summary: Ada doesn't build with coverage enabled on Arm
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110329
Tamar Christina changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110324
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110223
Bug ID: 110223
Summary: Missed optimization vectorizing booleans comparisons
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110142
--- Comment #2 from Tamar Christina ---
Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110142
Bug ID: 110142
Summary: [14 Regression] x264 from SPECCPU 2017 miscompares
from g:2f482a07365d9f4a94a56edd13b7f01b8f78b5a0
Product: gcc
Version: 14.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109940
Tamar Christina changed:
What|Removed |Added
Known to work|13.1.0 |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109711
--- Comment #6 from Tamar Christina ---
my own bisect does indeed end up at r14-377-gc92b8be9b52b7e and cannot
reproduce it on GCC 13.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109711
--- Comment #5 from Tamar Christina ---
(In reply to Martin Liška from comment #3)
> Hm, on x86_64-linux-gnu, it started with r13-6616-g2246d576f922ba.
$ cat prtest2.c
void lspf2lpc();
int interpolate_lpc_q_0;
void
interpolate_lpc(int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109632
--- Comment #9 from Tamar Christina ---
Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109632
--- Comment #6 from Tamar Christina ---
That's an interesting approach, I think it would also fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109391 would it not? Since the
int16x8x3_t return would be "scalarized" avoiding the bad expansion?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109632
--- Comment #3 from Tamar Christina ---
note that even if we can't stop SLP, we should be able to generate as efficient
code by being creative about the instruction selection, that's why I marked it
as a target bug :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109632
--- Comment #2 from Tamar Christina ---
(In reply to Richard Biener from comment #1)
> Well, the usual unknown ABI boundary at function entry/exit.
Yes but LLVM gets it right, so should be a solve able computer science problem.
:)
Note that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109632
Bug ID: 109632
Summary: Inefficient codegen when complex numbers are emulated
with structs
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
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=109154
--- Comment #54 from Tamar Christina ---
@Jakub, just to check to avoid doing duplicate work, did you intend to do the
remaining ifcvt changes or should we?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109587
--- Comment #7 from Tamar Christina ---
(In reply to Richard Biener from comment #5)
> (In reply to Tamar Christina from comment #4)
> > (In reply to Richard Biener from comment #3)
> > > The issue isn't unrolling but invariant motion. We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109587
--- Comment #4 from Tamar Christina ---
(In reply to Richard Biener from comment #3)
> The issue isn't unrolling but invariant motion. We unroll the innermost
> loop, vectorizer the middle loop and then unroll that as well. That leaves
> us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109587
Bug ID: 109587
Summary: Deeply nested loop unrolling overwhelms register
allocator
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #42 from Tamar Christina ---
Thanks for all the work so far folks!
Just to clarify the current state, it looks like the first reduced testcase is
now correct.
But the larger example as in c26 is still suboptimal, but slightly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109391
Bug ID: 109391
Summary: Inefficient codegen on AArch64 when structure types
are returned
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #25 from Tamar Christina ---
Created attachment 54777
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54777=edit
extracted codegen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #24 from Tamar Christina ---
(In reply to Jakub Jelinek from comment #12)
> (In reply to Richard Biener from comment #11)
> > _1 shoud be [-Inf, nextafter (0.0, -Inf)], not [-Inf, -0.0]
> The reduced testcase is invalid because it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230
--- Comment #11 from Tamar Christina ---
Neither of those vec_perms are valid targets for this optimization.
It looks like sel.series_p is not doing what I expected. It's matching even
elements and ignoring the odd ones.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230
--- Comment #1 from Tamar Christina ---
That patch only fixed the bootstrap, in any case I'm on holidays so have asked
someone else to look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
Tamar Christina changed:
What|Removed |Added
Summary|[13 regression] aarch64 |[13 regression] jump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #2 from Tamar Christina ---
Confirmed, It looks like the extra range information from
g:4fbe3e6aa74dae5c75a73c46ae6683fdecd1a75d is leading jump threading down the
wrong path.
Reduced testcase:
---
int etot_0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109156
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=109156
--- Comment #2 from Tamar Christina ---
(In reply to Richard Biener from comment #1)
> (In reply to Tamar Christina from comment #0)
> > 2. It looks like all targets that implement SAD do so with an instruction
> > that does ABD and then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #1 from Tamar Christina ---
Thanks for the report, taking a look!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109156
Bug ID: 109156
Summary: Support Absolute Difference detection in GCC
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109153
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=109153
--- Comment #3 from Tamar Christina ---
(In reply to Richard Biener from comment #2)
> On the GIMPLE side we should canonicalize here I think, at which point
> inserts into a splatted vector become more profitable depends?
>
> _4 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109153
Bug ID: 109153
Summary: missed vector constructor optimizations
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109130
--- Comment #1 from Tamar Christina ---
I can't reproduce that. on a Neoverse-N1 I see between those two commits:
./bench-compare.sh 2fc55f51f99 bad177e8487
A 1457 files
D 0 files
M 0 files
Extracted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109118
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109072
--- Comment #4 from Tamar Christina ---
(In reply to rsand...@gcc.gnu.org from comment #3)
> (In reply to Tamar Christina from comment #2)
> > I thought the SLP algorithm was bottom up and stores were
> > already sinks?
> Yeah, they are. But
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109072
--- Comment #2 from Tamar Christina ---
(In reply to rsand...@gcc.gnu.org from comment #1)
> (In reply to Tamar Christina from comment #0)
> > The SLP costs went from:
> >
> > Vector cost: 2
> > Scalar cost: 4
> >
> > to:
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109072
Bug ID: 109072
Summary: [12/13 Regression] SLP costs for vec duplicate too
high since g:4963079769c99c4073adfd799885410ad484cbbe
Product: gcc
Version: 12.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106594
--- Comment #17 from Tamar Christina ---
(In reply to Segher Boessenkool from comment #13)
> Hi!
>
> Either this should not be P1, or the proposed patch is taking completely the
> wrong direction. P1 means there is a regression. There is no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106594
Tamar Christina changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org,
301 - 400 of 753 matches
Mail list logo
