https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115240
Bug ID: 115240
Summary: [alias] Does we assume the math function have pure
attribute ?
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112306
Bug ID: 112306
Summary: [AArch64][neon] incorrect combine the (a -1)* b into
fnmsub for fixed vector type
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111584
Bug ID: 111584
Summary: [aarch64] Redundant movprfx with ptrue
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110638
Bug ID: 110638
Summary: [13 regression] memcpy should be inlined with sve loop
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110103
Bug ID: 110103
Summary: the pointers return from two malloc is not equal
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109269
--- Comment #3 from vfdff ---
* test: https://gcc.godbolt.org/z/5s4Wbs466
```
void mset (int *a, int num) {
for (int i=0; i< num; i++)
a[i] = 2;
}
```
* the issue is still exist with int type as we use 32-bits register? . see
detail on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109269
Bug ID: 109269
Summary: [sve] should check the upper bound for predicate sve
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108818
Bug ID: 108818
Summary: [aarch64] use a extra mov instruction compare to llvm
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106323
--- Comment #4 from vfdff ---
Now, llvm use 4 loads and CMP+CCMP, https://gcc.godbolt.org/z/PM3jxEM9M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104611
--- Comment #3 from vfdff ---
As the load instructions usually have long latency, so do it need some extra
restrict when we try this transformation?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107090
--- Comment #11 from vfdff ---
Created attachment 53787
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53787=edit
has different operand order base on different commit node
hi @Andrew Pinski
* Showed as the figure swap_order.jpg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107316
--- Comment #2 from vfdff ---
(In reply to Andrew Pinski from comment #1)
> I suspect this is just a dup of bug 106583 and will be fixed by the patch
> which was submitted recently
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107359
Bug ID: 107359
Summary: [aarch64] should avoid the punpklo/punpkhi compare to
llvm
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107316
Bug ID: 107316
Summary: [aarch64] Init big const value should be improved
compare to llvm
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104611
vfdff changed:
What|Removed |Added
CC||zhongyunde at huawei dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107208
--- Comment #3 from vfdff ---
it seems releted to targetm.calls.function_value called by assign_parms, who
return different behaviour for MODE_COMPLEX_FLOAT and MODE_COMPLEX_INT. With
the following changes, then choose a pair of DI for the int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107090
--- Comment #10 from vfdff ---
Created attachment 53698
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53698=edit
the huge bb sligtly change after match ResLo
Thanks for your suggestion, and I think both ctz_table_index and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107090
--- Comment #8 from vfdff ---
hi @Andrew Pinski
For the 2nd issue, I also matched the huge pattern, but it need return two
value, it seems don't work with current framework? so should I have to split it
into two simples to match the high and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107208
Bug ID: 107208
Summary: [aarch64] llvm generate better code than gcc base on
_Complex type mul
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107090
vfdff changed:
What|Removed |Added
Attachment #53684|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107090
vfdff changed:
What|Removed |Added
CC||zhongyunde at huawei dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107190
Bug ID: 107190
Summary: [aarch64] regression with optimization
-fexpensive-optimizations
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107090
--- Comment #4 from vfdff ---
(In reply to Andrew Pinski from comment #1)
> A few issues.
> First is:
>
> if (_26 != 0)
> goto ; [50.00%]
> else
> goto ; [50.00%]
>
>[local count: 536870913]:
> ht_15 = ht_13 + 4294967296;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107090
--- Comment #2 from vfdff ---
Thanks for your suggestion.
As the combine pass can't address more than 4 sequence insns, which pass may be
more suitable to match the huge pattern after fixing the 1st issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107090
Bug ID: 107090
Summary: [aarch64] sequence logic should be combined with mul
and umulh
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106954
Bug ID: 106954
Summary: [12 Regression] compiler fail base on gfortran
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106353
Bug ID: 106353
Summary: [suboptimal] Why is a 3D array initialized, use case 2
two-layer loop?
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106323
Bug ID: 106323
Summary: [Suboptimal] memcmp(s1, s2, n) == 0 expansion on
AArch64 compare to llvm
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106268
--- Comment #2 from vfdff ---
it seems different for the C version, see detail
https://godbolt.org/z/vc1edYKhf
in your above case, the icc also doesn't elide the outer loop.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106268
Bug ID: 106268
Summary: [suboptimal] Remove unnecessary loops releated to
fortran compare to ifort
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106255
Bug ID: 106255
Summary: [suboptinal] llvm uses instructions with larger access
bit width
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106254
Bug ID: 106254
Summary: [suboptinal] llvm uses instructions with larger access
bit width
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106200
Bug ID: 106200
Summary: Shrink-wrapping opportunity releated to function call
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106146
Bug ID: 106146
Summary: [instcombine] a redundant movprfx insn compare to llvm
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105181
Bug ID: 105181
Summary: [optimization] gcc generate worse code than clang base
on neon
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104045
Bug ID: 104045
Summary: [AArch64] combine related to insn fmaxnm
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94084
vfdff changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101119
Bug ID: 101119
Summary: Missing the check about modify global variable for
__attribute__((const)) function
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100697
Bug ID: 100697
Summary: Missing fwprop for argument register
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
39 matches
Mail list logo
