[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 #2 from James McKelvey --- Occurs with and without optimization. I'll compare errors between the two.
[Bug c++/100632] New: [11/12 Regression] ICE: Segmentation fault (in write_member_name)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100632
Bug ID: 100632
Summary: [11/12 Regression] ICE: Segmentation fault (in
write_member_name)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
g++-12.0.0-alpha20210516 snapshot (g:4a322345cab10879162a2ddf659fb0f873ba0182)
ICEs when compiling the following testcase, extracted from
test/CodeGenCXX/mangle-class-nttp.cpp from the clang 12.0.0 test suite, w/
-std=c++20:
struct B { const int *p; };
template void f();
struct Nested { union { int k; }; } nested;
template void f();
% g++-12.0.0 -std=c++20 -c hwmzjgfh.cpp
hwmzjgfh.cpp:6:31: internal compiler error: Segmentation fault
6 | template void f();
| ^
0x10dbb6f crash_signal
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210516/work/gcc-12-20210516/gcc/toplev.c:327
0x9ddcd5 tree_check(tree_node*, char const*, int, char const*, tree_code)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210516/work/gcc-12-20210516/gcc/tree.h:3355
0x9ddcd5 write_member_name
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210516/work/gcc-12-20210516/gcc/cp/mangle.c:2875
0x9db2ca write_expression
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210516/work/gcc-12-20210516/gcc/cp/mangle.c:3412
0x9d9ad2 write_expression
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210516/work/gcc-12-20210516/gcc/cp/mangle.c:3547
0x9dbc36 write_expression
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210516/work/gcc-12-20210516/gcc/cp/mangle.c:3340
0x9de64f mangle_template_parm_object(tree_node*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210516/work/gcc-12-20210516/gcc/cp/mangle.c:4518
0xaa0f1a get_template_parm_object
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210516/work/gcc-12-20210516/gcc/cp/pt.c:7162
0xacb8ab convert_nontype_argument
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210516/work/gcc-12-20210516/gcc/cp/pt.c:7647
0xacb8ab convert_template_argument
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210516/work/gcc-12-20210516/gcc/cp/pt.c:8546
0xacd2c3 coerce_template_parms
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210516/work/gcc-12-20210516/gcc/cp/pt.c:9025
0xada921 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210516/work/gcc-12-20210516/gcc/cp/pt.c:21504
0xadbbe4 get_bindings
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210516/work/gcc-12-20210516/gcc/cp/pt.c:24738
0xadcaf1 determine_specialization
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210516/work/gcc-12-20210516/gcc/cp/pt.c:2335
0xae235c determine_specialization
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210516/work/gcc-12-20210516/gcc/cp/pt.c:2158
0xae235c check_explicit_specialization(tree_node*, tree_node*, int, int,
tree_node*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210516/work/gcc-12-20210516/gcc/cp/pt.c:3126
0x97c5e1 grokfndecl
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210516/work/gcc-12-20210516/gcc/cp/decl.c:10119
0x9838fd grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210516/work/gcc-12-20210516/gcc/cp/decl.c:13975
0xa747e4 cp_parser_explicit_instantiation
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210516/work/gcc-12-20210516/gcc/cp/parser.c:18285
0xa85470 cp_parser_declaration
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210516/work/gcc-12-20210516/gcc/cp/parser.c:14127
[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 #1 from James McKelvey --- Created attachment 50821 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50821=edit Source of Main
[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 #2 from Fangrui Song --- (In reply to Alexander Monakov from comment #1) > It is not necessary to change -fno-pic code generation to gain most of the > -Bsymbolic benefit It is necessary, otherwise the function address taken from the -Bsymbolic/-Bsymbolic-functions/-Bsymbolic-global-functions shared object may be different from the address taken from the -fno-pic code. The ELF hack is called canonical PLT entry, similar to copy relocations. > as you say, the most important point is to avoid jumping > via PLT trampolines (or, with -fno-plt, GOT loads) for function calls, so > the linker could do -Bsymbolic relaxation for sites where address doesn't > matter (calls and jumps) while keeping a dynamic relocation for address > loads? Under some new option of course, like -Bsymbolic-plt. Right? There are two points: (1) R_*_JUMP_SLOT symbol lookup cost (2) whether call sites get penalized by the PLT indirection. -fno-pic code must use GOT (instead of an absolute relocation) for default visibility external function access to be compatible with a -Bsymbolic/-Bsymbolic-functions/-Bsymbolic-global-functions shared object.
[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 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #1 from Alexander Monakov --- It is not necessary to change -fno-pic code generation to gain most of the -Bsymbolic benefit: as you say, the most important point is to avoid jumping via PLT trampolines (or, with -fno-plt, GOT loads) for function calls, so the linker could do -Bsymbolic relaxation for sites where address doesn't matter (calls and jumps) while keeping a dynamic relocation for address loads? Under some new option of course, like -Bsymbolic-plt. Right?
[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 #2 from 康桓瑋 ---
In addition, I think elements_view::_Sentinel::_M_equal should be a template
function, and elements_view::_Iterator also needs to declare _Sentinel
as a friend, otherwise the following valid codes will be rejected:
https://godbolt.org/z/7aa75vqsP
#include
int main() {
auto r = std::views::iota(0)
| std::views::transform([](int) { return std::make_pair(42, "hello"); })
| std::views::keys;
auto b = std::ranges::cbegin(r);
auto e = std::end(r);
b.base() == e.base();
b == e; // error
}
:12:9: required from here
/opt/compiler-explorer/gcc-trunk-20210513/include/c++/12.0.0/ranges:3675:34:
error: cannot convert 'const
std::ranges::elements_view, main():: >, 0>::_Iterator' to
'const
std::ranges::elements_view, main():: >, 0>::_Iterator&'
3675 | { return __y._M_equal(__x); }
| ^
/opt/compiler-explorer/gcc-trunk-20210513/include/c++/12.0.0/ranges:3645:45:
note: initializing argument 1 of 'constexpr bool
std::ranges::elements_view<_Vp, _Nm>::_Sentinel<_Const>::_M_equal(const
std::ranges::elements_view<_Vp, _Nm>::_Iterator<_Const>&) const [with bool
_Const = false; _Vp = std::ranges::transform_view, main():: >; long unsigned int _Nm =
0]'
3645 | _M_equal(const _Iterator<_Const>& __x) const
|~^~~
[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 #1 from 康桓瑋 ---
Another issue is that in elements_view::_Sentinel in ranges#L3677:
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; }
the return type of the function is range_difference_t<_Base2>, but in
[range.elements#sentinel], it is defined as range_difference_t:
template
requires sized_sentinel_for, iterator_t>>
friend constexpr range_difference_t
operator-(const iterator& x, const sentinel& y);
Perhaps range_difference_t and range_difference_t<_Base2> are equivalent
in this case, but I am not sure.
[Bug libstdc++/100631] New: 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
Bug ID: 100631
Summary: ranges::elements_view:: _Sentinel is missing
__distance_from() that can access _M_current of
_Iterator
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
We should add a __distance_from() to elements_view::_Sentinel just like
transform_view:: _Sentinel does.
https://godbolt.org/z/Ezxh78bv5
#include
int main() {
auto r = std::views::iota(0)
| std::views::filter([](int){ return true; })
| std::views::take(42)
| std::views::reverse
| std::views::transform([](int) { return std::make_pair(42, "hello"); })
| std::views::take(42)
| std::views::keys;
auto b = r.begin();
auto e = r.end();
e - b;
}
:13:8: required from here
/opt/compiler-explorer/gcc-trunk-20210513/include/c++/12.0.0/ranges:3689:39:
error:
'std::ranges::iterator_t, main():: > > >,
main():: > > >
std::ranges::elements_view, main():: > > >,
main():: > >, 0>::_Iterator::_M_current' is private within
this context
3689 | { return __x._M_end - __y._M_current; }
| ^~
/opt/compiler-explorer/gcc-trunk-20210513/include/c++/12.0.0/ranges:3465:29:
note: declared private here
3465 | iterator_t<_Base> _M_current = iterator_t<_Base>();
| ^~
[Bug target/59371] [9/10/11/12 Regression] Performance regression in GCC 4.8/9/10/11/12 and later versions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59371
--- Comment #28 from Jiu Fu Guo ---
If change code as below, 'i' is not starting from '0', and 'compare code' is
'!='
then wrap/overflow on 'i' may happen, and optimizations (e.g. vectorization)
are not applied.
The below patch is trying to optimize this kind of loop.
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570424.html
int foo (int *p, unsigned short u_n, unsigned short i)
{
int x = 0;
for (; i != u_n; i++) {
x = x + p[i];
}
return x;
}
[Bug target/59371] [9/10/11/12 Regression] Performance regression in GCC 4.8/9/10/11/12 and later versions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59371 Jiu Fu Guo changed: What|Removed |Added CC||guojiufu at gcc dot gnu.org --- Comment #27 from Jiu Fu Guo --- For -O2, since a few optimizations are not enabled (e.g. some loop-based optimizations), the code was not optimized too much. At -O3, now, GCC could vectorize it. While with GCC 4.8, the code was not vectorized. I guess the pain in performance may be mitigated.
[Bug tree-optimization/100499] Different results with -fpeel-loops -ftree-loop-vectorize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 --- Comment #9 from bin cheng --- Seems we have a long standing bug in fold-const.c:multiple_of_p in case of wrapping types. Take unsigned int as an example: (0xfffc * 0x3) % 0x3 = 0x1 But multiple_of_p returns true here. The same issue also stands for MINUS_EXPR and PLUS_EXPR. Given multiple_of_p is used elsewhere, the fix might break existing optimizations. Especially, number of loop iterations is computed in unsigned types
[Bug target/100626] ICE Segmentation fault (during RTL pass: split1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100626
--- Comment #1 from Haoxin Tu ---
Another test case that crashes on all -O1 to -Os.
$cat small.c
#include
int uc_4, i_5, us_7;
void fn1() {
int li_18;
int64_t *ptr_43 = _18;
for (; us_7;) {
fn2();
*ptr_43 ^= uc_4;
}
i_5 = li_18;
}
[Bug fortran/94289] Assumed-rank array bounds resuscitate on the second call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94289 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #4 from sandra at gcc dot gnu.org --- I'm still seeing failures on mainline head, specifically these 3 groups: Testing pointer array Using assumed-rank array: lbound: expected: [ 1 1 1] got: [ 3 5 9] FAIL! ubound: expected: [ 2 46 3] got: [ 4 50 11] FAIL! Testing allocatable array Using assumed-rank array: lbound: expected: [ 1 1 1] got: [ 3 5 9] FAIL! ubound: expected: [ 2 46 3] got: [ 4 50 11] FAIL! Testing explicit array Using assumed-rank array: lbound: expected: [ 1 1 1] got: [ 3 5 9] FAIL! ubound: expected: [ 2 46 3] got: [ 4 50 11] FAIL! I'm also confused about the validity of the expectations. :-S
[Bug libstdc++/100630] New: Unexpected implicit conversion from volatile bool& to std::filesystem::path in gcc <= 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100630
Bug ID: 100630
Summary: Unexpected implicit conversion from volatile bool& to
std::filesystem::path in gcc <= 10
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
I came across this issue today (which I think is unexpected) with gcc 8, 9 and
10. It seems that the following code triggers some implicit conversion from
volatile bool& to std::filesystem::path while this was definitely not the
intention:
#include
#include
class Printer
{
public:
Printer& operator<<(bool iValue)
{
std::cout << __PRETTY_FUNCTION__<< ": " << std::boolalpha << iValue
<< std::endl;
return *this;
};
Printer& operator<<(const std::filesystem::path& iPath)
{
std::cout << __PRETTY_FUNCTION__<< ": " << std::boolalpha << iPath
<< std::endl;
return *this;
};
};
int main()
{
Printer aPrinter;
volatile bool a = false;
aPrinter << a;
};
It raises the following error (for example using gcc 10 in Compiler Explorer):
In file included from
/opt/compiler-explorer/gcc-10.3.0/include/c++/10.3.0/filesystem:45,
from :1:
/opt/compiler-explorer/gcc-10.3.0/include/c++/10.3.0/bits/fs_path.h: In
instantiation of 'struct
std::filesystem::__cxx11::__detail::__constructible_from':
/opt/compiler-explorer/gcc-10.3.0/include/c++/10.3.0/type_traits:138:12:
required from 'struct std::__and_ >,
std::filesystem::__cxx11::__detail::__constructible_from
>'
/opt/compiler-explorer/gcc-10.3.0/include/c++/10.3.0/type_traits:143:12:
required from 'struct std::__and_ >, std::__not_ >,
std::filesystem::__cxx11::__detail::__constructible_from
>'
/opt/compiler-explorer/gcc-10.3.0/include/c++/10.3.0/bits/fs_path.h:123:11:
required by substitution of 'template using _Path =
typename std::enable_if >::type,
std::filesystem::__cxx11::path> >, std::__not_::type> >,
std::filesystem::__cxx11::__detail::__constructible_from<_Tp1, _Tp2> >::value,
std::filesystem::__cxx11::path>::type [with _Tp1 = volatile bool; _Tp2 = void]'
/opt/compiler-explorer/gcc-10.3.0/include/c++/10.3.0/bits/fs_path.h:223:7:
required by substitution of 'template
std::filesystem::__cxx11::path::path(const _Source&,
std::filesystem::__cxx11::path::format) [with _Source = volatile bool; _Require
= ]'
:27:17: required from here
/opt/compiler-explorer/gcc-10.3.0/include/c++/10.3.0/bits/fs_path.h:119:29:
error: no matching function for call to '__is_path_src(volatile bool, int)'
119 | : decltype(__is_path_src(std::declval<_Source>(), 0))
|~^~~~
/opt/compiler-explorer/gcc-10.3.0/include/c++/10.3.0/bits/fs_path.h:95:5: note:
candidate: 'template
std::filesystem::__cxx11::__detail::__is_path_iter_src<_Iter>
std::filesystem::__cxx11::__detail::__is_path_src(_Iter, int)'
95 | __is_path_src(_Iter, int);
| ^
/opt/compiler-explorer/gcc-10.3.0/include/c++/10.3.0/bits/fs_path.h:95:5: note:
template argument deduction/substitution failed:
/opt/compiler-explorer/gcc-10.3.0/include/c++/10.3.0/bits/fs_path.h: In
substitution of 'template using
__is_path_iter_src = std::__and_::type, char>,
std::is_same::type, wchar_t>, std::is_same::type, char16_t>,
std::is_same::type, char32_t> >,
std::is_base_of > [with _Iter = bool; _Iter_traits =
std::iterator_traits]':
/opt/compiler-explorer/gcc-10.3.0/include/c++/10.3.0/bits/fs_path.h:95:5:
required by substitution of 'template
std::filesystem::__cxx11::__detail::__is_path_iter_src<_Iter>
std::filesystem::__cxx11::__detail::__is_path_src(_Iter, int) [with _Iter =
bool]'
/opt/compiler-explorer/gcc-10.3.0/include/c++/10.3.0/bits/fs_path.h:119:29:
required from 'struct
std::filesystem::__cxx11::__detail::__constructible_from'
/opt/compiler-explorer/gcc-10.3.0/include/c++/10.3.0/type_traits:138:12:
required from 'struct std::__and_ >,
std::filesystem::__cxx11::__detail::__constructible_from
>'
/opt/compiler-explorer/gcc-10.3.0/include/c++/10.3.0/type_traits:143:12:
required from 'struct std::__and_ >, std::__not_ >,
std::filesystem::__cxx11::__detail::__constructible_from
>'
/opt/compiler-explorer/gcc-10.3.0/include/c++/10.3.0/bits/fs_path.h:123:11:
required by substitution of 'template using _Path =
typename std::enable_if >::type,
std::filesystem::__cxx11::path> >, std::__not_::type> >,
std::filesystem::__cxx11::__detail::__constructible_from<_Tp1, _Tp2> >::value,
std::filesystem::__cxx11::path>::type [with _Tp1 = volatile bool; _Tp2 = void]'
/opt/compiler-explorer/gcc-10.3.0/include/c++/10.3.0/bits/fs_path.h:223:7:
required by substitution of 'template
std::filesystem::__cxx11::path::path(const
[Bug c++/100629] New: Regression from 10 symbol mismatch between class definition and use with optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100629 Bug ID: 100629 Summary: Regression from 10 symbol mismatch between class definition and use with optimization Product: gcc Version: 11.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mckelvey at maskull dot com Target Milestone: --- Created attachment 50820 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50820=edit Source of Break class On gcc-11/12 I get undefined symbols on link. Like this: /usr/bin/ld: header_edit.o:header_edit.cc:(.text.startup+0x36a): undefined reference to `_ZN13PatternDriver12BreakPatternC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKNS_26ConflateIntegerScalarValueESB_RKNS_12TemplateEnumIL_ZNS_16complement_namesB5cxx11EEL_ZNS_14COMPLEMENTENUM' >From main program header_edit.o: _ZN13PatternDriver12BreakPatternC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKNS_26ConflateIntegerScalarValueESB_RKNS_12TemplateEnumIL_ZNS_16complement_namesB5cxx11EEL_ZNS_14COMPLEMENTENUM from BreakPattern.o: _ZN13PatternDriver12BreakPatternC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKNS_26ConflateIntegerScalarValueESB_RKNS_12TemplateEnumIL_ZNS_16complement_namesEEL_ZNS_14COMPLEMENTENUM The problem is that the second string has the sequence B5cxx11. That sequence goes away when I change the optimization level from level 3 to default. I don't know how to reduce to a simple test case.
[Bug tree-optimization/96928] Failure to optimize one's complement abs pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96928 --- Comment #4 from Andrew Pinski --- Note while moving this optimization to match-and-simplify I noticed that the gimple produced is: (~a) ^ b But this get changed around to: ~(a ^ b) By PRE latter on. I only noticed this because the testcase is failing as it depends being that.
[Bug inline-asm/100628] New: fftw segfaults with gcc-9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100628 Bug ID: 100628 Summary: fftw segfaults with gcc-9 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: inline-asm Assignee: unassigned at gcc dot gnu.org Reporter: philip at balister dot org Target Milestone: --- Debian has this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943396#31 I've duplicated this in the dunfell release of the Yocto Project using the qemuarm machine. Using gdb, I also concluded the code doubled the value of r3 leading to the segfault. Let me know what I can do to collect more information. This is has worked in later gcc's and earlier ones. Hunting through gcc commit logs hasn't got me anywhere.
[Bug c/100483] Extend -fno-semantic-interposition to global variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100483 --- Comment #6 from Jan Hubicka --- > Thanks for the clarification. I misinterpreted the documentation. > Then it seems that -fno-semantic-interposition is a very safe optimization for > distributions to default to. Closing as intended. Basically -fno-semantic-interposition is OK unless you want to play tricks like interposing alternative malloc implementations. This comes very handy for some low-level libraries but I did not see it being used for interposing say some QT symbols or so. Honza
[Bug c/100483] Extend -fno-semantic-interposition to global variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100483 Fangrui Song changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #5 from Fangrui Song --- (In reply to Jan Hubicka from comment #3) Thanks for the clarification. I misinterpreted the documentation. Then it seems that -fno-semantic-interposition is a very safe optimization for distributions to default to. Closing as intended. I will try changing Clang to drop the local aliases for variables. It is tricky not to use local aliases for address taking of functions, though. Fortunately, this will not cause any problems once we do https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593 (In reply to H.J. Lu from comment #4) I will much appreciate it if you want to fix some copy relocations/canonical PLT entries issues so that it will be more easy for distributions to switch to something like a default -Wl,-Bsymbolic-global-functions. What does ld.so do for the proposed GNU_PROPERTY_SINGLE_GLOBAL_DEFINITION? Does it apply to STB_GLOBAL or also STB_WEAK? Does it add all definitions to a global namespace to enforce single definition for every candidate? If it does the additional check, this would further slow down dynamic linking. And I believe we should do the function oriented non-interposition-by-default plan, which will not be blocked by copy relocation elimination. (https://maskray.me/blog/2021-05-16-elf-interposition-and-bsymbolic#copy-relocations)
[Bug tree-optimization/100453] [12 Regression] wrong code at -O1 and above since r12-434
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100453 --- Comment #11 from Eric Botcazou --- *** Bug 100601 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/100601] wrong code at -O1 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100601 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE CC||ebotcazou at gcc dot gnu.org --- Comment #1 from Eric Botcazou --- Please avoid creating trivial duplicates. *** This bug has been marked as a duplicate of bug 100453 ***
[Bug target/100627] missing optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100627 --- Comment #1 from Andrew Pinski --- This is a target issue dealing with how uint64_t ->float/double conversions are done. On aarch64 for cvt_f64_std we get good code at -O3: cvt_f64_std(std::array&, std::array const&): ldp q7, q6, [x1] ldp q5, q4, [x1, 32] ldp q3, q2, [x1, 64] ldp q1, q0, [x1, 96] ucvtf v7.2d, v7.2d ucvtf v6.2d, v6.2d ucvtf v5.2d, v5.2d ucvtf v4.2d, v4.2d ucvtf v3.2d, v3.2d ucvtf v2.2d, v2.2d stp q7, q6, [x0] ucvtf v1.2d, v1.2d stp q5, q4, [x0, 32] ucvtf v0.2d, v0.2d stp q3, q2, [x0, 64] stp q1, q0, [x0, 96] ret The other function is: cvt_f32_std(std::array&, std::array const&): ldp x3, x2, [x1] ucvtf s7, x2 ucvtf s3, x3 ldp x3, x2, [x1, 32] ins v3.s[1], v7.s[0] ucvtf s6, x2 ucvtf s2, x3 ldp x3, x2, [x1, 64] ins v2.s[1], v6.s[0] ucvtf s5, x2 ucvtf s1, x3 ldp x3, x2, [x1, 96] ins v1.s[1], v5.s[0] ucvtf s4, x2 ucvtf s0, x3 ldr x2, [x1, 48] ldr x3, [x1, 16] ucvtf s17, x2 ldr x2, [x1, 112] ucvtf s18, x3 ldr x3, [x1, 80] ins v0.s[1], v4.s[0] ucvtf s4, x2 ucvtf s16, x3 ldr x2, [x1, 24] ldr x3, [x1, 56] ucvtf s7, x2 ldr x2, [x1, 88] ucvtf s6, x3 ldr x1, [x1, 120] ucvtf s5, x2 ins v3.s[2], v18.s[0] ins v2.s[2], v17.s[0] ins v1.s[2], v16.s[0] ins v0.s[2], v4.s[0] ucvtf s4, x1 ins v3.s[3], v7.s[0] ins v2.s[3], v6.s[0] ins v1.s[3], v5.s[0] ins v0.s[3], v4.s[0] stp q3, q2, [x0] stp q1, q0, [x0, 32] ret
[Bug tree-optimization/100627] New: missing optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100627 Bug ID: 100627 Summary: missing optimization Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: g.peterh...@t-online.de Target Milestone: --- Hello gcc team, i think i wrote something like that a long time ago, but i'm not sure. I think the standard conversion uint64_t -> float/double is inefficient when AVX512 is not available. At least on x86, but with SVE or other CPUs this may not be the case. Problems: - a lot of conditional jumps are generated, not BPU-friendly - and therefore not branchfree - larger codesize I briefly implemented a few conversions for SSE/SSE2 (https://godbolt.org/z/n63WedKT9). Advantages: - branchfree - mostly smaller codesize - more quickly Wouldn't it make sense to implement the standard conversion in this way (including for AVX/AVX2)? thx Gero
[Bug c/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 Andrew Pinski changed: What|Removed |Added Version|tree-ssa|12.0 Target Milestone|--- |11.2 Keywords||ice-on-valid-code
[Bug middle-end/100624] ICE: Segmentation fault, gimplify_target_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100624 Andrew Pinski changed: What|Removed |Added Depends on||98195 --- Comment #1 from Andrew Pinski --- Most likely a dup of bug 98195. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98195 [Bug 98195] [11/12 Regression] internal compiler error: Segmentation fault
[Bug tree-optimization/100626] New: ICE Segmentation fault (during RTL pass: split1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100626
Bug ID: 100626
Summary: ICE Segmentation fault (during RTL pass: split1)
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi all.
I don't know if there is a dup of this. I have searched but failed.
$cat small.c
#include
int uc_4, i_5, us_7;
void fn1() {
int li_18;
int64_t *ptr_43 = _18;
for (; us_7;) {
fn2();
*ptr_43 ^= uc_4;
}
i_5 = li_18;
}
$gcc -w -O1 -m32 small.c
during RTL pass: split1
small.c: In function ‘fn1’:
small.c:11:1: internal compiler error: Segmentation fault
11 | }
| ^
0xb2bebf crash_signal
../../gcc/toplev.c:327
0xe885ca ix86_fixup_binary_operands(rtx_code, machine_mode, rtx_def**)
../../gcc/config/i386/i386-expand.c:900
0xe8877b ix86_expand_binary_operator(rtx_code, machine_mode, rtx_def**)
../../gcc/config/i386/i386-expand.c:943
0x11a016e gen_split_216(rtx_insn*, rtx_def**)
../../gcc/config/i386/i386.md:9714
0x137d6a2 split_insns(rtx_def*, rtx_insn*)
../../gcc/config/i386/i386.md:14112
0x808ffe try_split(rtx_def*, rtx_insn*, int)
../../gcc/emit-rtl.c:3834
0xaa0f51 split_insn
../../gcc/recog.c:3363
0xaa63e7 split_all_insns()
../../gcc/recog.c:3467
0xaa6478 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
[Bug c/100625] New: 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
Bug ID: 100625
Summary: ICE on gimple program: Segmentation fault,
contains_struct_check(tree_node*,
tree_node_structure_enum, char const*, int, char
const*)
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: cnsun at uwaterloo dot ca
Target Milestone: ---
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.eZIsobWkq2-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210514 (experimental) [master revision
:e5c3c8afa:f3b1516d9dfd969d7cc1ca6f26dec13478a1c458] (GCC)
$ cat mutant.c
__GIMPLE
foo() {
bb1:
bb1:;
}
$ gcc-trunk -fgimple mutant.c
mutant.c:2:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
2 | foo() {
| ^~~
mutant.c: In function ‘foo’:
mutant.c:4:1: error: duplicate label ‘bb1’
4 | bb1:;
| ^~~
mutant.c:3:1: note: previous definition of ‘bb1’ with type ‘void’
3 | bb1:
| ^~~
during GIMPLE pass: cfg
mutant.c:2:1: internal compiler error: Segmentation fault
2 | foo() {
| ^~~
0xef83e3 crash_signal
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/toplev.c:327
0xf38755 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/tree.h:3469
0xf38755 stmt_starts_bb_p
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/tree-cfg.c:2784
0xf38755 make_blocks_1
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/tree-cfg.c:552
0xf44fd6 make_blocks
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/tree-cfg.c:661
0xf44fd6 build_gimple_cfg
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/tree-cfg.c:226
0xf44fd6 execute_build_cfg
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/tree-cfg.c:370
0xf44fd6 execute
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/tree-cfg.c:409
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c/100624] New: ICE: Segmentation fault, gimplify_target_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100624
Bug ID: 100624
Summary: ICE: Segmentation fault, gimplify_target_expr
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: cnsun at uwaterloo dot ca
Target Milestone: ---
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.eZIsobWkq2-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210514 (experimental) [master revision
:e5c3c8afa:f3b1516d9dfd969d7cc1ca6f26dec13478a1c458] (GCC)
$ cat mutant.c
_Atomic c;
void foo() { double j = c /= foo(); }
$ gcc-trunk mutant.c
mutant.c:1:9: warning: type defaults to ‘int’ in declaration of ‘c’
[-Wimplicit-int]
1 | _Atomic c;
| ^
mutant.c: In function ‘foo’:
mutant.c:2:1: error: void value not ignored as it ought to be
2 | void foo() { double j = c /= foo(); }
| ^~~~
mutant.c:2:27: internal compiler error: Segmentation fault
2 | void foo() { double j = c /= foo(); }
| ^~
0xef83e3 crash_signal
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/toplev.c:327
0xc34ee2 gimplify_target_expr
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/gimplify.c:6772
0xc269e2 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/gimplify.c:14480
0xc29eaa gimplify_stmt(tree_node**, gimple**)
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/gimplify.c:6877
0xc274ab gimplify_statement_list
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/gimplify.c:1879
0xc274ab gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/gimplify.c:14528
0xc29eaa gimplify_stmt(tree_node**, gimple**)
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/gimplify.c:6877
0xc2a2d9 gimplify_compound_expr
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/gimplify.c:6077
0xc3049d gimplify_modify_expr_rhs
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/gimplify.c:5398
0xc36c3a gimplify_modify_expr
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/gimplify.c:5773
0xc26578 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/gimplify.c:14083
0xc29eaa gimplify_stmt(tree_node**, gimple**)
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/gimplify.c:6877
0xc34ba7 gimplify_and_add(tree_node*, gimple**)
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/gimplify.c:489
0xc34ba7 gimplify_decl_expr
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/gimplify.c:1826
0xc270f2 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/gimplify.c:14280
0xc29eaa gimplify_stmt(tree_node**, gimple**)
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/gimplify.c:6877
0xc2a6de gimplify_bind_expr
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/gimplify.c:1421
0xc26913 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/gimplify.c:14284
0xc29eaa gimplify_stmt(tree_node**, gimple**)
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/gimplify.c:6877
0xc2b4a3 gimplify_body(tree_node*, bool)
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/gimplify.c:15328
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c/100483] Extend -fno-semantic-interposition to global variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100483 --- Comment #4 from H.J. Lu --- Symbol resolution in an executable or a shared library at run-time is determined by 1. Linker options + all input files at link-time. 2. ld.so + all shared libraries at run-time. Add a compiler option at compile-time has very limited impact on symbol resolution at run-time. My GNU_PROPERTY_SINGLE_GLOBAL_DEFINITION proposal provides a way to specify symbol resolution at compile-time, link-time and link-time.
[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 #7 from Jonathan O'Connor --- libstdc++. Woops, apologies! I feel somewhat vindicated by your non __STRICT_ANSI__ change! I'll now go away and write the proposal. Thanks for the encouragement.
[Bug target/100623] New: [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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100623 Bug ID: 100623 Summary: [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 Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 50819 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50819=edit reduced testcase (from openssl sources) Output: $ x86_64-pc-linux-gnu-gcc -Os -fno-dce -fno-defer-pop -fno-forward-propagate -flive-range-shrinkage -fno-rerun-cse-after-loop -mno-push-args testcase.c $ ./a.out Aborted bn_add_words() is called with r == NULL $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-815-20210516001637-g1ba3f0ef546-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r12-815-20210516001637-g1ba3f0ef546-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.0 20210516 (experimental) (GCC)
[Bug jit/100380] Segfault when using inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100380 --- Comment #5 from Antoni --- I can confirm that the problem is indeed what I described in my previous post. One solution would be to check if the rvalue was replayed (and if not, replay it now), but that involves adding this check everywhere, so that seems very invasive. Do you think there's a better solution?
[Bug fortran/100602] [11/12 Regression] Erroneous "pointer argument is not associated" runtime error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100602 Dominique d'Humieres changed: What|Removed |Added Known to fail||11.1.0, 12.0 Known to work||10.3.0 Priority|P3 |P4 Keywords||rejects-valid Target Milestone|--- |11.2 Summary|Erroneous "pointer argument |[11/12 Regression] |is not associated" runtime |Erroneous "pointer argument |error. |is not associated" runtime ||error. --- Comment #2 from Dominique d'Humieres --- This looks like a regression.
[Bug fortran/100607] ICE with SELECT RANK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100607 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2021-05-16 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug c/100618] Add a -fno-semantic-interposition variant which allows variable interposition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100618 --- Comment #3 from Alexander Monakov --- Furthermore as discussed in bug 100483 this request appears based on a misunderstanding what the 'semantic-' part of the option is about. It does not affect assembly/linker-level binding mechanism, so things like presence of copy relocations should not be affected.
[Bug c/100483] Extend -fno-semantic-interposition to global variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100483
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #3 from Jan Hubicka ---
As author of the flag I agree with Alexander.
-fno-semantic-interposition basically means that variables or functions can be
interposed only if the replacement is semantically equivalent. For variables it
means that they have same constructor and for function that the effect of the
function call is the same. So it allows inter-procedural optimization across
interposable functions and constant folding of reads of constant interposable
variables.
% cat a.c
int var;
int foo() { return var; }
(I implemented this for clang 11 x86)
% clang -fpic -fno-semantic-interposition -O2 -S a.c
% cat a.s
...
foo:# @foo
.Lfoo$local:
# %bb.0:# %entry
movl.Lvar$local(%rip), %eax
retq
...
this is wrong transformation since it will break when one writes var in one DSO
and reads it from another.
I think it is misinterpretation of semantic interposition flag at clang's side.
[Bug c/100483] Extend -fno-semantic-interposition to global variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100483
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comment #2 from Alexander Monakov ---
I'm afraid this is potentially misunderstanding what the word 'semantic' in
-fno-semantic-interposition implies. I am not the author, but I always
understood this like so:
GCC is concerned with two aspects of ELF interposition: address interposition
(for address uniqueness) and functionality interposition (e.g. hooking malloc).
For optimization, the compiler cares a lot about the latter (it blocks inlining
and other optimizations), but not so much about the former (taking an address
of a global is rarely on the hot paths, so it's not critical to convert GOT
loads to pc-relative relocations).
So GCC splits ELF interposition concerns to 'address interposition' and
'semantic interposition', maintains the ability to perform the former (so
address uniqueness is not broken), and allows the programmer to promise that
semantic interposition (interposing a function with another function that acts
differently) does not happen.
To illustrate, compiling
void f(){
asm("#");
}
void *g(){
f();
return f;
}
with -O2 -fpic -fno-semantic-interposition yields
f:
#
ret
g:
#
movqf@GOTPCREL(%rip), %rax
ret
i.e. the call is inlined, but taking the address goes through the GOT.
[Bug c++/100616] [modules] ICE when a variable of class taking a non-type template argument is defined both inside and outside the module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100616 --- Comment #2 from wang ivor --- One workaround I found is to always use templates to refer to C inside modules and only ever instantiate them in the outermost translation units. Or, if you only instantiate C with template arguments of primitive types (e.g. int, char, pointer types of primitive types, etc.) this bug doesn't happen.
[Bug c++/100617] [modules] Exported namespace not visible from outside when the module imports another module that declares the same namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100617 --- Comment #1 from wang ivor --- A workaround is to create a module that exports only the namespace A and 'export import' it in the module 'test1'.
[Bug libstdc++/95833] Incorrect static_assert in std::reduce overload taking a binary functor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95833 --- Comment #3 from Tony E Lewis --- Great. Thanks very much.
[Bug rtl-optimization/100622] New: Conversion to smaller unsigned type in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100622
Bug ID: 100622
Summary: Conversion to smaller unsigned type in loop
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Consider
unsigned int foo(unsigned int *a, int n)
{
int i;
unsigned int res = 0;
for (i=0; i:
0: 00 00 04 2c cmpwi r4,0
4: 30 00 81 40 ble 34
8: 20 00 89 78 clrldi r9,r4,32
c: fc ff 43 39 addir10,r3,-4
10: 00 00 60 38 li r3,0
14: a6 03 29 7d mtctr r9
18: 04 00 0a 85 lwzur8,4(r10)
1c: 14 1a 68 7c add r3,r8,r3
20: 20 00 63 78 clrldi r3,r3,32
24: ff ff 29 39 addir9,r9,-1
28: 20 00 29 79 clrldi r9,r9,32
2c: ec ff 00 42 bdnz18
30: 20 00 80 4e blr
34: 00 00 60 38 li r3,0
38: 20 00 80 4e blr
...
0048 :
48: 00 00 04 2c cmpwi r4,0
4c: 30 00 81 40 ble 7c
50: 20 00 89 78 clrldi r9,r4,32
54: fc ff 43 39 addir10,r3,-4
58: 00 00 60 38 li r3,0
5c: a6 03 29 7d mtctr r9
60: 04 00 0a 85 lwzur8,4(r10)
64: 14 42 63 7c add r3,r3,r8
68: ff ff 29 39 addir9,r9,-1
6c: 20 00 29 79 clrldi r9,r9,32
70: f0 ff 00 42 bdnz60
74: 20 00 63 78 clrldi r3,r3,32
78: 20 00 80 4e blr
7c: 00 00 60 38 li r3,0
80: f4 ff ff 4b b 74
so there is an extra instruction to mask the result of the
addition in foo. This should not be needed.
[Bug c/100618] Add a -fno-semantic-interposition variant which allows variable interposition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100618 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #2 from Alexander Monakov --- The implied split is 'code,data,tls-data' rather than 'functions,variables' (there are constants too, which are not variables, but should be treated like variables here; and TLS data does not rely on copy relocations). Since the original option was intended to be used mainly in the negative form, I think it may be less confusing to introduce -f[no-]semantic-code-interposition
