https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98772
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2021-01-21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98674
--- Comment #5 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #1)
> Richard, you refactored this code last?
Sorry, forgot about this PR. I'm a bit rusty on this, but how
important is the type/mode check for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98535
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82547
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98730
--- Comment #4 from rsandifo at gcc dot gnu.org
---
Hmm, yeah, looks like it might be a cost issue then.
arm_rtx_costs_internal seems to give CONST_VECTOR
a cost of 1 or 4 instructions, whereas a zero CONST_VECTOR
is free in this context.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92294
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92932
Bug 92932 depends on bug 92294, which changed state.
Bug 92294 Summary: alias attribute generates incorrect code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92294
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96974
--- Comment #6 from rsandifo at gcc dot gnu.org
---
(In reply to Stam Markianos-Wright from comment #5)
> I'm tempted to try and add a reverse:
>
> || multiple_p (*stmt_vectype_out, nunits_vectype)
>
> And then regtest, but I probably
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98535
--- Comment #8 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #6)
> that is, we end up with
>
>[local count: 73320728]:
> _99 = {j$b_2(D)};
> _100 = VIEW_CONVERT_EXPR(_99);
> _101 = [vec_duplicate_expr]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96974
--- Comment #4 from rsandifo at gcc dot gnu.org
---
(In reply to Stam Markianos-Wright from comment #3)
> Just started looking at this. I've narrowed it as the bug appearing with
> commit 9b75f56d4b7951c60a6563964a65787b95bc.
>
> I have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88836
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89057
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Summary|[8/9/10/11 Regression] |[8/9/10 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94994
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Summary|[10/11 Regression] possible |[10 Regression] possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98214
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Summary|[10/11 Regression] SVE: |[10 Regression] SVE: Wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98302
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Summary|[11 Regression] Wrong code |[?? Regression] Wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98314
Bug ID: 98314
Summary: [11 Regression] Install fails with "install -C"
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98852
Bug ID: 98852
Summary: [11 Regression] Conditional expression wrongly
rejected for arm_neon.h vectors
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98863
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Assignee|rguenth at gcc dot gnu.org |rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101105
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101097
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101134
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100089
--- Comment #3 from rsandifo at gcc dot gnu.org
---
Is this really a costing issue, or should we instead reject the
BB fallback if it leaves any scalar COND_EXPRs around? This would
be similar to the way that we reject IFN_MASK_LOAD/STORE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95958
Bug 95958 depends on bug 89057, which changed state.
Bug 89057 Summary: [9 Regression] AArch64 ld3 st4 less optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89057
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89057
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89967
Bug 89967 depends on bug 89057, which changed state.
Bug 89057 Summary: [9 Regression] AArch64 ld3 st4 less optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89057
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685
--- Comment #20 from rsandifo at gcc dot gnu.org
---
(In reply to Eric Gallager from comment #19)
> (In reply to rsand...@gcc.gnu.org from comment #18)
> > (In reply to Eric Gallager from comment #17)
> > > Richard Sandiford had a series of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100846
Bug ID: 100846
Summary: Different vector handling for strided IVs and modulo
conditions
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100849
Bug ID: 100849
Summary: Poor placement of vector IVs
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100848
Bug ID: 100848
Summary: Cases that require -fallow-store-data-races
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100328
--- Comment #7 from rsandifo at gcc dot gnu.org
---
(In reply to Kewen Lin from comment #6)
> Created attachment 51066 [details]
> aarch64 XPASS failure list
>
> The patch v3 bootstrapped and regression-tested on x86_64-redhat-linux and
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101223
--- Comment #10 from rsandifo at gcc dot gnu.org
---
> How can one write 0 - 1 in 1-bit signed though? 1 isn't in the range...
> One can only do 0 + -1 which doesn't overflow, or 0 - -1 which does.
Ah, yeah, of course. So the issue that 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101223
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101267
--- Comment #5 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #4)
> So we're having
>
> (gdb) p debug (slp_node)
> t.f90:1:21: note: node 0x39fbbc0 (max_nunits=2, refcnt=1)
> t.f90:1:21: note: op template: _144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99929
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98136
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94605
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100270
Bug ID: 100270
Summary: _Generic can't distinguish VLS SVE vectors and GNU
vectors
Product: gcc
Version: 10.3.1
Status: UNCONFIRMED
Keywords: rejects-valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100270
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100284
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100270
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |10.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100303
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Summary|[11/12 Regression] |[11 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100305
--- Comment #14 from rsandifo at gcc dot gnu.org
---
(In reply to Gilles Gouaillardet from comment #13)
> Thanks Richard for the quick fix.
>
> I am happy to confirm that the latest trunk passes the three reproducers
> included in this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99249
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98119
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99540
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97960
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|8.5 |10.4
--- Comment #11 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100305
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100284
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100303
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95694
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98302
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96796
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100305
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Summary|[11/12 Regression] aarch64: |[10/11/12 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98863
--- Comment #39 from rsandifo at gcc dot gnu.org
---
Just to give an update on this: I have a patch that reduces the
amount of memory consumed by fwprop so that it no longer seems
to be outlier. However, it involves doing more bitmap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99037
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99037
Bug ID: 99037
Summary: Invalid representation of vector zero in
aarch64-simd.md
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99038
Bug ID: 99038
Summary: aarch64_rtx_costs is missing tests for vector
immediate forms
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98986
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98998
--- Comment #4 from rsandifo at gcc dot gnu.org
---
Thanks for looking at this, and sorry for not having got to
it before now. I've been spending most of the past week fighting
the WRF thing.
(In reply to Jakub Jelinek from comment #3)
> ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96974
--- Comment #9 from rsandifo at gcc dot gnu.org
---
(In reply to Stam Markianos-Wright from comment #8)
> I have a liiitle bit more progress here, but I have a question about
> vect_get_smallest_scalar_type.
>
> If we look at the comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80198
--- Comment #20 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #19)
> So I think when you consider
>
> void __attribute__((noinline)) fun(int * a, int * b, int c)
> {
> int i;
> for (i=0; i < 256; i++) {
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98535
--- Comment #11 from rsandifo at gcc dot gnu.org
---
Fixed on trunk, but it's latent on release branches and should be
fixed there too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96582
--- Comment #6 from rsandifo at gcc dot gnu.org
---
(In reply to Alex Coplan from comment #5)
> so not sure if the issue was really fixed or perhaps just hidden.
Yeah, agree it's probably just gone latent.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99766
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99726
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98136
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Summary|[8/9/10/11 Regression] |[8/9/10 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Assignee|avieira at gcc dot gnu.org |rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97141
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98689
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99560
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99540
--- Comment #10 from rsandifo at gcc dot gnu.org
---
*** Bug 99560 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99252
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99216
--- Comment #9 from rsandifo at gcc dot gnu.org
---
*** Bug 99252 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99781
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98119
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99813
--- Comment #4 from rsandifo at gcc dot gnu.org
---
Thanks for looking at this. I agree swapping the constraints for
operand 2 looks like the right fix, and brings it into line with
*add3_aarch64". I think we need to swap operand 1 too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98917
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99102
--- Comment #7 from rsandifo at gcc dot gnu.org
---
*** Bug 98917 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98268
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96879
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97269
--- Comment #5 from rsandifo at gcc dot gnu.org
---
*** Bug 96879 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97513
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |ASSIGNED
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99873
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99873
Bug ID: 99873
Summary: [11 Regression] GCC no longer makes as much use of ST3
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98119
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Summary|[10/11 Regression] SVE: |[10 Regression] SVE: Wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97141
--- Comment #6 from rsandifo at gcc dot gnu.org
---
*** Bug 98726 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98268
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Summary|[10/11 Regression] ICE: |[10 Regression] ICE:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97141
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Summary|[10/11 Regression] aarch64, |[10 Regression] aarch64,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99726
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Summary|[10/11 Regression] ICE in |[10 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99873
--- Comment #3 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #2)
> We can also undo the splitting if SLP doesn't work out (keep the original
> DR analysis chaining somewhere).
Yeah, that sounds like something we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99596
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726
--- Comment #9 from rsandifo at gcc dot gnu.org
---
I think we should do a variation on (3): use poly-int subtraction
in rtx_vector_builder::step but force the returned value to a constant
using to_constant (). The justification is that the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99540
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
--- Comment #13 from rsandifo at gcc dot gnu.org
---
Sorry for not responding until now, but would it work to make
the "o" constraint check memory_address_addr_space_p too,
like the other memory constraints do? IMO it's wrong for "o"
to accept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99216
--- Comment #5 from rsandifo at gcc dot gnu.org
---
(In reply to Alex Coplan from comment #4)
> Right, the problem appears to be to do with the way that overloaded
> functions are implemented for the ACLE. Specifically the m_direct_overloads
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99973
Bug ID: 99973
Summary: -gsplit-dwarf uses host objcopy for cross compilers
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99873
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97513
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989
--- Comment #3 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #2)
> I don't think we want any initialization unless we invent an explicitely
> "uninitialized" state. Note that wide-int storage is large - I
101 - 200 of 633 matches
Mail list logo