[Bug fortran/100633] ICE: gfc_trans_omp_workshare(): Bad statement code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100633 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:efb6bda7f5136d59be254b10d2b81ba28be8ecfb commit r11-8428-gefb6bda7f5136d59be254b10d2b81ba28be8ecfb Author: Tobias Burnus Date: Mon May 17 13:20:27 2021 +0200 OpenMP/Fortran: Reject nonintrinsic assignments in OMP WORKSHARE [PR100633] PR fortran/100633 gcc/fortran/ChangeLog: * resolve.c (gfc_resolve_code): Reject nonintrinsic assignments in OMP WORKSHARE. gcc/testsuite/ChangeLog: * gfortran.dg/gomp/workshare-59.f90: New test. (cherry picked from commit 582776eb1b62c32f5234566a01ea92247b7d6bcc)
[Bug c++/100646] New: gcc -E -fdirectives-only causes "error: unterminated comment" when no new line at the end of file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100646 Bug ID: 100646 Summary: gcc -E -fdirectives-only causes "error: unterminated comment" when no new line at the end of file Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mtekieli+gcc at gmail dot com Target Milestone: --- $ cat test_gcc11.cpp int main() { } // namespace $ g++ -E -fdirectives-only test_gcc11.cpp -o test_gcc11.o test_gcc11.cpp:4:1: error: unterminated comment 4 | // namespace | ^ Above error occurs when test_gcc11.cpp or anything included in test_gcc11.cpp has a comment with no new line at the end of file. It looks like this patch does not help: https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=b6ecd493886891f8150905a2fd3b7d54e88fc7be It worked fine with gcc 10.
[Bug c++/100281] ICE with SImode pointer assignment in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100281 --- Comment #6 from CVS Commits --- The master branch has been updated by Andreas Krebbel : https://gcc.gnu.org/g:720dff974ea0487c35c0a4bfa527f30df5066ce1 commit r12-857-g720dff974ea0487c35c0a4bfa527f30df5066ce1 Author: Andreas Krebbel Date: Tue Apr 27 10:09:06 2021 +0200 PR100281 C++: Fix SImode pointer handling The problem appears to be triggered by two locations in the front-end where non-POINTER_SIZE pointers aren't handled right now. 1. An assertion in strip_typedefs is triggered because the alignment of the types don't match. This in turn is caused by creating the new type with build_pointer_type instead of taking the type of the original pointer into account. 2. An assertion in cp_convert_to_pointer is triggered which expects the target type to always have POINTER_SIZE. gcc/cp/ChangeLog: PR c++/100281 * cvt.c (cp_convert_to_pointer): Use the size of the target pointer type. * tree.c (cp_build_reference_type): Call cp_build_reference_type_for_mode with VOIDmode. (cp_build_reference_type_for_mode): Rename from cp_build_reference_type. Add MODE argument and invoke build_reference_type_for_mode. (strip_typedefs): Use build_pointer_type_for_mode and cp_build_reference_type_for_mode for pointers and references. gcc/ChangeLog: PR c++/100281 * tree.c (build_reference_type_for_mode) (build_pointer_type_for_mode): Pick pointer mode if MODE argument is VOIDmode. (build_reference_type, build_pointer_type): Invoke build_*_type_for_mode with VOIDmode. gcc/testsuite/ChangeLog: PR c++/100281 * g++.target/s390/pr100281-1.C: New test. * g++.target/s390/pr100281-2.C: New test.
[Bug c++/70834] Incorrect warning for placement new when conditionally used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70834 frankhb1989 at gmail dot com changed: What|Removed |Added CC||frankhb1989 at gmail dot com --- Comment #8 from frankhb1989 at gmail dot com --- (In reply to Martin Sebor from comment #7) > No change in GCC 11. This false positive too will be avoided by running > -Wplacement-new later, when the program is in SSA form, rather than in the > front end. Actually worse in GCC 11. Try this case: #include #include #include #include #include struct hdr_t { void* p_block; }; constexpr auto offset = sizeof(hdr_t) > alignof(hdr_t) ? sizeof(hdr_t) : alignof(hdr_t); void* operator new(std::size_t bytes, std::size_t alignment) { auto space(offset + bytes + alignment); auto ptr(static_cast(std::malloc(space))); void* p(&ptr[offset]); if(std::align(alignment, bytes, p, space)) { (::new(static_cast(static_cast(p) - offset)) hdr_t)->p_block = ptr; // (::new(ptr + (std::size_t(static_cast(p) - ptr)) - offset) hdr_t)->p_block = ptr; return p; } throw std::bad_alloc(); } int main() {} This is warned in G++ 11.1, but not G++ 10.2.
[Bug c++/100644] [11/12 regression] Deleted move constructor prevents templated constructor from being used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100644 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.2 Known to work||10.3.0 Summary|[11 regression] Deleted |[11/12 regression] Deleted |move constructor prevents |move constructor prevents |templated constructor from |templated constructor from |being used |being used Keywords||rejects-valid
[Bug target/100643] [11/12 Regression] ICE in ix86_mangle_function_version_assembler_name, at config/i386/i386-features.c:2809
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100643 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.2
[Bug libstdc++/100631] ranges::elements_view:: _Sentinel is missing __distance_from() that can access _M_current of _Iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100631 --- Comment #7 from 康桓瑋 --- (In reply to CVS Commits from comment #6) > The master branch has been updated by Patrick Palka : > > https://gcc.gnu.org/g:2e2eef80ac0c21f9533e6791ccf5e29458cbb77c > > commit r12-854-g2e2eef80ac0c21f9533e6791ccf5e29458cbb77c > Author: Patrick Palka > Date: Tue May 18 00:26:07 2021 -0400 > > libstdc++: Fix miscellaneous issues with elements_view::_Sentinel > [PR100631] > > libstdc++-v3/ChangeLog: > > PR libstdc++/100631 > * include/std/ranges (elements_view::_Iterator): Also befriend > _Sentinel. > (elements_view::_Sentinel::_M_equal): Templatize. > (elements_view::_Sentinel::_M_distance_from): Split out from ... > (elements_view::_Sentinel::operator-): ... here. Depend on > _Base2 instead of _Base in the return type. > * testsuite/std/ranges/adaptors/elements.cc (test06, test07): > New tests. Hey, Patrick, you missed the second one: template> requires sized_sentinel_for, iterator_t<_Base2>> friend constexpr range_difference_t<_Base2> operator-(const _Iterator<_Const2>& __x, const _Sentinel& __y) { return __x._M_current - __y._M_end; } this should be return -__y._M_distance_from(__x).
[Bug libstdc++/100475] semiregular-box's constructor uses wrong list-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100475 --- Comment #6 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:fe993b469c528230d9a01e1ae2208610f960dd9f commit r12-856-gfe993b469c528230d9a01e1ae2208610f960dd9f Author: Patrick Palka Date: Tue May 18 00:28:44 2021 -0400 libstdc++: Fix up semiregular-box partial specialization [PR100475] This makes the in-place constructor of our partial specialization of __box for already-semiregular types perform direct-non-list-initialization (in accordance with the specification of the primary template), and additionally makes the member function data() use std::__addressof. libstdc++-v3/ChangeLog: PR libstdc++/100475 * include/std/ranges (__box::__box): Use non-list-initialization in member initializer list of in-place constructor of the partial specialization for semiregular types. (__box::operator->): Use std::__addressof. * testsuite/std/ranges/adaptors/detail/semiregular_box.cc (test02): New test. * testsuite/std/ranges/single_view.cc (test04): New test.
[Bug libstdc++/100621] ranges::reverse_view fails to meet its complexity requirements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100621 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:03cf8d54e5c27cfe6b184cc96757cab30d8fa1df commit r12-855-g03cf8d54e5c27cfe6b184cc96757cab30d8fa1df Author: Patrick Palka Date: Tue May 18 00:26:25 2021 -0400 libstdc++: Fix condition for memoizing reverse_view::begin() [PR100621] A range being a random access range isn't a sufficient condition for ranges::next(iter, sent) to have constant time complexity -- it must also have a sized sentinel. This adjusts the memoization condition for reverse_view accordingly. libstdc++-v3/ChangeLog: PR libstdc++/100621 * include/std/ranges (reverse_view::_S_needs_cached_begin): Set to true if the underlying non-common random-access range doesn't have a sized sentinel.
[Bug libstdc++/100631] ranges::elements_view:: _Sentinel is missing __distance_from() that can access _M_current of _Iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100631 --- Comment #6 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:2e2eef80ac0c21f9533e6791ccf5e29458cbb77c commit r12-854-g2e2eef80ac0c21f9533e6791ccf5e29458cbb77c Author: Patrick Palka Date: Tue May 18 00:26:07 2021 -0400 libstdc++: Fix miscellaneous issues with elements_view::_Sentinel [PR100631] libstdc++-v3/ChangeLog: PR libstdc++/100631 * include/std/ranges (elements_view::_Iterator): Also befriend _Sentinel. (elements_view::_Sentinel::_M_equal): Templatize. (elements_view::_Sentinel::_M_distance_from): Split out from ... (elements_view::_Sentinel::operator-): ... here. Depend on _Base2 instead of _Base in the return type. * testsuite/std/ranges/adaptors/elements.cc (test06, test07): New tests.
[Bug rtl-optimization/100645] New: ICE in related_vector_mode, at stor-layout.c:537
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100645 Bug ID: 100645 Summary: ICE in related_vector_mode, at stor-layout.c:537 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Target: powerpc-*-linux-gnu gcc-12.0.0-alpha20210516 snapshot (g:4a322345cab10879162a2ddf659fb0f873ba0182) ICEs when compiling the following testcase, extracted from gcc/testsuite/gcc.target/i386/sse2-pr94680.c, w/ -maltivec: typedef long long v2di __attribute__((vector_size(16))); v2di foo_v2di_l (v2di x) { return __builtin_shuffle ((v2di) { 0, 0 }, x, (v2di) {3, 0}); } % powerpc-e300c3-linux-gnu-gcc-12.0.0 -maltivec -c z7u847kc.c during RTL pass: expand z7u847kc.c: In function 'foo_v2di_l': z7u847kc.c:6:10: internal compiler error: in related_vector_mode, at stor-layout.c:537 6 | return __builtin_shuffle ((v2di) { 0, 0 }, x, (v2di) {3, 0}); | ^ 0x69756e related_vector_mode(machine_mode, scalar_mode, poly_int<1u, unsigned long>) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_alpha20210516/work/gcc-12-20210516/gcc/stor-layout.c:537 0xd0b1e3 expand_vec_perm_const(machine_mode, rtx_def*, rtx_def*, int_vector_builder > const&, machine_mode, rtx_def*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_alpha20210516/work/gcc-12-20210516/gcc/optabs.c:6003 0xa8fc09 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_alpha20210516/work/gcc-12-20210516/gcc/expr.c:10033 0x964ee5 expand_gimple_stmt_1 /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_alpha20210516/work/gcc-12-20210516/gcc/cfgexpand.c:3950 0x964ee5 expand_gimple_stmt /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_alpha20210516/work/gcc-12-20210516/gcc/cfgexpand.c:4011 0x96aa86 expand_gimple_basic_block /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_alpha20210516/work/gcc-12-20210516/gcc/cfgexpand.c:6053 0x96c5cf execute /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_alpha20210516/work/gcc-12-20210516/gcc/cfgexpand.c:6737
[Bug jit/96067] __atomic_compare_exchange_n should return bool instead of void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96067 Antoni changed: What|Removed |Added Resolution|--- |DUPLICATE Status|ASSIGNED|RESOLVED --- Comment #4 from Antoni --- Closing in favor of 96066. That should be using a number instead of `n` as in `__atomic_compare_exchange_4`. *** This bug has been marked as a duplicate of bug 96066 ***
[Bug jit/96066] Cannot use values from some builtins because they are of void type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96066 --- Comment #4 from Antoni --- *** Bug 96067 has been marked as a duplicate of this bug. ***
[Bug jit/96066] Cannot use values from some builtins because they are of void type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96066 --- Comment #3 from Antoni --- Created attachment 50832 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50832&action=edit Patch to fix the issues with using atomic builtins I implemented the missing types and fixed the type checking.
[Bug jit/96079] Unresolved atomic builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96079 Antoni changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Antoni --- The actual call should be with a number instead of `n`, i.e. `__atomic_store_4`.
[Bug c++/100644] New: [11 regression] Deleted move constructor prevents templated constructor from being used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100644 Bug ID: 100644 Summary: [11 regression] Deleted move constructor prevents templated constructor from being used Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: botond at mozilla dot com Target Milestone: --- GCC 11 gives an error for the following code which GCC 10 and Clang accept: struct NonMovable { NonMovable(NonMovable&&) = delete; }; template struct Maybe { NonMovable mMember; template Maybe(Maybe&&); }; void foo(Maybe); void unlucky(Maybe&& x) { Maybe var{(Maybe&&)x}; } The error is: main.cpp: In function ‘void unlucky(Maybe&&)’: main.cpp:16:33: error: use of deleted function ‘Maybe::Maybe(Maybe&&)’ 16 | Maybe var{(Maybe&&)x}; | ^ main.cpp:6:8: note: ‘Maybe::Maybe(Maybe&&)’ is implicitly deleted because the default definition would be ill-formed: 6 | struct Maybe { |^ main.cpp:6:8: error: use of deleted function ‘NonMovable::NonMovable(NonMovable&&)’ main.cpp:2:3: note: declared here 2 | NonMovable(NonMovable &&) = delete; | ^~ I believe the code should be accepted, with the deleted move constructor ignored during overload resolution and the templated constructor used instead. I explain my reasoning, with links to the standard, in more detail here: https://bugzilla.mozilla.org/show_bug.cgi?id=1710235#c22 Please let me know if I've overlooked something and the code really is invalid.
[Bug libstdc++/100334] atomic::notify_one() sometimes wakes wrong thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100334 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |11.2
[Bug c++/100629] Regression from 10 symbol mismatch between class definition and use with/without optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100629 --- Comment #27 from Jonathan Wakely --- Created attachment 50831 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50831&action=edit further reduced
[Bug tree-optimization/100512] [12 Regression] ICE during GIMPLE pass: cddce in mark_operand_necessary, at tree-ssa-dce.c:173 (under -O2 to -Os) since r12-623-g1416a1434c43de0b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100512 --- Comment #8 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:3f476de7fd274f619a0b04c2e2f7077ee8ab17a5 commit r12-852-g3f476de7fd274f619a0b04c2e2f7077ee8ab17a5 Author: Andrew MacLeod Date: Mon May 17 15:53:39 2021 -0400 Once a range becomes constant, make it invariant. Once a range is forced to a constant globally, simply make it invariant. Unify this with the code which makes non-zero pointer ranges invariant. gcc/ PR tree-optimization/100512 * gimple-range-cache.cc (ranger_cache::set_global_range): Mark const and non-zero pointer ranges as invariant. * gimple-range.cc (gimple_ranger::range_of_stmt): Remove pointer processing from here. gcc/testsuite/ PR tree-optimization/100512 * gcc.dg/pr100512.c: New.
[Bug c++/100629] Regression from 10 symbol mismatch between class definition and use with/without optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100629 --- Comment #26 from Jonathan Wakely --- But I can't confirm this as a regression, because the same behaviour goes all the way back to GCC 5.1 when the abi_tag was introduced.
[Bug rtl-optimization/100622] Conversion to smaller unsigned type in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100622 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #5 from Segher Boessenkool --- (In reply to Thomas Koenig from comment #4) > Yes, the masking should be only performed at the end. > > However, the inner loop could be further simplified to > > label: > lwzu r8,4(r10) > add r3,r8,r3 > bdnz label > > without the need to do anything with r9, so this is probably > more than one topic in one test case. Please use -O2 instead, no one will care much about -O1. You can use -fno-unroll-loops to make it easier to read. The core for foo is .L3: lwzu 10,4(9) add 3,10,3 rldicl 3,3,0,32 bdnz .L3 and for foo2 is .L10: lwzu 10,4(9) add 3,3,10 bdnz .L10 This is this way in Gimple already: the IV is a DImode, while it would be better as a SImode. That is the root of the problem here. Sinking extensions could well help, but the IV should not be DImode in the first place! Confirmed.
[Bug c++/100629] Regression from 10 symbol mismatch between class definition and use with/without optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100629 --- Comment #25 from Jonathan Wakely --- Created attachment 50830 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50830&action=edit auto-reduced testcase This produces different mangling depending on -fdevirtualize
[Bug c++/100629] Regression from 10 symbol mismatch between class definition and use with/without optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100629 --- Comment #24 from James McKelvey --- Running Cygwin 3.2.0(0.340/5/3) under Windows 10. Using built-in specs. COLLECT_GCC=/usr/local/bin/g++ COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-cygwin/11.1.1/lto-wrapper.exe Target: x86_64-pc-cygwin Configured with: ./configure --enable-languages=c,c++ Thread model: single Supported LTO compression algorithms: zlib gcc version 11.1.1 20210515 (GCC) Compiler options compiling project: /usr/local/bin/g++ -std=c++0x -c -O3 -DNDEBUG -DUSE_INTL=1 -DUSE_MUTEX=1 -D_FORTIFY_SOURCE=1 -pedantic-errors -Werror -fno-common -Wall -Wold-style-cast -Wsign-promo -Wpointer-arith -Wundef -Wwrite-strings -Winvalid-pch -Woverloaded-virtual -Wcast-qual -Wextra -Wredundant-decls -Wshadow -Wcast-align=strict -Wcomment -fstrict-aliasing -Winit-self -Wmissing-include-dirs -Wswitch-default -Wswitch-enum -Wlogical-op -Wconversion -Wsign-conversion -Wmissing-declarations -Wdeprecated -ftree-switch-conversion -Wuninitialized -Wparentheses -Wimplicit-fallthrough=5 -Wformat-nonliteral -Wformat-truncation=2 -Wformat-signedness -Wdouble-promotion -Wformat=2 -Wformat-overflow=2 -Wformat-security -Wnull-dereference -Wmain -Wmultistatement-macros -Wsequence-point -Wswitch-default -Wswitch-enum -Wunused-value -Wstrict-overflow=2 -Warith-conversion -Wfloat-conversion -Wduplicated-cond -Wunsafe-loop-optimizations -Wreturn-type -Wunused-parameter -Wmaybe-uninitialized -Wstrict-aliasing -Wsuggest-attribute=noreturn -Wsuggest-attribute=format -Wsuggest-attribute=malloc -Wmissing-format-attribute -Wmissing-noreturn -Walloc-zero -Walloca -Wtrampolines -Wcast-function-type -Wlogical-op -Wpacked -Wredundant-decls -Wunused -Wmismatched-dealloc -Wmismatched-new-delete -Wfree-nonheap-object -Wexceptions -MMD -fimplicit-templates For linking: /usr/local/bin/g++ -std=c++0x -O3 -DNDEBUG -DUSE_INTL=1 -DUSE_MUTEX=1 -D_FORTIFY_SOURCE=1 -pedantic-errors -Werror -fno-common -Wall -Wold-style-cast -Wsign-promo -Wpointer-arith -Wundef -Wwrite-strings -Winvalid-pch -Woverloaded-virtual -Wcast-qual -Wextra -Wredundant-decls -Wshadow -Wcast-align=strict -Wcomment -fstrict-aliasing -Winit-self -Wmissing-include-dirs -Wswitch-default -Wswitch-enum -Wlogical-op -Wconversion -Wsign-conversion -Wmissing-declarations -Wdeprecated -ftree-switch-conversion -Wuninitialized -Wparentheses -Wimplicit-fallthrough=5 -Wformat-nonliteral -Wformat-truncation=2 -Wformat-signedness -Wdouble-promotion -Wformat=2 -Wformat-overflow=2 -Wformat-security -Wnull-dereference -Wmain -Wmultistatement-macros -Wsequence-point -Wswitch-default -Wswitch-enum -Wunused-value -Wstrict-overflow=2 -Warith-conversion -Wfloat-conversion -Wduplicated-cond -Wunsafe-loop-optimizations -Wreturn-type -Wunused-parameter -Wmaybe-uninitialized -Wstrict-aliasing -Wsuggest-attribute=noreturn -Wsuggest-attribute=format -Wsuggest-attribute=malloc -Wmissing-format-attribute -Wmissing-noreturn -Walloc-zero -Walloca -Wtrampolines -Wcast-function-type -Wlogical-op -Wpacked -Wredundant-decls -Wunused -Wmismatched-dealloc -Wmismatched-new-delete -Wfree-nonheap-object -Wexceptions -Winline -MMD -fimplicit-templates -Wl,-warn-common -L.. -o header_edit.exe header_edit.o -lPatternDriver -lintl -lpthread Yes I know that most warnings have no effect at link time.
[Bug fortran/98411] [10/11] Pointless: Array larger than ‘-fmax-stack-var-size=’, moved from stack to static storage for main program variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98411 --- Comment #8 from anlauf at gcc dot gnu.org --- (In reply to Vladimir Fuka from comment #7) > This sounds like good progress and I thank you for the patch. However, > shouldn't implicitly SAVE'd variables, as e.g. the program local variable in > the original report, be included as well? You are right. However, note that implicit SAVE for the main was added by Tobias only in r12-805, so I might have to think about a follow-up to this one.
[Bug fortran/98411] [10/11] Pointless: Array larger than ‘-fmax-stack-var-size=’, moved from stack to static storage for main program variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98411 --- Comment #7 from Vladimir Fuka --- This sounds like good progress and I thank you for the patch. However, shouldn't implicitly SAVE'd variables, as e.g. the program local variable in the original report, be included as well?
[Bug c++/100629] Regression from 10 symbol mismatch between class definition and use with/without optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100629 --- Comment #23 from Jonathan Wakely --- OK, the bad mangling happens with -O1 -fdevirtualize and not with -O1 alone.
[Bug analyzer/100615] analyzer failed to report leak in rxtxcpu's parse_cpu_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100615 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-05-17 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from David Malcolm --- Testing a fix for this (it's the strsep call; the strtol is const).
[Bug middle-end/100595] ICE: output_operand with static const int of address of label + difference of label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100595 --- Comment #3 from joseph at codesourcery dot com --- My old model of constant expressions for GNU extensions says that the difference of two label addresses is a "label difference constant expression", which is valid as a static initializer by itself but not when added to anything. https://www.polyomino.org.uk/computer/c/const-exprs-gnu.txt
[Bug c++/100629] Regression from 10 symbol mismatch between class definition and use with/without optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100629 --- Comment #22 from Jonathan Wakely --- This doesn't seem to be a compiler change, because I see the same mangling compiling the .ii with GCC 10 (after adjusting the .ii to remove the uses of the new intrinsics from GCC 11). So possibly a library change.
[Bug libstdc++/100630] Unexpected implicit conversion from volatile bool& to std::filesystem::path in gcc <= 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100630 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:f8d2cef5c544dd0196ec5a6f479fbf96d2214d76 commit r11-8425-gf8d2cef5c544dd0196ec5a6f479fbf96d2214d76 Author: Jonathan Wakely Date: Mon May 17 11:54:06 2021 +0100 libstdc++: Fix filesystem::path constraints for volatile [PR 100630] The constraint check for filesystem::path construction uses decltype(__is_path_src(declval())) which mean it considers conversion from an rvalue. When Source is a volatile-qualified type it cannot use is_path_src(const Unknown&) because a const lvalue reference can only bind to a non-volatile rvalue. Since the relevant path members all have a const Source& parameter, the constraint should be defined in terms of declval(), not declval(). This avoids the problem of volatile-qualified rvalues, because we no longer use an rvalue at all. libstdc++-v3/ChangeLog: PR libstdc++/100630 * include/experimental/bits/fs_path.h (__is_constructible_from): Test construction from a const lvalue, not an rvalue. * testsuite/27_io/filesystem/path/construct/100630.cc: New test. * testsuite/experimental/filesystem/path/construct/100630.cc: New test. (cherry picked from commit 45aa7a447652e8541cc381d7ab128544f81ed857)
[Bug c++/100635] error: cannot bind non-const lvalue reference of type 'const volatile int&' to ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100635 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |12.0 --- Comment #4 from Jonathan Wakely --- Fixed for GCC 12.
[Bug c++/100629] Regression from 10 symbol mismatch between class definition and use with/without optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100629 Jonathan Wakely changed: What|Removed |Added Keywords||link-failure Known to fail||11.1.1, 12.0 Status|WAITING |NEW --- Comment #21 from Jonathan Wakely --- (In reply to James McKelvey from comment #10) > Created attachment 50824 [details] > Preprocessed source for main OK, I can confirm it using this file, at -O2 or -O3.
[Bug tree-optimization/100512] [12 Regression] ICE during GIMPLE pass: cddce in mark_operand_necessary, at tree-ssa-dce.c:173 (under -O2 to -Os) since r12-623-g1416a1434c43de0b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100512 --- Comment #7 from Andrew Macleod --- # e_25 = PHI _3 = e_25 + 1; if (_3 != 0) goto ; [INV] else goto ; [INV] <...> : # e_26 = PHI in order to take the edge 3->9, _3 must be [0,0]. _27 is used before defined, so we now use UNDEFINED for that. This allows the PHI to be folded to [0,0] This in turn feeds the PHI for e_25, and means e_25 must be [0,0] _3 is now confidently calculated as [0,0] + 1, making it [1,1] BUT. we just concluded that _3 must be [0,0] in order to feed the PHI, so ranger now decides that means _3 and e_26 are actually UNDEFINED.. which is true. This entire hunk of code is about to be removed, so we don't really need to do anything to it. However, the early VRP pass has concluded that since e_26 and _3 are constants, we can propagate the constant value. It does not consider UNDEFINED to be a constant value, so the propagation code was trapping because it had eliminated the definition of e_26, expecting it to be replaced with [0,0], not UNDEFINED. Probably the best way to fix this entire class of propagation errors is to do what we do with non-zero pointers. Once we get to a globally constant range where further refinements can only end up in an UNDEFINED state, stop further evaluating the range. This typically happens in places which are about to be removed by CFG cleanup anyway. Patch is in testing
[Bug c++/100629] Regression from 10 symbol mismatch between class definition and use with/without optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100629 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #20 from Jonathan Wakely --- Please also provide all the gcc options you're using, as requested at https://gcc.gnu.org/bugs/
[Bug c++/100629] Regression from 10 symbol mismatch between class definition and use with/without optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100629 Jonathan Wakely changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever confirmed|1 |0 --- Comment #19 from Jonathan Wakely --- (In reply to James McKelvey from comment #17) > Sorry, that constructor is in the .cc file. Ah yes, sorry, I see it now. I tried to reproduce the issue with this code, but the symbol is always mangled consistently (with and without MAIN defined): #include #include class CString { }; extern const std::vector complement_names; extern const CString COMPLEMENTENUM; template & names, const CString& title> class TemplateEnum { }; class ConflateIntegerScalarValue { }; typedef TemplateEnum ComplementEnum; struct BreakPattern { BreakPattern(const std::string&, const ConflateIntegerScalarValue&, const ConflateIntegerScalarValue&, const ComplementEnum&); }; #ifdef MAIN int main() { BreakPattern b("", {}, {}, {}); } #else BreakPattern:: BreakPattern(const std::string&, const ConflateIntegerScalarValue&, const ConflateIntegerScalarValue&, const ComplementEnum&) { } #endif
[Bug libstdc++/100334] atomic::notify_one() sometimes wakes wrong thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100334 Thomas Rodgers changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Thomas Rodgers --- Fixed on master, backported to releases/gcc-11
[Bug c++/100640] GCC permits explicit instantiation of a constructor template with an explicit template argument list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100640 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||accepts-invalid Last reconfirmed||2021-05-17
[Bug libstdc++/89728] ctype is underconstrained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89728 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |12.0 Resolution|--- |FIXED --- Comment #2 from Jonathan Wakely --- Fixed by Antony's patch.
[Bug c++/100635] error: cannot bind non-const lvalue reference of type 'const volatile int&' to ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100635 --- Comment #3 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:5d93261bc03c9c6891ccd8c77ab22b2a09971905 commit r12-849-g5d93261bc03c9c6891ccd8c77ab22b2a09971905 Author: Jonathan Wakely Date: Mon May 17 10:53:56 2021 +0100 c++: Fix diagnostic for binding lvalue reference to volatile rvalue [PR 100635] The current diagnostic assumes the reference binding fails because the reference is non-const, but it can also fail if the rvalue is volatile. Use the current diagnostic for non-const cases, and a modified diagnostic otherwise. gcc/cp/ChangeLog: PR c++/100635 * call.c (convert_like_internal): Print different diagnostic if the lvalue reference is const. gcc/testsuite/ChangeLog: * g++.dg/conversion/pr100635.C: New test.
[Bug c++/100629] Regression from 10 symbol mismatch between class definition and use with/without optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100629 --- Comment #18 from James McKelvey --- If I build with -D_GLIBCXX_USE_CXX11_ABI=0 it all works. But with =1 I get the mismatches.
[Bug fortran/98411] [10/11] Pointless: Array larger than ‘-fmax-stack-var-size=’, moved from stack to static storage for main program variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98411 --- Comment #6 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:09867aa0ef7568012650395189b735f9a34cf9b5 commit r12-848-g09867aa0ef7568012650395189b735f9a34cf9b5 Author: Harald Anlauf Date: Mon May 17 21:35:38 2021 +0200 PR fortran/98411 - Pointless warning for static variables Variables with explicit SAVE attribute cannot end up on the stack. There is no point in checking whether they should be moved off the stack to static storage. gcc/fortran/ChangeLog: PR fortran/98411 * trans-decl.c (gfc_finish_var_decl): Add check for explicit SAVE attribute. gcc/testsuite/ChangeLog: PR fortran/98411 * gfortran.dg/pr98411.f90: New test.
[Bug c++/100641] Link error when using extern thread_local variables on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100641 --- Comment #1 from m farazma --- Issue seems to be similar to this older gcc bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59364
[Bug c++/100643] New: [11/12 Regression] ICE in ix86_mangle_function_version_assembler_name, at config/i386/i386-features.c:2809
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100643 Bug ID: 100643 Summary: [11/12 Regression] ICE in ix86_mangle_function_version_assembler_name, at config/i386/i386-features.c:2809 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20210314 and 20210328 : $ cat z1.cc int foo() { int foo() __attribute__((target("avx"))); int foo() __attribute__((target("default"))); } $ g++-12-20210516 -c z1.cc z1.cc: In function 'int foo()': z1.cc:3:10: warning: empty parentheses were disambiguated as a function declaration [-Wvexing-parse] 3 | int foo() __attribute__((target("avx"))); | ^~ z1.cc:3:10: note: remove parentheses to default-initialize a variable 3 | int foo() __attribute__((target("avx"))); | ^~ | -- z1.cc:3:10: note: or replace parentheses with braces to value-initialize a variable z1.cc:4:10: warning: empty parentheses were disambiguated as a function declaration [-Wvexing-parse] 4 | int foo() __attribute__((target("default"))); | ^~ z1.cc:4:10: note: remove parentheses to default-initialize a variable 4 | int foo() __attribute__((target("default"))); | ^~ | -- z1.cc:4:10: note: or replace parentheses with braces to value-initialize a variable z1.cc:5:1: warning: no return statement in function returning non-void [-Wreturn-type] 5 | } | ^ z1.cc: At global scope: z1.cc:5:1: internal compiler error: in ix86_mangle_function_version_assembler_name, at config/i386/i386-features.c:2809 0x107d5bb ix86_mangle_function_version_assembler_name ../../gcc/config/i386/i386-features.c:2809 0x107d5bb ix86_mangle_decl_assembler_name(tree_node*, tree_node*) ../../gcc/config/i386/i386-features.c:2839 0x719887 get_mangled_id ../../gcc/cp/mangle.c:4041 0x719887 mangle_decl(tree_node*) ../../gcc/cp/mangle.c:4078 0xf57cc2 decl_assembler_name(tree_node*) ../../gcc/tree.c:708 0xf9a8be notice_global_symbol(tree_node*) ../../gcc/varasm.c:1801 0x91d505 cgraph_node::finalize_function(tree_node*, bool) ../../gcc/cgraphunit.c:453 0x7ed17f expand_or_defer_fn(tree_node*) ../../gcc/cp/semantics.c:4682 0x7a1c59 cp_parser_function_definition_after_declarator ../../gcc/cp/parser.c:30121 0x7a2afc cp_parser_function_definition_from_specifiers_and_declarator ../../gcc/cp/parser.c:30024 0x7a2afc cp_parser_init_declarator ../../gcc/cp/parser.c:21677 0x782f5a cp_parser_simple_declaration ../../gcc/cp/parser.c:14464 0x7a7395 cp_parser_declaration ../../gcc/cp/parser.c:14161 0x7a68cb cp_parser_translation_unit ../../gcc/cp/parser.c:4942 0x7a68cb c_parse_file() ../../gcc/cp/parser.c:45393 0x8753f2 c_common_parse_file() ../../gcc/c-family/c-opts.c:1218
[Bug fortran/100642] New: ICE in omp_code_to_statement, at fortran/openmp.c:6907
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100642 Bug ID: 100642 Summary: ICE in omp_code_to_statement, at fortran/openmp.c:6907 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started with r11 between 20210411 and 20210425 : $ cat z1.f90 program p use omp_lib, only: omp_depend_kind integer(omp_depend_kind) :: a, b !$acc data !$omp depobj(b) depend(out:a) !$acc end data end $ cat z2.f90 program p integer :: a, b !$acc data !$omp depobj(b) depend(out:a) !$acc end data end $ gfortran-12-20210516 -c z1.f90 -fopenmp -fopenacc f951: internal compiler error: in omp_code_to_statement, at fortran/openmp.c:6907 0x6d1e8d omp_code_to_statement ../../gcc/fortran/openmp.c:6907 0x6dbdfd resolve_omp_directive_inside_oacc_region ../../gcc/fortran/openmp.c:6974 0x6dbdfd gfc_resolve_omp_directive(gfc_code*, gfc_namespace*) ../../gcc/fortran/openmp.c:7291 0x7004a3 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:12242 0x6ff2bf gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:10843 0x6dcb63 gfc_resolve_oacc_blocks(gfc_code*, gfc_namespace*) ../../gcc/fortran/openmp.c:7126 0x6ff5fb gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11755 0x701f67 resolve_codes ../../gcc/fortran/resolve.c:17402 0x70202e gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:17437 0x6ea584 resolve_all_program_units ../../gcc/fortran/parse.c:6309 0x6ea584 gfc_parse_file() ../../gcc/fortran/parse.c:6561 0x736f7f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug c++/100641] New: Link error when using extern thread_local variables on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100641 Bug ID: 100641 Summary: Link error when using extern thread_local variables on AIX Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mfarazma.ext at gmail dot com Target Milestone: --- Declaring a variable as "extern thread_local" in a C++ program leads to: "ERROR: Undefined symbol: TLS init function for ..." during linking. To reproduce: file `0.cc`: ``` extern thread_local int foo; int main(){ return foo; } ``` file `1.cc`: ``` thread_local int foo = 1; ``` Then compile with `g++ 0.cc 1.cc` which produces this error: ``` ld: 0711-317 ERROR: Undefined symbol: TLS init function for foo ld: 0711-317 ERROR: Undefined symbol: .TLS init function for foo ld: 0711-317 ERROR: Undefined symbol: __get_tpointer ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: error: ld returned 8 exit status ```
[Bug rtl-optimization/100590] [11/12 Regression] ICE: verify_flow_info failed (error: too many outgoing branch edges from bb 2) since r11-5002-ge3b3b59683c1e7d3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100590 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 50829 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50829&action=edit gcc12-pr100590.patch Untested fix.
[Bug c++/100629] Regression from 10 symbol mismatch between class definition and use with/without optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100629 --- Comment #17 from James McKelvey --- Sorry, that constructor is in the .cc file. Looks like the .cc contents weren't picked up by the attempt to get the preprocessed source. BreakPattern:: BreakPattern(const pdstring& value, const ConflateIntegerScalarValue& minimum, const ConflateIntegerScalarValue& maximum, const ComplementEnum& a_complement) : AbsCharSetPattern(value, a_complement, std::max(minimum._get_minimum_match_length(), 1UL) - 1UL), _minimum(minimum._get_value()), _maximum(maximum._get_value()) { }
[Bug middle-end/100593] [ELF] -fno-pic: Use GOT to take address of an external default visibility function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593 --- Comment #6 from Fangrui Song --- (In reply to Alexander Monakov from comment #5) > Hm, I still don't think I'm misunderstanding what you're saying. I'm > familiar with the ELF standard (and FWIW I have read your blog posts on > related matters). I am responding to this sentiment from the opening comment: > > > I believe ld -Bsymbolic-functions can materialize most of the savings other > > implementations provide, without introducing complex things to ELF. > > However, since -Bsymbolic-functions doesn't play well with -fno-pic's > > canonical PLT entries, we should fix -fno-pic. > > I am saying that fixing -fno-pic is not the only possible way forward. > Rather, a restricted -Bsymbolic-functions that relaxes relocations that are > not address-significant allows to still get some (but not all) of the > benefits for unchanged -fno-pic executables. You are right. A pure linker approach is possible. However, I think the approach is inelegant, because the linker would have different preemptibility ideas on different relocation types and (as you said) indirect calls like vtable definitions are not optimized. Let's say the proposed linker option for shared objects is -Bsymbolic-plt. The discussion below focuses on default visibility definitions which would otherwise be preemptible. Let categorize relocation types first. PLT-generating: R_X86_64_PLT32 GOT-generating: R_X86_64_GOTPCREL, R_X86_64_GOTPCRELX, R_X86_64_REX_GOTPCRELX absolute (symbolic): R_X86_64_64 There are three choices. (a) If all relocation types are PLT-generating, bind branch targets directly and suppress the PLT entry. If GOT-generating/absolute relocations are present, don't change behaviors. This choice is less effective for some otherwise address-insignificant functions, e.g. non-vague-linkage virtual functions. b) If all relocation types are R_X86_64_PLT32 or GOT-generating, bind branch targets directly and suppress the PLT entry. If GOT-generating relocations are present, produce a GOT entry and an associated R_X86_64_GLOB_DAT. If absolute relocations are present, don't change behaviors. c) Always bind branch targets directly and suppress the PLT entry. If GOT-generating relocations are present, produce a GOT entry and an associated R_X86_64_GLOB_DAT. If absolute relocations are present, produce outstanding dynamic relocations of the same type. > > You misunderstand this. Emitting GOT-generating relocation in -fno-pic mode > > is the only way to avoid canonical PLT entry, if the function turns out to > > be defined in a shared object. No -Bsymbolic variant can make this > > compatible. > > Well, if you frame the goal as "eliminate canonical PLT entries", then yes, > but that in itself surely is not the end goal? The end goals are reducing > startup time (which my idea helps only partially since it may bind direct > calls but not e.g. vtable definitions) and runtime overheads (where again my > proposal is weaker but not significantly so, assuming address loads are > rarely on hot paths). Yes, the end goal is to reduce startup time and bind call targets directly if feasible. Yes, -Bsymbolic-plt can help the goal partially. > > To clarify once more. I am not outright rejecting the idea in your opening > comment. I am saying that there potentially is a lighter-weight alternative, > which may be implementable purely in the linker, and still gets most of the > benefit you're promoting (like in your Clang example). Which is nice, > because it can be rolled out sooner, individual libraries/distros/users can > opt-in and experiment as they like, etc. Such a -Bsymbolic-plt can achieve some goals. But given that the function pointer equality problems are usually benign (-fno-pic is relatively uncommon in many areas; making use of such pointer equality is not a common practice), I'd hope we just don't add that intermediate linker option.
[Bug target/100626] [11/12 Regression] ICE Segmentation fault (during RTL pass: split1) since r11-165-geb72dc663e9070b2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100626 Uroš Bizjak changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Status|NEW |ASSIGNED --- Comment #5 from Uroš Bizjak --- Created attachment 50828 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50828&action=edit Proposed patch Patch in testing.
[Bug c++/100629] Regression from 10 symbol mismatch between class definition and use with/without optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100629 --- Comment #16 from James McKelvey --- The Break's are actually functions that call the constructor. They look like this: inline BreakPattern Break(const AbstractStringScalarValue& value, const ComplementEnum&a_complement = noncomplement) { return BreakPattern(value, a_complement); } there are 12 of them.
[Bug c++/100629] Regression from 10 symbol mismatch between class definition and use with/without optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100629 --- Comment #15 from James McKelvey --- The Break's are actually functions that call the constructor. They look like this: inline BreakPattern Break(const AbstractStringScalarValue& value, const ComplementEnum&a_complement = noncomplement) { return BreakPattern(value, a_complement); } there are 12 of them.
[Bug target/100497] [OpenMP][nvptx] libgomp.c-c++-common/reduction-5.c - fails on some nvptx systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100497 --- Comment #16 from Tom de Vries --- *** Bug 96932 has been marked as a duplicate of this bug. ***
[Bug target/96932] [nvptx] atomic_exchange missing barrier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96932 Tom de Vries changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #6 from Tom de Vries --- Duplicate. *** This bug has been marked as a duplicate of bug 100497 ***
[Bug target/100497] [OpenMP][nvptx] libgomp.c-c++-common/reduction-5.c - fails on some nvptx systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100497 Tom de Vries changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |12.0 --- Comment #15 from Tom de Vries --- Patch committed, marking-resolved-fixed.
[Bug target/100497] [OpenMP][nvptx] libgomp.c-c++-common/reduction-5.c - fails on some nvptx systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100497 --- Comment #14 from CVS Commits --- The master branch has been updated by Tom de Vries : https://gcc.gnu.org/g:58f7c7e098b79c96403c8341823ec3ba1e8b3945 commit r12-846-g58f7c7e098b79c96403c8341823ec3ba1e8b3945 Author: Tom de Vries Date: Mon May 17 10:11:52 2021 +0200 [nvptx] Handle memmodel for atomic ops The atomic ops in nvptx.md have memmodel arguments, which are currently ignored. Handle these, fixing test-case fails libgomp.c-c++-common/reduction-{5,6}.c on volta. Tested libgomp on x86_64-linux with nvptx accelerator. gcc/ChangeLog: 2021-05-17 Tom de Vries PR target/100497 * config/nvptx/nvptx-protos.h (nvptx_output_atomic_insn): Declare * config/nvptx/nvptx.c (nvptx_output_barrier) (nvptx_output_atomic_insn): New function. (nvptx_print_operand): Add support for 'B'. * config/nvptx/nvptx.md: Use nvptx_output_atomic_insn for atomic insns.
[Bug middle-end/100576] [11/12 Regression] ICE at -O1 and above: in decompose, at wide-int.h:984 since r11-2928-gd14c547abd484d35
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100576 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Jakub Jelinek --- Created attachment 50827 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50827&action=edit gcc12-pr100576.patch Untested fix.
[Bug c++/100629] Regression from 10 symbol mismatch between class definition and use with/without optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100629 --- Comment #14 from Jonathan Wakely --- (In reply to James McKelvey from comment #10) > Created attachment 50824 [details] > Preprocessed source for main This is header_edit.cc right? I don't see any definition of the missing constructor here. This one: BreakPattern(const pdstring& value, const ConflateIntegerScalarValue& minimum, const ConflateIntegerScalarValue& maximum, const ComplementEnum& a_complement);
[Bug target/100626] [11/12 Regression] ICE Segmentation fault (during RTL pass: split1) since r11-165-geb72dc663e9070b2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100626 --- Comment #4 from Haoxin Tu --- I found that it also crashes (under -O1 and -Os) on today's trunk version of GCC. $cat small.c #include int a; void b() { int c; uint64_t *d = &c; uint8_t *e; if (a) *d &= *e; if (*d) for (;;) ; } $gcc -w -O1 -m32 small.c (or -Os) during RTL pass: split1 small.c: In function ‘b’: small.c:12:1: internal compiler error: Segmentation fault 12 | } | ^ 0xba0cef crash_signal ../../gcc/toplev.c:327 0xefc40a ix86_fixup_binary_operands(rtx_code, machine_mode, rtx_def**) ../../gcc/config/i386/i386-expand.c:900 0xefc5bb ix86_expand_binary_operator(rtx_code, machine_mode, rtx_def**) ../../gcc/config/i386/i386-expand.c:943 0x1214538 gen_andsi3(rtx_def*, rtx_def*, rtx_def*) ../../gcc/config/i386/i386.md:9091 0x12147b4 gen_split_191(rtx_insn*, rtx_def**) ../../gcc/config/i386/i386.md:9123 0x13f8f22 split_insns(rtx_def*, rtx_insn*) ../../gcc/config/i386/i386.md:14140 0x87e61e try_split(rtx_def*, rtx_insn*, int) ../../gcc/emit-rtl.c:3786 0xb15ad1 split_insn ../../gcc/recog.c:3363 0xb1af47 split_all_insns() ../../gcc/recog.c:3467 0xb1afd8 execute ../../gcc/recog.c:4385 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/media/haoxin/SeagateData/haoxin-data/dut-research/compilers/gcc/build/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../configure --prefix=/home/haoxin/haoxin-data/dut-research/compilers/gcc/build/ --enable-bootstrap --enable-checking=release --enable-languages=c,c++ --enable-multilib Thread model: posix Supported LTO compression algorithms: zlib gcc version 12.0.0 20210517 (experimental) (GCC)
[Bug c++/100640] New: GCC permits explicit instantiation of a constructor template with an explicit template argument list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100640 Bug ID: 100640 Summary: GCC permits explicit instantiation of a constructor template with an explicit template argument list Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: richard-gccbugzilla at metafoo dot co.uk Target Milestone: --- Example: struct A { template A() {} }; template A::A(); GCC accepts this without even a warning under -std=c++20 -pedantic-errors, but this is not valid C++. If this is an intentional extension, it doesn't appear to be documented (and presumably should be rejected under -pedantic-errors).
[Bug c++/100639] reverse_view::reference erroneously uses iterator_traits::reference instead of iter_reference_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100639 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-05-17 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug middle-end/100576] [11/12 Regression] ICE at -O1 and above: in decompose, at wide-int.h:984 since r11-2928-gd14c547abd484d35
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100576 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Slightly cleaned up testcase (but needs the unprototyped memcmp): const char v[] = {0x12}; void foo (int n, const char *p) { int b = sizeof v; n += memcmp (p, v, b); if (n) __builtin_abort(); }
[Bug libstdc++/89120] std::minmax_element 2.5 times slower than hand written loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89120 --- Comment #2 from Antony Polukhin --- Long story short: I've found no way to improve the standard library code to always work faster. I'm in favor of closing this ticket as invalid/wont fix. Long story: I've tried to add a specialization of minmax_element algorithm for std::less comparators and arithmetic types. That specialization was doing more comparisons but in a more predictable way. On big datasets the performance increased, but decreased on small datasets. Then I've tried another approach. If the comparison of __first with __next is barely predictable, then just avoid branching on it. Portable solution: bool __b = __comp(__next, __first); _ForwardIterator __pots[3] = {__first, __next, __first}; _ForwardIterator __pot_min = *(__pots + __b); _ForwardIterator __pot_max = *(__pots + __b + 1); Special case for random access iterators: bool __b = __comp(__next, __first); _ForwardIterator __pot_min = __first, __pot_max = __next; __pot_min += b; __pot_max -= b; Unfortunately both those approaches add some overhead for small datasets. Another disadvantage, is that those approaches produce orthogonal results on different compilers: GCC-9 performance gets better on big datasets - Benchmark Time CPU Iterations - naive_minmax/2 3 ns 3 ns 247522237 naive_minmax/8 7 ns 7 ns 103044422 naive_minmax/262144 1715635 ns1710406 ns407 naive_minmax/1048576 6970755 ns6947034 ns101 branchless_minmax/28 ns 8 ns 81324904 branchless_minmax/8 30 ns 30 ns 23494608 branchless_minmax/262144 457287 ns 456412 ns 1529 branchless_minmax/10485764267914 ns4219969 ns363 Clang-9 performance degrades on big datasets - Benchmark Time CPU Iterations - naive_minmax/2 2 ns 2 ns 380928404 naive_minmax/8 7 ns 7 ns 92642970 naive_minmax/262144 262921 ns 262288 ns 2630 naive_minmax/1048576 1149407 ns1147626 ns618 branchless_minmax/22 ns 2 ns 307146020 branchless_minmax/8 10 ns 10 ns 74417142 branchless_minmax/262144 425880 ns 425241 ns 1637 branchless_minmax/10485761747785 ns1745725 ns397 Final attempt. Different compilers optimize the algorithm differently. Clang shows good performance on big datasets with >4k elements, GCC - on medium sized datasets with 128-1k elements. Maybe providing more info on probabilities could help both compilers to produce better code. But looks like heuristics already deduce the probabilities to be close to 0.5, __builtin_expect_with_probability(__b, true, 0.5) changed nothing in the assembly https://godbolt.org/z/PqWoaKfhW
[Bug c++/100580] [10/11/12 Regression] ICE with -fdump-passes since r10-6837-g2473c81cb2d4627f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100580 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 50826 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50826&action=edit gcc12-pr100580.patch Untested fix.
[Bug rtl-optimization/80960] [9/10 Regression] Huge memory use when compiling a very large test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80960 --- Comment #30 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Biener : https://gcc.gnu.org/g:47d3815f0669800666f1dd69f0c5cfecc617a12b commit r10-9832-g47d3815f0669800666f1dd69f0c5cfecc617a12b Author: Richard Biener Date: Wed Jan 27 15:35:52 2021 +0100 rtl-optimization/80960 - avoid creating garbage RTL in DSE The following avoids repeatedly turning VALUE RTXen into sth useful and re-applying a constant offset through get_addr via DSE check_mem_read_rtx. Instead perform this once for all stores to be visited in check_mem_read_rtx. This avoids allocating 1.6GB of garbage PLUS RTXen on the PR80960 testcase, fixing the memory usage regression from old GCC. 2021-01-27 Richard Biener PR rtl-optimization/80960 * dse.c (check_mem_read_rtx): Call get_addr on the offsetted address. (cherry picked from commit a523add327c6cfdd68cf9b788ea808068d0f508c)
[Bug libstdc++/100630] Unexpected implicit conversion from volatile bool& to std::filesystem::path in gcc <= 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100630 --- Comment #3 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:45aa7a447652e8541cc381d7ab128544f81ed857 commit r12-845-g45aa7a447652e8541cc381d7ab128544f81ed857 Author: Jonathan Wakely Date: Mon May 17 11:54:06 2021 +0100 libstdc++: Fix filesystem::path constraints for volatile [PR 100630] The constraint check for filesystem::path construction uses decltype(__is_path_src(declval())) which mean it considers conversion from an rvalue. When Source is a volatile-qualified type it cannot use is_path_src(const Unknown&) because a const lvalue reference can only bind to a non-volatile rvalue. Since the relevant path members all have a const Source& parameter, the constraint should be defined in terms of declval(), not declval(). This avoids the problem of volatile-qualified rvalues, because we no longer use an rvalue at all. libstdc++-v3/ChangeLog: PR libstdc++/100630 * include/experimental/bits/fs_path.h (__is_constructible_from): Test construction from a const lvalue, not an rvalue. * testsuite/27_io/filesystem/path/construct/100630.cc: New test. * testsuite/experimental/filesystem/path/construct/100630.cc: New test.
[Bug libstdc++/89728] ctype is underconstrained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89728 --- Comment #1 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:fd89fc77639a63a141dbbc6292dd73e653794d61 commit r12-844-gfd89fc77639a63a141dbbc6292dd73e653794d61 Author: Antony Polukhin Date: Mon May 17 14:58:28 2021 +0100 libstdc++: diagnose some misuses of [locale.convenience] functions [PR 89728] This patch provides better diagnostics for common misuse of [locale.convenience] functions with std::string as a character type. libstdc++-v3/ChangeLog: PR libstdc++/89728 * include/bits/locale_facets.h (ctype>): Declare (but do not define) partial specialization. * testsuite/22_locale/ctype/is/string/89728_neg.cc: New test.
[Bug c++/100629] Regression from 10 symbol mismatch between class definition and use with/without optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100629 James McKelvey changed: What|Removed |Added CC||mckelvey at maskull dot com --- Comment #13 from James McKelvey --- Created attachment 50825 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50825&action=edit Preprocessed source for BreakPattern.cc
[Bug c++/100629] Regression from 10 symbol mismatch between class definition and use with/without optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100629 --- Comment #12 from James McKelvey --- I don't see _GLIBCXX_USE_CXX11_ABI anywhere in the code.
[Bug c++/100629] Regression from 10 symbol mismatch between class definition and use with/without optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100629 --- Comment #11 from James McKelvey --- I don't see _GLIBCXX_USE_CXX11_ABI anywhere in the code.
[Bug c++/100639] New: reverse_view::reference erroneously uses iterator_traits::reference instead of iter_reference_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100639 Bug ID: 100639 Summary: reverse_view::reference erroneously uses iterator_traits::reference instead of iter_reference_t Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: barry.revzin at gmail dot com Target Milestone: --- Short example (from https://stackoverflow.com/q/67573305/2069064): #include template using iota = std::ranges::iota_view; template using iota_iter = std::ranges::iterator_t>; static_assert(std::same_as< std::reverse_iterator>::reference, int64_t>); This assertion fails when compiling with -std=c++20 (because the reference type is 'void') but passes with -std=gnu++20. The direct reason is that the difference_type of the iota_view iterator is __int128, which is considered a signed_integral with gnu++20 but not c++20. But the reason this matters is because std::reverse_iterator::reference is defined as std::iterator_traits::reference (which checks that I satsifies cpp17-input-iterator which has the signed_integral constraint) instead of being defined as std::iter_reference_t (which has no such check). With the latter implementation, the assertion above would pass on either version. The result is that reversing an iota_view isn't a range on -std=c++20.
[Bug target/99977] arm: ICE with __sync_bool_compare_and_swap and -mcpu=cortex-m23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99977 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Alex Coplan : https://gcc.gnu.org/g:c28df7197b4886fde6b4f7f47f2102f886339655 commit r11-8423-gc28df7197b4886fde6b4f7f47f2102f886339655 Author: Alex Coplan Date: Tue Apr 27 14:56:15 2021 +0100 arm: Fix ICEs with compare-and-swap and -march=armv8-m.base [PR99977] The PR shows two ICEs with __sync_bool_compare_and_swap and -mcpu=cortex-m23 (equivalently, -march=armv8-m.base): one in LRA and one later on, after the CAS insn is split. The LRA ICE occurs because the @atomic_compare_and_swap_1 pattern attempts to tie two output operands together (operands 0 and 1 in the third alternative). LRA can't handle this, since it doesn't make sense for an insn to assign to the same operand twice. The later (post-splitting) ICE occurs because the expansion of the cbranchsi4_scratch insn doesn't quite go according to plan. As it stands, arm_split_compare_and_swap calls gen_cbranchsi4_scratch, attempting to pass a register (neg_bval) to use as a scratch register. However, since the RTL template has a match_scratch here, gen_cbranchsi4_scratch ignores this argument and produces a scratch rtx. Since this is all happening after RA, this is doomed to fail (and we get an ICE about the insn not matching its constraints). It seems that the motivation for the choice of constraints in the atomic_compare_and_swap pattern comes from an attempt to satisfy the constraints of the cbranchsi4_scratch insn. This insn requires the scratch register to be the same as the input register in the case that we use a larger negative immediate (one that satisfies J, but not L). Of course, as noted above, LRA refuses to assign two output operands to the same register, so this was never going to work. The solution I'm proposing here is to collapse the alternatives to the CAS insn (allowing the two output register operands to be matched to different registers) and to ensure that the constraints for cbranchsi4_scratch are met in arm_split_compare_and_swap. We do this by inserting a move to ensure the source and destination registers match if necessary (i.e. in the case of large negative immediates). Another notable change here is that we only do: emit_move_insn (neg_bval, const1_rtx); for non-negative immediates. This is because the ADDS instruction used in the negative case suffices to leave a suitable value in neg_bval: if the operands compare equal, we don't take the branch (so neg_bval will be set by the load exclusive). Otherwise, the ADDS will leave a nonzero value in neg_bval, which will correctly signal that the CAS has failed when it is later negated. gcc/ChangeLog: PR target/99977 * config/arm/arm.c (arm_split_compare_and_swap): Fix up codegen with negative immediates: ensure we expand cbranchsi4_scratch correctly and ensure we satisfy its constraints. * config/arm/sync.md (@atomic_compare_and_swap_1): Don't attempt to tie two output operands together with constraints; collapse two alternatives. (@atomic_compare_and_swap_1): Likewise. * config/arm/thumb1.md (cbranchsi4_neg_late): New. gcc/testsuite/ChangeLog: PR target/99977 * gcc.target/arm/pr99977.c: New test. (cherry picked from commit 42a10bb884c0d5af2583b8bfe4d239ce95bf9e43)
[Bug target/100369] crash after error in gcc.target/aarch64/simd/vgetq_lane_s64_indices_1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100369 --- Comment #2 from David Binderman --- (In reply to Christophe Lyon from comment #1) > Can you share details on how you get this error? (GCC configure options, > command-line used to compile the testcase) configure is CC="clang -Wall -Wextra" CXX="clang++ -Wall -Wextra" \ ../trunk/configure --prefix=/home/pi/gcc/results.20210516 \ --disable-multilib \ --disable-werror \ --with-pkgversion=$HASH \ --enable-checking=yes \ --enable-languages=c,c++,fortran \ --with-cpu=cortex-a72 \ --with-fpu=neon-fp-armv8 \ --with-float=hard \ --build=arm-linux-gnueabihf \ --host=arm-linux-gnueabihf \ --target=arm-linux-gnueabihf sed 's/-O2/-O3 -march=native/' < Makefile > Makefile.tmp diff Makefile Makefile.tmp mv Makefile.tmp Makefile Host machine is a raspberry pi 3B+. It is entirely possible the configure is not quite optimal, although it seems to work. The command line I used is $ /home/pi/gcc/results.20210516/bin/gcc -c gcc.target/aarch64/simd/vgetq_lane_s64_indices_1.c The bug still seems to occur in yesterday's compiler.
[Bug c++/100629] Regression from 10 symbol mismatch between class definition and use with optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100629 --- Comment #10 from James McKelvey --- Created attachment 50824 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50824&action=edit Preprocessed source for main
[Bug c++/100629] Regression from 10 symbol mismatch between class definition and use with optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100629 --- Comment #9 from James McKelvey --- Created attachment 50823 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50823&action=edit Preprocessed source for BreakPattern.h
[Bug target/100369] crash after error in gcc.target/aarch64/simd/vgetq_lane_s64_indices_1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100369 --- Comment #1 from Christophe Lyon --- The trace you share contains arm-linux-gnueabihf, so it seems the target is actually arm, instead of aarch64? Anyway, I can see no such error in the automatic validations, see https://gcc.gnu.org/pipermail/gcc-testresults/ Can you share details on how you get this error? (GCC configure options, command-line used to compile the testcase)
[Bug tree-optimization/100349] [11/12 Regression] ICE Segmentation fault during GIMPLE pass: evrp (under -O2 to -Os)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100349 --- Comment #5 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:ce81282261c6c77883b17d0ebfbbe337bed76457 commit r12-842-gce81282261c6c77883b17d0ebfbbe337bed76457 Author: Aldy Hernandez Date: Thu May 13 16:09:58 2021 -0400 Bail in bounds_of_var_in_loop if scev returns NULL. Both initial_condition_in_loop_num and evolution_part_in_loop_num can return NULL. This patch exits if either one is NULL. Presumably this didn't happen before, because adjust_range_with_scev was called far less frequently than in ranger, which can call it for every PHI. gcc/ChangeLog: PR tree-optimization/100349 * vr-values.c (bounds_of_var_in_loop): Bail if scev returns NULL. gcc/testsuite/ChangeLog: * gcc.dg/pr100349.c: New test.
[Bug target/100497] [OpenMP][nvptx] libgomp.c-c++-common/reduction-5.c - fails on some nvptx systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100497 --- Comment #13 from Tom de Vries --- Posted: https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570508.html
[Bug target/100549] [12 Regression] ICE: Segmentation fault with __builtin_ia32_pcmpgtw128 since r12-110-gc54a9f7259fce1a2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100549 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug ipa/100529] [11/12 Regression] ICE at -O3: in force_constant_size, at gimplify.c:733 since r11-4494-ga4223abb3deb24e8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100529 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.2
[Bug target/100549] [12 Regression] ICE: Segmentation fault with __builtin_ia32_pcmpgtw128 since r12-110-gc54a9f7259fce1a2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100549 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0
[Bug target/100530] [9/10/11/12 Regression] ICE with -g: in add_dwarf_attr with __seg_gs (Alternative address-space) global variable since r8-4385-ga297ccb52e0c894e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100530 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.4
[Bug target/100518] [12 Regression] ICE in copy_to_mode_reg with aarch64 ILP32 and memset with -mstrict-align -O2 since r12-397-gda9e6e63d1ae22e530ec7baf59f6ed028bf05776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100518 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0 Version|11.0|12.0
[Bug c/100625] ICE on gimple program: Segmentation fault, contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100625 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Richard Biener --- Fixed.
[Bug c/100625] ICE on gimple program: Segmentation fault, contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100625 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:086882b1c8faa8f99f98a9219ccec42d89db50c2 commit r12-839-g086882b1c8faa8f99f98a9219ccec42d89db50c2 Author: Richard Biener Date: Mon May 17 14:47:08 2021 +0200 c/100625 - avoid building invalid labels in the GIMPLE FE When duplicate labes are diagnosed, avoid building a GIMPLE_LABEL. 2021-05-17 Richard Biener PR c/100625 gcc/c/ * gimple-parser.c (c_parser_gimple_label): Avoid building a GIMPLE label with NULL label decl. gcc/testsuite/ * gcc.dg/gimplefe-error-9.c: New testcase.
[Bug bootstrap/100552] [11/12 Regression] configure: 32208: Syntax error: Bad substitution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100552 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Marius Hillenbrand : https://gcc.gnu.org/g:a16952ddf9515aa08b8c9c02a80725801131cc94 commit r11-8422-ga16952ddf9515aa08b8c9c02a80725801131cc94 Author: Marius Hillenbrand Date: Wed May 12 13:59:19 2021 +0200 IBM Z: Avoid bash-specific substitution in configure Fix a bootstrap error observed on NetBSD. 2021-05-17 Marius Hillenbrand gcc/ChangeLog: PR bootstrap/100552 * configure.ac: Replace pattern substitution with call to sed. * configure: Regenerate. (cherry picked from commit 47abe2abf1210847629ebc271b1fc8c6d53f0d47)
[Bug bootstrap/100552] [11/12 Regression] configure: 32208: Syntax error: Bad substitution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100552 --- Comment #2 from CVS Commits --- The master branch has been updated by Marius Hillenbrand : https://gcc.gnu.org/g:47abe2abf1210847629ebc271b1fc8c6d53f0d47 commit r12-838-g47abe2abf1210847629ebc271b1fc8c6d53f0d47 Author: Marius Hillenbrand Date: Wed May 12 13:59:19 2021 +0200 IBM Z: Avoid bash-specific substitution in configure Fix a bootstrap error observed on NetBSD. 2021-05-17 Marius Hillenbrand gcc/ChangeLog: PR bootstrap/100552 * configure.ac: Replace pattern substitution with call to sed. * configure: Regenerate.
[Bug libstdc++/100630] Unexpected implicit conversion from volatile bool& to std::filesystem::path in gcc <= 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100630 --- Comment #2 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:4cd69a5a0dd31bc6fdef1bbabc8d6d1416014ea1 commit r10-9831-g4cd69a5a0dd31bc6fdef1bbabc8d6d1416014ea1 Author: Jonathan Wakely Date: Mon May 17 11:54:06 2021 +0100 libstdc++: Fix filesystem::path constraints for volatile [PR 100630] The constraint check for filesystem::path construction uses decltype(__is_path_src(declval())) which mean it considers conversion from an rvalue. When Source is a volatile-qualified type it cannot use is_path_src(const Unknown&) because a const lvalue reference can only bind to a non-volatile rvalue. Since the relevant path members all have a const Source& parameter, the constraint should be defined in terms of declval(), not declval(). This avoids the problem of volatile-qualified rvalues, because we no longer use an rvalue at all. libstdc++-v3/ChangeLog: PR libstdc++/100630 * include/bits/fs_path.h (__is_constructible_from): Test construction from a const lvalue, not an rvalue. * include/experimental/bits/fs_path.h (__is_constructible_from): Likewise. * testsuite/27_io/filesystem/path/construct/100630.cc: New test. * testsuite/experimental/filesystem/path/construct/100630.cc: New test.
[Bug libstdc++/100612] std::jthread can't be initialized with a pointer to a member function taking a std::stop_token
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100612 --- Comment #9 from Jonathan O'Connor --- I'd already figured out the workaround using a static member function calling the non-static member function. But the lambda version is nicer!
[Bug target/100638] FP16 vector compare missed optimization on AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100638 Tamar Christina changed: What|Removed |Added Target Milestone|--- |12.0
[Bug target/100638] New: FP16 vector compare missed optimization on AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100638 Bug ID: 100638 Summary: FP16 vector compare missed optimization on AArch64 Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: tnfchris at gcc dot gnu.org Target Milestone: --- Target: aarch64-* The following testcase ``` #include void foo(float16_t *x, uint16x8_t *out) { float16x8x2_t xk = vld2q_f16(x); float16x8_t xk_re = xk.val[0]; float16x8_t xk_im = xk.val[1]; uint16x8_t theta_rx = xk_re < 0; uint16x8_t theta_ix = xk_im < 0; out[0] = theta_rx; out[1] = theta_ix; } ``` on AArch64 with `-Ofast -march=armv8.2-a+fp16` generates ``` foo: ld2 {v0.8h - v1.8h}, [x0] mov w2, -1 fcvts2, h0 fcvts18, h1 dup h3, v0.h[1] dup h24, v0.h[2] dup h23, v0.h[3] fcmpe s2, #0.0 fcvts3, h3 fcvts24, h24 dup h22, v0.h[4] cselw0, w2, wzr, mi fcvts23, h23 fcmpe s3, #0.0 dup v2.4h, w0 dup h17, v1.h[1] dup h16, v1.h[2] cselw0, w2, wzr, mi fcmpe s24, #0.0 dup h7, v1.h[3] dup h6, v1.h[4] dup h5, v1.h[5] dup h4, v1.h[6] dup h3, v1.h[7] mov v1.16b, v2.16b dup h21, v0.h[5] fcvts22, h22 fcvts17, h17 dup h20, v0.h[6] ins v1.h[1], w0 cselw0, w2, wzr, mi fcmpe s23, #0.0 fcvts21, h21 dup h19, v0.h[7] fcvts20, h20 fcvts16, h16 ins v1.h[2], w0 fcvts7, h7 cselw0, w2, wzr, mi fcmpe s22, #0.0 fcvts19, h19 fcvts6, h6 fcvts5, h5 fcvts4, h4 ins v1.h[3], w0 fcvts3, h3 cselw0, w2, wzr, mi fcmpe s21, #0.0 ins v1.h[4], w0 cselw0, w2, wzr, mi fcmpe s20, #0.0 ins v1.h[5], w0 cselw0, w2, wzr, mi fcmpe s19, #0.0 ins v1.h[6], w0 cselw0, w2, wzr, mi fcmpe s18, #0.0 ins v1.h[7], w0 cselw0, w2, wzr, mi fcmpe s17, #0.0 dup v0.4h, w0 cselw0, w2, wzr, mi fcmpe s16, #0.0 ins v0.h[1], w0 cselw0, w2, wzr, mi fcmpe s7, #0.0 ins v0.h[2], w0 cselw0, w2, wzr, mi fcmpe s6, #0.0 ins v0.h[3], w0 cselw0, w2, wzr, mi fcmpe s5, #0.0 ins v0.h[4], w0 cselw0, w2, wzr, mi fcmpe s4, #0.0 ins v0.h[5], w0 cselw0, w2, wzr, mi fcmpe s3, #0.0 ins v0.h[6], w0 cselw2, w2, wzr, mi ins v0.h[7], w2 stp q1, q0, [x1] ret ``` instead of simply ``` foo: ld2 { v0.8h, v1.8h }, [x0] fcmlt v2.8h, v0.8h, #0.0 fcmlt v0.8h, v1.8h, #0.0 stp q2, q0, [x1] ret ``` This is happening because veclower doesn't find a pattern for the FP16 vector compare and then lowers to operations on scalar. However even the lowered operations are inefficient: ``` fcvts23, h23 fcmpe s23, #0.0 ``` indicates that the backend doesn't know how to do this operation on fp16.
[Bug rtl-optimization/100622] Conversion to smaller unsigned type in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100622 --- Comment #4 from Thomas Koenig --- Yes, the masking should be only performed at the end. However, the inner loop could be further simplified to label: lwzu r8,4(r10) add r3,r8,r3 bdnz label without the need to do anything with r9, so this is probably more than one topic in one test case.
[Bug libstdc++/100631] ranges::elements_view:: _Sentinel is missing __distance_from() that can access _M_current of _Iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100631 --- Comment #5 from 康桓瑋 --- (In reply to TC from comment #4) > This one is a problem with the WP. Thanks, Tim, does it have an LWG number?
[Bug libstdc++/100612] std::jthread can't be initialized with a pointer to a member function taking a std::stop_token
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100612 --- Comment #8 from Jonathan Wakely --- N.B. in C++20 you can call your member function using a lambda: std::jthread t1{[&obj] (std::stop_token st) { obj.withStopToken(std::move(st)); } }; Or generically, with perfect forwarding: std::jthread t1{[&obj] (auto&&... args) { obj.withStopToken(std::forward(args)...); } };
[Bug middle-end/100582] vectorize failed to generate VEC_COND_EXPR for v32qi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100582 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Richard Biener --- Fixed.
[Bug middle-end/100582] vectorize failed to generate VEC_COND_EXPR for v32qi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100582 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:e0a5daf81f2c79a0275eccd7c1a25349990a7a4d commit r12-837-ge0a5daf81f2c79a0275eccd7c1a25349990a7a4d Author: Richard Biener Date: Mon May 17 13:56:14 2021 +0200 middle-end/100582 - fix array_at_struct_end_p for vector indexing Vector indexing leaves us with ARRAY_REFs of VIEW_CONVERT_EXPRs, sth which array_at_struct_end_p considers a array-at-struct-end even when there's an underlying decl visible. The following fixes the latter. 2021-05-17 Richard Biener PR middle-end/100582 * tree.c (array_at_struct_end_p): Get to the base of the reference before looking for the underlying decl. * gcc.target/i386/pr100582.c: New testcase.
[Bug tree-optimization/100512] [12 Regression] ICE during GIMPLE pass: cddce in mark_operand_necessary, at tree-ssa-dce.c:173 (under -O2 to -Os) since r12-623-g1416a1434c43de0b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100512 Aldy Hernandez changed: What|Removed |Added CC||zhendong.su at inf dot ethz.ch --- Comment #6 from Aldy Hernandez --- *** Bug 100636 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/100636] ICE at -Os and above: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100636 Aldy Hernandez changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Aldy Hernandez --- Duplicate. The variable c is undefined and is an input to a PHI. *** This bug has been marked as a duplicate of bug 100512 ***
[Bug c++/100634] [11/12 Regression] ICE in convert_nontype_argument, at cp/pt.c:7653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100634 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/100632] [11/12 Regression] ICE: Segmentation fault (in write_member_name) since r11-2237
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100632 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug target/100626] [11/12 Regression] ICE Segmentation fault (during RTL pass: split1) since r11-165-geb72dc663e9070b2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100626 Richard Biener changed: What|Removed |Added Priority|P3 |P2