[Bug go/108426] [13 regression] SEGV in contains_struct_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108426 --- Comment #5 from Richard Biener --- Meh, similar to build_common_tree_nodes we should have a function to build those common builtin decls in the middle-end. They are C ABI after all and it's fine to use standard C named types there.
[Bug c/108423] [12/13 Regression] ICE in make_ssa_name_fn with VLA types in arguments and inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108423 Richard Biener changed: What|Removed |Added Component|middle-end |c Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Priority|P3 |P2 Last reconfirmed||2023-01-17 --- Comment #1 from Richard Biener --- #3 0x01697500 in remap_ssa_name (name=, id=0x7fffd910) at /home/rguenther/src/trunk/gcc/tree-inline.cc:237 237 new_tree = make_ssa_name (remap_type (TREE_TYPE (name), id)); (gdb) p debug_tree (name) nothrow def_stmt version:1 in-free-list> $1 = void so another case with a missing/misplaced DECL_EXPR for the VLA size.
[Bug other/108276] libiberty unlink_if_ordinary does not handle Windows nul device correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108276
--- Comment #6 from niXman ---
I think you don't understand me.
with your patch after preprocessing the `unlink_if_ordinary()` will look like:
```
int
unlink_if_ordinary (const char *name)
{
if (stricmp (name, "nul") == 0)
return 1;
return 1;
}
```
don't you think it's strange?
[Bug c++/108422] [13 Regression] ICE: base pointer cycle detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108422 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |13.0
[Bug fortran/108420] [13 Regression] ICE in check_charlen_present, at fortran/iresolve.cc:98
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108420 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |13.0
[Bug libstdc++/106183] std::atomic::wait might fail to be unblocked by notify_one/all on platforms without platform_wait()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106183 --- Comment #9 from niXman --- looks like it's fixed for x86_64-w64-mingw32. I used the test from the: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101037 I run it on bash loop for the night and it successfully executed for ~179k times.
[Bug target/108401] gcc defeats vector constant generation with intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108401 --- Comment #8 from Hongtao.liu --- > But, if you're going to improve constant generation, please make it so that > it can recognize not only the particular pattern described in this bug. More > importantly, it should recognize the all-ones case (as a single pcmpeq) as a > starting point. Then it can apply shifts to achieve the final result from > the all-ones vector - shifts of any width, length or direction, including > psrldq/pslldq. This would improve generated code in a wider range of cases. yes, we will try to do that. Generally fold intrinsic into compiler IR helps performance, and for this case we need to optimize codegen for special immediate broadcast(all-ones + shift)
[Bug rtl-optimization/106594] [13 Regression] sign-extensions no longer merged into addressing mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106594 --- Comment #10 from Roger Sayle --- Status update: The x86 backend pieces of my proposed fix have been approved and committed, but the remaining middle-end pieces have been making slow progress: https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609286.html
[Bug target/108396] [12/13 Regression] PPCLE: vec_vsubcuq missing since r12-5752-gd08236359eb229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108396 --- Comment #4 from Kewen Lin --- (In reply to Segher Boessenkool from comment #3) > (In reply to Kewen Lin from comment #2) > > Unfortunately we don't have the testing coverage in testsuite for the > > expected name vec_vsubcuq (in rs6000-vecdefines.h): > > Is it hard to add one for all (or many) of the legacy builtins? Do we want > to test more than just if it compiles? Good question, I think it's not hard to add several (classified as their stanzas) for them and testing the compilation is enough. I just filed one internal issue for tracking it in GCC14, it's to visit all bif names defined in header file and get or create one in test suite.
[Bug go/108426] [13 regression] SEGV in contains_struct_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108426 --- Comment #4 from Ian Lance Taylor --- Thanks Andrew, I'm testing the patch myself, but go ahead and commit if you are satisfied with it.
[Bug c++/108417] [ICE] Crash on aggregate initialization of base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108417 Andrew Pinski changed: What|Removed |Added Keywords|needs-bisection |ABI, ice-checking, ||ice-on-valid-code Known to work|12.2.1 | --- Comment #6 from Andrew Pinski --- (In reply to Richard Biener from comment #2) > Confirmed. Note that trunk ICEs differently now: > > 253 gcc_checking_assert (TARGET_EXPR_ELIDING_P (from)); That assert is turned off for release checking There is no different ICE on the trunk, just the same one. And again this is exactly same as those other issues except still ICE instead of rejects valid: This language/ABI issue is tracked at https://wg21.link/cwg2403 and https://github.com/itanium-cxx-abi/cxx-abi/issues/107
[Bug tree-optimization/108419] [13 Regression] Dead Code Elimination Regression at -O2 since r13-440-g98e475a8f58
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108419 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |13.0
[Bug other/108276] libiberty unlink_if_ordinary does not handle Windows nul device correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108276 --- Comment #5 from Himal --- (In reply to niXman from comment #4) > (In reply to niXman from comment #2) > > > I don't think the patch is correct because for WIN32 platform `unlink()` > > will never be called even for non-"nul" files. > > moreover, according to the man: > https://github.com/MicrosoftDocs/cpp-docs/blob/main/docs/c-runtime-library/ > reference/unlink-wunlink.md > > microsoft's `unlink()/_unlink()` works as just `remove()`. Hi, Thanks for the feedback. I noticed this while looking for [this](https://sourceware.org/bugzilla/show_bug.cgi?id=29947) bug. In MSYS/MinGW, It calls the `unlink` function even for 'nul', but it wasn't throwing any errors. I decided to submit this patch because it already has some code checking for special devices before calling `unlink`. If it's not required then I guess we can close this. Thanks.
[Bug modula2/108404] M2RTS_Halt fails with a segv (it should emit a diagnostic and exit).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108404 --- Comment #4 from Iain Sandoe --- Works for me - now the failing test cases produce a diagnostic; /src-local/gcc-master/libgm2/libm2iso/RTco.cc:373:in initThread has caused failed to set stack size attribute Although it does not seem to exit the failed program (is that because Halt eventually does a loop-forever?)
[Bug tree-optimization/108402] False positive Wuninitialized with ftrivial-auto-var-init=pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108402 --- Comment #6 from pefoley2 at pefoley dot com --- The attached file repos the issue for me. I avoided trying to compress it per https://gcc.gnu.org/bugs/ "An attached archive (tar, zip, shar, whatever) containing all (or some) of the above." being listed under "What we do not want". And yeah, the steps to repo from a kernel checkout were added mostly for completeness, I didn't expect people to need to use them.
[Bug testsuite/108427] bitfield tests fail with missing warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108427 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-01-16 Status|UNCONFIRMED |NEW --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > So this is basically just a testsuite failure and it might just need > pcc_bitfield_type_matters check in the dg-warning for the target and such. No pcc_bitfield_type_matters is the incorrect check. But there should be another one for ms_bitfields instead added.
[Bug testsuite/108427] bitfield tests fail with missing warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108427 --- Comment #2 from Andrew Pinski --- So this is basically just a testsuite failure and it might just need pcc_bitfield_type_matters check in the dg-warning for the target and such.
[Bug testsuite/108427] bitfield tests fail with missing warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108427 --- Comment #1 from Andrew Pinski --- -mms-bitfields is enabled by default. See TARGET_MS_BITFIELD_LAYOUT_P and https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/x86-Options.html#index-mms-bitfields The layout of bitfields are different here ...
[Bug target/105506] [12/13 Regression] Error building GCC 12.1.0 against MinGW-w64: fatal error: cannot execute 'cc1': CreateProcess: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506 --- Comment #11 from H.J. Lu --- Created attachment 54288 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54288=edit An updated patch Try this one.
[Bug testsuite/108427] New: bitfield tests fail with missing warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108427
Bug ID: 108427
Summary: bitfield tests fail with missing warnings
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
Both bitfield-3.m and bitfield-5.m appear to fail for the same reason on
x86_64-w64-mingw32 (cross compiled from linux, if it matters). The tests each
contain multiple tests for warnings, only one of which is missing in each case:
PASS: objc.dg/bitfield-3.m -fgnu-runtime (test for warnings, line 20)
FAIL: objc.dg/bitfield-3.m -fgnu-runtime (test for warnings, line 27)
PASS: objc.dg/bitfield-3.m -fgnu-runtime (test for warnings, line 32)
PASS: objc.dg/bitfield-3.m -fgnu-runtime (test for warnings, line 33)
PASS: objc.dg/bitfield-3.m -fgnu-runtime (test for excess errors)
PASS: objc.dg/bitfield-3.m -fgnu-runtime execution test
PASS: objc.dg/bitfield-5.m -fgnu-runtime (test for warnings, line 24)
PASS: objc.dg/bitfield-5.m -fgnu-runtime (test for warnings, line 33)
FAIL: objc.dg/bitfield-5.m -fgnu-runtime (test for warnings, line 40)
PASS: objc.dg/bitfield-5.m -fgnu-runtime (test for warnings, line 52)
PASS: objc.dg/bitfield-5.m -fgnu-runtime (test for warnings, line 57)
PASS: objc.dg/bitfield-5.m -fgnu-runtime (test for warnings, line 70)
PASS: objc.dg/bitfield-5.m -fgnu-runtime (test for warnings, line 74)
PASS: objc.dg/bitfield-5.m -fgnu-runtime (test for warnings, line 75)
PASS: objc.dg/bitfield-5.m -fgnu-runtime (test for warnings, line 76)
PASS: objc.dg/bitfield-5.m -fgnu-runtime (test for excess errors)
There are similar tests and failures for objc++, but maybe these are supposed
to be XFAIL'd due to PR23610:
PASS: obj-c++.dg/bitfield-4.mm -fgnu-runtime (test for warnings, line 21)
PASS: obj-c++.dg/bitfield-4.mm -fgnu-runtime (test for warnings, line 33)
PASS: obj-c++.dg/bitfield-4.mm -fgnu-runtime PR23610 at line 53 (test for bogus
messages, line )
PASS: obj-c++.dg/bitfield-4.mm -fgnu-runtime PR23610 at line 55 (test for bogus
messages, line 28)
FAIL: obj-c++.dg/bitfield-4.mm -fgnu-runtime PR23610 at line 56 (test for bogus
messages, line 34)
PASS: obj-c++.dg/bitfield-4.mm -fgnu-runtime (test for excess errors)
PASS: obj-c++.dg/bitfield-4.mm -fgnu-runtime execution test
PASS: obj-c++.dg/bitfield-1.mm -fgnu-runtime (test for warnings, line 26)
PASS: obj-c++.dg/bitfield-1.mm -fgnu-runtime (test for warnings, line 29)
PASS: obj-c++.dg/bitfield-1.mm -fgnu-runtime (test for warnings, line 76)
PASS: obj-c++.dg/bitfield-1.mm -fgnu-runtime PR23610 at line 118 (test for
bogus messages, line )
PASS: obj-c++.dg/bitfield-1.mm -fgnu-runtime PR23610 at line 119 (test for
bogus messages, line 42)
FAIL: obj-c++.dg/bitfield-1.mm -fgnu-runtime PR23610 at line 120 (test for
bogus messages, line 45)
FAIL: obj-c++.dg/bitfield-1.mm -fgnu-runtime PR23610 at line 121 (test for
bogus messages, line 59)
FAIL: obj-c++.dg/bitfield-1.mm -fgnu-runtime PR23610 at line 122 (test for
bogus messages, line 62)
FAIL: obj-c++.dg/bitfield-1.mm -fgnu-runtime PR23610 at line 123 (test for
bogus messages, line 77)
FAIL: obj-c++.dg/bitfield-1.mm -fgnu-runtime PR23610 at line 124 (test for
bogus messages, line 78)
PASS: obj-c++.dg/bitfield-1.mm -fgnu-runtime (test for excess errors)
bitfield-3.m:
@interface Derived: Base {
signed e: 5;
int f: 4;
enum Enum g: 3;
} /* { dg-warning "padding struct size to alignment boundary" } */
@end
bitfield-5.m:
@interface Derived: Base {
@public
signed e: 5;
unsigned f: 4;
enum Enum g: 3;
} /* { dg-warning "padding struct size to alignment boundary" } */
@end
[Bug libgcc/108279] Improved speed for float128 routines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279 --- Comment #17 from joseph at codesourcery dot com --- It's not part of the ABI for the Arm 32-bit Architecture (AAPCS32). https://github.com/ARM-software/abi-aa/blob/main/aapcs32/aapcs32.rst You can file an issue there if you want, though I don't know how interested the maintainers will be in that optional language feature.
gcc-snapshot: FTBFS on hurd-i386 (and other archs?)
Source: gcc-snapshot Version: 20230108-1 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd X-Debbugs-CC: debian-h...@lists.debian.org Hi, gcc-snapshot in sid FTBFS on hurd-i386 due to that some patches are not applied when building gcc-snapshot. After the statement in rules.patch ifeq ($(single_package),yes) debian_patches = endif previously defined patches are cleared, causing the build failure, see below. debian/ files causing the problem: debian/rules.defs: ifneq (,$(findstring gcc-snapshot, $(PKGSOURCE))) single_package = yes trunk_build = yes debian/rules.patch: ifeq ($(single_package),yes) debian_patches = endif Thanks!
[Bug target/105980] [11/12/13 Regression] ICE in final_scan_insn_1, at final.cc:2811
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105980 --- Comment #9 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:a396a123596d82d4a2f14dc43a382cb17826411c commit r13-5218-ga396a123596d82d4a2f14dc43a382cb17826411c Author: H.J. Lu Date: Mon Jan 16 10:45:41 2023 -0800 x86: Disable -mforce-indirect-call for PIC in 32-bit mode -mforce-indirect-call generates invalid instruction in 32-bit MI thunk since there are no available scratch registers in 32-bit PIC mode. Disable -mforce-indirect-call for PIC in 32-bit mode when generating MI thunk. gcc/ PR target/105980 * config/i386/i386.cc (x86_output_mi_thunk): Disable -mforce-indirect-call for PIC in 32-bit mode. gcc/testsuite/ PR target/105980 * g++.target/i386/pr105980.C: New test.
[Bug go/108426] [13 regression] SEGV in contains_struct_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108426
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> Confirmed.
> The following builtins are missing from the go front-end:
> BUILT_IN_CLZL
> BUILT_IN_CTZL
>
> The {,LL} versions are there but not the L version.
This should fix that:
diff --git a/gcc/go/go-gcc.cc b/gcc/go/go-gcc.cc
index a4a0e5d903e..eea361b4f70 100644
--- a/gcc/go/go-gcc.cc
+++ b/gcc/go/go-gcc.cc
@@ -627,6 +627,11 @@ Gcc_backend::Gcc_backend()
unsigned_type_node,
NULL_TREE),
builtin_const);
+ this->define_builtin(BUILT_IN_CTZL, "__builtin_ctzl", "ctzl",
+ build_function_type_list(integer_type_node,
+ long_unsigned_type_node,
+ NULL_TREE),
+ builtin_const);
this->define_builtin(BUILT_IN_CTZLL, "__builtin_ctzll", "ctzll",
build_function_type_list(integer_type_node,
long_long_unsigned_type_node,
@@ -637,6 +642,11 @@ Gcc_backend::Gcc_backend()
unsigned_type_node,
NULL_TREE),
builtin_const);
+ this->define_builtin(BUILT_IN_CLZL, "__builtin_clzl", "clzl",
+ build_function_type_list(integer_type_node,
+ long_unsigned_type_node,
+ NULL_TREE),
+ builtin_const);
this->define_builtin(BUILT_IN_CLZLL, "__builtin_clzll", "clzll",
build_function_type_list(integer_type_node,
long_long_unsigned_type_node,
[Bug go/108426] [13 regression] SEGV in contains_struct_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108426
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-01-16
Assignee|unassigned at gcc dot gnu.org |ian at airs dot com
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Component|tree-optimization |go
--- Comment #2 from Andrew Pinski ---
Confirmed.
The following builtins are missing from the go front-end:
BUILT_IN_CLZL
BUILT_IN_CTZL
The {,LL} versions are there but not the L version.
[Bug tree-optimization/108426] [13 regression] SEGV in contains_struct_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108426
--- Comment #1 from Andrew Pinski ---
Simple fix until we figure out if the go front-end should be initializing these
builtins are not:
diff --git a/gcc/tree-ssa-loop-niter.cc b/gcc/tree-ssa-loop-niter.cc
index 65b960461ae..0a0873bb572 100644
--- a/gcc/tree-ssa-loop-niter.cc
+++ b/gcc/tree-ssa-loop-niter.cc
@@ -2246,6 +2246,9 @@ build_cltz_expr (tree src, bool leading, bool
define_at_zero)
else
return NULL_TREE;
+ if (!use_ifn && !fn)
+return NULL_TREE;
+
tree call;
if (use_ifn)
{
[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608 --- Comment #35 from Florian Weimer --- I backported the fixes for building glibc to 2.34 last week, I really expect the testsuite to be clean there (on x86-64), and on later releases as well.
[Bug tree-optimization/108426] [13 regression] SEGV in contains_struct_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108426 Rainer Orth changed: What|Removed |Added Target Milestone|--- |13.0
[Bug tree-optimization/108426] New: [13 regression] SEGV in contains_struct_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108426 Bug ID: 108426 Summary: [13 regression] SEGV in contains_struct_check Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: andrew.carlotti at arm dot com Target Milestone: --- Host: sparc-sun-solaris2.11 Target: sparc-sun-solaris2.11 Build: sparc-sun-solaris2.11 Between 20230113 (9b6c624820050cd5e11b2fbd9c997f94b691295a) and 20230116 (b22634281fff352fcf71dd4fbbf6e6fcbc9a46cf), Solaris/SPARC bootstrap broke compiling 64-bit strconv.lo: during GIMPLE pass: evrp In function 'strconv.atofHex': go1: internal compiler error: Segmentation Fault libtool: compile: /var/gcc/regression/master/11.4-gcc/build/./gcc/gccgo -B/var/gcc/regression/master/11.4-gcc/build/./gcc/ -B/vol/gcc/sparc-sun-solaris2.11/bin/ -B/vol/gcc/sparc-sun-solaris2.11/lib/ -isystem /vol/gcc/sparc-sun-solaris2.11/include -isystem /vol/gcc/sparc-sun-solaris2.11/sys-include -fchecking=1 -O2 -g -m64 -I . -c -fgo-pkgpath=path /vol/gcc/src/hg/master/local/libgo/go/path/match.go /vol/gcc/src/hg/master/local/libgo/go/path/path.go -o path.o >/dev/null 2>&1 0xf25ceb crash_signal /vol/gcc/src/hg/master/local/gcc/toplev.cc:314 0x12c5328 contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*) /vol/gcc/src/hg/master/local/gcc/tree.h:3643 0x12c5328 build_call_expr_loc_array(unsigned int, tree_node*, int, tree_node**) /vol/gcc/src/hg/master/local/gcc/tree.cc:10686 0x12c5507 build_call_expr(tree_node*, int, ...) /vol/gcc/src/hg/master/local/gcc/tree.cc:10736 0x110738b build_cltz_expr /vol/gcc/src/hg/master/local/gcc/tree-ssa-loop-niter.cc:2300 0x1113e1f number_of_iterations_cltz_complement /vol/gcc/src/hg/master/local/gcc/tree-ssa-loop-niter.cc:2554 0x1113e1f number_of_iterations_bitcount /vol/gcc/src/hg/master/local/gcc/tree-ssa-loop-niter.cc:2640 0x1113e1f number_of_iterations_exit_assumptions(loop*, edge_def*, tree_niter_desc*, gcond**, bool, basic_block_def**) /vol/gcc/src/hg/master/local/gcc/tree-ssa-loop-niter.cc:3186 0x1115ed7 number_of_iterations_exit(loop*, edge_def*, tree_niter_desc*, bool, bool, basic_block_def**) /vol/gcc/src/hg/master/local/gcc/tree-ssa-loop-niter.cc:3275 0x1115ed7 estimate_numbers_of_iterations(loop*) /vol/gcc/src/hg/master/local/gcc/tree-ssa-loop-niter.cc:4845 0x1119683 loop_exits_before_overflow /vol/gcc/src/hg/master/local/gcc/tree-ssa-loop-niter.cc:5246 0x1119683 scev_probably_wraps_p(tree_node*, tree_node*, tree_node*, gimple*, loop*, bool) /vol/gcc/src/hg/master/local/gcc/tree-ssa-loop-niter.cc:5498 0x1365a67 bounds_of_var_in_loop(tree_node**, tree_node**, range_query*, loop*, gimple*, tree_node*) /vol/gcc/src/hg/master/local/gcc/vr-values.cc:524 0x19be32f fold_using_range::range_of_ssa_name_with_loop_info(vrange&, tree_node*, loop*, gphi*, fur_source&) /vol/gcc/src/hg/master/local/gcc/gimple-range-fold.cc:957 0x19bf1f3 fold_using_range::range_of_phi(vrange&, gphi*, fur_source&) /var/gcc/regression/master/11.4-gcc/build/i386-pc-solaris2.11/libstdc++-v3/include0x19bf1f3 fold_using_range::range_of_phi(vrange&, gphi*, fur_source&) /vol/gcc/src/hg/master/local/gcc/gimple-range-fold.cc:820 0x19c262f fold_using_range::fold_stmt(vrange&, gimple*, fur_source&, tree_node*) /vol/gcc/src/hg/master/local/gcc/gimple-range-fold.cc:491 0x19b0b6b gimple_ranger::fold_range_internal(vrange&, gimple*, tree_node*) /vol/gcc/src/hg/master/local/gcc/gimple-range.cc:257 0x19b0b6b gimple_ranger::range_of_stmt(vrange&, gimple*, tree_node*) /vol/gcc/src/hg/master/local/gcc/gimple-range.cc:318 0x19b0e13 gimple_ranger::register_inferred_ranges(gimple*) /vol/gcc/src/hg/master/local/gcc/gimple-range.cc:474 0x12ad20b rvrp_folder::pre_fold_bb(basic_block_def*) /vol/gcc/src/hg/master/local/gcc/tree-vrp.cc:1045 gdb shows Thread 2 received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] build_call_expr_loc_array (loc=0, fndecl=, n=1, argarray=0xffbf8e70) at /vol/gcc/src/hg/master/local/gcc/tree.cc:10686 10686 tree fntype = TREE_TYPE (fndecl); (gdb) bt #0 build_call_expr_loc_array (loc=0, fndecl=, n=1, argarray=0xffbf8e70) at /vol/gcc/src/hg/master/local/gcc/tree.cc:10686 #1 0x012c5508 in build_call_expr (fndecl=, n=1) at /vol/gcc/src/hg/master/local/gcc/tree.cc:10736 #2 0x0110738c in build_cltz_expr (src=, leading=, define_at_zero=) at /vol/gcc/src/hg/master/local/gcc/tree-ssa-loop-niter.cc:2300 #3 0x01113e20 in number_of_iterations_cltz_complement (exit=, niter=0xffbf9200, code=NE_EXPR, loop=0xfaa84ee0) at /vol/gcc/src/
[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608 --- Comment #34 from Romain Geissler --- >From what I wrote here https://sourceware.org/pipermail/libc-alpha/2022-November/143633.html apparently I already tried gcc 12 back in end of november 2022 and all float issues in glibc testsuite were gone. I didn't test gcc 12 since then.
[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608 --- Comment #33 from Jakub Jelinek --- Isn't that PR106805 ? More importantly, do those FAIL also with GCC 12 or just the trunk?
[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608 --- Comment #32 from Romain Geissler --- Hi, Thanks for the fix, indeed it has fixed quite some glibc maths tests ;) FYI, most likely it's totally unrelated to this bug, for right now with latest gcc trunk and glibc trunk on x86-64, I still see the following iseqsig errors: FAIL: math/test-double-iseqsig FAIL: math/test-float-iseqsig FAIL: math/test-float128-iseqsig FAIL: math/test-float32-iseqsig FAIL: math/test-float32x-iseqsig FAIL: math/test-float64-iseqsig FAIL: math/test-float64x-iseqsig FAIL: math/test-ldouble-iseqsig Cheers, Romain
[Bug target/105506] [12/13 Regression] Error building GCC 12.1.0 against MinGW-w64: fatal error: cannot execute 'cc1': CreateProcess: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506 --- Comment #10 from Brecht Sanders --- I can confirm GCC 12.2.0 builds fine with that patch and without CFLAG -D__USE_MINGW_ACCESS
[Bug tree-optimization/105769] [11/12/13 Regression] program segmentation fault with -ftree-vectorize and nested lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105769 --- Comment #7 from Jakub Jelinek --- Ah, the crash is actually when destructing the map_t temporary (D.5613) and because it shares the stack slot with bias, it isn't surprising. So now to figure out why the stack sharing happens and why even -fstack-reuse=none doesn't help.
[Bug fortran/108420] [13 Regression] ICE in check_charlen_present, at fortran/iresolve.cc:98
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108420 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2023-January/058774.html
[Bug fortran/108421] ICE in get_expr_storage_size, at fortran/interface.cc:2862
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108421 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #2 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2023-January/058773.html
[Bug tree-optimization/105769] [11/12/13 Regression] program segmentation fault with -ftree-vectorize and nested lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105769 --- Comment #6 from Jakub Jelinek --- The expand dump shows: Partition 4: size 64 align 16 cov_jn Partition 0: size 48 align 16 D.5642 biasD.5613 Partition 1: size 32 align 16 D.5615 Partition 2: size 32 align 16 D.5614 where D.5615 is the est2_t return value slot, D.5614 is the est_t parameter slot, D.5613 the map_t object, D.5642 the 48 byte "struct void", bias the 32 byte var, so there clearly is some stack reuse, but not for the vars I actually see overlapping. Anyway, -fstack-reuse=none doesn't seem to help (but the -da expand dump still prints the 3 vars there).
[Bug middle-end/106075] Wrong DSE with -fnon-call-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106075 --- Comment #6 from Jan Hubicka --- The SRA issue is fixed now, but I am not quite sure what is desrable solution here... This blocks modref from understanding side effects of functions doing EH.
[Bug middle-end/108425] Invalid DSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108425
--- Comment #6 from Andrew Pinski ---
(In reply to Jan Hubicka from comment #3)
> short a;
> int *null;
> int
> test(int val1, int val2)
> {
> a=1;
> int r = val1/val2;
> a=3;
> return r;
> }
Which is already filed as PR 106075 .
[Bug middle-end/108425] Invalid DSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108425 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0 Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Andrew Pinski --- Fixed in GCC 13 by r13-1408-gd86a20ee8bed88 .
[Bug middle-end/108425] Invalid DSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108425 --- Comment #4 from Andrew Pinski --- (In reply to Jan Hubicka from comment #3) > We do not delete the stmt causing EH. Also the flag does not fix it: Because it was broken in GCC 12 but was fixed on the trunk ...
[Bug middle-end/108425] Invalid DSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108425
Jan Hubicka changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed||2023-01-16
Resolution|INVALID |---
Ever confirmed|0 |1
--- Comment #3 from Jan Hubicka ---
We do not delete the stmt causing EH. Also the flag does not fix it:
jan@localhost:/tmp> gcc -B ./ -O2 q.C -fnon-call-exceptions -S
-fdump-tree-all-details -fno-delete-dead-exceptions
jan@localhost:/tmp> cat q.C*dse1*
;; Function test (_Z4testP1aS0_, funcdef_no=0, decl_uid=2377, cgraph_uid=1,
symbol_order=0)
Deleted dead store: *a_2(D).e = 4;
Deleted dead store: *a_2(D).d = 3;
Deleted dead store: *a_2(D).c = 2;
Deleted dead store: *a_2(D).b = 1;
Deleted dead store: *a_2(D).a = 0;
void test (struct a * restrict a, struct a * b)
{
:
*a_2(D) = MEM[(const struct a &)b_8(D)];
return;
}
a related testcase:
short a;
int *null;
int
test(int val1, int val2)
{
a=1;
int r = val1/val2;
a=3;
return r;
}
this shows that the function causing EH may not be visited by the ao walk.
[Bug tree-optimization/105769] [11/12/13 Regression] program segmentation fault with -ftree-vectorize and nested lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105769
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
At least when using g++ 12.1.1 (20220507), the crash is because the
stack slot holding return value from jacknife is clobbered on the
bias = est(map);
line.
I see in main (well, print_cov_ratio and std::function inlined into it):
0x004016d1 : lea0x50(%rsp),%rsi
0x004016d6 : lea0x30(%rsp),%rdi
=> 0x004016db : call *0x48(%rsp)
0x004016df : jmp0x401742
where 0x30(%rsp) seems to be the est argument to jacknife (32 byte est_t) and
0x50(%rsp) the return value from jacknife (32 byte est_t)
(gdb) p/x $rsp+0x50
$49 = 0x7fffdd20
where the indirect call calls:
#0 std::_Function_handler),
jacknife<2ul, ab>(std::function (std::function)>, vec<2ul, vec<2ul, ab> >&, vec<2ul,
ab>&)::{lambda(std::function)#1}>::_M_invoke(std::_Any_data const&, std::function&&) (
__functor=..., __args#0=...) at /usr/include/c++/12/bits/std_function.h:288
#1 0x004016df in std::function)>::operator()(std::function)
const (__args#0=...,
this=0x7fffdd00) at /usr/include/c++/12/bits/std_function.h:591
#2 print_cov_ratio () at /usr/src/gcc/obj/gcc/pr105769.C:85
#3 main () at /usr/src/gcc/obj/gcc/pr105769.C:121
But later in
#0 0x004014f3 in jacknife<2ul, ab>(std::function
(std::function)>, vec<2ul, vec<2ul, ab> >&,
vec<2ul, ab>&)::{lambda(std::function)#1}::operator()(std::function) const
(map=..., __closure=0x4172c0) at /usr/src/gcc/obj/gcc/pr105769.C:59
#1 std::__invoke_impl(std::function
(std::function)>, vec<2ul, vec<2ul, ab> >&,
vec<2ul, ab>&)::{lambda(std::function)#1}&,
std::function >(std::__invoke_other,
jacknife<2ul, ab>(std::function (std::function)>, vec<2ul, vec<2ul, ab> >&, vec<2ul,
ab>&)::{lambda(std::function)#1}&,
std::function&&) (__f=...)
at /usr/include/c++/12/bits/invoke.h:61
#2 std::__invoke_r(std::function
(std::function)>, vec<2ul, vec<2ul, ab> >&,
vec<2ul, ab>&)::{lambda(std::function)#1}&,
std::function >(jacknife<2ul,
ab>(std::function (std::function)>,
vec<2ul, vec<2ul, ab> >&, vec<2ul, ab>&)::{lambda(std::function)#1}&, std::function&&)
(__fn=...)
at /usr/include/c++/12/bits/invoke.h:111
#3 std::_Function_handler),
jacknife<2ul, ab>(std::function (std::function)>, vec<2ul, vec<2ul, ab> >&, vec<2ul,
ab>&)::{lambda(std::function)#1}>::_M_invoke(std::_Any_data const&, std::function&&) (
__functor=..., __args#0=...) at /usr/include/c++/12/bits/std_function.h:290
#4 0x004016df in std::function)>::operator()(std::function)
const (__args#0=...,
this=0x7fffdd00) at /usr/include/c++/12/bits/std_function.h:591
#5 print_cov_ratio () at /usr/src/gcc/obj/gcc/pr105769.C:85
#6 main () at /usr/src/gcc/obj/gcc/pr105769.C:121
is equal to the address of the jacknife return value:
$50 = (vec<2, ab> *) 0x7fffdd20
To make the dumps more readable, I've patched the testcase:
--- pr105769.C~ 2023-01-16 19:05:01.0 +0100
+++ pr105769.C 2023-01-16 20:38:25.101524077 +0100
@@ -40,7 +40,7 @@ using sq_mat = mat;
using map_t = std::function;
template
-using est_t = std::function;
+using est_t = std::function; template using est2_t
= std::function;
map_t id_map() {
return [](size_t j) -> size_t {
@@ -50,7 +50,7 @@ map_t id_map() {
template
-est_t jacknife(const est_t> est,
+est2_t jacknife(const est_t> est,
sq_mat& cov, vec& bias) {
return [est, , ](
and with that in the *.gimple dump I see:
void print_cov_ratio ()
[pr105769.C:88:1] {
struct est2_t D.85904;
struct est_t D.85869;
struct ._anon_95 D.85344;
struct map_t D.85939;
struct sq_mat cov_jn;
struct vec bias;
typedef struct ._anon_95 ._anon_95;
try
{
[pr105769.C:73:16] vec<2, vec<2, ab> >::vec ([pr105769.C:73:16] _jn);
[pr105769.C:74:13] vec<2, ab>::vec ([pr105769.C:74:13] );
[pr105769.C:85:23] try
{
try
{
try
{
[pr105769.C:85:23] std::function(std::function)>::function():: > ([pr105769.C:85
try
{
[pr105769.C:85:23] D.85904 = jacknife<2, ab>
([pr105769.C:85:23] , [pr105769.C:85:10] _jn, [pr105769.C:85:18]
); [return slot optimization]
try
{
try
{
[pr105769.C:85:23] D.85939 = id_map (); [return
slot optimization]
try
{
[pr105769.C:85:23]
std::function)>::operator() ([pr105769.C:85:23] , [pr105769.C:85
}
finally
{
[Bug tree-optimization/108306] [12/13 Regression] false-positive -Warray-bounds warning emitted with -fsanitize=shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306 Andrew Macleod changed: What|Removed |Added Attachment #54286|0 |1 is obsolete|| --- Comment #11 from Andrew Macleod --- Created attachment 54287 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54287=edit simpler patch actually, its even simpler than that. The original code was fine, it was returning varying instead of [0,0] for the out of bounds cases.
[Bug fortran/108420] [13 Regression] ICE in check_charlen_present, at fortran/iresolve.cc:98
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108420
--- Comment #2 from anlauf at gcc dot gnu.org ---
I'm regtesting the following patch which fixes both cases:
diff --git a/gcc/fortran/iresolve.cc b/gcc/fortran/iresolve.cc
index 711e9178ad4..33794f0a858 100644
--- a/gcc/fortran/iresolve.cc
+++ b/gcc/fortran/iresolve.cc
@@ -94,9 +94,12 @@ check_charlen_present (gfc_expr *source)
else if (source->expr_type == EXPR_ARRAY)
{
gfc_constructor *c = gfc_constructor_first (source->value.constructor);
- source->ts.u.cl->length
- = gfc_get_int_expr (gfc_charlen_int_kind, NULL,
- c->expr->value.character.length);
+ if (c)
+ source->ts.u.cl->length
+ = gfc_get_int_expr (gfc_charlen_int_kind, NULL,
+ c->expr->value.character.length);
+ if (source->ts.u.cl->length == NULL)
+ gfc_internal_error ("check_charlen_present(): length not set");
}
}
[Bug fortran/108421] ICE in get_expr_storage_size, at fortran/interface.cc:2862
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108421
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2023-01-16
CC||anlauf at gcc dot gnu.org
--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed. A very old issue.
Patch:
diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc
index c4f7faaf597..307082b048d 100644
--- a/gcc/fortran/interface.cc
+++ b/gcc/fortran/interface.cc
@@ -2858,6 +2858,7 @@ get_expr_storage_size (gfc_expr *e)
if (e->ts.type == BT_CHARACTER)
{
if (e->ts.u.cl && e->ts.u.cl->length
+ && e->ts.u.cl->length->ts.type == BT_INTEGER
&& e->ts.u.cl->length->expr_type == EXPR_CONSTANT)
strlen = mpz_get_si (e->ts.u.cl->length->value.integer);
else if (e->expr_type == EXPR_CONSTANT
[Bug middle-end/108425] Invalid DSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108425 --- Comment #2 from Andrew Pinski --- https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Code-Gen-Options.html#index-fdelete-dead-exceptions
[Bug middle-end/108425] Invalid DSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108425 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- You need -fno-delete-dead-exceptions to stop the deleting.
[Bug middle-end/108425] New: Invalid DSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108425
Bug ID: 108425
Summary: Invalid DSE
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
With non-call exceptions we misoptimize following testcase:
struct a{int a,b,c,d,e;};
void
test(struct a * __restrict a, struct a *b)
{
*a = (struct a){0,1,2,3,4};
*a = *b;
}
jan@localhost:/tmp> g++ -O2 q.C -S -fdump-tree-all-details
-fnon-call-exceptions
jan@localhost:/tmp> cat q.C*optimized
;; Function test (_Z4testP1aS0_, funcdef_no=0, decl_uid=2377, cgraph_uid=1,
symbol_order=0)
Scope blocks after cleanups:
{ Scope block #0
}
void test (struct a * restrict a, struct a *b)
{
[local count: 1073741824]:
*a_2(D) = MEM[(const struct a &)b_3(D)];
return;
}
If function is called with b==NULL and the non-call exception is caught, a
should be initialized to {1,2,3,4}.
[Bug fortran/108420] [13 Regression] ICE in check_charlen_present, at fortran/iresolve.cc:98
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108420
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-01-16
Ever confirmed|0 |1
--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.
The following variation actually ICEs for me down to at least v7:
program p
character :: c = 'c'
logical :: m = .true.
print *, merge(transfer('a', 'b', 0), c, m)
end
[Bug tree-optimization/108306] [12/13 Regression] false-positive -Warray-bounds warning emitted with -fsanitize=shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306 --- Comment #10 from Andrew Macleod --- Created attachment 54286 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54286=edit proposed patch There is a bug in the implementation of range-ops for shifts when the shift is guaranteed to be out of range. get_shift_range() calculates what the valid part of op2 is for a shift, but instead of returning true when the result is undefined, it returns FALSE. THe fold routine interprets a false value to mean it can't extract a range at all, and then defaults to either UNDEFINED or VARYING depending on the value of op2. With this patch, we cfix that and return 0 for both rshift and lshift when the possible values are out of range. This causes the testcase as specified to issue no warnings at all. is that correct? See if this fixes your issue. I'll run this thru testing shortly.
[Bug driver/108350] Windows: invoking gcc via symlink does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350 --- Comment #29 from niXman --- Created attachment 54285 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54285=edit patch another version of the patch.
[Bug target/105506] [12/13 Regression] Error building GCC 12.1.0 against MinGW-w64: fatal error: cannot execute 'cc1': CreateProcess: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506 --- Comment #9 from H.J. Lu --- Created attachment 54284 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54284=edit A patch Please try this.
[Bug bootstrap/107950] partial LTO linking of libbackend.a: gcc/gcc-rich-location.cc:207: undefined reference to `range_label_for_type_mismatch::get_text(unsigned int) const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107950 --- Comment #9 from Jan Hubicka --- > > Feel free to grab my initial patch in c#0 and upstream it. I tried that some > time ago in the following email thread: > https://gcc.gnu.org/pipermail/gcc/2021-May/236096.html Actually I was shooting for partial linking LTO streams just to make individual WPAs chaper. With -flinker-output=nolto-rel we are effectively disabling most of benefits of LTO. My main problem was arranging the partial link only when stage1/2 compiler is used so bootstrap works with older GCCs which suports LTO but not partial linking yet. > > > > > I also think it is the case where partial linking makes the symbol to be > > pulled into LTO binary at the initial link time. It should be optimized > > away if linker was not complaining. > > Optimize away during the partial linking? So you think it's a GCC issue when > it > comes to partial linking? No with partial linking you merge all the individual object files into single. So if lto frontned is not using some of libbackend entry point, you still get that code biult into it. So I think it is correct behaviour.
[Bug target/105980] [11/12/13 Regression] ICE in final_scan_insn_1, at final.cc:2811
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105980 --- Comment #8 from H.J. Lu --- A patch is posted at https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610035.html
[Bug other/108276] libiberty unlink_if_ordinary does not handle Windows nul device correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108276 --- Comment #4 from niXman --- (In reply to niXman from comment #2) > I don't think the patch is correct because for WIN32 platform `unlink()` > will never be called even for non-"nul" files. moreover, according to the man: https://github.com/MicrosoftDocs/cpp-docs/blob/main/docs/c-runtime-library/reference/unlink-wunlink.md microsoft's `unlink()/_unlink()` works as just `remove()`.
[Bug modula2/108404] M2RTS_Halt fails with a segv (it should emit a diagnostic and exit).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108404 Gaius Mulley changed: What|Removed |Added CC||gaius at gcc dot gnu.org --- Comment #3 from Gaius Mulley --- Created attachment 54283 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54283=edit Potential fix to allow RTco (and others) to call M2RTS_HaltC This patch contains a new procedure exported from M2RTS HaltC which passes the address of nul terminated strings to be passed without requiring conversion to Modula-2 strings.
[Bug c/108424] ICE in perform_integral_promotions with nullptr case and switch on int type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108424 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Marek Polacek --- Mine then.
[Bug c/108424] ICE in perform_integral_promotions with nullptr case and switch on int type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108424 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||ice-on-invalid-code Ever confirmed|0 |1 Summary|[13 Regression] ICE in |ICE in |perform_integral_promotions |perform_integral_promotions |, at c/c-typeck.cc:2277 |with nullptr case and ||switch on int type Last reconfirmed||2023-01-16 --- Comment #1 from Andrew Pinski --- The ICE showed up when nullptr support was added in r13-2206-g60d84e82639e25 .
[Bug middle-end/108423] [12/13 Regression] ICE in make_ssa_name_fn, at tree-ssanames.cc:360
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108423 Andrew Pinski changed: What|Removed |Added Component|c |middle-end Keywords||ice-on-valid-code Target Milestone|--- |12.3
[Bug driver/108350] Windows: invoking gcc via symlink does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350 --- Comment #28 from niXman --- in rebuilding stage... one more issue: when the symlink called `gcc.exe` and I exec it as `gcc.exe a.c` - all works as it should, but when I exec it as `gcc a.c` - I get the same result as before - `fatal error: cannot execute 'cc1': CreateProcess: No such file or directory` which way this is usually resolved?
[Bug target/105980] [11/12/13 Regression] ICE in final_scan_insn_1, at final.cc:2811
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105980 --- Comment #7 from Jakub Jelinek --- Can you post it to gcc-patches?
[Bug target/106069] [12/13 Regression] wrong code with -O -fno-tree-forwprop -maltivec on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106069 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #34 from Jakub Jelinek --- What is the state of this PR? I see patches posted in August, but don't see anything committed...
[Bug c/108424] New: [13 Regression] ICE in perform_integral_promotions, at c/c-typeck.cc:2277
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108424
Bug ID: 108424
Summary: [13 Regression] ICE in perform_integral_promotions, at
c/c-typeck.cc:2277
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 20220821 and 20220828, with -std=c2x :
$ cat z1.c
void f (int n)
{
switch (n) {
case nullptr:
default:
}
}
$ cat z2.c
void f (int n)
{
switch (n) {
case nullptr:
case 1:
}
return;
}
$ gcc-13-20230115 -c z1.c -std=c2x
z1.c: In function 'f':
z1.c:4:3: internal compiler error: in perform_integral_promotions, at
c/c-typeck.cc:2277
4 | case nullptr:
| ^~~~
0x795f60 perform_integral_promotions(tree_node*)
../../gcc/c/c-typeck.cc:2277
0x7f1987 check_case_value
../../gcc/c-family/c-common.cc:2243
0x8269fd c_add_case_label(unsigned int, splay_tree_s*, tree_node*, tree_node*,
tree_node*, tree_node*)
../../gcc/c-family/c-common.cc:5092
0x798436 do_case(unsigned int, tree_node*, tree_node*, tree_node*)
../../gcc/c/c-typeck.cc:11561
0x7d3ab6 c_parser_label
../../gcc/c/c-parser.cc:6394
0x7de9f5 c_parser_compound_statement_nostart
../../gcc/c/c-parser.cc:6207
0x7def03 c_parser_compound_statement
../../gcc/c/c-parser.cc:6117
0x7dc522 c_parser_statement_after_labels
../../gcc/c/c-parser.cc:6628
0x7e28e2 c_parser_statement
../../gcc/c/c-parser.cc:6599
0x7e28e2 c_parser_c99_block_statement
../../gcc/c/c-parser.cc:6858
0x7dca53 c_parser_switch_statement
../../gcc/c/c-parser.cc:7120
0x7dca53 c_parser_statement_after_labels
../../gcc/c/c-parser.cc:6637
0x7de68a c_parser_compound_statement_nostart
../../gcc/c/c-parser.cc:6308
0x7def03 c_parser_compound_statement
../../gcc/c/c-parser.cc:6117
0x7e0f13 c_parser_declaration_or_fndef
../../gcc/c/c-parser.cc:2853
0x7e869f c_parser_external_declaration
../../gcc/c/c-parser.cc:1925
0x7e8fdd c_parser_translation_unit
../../gcc/c/c-parser.cc:1779
0x7e8fdd c_parse_file()
../../gcc/c/c-parser.cc:24602
0x847651 c_common_parse_file()
../../gcc/c-family/c-opts.cc:1248
[Bug c/108423] New: [12/13 Regression] ICE in make_ssa_name_fn, at tree-ssanames.cc:360
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108423
Bug ID: 108423
Summary: [12/13 Regression] ICE in make_ssa_name_fn, at
tree-ssanames.cc:360
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 2024 and 20211121, at -O2+ :
$ cat z1.c
int f (int n, int (**(*a)(void))[n])
{
return (*a())[0];
}
int g ()
{
int m = 3;
int (*a[m])(void);
return f(m, );
}
$ gcc-13-20230115 -c z1.c -O2
z1.c: In function 'f':
z1.c:3:10: warning: returning 'int *' from a function with return type 'int'
makes integer from pointer without a cast [-Wint-conversion]
3 | return (*a())[0];
| ^
z1.c: In function 'g':
z1.c:9:15: warning: passing argument 2 of 'f' from incompatible pointer type
[-Wincompatible-pointer-types]
9 | return f(m, );
| ^~
| |
| int (* (*)[m])(void)
z1.c:1:24: note: expected 'int (** (*)(void))[n]' but argument is of type 'int
(* (*)[m])(void)'
1 | int f (int n, int (**(*a)(void))[n])
| ~^~~~
during GIMPLE pass: einline
z1.c:9:10: internal compiler error: in make_ssa_name_fn, at
tree-ssanames.cc:360
9 | return f(m, );
| ^~~~
0x11b1edd make_ssa_name_fn(function*, tree_node*, gimple*, unsigned int)
../../gcc/tree-ssanames.cc:357
0xfa16f6 make_ssa_name
../../gcc/tree-ssanames.h:97
0xfa16f6 remap_ssa_name
../../gcc/tree-inline.cc:237
0xfa5717 copy_tree_body_r(tree_node**, int*, void*)
../../gcc/tree-inline.cc:1226
0x1271d23 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../gcc/tree.cc:11289
0x1272784 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../gcc/tree.cc:11520
0xf9e851 remap_type_1
../../gcc/tree-inline.cc:596
0xf9fa28 remap_type(tree_node*, copy_body_data*)
../../gcc/tree-inline.cc:713
0xf9e6b7 remap_type_1
../../gcc/tree-inline.cc:425
0xf9fa28 remap_type(tree_node*, copy_body_data*)
../../gcc/tree-inline.cc:713
0xf9e6b7 remap_type_1
../../gcc/tree-inline.cc:425
0xf9fa28 remap_type(tree_node*, copy_body_data*)
../../gcc/tree-inline.cc:713
0xf9e7bf remap_type_1
../../gcc/tree-inline.cc:509
0xf9fa28 remap_type(tree_node*, copy_body_data*)
../../gcc/tree-inline.cc:713
0xf9e6b7 remap_type_1
../../gcc/tree-inline.cc:425
0xf9fa28 remap_type(tree_node*, copy_body_data*)
../../gcc/tree-inline.cc:713
0xfacb69 initialize_inlined_parameters
../../gcc/tree-inline.cc:3642
0xfacb69 expand_call_inline
../../gcc/tree-inline.cc:5004
0xfaf1e9 gimple_expand_calls_inline
../../gcc/tree-inline.cc:5307
0xfaf1e9 optimize_inline_calls(tree_node*)
../../gcc/tree-inline.cc:5479
[Bug c++/108422] New: [13 Regression] ICE: base pointer cycle detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108422
Bug ID: 108422
Summary: [13 Regression] ICE: base pointer cycle detected
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 20220911 and 20220918 :
$ cat z1.cc
void foo (int a)
{
auto bar = [&]()
{
#pragma omp target parallel
#pragma omp target
++a;
};
bar();
}
$ cat z2.cc
void foo (int a)
{
auto bar = [&]()
{
#pragma omp target
#pragma omp target
++a;
};
bar();
}
$ g++-13-20230115 -c z1.cc -fopenmp
when processing group:
map(to:*__closure)
z1.cc: In lambda function:
z1.cc:5:13: internal compiler error: base pointer cycle detected
5 | #pragma omp target parallel
| ^~~
0xc0a6f3 omp_tsort_mapping_groups_1
../../gcc/gimplify.cc:9603
0xc0a515 omp_tsort_mapping_groups_1
../../gcc/gimplify.cc:9646
0xc0a515 omp_tsort_mapping_groups_1
../../gcc/gimplify.cc:9646
0xc1ee00 omp_tsort_mapping_groups
../../gcc/gimplify.cc:9684
0xc1ee00 gimplify_scan_omp_clauses
../../gcc/gimplify.cc:10771
0xc24fce gimplify_omp_workshare
../../gcc/gimplify.cc:15390
0xc10cca gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:16903
0xc14308 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.cc:7219
0xc14861 gimplify_bind_expr
../../gcc/gimplify.cc:1430
0xc10eea gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:16562
0xc14308 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.cc:7219
0xc11ccb gimplify_statement_list
../../gcc/gimplify.cc:2019
0xc11ccb gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:16806
0xc14308 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.cc:7219
0xc14861 gimplify_bind_expr
../../gcc/gimplify.cc:1430
0xc10eea gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:16562
0xc14308 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.cc:7219
0xc153ab gimplify_body(tree_node*, bool)
../../gcc/gimplify.cc:17623
0xc157fd gimplify_function_tree(tree_node*)
../../gcc/gimplify.cc:17822
0xa988e7 cgraph_node::analyze()
../../gcc/cgraphunit.cc:676
[Bug fortran/108421] New: ICE in get_expr_storage_size, at fortran/interface.cc:2862
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108421 Bug ID: 108421 Summary: ICE in get_expr_storage_size, at fortran/interface.cc:2862 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least r5 : (follow-up of pr107707) $ cat z1.f90 program p character(real(3)) :: c call s(c) end subroutine s(x) character(*) :: x end $ gfortran-13-20230115 -c z1.f90 z1.f90:2:13: 2 |character(real(3)) :: c | 1 Error: Expression at (1) must be of INTEGER type, found REAL f951: internal compiler error: Segmentation fault 0xf8734f crash_signal ../../gcc/toplev.cc:314 0x848e0d get_expr_storage_size ../../gcc/fortran/interface.cc:2862 0x848e0d gfc_compare_actual_formal(gfc_actual_arglist**, gfc_formal_arglist*, int, int, bool, locus*) ../../gcc/fortran/interface.cc:3326 0x9b2746 check_externals_procedure ../../gcc/fortran/frontend-passes.cc:5742 0x9b7439 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int (*)(gfc_expr**, int*, void*), void*) ../../gcc/fortran/frontend-passes.cc:5352 0x9b8c9b gfc_check_externals0 ../../gcc/fortran/frontend-passes.cc:5861 0x9b9c24 gfc_check_externals(gfc_namespace*) ../../gcc/fortran/frontend-passes.cc:5883 0x89e900 gfc_parse_file() ../../gcc/fortran/parse.cc:6942 0x8ed3af gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:229
[Bug fortran/108420] New: [13 Regression] ICE in check_charlen_present, at fortran/iresolve.cc:98
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108420
Bug ID: 108420
Summary: [13 Regression] ICE in check_charlen_present, at
fortran/iresolve.cc:98
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 20221127 and 20221204 :
$ cat z1.f90
program p
character :: c = 'c'
print *, merge(transfer('a', 'b', 0), c, .true.)
end
$ gfortran-13-20230115 -c z1.f90
f951: internal compiler error: Segmentation fault
0xda7faf crash_signal
../../gcc/toplev.cc:314
0x7eb6dc check_charlen_present
../../gcc/fortran/iresolve.cc:98
0x7eecff gfc_resolve_merge(gfc_expr*, gfc_expr*, gfc_expr*, gfc_expr*)
../../gcc/fortran/iresolve.cc:1958
0x7d7635 resolve_intrinsic
../../gcc/fortran/intrinsic.cc:4577
0x7d7635 do_simplify
../../gcc/fortran/intrinsic.cc:4714
0x7e24fa gfc_intrinsic_func_interface(gfc_expr*, int)
../../gcc/fortran/intrinsic.cc:5056
0x839218 resolve_unknown_f
../../gcc/fortran/resolve.cc:2990
0x839218 resolve_function
../../gcc/fortran/resolve.cc:3347
0x839218 gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.cc:7195
0x83f4ac gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.cc:7162
0x83f4ac gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.cc:11982
0x83dfdf gfc_resolve_blocks(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.cc:10980
0x83e338 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.cc:11972
0x8410e7 resolve_codes
../../gcc/fortran/resolve.cc:17629
0x8411ae gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.cc:17664
0x828f44 resolve_all_program_units
../../gcc/fortran/parse.cc:6656
0x828f44 gfc_parse_file()
../../gcc/fortran/parse.cc:6912
0x876eff gfc_be_parse_file
../../gcc/fortran/f95-lang.cc:229
[Bug libstdc++/106183] std::atomic::wait might fail to be unblocked by notify_one/all on platforms without platform_wait()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106183 --- Comment #8 from CVS Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:1dfe15e534adba21e680b8128f0631e8054a5e42 commit r12-9047-g1dfe15e534adba21e680b8128f0631e8054a5e42 Author: Jonathan Wakely Date: Thu Jul 28 16:15:58 2022 +0100 libstdc++: Unblock atomic wait on non-futex platforms [PR106183] When using a mutex and condition variable, the notifying thread needs to increment _M_ver while holding the mutex lock, and the waiting thread needs to re-check after locking the mutex. This avoids a missed notification as described in the PR. By moving the increment of _M_ver to the base _M_notify we can make the use of the mutex local to the use of the condition variable, and simplify the code a little. We can use a relaxed store because the mutex already provides sequential consistency. Also we don't need to check whether __addr == &_M_ver because we know that's always true for platforms that use a condition variable, and so we also know that we always need to use notify_all() not notify_one(). Reviewed-by: Thomas Rodgers libstdc++-v3/ChangeLog: PR libstdc++/106183 * include/bits/atomic_wait.h (__waiter_pool_base::_M_notify): Move increment of _M_ver here. [!_GLIBCXX_HAVE_PLATFORM_WAIT]: Lock mutex around increment. Use relaxed memory order and always notify all waiters. (__waiter_base::_M_do_wait) [!_GLIBCXX_HAVE_PLATFORM_WAIT]: Check value again after locking mutex. (__waiter_base::_M_notify): Remove increment of _M_ver. (cherry picked from commit af98cb88eb4be6a1668ddf966e975149bf8610b1)
[Bug libstdc++/106183] std::atomic::wait might fail to be unblocked by notify_one/all on platforms without platform_wait()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106183 Jonathan Wakely changed: What|Removed |Added CC||bjornsundin02 at gmail dot com --- Comment #7 from Jonathan Wakely --- *** Bug 101037 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/106523] [10/11/12/13 Regression] forwprop miscompile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106523 --- Comment #5 from Jakub Jelinek --- Created attachment 54282 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54282=edit gcc13-pr106523.patch Untested fix.
[Bug libstdc++/101037] C++20 std::atomic_flag deadlock on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101037 Jonathan Wakely changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #9 from Jonathan Wakely --- Closing as a dup of the other bug (even though this one was reported, and correctly analyzed, earlier). *** This bug has been marked as a duplicate of bug 106183 ***
[Bug libstdc++/101037] C++20 std::atomic_flag deadlock on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101037 --- Comment #8 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #6) > (In reply to niXman from comment #5) > > > can't the example be checked using thread sanitizer? > > > > ... on Linux. > > The implementation is completely different on linux, so that would require > some code changes at least. Which is actually trivial, and confirms the bug is not Windows-specific. As comment 3 said, it's present in all non-futex targets. I can reproduce the deadlock on linux when disabling the platform_wait path in gcc-12. > There was already a change to the code waiting on _M_ver in > r12-7151-g4cf3c339815cdf and then a fix for the synchronization in > r13-1957-gaf98cb88eb4be6 (which should be backported to the gcc-12 branch). After backporting r13-1957 to gcc-12 the deadlock is gone. So I think this is the same issue as PR 106183. I'll push the backport to the gcc-12 branch. I think the changes are equivalent to Pekka's correct suggestion in comment 3, although only the minimal fix, not the "and a bit more" part.
[Bug libstdc++/101037] C++20 std::atomic_flag deadlock on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101037 --- Comment #7 from niXman --- > The implementation is completely different on linux, so that would require > some code changes at least. I didn't think so... I think conceptually the solution looks the same for all platforms... OK, got it! > Does the problem even still exist on Windows? I don't know, I haven't tested it, I have just seen the issue is still open. will test it! thanks!
[Bug libgomp/96844] OpenMP: two worksharing constructs with different num_threads clauses break thread pooling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96844 rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org Last reconfirmed||2023-01-16 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=44833 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from rsandifo at gcc dot gnu.org --- I got an internal Arm report about the same behaviour. Like you say, they don't see the problem with LLVM's and Intel's libraries. https://github.com/xianyi/OpenBLAS/pull/3546#issuecomment-1153914479 is a discussion about the same problem in an OpenBLAS context. Some other places where the question has come up: - https://stackoverflow.com/a/52821175 - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71781 I suppose the question is what to do instead. As [https://github.com/xianyi/OpenBLAS/pull/3546#issuecomment-1154817082] says, past behaviour isn't necessarily an indication of future behaviour, so a simple counter- or time-based reaping heuristic is likely to create unexpected cliff-edges. >From my reading of the LLVM libomp sources, it looks like it doesn't reap threads until: - library shutdown - omp_pause_resource(omp_pause_hard, ...) or omp_pause_resource_all(omp_pause_hard) is called (__kmp_allocate_team also reaps teams that are too small for the request, but the comments indicate that that's temporary.) I could well be wrong: there could well be other situations in which LLVM reaps threads too. Still, would it be OK/useful to have an environment variable that selects the same behaviour in libgomp?
[Bug libstdc++/101037] C++20 std::atomic_flag deadlock on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101037 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2023-01-16 Ever confirmed|0 |1 --- Comment #6 from Jonathan Wakely --- (In reply to niXman from comment #5) > > can't the example be checked using thread sanitizer? > > ... on Linux. The implementation is completely different on linux, so that would require some code changes at least. There was already a change to the code waiting on _M_ver in r12-7151-g4cf3c339815cdf and then a fix for the synchronization in r13-1957-gaf98cb88eb4be6 (which should be backported to the gcc-12 branch). Does the problem even still exist on Windows?
[Bug driver/108350] Windows: invoking gcc via symlink does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350 --- Comment #27 from niXman --- ah, got it. thanks!
[Bug driver/108350] Windows: invoking gcc via symlink does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350 --- Comment #26 from Bill Zissimopoulos --- (In reply to niXman from comment #25) > updated patch there: > https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610029.html A couple of things: 1. If the GetFinalPathNameByHandle method fails, I would always fall back to the GetFullPathName method (which has fewer failure modes). GetFinalPathNameByHandle can fail for many reasons: for example, if the drive X: is a local drive created by SUBST/DefineDosDevice or for special files like NUL (as you have discovered). 2. I would not do anything particular for special files like NUL. See my above comment: if GetFinalPathNameByHandle fails fall back to GetFullPathName.
[Bug ipa/106077] Invalid IPA-SRA with non-call exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106077 --- Comment #2 from CVS Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:b1f30bf42d8d47228e52de998f3172b2f5dd7265 commit r13-5215-gb1f30bf42d8d47228e52de998f3172b2f5dd7265 Author: Jan Hubicka Date: Mon Jan 16 18:14:45 2023 +0100 Fix wrong code issues with ipa-sra Fix wrong code issues in ipa-sra where we are trying to prove that on every execution of a given function a call to other function will happen. The code uses post dominators and makes a wrong query (which passes only for first BB in function). Hoever post-dominators are only valid if fake edges for every possible reason for fuction execution to terminate are added. Fixing this using postdominators is somewhat costy since one needs to walk whole body and add a lot of fake edges. I ended up implementing a special purpose function for this which is also useful in ipa-modref and other places that does similar analysis. One does not need to modify CFG to use it and moreover for complex functions it usually stops on first unanalyzed function call and ends up being relatively cheap. Bootstrapped/regtested x86_64-linux, plan to commit it shortly. gcc/ChangeLog: 2023-01-16 Jan Hubicka PR ipa/106077 * ipa-modref.cc (modref_access_analysis::analyze): Use find_always_executed_bbs. * ipa-sra.cc (process_scan_results): Likewise. * ipa-utils.cc (stmt_may_terminate_function_p): New function. (find_always_executed_bbs): New function. * ipa-utils.h (stmt_may_terminate_function_p): Declare. (find_always_executed_bbs): Declare. gcc/testsuite/ChangeLog: 2023-01-16 Jan Hubicka * g++.dg/tree-ssa/pr106077.C: New test.
[Bug libstdc++/101037] C++20 std::atomic_flag deadlock on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101037 --- Comment #5 from niXman --- (In reply to niXman from comment #4) > I don't think it is mingw/windows related. > can't the example be checked using thread sanitizer? ... on Linux.
[Bug libstdc++/101037] C++20 std::atomic_flag deadlock on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101037 niXman changed: What|Removed |Added CC||i.nixman at autistici dot org --- Comment #4 from niXman --- I don't think it is mingw/windows related. can't the example be checked using thread sanitizer?
[Bug driver/108350] Windows: invoking gcc via symlink does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350 --- Comment #25 from niXman --- updated patch there: https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610029.html
[Bug other/108276] libiberty unlink_if_ordinary does not handle Windows nul device correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108276 --- Comment #3 from niXman --- and I propose to use `strcasecmp()`
[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107532 --- Comment #3 from Marek Polacek --- Sorry about the long delay. Unfortunately I'm not sure yet how to fix it. We have Ref::inner (_EXPR ) which returns a ref and its arg is a temporary.
[Bug target/108396] [12/13 Regression] PPCLE: vec_vsubcuq missing since r12-5752-gd08236359eb229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108396 --- Comment #3 from Segher Boessenkool --- (In reply to Kewen Lin from comment #2) > Yes, it's a typo, which makes the macro definition change to: > > #define vec_vsubcuqP __builtin_vec_vsubcuq Yup. > Unfortunately we don't have the testing coverage in testsuite for the > expected name vec_vsubcuq (in rs6000-vecdefines.h): Is it hard to add one for all (or many) of the legacy builtins? Do we want to test more than just if it compiles?
[Bug other/108276] libiberty unlink_if_ordinary does not handle Windows nul device correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108276 --- Comment #2 from niXman --- @Himal ``` +#ifdef _WIN32 +if (stricmp (name, "nul") == 0) + return 1; +#else struct stat st; if (lstat (name, ) == 0 && (S_ISREG (st.st_mode) || S_ISLNK (st.st_mode))) return unlink (name); +#endif ``` I don't think the patch is correct because for WIN32 platform `unlink()` will never be called even for non-"nul" files. right?
[Bug c++/108417] [ICE] Crash on aggregate initialization of base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108417 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=90254 --- Comment #5 from Andrew Pinski --- Note in c++17 the copy is required to be elision away. And the frontend is doing that but messing up. The problems are all related really. The question comes should they be elision away or not and that is what the c++ defect report is about and the same way the abi issue is about.
[Bug c++/108417] [ICE] Crash on aggregate initialization of base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108417 --- Comment #4 from m.cencora at gmail dot com --- (In reply to Andrew Pinski from comment #3) > I am 99% sure this is the same issue as pr98995 even though this is a crash. > The ice is the same as PR 93711. > > This code has both an abi issue against it filed and a c++ defect report > filed against it. I think this is a separate issue. Here the 'NonTrivial' class is copyable, so even if compiler cannot perform copy ellision (due to ABI or etc), it should be able to initialize the base object.
[Bug c++/86426] g++ ICE at on valid code in tree_operand_check, at tree.h:3615
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86426 --- Comment #11 from David Binderman --- Probably still broken. One for Jason ?
[Bug c++/108417] [ICE] Crash on aggregate initialization of base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108417 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=93711 --- Comment #3 from Andrew Pinski --- I am 99% sure this is the same issue as pr98995 even though this is a crash. The ice is the same as PR 93711. This code has both an abi issue against it filed and a c++ defect report filed against it.
[Bug tree-optimization/108419] New: [13 Regression] Dead Code Elimination Regression at -O2 since r13-440-g98e475a8f58
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108419
Bug ID: 108419
Summary: [13 Regression] Dead Code Elimination Regression at
-O2 since r13-440-g98e475a8f58
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: yann at ywg dot ch
Target Milestone: ---
Created attachment 54281
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54281=edit
case as file
cat case.c #1565
static int b = 6, c;
long d;
short h;
short i;
short j;
char k;
void foo();
short(a)(short l, short m) { return l + m; }
short f();
short g(unsigned short, int, char, long);
static signed char e() {
unsigned n = -10;
for (; n >= 14; n = a(n, 8)) {
i = g(b, 0, c, b);
j = f(i, b, d < j, 5, 7, 9, 5);
k = 200 + n;
h = k % 5;
if (h)
;
else
foo();
}
return n;
}
int main() {
b || e();
b = 1;
}
`gcc-f99d7d669eaa2830eb5878df4da67e77ec791522 (trunk) -O2` can not eliminate
`foo` but `gcc-releases/gcc-12.2.0 -O2` can.
`gcc-f99d7d669eaa2830eb5878df4da67e77ec791522 (trunk) -O2 -S -o /dev/stdout
case.c`
- OUTPUT -
main:
.LFB2:
.cfi_startproc
movlb(%rip), %esi
testl %esi, %esi
je .L12
movl$1, b(%rip)
xorl%eax, %eax
ret
.L12:
pushq %r12
.cfi_def_cfa_offset 16
.cfi_offset 12, -16
movl$-10, %r12d
pushq %rbp
.cfi_def_cfa_offset 24
.cfi_offset 6, -24
movl$2, %ebp
pushq %rbx
.cfi_def_cfa_offset 32
.cfi_offset 3, -32
movl$5, %ebx
.L6:
movslq b(%rip), %rcx
xorl%edx, %edx
xorl%esi, %esi
movzwl %cx, %edi
callg
movlb(%rip), %esi
movl$5, %ecx
movswq j(%rip), %rdx
movw%ax, i(%rip)
cmpqd(%rip), %rdx
movswl %ax, %edi
movl$9, %r9d
pushq %rax
.cfi_def_cfa_offset 40
setg%dl
movl$7, %r8d
xorl%eax, %eax
pushq $5
.cfi_def_cfa_offset 48
movzbl %dl, %edx
callf
movw%ax, j(%rip)
leal-56(%r12), %eax
movb%al, k(%rip)
cbtw
idivb %bl
movl%eax, %edx
sarw$8, %dx
shrw$8, %ax
movw%dx, h(%rip)
popq%rdx
.cfi_def_cfa_offset 40
popq%rcx
.cfi_def_cfa_offset 32
je .L13
.L5:
addl$8, %r12d
subl$1, %ebp
movswl %r12w, %r12d
je .L14
movl$1, %ebp
jmp .L6
.L14:
movl$1, b(%rip)
popq%rbx
.cfi_remember_state
.cfi_def_cfa_offset 24
xorl%eax, %eax
popq%rbp
.cfi_def_cfa_offset 16
popq%r12
.cfi_def_cfa_offset 8
ret
.L13:
.cfi_restore_state
xorl%eax, %eax
callfoo
jmp .L5
-- END OUTPUT -
`gcc-releases/gcc-12.2.0 -O2 -S -o /dev/stdout case.c`
- OUTPUT -
main:
.LFB2:
.cfi_startproc
movlb(%rip), %r9d
testl %r9d, %r9d
je .L11
movl$1, b(%rip)
xorl%eax, %eax
ret
.L11:
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movl$-66, %ebp
pushq %rbx
.cfi_def_cfa_offset 24
.cfi_offset 3, -24
movl$5, %ebx
pushq %r8
.cfi_def_cfa_offset 32
.L5:
movslq b(%rip), %rcx
xorl%edx, %edx
xorl%esi, %esi
movzwl %cx, %edi
callg
movswq j(%rip), %rdx
cmpqd(%rip), %rdx
movl$9, %r9d
pushq %rcx
.cfi_def_cfa_offset 40
setg%dl
movlb(%rip), %esi
movswl %ax, %edi
pushq $5
.cfi_def_cfa_offset 48
movzbl %dl, %edx
movl$7, %r8d
movl$5, %ecx
movw%ax, i(%rip)
xorl%eax, %eax
callf
popq%rsi
.cfi_def_cfa_offset 40
popq%rdi
.cfi_def_cfa_offset 32
movb%bpl, k(%rip)
movw%ax, j(%rip)
movsbw %bpl, %ax
idivb %bl
sarw$8, %ax
movw%ax, h(%rip)
cmpb$-58, %bpl
je .L12
movl$-58, %ebp
jmp .L5
.L12:
movl$1, b(%rip)
xorl%eax, %eax
popq%rdx
.cfi_def_cfa_offset 24
popq%rbx
.cfi_def_cfa_offset 16
popq%rbp
.cfi_def_cfa_offset 8
ret
-- END OUTPUT -
Bisects to: r13-440-g98e475a8f58
commit 98e475a8f58ca3ba6e9bd5c9276efce4236f5d26
[Bug target/108346] gather/scatter loops optimized too often for znver4 (and other zens)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108346 --- Comment #2 from Jan Hubicka --- Sadly the win/loss cases does not seem to suggest a simple cost scheme. We currently compute gather/scatter costs as static startup cost + cost per lane and they are set to approximately match actual latencies. I am not sure how much better we can do.
[Bug tree-optimization/108418] gcc does not optimize trivial code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108418 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Ever confirmed|0 |1 Last reconfirmed||2023-01-16 Status|UNCONFIRMED |NEW --- Comment #2 from Richard Biener --- Confirmed. We might have a duplicate bugreport for this - it's difficult to fix because the tests are lowered to a CFG representation and "re-associating" in that representation is difficult.
[Bug tree-optimization/108418] gcc does not optimize trivial code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108418 --- Comment #1 from Коренберг Марк --- Sorry, but such kind of code happens as a result of C-code automatic generation.
[Bug tree-optimization/108418] New: gcc does not optimize trivial code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108418
Bug ID: 108418
Summary: gcc does not optimize trivial code
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: socketpair at gmail dot com
Target Milestone: ---
https://godbolt.org/z/s3j8jK6ca
```
#include
int firewall1(const uint8_t *restrict data) {
const uint8_t ip_proto = *data;
const uint16_t dst_port = *((const uint16_t *)data + 32);
const uint16_t qwe = *((const uint16_t *)data + 64);
if (ip_proto == 17 && dst_port == 17 && qwe == 42) return 1;
if (ip_proto == 17 && dst_port == 23 && qwe == 42) return 1;
if (ip_proto == 17 && dst_port == 45 && qwe == 42) return 1;
if (ip_proto == 17 && dst_port == 63 && qwe == 42) return 1;
if (ip_proto == 17 && dst_port == 0 && qwe == 42) return 1;
if (ip_proto == 17 && dst_port == 2 && qwe == 42) return 1;
if (ip_proto == 17 && dst_port == 3 && qwe == 42) return 1;
return 0;
}
int firewall2(const uint8_t *restrict data) {
const uint8_t ip_proto = *data;
const uint16_t dst_port = *((const uint16_t *)data + 32);
const uint16_t qwe = *((const uint16_t *)data + 64);
if (ip_proto == 17 && dst_port == 17) return 1;
if (ip_proto == 17 && dst_port == 23) return 1;
if (ip_proto == 17 && dst_port == 45) return 1;
if (ip_proto == 17 && dst_port == 63) return 1;
if (ip_proto == 17 && dst_port == 0) return 1;
if (ip_proto == 17 && dst_port == 2) return 1;
if (ip_proto == 17 && dst_port == 3) return 1;
return 0;
}
```
It can't understand common condition (ip_proto == 17 && qwe == 42).
But it can for simpler case in firewall2.
See godbolt assembler output.
[Bug driver/108350] Windows: invoking gcc via symlink does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #24 from niXman ---
BTW, I have no ideas how can I test the patch for UNC ('\\?\UNC' prefixed) ...
[Bug c++/108417] [ICE] Crash on aggregate initialization of base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108417 Richard Biener changed: What|Removed |Added Keywords||needs-bisection Known to fail||10.4.1 Last reconfirmed||2023-01-16 Status|UNCONFIRMED |NEW Known to work||12.2.1 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Confirmed. Note that trunk ICEs differently now: > ./cc1plus -quiet t.ii -std=c++17 t.ii: In function 'Derived ICE_createDerived()': t.ii:37:5: internal compiler error: in cp_gimplify_init_expr, at cp/cp-gimplify.cc:253 37 | }; | ^ 0xd6fb33 cp_gimplify_init_expr /home/rguenther/src/trunk/gcc/cp/cp-gimplify.cc:253 0xd709d8 cp_gimplify_expr(tree_node**, gimple**, gimple**) /home/rguenther/src/trunk/gcc/cp/cp-gimplify.cc:508 0x15a124e gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) /home/rguenther/src/trunk/gcc/gimplify.cc:16269 0x157517f gimplify_stmt(tree_node**, gimple**) /home/rguenther/src/trunk/gcc/gimplify.cc:7219 0x155e516 gimplify_and_add(tree_node*, gimple**) /home/rguenther/src/trunk/gcc/gimplify.cc:492 0x156d62c gimplify_init_ctor_eval /home/rguenther/src/trunk/gcc/gimplify.cc:5019 ... 253 gcc_checking_assert (TARGET_EXPR_ELIDING_P (from)); needs bisecting for the fix and the new breakage (and possibly splitting).
[Bug c++/108417] [ICE] Crash on aggregate initialization of base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108417 --- Comment #1 from m.cencora at gmail dot com --- The problem seems to occur if base class has a tail padding, and derived class is trying to reuse it to store its members
[Bug driver/108350] Windows: invoking gcc via symlink does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350 --- Comment #23 from niXman --- Created attachment 54280 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54280=edit patch looks like I have finished! boostrapped successfully as x86_64-mingw-w64. @Bill Zissimopoulos, @Jonathan Wakely could you please review the patch?
[Bug driver/108350] Windows: invoking gcc via symlink does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350 --- Comment #22 from Bill Zissimopoulos --- (In reply to niXman from comment #21) > another strange problem is that `CreateFile()` is able to open the special > file `nul` for reading, but `GetFinalPathNameByHandle()` cannot get the full > name of this file and returns 0 and setting `last error` to > `ERROR_INVALID_PARAMETER`. > > and so you don't get bored I'll add: `GetFullPathName()` can get the full > name of such a file. > > (how could this happen? %) ) Yes :) GetFinalPathNameByHandle internally performs a special request that only file system drivers respond to (IRP_MJ_QUERY_INFORMATION / FileNormalizedNameInformation). So a path like X:\Path\To\File will be resolved to an internal path like: \Device\\Path\To\File Now \Device\ is a file system driver (or points to one via an elaborate mechanism, but let's not complicate matters further) and knows how to respond to FileNormalizedNameInformation queries. OTOH a path like nul will be resolved to an internal path like: \Device\Null This is a simple device and not a file system driver and does not know how to respond to FileNormalizedNameInformation queries. So GetFinalPathNameByHandle works on the first, but not the second. As for GetFullPathName: I think it works by doing simple string manipulations on the path (i.e. no attempts to open the file and query its path, etc.)
