https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116005
--- Comment #5 from Andrew Pinski ---
If I change the definition of B to:
template
using B = A;
Then it works in GCC and MSVC but still fails on clang (but that might be a
clang issue).
Note EDG also rejects it.
```
"", line 20: error: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116005
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116005
--- Comment #3 from Andrew Pinski ---
I tested the trunk of clang.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116009
--- Comment #5 from Andrew Pinski ---
Created attachment 58712
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58712=edit
slightly different testcase
So it looks like an interaction between ccmp and late_combine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116009
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116009
Andrew Pinski changed:
What|Removed |Added
Attachment #58710|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116009
--- Comment #2 from Andrew Pinski ---
Created attachment 58710
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58710=edit
Cleanup reduced testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116009
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45215
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82189
--- Comment #4 from Andrew Pinski ---
Note starting GCC 14 on aarch64 we get:
ldp s31, s30, [x1]
add x1, x2, 4
dup v0.4s, v0.s[0]
ld1 {v30.s}[1], [x1]
ld1 {v31.s}[1], [x2]
zip1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116010
Andrew Pinski changed:
What|Removed |Added
Keywords||testsuite-fail
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85012
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98986
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93594
--- Comment #11 from Andrew Pinski ---
I know the missed optimization is fixed in GCC 10 at the RTL level.
But shouldn't these optimized at gimple level to similar to:
```
__m256i cvt_setr1(__m128i low)
{
return __builtin_shufflevector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93613
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105728
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100929
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007
--- Comment #3 from Andrew Pinski ---
> --enable-libquadmath --enable-libquadmath-support
You should not need this since the libc should already have support for 128bit
FP (either double double or IEEE 128bit).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007
Andrew Pinski changed:
What|Removed |Added
Keywords||build
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102951
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108017
--- Comment #3 from Andrew Pinski ---
Related is optimizing:
_1 = (long unsigned int) j_5(D);
_2 = _1 * 4;
t_7 = i_6(D) + _2;
_3 = (long unsigned int) k_8(D);
_4 = _3 * 4;
t1_9 = i_6(D) + _4;
_10 = MAX_EXPR ;
into:
i_6(D) +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116008
--- Comment #1 from Andrew Pinski ---
Note clang/LLVM can optimize the case where j/k are constants but gcc still
does not. e.g.
```
int f2(int i, int j, int k)
{
j = 1;
k = 2;
int t = i+j;
int t1 = i+k;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116008
Bug ID: 116008
Summary: MAX should simplify to MAX+i
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86901
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101200
--- Comment #8 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> For aarch64 we get:
> adrpx1, .LANCHOR0
> add x0, x1, :lo12:.LANCHOR0
> add x0, x0, 8
> ldrbw1, [x1,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907
--- Comment #42 from Andrew Pinski ---
(In reply to frankhb1989 from comment #41)
> I ran into exact the same trouble of C23 missing symbols on old systems. In
> my case it is a custom build (with tailored source) of libfreeimage which
> has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116006
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115990
--- Comment #17 from Andrew Pinski ---
Note the argument about nobody reads documentation does not hold much weight
about doing what we think is right. If that was the argument then -fwrapv and
-fno-strict-aliasing would be defaults in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116005
--- Comment #1 from Andrew Pinski ---
clang rejects it with:
:11:1: error: deduction guide template contains a template parameter
that cannot be deduced
11 | A(std::vector const &) -> A;
| ^
:10:33: note: non-deducible template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46728
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |4.7.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #26 from Andrew Pinski ---
Note I think we should be able to do this without the tracer.
After PRE we get now:
```
if (_1 == 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 531502204]:
_14 = operator new (16);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114192
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115998
Andrew Pinski changed:
What|Removed |Added
Resolution|FIXED |INVALID
--- Comment #4 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115999
Bug ID: 115999
Summary: a - (a>>31) should be transformed into a +
((unsigned)a)>>31 (for signed a)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98772
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96691
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57371
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116001
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57124
Andrew Pinski changed:
What|Removed |Added
Resolution|FIXED |INVALID
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110218
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115998
--- Comment #2 from Andrew Pinski ---
The add 8 to the sp before the jump to g says the return address on the stack
now belongs to g's stack and it is g responsible to realign the stack as
needed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115998
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115993
Bug ID: 115993
Summary: `((A)^C)^B` or `(~A & B) ^ C` is more canonical
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113131
--- Comment #2 from Andrew Pinski ---
```
int f(int A, int B, int C)
{
return ((A)^C)|B; // C|B
}
int f1(int A, int B, int C)
{
return ((A|B)^C)|B; // (C^A)|B
}
int f2(int A, int B, int C)
{
return ((A^B)^C)|B; // (C^A)|B
}
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115991
--- Comment #7 from Andrew Pinski ---
(In reply to Sam James from comment #6)
> The ICE bisects to r15-1945-g9d20529d94b232. The ivopts issue needs to be
> done still.
Note this is basically the same issue as PR 115881 except it could be fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115991
--- Comment #5 from Andrew Pinski ---
Note the testcase in PR 115992 also produces the same broken IV-OPTS even on
aarch64 this time around.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115992
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115991
--- Comment #4 from Andrew Pinski ---
*** Bug 115992 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115991
--- Comment #3 from Andrew Pinski ---
It is ok on aarch64:
ivtmp.16_6 = (unsigned long)
I didn't look into why x86 choices unsigned int and why aarch64 choises
unsigned long though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115991
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115991
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115913
--- Comment #7 from Andrew Pinski ---
The bigger question should `GCC pop_options` also pop the diagnostic option
changes too? or is that only done with `GCC diagnostic pop`.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112626
--- Comment #2 from Andrew Pinski ---
For non wrapping case:
#define func(opname,op) int abs##opname (int a) { return __builtin_abs(a) op a;
}
func(le,<=) // a >= 0
func(lt,<) // false
func(ge,>=) // true
func(gt,>) // a < 0
func(eq,==) //
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115990
--- Comment #9 from Andrew Pinski ---
https://inbox.sourceware.org/gcc-patches/alpine.lnx.2.00.1005251143560.1...@zhemvz.fhfr.qr/
https://inbox.sourceware.org/gcc-patches/alpine.lnx.2.00.1005251147450.1...@zhemvz.fhfr.qr/
Fortran enabling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115990
--- Comment #8 from Andrew Pinski ---
https://inbox.sourceware.org/gcc-patches/alpine.lnx.2.00.1005211345180.1...@zhemvz.fhfr.qr/
The discussion when the patch was posted.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115990
--- Comment #7 from Andrew Pinski ---
https://inbox.sourceware.org/gcc/alpine.lnx.2.00.1005061613520.1...@zhemvz.fhfr.qr/
is the original discussion about adding -Ofast.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115990
--- Comment #5 from Andrew Pinski ---
https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Optimize-Options.html#index-Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115990
--- Comment #4 from Andrew Pinski ---
(In reply to Aaron Ballman from comment #3).
> >
> > People will never read the documentation either way anyways.
>
> Agreed, that's part of why we're deprecating.
That is a real bad excuse really.
Also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115990
--- Comment #2 from Andrew Pinski ---
https://gcc.gnu.org/wiki/FloatingPointMath
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115990
--- Comment #1 from Andrew Pinski ---
I don't think it should be deprecated or removed. It still has its uses.
Documentation is clear too.
We just fixed some documentation about the flags being enabled by -Ofast too.
People will never read
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115982
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-07-18
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115982
Andrew Pinski changed:
What|Removed |Added
Keywords|ra |
Component|rtl-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115985
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115984
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-07-18
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115986
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-07-18
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115986
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109642
Andrew Pinski changed:
What|Removed |Added
CC||durosu at yahoo dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115987
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82776
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115969
--- Comment #7 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #6)
> The problem is here:
> ```
> /* Return TRUE if OP is a valid vector addressing mode. */
>
> bool
> aarch64_simd_mem_operand_p (rtx op)
> {
> return MEM_P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115969
Andrew Pinski changed:
What|Removed |Added
Component|rtl-optimization|target
--- Comment #6 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115969
Andrew Pinski changed:
What|Removed |Added
Component|target |rtl-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115972
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115969
Andrew Pinski changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115969
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115969
--- Comment #2 from Andrew Pinski ---
#5 0x00f7d015 in output_asm_insn (operands=,
templ=0x287a292 "ld1r\t{%0.2s}, %1") at ../../gcc/final.cc:3420
3420 if (*templ == 0)
(gdb) up
(insn:TI 233 1301 1297 (set (reg:V2SI 63 v31)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115977
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115977
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-07-18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115976
Andrew Pinski changed:
What|Removed |Added
Summary|Missing uadd_sat/usub_sat |Missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115974
--- Comment #3 from Andrew Pinski ---
here is testcase for ustrunc at least (note llvm does not use uqxtn here even
though it could):
```
void ustrunc0(unsigned long long *__restrict__ a, unsigned * __restrict__ b)
{
int i = 0;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115974
--- Comment #2 from Andrew Pinski ---
ssadd_optab -> SQADD
usadd_optab -> UQADD
sssub_optab -> SQSUB
ussub_optab -> UQSUB
(q)
ustrunc_optab -> UQXTN
sstrunc_optab -> SQXTN
(aarch64_qmovn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115976
--- Comment #1 from Andrew Pinski ---
Note f2 should really be:
```
void f2(unsigned *__restrict__ a, unsigned * __restrict__ b)
{
for(int i = 0;i < 1024;i ++)
{
long long ta = a[i];
long long tb = b[i];
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115976
Bug ID: 115976
Summary: Missing uadd_sat/usub_sat vectorization
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115975
Bug ID: 115975
Summary: sat_add, etc. vector patterns not done for aarch64
(sve)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115974
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115974
Bug ID: 115974
Summary: sat_add vector patterns not done for aarch64
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115970
--- Comment #1 from Andrew Pinski ---
Isn't this just writing through a named pipe?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115960
--- Comment #6 from Andrew Pinski ---
(In reply to Noah Williams from comment #5)
> It isn't? The library I was trying to compile included the "optional"
> header, and I had looked it up and found it was part of C++ 17, so I thought
> it was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115968
Andrew Pinski changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #4 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107200
Andrew Pinski changed:
What|Removed |Added
CC||summersnow9403 at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107200
Andrew Pinski changed:
What|Removed |Added
CC||akihiko.odaki at daynix dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115291
Andrew Pinski changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #4 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107200
--- Comment #5 from Andrew Pinski ---
See https://libeigen.gitlab.io/docs/TopicPitfalls.html
section "C++11 and the auto keyword" explictly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115966
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115965
--- Comment #7 from Andrew Pinski ---
Note valgrind in this case cannot always capture buffer overruns due to it
cann't easily add a redzone (buffer to detect overruns) for stack arrays. This
is why -fsanitize=address is more powerful than both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115965
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
Bug 63426 depends on bug 115967, which changed state.
Bug 115967 Summary: ubsan: shift exponent 64 is too large for 64-bit type
HOST_WIDE_INT in ext-dce.cc on line 600 since r15-1901-g98914f9eba5f19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115967
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
201 - 300 of 24613 matches
Mail list logo
