[Bug c++/109642] False Positive -Wdangling-reference with std::span-like classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109642 --- Comment #1 from Andrew Pinski --- std::span, std::reference_wrapper and std::ref_view are all special cased for the warning.
[Bug libgomp/109634] Linking Imagick for PHP compiles fine but gives segfault caused by libgomp on runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109634
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comment #5 from Alexander Monakov ---
I remember Glibc used to issue a readable diagnostic in that case ("cannot
allocate memory in static TLS block"). Worth reporting to Glibc if that part
regressed and the diagnostic is no longer available (at least I don't see it in
the linked Github issue).
What is actually happening here? Valgrind catches a null pointer dereference,
but where is that null coming from? Is the dynamic linker invoking constructors
with TLS pointer set to null, instead of aborting?
[Bug c++/109642] False Positive -Wdangling-reference with std::span-like classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109642 --- Comment #2 from Carlos Galvez --- Is there a way to tag classes to mark them for exclusion? Currently the warning is part of -Wall and leads to many false positives. The warning message also says "possibly" dangling reference. In my opinion "possibly" type of warnings should not be part of -Wall due to the high FP rate. I also find it strange that it complains about const references, which anyway extend the lifetime of the temporary, or?
[Bug target/109632] Inefficient codegen when complex numbers are emulated with structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109632
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comment #4 from rsandifo at gcc dot gnu.org
---
Maybe worth noting that if the complex arguments are passed
by value, to give:
struct complx_t {
float re;
float im;
};
complx_t
add(const complx_t a, const complx_t b) {
return {a.re + b.re, a.im + b.im};
}
and SLP is disabled, we get:
fmovw4, s1
fmovw3, s3
fmovx0, d0
fmovx1, d2
mov x2, 0
bfi x0, x4, 32, 32
bfi x1, x3, 32, 32
fmovd0, x0
fmovd1, x1
sbfxx3, x0, 0, 32
sbfxx0, x1, 0, 32
ushrd1, d1, 32
fmovd3, x0
fmovd2, x3
ushrd0, d0, 32
fadds2, s2, s3
fadds0, s0, s1
fmovw1, s2
fmovw0, s0
bfi x2, x1, 0, 32
bfi x2, x0, 32, 32
lsr x0, x2, 32
lsr w2, w2, 0
fmovs1, w0
fmovs0, w2
ret
which is almost impressive, in its way.
I think we need a way in gimple of “SRA-ing” the arguments
and return value, in cases where that's forced by the ABI.
I.e. provide separate incoming values of a.re and a.im,
and store them to “a” on entry. Then similarly make the
return stmt return RETURN_DECL.re and RETURN_DECL.im
separately.
[Bug ipa/109643] [14 Regression] IPA inline ICE on pkg-config-0.29.2 since r14-249-g3c9372dfee0bb8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109643
--- Comment #3 from Sergei Trofimovich ---
Got a slightly nicer backtrace with debugging symbols:
(gdb) bt
#0 0x00f70d7b in canonize (val=0x7fff9120, len=len@entry=0,
precision=precision@entry=576) at ../../source/gcc/wide-int.cc:96
#1 0x00f71699 in wi::force_to_size (val=val@entry=0x7fff9120,
xval=xval@entry=0x7fffa320, xlen=,
xprecision=, precision=precision@entry=576, sgn=) at ../../source/gcc/wide-int.cc:400
#2 0x00bd6c3d in fixed_wide_int_storage<576>::from (sgn=, x=...) at ../../source/gcc/wide-int.h:1292
Looks like canonize() below has `val` of zero length:
(gdb) print len
$1 = 0
(gdb) print val
$2 = (long *) 0x7fff9120
static unsigned int
canonize (HOST_WIDE_INT *val, unsigned int len, unsigned int precision)
{
unsigned int blocks_needed = BLOCKS_NEEDED (precision);
HOST_WIDE_INT top;
int i;
if (len > blocks_needed)
len = blocks_needed;
if (len == 1)
return len;
top = val[len - 1];
...
[Bug target/109636] [14 Regression] ICE: in paradoxical_subreg_p, at rtl.h:3205 with -O -mcpu=a64fx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109636 ktkachov at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2023-04-27 Status|UNCONFIRMED |NEW CC||rsandifo at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from ktkachov at gcc dot gnu.org --- Confirmed. The operand that's blowing it up is: (subreg:V2DI (reg/v:OI 97 [ w ]) 16) at rtx sve_op1 = simplify_gen_subreg (sve_mode, operands[1], mode, 0); simplify_gen_subreg, lowpart_subreg, copy_to_mode_reg and force_reg all ICE :(
[Bug sanitizer/109594] [14 Regression] ICE verify_gimple failed with ASAN since r14-67-g2c800ed8d59cff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109594 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Richard Biener --- Fixed.
[Bug sanitizer/109594] [14 Regression] ICE verify_gimple failed with ASAN since r14-67-g2c800ed8d59cff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109594 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Richard Biener --- Fixed.
[Bug sanitizer/109594] [14 Regression] ICE verify_gimple failed with ASAN since r14-67-g2c800ed8d59cff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109594 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:7bcdcf86e8272eeb524cc1dcb0ada8c8cfe6f27e commit r14-285-g7bcdcf86e8272eeb524cc1dcb0ada8c8cfe6f27e Author: Richard Biener Date: Mon Apr 24 13:20:25 2023 +0200 tree-optimization/109594 - wrong register promotion We fail to verify the constraints under which we allow handled components to wrap registers. The gcc.dg/pr70022.c testcase shows that we happily end up with _2 = VIEW_CONVERT_EXPR(v_1(D)) as produced by SSA rewrite and update_address_taken. But the intent was that we wrap registers with at most a single level of handled components and specifically only allow __real, __imag, BIT_FIELD_REF and VIEW_CONVERT_EXPR on them, but not ARRAY_REF or COMPONENT_REF. Together with the improved gimple_load predicate taking advantage of the above and ASAN this eventually ICEd. The following fixes update_address_taken as to this constraint. PR tree-optimization/109594 * tree-ssa.cc (non_rewritable_mem_ref_base): Constrain what we rewrite to a register based on the above.
[Bug middle-end/109644] New: Missing GIMPLE IL verification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109644 Bug ID: 109644 Summary: Missing GIMPLE IL verification Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- We are missing GIMPLE IL verification of handled component operations on registers. There's only a subset of operations allowed and they should not stack but behave like UNARY ops. The subset allowed is REALPART_EXPR, IMAGPART_EXPR, VIEW_CONVERT_EXPR and BIT_FIELD_REF. In particular ops that require aggregate types such as ARRAY_REF and COMPONENT_REF are not allowed, but the missing IL verification makes those sneak through with the register wrapped in a VIEW_CONVERT_EXPR producing the aggregate type.
[Bug middle-end/109644] Missing GIMPLE IL verification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109644 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2023-04-27 --- Comment #1 from Richard Biener --- Created attachment 54936 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54936&action=edit patch implementing the IL verification This implements appropriate IL verification, but it currently runs into quite some issues where we create invalid GIMPLE.
[Bug ipa/109643] [14 Regression] IPA inline ICE on pkg-config-0.29.2 since r14-249-g3c9372dfee0bb8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109643 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Aldy Hernandez --- dup *** This bug has been marked as a duplicate of bug 109639 ***
[Bug ipa/109639] [14 regression] Internal compiler error: tree check: expected integer_cst, have addr_expr in to_wide, at tree.h:6283 since r14-249-g3c9372dfee0bb8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109639 Aldy Hernandez changed: What|Removed |Added CC||slyfox at gcc dot gnu.org --- Comment #11 from Aldy Hernandez --- *** Bug 109643 has been marked as a duplicate of this bug. ***
[Bug ipa/109639] [14 regression] Internal compiler error: tree check: expected integer_cst, have addr_expr in to_wide, at tree.h:6283 since r14-249-g3c9372dfee0bb8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109639 Aldy Hernandez changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org CC||amacleod at redhat dot com --- Comment #12 from Aldy Hernandez --- We're trying to build a range of [&k, &k] and are failing because irange's no longer support symbolics. Truth be told, we haven't supported them in a while, because ranger doesn't. However, the setter was normalizing addresses to non-zero, which it is no longer doing. Mine.
[Bug ipa/109639] [14 regression] Internal compiler error: tree check: expected integer_cst, have addr_expr in to_wide, at tree.h:6283 since r14-249-g3c9372dfee0bb8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109639
--- Comment #13 from Aldy Hernandez ---
Sorry, it wasn't the setter doing the normalization, but the
range_fold_{unary,binary}_expr helpers. Since IPA was the only user of these
deprecated functions, this should be relatively easy to contain.
[Bug c++/109645] New: ice in instantiate_decl, at cp/pt.cc:27097
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109645 Bug ID: 109645 Summary: ice in instantiate_decl, at cp/pt.cc:27097 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: --- Created attachment 54937 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54937&action=edit gzipped C++ source code The attached C++ code, does this with recent gcc trunk: $ ../results.20230426.asan.ubsan/bin/gcc -c -w -march=znver1 bug910.cc $ ../results.20230427.asan.ubsan/bin/gcc -c -w -march=znver1 bug910.cc 2>&1 | fgrep internal /home/dcb36/rpmbuild/BUILD/media-downloader-2.9.0/src/engines/../utils/threads.hpp:55:79: internal compiler error: in instantiate_decl, at cp/pt.cc:27097 $ ../results.20230426.asan.ubsan/bin/gcc -v 2>&1 | fgrep exp gcc version 14.0.0 20230426 (experimental) (5fce06b868ec0d4f) $ ../results.20230427.asan.ubsan/bin/gcc -v 2>&1 | fgrep exp gcc version 14.0.0 20230427 (experimental) (d94ca762f6e0e4f1) $ git log 5fce06b868ec0d4f..d94ca762f6e0e4f1 | grep -c "^commit" 43 I have a reduction running.
[Bug c/107682] [13/14 Regression] ICE in c_parser_braced_init, at c/c-parser.cc:5619
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107682 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a1030fbf70eef5b635e4fbb904ec7209ebd137ca commit r14-287-ga1030fbf70eef5b635e4fbb904ec7209ebd137ca Author: Jakub Jelinek Date: Thu Apr 27 11:35:55 2023 +0200 c: Fix up error-recovery on functions initialized as variables [PR109412] The change to allow empty initializers in C broke error-recovery on the following testcase. We are emitting function %qD is initialized like a variable error early; if the initializer is non-empty, we just emit another error that the initializer is invalid. Previously if it was empty, we'd emit another error that scalar is being initialized by empty initializer (not really correct), but now we instead just try to build_zero_cst for the FUNCTION_TYPE and ICE on it. The following patch just emits the same diagnostics for the empty initializers as we emit for the non-empty ones. 2023-04-27 Jakub Jelinek PR c/107682 PR c/109412 * c-typeck.cc (pop_init_level): If constructor_type is FUNCTION_TYPE, reject empty initializer as invalid. * gcc.dg/pr109412.c: New test.
[Bug c/109412] [13/14 Regression] ICE in fold_convert_loc, at fold-const.cc:2627 since r13-2205-g14cfa01755a66a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109412 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a1030fbf70eef5b635e4fbb904ec7209ebd137ca commit r14-287-ga1030fbf70eef5b635e4fbb904ec7209ebd137ca Author: Jakub Jelinek Date: Thu Apr 27 11:35:55 2023 +0200 c: Fix up error-recovery on functions initialized as variables [PR109412] The change to allow empty initializers in C broke error-recovery on the following testcase. We are emitting function %qD is initialized like a variable error early; if the initializer is non-empty, we just emit another error that the initializer is invalid. Previously if it was empty, we'd emit another error that scalar is being initialized by empty initializer (not really correct), but now we instead just try to build_zero_cst for the FUNCTION_TYPE and ICE on it. The following patch just emits the same diagnostics for the empty initializers as we emit for the non-empty ones. 2023-04-27 Jakub Jelinek PR c/107682 PR c/109412 * c-typeck.cc (pop_init_level): If constructor_type is FUNCTION_TYPE, reject empty initializer as invalid. * gcc.dg/pr109412.c: New test.
[Bug c/109409] [13/14 Regression] ICE in check_format_arg, at c-family/c-format.cc:1777 since r13-2205-g14cfa01755a66a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109409 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d8842271ebf9a81128df9ae80e1d3b688749eac8 commit r14-288-gd8842271ebf9a81128df9ae80e1d3b688749eac8 Author: Jakub Jelinek Date: Thu Apr 27 11:36:54 2023 +0200 c: Fix up error-recovery on non-empty VLA initializers [PR109409] On the following testcase we ICE, because after we emit the variable-sized object may not be initialized except with an empty initializer error we don't really reset the initializer to error_mark_node and then at -Wformat checking time we ICE on seeing STRING_CST initializer for a VLA. The following patch just arranges for error_mark_node to be returned after the error diagnostics. 2023-04-27 Jakub Jelinek PR c/109409 * c-parser.cc (c_parser_initializer): Move diagnostics about initialization of variable sized object with non-empty initializer after c_parser_expr_no_commas call and ret.set_error (); after it. * gcc.dg/pr109409.c: New test.
[Bug c/109412] [13/14 Regression] ICE in fold_convert_loc, at fold-const.cc:2627 since r13-2205-g14cfa01755a66a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109412 --- Comment #7 from CVS Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7e312adcb70ca7d67f0c2cf238cddec9b3243ff9 commit r13-7257-g7e312adcb70ca7d67f0c2cf238cddec9b3243ff9 Author: Jakub Jelinek Date: Thu Apr 27 11:35:55 2023 +0200 c: Fix up error-recovery on functions initialized as variables [PR109412] The change to allow empty initializers in C broke error-recovery on the following testcase. We are emitting function %qD is initialized like a variable error early; if the initializer is non-empty, we just emit another error that the initializer is invalid. Previously if it was empty, we'd emit another error that scalar is being initialized by empty initializer (not really correct), but now we instead just try to build_zero_cst for the FUNCTION_TYPE and ICE on it. The following patch just emits the same diagnostics for the empty initializers as we emit for the non-empty ones. 2023-04-27 Jakub Jelinek PR c/107682 PR c/109412 * c-typeck.cc (pop_init_level): If constructor_type is FUNCTION_TYPE, reject empty initializer as invalid. * gcc.dg/pr109412.c: New test. (cherry picked from commit a1030fbf70eef5b635e4fbb904ec7209ebd137ca)
[Bug c/107682] [13/14 Regression] ICE in c_parser_braced_init, at c/c-parser.cc:5619
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107682 --- Comment #6 from CVS Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7e312adcb70ca7d67f0c2cf238cddec9b3243ff9 commit r13-7257-g7e312adcb70ca7d67f0c2cf238cddec9b3243ff9 Author: Jakub Jelinek Date: Thu Apr 27 11:35:55 2023 +0200 c: Fix up error-recovery on functions initialized as variables [PR109412] The change to allow empty initializers in C broke error-recovery on the following testcase. We are emitting function %qD is initialized like a variable error early; if the initializer is non-empty, we just emit another error that the initializer is invalid. Previously if it was empty, we'd emit another error that scalar is being initialized by empty initializer (not really correct), but now we instead just try to build_zero_cst for the FUNCTION_TYPE and ICE on it. The following patch just emits the same diagnostics for the empty initializers as we emit for the non-empty ones. 2023-04-27 Jakub Jelinek PR c/107682 PR c/109412 * c-typeck.cc (pop_init_level): If constructor_type is FUNCTION_TYPE, reject empty initializer as invalid. * gcc.dg/pr109412.c: New test. (cherry picked from commit a1030fbf70eef5b635e4fbb904ec7209ebd137ca)
[Bug c/109409] [13/14 Regression] ICE in check_format_arg, at c-family/c-format.cc:1777 since r13-2205-g14cfa01755a66a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109409 --- Comment #6 from CVS Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:297d0efc13d73d36371583c2d6d6e7a47f88cd02 commit r13-7258-g297d0efc13d73d36371583c2d6d6e7a47f88cd02 Author: Jakub Jelinek Date: Thu Apr 27 11:36:54 2023 +0200 c: Fix up error-recovery on non-empty VLA initializers [PR109409] On the following testcase we ICE, because after we emit the variable-sized object may not be initialized except with an empty initializer error we don't really reset the initializer to error_mark_node and then at -Wformat checking time we ICE on seeing STRING_CST initializer for a VLA. The following patch just arranges for error_mark_node to be returned after the error diagnostics. 2023-04-27 Jakub Jelinek PR c/109409 * c-parser.cc (c_parser_initializer): Move diagnostics about initialization of variable sized object with non-empty initializer after c_parser_expr_no_commas call and ret.set_error (); after it. * gcc.dg/pr109409.c: New test. (cherry picked from commit d8842271ebf9a81128df9ae80e1d3b688749eac8)
[Bug c/109412] [13/14 Regression] ICE in fold_convert_loc, at fold-const.cc:2627 since r13-2205-g14cfa01755a66a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109412 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Jakub Jelinek --- Fixed for 13.2+ and 14+.
[Bug c/107682] [13/14 Regression] ICE in c_parser_braced_init, at c/c-parser.cc:5619
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107682 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed for 13.2+ and 14+.
[Bug c/109409] [13/14 Regression] ICE in check_format_arg, at c-family/c-format.cc:1777 since r13-2205-g14cfa01755a66a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109409 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Jakub Jelinek --- Fixed for 13.2+ and 14+.
[Bug c++/109645] ice in instantiate_decl, at cp/pt.cc:27097
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109645 --- Comment #1 from David Binderman --- Created attachment 54938 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54938&action=edit gzipped C++ source code After an hour of reduction, I have the attached file. C++ code takes a long time to reduce with cvise.
[Bug c++/109645] ice in instantiate_decl, at cp/pt.cc:27097
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109645 --- Comment #2 from David Binderman --- Attempting a bisection.
[Bug ipa/109639] [14 regression] Internal compiler error: tree check: expected integer_cst, have addr_expr in to_wide, at tree.h:6283 since r14-249-g3c9372dfee0bb8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109639 --- Comment #14 from Aldy Hernandez --- Created attachment 54939 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54939&action=edit proposed patch in testing
[Bug libstdc++/105081] Make std::random_device throw std::system_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105081 --- Comment #3 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:f9412cedd6c0e7417b30d9a80d3f45c8746223b4 commit r14-289-gf9412cedd6c0e7417b30d9a80d3f45c8746223b4 Author: Jonathan Wakely Date: Wed Apr 26 15:23:57 2023 +0100 libstdc++: Make std::random_device throw std::system_error [PR105081] This changes std::random_device constructors to throw std::system_error (with EINVAL as the error code) when the constructor argument is invalid. We can also throw std::system_error when read(2) fails so that the exception includes the additional information provided by errno. As noted in the PR, this is consistent with libc++, and doesn't break any existing code which catches std::runtime_error, because those handlers will still catch std::system_error. libstdc++-v3/ChangeLog: PR libstdc++/105081 * src/c++11/random.cc (__throw_syserr): New function. (random_device::_M_init, random_device::_M_init_pretr1): Use new function for bad tokens. (random_device::_M_getval): Use new function for read errors. * testsuite/util/testsuite_random.h (random_device_available): Change catch handler to use std::system_error.
[Bug libstdc++/40380] class documentation should mention include file to use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40380 --- Comment #7 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:865869dc6943eb5dee855bc1ea88b09b7dabc641 commit r14-290-g865869dc6943eb5dee855bc1ea88b09b7dabc641 Author: Jonathan Wakely Date: Wed Apr 26 22:48:35 2023 +0100 libstdc++: Add @headerfile and @since to doxygen comments [PR40380] libstdc++-v3/ChangeLog: PR libstdc++/40380 * include/bits/basic_string.h: Improve doxygen comments. * include/bits/cow_string.h: Likewise. * include/bits/forward_list.h: Likewise. * include/bits/fs_dir.h: Likewise. * include/bits/fs_path.h: Likewise. * include/bits/quoted_string.h: Likewise. * include/bits/stl_bvector.h: Likewise. * include/bits/stl_map.h: Likewise. * include/bits/stl_multimap.h: Likewise. * include/bits/stl_multiset.h: Likewise. * include/bits/stl_set.h: Likewise. * include/bits/stl_vector.h: Likewise. * include/bits/unordered_map.h: Likewise. * include/bits/unordered_set.h: Likewise. * include/std/filesystem: Likewise. * include/std/iomanip: Likewise.
[Bug ipa/109607] IPA replaces stmt with invalid gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109607 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:d89e23f27215fcd822994fb2fad17fcd31eef5e1 commit r14-295-gd89e23f27215fcd822994fb2fad17fcd31eef5e1 Author: Richard Biener Date: Wed Apr 26 13:05:44 2023 +0200 ipa/109607 - properly gimplify conversions introduced by IPA param manipulation The following addresses IPA param manipulation (through IPA SRA) replacing BIT_FIELD_REF <*this_8(D), 8, 56> with BIT_FIELD_REF (ISRA.814), 8, 56> which is supposed to be invalid GIMPLE (ISRA.814 is a register). There's currently insufficient checking in place to catch this in the IL verifier but I am working on that as part of fixing PR109594. The solution for the particular testcase I am running into this is to split the conversion to a separate stmt. Generally the modification phase is set up for this but the extra_stmts sequence isn't passed around everywhere. The following passes it to modify_expression from modify_assignment when rewriting the RHS. PR ipa/109607 * ipa-param-manipulation.h (ipa_param_body_adjustments::modify_expression): Add extra_stmts argument. * ipa-param-manipulation.cc (ipa_param_body_adjustments::modify_expression): Likewise. When we need a conversion and the replacement is a register split the conversion out. (ipa_param_body_adjustments::modify_assignment): Pass extra_stmts to RHS modify_expression. * g++.dg/torture/pr109607.C: New testcase.
[Bug middle-end/109644] Missing GIMPLE IL verification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109644 Bug 109644 depends on bug 109607, which changed state. Bug 109607 Summary: IPA replaces stmt with invalid gimple https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109607 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug ipa/109607] IPA replaces stmt with invalid gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109607 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed (this particular case I ran into).
[Bug sanitizer/109594] [14 Regression] ICE verify_gimple failed with ASAN since r14-67-g2c800ed8d59cff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109594 Bug 109594 depends on bug 109607, which changed state. Bug 109607 Summary: IPA replaces stmt with invalid gimple https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109607 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug libstdc++/105081] Make std::random_device throw std::system_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105081 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|13.2|14.0 --- Comment #4 from Jonathan Wakely --- Done for GCC 14
[Bug libgomp/109646] New: OpenACC attach directive fails with "pointer target not mapped for attach"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109646
Bug ID: 109646
Summary: OpenACC attach directive fails with "pointer target
not mapped for attach"
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick.be...@univ-grenoble-alpes.fr
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Created attachment 54940
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54940&action=edit
Small test case to reproduce the problem
Using GNU Fortran (GCC) 12.2.1 20230302 [OG12] in OpenACC offloading.
the "!$acc enter data attach" directive fails with the message "libgomp:
pointer target not mapped for attach"
A small test-case is provide.
Compilation: gfortran -g -fopenacc tranform.f90 -o transform
Execution:
./transform
In add_new_transform for [Premiere]
In add_new_transform : [Premiere] is the first transform
In add_new_transform done for [Premiere]
In add_new_transform for [Seconde]
In add_new_transform insert [Seconde] after [Premiere]
libgomp: pointer target not mapped for attach
Test runs fine with nvfortran 22.5 (nvfortran -acc -g tranform.f90 -o
transform)
Test runs fine with Cray Fortran 15.0.1 (ftn -hacc -g tranform.f90 -o
transform)
Correct poutput is:
In add_new_transform for [Premiere]
In add_new_transform : [Premiere] is the first transform
In add_new_transform done for [Premiere]
In add_new_transform for [Seconde]
In add_new_transform insert [Seconde] after [Premiere]
In add_new_transform done for [Seconde]
Found 2
Stack size of the call giving the error:
Thread 1 "transform" hit Breakpoint 2, gomp_attach_pointer
(devicep=devicep@entry=0x634120, aq=aq@entry=0x0,
mem_map=mem_map@entry=0x634208, n=n@entry=0xb96cc0, attach_to=12150352,
bias=, cbufp=0x0,
allow_zero_length_array_sections=false) at
../../../gcc/libgomp/target.c:1012
1012 gomp_fatal ("pointer target not mapped for attach");
(gdb) where
#0 gomp_attach_pointer (devicep=devicep@entry=0x634120, aq=aq@entry=0x0,
mem_map=mem_map@entry=0x634208,
n=n@entry=0xb96cc0, attach_to=12150352, bias=, cbufp=0x0,
allow_zero_length_array_sections=false)
at ../../../gcc/libgomp/target.c:1012
#1 0x7736c007 in goacc_enter_data_internal (aq=,
kinds=, sizes=,
hostaddrs=0x7fffcc70, mapnum=, acc_dev=)
at ../../../gcc/libgomp/oacc-mem.c:1217
#2 goacc_enter_exit_data_internal (flags_m=, mapnum=, hostaddrs=0x7fffcc70,
sizes=, kinds=,
data_enter=data_enter@entry=true, async=,
num_waits=, ap=) at
../../../gcc/libgomp/oacc-mem.c:1534
#3 0x7736cc0c in GOACC_enter_data (flags_m=,
mapnum=,
hostaddrs=, sizes=, kinds=,
async=, num_waits=0)
at ../../../gcc/libgomp/oacc-mem.c:1607
#4 0x0040148f in transforms_defs_m::add_new_transform
(transform=0x606a20, name=...,
new_ptr=,
_name=7) at tranform.f90:87
#5 0x00401698 in MAIN__ () at tranform.f90:138
[Bug libstdc++/40380] class documentation should mention include file to use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40380 --- Comment #8 from Jonathan Wakely --- Added some more of these @headerfile annotations, but there's still more to do.
[Bug c++/109645] ice in instantiate_decl, at cp/pt.cc:27097
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109645 --- Comment #3 from David Binderman --- (In reply to David Binderman from comment #2) > Attempting a bisection. Current range is a8e1551bdb372aa3..d94ca762f6e0e4f1.
[Bug target/109632] Inefficient codegen when complex numbers are emulated with structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109632 --- Comment #5 from rsandifo at gcc dot gnu.org --- Created attachment 54941 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54941&action=edit hacky proof-of-concept patch This is a very hacky proof of concept patch. Don't try it on anything serious, and certainly don't try to bootstrap with it -- it'll fall over in the slightest breeze. But it does produce: ldp s3, s2, [x0] ldp s0, s1, [x1] fadds1, s2, s1 fadds0, s3, s0 ret for the original testcase.
[Bug target/109632] Inefficient codegen when complex numbers are emulated with structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109632 --- Comment #6 from Tamar Christina --- That's an interesting approach, I think it would also fix https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109391 would it not? Since the int16x8x3_t return would be "scalarized" avoiding the bad expansion?
[Bug target/108758] [12/13 Regression] gcc.target/powerpc/float128-cmp2-runnable.c fails with excess errors on power 9 BE since r12-5752
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108758 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.3
[Bug tree-optimization/105723] [12 Regression] Optimization false positive warning (-Wstringop-overflow)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105723 Richard Biener changed: What|Removed |Added Keywords||needs-bisection --- Comment #3 from Richard Biener --- Needs bisection as to what fixed it on trunk.
[Bug libstdc++/107466] [12 Regression] invalid -Wnarrowing error with std::subtract_with_carry_engine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107466 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug libstdc++/107466] [12 Regression] invalid -Wnarrowing error with std::subtract_with_carry_engine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107466 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug libstdc++/107852] [12 Regression] Spurious warnings stringop-overflow and array-bounds copying data as bytes into vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107852 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Known to work||12.2.1 Known to fail||12.2.0 Resolution|--- |FIXED --- Comment #14 from Richard Biener --- The diagnostic is fixed on the branch as well (just checked).
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 107852, which changed state. Bug 107852 Summary: [12 Regression] Spurious warnings stringop-overflow and array-bounds copying data as bytes into vector https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107852 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 107852, which changed state. Bug 107852 Summary: [12 Regression] Spurious warnings stringop-overflow and array-bounds copying data as bytes into vector https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107852 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug libstdc++/109647] New: ranges:6151:14: error: requires clause differs in template redeclaration rejected by clang++ 16.0.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109647
Bug ID: 109647
Summary: ranges:6151:14: error: requires clause differs in
template redeclaration rejected by clang++ 16.0.2
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: redi at gcc dot gnu.org
Target Milestone: ---
Apparently, clang++ 16.0.2 can't digest libstdc++ version of ranges header
file:
echo '#include ' | clang++ -x c++ - -c -std=c++2b
In file included from :1:
/usr/bin/../lib64/gcc/x86_64-suse-linux/13/../../../../include/c++/13/ranges:6151:14:
error: requires clause differs in template redeclaration
requires forward_range<_Vp>
^
/usr/bin/../lib64/gcc/x86_64-suse-linux/13/../../../../include/c++/13/ranges:5850:14:
note: previous template declaration is here
requires input_range<_Vp>
^
/usr/bin/../lib64/gcc/x86_64-suse-linux/13/../../../../include/c++/13/ranges:8846:20:
error: type-id cannot have a name
{ return (auto(__x) += __y); }
^
/usr/bin/../lib64/gcc/x86_64-suse-linux/13/../../../../include/c++/13/ranges:8846:25:
error: expected ')'
{ return (auto(__x) += __y); }
^
/usr/bin/../lib64/gcc/x86_64-suse-linux/13/../../../../include/c++/13/ranges:8846:14:
note: to match this '('
{ return (auto(__x) += __y); }
^
/usr/bin/../lib64/gcc/x86_64-suse-linux/13/../../../../include/c++/13/ranges:8846:32:
error: expected expression
{ return (auto(__x) += __y); }
^
4 errors generated.
$ echo '#include ' | g++-13 -x c++ - -c -std=c++2b
(ok)
[Bug tree-optimization/107087] [12 Regression] bits/stl_algobase.h:431: warning: 'void* __builtin_memcpy(void*, const void*, unsigned int)' reading between 8 and 2147483644 bytes from a region of siz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107087 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Known to work|12.2.1 |11.3.0, 13.0 Known to fail|13.0|12.2.0 --- Comment #13 from Richard Biener --- I verified that picking this change fixes the diagnostic on the branch as well. I have no opinion as to how dangerous this is.
[Bug ipa/109639] [14 regression] Internal compiler error: tree check: expected integer_cst, have addr_expr in to_wide, at tree.h:6283 since r14-249-g3c9372dfee0bb8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109639 --- Comment #15 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:2b8ac1df6493eb1789c7c4d9f3df280ef9cf0ac4 commit r14-298-g2b8ac1df6493eb1789c7c4d9f3df280ef9cf0ac4 Author: Aldy Hernandez Date: Thu Apr 27 12:05:36 2023 +0200 Normalize addresses in IPA before calling range_op_handler [PR109639] The old legacy code would allow building ranges containing symbolics, even though the entire ranger ecosystem does not handle them. These were normalized into non-zero ranges by helper functions in VRP (range_fold_*_expr) before calling the ranger. The only users of these functions should have been legacy VRP, which is no more. However, a handful of users crept into IPA, even though these functions shouldn't never been called outside of VRP or vr-values. The issue here is that IPA is building a range of [&foo, &foo] and expecting range_fold_binary to normalize it to non-zero. Fixed by adding a helper function before calling the range_op handler. I think these covers the problematic ranges. If not, I'll come up with something more generalized that does not involve polluting irange::set with the normalization code. After all, this only involves a handful of IPA places. I've also added an assert in irange::set() making it easier to detect any possible fallout without having to drill deep into the setter. gcc/ChangeLog: PR tree-optimization/109639 * ipa-cp.cc (ipa_value_range_from_jfunc): Normalize range. (propagate_vr_across_jump_function): Same. * ipa-fnsummary.cc (evaluate_conditions_for_known_args): Same. * ipa-prop.h (ipa_range_set_and_normalize): New. * value-range.cc (irange::set): Assert min and max are INTEGER_CST.
[Bug ipa/109639] [14 regression] Internal compiler error: tree check: expected integer_cst, have addr_expr in to_wide, at tree.h:6283 since r14-249-g3c9372dfee0bb8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109639 Aldy Hernandez changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #16 from Aldy Hernandez --- fixed
[Bug tree-optimization/107087] [12 Regression] bits/stl_algobase.h:431: warning: 'void* __builtin_memcpy(void*, const void*, unsigned int)' reading between 8 and 2147483644 bytes from a region of siz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107087 --- Comment #14 from Jonathan Wakely --- I think it should be fine. I would prefer to wait until 12.4 so it has more bake time, but that would just mean another few months of duplicate reports for this issue.
[Bug tree-optimization/106878] [11/12 Regression] ICE: verify_gimple failed at -O2 with pointers and bitwise calculation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106878 Richard Biener changed: What|Removed |Added Keywords||ice-checking --- Comment #14 from Richard Biener --- Iff then I think we want to backport all but the verifier changes.
[Bug target/107131] [11/12 Regression] wrong code with -Os -fno-ipa-vrp -fno-tree-bit-ccp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107131
--- Comment #11 from Richard Biener ---
(In reply to Jakub Jelinek from comment #8)
> I think the problem happens during combine. Parts of the vector code
> related to:
> V b = (V) { } >= o;
> V c = b <= (V)(b >= (V) { 0, 0, 0, 0, 0, 0x90DF0BE3990AC871ULL });
> - in particular the scalar c[5] computation, i.e.
> unsigned long long b = 0 >= o ? -1ULL : 0ULL;
> unsigned long long c = b <= (b >= 0x90DF0BE3990AC871ULL ? -1ULL : 0ULL) ?
> -1ULL : 0ULL;
> evaluates to 0 rather than -1 that it should when o is 0.
>
> This boils down to:
> __attribute__((noipa)) unsigned long long
> foo (unsigned char o)
> {
> unsigned long long t1 = -(long long) (o == 0);
> unsigned long long t2 = -(long long) (t1 > 10439075533421201520ULL);
> unsigned long long t3 = -(long long) (t1 <= t2);
> return t3;
> }
>
> int
> main ()
> {
> if (foo (0) != -1ULL)
> __builtin_abort ();
> return 0;
> }
> at -O2 or -Os, which was miscompiled starting with r12-303-g86403f4e6e5f7216
> and got fixed with r13-3530-g0e36a9c6915c713d30.
> No idea why this is marked as 11 regression though...
>
> So, do we need to backport PR107172 change to 12 branch?
Yes. Testing that now.
[Bug target/107131] [11/12 Regression] wrong code with -Os -fno-ipa-vrp -fno-tree-bit-ccp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107131
--- Comment #12 from Richard Biener ---
(In reply to Richard Biener from comment #11)
> (In reply to Jakub Jelinek from comment #8)
> > I think the problem happens during combine. Parts of the vector code
> > related to:
> > V b = (V) { } >= o;
> > V c = b <= (V)(b >= (V) { 0, 0, 0, 0, 0, 0x90DF0BE3990AC871ULL });
> > - in particular the scalar c[5] computation, i.e.
> > unsigned long long b = 0 >= o ? -1ULL : 0ULL;
> > unsigned long long c = b <= (b >= 0x90DF0BE3990AC871ULL ? -1ULL : 0ULL) ?
> > -1ULL : 0ULL;
> > evaluates to 0 rather than -1 that it should when o is 0.
> >
> > This boils down to:
> > __attribute__((noipa)) unsigned long long
> > foo (unsigned char o)
> > {
> > unsigned long long t1 = -(long long) (o == 0);
> > unsigned long long t2 = -(long long) (t1 > 10439075533421201520ULL);
> > unsigned long long t3 = -(long long) (t1 <= t2);
> > return t3;
> > }
> >
> > int
> > main ()
> > {
> > if (foo (0) != -1ULL)
> > __builtin_abort ();
> > return 0;
> > }
> > at -O2 or -Os, which was miscompiled starting with r12-303-g86403f4e6e5f7216
> > and got fixed with r13-3530-g0e36a9c6915c713d30.
> > No idea why this is marked as 11 regression though...
> >
> > So, do we need to backport PR107172 change to 12 branch?
>
> Yes. Testing that now.
Not. Not picking cleanly.
[Bug tree-optimization/106878] [11/12 Regression] ICE: verify_gimple failed at -O2 with pointers and bitwise calculation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106878 --- Comment #15 from Jakub Jelinek --- Just note this had various follow-ups. r13-2658 r13-2709 r13-2891 at least.
[Bug c++/108309] [12 Regression] ICE in in cxx_eval_component_reference, at cp/constexpr.cc:4136
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108309 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/108833] [11/12 Regression] internal compiler error: Segmentation fault (GCC 12.1.1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108833 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug libstdc++/109647] ranges:6151:14: error: requires clause differs in template redeclaration rejected by clang++ 16.0.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109647 Jonathan Wakely changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jonathan Wakely --- This is a clang bug. The primary template on line 5850 has these constraints: template requires input_range<_Vp> class chunk_view : public view_interface> But then there is a partial specialization for forward_range on line 6075: template requires forward_range<_Vp> class chunk_view<_Vp> : public view_interface> The error on line 6151 incorrectly says that the definition is inconstistent with line 5850. That's true, but it's a definition for the one on line 6075 instead.
[Bug libstdc++/109647] ranges:6151:14: error: requires clause differs in template redeclaration rejected by clang++ 16.0.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109647 --- Comment #2 from Jonathan Wakely --- As already explained in Bug 96830 comment 8 This is https://github.com/llvm/llvm-project/issues/49620 which is fixed on trunk, but still present in Clang 16.0.0
[Bug tree-optimization/109170] [13 Regression] New glibc warning: open_catalog.c:86:16: error: pointer ‘old_buf’ may be used after ‘realloc’ [-Werror=use-after-free] since r13-6707-g0a07bfad12530bca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109170 --- Comment #7 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:65369ab62cee68eb7f6ef65e3d12d1969a9e20ee commit r14-300-g65369ab62cee68eb7f6ef65e3d12d1969a9e20ee Author: Richard Biener Date: Fri Mar 17 13:14:49 2023 +0100 tree-optimization/109170 - bogus use-after-free with __builtin_expect The following generalizes the range-op for __builtin_expect by using the fnspec machinery. PR tree-optimization/109170 * gimple-range-op.cc (gimple_range_op_handler::maybe_builtin_call): Handle __builtin_expect and similar via cfn_pass_through_arg1 and inspecting the calls fnspec. * builtins.cc (builtin_fnspec): Handle BUILT_IN_EXPECT and BUILT_IN_EXPECT_WITH_PROBABILITY.
[Bug libstdc++/97936] [11/12 Regression] 30_threads/latch/3.cc hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97936 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #21 from Jonathan Wakely --- Reclosing, the problem with the non-futex path was dealt with as PR 106183
[Bug libgomp/109646] OpenACC attach directive fails with "pointer target not mapped for attach"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109646 --- Comment #1 from Patrick Bégou --- Using 12.2.1 as more recent versions of gfortran cannot compile this file (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109622)
[Bug c++/106057] Missed stmt_can_throw_external check in stmt_kills_ref_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106057 --- Comment #5 from CVS Commits --- The releases/gcc-12 branch has been updated by Richard Biener : https://gcc.gnu.org/g:ea162107bb376f5ffa18bbda70e14b47bc338070 commit r12-9478-gea162107bb376f5ffa18bbda70e14b47bc338070 Author: Jan Hubicka Date: Fri Aug 12 16:25:28 2022 +0200 Fix invalid devirtualization when combining final keyword and anonymous types this patch fixes a wrong code issue where we incorrectly devirtualize to __builtin_unreachable. The problem occurs in combination of anonymous namespaces and final keyword used on methods. We do two optimizations here 1) when reacing final method we cut the search for possible new targets 2) if the type is anonymous we detect whether it is ever instatiated by looking if its vtable is referred to. Now this goes wrong when thre is an anonymous type with final method that is not instantiated while its derived type is. So if 1 triggers we need to make 2 to look for vtables of all derived types as done by this patch. Bootstrpaped/regtested x86_64-linux Honza gcc/ChangeLog: 2022-08-10 Jan Hubicka PR middle-end/106057 * ipa-devirt.cc (type_or_derived_type_possibly_instantiated_p): New function. (possible_polymorphic_call_targets): Use it. gcc/testsuite/ChangeLog: 2022-08-10 Jan Hubicka PR middle-end/106057 * g++.dg/tree-ssa/pr101839.C: New test. (cherry picked from commit 0f2c7ccd14a29a8af8318f50b8296098fb0ab218)
[Bug rtl-optimization/106421] [10/11/12 Regression] ICE with computed goto from a nested functon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106421 --- Comment #5 from CVS Commits --- The releases/gcc-12 branch has been updated by Richard Biener : https://gcc.gnu.org/g:0a5fb0ee337b824224a2c13b76fd682b62e6d314 commit r12-9480-g0a5fb0ee337b824224a2c13b76fd682b62e6d314 Author: Roger Sayle Date: Tue Jan 10 14:05:46 2023 + PR rtl-optimization/106421: ICE in bypass_block from non-local goto. This patch fixes PR rtl-optimization/106421, an ICE-on-valid (but undefined) regression. The fix, as proposed by Richard Biener, is to defend against BLOCK_FOR_INSN returning NULL in cprop's bypass_block. 2023-01-10 Roger Sayle gcc/ChangeLog PR rtl-optimization/106421 * cprop.cc (bypass_block): Check that DEST is local to this function (non-NULL) before calling find_edge. gcc/testsuite/ChangeLog PR rtl-optimization/106421 * gcc.dg/pr106421.c: New test case. (cherry picked from commit 851e1ba03f9de699a754dd8648fc151c3e26d697)
[Bug tree-optimization/109392] [12 Regression] ICE in tree_vec_extract, at tree-vect-generic.cc:177 since r12-117-gb972e036f40c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109392 --- Comment #6 from CVS Commits --- The releases/gcc-12 branch has been updated by Richard Biener : https://gcc.gnu.org/g:d639236ea87ff8a6a2d56c0408e6eb92674418e6 commit r12-9482-gd639236ea87ff8a6a2d56c0408e6eb92674418e6 Author: Jakub Jelinek Date: Sat Apr 8 12:21:42 2023 -0600 PR tree-optimization/109392 If we have an object with SSA_NAME_OCCURS_IN_ABNORMAL_PHI, then maybe_push_res_to_seq may fail. Directly build the extraction for that case. PR tree-optimization/109392 gcc/ * tree-vect-generic.cc (tree_vec_extract): Handle failure of maybe_push_res_to_seq better. gcc/testsuite/ * gcc.dg/pr109392.c: New test. (cherry picked from commit 101380a8394c22a7a2ea70de2060ee93716156e2)
[Bug target/105980] [11/12 Regression] ICE in final_scan_insn_1, at final.cc:2811
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105980 --- Comment #11 from CVS Commits --- The releases/gcc-12 branch has been updated by Richard Biener : https://gcc.gnu.org/g:37da428922e5cb548430aa00482d6a4c7aa8f8b2 commit r12-9479-g37da428922e5cb548430aa00482d6a4c7aa8f8b2 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. (cherry picked from commit a396a123596d82d4a2f14dc43a382cb17826411c)
[Bug tree-optimization/108791] [12 Regression] ICE: verify_gimple failed since r12-2733-g31855ba6b16cd138
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108791 --- Comment #8 from CVS Commits --- The releases/gcc-12 branch has been updated by Richard Biener : https://gcc.gnu.org/g:fcf27816635186acce77dd9b6d756d5c93fd92ef commit r12-9481-gfcf27816635186acce77dd9b6d756d5c93fd92ef Author: Richard Biener Date: Wed Feb 15 14:00:21 2023 +0100 tree-optimization/108791 - checking ICE with sloppy ADDR_EXPR The following fixes a checking ICE by choosing a more appropriate type for an ADDR_EXPR built by forwprop. PR tree-optimization/108791 * tree-ssa-forwprop.cc (optimize_vector_load): Build the ADDR_EXPR of a TARGET_MEM_REF using a more meaningful type. * gcc.dg/torture/pr108791.c: New testcase. (cherry picked from commit 441c466fd4d8b9afd99f585f7c4bfade911c4652)
[Bug tree-optimization/108791] [12 Regression] ICE: verify_gimple failed since r12-2733-g31855ba6b16cd138
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108791 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Known to fail||12.2.0 Resolution|--- |FIXED --- Comment #9 from Richard Biener --- Fixed.
[Bug tree-optimization/109392] [12 Regression] ICE in tree_vec_extract, at tree-vect-generic.cc:177 since r12-117-gb972e036f40c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109392 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Known to fail||12.2.0 --- Comment #7 from Richard Biener --- Fixed.
[Bug ipa/101839] [10/11 Regression] Hang in C++ code with -fdevirtualize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101839 Richard Biener changed: What|Removed |Added Known to fail||12.2.0 Known to work||12.2.1 Summary|[10/11/12 Regression] Hang |[10/11 Regression] Hang in |in C++ code with|C++ code with |-fdevirtualize |-fdevirtualize --- Comment #13 from Richard Biener --- And on the 12 branch with r12-9478-gea162107bb376f
[Bug target/109632] Inefficient codegen when complex numbers are emulated with structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109632 --- Comment #7 from rsandifo at gcc dot gnu.org --- Thinking more about it, it would probably be better to defer the split until around lower_complex time, after IPA (especially inlining), NRV and tail-recursion. Doing it there should also make it easier to split arguments. (In reply to Tamar Christina from comment #6) > That's an interesting approach, I think it would also fix > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109391 would it not? Since the > int16x8x3_t return would be "scalarized" avoiding the bad expansion? I don't think it will help with that, since the returned value there is a natural V3x8HI (rather than something that the ABI splits apart). Splitting in that case might pessimise cases where the return value is loaded as a whole, rather than assigned to individually. But it might be worth giving SRA the option of splitting even in that case, as a follow-on optimisation, if it fits naturally with the definitions.
[Bug fortran/47485] gfortran -M output is incorrect when -MT option is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47485 Volker Weißmann changed: What|Removed |Added CC||volker.weissmann at gmx dot de --- Comment #6 from Volker Weißmann --- Still present in gcc 12.2.1 This bug still creates problems for meson's fortran support. Please fix.
[Bug libstdc++/107466] [12 Regression] invalid -Wnarrowing error with std::subtract_with_carry_engine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107466 --- Comment #7 from CVS Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:d8def0b55572fc5bc02a0fee6a98787cd50ee885 commit r12-9485-gd8def0b55572fc5bc02a0fee6a98787cd50ee885 Author: Jonathan Wakely Date: Mon Nov 28 09:44:52 2022 + libstdc++: Make 16-bit std::subtract_with_carry_engine work [PR107466] This implements the proposed resolution of LWG 3809, so that std::subtract_with_carry_engine can be used with a 16-bit result_type. Currently this produces a narrowing error when instantiating the std::linear_congruential_engine to create the initial state. It also truncates the default_seed constant when passing it as a result_type argument. Change the type of the constant to uint_least32_t and pass 0u when the default_seed should be used. libstdc++-v3/ChangeLog: PR libstdc++/107466 * include/bits/random.h (subtract_with_carry_engine): Use 32-bit type for default seed. Use 0u as default argument for subtract_with_carry_engine(result_type) constructor and seed(result_type) member function. * include/bits/random.tcc (subtract_with_carry_engine): Use 32-bit type for default seed and engine used for initial state. * testsuite/26_numerics/random/subtract_with_carry_engine/cons/lwg3809.cc: New test. (cherry picked from commit a64775a0edd46980036b757041f0c065ed9f8d22)
[Bug libstdc++/109339] [12 Regression] stop_token compiled with -Og yields maybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109339 --- Comment #14 from CVS Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:47880309516fd5c913102eb4c52dc86da7051983 commit r12-9486-g47880309516fd5c913102eb4c52dc86da7051983 Author: Jonathan Wakely Date: Fri Mar 31 13:38:14 2023 +0100 libstdc++: Avoid -Wmaybe-uninitialized warning in std::stop_source [PR109339] We pass a const-reference to *this before it's constructed, and GCC assumes that all const-references are accessed. Add the access attribute to say it's not accessed. libstdc++-v3/ChangeLog: PR libstdc++/109339 * include/std/stop_token (_Stop_state_ptr(const stop_source&)): Add attribute access with access-mode 'none'. * testsuite/30_threads/stop_token/stop_source/109339.cc: New test. (cherry picked from commit a35e8042fbc7a3eb9cece1fba4cdd3b6cdfb906f)
[Bug libstdc++/109339] [12 Regression] stop_token compiled with -Og yields maybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109339 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #15 from Jonathan Wakely --- Fixed for 12.3
[Bug libstdc++/108952] [10/11/12 Regression] Regression in uses_allocator_construction_args for pair of rvalue references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108952 --- Comment #9 from CVS Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:858ff5c919fc1af31e399a7aea118c87f855972a commit r12-9487-g858ff5c919fc1af31e399a7aea118c87f855972a Author: Jonathan Wakely Date: Mon Feb 27 22:34:57 2023 + libstdc++: Fix uses_allocator_construction_args for pair [PR108952] This implements LWG 3527 which fixes the handling of pair in std::uses_allocator_construction_args. libstdc++-v3/ChangeLog: PR libstdc++/108952 * include/bits/uses_allocator_args.h (uses_allocator_construction_args): Implement LWG 3527. * testsuite/20_util/pair/astuple/get-2.cc: New test. * testsuite/20_util/scoped_allocator/108952.cc: New test. * testsuite/20_util/uses_allocator/lwg3527.cc: New test. (cherry picked from commit 8e342c04550466ab088c33746091ce7f3498ee44)
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 109339, which changed state. Bug 109339 Summary: [12 Regression] stop_token compiled with -Og yields maybe-uninitialized https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109339 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug libstdc++/107466] [12 Regression] invalid -Wnarrowing error with std::subtract_with_carry_engine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107466 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Jonathan Wakely --- Fixed for 12.3
[Bug libstdc++/108952] [10/11 Regression] Regression in uses_allocator_construction_args for pair of rvalue references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108952 Jonathan Wakely changed: What|Removed |Added Summary|[10/11/12 Regression] |[10/11 Regression] |Regression in |Regression in |uses_allocator_construction |uses_allocator_construction |_args for pair of rvalue|_args for pair of rvalue |references |references --- Comment #10 from Jonathan Wakely --- Fixed for 12.3 too.
[Bug c++/109648] New: ICE: tree check: expected type_pack_expansion or expr_pack_expansion, have error_mark in tsubst_pack_expansion, at cp/pt.cc:13551
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109648
Bug ID: 109648
Summary: ICE: tree check: expected type_pack_expansion or
expr_pack_expansion, have error_mark in
tsubst_pack_expansion, at cp/pt.cc:13551
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
struct S {
int operator[](int);
};
auto foo(auto v) {
return [&] {
return (v()[Is] + ...);
}.template operator()<>();
}
auto test() {
auto v = [] { return S{}; };
return [&] {
return (foo(v()[Is]) + ...);
}.template operator()<>();
}
int main() {
test();
}
https://godbolt.org/z/Ye89xfKdY
[Bug c++/109506] [10/11/12/13/14 regression] -fchecking=2 causes some template constructor not be instantiated when used with NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109506 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug c++/109645] ice in instantiate_decl, at cp/pt.cc:27097
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109645 David Binderman changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #4 from David Binderman --- (In reply to David Binderman from comment #3) > (In reply to David Binderman from comment #2) > > Attempting a bisection. > > Current range is a8e1551bdb372aa3..d94ca762f6e0e4f1. Latest range is d60cbbfaa9a3ad3b..d94ca762f6e0e4f1, which is 6 commits. Two of those commits are by Jason Merrill and are the only commits in the C++ area. Adding Jason for their best advice.
[Bug c/90885] GCC should warn about 2^16 and 2^32 and 2^64 [-Wxor-used-as-pow]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90885 warp at iki dot fi changed: What|Removed |Added CC||warp at iki dot fi --- Comment #30 from warp at iki dot fi --- Note that a few of the examples in that first tweet are actually misleading. More particularly, the example in png.c. At first glance it looks like C and an example of this mistake, but if you look at the context it becomes clear that it actually isn't C at all (because that line appears in a context where it would be illegal code, namely, inside the initialization list of an array). It's actually BC code embedded in the C source code, for some reason. In BC 2^32 is legitimately 2 to the power of 32. The other examples are probably legitimate, though.
[Bug c++/109642] False Positive -Wdangling-reference with std::span-like classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109642 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- Sorry, you need to use #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wdangling-reference" ... #pragma GCC diagnostic pop when using MySpan here, because the compiler can't figure out it's std::span-like.
[Bug c++/109649] New: GCC accepts invalid inaccessible friend declaration of member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109649
Bug ID: 109649
Summary: GCC accepts invalid inaccessible friend declaration of
member function
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jlame646 at gmail dot com
Target Milestone: ---
The following invalid programs explained here:
https://stackoverflow.com/a/76120963/12002570 can be compiled with gcc but
rejected by msvc and clang. See demo: https://godbolt.org/z/Mz8cq3G5n
```
template
class X {
void f(){}
};
class Y
{
friend void X::f();
};
int main()
{
X t;
t.f();
Y b;
}
```
As we can note the above program compiles with gcc trunk.
[Bug c++/109640] Spurious Wdangling-reference for argument to temporary lambda cast to rvalue reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109640 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- We could probably disable the warning when the temporary is of empty class type?
[Bug c++/109649] [13/14 Regression] GCC accepts invalid inaccessible friend declaration of member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109649 Andrew Pinski changed: What|Removed |Added Known to fail||13.1.0 Status|UNCONFIRMED |NEW Known to work||12.2.0 Ever confirmed|0 |1 Keywords||needs-bisection Summary|GCC accepts invalid |[13/14 Regression] GCC |inaccessible friend |accepts invalid |declaration of member |inaccessible friend |function|declaration of member ||function Target Milestone|--- |13.2 Last reconfirmed||2023-04-27 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug target/108239] -mprefixed causes too large displacements for extended inline asm memory operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108239 Peter Bergner changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Peter Bergner --- This is a dup or PR105325. *** This bug has been marked as a duplicate of bug 105325 ***
[Bug target/105325] power10: Error: operand out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105325 Peter Bergner changed: What|Removed |Added CC||npiggin at gmail dot com --- Comment #15 from Peter Bergner --- *** Bug 108239 has been marked as a duplicate of this bug. ***
[Bug libstdc++/40380] class documentation should mention include file to use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40380 --- Comment #9 from Jonathan Wakely --- Grr, I've just noticed that classes defined in a header with no file extension do not get an implicit @headerfile, the way that classes defined in a foo.h header do. See https://github.com/doxygen/doxygen/issues/10010 This is frustrating for libstdc++, because **none** of the public headers have an extension, so we can't rely on all the contents of e.g. getting a correct #include displayed. The _only_ classes which show a #include are the ones in a .h file where it's always wrong (until we add an explicit @headerfile to them). So unless that doxygen issue gets fixed, we need an explicit @headerfile on every single class in the library. Sigh.
[Bug target/105325] power10: Error: operand out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105325
Peter Bergner changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
||il/gcc-patches/2023-April/6
||16805.html
--- Comment #16 from Peter Bergner ---
Another test case from Nick's dup bugzilla (PR108239):
--- test.c ---
// powerpc64le-linux-gnu-gcc -O2 -mcpu=power10 -mno-pcrel -c test.c
#include
static inline uint32_t readl(uint32_t *addr)
{
uint32_t ret;
__asm__ __volatile__("lwz %0,%1" : "=r" (ret) : "m" (*addr));
return ret;
}
int test(void *addr)
{
return readl(addr + 0x8024);
}
[Bug c++/109649] [13/14 Regression] GCC accepts invalid inaccessible friend declaration of member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109649 Marek Polacek changed: What|Removed |Added Keywords|needs-bisection | CC||jason at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Changed in r13-55-ge9d2adc17d0dbe: commit e9d2adc17d0dbe46db67e1b618dea888d5c7aca3 Author: Jason Merrill Date: Fri Apr 8 13:48:25 2022 -0400 c++: reorganize friend template matching [PR91618]
[Bug c++/109623] constexpr restrictions are not relaxed enough
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109623 Marek Polacek changed: What|Removed |Added Last reconfirmed||2023-04-27 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Most likely, mine thus.
[Bug c++/109645] ice in instantiate_decl, at cp/pt.cc:27097
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109645 --- Comment #5 from David Binderman --- This commit commit 95d4c0d2e6318aef88ba0bc607dfc1ec6b7a612f Author: Jason Merrill Date: Thu Mar 16 16:55:39 2023 -0400 c++: restore instantiate_decl assert looks to be a hot candidate.
[Bug target/109610] [14 regression] gcc.target/powerpc/dform-3.c fails after r14-172-g0368d169492017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109610 Peter Bergner changed: What|Removed |Added CC||meissner at gcc dot gnu.org, ||segher at gcc dot gnu.org --- Comment #8 from Peter Bergner --- Adding Mike and Segher for their input.
[Bug c/109650] New: avr-gcc incorrect code with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109650
Bug ID: 109650
Summary: avr-gcc incorrect code with -Os
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: thierer at web dot de
Target Milestone: ---
Created attachment 54942
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54942&action=edit
preprocessed input file
The attached file imho creates invalid code with avr-gcc 12.2.0 when compiling
with "-Os". The same code works with either different optimization settings or
avr-gcc 11.3.0 (haven't tried any other versions).
The misbehaving code is this function:
static bool test_func(uint8_t p1, uint8_t p2) {
if (p1 == 0 || p1 > 7)
return false;
if (p1 < 3) return p2 <= 8;
else if (p1 < 5) return p2 <= 6;
else if (p1 < 7) return p2 <= 4;
else return p2 <= 2;
}
It should return false for all values of p2 if p1 is 0 or > 7 and the result
should depend on p2 for inbetween values of p1.
The code contains a lot of boilerplate for sending a showcase output over
USART0. This is the result for values of 0 <= p2 < 10 (columns) for 0 < p1 < 9
(rows):
0123456789
0 ??
1 X?
2 X?
3 XX
4 XX
5 ??
6 ??
7 XX
8 ??
"X" means test_func() returned true, "?" false. The result for p1 in [0,1,2,8]
is correct, all the other results are off (too low) by 1. For example, for p1
== 3 the function should return true for all p2 <= 6, but it only does for <=
5.
I'm not too familiar with AVR assembly, but the problem seems to be that the
comparisons that calculate the result value all use the same brlo (branch if
lower) instruction at .L34, but the compiler fails to compensate for the
"lower" instead of "lower or equal" for all but the first (<= 8) condition:
.L21:
cpi r17,lo8(7)
brsh .L25
cpi r28,lo8(3)
brsh .L12
cpi r29,lo8(9) ; this correctly compares to 9 == 8+1
.L34:
brlo .L27
.L25:
ldi r24,lo8(63)
.L11:
[...]
.L12:
cpi r28,lo8(5)
brsh .L15
cpi r29,lo8(6) ; but this does not (should be 6+1 == 7)
rjmp .L34
.L15:
cpi r28,lo8(7)
breq .L17
cpi r29,lo8(4) ; neither does this (should be 4+1 == 5)
rjmp .L34
.L17:
cpi r29,lo8(2) ; nor this (should be 2+1 == 3)
rjmp .L34
.L27:
Tested with the respective Arch Linux x86_64 avr-gcc packages.
Output of "avr-gcc -v":
> avr-gcc -v -save-temps -Wall -Wextra -mmcu=atmega1284p -Os
> --param=min-pagesize=0 avr-bug.c
Using built-in specs.
Reading specs from /usr/lib/gcc/avr/12.2.0/device-specs/specs-atmega1284p
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/12.2.0/lto-wrapper
Target: avr
Configured with: /build/avr-gcc/src/gcc-12.2.0/configure
--disable-install-libiberty --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-linker-build-id --disable-nls
--disable-werror --disable-__cxa_atexit --enable-checking=release
--enable-clocale=gnu --enable-gnu-unique-object --enable-gold
--enable-languages=c,c++ --enable-ld=default --enable-lto --enable-plugin
--enable-shared --infodir=/usr/share/info --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --prefix=/usr --target=avr
--with-as=/usr/bin/avr-as --with-gnu-as --with-gnu-ld --with-ld=/usr/bin/avr-ld
--with-plugin-ld=ld.gold --with-system-zlib --with-isl
--enable-gnu-indirect-function
Thread model: single
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-Os'
'--param=min-pagesize=0' '-mdouble=32' '-mlong-double=64'
'-specs=device-specs/specs-atmega1284p' '-mmcu=avr51' '-dumpdir' 'a-'
/usr/lib/gcc/avr/12.2.0/cc1 -E -quiet -v -imultilib avr51
-D__AVR_ATmega1284P__ -D__AVR_DEVICE_NAME__=atmega1284p avr-bug.c -mn-flash=2
-mno-skip-bug -mdouble=32 -mlong-double=64 -mmcu=avr51 -Wall -Wextra -Os
-fpch-preprocess -o a-avr-bug.i
ignoring nonexistent directory
"/usr/lib/gcc/avr/12.2.0/../../../../avr/sys-include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/avr/12.2.0/include
/usr/lib/gcc/avr/12.2.0/include-fixed
/usr/lib/gcc/avr/12.2.0/../../../../avr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-Os'
'--param=min-pagesize=0' '-mdouble=32' '-mlong-double=64'
'-specs=device-specs/specs-atmega1284p' '-mmcu=avr51' '-dumpdir' 'a-'
/usr/lib/gcc/avr/12.2.0/cc1 -fpreprocessed a-avr-bug.i -mn-flash=2
-mno-skip-bug -quiet -dumpdir a- -dumpbase avr-bug.c -dumpbase-ext .c
-mdouble=32 -mlong-double=64 -mmcu=avr51 -Os -Wall -Wextra -version
--param=min-pagesize=0 -o a-avr-bug.s
GNU C17 (GCC) version 12.2.0 (avr)
compiled by GNU C version 12.1.1 20220730, GMP version 6.2
[Bug c++/109651] New: ICE in lookup_template_class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109651 Bug ID: 109651 Summary: ICE in lookup_template_class Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jeanmichael.celerier at gmail dot com Target Milestone: --- g++ version: g++ (SUSE Linux) 13.0.1 20230421 (prerelease) [revision f980561c60b0446cc427595198d7f3f4f90e0924] as shipped by opensuse tumbleweed (reproducible in the official opensuse/tumbleweed:latest container) preprocessed source as given by -freport-bug attached. /usr/bin/g++-13 -DBOOST_ASIO_DISABLE_CONCEPTS=1 -DBOOST_MATH_DISABLE_FLOAT128=1 -DBOOST_NO_RTTI=1 -DLIBREMIDI_ALSA -DLIBREMIDI_JACK -DQT_CORE_LIB -DQT_DISABLE_DEPRECATED_BEFORE=0x0605ff -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_NO_JAVA_STYLE_ITERATORS -DQT_NO_KEYWORDS -DQT_NO_LINKED_LIST -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_NO_USING_NAMESPACE -DQT_OPENGL_LIB -DQT_QMLINTEGRATION_LIB -DQT_QML_LIB -DQT_SERIALPORT_LIB -DQT_SHADERTOOLS_LIB -DQT_STATEMACHINE_LIB -DQT_USE_QSTRINGBUILDER -DQT_WEBSOCKETS_LIB -DQT_WIDGETS_LIB -DRAPIDJSON_HAS_STDSTRING=1 -DSCORE_ADDON_NETWORK_EXPORTS -DSCORE_LIB_BASE -DSCORE_LIB_DEVICE -DSCORE_LIB_INSPECTOR -DSCORE_LIB_LOCALTREE -DSCORE_LIB_PCH_EXPORTS -DSCORE_LIB_PROCESS -DSCORE_LIB_STATE -DSCORE_PLUGIN_AUDIO -DSCORE_PLUGIN_AUTOMATION -DSCORE_PLUGIN_AVND -DSCORE_PLUGIN_CURVE -DSCORE_PLUGIN_DATAFLOW -DSCORE_PLUGIN_DEVICEEXPLORER -DSCORE_PLUGIN_ENGINE -DSCORE_PLUGIN_GFX -DSCORE_PLUGIN_LIBRARY -DSCORE_PLUGIN_MEDIA -DSCORE_PLUGIN_SCENARIO -DSCORE_PLUGIN_TRANSPORT -DSERVUS_USE_AVAHI_CLIENT -DTINYSPLINE_DOUBLE_PRECISION -I/tmp/build/src/addons/iscore-addon-network -I/ossia/score/src/addons/iscore-addon-network -I/tmp/build -I/ossia/score/3rdparty -I/ossia/score/3rdparty/zipdownloader/src -I/ossia/score/3rdparty/QProgressIndicator -I/ossia/score/3rdparty/Qt-Color-Widgets -I/ossia/score/3rdparty/Qt-Color-Widgets/src -I/ossia/score/3rdparty/Qt-Color-Widgets/QtColorWidgets -I/ossia/score/3rdparty/libossia/3rdparty/verdigris/src -I/tmp/build/src/lib -I/ossia/score/src/lib -I/ossia/score/3rdparty/libossia/3rdparty/Flicks -I/ossia/score/3rdparty/libossia/src -I/tmp/build/3rdparty/libossia/src -I/ossia/score/3rdparty/libossia/3rdparty/Servus/servus/.. -I/ossia/score/3rdparty/QCodeEditor/include -I/tmp/build/src/plugins/score-plugin-scenario -I/ossia/score/src/plugins/score-plugin-scenario -I/usr/include/qt6/QtDBus/6.5.0 -I/usr/include/qt6/QtDBus/6.5.0/QtDBus -I/tmp/build/src/plugins/score-lib-process -I/ossia/score/src/plugins/score-lib-process -I/tmp/build/src/plugins/score-lib-state -I/ossia/score/src/plugins/score-lib-state -I/tmp/build/src/plugins/score-lib-inspector -I/ossia/score/src/plugins/score-lib-inspector -I/tmp/build/src/plugins/score-lib-device -I/ossia/score/src/plugins/score-lib-device -I/tmp/build/src/plugins/score-lib-localtree -I/ossia/score/src/plugins/score-lib-localtree -I/tmp/build/src/plugins/score-plugin-deviceexplorer -I/ossia/score/src/plugins/score-plugin-deviceexplorer -I/tmp/build/src/plugins/score-plugin-curve -I/ossia/score/src/plugins/score-plugin-curve -I/tmp/build/src/plugins/score-plugin-automation -I/ossia/score/src/plugins/score-plugin-automation -I/tmp/build/src/plugins/score-plugin-library -I/ossia/score/src/plugins/score-plugin-library -I/tmp/build/src/plugins/score-plugin-transport -I/ossia/score/src/plugins/score-plugin-transport -I/tmp/build/src/plugins/score-plugin-engine -I/ossia/score/src/plugins/score-plugin-engine -I/tmp/build/src/plugins/score-plugin-audio -I/ossia/score/src/plugins/score-plugin-audio -I/tmp/build/src/plugins/score-plugin-avnd -I/ossia/score/src/plugins/score-plugin-avnd -I/tmp/build/src/plugins/score-plugin-media -I/ossia/score/src/plugins/score-plugin-media -I/tmp/build/src/plugins/score-plugin-dataflow -I/ossia/score/src/plugins/score-plugin-dataflow -I/ossia/score/3rdparty/libossia/3rdparty -I/ossia/score/3rdparty/DSPFilters/DSPFilters/include -I/ossia/score/3rdparty/Gamma -I/tmp/build/src/plugins/score-plugin-gfx -I/ossia/score/src/plugins/score-plugin-gfx -I/tmp/build/3rdparty/snappy -I/ossia/score/3rdparty/snappy -isystem /ossia/score/3rdparty/libossia/3rdparty/nano-signal-slot -isystem /ossia/score/3rdparty/libossia/3rdparty/brigand -isystem /ossia/score/3rdparty/libossia/3rdparty/readerwriterqueue -isystem /ossia/score/3rdparty/magicitems/include -isystem /ossia/score/3rdparty/avendish/include -isystem /ossia/score/3rdparty/libossia/3rdparty/boost_1_81_0 -isystem /ossia/score/3rdparty/libossia/3rdparty/rnd/include -isystem /usr/include/qt6/QtCore -isystem /usr/include/qt6 -isystem /usr/lib64/qt6/mkspecs/linux-g++ -isystem /usr/include/qt6/QtGui -isystem /usr/include/qt6/QtGui/6.5.0 -isystem /usr/include/qt6/QtGui/6.5.0/QtGui -isystem /usr/include/qt6/QtCore/6.5.0 -isystem /usr/include/qt6/QtCore/6.5.0/QtCore -isystem /usr/inclu
[Bug c++/109651] ICE in lookup_template_class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109651 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- It appears that the preprocessed source file isn't attached.
[Bug c++/109651] ICE in lookup_template_class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109651 --- Comment #2 from Andrew Pinski --- >preprocessed source as given by -freport-bug attached. The attachment might have been too big, please try to compress it and try again.
