[Bug ipa/89711] New: ICE in insert_vi_for_tree, at tree-ssa-structalias.c:2832
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89711
Bug ID: 89711
Summary: ICE in insert_vi_for_tree, at
tree-ssa-structalias.c:2832
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
gcc-9.0.0-alpha20190310 snapshot (r269561) ICEs when compiling the following
testcase at any optimization level and w/ -fipa-pta -flto (note: w/o -c):
__attribute__ ((target_clones ("avx", "default"))) void
xd (void)
{
}
__attribute__ ((target_clones ("avx", "default"))) void
tx (void)
{
}
int
main (void)
{
return 0;
}
% x86_64-pc-linux-gnu-gcc-9.0.0-alpha20190310 -O1 -fipa-pta -flto jrbgpkcn.c
during IPA pass: pta
lto1: internal compiler error: in insert_vi_for_tree, at
tree-ssa-structalias.c:2832
0xe371aa insert_vi_for_tree
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190310/work/gcc-9-20190310/gcc/tree-ssa-structalias.c:2832
0xe4456d create_function_info_for
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190310/work/gcc-9-20190310/gcc/tree-ssa-structalias.c:5817
0xe4456d ipa_pta_execute
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190310/work/gcc-9-20190310/gcc/tree-ssa-structalias.c:7970
0xe4456d execute
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190310/work/gcc-9-20190310/gcc/tree-ssa-structalias.c:8311
[Bug tree-optimization/89710] New: ICE in dyn_cast(gimple*) / should_duplicate_loop_header_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89710
Bug ID: 89710
Summary: ICE in dyn_cast(gimple*) /
should_duplicate_loop_header_p
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: ---
Another __attribute__((returns_twice)) issue.
gcc-9.0.0-alpha20190310 snapshot (r269561), 8.3, 7.3, 6.3, 5.4, 4.9.4 all ICE
when compiling the following testcase at -O1 (-O2, -O3, -Ofast):
void
gm (int *);
__attribute__ ((returns_twice)) void
jg (void)
{
}
void
eb (void)
{
int r6 = 0;
if (r6 != 0)
gm ();
}
void
gm (int *r6)
{
jg ();
for (;;)
{
eb ();
*r6 = 0;
}
}
% gcc-9.0.0-alpha20190310 -O1 -c ywwoc56m.c
during GIMPLE pass: ch
ywwoc56m.c: In function 'gm':
ywwoc56m.c:19:1: internal compiler error: Segmentation fault
19 | gm (int *r6)
| ^~
0xd65daf crash_signal
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190310/work/gcc-9-20190310/gcc/toplev.c:326
0xe96cb8 gcond* dyn_cast(gimple*)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190310/work/gcc-9-20190310/gcc/is-a.h:224
0xe96cb8 should_duplicate_loop_header_p
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190310/work/gcc-9-20190310/gcc/tree-ssa-loop-ch.c:103
0xe96cb8 copy_headers
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190310/work/gcc-9-20190310/gcc/tree-ssa-loop-ch.c:395
0xe96cb8 copy_headers
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190310/work/gcc-9-20190310/gcc/tree-ssa-loop-ch.c:350
0xe976d1 execute
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190310/work/gcc-9-20190310/gcc/tree-ssa-loop-ch.c:533
[Bug tree-optimization/84396] missing -Wstringop-truncation with non-nul assignment to destination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84396 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-03-14 Ever confirmed|0 |1 Known to fail||8.3.0, 9.0 --- Comment #1 from Martin Sebor --- Confirming with GCC 9.
[Bug tree-optimization/89688] [9 Regression] -Wstringop-overflow confused by const 2D array of char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89688 Martin Sebor changed: What|Removed |Added Keywords||patch See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=86708 Depends on|86708 | --- Comment #4 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00677.html Turns out pr86708 is not quite the same. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86708 [Bug 86708] strlen of an empty aggregate element or member string not folded
[Bug c++/80604] internal compiler error: Internal compiler error in tsubst_decl, at cp/pt.c:11749
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80604 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.4 --- Comment #1 from Paolo Carlini --- Fixed in 7.4.0.
[Bug c++/86521] [8/9 Regression] GCC 8 selects incorrect overload of ref-qualified conversion operator template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86521 --- Comment #8 from Jason Merrill --- Author: jason Date: Wed Mar 13 23:34:51 2019 New Revision: 269667 URL: https://gcc.gnu.org/viewcvs?rev=269667=gcc=rev Log: PR c++/86521 - C++17 copy elision in initialization by constructor. This is an overlooked case in C++17 mandatory copy elision: We want overload resolution to reflect that initializing an object from a prvalue does not involve a copy or move constructor even when [over.match.ctor] says that only constructors are candidates. Here I implement that by looking through the copy/move constructor in joust. * call.c (joust_maybe_elide_copy): New. (joust): Call it. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/g++.dg/cpp0x/overload-conv-3.C trunk/gcc/testsuite/g++.dg/overload/conv-op2.C
[Bug tree-optimization/89546] [8/9 Regression] Suspected arm flint miscompilation starting with r255510
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89546 --- Comment #8 from Martin Jambor --- Created attachment 45964 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45964=edit x86_64 testcase It took me four or five evenings and is quite fragile, but finally I have an x86_64-linux testcase that triggers the miscompilation (so this really should be P1). The correct fix is the one from my previous comment, I'll prepare a proper patch tomorrow.
[Bug middle-end/88588] ICE in make_decl_rtl, at varasm.c:1329
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88588 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-03-13 CC||jakub at gcc dot gnu.org Known to work||9.0 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 Known to fail|9.0 | --- Comment #4 from Jakub Jelinek --- Fixed on the trunk (so far).
[Bug target/85860] [8/9 Regression] ICE: in lra_split_hard_reg_for, at lra-assigns.c:1810: unable to find a register to spill with -flive-range-shrinkage -mbmi2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85860 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Known to work||8.3.1, 9.0 Resolution|--- |FIXED Known to fail|9.0 | --- Comment #8 from Jakub Jelinek --- Fixed.
[Bug c++/89709] [9 Regression] ICE with constexpr and "-O"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89709 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-03-13 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/89709] [9 Regression] ICE with constexpr and "-O"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89709 --- Comment #1 from Jakub Jelinek --- Started with r267272.
[Bug c++/89709] [9 Regression] ICE with constexpr and "-O"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89709 Volker Reichelt changed: What|Removed |Added Target Milestone|--- |9.0
[Bug c++/89709] New: [9 Regression] ICE with constexpr and "-O"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89709
Bug ID: 89709
Summary: [9 Regression] ICE with constexpr and "-O"
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
Target Milestone: ---
The following valid code snippet (compiled with "-O") triggers an ICE on trunk:
=
struct A
{
int i;
};
A a;
constexpr int* foo()
{
return
}
bool bar()
{
return foo() ==
}
=
bug.cc: In function 'bool bar()':
bug.cc:15:22: internal compiler error: in operand_equal_p, at fold-const.c:2962
15 | return foo() ==
| ^
0x6e8344 operand_equal_p(tree_node const*, tree_node const*, unsigned int)
../../gcc/gcc/fold-const.c:2962
0x141f84d generic_simplify_EQ_EXPR
/tmp/gccbuild/src-9/build/gcc/generic-match.c:41813
0x144dc1d generic_simplify(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/tmp/gccbuild/src-9/build/gcc/generic-match.c:52806
0xc4e885 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/gcc/fold-const.c:9378
0xc56c99 fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/gcc/fold-const.c:12350
0x8c112a cp_fold
../../gcc/gcc/cp/cp-gimplify.c:2448
0x8c30ec cp_fold_maybe_rvalue(tree_node*, bool)
../../gcc/gcc/cp/cp-gimplify.c:2126
0xa29908 maybe_warn_about_returning_address_of_local
../../gcc/gcc/cp/typeck.c:9183
0xa3f9c6 check_return_expr(tree_node*, bool*)
../../gcc/gcc/cp/typeck.c:9751
0x9f955f finish_return_stmt(tree_node*)
../../gcc/gcc/cp/semantics.c:895
0x979f77 cp_parser_jump_statement
../../gcc/gcc/cp/parser.c:12848
0x979f77 cp_parser_statement
../../gcc/gcc/cp/parser.c:11120
0x97a678 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11586
0x97a758 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:11540
0x992c95 cp_parser_function_body
../../gcc/gcc/cp/parser.c:22521
0x992c95 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:22558
0x99351b cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:27621
0x994269 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:27537
0x994269 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:20196
0x976f62 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13470
Please submit a full bug report, [etc.]
The regression was introduced between 2018-12-14 and 2019-01-12.
[Bug fortran/67740] Wrong association status of allocatable character pointer in derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67740 --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #2) > The dump-tree looks funny: it appears that in the last test > > print *, "Associated contents?", associated(p1%string, p2%string) > > the association is already evaluated at compile time to .false. I do not understand the following code in trans-intrinsic.c, which may be part of the underlying cause: 8426 nonzero_charlen = NULL_TREE; 8427 if (arg1->expr->ts.type == BT_CHARACTER) 8428nonzero_charlen = fold_build2_loc (input_location, NE_EXPR, 8429 logical_type_node, 8430 arg1->expr->ts.u.cl->backend_decl, 8431 build_zero_cst 8432 (TREE_TYPE (arg1->expr->ts.u.cl->backend_decl))); and 8500 /* If target is present zero character length pointers cannot 8501 be associated. */ 8502 if (nonzero_charlen != NULL_TREE) 8503se->expr = fold_build2_loc (input_location, TRUTH_AND_EXPR, 8504logical_type_node, 8505se->expr, nonzero_charlen);
[Bug c++/89708] printf and std::byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89708 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- Your typedef is not equivalent. std::byte is not implicitly convertible to unsigned char.
[Bug c++/89700] Warn if move constructor is not generated and not deleted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89700
--- Comment #3 from Jonathan Wakely ---
You're mistaken.
struct X
{
std::string str = "not empty";
X() = default;
X(const X&) = default;
};
This type does not have a move constructor. Copying an rvalue will perform a
copy (not a move):
X x1;
X x2 = std::move(x1); // calls copy constructor
But it does not have a deleted move constructor. It has no move constructor.
That's different. If it had a deleted move constructor then the initialization
of x2 above would fail to compile.
[Bug fortran/87673] [7/8 Regression] Errors caused by using function for character length in allocate with typespec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87673 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Thomas Koenig --- Fixed on all open branches, closing.
[Bug fortran/87673] [7/8 Regression] Errors caused by using function for character length in allocate with typespec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87673 --- Comment #13 from Thomas Koenig --- Author: tkoenig Date: Wed Mar 13 22:15:33 2019 New Revision: 269666 URL: https://gcc.gnu.org/viewcvs?rev=269666=gcc=rev Log: 2019-03-13 Thomas Koenig PR fortran/87673 Backport from trunk * match.c (gfc_match_type_spec): Remove call to gfc_resolve_expr for character length. 2019-03-13 Thomas Koenig PR fortran/87673 Backport from trunk * gfortran.dg/charlen_17.f90: New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/charlen_17.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/match.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug fortran/87673] [7/8 Regression] Errors caused by using function for character length in allocate with typespec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87673 --- Comment #12 from Thomas Koenig --- Author: tkoenig Date: Wed Mar 13 22:05:59 2019 New Revision: 269665 URL: https://gcc.gnu.org/viewcvs?rev=269665=gcc=rev Log: 2019-03-13 Thomas Koenig PR fortran/87673 Backport from trunk * match.c (gfc_match_type_spec): Remove call to gfc_resolve_expr for character length. 2019-03-13 Thomas Koenig PR fortran/87673 Backport from trunk * gfortran.dg/charlen_17.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/charlen_17.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/match.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/87045] pointer to array of character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87045 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from anlauf at gcc dot gnu.org --- Fixed on trunk.
[Bug fortran/87045] pointer to array of character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87045 --- Comment #4 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Wed Mar 13 21:33:27 2019 New Revision: 269664 URL: https://gcc.gnu.org/viewcvs?rev=269664=gcc=rev Log: 2019-03-13 Harald Anlauf PR fortran/87045 * trans-expr.c (gfc_trans_pointer_assignment): Move check for same string length so that we do not get false errors for deferred length. PR fortran/87045 * gfortran.dg/pr87045.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr87045.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug c++/68138] "operator== is ambiguous" when comparing a tuple containing values with one containing refs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68138
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment #3 from Harald van Dijk ---
Here's a reduced standalone testcase, no libstdc++.
struct Empty { bool operator==(Empty); };
class tuple_impl : Empty {};
class tuple : tuple_impl, Empty {};
bool operator==(tuple, tuple);
int main() { tuple a, b; a == b; }
tuple derives from Empty twice and would inherit its operator==(Empty) member
function, except any attempt to use it would be ambiguous. GCC and Intel reject
this, clang and MSVC accept it using the global operator==(tuple, tuple). If
tuple only inherits from Empty once, then all compilers are in agreement that
operator==(tuple, tuple) is a better match than the operator==(Empty) member
function.
[Bug rtl-optimization/86438] [8 Regression] wrong code at -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86438 John David Anglin changed: What|Removed |Added Last reconfirmed|2018-07-09 00:00:00 |2019-3-13 CC||danglin at gcc dot gnu.org --- Comment #11 from John David Anglin --- Fails on hppa64-hp-hpux11.11 with error shown in comment 9.
[Bug debug/89498] [8 Regression] ICE in AT_loc_list, at dwarf2out.c:4871
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89498 Jakub Jelinek changed: What|Removed |Added Summary|[8/9 Regression] ICE in |[8 Regression] ICE in |AT_loc_list, at |AT_loc_list, at |dwarf2out.c:4871|dwarf2out.c:4871 --- Comment #6 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug d/88990] ICE in get_symbol_decl, at d/decl.cc:1097
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88990 --- Comment #1 from Iain Buclaw --- Doesn't look like invalid code, but 'extern' is propagated erroneously to all declarations inside the block, even paraneters, which is why the ICE occurs.
[Bug c++/89705] [7/8/9 Regression] ICE in convert_like_real, at cp/call.c:7334
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89705
--- Comment #4 from Marek Polacek ---
Same with int:
struct W { operator const int(); };
int&& i = W();
[Bug target/85860] [8/9 Regression] ICE: in lra_split_hard_reg_for, at lra-assigns.c:1810: unable to find a register to spill with -flive-range-shrinkage -mbmi2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85860 --- Comment #7 from Vladimir Makarov --- Author: vmakarov Date: Wed Mar 13 20:44:50 2019 New Revision: 269663 URL: https://gcc.gnu.org/viewcvs?rev=269663=gcc=rev Log: 2019-03-13 Vladimir Makarov PR target/85860 * lra-constraints.c (inherit_in_ebb): Update potential_reload_hard_regs along with live_hard_regs. 2019-03-13 Vladimir Makarov PR target/85860 * gcc.target/i386/pr85860.c: New. Added: branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr85860.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/lra-constraints.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug c++/79651] ICE on invalid c++ code in lambda_expr_this_capture in lambda.c:718
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79651 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Paolo Carlini --- AFAICS this got fixed for the released 7.1.0 and the fix even backported to 6.4.0. Please double check and, in case, reopen.
[Bug target/85860] [8/9 Regression] ICE: in lra_split_hard_reg_for, at lra-assigns.c:1810: unable to find a register to spill with -flive-range-shrinkage -mbmi2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85860 --- Comment #6 from Vladimir Makarov --- Author: vmakarov Date: Wed Mar 13 20:35:18 2019 New Revision: 269662 URL: https://gcc.gnu.org/viewcvs?rev=269662=gcc=rev Log: 2019-03-13 Vladimir Makarov PR target/85860 * lra-constraints.c (inherit_in_ebb): Update potential_reload_hard_regs along with live_hard_regs. 2019-03-13 Vladimir Makarov PR target/85860 * gcc.target/i386/pr85860.c: New. Added: trunk/gcc/testsuite/gcc.target/i386/pr85860.c Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c trunk/gcc/testsuite/ChangeLog
[Bug c++/89708] New: printf and std::byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89708
Bug ID: 89708
Summary: printf and std::byte
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
#include
#include
typedef unsigned char byte_t;
void test (byte_t a, std::byte b)
{
printf("%u", a); // OK
printf("%hhu", a); // OK
printf("%u", b); // GCC warns, Clang warns and recommends %hhu
printf("%hhu", b); // GCC warns
}
What is wrong with this code? I think we shouldn't see any warnings for
std::byte.. or?
[Bug debug/89498] [8/9 Regression] ICE in AT_loc_list, at dwarf2out.c:4871
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89498 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Wed Mar 13 20:22:15 2019 New Revision: 269661 URL: https://gcc.gnu.org/viewcvs?rev=269661=gcc=rev Log: PR debug/89498 * dwarf2out.c (size_of_die): For dw_val_class_view_list always use DWARF_OFFSET_SIZE. (value_format): For dw_val_class_view_list never use DW_FORM_loclistx. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug fortran/89707] New: [F03] PDT with procedure pointer component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89707 Bug ID: 89707 Summary: [F03] PDT with procedure pointer component Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: janus at gcc dot gnu.org Target Milestone: --- Follow-up to PR 89601 (essentially the same ICE, but this time on valid code): program pdt_with_ppc type :: q (k) integer, kind :: k = 4 procedure (real(kind=k)), pointer, nopass :: p end type type (q) :: x end Current trunk ICEs like this: f951: internal compiler error: Segmentation fault 0xc9c0af crash_signal /home/janus/github/gcc/trunk/gcc/toplev.c:326 0x6994f3 resolve_component /home/janus/github/gcc/trunk/gcc/fortran/resolve.c:13965 0x699e8a resolve_fl_derived0 /home/janus/github/gcc/trunk/gcc/fortran/resolve.c:14315 0x69a4f7 resolve_fl_derived0 /home/janus/github/gcc/trunk/gcc/fortran/resolve.c:14402 0x69a4f7 resolve_fl_derived /home/janus/github/gcc/trunk/gcc/fortran/resolve.c:1 0x6968ef resolve_symbol /home/janus/github/gcc/trunk/gcc/fortran/resolve.c:14818 0x6b9822 do_traverse_symtree /home/janus/github/gcc/trunk/gcc/fortran/symbol.c:4157 0x690d54 resolve_types /home/janus/github/gcc/trunk/gcc/fortran/resolve.c:16730 0x695ddc gfc_resolve(gfc_namespace*) /home/janus/github/gcc/trunk/gcc/fortran/resolve.c:16844 0x683347 resolve_all_program_units /home/janus/github/gcc/trunk/gcc/fortran/parse.c:6073 0x683347 gfc_parse_file() /home/janus/github/gcc/trunk/gcc/fortran/parse.c:6323 0x6cf1ff gfc_be_parse_file /home/janus/github/gcc/trunk/gcc/fortran/f95-lang.c:204 Apparently c->tb is NULL.
[Bug c++/89660] [9 Regression] Rejects-valid error with -Wredundant-move starting with r269427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89660 Marek Polacek changed: What|Removed |Added Keywords||rejects-valid Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- Fixed.
[Bug c++/89660] [9 Regression] Rejects-valid error with -Wredundant-move starting with r269427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89660 --- Comment #3 from Marek Polacek --- Author: mpolacek Date: Wed Mar 13 20:04:33 2019 New Revision: 269660 URL: https://gcc.gnu.org/viewcvs?rev=269660=gcc=rev Log: PR c++/89660 - bogus error with -Wredundant-move. * typeck.c (maybe_warn_pessimizing_move): Only accept (T &) as the std::move's argument. Don't call convert_for_initialization when warn_redundant_move isn't on. * g++.dg/cpp0x/Wredundant-move8.C: New test. * g++.dg/cpp0x/Wredundant-move9.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/Wredundant-move8.C trunk/gcc/testsuite/g++.dg/cpp0x/Wredundant-move9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c++/89686] Lambda pack capture with pack on both sides
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89686 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- Fixed.
[Bug debug/24943] [hppa64] Bad dwarf output using non-preserved base register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24943
--- Comment #11 from dave.anglin at bell dot net ---
On 2019-03-13 4:09 a.m., rguenth at gcc dot gnu.org wrote:
> So it's a target issue, not a debug one. Of course we could avoid generating
> wrong-debug by generating none whenever the argument pointer is involved?
It appears to me that this is likely a generic target problem:
rtx
default_internal_arg_pointer (void)
{
/* If the reg that the virtual arg pointer will be translated into is
not a fixed reg or is the stack pointer, make a copy of the virtual
arg pointer, and address parms via the copy. The frame pointer is
considered fixed even though it is not marked as such. */
if ((ARG_POINTER_REGNUM == STACK_POINTER_REGNUM
|| ! (fixed_regs[ARG_POINTER_REGNUM]
|| ARG_POINTER_REGNUM == FRAME_POINTER_REGNUM)))
return copy_to_reg (virtual_incoming_args_rtx);
else
return virtual_incoming_args_rtx;
}
static rtx
pa_internal_arg_pointer (void)
{
/* The argument pointer and the hard frame pointer are the same in
the 32-bit runtime, so we don't need a copy. */
if (TARGET_64BIT)
return copy_to_reg (virtual_incoming_args_rtx);
else
return virtual_incoming_args_rtx;
}
Both routines use copy_to_reg.
[Bug c++/89686] Lambda pack capture with pack on both sides
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89686 --- Comment #3 from Marek Polacek --- Author: mpolacek Date: Wed Mar 13 19:58:20 2019 New Revision: 269659 URL: https://gcc.gnu.org/viewcvs?rev=269659=gcc=rev Log: PR c++/89686 - mixing init-capture and simple-capture in lambda. * parser.c (cp_parser_lambda_introducer): Give error when combining init-capture and simple-capture. * g++.dg/cpp2a/lambda-pack-init2.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp2a/lambda-pack-init2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug libfortran/89696] A potential bug with read() when parsing number from string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89696 --- Comment #11 from Khang H. Nguyen --- That is cool with me if you think it that way. But I don't think you would be very happy parsing " 123 4" and still get the same result as "1234". Or if you were to give it a blank string and get 0 where "0" would also give 0. If your database application depended on it for validating input. That could produce unintended results and impact security, wouldn't you think so? Nonetheless, thank you for your time.
[Bug tree-optimization/89706] -Wstringop-truncation strncpy message is confusing and has psuedo-false-positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89706
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-03-13
CC||msebor at gcc dot gnu.org
Component|c++ |tree-optimization
Blocks||88781
Ever confirmed|0 |1
--- Comment #1 from Martin Sebor ---
The checker looks for a 'buf[N] = '\0';' statement immediately after the call
to strncpy and when it finds one it suppresses the warning. But the logic is
less than perfect and doesn't handle this case where it sees:
buf.2_7 = buf;
__builtin_strncpy (buf.2_7, "Progress", sz_6);
buf.3_8 = buf;
_9 = buf.3_8 + sz_6;
*_9 = 0;
It doesn't see that the _9 on the last line is related to buf.2_7 (the first
argument to strncpy).
In general, the warning (clearly naively) assumes strncpy and strncat are used
in meaningful but possibly incorrect ways. Especially in "unusual" calls to
the functions like in the test case in comment #0 (but in some others as well)
the suppression logic may be ineffective and lead to false positives. I'm
working on improving this but I doubt the improvements will make it into the
first release of GCC 9.
In the meantime, the false positive in this case can be suppressed by replacing
strncpy with stpncpy like so:
inline void func(const char* s) {
size_t sz = strlen(s);
if (sz > len - 1)
sz = len - 1;
*stpncpy(buf, s, sz) = '\0';
}
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781
[Bug 88781] [meta-bug] bogus/missing -Wstringop-truncation warnings
[Bug fortran/89601] [8/9 Regression] [PDT] ICE: Segmentation fault (in resolve_component)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89601 --- Comment #5 from janus at gcc dot gnu.org --- Author: janus Date: Wed Mar 13 19:52:23 2019 New Revision: 269658 URL: https://gcc.gnu.org/viewcvs?rev=269658=gcc=rev Log: fix PR 89601 2019-03-13 Janus Weil PR fortran/89601 * decl.c (gfc_match_formal_arglist): Reject empty type parameter lists. (gfc_match_derived_decl): Mark as PDT only if type parameter list was matched successfully. 2019-03-13 Janus Weil PR fortran/89601 * gfortran.dg/pdt_16.f03: Modified to avoid follow-up errors. * gfortran.dg/pdt_30.f90: New test case. Added: trunk/gcc/testsuite/gfortran.dg/pdt_30.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pdt_16.f03
[Bug libfortran/89696] A potential bug with read() when parsing number from string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89696 --- Comment #10 from Steve Kargl --- On Wed, Mar 13, 2019 at 07:36:10PM +, kevin at fai dot host wrote: > > --- Comment #9 from Khang H. Nguyen --- > No, no, you got me wrong, it is not a tutorial. You got it wrong. > I just see so much insecure with the statement read, of which I > think it more like a procedure. That is why I am trying to report > the bug. What you have shown is a fundamental lack of knowledge on how the Fortran language works. It isn't a bug. Both Thomas's response and mine are tutorial in nature.
[Bug libfortran/89696] A potential bug with read() when parsing number from string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89696 --- Comment #9 from Khang H. Nguyen --- No, no, you got me wrong, it is not a tutorial. You got it wrong. I just see so much insecure with the statement read, of which I think it more like a procedure. That is why I am trying to report the bug. For the example below. You telling the compiler that within this 100 character, there is a set of number. Fair enough, but this string below is not a valid integer and yet it still parses it because it disregarded any spaces, doesn't matter where in the string. I am not being disrespectful or want to advertise my product. I just intended to report a bug. Nonetheless, I wrote this. https://github.com/kevinhng86/faiNumber-Fortran. Now if you compare that to read() and tell me if read() was badly designed or not. Sorry if I offended you, I just want the code to be more secure. Fortran is a good language because it has bit extraction by position. That is a great feature. Nonetheless, built-in procedures and built-in methods should be secure. Because after all, those are depended on by everyone. program test1 implicit none character(len=100) :: str integer :: b str = " 12341234 1" read(str, '(I100)') b print *, b end program test1
[Bug libfortran/89696] A potential bug with read() when parsing number from string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89696 --- Comment #8 from Steve Kargl --- On Wed, Mar 13, 2019 at 07:17:42PM +, kevin at fai dot host wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89696 > > --- Comment #6 from Khang H. Nguyen --- > Sorry, if I am wasting your time. bugzilla isn't meant for Fortran tutorials. This is my last response. > > If you use formatting. For example, in a case like this below, > it will not give a correct value, as now leading spaces will > be disregarded but no error is thrown. This code below will > give 124 > > program test1 > implicit none > character(len=100) :: str > integer :: b > str = " 1245 ab " > read(str, '(I4)') b > print *, b > end program test1 > The program is giving the correct answer for the string given. I4 means read the 1st 4 characters. Those characters are ' 124'. The rest of the string is ignored.
[Bug c++/89705] [7/8/9 Regression] ICE in convert_like_real, at cp/call.c:7334
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89705 --- Comment #3 from Jakub Jelinek --- Started to be rejected in r209521 with: error: invalid initialization of reference of type ‘E&&’ from expression of type ‘S’ (before accepted). Started to ICE with r210436.
[Bug libfortran/89696] A potential bug with read() when parsing number from string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89696 --- Comment #7 from Steve Kargl --- On Wed, Mar 13, 2019 at 07:09:19PM +, kevin at fai dot host wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89696 > > --- Comment #5 from Khang H. Nguyen --- > > program foo > > integer i > > read(*,*) i > > read(*,'(I4)') i > > end program foo > > > > % gfcx -o z a.f90 > > % ./z > > % ./z > > 12 b > > 12 b > > At line 4 of file a.f90 (unit = 5, file = 'stdin') > > Fortran runtime error: Bad value during integer read > > > > The first '12 b' is read a '12'. The second read says the 4 characters > > are an integer, so '12 b' generates an error. > > For that scenario, you absolutely need to know the format of the string and > can't pass the string without knowing the format then? > In the first case, 'read(*,*)', the compiler will do the right thing. In the second case, 'read(*,'(I4)'), the programmer is telling the compiler that when the read occurs there are 4 characters and those four characters are an integer. You could write '12 ' or ' 12' or ' 12 '. The blanks will be stripped. If you write '12 b', 'b' isn't a digit that can be converted to an integer.
[Bug libfortran/89696] A potential bug with read() when parsing number from string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89696 --- Comment #6 from Khang H. Nguyen --- Sorry, if I am wasting your time. I just have an addition to add to the above. If you use formatting. For example, in a case like this below, it will not give a correct value, as now leading spaces will be disregarded but no error is thrown. This code below will give 124 program test1 implicit none character(len=100) :: str integer :: b str = " 1245 ab " read(str, '(I4)') b print *, b end program test1
[Bug libfortran/89696] A potential bug with read() when parsing number from string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89696 --- Comment #5 from Khang H. Nguyen --- > program foo > integer i > read(*,*) i > read(*,'(I4)') i > end program foo > > % gfcx -o z a.f90 > % ./z > % ./z > 12 b > 12 b > At line 4 of file a.f90 (unit = 5, file = 'stdin') > Fortran runtime error: Bad value during integer read > > The first '12 b' is read a '12'. The second read says the 4 characters > are an integer, so '12 b' generates an error. For that scenario, you absolutely need to know the format of the string and can't pass the string without knowing the format then?
[Bug tree-optimization/89703] [8/9 Regression] ICE in compare_values_warnv, at tree-vrp.c:997
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89703 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 45963 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45963=edit gcc9-pr89703.patch Untested fix.
[Bug c++/89706] New: -Wstringop-truncation strncpy message is confusing and has psuedo-false-positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89706
Bug ID: 89706
Summary: -Wstringop-truncation strncpy message is confusing and
has psuedo-false-positives
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
https://godbolt.org/z/BAeXQB
"strncpy output truncated copying between 0 and 8 bytes from a string of length
8" doesn't make it obvious what the problem with the is or how to solve it.
Once I decoded it[1], I realized it was warning about something the code was
already set up to handle correctly. Specifically, the last line of func
re-establishes the nul byte termination regardless of how many bytes are
copied. (Yes I know that this code is a dumb use of strncpy and we should
probably just be using memcpy, but that isn't what this warning is warning
about.)
[1] I was only able to decode it by tweaking the code until I got the "output
truncated before terminating nul copying 8 bytes from a string of the same
length" form of the warning. This happens if you comment out the if-block in
this code.
#include
extern size_t len;
extern char *buf;
inline void func(const char* s) {
size_t sz = strlen(s);
if (sz > len - 1)
sz = len - 1;
strncpy(buf, s, sz);
buf[sz] = '\0';
}
void test() {
const char* p = "Progress";
func(p);
}
> g++ -Wstringop-truncation -O2
In function 'void func(const char*)',
inlined from 'void test()' at :16:9:
:10:12: warning: 'char* strncpy(char*, const char*, size_t)' output
truncated copying between 0 and 8 bytes from a string of length 8
[-Wstringop-truncation]
10 | strncpy(buf, s, sz);
| ~~~^~~~
[Bug ipa/85656] gcc.dg/ipa/ipa-icf-38.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85656 --- Comment #12 from John David Anglin --- Created attachment 45962 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45962=edit Tree dump For FAIL: gcc.dg/ipa/ipa-icf-38.c scan-ltrans-tree-dump-not optimized "Function bar" on hppa64-hp-hpux11.11.
[Bug tree-optimization/69807] FAIL: gcc.dg/graphite/scop-19.c scan-tree-dump-times graphite "number of SCoPs: 0" 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69807 --- Comment #2 from John David Anglin --- Created attachment 45961 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45961=edit .graphite file gcc-9.
[Bug c++/88979] [C++20] P0634R3 not working for constructor parameter types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88979 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Marek Polacek --- Fixed.
[Bug c++/88979] [C++20] P0634R3 not working for constructor parameter types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88979 --- Comment #5 from Marek Polacek --- Author: mpolacek Date: Wed Mar 13 18:38:45 2019 New Revision: 269656 URL: https://gcc.gnu.org/viewcvs?rev=269656=gcc=rev Log: PR c++/88979 - further P0634 fix for constructors. * parser.c (cp_parser_decl_specifier_seq): Pass flags to cp_parser_constructor_declarator_p. (cp_parser_direct_declarator): Allow missing typename for constructor parameters. (cp_parser_constructor_declarator_p): Add FLAGS parameter. Pass it to cp_parser_type_specifier. * g++.dg/cpp2a/typename15.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp2a/typename15.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug libfortran/89696] A potential bug with read() when parsing number from string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89696 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #4 from kargl at gcc dot gnu.org --- (In reply to Khang H. Nguyen from comment #3) > Sorry, I just have one more quick question. > > Bug 1: > Nonetheless, for read(), I was just wondering, if you read from a list input > then it should be like that. > > However, if it is just a raw string and it acted like that, then how do you > tell if a string is an invalid integer string? Formatted input will tell you that you have a problem. % cat a.f90 program foo integer i read(*,*) i read(*,'(I4)') i end program foo % gfcx -o z a.f90 % ./z % ./z 12 b 12 b At line 4 of file a.f90 (unit = 5, file = 'stdin') Fortran runtime error: Bad value during integer read The first '12 b' is read a '12'. The second read says the 4 characters are an integer, so '12 b' generates an error. > Do you have to build a check for that then? Shouldn't read() be able to > detect that because if you build a check on top of that, you would have to > go through all the character one and then read would then goes through all > the characters again. > > Bug 2: > As you said that it is not a bug. I just suggested that for -2147483648, it > is still assignable with range check on, you just have to assign -2147483647 > - 1 Yes, you can assign -2147483647 - 1. As Thomas suggested, the first minus sign is a unary operator and the second minus sign is a binary operator. So, there are two operators in the expression.
[Bug preprocessor/48957] GCC's handling of include-fixed does not work well with --sysroot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48957 --- Comment #4 from joseph at codesourcery dot com --- Well, I suppose you could have a new option to say what set of fixed headers to use, in the case where your sysroot is not based on the one used when building GCC.
[Bug c++/89700] Warn if move constructor is not generated and not deleted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89700 Igor Klevanets changed: What|Removed |Added CC||cerevra at yandex dot ru --- Comment #2 from Igor Klevanets --- (In reply to Jonathan Wakely from comment #1) > A class might intentionally want to copy so its members are never left in a > moved-from state (In reply to Jonathan Wakely from comment #1) > They can't delete the move constructor (that makes the class non-movable) If I am not mistaken, these concepts conflict with each other. Could you describe example for such class?
[Bug target/42689] bad formatting of specs diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42689
Joseph S. Myers changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #4 from Joseph S. Myers ---
This issue is about %e/%n diagnostics in specs, not about diagnostics in .opt
files.
By inspection, there are still some such diagnostics (e.g. in
config/pa/pa-hpux11.h) that are split into two such diagnostics in the middle
of a sentence, which is problematic for translations. Also, there are still
the trailing newlines, though those are currently harmless (removed both by
gcc.c and by exgettext). Also, such a diagnostic split in the source file with
backslash-newline doesn't get extracted for translation at all;
config/freebsd-spec.h has
%{pthread: %eThe -pthread option is only supported on FreeBSD when gcc \
is built with the --enable-threads configure-time option.}
which is missing from gcc.pot.
[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883 Bug 40883 depends on bug 42689, which changed state. Bug 42689 Summary: bad formatting of specs diagnostics https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42689 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug c++/89705] [7/8/9 Regression] ICE in convert_like_real, at cp/call.c:7334
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89705 --- Comment #2 from Marek Polacek --- Started with r210436.
[Bug c++/89705] [7/8/9 Regression] ICE in convert_like_real, at cp/call.c:7334
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89705 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-03-13 CC||mpolacek at gcc dot gnu.org Known to work||4.9.4 Target Milestone|--- |7.5 Summary|ICE in convert_like_real, |[7/8/9 Regression] ICE in |at cp/call.c:7334 |convert_like_real, at ||cp/call.c:7334 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c/89667] initializers for character string arrays (char *[]) appear to reside in protected storage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89667
--- Comment #2 from joseph at codesourcery dot com ---
Or if for some reason you need an array of pointers to writable strings,
you can use e.g. (char []) { "foo" }, a compound literal, as the
initializer for such a pointer, instead of a simple string constant.
[Bug tree-optimization/89703] [8/9 Regression] ICE in compare_values_warnv, at tree-vrp.c:997
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89703
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-03-13
CC||jakub at gcc dot gnu.org
Summary|[9 Regression] ICE in |[8/9 Regression] ICE in
|compare_values_warnv, at|compare_values_warnv, at
|tree-vrp.c:997 |tree-vrp.c:997
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
Started with r255790.
Another testcase that also ICEs since that revision:
typedef __SIZE_TYPE__ size_t;
extern void *memcpy (void *, const void *, size_t);
extern char *strlen (const char *);
extern char c[2];
void
foo (char **q)
{
memcpy (c, "a", 2);
q[0] = strlen (c);
}
[Bug libfortran/89696] A potential bug with read() when parsing number from string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89696 --- Comment #3 from Khang H. Nguyen --- Sorry, I just have one more quick question. Bug 1: Nonetheless, for read(), I was just wondering, if you read from a list input then it should be like that. However, if it is just a raw string and it acted like that, then how do you tell if a string is an invalid integer string? Do you have to build a check for that then? Shouldn't read() be able to detect that because if you build a check on top of that, you would have to go through all the character one and then read would then goes through all the characters again. Bug 2: As you said that it is not a bug. I just suggested that for -2147483648, it is still assignable with range check on, you just have to assign -2147483647 - 1
[Bug c/89573] -fexcess-precision=standard doesn't work for conversion to integer of multiplication
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89573 --- Comment #4 from joseph at codesourcery dot com --- On Mon, 11 Mar 2019, rguenth at gcc dot gnu.org wrote: > > I wouldn't expect such a cast to be generated on the result of the > > multiplication; I'd expect long double to be converted directly to int. > > There is, indeed, a test of that (see test_cast in > > gcc.target/i386/excess-precision-1.c). > > Exactly why? The multiplication result has excess precision here. > Do you say an extra rounding step to double precision cannot change > the conversion to integer result or do you say such extra rounding step > isn't allowed here? IMHO this is exactly the "issue" pointed out by > the testcase. The extra rounding step isn't allowed by the language semantics as I understand them. The result of the double multiplication is represented with the range and precision of long double and must be converted directly to int, not to double and then to int. > Note the frontend _does_ originally emit (int) (double) ((long double) log (p) > * (long double) inv_log_of_base) but the conversion to double is elided The front end should not be emitting such a conversion to double. An EXCESS_PRECISION_EXPR is not a conversion (and convert_for_assignment removes an EXCESS_PRECISION_EXPR very early, before converting to the desired type). > by convert_to_real in the code piece I qouted. The truncation to double should not be removed because it should fail the real_can_shorten_arithmetic test, as well as failing the !excess_precision_type (newtype) test (the former is testing whether removing such a truncation is valid in the sense of not affecting the result, the latter is testing whether the change of type for arithmetic would run into the back end not actually having proper arithmetic operations for the narrower type).
[Bug libfortran/89696] A potential bug with read() when parsing number from string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89696 --- Comment #2 from Khang H. Nguyen --- okay, thank you for the information, I did not know that.
[Bug other/89702] 03 issue with SIGALRM causes program to SEGV on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89702
--- Comment #3 from Karl Burgess ---
(In reply to Andrew Pinski from comment #2)
> >Solaris SunOS 5.10
>
> This might mean it is a kernel issue too.
> What does gdb show when it crashes?
> info registers
Program terminated with signal 11, Segmentation fault.
#0 isLegalUTF8 (length=1, source=0x812e40f 'A' ...)
at ConvertUTF.c:131
131 switch (length) {
(gdb) where
#0 isLegalUTF8 (length=1, source=0x812e40f 'A' ...)
at ConvertUTF.c:131
#1 ConvertUTF8toUTF16 (sourceStart=sourceStart@entry=0x8047c70,
sourceEnd=sourceEnd@entry=0x9961740 "\001",
targetStart=targetStart@entry=0x8047c6c,
targetEnd=targetEnd@entry=0xcb61748, flags=flags@entry=lenientConversion)
at ConvertUTF.c:169
#2 0x08051311 in ConvertData (size=, pData=0x8061740)
at main.c:32
#3 main (argc=, argv=) at main.c:87
(gdb) info registers
eax0x0 0
ecx0x9afb0e6162509030
edx0x812e40f135455759
ebx0x1 1
esp0x8047c2a0x8047c2a
ebp0x812e4100x812e410
esi0x -65536
edi0x41 65
eip0x8050ee80x8050ee8
eflags 0x297[ CF PF AF SF IF ]
cs 0x3b 59
ss 0x43 67
ds 0x43 67
es 0x43 67
fs 0x0 0
gs 0x1c3451
(gdb)
[Bug c++/89705] New: ICE in convert_like_real, at cp/call.c:7334
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89705
Bug ID: 89705
Summary: ICE in convert_like_real, at cp/call.c:7334
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Affects versions down to gcc-5 (gcc-5 with -std=c++14).
(afaict gcc-4.9 -std=c++14, clang7, icc19 accepts it).
Compiles without "const".
$ cat z1.cc
enum e { a };
struct s { operator const e(); };
e && b = s();
$ g++-9-20190310 -c z1.cc
z1.cc:3:12: internal compiler error: in convert_like_real, at cp/call.c:7334
3 | e && b = s();
|^
0x6357e2 convert_like_real
../../gcc/cp/call.c:7334
0x640ed3 initialize_reference(tree_node*, tree_node*, int, int)
../../gcc/cp/call.c:11480
0x6b76e7 grok_reference_init
../../gcc/cp/decl.c:5401
0x6b76e7 check_initializer
../../gcc/cp/decl.c:6412
0x6dff6c cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/cp/decl.c:7196
0x7a5d25 cp_parser_init_declarator
../../gcc/cp/parser.c:20468
0x786426 cp_parser_simple_declaration
../../gcc/cp/parser.c:13492
0x7adf44 cp_parser_declaration
../../gcc/cp/parser.c:13189
0x7ae70c cp_parser_translation_unit
../../gcc/cp/parser.c:4698
0x7ae70c c_parse_file()
../../gcc/cp/parser.c:41114
0x90a270 c_common_parse_file()
../../gcc/c-family/c-opts.c:1155
[Bug c/89704] New: [7/8/9 Regression] ICE in add_const_value_attribute, at dwarf2out.c:19685
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89704
Bug ID: 89704
Summary: [7/8/9 Regression] ICE in add_const_value_attribute,
at dwarf2out.c:19685
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started with gcc-6, compiles with gcc-5 :
$ cat z1.c
int f ()
{
L1: L2:;
static int i = (long) && L1 - (long) && L2;
static int j = (long) && L1 - (long) && L2;
return i;
}
$ gcc-9-20190310 -c z1.c -O2
$ gcc-9-20190310 -c z1.c -O0 -g
$
$ gcc-9-20190310 -c z1.c -O2 -g
z1.c:7:1: internal compiler error: in add_const_value_attribute, at
dwarf2out.c:19685
7 | }
| ^
0x83cd86 add_const_value_attribute
../../gcc/dwarf2out.c:19685
0x83cfd2 tree_add_const_value_attribute
../../gcc/dwarf2out.c:20393
0x83d7b5 optimize_location_into_implicit_ptr
../../gcc/dwarf2out.c:30105
0x83d7b5 resolve_addr
../../gcc/dwarf2out.c:30509
0x83d663 resolve_addr
../../gcc/dwarf2out.c:30591
0x83d663 resolve_addr
../../gcc/dwarf2out.c:30591
0x858e5f dwarf2out_finish
../../gcc/dwarf2out.c:31340
[Bug tree-optimization/89703] [9 Regression] ICE in compare_values_warnv, at tree-vrp.c:997
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89703 Andrew Pinski changed: What|Removed |Added Component|c |tree-optimization Target Milestone|--- |9.0
[Bug c/89703] New: [9 Regression] ICE in compare_values_warnv, at tree-vrp.c:997
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89703
Bug ID: 89703
Summary: [9 Regression] ICE in compare_values_warnv, at
tree-vrp.c:997
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started with gcc-9 (before 20180429), at -O2+ :
$ cat z1.c
typedef __SIZE_TYPE__ size_t;
extern char* strlen (const char*);
extern char* strnlen (const char*, size_t);
char** q;
void foo ()
{
extern char c[2];
q[0] = strlen (c);
q[1] = strnlen (c, 2);
}
$ gcc-9-20190310 -c z1.c -O1
$
$ gcc-9-20190310 -c z1.c -O2
during GIMPLE pass: vrp
z1.c: In function 'foo':
z1.c:5:6: internal compiler error: in compare_values_warnv, at tree-vrp.c:997
5 | void foo ()
| ^~~
0xcac6cf compare_values_warnv(tree_node*, tree_node*, bool*)
../../gcc/tree-vrp.c:996
0xd094be compare_range_with_value
../../gcc/vr-values.c:1651
0xd0e136
vr_values::vrp_evaluate_conditional_warnv_with_ops_using_ranges(tree_code,
tree_node*, tree_node*, bool*)
../../gcc/vr-values.c:2283
0xd0f814 vr_values::simplify_min_or_max_using_ranges(gimple_stmt_iterator*,
gimple*)
../../gcc/vr-values.c:3201
0xd133bd vr_values::simplify_stmt_using_ranges(gimple_stmt_iterator*)
../../gcc/vr-values.c:4259
0xbd9d86 substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
../../gcc/tree-ssa-propagate.c:1082
0x117e7f4 dom_walker::walk(basic_block_def*)
../../gcc/domwalk.c:353
0xbd9323 substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
../../gcc/tree-ssa-propagate.c:1194
0xcab87e vrp_prop::vrp_finalize(bool)
../../gcc/tree-vrp.c:6709
0xcb9114 execute_vrp
../../gcc/tree-vrp.c:6780
Configured with --enable-checking=yes :
$ gcc-9-20190310 -c z1.c -O2
z1.c: In function 'foo':
z1.c:5:6: error: type mismatch in binary expression
5 | void foo ()
| ^~~
char *
char *
size_t
_3 = MIN_EXPR <_2, 2>;
during GIMPLE pass: strlen
z1.c:5:6: internal compiler error: verify_gimple failed
0xc7b93f verify_gimple_in_cfg(function*, bool)
../../gcc/tree-cfg.c:5434
0xb37926 execute_function_todo
../../gcc/passes.c:1977
0xb38962 execute_todo
../../gcc/passes.c:2031
[Bug tree-optimization/89662] [9 Regression] -Warray-bounds ICE on void* arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89662 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Sebor --- Patch committed in r269655.
[Bug tree-optimization/89662] [9 Regression] -Warray-bounds ICE on void* arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89662 --- Comment #3 from Martin Sebor --- Author: msebor Date: Wed Mar 13 17:19:43 2019 New Revision: 269655 URL: https://gcc.gnu.org/viewcvs?rev=269655=gcc=rev Log: PR tree-optimization/89662 - -Warray-bounds ICE on void* arithmetic gcc/ChangeLog: PR tree-optimization/89662 * tree-vrp.c (vrp_prop::check_mem_ref): Avoid assuming every type has a size. gcc/testsuite/ChangeLog: PR tree-optimization/89662 * gcc.dg/Warray-bounds-41.c: New test. Added: trunk/gcc/testsuite/gcc.dg/Warray-bounds-41.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug middle-end/89690] ICE on a MEM_REF in trivial gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89690 --- Comment #2 from Martin Sebor --- Shouldn't the GIMPLE front-end give a better error message for invalid input? I realize -fgimple is an experimental feature but it seems that we should at least aim for the same robust error handling in the front-end as everywhere else.
[Bug other/89702] 03 issue with SIGALRM causes program to SEGV on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89702 --- Comment #2 from Andrew Pinski --- >Solaris SunOS 5.10 This might mean it is a kernel issue too. What does gdb show when it crashes? info registers
[Bug c/89699] [8/9 Regression] false warning -Wstringop-overflow and memcmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89699
Martin Sebor changed:
What|Removed |Added
Status|NEW |RESOLVED
Blocks||88443
Resolution|--- |INVALID
--- Comment #2 from Martin Sebor ---
The warning here is by design. When the value's range is negative and includes
zero it's taken to be strictly negative because it's so much more likely. We
could adjust this heuristic if we thought it necessary (simply by passing
allow_zero = true to get_size_range()) but since as Jakub said the size would
more appropriately be represented as unsigned (otherwise a large strlen result
could result in min being negative), I don't believe it is. Thus this is not a
false positive.
The following is a simplified version of the test case.
$ cat z.c && gcc -O2 -S -Wall -fdump-tree-vrp1=/dev/stdout z.c
int f (const char *s1, const char *s2, int i)
{
int min = i < 0 ? i : 0;
return __builtin_memcmp (s1, s2, min);
}
;; Function f (f, funcdef_no=0, decl_uid=1908, cgraph_uid=1, symbol_order=0)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2
;; 2 succs { 1 }
Value ranges after VRP:
_1: long unsigned int ~[1, 18446744071562067967]
i_2(D): VARYING
min_3: int [-INF, 0]
s1_5(D): VARYING
s2_6(D): VARYING
_7: VARYING
f (const char * s1, const char * s2, int i)
{
int min;
long unsigned int _1;
int _7;
[local count: 1073741824]:
min_3 = MIN_EXPR ;
_1 = (long unsigned int) min_3;
_7 = __builtin_memcmp (s1_5(D), s2_6(D), _1);
return _7;
}
z.c: In function ‘f’:
z.c:4:10: warning: ‘__builtin_memcmp’ specified size between
18446744071562067968 and 18446744073709551615 exceeds maximum object size
9223372036854775807 [-Wstringop-overflow=]
4 | return __builtin_memcmp (s1, s2, min);
| ^~
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
[Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 89699, which changed state. Bug 89699 Summary: [8/9 Regression] false warning -Wstringop-overflow and memcmp https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89699 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID
[Bug c++/89512] [7/8/9 Regression] ICE in get_expr_operands, at tree-ssa-operands.c:882
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89512
--- Comment #2 from Jakub Jelinek ---
Slightly cleaned up testcase:
struct A {
template
static const int a = 0;
};
struct B {
template
static int foo ()
{
return T::a;
}
};
int bar ()
{
return B::foo ();
}
Outside of a template this is caught by finish_id_expression_1 doing:
/* If we didn't find anything, or what we found was a type,
then this wasn't really an id-expression. */
if (TREE_CODE (decl) == TEMPLATE_DECL
&& !DECL_FUNCTION_TEMPLATE_P (decl))
{
*error_msg = G_("missing template arguments");
return error_mark_node;
}
but in this case, we don't call finish_id_expression, but go through
tsubst_qualified_id -> finish_qualified_id_expr
So, I wonder if we shouldn't handle this in the latter, something like:
--- gcc/cp/semantics.c.jj 2019-03-08 11:45:27.556465237 +0100
+++ gcc/cp/semantics.c 2019-03-13 17:24:46.260345284 +0100
@@ -2112,6 +2112,14 @@ finish_qualified_id_expr (tree qualifyin
expr = build_offset_ref (qualifying_class, expr, /*address_p=*/false,
complain);
}
+ else if (!template_p
+ && TREE_CODE (expr) == TEMPLATE_DECL
+ && !DECL_FUNCTION_TEMPLATE_P (expr))
+{
+ if (complain & tf_error)
+ error ("%qE missing template arguments", DECL_TEMPLATE_RESULT (expr));
+ return error_mark_node;
+}
else
{
/* In a template, return a SCOPE_REF for most qualified-ids
[Bug c++/67398] Segfault when template static references another template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67398 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #7 from Paolo Carlini --- All fixed long time ago, in 6.1.0.
[Bug tree-optimization/89672] NULL pointer check optimized out for the return value of memchr(NULL, c, 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89672 --- Comment #4 from Damon Revoe --- And that fact is used by the optimizer. I see. Thanks!
[Bug c++/89700] Warn if move constructor is not generated and not deleted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89700 --- Comment #1 from Jonathan Wakely --- (In reply to Antony Polukhin from comment #0) > The rules for the warning could be following: > Issue a warning if at least one of the class members has a move constructor, > class has a copy constructor and the move constructor is not implicitly > deleted. I like the idea in general, but I'm not sure this rule is right, or how to workaround the warning. A class might intentionally want to copy so its members are never left in a moved-from state, so the warning would not be helpful for that class. But I can't think of a convenient way for the class author to indicate that the behaviour is as intended. They can't delete the move constructor (that makes the class non-movable), and they can't default it (that would leave members in moved-from states).
[Bug c++/63508] ICE when using bracketed initializer on pointer to member function of a templated class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63508 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #5 from Paolo Carlini --- Fixed in 8.1.0.
[Bug c++/63508] ICE when using bracketed initializer on pointer to member function of a templated class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63508 --- Comment #4 from paolo at gcc dot gnu.org --- Author: paolo Date: Wed Mar 13 15:01:00 2019 New Revision: 269651 URL: https://gcc.gnu.org/viewcvs?rev=269651=gcc=rev Log: 2019-03-13 Paolo Carlini PR c++/63508 * g++.dg/cpp0x/auto53.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/auto53.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/89672] NULL pointer check optimized out for the return value of memchr(NULL, c, 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89672 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- C says e.g. for memchr: "The memchr function locates the first occurrence of c (converted to an unsigned char) in the initial n characters (each interpreted as unsigned char) of the object pointed to by s." and elsewhere: "If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function." As memchr first argument must point to an object and NULL does not point to any object, NULL is not a valid value. It is similar to memcpy (NULL, NULL, 0) or memset (NULL, 0, 0) etc. being invalid.
[Bug target/89378] [9 regression][MIPS] FAIL: gcc.dg/vect/pr88598-3.c -mmsa (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89378 --- Comment #3 from Jakub Jelinek --- Created attachment 45960 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45960=edit gcc9-pr89378.patch Untested (quite obvious) fix, though I don't really have a way to test this. If you could test this, I can submit it to gcc-patches. In RTL, a SUBREG of a SUBREG is invalid, and gen_lowpart is a function that takes care of all the folding to get the right single SUBREG.
[Bug target/89378] [9 regression][MIPS] FAIL: gcc.dg/vect/pr88598-3.c -mmsa (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89378 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-03-13 Component|rtl-optimization|target Ever confirmed|0 |1
[Bug tree-optimization/89672] NULL pointer check optimized out for the return value of memchr(NULL, c, 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89672 --- Comment #2 from Damon Revoe --- Oops. Ironically, I checked the man page for whether NULL was a valid argument. It just didn't occur to me to check the source. Duh. Thank you for your time!
[Bug c++/89074] valid pointer equality constexpr comparison rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89074
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Another testcase:
template
struct S {
static constexpr int a[2] = { 1, 2 };
};
static_assert (<0>::a[1] != nullptr);
[Bug other/89702] 03 issue with SIGALRM causes program to SEGV on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89702 Richard Biener changed: What|Removed |Added Target||i386-pc-solaris2.10 Status|UNCONFIRMED |WAITING Last reconfirmed||2019-03-13 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Note GCC 4.8.0 is no longer maintained (and is also the very first release off the GCC 4.8 branch with loads of bugfixes to come...). Please update to a maintained version and try again - that would be at _least_ GCC 7.4, better GCC 8.3
[Bug lto/89692] [9 Regression] ICE in streamer_write_chain, at tree-streamer-out.c:506
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89692 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jamborm at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Started with r269556.
[Bug other/89702] New: 03 issue with SIGALRM causes program to SEGV on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89702 Bug ID: 89702 Summary: 03 issue with SIGALRM causes program to SEGV on Solaris Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: karl.burgess at oracle dot com Target Milestone: --- Created attachment 45959 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45959=edit Program source files I have a program which compiles and works ok with -O1, but when I compile with -O3 the program crashes. The platform Solaris SunOS 5.10 is significant. The program works fine when compiled with -O3 on Linux. The key thing in the program to reproduce the crash is to have a SIGALRM signal handled during the execution of the optimized function ConvertUTF8toUTF16(). Setting the input buffer large enough for that function to take longer to execute is important. Steps to reproduce the bug: -bash-3.2$ uname -a SunOS bazalgette.uk.oracle.com 5.10 Generic_150401-63 i86pc i386 i86pc Solaris -bash-3.2$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/opt/tarantella/libexec/gcc/i386-pc-solaris2.10/4.8.0/lto-wrapper Target: i386-pc-solaris2.10 Configured with: ../gcc-4.8.0/configure --with-fpmath=sse --disable-sjlj-exceptions --with-gnu-as --with-as=/opt/tarantella/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld --with-system-zlib --build=i386-pc-solaris2.10 --host=i386-pc-solaris2.10 --with-boot-ldflags=-Wl,-R,/opt/tarantella/lib --disable-werror --disable-silent-rules --enable-multilib --prefix=/opt/tarantella --with-gmp=/opt/tarantella/ --with-mpfr=/opt/tarantella/ --with-mpc=/opt/tarantella/ --enable-threads=posix --enable-libgomp --enable-languages=c,c++ --with-cloog=/opt/tarantella/ --with-isl=/opt/tarantella/ --with-libelf=/opt/tarantella/ --disable-nls --enable-cloog-backend=isl --disable-cloog-version-check Thread model: posix gcc version 4.8.0 (GCC) -bash-3.2$ make gcc -c main.c -O3 -ggdb -save-temps gcc -c ConvertUTF.c -O3 -ggdb -save-temps gcc -otest main.o ConvertUTF.o -O3 -ggdb -save-temps -bash-3.2$ ./test Clipboard data len 26214400 Segmentation Fault (core dumped) The problem also occurs with gcc 8.3.0 on Solaris: COLLECT_GCC=/export/home/kb161603/build_gcc/gcc/xgcc Target: i386-pc-solaris2.10 Configured with: ../gcc-8.3.0/configure --with-mpc=/opt/tarantella --with-gmp=/opt/tarantella --with-mpfr=/opt/tarantella : (reconfigured) ../gcc-8.3.0/configure --with-mpc=/opt/tarantella --with-gmp=/opt/tarantella --with-mpfr=/opt/tarantella --enable-languages=c,c++ Thread model: posix gcc version 8.3.0 (GCC) The attachment gccbug.tar.gz contains the program source files, .i files and Makefile: -bash-3.2$ tar tvf gccbug.tar -rw-r--r-- kb161603/other 9120 2019-03-12 15:59 ConvertUTF.c -rw-r--r-- kb161603/other 6695 2019-03-07 11:29 ConvertUTF.h -rw-r--r-- kb161603/other 5595 2019-03-13 13:59 ConvertUTF.i -rw-r--r-- kb161603/other 6308 2019-03-13 13:59 ConvertUTF.o -rw-r--r-- kb161603/other 26821 2019-03-13 13:59 ConvertUTF.s -rw-r--r-- kb161603/other 1945 2019-03-12 16:14 main.c -rw-r--r-- kb161603/other 38874 2019-03-13 13:59 main.i -rw-r--r-- kb161603/other 10004 2019-03-13 13:59 main.o -rw-r--r-- kb161603/other 37056 2019-03-13 13:59 main.s -rw-r--r-- kb161603/other 268 2019-03-12 16:16 Makefile -rwxr-xr-x kb161603/other 18936 2019-03-13 13:59 test
[Bug rtl-optimization/89634] gmp-ecm miscompilation on s390x with -march=zEC12 -m64 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89634 Bug 89634 depends on bug 89497, which changed state. Bug 89497 Summary: [8 Regression] ICE caused by Segmentation Fault when compiling cups 2.2.10 with LTO flags enabled https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89497 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/89497] [8 Regression] ICE caused by Segmentation Fault when compiling cups 2.2.10 with LTO flags enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89497 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||8.3.1 Resolution|--- |FIXED --- Comment #29 from Richard Biener --- Fixed.
[Bug middle-end/89677] [7/8 Regression] internal compiler error: in wide_int_to_tree_1, at tree.c:1549
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89677 --- Comment #6 from Richard Biener --- Author: rguenth Date: Wed Mar 13 14:08:07 2019 New Revision: 269650 URL: https://gcc.gnu.org/viewcvs?rev=269650=gcc=rev Log: 2019-03-14 Richard Biener Backport from mainline 2019-03-13 Richard Biener PR middle-end/89677 * tree-scalar-evolution.c (simplify_peeled_chrec): Do not throw FP expressions at tree-affine. * gcc.dg/torture/pr89677.c: New testcase. 2019-03-01 Richard Biener PR middle-end/89497 * tree-cfgcleanup.h (cleanup_tree_cfg): Add SSA update flags argument, defaulted to zero. * passes.c (execute_function_todo): Pass down SSA update flags to cleanup_tree_cfg. * tree-cfgcleanup.c: Include tree-into-ssa.h and tree-cfgcleanup.h. (cleanup_tree_cfg_1): After cleanup_control_flow_pre update SSA form if requested. (cleanup_tree_cfg_noloop): Pass down SSA update flags. (cleanup_tree_cfg): Get and pass down SSA update flags. * gcc.dg/tree-ssa/reassoc-43.c: Avoid false match in regex. * g++.dg/tree-prof/devirt.C: Scan tracer dump for foldings that happen now earlier. 2019-02-18 Richard Biener PR tree-optimization/89296 * tree-ssa-loop-ch.c (ch_base::copy_headers): Restrict setting of no-warning flag to cases that might emit the bogus warning. * gcc.dg/uninit-pr89296.c: New testcase. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr89677.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/uninit-pr89296.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/passes.c branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/g++.dg/tree-prof/devirt.C branches/gcc-8-branch/gcc/testsuite/gcc.dg/tree-ssa/reassoc-43.c branches/gcc-8-branch/gcc/tree-cfgcleanup.c branches/gcc-8-branch/gcc/tree-cfgcleanup.h branches/gcc-8-branch/gcc/tree-scalar-evolution.c branches/gcc-8-branch/gcc/tree-ssa-loop-ch.c
[Bug tree-optimization/89296] [7/8 Regression] tree copy-header masking uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89296 --- Comment #5 from Richard Biener --- Author: rguenth Date: Wed Mar 13 14:08:07 2019 New Revision: 269650 URL: https://gcc.gnu.org/viewcvs?rev=269650=gcc=rev Log: 2019-03-14 Richard Biener Backport from mainline 2019-03-13 Richard Biener PR middle-end/89677 * tree-scalar-evolution.c (simplify_peeled_chrec): Do not throw FP expressions at tree-affine. * gcc.dg/torture/pr89677.c: New testcase. 2019-03-01 Richard Biener PR middle-end/89497 * tree-cfgcleanup.h (cleanup_tree_cfg): Add SSA update flags argument, defaulted to zero. * passes.c (execute_function_todo): Pass down SSA update flags to cleanup_tree_cfg. * tree-cfgcleanup.c: Include tree-into-ssa.h and tree-cfgcleanup.h. (cleanup_tree_cfg_1): After cleanup_control_flow_pre update SSA form if requested. (cleanup_tree_cfg_noloop): Pass down SSA update flags. (cleanup_tree_cfg): Get and pass down SSA update flags. * gcc.dg/tree-ssa/reassoc-43.c: Avoid false match in regex. * g++.dg/tree-prof/devirt.C: Scan tracer dump for foldings that happen now earlier. 2019-02-18 Richard Biener PR tree-optimization/89296 * tree-ssa-loop-ch.c (ch_base::copy_headers): Restrict setting of no-warning flag to cases that might emit the bogus warning. * gcc.dg/uninit-pr89296.c: New testcase. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr89677.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/uninit-pr89296.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/passes.c branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/g++.dg/tree-prof/devirt.C branches/gcc-8-branch/gcc/testsuite/gcc.dg/tree-ssa/reassoc-43.c branches/gcc-8-branch/gcc/tree-cfgcleanup.c branches/gcc-8-branch/gcc/tree-cfgcleanup.h branches/gcc-8-branch/gcc/tree-scalar-evolution.c branches/gcc-8-branch/gcc/tree-ssa-loop-ch.c
[Bug middle-end/89497] [8 Regression] ICE caused by Segmentation Fault when compiling cups 2.2.10 with LTO flags enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89497 --- Comment #30 from Richard Biener --- Author: rguenth Date: Wed Mar 13 14:08:07 2019 New Revision: 269650 URL: https://gcc.gnu.org/viewcvs?rev=269650=gcc=rev Log: 2019-03-14 Richard Biener Backport from mainline 2019-03-13 Richard Biener PR middle-end/89677 * tree-scalar-evolution.c (simplify_peeled_chrec): Do not throw FP expressions at tree-affine. * gcc.dg/torture/pr89677.c: New testcase. 2019-03-01 Richard Biener PR middle-end/89497 * tree-cfgcleanup.h (cleanup_tree_cfg): Add SSA update flags argument, defaulted to zero. * passes.c (execute_function_todo): Pass down SSA update flags to cleanup_tree_cfg. * tree-cfgcleanup.c: Include tree-into-ssa.h and tree-cfgcleanup.h. (cleanup_tree_cfg_1): After cleanup_control_flow_pre update SSA form if requested. (cleanup_tree_cfg_noloop): Pass down SSA update flags. (cleanup_tree_cfg): Get and pass down SSA update flags. * gcc.dg/tree-ssa/reassoc-43.c: Avoid false match in regex. * g++.dg/tree-prof/devirt.C: Scan tracer dump for foldings that happen now earlier. 2019-02-18 Richard Biener PR tree-optimization/89296 * tree-ssa-loop-ch.c (ch_base::copy_headers): Restrict setting of no-warning flag to cases that might emit the bogus warning. * gcc.dg/uninit-pr89296.c: New testcase. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr89677.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/uninit-pr89296.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/passes.c branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/g++.dg/tree-prof/devirt.C branches/gcc-8-branch/gcc/testsuite/gcc.dg/tree-ssa/reassoc-43.c branches/gcc-8-branch/gcc/tree-cfgcleanup.c branches/gcc-8-branch/gcc/tree-cfgcleanup.h branches/gcc-8-branch/gcc/tree-scalar-evolution.c branches/gcc-8-branch/gcc/tree-ssa-loop-ch.c
[Bug c/89699] [8/9 Regression] false warning -Wstringop-overflow and memcmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89699
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-03-13
CC||jakub at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
Warning like this shouldn't be enabled by default with the amount of false
positives it has.
In this case, we have:
# RANGE [-2147483648, 0]
min_6 = MIN_EXPR ;
# RANGE ~[1, 18446744071562067967]
_3 = (long unsigned int) min_6;
_7 = __builtin_memcmp (s1.0_1, "", _3);
where we don't know anything about len1 (VARYING), but as we folded strlen ("")
into 0, it is min is actually MIN (len1, 0) and so the range of it is indeed
[-2147483648, 0] and that converted to size_t is 0 or -2147483648UL or higher.
As a workaround, I'd strongly recommend not using int variables to hold sizes
of strings, it should be using size_t instead.
[Bug other/89701] New: Provide -fcf-protection=branch,return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89701 Bug ID: 89701 Summary: Provide -fcf-protection=branch,return Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: bonzini at gnu dot org Target Milestone: --- Right now the only possibility to specify that combination -fcf-protection=full, but this is not future proof; if other suboptions are added later, they could be applied to code that does not support them. Code that wants to be reliable against future extensions to -fcf-protection needs to specify each desired option manually, as in "-fcf-protection=branch,return".
[Bug ipa/89693] [9 Regression] ICE: verify_cgraph_node failed (error: edge points to wrong declaration)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89693 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-03-13 CC||jakub at gcc dot gnu.org, ||jamborm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r269462.
[Bug c++/68138] "operator== is ambiguous" when comparing a tuple containing values with one containing refs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68138
Alexander Haase changed:
What|Removed |Added
CC||unsavoryemail at gmail dot com
--- Comment #2 from Alexander Haase ---
Can confirm that this is still an issue up to the latest release of GCC 8.
Here's an even simpler reproduction:
#include
struct Empty {
bool operator == (const Empty &) const { return true; }
};
int main() {
std::tuple a, b;
return a == b;
}
Here's a compiler explorer example where clang and msvc compile the above with
no issue, but gcc does not. Note that clang and gcc use the same stl
implementation as configured for compiler explorer.
https://godbolt.org/z/Em6B9e
[Bug translation/79618] prevent missing space in multiline string literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79618 Eric Gallager changed: What|Removed |Added Blocks|40883 | --- Comment #6 from Eric Gallager --- (In reply to Roland Illig from comment #5) > Agreed. > > I myself cannot remove it from the list of trivial bugs though. OK I have now. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883 [Bug 40883] [meta-bug] Translation breakage with trivial fixes
