[Bug tree-optimization/111393] ICE: Segmentation fault src/gcc/toplev.cc:314
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111393 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #11 from Xi Ruoyao --- Read https://www.bitwizard.nl/sig11/. Though it was written for ancient 386 systems I find much of its points are still valid today for modern x86 or non-x86 systems.
[Bug tree-optimization/111422] New: Wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111422
Bug ID: 111422
Summary: Wrong code at -O3 on x86_64-linux-gnu
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
Target Milestone: ---
gcc at -O3 produced the wrong code.
Compiler explorer: https://godbolt.org/z/3b4v478TG
$ cat a.c
int printf(const char *, ...);
int a, b;
int *c = &b;
unsigned d;
char e;
int f=1;
int i(int k, char *l) {
if (k < 6)
return a;
l[0] = l[1] = l[k - 1] = 8;
return 0;
}
int m(int k) {
char g[11];
int h = i(k, g);
return h;
}
int main() {
for (; b < 8; b = b + 1)
;
int j;
int *n[8];
j = 0;
for (;18446744073709551608U + m(*c) + *c + j < 2; j++){
n[j] = &f;
}
for (; e <= 4; e++)
d = *n[0] == f;
printf("%d\n", d);
}
$
$ gcc -O0 a.c && ./a.out
1
$ gcc -O3 a.c && ./a.out
Segmentation fault
$ gcc -O3 -fwrapv a.c && ./a.out
Segmentation fault
$ gcc -fsanitize=address,undefined a.c && ./a.out
1
$
[Bug target/111367] Error: operand out of range (0x1391c is not between 0xffffffffffff8000 and 0x7fff)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111367 Kewen Lin changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #5 from Kewen Lin --- This is 32 bit specific issue, the root cause is that we don't support stack_protect_setsi and stack_protect_testsi to emit prefixed insns, but the previous checks consider it's valid to use them. This is something we missed to update before.
[Bug target/111231] armhf: Miscompilation with -O2/-fno-exceptions level (-O2 is working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231 --- Comment #7 from Mathieu Malaterre --- new cvise setup started today: % cvise check.sh widen_mul_test.cc 00:01:16 INFO ===< 1427429 >=== 00:01:16 INFO running 4 interestingness tests in parallel 00:01:16 INFO INITIAL PASSES 00:01:16 INFO ===< IncludesPass >===
[Bug c++/111423] New: bogus Wsubobject-linkage when using CRTP with an invisible base, template template parameters, and concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111423
Bug ID: 111423
Summary: bogus Wsubobject-linkage when using CRTP with an
invisible base, template template parameters, and
concepts
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: brunopitrus at hotmail dot com
Target Milestone: ---
header.h:
```
template
concept bar = requires(const T& t) {
{ t.GetA() };
};
template typename T>
struct Derived : T>{};
```
main.cpp:
```
#include "header.h"
namespace {
template
struct Base2 {
void GetA() const {}
};
using B2 = Derived;
static_assert(bar);
}
```
This code makes GCC complain with
```
In file included from /app/main.cpp:1:
header.h: In instantiation of 'struct Derived<{anonymous}::Base2>':
/app/header.h:3:7: required from here
/app/header.h:7:8: error: 'Derived<{anonymous}::Base2>' has a base
'{anonymous}::Base2 >' which uses the anonymous
namespace [-Werror=subobject-linkage]
7 | struct Derived : T>{};
|^~~
```
which is incorrect — `Derived<{anonymous}::Base2>` should have internal linkage
due to it being dependent on the internal-linkage `{anonymous}::Base2` —
therefore it should not matter what linkage its bases have.
See it on Godbolt:
https://godbolt.org/z/q7jb5bGb6
[Bug target/111411] [14 regression] ICE when building opus-1.4, unrecognizable insn with -fstack-protector-strong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111411 --- Comment #9 from CVS Commits --- The trunk branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:2d38f45bcca62ca0c7afef4b579f82c5c2a01610 commit r14-4010-g2d38f45bcca62ca0c7afef4b579f82c5c2a01610 Author: Richard Sandiford Date: Fri Sep 15 09:19:14 2023 +0100 aarch64: Fix loose ldpstp check [PR111411] aarch64_operands_ok_for_ldpstp contained the code: /* One of the memory accesses must be a mempair operand. If it is not the first one, they need to be swapped by the peephole. */ if (!aarch64_mem_pair_operand (mem_1, GET_MODE (mem_1)) && !aarch64_mem_pair_operand (mem_2, GET_MODE (mem_2))) return false; But the requirement isn't just that one of the accesses must be a valid mempair operand. It's that the lower access must be, since that's the access that will be used for the instruction operand. gcc/ PR target/111411 * config/aarch64/aarch64.cc (aarch64_operands_ok_for_ldpstp): Require the lower memory access to a mem-pair operand. gcc/testsuite/ PR target/111411 * gcc.dg/rtl/aarch64/pr111411.c: New test.
[Bug target/111411] [14 regression] ICE when building opus-1.4, unrecognizable insn with -fstack-protector-strong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111411 --- Comment #10 from Richard Sandiford --- Fixed on trunk. The patch applies cleanly to GCC 12 and 13, so I'll backport there next week.
[Bug libstdc++/111172] Dead code in std::get for variant?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72 --- Comment #1 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:d19bdf8874059457fdfe50a9e14dad8f8b8cecbb commit r14-4012-gd19bdf8874059457fdfe50a9e14dad8f8b8cecbb Author: Jonathan Wakely Date: Tue Sep 12 21:28:38 2023 +0100 libstdc++: Remove non-void static assertions in variant's std::get [PR72] A void template argument would cause a substitution failure when trying to form a reference for the return type, so the function body would never be instantiated. libstdc++-v3/ChangeLog: PR libstdc++/72 * include/std/variant (get): Remove !is_void static assertions.
[Bug target/111411] [14 regression] ICE when building opus-1.4, unrecognizable insn with -fstack-protector-strong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111411 --- Comment #11 from Martin Jansa --- I can confirm https://gcc.gnu.org/g:2d38f45bcca62ca0c7afef4b579f82c5c2a01610 fixes the other reproducer from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111418 as well. Thank you for quick fix.
[Bug target/111411] [14 regression] ICE when building opus-1.4, unrecognizable insn with -fstack-protector-strong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111411 --- Comment #12 from Martin Jansa --- I can confirm https://gcc.gnu.org/g:2d38f45bcca62ca0c7afef4b579f82c5c2a01610 fixes the other reproducer from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111418 as well. Thank you for quick fix.
[Bug middle-end/106811] GENERIC and GIMPLE IL undefined behavior needs documenting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106811 Richard Biener changed: What|Removed |Added Keywords||documentation Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-09-15 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #5 from Richard Biener --- Mine.
[Bug target/111424] New: LoongArch: Enable vect test suite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111424 Bug ID: 111424 Summary: LoongArch: Enable vect test suite Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: xry111 at gcc dot gnu.org Target Milestone: --- It would help detecting LSX/LASX issues. We need to edit gcc/testsuite/lib/target-supports.exp for this. I have some local modifications but there are still many FAILs to be triaged.
[Bug target/111425] New: ia64: ICE in net/ipv4/fib_semantics.c:1621:1: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111425 Bug ID: 111425 Summary: ia64: ICE in net/ipv4/fib_semantics.c:1621:1: internal compiler error: Segmentation fault Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: frank.scheiner at web dot de Target Milestone: --- Created attachment 55904 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55904&action=edit Used kernel config Hi there, there is a regression present for target ia64 since at least 13.1.0 that also manifests during cross-compilation on amd64 (most likely present also for other cross-compiling host arches, but not checked). Compiling various Linux kernel versions (checked for tags v6.6-rc1, v6.4, v6.0 and v5.19 of the mainline kernel) all lead to the "same" error. It always happens for the same file (actually multiple files when looking at the kernel build attempts in Debian ports (e.g. [1], search for "segmentation fault") but only for the following file for my kernel config): net/ipv4/fib_semantics.c ...and function fib_create_info(). Not sure what the problem is here, moving the function around in the file or adding additional but unsued vars or NOPs doesn't change the outcome, only the line numbers. [1]: https://buildd.debian.org/status/fetch.php?pkg=linux&arch=ia64&ver=6.4.4-2&stamp=1690708282&raw=0 ``` # ia64-linux-gcc -v -freport-bug -Wp,-MMD,net/ipv4/.fib_semantics.o.d -nostdinc -I./arch/ia64/include -I./arch/ia64/include/generated -I./include -I./arch/ia64/include/uapi -I./arch/ia64/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -DHAVE_WORKING_TEXT_ALIGN -DHAVE_MODEL_SMALL_ATTRIBUTE -DHAVE_SERIALIZE_DIRECTIVE -fmacro-prefix-map=./= -std=gnu11 -fshort-wchar -funsigned-char -fno-common -fno-PIE -fno-strict-aliasing -pipe -ffixed-r13 -mfixed-range=f12-f15,f32-f127 -frename-registers -fno-optimize-sibling-calls -fno-delete-null-pointer-checks -O2 -fno-allow-store-data-races -fno-stack-protector -fomit-frame-pointer -ftrivial-auto-var-init=zero -fno-stack-clash-protection -falign-functions=32 -fstrict-flex-arrays=3 -fno-strict-overflow -fno-stack-check -fconserve-stack -Wall -Wundef -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Werror=strict-prototypes -Wno-format-security -Wno-trigraphs -Wno-frame-address -Wno-address-of-packed-member -Wframe-larger-than=2048 -Wno-main -Wno-unused-but-set-variable -Wno-unused-const-variable -Wno-dangling-pointer -Wvla -Wno-pointer-sign -Wcast-function-type -Wno-array-bounds -Wno-alloc-size-larger-than -Wimplicit-fallthrough=5 -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -Wenum-conversion -Wno-unused-but-set-variable -Wno-unused-const-variable -Wno-restrict -Wno-packed-not-aligned -Wno-format-overflow -Wno-format-truncation -Wno-stringop-overflow -Wno-stringop-truncation -Wno-missing-field-initializers -Wno-type-limits -Wno-shift-negative-value -Wno-maybe-uninitialized -Wno-sign-compare -g -mconstant-gp -DKBUILD_MODFILE='"net/ipv4/fib_semantics"' -DKBUILD_BASENAME='"fib_semantics"' -DKBUILD_MODNAME='"fib_semantics"' -D__KBUILD_MODNAME=kmod_fib_semantics -c -o net/ipv4/fib_semantics.o net/ipv4/fib_semantics.c Using built-in specs. COLLECT_GCC=ia64-linux-gcc Target: ia64-linux Configured with: /home/arnd/git/gcc/configure --host=x86_64-linux-gnu --build=aarch64-linux --target=ia64-linux --enable-targets=all --prefix=/home/arnd/cross/x86_64/gcc-13.2.0-nolibc/ia64-linux --enable-languages=c --without-headers --disable-bootstrap --disable-nls --disable-threads --disable-shared --disable-libmudflap --disable-libssp --disable-libgomp --disable-decimal-float --disable-libquadmath --disable-libatomic --disable-libcc1 --disable-libmpx --enable-checking=release --with-static-standard-libraries --with-system-libunwind Thread model: single Supported LTO compression algorithms: zlib zstd gcc version 13.2.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-freport-bug' '-nostdinc' '-I' './arch/ia64/include' '-I' './arch/ia64/include/generated' '-I' './include' '-I' './arch/ia64/include/uapi' '-I' './arch/ia64/include/generated/uapi' '-I' './include/uapi' '-I' './include/generated/uapi' '-include' './include/linux/compiler-version.h' '-include' './include/linux/kconfig.h' '-include' './include/linux/compiler_types.h' '-D' '__KERNEL__' '-D' 'HAVE_WORKING_TEXT_ALIGN' '-D' 'HAVE_MODEL_SMALL_ATTRIBUTE' '-D' 'HAVE_SERIALIZE_DIRECTIVE' '-fmacro-prefix-map=./=' '-std=gnu11' '-fshort-wchar' '-funsigned-char' '-fno-common' '-fno-PIE' '-fno-strict-aliasing' '-pipe' '-ffixed-r13' '-mfixed-range=f12-f15,f32-f127' '-frename-registers' '-fno-optimize-sibling-calls' '-fno-delete-null-pointer-ch
[Bug target/111425] ia64: ICE in net/ipv4/fib_semantics.c:1621:1: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111425 --- Comment #1 from Frank Scheiner --- Created attachment 55905 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55905&action=edit the gzip compressed preprocessed file Added the preprocessed file (gzip compressed due to size of 4.4 MiB).
[Bug fortran/108957] Fortran FE memleak with interfaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108957 --- Comment #6 from CVS Commits --- The master branch has been updated by Mikael Morin : https://gcc.gnu.org/g:e6dba708c8627080f4ca776590a191683b38336c commit r14-4021-ge6dba708c8627080f4ca776590a191683b38336c Author: Mikael Morin Date: Fri Sep 15 13:40:08 2023 +0200 fortran: Remove reference count update [PR108957] Remove one reference count incrementation following the assignment of a symbol pointer to a local variable. Most symbol pointers are "weak" pointer and don't need any reference count update when they are assigned, and it is especially the case of local variables. This fixes a memory leak with the testcase from the PR (not included). PR fortran/108957 gcc/fortran/ChangeLog: * gfortran.h (gfc_symbol): Add comment documenting reference counting. * parse.cc (parse_interface): Remove reference count incrementation.
[Bug target/111425] ia64: ICE in net/ipv4/fib_semantics.c:1621:1: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111425
Richard Biener changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Target||ia64
Last reconfirmed||2023-09-15
--- Comment #2 from Richard Biener ---
Confirmed on trunk - we ICE in cselib during var-tracking, so -fno-var-tracking
would be a workaround (or -g0). We ICE processing mo->insn
(call_insn:TI 6446 8040 8038 59 (parallel [
(set (reg:DI 8 r8)
(call (mem:DI (symbol_ref:DI ("memset") [flags 0x41]
) [0 S8 A64])
(const_int 0 [0])))
(clobber (reg:DI 320 b0))
]) "net/ipv4/fib_semantics.c":703:3 330 {call_value_nogp}
(expr_list:REG_DEAD (reg:DI 122 r74)
(expr_list:REG_DEAD (reg:SI 121 r73)
(expr_list:REG_DEAD (reg:DI 120 r72)
(expr_list:REG_DEAD (reg:DI 1 r1)
(expr_list:REG_UNUSED (reg:DI 8 r8)
(expr_list:REG_CALL_DECL (symbol_ref:DI ("memset")
[flags 0x41] )
(nil)))
(expr_list (use (reg:DI 1 r1))
(expr_list:DI (set (reg:DI 8 r8)
(reg:DI 120 r72))
(expr_list:DI (use (reg:DI 120 r72))
(expr_list:SI (use (reg:SI 121 r73))
(expr_list:DI (use (reg:DI 122 r74))
(nil)))
[Bug tree-optimization/111422] Wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111422 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 CC||rguenth at gcc dot gnu.org Status|UNCONFIRMED |NEW Keywords||needs-bisection, wrong-code Last reconfirmed||2023-09-15 --- Comment #1 from Richard Biener --- Confirmed. We segfault at *n[0], also happens with -O2 -funswitch-loops, still happens with -O3 -fno-unswitch-loops.
[Bug tree-optimization/111422] Wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111422 Richard Biener changed: What|Removed |Added Known to fail||10.4.0, 12.3.1, 7.5.0 --- Comment #2 from Richard Biener --- Hmm, -fstack-reuse=none helps...
[Bug tree-optimization/111422] Wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111422
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #3 from Richard Biener ---
There's a missed optimization. We have
# PT = { D.2843 }
_44 = &g + _43;
...
*_44 = 8;
g ={v} {CLOBBER(eol)};
...
*_44 = 8;
g ={v} {CLOBBER(eol)};
...
*_44 = 8;
g ={v} {CLOBBER(eol)};
I guess the clobber doesn't kill the ref according to stmt_kills_ref_p,
we'd have to special-case singleton points-to sets here. Optimizing the
stores would avoid the bogus sharing of g and n.
[Bug target/111425] ia64: ICE in net/ipv4/fib_semantics.c:1621:1: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111425
--- Comment #3 from Richard Biener ---
Reduced testcase:
enum { REFCOUNT_ADD_NOT_ZERO_OVF } refcount_warn_saturate();
int refcount_inc_not_zero_old, fib_info_num_path___trans_tmp_11,
rtnh_ok_remaining, fib_create_info_nexthop_nh_0, fib_create_info_fi;
struct rtnexthop {
short rtnh_len;
} fib_count_nexthops_rtnh;
struct nexthop *nh;
void atomic_read(int *v) { *(volatile typeof(_Generic(0, default : 0)) *)v; }
typedef struct {
int refs;
} refcount_t;
void refcount_inc_not_zero(refcount_t *r) {
_Bool __trans_tmp_13;
atomic_read(&r->refs);
while (!__trans_tmp_13)
if (__builtin_expect(refcount_inc_not_zero_old, 0))
refcount_warn_saturate();
}
struct nexthop {
refcount_t refcnt;
};
int fib_info_num_path() {
if (__builtin_expect(!nh, 0))
return fib_info_num_path___trans_tmp_11;
}
int rtnh_ok(struct rtnexthop *rtnh) {
return rtnh_ok_remaining && rtnh->rtnh_len <= rtnh_ok_remaining;
}
void fib_create_info() {
struct rtnexthop __trans_tmp_12;
while (rtnh_ok(&fib_count_nexthops_rtnh))
fib_count_nexthops_rtnh = __trans_tmp_12;
if (nh)
refcount_inc_not_zero(&nh->refcnt);
for (; fib_info_num_path();)
fib_create_info_nexthop_nh_0 = fib_create_info_fi;
}
[Bug c++/111426] New: [11/12/13/14 Regression] "error: use of deleted function" printed twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111426
Bug ID: 111426
Summary: [11/12/13/14 Regression] "error: use of deleted
function" printed twice
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
An inaccessible destructor prevents derivation:
struct X {
~X() = delete;
};
class D : public X { };
D d;
but we complain twice:
$ ./cc1plus -quiet q.C
q.C:6:3: error: use of deleted function ‘D::D()’
6 | D d;
| ^
q.C:5:7: note: ‘D::D()’ is implicitly deleted because the default definition
would be ill-formed:
5 | class D : public X { };
| ^
q.C:5:7: error: use of deleted function ‘X::~X()’
q.C:2:3: note: declared here
2 | ~X() = delete;
| ^
q.C:6:3: error: use of deleted function ‘D::~D()’
6 | D d;
| ^
q.C:5:7: note: ‘D::~D()’ is implicitly deleted because the default definition
would be ill-formed:
5 | class D : public X { };
| ^
q.C:5:7: error: use of deleted function ‘X::~X()’
q.C:2:3: note: declared here
2 | ~X() = delete;
| ^
[Bug c++/111426] [11/12/13/14 Regression] "error: use of deleted function" printed twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111426 Marek Polacek changed: What|Removed |Added Target Milestone|--- |11.5 Keywords||diagnostic CC||jason at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-09-15 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=106880 --- Comment #1 from Marek Polacek --- Started with r224842 so it's not a dup of bug 106880. commit d4c9e7f92225d829ad1d18c950066cf99fc58cc7 Author: Jason Merrill Date: Tue Jun 23 10:08:19 2015 -0400 re PR c++/66542 ([C++11] Can create static variable of type that has deleted destructor)
[Bug tree-optimization/111407] ICE: SSA corruption due to widening_mul opt on conflict across an abnormal edge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111407 --- Comment #9 from CVS Commits --- The master branch has been updated by Qing Zhao : https://gcc.gnu.org/g:4aca1cfd6235090e48a53dab734437740671bbf3 commit r14-4034-g4aca1cfd6235090e48a53dab734437740671bbf3 Author: Qing Zhao Date: Fri Sep 15 13:46:52 2023 + Fix PR111407--SSA corruption due to widening_mul opt on conflict across an abnormal edge This is a bug in tree-ssa-math-opts.cc, when applying the widening mul optimization, the compiler needs to check whether the operand is in a ABNORMAL PHI, if YES, we should avoid the transformation. PR tree-optimization/111407 gcc/ChangeLog: * tree-ssa-math-opts.cc (convert_mult_to_widen): Avoid the transform when one of the operands is subject to abnormal coalescing. gcc/testsuite/ChangeLog: * gcc.dg/pr111407.c: New test.
[Bug tree-optimization/111407] ICE: SSA corruption due to widening_mul opt on conflict across an abnormal edge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111407 --- Comment #10 from qinzhao at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #6) the fix has been in GCC14, shall we backport the patch to previous releases?
[Bug other/9346] make uninstall does not remove all files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9346 Tom Tromey changed: What|Removed |Added CC||tromey at gcc dot gnu.org --- Comment #8 from Tom Tromey --- (In reply to Andrew Pinski from comment #6) > uninstall is hard to support really because it means backing up everything > install will overwrite. This is hard to do really. Also it is easy to > install in a clean directory and just remove that directory if you want > uninstall GCC. GNU style "make uninstall" just deletes any files installed by "make install".
[Bug c++/111423] bogus Wsubobject-linkage when using CRTP with an invisible base, template template parameters, and concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111423 Patrick Palka changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED CC||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- dup of PR70413, I think *** This bug has been marked as a duplicate of bug 70413 ***
[Bug c++/70413] Class template names in anonymous namespaces are not globally unique
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70413 Patrick Palka changed: What|Removed |Added CC||brunopitrus at hotmail dot com --- Comment #7 from Patrick Palka --- *** Bug 111423 has been marked as a duplicate of this bug. ***
[Bug c++/70413] Class template names in anonymous namespaces are not globally unique
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70413 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org CC||ppalka at gcc dot gnu.org
[Bug tree-optimization/111414] [14 Regression] ICE in verify_gimple failed since r14-3719-gb34f3736356
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111414 --- Comment #4 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:ba4c1f2bfc9ec063188b39d0281fae04c57b1416 commit r14-4037-gba4c1f2bfc9ec063188b39d0281fae04c57b1416 Author: Andrew Pinski Date: Thu Sep 14 07:39:31 2023 -0700 MATCH: Fix `(1 >> X) != 0` pattern for vector types I had missed that integer_onep can match vector types with uniform constant of `1`. This means the shifter could be an scalar type and then doing a comparison against `0` would be an invalid transformation. This fixes the problem by adding a check for the type of the integer_onep to make sure it is a INTEGRAL_TYPE_P (which does not match a vector type). OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. PR tree-optimization/111414 gcc/ChangeLog: * match.pd (`(1 >> X) != 0`): Check to see if the integer_onep was an integral type (not a vector type). gcc/testsuite/ChangeLog: * gcc.c-torture/compile/pr111414-1.c: New test.
[Bug tree-optimization/111414] [14 Regression] ICE in verify_gimple failed since r14-3719-gb34f3736356
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111414 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Andrew Pinski --- Fixed.
[Bug tree-optimization/110992] [13/14 Regression] missed VRP optimization due to transformation of `a & -zero_one_valued_p` into `a * zero_one_valued_p`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110992
--- Comment #9 from Andrew Pinski ---
This is what I have so far:
/* Transform (a * { 0 or 1 }) != 0 into {0 or 1} != 0 & (a != 0) */
/* Transform (a * { 0 or 1 }) == 0 into ({0 or 1} == 0) | (a == 0) */
(for cmp (ne eq)
bit_op (bit_and bit_ior)
(simplify
(cmp (mult:cs @0 zero_one_valued_p@1) integer_zerop@2)
(bit_op (cmp @1 { build_zero_cst (TREE_TYPE (@1)); })
(cmp @0 @2
/* zero_one_valued_p != 0 -> (cast)zero_one_valued_p */
(simplify
(ne zero_one_valued_p@0 integer_zerop)
(convert @0))
[Bug target/111420] relocation truncated to fit: R_RISCV_JAL against `.L12287'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111420 --- Comment #6 from AK --- To confirm what Andrew mentioned, the release build (-O3) built successfully.
[Bug c++/90670] const& template parameter in a header trips -Wsubobject-linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90670 Patrick Palka changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED CC||ppalka at gcc dot gnu.org --- Comment #2 from Patrick Palka --- The warning seems right to me: the const DummyId has internal linkage, which makes the type seChildScheduleAccess have internal linkage, which makes the definition of seGccBugJob (strictly speaking) different in different TUs. So the warning is correctly exposing a potential ODR violation. To fix the ODR violation, you can declare DummyId 'inline'.
[Bug c/111421] constexpr not working with array subscript
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111421 --- Comment #1 from joseph at codesourcery dot com --- See the definitions of "named constant" and "compound literal constant". Array element accesses aren't allowed, and the example you have with "->" shouldn't be accepted either (although the standard rules for implementation-defined constant expressions probably allow implementations to accept such an example if they so choose).
[Bug c/111421] constexpr not working with array subscript
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111421 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Marek Polacek --- Invalid then.
[Bug c/111421] constexpr not working with array subscript
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111421 --- Comment #3 from Abdulmalek Almkainzi --- (In reply to jos...@codesourcery.com from comment #1) > See the definitions of "named constant" and "compound literal constant". > Array element accesses aren't allowed, and the example you have with "->" > shouldn't be accepted either (although the standard rules for > implementation-defined constant expressions probably allow implementations > to accept such an example if they so choose). Alright, I see how this is not a GCC bug and instead part of the standard. But may I ask how this is even the case? the expression is constant and can be evaluated at compile time.
[Bug fortran/30802] out of bounds error array I/O not picked up with -fbounds-check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30802 --- Comment #12 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:1cbf18978aa384bd0ed2dc29b107fc3423cf8e62 commit r14-4039-g1cbf18978aa384bd0ed2dc29b107fc3423cf8e62 Author: Harald Anlauf Date: Fri Sep 15 19:13:38 2023 +0200 Fortran: improve bounds-checking for array sections [PR30802] gcc/fortran/ChangeLog: PR fortran/30802 * trans-array.cc (trans_array_bound_check): Add optional argument COMPNAME for explicit specification of array component name. (array_bound_check_elemental): Helper function for generating bounds-checking code for elemental dimensions. (gfc_conv_expr_descriptor): Use bounds-checking also for elemental dimensions, i.e. those not handled by the scalarizer. gcc/testsuite/ChangeLog: PR fortran/30802 * gfortran.dg/bounds_check_fail_6.f90: New test.
[Bug c/111421] constexpr not working with array subscript
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111421 --- Comment #4 from joseph at codesourcery dot com --- The definition of constexpr in C2x is intentionally minimal, with potential for future expansion in subsequent standard revisions. Allowing array element accesses would run into needing an appropriate definition of exactly what cases are allowed and don't count as accessing the value of an object (presumably including requiring the array element index itself to be an integer constant expression within range for the array in question).
[Bug fortran/108957] Fortran FE memleak with interfaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108957 Mikael Morin changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Mikael Morin --- Fixed for gfortran 14, closing.
[Bug fortran/106050] ICE in reject_statement, at fortran/parse.cc:2879 since r8-3056-g5bab4c9631c478b7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106050 Mikael Morin changed: What|Removed |Added Target Milestone|--- |14.0
[Bug fortran/108957] Fortran FE memleak with interfaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108957 Mikael Morin changed: What|Removed |Added Target Milestone|--- |14.0
[Bug fortran/110996] RISC-V vector Fortran: SEGV ICE during parsing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996 Mikael Morin changed: What|Removed |Added Target Milestone|--- |14.0
[Bug c++/98820] Placeholder (auto) non-type template parameter wrongly deduced to 'const' for class type arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98820 Patrick Palka changed: What|Removed |Added CC||johelegp at gmail dot com --- Comment #2 from Patrick Palka --- *** Bug 99631 has been marked as a duplicate of this bug. ***
[Bug c++/99631] decltype of non-type template-parameter shouldn't be const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99631 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #8 from Patrick Palka --- dup of PR98820 *** This bug has been marked as a duplicate of bug 98820 ***
[Bug c++/99631] decltype of non-type template-parameter shouldn't be const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99631 Patrick Palka changed: What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|DUPLICATE |--- Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org --- Comment #9 from Patrick Palka --- Actually it's probably better to mark PR98820 as the dup
[Bug c++/98820] Placeholder (auto) non-type template parameter wrongly deduced to 'const' for class type arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98820 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Patrick Palka --- dup *** This bug has been marked as a duplicate of bug 99631 ***
[Bug c++/99631] decltype of non-type template-parameter shouldn't be const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99631 Patrick Palka changed: What|Removed |Added CC||davveston at gmail dot com --- Comment #10 from Patrick Palka --- *** Bug 98820 has been marked as a duplicate of this bug. ***
[Bug target/110792] [13/14 Regression] GCC 13 x86_32 miscompilation of Whirlpool hash function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110792 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #16 from Marek Polacek --- (In reply to Sam James from comment #15) > Roger, is this one ready to backport to releases/gcc-13 so we can pick it up > easily downstream via the branch snapshots, or do you want to let it bake on > trunk a bit longer? Cheers. I have the same question.
[Bug c++/87452] decltype ignores namespace in trailing return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87452 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Patrick Palka --- Looks like this is fixed for GCC 12+ by r12-6022-gbb2a7f80a98de3 *** This bug has been marked as a duplicate of bug 51577 ***
[Bug c++/51577] dependent name lookup finds operator in global namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577 Patrick Palka changed: What|Removed |Added CC||schuchart at icl dot utk.edu --- Comment #24 from Patrick Palka --- *** Bug 87452 has been marked as a duplicate of this bug. ***
[Bug fortran/97039] -fbounds-check misses violation with slice of array but not an element
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97039 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #4 from anlauf at gcc dot gnu.org --- Should be fixed by r14-4039-g1cbf18978aa384 for pr30802. Thus marking as duplicate. *** This bug has been marked as a duplicate of bug 30802 ***
[Bug fortran/30802] out of bounds error array I/O not picked up with -fbounds-check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30802 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anthony.debeus at gmail dot com --- Comment #13 from anlauf at gcc dot gnu.org --- *** Bug 97039 has been marked as a duplicate of this bug. ***
[Bug fortran/27766] [meta-bug] -fbounds-check related bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27766 Bug 27766 depends on bug 30802, which changed state. Bug 30802 Summary: out of bounds error array I/O not picked up with -fbounds-check https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30802 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/30802] out of bounds error array I/O not picked up with -fbounds-check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30802 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |14.0 --- Comment #14 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-14.
[Bug fortran/37802] Improve wording for matmul bound checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37802 Bug 37802 depends on bug 30802, which changed state. Bug 30802 Summary: out of bounds error array I/O not picked up with -fbounds-check https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30802 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug driver/86030] specs file processing does not create response files for input directories
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030 --- Comment #16 from John Soo --- It is actually somewhat likely that ARG_MAX will be hit when running on linux because it is hit when the stack can't contain enough pointers to contain argv and environ (see exec.c in the kernel https://github.com/torvalds/linux/blob/master/fs/exec.c#L509). The bad news is that response files can only mitigate the problem since environ must also be small enough to fit into an execv* call. Is there a reasonable way to keep only the env vars required to exec subprocesses?
[Bug fortran/93485] ICE in gfc_trans_array_ctor_element, at fortran/trans-array.c:1682
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93485 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Known to work||11.3.0, 12.1.0, 13.1.0, ||14.0 Status|WAITING |RESOLVED Known to fail||10.5.0 --- Comment #4 from anlauf at gcc dot gnu.org --- Apparently fixed since gcc-11. Closing.
[Bug other/111406] libiberty build produces errors with CC=clang, unsupported option '-print-multi-os-directory'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111406 --- Comment #4 from Andreas K. Huettel --- (In reply to Richard Biener from comment #3) > > So I think this isn't an issue unless you try to build libiberty stand-alone > or as part of binutils and also install it? > We have a binutils-libs package, which installs libbfd, libctf, libopcodes, libsframe, and a statical libiberty.a
[Bug tree-optimization/110131] [12/13/14 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r12-6924-gc2b610e7c6c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110131 --- Comment #10 from Andrew Pinski --- (In reply to Andrew Pinski from comment #8) > With https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629128.html we > get: > _34 = (int) _13; > _30 = (unsigned int) _13; > _22 = _30 == 4294967295; > _35 = _22 ? _34 : 0; Maybe: (simplify (cond (eq (convert1?@4 @0) INTEGER_CST@1) (convert2? @0) INTEGER_CST@3) (if (type is a nop_conversion type from @1) (cond! @4 (convert @1) @3))) This should give: _30 = (unsigned int) _13; _22 = _30 == 4294967295; _35 = _22 ? -1 : 0; if (_35 != 5) _35 will -(convert)_22 really. Anyways VRP will notice that _35 can't be 5 and optimize it out.
[Bug other/111427] New: [14 regression] gfortran.dg/vect/pr60510.f fails after r14-3999-g3c834d85f2ec42
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111427
Bug ID: 111427
Summary: [14 regression] gfortran.dg/vect/pr60510.f fails after
r14-3999-g3c834d85f2ec42
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at gcc dot gnu.org
Target Milestone: ---
g:3c834d85f2ec42c60995c2b678196a06cb744959, r14-3999-g3c834d85f2ec42
make -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'
vect.exp=gfortran.dg/vect/pr60510.f"
spawn [open ...]
STOP 1
FAIL: gfortran.dg/vect/pr60510.f -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions execution test
commit 3c834d85f2ec42c60995c2b678196a06cb744959
Author: Vladimir N. Makarov
Date: Thu Sep 14 10:26:48 2023 -0400
[RA]: Improve cost calculation of pseudos with equivalences
Looks like this actually only happens with -m32.
[Bug target/111428] New: RISC-V vector: Flaky segfault in {min|max}val_char_{1|2}.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111428
Bug ID: 111428
Summary: RISC-V vector: Flaky segfault in
{min|max}val_char_{1|2}.f90
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick at rivosinc dot com
Target Milestone: ---
Created attachment 55906
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55906&action=edit
Excerpt from the debug log
Failures:
FAIL: gfortran.dg/minval_char_1.f90 -O3 -g execution test
FAIL: gfortran.dg/minval_char_1.f90 -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions execution test
FAIL: gfortran.dg/minval_char_2.f90 -O3 -g execution test
FAIL: gfortran.dg/minval_char_2.f90 -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions execution test
FAIL: gfortran.dg/maxval_char_1.f90 -O3 -g execution test
FAIL: gfortran.dg/maxval_char_1.f90 -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions execution test
FAIL: gfortran.dg/maxval_char_2.f90 -O3 -g execution test
FAIL: gfortran.dg/maxval_char_2.f90 -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions execution test
Observed on:
rv64gcv_zvbb_zvbc_zvkg_zvkn_zvknc_zvkned_zvkng_zvknha_zvknhb_zvks_zvksc_zvksed_zvksg_zvksh_zvkt-lp64d
rv64gcv-lp64d
rv64imafdcv_zicond_zawrs_zbc_zvkng_zvksg_zvbb_zvbc_zicsr_zba_zbb_zbs_zicbom_zicbop_zicboz_zfhmin_zkt-lp64d
Seems to only occur on rv64 glibc targets with the v extension enabled.
Known to pass: r14-3834-gd05aac047e0
Known to fail: r14-3840-g88a0a883960
Replicated locally using
https://github.com/patrick-rivos/riscv-gnu-toolchain/tree/29d071a8eec4603ff5fe4fe21d7e4ffa24f705f0
git submodule update --init gcc
cd gcc && git checkout 316d57da5bb9205b946afc56d78582fee874e4b5
cd .. && mkdir build && cd build
../configure --prefix=$(pwd) --with-arch=rv64gcv --with-abi=lp64
make report-linux -j32
There was previously flaky behavior with these testcases, but it's been
resolved for other targets:
https://gcc.gnu.org/legacy-ml/gcc-patches/2017-12/msg00807.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83379
[Bug tree-optimization/57755] Improve fold_binary_op_with_conditional_arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57755
--- Comment #6 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> I think we should optimize this testcases slightly different from
> "improving" fold_binary_op_with_conditional_arg (I think
> fold_binary_op_with_conditional_arg
> should go away even but that is a different story).
>
> Let's start with:
> ```
> int f(int a,int b){
> return (((a<=3)?-1:0)&((b<=2)?-1:0))!=0;
> }
> ```
> After ccp1 we have:
> # iftmp.1_4 = PHI <-1(4), 0(5)>
> _1 = iftmp.0_3 & iftmp.1_4;
>
> But really that should just become:
> # _1 = PHI
>
> PRE does that but that is way too late.
Actually another way of fixing the above is we have in forwprop3:
_14 = a_5(D) <= 3;
_17 = (int) _14;
_18 = -_17;
_9 = b_6(D) <= 2;
_12 = (int) _9;
_1 = _12 * _18;
_2 = _1 != 0;
_7 = (int) _2;
Well we can see (_12 * _18) != 0 is really _12 != 0 & _18 != 0 which can be
done easier as _12 has a range of [0,1].
If we do that then in forwprop3 we get:
_9 = b_6(D) <= 2;
_3 = a_5(D) <= 3;
_2 = _3 & _9;
_7 = (int) _2;
which what we want ...
That is that transformation is what we have in bug 110992 comment #9 . the
reason for the check of [0,1] is that we know there would be no overflows and
can be safely done no matter what.
[Bug target/111259] [14 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1934 during riscv64 build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111259 --- Comment #1 from CVS Commits --- The master branch has been updated by Patrick O'Neill : https://gcc.gnu.org/g:d7b6020276a843e97f6135259b4ab3b53a5850e2 commit r14-4044-gd7b6020276a843e97f6135259b4ab3b53a5850e2 Author: Fei Gao Date: Fri Sep 15 01:20:08 2023 + fix PR 111259 invalid zcmp mov predicate. The code changes are from Palmer. root cause: In a gcc build with --enable-checking=yes, REGNO (op) checks rtx code and expected code 'reg'. so a rtx with 'subreg' causes an internal compiler error. solution: Restrict predicate to allow 'reg' only. gcc/ChangeLog: * config/riscv/predicates.md: Restrict predicate to allow 'reg' only. Reviewed-by: Palmer Dabbelt Acked-by: Palmer Dabbelt
[Bug analyzer/111312] Should the analyzer run earlier?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111312 --- Comment #3 from David Malcolm --- Another example can be seen here: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628759.html in: gcc/testsuite/c-c++-common/analyzer/overlapping-buffers.c where -Wanalyzer-overlapping-buffers only catches cases that the optimizer doesn't see; others it misses due to them being optimized away due to undefined behavior.
[Bug tree-optimization/110992] [13/14 Regression] missed VRP optimization due to transformation of `a & -zero_one_valued_p` into `a * zero_one_valued_p`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110992
--- Comment #10 from Andrew Pinski ---
This is what I came up with in the end:
/* (a * b@[0,1]) == CST
->
CST == 0 ? (a == CST | b == 0) : (a == CST & b != 0)
(a * b@[0,1]) != CST
->
CST != 0 ? (a != CST | b == 0) : (a != CST & b != 0) */
(for cmp (ne eq)
(simplify
(cmp (mult:cs @0 zero_one_valued_p@1) INTEGER_CST@2)
(if ((cmp == EQ_EXPR) ^ (wi::to_wide (@2) != 0))
(bit_ior
(cmp @0 @2)
(convert (bit_xor @1 { build_one_cst (TREE_TYPE (@1)); })))
(bit_and (cmp @0 @2) (convert @1)
This allows more than just CST == 0 even. I will write up some testcases now
...
[Bug middle-end/111429] New: NO_COLOR env should disable color
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111429 Bug ID: 111429 Summary: NO_COLOR env should disable color Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Similar as gdb now supports here: https://sourceware.org/pipermail/gdb-patches/2023-September/202528.html
[Bug ipa/111430] New: IPA read only variable analysis should handle the case where the storing was the same as the initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111430
Bug ID: 111430
Summary: IPA read only variable analysis should handle the case
where the storing was the same as the initialization
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Take:
```
#define CST 1025
static int b = CST;
void f(int a)
{
if (a)
b = CST;
}
int g(void)
{
return b;
}
```
We should be able to optimize out the store to b in f and even the load in g.
This is another way of solving the original testcase in PR 110992.
[Bug ipa/111430] IPA read only variable analysis should handle the case where the storing was the same as the initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111430 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug ipa/111430] IPA read only variable analysis should handle the case where the storing was the same as the initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111430 --- Comment #1 from Andrew Pinski --- Note LLVM does this optimization ...
[Bug c++/90670] const& template parameter in a header trips -Wsubobject-linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90670 --- Comment #3 from Adam Byrd --- Hmm, I reckon that makes sense. Though the wording is confusing. Why is it "uses the anonymous namespace" instead of something like "has internal linkage". I'm not aware of an anonymous namespace being involved here. Is that language esoterica or a compiler implementation detail?
[Bug c++/90670] const& template parameter in a header trips -Wsubobject-linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90670 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=86491 --- Comment #4 from Andrew Pinski --- (In reply to Adam Byrd from comment #3) > I'm not aware of an anonymous namespace being involved here. Is that > language esoterica or a compiler implementation detail? Since GCC 13, the diagnostic is: In file included from t66.cc:1: t66.h:7:8: warning: ‘seGccBugJob’ has a field ‘seChildScheduleAccess seGccBugJob::m_test’ whose type has internal linkage [-Wsubobject-linkage] 7 | struct seGccBugJob |^~~ Basically the diagnostic was not updated for C++11 changes ...
[Bug tree-optimization/57755] Improve fold_binary_op_with_conditional_arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57755 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED Severity|normal |enhancement See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=94274 --- Comment #7 from Andrew Pinski --- Undoing the badness of fold_binary_op_with_conditional_arg is PR 94274. I have a patch which handles what fold_binary_op_with_conditional_arg is trying to solve in phiopt though currently only handles constants but I suspect I could extend it to ssa names too ..
[Bug tree-optimization/111431] New: a & (a == 0) is not optimized to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111431
Bug ID: 111431
Summary: a & (a == 0) is not optimized to 0
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization, xfail
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
int
foo (int a)
{
int b = !a;
return (a & b);
}
```
The general rule is:
(a == CST) & a
transform into:
(CST & 1) ? (a == CST) : 0
So
(simplify
(bit_and:c (convert@2 (eq @0 INTEGER_CST@1)) @0)
(if ((wi::to_wide (@1) & 1) != 0)
@2
{ build_zero_cst (type); }))
[Bug tree-optimization/111431] a & (a == 0) is not optimized to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111431 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-09-16 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- The following testcases are xfailed because of this missing optimization: gcc.dg/binop-notand1a.c gcc.dg/binop-notand4a.c
[Bug tree-optimization/111431] a & (a == 0) is not optimized to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111431
--- Comment #2 from Andrew Pinski ---
The pattern should be:
(simplify
(bit_and:c (convert@2 (eq @0 INTEGER_CST@1)) (convert? @0))
(if ((wi::to_wide (@1) & 1) != 0)
@2
{ build_zero_cst (type); }))
Since 0/1 of the eq, the convert on the @0 inside the bit_and does not matter.
[Bug tree-optimization/111431] a & (a == 0) is not optimized to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111431 --- Comment #3 from Andrew Pinski --- Note this is an extension of the pattern: /* X & !X -> 0. */ (simplify (bit_and:c @0 (logical_inverted_value @0)) Which was moved to match via r5-4683-g5609420fbab5ca .
[Bug tree-optimization/111431] a & (a == 0) is not optimized to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111431 --- Comment #4 from Andrew Pinski --- Note I found this while looking into the patch that was originally posted for PR 57755 which removed the xfail for binop-notand1a.c/binop-notand4a.c but found this was a better way of fixing this rather than that old patch. Plus there can be more benifit out of it too.
[Bug tree-optimization/111431] a & (a == 0) is not optimized to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111431 --- Comment #5 from Andrew Pinski --- Created attachment 55907 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55907&action=edit Patch which I am testing I should note that LLVM does NOT do this simple pattern matching either.
[Bug tree-optimization/111432] New: `bool & (a|1)` is not optimized to just `bool`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111432
Bug ID: 111432
Summary: `bool & (a|1)` is not optimized to just `bool`
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
take:
```
int
foo3(int c, int bb)
{
if ((bb & ~3)!=0) __builtin_unreachable();
return (bb & (c|3));
}
int
foo_bool(int c, _Bool bb)
{
return (bb & (c|7));
}
```
foo3 should be optimized to just `return bb`, likewise for foo_bool.
Note LLVM does this.
[Bug tree-optimization/110502] [14 Regression] Dead Code Elimination Regression at -Os since r14-1656-g55fcaa9a8bd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110502 --- Comment #3 from Andrew Pinski --- Note LIM2 has way different IR selection which is kinda interesting since there are no stores that happened in the bbs that were removed: if (_2 != 0) goto ; [75.00%] else goto ; [25.00%] [local count: 6515660663]: iftmp.8_23 = s.5_14 + -3; [local count: 8687547565]: # iftmp.8_24 = PHI
[Bug tree-optimization/95408] Failure to optimize bitwise and with negated conditional using the same operand to conditional with decremented operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95408 Andrew Pinski changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-Septemb ||er/630651.html Keywords||patch --- Comment #3 from Andrew Pinski --- I was looking for this one when I wrote https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630651.html .
