[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=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=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=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=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=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=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 =
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=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=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=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=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{[] (std::stop_token st) {
obj.withStopToken(std::move(st)); }
};
Or generically, with perfect forwarding:
std::jthread t1{[] (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
[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 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-05-17 --- Comment #1 from Richard Biener --- I have a patch.
[Bug target/100623] [10/11/12 Regression] wrong code with -Os -fno-dce -fno-defer-pop -fno-forward-propagate -flive-range-shrinkage -fno-rerun-cse-after-loop -mno-push-args since r10-7515-g2c0fa3ecf70
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100623 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.4 Priority|P3 |P2
[Bug rtl-optimization/100622] Conversion to smaller unsigned type in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100622 --- Comment #3 from Richard Biener --- why is masking not needed? it looks like it is present in both cases, once before the return and once after the add (that could be sunk).
[Bug c/100620] ICE: in gimplify_var_or_parm_decl, at gimplify.c:2840
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100620 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords||accepts-invalid Version|tree-ssa|12.0 Last reconfirmed||2021-05-17 --- Comment #1 from Richard Biener --- OK, this is about t1 being used as variable and underlying decl for the SSA var t1_1. It would be nice to diagnose this indeed.
[Bug c++/100498] SFINAE and static inline function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100498 --- Comment #2 from Wolfgang Roehrl --- @Jonathan Wakely: Thank you very much for the detailled answer. Using this info it was possible for us to patch our 7.5 compiler version. At the moment we are constrained to use a 7.x compiler because we need support for the PowerPC e500 core. (To our knowledge this support has been phased out with the 8.x versions.)
[Bug c/100619] [11/12 Regression] ICE: in build_attr_access_from_parms, at c-family/c-attribs.c:5038 since r11-3303-g6450f07388f9fe57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100619 Richard Biener changed: What|Removed |Added Priority|P3 |P2
