https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82854
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> /* 0 - (x & 0x8000) -> x & 0x8000 */
> LLVM does
Actually RTL has done this since at least GCC 4.1.0, most likely before.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71034
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109691
Bug ID: 109691
Summary: Takes until forwprop2 to remove !a sometimes
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: internal-improvement, missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80574
Andrew Pinski changed:
What|Removed |Added
Target Milestone|8.0 |---
--- Comment #8 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101226
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98581
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90883
--- Comment #34 from Andrew Pinski ---
aarch64 was fixed fully with r11-4973-g54bbde550ec5 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49513
Andrew Pinski changed:
What|Removed |Added
Known to work||10.1.0, 11.1.0, 12.1.0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79119
--- Comment #4 from Andrew Pinski ---
Hmm:
# RANGE [irange] long unsigned int [0,
2305843009213693951][16140901064495857664, +INF]
iftmp.0_7 = (long unsigned intD.10) _19;
if (iftmp.0_7 > 2305843009213693951)
So that is _19 < 0 If I read
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103281
--- Comment #8 from Andrew Pinski ---
Hmm:
# RANGE [irange] char [0, 2] NONZERO 0x3
c_9 = (charD.7) b.4_5;
_1 = c_9 <= 0;
Should _1 be replaced with c_9 == 0 which then can be simplified to b.4_5 == 0
That is PR 28794 I think.
And
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109680
--- Comment #5 from Marek Polacek ---
(In reply to Jakub Jelinek from comment #4)
> template
> U __declval (int);
> template
> T __declval (long);
> template
> auto declval () noexcept -> decltype (__declval (0));
> using To = int () const;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109689
--- Comment #1 from Andrew Pinski ---
Maybe r14-301-gf2d6beb7a4ddf18dd or r14-145-g2f4e45101dd812a6f (or
r14-150-gf7b9258e0d4127c1f4 ).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109690
--- Comment #3 from Andrew Pinski ---
So in the case of without -march, we get:
first:
/app/example.cpp:14:24: note: Cost model analysis for part in loop 0:
Vector cost: 28
Scalar cost: 24
so we reject that and then we try it again and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83780
--- Comment #4 from Ed Catmur ---
Clang has fixed this in
https://github.com/llvm/llvm-project/commit/4ddf140c00408ecee9d20f4470e69e0f696d8f8a
(12.0.0-rc1).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109690
--- Comment #2 from Andrew Pinski ---
Even more interesting is:
for (int i = 0; i < 3; i++)
a[i] = ((unsigned)a[i]) << 1;
Produces different code .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109690
--- Comment #1 from Andrew Pinski ---
Without -march=znver1, we get:
vect__10.6_9 = MEM [(int *)];
vect_patt_13.7_8 = VIEW_CONVERT_EXPR(vect__10.6_9);
vect_patt_19.8_1 = vect_patt_13.7_8 << 1;
vect_patt_25.9_2 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109678
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109690
Bug ID: 109690
Summary: bad SLP vectorization on zen
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109689
Andrew Pinski changed:
What|Removed |Added
Summary|ICE at -O1 with |[14 Regression] ICE at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109666
--- Comment #4 from CVS Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:07c52d1eec9671af92b7ce977b469f13a87887ad
commit r14-386-g07c52d1eec9671af92b7ce977b469f13a87887ad
Author: Jason Merrill
Date:
p
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230501 (experimental) (GCC)
[630] %
[630] % gcctk -O1 -ftree-vectorize small.c
during GIMPLE pas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109688
TC changed:
What|Removed |Added
CC||rs2740 at gmail dot com
--- Comment #6 from TC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101339
Andrew Pinski changed:
What|Removed |Added
Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109456
--- Comment #7 from gccriscvuser at proton dot me ---
To be clear, when I said "generator is emitting correct code", I mean with
respect to the ABI specification.
However, this is an actual bug, not a request for enhancement, because the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109688
--- Comment #5 from Andrew Pinski ---
(In reply to Jamaika from comment #4)
> https://github.com/gabime/spdlog/blob/v1.x/example/example.cpp
> ```
> for %%f in ("example.cpp") do g++.exe -v -std=gnu++20 -march=x86-64-v2
> -ftree-vectorize -g0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109688
--- Comment #4 from Jamaika ---
https://github.com/gabime/spdlog/blob/v1.x/example/example.cpp
```
for %%f in ("example.cpp") do g++.exe -v -std=gnu++20 -march=x86-64-v2
-ftree-vectorize -g0 -O3 -fPIC -mavx -mxsave -mpclmul -maes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109688
--- Comment #3 from Jamaika ---
SPDLOG claims that MSVC compiles.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109688
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109688
Andrew Pinski changed:
What|Removed |Added
Summary|Build fail with C++20 and |SPDLOG build fails with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109688
Bug ID: 109688
Summary: Build fail with C++20 and -DSPDLOG_USE_STD_FORMAT=1
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106532
--- Comment #12 from David Harris ---
Thank you for the speedy discovery and resolution.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106532
Andrew Pinski changed:
What|Removed |Added
CC||david_harris at hmc dot edu
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109687
Andrew Pinski changed:
What|Removed |Added
Target|riscv64-elf |riscv32-elf
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109687
--- Comment #1 from David Harris ---
harris@vlsi:~/cvw/benchmarks/embench$ riscv64-unknown-elf-gcc -v
Using built-in specs.
COLLECT_GCC=riscv64-unknown-elf-gcc
COLLECT_LTO_WRAPPER=/opt/riscv/libexec/gcc/riscv64-unknown-elf/12.2.0/lto-wrapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109687
Bug ID: 109687
Summary: riscv64-unknown-elf-gcc internal error on embench when
using bit manipulation extensions
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109456
--- Comment #6 from gccriscvuser at proton dot me ---
I'm willing to agree that the generator is emitting correct code, but in that
case, there should be an error- or fatal-level diagnostic indicating that
`-ffixed` is not supported for `a4`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59666
Sergey Fedorov changed:
What|Removed |Added
CC||vital.had at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109680
--- Comment #4 from Jakub Jelinek ---
template
U __declval (int);
template
T __declval (long);
template
auto declval () noexcept -> decltype (__declval (0));
using To = int () const;
using From = int (*) ();
To foo () { return declval ();
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109641
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109680
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109686
--- Comment #3 from Arsen Arsenović ---
no problem, thank you for reporting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107334
--- Comment #3 from Madhur Chauhan ---
I feel changing the warning text will still cause troubles for people using
-Werror. This forces to use ignore pragmas or disable this warning completely,
none of them are ideal.
Maybe disable warning in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109686
Madhur Chauhan changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107334
Madhur Chauhan changed:
What|Removed |Added
CC||madhur4127 at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109686
Arsen Arsenović changed:
What|Removed |Added
CC||arsen at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109666
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109686
Bug ID: 109686
Summary: Errorneous infinite loop detection
(-Winfinite-recursion)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109685
Bug ID: 109685
Summary: Memory leak in `__deregister_frame`
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105723
--- Comment #6 from Sam James ---
(In reply to Andrew Pinski from comment #5)
> Dup of bug 107852 then.
>
> *** This bug has been marked as a duplicate of bug 107852 ***
.. would've helped if i'd checked the bug referenced, ha. thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684
Bug ID: 109684
Summary: compiling failure: complaining about a final
subroutine of a type being not PURE (while it is
indeed PURE)
Product: gcc
Version: 13.1.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 105723, which changed state.
Bug 105723 Summary: [12 Regression] Optimization false positive warning
(-Wstringop-overflow)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105723
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107852
Andrew Pinski changed:
What|Removed |Added
CC||jeffrey.reynolds@ticketmast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105723
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109676
--- Comment #13 from Jakub Jelinek ---
Created attachment 54963
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54963=edit
gcc14-pr109676.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109677
Patrick Palka changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109437
Benjamin Priour changed:
What|Removed |Added
CC||vultkayn at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109683
Patrick Palka changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109683
Ali Mohammad Pur Fard changed:
What|Removed |Added
CC||ali.mpfard at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109676
--- Comment #12 from Jakub Jelinek ---
The mode is changed in:
1637case REG:
1638 PUT_MODE (src, V1TImode);
1639 /* Call fix_debug_reg_uses only if SRC is never defined. */
1640 if (!DF_REG_DEF_CHAIN (REGNO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105723
Sam James changed:
What|Removed |Added
CC||rguenther at suse dot de
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109683
Bug ID: 109683
Summary: [13/14 Regression] False cyclic dependency error
reported for constraint
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109676
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109680
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93265
--- Comment #3 from Petr Skocik ---
Here's another example (which may be summarizing it more nicely)
struct a{ char _[4]; };
#include
int cmp(struct a A, struct a B){ return !!memcmp(,,4); }
Expected x86-64 codegen (✓ for gcc -O2/-O3 and for
64 matches
Mail list logo
