|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114057
--- Comment #11 from Richard Biener ---
Created attachment 57816
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57816=edit
manually reduced preprocessed source
This is the TU reduced to idihs where I put flatten on, with just -Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114057
--- Comment #10 from Richard Biener ---
So the ref output is
-3.22397e+05
3.07684e+02
1.06621e+10
and before the change we get
-3.22205e+05
3.05161e+02
1.06660e+10
while after it is
-3.22401e+05
3.11606e+02
1.06579e+10
vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114057
--- Comment #9 from Richard Biener ---
Interestingly r14-7272-g57f611604e8bab causes quite some BB vectorization
cases to be rejected - I would have expected it to only get us more
vectorization?
-innerf.f:277:72: optimized: basic block part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114057
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114057
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113724
--- Comment #8 from Richard Biener ---
With release checking we ICE with
t.c: In function 'main':
t.c:46:11: internal compiler error: Segmentation fault
46 | #pragma omp target data map(S1.p[:N],S1.p,S1.a,S1.b)
| ^~~
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113765
--- Comment #5 from Richard Biener ---
Can somebody prepare a patch along this line?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113724
Richard Biener changed:
What|Removed |Added
Known to work||13.2.1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113390
Richard Biener changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113291
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208
--- Comment #21 from Richard Biener ---
Honza, can you please have a look here?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112303
--- Comment #10 from Richard Biener ---
Looks like so, can you test that? I think !(bb->count >= new_count) is good,
we're using this kind of compare regularly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #18 from Richard Biener ---
Just as hint we've had wrong upper bounds on vectorized loops/epilogues which
would trigger wrong unrolling. But then unrolling also always hints as
eventually having wrong range-info.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114471
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114464
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114027
--- Comment #20 from Richard Biener ---
Thanks for reporting.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114464
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114476
Richard Biener changed:
What|Removed |Added
Target Milestone|14.0|13.3
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114475
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
Summary|[14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114473
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.3
Priority|P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114472
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114471
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114468
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114377
Richard Biener changed:
What|Removed |Added
Priority|P1 |P2
Version|unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114303
Richard Biener changed:
What|Removed |Added
Priority|P1 |P2
--- Comment #4 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112470
Richard Biener changed:
What|Removed |Added
Priority|P1 |P2
--- Comment #15 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
Richard Biener changed:
What|Removed |Added
Priority|P1 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51
Richard Biener changed:
What|Removed |Added
Priority|P1 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114398
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.3
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.5
Priority|P3
,
||needs-reduction
Target Milestone|--- |14.0
CC||rguenth at gcc dot gnu.org
Component|middle-end |tree-optimization
--- Comment #1 from Richard Biener ---
x86-64?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114462
--- Comment #1 from Richard Biener ---
Apart from marking via -ffinite-loops GCC considers loops without an exit as
not required to make "forward progress". That's more than just a constant
controlling expression but should allow optimizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114449
--- Comment #5 from Richard Biener ---
Note we do unroll the loop with -O3 but only late after which we do not re-do
bswap recognition (which happens before loop optimization). At -O2 we
don't unroll because that increases code-size too much.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114447
Richard Biener changed:
What|Removed |Added
CC||doko at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114440
Richard Biener changed:
What|Removed |Added
Blocks||53947
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114435
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51
--- Comment #13 from Richard Biener ---
(In reply to Jakub Jelinek from comment #11)
> Perhaps
> --- fold-const.cc.jj8 2024-03-11 22:37:29.0 +0100
> +++ fold-const.cc 2024-03-22 19:31:44.189686120 +0100
> @@ -7104,6 +7104,27 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114432
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #15 from Richard Biener ---
The valgrind output might be because we vectorize the loads a[i], a[i+8], ...
as full vector loads at a[i], a[i+8] but the last we access as scalar. So
the uninit load might be harmless.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #14 from Richard Biener ---
There are a few vectorizations in the dumps but only one early-exit where
we vectorize
[local count: 102053600]:
first$I_39 = MEM[(struct value_op_iterator *)];
last$I_40 = MEM[(struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #48 from Richard Biener ---
So another "simple" way is to keep the redundant insn walking ("it's O(1)") but
remember processsed insns and only re-process those we mark as such.
There might be a free "visited" bit on rtx_insn, who
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #47 from Richard Biener ---
The rtx_equal_p change gets us 50% improvement only, it's necessary to also
disable the added_{links,notes}_insn extra re-processing to get us all the
way to -O1 speed. We'd need the worklist to avoid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #23 from Richard Biener ---
It looks like this could go to suitable_reference_p instead?
That said, I do wonder why with my patch split_data_refs_to_components
doesn't fixup. I think it's supposed to handle the case where
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #9 from Richard Biener ---
Nothing obviously suspicious here ... I wonder if you can attach
177t.ch_vect, 178t.ifcvt and 179t.vect for the case with the single vectorized
bad loop?
Maybe we're running into a latent issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #46 from Richard Biener ---
Maybe combine already knows that it just "keeps i2" rather than replacing it?
When !newi2pat we seem to delete i2. Anyway, somebody more familiar with
combine should produce a good(TM) patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #43 from Richard Biener ---
The interesting bit is that there are only 12026 overall loglinks, the
number of combine attempts is way higher than that would suggest also
given the few successful combinations. So something is odd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
Richard Biener changed:
What|Removed |Added
Known to fail||14.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #19 from Richard Biener ---
But note that {0, +, 3 } and {2, + , 3} with size 2 will still eventually
overlap. See dr_analyze_indices where we attempt to make DR_INIT a
multiple of the element size (probably also not a perfect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #16 from Richard Biener ---
Created attachment 57766
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57766=edit
patch
Oddly enough the following patch doesn't fix it but it correctly prevents us
from recording the access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
Richard Biener changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114419
--- Comment #1 from Richard Biener ---
We need to document llvm requirements here I guess (and stick to llvm17 or
lower for now).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113622
--- Comment #26 from Richard Biener ---
I've enabled vec_set for hard-regs on the branch and plugged the vectorizer
hole for GCC 13. I'm not sure to what extent we need the expansion change.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114231
Richard Biener changed:
What|Removed |Added
Known to fail||13.2.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #41 from Richard Biener ---
(In reply to Segher Boessenkool from comment #38)
> (In reply to Richard Biener from comment #36)
[...]
> But linear is linear, and stays linear, for way too big code it is just as
> acceptable as for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #40 from Richard Biener ---
(In reply to Segher Boessenkool from comment #39)
> (In reply to Richard Biener from comment #37)
> > Created attachment 57753 [details]
> > quick attempt at a limit
> >
> > So like this?
>
> Hrm. It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114203
Richard Biener changed:
What|Removed |Added
Known to work||13.2.1
Resolution|---
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
The gcc.dg/vect/bb-slp-32.c shows that while we now discover both the store
and the reduction as BB vectorization opportunities we merge the SLP
instances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114412
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
--- Comment #1 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114411
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114411
--- Comment #2 from Richard Biener ---
r14-9412-g3e3e4156a5f93e would be likely (but there's a lot of changes in that
range)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114409
--- Comment #6 from Richard Biener ---
The alternative is "bisceting" with -fdbg-cnt=vect_loop (IIRC there were some
ICEs reported when using that, so YMMV)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114408
Richard Biener changed:
What|Removed |Added
Known to work||12.3.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92080
--- Comment #10 from Richard Biener ---
But it's even simpler than the cited case - the mode has the same size (for the
latest testcase, not for the original one, of course).
It's also that after reload a zeroing of V4SImode will also zero ymm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #37 from Richard Biener ---
Created attachment 57753
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57753=edit
quick attempt at a limit
So like this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #36 from Richard Biener ---
(In reply to Segher Boessenkool from comment #35)
> (In reply to Richard Biener from comment #34)
> > The change itself looks reasonable given costs, though maybe 2 -> 2
> > combinations should not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
--- Comment #15 from Richard Biener ---
(In reply to Richard Biener from comment #13)
> The original testcase is fixed, appearantly slapping 'extern' on the int
> makes it not effective.
>
> Possibly better amend the
>
> if (VAR_P (inner)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113727
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
--- Comment #14 from Richard Biener ---
That also fixes
int foo (int __seg_gs *m)
{
return *m;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
Richard Biener changed:
What|Removed |Added
Status|REOPENED|ASSIGNED
--- Comment #13 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
Richard Biener changed:
What|Removed |Added
CC||iii at linux dot ibm.com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114404
Richard Biener changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114396
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #34 from Richard Biener ---
(In reply to Andreas Krebbel from comment #1)
> This appears to be triggered by try_combine unnecessarily setting back the
> position by returning the i2 insn.
>
> When 866 is inserted into 973 866 still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114404
Richard Biener changed:
What|Removed |Added
Component|c |target
--- Comment #3 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396
Richard Biener changed:
What|Removed |Added
Known to work||14.0
Summary|[13/14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114396
--- Comment #9 from Richard Biener ---
(In reply to Robin Dapp from comment #8)
> No fallout on x86 or aarch64.
>
> Of course using false instead of TYPE_SIGN (utype) is also possible and
> maybe clearer?
Well, wi::from_mpz doesn't take a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396
--- Comment #31 from Richard Biener ---
diff --git a/gcc/tree-dfa.cc b/gcc/tree-dfa.cc
index cbd3774b21f..1dbd9bd7a00 100644
--- a/gcc/tree-dfa.cc
+++ b/gcc/tree-dfa.cc
@@ -549,7 +549,8 @@ get_ref_base_and_extent (tree exp, poly_int64 *poffset,
|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #30 from Richard Biener ---
It's LIM2 which applies store-motion to m[0] but keeps m[p] in the loop.
Then with range-info for the int128 of [0, +INF] we get into
get_ref_base_and_extent:
query = get_range_query
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113727
--- Comment #23 from Richard Biener ---
Note with the 2nd patch it's still broken when the BIT_FIELD_REFs in the IL are
not byte aligned.
Both patches passed bootstrap & regtest, there is unknown effect on
optimization of __imag / __real.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114074
Bug 114074 depends on bug 114269, which changed state.
Bug 114269 Summary: [14 Regression] Multiple 3-6% exec time regressions of
434.zeusmp since r14-9193-ga0b1798042d033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114269
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114074
Bug 114074 depends on bug 114151, which changed state.
Bug 114151 Summary: [14 Regression] weird and inefficient codegen and
addressing modes since r14-9193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114269
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114074
Bug 114074 depends on bug 114322, which changed state.
Bug 114322 Summary: [14 Regression] SCEV analysis failed for bases like
A[(i+x)*stride] since r14-9193-ga0b1798042d033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114322
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 114269, which changed state.
Bug 114269 Summary: [14 Regression] Multiple 3-6% exec time regressions of
434.zeusmp since r14-9193-ga0b1798042d033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114269
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114322
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114074
Richard Biener changed:
What|Removed |Added
Summary|[11/12/13 Regression] wrong |[11/12/13/14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114391
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-03-19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114393
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113727
--- Comment #22 from Richard Biener ---
Handling LHS sra_handled_bf_read_p the same as RHS also fixes the issue,
we then detect the partial overlap of the accesses without looking at
grp_partial_lhs.
I wonder if we run into the same issue for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113727
Richard Biener changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
---
|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #20 from Richard Biener ---
I will have a look. Thanks for the reduced testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114375
Richard Biener changed:
What|Removed |Added
Summary|[11/12/13/14 Regression]|[11/12/13 Regression] Wrong
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
We fail to handle SLP of a permuted mask load. See PR114375.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114388
Richard Biener changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114379
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
Blocks|
701 - 800 of 53333 matches
Mail list logo
