[Bug c++/111974] internal error: Segmentation fault on Ubuntu 23.10 (x86-64) - compiling RefPerSys
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111974 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #5 from Sam James --- (In reply to Jonathan Wakely from comment #2) > (In reply to Basile Starynkevitch from comment #0) > > Please submit a full bug report, with preprocessed source (by using > > -freport-bug). > > ^^^ Yes, please do this. We need a preprocessed file.
[Bug c/112112] Improper Arithmetic Type Conversion in s390x-linux-gnu-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112112 --- Comment #2 from Andrew Pinski --- One thing you should note (most likely not an issue here) is that plain char can default to signed or unsigned depending on the arch/abi .
[Bug c/112112] Improper Arithmetic Type Conversion in s390x-linux-gnu-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112112 --- Comment #1 from 김대영 <22s302h0659 at sonline20 dot sen.go.kr> --- Created attachment 56320 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56320=edit bug_Poc Codes.
[Bug c/112112] New: Improper Arithmetic Type Conversion in s390x-linux-gnu-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112112
Bug ID: 112112
Summary: Improper Arithmetic Type Conversion in
s390x-linux-gnu-gcc
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: 22s302h0659 at sonline20 dot sen.go.kr
Target Milestone: ---
### Environment
- Compiler: s390x-linux-gnu-gcc (64bit)
- Version: gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)
- Platform: Windows 11_5.15.90.1-microsoft-standard-WSL2
- Build Optimization Options: O0, O1, O2, O3
I installed the s390x-linux-gnu toolchain using the 'apt' package manager in
Ubuntu and utilized s390x-linux-gnu-gcc (version 11.4.0) from it.
### Summary
Using the legacy C code generator 'csmith' to generate test cases, I am
performing fuzzing on the GCC compiler for various architectures and
optimization options. I have discovered a bug specific to the s390x
architecture, and I will be reporting it.
### Source Code
I have prepared an 'binarys.zip' archive containing two versions of the bug PoC
code, along with '[c.sh](http://c.sh/)' for compiling them and
'[r.sh](http://r.sh/)' for running them
```bash
1 // bug_Poc1.c
2 #include
3 char v1 = -1;
4 short v2 = 1;
5 int main()
6 {
7 printf("bug = %d\n", v1 <= v2);
8 return 0;
9 }
```
```bash
// result
bug_O0 = 0
bug_O1 = 0
bug_O2 = 1
bug_O3 = 1
```
Line 7 yields a correct result of 1 for the normal comparison operation.
However, with the O0 and O1 optimization options, it returns 0. With O2 and O3,
it correctly returns 1. I conducted tests to confirm the possibility of this
bug occurring in cross-compilers for the same version but different
architectures, but it consistently output the correct value of 1.
```bash
1 // bug_Poc2.c
2 #include
3 char v1 = -1;
4 short v2 = 1;
5 int main()
6 {
7 printf("bug = %d\n", v1 >= v2);
8 return 0;
9 }
```
```bash
// result
bug_O0 = 1
bug_O1 = 1
bug_O2 = 0
bug_O3 = 0
```
On the 7th line, the normal comparison operation results in 0. However, with
the O0 and O1 optimization options, it returns 01. With O2 and O3, it correctly
returns 0. I conducted tests to confirm the possibility of this bug occurring
in cross-compilers for the same version but different architectures, but it
consistently output the correct value of 0.
### Coclusion
The commonality in the two bug code examples above appears to be the treatment
of -1 as unsigned rather than signed. My suspicion is that there might be an
issue with the integer arithmetic types or instructions on the s390x
architecture.
[Bug c/112111] New: Improper Arithmetic Type Conversion in s390x-linux-gnu-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112111
Bug ID: 112111
Summary: Improper Arithmetic Type Conversion in
s390x-linux-gnu-gcc
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: 22s302h0659 at sonline20 dot sen.go.kr
Target Milestone: ---
### Environment
- Compiler: s390x-linux-gnu-gcc (64bit)
- Version: gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)
- Platform: Windows 11_5.15.90.1-microsoft-standard-WSL2
- Build Optimization Options: O0, O1, O2, O3
I installed the s390x-linux-gnu toolchain using the 'apt' package manager in
Ubuntu and utilized s390x-linux-gnu-gcc (version 11.4.0) from it.
### Summary
Using the legacy C code generator 'csmith' to generate test cases, I am
performing fuzzing on the GCC compiler for various architectures and
optimization options. I have discovered a bug specific to the s390x
architecture, and I will be reporting it.
### Source Code
I have prepared an 'binarys.zip' archive containing two versions of the bug PoC
code, along with '[c.sh](http://c.sh/)' for compiling them and
'[r.sh](http://r.sh/)' for running them
```bash
1 // bug_Poc1.c
2 #include
3 char v1 = -1;
4 short v2 = 1;
5 int main()
6 {
7 printf("bug = %d\n", v1 <= v2);
8 return 0;
9 }
```
```bash
// result
bug_O0 = 0
bug_O1 = 0
bug_O2 = 1
bug_O3 = 1
```
Line 7 yields a correct result of 1 for the normal comparison operation.
However, with the O0 and O1 optimization options, it returns 0. With O2 and O3,
it correctly returns 1. I conducted tests to confirm the possibility of this
bug occurring in cross-compilers for the same version but different
architectures, but it consistently output the correct value of 1.
```bash
1 // bug_Poc2.c
2 #include
3 char v1 = -1;
4 short v2 = 1;
5 int main()
6 {
7 printf("bug = %d\n", v1 >= v2);
8 return 0;
9 }
```
```bash
// result
bug_O0 = 1
bug_O1 = 1
bug_O2 = 0
bug_O3 = 0
```
On the 7th line, the normal comparison operation results in 0. However, with
the O0 and O1 optimization options, it returns 01. With O2 and O3, it correctly
returns 0. I conducted tests to confirm the possibility of this bug occurring
in cross-compilers for the same version but different architectures, but it
consistently output the correct value of 0.
### Coclusion
The commonality in the two bug code examples above appears to be the treatment
of -1 as unsigned rather than signed. My suspicion is that there might be an
issue with the integer arithmetic types or instructions on the s390x
architecture.
[Bug c++/111703] [12/13/14 Regression] [C++20]Compiler fails when using generic lambda in specific situation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111703
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #3 from Patrick Palka ---
FWIW a workaround is to ensure an equivalent 'f(x)' call is first checked in a
non-template context, e.g.
#include
using P = std::pair;
void (*f)(P);
static_assert(requires(P x) { f(x); }); // work around PR111703
int main(){
[](auto) {
P x;
f(x);
};
}
[Bug c/80454] -Wmissing-braces wrongly warns about universal zero initializer {0}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80454 Barnabás Pőcze changed: What|Removed |Added CC||pobrn at protonmail dot com --- Comment #7 from Barnabás Pőcze --- Created attachment 56319 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56319=edit proposed patch I would like to see this fixed, so I have tried something, see the attached patch. It's a bit of a hack at the moment, and I am not sure it fixes everything (it improves the status quo in any case), any thoughts?
[Bug rtl-optimization/112107] [14 Regression] bootstrap failure on i686-linux: gcc/ira-build.o differs since r14-4944-gf55cdce3f8dd85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112107 Sergei Trofimovich changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Sergei Trofimovich --- The change fixed bootstrap for me. Thank you! Let's declare it fixed.
[Bug fortran/104555] ICE in gfc_compare_derived_types, at fortran/interface.cc:628 since r10-2912-g70570ec192745095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104555 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- In this case the associate-name is essential in the SELECT TYPE, as well as the surrounding SELECT RANK, and a CHARACTER component in the derived type. Replacing character(:), allocatable :: a by character(10) :: a changes the ICE to a bogus error message with a corrupted variable name. valgrind gives invalid reads...
[Bug rtl-optimization/112107] [14 Regression] bootstrap failure on i686-linux: gcc/ira-build.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112107 --- Comment #10 from CVS Commits --- The trunk branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:4d3d2cdb574488223d023b590c3a34ddd93f4dae commit r14-4986-g4d3d2cdb574488223d023b590c3a34ddd93f4dae Author: Vladimir N. Makarov Date: Fri Oct 27 14:50:40 2023 -0400 [RA]: Fixing i686 bootstrap failure because of pushing the equivalence patch GCC with my recent patch improving cost calculation for pseudos with equivalence may generate different code with and without debug info and as the result i686 bootstrap fails on i686. The patch fixes this bug. gcc/ChangeLog: PR rtl-optimization/112107 * ira-costs.cc: (calculate_equiv_gains): Use NONDEBUG_INSN_P instead of INSN_P.
[Bug rtl-optimization/112107] [14 Regression] bootstrap failure on i686-linux: gcc/ira-build.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112107 --- Comment #9 from Vladimir Makarov --- (In reply to Sergei Trofimovich from comment #8) > bootstrap with default options did not fail for me either. I had to use > --enable-checking=release to trigger the failure. I wonder if it exposes the > failure for you as well. Yes, with --enable-checking=release I managed to reproduce a failure on clean bootstrap. BTW, thank you for the reproducer. It was easier to start from it.
[Bug fortran/104649] ICE in gfc_match_formal_arglist, at fortran/decl.cc:6733 since r6-1958-g4668d6f9c00d4767
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104649 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |14.0 --- Comment #8 from anlauf at gcc dot gnu.org --- Fixed in gcc-14. Closing. Thanks for the report!
[Bug rtl-optimization/112107] [14 Regression] bootstrap failure on i686-linux: gcc/ira-build.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112107 --- Comment #8 from Sergei Trofimovich --- bootstrap with default options did not fail for me either. I had to use --enable-checking=release to trigger the failure. I wonder if it exposes the failure for you as well.
[Bug rtl-optimization/112107] [14 Regression] bootstrap failure on i686-linux: gcc/ira-build.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112107 --- Comment #7 from Vladimir Makarov --- Sorry for inconvenience because of my patch. I reproduced the bug with the reproducer using stage1 gcc although strangely the standard bootstrap works ok for me on i686 debian. I think I know the reason for this bug. I'll fix it today.
[Bug fortran/104649] ICE in gfc_match_formal_arglist, at fortran/decl.cc:6733 since r6-1958-g4668d6f9c00d4767
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104649 --- Comment #7 from Steve Kargl --- On Fri, Oct 27, 2023 at 05:18:02PM +, cvs-commit at gcc dot gnu.org wrote: > > > commit r14-4983-gc6430d3e6d3279c7e4be9d189031a17bb3dec347 > Author: Harald Anlauf > Date: Thu Oct 26 22:32:35 2023 +0200 > Thanks for taking care of this issue. Sorry about missing the second case, and good catch.
[Bug analyzer/109131] -Wanalyzer-deref-before-check false positive seen in git's builtin/show-ref.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109131
Alexey changed:
What|Removed |Added
CC||alexey.lapshin at espressif
dot co
||m
--- Comment #1 from Alexey ---
There is a smaller reproducer:
```
struct a {
int b;
};
void foo(struct a *p) {
if (p->b)
p = 0;
if (p && p->b) // "p" can be 0 but warning
;
}
```
[Bug modula2/112110] fails to build on freebsd when compiling wrapclock.cc in wrapclock_timezone attempting to return timezone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112110 Gaius Mulley changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Gaius Mulley --- Closing now that the patch has been applied.
[Bug modula2/112110] fails to build on freebsd when compiling wrapclock.cc in wrapclock_timezone attempting to return timezone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112110 Gaius Mulley changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-10-27 --- Comment #2 from Gaius Mulley --- Confirmed on freebsd 13.2.
[Bug modula2/112110] fails to build on freebsd when compiling wrapclock.cc in wrapclock_timezone attempting to return timezone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112110 --- Comment #1 from CVS Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:32cc0b82a3c2e38caa9f2266d4ba375ccb1fe9cc commit r14-4984-g32cc0b82a3c2e38caa9f2266d4ba375ccb1fe9cc Author: Gaius Mulley Date: Fri Oct 27 18:42:09 2023 +0100 PR modula2/112110: fails to build on freebsd when compiling wrapclock.cc This patch fixes a mangled #if #endif conditional section within wrapclock.cc. The conditional section in wrapclock_timezone should return 0 rather than return timezone. libgm2/ChangeLog: PR modula2/112110 * libm2iso/wrapclock.cc (timezone): Return 0 if unable to get the timezone from the tm struct. Signed-off-by: Gaius Mulley
[Bug fortran/104649] ICE in gfc_match_formal_arglist, at fortran/decl.cc:6733 since r6-1958-g4668d6f9c00d4767
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104649 --- Comment #6 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:c6430d3e6d3279c7e4be9d189031a17bb3dec347 commit r14-4983-gc6430d3e6d3279c7e4be9d189031a17bb3dec347 Author: Harald Anlauf Date: Thu Oct 26 22:32:35 2023 +0200 Fortran: diagnostics of MODULE PROCEDURE declaration conflicts [PR104649] gcc/fortran/ChangeLog: PR fortran/104649 * decl.cc (gfc_match_formal_arglist): Handle conflicting declarations of a MODULE PROCEDURE when one of the declarations is an alternate return. gcc/testsuite/ChangeLog: PR fortran/104649 * gfortran.dg/pr104649.f90: New test. Co-authored-by: Steven G. Kargl
[Bug target/112088] [14 Regression] GCN target testing broken by "amdgcn: add -march=gfx1030 EXPERIMENTAL"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112088 Andrew Stubbs changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Andrew Stubbs --- The patch should fix the bug.
[Bug target/112088] [14 Regression] GCN target testing broken by "amdgcn: add -march=gfx1030 EXPERIMENTAL"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112088 --- Comment #2 from CVS Commits --- The master branch has been updated by Andrew Stubbs : https://gcc.gnu.org/g:9f3c4c673d769bd3f1d504d85b743ba250e68d7b commit r14-4982-g9f3c4c673d769bd3f1d504d85b743ba250e68d7b Author: Andrew Stubbs Date: Fri Oct 27 17:53:10 2023 +0100 amdgcn: Fix bug in gfx1030 support patch The previous patch to add gfx1030 support introduced an issue with passing exit codes from kernels run under gcn-run (offload kernels were unaffected). gcc/ChangeLog: PR target/112088 * config/gcn/gcn.cc (gcn_expand_epilogue): Fix kernel epilogue register conflict.
[Bug c++/112099] GCC doesn't recognize matching friend operator!= to resolve ambiguity in operator==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112099 --- Comment #2 from Utkarsh Saxena --- Great. The core issue completely captures this issue. Then I will wait for a resolution there.
[Bug rtl-optimization/112107] [14 Regression] bootstrap failure on i686-linux: gcc/ira-build.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112107 --- Comment #6 from Sergei Trofimovich --- (In reply to Sergei Trofimovich from comment #5) > Bisected down to r14-4943-g8d2130a4e5ce36 "[RA]: Modfify cost calculation > for dealing with equivalences" Sorry, pasted wrong hash. That should be a r14-4944-gf55cdce3f8dd85 "[RA]: Modfify cost calculation for dealing with equivalences"
[Bug rtl-optimization/112107] [14 Regression] bootstrap failure on i686-linux: gcc/ira-build.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112107 Sergei Trofimovich changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org, ||vmakarov at redhat dot com --- Comment #5 from Sergei Trofimovich --- Bisected down to r14-4943-g8d2130a4e5ce36 "[RA]: Modfify cost calculation for dealing with equivalences"
[Bug modula2/112110] New: fails to build on freebsd when compiling wrapclock.cc in wrapclock_timezone attempting to return timezone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112110 Bug ID: 112110 Summary: fails to build on freebsd when compiling wrapclock.cc in wrapclock_timezone attempting to return timezone Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: gaius at gcc dot gnu.org Target Milestone: --- It looks like a mangled #if #endif has crept into wrapc_timezone.
[Bug tree-optimization/111950] [14 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.cc:250 since r14-4786-gd118738e71c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111950 --- Comment #4 from Tamar Christina --- > turning c_I_lsm.18_38 into a fully invariant reduction def which likely isn't supported - we had bugs here in the past with not relevant but live stmts. But if-conversion also performs the (now valid) hoisting, this is maybe why it was triggered by that rev. Ah yeah this is something different from what I just fixed. Indeed, this causes find_guard_arg to no longer find the tie to the original PHI. It's trying to match # c_I_lsm.18_60 = PHI and # c_I_lsm.18_79 = PHI after it adds the edge. Normally loop invariant values are left in the the guard block for this. In this case we've left # c_I_lsm.18_65 = PHI Normally instead of # c_I_lsm.18_60 = PHI we'd find c_I_lsm.18_65 here. The value is as you mentioned loop invariant. but since c_I_lsm.18_38 is no longer a PHI node the link was broken. I don't think we can really recover this in the vectorizer can we? Would the proper fix perhaps be to have ifconvert fully convert things? It seems to have missed that # c_I_lsm.18_60 = PHI is just c_I_lsm.18_60 = _58 ? 1 : a.3_23; that would prevent the PHI node confusion
[Bug c++/111929] [14 Regression] in decompose, at wide-int.h:1049 since r14-4793-gdad311874ac3b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111929 --- Comment #12 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:6ff8b93c7b0bf3913fb7754f9985e7e31c46d89c commit r14-4979-g6ff8b93c7b0bf3913fb7754f9985e7e31c46d89c Author: Patrick Palka Date: Fri Oct 27 11:31:02 2023 -0400 c++: another build_new_1 folding fix [PR111929] In build_new_1, we also need to avoid folding 'outer_nelts_check' when in a template context to prevent an ICE on the below testcase. This patch replaces the problematic fold_build2 call with build2 (we'll later fold it if appropriate during cp_fully_fold). In passing, this patch removes an unnecessary conversion of 'nelts' since it should always already be a size_t (and 'convert' isn't the best conversion entry point to use anyway since it lacks a complain parameter). PR c++/111929 gcc/cp/ChangeLog: * init.cc (build_new_1): Remove unnecessary call to convert on 'nelts'. Use build2 instead of fold_build2 for 'outer_nelts_checks'. gcc/testsuite/ChangeLog: * g++.dg/template/non-dependent28a.C: New test.
[Bug modula2/111530] Unable to build GM2 standard library on BSD due to a `getopt_long_only' GNU extension dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111530 Gaius Mulley changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Gaius Mulley --- Closing now that the patch has been applied and bootstrap succeeded on netbsd 9.3
[Bug modula2/111530] Unable to build GM2 standard library on BSD due to a `getopt_long_only' GNU extension dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111530 --- Comment #3 from CVS Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:e5f6a5ad7ceece5238fc3d63f7ea92574df4264d commit r14-4976-ge5f6a5ad7ceece5238fc3d63f7ea92574df4264d Author: Gaius Mulley Date: Fri Oct 27 15:54:48 2023 +0100 PR modula2/111530: Build failure on BSD due to getopt_long_only GNU extension dependency This patch uses the libiberty getopt long functions (wrapped up inside libgm2/libm2pim/cgetopt.cc) and only enables this implementation if libgm2/configure.ac detects no getopt_long and friends on the target. gcc/m2/ChangeLog: PR modula2/111530 * gm2-libs-ch/cgetopt.c (cgetopt_cgetopt_long): Re-format. (cgetopt_cgetopt_long_only): Re-format. (cgetopt_SetOption): Re-format and assign flag to NULL if name is also NULL. * gm2-libs/GetOpt.def (AddLongOption): Add index parameter and change flag to be a VAR parameter rather than a pointer. (GetOptLong): Re-format. (GetOpt): Correct comment. * gm2-libs/GetOpt.mod: Re-write to rely on cgetopt rather than implement long option creation in GetOpt. * gm2-libs/cgetopt.def (SetOption): has_arg type is INTEGER. libgm2/ChangeLog: PR modula2/111530 * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * config.h.in: Regenerate. * configure: Regenerate. * configure.ac (AC_CHECK_HEADERS): Include getopt.h. (GM2_CHECK_LIB): getopt_long check. (GM2_CHECK_LIB): getopt_long_only check. * libm2cor/Makefile.in: Regenerate. * libm2iso/Makefile.in: Regenerate. * libm2log/Makefile.in: Regenerate. * libm2min/Makefile.in: Regenerate. * libm2pim/Makefile.in: Regenerate. * libm2pim/cgetopt.cc: Re-write using conditional on configure and long function code from libiberty/getopt.c. gcc/testsuite/ChangeLog: PR modula2/111530 * gm2/pimlib/run/pass/testgetopt.mod: New test. Signed-off-by: Gaius Mulley
[Bug tree-optimization/111950] [14 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.cc:250 since r14-4786-gd118738e71c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111950 --- Comment #3 from Tamar Christina --- (In reply to Richard Biener from comment #2) > For the epilog LC-SSA we lack the correct SSA name for the skip edge: > > > [local count: 16140304]: > # prephitmp_78 = PHI > # c_I_lsm.18_79 = PHI > # iftmp.0_80 = PHI > FWIW I just fixed a similar bug in my early break rebasing branch. I can check if it fixes this one too.
[Bug target/112109] New: Missing riscv vectorized strcmp (and other) expanders
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112109 Bug ID: 112109 Summary: Missing riscv vectorized strcmp (and other) expanders Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: rdapp at gcc dot gnu.org CC: juzhe.zhong at rivai dot ai, kito at gcc dot gnu.org, law at gcc dot gnu.org Target Milestone: --- Target: riscv We miss several vector expanders for string routines like strlen, strcmp. This is a reminder PR for them.
[Bug tree-optimization/111950] [14 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.cc:250 since r14-4786-gd118738e71c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111950 Richard Biener changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org Keywords||ice-on-valid-code, ||wrong-code --- Comment #2 from Richard Biener --- For the epilog LC-SSA we lack the correct SSA name for the skip edge: [local count: 16140304]: # prephitmp_78 = PHI # c_I_lsm.18_79 = PHI # iftmp.0_80 = PHI see how c_I_lsm.18_60 is used for both args but the name is defined in the epilog only. Though it looks like the original reduction variable isn't computed at all for the loop which means the reduction vectorization is wrong. if-conversion turns [local count: 146730041]: # d.12_13 = PHI _1 = a.3_23 >> b.2_22; if (_1 != 0) goto ; [50.00%] else goto ; [50.00%] [local count: 146730041]: # iftmp.0_9 = PHI <1(13), iftmp.0_39(11)> # c_I_lsm.18_38 = PHI <1(13), a.3_23(11)> # prephitmp_43 = PHI <1(13), a.3_23(11)> _37 = d.12_13 + 1; if (_37 != 0) goto ; [89.00%] else goto ; [11.00%] into [local count: 146730041]: # d.12_13 = PHI <_37(15), d.12_5(26)> iftmp.0_9 = _32 ? 1 : iftmp.0_39; c_I_lsm.18_38 = _32 ? 1 : a.3_23; _37 = d.12_13 + 1; if (_37 != 0) goto ; [89.00%] else goto ; [11.00%] turning c_I_lsm.18_38 into a fully invariant reduction def which likely isn't supported - we had bugs here in the past with not relevant but live stmts. But if-conversion also performs the (now valid) hoisting, this is maybe why it was triggered by that rev.
[Bug target/112108] New: [aarch64] Some intrinsics are not correctly enabled when using 'target' attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112108 Bug ID: 112108 Summary: [aarch64] Some intrinsics are not correctly enabled when using 'target' attributes Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: andrew.carlotti at arm dot com Target Milestone: --- Intrinsics gated by the +memtag, +ls64 and +tme features are currently only available if the feature was enabled in the global target settings. Their availability needs to be adjusted for individual functions, taking into account any local changes to the enabled features (e.g. using 'target' attributes). I'll post patches to fix this shortly.
[Bug rtl-optimization/112107] [14 Regression] bootstrap failure on i686-linux: gcc/ira-build.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112107 Andrew Pinski changed: What|Removed |Added Keywords||ra Component|bootstrap |rtl-optimization --- Comment #4 from Andrew Pinski --- Looks like the first difference comes from reload (LRA) .
[Bug c++/98995] [11/12/13/14 Regression] Copy elision not applied to members declared with [[no_unique_address]] or a empty base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98995
Jan Kokemüller changed:
What|Removed |Added
CC||jan.kokemueller at gmail dot
com
--- Comment #13 from Jan Kokemüller ---
Sometimes, all of the padding bytes of a "[[no_unique_address]]" member are
known when designing a class. It would be great if there was a way to say:
"hey, it's OK to do guaranteed copy elision here". Example:
union U {
[[no_unique_address]] Val val;
[[no_unique_address]] Err err;
};
struct R {
[[no_unique_address]] U union;
[[no_unique_address]] bool has_val;
};
struct expected {
R r;
};
In this example, "union U" and "struct R" are only used in the "struct
expected", by design. So it should be safe to allow guaranteed copy elision
when initializing the members "val" and "err" of the union since we have full
control over the tail padding bytes (there can only be "has_val" in there,
nothing else).
Maybe there could be an attribute, something like
"[[gnu::allow_guaranteed_copy_elision]]" or
"[[gnu::defer_temporary_materialization]]", to mark those members where
guaranteed copy elision is safe? So you could have:
union U {
[[no_unique_address,gnu::defer_temporary_materialization]] Val val;
[[no_unique_address,gnu::defer_temporary_materialization]] Err err;
};
What do you think?
[Bug bootstrap/112107] [14 Regression] bootstrap failure on i686-linux: gcc/ira-build.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112107 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-10-27 Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- Confirmed. > ./xg++ -B. -c -g -O2 -fno-exceptions -fno-rtti t.ii -fcompare-debug -m32 xg++: error: t.ii: '-fcompare-debug' failure (length)
[Bug bootstrap/112107] [14 Regression] bootstrap failure on i686-linux: gcc/ira-build.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112107
--- Comment #2 from Sergei Trofimovich ---
Reduced ira-build.cc down to the following:
// $ cat pp.cc.cc
typedef struct ira_object *ira_object_t;
struct ira_object {
void *conflicts_array;
int min, max;
};
void *ira_allocate(int);
int ira_conflict_vector_profitable_p_nbytes;
void ira_conflict_vector_profitable_p(ira_object_t obj) {
int max(obj->max);
if (max < obj->min)
ira_conflict_vector_profitable_p_nbytes = max - obj->min;
}
void ira_allocate_object_conflicts(ira_object_t obj) {
ira_conflict_vector_profitable_p(obj);
int size((obj->max - obj->min) * sizeof 0);
obj->conflicts_array = ira_allocate(size);
}
Reproducer:
# cat trigger.bash
#!/usr/bin/env bash
f() {
stage3-gcc/xg++ -Bstage3-gcc -nostdinc++ -fno-PIE -g -O2 -fchecking=1
-DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -fno-PIE -c
pp.cc.cc -o pp.o -Wall "$@"
strip --strip-debug pp.o
sha1sum pp.o
}
[[ "$(f)" == "$(f -gtoggle)" ]] && echo EQUAL || echo DIFF
Running:
$ ./trigger.bash
DIFF
[Bug target/112088] [14 Regression] GCN target testing broken by "amdgcn: add -march=gfx1030 EXPERIMENTAL"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112088 Andrew Stubbs changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2023-10-27 Assignee|unassigned at gcc dot gnu.org |ams at gcc dot gnu.org --- Comment #1 from Andrew Stubbs --- I'm testing a fix for this.
[Bug bootstrap/112107] [14 Regression] bootstrap failure on i686-linux: gcc/ira-build.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112107 Richard Biener changed: What|Removed |Added Target||i686-unknown-linux-gnu Build||i686-unknown-linux-gnu Keywords||needs-bisection Target Milestone|--- |14.0 Host||i686-unknown-linux-gnu
[Bug tree-optimization/112104] loop of ^1 should just be reduced to ^(n&1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112104
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2023-10-27
Status|UNCONFIRMED |NEW
--- Comment #2 from Richard Biener ---
Confirmed. I think it should apply even to
int
foo(long n3, int j, int x) {
for(int i=0; i
[Bug target/112103] [14 regression] gcc.target/powerpc/rlwinm-0.c fails after r14-4941-gd1bb9569d70304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112103 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0
[Bug tree-optimization/111970] [14 regression] SLP for non-IFN gathers result in RISC-V test failure on gather since r14-4745-gbeab5b95c58145
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111970 --- Comment #5 from Li Pan --- Thank you, any thing I can help please feel free to let me know.
[Bug target/112088] [14 Regression] GCN target testing broken by "amdgcn: add -march=gfx1030 EXPERIMENTAL"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112088 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0
[Bug middle-end/112087] gimple front end: Simple testcase with array fails to round trip
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112087
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2023-10-27
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
"Round-tripping" in the sense of
gcc -fdump-tree-X-gimple=- t.c -S | gcc -x c -fgimple -
was never the intention.
Yes, parsing of CLOBBERs isn't implemented, nor is parsing of
"gimple_has_volatile_ops", but since that's redundant info recomputed
at update_stmt time we can just scrap it at dump time (but then it's
a bit odd to not see it with -gimple ..).
It would be nice to have bugreports more specific that "cannot round-trip A or
B".
Two bugs for this.
Parsing of ={v}
Parsing of {CLOBBER} (and variants)
parsing of ={v} is a bit difficult since it would need to be tentative
(there's always a reason why seemingly "easy" things are not yet done).
Finding a better syntax for dumping the flags on a stmt might help.
Workaround for both: use -fstack-reuse=none
[Bug bootstrap/112107] [14 Regression] bootstrap failure on i686-linux: gcc/ira-build.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112107 --- Comment #1 from Sergei Trofimovich --- `diffoscope` says there is a difference in generated code in one of the functions: $ strip --strip-debug stage2-gcc-ira-build.o stage3-gcc-ira-build.o $ diffoscope stage2-gcc-ira-build.o stage3-gcc-ira-build.o │ add$0x10,%esp │ mov$0x1,%edx │ mov%eax,0x4(%esi) │ movl $0x0,(%eax) │ movl $0x0,0x38(%esi) │ - jmp363b │ - lea0x0(%esi,%eiz,1),%esi │ - lea0x0(%esi),%esi │ + jmp363c │ + xchg %ax,%ax
[Bug middle-end/111976] Large constant zero-valued objects should go in .bss rather than .rodata
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111976 Richard Biener changed: What|Removed |Added Last reconfirmed||2023-10-27 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- Similar to -fzero-initialized-in-bss we could have -fzero-rodata-in-bss maybe, but note that can also have security implications. A special .robss section might be nice (it could also be "mergeable" with a flag, losing distinct addresses for distinct objects). With -fdata-sections this optimization could be performed by the linker as well.
[Bug c++/111974] internal error: Segmentation fault on Ubuntu 23.10 (x86-64) - compiling RefPerSys
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111974 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Known to fail||13.2.0 Known to work||14.0 Last reconfirmed||2023-10-27 Status|UNCONFIRMED |WAITING --- Comment #4 from Richard Biener --- Waiting for a testcase or confirmation the bug is also gone on the GCC 13 branch.
[Bug tree-optimization/111972] [14 regression] missed vectorzation for bool a = j != 1; j = (long int)a;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111972 Richard Biener changed: What|Removed |Added Priority|P3 |P1 --- Comment #10 from Richard Biener --- # j_19 = PHI <_14(8), j_22(5)> _9 = j_19 != 1; _14 = (long int) _9; so the vectorizer interesting thing is whether we can handle (equality) compares the same as other associative operations (apart from the involved cast). Now the above isn't canonical, j_19 ^ 1 was though.
[Bug bootstrap/112107] New: [14 Regression] bootstrap failure on i686-linux: gcc/ira-build.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112107 Bug ID: 112107 Summary: [14 Regression] bootstrap failure on i686-linux: gcc/ira-build.o differs Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: slyfox at gcc dot gnu.org Target Milestone: --- Noticed on this week's build on i686-unknown-linux-gnu build/host/target. How to reproduce against r14-4967-g8697d3a1dcf327: $ ../gcc/configure --disable-multilib --enable-languages=c,c++ --enable-languages=c,c++ --enable-checking=release $ make STAGE1_CFLAGS=-O2 ... Comparing stages 2 and 3 Bootstrap comparison failure! gcc/ira-build.o differs $ stage3-gcc/xgcc -Bstage3-gcc -v Reading specs from stage3-gcc/specs COLLECT_GCC=stage3-gcc/xgcc COLLECT_LTO_WRAPPER=stage3-gcc/lto-wrapper Target: i686-pc-linux-gnu Configured with: /home/slyfox/dev/git/gcc/configure --disable-multilib --enable-languages=c,c++ --enable-checking=release Thread model: posix Supported LTO compression algorithms: zlib gcc version 14.0.0 20231027 (experimental) (GCC)
[Bug rtl-optimization/111971] [12/13/14 regression] ICE: maximum number of generated reload insns per insn achieved (90) since r12-6803-g85419ac59724b7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111971 Richard Biener changed: What|Removed |Added Target||powerpc Version|unknown |14.0 Keywords||ra Target Milestone|--- |12.4
[Bug tree-optimization/111970] [14 regression] SLP for non-IFN gathers result in RISC-V test failure on gather since r14-4745-gbeab5b95c58145
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111970 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Priority|P3 |P1 Ever confirmed|0 |1 Last reconfirmed||2023-10-27 --- Comment #4 from Richard Biener --- I will have a look. The patch should have been a noop for IFN gather loads since those are processed differently via pattern recog.
[Bug tree-optimization/111967] [12/13/14 Regression] during GIMPLE pass: evrp ICE: in operator[], at vec.h:910 with -O2 -fno-tree-forwprop -fdump-tree-evrp-all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111967 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug preprocessor/111965] -fno-debug-cpp does not disable -fdebug-cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111965 --- Comment #5 from Richard Biener --- (In reply to Andrew Pinski from comment #4) > https://gcc.gnu.org/pipermail/gcc-patches/2011-October/325728.html > > I don't know if there should be a -fno-debug-cpp option. Maybe we should > just reject that ... Well, option compositing hygiene tells us to just allow it. Patch looks obvious btw.
[no subject]
ทุนหมุนเวียนธุรกิจระยะสั้นสำหรับ ผู้ประกอบกิจการ โรงงานฯ หจก. บริษัท ธุรกิจ SMEs ✔ไม่เช็คบูโร อนุมัติง่ายกว่าธนาคาร ✔สามารถปิดยอดใด้ตลอตเวลา ✔ลดต้น ดอกเบี้ยลดทันที ✔ไม่ต้องค้ำ ไม่เรียกเก็บก่อน หรือ มัดจำ ทั้งสิ้น ✔คุยง่าย อนุมัติไวเร็ว ✔ดอกเบี้ยเริ่มต้น 1.5% ✔วงเงินสูง 5 ล้านบาท ✔️หากคุณสนใจบริการของเรา โทรด่วนหาเรา ☎ 0825928519 คุณตาล ☎ 0632543219 คุณเต้ 퐿퐼풩퐸 id esc.credit (โปรดเก็บใว้พิจารณาด้วยครับ)
[Bug ipa/111958] [11/12/13/14 Regression] Line number debugging information indicates wrong file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111958
Richard Biener changed:
What|Removed |Added
Keywords||needs-reduction
Component|debug |ipa
Priority|P3 |P2
CC||hubicka at gcc dot gnu.org,
||marxin at gcc dot gnu.org
--- Comment #3 from Richard Biener ---
The issue goes away when using -fno-ipa-icf - we have
# 2 "/usr/include/sys/unistd.h" 2 3 4
# 9 "getgid.c" 2
# 14 "getgid.c"
gid_t _POSIX_types_Gid = 0;
gid_t
getgid (void)
{
return _POSIX_types_Gid;
}
gid_t
getegid (void)
{
return _POSIX_types_Gid;
}
which we first ICF and then inline back. So it looks like when "materializing"
the alias clone for getegid we get a wrong location (or the location for the
alias clone is broken / not initialized?)
Honza?
[Bug libstdc++/82366] std::regex constructor called from shared library throws std::bad_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82366 --- Comment #12 from Jonathan Wakely --- Is the engine a C++ application, or C, or something else?
[Bug target/112105] [14 Regression] vector by lane operation costing broken since g:21416caf221fae4351319ef8ca8d41c0234bdfa7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112105 --- Comment #2 from Richard Sandiford --- Seems to be due to aarch64_modes_tieable_p saying that SF can't be tied to V2x2SF, so that a subreg of that form is given a cost of 2 instructions. Using: if (aarch64_vector_data_mode_p (mode1) || aarch64_vector_data_mode_p (mode2)) return true; makes the test work, but who knows what the knock-on effects will be…
[Bug c/112101] feature request: typeof_arg for extracting the type of a function's (or function pointer's) arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112101
--- Comment #2 from Abdulmalek Almkainzi ---
Another correction, I'm sorry, its a bit hard to write hypothetical code.
the macro print_func:
#define print_func(f) \
printf( \
_Generic( (__typeof_arg(f, 0)){0}, \
int: #f "(int)", \
long:#f "(long)", \
float: #f "(float)", \
char*: #f "(char*)", \
default: #f "(other)") \
)
[Bug target/112105] [14 Regression] vector by lane operation costing broken since g:21416caf221fae4351319ef8ca8d41c0234bdfa7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112105 Richard Sandiford changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Last reconfirmed||2023-10-27 Ever confirmed|0 |1 --- Comment #1 from Richard Sandiford --- Gah. Thanks for the report, will have a look.
[Bug rtl-optimization/112106] New: ICE: verify_flow_info failed: verify_flow_info: REG_BR_PROB does not match cfg 268435462 268435460 with custom flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112106 Bug ID: 112106 Summary: ICE: verify_flow_info failed: verify_flow_info: REG_BR_PROB does not match cfg 268435462 268435460 with custom flags Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 56318 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56318=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O3 -fno-ivopts -mno-unroll-only-small-loops --param=max-jump-thread-duplication-stmts=50 -fno-tree-ch -fharden-control-flow-redundancy -fno-tree-vrp testcase.C testcase.C: In function 'void DrawSprite(int)': testcase.C:39:1: error: verify_flow_info: REG_BR_PROB does not match cfg 268435462 268435460 39 | } | ^ during RTL pass: loop2_unroll testcase.C:39:1: internal compiler error: verify_flow_info failed 0x125a54e verify_flow_info() /repo/gcc-trunk/gcc/cfghooks.cc:287 0x16835f7 execute_function_todo /repo/gcc-trunk/gcc/passes.cc:2100 0x1683b2e execute_todo /repo/gcc-trunk/gcc/passes.cc:2142 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-4964-20231027105550-g7eed861e8ca-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-4964-20231027105550-g7eed861e8ca-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20231027 (experimental) (GCC)
[Bug target/112105] [14 Regression] vector by lane operation costing broken since g:21416caf221fae4351319ef8ca8d41c0234bdfa7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112105 Tamar Christina changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |14.0
[Bug target/112105] New: [14 Regression] vector by lane operation costing broken since g:21416caf221fae4351319ef8ca8d41c0234bdfa7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112105
Bug ID: 112105
Summary: [14 Regression] vector by lane operation costing
broken since
g:21416caf221fae4351319ef8ca8d41c0234bdfa7
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
CC: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: aarch64-*
After this commit g:21416caf221fae4351319ef8ca8d41c0234bdfa7
commit 21416caf221fae4351319ef8ca8d41c0234bdfa7
Author: Richard Sandiford
Date: Tue Oct 24 11:01:52 2023 +0100
aarch64: Define TARGET_INSN_COST
This patch adds a bare-bones TARGET_INSN_COST. See the comment
in the patch for the rationale.
we now fail to form by lane instructions when they're not single use:
> cat test.c
#include
typedef struct {
float re;
float im;
} cmplx_f32_t;
void test2x2_f32(const cmplx_f32_t *p_src_a,
const cmplx_f32_t *p_src_b,
cmplx_f32_t *p_dst) {
const float32_t *a_ptr = (const float32_t *)p_src_a;
const float32_t *b_ptr = (const float32_t *)p_src_b;
float32_t *out_ptr = (float32_t *)p_dst;
float32x2x2_t a_col[2];
float32x2x2_t b[2];
float32x2x2_t result[2];
a_col[0] = vld2_f32(a_ptr);
b[0] = vld2_f32(b_ptr);
result[0].val[0] = vmul_lane_f32(a_col[0].val[0], b[0].val[0], 0);
result[0].val[1] = vmul_lane_f32(a_col[0].val[1], b[0].val[0], 0);
vst2_f32(out_ptr, result[0]);
out_ptr = out_ptr + 4;
}
---
> ./bin/gcc test.c -O1 -S -o -
...
test2x2_f32:
ld2 {v27.2s - v28.2s}, [x0]
ld2 {v30.2s - v31.2s}, [x1]
dup v31.2s, v30.s[0]
fmulv29.2s, v31.2s, v27.2s
fmulv30.2s, v31.2s, v28.2s
st2 {v29.2s - v30.2s}, [x2]
ret
which has an unneeded dup. Before this we generated:
test2x2_f32:
ld2 {v0.2s - v1.2s}, [x1]
ld2 {v4.2s - v5.2s}, [x0]
fmulv2.2s, v4.2s, v0.s[0]
fmulv3.2s, v5.2s, v0.s[0]
st2 {v2.2s - v3.2s}, [x2]
ret
[Bug libstdc++/111588] Provide opt-out of shared_ptr single-threaded optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111588 --- Comment #5 from Mathias Stearn --- Mea culpa. The difference between boost and std was due to the code to fast-path shared_ptrs that aren't actually shared: https://github.com/gcc-mirror/gcc/blob/be34a8b538c0f04b11a428bd1a9340eb19dec13f/libstdc%2B%2B-v3/include/bits/shared_ptr_base.h#L324-L362. I still think that optimization is a good idea, even if it looks bad in this specific microbenchmark. When that is disabled, they have the same perf, even with the check for single-threaded. That said, I'd still love an opt out. For now, I'll just propose that we add a do-nothing bg thread in our benchmark main() to avoid misleading results.
[Bug libstdc++/111588] Provide opt-out of shared_ptr single-threaded optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111588 --- Comment #4 from Mathias Stearn --- So even though I already knew in the back of my mind about how this can affect benchmark results, I *still* got burned by it! I was benchmarking a simple hazard pointer implementation against shared ptrs by having them crab-walk a list of 1000 pointers. This was an admittedly simple and unrealistic benchmark that only ever accessed the objects from a single thread and never had any contention. It was a few hours after getting the initial results that I remembered this issue and went back to add a bg thread. > This needs numbers, not opinions While my biggest concern was misleading benchmarks (which I now feel a bit validated by my own mistake :), here are the numbers I see. I added boost::shared_ptr on the assumption (unvalidated) that the primary difference would be that it unconditionally uses atomics. --- Benchmark Time CPU Iterations --- BM_scanLinks_HazPtr6420 ns 6420 ns 108948 BM_scanLinks_BoostSharedPtr 11223 ns11223 ns62380 BM_scanLinks_StdSharedPtr 3217 ns 3217 ns 217621 BM_scanLinks_AtomicSharedPtr 28920 ns28920 ns24200 And with a bg thread doing nothing but sleeping: --- Benchmark Time CPU Iterations --- BM_scanLinks_HazPtr6887 ns 6887 ns 101445 BM_scanLinks_BoostSharedPtr 11224 ns11224 ns62373 BM_scanLinks_StdSharedPtr 14221 ns14221 ns49221 BM_scanLinks_AtomicSharedPtr 49574 ns49573 ns14126
[Bug debug/109411] missing debug information with statement frontiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109411 --- Comment #2 from Alexandre Oliva --- AFAICT there are mentions to test.h line numbers both with and without -gstatement-frontiers, and the mentions are the same. The problem is two-fold: - there aren't any stmt markers for the lines in the template instantiation from test.h. absent stmt markers, is_stmt remains at zero throughout the function, except for its entry on line 6 - GDB appears to disregard !is_stmt locs entirely when setting breakpoints I suppose getting markers for the instantiation would fix the problem, but I don't have any insight into why they're not generated.
[Bug fortran/104625] ICE in fixup_array_ref, at fortran/resolve.cc:9275 since r10-2912-g70570ec192745095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104625 Paul Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from Paul Thomas --- Fixed on mainline. If there is any demand, I can back port it after a few weeks. However, I will close it now. Thanks once again, Gerhard! Paul
[Bug target/110551] [11/12/13/14 Regression] an extra mov when doing 128bit multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110551 --- Comment #5 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:89e5d902fc55ad375f149f25a84c516ad360a606 commit r14-4968-g89e5d902fc55ad375f149f25a84c516ad360a606 Author: Roger Sayle Date: Fri Oct 27 10:03:53 2023 +0100 PR target/110551: Fix reg allocation for widening multiplications on x86. This patch contains clean-ups of the widening multiplication patterns in i386.md, and provides variants of the existing highpart multiplication peephole2 transformations (that tidy up register allocation after reload), and thereby fixes PR target/110551, which is a superfluous move instruction. For the new test case, compiled on x86_64 with -O2. Before: mulx64: movabsq $-7046029254386353131, %rcx movq%rcx, %rax mulq%rdi xorq%rdx, %rax ret After: mulx64: movabsq $-7046029254386353131, %rax mulq%rdi xorq%rdx, %rax ret The clean-ups are (i) that operand 1 is consistently made register_operand and operand 2 becomes nonimmediate_operand, so that predicates match the constraints, (ii) the representation of the BMI2 mulx instruction is updated to use the new umul_highpart RTX, and (iii) because operands 0 and 1 have different modes in widening multiplications, "a" is a more appropriate constraint than "0" (which avoids spills/reloads containing SUBREGs). The new peephole2 transformations are based upon those at around line 9951 of i386.md, that begins with the comment ;; Highpart multiplication peephole2s to tweak register allocation. ;; mov imm,%rdx; mov %rdi,%rax; imulq %rdx -> mov imm,%rax; imulq %rdi 2023-10-27 Roger Sayle gcc/ChangeLog PR target/110551 * config/i386/i386.md (mul3): Make operands 1 and 2 take "regiser_operand" and "nonimmediate_operand" respectively. (mulqihi3): Likewise. (*bmi2_umul3_1): Operand 2 needs to be register_operand matching the %d constraint. Use umul_highpart RTX to represent the highpart multiplication. (*umul3_1): Operand 2 should use regiser_operand predicate, and "a" rather than "0" as operands 0 and 2 have different modes. (define_split): For mul to mulx conversion, use the new umul_highpart RTX representation. (*mul3_1): Operand 1 should be register_operand and the constraint %a as operands 0 and 1 have different modes. (*mulqihi3_1): Operand 1 should be register_operand matching the constraint %0. (define_peephole2): Providing widening multiplication variants of the peephole2s that tweak highpart multiplication register allocation. gcc/testsuite/ChangeLog PR target/110551 * gcc.target/i386/pr110551.c: New test case.
[Bug preprocessor/87299] #pragma GCC target behaves differently when using -save-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87299 Lewis Hyatt changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Lewis Hyatt --- Fixed for GCC 14.
[Bug preprocessor/87299] #pragma GCC target behaves differently when using -save-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87299 --- Comment #5 from CVS Commits --- The master branch has been updated by Lewis Hyatt : https://gcc.gnu.org/g:8697d3a1dcf32750a3b9dc007586eb5f9ba5f17a commit r14-4967-g8697d3a1dcf32750a3b9dc007586eb5f9ba5f17a Author: Lewis Hyatt Date: Fri Oct 27 04:32:50 2023 -0400 preprocessor: c++: Support `#pragma GCC target' macros [PR87299] `#pragma GCC target' is not currently handled in preprocess-only mode (e.g., when running gcc -E or gcc -save-temps). As noted in the PR, this means that if the target pragma defines any macros, those macros are not effective in preprocess-only mode. Similarly, such macros are not effective when compiling with C++ (even when compiling without -save-temps), because C++ does not process the pragma until after all tokens have been obtained from libcpp, at which point it is too late for macro expansion to take place. Since r13-1544 and r14-2893, there is a general mechanism to handle pragmas under these conditions as well, so resolve the PR by using the new "early pragma" support. toplev.cc required some changes because the target-specific handlers for `#pragma GCC target' may call target_reinit(), and toplev.cc was not expecting that function to be called in preprocess-only mode. I added some additional testcases from the PR for x86. The other targets that support `#pragma GCC target' (aarch64, arm, nios2, powerpc, s390) already had tests verifying that the pragma sets macros as expected; here I have added -save-temps versions of some of them, to test that they now work in preprocess-only mode as well. gcc/c-family/ChangeLog: PR preprocessor/87299 * c-pragma.cc (init_pragma): Register `#pragma GCC target' and related pragmas in preprocess-only mode, and enable early handling. (c_reset_target_pragmas): New function refactoring code from... (handle_pragma_reset_options): ...here. * c-pragma.h (c_reset_target_pragmas): Declare. gcc/cp/ChangeLog: PR preprocessor/87299 * parser.cc (cp_lexer_new_main): Call c_reset_target_pragmas () after preprocessing is complete, before starting compilation. gcc/ChangeLog: PR preprocessor/87299 * toplev.cc (no_backend): New static global. (finalize): Remove argument no_backend, which is now a static global. (process_options): Likewise. (do_compile): Likewise. (target_reinit): Don't do anything in preprocess-only mode. (toplev::main): Adapt to no_backend change. (toplev::finalize): Likewise. gcc/testsuite/ChangeLog: PR preprocessor/87299 * c-c++-common/pragma-target-1.c: New test. * c-c++-common/pragma-target-2.c: New test. * g++.target/i386/pr87299-1.C: New test. * g++.target/i386/pr87299-2.C: New test. * gcc.target/i386/pr87299-1.c: New test. * gcc.target/i386/pr87299-2.c: New test. * gcc.target/s390/target-attribute/tattr-2b.c: New test. * gcc.target/aarch64/pragma_cpp_predefs_1b.c: New test. * gcc.target/arm/pragma_arch_attribute_1b.c: New test. * gcc.target/nios2/custom-fp-2b.c: New test. * gcc.target/powerpc/float128-3b.c: New test.
[Bug fortran/104625] ICE in fixup_array_ref, at fortran/resolve.cc:9275 since r10-2912-g70570ec192745095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104625 --- Comment #9 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:b038e202210eb3e982c2ec802438edd523b47a02 commit r14-4966-gb038e202210eb3e982c2ec802438edd523b47a02 Author: Paul Thomas Date: Fri Oct 27 09:33:38 2023 +0100 Fortran: Fix some problems with SELECT TYPE selectors [PR104625]. 2023-10-27 Paul Thomas gcc/fortran PR fortran/104625 * expr.cc (gfc_check_vardef_context): Check that the target does have a vector index before emitting the specific error. * match.cc (copy_ts_from_selector_to_associate): Ensure that class valued operator expressions set the selector rank and use the rank to provide the associate variable with an appropriate array spec. * resolve.cc (resolve_operator): Reduce stacked parentheses to a single pair. (fixup_array_ref): Extract selector symbol from parentheses. gcc/testsuite/ PR fortran/104625 * gfortran.dg/pr104625.f90: New test. * gfortran.dg/associate_55.f90: Change error check.
[Bug libstdc++/82366] std::regex constructor called from shared library throws std::bad_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82366 --- Comment #11 from Alibek Omarov --- I reproduced it with the game engine loading game mod, on Ubuntu Linux system. Both the engine and the mod are open source, but I'm trying to craft a smaller example.
[Bug tree-optimization/94884] Failure to recognize that result of or is always superior to operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94884 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |14.0 --- Comment #8 from Andrew Pinski --- Fixed.
[Bug tree-optimization/94884] Failure to recognize that result of or is always superior to operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94884 Bug 94884 depends on bug 101590, which changed state. Bug 101590 Summary: (len & - N) <= len is not optimized to 1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101590 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/19987] [meta-bug] fold missing optimizations in general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987 Bug 19987 depends on bug 94884, which changed state. Bug 94884 Summary: Failure to recognize that result of or is always superior to operands https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94884 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/101590] (len & - N) <= len is not optimized to 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101590 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |14.0 Status|ASSIGNED|RESOLVED --- Comment #11 from Andrew Pinski --- Fixed.
[Bug tree-optimization/94884] Failure to recognize that result of or is always superior to operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94884 --- Comment #7 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:a5e69e94591ae282857d59e868ff6cea7306c802 commit r14-4965-ga5e69e94591ae282857d59e868ff6cea7306c802 Author: Andrew Pinski Date: Tue Sep 12 18:24:22 2023 -0700 MATCH: Simplify `(X &| B) CMP X` if possible [PR 101590] I noticed we were missing these simplifications so let's add them. This adds the following simplifications: U & N <= U -> true U & N > U -> false When U is known to be as non-negative. When N is also known to be non-negative, this is also true: U | N < U -> false U | N >= U -> true When N is a negative integer, the result flips and we get: U | N < U -> true U | N >= U -> false We could extend this later on to be the case where we know N is nonconstant but is known to be negative. Bootstrapped and tested on x86_64-linux-gnu with no regressions. PR tree-optimization/101590 PR tree-optimization/94884 gcc/ChangeLog: * match.pd (`(X BIT_OP Y) CMP X`): New pattern. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/bitcmp-1.c: New test. * gcc.dg/tree-ssa/bitcmp-2.c: New test. * gcc.dg/tree-ssa/bitcmp-3.c: New test. * gcc.dg/tree-ssa/bitcmp-4.c: New test. * gcc.dg/tree-ssa/bitcmp-5.c: New test. * gcc.dg/tree-ssa/bitcmp-6.c: New test.
[Bug tree-optimization/101590] (len & - N) <= len is not optimized to 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101590 --- Comment #10 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:a5e69e94591ae282857d59e868ff6cea7306c802 commit r14-4965-ga5e69e94591ae282857d59e868ff6cea7306c802 Author: Andrew Pinski Date: Tue Sep 12 18:24:22 2023 -0700 MATCH: Simplify `(X &| B) CMP X` if possible [PR 101590] I noticed we were missing these simplifications so let's add them. This adds the following simplifications: U & N <= U -> true U & N > U -> false When U is known to be as non-negative. When N is also known to be non-negative, this is also true: U | N < U -> false U | N >= U -> true When N is a negative integer, the result flips and we get: U | N < U -> true U | N >= U -> false We could extend this later on to be the case where we know N is nonconstant but is known to be negative. Bootstrapped and tested on x86_64-linux-gnu with no regressions. PR tree-optimization/101590 PR tree-optimization/94884 gcc/ChangeLog: * match.pd (`(X BIT_OP Y) CMP X`): New pattern. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/bitcmp-1.c: New test. * gcc.dg/tree-ssa/bitcmp-2.c: New test. * gcc.dg/tree-ssa/bitcmp-3.c: New test. * gcc.dg/tree-ssa/bitcmp-4.c: New test. * gcc.dg/tree-ssa/bitcmp-5.c: New test. * gcc.dg/tree-ssa/bitcmp-6.c: New test.
[Bug ipa/111960] [14 Regression] ICE: during GIMPLE pass: rebuild_frequencies: SIGSEGV (Invalid read of size 4) with -fdump-tree-rebuild_frequencies-all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111960
Andrew Pinski changed:
What|Removed |Added
Component|tree-optimization |ipa
CC||hubicka at gcc dot gnu.org,
||marxin at gcc dot gnu.org
--- Comment #2 from Andrew Pinski ---
Reduced (C) testcase:
```
int _token;
static inline
void CommaExpr (void)
{
for (; _token; CommaExpr ())
;
}
void Compile (void)
{
CommaExpr ();
}
```
`-O --param=max-inline-recursive-depth=100
-fdump-tree-rebuild_frequencies-all`
[Bug tree-optimization/111960] [14 Regression] ICE: during GIMPLE pass: rebuild_frequencies: SIGSEGV (Invalid read of size 4) with -fdump-tree-rebuild_frequencies-all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111960 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Summary|ICE: during GIMPLE pass:|[14 Regression] ICE: during |rebuild_frequencies:|GIMPLE pass: |SIGSEGV (Invalid read of|rebuild_frequencies: |size 4) with|SIGSEGV (Invalid read of |-fdump-tree-rebuild_frequen |size 4) with |cies-all|-fdump-tree-rebuild_frequen ||cies-all Target Milestone|--- |14.0 Status|UNCONFIRMED |NEW Last reconfirmed||2023-10-27 --- Comment #1 from Andrew Pinski --- Confirmed. I could not reproduce it earlier.
[Bug libstdc++/82366] std::regex constructor called from shared library throws std::bad_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82366 --- Comment #10 from Jonathan Wakely --- My best guess for what's happening in the original report is that the shared library is being loaded into a running process which uses an older version of libstdc++, and so the locale facets needed by the shared library were never created at startup. When std::regex tried to use those facets, it fails to find it. But without a way to reproduce the problem, this will never get resolved.
[Bug libstdc++/82366] std::regex constructor called from shared library throws std::bad_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82366 --- Comment #9 from Jonathan Wakely --- If this only happens when the shared library is loaded from a closed source application, you really need to talk to Oracle.
[Bug libstdc++/82366] std::regex constructor called from shared library throws std::bad_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82366 --- Comment #8 from Jonathan Wakely --- We still don't have a complete description of the problem though.
[Bug tree-optimization/111972] [14 regression] missed vectorzation for bool a = j != 1; j = (long int)a;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111972
--- Comment #9 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #8)
> These should work:
>
> (simplify
> (convert (eq one_zero_valued_p@1 one_zero_valued_p@2))
> (if (types_match (type, TREE_TYPE (@1)))
> (bit_xor @1 (bit_xor! @2 { build_one_cst (type); }
>
> (simplify
> (convert (ne one_zero_valued_p@1 one_zero_valued_p@2))
> (if (types_match (type, TREE_TYPE (@1)))
> (bit_xor @1 @2})))
>
>
> Will test tomorrow.
Maybe we don't need the types_match either ...
But then we need a convert. That would fix PR 110637 too.
[Bug tree-optimization/111972] [14 regression] missed vectorzation for bool a = j != 1; j = (long int)a;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111972
--- Comment #8 from Andrew Pinski ---
These should work:
(simplify
(convert (eq one_zero_valued_p@1 one_zero_valued_p@2))
(if (types_match (type, TREE_TYPE (@1)))
(bit_xor @1 (bit_xor! @2 { build_one_cst (type); }
(simplify
(convert (ne one_zero_valued_p@1 one_zero_valued_p@2))
(if (types_match (type, TREE_TYPE (@1)))
(bit_xor @1 @2})))
Will test tomorrow.
