[Bug c/107802] -Wsuggest-attribute=format ignores [[gnu::format(...)]]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107802 --- Comment #4 from Andrew Pinski --- (In reply to Adam Badura from comment #3) > Why is this marked as a duplicate of bug 98487? I have seen bug 98487 before > reporting it. Furthermore, I experienced it while trying my code sample on > the trunk version to see if the problem still exists. Because the problem is exactly the same. That is with release checking set, the ICE does not happen and instead the attribute gets ignored. > However, since trunk version breaks completely with the same code it is not > possible to determine if the problem reported here exists there or not. > After preventing the compiler from crashing we may very well start to > observe the problem reported here. > > Or is bug 98487 intended to solve the problem reported here as well along > the way? The later. The ICE is due to how attributes are represented internally inside GCC. The scoped attributes are done slightly different from the gnu style attributes but then that was forgotten in the code and only handle the gnu style attribute and that causes an ICE. The fix is to use the functions which handle both ways and it will also fix the ignoring part too. Also if you compile the trunk with --enable-checking=release, you get the behavior reported here of ignoring the attribute; the ignoring is a symptom and the ICE shows the cause (but is hidden in releases for speed reasons).
[Bug c/107802] -Wsuggest-attribute=format ignores [[gnu::format(...)]]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107802 --- Comment #3 from Adam Badura --- Why is this marked as a duplicate of bug 98487? I have seen bug 98487 before reporting it. Furthermore, I experienced it while trying my code sample on the trunk version to see if the problem still exists. However, since trunk version breaks completely with the same code it is not possible to determine if the problem reported here exists there or not. After preventing the compiler from crashing we may very well start to observe the problem reported here. Or is bug 98487 intended to solve the problem reported here as well along the way?
[Bug libstdc++/107801] Building cross compiler for H8 family fails in libstdc++ (c++17/memory_resource.cc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107801
--- Comment #7 from Jan Dubiec ---
OK, I have applied the patch manually to my 12.2.0 tree and libstdc++ has been
partially build. "Partially" because everything seems to be fine for H8/300H,
H8S and H8SX in "advanced mode" (let's call it "32-bit mode") but compilation
fails (in the same file!) in "normal mode" ("16-bit mode"). Note the -mn
option:
[...]
Making all in c++17
make[9]: Entering directory
'/d/Works/xcomp/gcc-build/h8300-elf/normal/libstdc++-v3/src/c++17'
/bin/sh ../../libtool --tag CXX --tag disable-shared --mode=compile
/d/Works/xcomp/gcc-build/./gcc/xgcc -shared-libgcc
-B/d/Works/xcomp/gcc-build/./gcc -nostdinc++
-L/d/Works/xcomp/gcc-build/h8300-elf/normal/libstdc++-v3/src
-L/d/Works/xcomp/gcc-build/h8300-elf/normal/libstdc++-v3/src/.libs
-L/d/Works/xcomp/gcc-build/h8300-elf/normal/libstdc++-v3/libsupc++/.libs
-B/usr/local/h8300-elf/bin/ -B/usr/local/h8300-elf/lib/ -isystem
/usr/local/h8300-elf/include -isystem /usr/local/h8300-elf/sys-include -mn
-I/d/Works/xcomp/gcc-12.2.0/libstdc++-v3/../libgcc
-I/d/Works/xcomp/gcc-build/h8300-elf/normal/libstdc++-v3/include/h8300-elf
-I/d/Works/xcomp/gcc-build/h8300-elf/normal/libstdc++-v3/include
-I/d/Works/xcomp/gcc-12.2.0/libstdc++-v3/libsupc++ -std=gnu++17 -nostdinc++
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=floating_from_chars.lo -fimplicit-templates -isystem
/d/Works/xcomp/sysroot/h8300-elf/include -mn -c -o floating_from_chars.lo
../../../../../../gcc-12.2.0/libstdc++-v3/src/c++17/floating_from_chars.cc
libtool: compile: /d/Works/xcomp/gcc-build/./gcc/xgcc -shared-libgcc
-B/d/Works/xcomp/gcc-build/./gcc -nostdinc++
-L/d/Works/xcomp/gcc-build/h8300-elf/normal/libstdc++-v3/src
-L/d/Works/xcomp/gcc-build/h8300-elf/normal/libstdc++-v3/src/.libs
-L/d/Works/xcomp/gcc-build/h8300-elf/normal/libstdc++-v3/libsupc++/.libs
-B/usr/local/h8300-elf/bin/ -B/usr/local/h8300-elf/lib/ -isystem
/usr/local/h8300-elf/include -isystem /usr/local/h8300-elf/sys-include -mn
-I/d/Works/xcomp/gcc-12.2.0/libstdc++-v3/../libgcc
-I/d/Works/xcomp/gcc-build/h8300-elf/normal/libstdc++-v3/include/h8300-elf
-I/d/Works/xcomp/gcc-build/h8300-elf/normal/libstdc++-v3/include
-I/d/Works/xcomp/gcc-12.2.0/libstdc++-v3/libsupc++ -std=gnu++17 -nostdinc++
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=floating_from_chars.lo -fimplicit-templates -isystem
/d/Works/xcomp/sysroot/h8300-elf/include -mn -c
../../../../../../gcc-12.2.0/libstdc++-v3/src/c++17/floating_from_chars.cc -o
floating_from_chars.o
/bin/sh ../../libtool --tag CXX --tag disable-shared --mode=compile
/d/Works/xcomp/gcc-build/./gcc/xgcc -shared-libgcc
-B/d/Works/xcomp/gcc-build/./gcc -nostdinc++
-L/d/Works/xcomp/gcc-build/h8300-elf/normal/libstdc++-v3/src
-L/d/Works/xcomp/gcc-build/h8300-elf/normal/libstdc++-v3/src/.libs
-L/d/Works/xcomp/gcc-build/h8300-elf/normal/libstdc++-v3/libsupc++/.libs
-B/usr/local/h8300-elf/bin/ -B/usr/local/h8300-elf/lib/ -isystem
/usr/local/h8300-elf/include -isystem /usr/local/h8300-elf/sys-include -mn
-I/d/Works/xcomp/gcc-12.2.0/libstdc++-v3/../libgcc
-I/d/Works/xcomp/gcc-build/h8300-elf/normal/libstdc++-v3/include/h8300-elf
-I/d/Works/xcomp/gcc-build/h8300-elf/normal/libstdc++-v3/include
-I/d/Works/xcomp/gcc-12.2.0/libstdc++-v3/libsupc++ -std=gnu++17 -nostdinc++
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=floating_to_chars.lo -fimplicit-templates -isystem
/d/Works/xcomp/sysroot/h8300-elf/include -mn -c -o floating_to_chars.lo
../../../../../../gcc-12.2.0/libstdc++-v3/src/c++17/floating_to_chars.cc
libtool: compile: /d/Works/xcomp/gcc-build/./gcc/xgcc -shared-libgcc
-B/d/Works/xcomp/gcc-build/./gcc -nostdinc++
-L/d/Works/xcomp/gcc-build/h8300-elf/normal/libstdc++-v3/src
-L/d/Works/xcomp/gcc-build/h8300-elf/normal/libstdc++-v3/src/.libs
-L/d/Works/xcomp/gcc-build/h8300-elf/normal/libstdc++-v3/libsupc++/.libs
-B/usr/local/h8300-elf/bin/ -B/usr/local/h8300-elf/lib/ -isystem
/usr/local/h8300-elf/include -isystem /usr/local/h8300-elf/sys-include -mn
-I/d/Works/xcomp/gcc-12.2.0/libstdc++-v3/../libgcc
-I/d/Works/xcomp/gcc-build/h8300-elf/normal/libstdc++-v3/include/h8300-elf
-I/d/Works/xcomp/gcc-build/h8300-elf/normal/libstdc++-v3/include
-I/d/Works/xcomp/gcc-12.2.0/libstdc++-v3/libsupc++ -std=gnu++17 -nostdinc++
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=floating_to_chars.lo -fimplicit-templates -isystem
/d/Works/xcomp/sysroot/h8300-elf/include -mn -c
../../../../../../gcc-12.2.0/libstdc++-v3/src/c++17/floating_to_chars.cc -o
floating_to_chars.o
/bin/sh ../../libtool --tag
[Bug testsuite/107830] New: [13 Regression] ICE in gen_aarch64_bitmask_udiv3, at ./insn-opinit.h:813
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107830
Bug ID: 107830
Summary: [13 Regression] ICE in gen_aarch64_bitmask_udiv3, at
./insn-opinit.h:813
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, openmp
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: aarch64-linux-gnu
gcc 13.0.0 20221120 snapshot (g:a16a5460447eaaff0b4468064e4d7b1cc8fc42eb) ICEs
when compiling the following testcase, reduced from
libgomp/testsuite/libgomp.c-c++-common/for-15.c, w/ -march=armv9-a -Os
-fopenmp:
void
f2 (int *a)
{
unsigned int i;
#pragma omp simd
for (i = 0; i < 4; ++i)
a[i / 3] -= 4;
}
% aarch64-linux-gnu-gcc-13 -march=armv9-a -Os -fopenmp -c t3uokd3k.c
during RTL pass: expand
t3uokd3k.c: In function 'f2':
t3uokd3k.c:8:9: internal compiler error: in gen_aarch64_bitmask_udiv3, at
./insn-opinit.h:813
8 | a[i / 3] -= 4;
| ~~^~~
0x7e5c72 gen_aarch64_bitmask_udiv3(machine_mode, rtx_def*, rtx_def*, rtx_def*)
./insn-opinit.h:813
0x7e5c72 gen_aarch64_bitmask_udiv3(machine_mode, rtx_def*, rtx_def*, rtx_def*)
./insn-opinit.h:810
0x7e5c72 aarch64_vectorize_can_special_div_by_constant(tree_code, tree_node*,
generic_wide_int, rtx_def**, rtx_def*, rtx_def*)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221120/work/gcc-13-20221120/gcc/config/aarch64/aarch64.cc:24339
0xb26cca expand_divmod(int, tree_code, machine_mode, tree_node*, tree_node*,
rtx_def*, rtx_def*, rtx_def*, int, optab_methods)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221120/work/gcc-13-20221120/gcc/expmed.cc:4383
0xb2a706 expand_expr_divmod
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221120/work/gcc-13-20221120/gcc/expr.cc:9198
0xb349ab expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221120/work/gcc-13-20221120/gcc/expr.cc:9868
0xa0eac0 expand_gimple_stmt_1
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221120/work/gcc-13-20221120/gcc/cfgexpand.cc:3983
0xa0eac0 expand_gimple_stmt
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221120/work/gcc-13-20221120/gcc/cfgexpand.cc:4044
0xa14e2e expand_gimple_basic_block
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221120/work/gcc-13-20221120/gcc/cfgexpand.cc:6096
0xa16817 execute
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221120/work/gcc-13-20221120/gcc/cfgexpand.cc:6822
[Bug tree-optimization/107699] [12/13 Regression] False positive -Warray-bounds, non-existent offset reported by GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107699 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #3 from Hans-Peter Nilsson --- (In reply to Carlos Galvez from comment #2) > Since the __last iterator cannot be known at compile time, this "if" branch > must be generated by the compiler. But then std::sort has hardcoded this > _S_threshold = 16, and computes a pointer __first + 16, which is known to be > OOB. > > The question is: should the compiler *really* warn in this type of code, in > -Wall, which is the bare-minimum warning level for all projects? All analysis of the actual test-case aside, from the setting of "NEW" and "last confirmed" of the bugzilla entry, the answer is clearly "no". ;-) I'm not sure it happened this time, but sometimes reporters misinterpret gcc-folks comments about the bug, to be comments related to the validity of their test-case, when it's about what gcc did wrong.
[Bug c++/97665] constexpr union array member incorrectly rejected as non-constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97665 Jiang An changed: What|Removed |Added CC||de34 at live dot cn --- Comment #11 from Jiang An --- This looks like CWG issue 2558 (currently unresolved). https://cplusplus.github.io/CWG/issues/2558.html
[Bug lto/107829] New: Trivial compile time tracking code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107829 Bug ID: 107829 Summary: Trivial compile time tracking code Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: fxue at os dot amperecomputing.com CC: marxin at gcc dot gnu.org Target Milestone: --- In the function "materialize_cgraph" of lto.cc: /* Start the appropriate timer depending on the mode that we are operating in. */ lto_timer = (flag_wpa) ? TV_WHOPR_WPA : (flag_ltrans) ? TV_WHOPR_LTRANS : TV_LTO; timevar_push (lto_timer); current_function_decl = NULL; set_cfun (NULL); if (!quiet_flag) fprintf (stderr, "\n"); timevar_pop (lto_timer); Execution of code enclosed by time-variable "lto_timer" is expected to be of zero time. Adding time tracking here seems to be superfluous.
[Bug tree-optimization/107828] New: tree-inlining would generate SSA with incorrect def stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107828
Bug ID: 107828
Summary: tree-inlining would generate SSA with incorrect def
stmt
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: fxue at os dot amperecomputing.com
Target Milestone: ---
In the function "remap_gimple_op_r" of tree-inlining.cc:
...
if (TREE_CODE (*tp) == SSA_NAME)
{
*tp = remap_ssa_name (*tp, id);
*walk_subtrees = 0;
if (is_lhs)
SSA_NAME_DEF_STMT (*tp) = wi_p->stmt;
return NULL;
}
The definition statement of original "*tp" may be same as wi_p->stmt. So, we
will end up with a statement that it is pointed by both old and new SSA name,
while the old one should have been reclaimed.
And this happens when some parameter needs to be adjusted during inline
versioning as:
remap_gimple_stmt()
{
...
if (id->param_body_adjs)
{
...
if (!gimple_seq_empty_p (extra_stmts))
{
memset (, 0, sizeof (wi));
wi.info = id;
for (gimple_stmt_iterator egsi = gsi_start (extra_stmts);
!gsi_end_p (egsi);
gsi_next ())
walk_gimple_op (gsi_stmt (egsi), remap_gimple_op_r, );
^
...
}
}
...
}
[Bug d/98058] libphobos: Support building on *-*-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98058 Sergey Fedorov changed: What|Removed |Added CC||vital.had at gmail dot com --- Comment #2 from Sergey Fedorov --- What is the current status of libphobos on powerpc*-apple-darwin?
[Bug c/107405] [13 Regression] enum change causing Linux kernel to fail to build due to Linux depending on old behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107405 --- Comment #19 from joseph at codesourcery dot com --- On Tue, 22 Nov 2022, macro at orcam dot me.uk via Gcc-bugs wrote: > Well, according to the assertion triggered `typeof (EM_MAX_SLOTS)' will > yield a data type of a different width depending on the compiler version. I don't think typeof(expression) should really be considered part of the ABI. Technically, yes, someone could declare a variable in a header as "extern typeof (EM_MAX_SLOTS) x;", and then the ABI for that variable would change. What hasn't changed is the normal case - where the variable is declared as "extern enum whatever_the_tag_is x;" - the size of the enum type itself is the same as what it was before.
[Bug analyzer/107788] [13 Regression] ICE in wide_int_to_tree_1, at tree.cc:1757 since r13-4074-g86a90006864840c2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107788 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from David Malcolm --- (In reply to David Malcolm from comment #4) > That said, the known_function machinery is erroneously deciding to use the > "bind" handling even for std::bind, so keeping this open to track only doing > it for names in the root namespace. Fixed by the commit in comment #5. Marking this as resolved.
[Bug analyzer/107783] [13 Regression] ICE in deref_rvalue, at analyzer/region-model.cc:3238 since r13-4074-g86a90006864840c2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107783 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #6 from David Malcolm --- I found another ICE with the new "bind"-handling code, which I fixed in the above commit. Marking this as resolved. If you're still running into issues with the "bind"-handling code, please open separate bugs for them. Thanks!
[Bug analyzer/107807] gcc.dg/analyzer/errno-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107807 David Malcolm changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #5 from David Malcolm --- Did the above patch fix things?
[Bug analyzer/107788] [13 Regression] ICE in wide_int_to_tree_1, at tree.cc:1757 since r13-4074-g86a90006864840c2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107788 --- Comment #5 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:ec7c796de020cb5cd955aa5b26c92b1da49d6076 commit r13-4249-gec7c796de020cb5cd955aa5b26c92b1da49d6076 Author: David Malcolm Date: Tue Nov 22 17:29:21 2022 -0500 analyzer: only look for named functions in root ns [PR107788] gcc/analyzer/ChangeLog: PR analyzer/107788 * known-function-manager.cc (known_function_manager::get_match): Don't look up fndecls by name when they're not in the root namespace. gcc/testsuite/ChangeLog: PR analyzer/107788 * g++.dg/analyzer/named-functions.C: New test. Signed-off-by: David Malcolm
[Bug analyzer/107807] gcc.dg/analyzer/errno-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107807 --- Comment #4 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:7c9717fcb5cf94ce1e7ef5c903058adf9980ff28 commit r13-4247-g7c9717fcb5cf94ce1e7ef5c903058adf9980ff28 Author: David Malcolm Date: Tue Nov 22 17:29:21 2022 -0500 analyzer: fix 'errno' on Solaris and OS X [PR107807] gcc/analyzer/ChangeLog: PR analyzer/107807 * region-model-impl-calls.cc (register_known_functions): Register "___errno" and "__error" as synonyms for "__errno_location". gcc/testsuite/ChangeLog: PR analyzer/107807 * gcc.dg/analyzer/errno-___errno.c: New test. * gcc.dg/analyzer/errno-__error.c: New test. * gcc.dg/analyzer/errno-global-var.c: New test. Signed-off-by: David Malcolm
[Bug analyzer/107783] [13 Regression] ICE in deref_rvalue, at analyzer/region-model.cc:3238 since r13-4074-g86a90006864840c2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107783 --- Comment #5 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:64fb291c5839e1a82afb62743172b4eab1267399 commit r13-4248-g64fb291c5839e1a82afb62743172b4eab1267399 Author: David Malcolm Date: Tue Nov 22 17:29:21 2022 -0500 analyzer: fix ICE on 'bind(INT_CST, ...)' [PR107783] This was crashing inside fd_phase_mismatch's ctor with assertion failure when the state was "fd-constant". Fix the ICE by not complaining about constants passed to these APIs. gcc/analyzer/ChangeLog: PR analyzer/107783 * sm-fd.cc (fd_state_machine::check_for_new_socket_fd): Don't complain when old state is "fd-constant". (fd_state_machine::on_listen): Likewise. (fd_state_machine::on_accept): Likewise. gcc/testsuite/ChangeLog: PR analyzer/107783 * gcc.dg/analyzer/fd-accept.c (test_accept_on_constant): New. * gcc.dg/analyzer/fd-bind.c (test_bind_on_constant): New. * gcc.dg/analyzer/fd-connect.c (test_connect_on_constant): New. * gcc.dg/analyzer/fd-listen.c (test_listen_on_connected_socket): Fix typo. (test_listen_on_constant): New. Signed-off-by: David Malcolm
[Bug target/107827] switch table compression could shrink large tables (but missing), testcase cerf-lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107827 --- Comment #5 from Alexander Kleinsorge --- And what about linear equation for same-sized cases (each case has same code-size). Which should be possible in Case 1 (I think).
[Bug target/107827] switch table compression could shrink large tables (but missing), testcase cerf-lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107827 --- Comment #4 from Alexander Kleinsorge --- (In reply to Andrew Pinski from comment #2) > x86_64 target does not dojump table compression at all. > But aarch64 and arm targets do: > .L4: > .2byte (.L103 - .Lrtx4) / 4 > .2byte (.L102 - .Lrtx4) / 4 > .2byte (.L101 - .Lrtx4) / 4 > .2byte (.L100 - .Lrtx4) / 4 > .2byte (.L99 - .Lrtx4) / 4 > .2byte (.L98 - .Lrtx4) / 4 > .2byte (.L97 - .Lrtx4) / 4 > .2byte (.L96 - .Lrtx4) / 4 > .2byte (.L95 - .Lrtx4) / 4 > > > Confirmed. Note the /4 can't be done for x86 but the rest I think can be > done. The /4 can't be done because some instructions one byte in length on > x86_64. I think by inserting 1 byte NOPs should be possible to get jump-point-alignment https://www.felixcloutier.com/x86/nop So the other 1 byte ops could be filled up for alignment.
[Bug target/107827] switch table compression could shrink large tables (but missing), testcase cerf-lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107827 --- Comment #3 from Andrew Pinski --- Interesting how clang does not do it either for x86_64 but does it also for aarch64 ...
[Bug target/107827] switch table compression could shrink large tables (but missing), testcase cerf-lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107827 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Component|c |target Target||x86_64-*-* Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-11-22 --- Comment #2 from Andrew Pinski --- x86_64 target does not dojump table compression at all. But aarch64 and arm targets do: .L4: .2byte (.L103 - .Lrtx4) / 4 .2byte (.L102 - .Lrtx4) / 4 .2byte (.L101 - .Lrtx4) / 4 .2byte (.L100 - .Lrtx4) / 4 .2byte (.L99 - .Lrtx4) / 4 .2byte (.L98 - .Lrtx4) / 4 .2byte (.L97 - .Lrtx4) / 4 .2byte (.L96 - .Lrtx4) / 4 .2byte (.L95 - .Lrtx4) / 4 Confirmed. Note the /4 can't be done for x86 but the rest I think can be done. The /4 can't be done because some instructions one byte in length on x86_64.
[Bug fortran/107577] [13 Regression] ICE in find_array_spec, at fortran/resolve.cc:5008 since r13-1757-gf838d15641d256e2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107577 --- Comment #3 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2022-November/058549.html
[Bug libstdc++/106201] filesystem::directory_iterator is a borrowable range?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106201 --- Comment #12 from CVS Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:477b3f9d58589b3af7a5a7d038d78352ad66406e commit r12-8927-g477b3f9d58589b3af7a5a7d038d78352ad66406e Author: Jonathan Wakely Date: Tue Nov 22 18:15:56 2022 + libstdc++: Add workaround for fs::path constraint recursion [PR106201] This works around a compiler bug where overload resolution attempts implicit conversion to path in order to call a function with a path& parameter. Such conversion would produce a prvalue, which would not be able to bind to the lvalue reference anyway. Attempting to check the conversion causes a constraint recursion because the arguments to the path constructor are checked to see if they're iterators, which checks if they're swappable, which tries to use the swap function that triggered the conversion in the first place. This replaces the swap function with an abbreviated function template that is constrained with same_as auto& so that the invalid conversion is never considered. libstdc++-v3/ChangeLog: PR libstdc++/106201 * include/bits/fs_path.h (filesystem::swap(path&, path&)): Replace with abbreviated function template. * include/experimental/bits/fs_path.h (filesystem::swap): Likewise. * testsuite/27_io/filesystem/iterators/106201.cc: New test. * testsuite/experimental/filesystem/iterators/106201.cc: New test.
[Bug c/107827] switch table compression could shrink large tables (but missing), testcase cerf-lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107827 --- Comment #1 from Andrew Pinski --- Created attachment 53950 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53950=edit testcase
[Bug libstdc++/107814] [13 regression] experimental/filesystem/iterators/error_reporting.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107814 --- Comment #2 from Jonathan Wakely --- Created attachment 53949 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53949=edit Fix unsafe use of dirent::d_name I'm unable to access the Solaris/x86 host in the compile farm (gcc210) so I can't test if this fixes it. It passes on Solaris/sparc.
[Bug c/107827] New: switch table compression could shrink large tables (but missing), testcase cerf-lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107827
Bug ID: 107827
Summary: switch table compression could shrink large tables
(but missing), testcase cerf-lib
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: aleks at physik dot tu-berlin.de
Target Milestone: ---
The cerf-lib (self-contained numeric library that provides an efficient and
accurate implementation of complex error functions) contains 2 switch-blocks
having about 100 entries. Each entry represents a piece-wise
taylor-polynomial-approximation (aiming nearly machine precision, type double).
https://jugit.fz-juelich.de/mlz/libcerf/-/tree/main/lib
Compiler Explorer (selected -O3 for x86-64-gcc-12) https://godbolt.org/
shows ASM output having huge jump-tables. Even code compiles fine on my PC with
gcc11, you have to shrink to 20 cases in Compiler-Explorer to see result (some
webservice limit, but this is not the issue here). Lets focus on 2 static
functions.
1. erfcx.c / static double erfcx_y100() / case (int) 0..99 (100 cases, no gap,
each case is a taylor-polynomial of grade 6). Gives Jump-Table of 100 x 8
bytes, plus code. The table could be easy compressed or replaced by linear
formula.
a) assumning no function ever exceeded 4 GB of code, it would be possible to
use only 4 byte offset (jumping-distance), and for 99% of funtions 65 KB range
would be enough (at least in O2 is makes sence, but also in O3 it could be
faster to decrease memory/cache usage - this could become a new option to
control it).
b) for this erfcx_y100-sample it would be even possible to calc the offset by
formula.
c) of course the parameters could be a separate lookup-table, but no speedup
for other reasons (I tried these days). gcc could detect the similarity
(idential cases beside the 7 hard-coded coefficients) which would be antother
change request..
sample (I cutted the coefficients numbers for readability)
switch ((int) y100) {
case 0: {
double t = 2*y100 - 1;
return 0.7 + (0.7 + (0.3 + (0.1 + (0.8 + (0.3 + 0.1 * t) *t) *t) *t) *t)
*t;
}
case 1: {
double t = 2*y100 - 3;
return 0.2 + (0.7 + (0.3 + (0.1 + (0.8 + (0.3 + 0.1 *t) *t) *t) *t) *t) *t;
}
.. until case 99:
// instead 8 x 100 byte table it could be 2 x 100 byte, or 10 byte linear
equation.
2. im_w_of_x.c / static double w_im_y100() / case (int) 0..96 (97 cases, no
gap, similar polynomials between 6th to 8th grade, plus another unique final
formula). Here the code is (even neglecting the coefficients) not identical,
but still similar. Address-Offset-Compression could still be used (but not
linear all the way).
d) same as a) + b)
e) side note: " 2*y100 " seems no to be detected and calculated once at begin
of switch.
f) detection of similar code (same equation, different parameters) could be
used to decrease object-size (text) as only 4 kinds of equations are here, only
offset in some created "const double parameters[]"-array differs.
PS: no code is wrong or shows different results, this is a
ro-memory-consumption and timing issue only.
Thanks for reading.
[Bug libstdc++/107817] std/format/functions/format.cc etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107817 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- Native configuration is sparc-sun-solaris2.11 === libstdc++ tests === Schedule of variations: unix Running target unix Running /export/home/jwakely/src/gcc/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ... PASS: std/format/arguments/args.cc (test for excess errors) PASS: std/format/arguments/args.cc execution test PASS: std/format/error.cc (test for excess errors) PASS: std/format/error.cc execution test PASS: std/format/formatter/concept.cc (test for excess errors) PASS: std/format/formatter/requirements.cc (test for excess errors) PASS: std/format/formatter/requirements.cc execution test PASS: std/format/functions/format.cc (test for excess errors) PASS: std/format/functions/format.cc execution test PASS: std/format/functions/format_to_n.cc (test for excess errors) PASS: std/format/functions/format_to_n.cc execution test PASS: std/format/functions/size.cc (test for excess errors) PASS: std/format/functions/size.cc execution test PASS: std/format/functions/vformat_to.cc (test for excess errors) PASS: std/format/functions/vformat_to.cc execution test PASS: std/format/parse_ctx.cc (test for excess errors) PASS: std/format/parse_ctx.cc execution test PASS: std/format/string.cc (test for excess errors) PASS: std/format/string.cc execution test PASS: std/format/string_neg.cc (test for errors, line ) PASS: std/format/string_neg.cc (test for excess errors) === libstdc++ Summary === # of expected passes21
[Bug tree-optimization/107823] [13 Regression] Dead Code Elimination Regression at -Os (trunk vs. 12.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107823 Andrew Pinski changed: What|Removed |Added Summary|Dead Code Elimination |[13 Regression] Dead Code |Regression at -Os (trunk|Elimination Regression at |vs. 12.2.0) |-Os (trunk vs. 12.2.0) Target Milestone|--- |13.0
[Bug tree-optimization/107822] [13 Regression] Dead Code Elimination Regression at -Os (trunk vs. 12.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107822 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0 Summary|Dead Code Elimination |[13 Regression] Dead Code |Regression at -Os (trunk|Elimination Regression at |vs. 12.2.0) |-Os (trunk vs. 12.2.0)
[Bug analyzer/106473] [12/13 Regression] -Wanalyzer-malloc-leak false positive regression when returning heap-allocation through nested pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106473 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Summary|-Wanalyzer-malloc-leak |[12/13 Regression] |false positive regression |-Wanalyzer-malloc-leak |when returning |false positive regression |heap-allocation through |when returning |nested pointers |heap-allocation through ||nested pointers Last reconfirmed||2022-11-22 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from David Malcolm --- Thanks for filing this bug. Confirmed; am investigating.
[Bug fortran/107819] ICE in gfc_check_argument_var_dependency, at fortran/dependency.cc:978
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107819 --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #2) > Potential patch: This regtests ok. However, > Note that we get a (correct) warning for z1 after this fix: > > pr107819-z1.f90:4:10-16: > > 4 | call s (a(n), a) > | 2 1 > Warning: INTENT(OUT) actual argument at (1) might interfere with actual > argument at (2). this comes from gfc_check_argument_var_dependency, where we see the INTENT(OUT) argument a, we see a(n), and here 966 /* In case of elemental subroutines, there is no dependency 967 between two same-range array references. */ 968 if (gfc_ref_needs_temporary_p (expr->ref) 969 || gfc_check_dependency (var, expr, elemental == NOT_ELEMENTAL)) gfc_ref_needs_temporary_p (expr->ref) correctly returns true. The comment sort of does not fit to what happens: the "range" is the same, but n generates a permutation which is detected by gfc_ref_needs_temporary_p. But then no temporary is generated for a(n), which means we miss a corresponding check elsewhere. Could need help by some expert on this...
[Bug tree-optimization/107826] ice during GIMPLE pass: slp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107826 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=107766 --- Comment #1 from Andrew Pinski --- I suspect this is already fixed. See PR 107766 .
[Bug c/107826] New: ice during GIMPLE pass: slp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107826
Bug ID: 107826
Summary: ice during GIMPLE pass: slp
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For the following reduced C code, compiled as follows:
$ ~/gcc/results/bin/gcc -c -O2 -std=c99 bug864B.c
during GIMPLE pass: slp
bug864B.c:3:1: internal compiler error: Segmentation fault
3 | cpl_image_multiply_scalar_self() {
| ^~
0xd7e3a9 crash_signal(int)
../../trunk.d1/gcc/toplev.cc:314
0x105cabc contains_struct_check(tree_node*, tree_node_structure_enum, char
const
*, int, char const*)
../../trunk.d1/gcc/tree.h:3645
0x105cabc complex_mul_pattern::matches(_complex_operation, hash_map<_slp_tree*,
_complex_perm_kinds, simple_hashmap_traits,
_com
plex_perm_kinds> >*, hash_map,
nofree_ptr_h
ash<_slp_tree> >, bool,
simple_hashmap_traits, nofree_ptr_hash<_slp_tree> > >, bool> >*, _slp_tree**,
v
ec<_slp_tree*, va_heap, vl_ptr>*)
C code is:
enum { CPL_TYPE_FLOAT, CPL_TYPE_FLOAT_COMPLEX } __assert_fail;
cpl_image_multiply_scalar_nxy;
cpl_image_multiply_scalar_self() {
switch (cpl_image_get_type()) {
double *pio;
unsigned long i;
pio[i] *= 0;
case CPL_TYPE_FLOAT:
for (; cpl_image_multiply_scalar_nxy; i++)
pio[i] *= 0;
for (; cpl_image_multiply_scalar_nxy;)
case CPL_TYPE_FLOAT_COMPLEX: {
_Complex *pio = cpl_image_multiply_scalar_self;
_Complex cscalar = __assert_fail;
for (;; i++)
pio[i] *= cscalar;
}
}
}
The code seems to first go wrong sometime between git hash 2b2f2ee49a33419f
and 59cc4da605e5cb8e, a day later.
[Bug c/98487] ICE: tree check: expected identifier_node, have tree_list in is_attribute_p, at attribs.h:155 [C2X or C++11 attribute syntax, gnu::format and -Wsuggest-attribute=format] or a suggest wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98487 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org
[Bug fortran/107819] ICE in gfc_check_argument_var_dependency, at fortran/dependency.cc:978
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107819
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-11-22
Keywords||ice-on-invalid-code,
||ice-on-valid-code
Ever confirmed|0 |1
CC||anlauf at gcc dot gnu.org
--- Comment #2 from anlauf at gcc dot gnu.org ---
Confirmed.
Potential patch:
diff --git a/gcc/fortran/trans-stmt.cc b/gcc/fortran/trans-stmt.cc
index fd6d294147e..b288f1f9050 100644
--- a/gcc/fortran/trans-stmt.cc
+++ b/gcc/fortran/trans-stmt.cc
@@ -264,6 +264,7 @@ gfc_conv_elemental_dependencies (gfc_se * se, gfc_se *
loopse,
if (e->expr_type == EXPR_VARIABLE
&& e->rank && fsym
&& fsym->attr.intent != INTENT_IN
+ && !fsym->attr.value
&& gfc_check_fncall_dependency (e, fsym->attr.intent,
sym, arg0, check_variable))
{
Note that we get a (correct) warning for z1 after this fix:
pr107819-z1.f90:4:10-16:
4 | call s (a(n), a)
| 2 1
Warning: INTENT(OUT) actual argument at (1) might interfere with actual
argument at (2).
[Bug c/98487] ICE: tree check: expected identifier_node, have tree_list in is_attribute_p, at attribs.h:155 [C2X or C++11 attribute syntax, gnu::format and -Wsuggest-attribute=format] or a suggest wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98487 --- Comment #5 from Andrew Pinski --- I should note this happens with both front-ends too. though the code is shared here.
[Bug fortran/107820] ICE in match_mult_operand, at fortran/matchexp.cc:296
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107820 anlauf at gcc dot gnu.org changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=107721 Status|UNCONFIRMED |NEW CC||anlauf at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2022-11-22 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. I think this is a dup of pr107721 (lost typespec).
[Bug c/98487] ICE: tree check: expected identifier_node, have tree_list in is_attribute_p, at attribs.h:155 [C2X attribute syntax, gnu::format and -Wsuggest-attribute=format]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98487 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic --- Comment #4 from Andrew Pinski --- Without checking enabled, we get a suggest warning too which is wrong.
[Bug c/107802] -Wsuggest-attribute=format ignores [[gnu::format(...)]]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107802 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Andrew Pinski --- Dup of bug 98487. *** This bug has been marked as a duplicate of bug 98487 ***
[Bug c/98487] ICE: tree check: expected identifier_node, have tree_list in is_attribute_p, at attribs.h:155 [C2X attribute syntax, gnu::format and -Wsuggest-attribute=format]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98487 Andrew Pinski changed: What|Removed |Added CC||adam.f.badura at gmail dot com --- Comment #3 from Andrew Pinski --- *** Bug 107802 has been marked as a duplicate of this bug. ***
[Bug c++/105593] avx512 math function raises uninitialized variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593 Andrew Pinski changed: What|Removed |Added CC||bill.trost at harmonicinc dot com --- Comment #7 from Andrew Pinski --- *** Bug 107825 has been marked as a duplicate of this bug. ***
[Bug c++/107825] uninitialized variable warning in avx512fintrin.h with skylake architecture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107825 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup of bug 105593. *** This bug has been marked as a duplicate of bug 105593 ***
[Bug c/107802] -Wsuggest-attribute=format ignores [[gnu::format(...)]]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107802
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c++ |c
Keywords||ice-checking,
||ice-on-valid-code
Last reconfirmed||2022-11-22
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
Well Looks like it ICEs on the trunk with -Wsuggest-attribute=format -W -Wall :
```
#include
#include
#include
[[gnu::format(printf, 1, 2)]]
void raise(
const char* assertionMessage,
...)
{
va_list args;
va_start(args, assertionMessage);
vfprintf(stderr, assertionMessage, args);
va_end(args);
abort();
}
void f(void)
{
raise("%s", 1223);
}
```
With both the C and C++ front-ends.
Confirmed.
[Bug tree-optimization/105616] Using regex_replace throws "maybe-uninitialized" warnings with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105616 Jonathan Wakely changed: What|Removed |Added CC||bill.trost at harmonicinc dot com --- Comment #4 from Jonathan Wakely --- *** Bug 107824 has been marked as a duplicate of this bug. ***
[Bug c++/107824] maybe-uninitialized variable in std::function ctor with -Wall -fsanitize=address when constructing a regex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107824 Jonathan Wakely changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jonathan Wakely --- dup *** This bug has been marked as a duplicate of bug 105616 ***
[Bug c++/107825] uninitialized variable warning in immintrin.h with skylake architecture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107825 Bill T. changed: What|Removed |Added URL||https://godbolt.org/z/h8v1j ||4Gac CC||bill.trost at harmonicinc dot com --- Comment #1 from Bill T. --- Weirdly, the program seems to compile fine if C is used rather than C++.
[Bug c++/107825] New: uninitialized variable warning in immintrin.h with skylake architecture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107825
Bug ID: 107825
Summary: uninitialized variable warning in immintrin.h with
skylake architecture
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bill.trost at harmonicinc dot com
Target Milestone: ---
Created attachment 53948
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53948=edit
Error mesages generated by compiling the program using the indicated flags
The following program generates warnings about uninitialized parameters in
avx512fintrin.h.
#include
__m512 f(__m512i a)
{
return _mm512_cvtepi32_ps(a);
}
// Compiler used: x86-64 gcc 12.2
// Options used: -O3 -Wall -Werror -march=skylake-avx512
Warnings are attached, but in summary, the value _mm512_undefined_ps() passed
to __builtin_ia32_cvtdq2ps512_mask is deliberately uninitialized.
[Bug fortran/107821] ICE in gfc_conv_scalarized_array_ref, at fortran/trans-array.cc:3723
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107821 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Last reconfirmed||2022-11-22 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. Note that I also get an ICE on z0.f90 with gcc <= 12. So we already got slightly better...
[Bug bootstrap/107722] [13 Regression] Bootstrap failure for some locales starting with r13-4070
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107722 --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #3) > Created attachment 53942 [details] > gcc13-pr107722.patch > > So like this? Yes, this patch makes the compile succeed with my locale.
[Bug c++/107824] New: maybe-uninitialized variable in std::function ctor with -Wall -fsanitize=address when constructing a regex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107824
Bug ID: 107824
Summary: maybe-uninitialized variable in std::function ctor
with -Wall -fsanitize=address when constructing a
regex
Product: gcc
Version: 12.2.0
URL: https://godbolt.org/z/Phs5rM4xn
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bill.trost at harmonicinc dot com
Target Milestone: ---
Target: x86-64
Created attachment 53947
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53947=edit
error messages when compiling the program
The code below generates several warning messages when compiled with -Wall and
-fsanitize=address. Without the sanitizer, the code compiles fine.
#include
void f()
{
std::regex r("");
}
// Options used: -O3 -Wall -Werror -fsanitize=address -std=gnu++2a
// Compiler used: x86-64 gcc 12.2
Warning messages are attached.
[Bug libstdc++/107817] std/format/functions/format.cc etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107817 --- Comment #3 from Jonathan Wakely --- This should be fixed now. I'm doing a Solaris build to check.
[Bug tree-optimization/107823] New: Dead Code Elimination Regression at -Os (trunk vs. 12.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107823
Bug ID: 107823
Summary: Dead Code Elimination Regression at -Os (trunk vs.
12.2.0)
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 53946
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53946=edit
Code
cat case.c #230633
int a;
void bar64_(void);
void foo();
int main() {
char b = a = 6;
for (; a; a = 0) {
bar64_();
b = 0;
}
if (b <= 0)
;
else
foo();
}
`gcc-e4faee8d02ec5d65bf418612f7181823eb08c078 (trunk) -Os` can not eliminate
`foo` but `gcc-releases/gcc-12.2.0 -Os` can.
`gcc-e4faee8d02ec5d65bf418612f7181823eb08c078 (trunk) -Os -S -o /dev/stdout
case.c`
- OUTPUT -
main:
.LFB0:
.cfi_startproc
pushq %rcx
.cfi_def_cfa_offset 16
movl$6, %eax
movb$6, %dl
.L2:
movl%eax, a(%rip)
testl %eax, %eax
je .L10
callbar64_
xorl%eax, %eax
xorl%edx, %edx
jmp .L2
.L10:
testb %dl, %dl
je .L4
callfoo
.L4:
xorl%eax, %eax
popq%rdx
.cfi_def_cfa_offset 8
ret
-- END OUTPUT -
`gcc-releases/gcc-12.2.0 -Os -S -o /dev/stdout case.c`
- OUTPUT -
main:
.LFB0:
.cfi_startproc
pushq %rax
.cfi_def_cfa_offset 16
movl$6, a(%rip)
callbar64_
xorl%edx, %edx
xorl%eax, %eax
movl%edx, a(%rip)
popq%rcx
.cfi_def_cfa_offset 8
ret
-- END OUTPUT -
Bisects to:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=353fd1ec3df92fbe66ce1513c5a86bdd5c5e22d1
[Bug libstdc++/107817] std/format/functions/format.cc etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107817 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:dfc1ea414e0cebccfcffc771ebcefa3d24c9754c commit r13-4243-gdfc1ea414e0cebccfcffc771ebcefa3d24c9754c Author: Jonathan Wakely Date: Tue Nov 22 17:39:43 2022 + libstdc++: Replace std::isdigit and std::isxdigit in [PR107817] These functions aren't usable in constant expressions. Provide our own implementations, based on __from_chars_alnum_to_val from . libstdc++-v3/ChangeLog: PR libstdc++/107817 * include/std/charconv (__from_chars_alnum_to_val): Add constexpr for C++20. * include/std/format (__is_digit, __is_xdigit): New functions. (_Spec::_S_parse_width_or_precision): Use __is_digit. (__formatter_fp::parse): Use __is_xdigit.
[Bug libstdc++/106201] filesystem::directory_iterator is a borrowable range?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106201 --- Comment #11 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:6b859736bb1e707778627b2e58ef6088e475a54c commit r13-4242-g6b859736bb1e707778627b2e58ef6088e475a54c Author: Jonathan Wakely Date: Tue Nov 22 12:17:27 2022 + libstdc++: Add testcase for fs::path constraint recursion [PR106201] libstdc++-v3/ChangeLog: PR libstdc++/106201 * testsuite/27_io/filesystem/iterators/106201.cc: New test.
[Bug tree-optimization/107822] New: Dead Code Elimination Regression at -Os (trunk vs. 12.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107822
Bug ID: 107822
Summary: Dead Code Elimination Regression at -Os (trunk vs.
12.2.0)
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 53945
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53945=edit
Code
cat case.c #230636
int b;
void foo();
void(a)();
int main() {
int c;
int *d =
*d = a && 8;
b = 0;
for (; b < 9; ++b)
*d ^= 3;
if (*d)
;
else
foo();
}
`gcc-e4faee8d02ec5d65bf418612f7181823eb08c078 (trunk) -Os` can not eliminate
`foo` but `gcc-releases/gcc-12.2.0 -Os` can.
`gcc-e4faee8d02ec5d65bf418612f7181823eb08c078 (trunk) -Os -S -o /dev/stdout
case.c`
- OUTPUT -
main:
.LFB0:
.cfi_startproc
movl$10, %edx
xorl%ecx, %ecx
movl$1, %eax
.L2:
decl%edx
je .L12
xorl$3, %eax
movb$1, %cl
jmp .L2
.L12:
testb %cl, %cl
jne .L4
xorl%esi, %esi
movl%esi, b(%rip)
jmp .L5
.L4:
movl$9, b(%rip)
.L5:
testl %eax, %eax
jne .L8
pushq %rdx
.cfi_def_cfa_offset 16
callfoo
xorl%eax, %eax
popq%rcx
.cfi_def_cfa_offset 8
ret
.L8:
xorl%eax, %eax
ret
-- END OUTPUT -
`gcc-releases/gcc-12.2.0 -Os -S -o /dev/stdout case.c`
- OUTPUT -
main:
.LFB0:
.cfi_startproc
movl$9, b(%rip)
xorl%eax, %eax
ret
-- END OUTPUT -
Bisects to:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e7310e24b1c0ca67b1bb507c1330b2bf39e59e32
[Bug fortran/107821] New: ICE in gfc_conv_scalarized_array_ref, at fortran/trans-array.cc:3723
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107821 Bug ID: 107821 Summary: ICE in gfc_conv_scalarized_array_ref, at fortran/trans-array.cc:3723 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 : $ cat z1.f90 program p associate (a => 1) print *, [character((a(1))) :: '1'] end associate end $ cat z2.f90 program p associate (a => 1) print *, [character((a((1 :: '1'] end associate end $ cat z3.f90 program p associate (a => 1) print *, [character(((a(1 :: '1'] end associate end $ cat z0.f90 program p associate (a => 1) print *, [character(a(1)) :: '1'] end associate end $ gfortran-13-20221120 -c z0.f90 z0.f90:3:26: 3 | print *, [character(a(1)) :: '1'] | 1 Error: Scalar INTEGER expression expected at (1) $ gfortran-13-20221120 -c z1.f90 z1.f90:3:41: 3 | print *, [character((a(1))) :: '1'] | 1 internal compiler error: Segmentation fault 0xda0f4f crash_signal ../../gcc/toplev.cc:314 0x87e95a gfc_conv_scalarized_array_ref ../../gcc/fortran/trans-array.cc:3723 0x87f45e gfc_conv_array_ref(gfc_se*, gfc_array_ref*, gfc_expr*, locus*) ../../gcc/fortran/trans-array.cc:3879 0x8ae66e gfc_conv_variable ../../gcc/fortran/trans-expr.cc:3104 0x8aa9ea gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.cc:9469 0x8aaaf6 gfc_conv_expr_op ../../gcc/fortran/trans-expr.cc:3782 0x8aaaf6 gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.cc:9457 0x8ad813 gfc_conv_expr_val(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.cc:9514 0x8ad960 gfc_conv_expr_type(gfc_se*, gfc_expr*, tree_node*) ../../gcc/fortran/trans-expr.cc:9528 0x887e0f trans_array_constructor ../../gcc/fortran/trans-array.cc:2783 0x887e0f gfc_add_loop_ss_code ../../gcc/fortran/trans-array.cc:3181 0x8880f5 gfc_conv_loop_setup(gfc_loopinfo*, locus*) ../../gcc/fortran/trans-array.cc:5478 0x8ddd45 gfc_trans_transfer(gfc_code*) ../../gcc/fortran/trans-io.cc:2671 0x879a37 trans_code ../../gcc/fortran/trans.cc:2170 0x8db6ce build_dt ../../gcc/fortran/trans-io.cc:2051 0x879a17 trans_code ../../gcc/fortran/trans.cc:2142 0x8f71af gfc_trans_block_construct(gfc_code*) ../../gcc/fortran/trans-stmt.cc:2314 0x879917 trans_code ../../gcc/fortran/trans.cc:2046 0x8a2e1e gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.cc:7674 0x824fae translate_all_program_units ../../gcc/fortran/parse.cc:6696
[Bug fortran/107820] New: ICE in match_mult_operand, at fortran/matchexp.cc:296
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107820 Bug ID: 107820 Summary: ICE in match_mult_operand, at fortran/matchexp.cc:296 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 : $ cat z1.f90 program p print *, [real :: ([3])] ** 20 end $ cat z2.f90 program p print *, [real :: (3)] ** 20 print *, 3.0 ** 20 end $ gfortran-13-20221120 z2.f90 && ./a.out 3.48678451E+09 3.48678451E+09 $ gfortran-13-20221120 -c z1.f90 z1.f90:2:23: 2 |print *, [real :: ([3])] ** 20 | 1 Error: Result of exponentiation at (1) exceeds the range of INTEGER(4) f951: internal compiler error: Segmentation fault 0xf37d3f crash_signal ../../gcc/toplev.cc:314 0x83abfc match_mult_operand ../../gcc/fortran/matchexp.cc:296 0x83ad98 match_add_operand ../../gcc/fortran/matchexp.cc:356 0x83afec match_level_2 ../../gcc/fortran/matchexp.cc:480 0x83b142 match_level_3 ../../gcc/fortran/matchexp.cc:551 0x83b234 match_level_4 ../../gcc/fortran/matchexp.cc:599 0x83b234 match_and_operand ../../gcc/fortran/matchexp.cc:693 0x83b422 match_or_operand ../../gcc/fortran/matchexp.cc:722 0x83b4f2 match_equiv_operand ../../gcc/fortran/matchexp.cc:765 0x83b5c4 match_level_5 ../../gcc/fortran/matchexp.cc:811 0x83a991 gfc_match_expr(gfc_expr**) ../../gcc/fortran/matchexp.cc:870 0x822089 match_io_element ../../gcc/fortran/io.cc:3668 0x8249ba match_io_list ../../gcc/fortran/io.cc:3716 0x824dbe match_io ../../gcc/fortran/io.cc:4394 0x8288ba gfc_match_print() ../../gcc/fortran/io.cc:4450 0x85abf1 match_word ../../gcc/fortran/parse.cc:67 0x860853 decode_statement ../../gcc/fortran/parse.cc:539 0x860c8a next_free ../../gcc/fortran/parse.cc:1402 0x860c8a next_statement ../../gcc/fortran/parse.cc:1634 0x863414 parse_spec ../../gcc/fortran/parse.cc:4006
[Bug fortran/107819] ICE in gfc_check_argument_var_dependency, at fortran/dependency.cc:978
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107819 --- Comment #1 from G. Steinmetz --- Works here with explicitly enforced evaluation (a(n)) : $ cat z3.f90 program p integer :: a(4) = [-1, -2, -3, -4] integer :: n(4) = [4, 2, 1, 3] call s ((a(n)), a) print *, a contains elemental subroutine s (x, y) integer, value :: x integer, intent(out) :: y y = x end end $ cat z8.f90 program p implicit none integer, parameter :: m = 99 integer :: i integer :: a(m) = [(-i,i=1,m)] call s ((a(m:1:-1)), a) print '(10i6)', a contains elemental subroutine s (x, y) integer, value :: x integer, intent(out) :: y y = x end end $ cat z9.f90 program p implicit none integer, parameter :: m = 99 integer :: i integer :: a(m) = [(-i,i=1,m)] integer :: n(m) = [(i,i=m,1,-1)] call s ([a(n)], a) print '(10i6)', a contains elemental subroutine s (x, y) integer, value :: x integer, intent(out) :: y y = x end end $ gfortran-13-20221120 z3.f90 && ./a.out -4 -2 -1 -3 $
[Bug fortran/107819] New: ICE in gfc_check_argument_var_dependency, at fortran/dependency.cc:978
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107819 Bug ID: 107819 Summary: ICE in gfc_check_argument_var_dependency, at fortran/dependency.cc:978 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 : (presumably processor dependent) $ cat z1.f90 program p integer :: a(4) = [-1, -2, -3, -4] integer :: n(4) = [4, 2, 1, 3] call s (a(n), a) print *, a contains elemental subroutine s (x, y) integer, value :: x integer, intent(out) :: y y = x end end $ cat z2.f90 program p integer :: a(1) = [-1] integer :: n(1) = [1] call s (a(n), a) print *, a contains elemental subroutine s (x, y) integer, value :: x integer, intent(out) :: y y = x end end $ cat z6.f90 program p integer :: a(1) = [-1] integer :: n = 1 call s (a(n:n), a) print *, a contains elemental subroutine s (x, y) integer, value :: x integer, intent(out) :: y y = x end end $ cat z7.f90 program p implicit none integer, parameter :: m = 99 integer :: i integer :: a(m) = [(-i,i=1,m)] integer :: n(m) = [(i,i=m,1,-1)] call s (a(n), a) print *, a contains elemental subroutine s (x, y) integer, value :: x integer, intent(out) :: y y = x end end $ gfortran-13-20221120 -c z1.f90 z1.f90:4:19: 4 |call s (a(n), a) | 1 internal compiler error: in gfc_check_argument_var_dependency, at fortran/dependency.cc:978 0x8add39 gfc_check_argument_var_dependency ../../gcc/fortran/dependency.cc:978 0x8addcc gfc_check_argument_dependency ../../gcc/fortran/dependency.cc:1075 0x8addcc gfc_check_fncall_dependency(gfc_expr*, sym_intent, gfc_symbol*, gfc_actual_arglist*, gfc_dep_check) ../../gcc/fortran/dependency.cc:1120 0x9640b0 gfc_conv_elemental_dependencies ../../gcc/fortran/trans-stmt.cc:267 0x9640b0 gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool) ../../gcc/fortran/trans-stmt.cc:491 0x8be656 trans_code ../../gcc/fortran/trans.cc:2018 0x8f5379 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.cc:7674 0x86775e translate_all_program_units ../../gcc/fortran/parse.cc:6696 0x86775e gfc_parse_file() ../../gcc/fortran/parse.cc:7002 0x8b5a9f gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:229
[Bug ipa/107661] [13 Regression] lambdas get merged incorrectly in tempaltes, cause llvm-12 miscompilation since r13-3358-ge0403e95689af7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107661 Martin Jambor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #17 from Martin Jambor --- Fixed.
[Bug ipa/107661] [13 Regression] lambdas get merged incorrectly in tempaltes, cause llvm-12 miscompilation since r13-3358-ge0403e95689af7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107661 --- Comment #16 from CVS Commits --- The master branch has been updated by Martin Jambor : https://gcc.gnu.org/g:c4a92a9117a034e7cf291ae51d8b9b844fb5a88b commit r13-4238-gc4a92a9117a034e7cf291ae51d8b9b844fb5a88b Author: Martin Jambor Date: Tue Nov 22 18:22:03 2022 +0100 ipa-cp: Do not be too optimistic about self-recursive edges (PR 107661) PR 107661 shows that function push_agg_values_for_index_from_edge should not attempt to optimize self-recursive call graph edges when called from cgraph_edge_brings_all_agg_vals_for_node. Unlike when being called from find_aggregate_values_for_callers_subset, we cannot expect that any cloning for constants would lead to the edge leading from a new clone to the same new clone, in this case it would only be redirected to a new callee. Fixed by adding a parameter to push_agg_values_from_edge whether being optimistic about self-recursive edges is possible. gcc/ChangeLog: 2022-11-22 Martin Jambor PR ipa/107661 * ipa-cp.cc (push_agg_values_from_edge): New parameter optimize_self_recursion, use it to decide whether to pass interim to the helper function. (find_aggregate_values_for_callers_subset): Pass true in the new parameter of push_agg_values_from_edge. (cgraph_edge_brings_all_agg_vals_for_node): Pass false in the new parameter of push_agg_values_from_edge. gcc/testsuite/ChangeLog: 2022-11-22 Martin Jambor PR ipa/107661 * g++.dg/ipa/pr107661.C: New test.
[Bug libstdc++/107815] 20_util/to_chars/float128_c++23.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815 --- Comment #3 from Jakub Jelinek --- (In reply to r...@cebitec.uni-bielefeld.de from comment #2) > > --- Comment #1 from Jakub Jelinek --- > > Can you please uncomment the > > //std::cout << i << ' ' << std::string_view (str1, ptr1) << '\n'; > > and > > //std::cout << i << ' ' << std::string_view (str1, ptr5) << '\n'; > > lines in the test, so that it is clear at least which test it is on? > > Sure. This is supposed to print u, I assume ;-) Oops, sure. > > The line before the assertion failure is > > 1.18973e+4932 1e+4932 > /vol/gcc/src/hg/master/local/libstdc++-v3/testsuite/20_util/to_chars/ > float128_c++23.cc:66: void test(std::chars_format): Assertion 'ec2 == > std::errc() && ptr2 - str2 == ptr1 - str1' failed. > > i.e. LDBL_MAX. This is weird. If line 66 is reached, fmt must be std::chars_format::fixed and in that case ptr1 - str1 should be 4933 and str1 should be that many chars long string starting with 11897314953572317650857593266280070161964690526416940455296988842121635797553123923249740128484620735259020335647491268597552654335738044626726987519452614908534619587250212628458657994054044935746815 If you get just 1e+4932 when asked for fixed format, something is just wrong, that is scientific or general format. > > > If line 66 fails, it is a fixed printing test trying to verify > > that the string created by line 60 was actually the minimal. > > It doesn't now reliably: I compiled with -g3 -O0 to be able to check > things with gdb if needed. > > > On SPARC Solaris, I assume long double is IEEE quad, and it is the shortest > > version, so should use ryu library for both cases. > > It is, although only ever implemented in software. > > > Line 74 failure is about whether the created string can be read back, > > in that case for IEEE quad fast_float library can't be used and so it should > > use newlocale/uselocale/strtold/uselocale/freelocale, or if the OS doesn't > > support newlocale/uselocale/freelocale most likely just strtod with lost > > precision (so in that case the test would fail) on line 74. > > I'm not seeing the failure on l.74 any longer, even with the default > optimization options. There has been an effort to introduce an xpg7 > locale, but that had quite a number of unresolved issues (both on AIX > and Solaris) and was never finished. Currently, we're stuck with > generic.
[Bug libstdc++/107799] Wrong return type for std::bit_width
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107799 --- Comment #3 from Jonathan Wakely --- It will get updated.
[Bug libstdc++/107817] std/format/functions/format.cc etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107817 Jonathan Wakely changed: What|Removed |Added Target|*-*-solaris2.11,|*-*-solaris2.11, |x86_64-unknown-freebsd12.4, |x86_64-unknown-freebsd12.4, |powerpc64le-unknown-linux-g | |nu | --- Comment #1 from Jonathan Wakely --- (In reply to Rainer Orth from comment #0) > FreeBSD and (maybe, if that's not an older issue since > fixed) > Linux/powerpc64le are equally affected. Linux/powerpc64le was PR107720 and is unrelated to this.
[Bug libstdc++/107817] std/format/functions/format.cc etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107817 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Last reconfirmed||2022-11-22
[Bug libstdc++/107801] Building cross compiler for H8 family fails in libstdc++ (c++17/memory_resource.cc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107801 --- Comment #6 from Jonathan Wakely --- Understood, thanks. My commit message could have been worded more precisely, but none of that matters for the purposes of the fix. What matters is that there is at least one target with 16-bit int and 32-bit size_t, and after the commits above, that should be supported.
[Bug libstdc++/107801] Building cross compiler for H8 family fails in libstdc++ (c++17/memory_resource.cc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107801 --- Comment #5 from jdx at o2 dot pl --- (In reply to CVS Commits from comment #4) > The releases/gcc-12 branch has been updated by Jonathan Wakely > : > > https://gcc.gnu.org/g:691012693aaa831e4cd1ab5180195792e32baceb > > commit r12-8926-g691012693aaa831e4cd1ab5180195792e32baceb > Author: Jonathan Wakely > Date: Tue Nov 22 09:53:36 2022 + > > libstdc++: Fix pool resource build errors for H8 [PR107801] > > The array of pool sizes was previously adjusted to work for msp430-elf > which has 16-bit int and either 16-bit size_t or 20-bit size_t. The > largest pool sizes were disabled unless size_t has more than 20 bits. > > The H8 family has 16-bit int but 32-bit size_t, which means that the > largest sizes are enabled, but 1<<15 produces a negative number that > then cannot be narrowed to size_t. Jonathan, a bit of explanation regarding H8 family – it has a few "subfamilies": 1. H8/300 and H8/300L (L from "low power" AFAIR) – these are pure 16-bit MCUs, it has 16-bit general purpose registers, sizeof(int) = sizeof(size_t) = 2; AFAIK they are not manufactured anymore; I have never used any of them. 2. H8/300H, H8S and H8SX – Renesas/Hitachi calls them 16-bit but I call them quasi 32-bit MCUs because they have 32-bit GPRs and instructions, although data bus width is 16 bit. Here things are more complicated – sizeof(size_t) = 4 but sizeof(int) may be 2 or 4 depending on -mint32 command line option. To get things even more complicated, these MCUs have also so called "normal mode" (-mn option) – it is compatibility mode with H8/300 and obviously in this mode sizeof(int) = sizeof(size_t) = 2; __NORMAL_MODE__ macro is defined in this mode.
[Bug libstdc++/107816] 29_atomics/atomic/compare_exchange_padding.cc etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107816 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2022-11-22 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- See https://gcc.gnu.org/pipermail/libstdc++/2022-October/054899.html There's no portable way to write this test.
[Bug libstdc++/93687] Add mcf thread model to GCC on windows for supporting C++11 std::thread?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93687 LIU Hao changed: What|Removed |Added CC||lh_mouse at 126 dot com --- Comment #5 from LIU Hao --- afaict this can be closed now.
[Bug libstdc++/107784] QOI: sizeof( bind_front( Member-Function ) ) too big
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107784 --- Comment #9 from Jonathan Wakely --- I'm not interested in encouraging people to use it, that just makes my job harder. But if you want to use it, it exists.
[Bug modula2/107233] gm2 build hardcodes python3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107233 --- Comment #3 from Gaius Mulley --- ok, thanks for the suggestion. I've changed gcc/configure.ac to use AM_PATH_PYTHON and AM_CONDITIONAL: # Python3? AM_PATH_PYTHON(,, [:]) AM_CONDITIONAL([HAVE_PYTHON], [test "$PYTHON" != :])
[Bug libstdc++/107815] 20_util/to_chars/float128_c++23.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Jakub Jelinek --- > Can you please uncomment the > //std::cout << i << ' ' << std::string_view (str1, ptr1) << '\n'; > and > //std::cout << i << ' ' << std::string_view (str1, ptr5) << '\n'; > lines in the test, so that it is clear at least which test it is on? Sure. This is supposed to print u, I assume ;-) The line before the assertion failure is 1.18973e+4932 1e+4932 /vol/gcc/src/hg/master/local/libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc:66: void test(std::chars_format): Assertion 'ec2 == std::errc() && ptr2 - str2 == ptr1 - str1' failed. i.e. LDBL_MAX. > If line 66 fails, it is a fixed printing test trying to verify > that the string created by line 60 was actually the minimal. It doesn't now reliably: I compiled with -g3 -O0 to be able to check things with gdb if needed. > On SPARC Solaris, I assume long double is IEEE quad, and it is the shortest > version, so should use ryu library for both cases. It is, although only ever implemented in software. > Line 74 failure is about whether the created string can be read back, > in that case for IEEE quad fast_float library can't be used and so it should > use newlocale/uselocale/strtold/uselocale/freelocale, or if the OS doesn't > support newlocale/uselocale/freelocale most likely just strtod with lost > precision (so in that case the test would fail) on line 74. I'm not seeing the failure on l.74 any longer, even with the default optimization options. There has been an effort to introduce an xpg7 locale, but that had quite a number of unresolved issues (both on AIX and Solaris) and was never finished. Currently, we're stuck with generic.
[Bug tree-optimization/107808] gcc.dg/vect/vect-bitfield-write-2.c etc.FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107808 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #2 from avieira at gcc dot gnu.org --- > Hi Rainer, > > I suspect this means SPARC should be added to the list of targets that fail > check_effective_target_vect_long_long. From the dump it looks like the target > doesn't support a long long vectype. Just the opposite, I'd say: the list in check_effective_target_vect_long_long is a positive list of targets supporting that, so it's fine as is. However, the affected testcases don't require that feature, although they depend on it.
[Bug analyzer/107807] gcc.dg/analyzer/errno-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107807 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-11-22 --- Comment #3 from David Malcolm --- Thanks; am working on a fix.
[Bug tree-optimization/107818] New: Overflow of linemap breaks its chronological order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107818 Bug ID: 107818 Summary: Overflow of linemap breaks its chronological order Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: fxue at os dot amperecomputing.com Target Milestone: --- Large-size source codes might exceed representation space of linemap. When this happens, UNKNOWN_LOCATION(0) would inserted to the end of linemap. And the action breaks the order constraint on the map, which requires all logical locations contained by it should remain chronologically-ordered, so that binary search could be used.(Comments in linemap_ordinary_map_lookup). In the function "linemap_add": ... if (start_location >= LINE_MAP_MAX_LOCATION) /* We ran out of line map space. */ start_location = 0; line_map_ordinary *map = linemap_check_ordinary (new_linemap (set, start_location)); ^^^ UNKNOWN_LOCATION(0) is also added to linemap map->reason = reason; ... Afterwards, logical location to source line would be mis-translated. pr86872 only partially fixed see-able ICE due to linemap overflow, but made a this hidden issue.
[Bug c/107405] [13 Regression] enum change causing Linux kernel to fail to build due to Linux depending on old behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107405 --- Comment #18 from Maciej W. Rozycki --- Well, according to the assertion triggered `typeof (EM_MAX_SLOTS)' will yield a data type of a different width depending on the compiler version. Even if this GNU extension does not constitute a part of the ABI it does guarantee link incompatibility for a feature we've had for decades now, even if the old semantics was unintentional. Data corruption cannot be ruled out. Besides, `sizeof (EM_MAX_SLOTS)' can also be used to build a data type (an array type) and process it. So I think a pedantic warning is not enough to fulfil the principle of least surprise for the real world out there. Therefore I maintain that for pre-C2x compilations we either need to keep the old semantics, possibly with a fat warning under `-Wall', or as I say make it a hard error.
[Bug c++/107781] strchrnul' was not declared in this scope; did you mean 'strchr'? For contracts for canadian compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107781 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Jason Merrill --- Fixed.
[Bug c++/107781] strchrnul' was not declared in this scope; did you mean 'strchr'? For contracts for canadian compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107781 --- Comment #7 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:ac5054144bd2248e948842937448eb5f4ce36bfd commit r13-4236-gac5054144bd2248e948842937448eb5f4ce36bfd Author: Jason Merrill Date: Mon Nov 21 17:42:14 2022 -0500 c++: don't use strchrnul [PR107781] The contracts implementation was using strchrnul, which is a glibc extension, so bootstrap broke on non-glibc targets. Use C89 strcspn instead. PR c++/107781 gcc/cp/ChangeLog: * contracts.cc (role_name_equal): Use strcspn instead of strchrnul.
[Bug target/107812] [11/12/13 Regression] RTL SSA forwprop introduced regression since r11-6188
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107812 rsandifo at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2022-11-22 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED --- Comment #1 from rsandifo at gcc dot gnu.org --- Mine.
[Bug libstdc++/107815] 20_util/to_chars/float128_c++23.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815 --- Comment #1 from Jakub Jelinek --- Can you please uncomment the //std::cout << i << ' ' << std::string_view (str1, ptr1) << '\n'; and //std::cout << i << ' ' << std::string_view (str1, ptr5) << '\n'; lines in the test, so that it is clear at least which test it is on? If line 66 fails, it is a fixed printing test trying to verify that the string created by line 60 was actually the minimal. On SPARC Solaris, I assume long double is IEEE quad, and it is the shortest version, so should use ryu library for both cases. Line 74 failure is about whether the created string can be read back, in that case for IEEE quad fast_float library can't be used and so it should use newlocale/uselocale/strtold/uselocale/freelocale, or if the OS doesn't support newlocale/uselocale/freelocale most likely just strtod with lost precision (so in that case the test would fail) on line 74.
[Bug ipa/107661] [13 Regression] lambdas get merged incorrectly in tempaltes, cause llvm-12 miscompilation since r13-3358-ge0403e95689af7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107661 --- Comment #15 from Martin Jambor --- I have proposed a patch on the mailing list: https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607017.html
[Bug libstdc++/107784] QOI: sizeof( bind_front( Member-Function ) ) too big
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107784 --- Comment #8 from Jörg Richter --- To be honest, I can't tell from the description that this option unlocks a libstdc++ that makes no allowance for ABI incompatibilities. If you had a libstdc++ that didn't care about the ABI, similar to boost, this would hopefully attract more contributors and you would have something ready to go if an ABI break does happen. If you advertise such a mode in the release notes, it will surely be used by more than a handful of users.
[Bug libstdc++/107817] std/format/functions/format.cc etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107817 Rainer Orth changed: What|Removed |Added Target Milestone|--- |13.0
[Bug libstdc++/107817] New: std/format/functions/format.cc etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107817 Bug ID: 107817 Summary: std/format/functions/format.cc etc. FAIL Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: *-*-solaris2.11, x86_64-unknown-freebsd12.4, powerpc64le-unknown-linux-gnu The std/format/functions/format.cc and std/format/functions/format_to_n.cc tests FAIL on Solaris (32 and 64-bit, sparc and x86): +FAIL: std/format/functions/format.cc (test for excess errors) +UNRESOLVED: std/format/functions/format.cc compilation failed to produce executable Excess errors: /var/gcc/regression/master/11.4-gcc-gas/build/i386-pc-solaris2.11/libstdc++-v3/include/format:508: error: 'static constexpr std::__format::_Spec<_CharT>::iterator std::__format::_Spec<_CharT>::_S_parse_width_or_precision(iterator, iterator, short unsigned int&, bool&, std::basic_format_parse_context<_CharT>&) [with _CharT = char; iterator = const char*]' called in a constant expression /var/gcc/regression/master/11.4-gcc-gas/build/i386-pc-solaris2.11/libstdc++-v3/include/format:468: error: call to non-'constexpr' function 'int std::isdigit(int)' /var/gcc/regression/master/11.4-gcc-gas/build/i386-pc-solaris2.11/libstdc++-v3/include/format:508: error: 'static constexpr std::__format::_Spec<_CharT>::iterator std::__format::_Spec<_CharT>::_S_parse_width_or_precision(iterator, iterator, short unsigned int&, bool&, std::basic_format_parse_context<_CharT>&) [with _CharT = char; iterator = const char*]' called in a constant expression /var/gcc/regression/master/11.4-gcc-gas/build/i386-pc-solaris2.11/libstdc++-v3/include/format:508: error: 'static constexpr std::__format::_Spec<_CharT>::iterator std::__format::_Spec<_CharT>::_S_parse_width_or_precision(iterator, iterator, short unsigned int&, bool&, std::basic_format_parse_context<_CharT>&) [with _CharT = char; iterator = const char*]' called in a constant expression and many more +FAIL: std/format/functions/format_to_n.cc (test for excess errors) +UNRESOLVED: std/format/functions/format_to_n.cc compilation failed to produce executable Excess errors: /var/gcc/regression/master/11.4-gcc-gas/build/i386-pc-solaris2.11/libstdc++-v3/include/format:508: error: 'static constexpr std::__format::_Spec<_CharT>::iterator std::__format::_Spec<_CharT>::_S_parse_width_or_precision(iterator, iterator, short unsigned int&, bool&, std::basic_format_parse_context<_CharT>&) [with _CharT = char; iterator = const char*]' called in a constant expression /var/gcc/regression/master/11.4-gcc-gas/build/i386-pc-solaris2.11/libstdc++-v3/include/format:468: error: call to non-'constexpr' function 'int std::isdigit(int)' /var/gcc/regression/master/11.4-gcc-gas/build/i386-pc-solaris2.11/libstdc++-v3/include/format:508: error: 'static constexpr std::__format::_Spec<_CharT>::iterator std::__format::_Spec<_CharT>::_S_parse_width_or_precision(iterator, iterator, short unsigned int&, bool&, std::basic_format_parse_context<_CharT>&) [with _CharT = wchar_t; iterator = const wchar_t*]' called in a constant expression and many more since 20221114. FreeBSD and (maybe, if that's not an older issue since fixed) Linux/powerpc64le are equally affected.
[Bug libstdc++/107816] 29_atomics/atomic/compare_exchange_padding.cc etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107816 Rainer Orth changed: What|Removed |Added Target Milestone|--- |13.0
[Bug libstdc++/107816] New: 29_atomics/atomic/compare_exchange_padding.cc etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107816 Bug ID: 107816 Summary: 29_atomics/atomic/compare_exchange_padding.cc etc. FAIL Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: sparc*-sun-solaris2.11, riscv64-suse-linux-gnu, powerpc-ibm-aix7.2.5.0 The 29_atomics/atomic/compare_exchange_padding.cc and 29_atomics/atomic_ref/compare_exchange_padding.cc tests FAIL on 64-bit Solaris/SPARC since 20220909: +FAIL: 29_atomics/atomic/compare_exchange_padding.cc execution test +FAIL: 29_atomics/atomic_ref/compare_exchange_padding.cc execution test /vol/gcc/src/hg/master/local/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc:29: int main(): Assertion '!compare_struct(s, ts)' failed. /vol/gcc/src/hg/master/local/libstdc++-v3/testsuite/29_atomics/atomic_ref/compare_exchange_padding.cc:31: int main(): Assertion '!compare_struct(ss, ts)' failed. There are also reports for Linux/riscv64 and AIX on gcc-testresults. I vaguely remember having seen this discussed on gcc-patches, but couldn't find a corresponding PR.
[Bug libstdc++/107815] 20_util/to_chars/float128_c++23.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815 Rainer Orth changed: What|Removed |Added Target Milestone|--- |13.0
[Bug libstdc++/107815] New: 20_util/to_chars/float128_c++23.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815 Bug ID: 107815 Summary: 20_util/to_chars/float128_c++23.cc FAILs Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- Target: sparc*-sun-solaris2.11, hppa64-hp-hpux11.11 The 20_util/to_chars/float128_c++23.cc test FAILs on SPARC (32 and 64-bit) since it was introduced: +FAIL: 20_util/to_chars/float128_c++23.cc execution test There are also reports on HP-UX. The log shows: /vol/gcc/src/hg/master/local/libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc:66: void test(std::chars_format): Assertion 'ec2 == std::errc() && ptr2 - str2 == ptr1 - str1' failed. Weirdly, if I recompile the test manually, I get this instead: /vol/gcc/src/hg/master/local/libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc:74: void test(std::chars_format): Assertion 'ec4 == std::errc() && ptr4 == ptr1' failed.
[Bug libstdc++/107814] [13 regression] experimental/filesystem/iterators/error_reporting.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107814 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-11-22 Status|UNCONFIRMED |NEW --- Comment #1 from Jonathan Wakely --- Are you sure this is a regression? Isn't it the same case as PR104731, but that was only fixed for 27_io/filesystem/iterators/error_reporting.cc and not experimental/filesystem/iterators/error_reporting.cc ?
[Bug libstdc++/107814] [13 regression] experimental/filesystem/iterators/error_reporting.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107814 Rainer Orth changed: What|Removed |Added Target Milestone|--- |13.0
[Bug c++/107813] Enum with underlying type uint8_t bad promotion for unsigned char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107813
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #2 from Jonathan Wakely ---
Reduced:
void f(unsigned char) = delete;
void f(int) { }
enum TEnum: unsigned char {
Kot = 67
};
template void g(const T& t) { f(t); }
template<> void g(const unsigned char&) { }
int main()
{
g(Kot);
}
This compiles with GCC 9 and not with GCC 10. But GCC 10 is correct, this was
fixed by commit r10-3736-ge295e3d981355c
PR c++/92032 - DR 1601: Promotion of enum with fixed underlying type.
[Bug libstdc++/107814] New: [13 regression] experimental/filesystem/iterators/error_reporting.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107814 Bug ID: 107814 Summary: [13 regression] experimental/filesystem/iterators/error_reporting.cc FAILs Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: i386-pc-solaris2.11, amd64-pc-solaris2.11 Since 20221114, experimental/filesystem/iterators/error_reporting.cc FAILs on Solaris/x86 only, 32 and 64-bit, while SPARC is fine: FAIL: experimental/filesystem/iterators/error_reporting.cc execution test /vol/gcc/src/hg/master/local/libstdc++-v3/testsuite/experimental/filesystem/iterators/error_reporting.cc:112: void test02(): Assertion 'ec.value() == EIO' failed. Running the test under truss on i386 vs. sparc shows: * i386: 380:mkdirat(AT_FDCWD, "filesystem-test.error_reporting.4042030604.aA7VId/subdir", 0777) = 0 380:openat64(AT_FDCWD, "filesystem-test.error_reporting.4042030604.aA7VId", O_RDONLY|O_CLOEXEC|O_DIRECTORY) = 3 380:fcntl(3, F_GETFL) = 8192 FOFFMAX 380:fstatat64(3, NULL, 0xFEFFD8C0, 0) = 0 380:d=0x04390012 i=2368576 m=0042755 l=3 u=2110 g=4620 sz=3 380:at = Nov 22 14:15:46 MET 2022 [ 1669122946.599365773 ] 380:mt = Nov 22 14:15:46 MET 2022 [ 1669122946.599784611 ] 380:ct = Nov 22 14:15:46 MET 2022 [ 1669122946.599784611 ] 380:bsz=131072 blks=1 fs=zfs 380:llseek(3, 0, SEEK_CUR) = 0 380:fcntl(3, F_SETFD, 0x0001) = 0 380:fstatat64(AT_FDCWD, "filesystem-test.error_reporting.4042030604.aA7VId/su\x01", 0xFEFFD8D0, AT_SYMLINK_NOFOLLOW) Err#2 ENOENT * sparc: 14724: mkdirat(AT_FDCWD, "filesystem-test.error_reporting.2190730903.bVmlIc/subdir", 0777) = 0 14724: openat64(AT_FDCWD, "filesystem-test.error_reporting.2190730903.bVmlIc", O_RDONLY|O_CLOEXEC|O_DIRECTORY) = 3 14724: fcntl(3, F_GETFL) = 8192 FOFFMAX 14724: fstatat64(3, NULL, 0xFFBFE738, 0) = 0 14724: d=0x04190013 i=5268679 m=0042755 l=3 u=2110 g=4620 sz=3 14724: at = Nov 22 14:27:21 MET 2022 [ 1669123641.516468740 ] 14724: mt = Nov 22 14:27:21 MET 2022 [ 1669123641.516614735 ] 14724: ct = Nov 22 14:27:21 MET 2022 [ 1669123641.516614735 ] 14724: bsz=131072 blks=1 fs=zfs 14724: llseek(3, 0, SEEK_CUR) = 0 14724: fcntl(3, F_SETFD, 0x0001) = 0 14724: fstatat64(AT_FDCWD, "filesystem-test.error_reporting.2190730903.bVmlIc/subdir", 0xFFBFE728, AT_SYMLINK_NOFOLLOW) = 0 I.e. the pathname is somehow corrupted.
[Bug c++/107813] Enum with underlying type uint8_t bad promotion for unsigned char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107813 --- Comment #1 from Jonathan Wakely --- GCC 10 is correct. The template is a exact match for the argument, accepting any argument type, so the enum should not be converted to unsigned char. When you call this->o << t then there is no exact match, so an implicit conversion to unsigned char happens.
[Bug libstdc++/107799] Wrong return type for std::bit_width
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107799 --- Comment #2 from Diego Baldassar --- Ah I see, it was a DR. My mistake. Will we see this updated for GCC 13? Or is it considered a breaking change that's too late to fix?
[Bug analyzer/107807] gcc.dg/analyzer/errno-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107807 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from David Malcolm --- > I've tested errno-1.c with glibc's errno.h, and with a simple "extern int > errno;". > > What does look like on your machine? In particular, how is "errno" > defined/declared? Thanks. It's a bit more complicated here, boiling down to extern int *___errno(void) __attribute__((__const__)); #define errno (*(___errno())) You will find something similar e.g. on Mac OS X 10.7, btw.: extern int * __error(void); #define errno (*__error())
[Bug libstdc++/107811] libstdc++-v3/src/c++17/floating_from_chars.cc:787:9: error: 'fast_float' has not been declared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107811 --- Comment #2 from Jonathan Wakely --- Yes it does
[Bug analyzer/107807] gcc.dg/analyzer/errno-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107807 --- Comment #1 from David Malcolm --- Thanks for filing this bug; sorry about the test failures. I've tested errno-1.c with glibc's errno.h, and with a simple "extern int errno;". What does look like on your machine? In particular, how is "errno" defined/declared? Thanks.
[Bug target/107604] FAIL: gcc.target/aarch64/aapcs64/test_dfp_17.c execution, -O0 fails on aarch64_be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107604 Christophe Lyon changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Christophe Lyon --- Fixed.
[Bug tree-optimization/80548] -Wmaybe-uninitialized false positive when an assignment is added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548 --- Comment #11 from Jeffrey A. Law --- Thanks! So the change in question improves the decisions in the predicate analysis code, which can be best thought of as a filter for the false positives that are still in the IL. As I said in my previous comment, the best way forward is to get those two new instances filed as distinct bugs in BZ.
[Bug target/107604] FAIL: gcc.target/aarch64/aapcs64/test_dfp_17.c execution, -O0 fails on aarch64_be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107604 --- Comment #4 from CVS Commits --- The master branch has been updated by Christophe Lyon : https://gcc.gnu.org/g:4eb3a48698b2ca43967a4e7e7cfc0408192e85b2 commit r13-4235-g4eb3a48698b2ca43967a4e7e7cfc0408192e85b2 Author: Christophe Lyon Date: Tue Nov 22 08:33:06 2022 + aarch64: Fix test_dfp_17.c for big-endian [PR 107604] gcc.target/aarch64/aapcs64/test_dfp_17.c has been failing on big-endian, because the _Decimal32 on-stack argument is not padded in the same direction depending on endianness. This patch fixes the testcase so that it expects the argument in the right stack location, similarly to what other tests do in the same directory. gcc/testsuite/ChangeLog: PR target/107604 * gcc.target/aarch64/aapcs64/test_dfp_17.c: Fix for big-endian.
[Bug libstdc++/107811] libstdc++-v3/src/c++17/floating_from_chars.cc:787:9: error: 'fast_float' has not been declared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107811 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |13.0
