[Bug rtl-optimization/89490] char array constant put in string merge section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #1 from Alan Modra ---
Reduced C testcase, compile at -O1.
static const unsigned char utf8_bom[3] = { 0xEF, 0xBB, 0xBF };
void
plonk (unsigned char *p)
{
__builtin_memcpy (p, utf8_bom, 3);
}
[Bug rtl-optimization/89490] New: char array constant put in string merge section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490 Bug ID: 89490 Summary: char array constant put in string merge section Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: amodra at gmail dot com Target Milestone: --- Created attachment 45813 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45813=edit preprocessed source gold flagged this from a svn r269173 build: warning: .../powerpc64le-linux/libstdc++-v3/src/.libs//libstdc++.a(lt1-codecvt.o): last entry in mergeable string section '.rodata._ZNSt12_GLOBAL__N_114write_utf8_bomIcEEbRNS_5rangeIT_Lb1EEESt12codecvt_mode.part.0.str1.8' not null terminated and yes, 3 bytes are put in the string merge section (flags AMS) without a NUL. I'm not sure about the classification of this bug since I haven't done any analysis, it may turn out to be a target problem. cc1plus -fpreprocessed codecvt.ii -quiet -dumpbase codecvt.cc -mcpu=power9 -auxbase-strip codecvt.o -g -O2 -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -std=gnu++11 -version -fchecking=1 -fno-implicit-templates -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=codecvt.lo -fchar8_t -fPIC -o codecvt.s
[Bug tree-optimization/89489] New: [9 Regression] ICE in gimple_duplicate_bb, at tree-cfg.c:6257
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89489 Bug ID: 89489 Summary: [9 Regression] ICE in gimple_duplicate_bb, at tree-cfg.c:6257 Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- gfortran-9.0.0-alpha20190224 snapshot (r269177) ICEs when compiling gcc/testsuite/gfortran.dg/inline_sum_5.f90 w/ -O1 -floop-parallelize-all -ftree-parallelize-loops=2: % powerpc-e300c3-linux-gnu-gfortran-9.0.0-alpha20190224 -O1 -floop-parallelize-all -ftree-parallelize-loops=2 -c gcc/testsuite/gfortran.dg/inline_sum_5.f90 during GIMPLE pass: cunroll f951: internal compiler error: in gimple_duplicate_bb, at tree-cfg.c:6257 0x64d066 gimple_duplicate_bb /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/tree-cfg.c:6257 0x94d81e duplicate_block(basic_block_def*, edge_def*, basic_block_def*, copy_bb_data*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/cfghooks.c:1085 0x94ee42 copy_bbs(basic_block_def**, unsigned int, basic_block_def**, edge_def**, unsigned int, edge_def**, loop*, basic_block_def*, bool) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/cfghooks.c:1353 0x95bebc duplicate_loop_to_header_edge(loop*, edge_def*, unsigned int, simple_bitmap_def*, edge_def*, vec*, int) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/cfgloopmanip.c:1296 0xf00818 gimple_duplicate_loop_to_header_edge(loop*, edge_def*, unsigned int, simple_bitmap_def*, edge_def*, vec*, int) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/tree-ssa-loop-manip.c:921 0xee4df0 try_unroll_loop_completely /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/tree-ssa-loop-ivcanon.c:907 0xee4df0 canonicalize_loop_induction_variables /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/tree-ssa-loop-ivcanon.c:1250 0xee6fc0 tree_unroll_loops_completely_1 /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/tree-ssa-loop-ivcanon.c:1391 0xee6f2a tree_unroll_loops_completely_1 /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/tree-ssa-loop-ivcanon.c:1344 0xee6f2a tree_unroll_loops_completely_1 /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/tree-ssa-loop-ivcanon.c:1344 0xee7223 tree_unroll_loops_completely /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/tree-ssa-loop-ivcanon.c:1437 0xee761c execute /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/tree-ssa-loop-ivcanon.c:1597 (While my target here is powerpc, the ICE is not target-specific.)
[Bug target/89482] arm aarch32 inline assembly w constraints generate s registers instead of d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89482 Andrew Pinski changed: What|Removed |Added Keywords||documentation Target||arm*, aarch64* Component|c |target --- Comment #1 from Andrew Pinski --- There is a few undocumented modifies (not constraints) that need to be documented for both ARM (aarch32) and AARCH64. There is at least another bug about them. NOTE x86 documents the modifies these days.
[Bug c++/89483] internal compiler error: Segmentation fault signal terminated program cc1plus with templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89483 --- Comment #5 from Andrew Pinski --- https://gcc.gnu.org/onlinedocs/gcc-8.3.0/gcc/C_002b_002b-Dialect-Options.html#index-ftemplate-depth
[Bug c++/89483] internal compiler error: Segmentation fault signal terminated program cc1plus with templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89483 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from Andrew Pinski --- >-ftemplate-depth=100 You get what you get when you increase this value. And it is documented to maybe run out of stack space too: The default value is 900, as the compiler can run out of stack space before hitting 1024 in some situations.
[Bug c++/89488] New: [9 Regression] ICE in merge_exception_specifiers, at cp/typeck2.c:2395
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89488
Bug ID: 89488
Summary: [9 Regression] ICE in merge_exception_specifiers, at
cp/typeck2.c:2395
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: 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++-9.0.0-alpha20190224 snapshot (r269177) ICEs when compiling the following
testcase:
struct zl {
struct {
int x2 = zl ();
} fx;
};
% g++-9.0.0-alpha20190224 -c vczgd7oc.cpp
vczgd7oc.cpp:3:18: error: default member initializer for 'zlx2' required before the end of its enclosing class
3 | int x2 = zl ();
| ^
vczgd7oc.cpp:3:12: note: defined here
3 | int x2 = zl ();
|^~~~
vczgd7oc.cpp:3:18: internal compiler error: in merge_exception_specifiers, at
cp/typeck2.c:2395
3 | int x2 = zl ();
| ^
0x67cfaf merge_exception_specifiers(tree_node*, tree_node*)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/cp/typeck2.c:2395
0x96aa69 process_subob_fn
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/cp/method.c:1261
0x96aa69 process_subob_fn
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/cp/method.c:1246
0x96b0a5 walk_field_subobs
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/cp/method.c:1458
0x96b900 synthesized_method_walk
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/cp/method.c:1724
0x96eae3 get_defaulted_eh_spec(tree_node*, int)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/cp/method.c:1762
0xa07186 maybe_instantiate_noexcept(tree_node*, int)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/cp/pt.c:24190
0x92e0da mark_used(tree_node*, int)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/cp/decl2.c:5392
0x893ff5 build_over_call
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/cp/call.c:8552
0x896b1f build_new_method_call_1
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/cp/call.c:9773
0x896b1f build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/cp/call.c:9848
0x897889 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/cp/call.c:9272
0x949ac6 build_value_init(tree_node*, int)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/cp/init.c:354
0xa7af92 build_functional_cast(tree_node*, tree_node*, int)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/cp/typeck2.c:2274
0x997574 cp_parser_functional_cast
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/cp/parser.c:28255
0x9a9c41 cp_parser_postfix_expression
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/cp/parser.c:7098
0x9b8bc9 cp_parser_unary_expression
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/cp/parser.c:8469
0x991d72 cp_parser_cast_expression
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/cp/parser.c:9355
0x99264a cp_parser_binary_expression
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/cp/parser.c:9457
0x9937b6 cp_parser_assignment_expression
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/cp/parser.c:9754
[Bug libstdc++/89477] Incorrect CTAD deduction guides for set and multiset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89477
--- Comment #1 from Arthur O'Dwyer ---
Similar cases for `unordered_{multi,}set` as well.
// https://godbolt.org/z/onYid6
#include
int main() {
const int arr[] = { 1, 2, 3 };
std::unordered_set s(arr, arr+3, 42, std::hash(),
std::allocator());
std::unordered_set t({ 1, 2, 3 }, 42, std::allocator());
}
[Bug rtl-optimization/89487] New: [8/9 Regression] ICE in expand_expr_addr_expr_1, at expr.c:7993
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89487
Bug ID: 89487
Summary: [8/9 Regression] ICE in expand_expr_addr_expr_1, at
expr.c:7993
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: x86_64-pc-linux-gnu
gcc-9.0.0-alpha20190224 snapshot (r269177) ICEs when compiling the following
snippet reduced from ocaml 4.05.0 package:
void
caml_interprete (void)
{
register int *pc asm("%r15");
register int *sp asm("%r14");
int i;
for (i = 0; i < 3; ++i)
*--sp = pc[i];
}
% x86_64-pc-linux-gnu-gcc-9.0.0-alpha20190224 -O2 -ftree-loop-distribution -c
/tmp/interp.i
during RTL pass: expand
/tmp/interp.i: In function 'caml_interprete':
/tmp/interp.i:2:1: internal compiler error: in expand_expr_addr_expr_1, at
expr.c:7993
2 | caml_interprete (void)
| ^~~
0x60739b expand_expr_addr_expr_1
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/expr.c:7993
0xa2909b expand_expr_addr_expr
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/expr.c:8106
0xa2909b expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/expr.c:11261
0xa355e4 expand_expr
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/expr.h:279
0xa355e4 expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**,
rtx_def**, expand_modifier)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/expr.c:7872
0xa3d20c expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/expr.c:8732
0xa29987 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/expr.c:11317
0xa35927 expand_expr
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/expr.h:279
0xa35927 expand_expr_addr_expr_1
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/expr.c:7931
0xa2909b expand_expr_addr_expr
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/expr.c:8106
0xa2909b expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/expr.c:11261
0xa355e4 expand_expr
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/expr.h:279
0xa355e4 expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**,
rtx_def**, expand_modifier)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/expr.c:7872
0xa3bfaa expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/expr.c:9732
0xa2bc5d expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/expr.c:9942
0xa3ed51 expand_expr
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/expr.h:279
0xa3ed51 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/expr.c:8508
0xa2bc5d expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/expr.c:9942
0x984200 expand_normal
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/expr.h:285
0x984200 do_compare_and_jump
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190224/work/gcc-9-20190224/gcc/dojump.c:1204
[Bug fortran/89174] [8 Regression] Allocation segfault with CLASS(*) MOLD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89174 --- Comment #14 from Neil Carlson --- The comment for r268313 calls out a change to gfc_find_and_cut_at_last_class_ref -- same function Thomas worked on for the fix on the trunk.
[Bug fortran/89174] [8 Regression] Allocation segfault with CLASS(*) MOLD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89174 --- Comment #13 from Neil Carlson --- I've pinpointed were the regression was introduced on the 8 branch. r268313 segfaults, but r268311 (the preceding change to 8) works fine.
[Bug libstdc++/89464] shared_ptr_base.h: error: '__tag' was not declared in this scope (gcc-8.3.0 regression?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89464 --- Comment #9 from Milhouse --- Thanks Jonathan, that's all clear now. A fix has been pushed which is working with both gcc-8.2.0 and gcc-8.3.0: https://github.com/Silicondust/libhdhomerun/pull/19
[Bug fortran/89219] ICE with derived type I/O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89219
--- Comment #4 from Jerry DeLisle ---
After a semi-lengthy session I am seeing this just before the segfault.
(gdb) p *expr
$2 = {expr_type = EXPR_OP, ts = {type = BT_CLASS, kind = 0, u = {
derived = 0x1f24e70, cl = 0x1f24e70, pad = 32657008}, interface = 0x0,
is_c_interop = 0, is_iso_c = 0, f90_type = BT_CLASS, deferred = false,
interop_kind = 0x0}, rank = 0, shape = 0x0, symtree = 0x0, ref = 0x0,
where = {nextc = 0x1eca90c, lb = 0x1eca8c0}, base_expr = 0x0, is_boz = 0,
is_snan = 0, error = 0, user_operator = 0, mold = 0, must_finalize = 0,
no_bounds_check = 0, external_blas = 0, do_not_resolve_again = 0,
do_not_warn = 0, representation = {length = 0, string = 0x0}, value = {
logical = 27, iokind = 27, integer = {{_mp_alloc = 27, _mp_size = 0,
_mp_d = 0x0}}, real = {{_mpfr_prec = 27, _mpfr_sign = 0,
_mpfr_exp = 31821088, _mpfr_d = 0x0}}, complex = {{re = {{
_mpfr_prec = 27, _mpfr_sign = 0, _mpfr_exp = 31821088,
_mpfr_d = 0x0}}, im = {{_mpfr_prec = 0, _mpfr_sign = 0,
_mpfr_exp = 0, _mpfr_d = 0x0, op = {
op = INTRINSIC_PARENTHESES, uop = 0x0, op1 = 0x1e58d20, op2 = 0x0},
function = {actual = 0x1b, name = 0x0, isym = 0x1e58d20, esym = 0x0},
compcall = {actual = 0x1b, name = 0x0, base_object = 0x1e58d20, tbp = 0x0,
ignore_pass = 0, assign = 0}, character = {length = 27, string = 0x0},
constructor = 0x1b}, param_list = 0x0}
(gdb) frame
#0 get_dtio_proc (ts=ts@entry=0x1ee8498, code=code@entry=0x1ee8570,
dtio_sub=dtio_sub@entry=0x7fffcd00)
at ../../trunk/gcc/fortran/trans-io.c:2246
2246 gfc_add_vptr_component (expr);
One thing that strikes me here is we are trying to get the dtio procedure out
of I think an EXPR_OP. So I wonder if we need to try to resolve or simplify
this to get the actual class. This is new territory for me. Anyone else have
any input?
[Bug target/89485] Support vectorcall calling convention on windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89485 Andrew Pinski changed: What|Removed |Added Target||x86_64-*-*-mingw32 Component|c |target Severity|normal |enhancement
[Bug tree-optimization/40635] bogus name and location in 'may be used uninitialized' warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40635 Martin Sebor changed: What|Removed |Added Last reconfirmed|2017-03-02 00:00:00 |2019-2-24 CC||msebor at gcc dot gnu.org Known to fail||8.3.0, 9.0 --- Comment #12 from Martin Sebor --- No change in GCC 9.
[Bug middle-end/36823] missing uninitialized warning (IPA, inlining)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36823 Martin Sebor changed: What|Removed |Added Last reconfirmed|2009-02-09 15:35:38 |2019-2-24 CC||msebor at gcc dot gnu.org --- Comment #4 from Martin Sebor --- GCC 7, 8 and 9 do warn at -O1 but not at -O2. The last version on Godbolt to warn at -O2 was 4.1 (I don't have access to the bisection machine so I can't tell where this problem was introduced).
[Bug c++/84585] [7 Regression] internal compiler error: in get_local_decls, at cp/name-lookup.c:3654
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84585 Paolo Carlini changed: What|Removed |Added CC|vegard.nossum at gmail dot com | Summary|[7/8/9 Regression] internal |[7 Regression] internal |compiler error: in |compiler error: in |get_local_decls, at |get_local_decls, at |cp/name-lookup.c:3654 |cp/name-lookup.c:3654 --- Comment #4 from Paolo Carlini --- This is fixed in trunk and 8.1.0.
[Bug c++/84585] [7/8/9 Regression] internal compiler error: in get_local_decls, at cp/name-lookup.c:3654
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84585 --- Comment #3 from paolo at gcc dot gnu.org --- Author: paolo Date: Sun Feb 24 23:44:11 2019 New Revision: 269180 URL: https://gcc.gnu.org/viewcvs?rev=269180=gcc=rev Log: 2019-02-24 Paolo Carlini PR c++/84585 * g++.dg/cpp0x/pr84585.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr84585.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug middle-end/31279] Uninitialized warning for call-by-reference arguments with known intent(in)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31279 Martin Sebor changed: What|Removed |Added Last reconfirmed|2012-02-02 00:00:00 |2019-2-24 CC||msebor at gcc dot gnu.org Depends on||83859 --- Comment #4 from Martin Sebor --- I have implemented three attributes: read_only, read_write, and write_only. They take two arguments: one refers to the pointer function parameter and the other to the size of the object the pointer points to. See bug 83859. Besides warning, they can also be used for optimization. I'm hoping to submit the feature for GCC 10. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83859 [Bug 83859] Please add new attribute which will establish relation between parameters for buffer and its size
[Bug target/81879] Bad compilation of small program if LTO is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81879 --- Comment #5 from Martin Liška --- The .res file contains just a single object, thus PREEMPTED_REG does not make sense. Problem will be probably in binutils. I'm investigating right now..
[Bug fortran/89174] [8 Regression] Allocation segfault with CLASS(*) MOLD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89174 Thomas Koenig changed: What|Removed |Added Summary|[8/9 Regression] Allocation |[8 Regression] Allocation |segfault with CLASS(*) MOLD |segfault with CLASS(*) MOLD --- Comment #12 from Thomas Koenig --- Fixed on trunk so far.
[Bug fortran/89174] [8/9 Regression] Allocation segfault with CLASS(*) MOLD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89174 --- Comment #11 from Thomas Koenig --- Author: tkoenig Date: Sun Feb 24 22:49:47 2019 New Revision: 269179 URL: https://gcc.gnu.org/viewcvs?rev=269179=gcc=rev Log: 2019-02-24 Thomas Koenig PR fortran/89174 * trans-expr.c (gfc_find_and_cut_at_last_class_ref): Add is_mold to garguments. If we are dealing with a MOLD, call gfc_expr_to_initialize(). * trans-stmt.c (gfc_trans_allocate): For MOLD, pass is_mold=true to gfc_find_and_cut_at_last_class_ref. * trans.h (gfc_find_and_cut_at_last_class_ref): Add optional argument is_mold with default false. 2019-02-24 Thomas Koenig PR fortran/89174 * gfortran.dg/allocate_with_mold_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/allocate_with_mold_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog
[Bug target/87007] [8 Regression] 10% slowdown with -march=skylake-avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87007 --- Comment #10 from hjl at gcc dot gnu.org --- Author: hjl Date: Sun Feb 24 22:41:55 2019 New Revision: 269178 URL: https://gcc.gnu.org/viewcvs?rev=269178=gcc=rev Log: i386: Compile PR target/87007 tests with -mfpmath=sse -mfpmath=sse is needed to enable SSE for FP math in 32-bit. PR target/87007 * gcc.target/i386/pr87007-1.c: Compile with -mfpmath=sse. * gcc.target/i386/pr87007-2.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/pr87007-1.c trunk/gcc/testsuite/gcc.target/i386/pr87007-2.c
[Bug target/81879] Bad compilation of small program if LTO is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81879 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-24 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Martin Liška --- Confirmed. I can confirm that the difference in resolution file is the problem: 750 6dacea834fb099d1 PREVAILING_DEF_IRONLY _ZNKSt5ctypeIcE8do_widenEc vs. 750 1b64a3a32ab1e36a PREEMPTED_REG _ZNKSt5ctypeIcE8do_widenEc Note that on a native x86_64-linux-gnu system, the resolution is also PREVAILING_DEF_IRONLY with -static option. It's also visible with: x86_64-w64-mingw32-nm --plugin /usr/lib64/gcc/x86_64-w64-mingw32/8.2.0/liblto_plugin.so simpler.o | grep do_widen T _ZNKSt5ctypeIcE8do_widenEc while on a native linux system: nm s2.o | grep do_widen W _ZNKSt5ctypeIcE8do_widenEc T == The symbol is in the text (code) section. W == The symbol is a weak object.
[Bug tree-optimization/89478] missed optimization for lambda expression when variable is uninitialized when declared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89478 --- Comment #2 from SztfG at yandex dot ru --- (In reply to Marc Glisse from comment #1) > I think the uninitialized variable makes the initialization not constexpr > (and indeed gcc/clang complain if you try to declare test constexpr). Then > we hit the well-known missed optimization that gcc is unable to convert a > dynamic initialization into a static initialization even in the most trivial > constant cases. Then need to mark this bug as duplicate, but where that bug in GCC bugzilla, which about that well-known missed optimization?
[Bug c++/89486] New: GCC fails to compile designated initializer use involving implicit conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89486
Bug ID: 89486
Summary: GCC fails to compile designated initializer use
involving implicit conversion
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: st at quanttec dot com
Target Milestone: ---
The following code fails to compile with the current trunk version of GCC.
clang compiles the code fine.
struct P {
int a = 0;
void* b;
};
void f(P) {}
void test() {
f({.b = nullptr});
}
: In function 'void test()':
:9:19: error: could not convert '{nullptr}' from '' to 'P'
9 | f({.b = nullptr});
| ^
| |
|
Compiler returned: 1
[Bug fortran/84779] [7/8/9 Regression] Compiling gfortran.fortran-torture/execute/entry_4.f90 with -O1 or -Os and -fdefault-integer-8 gives an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84779 --- Comment #5 from Harald Anlauf --- With rev. 269177 and on x86_64-pc-linux-gnu, I now see the ICE only at -O1, but no longer at -Os. After a frustrating debugging session, I decided to look at the -fdump-tree-all for all options -O0 ... -O2, but didn't get any idea what to look for. Maybe some help from a middle-end expert would be needed.
[Bug target/87007] [8 Regression] 10% slowdown with -march=skylake-avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87007 Rainer Orth changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #9 from Rainer Orth --- (In reply to H.J. Lu from comment #8) > Fixed on trunk so far. However the new tests FAIL for 32-bit (seen on i386-pc-solaris2.11): +FAIL: gcc.target/i386/pr87007-1.c scan-assembler-times vxorps[^\\n\\r]*xmm[0-9] 1 +FAIL: gcc.target/i386/pr87007-2.c scan-assembler-times vxorps[^\\n\\r]*xmm[0-9] 1
[Bug fortran/88326] [7/8/9 Regression] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6085
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88326 --- Comment #6 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Sun Feb 24 20:03:28 2019 New Revision: 269177 URL: https://gcc.gnu.org/viewcvs?rev=269177=gcc=rev Log: 2019-02-24 Harald Anlauf PR fortran/89266 PR fortran/88326 * target-memory.c (gfc_element_size): Return false if element size cannot be determined; element size is returned separately. (gfc_target_expr_size): Return false if expression size cannot be determined; expression size is returned separately. * target-memory.h: Adjust prototypes. * check.c (gfc_calculate_transfer_sizes): Adjust references to gfc_target_expr_size, gfc_element_size. * arith.c (hollerith2representation): Likewise. * class.c (find_intrinsic_vtab): Likewise. * simplify.c (gfc_simplify_sizeof): Likewise. PR fortran/89266 PR fortran/88326 * gfortran.dg/pr89266.f90: New test. * gfortran.dg/pr88326.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr88326.f90 trunk/gcc/testsuite/gfortran.dg/pr89266.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/arith.c trunk/gcc/fortran/check.c trunk/gcc/fortran/class.c trunk/gcc/fortran/simplify.c trunk/gcc/fortran/target-memory.c trunk/gcc/fortran/target-memory.h trunk/gcc/testsuite/ChangeLog
[Bug fortran/89266] ICE with TRANSFER of len=0 character array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89266 --- Comment #11 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Sun Feb 24 20:03:28 2019 New Revision: 269177 URL: https://gcc.gnu.org/viewcvs?rev=269177=gcc=rev Log: 2019-02-24 Harald Anlauf PR fortran/89266 PR fortran/88326 * target-memory.c (gfc_element_size): Return false if element size cannot be determined; element size is returned separately. (gfc_target_expr_size): Return false if expression size cannot be determined; expression size is returned separately. * target-memory.h: Adjust prototypes. * check.c (gfc_calculate_transfer_sizes): Adjust references to gfc_target_expr_size, gfc_element_size. * arith.c (hollerith2representation): Likewise. * class.c (find_intrinsic_vtab): Likewise. * simplify.c (gfc_simplify_sizeof): Likewise. PR fortran/89266 PR fortran/88326 * gfortran.dg/pr89266.f90: New test. * gfortran.dg/pr88326.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr88326.f90 trunk/gcc/testsuite/gfortran.dg/pr89266.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/arith.c trunk/gcc/fortran/check.c trunk/gcc/fortran/class.c trunk/gcc/fortran/simplify.c trunk/gcc/fortran/target-memory.c trunk/gcc/fortran/target-memory.h trunk/gcc/testsuite/ChangeLog
[Bug target/89451] [9 Regression] FAIL: gfortran.dg/pr79315.f90 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89451 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from janus at gcc dot gnu.org --- In fact it looks like the problem is gone at r269173 (probably fixed by r269127).
[Bug rtl-optimization/89445] [9 regression] _mm512_maskz_loadu_pd "forgets" to use the mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89445 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #10 from Jakub Jelinek --- Should be fixed now. Guess for the missed optimizations we should have another PR, targeted at GCC 10.
[Bug rtl-optimization/89445] [9 regression] _mm512_maskz_loadu_pd "forgets" to use the mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89445
--- Comment #9 from Jakub Jelinek ---
Author: jakub
Date: Sun Feb 24 19:23:51 2019
New Revision: 269176
URL: https://gcc.gnu.org/viewcvs?rev=269176=gcc=rev
Log:
PR rtl-optimization/89445
* simplify-rtx.c (simplify_ternary_operation): Don't use
simplify_merge_mask on operands that may trap.
* rtlanal.c (may_trap_p_1): Use FLOAT_MODE_P instead of
SCALAR_FLOAT_MODE_P checks. For integral division by zero, if
second operand is CONST_VECTOR, check if any element could be zero.
Don't expect traps for VEC_{MERGE,SELECT,CONCAT,DUPLICATE} unless
their operands can trap.
* gcc.target/i386/avx512f-pr89445.c: New test.
Added:
trunk/gcc/testsuite/gcc.target/i386/avx512f-pr89445.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/rtlanal.c
trunk/gcc/simplify-rtx.c
trunk/gcc/testsuite/ChangeLog
[Bug target/89451] [9 Regression] FAIL: gfortran.dg/pr79315.f90 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89451 janus at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #11 from janus at gcc dot gnu.org --- (In reply to H.J. Lu from comment #10) > Does it fail without --with-arch=haswell if you add -march=haswell by hand? Yes, it does. Further investigation seems to indicate that the problem is related to AVX: Compiling the test case results in an ICE when adding -mavx or -march=sandybridge, but not with -msse4.2 or -march=westmere.
[Bug target/89271] [9 Regression] gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271 --- Comment #14 from Segher Boessenkool --- Cool results so far! +FAIL: gcc.target/powerpc/p9-dimode1.c scan-assembler-not \\mmtvsrd\\M p9_plus_1: .LFB1: .cfi_startproc - vspltisw 0,1 - vupklsw 0,0 + li 9,1 + mtvsrd 0,9 The new code is actually cheaper on p9. The test is wrong?
[Bug c/89485] New: Support vectorcall calling convention on windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89485 Bug ID: 89485 Summary: Support vectorcall calling convention on windows Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: yyc1992 at gmail dot com Target Milestone: --- I'm very surprised that I didn't find an issue for this so sorry if this is discussed/rejected somewhere else. It appears that both MSVC and clang supports a vectorcall calling convention which is very similar to the one used on linux and passes large vectors in the corresponding vector register instead of on the stack. It'll be nice if gcc can support that both for efficiency and for compatibility. Ref https://docs.microsoft.com/en-us/cpp/cpp/vectorcall?view=vs-2017 https://clang.llvm.org/docs/AttributeReference.html#id335
[Bug c++/89484] Compiler ICE: internal compiler error: in dwarf2out_frame_debug_adjust_cfa, at dwarf2cfi.c:1171 when using __attribute__((interrupt))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89484 --- Comment #2 from Hans-Peter Dusel --- thor:build hdusel$ /opt/gcc-8.3.0-rx-none-elf/bin/rx-none-elf-g++ -v Using built-in specs. COLLECT_GCC=/opt/gcc-8.3.0-rx-none-elf/bin/rx-none-elf-g++ COLLECT_LTO_WRAPPER=/opt/gcc-8.3.0-rx-none-elf/libexec/gcc/rx-none-elf/8.3.0/lto-wrapper Target: rx-none-elf Configured with: /tmp/build_cross_gcc/gcc-8.3.0_arch/gcc-8.3.0/configure --target=rx-none-elf --prefix=/opt/gcc-8.3.0-rx-none-elf --disable-nls --disable-shared --disable-threads --disable-libssp --enable-multilib --enable-lto --without-headers --with-newlib --with-gnu-as --with-gnu-ld --with-gcc --enable-languages=c,c++ --disable-werror Thread model: single gcc version 8.3.0 (GCC)
[Bug fortran/89219] ICE with derived type I/O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89219 Jerry DeLisle changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #3 from Jerry DeLisle --- I will try.
[Bug fortran/89291] internal compiler error: in gfc_trans_use_stmts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89291 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #6 from Jerry DeLisle --- According to the goddess google, this likely is not a gfortran issue. Regardless, for reference: https://github.com/wrf-model/WRF If someone wants to try to download and build this.
[Bug c/89410] [7/8 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1237 after #line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410 --- Comment #16 from Jonny Grant --- Hello! Checked 23 Feb trunk g++ (Compiler-Explorer-Build) 9.0.1 20190223 (experimental) comment 9 test case #line 0 does not give an error Original test case still shows negative line numbers :-737418241:2: warning: #warning second [-Wcpp] :-737418240:7: warning: line number out of range Same for comment 5 test case Could the "line number out of range" specify what the max line number supported is perhaps?
[Bug c/89410] [7/8 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1237 after #line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410 --- Comment #15 from Jonny Grant --- (In reply to Segher Boessenkool from comment #11) > (In reply to Jonny Grant from comment #9) > > Maybe zero could be disallowed too. > > Yes, but maybe we need that for historical reasons. > > > Not sure what is best here, I'm not knowledgeable of GCC, but maybe setting > > it to -1 if it goes above, and then never increment again if(-1 == line) ... > > The testcase will still ICE then... The assert is > > /* The spans must be ordered. */ > gcc_assert (prev->m_first_line < next->m_first_line); Maybe it needs an update, if #line 0 is not allowed
[Bug libstdc++/89416] [9 regression] std::vector::push_back no longer builds.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89416 Jonathan Wakely changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jonathan Wakely --- It should be OK with Clang now.
[Bug libstdc++/89416] [9 regression] std::vector::push_back no longer builds.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89416 --- Comment #5 from Jonathan Wakely --- Author: redi Date: Sun Feb 24 15:44:18 2019 New Revision: 269175 URL: https://gcc.gnu.org/viewcvs?rev=269175=gcc=rev Log: PR libstdc++/89416 fix accessibility of members PR libstdc++/89416 * include/bits/alloc_traits.h (__is_alloc_insertable_impl): Make copy and move members public. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/alloc_traits.h
[Bug c++/89484] Compiler ICE: internal compiler error: in dwarf2out_frame_debug_adjust_cfa, at dwarf2cfi.c:1171 when using __attribute__((interrupt))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89484 --- Comment #1 from Hans-Peter Dusel --- Tried to verify this with a GCC 8.3 Crosscompiler (same environment as described) but now for Target ARM. This Crosscompiler together with the mentioned Code-snippet and command line __does not__ cause an ICE.
[Bug d/89177] unaligned memory access in libphobos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89177 --- Comment #6 from Johannes Pfau --- Patch posted here: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01897.html
[Bug target/89451] [9 Regression] FAIL: gfortran.dg/pr79315.f90 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89451 H.J. Lu changed: What|Removed |Added Status|NEW |WAITING CC||hjl.tools at gmail dot com --- Comment #10 from H.J. Lu --- (In reply to janus from comment #8) > In fact I only see the problem when configuring with --with-arch=haswell. It > goes away if I remove that flag. Does it fail without --with-arch=haswell if you add -march=haswell by hand?
[Bug c++/89484] New: Compiler ICE: internal compiler error: in dwarf2out_frame_debug_adjust_cfa, at dwarf2cfi.c:1171 when using __attribute__((interrupt))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89484
Bug ID: 89484
Summary: Compiler ICE: internal compiler error: in
dwarf2out_frame_debug_adjust_cfa, at dwarf2cfi.c:1171
when using __attribute__((interrupt))
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hdu...@tangerine-soft.de
Target Milestone: ---
Environmant
===
Given is a Crosscompiler GCC 8.3 (official Release)
This Crosscompiler hass been build with Xcode Clang
(Apple LLVM version 10.0.0 (clang-1000.11.45.5) Target:
x86_64-apple-darwin17.7.0)
xGCC Target architecture is "RX" (Renesas RX)
Running Host is: Mac OS X 10.11.6
Problem:
===
If one tries to compile the code as follows:
code start -
static void __attribute__((interrupt)) ISR_handleUartReceiveData(void)
{}
- code end --
...by using the commend line...
$> rx-none-elf-c++ ../Test.cpp -c -g
...The following ICE will happen:
during RTL pass: dwarf2
../Test.cpp: In function 'void ISR_handleUartReceiveData()':
../Test.cpp:6:1: internal compiler error: in dwarf2out_frame_debug_adjust_cfa,
at dwarf2cfi.c:1171
}
^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug fortran/89174] [8/9 Regression] Allocation segfault with CLASS(*) MOLD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89174 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org
[Bug c++/89483] internal compiler error: Segmentation fault signal terminated program cc1plus with templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89483 --- Comment #3 from Daniil Sharko --- Created attachment 45812 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45812=edit preprocessed-segfault-program
[Bug c++/89483] internal compiler error: Segmentation fault signal terminated program cc1plus with templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89483 --- Comment #2 from Daniil Sharko --- Created attachment 45811 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45811=edit verbose-output
[Bug c++/89483] internal compiler error: Segmentation fault signal terminated program cc1plus with templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89483 --- Comment #1 from Daniil Sharko --- Created attachment 45810 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45810=edit non-segfault-program.cpp
[Bug c++/89483] New: internal compiler error: Segmentation fault signal terminated program cc1plus with templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89483 Bug ID: 89483 Summary: internal compiler error: Segmentation fault signal terminated program cc1plus with templates Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: integrex at yandex dot ru Target Milestone: --- Created attachment 45809 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45809=edit segfault-program.cpp Description: Segmentation fault happens while compiling segfault-program.cpp (in attachments) with options: "g++ -ftemplate-depth=100 segfault-program.cpp". Also, there is no errors while compiling non-segfault-program.cpp (in attachments) with the same compiler options, but it takes some time: real2m16,186s user2m14,934s sys 0m0,231s Additional info: * Verbose output of compiling (with -v option) in attachments (verbose-output). * g++ version: "g++ (GCC) 8.2.1 20180831". * Arch Linux version: "Linux Billy 4.18.16-arch1-1-ARCH #1 SMP PREEMPT Sat Oct 20 22:06:45 UTC 2018 x86_64 GNU/Linux". * Preprosessed segfault program in attachments (preprocessed-segfault-program).
[Bug fortran/89291] internal compiler error: in gfc_trans_use_stmts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89291 --- Comment #5 from zwieflhofer --- Yes, I did provided NCAR with the URL to this bug-id but no response so far. I did not try the 8.2 trunk - sort of assuming that NCAR will do so anyway in due course as part of their standard release testing. I am good with 5.5.0 unless you tell me that 8.2 will create binaries that are likley to run faster on Intel/AMD.
[Bug fortran/89174] [8/9 Regression] Allocation segfault with CLASS(*) MOLD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89174
--- Comment #10 from Thomas Koenig ---
This seems to work:
Index: trans-expr.c
===
--- trans-expr.c(Revision 269161)
+++ trans-expr.c(Arbeitskopie)
@@ -352,7 +352,7 @@ gfc_vptr_size_get (tree vptr)
of refs following. */
gfc_expr *
-gfc_find_and_cut_at_last_class_ref (gfc_expr *e)
+gfc_find_and_cut_at_last_class_ref (gfc_expr *e, bool is_mold)
{
gfc_expr *base_expr;
gfc_ref *ref, *class_ref, *tail = NULL, *array_ref;
@@ -394,7 +394,10 @@ gfc_expr *
e->ref = NULL;
}
- base_expr = gfc_copy_expr (e);
+ if (is_mold)
+base_expr = gfc_expr_to_initialize (e);
+ else
+base_expr = gfc_copy_expr (e);
/* Restore the original tail expression. */
if (class_ref)
Index: trans-stmt.c
===
--- trans-stmt.c(Revision 269161)
+++ trans-stmt.c(Arbeitskopie)
@@ -6641,7 +6641,7 @@ gfc_trans_allocate (gfc_code * code)
/* Use class_init_assign to initialize expr. */
gfc_code *ini;
ini = gfc_get_code (EXEC_INIT_ASSIGN);
- ini->expr1 = gfc_find_and_cut_at_last_class_ref (expr);
+ ini->expr1 = gfc_find_and_cut_at_last_class_ref (expr, true);
tmp = gfc_trans_class_init_assign (ini);
gfc_free_statements (ini);
gfc_add_expr_to_block (, tmp);
Index: trans.h
===
--- trans.h (Revision 269161)
+++ trans.h (Arbeitskopie)
@@ -412,7 +412,7 @@ tree gfc_class_data_get (tree);
tree gfc_class_vptr_get (tree);
tree gfc_class_len_get (tree);
tree gfc_class_len_or_zero_get (tree);
-gfc_expr * gfc_find_and_cut_at_last_class_ref (gfc_expr *);
+gfc_expr * gfc_find_and_cut_at_last_class_ref (gfc_expr *, bool is_mold =
false);
/* Get an accessor to the class' vtab's * field, when a class handle is
available. */
tree gfc_class_vtab_hash_get (tree);
[Bug fortran/89174] [8/9 Regression] Allocation segfault with CLASS(*) MOLD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89174 --- Comment #9 from Thomas Koenig --- FWITW, there is a difference when handling the MOLD expression in gfc_find_and_cut_at_last_class_ref. In the version that calls gfc_expr_to_initialize, we see (gdb) call debug(base_expr) push:this % mold (CLASS __class__STAR_a) whereas with current trunk we see (gdb) call debug(base_expr) push:this % mold (DERIVED STAR) On entry, the variable is push:this % mold (DERIVED STAR), so the call to gfc_expre_to_initialize seems to do something about the type...
[Bug fortran/87566] ICE with class(*) and select
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87566 --- Comment #13 from Paul Thomas --- (In reply to Neil Carlson from comment #12) > The commit r265171 that fixed this issue also introduced a regression in 8.2 > and 9, and certainly the 7 branch too if it was back-ported to it. See > PR89174 for the example, which had worked correctly for 7, 8, and 9, but > which now segfaults on at least 8 and 9. I suppose it's too late revert that > patch ... Hi Neil, As I said in comment #8, I decided that backporting was not going to work because there were too many antecedent patches. I just checked through the ChangeLog for 8-branch and there is no sign of anybody else attempting the fix. I'll take a look at 89174. Thanks Paul
[Bug fortran/89476] FAIL: gfortran.dg/ISO_Fortran_binding_5.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89476 --- Comment #5 from Paul Thomas --- Many Thanks HJ. I find that there is a ISO_Fortran_binding.h still residing in gfortran.dg, in my tree. Hence the successful regtesting on my side. Sorry about that Paul
[Bug fortran/89174] [8/9 Regression] Allocation segfault with CLASS(*) MOLD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89174 --- Comment #8 from Thomas Koenig --- (In reply to Thomas Koenig from comment #7) > This patch makes the test case work again: This also introduces numerous regressions, so this is not recommended as a fix :-)
[Bug fortran/89174] [8/9 Regression] Allocation segfault with CLASS(*) MOLD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89174 --- Comment #7 from Thomas Koenig --- This patch makes the test case work again: === --- trans-expr.c(Revision 265171) +++ trans-expr.c(Arbeitskopie) @@ -394,7 +394,11 @@ e->ref = NULL; } +#if 0 base_expr = gfc_copy_expr (e); +#else + base_expr = gfc_expr_to_initialize (e); +#endif /* Restore the original tail expression. */ if (class_ref)
[Bug c/89482] New: arm aarch32 inline assembly w constraints generate s registers instead of d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89482
Bug ID: 89482
Summary: arm aarch32 inline assembly w constraints generate s
registers instead of d
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ciro.santilli at gmail dot com
Target Milestone: ---
The 8.2.0 documentation at
https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Machine-Constraints.html#Machine-Constraints
says:
t
VFP floating-point registers s0-s31. Used for 32 bit values.
w
VFP floating-point registers d0-d31 and the appropriate subset d0-d15 based on
command line options. Used for 64 bit values only. Not valid for Thumb1.
However, when I try to compile the following:
main.c
#include
int main(void) {
float my_float = 1.5;
__asm__ (
"vmov s0, 1.0;"
"vadd.f32 %[my_float], %[my_float], s0;"
: [my_float] "+t" (my_float)
:
: "s0"
);
assert(my_float == 2.5);
#if 1
double my_double = 1.5;
__asm__ (
"vmov.f64 d0, 1.0;"
"vadd.f64 %[my_double], %[my_double], d0;"
: [my_double] "+w" (my_double)
:
: "d0"
);
assert(my_double == 2.5);
#endif
}
with:
arm-linux-gnueabihf-gcc -std=c99 -ggdb3 -march=armv7-a -pedantic -Wall
-Wextra -o 'main' 'main.c'
the part in #if 1 would fail with:
selected FPU does not support instruction -- `vadd.f64 s14,s14,d0'
so it appears that the "w" constraint is actually being converted to an s
register.
Tested in Ubuntu 18.10, packaged GCC 8.2.0, mentioned at:
https://stackoverflow.com/questions/53960240/armv8-floating-point-output-inline-assembly
[Bug fortran/89174] [8/9 Regression] Allocation segfault with CLASS(*) MOLD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89174
--- Comment #6 from Thomas Koenig ---
And on my AMD system, it does indeed pass with r265170. OK.
Looking at the diff of the tree dumps between the two versions,
the difference is
--- a.r265170 2019-02-24 10:56:39.138713129 +0100
+++ a.r265171 2019-02-24 10:56:59.59069 +0100
@@ -229,10 +229,7 @@
}
(struct __vtype__STAR *) this->_data->mold._vptr = (struct __vtype__STAR *)
((struct __class__STAR_t *) value)->_vptr;
this->_data->mold._len = ((struct __class__STAR_t *) value)->_len;
- if (this->_data->mold._vptr->_def_init != 0B)
-{
- (void) __builtin_memcpy (this->_data->mold._data, (void *)
this->_data->mold._vptr->_def_init, (unsigned long)
this->_data->mold._vptr->_size);
-}
+ (void) __builtin_memcpy (this->_data->mold._data, (void *)
this->_data->mold._vptr->_def_init, (unsigned long)
this->_data->mold._vptr->_size);
}
so there is a NULL pointer check missing from the code compiled with
r265171.
[Bug target/89451] [9 Regression] FAIL: gfortran.dg/pr79315.f90 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89451 Thomas Koenig changed: What|Removed |Added Component|fortran |target --- Comment #9 from Thomas Koenig --- (In reply to janus from comment #8) > In fact I only see the problem when configuring with --with-arch=haswell. It > goes away if I remove that flag. Looks like a target regression then, which Fortran just happens to expose. Moving component to TARGET.
[Bug fortran/89174] [8/9 Regression] Allocation segfault with CLASS(*) MOLD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89174 --- Comment #5 from Thomas Koenig --- The problem is with the subroutine, not with the call from the main program. If you split the module and main program into a separate file and compile the modlue with r264951 (a random version which works) and the mani program with r265171, the program works. The other way around, it segfaults.
[Bug fortran/89451] [9 Regression] FAIL: gfortran.dg/pr79315.f90 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89451 janus at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #8 from janus at gcc dot gnu.org --- In fact I only see the problem when configuring with --with-arch=haswell. It goes away if I remove that flag.
[Bug c++/89481] New: constexpr function allows writing one active union member and reading another
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89481
Bug ID: 89481
Summary: constexpr function allows writing one active union
member and reading another
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mickey.veksler at gmail dot com
Target Milestone: ---
The following code should not compile, not when passed as a template argument
to std::intergral_constant :
constexpr bool all_zeros()
{
union mix {
double numeric;
char bytes[sizeof(double)+1];
};
mix zero{-0.0}; // active is 'numeric'
// setting a different active member(?):
zero.bytes[sizeof(double)] = '\0';
for (unsigned i=0 ; i != sizeof(double) ; ++i)
{
// or this is illegal (since it was never initialized through 'bytes')
if (zero.bytes[i])
return false;
}
return true;
}
The puzzling thing is that the following two give different results:
int main()
{
// return all_zeros();
return std::integral_constant::value;
}
Unlike gcc, clang-7.0.0 emits diagnostics:
:3:16: error: constexpr function never produces a constant expression
[-Winvalid-constexpr]
constexpr bool all_zeros()
^
:10:32: note: assignment to member 'bytes' of union with active
member 'numeric' is not allowed in a constant expression
zero.bytes[sizeof(double)] = '\0';
^
[Bug target/89474] ice in df_reg_chain_verify_unmarked, at df-scan.c:3995
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89474 --- Comment #2 from David Binderman --- Using built-in specs. COLLECT_GCC=/home/dcb/gcc/results/bin/gcc Target: x86_64-pc-linux-gnu Configured with: ../trunk/configure --prefix=/home/dcb/gcc/results.269150 --disa ble-multilib --disable-werror --enable-checking=df,extra,fold,rtl,yes --enable-l anguages=c,c++,fortran Thread model: posix gcc version 9.0.1 20190223 (experimental) (GCC) COLLECT_GCC_OPTIONS='-O3' '-march=native' '-c' '-w' '-v' /home/dcb/gcc/results.269150/libexec/gcc/x86_64-pc-linux-gnu/9.0.1/cc1 -quiet - v bug507.c -march=bdver2 -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -msse4a -m cx16 -msahf -mno-movbe -maes -mno-sha -mpclmul -mpopcnt -mabm -mlwp -mfma -mfma4 -mxop -mbmi -mno-sgx -mno-bmi2 -mno-pconfig -mno-wbnoinvd -mtbm -mavx -mno-avx2 -msse4.2 -msse4.1 -mlzcnt -mno-rtm -mno-hle -mno-rdrnd -mf16c -mno-fsgsbase -mn o-rdseed -mprfchw -mno-adx -mfxsr -mxsave -mno-xsaveopt -mno-avx512f -mno-avx512 er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mno-clflushopt -mno-xsavec -mno -xsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbm i -mno-avx5124fmaps -mno-avx5124vnniw -mno-clwb -mno-mwaitx -mno-clzero -mno-pku -mno-rdpid -mno-gfni -mno-shstk -mno-avx512vbmi2 -mno-avx512vnni -mno-vaes -mno -vpclmulqdq -mno-avx512bitalg -mno-movdiri -mno-movdir64b -mno-waitpkg -mno-clde mote -mno-ptwrite --param l1-cache-size=16 --param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=bdver2 -quiet -dumpbase bug507.c -auxbase bug507 -O3 -w -version -o /tmp/ccO1klSX.s GNU C17 (GCC) version 9.0.1 20190223 (experimental) (x86_64-pc-linux-gnu) compiled by GNU C version 9.0.1 20190223 (experimental), GMP version 6.1 .2, MPFR version 3.1.6-p2, MPC version 1.1.0, isl version isl-0.16.1-GMP GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring nonexistent directory "/home/dcb/gcc/results.269150/lib/gcc/x86_64-pc-l inux-gnu/9.0.1/../../../../x86_64-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /home/dcb/gcc/results.269150/lib/gcc/x86_64-pc-linux-gnu/9.0.1/include /usr/local/include /home/dcb/gcc/results.269150/include /home/dcb/gcc/results.269150/lib/gcc/x86_64-pc-linux-gnu/9.0.1/include-fixed /usr/include End of search list. GNU C17 (GCC) version 9.0.1 20190223 (experimental) (x86_64-pc-linux-gnu) compiled by GNU C version 9.0.1 20190223 (experimental), GMP version 6.1 .2, MPFR version 3.1.6-p2, MPC version 1.1.0, isl version isl-0.16.1-GMP GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: f1cd29d4369196367e92853cfa6243b0 during RTL pass: ira bug507.c: In function ‘c’: bug507.c:6:1: internal compiler error: in df_reg_chain_verify_unmarked, at df-sc an.c:3995 6 | } | ^ 0x61ca63 df_reg_chain_verify_unmarked ../../trunk/gcc/df-scan.c:3995 Everything is ok at -O3, so it looks machine type specific.
[Bug target/88469] [7/8 regression] AAPCS/AAPCS64 - Struct with 64-bit bitfield (128-bit on AArch64) may be passed in wrong registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469 --- Comment #12 from Stefan Ring --- Unfortunately my armv5 device has died in the meantime, so I cannot verify my original use case. The behavior is indeed different on armv7. It does not trap, even for the original misaligned code. And contrary to x86, where the alignment check flag can be changed by user space, this is a privileged operation on arm, so I cannot even selectively enable it.
[Bug tree-optimization/89479] __restrict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89479 --- Comment #3 from Marc Glisse --- Hmm indeed they are different (it would have been clearer to omit const in the initial testcase). I couldn't find an obvious duplicate in bug 49774.
[Bug target/89271] [9 Regression] gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271 Alan Modra changed: What|Removed |Added Attachment #45760|0 |1 is obsolete|| --- Comment #13 from Alan Modra --- Created attachment 45808 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45808=edit Current set of patches
