https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113431
--- Comment #21 from Richard Biener ---
(In reply to Jakub Jelinek from comment #20)
> Though, trying that in a cross to arm, with -march=armv9-a
> -munaligned-access it matches (in that case I believe vect_hw_misalign
> should be true), but it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114353
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114351
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114352
--- Comment #2 from Richard Biener ---
*** Bug 114351 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114347
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114346
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114345
--- Comment #4 from Richard Biener ---
Well, the shuffling in .LOAD_LANES will be a bit awkward to do, but sure. We
basically lack "constant folding" of .LOAD_LANES and similarly of course
we can't see through .STORE_LANES of a constant when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114343
Richard Biener changed:
What|Removed |Added
Known to work||13.2.0
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114338
--- Comment #5 from Richard Biener ---
For canonicalization the BIT_AND variants might be preferable since they
possibly combine with other logical ops. Also more constant operands
when the number of operations is the same might be preferable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114337
--- Comment #3 from Richard Biener ---
The linker needs to re-scan for new references to libc and libgcc functions
anyway. For example a structure copy might be expanded as memcpy. We probably
don't introduce new calls to memcpy so maybe for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114334
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114324
--- Comment #3 from Richard Biener ---
So the missed feature is to implement swapping operands of a MINUS_EXPR
during SLP discovery by introducing a conditional negate (for example
by multiplying with { 1, -1 } or with two_operator negate,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114331
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
||rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114324
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
--- Comment #2 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261
--- Comment #9 from Richard Biener ---
As far as I understand the testcase is from fuzzing so not "real", so I think
this proposed "fix" isn't necessary (and it's not a real fix, adding a
setjmp call at the end of the function will restore it).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114323
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114322
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114319
--- Comment #5 from Richard Biener ---
Coalescing successful!
Merged into 1 stores
32 bit bswap implementation found at: _37
looks like we are only merging one store. Note we cannot recognize
bswap to memory this is a known issue. So for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
--- Comment #22 from Richard Biener ---
(In reply to Andrew Macleod from comment #21)
> (In reply to Richard Biener from comment #19)
>
> >
> > While ranger has a range_on_exit API this doesn't work on GENERIC
> > expressions
> > as far as I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114317
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-03-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114318
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114312
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #2 from Richard Biener ---
I will have a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114310
Richard Biener changed:
What|Removed |Added
Target||aarch64
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114308
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
--- Comment #20 from Richard Biener ---
Created attachment 57681
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57681=edit
patch for context sensitive range during SCEV
This is the patch I was playing with.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
--- Comment #19 from Richard Biener ---
So what remains here is differences like
- (chrec = {(long unsigned int) (col_stride_10 * _105), +, (long unsigned int)
col_stride_10}_2)
+ (chrec = (long unsigned int) (int) {(unsigned int)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261
--- Comment #6 from Richard Biener ---
Isn't the "scheduling window" limited somehow? Can we impose an upper bound on
the number of dependences by placing a "virtual barrier" when we hit that
limit?
I don't know the structure of the scheduler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96564
--- Comment #16 from Richard Biener ---
(In reply to Andrew Macleod from comment #15)
> (In reply to Richard Biener from comment #13)
> > (In reply to Jeffrey A. Law from comment #12)
> > > So I think we could solve this with a bit of help from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114297
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114302
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96564
--- Comment #14 from Richard Biener ---
gcc.c-torture/execute/pr64242.c is one of the testcases FAILing (guess it's
invalid)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
Richard Biener changed:
What|Removed |Added
Resolution|--- |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
--- Comment #1 from Richard
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
I see
[ 208s] make[1]: Entering directory
'/home/abuild/rpmbuild/BUILD/lapack-3.9.0/TESTING'
[ 208s] DGEBAL: Testing the balancing of a DOUBLE PRECISION general matrix
[ 208s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114299
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96564
--- Comment #13 from Richard Biener ---
(In reply to Jeffrey A. Law from comment #12)
> So I think we could solve this with a bit of help from the alias oracle. We
> have the routine ptrs_compare_unequal, but points-to-null is going to get
>
|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #3 from Richard Biener ---
OK, so the abort () call is only elided during RTL optimization before the
change. The change itself first manifests during ESRA as
void testK ()
{
- x$j;
unsigned int D.1835;
static unsigned
|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #2 from Richard Biener ---
Confirmed. We gimplify
D.2427 = VIEW_CONVERT_EXPR( VEC_PERM_EXPR < {v, { 0.0, 0.0, 0.0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114297
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=114288
Richard Biener changed:
What|Removed |Added
Keywords||ice-on-valid-code
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114285
--- Comment #1 from Richard Biener ---
Given GCC considers memory to be initialized when you write to it and
copying from A to B involves a write to B the uninit info would be lost if
A is uninitialized. So IMO it's reasonable to diagnose a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
--- Comment #18 from Richard Biener ---
r14-9391-g018ddc86b92851 doesn't seem to make a difference for this aarch64
IVOPTs case. It might be that tree-affine.cc needs similar handling. I'm
going to dig into that on Monday.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 114238, which changed state.
Bug 114238 Summary: [14 regression] Multiple 554.roms_r run-time regressions
(4%-20%) since r14-9193-ga0b1798042d033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114238
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114238
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114269
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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-27% 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=111822
Richard Biener changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114284
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822
--- Comment #12 from Richard Biener ---
(In reply to Uroš Bizjak from comment #11)
> (In reply to Richard Biener from comment #10)
> > The easiest fix would be to refuse applying STV to a insn that
> > can_throw_internal () (that's an insn that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114269
--- Comment #4 from Richard Biener ---
The following is a C testcase for a case where ranges will not help:
void foo (int *a, long js, long je, long is, long ie, long ks, long ke, long
xi, long xj)
{
for (long j = js; j < je; ++j)
for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114074
--- Comment #10 from Richard Biener ---
Some thoughts on the CHREC folding, in the context of the many reported
optimization regressions.
We try to handle { a, +, b } * c as { a * c, +, b * c } and the issue is
cases of undefined overflow this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114269
--- Comment #3 from Richard Biener ---
good (base) vs. bad (peak) on Zen2 with -Ofast -march=native shows
Samples: 654K of event 'cycles', Event count (approx.): 743149709374
Overhead Samples Command Shared Object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114277
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822
--- Comment #10 from Richard Biener ---
The easiest fix would be to refuse applying STV to a insn that
can_throw_internal () (that's an insn that has associated EH info). Updating
in this case would require splitting the BB or at least moving
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
--- Comment #16 from Richard Biener ---
(In reply to Andrew Macleod from comment #12)
>
> all VRP passes are the same now. so just schedule EVRP. in theory, you
> could schedule the fast vrp pass I added, but its not heavily tested... but
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114270
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Target Milestone|--- |14.0
Last reconfirmed||2024-03-08
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
I will look if I can find a nice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114268
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822
--- Comment #7 from Richard Biener ---
IMO verify_flow_info on RTL should ICE with unreachable blocks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822
Richard Biener changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #6 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108355
--- Comment #12 from Richard Biener ---
(In reply to Andrew Pinski from comment #11)
> (In reply to Hans-Peter Nilsson from comment #10)
> > (In reply to Richard Biener from comment #9)
> > > gcc.dg/tree-ssa/ssa-fre-104.c has been XFAILed.
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822
Richard Biener changed:
What|Removed |Added
Status|NEW |WAITING
Priority|P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114252
--- Comment #13 from Richard Biener ---
(In reply to Georg-Johann Lay from comment #12)
> (In reply to Richard Biener from comment #10)
> > I think the target controls the "libcall" ABI that's used for calls to
> > libgcc,
>
> You have a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114252
--- Comment #11 from Richard Biener ---
diff --git a/gcc/gimple-ssa-store-merging.cc b/gcc/gimple-ssa-store-merging.cc
index 42b68abf61b..c9d4662656f 100644
--- a/gcc/gimple-ssa-store-merging.cc
+++ b/gcc/gimple-ssa-store-merging.cc
@@ -170,6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114252
Richard Biener changed:
What|Removed |Added
CC||sayle at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114258
--- Comment #2 from Richard Biener ---
Huh, very strange RTL we emit for the union assignment.
void func_1(union U6 *a) {
g_13 = *a;
}
works OK though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114254
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
--- Comment #14 from Richard Biener ---
(In reply to Andrew Macleod from comment #13)
> Created attachment 57638 [details]
> patch
>
> Ok, there were 2 issues with simply invoking range_of_stmt, which this new
> patch resolves. IF we aren't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114252
--- Comment #7 from Richard Biener ---
Note I do understand what you are saying, just the middle-end in detecting and
using __builtin_bswap32 does what it does everywhere else - it checks whether
the target implements the operation.
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114252
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114239
Richard Biener changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114234
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114239
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114249
--- Comment #9 from Richard Biener ---
*** Bug 114251 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114251
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114252
--- Comment #2 from Richard Biener ---
Looking at avr.md there's no bswap implementation, only the libcall. Why
expose it this way?
I suppose the pattern was added to get bswap recognition, so this is what you
get if you do that?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114252
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114253
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114246
Richard Biener changed:
What|Removed |Added
Summary|[11/12/13/14 Regression]|[11/12/13 Regression] ICE:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114249
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114249
--- Comment #6 from Richard Biener ---
*** Bug 114250 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114250
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114249
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=114247
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 #3 from Richard Biener ---
Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114241
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
--- Comment #11 from Richard Biener ---
(In reply to Richard Biener from comment #10)
> (In reply to Andrew Macleod from comment #9)
> > Created attachment 57620 [details]
> > proposed patch
> >
> > Does this solve your problem if there is an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
--- Comment #10 from Richard Biener ---
(In reply to Andrew Macleod from comment #9)
> Created attachment 57620 [details]
> proposed patch
>
> Does this solve your problem if there is an active ranger? it bootstraps
> with no regressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112307
--- Comment #6 from Richard Biener ---
Thanks, so keeping this open but it will likely end up INVALID.
|P1
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Target Milestone|--- |14.0
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2024-03-05
--- Comment #2 from Richard
|--- |WONTFIX
CC||rguenth at gcc dot gnu.org
--- Comment #1 from Richard Biener ---
Executing store motion of MEM[(short int *)_16] from loop 2
Re-issueing dependent store of *g_70.2_4 from loop 2 on exit 4 -> 5
Moving statement
The ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112307
Richard Biener changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114231
Richard Biener changed:
What|Removed |Added
Summary|[12/13/14 regression] ICE |[12/13 Regression] ICE when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113441
--- Comment #44 from Richard Biener ---
(In reply to Richard Sandiford from comment #42)
> Created attachment 57605 [details]
> proof-of-concept patch to suppress peeling for gaps
>
> How about the attached? It records whether all accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #11 from Richard Biener ---
(In reply to Uroš Bizjak from comment #10)
> Created attachment 57612 [details]
> Prototype patch
>
> Let's try this approach.
Yeah, I guess !TARGET_PARTIAL_REG_STALL || optimize_function_for_size_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114231
--- Comment #12 from Richard Biener ---
So the immediate reason is that between analysis and transform whether we
consider the shift vectorizable changes. That's because we code generated
a live lane which ended up changing operands in stmts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #8 from Richard Biener ---
> grep optimize_ insn-flags.h | wc -l
14
so it's not very many standard patterns that would be affected. I'd say
using these kind of flags on standard patterns is at least fragile?
801 - 900 of 53323 matches
Mail list logo
