[Bug ipa/94245] New: [10 Regression] ICE in ipa_find_agg_cst_for_param, at ipa-prop.c:3467 since r10-7237-g4e3d3e40726e1b68
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94245
Bug ID: 94245
Summary: [10 Regression] ICE in ipa_find_agg_cst_for_param, at
ipa-prop.c:3467 since r10-7237-g4e3d3e40726e1b68
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: marxin at gcc dot gnu.org, rguenth at gcc dot gnu.org
Target Milestone: ---
I hope it's the last fallout:
$ cat x.ii
template < typename, typename, typename, typename, typename = int >
class _Rb_tree {
typedef int *_Link_type;
struct _Alloc_node {
_Alloc_node(_Rb_tree &__t) : _M_t(__t) {}
template < typename _Arg > _Link_type operator()(_Arg) {
_M_t._M_create_node(0);
}
_Rb_tree &_M_t;
};
template < typename _Args > void _M_create_node(_Args);
template < typename _NodeGen > void _M_clone_node(int, _NodeGen &__node_gen)
{
int *__trans_tmp_1 = __node_gen(__trans_tmp_1);
}
template < typename _NodeGen > _Link_type _M_copy(int, int, _NodeGen &);
template < typename _NodeGen > void _M_copy(_Rb_tree, _NodeGen __gen) {
_M_copy(0, 0, __gen);
}
void _M_copy(_Rb_tree __x) {
_Alloc_node __an(*this);
_M_copy(__x, __an);
}
public:
_Rb_tree(const _Rb_tree &__x) { _M_copy(__x); }
};
template < typename _Key, typename _Val, typename _KoV, typename _Compare,
typename _Alloc >
template < typename _NodeGen >
typename _Rb_tree< _Key, _Val, _KoV, _Compare, _Alloc >::_Link_type
_Rb_tree< _Key, _Val, _KoV, _Compare, _Alloc >::_M_copy(int __x, int,
_NodeGen &__node_gen) {
_M_clone_node(__x, __node_gen);
}
class map {
_Rb_tree< int, int, int, int > _M_t;
};
class Trans_NS___cxx11_basic_string;
template < typename V > class static_map {
map _m;
public:
static_map(Trans_NS___cxx11_basic_string, V);
operator map() { return _m; }
};
class Trans_NS___cxx11_basic_string {
public:
Trans_NS___cxx11_basic_string(char *);
};
int handle_volume_rcp_update(int, int &, int &);
map dispatch =
static_map< int(int, int &, int &) >("", handle_volume_rcp_update);
$ g++ x.ii -O2 -flto -fPIC -shared
x.ii: In member function ‘int* _Rb_tree< ,
, , ,
>::_Alloc_node::operator()(_Arg)’:
x.ii:8:5: warning: no return statement in function returning non-void
[-Wreturn-type]
8 | }
| ^
x.ii: In member function ‘int* _Rb_tree< ,
, , ,
>::_M_copy(int, int, _NodeGen&)’:
x.ii:34:1: warning: no return statement in function returning non-void
[-Wreturn-type]
34 | }
| ^
x.ii: At global scope:
x.ii:52:42: warning: ISO C++ forbids converting a string constant to ‘char*’
[-Wwrite-strings]
52 | static_map< int(int, int &, int &) >("", handle_volume_rcp_update);
| ^~
during IPA pass: cp
lto1: internal compiler error: in ipa_find_agg_cst_for_param, at
ipa-prop.c:3467
0x6584b9 ipa_find_agg_cst_for_param(ipa_agg_value_set*, tree_node*, long, bool,
bool*)
../../gcc/ipa-prop.c:3467
0x6584b9 ipa_find_agg_cst_for_param(ipa_agg_value_set*, tree_node*, long, bool,
bool*)
../../gcc/ipa-prop.c:3440
0xadc8bf evaluate_conditions_for_known_args
../../gcc/ipa-fnsummary.c:371
0xae6369 estimate_ipcp_clone_size_and_time(cgraph_node*, vec, vec,
vec, int*, sreal*, sreal*, int*)
../../gcc/ipa-fnsummary.c:3658
0x165e31f perform_estimation_of_a_value
../../gcc/ipa-cp.c:3397
0x16662a3 estimate_local_effects
../../gcc/ipa-cp.c:3623
0x166ffbf propagate_constants_topo
../../gcc/ipa-cp.c:3819
0x166ffbf ipcp_propagate_stage
../../gcc/ipa-cp.c:3915
0x166ffbf ipcp_driver
../../gcc/ipa-cp.c:5911
0x166ffbf execute
../../gcc/ipa-cp.c:6004
[Bug ipa/94245] [10 Regression] ICE in ipa_find_agg_cst_for_param, at ipa-prop.c:3467 since r10-7237-g4e3d3e40726e1b68
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94245 Martin Liška changed: What|Removed |Added Target Milestone|--- |10.0 Ever confirmed|0 |1 Known to work||9.3.0 Known to fail||10.0 Status|UNCONFIRMED |NEW Last reconfirmed||2020-03-21 Priority|P3 |P1
[Bug c/94239] [10 regression] cc1 SEGV in get_location_from_adhoc_loc with gcc.dg/pr20245-1.c etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94239 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #3 from Jakub Jelinek --- Yes, see https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542459.html Sorry for that.
[Bug target/94052] Paradoxical subregs out of expand causes ICE with multi register modes at -O2 or higher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94052 --- Comment #6 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:497498c878d48754318e486428e2aa30854020b9 commit r10-7312-g497498c878d48754318e486428e2aa30854020b9 Author: Richard Sandiford Date: Mon Mar 9 19:42:57 2020 + lra: Tighten check for reloading paradoxical subregs [PR94052] simplify_operand_subreg tries to detect whether the allocation for a pseudo in a paradoxical subreg is also valid for the outer mode. The condition it used to check for an invalid combination was: else if (REG_P (reg) && REGNO (reg) >= FIRST_PSEUDO_REGISTER && (hard_regno = lra_get_regno_hard_regno (REGNO (reg))) >= 0 && (hard_regno_nregs (hard_regno, innermode) < hard_regno_nregs (hard_regno, mode)) && (regclass = lra_get_allocno_class (REGNO (reg))) && (type != OP_IN || !in_hard_reg_set_p (reg_class_contents[regclass], mode, hard_regno) || overlaps_hard_reg_set_p (lra_no_alloc_regs, mode, hard_regno))) I think there are two problems with this: (1) It never actually checks whether the hard register is valid for the outer mode (in the hard_regno_mode_ok sense). If it isn't, any attempt to reload in the outer mode is likely to cycle, because the implied regno/mode combination will be just as invalid next time curr_insn_transform sees the subreg. (2) The check is valid for little-endian only. For big-endian we need to move hard_regno backwards. Using simplify_subreg_regno should avoid both problems. As the existing comment says, IRA should always take subreg references into account when allocating hard registers, so this fix-up should only really be needed for pseudos allocated by LRA itself. gcc/ 2020-03-21 Richard Sandiford PR rtl-optimization/94052 * lra-constraints.c (simplify_operand_subreg): Reload the inner register of a paradoxical subreg if simplify_subreg_regno fails to give a valid hard register for the outer mode. gcc/testsuite/ 2020-03-21 Tamar Christina PR target/94052 * gcc.target/aarch64/pr94052.C: New test.
[Bug fortran/94246] New: valgrind error for ./gfortran.dg/bessel_5.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94246 Bug ID: 94246 Summary: valgrind error for ./gfortran.dg/bessel_5.f90 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- I just tried a valgrind version of recent trunk gfortran over testsuite file gfortran.dg/bessel_5.f90. I got $ /home/dcb/gcc/results.20200320.valgrind/bin/gfortran -c ./gfortran.dg/bessel_5.f90 ./gfortran.dg/bessel_5.f90:64:50: 64 | if (any (BESSEL_YN(0, 10, 0.0) /= [ (BESSEL_YN(i, 0.0), i = 0, 10) ])) & | 1 Error: Result of BESSEL_YN overflows its kind at (1) ./gfortran.dg/bessel_5.f90:64:26: 64 | if (any (BESSEL_YN(0, 10, 0.0) /= [ (BESSEL_YN(i, 0.0), i = 0, 10) ])) & | 1 Error: Result of BESSEL_YN is -INF at (1) ==1776287== Invalid read of size 8 ==1776287==at 0x603913: reduce_binary_ac(arith (*)(gfc_expr*, gfc_expr*, gfc_expr**), gfc_expr*, gfc_expr*, gfc_expr**) (arith.c:1325) ==1776287==by 0x60397A: reduce_binary_ac(arith (*)(gfc_expr*, gfc_expr*, gfc_expr**), gfc_expr*, gfc_expr*, gfc_expr**) (arith.c:1312) ==1776287==by 0x603B34: reduce_binary(arith (*)(gfc_expr*, gfc_expr*, gfc_expr**), gfc_expr*, gfc_expr*, gfc_expr**) (arith.c:1438) ==1776287==by 0x603F72: eval_intrinsic(gfc_intrinsic_op, eval_f, gfc_expr*, gfc_expr*) (arith.c:1613) Please note I didn't use the recommended testsuite flags of -Wall -fno-range-check. Also, since this valgrind error occurs after gfortran finds an error in the user's source code, it doesn't look very important to me.
[Bug fortran/94246] [9/10 Regression] valgrind error for ./gfortran.dg/bessel_5.f90 since r9-1566-g87c789f1c0b2df41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94246 Martin Liška changed: What|Removed |Added Known to fail||10.0, 9.3.0 Known to work||8.4.0 Last reconfirmed||2020-03-21 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Target Milestone|--- |9.4 Blocks||63426 Summary|valgrind error for |[9/10 Regression] valgrind |./gfortran.dg/bessel_5.f90 |error for ||./gfortran.dg/bessel_5.f90 ||since ||r9-1566-g87c789f1c0b2df41 CC||marxin at gcc dot gnu.org, ||pault at gcc dot gnu.org --- Comment #1 from Martin Liška --- Confirmed, started with r9-1566-g87c789f1c0b2df41. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 [Bug 63426] [meta-bug] Issues found with -fsanitize=undefined
[Bug c/94247] New: Wrong char-subscripts warning for limited-range index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94247
Bug ID: 94247
Summary: Wrong char-subscripts warning for limited-range index
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
#define MAXID 20
static const char shft[MAXID] = {1,2,3,4,5,6,7,1,2,3,4,5,6,7,1,2,3,4,5,6};
int hashstr(const char *s) {
char c;
char k = 0;
unsigned int sum = 0;
while( (c = *s++) != '\0' && k < MAXID-1 ) {
sum += c + (c<> 1);
}
The above program is a slight variation of the OpenJDK code in
src/hotspot/share/libadt/dict.cpp. It uses a char for indexing an array, which
triggers this warning:
dict.cpp: In function ‘int hashstr(const char*)’:
dict.cpp:10:28: warning: array subscript has type ‘char’ [-Wchar-subscripts]
sum += c + (c<
[Bug c/94247] Wrong char-subscripts warning for limited-range index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94247 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic --- Comment #1 from Andrew Pinski --- The warning is not context sensitive. What I mean is it does not take into account the range of k. Also you can avoid the warning by using either unsigned char or signed char. char is a special type. Unlike other plain types, it can default either to signed or unsigned and for GCC it depends on the ABI. >and the compiler already knows this Not when the warning is generated from the front-end. It does not know the range of the char variable there.
[Bug c/94247] Wrong char-subscripts warning for limited-range index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94247 --- Comment #2 from Roland Illig --- (In reply to Andrew Pinski from comment #1) > >and the compiler already knows this > Not when the warning is generated from the front-end. It does not know the > range of the char variable there. Ah, that fine distinction. From my point of view there only was "the compiler". If the range of the variable is not known at that time, it would probably be too much work to implement this extra rule. So you suggest that the code should be fixed instead? Then I'll tell the OpenJDK people.
[Bug target/94248] New: [amdgcn] Doesn't build with RTL checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94248 Bug ID: 94248 Summary: [amdgcn] Doesn't build with RTL checking Product: gcc Version: unknown Status: UNCONFIRMED Keywords: ice-checking Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org CC: ams at gcc dot gnu.org, jules at gcc dot gnu.org Target Milestone: --- Target: amdgcn Building (for offloading) a '--target=amdgcn-amdhsa' GCC with '--enable-checking=yes,extra,rtl' fails: during RTL pass: split2 [...]/source-gcc/libgcc/libgcc2.c: In function '__absvdi2': [...]/source-gcc/libgcc/libgcc2.c:271:1: internal compiler error: RTL check: expected code 'reg', have 'const_int' in rhs_regno, at rtl.h:1923 271 | } | ^ 0x565847 ??? [...]/source-gcc/gcc/rtl.c:881 0x59a8a4 ??? [...]/source-gcc/gcc/rtl.h:1923 0x12e3a5c ??? [...]/source-gcc/gcc/config/gcn/gcn.md:631 [...] Makefile:501: recipe for target '_absvdi2.o' failed make[4]: *** [_absvdi2.o] Error 1 make[4]: Leaving directory '[...]/build-gcc-offload-amdgcn-amdhsa/amdgcn-amdhsa/gfx900/libgcc' I haven't made a real attempt to understand the gibberish ;-) in 'gcc/config/gcn/gcn.md', but supposedly that means we're using 'REGNO' on something that's not a 'reg' (but a 'const_int', here) -- wrongly entering/using (this part of?) the 'define_insn_and_split "*mov_insn"'?
[Bug lto/94249] [10 regression] Many -flto -fuse-linker-plugin tests FAIL: could not add symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94249 Rainer Orth changed: What|Removed |Added Target Milestone|--- |10.0
[Bug lto/94249] New: [10 regression] Many -flto -fuse-linker-plugin tests FAIL: could not add symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94249 Bug ID: 94249 Summary: [10 regression] Many -flto -fuse-linker-plugin tests FAIL: could not add symbols Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- Host: sparc-sun-solaris2.11 Target: sparc-sun-solaris2.11 Build: sparc-sun-solaris2.11 Between 20200313 (fd8679974b2ded884ffd7d912efef7fe13e4ff4f) and 20200320 (719c864225e28c33a0737a331a772781ce8e6591), many LTO tests began to FAIL on Solaris/SPARC with gld 2.34, e.g. +FAIL: c-c++-common/asan/alloca_instruments_all_paddings.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) +UNRESOLVED: c-c++-common/asan/alloca_instruments_all_paddings.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects compilation failed to produce executable Excess errors: /vol/gcc/bin/gld-2.34: error: could not add symbols For some reason, this still works ok on Solaris/x86, though.
[Bug lto/91028] [10 Regression] g++.dg/lto/alias-2 FAILs with -fno-use-linker-plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91028 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #3 from Jan Hubicka --- > I believe this was fixed a while ago by adding the loop. It no longer fails > with -fno-use-linker-plugin. Is it OK on Solaris? It no longer FAILs indeed after 20190715 on both Solaris/SPARC and x86.
[Bug lto/91028] [10 Regression] g++.dg/lto/alias-2 FAILs with -fno-use-linker-plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91028 Rainer Orth changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED
[Bug c/94239] [10 regression] cc1 SEGV in get_location_from_adhoc_loc with gcc.dg/pr20245-1.c etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94239 Bill Seurer changed: What|Removed |Added CC||seurer at linux dot vnet.ibm.com --- Comment #4 from Bill Seurer --- I think this also hit powerpc though only on power 8. Regressions on trunk (power8) on update from 37482edc3f7f19110da7178d0d4c3003ea5272f3, r10-7280 to 9def91e9f2a7051c9c146f16c1a10d1b25d33b47, r10-7281: New failures (these tests were not seen to fail previously): FAIL: gcc.dg/pr20245-1.c (internal compiler error) FAIL: gcc.dg/pr20245-1.c (test for excess errors) FAIL: gcc.dg/pr28419.c (internal compiler error) FAIL: gcc.dg/pr28419.c (test for excess errors) This only happens on a bootstrap.
[Bug c++/94066] [8/9/10 Regression] ICE (starting/ending union member lifetime) in cxx_eval_bare_aggregate, at cp/constexpr.c:3790 since r6-7592
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94066 --- Comment #8 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:b599bf9d6d1e180d350b71e51e08a66a1bb1546a commit r10-7313-gb599bf9d6d1e180d350b71e51e08a66a1bb1546a Author: Patrick Palka Date: Thu Mar 19 09:58:28 2020 -0400 c++: Reject changing active member of union during initialization [PR94066] This patch adds a check to detect changing the active union member during initialization of another member of the union in cxx_eval_store_expression. It uses the CONSTRUCTOR_NO_CLEARING flag as a proxy for whether the non-empty CONSTRUCTOR of UNION_TYPE we're assigning to is in the process of being initialized. This patch additionally fixes an issue in reduced_constant_expression_p where we were returning false for an uninitialized union with no active member. This lets us correctly reject the uninitialized use in the testcase testconstexpr-union4.C that we weren't before. gcc/cp/ChangeLog: PR c++/94066 * constexpr.c (reduced_constant_expression_p) [CONSTRUCTOR]: Properly handle unions without an initializer. (cxx_eval_component_reference): Emit a different diagnostic when the constructor element corresponding to a union member is NULL. (cxx_eval_bare_aggregate): When constructing a union, always set the active union member before evaluating the initializer. Relax assertion that verifies the index of the constructor element we're initializing hasn't been changed. (cxx_eval_store_expression): Diagnose changing the active union member while the union is in the process of being initialized. After setting an active union member, clear CONSTRUCTOR_NO_CLEARING on the underlying CONSTRUCTOR. (cxx_eval_constant_expression) [PLACEHOLDER_EXPR]: Don't re-reduce a CONSTRUCTOR returned by lookup_placeholder. gcc/testsuite/ChangeLog: PR c++/94066 * g++.dg/cpp1y/constexpr-union2.C: New test. * g++.dg/cpp1y/constexpr-union3.C: New test. * g++.dg/cpp1y/constexpr-union4.C: New test. * g++.dg/cpp1y/constexpr-union5.C: New test. * g++.dg/cpp1y/pr94066.C: New test. * g++.dg/cpp1y/pr94066-2.C: New test. * g++.dg/cpp1y/pr94066-3.C: New test. * g++.dg/cpp2a/constexpr-union1.C: New test.
[Bug ipa/62051] [8/9/10 Regression] Undefined reference to vtable with -O2 and -fdevirtualize-speculatively
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62051 Jan Hubicka changed: What|Removed |Added Target Milestone|8.5 |11.0 --- Comment #23 from Jan Hubicka --- This is bit of a grey area of what we can/can not refer in presence of visibilities and I hope codebases are now adopted for GCC behaviour. I think we could delay this post GCC10, so re-taretting.
[Bug fortran/78746] charlen_03, charlen_10 ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78746 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #20 from David Binderman --- (In reply to Arseny Solokha from comment #17) > Just in case, w/ gcc/testsuite/gfortran.dg/class_61.f90 (as of r268503): > > ==20572== Invalid read of size 8 > ==20572==at 0x8150A4: resolve_component(gfc_component*, gfc_symbol*) > (resolve.c:13809) > ==20572==by 0x815BB2: resolve_fl_derived0(gfc_symbol*) [clone .part.54] > (resolve.c:14258) > ==20572==by 0x8161FF: resolve_fl_derived0 (resolve.c:14357) > ==20572==by 0x8161FF: resolve_fl_derived(gfc_symbol*) (resolve.c:14387) I can confirm that I am still seeing this one, over a year later. Since the code is in error, probably not a high priority.
[Bug libstdc++/93983] std::filesystem::path is not concept-friendly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93983
Paco Arjonilla changed:
What|Removed |Added
CC||pacoarjonilla at yahoo dot es
--- Comment #4 from Paco Arjonilla ---
I got this error too. This is the code:
#include
#include
struct A {
A() = default;
A(A const&) = default;
A & operator = (A const&) = default;
A(std::filesystem::path); // This line triggers the error.
};
static_assert(std::semiregular);
There is no reason why an extra constructor would affect the semiregularity of
a type.
$> g++ -std=c++20
In file included from
/opt/compiler-explorer/gcc-trunk-20200321/include/c++/10.0.1/compare:39,
from
/opt/compiler-explorer/gcc-trunk-20200321/include/c++/10.0.1/bits/stl_pair.h:65,
from
/opt/compiler-explorer/gcc-trunk-20200321/include/c++/10.0.1/bits/stl_algobase.h:64,
from
/opt/compiler-explorer/gcc-trunk-20200321/include/c++/10.0.1/bits/char_traits.h:39,
from
/opt/compiler-explorer/gcc-trunk-20200321/include/c++/10.0.1/string:40,
from
/opt/compiler-explorer/gcc-trunk-20200321/include/c++/10.0.1/stdexcept:39,
from
/opt/compiler-explorer/gcc-trunk-20200321/include/c++/10.0.1/system_error:41,
from
/opt/compiler-explorer/gcc-trunk-20200321/include/c++/10.0.1/bits/fs_fwd.h:35,
from
/opt/compiler-explorer/gcc-trunk-20200321/include/c++/10.0.1/filesystem:44,
from :1:
/opt/compiler-explorer/gcc-trunk-20200321/include/c++/10.0.1/bits/stl_iterator_base_types.h:
In instantiation of 'struct std::iterator_traits':
/opt/compiler-explorer/gcc-trunk-20200321/include/c++/10.0.1/bits/fs_path.h:84:11:
required by substitution of 'template using
__is_path_iter_src = std::__and_::type, char>,
std::is_same::type, char8_t>, std::is_same::type, wchar_t>,
std::is_same::type, char16_t>, std::is_same::type, char32_t> >,
std::is_base_of > [with _Iter = A; _Iter_traits =
std::iterator_traits]'
/opt/compiler-explorer/gcc-trunk-20200321/include/c++/10.0.1/bits/fs_path.h:91: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 = A]'
/opt/compiler-explorer/gcc-trunk-20200321/include/c++/10.0.1/bits/fs_path.h:115:29:
required from 'struct
std::filesystem::__cxx11::__detail::__constructible_from'
/opt/compiler-explorer/gcc-trunk-20200321/include/c++/10.0.1/type_traits:138:12:
required from 'struct std::__and_ >,
std::filesystem::__cxx11::__detail::__constructible_from >'
/opt/compiler-explorer/gcc-trunk-20200321/include/c++/10.0.1/type_traits:143:12:
required from 'struct std::__and_ >, std::__not_ >,
std::filesystem::__cxx11::__detail::__constructible_from >'
/opt/compiler-explorer/gcc-trunk-20200321/include/c++/10.0.1/bits/fs_path.h:119: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 = A; _Tp2 = void]'
/opt/compiler-explorer/gcc-trunk-20200321/include/c++/10.0.1/bits/fs_path.h:219:7:
required by substitution of 'template
std::filesystem::__cxx11::path::path(const _Source&,
std::filesystem::__cxx11::path::format) [with _Source = A; _Require =
]'
/opt/compiler-explorer/gcc-trunk-20200321/include/c++/10.0.1/type_traits:901:30:
required from 'struct std::__is_constructible_impl'
/opt/compiler-explorer/gcc-trunk-20200321/include/c++/10.0.1/type_traits:906:12:
required from 'struct std::is_constructible'
/opt/compiler-explorer/gcc-trunk-20200321/include/c++/10.0.1/type_traits:3091:25:
required from 'constexpr const bool std::is_constructible_v'
/opt/compiler-explorer/gcc-trunk-20200321/include/c++/10.0.1/concepts:139:30:
required from here
/opt/compiler-explorer/gcc-trunk-20200321/include/c++/10.0.1/concepts:139:30:
error: the value of 'std::is_constructible_v' is not usable in a constant
expression
139 | = destructible<_Tp> && is_constructible_v<_Tp, _Args...>;
| ^
In file included from
/opt/compiler-explorer/gcc-trunk-20200321/include/c++/10.0.1/bits/move.h:57,
from
/opt/compiler-explorer/gcc-trunk-20200321/include/c++/10.0.1/bits/nested_exception.h:40,
from
/opt/compiler-explorer/gcc-trunk-20200321/include/c++/10.0.1/exception:148,
from
/opt/compiler-explorer
[Bug c++/94250] New: valgrind error for ./g++.dg/ipa/remref-1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94250 Bug ID: 94250 Summary: valgrind error for ./g++.dg/ipa/remref-1.C Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- For testsuite file ./g++.dg/ipa/remref-1.C, compiled by recent trunk in a valgrind version and compiler flag -O2, does this: ==1825381== Invalid read of size 2 ==1825381==at 0x853A7C: symtab_node::clone_reference(ipa_ref*, gimple*) (symtab.c:712) ==1825381==by 0xA4F665: ipa_edge_args_sum_t::duplicate(cgraph_edge*, cgraph_edge*, ipa_edge_args*, ipa_edge_args*) (ipa-prop.c:4226) ==1825381==by 0xA58061: call_summary::symtab_duplication(cgraph_edge*, cgraph_edge*, void*) (symbol-summary.h:737) ==1825381==by 0x85CBD3: call_edge_duplication_hooks (cgraph.c:450)
[Bug target/94248] [amdgcn] Doesn't build with RTL checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94248
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2020-03-21
Status|UNCONFIRMED |NEW
--- Comment #1 from Jakub Jelinek ---
Either:
--- gcc/config/gcn/gcn.md.jj2020-03-03 07:57:42.363827602 +0100
+++ gcc/config/gcn/gcn.md 2020-03-21 15:35:22.395639196 +0100
@@ -625,7 +625,7 @@ (define_insn_and_split "*mov_insn"
rtx outhi = gen_highpart_mode (SImode, mode, operands[0]);
/* Ensure that overlapping registers aren't corrupted. */
-if (REGNO (outlo) == REGNO (inhi))
+if (REG_P (inhi) && REGNO (outlo) == REGNO (inhi))
{
operands[0] = outhi;
operands[1] = inhi;
or:
--- gcc/config/gcn/gcn.md.jj2020-03-03 07:57:42.363827602 +0100
+++ gcc/config/gcn/gcn.md 2020-03-21 15:37:45.337552515 +0100
@@ -625,7 +625,7 @@ (define_insn_and_split "*mov_insn"
rtx outhi = gen_highpart_mode (SImode, mode, operands[0]);
/* Ensure that overlapping registers aren't corrupted. */
-if (REGNO (outlo) == REGNO (inhi))
+if (reg_overlap_mentioned_p (outlo, inhi))
{
operands[0] = outhi;
operands[1] = inhi;
ought to fix this, but I don't yet have setup where I can sufficiently test it.
I think the latter is better and is in line what other backends are using.
[Bug c++/94250] valgrind error for ./g++.dg/ipa/remref-1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94250 Nicholas Krause changed: What|Removed |Added CC||mliska at suse dot cz, ||xerofoify at gmail dot com --- Comment #1 from Nicholas Krause --- After looking through the git history that last time this functions in your trace were changed is by commit id, db30281f0b2ff6dfc0c4146291baf020a27e4065. Martin Liska was the original committer so he should comment on this. https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=db30281f0b2ff6dfc0c4146291baf020a27e4065 However this was changed: summary->duplicate (edge1, edge2, edge1_summary, summary->get_create (edge2));
[Bug c++/94250] valgrind error for ./g++.dg/ipa/remref-1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94250 --- Comment #2 from Nicholas Krause --- (In reply to Nicholas Krause from comment #1) > After looking through the git history that last time this functions in your > trace were changed is by commit id, > db30281f0b2ff6dfc0c4146291baf020a27e4065. Martin Liska was the original > committer so he should comment on this. > https://gcc.gnu.org/git/?p=gcc.git;a=commit; > h=db30281f0b2ff6dfc0c4146291baf020a27e4065 > > However this was changed: > summary->duplicate (edge1, edge2, edge1_summary, > summary->get_create (edge2)); and it appears to be assuming based on the above lines: if (summary->m_initialize_when_cloning) edge1_summary = summary->get_create (edge1); else edge1_summary = summary->get (edge1); That this can never occur for edge2. Martin is edge2 assumed to be good by this comment?
[Bug libgomp/94251] New: [OpenMP] 'target link' fails at run time / libgomp.c/target-link-1.c fails on GCN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94251
Bug ID: 94251
Summary: [OpenMP] 'target link' fails at run time /
libgomp.c/target-link-1.c fails on GCN
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: openmp, wrong-code
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Follow-up to PR 94233.
The test case libgomp.c/target-link-1.c fails with AMDGCN with:
"libgomp: Cannot map target variables (size mismatch)"
That's in libgomp/target.c's gomp_load_image_to_device:
/* Most significant bit of the size in host and target tables marks
"omp declare target link" variables. */
const uintptr_t link_bit = 1ULL << (sizeof (uintptr_t) * __CHAR_BIT__ - 1);
const uintptr_t size_mask = ~link_bit;
struct addr_pair *target_var = &target_table[num_funcs + i];
uintptr_t target_size = target_var->end - target_var->start;
if ((uintptr_t) host_var_table[i * 2 + 1] != target_size)
gomp_fatal ("Cannot map target variables (size mismatch)");
---
The code clearly assumes that the link_bit is also present in target_size –
which is not only visible in the quoted condition but also for:
k->refcount = target_size & link_bit ? REFCOUNT_LINK : REFCOUNT_INFINITY;
While for the host data, that's not assumed as one masks the data:
k->host_end
= k->host_start + (size_mask & (uintptr_t) host_var_table[i * 2 + 1]);
I think it should be:
* no link mask in target_var->end / target_size
* Use 'host_var_table[i*2+1] & link_bit' in the refcount expression
* Use '& link_bit' for the size comparison.
The passed arguments are fine:
(gdb) p host_var_table[1]
$15 = (void *) 0x8008
(gdb) p host_var_table[3]
$16 = (void *) 0x80d8
(gdb) p host_var_table[5]
$17 = (void *) 0x4
(gdb) p host_var_table[7]
$18 = (void *) 0x8004
Namely: 'd' = 2*int = 8, 'c' = 27*double = 216 = 0xD8, 'a' and 'b' being
int=4.,
'b' is 'to', the rest is 'link'.
However, at least with AMDGCN, target_size == 8 for all variables. At a glance,
the code in GOMP_OFFLOAD_load_image looks fine, but:
image_desc->global_variables[i]->name is "d_linkptr" and not "d".
That variable is generated by lto/lto.c's offload_handle_link_vars as
tree type = build_pointer_type (TREE_TYPE (var->decl));
where var->decl is "d" in this case.
Thus, it is not surprising that the size is always 8.
* * *
Looking at the other plugins, they seems to work mostly likewise [get bit size
correctly]:
* hsa: global variables not processed in load_image, i.e.
target_table not updated for the global variables!
* nvptx: cuModuleGetGlobal called, look fine.
[Bug target/90835] Incompatibilities with macOS 10.15 headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835 Iain Sandoe changed: What|Removed |Added Status|NEW |WAITING --- Comment #23 from Iain Sandoe --- unpatched GCC master, gcc-9.x, gcc-8.x and gcc-7.5 work for me with any SDK >= Xcode commandline tools 11.3b. If there's no additional information I propose we close this PR after another week.
[Bug libgomp/94251] [OpenMP] 'target link' fails at run time / libgomp.c/target-link-1.c fails on GCN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94251 --- Comment #1 from Tobias Burnus --- Created attachment 48077 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48077&action=edit (Partial patch): Patch for gomp_load_image_to_device to handle link_flag correctly [Cross ref: nvptx disables the libgomp.c/target-link-1.c because of PR81689] Attached fixes the size check and the link vs not link for refcount. However, the big question is what be the target variable? (a) the variable itself such as 'c' with 'int c[27]' (b) a pointer to a variable such as 'c_linkptr' If (b), then the size check does not work and the the tgt side is a pointer. If (a), then the passed name does not fit. Jakub: How is this supposed to be implemented?
[Bug c++/94250] valgrind error for ./g++.dg/ipa/remref-1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94250 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-03-21 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #3 from Martin Liška --- A nice catch David! I've got a patch for it.
[Bug ipa/94250] [10 Regression] ]valgrind error for ./g++.dg/ipa/remref-1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94250 Martin Liška changed: What|Removed |Added Target Milestone|--- |10.0 Component|c++ |ipa Summary|valgrind error for |[10 Regression] ]valgrind |./g++.dg/ipa/remref-1.C |error for ||./g++.dg/ipa/remref-1.C
[Bug ipa/94250] [10 Regression] valgrind error for ./g++.dg/ipa/remref-1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94250 --- Comment #4 from David Binderman --- (In reply to Martin Liška from comment #3) > A nice catch David! I've got a patch for it. Thanks. I should also perhaps mention that testsuite file ./g++.dg/ipa/remref-2.C has the same problem. It would be wise to ensure your patch fixes both.
[Bug lto/94249] [10 regression] Many -flto -fuse-linker-plugin tests FAIL: could not add symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94249 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-03-21 --- Comment #1 from Martin Liška --- It will be definitely caused by my g:c8429c2aba80f845939ffa6b2cfe8a0be1b50078. The error comes from lto-plugin.c: if (add_symbols_v2) status = add_symbols_v2 (file->handle, lto_file.symtab.nsyms, lto_file.symtab.syms); else status = add_symbols (file->handle, lto_file.symtab.nsyms, lto_file.symtab.syms); check (status == LDPS_OK, LDPL_FATAL, "could not add symbols"); In our case add_symbols_v2 should be NULL, so the old function add_symbols should be called. So is the reason usage of ld.gold? Is the default linker fine?
[Bug ipa/94250] [10 Regression] valgrind error for ./g++.dg/ipa/remref-1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94250 --- Comment #5 from Martin Liška --- (In reply to David Binderman from comment #4) > (In reply to Martin Liška from comment #3) > > A nice catch David! I've got a patch for it. > > Thanks. I should also perhaps mention that testsuite file > ./g++.dg/ipa/remref-2.C has the same problem. It would be > wise to ensure your patch fixes both. Yes, the patch covers both files. It's quite clear goes wrong there.
[Bug c++/94252] New: Can't use a lambda in a requires expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94252
Bug ID: 94252
Summary: Can't use a lambda in a requires expression
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: ---
This program:
auto f = []{ return 0; };
static_assert(requires { f(); });
Fails to compile on trunk (https://godbolt.org/z/DEuoVM), with the error:
:2:15: error: static assertion failed
2 | static_assert(requires { f(); });
| ^
[Bug lto/94249] [10 regression] Many -flto -fuse-linker-plugin tests FAIL: could not add symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94249 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Martin Liška --- > It will be definitely caused by my g:c8429c2aba80f845939ffa6b2cfe8a0be1b50078. [...] > So is the reason usage of ld.gold? Is the default linker fine? No, ld.gold doesn't work on Solaris, so this is plain gld/ld.bfd 2.34. The default linker is Solaris ld, which doesn't support the LTO plugin. It is fine indeed, though.
[Bug target/93694] Inconsistent grammar in darwin.opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93694 --- Comment #5 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:837cece888f36543b6d326101362acb67ac3df0a commit r10-7315-g837cece888f36543b6d326101362acb67ac3df0a Author: Iain Sandoe Date: Sun Mar 1 13:04:58 2020 + Darwin: Address translation comments (PR93694). This updates the options descriptions after feedback from a translator. gcc/ChangeLog: 2020-03-21 Iain Sandoe PR target/93694 * gcc/config/darwin.opt: Amend options descriptions.
[Bug lto/94237] [10 regression] Many (100s) of new LTO fails on Darwin targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94237 --- Comment #3 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:dfb25dfe3d34703f6e493664831dfaf53672b07b commit r10-7316-gdfb25dfe3d34703f6e493664831dfaf53672b07b Author: Iain Sandoe Date: Sat Mar 21 13:20:47 2020 + Darwin: Handle NULL DECL_SIZE_TYPE in machopic_select_section (PR94237). A recent change in the LTO streaming arrangement means that it is now possible for machopic_select_section () to be called with a NULL value for DECL_SIZE_TYPE - corresponding to an incomplete or not-yet- laid out type. When section anchors are present, and we are generating assembler, we normally need to know the object size when choosing the section, since zero-sized objects must be placed in sections that forbid section anchors. In the current circumstance, the objective of the earlier streaming of this data is to allow nm to determine BSS c.f. Data symbols (when used with the LTO plugin). Since Darwin does not yet make use of the plugin this fix is a bit of future-proofing. We now emit the 'generic' section for the decl (absent knowing its size) - which will still be correct in determining the BSS c.f. Data case. gcc/ChangeLog: 2020-03-21 Iain Sandoe PR lto/94237 * config/darwin.c (darwin_mergeable_constant_section): Collect section anchor checks into the caller. (machopic_select_section): Collect section anchor checks into the determination of 'effective zero-size' objects. When the size is unknown, assume it is non-zero, and thus return the 'generic' section for the DECL.
[Bug target/94253] New: FAIL: gfortran.dg/bind_c_coms.f90 -O0 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94253 Bug ID: 94253 Summary: FAIL: gfortran.dg/bind_c_coms.f90 -O0 (test for excess errors) Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 spawn /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran -B/test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../ -B/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/ /test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/bind_c_coms.f90 -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -O0 -w /test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/bind_c_coms_driver.c -B/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libatomic/.libs -B/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libquadmath/.libs -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libquadmath/.libs -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libquadmath/.libs -lm -o ./bind_c_coms.exe ld: (Warning) Symbol "com" in "/var/tmp//cc14WyWs.o" does not satisfy the required 16-byte alignment in "/var/tmp//cc4g1Pgg.o". 1 warnings. output is: ld: (Warning) Symbol "com" in "/var/tmp//cc14WyWs.o" does not satisfy the required 16-byte alignment in "/var/tmp//cc4g1Pgg.o". 1 warnings. FAIL: gfortran.dg/bind_c_coms.f90 -O0 (test for excess errors) Excess errors: ld: (Warning) Symbol "com" in "/var/tmp//cc14WyWs.o" does not satisfy the required 16-byte alignment in "/var/tmp//cc4g1Pgg.o". 1 warnings. Fails at all optimizations. We now have in bind_c_coms_driver.s: .section.bss .align 8 .type com, @object .size com, 16 .align 8 com: .block 16 We used to have: .section.bss com .comm 16 The later provides 16-byte alignment. Looks to me like there are problems with both pa_asm_output_aligned_bss() and pa_asm_output_aligned_common(). It looks like allocations in the BSS need to be aligned to a power of 2 alignment greater than the size of the block.
[Bug libstdc++/94244] std::sort corrupts memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94244 --- Comment #2 from Jonathan Wakely --- In other words, you have failed to meet the requirement that the comparison is a strict weak ordering. https://en.wikipedia.org/wiki/Weak_ordering#Strict_weak_orderings
[Bug libstdc++/93983] std::filesystem::path is not concept-friendly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93983 --- Comment #5 from Jonathan Wakely --- (In reply to Paco Arjonilla from comment #4) > There is no reason why an extra constructor would affect the semiregularity > of a type. That's not true. A private or deleted constructor that is a better match for some arguments can affect it.
[Bug target/94254] New: [10 regression] r10-7312 causes compiler hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254 Bug ID: 94254 Summary: [10 regression] r10-7312 causes compiler hangs Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: seurer at linux dot vnet.ibm.com Target Milestone: --- g:497498c878d48754318e486428e2aa30854020b9, r10-7312 FAIL: gcc.target/powerpc/pr39902-2.c (test for excess errors) FAIL: gcc.target/powerpc/pr79916.c (test for excess errors) FAIL: gcc.target/powerpc/sd-pwr6.c (test for excess errors) All 3 of those compilations hang starting with this revision. I saw this on a power 8 and power 9.
[Bug fortran/94246] [9/10 Regression] valgrind error for ./gfortran.dg/bessel_5.f90 since r9-1566-g87c789f1c0b2df41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94246 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- (In reply to David Binderman from comment #0) > I just tried a valgrind version of recent trunk gfortran over testsuite file > gfortran.dg/bessel_5.f90. > > I got > > $ /home/dcb/gcc/results.20200320.valgrind/bin/gfortran -c > ./gfortran.dg/bessel_5.f90 > ./gfortran.dg/bessel_5.f90:64:50: > >64 | if (any (BESSEL_YN(0, 10, 0.0) /= [ (BESSEL_YN(i, 0.0), i = 0, 10) > ])) & > | 1 > Error: Result of BESSEL_YN overflows its kind at (1) > ./gfortran.dg/bessel_5.f90:64:26: > >64 | if (any (BESSEL_YN(0, 10, 0.0) /= [ (BESSEL_YN(i, 0.0), i = 0, 10) > ])) & > | 1 > Error: Result of BESSEL_YN is -INF at (1) > ==1776287== Invalid read of size 8 > ==1776287==at 0x603913: reduce_binary_ac(arith (*)(gfc_expr*, gfc_expr*, > gfc_expr**), gfc_expr*, gfc_expr*, gfc_expr**) (arith.c:1325) > ==1776287==by 0x60397A: reduce_binary_ac(arith (*)(gfc_expr*, gfc_expr*, > gfc_expr**), gfc_expr*, gfc_expr*, gfc_expr**) (arith.c:1312) > ==1776287==by 0x603B34: reduce_binary(arith (*)(gfc_expr*, gfc_expr*, > gfc_expr**), gfc_expr*, gfc_expr*, gfc_expr**) (arith.c:1438) > ==1776287==by 0x603F72: eval_intrinsic(gfc_intrinsic_op, eval_f, > gfc_expr*, gfc_expr*) (arith.c:1613) > > Please note I didn't use the recommended testsuite flags of > -Wall -fno-range-check. > So, what happens if you do use the required -fno-range-check option?
[Bug lto/94249] [10 regression] Many -flto -fuse-linker-plugin tests FAIL: could not add symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94249 John David Anglin changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #3 from John David Anglin --- Same occurs on hppa-linux.
[Bug libstdc++/94242] filesystem::path::generic_string() only works with std::allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94242 --- Comment #1 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:9fc985118d9f5014afc1caf32a411ee5803fba61 commit r10-7317-g9fc985118d9f5014afc1caf32a411ee5803fba61 Author: Jonathan Wakely Date: Sat Mar 21 21:51:07 2020 + libstdc++: Fix path::generic_string allocator handling (PR 94242) It's not possible to construct a path::string_type from an allocator of a different type. Create the correct specialization of basic_string, and adjust path::_S_str_convert to use a basic_string_view so that it is independent of the allocator type. PR libstdc++/94242 * include/bits/fs_path.h (path::_S_str_convert): Replace first parameter with basic_string_view so that strings with different allocators can be accepted. (path::generic_string()): Use basic_string object that uses the right allocator type. * testsuite/27_io/filesystem/path/generic/94242.cc: New test. * testsuite/27_io/filesystem/path/generic/generic_string.cc: Improve test coverage.
[Bug libstdc++/94242] filesystem::path::generic_string() only works with std::allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94242 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |8.5
[Bug fortran/94246] [9/10 Regression] valgrind error for ./gfortran.dg/bessel_5.f90 since r9-1566-g87c789f1c0b2df41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94246 --- Comment #3 from David Binderman --- (In reply to kargl from comment #2) > So, what happens if you do use the required -fno-range-check > option? The code is compiled happily: $ /home/dcb/gcc/results.20200320.valgrind/bin/gfortran -c -Wall -fno-range-check gfortran.dg/bessel_5.f90 $
[Bug middle-end/69008] gcc emits unneeded memory access when passing trivial structs by value (ARM)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69008
David Forgeas changed:
What|Removed |Added
CC||david.forgeas at gmail dot com
--- Comment #7 from David Forgeas ---
The use case that made me see this is std::string_view, or equivalently:
namespace my {
struct string_view {
const char *data;
unsigned long length;
const char & back() const {
return data[length - 1];
}
};
}
const char *back(my::string_view const sv)
{
return &sv.back();
}
pi@raspberrypi:~ $ g++ -O3 -pipe -S string_view.cpp -std=c++1z
pi@raspberrypi:~ $ cat string_view.s
.arch armv6
.eabi_attribute 28, 1
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 2
.eabi_attribute 30, 2
.eabi_attribute 34, 1
.eabi_attribute 18, 4
.file "string_view.cpp"
.text
.align 2
.global _Z4backN2my11string_viewE
.syntax unified
.arm
.fpu vfp
.type _Z4backN2my11string_viewE, %function
_Z4backN2my11string_viewE:
.fnstart
.LFB1:
@ args = 0, pretend = 0, frame = 8
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
sub sp, sp, #8
add r3, sp, #8
stmdb r3, {r0, r1}
ldm sp, {r0, r3}
sub r3, r3, #1
add r0, r0, r3
add sp, sp, #8
@ sp needed
bx lr
.cantunwind
.fnend
.size _Z4backN2my11string_viewE, .-_Z4backN2my11string_viewE
.ident "GCC: (Raspbian 6.3.0-18+rpi1+deb9u1) 6.3.0 20170516"
Also seen in a more recent version: https://godbolt.org/z/3LJ9SN
[Bug libstdc++/93245] std::experimental::filesystem::path::generic_string() doesn't normalize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93245 --- Comment #1 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a577c0c26931090e7c25e56ef5ffc807627961ec commit r10-7318-ga577c0c26931090e7c25e56ef5ffc807627961ec Author: Jonathan Wakely Date: Sat Mar 21 22:11:44 2020 + libstdc++: Fix experimental::path::generic_string (PR 93245) This function was unimplemented, simply returning the native format string instead. PR libstdc++/93245 * include/experimental/bits/fs_path.h (path::generic_string()): * testsuite/experimental/filesystem/path/generic/generic_string.cc: Improve test coverage.
[Bug fortran/94246] [9/10 Regression] valgrind error for ./gfortran.dg/bessel_5.f90 since r9-1566-g87c789f1c0b2df41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94246 --- Comment #4 from Steve Kargl --- On Sat, Mar 21, 2020 at 10:27:03PM +, dcb314 at hotmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94246 > > --- Comment #3 from David Binderman --- > (In reply to kargl from comment #2) > > So, what happens if you do use the required -fno-range-check > > option? > > The code is compiled happily: > > $ /home/dcb/gcc/results.20200320.valgrind/bin/gfortran -c -Wall > -fno-range-check gfortran.dg/bessel_5.f90 So, the code should be closed with WONTFIX or INVALID.
[Bug d/93038] Missing dependencies in depfile for imported files at compilation time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93038 --- Comment #3 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:4a01f7b1e73e98a86520d8a825ddd3777faa7c33 commit r10-7320-g4a01f7b1e73e98a86520d8a825ddd3777faa7c33 Author: Iain Buclaw Date: Sun Mar 22 00:10:17 2020 +0100 d: Fix missing dependencies in depfile for imported files (PR93038) A new field for tracking imported files was added to the front-end, this makes use of it by writing all such files in the make dependency list. gcc/d/ChangeLog: 2020-03-22 Iain Buclaw PR d/93038 * d-lang.cc (deps_write): Add content imported files to the make dependency list. gcc/testsuite/ChangeLog: 2020-03-22 Iain Buclaw PR d/93038 * gdc.dg/fileimports/pr93038.txt: New test. * gdc.dg/pr93038.d: New test.
[Bug d/93038] Missing dependencies in depfile for imported files at compilation time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93038 Iain Buclaw changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Iain Buclaw --- Exposed information from the front-end, fix committed.
[Bug c++/94255] New: template specialization in different namespace causes crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94255
Bug ID: 94255
Summary: template specialization in different namespace causes
crash
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vince.a.bridgers at gmail dot com
Target Milestone: ---
I encountered this issue using gcc/g++ 6.2.0, then 8.2.0, the tried trunk that
I built on rhel7. g++ crashes when trying to compile code with template
specialization in different namespace. I know this is incorrect code, but I
wouldn't expect g++ to crash. For reference, clang 8.0.0 compiles this and
gives an error.
Last git hash in log
commit 9def91e9f2a7051c9c146f16c1a10d1b25d33b47
Author: Jakub Jelinek
Date: Thu Mar 19 22:56:20 2020 +0100
---
Configure step for custom, trunk build ...
../gcc/configure --enable-languages=c,c++ --disable-multilib
--prefix=/gcc-install
$ g++ --version
g++ (GCC) 10.0.1 20200319 (experimental)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ g++ gcc-test.cpp
gcc-test.cpp:15:38: error: specialization of ‘template
struct clang::DynTypedNode::BaseConverter’ in different namespace
[-fpermissive]
15 | template <> struct DynTypedNode::BaseConverter : public
ValueConverter {};
| ^~~~
gcc-test.cpp:5:60: note: from definition of ‘template struct clang::DynTypedNode::BaseConverter’
5 | template struct
BaseConverter;
|
^
g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug d/91600] "Architecture not supported" reported for MinGW-W64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91600 --- Comment #1 from Iain Buclaw --- The following versions may be defined by the compiler on mingw targets Windows MinGW Win32 Win64 And on cygwin targets. Windows Cygwin Posix Druntime should compile fine if these exist.
[Bug d/91595] Version (Windows) is not defined in GCC D Compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91595 --- Comment #1 from Iain Buclaw --- *** Bug 91666 has been marked as a duplicate of this bug. ***
[Bug d/91666] _builtin function no work with GDC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91666 Iain Buclaw changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Iain Buclaw --- I'm pretty sure this is a duplicate of 91595, as if all predefined version were present, it wouldn't happen. *** This bug has been marked as a duplicate of bug 91595 ***
[Bug d/91595] Version (Windows) is not defined in GCC D Compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91595 --- Comment #2 from Iain Buclaw --- *** Bug 91600 has been marked as a duplicate of this bug. ***
[Bug d/91600] "Architecture not supported" reported for MinGW-W64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91600 Iain Buclaw changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Iain Buclaw --- So I'm just going to mark this as duplicate of 91595 *** This bug has been marked as a duplicate of bug 91595 ***
[Bug c++/94255] template specialization in different namespace causes crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94255
--- Comment #1 from Vince Bridgers ---
The corrected code successfully compiles. Basically, making sure the template
specialization is in the correct namespace.
namespace clang {
class DynTypedNode {
private:
template struct BaseConverter;
template struct ValueConverter {};
};
namespace ast_type_traits {
using DynTypedNode = ::clang::DynTypedNode;
}; // end namespace ast_type_traits
}; // end namespace clang
namespace clang {
//namespace ast_type_traits {
template <> struct DynTypedNode::BaseConverter : public
ValueConverter {};
//}; // end namespace ast_type_traits
}; // end namespace clang
int main(void) {
return 0;
}
[Bug d/91595] Version (Windows) is not defined in GCC D Compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91595 --- Comment #3 from Iain Buclaw --- Created attachment 48078 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48078&action=edit winnt-d support Attached patch, though the target is untested.
[Bug ipa/94256] New: Setting max-sched-region-blocks to >48 causes GCC memory usage to explode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94256 Bug ID: 94256 Summary: Setting max-sched-region-blocks to >48 causes GCC memory usage to explode Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: sultan at kerneltoast dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Passing any value greater than 48 for max-sched-region-blocks causes GCC memory usage to explode to the point of hitting the OOM killer. For example, using "--param max-sched-region-blocks=48" causes GCC memory usage to peak at 2 GB for my usecase. Using "--param max-sched-region-blocks=49" causes GCC memory usage to reach the full 32 GB of my machine and causes GCC to be killed. What is most fascinating is that, when I try to recompile GCC from source, setting the default value for max-sched-region-blocks to a number greater than 48 in params.def causes the GCC I'm using to recompile the source to exhibit the same issue, even though I haven't changed the max-sched-region-blocks parameter for my host's GCC. So, an easy way to reproduce the issue would be to: 1. Download GCC source 2. Modify the following code snippet in params.def to change the default value of max-sched-region-blocks to 49: Change this: DEFPARAM(PARAM_MAX_SCHED_REGION_BLOCKS, "max-sched-region-blocks", "The maximum number of blocks in a region to be considered for interblock scheduling.", 10, 0, 0) To: DEFPARAM(PARAM_MAX_SCHED_REGION_BLOCKS, "max-sched-region-blocks", "The maximum number of blocks in a region to be considered for interblock scheduling.", 49, 0, 0) 3. Try to compile your modified GCC source using your host's GCC 4. Your host's GCC will explode in memory usage and die
[Bug c++/94255] template specialization in different namespace causes crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94255
Nicholas Krause changed:
What|Removed |Added
CC||jason at redhat dot com,
||xerofoify at gmail dot com
--- Comment #2 from Nicholas Krause ---
I've managed to track this down to what appears to me to be a issue in:
tree
push_inner_scope (tree inner)
{
tree outer = current_scope ();
if (!outer)
outer = current_namespace;
push_inner_scope_r (outer, inner);
return outer;
}
I'm not certain if we should just check against NULL_TREE for outer or do we
need to also check against DECL_NAMESPACE as well. CCing Jason Merrill to take
a look at this with his comments.
[Bug c++/94255] template specialization in different namespace causes crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94255
--- Comment #3 from Nicholas Krause ---
I've managed to track this down to what appears to me to be a issue in:
tree
push_inner_scope (tree inner)
{
tree outer = current_scope ();
if (!outer)
outer = current_namespace;
push_inner_scope_r (outer, inner);
return outer;
}
I'm not certain if we should just check against NULL_TREE for outer or do we
need to also check against DECL_NAMESPACE as well. CCing Jason Merrill to take
a look at this with his comments.
[Bug gcov-profile/94029] [9 Regression] gcc crash in coverage.c:655 since r9-4216-g390e529e2b98983d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94029 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #15 from sandra at gcc dot gnu.org --- Seen on nios2-elf: FAIL: gcc.misc-tests/gcov-pr94029.c gcov failed: gcov-pr94029.c.gcov does not exist
[Bug gcov-profile/94029] [9 Regression] gcc crash in coverage.c:655 since r9-4216-g390e529e2b98983d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94029 --- Comment #16 from Bernd Edlinger --- Sandra, I am pretty sure it should exist, can you check which git revision you are looking at?
[Bug rtl-optimization/94256] Setting max-sched-region-blocks to >48 causes GCC memory usage to explode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94256
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |WONTFIX
--- Comment #1 from Andrew Pinski ---
That is why it is limited in the first place:
/* Update number of blocks and the estimate for number of insns
in the region. Return true if the region is "too large" for interblock
scheduling (compile time considerations). */
static bool
too_large (int block, int *num_bbs, int *num_insns)
{
(*num_bbs)++;
(*num_insns) += (common_sched_info->estimate_number_of_insns
(BASIC_BLOCK_FOR_FN (cfun, block)));
return ((*num_bbs > param_max_sched_region_blocks)
|| (*num_insns > param_max_sched_region_insns));
}
CUT -
having a more than 10 basic blocks in a region is huge really.
