[Bug inline-asm/84625] [6/7 Regression] ICE with empty constraint and vector constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84625 Jakub Jelinek changed: What|Removed |Added Summary|[6/7/8 Regression] ICE with |[6/7 Regression] ICE with |empty constraint and vector |empty constraint and vector |constant|constant --- Comment #5 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug middle-end/84603] -finline-limit not accepted in attribute and #pragma optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84603 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |INVALID --- Comment #4 from Richard Biener --- Note this is an option having IPA effect so it doesn't make sense to specify it on a per-function level. Thus INVALID. That is, the effect is setting some --params but their values are always global and not per function. So it's more an implementation "defect", some of the inliner parameters might make sense to constrain on a per-function level.
[Bug target/83790] Update nvptx target to work with cuda 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83790 --- Comment #3 from Thomas Schwinge --- Author: tschwinge Date: Fri Mar 2 08:40:04 2018 New Revision: 258127 URL: https://gcc.gnu.org/viewcvs?rev=258127&root=gcc&view=rev Log: [nvptx] Add support for CUDA 9 Backport trunk r256891: gcc/ 2018-01-19 Cesar Philippidis PR target/83790 * config/nvptx/nvptx.c (output_init_frag): Don't use generic address spaces for function labels. gcc/testsuite/ 2018-01-19 Cesar Philippidis PR target/83790 * gcc.target/nvptx/indirect_call.c: New test. Added: branches/gcc-6-branch/gcc/testsuite/gcc.target/nvptx/indirect_call.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/nvptx/nvptx.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug target/83790] Update nvptx target to work with cuda 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83790 --- Comment #2 from Thomas Schwinge --- Author: tschwinge Date: Fri Mar 2 08:39:31 2018 New Revision: 258126 URL: https://gcc.gnu.org/viewcvs?rev=258126&root=gcc&view=rev Log: [nvptx] Add support for CUDA 9 Backport trunk r256891: gcc/ 2018-01-19 Cesar Philippidis PR target/83790 * config/nvptx/nvptx.c (output_init_frag): Don't use generic address spaces for function labels. gcc/testsuite/ 2018-01-19 Cesar Philippidis PR target/83790 * gcc.target/nvptx/indirect_call.c: New test. Added: branches/gcc-7-branch/gcc/testsuite/gcc.target/nvptx/indirect_call.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/nvptx/nvptx.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug c++/84661] New: internal compiler error: Segmentation fault (strip_array_types())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84661
Bug ID: 84661
Summary: internal compiler error: Segmentation fault
(strip_array_types())
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vegard.nossum at gmail dot com
CC: webrown.cpp at gmail dot com
Target Milestone: ---
Input:
class {
&a;
b(decltype(((a = 0) || ((auto)
};
Output:
$ xgcc -x c++ -S -
:2:4: error: ISO C++ forbids declaration of 'a' with no type
[-fpermissive]
:3:28: error: expected primary-expression before 'auto'
:3:28: error: expected ')' before 'auto'
:3:37: error: expected ')' before '}' token
:4:1: internal compiler error: Segmentation fault
0x3155789 crash_signal
/home/vegard/git/gcc/gcc/toplev.c:325
0x400d828 strip_array_types(tree_node*)
/home/vegard/git/gcc/gcc/tree.c:7932
0x139c9d0 cp_type_quals(tree_node const*)
/home/vegard/git/gcc/gcc/cp/typeck.c:9585
0x136f3dc cv_unqualified(tree_node*)
/home/vegard/git/gcc/gcc/cp/tree.c:1286
0xa4dc38 initialized_type
/home/vegard/git/gcc/gcc/cp/constexpr.c:2707
0xa4dc38 cxx_eval_outermost_constant_expr
/home/vegard/git/gcc/gcc/cp/constexpr.c:4794
0xa5b966 maybe_constant_value(tree_node*, tree_node*)
/home/vegard/git/gcc/gcc/cp/constexpr.c:5044
0xaba942 cp_fully_fold(tree_node*)
/home/vegard/git/gcc/gcc/cp/cp-gimplify.c:2040
0xec86a3 cp_parser_binary_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9298
0xec95aa cp_parser_assignment_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9484
0xecbaca cp_parser_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9653
0xf3833e cp_parser_primary_expression
/home/vegard/git/gcc/gcc/cp/parser.c:5204
0xf7a2eb cp_parser_postfix_expression
/home/vegard/git/gcc/gcc/cp/parser.c:7028
0xf2e057 cp_parser_unary_expression
/home/vegard/git/gcc/gcc/cp/parser.c:8320
0xec31aa cp_parser_cast_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9088
0xec57d6 cp_parser_binary_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9189
0xec95aa cp_parser_assignment_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9484
0xecbaca cp_parser_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9653
0xf7d8a1 cp_parser_decltype_expr
/home/vegard/git/gcc/gcc/cp/parser.c:14052
0xf7d8a1 cp_parser_decltype
/home/vegard/git/gcc/gcc/cp/parser.c:14126
$ xgcc --version
xgcc (GCC) 8.0.1 20180301 (experimental)
Built from git c435a9e730c6e8f10da09d58b4fc9aaeb401b0d5 (r258097).
Seems present on 4.9.0 if you pass -std=c++14.
Test case was minimised by C-Reduce.
[Bug target/83790] Update nvptx target to work with cuda 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83790 Thomas Schwinge changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Last reconfirmed||2018-03-01 CC||tschwinge at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |cesar at gcc dot gnu.org --- Comment #4 from Thomas Schwinge --- Fixed in trunk, gcc-7-branch, gcc-6-branch.
[Bug fortran/84219] [8 Regression] ICE: Invalid expression in gfc_target_interpret_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84219 --- Comment #4 from Paul Thomas --- Author: pault Date: Fri Mar 2 08:51:06 2018 New Revision: 258128 URL: https://gcc.gnu.org/viewcvs?rev=258128&root=gcc&view=rev Log: 2018-03-02 Paul Thomas PR fortran/84219 * gfortran.dg/coarray_47.f90: Use the correct test. Modified: trunk/gcc/testsuite/gfortran.dg/coarray_47.f90
[Bug c++/84662] New: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in is_bitfield_expr_with_lowered_type, at cp/typeck.c:1944
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84662
Bug ID: 84662
Summary: internal compiler error: tree check: expected class
'type', have 'exceptional' (error_mark) in
is_bitfield_expr_with_lowered_type, at
cp/typeck.c:1944
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vegard.nossum at gmail dot com
CC: webrown.cpp at gmail dot com
Target Milestone: ---
Input:
double b;
a(__attribute__((c(0 && int() - ([] {} && b) || auto;
Output:
$ xgcc -x c++ -S -
:2:31: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in is_bitfield_expr_with_lowered_type, at
cp/typeck.c:1944
0x660319 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/home/vegard/git/gcc/gcc/tree.c:9388
0x13af08d tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/home/vegard/git/gcc/gcc/tree.h:3255
0x13af08d is_bitfield_expr_with_lowered_type(tree_node const*)
/home/vegard/git/gcc/gcc/cp/typeck.c:1944
0x13af7f5 cp_perform_integral_promotions(tree_node*, int)
/home/vegard/git/gcc/gcc/cp/typeck.c:2169
0x13cc321 cp_default_conversion
/home/vegard/git/gcc/gcc/cp/typeck.c:2138
0x13ce169 cp_build_binary_op(unsigned int, tree_code, tree_node*, tree_node*,
int)
/home/vegard/git/gcc/gcc/cp/typeck.c:4272
0x945247 build_new_op_1
/home/vegard/git/gcc/gcc/cp/call.c:6013
0x948c36 build_new_op(unsigned int, tree_code, int, tree_node*, tree_node*,
tree_node*, tree_node**, int)
/home/vegard/git/gcc/gcc/cp/call.c:6058
0x1395e6b build_x_binary_op(unsigned int, tree_code, tree_node*, tree_code,
tree_node*, tree_code, tree_node**, int)
/home/vegard/git/gcc/gcc/cp/typeck.c:4030
0x10f4b6e tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/vegard/git/gcc/gcc/cp/pt.c:17537
0x10f49f2 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/vegard/git/gcc/gcc/cp/pt.c:17524
0x10f4a23 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/vegard/git/gcc/gcc/cp/pt.c:17525
0xa5c07a fold_non_dependent_expr(tree_node*)
/home/vegard/git/gcc/gcc/cp/constexpr.c:5097
0x105525f build_non_dependent_expr(tree_node*)
/home/vegard/git/gcc/gcc/cp/pt.c:25295
0x13967bf build_x_binary_op(unsigned int, tree_code, tree_node*, tree_code,
tree_node*, tree_code, tree_node**, int)
/home/vegard/git/gcc/gcc/cp/typeck.c:4022
0xec7b2b cp_parser_binary_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9354
0xec95aa cp_parser_assignment_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9484
0xed75e4 cp_parser_parenthesized_expression_list
/home/vegard/git/gcc/gcc/cp/parser.c:7762
0xeda0bb cp_parser_gnu_attribute_list
/home/vegard/git/gcc/gcc/cp/parser.c:25047
0xeda0bb cp_parser_gnu_attributes_opt
/home/vegard/git/gcc/gcc/cp/parser.c:24962
$ xgcc --version
xgcc (GCC) 8.0.1 20180301 (experimental)
Built from git c435a9e730c6e8f10da09d58b4fc9aaeb401b0d5 (r258097).
7.3.0 seems fine.
Test case was minimised by C-Reduce.
[Bug c++/84663] New: internal compiler error: tree check: expected array_type, have error_mark in cp_complete_array_type, at cp/decl.c:8334
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84663
Bug ID: 84663
Summary: internal compiler error: tree check: expected
array_type, have error_mark in cp_complete_array_type,
at cp/decl.c:8334
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vegard.nossum at gmail dot com
CC: webrown.cpp at gmail dot com
Target Milestone: ---
Input:
struct c {
typedef c a[alignof(long)];
int f:-1ULL;
c() {
struct {
a d;
} e[];
}
};
Output:
$ xgcc -x c++ -S -
:3:10: warning: width of 'c::f' exceeds its type
: In constructor 'c::c()':
:7:9: error: size of array is too large
:7:9: internal compiler error: tree check: expected array_type, have
error_mark in cp_complete_array_type, at cp/decl.c:8334
0x65f900 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/home/vegard/git/gcc/gcc/tree.c:9337
0xb45e66 tree_check(tree_node*, char const*, int, char const*, tree_code)
/home/vegard/git/gcc/gcc/tree.h:3132
0xb45e66 cp_complete_array_type(tree_node**, tree_node*, bool)
/home/vegard/git/gcc/gcc/cp/decl.c:8334
0xb463f0 maybe_deduce_size_from_array_init
/home/vegard/git/gcc/gcc/cp/decl.c:5445
0xb47f66 check_initializer
/home/vegard/git/gcc/gcc/cp/decl.c:6369
0xbdcd8e cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
/home/vegard/git/gcc/gcc/cp/decl.c:7084
0xfa49d9 cp_parser_init_declarator
/home/vegard/git/gcc/gcc/cp/parser.c:19722
0xfa9757 cp_parser_simple_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:13063
0xfaf948 cp_parser_block_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:12881
0xfb1e14 cp_parser_declaration_statement
/home/vegard/git/gcc/gcc/cp/parser.c:12474
0xefdd8b cp_parser_statement
/home/vegard/git/gcc/gcc/cp/parser.c:10923
0xf0184b cp_parser_statement_seq_opt
/home/vegard/git/gcc/gcc/cp/parser.c:11272
0xf022ea cp_parser_compound_statement
/home/vegard/git/gcc/gcc/cp/parser.c:11226
0xf967eb cp_parser_function_body
/home/vegard/git/gcc/gcc/cp/parser.c:21769
0xf967eb cp_parser_ctor_initializer_opt_and_function_body
/home/vegard/git/gcc/gcc/cp/parser.c:21804
0xf9f9f5 cp_parser_function_definition_after_declarator
/home/vegard/git/gcc/gcc/cp/parser.c:26809
0xfa1cbc cp_parser_late_parsing_for_member
/home/vegard/git/gcc/gcc/cp/parser.c:27690
0xf1aed5 cp_parser_class_specifier_1
/home/vegard/git/gcc/gcc/cp/parser.c:22733
0xf2642b cp_parser_class_specifier
/home/vegard/git/gcc/gcc/cp/parser.c:22759
0xf2642b cp_parser_type_specifier
/home/vegard/git/gcc/gcc/cp/parser.c:16765
$ xgcc --version
xgcc (GCC) 8.0.1 20180301 (experimental)
Built from git c435a9e730c6e8f10da09d58b4fc9aaeb401b0d5 (r258097).
Doesn't seem present on 7.3.0.
Test case was minimised by C-Reduce.
[Bug rtl-optimization/84614] [8 Regression] wrong code with u16->u128 extension at aarch64 -fno-split-wide-types -g3 --param=max-combine-insns=3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84614 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Fri Mar 2 09:16:50 2018 New Revision: 258129 URL: https://gcc.gnu.org/viewcvs?rev=258129&root=gcc&view=rev Log: PR target/84614 * rtl.h (prev_real_nondebug_insn, next_real_nondebug_insn): New prototypes. * emit-rtl.c (next_real_insn, prev_real_insn): Fix up function comments. (next_real_nondebug_insn, prev_real_nondebug_insn): New functions. * cfgcleanup.c (try_head_merge_bb): Use prev_real_nondebug_insn instead of a loop around prev_real_insn. * combine.c (move_deaths): Use prev_real_nondebug_insn instead of prev_real_insn. * gcc.dg/pr84614.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr84614.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgcleanup.c trunk/gcc/combine.c trunk/gcc/emit-rtl.c trunk/gcc/rtl.h trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/84486] [7/8 Regression] code hoisting removes alignment assumption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84486 --- Comment #2 from Richard Biener --- Created attachment 43540 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43540&action=edit candidate patch Can you check whether this patch works for you (on the unreduced testcase which likely exists)? The underlying issue is of course bigger and not restricted to code-hoisting. All the new code generated by PRE (inserted for partial redundancy removal or code-hoisting) has no SSA info attached. That includes points-to info which isn't flow-sensitive but of course also all the flow-sensitive information like range info and alignment info that we can't generally preserve easily. This means that we'd ideally have passes computing those _after_ PRE. Which means experimenting with a larger pass pipeline re-organization like exchanging FRE after inlining and PRE and moving CCP after inlining downstream. The alternative would be to make the elimination phase do simple dom-style computation and propagation of both ranges (easy with the EVRP engine) and alignment (moderately easy with some refactoring of CCP). That would leave points-to info which we'd ideally tack onto the PRE expressions then.
[Bug c++/84664] New: internal compiler error: in cp_perform_integral_promotions, at cp/typeck.c:2172
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84664
Bug ID: 84664
Summary: internal compiler error: in
cp_perform_integral_promotions, at cp/typeck.c:2172
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vegard.nossum at gmail dot com
CC: webrown.cpp at gmail dot com
Target Milestone: ---
Input:
int a() {
auto &b = 1;
[] { b > 0 }
}
Output:
$ xgcc -x c++ -S -
: In function 'int a()':
:2:13: error: cannot bind non-const lvalue reference of type 'int&' to
an rvalue of type 'int'
: In lambda function:
:3:12: error: 'b' is not captured
:3:4: note: the lambda has no capture-default
:2:9: note: 'int& b' declared here
:3:12: internal compiler error: in cp_perform_integral_promotions, at
cp/typeck.c:2172
0x13afaff cp_perform_integral_promotions(tree_node*, int)
/home/vegard/git/gcc/gcc/cp/typeck.c:2172
0x13cc321 cp_default_conversion
/home/vegard/git/gcc/gcc/cp/typeck.c:2138
0x13cc5d7 cp_build_binary_op(unsigned int, tree_code, tree_node*, tree_node*,
int)
/home/vegard/git/gcc/gcc/cp/typeck.c:4270
0x945247 build_new_op_1
/home/vegard/git/gcc/gcc/cp/call.c:6013
0x948c36 build_new_op(unsigned int, tree_code, int, tree_node*, tree_node*,
tree_node*, tree_node**, int)
/home/vegard/git/gcc/gcc/cp/call.c:6058
0x1395e6b build_x_binary_op(unsigned int, tree_code, tree_node*, tree_code,
tree_node*, tree_code, tree_node**, int)
/home/vegard/git/gcc/gcc/cp/typeck.c:4030
0xec7b2b cp_parser_binary_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9354
0xec95aa cp_parser_assignment_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9484
0xecd516 cp_parser_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9653
0xee1a96 cp_parser_expression_statement
/home/vegard/git/gcc/gcc/cp/parser.c:11129
0xefd340 cp_parser_statement
/home/vegard/git/gcc/gcc/cp/parser.c:10933
0xf0184b cp_parser_statement_seq_opt
/home/vegard/git/gcc/gcc/cp/parser.c:11272
0xfd36d1 cp_parser_lambda_body
/home/vegard/git/gcc/gcc/cp/parser.c:10683
0xfd36d1 cp_parser_lambda_expression
/home/vegard/git/gcc/gcc/cp/parser.c:10184
0xf38814 cp_parser_primary_expression
/home/vegard/git/gcc/gcc/cp/parser.c:5259
0xf7a2eb cp_parser_postfix_expression
/home/vegard/git/gcc/gcc/cp/parser.c:7028
0xf2e057 cp_parser_unary_expression
/home/vegard/git/gcc/gcc/cp/parser.c:8320
0xec31aa cp_parser_cast_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9088
0xec57d6 cp_parser_binary_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9189
0xec95aa cp_parser_assignment_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9484
$ xgcc --version
xgcc (GCC) 8.0.1 20180301 (experimental)
Built from git c435a9e730c6e8f10da09d58b4fc9aaeb401b0d5 (r258097).
7.3.0 looks fine to me.
Test case was minimised by C-Reduce.
[Bug fortran/84640] gcc/fortran/simplify.c:2587:9: runtime error: pointer index expression with base 0x0000090de160 overflowed to 0xffffffffc0632960
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84640 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-03-02 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- I cannot reproduce that. Could you please describe the problem with more details?
[Bug tree-optimization/84634] [8 Regression] gcc/tree-vect-stmts.c:6786:19: runtime error: member access within null pointer of type 'struct _loop_vec_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84634 --- Comment #2 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Fri Mar 2 09:46:43 2018 New Revision: 258131 URL: https://gcc.gnu.org/viewcvs?rev=258131&root=gcc&view=rev Log: Avoid &LOOP_VINFO_MASKS for bb vectorisation (PR 84634) We were computing &LOOP_VINFO_MASKS even for bb vectorisation, which is UB. 2018-03-02 Richard Sandiford gcc/ PR tree-optimization/84634 * tree-vect-stmts.c (vectorizable_store, vectorizable_load): Replace masks and masked_loop_p with a single loop_masks, making sure it's null for bb vectorization. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-stmts.c
[Bug c++/84665] New: internal compiler error: in build_value_init, at cp/init.c:343
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84665
Bug ID: 84665
Summary: internal compiler error: in build_value_init, at
cp/init.c:343
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vegard.nossum at gmail dot com
CC: webrown.cpp at gmail dot com
Target Milestone: ---
Input:
struct {
} a[1];
template
void b() {
__attribute__((noinline(a[0]))) int c = 0;
}
Output:
$ xgcc -x c++ -S -
: In function 'void b()':
:6:38: internal compiler error: in build_value_init, at cp/init.c:343
0xcfbe2b build_value_init(tree_node*, int)
/home/vegard/git/gcc/gcc/cp/init.c:342
0xa47056 cxx_eval_array_reference
/home/vegard/git/gcc/gcc/cp/constexpr.c:2458
0xa339b0 cxx_eval_constant_expression
/home/vegard/git/gcc/gcc/cp/constexpr.c:4470
0xa4e0da cxx_eval_outermost_constant_expr
/home/vegard/git/gcc/gcc/cp/constexpr.c:4827
0xa5b966 maybe_constant_value(tree_node*, tree_node*)
/home/vegard/git/gcc/gcc/cp/constexpr.c:5044
0xc43ac2 cp_check_const_attributes
/home/vegard/git/gcc/gcc/cp/decl2.c:1415
0xc43ac2 cplus_decl_attributes(tree_node**, tree_node*, int)
/home/vegard/git/gcc/gcc/cp/decl2.c:1531
0xc1974a start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
/home/vegard/git/gcc/gcc/cp/decl.c:5050
0xfa391c cp_parser_init_declarator
/home/vegard/git/gcc/gcc/cp/parser.c:19591
0xfa9757 cp_parser_simple_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:13063
0xfaf948 cp_parser_block_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:12881
0xfb1e14 cp_parser_declaration_statement
/home/vegard/git/gcc/gcc/cp/parser.c:12474
0xefdd8b cp_parser_statement
/home/vegard/git/gcc/gcc/cp/parser.c:10923
0xf0184b cp_parser_statement_seq_opt
/home/vegard/git/gcc/gcc/cp/parser.c:11272
0xf022ea cp_parser_compound_statement
/home/vegard/git/gcc/gcc/cp/parser.c:11226
0xf967eb cp_parser_function_body
/home/vegard/git/gcc/gcc/cp/parser.c:21769
0xf967eb cp_parser_ctor_initializer_opt_and_function_body
/home/vegard/git/gcc/gcc/cp/parser.c:21804
0xf9f9f5 cp_parser_function_definition_after_declarator
/home/vegard/git/gcc/gcc/cp/parser.c:26809
0xfa604d cp_parser_function_definition_from_specifiers_and_declarator
/home/vegard/git/gcc/gcc/cp/parser.c:26726
0xfa604d cp_parser_init_declarator
/home/vegard/git/gcc/gcc/cp/parser.c:19493
$ xgcc --version
xgcc (GCC) 8.0.1 20180301 (experimental)
Built from git c435a9e730c6e8f10da09d58b4fc9aaeb401b0d5 (r258097).
Seems to have appeared between 6.3.0 and 7.1.0.
Test case was minimised by C-Reduce.
[Bug tree-optimization/84634] [8 Regression] gcc/tree-vect-stmts.c:6786:19: runtime error: member access within null pointer of type 'struct _loop_vec_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84634 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from rsandifo at gcc dot gnu.org --- Fixed.
[Bug c++/84590] [7/8 Regression] -fsanitize=undefined internal compiler error: tree check: expected constructor, have target_expr in split_nonconstant_init_1, at cp/typeck2.c:629
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84590 --- Comment #7 from Marek Polacek --- Author: mpolacek Date: Fri Mar 2 09:48:41 2018 New Revision: 258132 URL: https://gcc.gnu.org/viewcvs?rev=258132&root=gcc&view=rev Log: PR c++/84590 * cp-gimplify.c (cp_fully_fold): Unwrap TARGET_EXPR or a CONSTRUCTOR wrapped in VIEW_CONVERT_EXPR. * c-c++-common/ubsan/shift-11.c: New test. Added: trunk/gcc/testsuite/c-c++-common/ubsan/shift-11.c Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c trunk/gcc/testsuite/ChangeLog
[Bug c++/84590] [7 Regression] -fsanitize=undefined internal compiler error: tree check: expected constructor, have target_expr in split_nonconstant_init_1, at cp/typeck2.c:629
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84590 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Summary|[7/8 Regression]|[7 Regression] |-fsanitize=undefined|-fsanitize=undefined |internal compiler error:|internal compiler error: |tree check: expected|tree check: expected |constructor, have |constructor, have |target_expr in |target_expr in |split_nonconstant_init_1, |split_nonconstant_init_1, |at cp/typeck2.c:629 |at cp/typeck2.c:629 --- Comment #8 from Marek Polacek --- Fixed in 8; probably not going to backport.
[Bug libstdc++/84666] New: ostringstream prints floats 2x slower than snprintf, when precision>=37
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84666 Bug ID: 84666 Summary: ostringstream prints floats 2x slower than snprintf, when precision>=37 Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: b7.10110111 at gmail dot com Target Milestone: --- Created attachment 43541 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43541&action=edit Test program If you compile the attached test program and run it, you'll notice that ostringstream performance becomes 2x slower at precision>=38 (and 1.5x slower on average at precision==37). I've traced it to _M_insert_float using too small initial buffer, regardless of the precision requested, and thus having to call std::__convert_from_v second time. The offending line is: // First try a buffer perhaps big enough (most probably sufficient // for non-ios_base::fixed outputs) int __cs_size = __max_digits * 3; Here __max_digits is a numeric trait of _ValueT, and doesn't depend on __prec. It seems more correct to use __prec instead of (or in addition to) __max_digits here. Interestingly, a few lines below, in the #else branch of #if _GLIBCXX_USE_C99_STDIO, we can see that __prec is taken into account in calculation of __cs_size. Apparently, on Kubuntu 14.04 amd64, _GLIBCXX_USE_C99_STDIO was set to 1.
[Bug ipa/83983] FAIL: g++.dg/lto/pr83121 (test for LTO warnings, pr83121_0.C line 8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83983 --- Comment #7 from Eric Botcazou --- Author: ebotcazou Date: Fri Mar 2 09:57:43 2018 New Revision: 258133 URL: https://gcc.gnu.org/viewcvs?rev=258133&root=gcc&view=rev Log: PR ipa/83983 * ipa-devirt.c (odr_subtypes_equivalent_p): Get the ODR type of both arguments if they are comparable. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-devirt.c
[Bug c++/84667] New: unreasonable refusal to use assignment operator method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84667
Bug ID: 84667
Summary: unreasonable refusal to use assignment operator method
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: estellnb at elstel dot org
Target Milestone: ---
Created attachment 43542
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43542&action=edit
sample program that evokes the given error
g++ (Debian 6.3.0-18+deb9u1) 6.3.0 20170516:
At me g++ refuses to make use of the following operator
xstrbuf& operator = ( base_str_const s );
Instead it seems to convert an xstr_const into an xstr_mutable which is
generally forbidden and not enabled by my code.
Things work well however if I use the standard constructor instead of an
assignment:
inline xstrbuf( base_str_const s ) : base_str(
const_cast(s.chars), s.length ) { bufParams = xstrbuf_constBuf; };
It is important to get the "bufParams = xstrbuf_constBuf; " executed otherwise
the code will fail. You can test for it yourself by executing ./runit.
Any feedback would be very appreciated!
[Bug debug/84620] DW_AT_GNU_entry_view should not use address class forms, but constant forms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84620
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Comment on attachment 43539
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43539
candidate patch
>[IEPM] [PR debug/84620] use constant form for DW_AT_GNU_entry_view
>
>When outputting entry views in symbolic mode, we used to use a lbl_id,
>but was output as an addr, perhaps even in an indirect one, which is
>all excessive and undesirable for a small assembler-computed constant.
>Introduce a new value class for symbolic views, so that we can output
>the labels as constant data, using small forms that should suffice for
>any symbolic views. Ideally, we'd use uleb128, but then the compiler
>would have to defer .debug_info offset computation to the assembler: a
>symbolic uleb128 assembler constant in an attribute is not something
>GCC can deal with ATM.
>
>for gcc/ChangeLog
>
> PR debug/84620
> * dwarf2out.h (dw_val_class): Add dw_val_class_symview.
> (dw_val_node): Add val_symbolic_view.
> * dwarf2out.c (dw_val_equal_p): Handle symview.
> (add_AT_symview): New.
> (print_dw_val): Handle symview.
> (attr_checksum, attr_checksum_ordered): Likewise.
> (same_dw_val_p, size_of_die): Likewise.
> (value_format, output_die): Likewise.
> (add_high_low_attributes): Use add_AT_symview for entry_view.
>---
> gcc/dwarf2out.c | 40 +++-
> gcc/dwarf2out.h |4 +++-
> 2 files changed, 42 insertions(+), 2 deletions(-)
>
>diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
>index 41bb11558f69..b52edee845f2 100644
>--- a/gcc/dwarf2out.c
>+++ b/gcc/dwarf2out.c
>@@ -1434,6 +1434,8 @@ dw_val_equal_p (dw_val_node *a, dw_val_node *b)
> return a->v.val_die_ref.die == b->v.val_die_ref.die;
> case dw_val_class_fde_ref:
> return a->v.val_fde_index == b->v.val_fde_index;
>+case dw_val_class_symview:
>+ return strcmp (a->v.val_symbolic_view, b->v.val_symbolic_view) == 0;
> case dw_val_class_lbl_id:
> case dw_val_class_lineptr:
> case dw_val_class_macptr:
>@@ -3600,6 +3602,7 @@ static addr_table_entry *add_addr_table_entry (void *,
>enum ate_kind);
> static void remove_addr_table_entry (addr_table_entry *);
> static void add_AT_addr (dw_die_ref, enum dwarf_attribute, rtx, bool);
> static inline rtx AT_addr (dw_attr_node *);
>+static void add_AT_symview (dw_die_ref, enum dwarf_attribute, const char *);
> static void add_AT_lbl_id (dw_die_ref, enum dwarf_attribute, const char *);
> static void add_AT_lineptr (dw_die_ref, enum dwarf_attribute, const char *);
> static void add_AT_macptr (dw_die_ref, enum dwarf_attribute, const char *);
>@@ -5114,6 +5117,21 @@ add_AT_vms_delta (dw_die_ref die, enum dwarf_attribute
>attr_kind,
> add_dwarf_attr (die, &attr);
> }
>
>+/* Add a symbolic view identifier attribute value to a DIE. */
>+
>+static inline void
>+add_AT_symview (dw_die_ref die, enum dwarf_attribute attr_kind,
>+ const char *view_label)
>+{
>+ dw_attr_node attr;
>+
>+ attr.dw_attr = attr_kind;
>+ attr.dw_attr_val.val_class = dw_val_class_symview;
>+ attr.dw_attr_val.val_entry = NULL;
>+ attr.dw_attr_val.v.val_symbolic_view = xstrdup (view_label);
>+ add_dwarf_attr (die, &attr);
>+}
>+
> /* Add a label identifier attribute value to a DIE. */
>
> static inline void
>@@ -6457,6 +6475,9 @@ print_dw_val (dw_val_node *val, bool recurse, FILE
>*outfile)
> fprintf (outfile, "delta: @slotcount(%s-%s)",
> val->v.val_vms_delta.lbl2, val->v.val_vms_delta.lbl1);
> break;
>+case dw_val_class_symview:
>+ fprintf (outfile, "view: %s", val->v.val_symbolic_view);
>+ break;
> case dw_val_class_lbl_id:
> case dw_val_class_lineptr:
> case dw_val_class_macptr:
>@@ -6828,6 +6849,7 @@ attr_checksum (dw_attr_node *at, struct md5_ctx *ctx,
>int *mark)
>
> case dw_val_class_fde_ref:
> case dw_val_class_vms_delta:
>+case dw_val_class_symview:
> case dw_val_class_lbl_id:
> case dw_val_class_lineptr:
> case dw_val_class_macptr:
>@@ -7124,6 +7146,7 @@ attr_checksum_ordered (enum dwarf_tag tag, dw_attr_node
>*at,
> break;
>
> case dw_val_class_fde_ref:
>+case dw_val_class_symview:
> case dw_val_class_lbl_id:
> case dw_val_class_lineptr:
> case dw_val_class_macptr:
>@@ -7624,6 +7647,9 @@ same_dw_val_p (const dw_val_node *v1, const dw_val_node
>*v2, int *mark)
> case dw_val_class_die_ref:
> return same_die_p (v1->v.val_die_ref.die, v2->v.val_die_ref.die, mark);
>
>+case dw_val_class_symview:
>+ return strcmp (v1->v.val_symbolic_view, v2->v.val_symbolic_view) == 0;
>+
> case dw_val_class_fde_ref:
> case dw_val_class_vms_delta:
> case dw_val_class_lbl_id:
>@@
[Bug debug/84620] DW_AT_GNU_entry_view should not use address class forms, but constant forms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84620
--- Comment #3 from Jakub Jelinek ---
I meant to say:
The char * GTY ((tag ("dw_val_class_symview"))) val_symbolic_view; line should
come at the and of the union, not before the other classes.
The FIXMEs don't really look helpful, we are not going to change the offset
computation from compile time to assemble time, that would be terribly
expensive.
What guarantees the symview symbols always fit into 16 bits? Does something
punt if it needs more than 65536 views?
[Bug c++/84665] [7/8 Regression] internal compiler error: in build_value_init, at cp/init.c:343
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84665
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-03-02
CC||jakub at gcc dot gnu.org
Target Milestone|--- |7.4
Summary|internal compiler error: in |[7/8 Regression] internal
|build_value_init, at|compiler error: in
|cp/init.c:343 |build_value_init, at
||cp/init.c:343
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
struct S {} a[1];
template
void
foo ()
{
__attribute__ ((noinline (a[0]))) int c = 0;
}
Started with r239267, before it has been rejected:
pr84665.C: In function ‘void foo()’:
pr84665.C:7:41: error: wrong number of arguments specified for ‘noinline’
attribute
__attribute__ ((noinline (a[0]))) int c = 0;
^
[Bug c++/84664] [8 Regression] internal compiler error: in cp_perform_integral_promotions, at cp/typeck.c:2172
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84664
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-03-02
CC||jakub at gcc dot gnu.org,
||jason at gcc dot gnu.org
Target Milestone|--- |8.0
Summary|internal compiler error: in |[8 Regression] internal
|cp_perform_integral_promoti |compiler error: in
|ons, at cp/typeck.c:2172|cp_perform_integral_promoti
||ons, at cp/typeck.c:2172
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
void
foo ()
{
auto &b = 1;
[] { b > 0; };
}
Error-recovery ICE started with r253601, before that we got just:
pr84664.C: In function ‘void foo()’:
pr84664.C:4:13: error: cannot bind non-const lvalue reference of type ‘int&’ to
an rvalue of type ‘int’
auto &b = 1;
^
pr84664.C: In lambda function:
pr84664.C:5:12: error: ‘b’ is not captured
[] { b > 0; };
^
pr84664.C:5:4: note: the lambda has no capture-default
[] { b > 0; };
^
pr84664.C:4:9: note: ‘int& b’ declared here
auto &b = 1;
^
[Bug rtl-optimization/84614] [8 Regression] wrong code with u16->u128 extension at aarch64 -fno-split-wide-types -g3 --param=max-combine-insns=3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84614 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug c++/84661] internal compiler error: Segmentation fault (strip_array_types())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84661 Marek Polacek changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2018-03-02 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug target/70359] [6/7/8 Regression] Code size increase for ARM compared to gcc-5.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
--- Comment #22 from Aldy Hernandez ---
For the record, current mainline is even worse than when the testccase was
originally reported. We are now are at 116 bytes versus 96 for gcc-5-branch.
(In reply to Jakub Jelinek from comment #5)
> I see multiple points of the increases:
> r224048 added 4 bytes.
> r224995 added 8 bytes.
> r228318 added 4 bytes.
>
> Perhaps the middle one could change from
> (if (single_use (@2)
> || (TREE_CODE (@1) == INTEGER_CST && TREE_CODE (@3) == INTEGER_CST))
> to
> (if (single_use (@2)
> || (!optimize_size && TREE_CODE (@1) == INTEGER_CST && TREE_CODE (@3)
> == INTEGER_CST))
> (or some optimize*for_speed*)?
As Jakub mentions in comment #5, there are multiple patches that slowly bloated
the generated code, but perhaps it is a fool's errand to tackle them
individually. For instance, associating "buf + len - 1" differently in r224995
reduces the generated code by 8 bytes, but predicating the association by
optimize_for_speed seems fragile IMO.
Interestingly, disabling -ftree-forwprop, reduces the byte count to 92 which is
even smaller than gcc-5-branch, so perhaps worth pursuing. Even on x86,
disabling forwprop reduces the byte count by 13. And on both x86 and arm, we
get one less branch without forwprop.
The first forwprop change is to replace an equality by a greater than, which
hardly seems worthwhile (and even a longer byte sequence on x86), but perhaps
not a showstopper:
< if (ui_21 != 0)
---
> if (ui_7 > 9)
OTOH, the following changes things quite a bit on arm:
< p_22 = p_19 + 4294967295;
< *p_22 = 45;
---
> p_22 = p_8 + 4294967294;
> MEM[(char *)p_19 + 4294967295B] = 45;
For context, we are using p_8 which was the previous iteration's value for p_8
and then subtracting 2 to return p correctly. What the heck?
[local count: 118111601]:
_1 = ABS_EXPR ;
ui_13 = (unsigned int) _1;
len.0_2 = (sizetype) len_14(D);
_3 = len.0_2 + 4294967295;
p_16 = buf_15(D) + _3;
*p_16 = 0;
[local count: 1073741825]:
# ui_7 = PHI
# p_8 = PHI
_4 = ui_7 % 10;
_5 = (char) _4;
p_19 = p_8 + 4294967295;
_6 = _5 + 48;
MEM[base: p_19, offset: 0B] = _6;
ui_21 = ui_7 / 10;
if (ui_7 > 9)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 118111601]:
if (i_12(D) < 0)
goto ; [41.00%]
else
goto ; [59.00%]
[local count: 48425756]:
p_22 = p_8 + 4294967294;
MEM[(char *)p_19 + 4294967295B] = 45;
[local count: 118111601]:
# p_9 = PHI
return p_9;
This finally yields assembly without auto dec, and with an extra (forward!)
branch:
.L2:
mov r1, #10
mov r0, r6
bl __aeabi_uidivmod
umull r2, r3, r6, r8
add r1, r1, #48
cmp r6, #9
sub r4, r5, #1
strbr1, [r5, #-1]
lsr r3, r3, #3
bhi .L4 ;; extra forward branch
cmp r7, #0
movlt r3, #45
strblt r3, [r4, #-1]
sublt r4, r5, #2
mov r0, r4
pop {r4, r5, r6, r7, r8, pc}
.L4:
mov r5, r4
mov r6, r3
b .L2
whereas without -ftree-forwprop we get auto dec:
.L2:
mov r0, r5
mov r1, #10
bl __aeabi_uidivmod
umull r2, r3, r5, r7
add r1, r1, #48
lsrsr5, r3, #3
strbr1, [r4, #-1]! ;; auto dec, yay
bne .L2
cmp r6, #0
movlt r3, #45
strblt r3, [r4, #-1]! ;; auto dec, yay
mov r0, r4
pop {r4, r5, r6, r7, r8, pc}
[Bug c++/84661] [6/7/8 Regression] internal compiler error: Segmentation fault (strip_array_types())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84661 Marek Polacek changed: What|Removed |Added Target Milestone|--- |6.5 Summary|internal compiler error:|[6/7/8 Regression] internal |Segmentation fault |compiler error: |(strip_array_types()) |Segmentation fault ||(strip_array_types())
[Bug c++/84663] [6/7/8 Regression] internal compiler error: tree check: expected array_type, have error_mark in cp_complete_array_type, at cp/decl.c:8334
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84663
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-03-02
CC||jakub at gcc dot gnu.org,
||jason at gcc dot gnu.org
Target Milestone|--- |6.5
Summary|internal compiler error:|[6/7/8 Regression] internal
|tree check: expected|compiler error: tree check:
|array_type, have error_mark |expected array_type, have
|in cp_complete_array_type, |error_mark in
|at cp/decl.c:8334 |cp_complete_array_type, at
||cp/decl.c:8334
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
struct S {
typedef S T[8];
int f : -1ULL;
S () { struct { T d; } e[]; }
};
Regressed in between r118975, which gave just:
pr84663.C:3: warning: width of ‘S::f’ exceeds its type
pr84663.C: In constructor ‘S::S()’:
pr84663.C:4: error: storage size of ‘e’ isn't known
and r119009:
pr84663.C:3: warning: width of ‘S::f’ exceeds its type
pr84663.C:1: internal compiler error: in tree_low_cst, at tree.c:4556
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
In that range likely r118977.
Current trunk gives:
pr84663.C:3:12: warning: width of ‘S::f’ exceeds its type
int f : -1ULL;
^~~~
pr84663.C: In constructor ‘S::S()’:
pr84663.C:4:28: error: size of array is too large
S () { struct { T d; } e[]; }
^
pr84663.C:4:28: internal compiler error: tree check: expected array_type, have
error_mark in cp_complete_array_type, at cp/decl.c:8291
0x15df0f1 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9337
0x7f1b71 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/tree.h:3132
0x8cab45 cp_complete_array_type(tree_node**, tree_node*, bool)
../../gcc/cp/decl.c:8291
[Bug c++/84662] internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in is_bitfield_expr_with_lowered_type, at cp/typeck.c:1944
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84662 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Actually this one seems to be fixed.
[Bug fortran/81827] Large compile time with derived-type rrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81827 --- Comment #17 from Paul Thomas --- > There are two ways to fix this: > (i) Generate incomplete vtables, with the pointers to copy and finalise set > to null, for module derived types. This has the disadvantage that class > objects, such as the above, will still cause the compilation cascade; or > (ii) Call the functions associated with each derived type vtable at each > level. > > My preference would be for the latter and I will set to seeing how it can be > done. > > Cheers > > Paul Hi Richard, I am waiting for a light bulb moment on this problem. The source of the problem lies in the automatic deallocation and copying of allocatable derived type components. This is carried out be the chunk of code trans-array.c:8299-9396. The problem will remain, even if I carry out (i) and (ii) above. Every time that 'foo' in the reporter's testcase is allocated or if it were declared anywhere other than the main programme, the automatic deallocation/finalisation will occur and this will cause the exponential code bloat on each and every occasion. The 'obvious' way to deal with this is to ape the code in trans-array.c with library functions that make use of a reduced representation of the derived types (a list of offsets and pointers to the corresponding derived type component functions, where needed) or generated functions for each derived type. I am afraid that this will not happen overnight. Erik Edelman and I discussed this possibility originally but were put off by the complexity, compared with the present methodology, which has grown like Topsy since. I propose to work on the other regressions/bugs that I have caused and to come back to this for 9.0.0. Paul
[Bug target/70359] [6/7/8 Regression] Code size increase for ARM compared to gcc-5.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359 --- Comment #23 from Aldy Hernandez --- For the curious, on x86 with -ftree-forwprop we get an additional jump: inttostr: .LFB0: .cfi_startproc movl%edi, %eax movslq %edx, %rdx movl$-858993459, %r9d sarl$31, %eax leaq-1(%rsi,%rdx), %rsi movl%eax, %ecx movb$0, (%rsi) xorl%edi, %ecx subl%eax, %ecx jmp .L2;; boo! .p2align 4,,10 .p2align 3 .L4: movq%r8, %rsi movl%edx, %ecx .L2: ... ... ... movb$45, -1(%r8) leaq-2(%rsi), %r8 Not to mention that the last two instructions are slower (ok, larger) than without forwprop, probably because rsi encodes better than r8. movb$45, -1(%rsi) subq$1, %rsi Also, the inequality comparison on x86 is shorter than comparing with > 9. But that's probably irrelevant. All in all: x86 -ftree-forwprop:139 bytes x86 -fno-tree-forwprop: 126 bytes
[Bug demangler/84668] New: c++filt: out of memory allocating 18446744071696285694 bytes after a total of 135168 bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84668 Bug ID: 84668 Summary: c++filt: out of memory allocating 18446744071696285694 bytes after a total of 135168 bytes Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: vegard.nossum at gmail dot com Target Milestone: --- $ c++filt '__H5z55_H5z555' c++filt: out of memory allocating 18446744071696285694 bytes after a total of 135168 bytes $ xgcc --version xgcc (GCC) 8.0.1 20180301 (experimental) Built from git c435a9e730c6e8f10da09d58b4fc9aaeb401b0d5 (r258097). Found by AFL.
[Bug target/70359] [6/7/8 Regression] Code size increase for ARM compared to gcc-5.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359 --- Comment #24 from rguenther at suse dot de --- > OTOH, the following changes things quite a bit on arm: > > < p_22 = p_19 + 4294967295; > < *p_22 = 45; > --- > > p_22 = p_8 + 4294967294; > > MEM[(char *)p_19 + 4294967295B] = 45; > > For context, we are using p_8 which was the previous iteration's value for p_8 > and then subtracting 2 to return p correctly. What the heck? > >[local count: 118111601]: > _1 = ABS_EXPR ; > ui_13 = (unsigned int) _1; > len.0_2 = (sizetype) len_14(D); > _3 = len.0_2 + 4294967295; > p_16 = buf_15(D) + _3; > *p_16 = 0; > >[local count: 1073741825]: > # ui_7 = PHI > # p_8 = PHI > _4 = ui_7 % 10; > _5 = (char) _4; > p_19 = p_8 + 4294967295; > _6 = _5 + 48; > MEM[base: p_19, offset: 0B] = _6; > ui_21 = ui_7 / 10; > if (ui_7 > 9) > goto ; [89.00%] > else > goto ; [11.00%] > >[local count: 118111601]: > if (i_12(D) < 0) > goto ; [41.00%] > else > goto ; [59.00%] > >[local count: 48425756]: > p_22 = p_8 + 4294967294; > MEM[(char *)p_19 + 4294967295B] = 45; > >[local count: 118111601]: > # p_9 = PHI > return p_9; forwprop aggressively canonicalizes memory references by forwarding all constant address adjustments into its constant offset part. What usually makes things complicated in the end is when for an IV we get overlapping life-ranges for the before and after value because that inhibits coalescing. Is this what happens here? We do have some code trying to rectify IV-related stuff for coalescing, maybe that can be enhanced to handle these kind of cases... I fear that in the end somehow exposing autoinc/dec on GIMPLE might be the only way to truly fix and maintain good code...
[Bug fortran/81827] Large compile time with derived-type rrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81827 --- Comment #18 from rguenther at suse dot de --- On Fri, 2 Mar 2018, pault at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81827 > > --- Comment #17 from Paul Thomas --- > > > There are two ways to fix this: > > (i) Generate incomplete vtables, with the pointers to copy and finalise set > > to null, for module derived types. This has the disadvantage that class > > objects, such as the above, will still cause the compilation cascade; or > > (ii) Call the functions associated with each derived type vtable at each > > level. > > > > My preference would be for the latter and I will set to seeing how it can be > > done. > > > > Cheers > > > > Paul > > Hi Richard, > > I am waiting for a light bulb moment on this problem. The source of the > problem > lies in the automatic deallocation and copying of allocatable derived type > components. This is carried out be the chunk of code trans-array.c:8299-9396. > The problem will remain, even if I carry out (i) and (ii) above. Every time > that 'foo' in the reporter's testcase is allocated or if it were declared > anywhere other than the main programme, the automatic > deallocation/finalisation > will occur and this will cause the exponential code bloat on each and every > occasion. > > The 'obvious' way to deal with this is to ape the code in trans-array.c with > library functions that make use of a reduced representation of the derived > types (a list of offsets and pointers to the corresponding derived type > component functions, where needed) or generated functions for each derived > type. I am afraid that this will not happen overnight. Erik Edelman and I > discussed this possibility originally but were put off by the complexity, > compared with the present methodology, which has grown like Topsy since. > > I propose to work on the other regressions/bugs that I have caused and to come > back to this for 9.0.0. Fair enough. I read some original comment in this bug that the recursive initialization is bogus in the first place though, so you say all allocations are actually necessary?
[Bug c++/84663] [6/7/8 Regression] internal compiler error: tree check: expected array_type, have error_mark in cp_complete_array_type, at cp/decl.c:8334
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84663
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #2 from Marek Polacek ---
I think this should be enough:
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -8323,7 +8323,7 @@ cp_complete_array_type (tree *ptype, tree initial_value,
bool do_default)
bits. See also complete_type which does the same thing for arrays
of fixed size. */
type = *ptype;
- if (TYPE_DOMAIN (type))
+ if (type != error_mark_node && TYPE_DOMAIN (type))
{
elt_type = TREE_TYPE (type);
TYPE_NEEDS_CONSTRUCTING (type) = TYPE_NEEDS_CONSTRUCTING (elt_type);
[Bug c++/84663] [6/7/8 Regression] internal compiler error: tree check: expected array_type, have error_mark in cp_complete_array_type, at cp/decl.c:8334
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84663 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug fortran/84219] Failure to generate error for IO of transfer intrinsic, when MOLD has derived type components.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84219 Paul Thomas changed: What|Removed |Added Summary|[8 Regression] ICE: Invalid |Failure to generate error |expression in |for IO of transfer |gfc_target_interpret_expr |intrinsic, when MOLD has ||derived type components. --- Comment #5 from Paul Thomas --- This version of the testcase (which I inadvertently committed the first time): program p type t integer, allocatable :: t end type type(t) :: x integer :: foo = -1 print *, transfer(foo, x) end generates no error and outputs -1 for gfortran going back to at least 6.4.1. This is manifestly wrong and the error should be generated. I am changing the summary accordingly. Paul
[Bug c++/84661] [6/7/8 Regression] internal compiler error: Segmentation fault (strip_array_types())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84661 --- Comment #2 from Jakub Jelinek --- ICEs starting with r208426, before that we rejected it with: pr84661.C:3:36: error: expected primary-expression before ‘auto’ void foo (decltype(((a = 0) || ((auto); ^ pr84661.C:3:36: error: expected ‘)’ before ‘auto’ pr84661.C:3:45: error: expected ‘)’ before ‘;’ token void foo (decltype(((a = 0) || ((auto); ^ pr84661.C:3:45: error: expected ‘)’ before ‘;’ token pr84661.C:3:45: error: expected ‘)’ before ‘;’ token pr84661.C:3:13: error: expected identifier before ‘decltype’ void foo (decltype(((a = 0) || ((auto); ^ pr84661.C:3:36: error: expected primary-expression before ‘auto’ void foo (decltype(((a = 0) || ((auto); ^ pr84661.C:3:36: error: expected ‘)’ before ‘auto’ pr84661.C:3:45: error: expected ‘)’ before ‘;’ token void foo (decltype(((a = 0) || ((auto); ^ pr84661.C:3:45: error: expected ‘)’ before ‘;’ token pr84661.C:3:45: error: expected ‘)’ before ‘;’ token pr84661.C:3:13: error: expected ‘,’ or ‘...’ before ‘decltype’ void foo (decltype(((a = 0) || ((auto); ^ I guess this is a dup of PR84642 and PR84647 though.
[Bug c++/84661] [6/7/8 Regression] internal compiler error: Segmentation fault (strip_array_types())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84661
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Slightly cleaned up testcase, so that it isn't that invalid:
struct S {
int &a;
void foo (decltype(((a = 0) || ((auto);
};
[Bug c++/84662] internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in is_bitfield_expr_with_lowered_type, at cp/typeck.c:1944
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84662
--- Comment #2 from Jakub Jelinek ---
Started with r230365.
Before it got rejected with
pr84662.C:2:3: error: expected constructor, destructor, or type conversion
before ‘(’ token
a (__attribute__((c(0 && int() - ([] {} && b) || auto;
^
[Bug c++/84662] [6/7/8 Regression] internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in is_bitfield_expr_with_lowered_type, at cp/typeck.c:1944
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84662 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2018-03-02 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |6.5 Summary|internal compiler error:|[6/7/8 Regression] internal |tree check: expected class |compiler error: tree check: |'type', have 'exceptional' |expected class 'type', have |(error_mark) in |'exceptional' (error_mark) |is_bitfield_expr_with_lower |in |ed_type, at |is_bitfield_expr_with_lower |cp/typeck.c:1944|ed_type, at ||cp/typeck.c:1944 Ever confirmed|0 |1 --- Comment #3 from Jakub Jelinek --- (In reply to Marek Polacek from comment #1) > Actually this one seems to be fixed. I can still reproduce with latest trunk.
[Bug middle-end/84603] -finline-limit not accepted in attribute and #pragma optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84603 --- Comment #5 from Martin Liška --- (In reply to Richard Biener from comment #4) > Note this is an option having IPA effect so it doesn't make sense to specify > it on a per-function level. Thus INVALID. > > That is, the effect is setting some --params but their values are always > global and not per function. So it's more an implementation "defect", some > of the > inliner parameters might make sense to constrain on a per-function level. And do you Richi agree with option obsoleting?
[Bug c++/84664] [8 Regression] internal compiler error: in cp_perform_integral_promotions, at cp/typeck.c:2172
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84664 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Untested fix: --- a/gcc/cp/typeck.c +++ b/gcc/cp/typeck.c @@ -2161,6 +2161,8 @@ cp_perform_integral_promotions (tree expr, tsubst_flags_t complain) tree promoted_type; expr = mark_rvalue_use (expr); + if (error_operand_p (expr)) +return error_mark_node; /* [conv.prom]
[Bug c++/84669] New: Error displaying in wrong file for unclosed scopes in headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84669
Bug ID: 84669
Summary: Error displaying in wrong file for unclosed scopes in
headers
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: schlong at cock dot li
Target Milestone: ---
Created attachment 43543
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43543&action=edit
Preprocessed file
G++ version:
g++ (Debian 7.3.0-5) 7.3.0
Command line:
g++ ./main.cpp
Compiler output:
./main.cpp:11:1: error: expected ‘}’ at end of input
}
^
Expected behavior:
g++ shows an error indicating a missing closing curly bracket in other.hpp or
keeps the error as it is but also shows where the bracket has been opened.
Since there's no option to add multiple files and you don't want archives, here
are
Content of other.hpp:
namespace NS
{
// Missing closing curly bracket here
Content of main.cpp:
#include "other.hpp"
// }
// Closing curly bracket for @NS. Un-commenting this causes successful
// compilation.
int main(int argc, char *argv[])
{
return 0;
}
[Bug target/70359] [6/7/8 Regression] Code size increase for ARM compared to gcc-5.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359 --- Comment #25 from Richard Biener --- So we indeed have p_20 and p_9 live as p_9 is used after the loop. Originally this wasn't the case but fold_stmt in the first forwprop pass does this by means of following use-def chains. As I usually say the user could have written the loop that way so a real fix is to try undoing this somewhere. Sprinkling single_use checks in match.pd (or simple_iv_increment_p-like checks) doesn't look like a sustainable approach to me.
[Bug c++/84662] [6/7/8 Regression] internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in is_bitfield_expr_with_lowered_type, at cp/typeck.c:1944
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84662 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 43544 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43544&action=edit gcc8-pr84662.patch Untested fix.
[Bug target/70359] [6/7/8 Regression] Code size increase for ARM compared to gcc-5.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359 --- Comment #26 from Richard Biener --- So I suggest to look at insert_backedge_copies () to see whether replacing out-of-loop pre-inc uses with the post-inc value is possible.
[Bug demangler/84668] c++filt: out of memory allocating 18446744071696285694 bytes after a total of 135168 bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84668 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-03-02 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug c++/84665] [7/8 Regression] internal compiler error: in build_value_init, at cp/init.c:343
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84665
--- Comment #2 from Jakub Jelinek ---
We don't ICE with
struct S { int s; } a[1];
but do ICE with e.g.
struct S { constexpr S () {} } a[1];
build_value_init has:
341 /* The AGGR_INIT_EXPR tweaking below breaks in templates. */
342 gcc_assert (!processing_template_decl
343 || (SCALAR_TYPE_P (type) || TREE_CODE (type) ==
ARRAY_TYPE));
early, and type in this case is RECORD_TYPE S.
Called from:
2456 /* If it's within the array bounds but doesn't have an explicit
2457 initializer, it's value-initialized. */
2458 tree val = build_value_init (elem_type, tf_warning_or_error);
2459 return cxx_eval_constant_expression (ctx, val, lval, non_constant_p,
2460 overflow_p);
because a doesn't have explicit initializer.
No idea what to do here...
[Bug c/17426] Emit mandatory warning for manual expansions of offsetof
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17426 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #6 from Eric Gallager --- (In reply to Giovanni Bajo from comment #3) > (In reply to comment #2) > > > it's only where an integer constant expression is > > required, as in bug 17396 (static array dimension) or for case labels, > > enum values, bit-field widths, null pointer constants, designators for > > array initializers, that there's a problem. > > Thanks for the list. I will try to activate the warning in these contexts, > but > I do not know the C frontend, so maybe I'll need to do this incrementally. > > > fits the long-established > > GCC extension of symbolic difference constant expressions if being used in > > a static initializer > > This could be a pedwarn, then, right? Are you still working on this?
[Bug target/30082] Expansion of lceil and lfloor could use if-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30082
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment #4 from Eric Gallager ---
(In reply to Richard Biener from comment #3)
> long foo(float x)
> {
> return __builtin_lfloorf(x);
> }
>
> generates
>
> foo:
> .LFB2:
> cvttss2siq %xmm0, %rax
> cvtsi2ssq %rax, %xmm1
> leaq-1(%rax), %rdx
> comiss %xmm0, %xmm1
> cmova %rdx, %rax
> ret
>
> the adc/sbb variants are no longer generated.
Are you still working on this?
[Bug tree-optimization/33915] iv folding fails with pointer iterations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33915 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #9 from Eric Gallager --- (In reply to Zdenek Dvorak from comment #3) > It does not reproduce for me on i686-linux, either. Do you pass any special > flags to configure? If it didn't reproduce for you does it make sense for you still to be the assignee for this?
[Bug ipa/84658] [7/8 Regression] -O3 -fmerge-all-constants causes incorrect for-each loop generation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84658
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Adjusted testcase for the testsuite:
// PR ipa/84658
// { dg-do run }
// { dg-options "-O3 -fmerge-all-constants" }
// { dg-output "foo 0, 1, 2, 3, 4, 5, 8, 15, 16, 17, 512, 1020, 1021, 1022,
1023, 1024, end.*" }
// { dg-output "bar 0, 1, 2, 3, 4, 5, 8, 15, 16, 17, 512, 1020, 1021, 1022,
1023, 1024, end" }
extern "C" int printf (const char *, ...);
void
foo ()
{
const int a[] = { 0, 1, 2, 3, 4, 5, 8, 15, 16, 17, 512, 1020, 1021, 1022,
1023, 1024 };
for (int b : a)
printf ("%d, ", b);
}
void
bar ()
{
const int a[] = { 0, 1, 2, 3, 4, 5, 8, 15, 16, 17, 512, 1020, 1021, 1022,
1023, 1024 };
for (int b : a)
printf ("%d, ", b);
}
int
main ()
{
printf ("foo ");
foo ();
printf ("end\nbar ");
bar ();
printf ("end\n");
}
[Bug tree-optimization/19347] Invariant load not moved out of loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19347 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #5 from Eric Gallager --- (In reply to Ira Rosen from comment #2) > Created attachment 7916 [details] > Full testcase Are you still working on this at all?
[Bug target/36381] preprocessing, fortran: register include paths and framework
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36381 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=36348 --- Comment #1 from Eric Gallager --- (In reply to Daniel Franke from comment #0) > Follow up to PR36348: > > "[darwin-f.c] need[s] to implement darwin_register_frameworks, as well as > the -iframework option implemented by handle_c_option in darwin-c.c. I > suggest splitting that part of darwin-c.c into a new file darwin-cpp.c that > is included in all three of c_target_objs, cxx_target_objs, > fortran_target_objs. > > Furthermore, given that the target hook TARGET_HANDLE_C_OPTION is > implemented only by darwin-c.c, it makes sense to rename it to > TARGET_HANDLE_CPP_OPTION and call it from the Fortran front-end too." > > Reference: http://gcc.gnu.org/ml/fortran/2008-05/msg00348.html Are you still working on this? If so, the status can be ASSIGNED, otherwise, it'd make sense to remove yourself as the assignee.
[Bug other/44803] LIBRARY_PATH should work on cross-compilers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44803 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #4 from Eric Gallager --- (In reply to Felipe Contreras from comment #3) > Is this not clear? > > It would be useful to cross-compile like this: > > export C_INCLUDE_PATH=/opt/arm/ffmpeg/include > export LIBRARY_PATH=/opt/arm/ffmpeg/lib > > But LIBRARY_PATH is ignored. this bug showed up in my Assignee_but_not_ASSIGNED saved search. Are you still working on this?
[Bug target/36503] x86 can use x >> -y for x >> 32-y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36503
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment #10 from Eric Gallager ---
(In reply to Uroš Bizjak from comment #7)
> Created attachment 21972 [details]
> Patch that implements suggested optimization
>
> Attached patch compiles the test from comment #0 to the proposed code:
>
> int test (int a, int b)
> {
> return a >> (32 - b);
> }
>
> -O2 -m32:
>
> movl8(%esp), %ecx
> movl4(%esp), %eax
> negl%ecx
> sarl%cl, %eax
> ret
>
> -O2 -m64:
>
> negl%esi
> movl%edi, %eax
> movl%esi, %ecx
> sarl%cl, %eax
> ret
Please send the patch to the gcc-patches mailing list if it still applies and
works. And change the status to ASSIGNED if you're still working on it.
[Bug target/30974] pdp11-dec-bsd will not successfully build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30974 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #5 from Eric Gallager --- (In reply to Paul Koning from comment #4) > At this point pdp11-*-bsd has been removed. It probably could be put back > in. > > The error is caused by the fact that gcc is generating assembly code for the > 2BSD unix assembler, but you're feeding it to gas. The "other" assembly > format, even though it's called "DEC assembler" is actually the format > expected by pdp11-gas. > > As a workaround you can compile with -mdec-asm. What we really need here is > a --with-gnu-as configure switch that tells the pdp11 target code to default > to the "dec" (really GNU) assembler format. Given that it doesn't seem to have been put back in in all this time, would it make sense to close this bug?
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #30 from Eric Gallager --- (In reply to rguent...@suse.de from comment #26) > On Wed, 16 Mar 2011, joe at mcknight dot de wrote: > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 > > > > --- Comment #25 from joe at mcknight dot de 2011-03-16 12:58:50 UTC --- > > (In reply to comment #24) > > > > > Well, it confirmed that void_list_node is not used, but I can't > > > reproduce this fact. > > > > Then how should we go on with this? As said, I can also only reproduce it > > under > > very special circumstances but unfortunately these were the default > > circumstances for our compiler runs. > > You should try to debug this yourself then. > > > Can we use anything else to terminate the loop? Is there any other debug > > output > > that would be helpful for you? > > Well, try to figure out who creates that void_list_node clone. > > You can use !VOID_TYPE_P (TREE_VALUE (arg)) instead. > > Richard. So, if the responsibility is on Joe to debug, does it make sense for you to still be the assignee then?
[Bug c++/19073] cp_binding_level::names not returning all decls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19073 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #12 from Eric Gallager --- (In reply to Gabriel Dos Reis from comment #5) > Subject: Re: cp_namespace_decl not returning all decls > > "pinskia at gcc dot gnu dot org" writes: > > | I think -fdump-translation-unit should be removed, it is only useful > > Removing -fdump-translation-unit is a good step to make GCC more > useless; it does not fix the problem. > > -- Gaby -fdump-translation-unit has been removed for gcc 8
[Bug target/30082] Expansion of lceil and lfloor could use if-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30082 Richard Biener changed: What|Removed |Added Last reconfirmed|2007-08-28 10:58:39 |2018-3-2 Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #5 from Richard Biener --- No.
[Bug rtl-optimization/951] Documentation of compiler passes and sources very out of date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=951 Eric Gallager changed: What|Removed |Added Keywords||deferred CC||egallager at gcc dot gnu.org, ||sandra at codesourcery dot com --- Comment #9 from Eric Gallager --- If the documentation mentioned by this bug was very out-of-date in 2000, what does that make it now 18 years later? (In reply to Steven Bosscher from comment #8) > Not really related to tree-ssa, move to 3.5 > Besides, the tree-ssa passes _are_ properly documented. At best, we make a > few other flags redundant :-) Taking this as cause for the "deferred" keyword
[Bug ipa/84658] [7/8 Regression] -O3 -fmerge-all-constants causes incorrect for-each loop generation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84658
--- Comment #3 from Jakub Jelinek ---
Seems the inliner immediately undoes what ICF did and both get inlined into
main as well.
The aD.2373 array becomes an alias of aD.2363.
And the real bug is introduced in ccp2:
Folding predicate __for_begin_5 == &MEM[(void *)&a + 64B] to 0
on previously:
intD.9 bD.2396;
const intD.9 * __for_beginD.2397;
static const intD.9 aD.2363[16] = {0, 1, 2, 3, 4, 5, 8, 15, 16, 17, 512,
1020, 1021, 1022, 1023, 1024};
intD.9 bD.2394;
const intD.9 * __for_beginD.2395;
static const intD.9 aD.2373[16];
[local count: 63136019]:
printf ("foo ");
[local count: 1073741820]:
# __for_begin_8 = PHI <&aD.2363(2), __for_begin_10(4)>
if (__for_begin_8 == &MEM[(voidD.46 *)&aD.2363 + 64B])
goto ; [5.88%]
else
goto ; [94.12%]
[local count: 1010605800]:
b_9 = *__for_begin_8;
printf ("%d, ", b_9);
__for_begin_10 = __for_begin_8 + 4;
goto ; [100.00%]
[local count: 63136019]:
printf ("end\nbar ");
[local count: 1073741825]:
# __for_begin_5 = PHI <&aD.2373(5), __for_begin_7(7)>
if (__for_begin_5 == &MEM[(voidD.46 *)&aD.2373 + 64B])
goto ; [5.88%]
else
goto ; [94.12%]
[local count: 1010605805]:
b_6 = *__for_begin_5;
printf ("%d, ", b_6);
__for_begin_7 = __for_begin_5 + 4;
goto ; [100.00%]
[local count: 63136019]:
__builtin_puts (&"end"[0]);
[Bug tree-optimization/84670] New: [8 Regression] ICE: in compute_antic_aux, at tree-ssa-pre.c:2148 with -O2 -fno-tree-dominator-opts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84670 Bug ID: 84670 Summary: [8 Regression] ICE: in compute_antic_aux, at tree-ssa-pre.c:2148 with -O2 -fno-tree-dominator-opts Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Created attachment 43545 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43545&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O2 -fno-tree-dominator-opts testcase.c during GIMPLE pass: pre testcase.c: In function 'foo': testcase.c:4:1: internal compiler error: in compute_antic_aux, at tree-ssa-pre.c:2148 foo (void) ^~~ 0xf6fd2e compute_antic_aux /repo/gcc-trunk/gcc/tree-ssa-pre.c:2148 0xf6fd2e compute_antic /repo/gcc-trunk/gcc/tree-ssa-pre.c:2364 0xf6fd2e execute /repo/gcc-trunk/gcc/tree-ssa-pre.c:4131 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-trunk-258129-checking-yes-rtl-df-extra-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-258129-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-258129-checking-yes-rtl-df-extra-amd64 Thread model: posix gcc version 8.0.1 20180302 (experimental) (GCC) This is a recent regression: r258129 - FAIL r258075 - OK
[Bug tree-optimization/19347] Invariant load not moved out of loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19347 Richard Biener changed: What|Removed |Added Last reconfirmed|2006-02-16 21:28:32 |2018-3-2 Blocks||53947 Assignee|irar at il dot ibm.com |unassigned at gcc dot gnu.org --- Comment #6 from Richard Biener --- Reconfirmed. Note we do vectorize the loop now but we add a runtime check for the aliasing (and not move the invariant out either). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug c++/84657] Wrong exception type matched in catch clause when compiled with address sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84657 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-03-02 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- It still happens with trunk, but you need to use -fPIC (which your Arch Linux system compiler enables by default).
[Bug c++/84657] Wrong exception type matched in catch clause when compiled with address sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84657 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- which makes this an exact dup of PR 78651. *** This bug has been marked as a duplicate of bug 78651 ***
[Bug c++/78651] Incorrect exception handling when catch clause uses local class and PIC and sanitizer are active
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78651 Jonathan Wakely changed: What|Removed |Added CC||mikezackles at gmail dot com --- Comment #2 from Jonathan Wakely --- *** Bug 84657 has been marked as a duplicate of this bug. ***
[Bug ipa/84658] [7/8 Regression] -O3 -fmerge-all-constants causes incorrect for-each loop generation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84658
Martin Liška changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
--- Comment #4 from Martin Liška ---
Yes, it's cpp2 that removes the check, IPA inlining is not needed:
$ cat ~/Programming/testcases/pr84658.cpp
#include
const int kTestCasesFoo[] = { 0, 1, 2, 3, 4, 5, 8, 15, 16, 17, 512, 1020, 1021,
1022, 1023, 1024 };
const int kTestCasesBar[] = { 0, 1, 2, 3, 4, 5, 8, 15, 16, 17, 512, 1020, 1021,
1022, 1023, 1024 };
void Foo() {
for (int count : kTestCasesFoo) {
printf("foo: %d\n", count);
}
}
void Bar() {
for (int count : kTestCasesBar) {
printf("bar: %d\n", count);
}
}
int main() {
Foo();
Bar();
}
$ ./xg++ -B. ~/Programming/testcases/pr84658.cpp -O2 -fno-ipa-icf-functions
-fmerge-all-constants -c -fno-inline
[Bug other/704] --help and --version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=704 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #13 from Eric Gallager --- gcc-ar, gcc-nm, and gcc-ranlib all fail for me when passed --help or --version like this: /usr/local/bin/gcc-ranlib: Cannot find plugin 'liblto_plugin.so' IMO the --help or --version output should be printed before looking for the plugin.
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650
Richard Biener changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|--- |FIXED
--- Comment #31 from Richard Biener ---
Original issue was fixed.
Please open a new bugreport if there's an issue you think should be fixed on
current trunk preferably without a plugin but using some -fdump-* functions.
There's now -fdump-tree-*-gimple which should yield (roughly) compilable
code with -fgimple. At least the function definitions should have the
correct prototypes.
Your last testcase (on Linux, don't have accces to Solaris) gets me
in t.c.004t.gimple with -fdump-tree-gimple-gimple
void __GIMPLE ()
foo (char * const buf, const int bufsz)
{
}
which looks fine.
[Bug c++/78651] Incorrect exception handling when catch clause uses local class and PIC and sanitizer are active
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78651
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-03-02
Ever confirmed|0 |1
--- Comment #3 from Jonathan Wakely ---
Confirmed:
struct A { };
namespace {
void thisThrows() {
throw A();
}
struct SomeRandomType {};
}
int main() {
try {
thisThrows();
}
catch(SomeRandomType) {
throw;
}
catch(A) {
}
}
$ g++ throws.cc && ./a.out
$ g++ throws.cc -fPIC && ./a.out
$ g++ throws.cc -fsanitize=address && ./a.out
$ g++ throws.cc -fsanitize=address -fPIC && ./a.out
terminate called after throwing an instance of 'A'
Aborted (core dumped)
[Bug ipa/84658] [7/8 Regression] -O3 -fmerge-all-constants causes incorrect for-each loop generation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84658 --- Comment #5 from Martin Liška --- Created attachment 43546 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43546&action=edit Problematic CCP2 dump file Jakub do you understand why is the folding happens? I'm not skilled in CCP.
[Bug ipa/84658] [7/8 Regression] -O3 -fmerge-all-constants causes incorrect for-each loop generation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84658 --- Comment #6 from Martin Liška --- (In reply to Jakub Jelinek from comment #3) > Seems the inliner immediately undoes what ICF did and both get inlined into > main as well. It's not undoing the decision because the symbol (Bar) is global. So it both inlines into main and the wrapper is preserved. But it's not triggering the issue.
[Bug libstdc++/84671] New: Chrono literals don't accept apostrophe as separator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84671
Bug ID: 84671
Summary: Chrono literals don't accept apostrophe as separator
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: curdeius at gmail dot com
Target Milestone: ---
Created attachment 43547
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43547&action=edit
bug-chrono-literals-apostrophe-repro
Concerned GCC versions: from 5.0.0 onwards (tested up to GCC 8.0.1 trunk from
2018-02-28).
GCC 4.9.3 accepts the code.
Online demo: http://coliru.stacked-crooked.com/a/eed5e2702d1daaa8.
When using UDLs from std::literals::chrono_literals, rejects the use of
apostrophes as delimiters.
E.g.:
```
using namespace std::literals::chrono_literals;
auto ns_ok = 12113ns;
auto ns_fail = 12'113ns;
```
Compiling this code (or precisely the attachment) using `g++ prog.cc
-std=c++14` or any standard from C++14 onwards gives the message:
```
In file included from /opt/wandbox/gcc-head/include/c++/8.0.1/chrono:42,
from prog.cc:1:
/opt/wandbox/gcc-head/include/c++/8.0.1/bits/parse_numbers.h: In instantiation
of 'struct std::__parse_int::_Number_help<10, 100, '\'', '1', '1', '3'>':
/opt/wandbox/gcc-head/include/c++/8.0.1/bits/parse_numbers.h:195:57:
recursively required from 'struct std::__parse_int::_Number_help<10, 1000, '2',
'\'', '1', '1', '3'>'
/opt/wandbox/gcc-head/include/c++/8.0.1/bits/parse_numbers.h:195:57: required
from 'struct std::__parse_int::_Number_help<10, 1, '1', '2', '\'', '1',
'1', '3'>'
/opt/wandbox/gcc-head/include/c++/8.0.1/bits/parse_numbers.h:208:12: required
from 'struct std::__parse_int::_Number<10, '1', '2', '\'', '1', '1', '3'>'
/opt/wandbox/gcc-head/include/c++/8.0.1/bits/parse_numbers.h:248:12: required
from 'struct std::__parse_int::_Parse_int<'1', '2', '\'', '1', '1', '3'>'
/opt/wandbox/gcc-head/include/c++/8.0.1/chrono:905:67: required from
'constexpr _Dur std::literals::chrono_literals::__check_overflow() [with _Dur =
std::chrono::duration >; char ..._Digits =
{'1', '2', '\'', '1', '1', '3'}]'
/opt/wandbox/gcc-head/include/c++/8.0.1/chrono:961:65: required from
'constexpr std::chrono::nanoseconds
std::literals::chrono_literals::operator""ns() [with char ..._Digits = {'1',
'2', '\'', '1', '1', '3'}; std::chrono::nanoseconds =
std::chrono::duration >]'
prog.cc:5:16: required from here
/opt/wandbox/gcc-head/include/c++/8.0.1/bits/parse_numbers.h:196:42: error:
static assertion failed: integer literal does not fit in unsigned long long
static_assert((type::value / _Pow) == __digit::value,
~^~
```
The problem seems to come from struct _Number_help that does not take
apostrophes '\'' into account
(https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/parse_numbers.h#L188).
[Bug tree-optimization/84670] [8 Regression] ICE: in compute_antic_aux, at tree-ssa-pre.c:2148 with -O2 -fno-tree-dominator-opts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84670 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-03-02 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |8.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- *sigh*, mine.
[Bug tree-optimization/84670] [8 Regression] ICE: in compute_antic_aux, at tree-ssa-pre.c:2148 with -O2 -fno-tree-dominator-opts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84670 Franz Sirl changed: What|Removed |Added CC||sirl at gcc dot gnu.org --- Comment #2 from Franz Sirl --- Created attachment 43548 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43548&action=edit another testcase You just beat me to open this report :D I'm adding another (but not so small) testcase.
[Bug ipa/84658] [7/8 Regression] -O3 -fmerge-all-constants causes incorrect for-each loop generation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84658 --- Comment #7 from Jakub Jelinek --- Tried to look at the ccp2-uid-details dump and can't make any sense from that, so I think we need Richi on this. A guess would be that something somewhere looks through the alais at one point and not the other point, it is referenced just in # __for_begin_5 = PHI <&aD.2373(5), __for_begin_7(7)> if (__for_begin_5 == &MEM[(voidD.46 *)&aD.2373 + 64B]) and similarly # __for_begin_8 = PHI <&aD.2363(2), __for_begin_10(4)> if (__for_begin_8 == &MEM[(voidD.46 *)&aD.2363 + 64B]) for the variable we've kept as variable, not alias, or something is upset by the const variable without initializer. The alias has been created and its DECL_INITIAL cleared by sem_variable::merge, 2265 DECL_INITIAL (alias->decl) = NULL; 2266 ((symtab_node *)alias)->call_for_symbol_and_aliases (clear_decl_rtl, 2267 NULL, true); 2268 alias->need_bounds_init = false; 2269 alias->remove_all_references (); 2270 if (TREE_ADDRESSABLE (alias->decl)) 2271original->call_for_symbol_and_aliases (set_addressable, NULL, true); 2272 2273 varpool_node::create_alias (alias_var->decl, decl); 2274 alias->resolve_alias (original); 2275 2276 if (dump_file) 2277fprintf (dump_file, "Unified; Variable alias has been created.\n"); Not really sure if it isn't an optimization problem if optimizers don't see the initializer (if they are smart enough to look through the alias).
[Bug ipa/84658] [7/8 Regression] -O3 -fmerge-all-constants causes incorrect for-each loop generation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84658 --- Comment #8 from Jakub Jelinek --- (In reply to Martin Liška from comment #6) > (In reply to Jakub Jelinek from comment #3) > > Seems the inliner immediately undoes what ICF did and both get inlined into > > main as well. > > It's not undoing the decision because the symbol (Bar) is global. So it both > inlines into main and the wrapper is preserved. But it's not triggering the > issue. Well, it does, because it inlines Foo back into Bar, so all the ICF effort except for creating the variable alias is gone.
[Bug libstdc++/84671] [6/7/8 Regression] Chrono literals don't accept apostrophe as separator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84671
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Known to work|4.9.3 |4.9.4
Keywords||rejects-valid
Last reconfirmed||2018-03-02
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Ever confirmed|0 |1
Summary|Chrono literals don't |[6/7/8 Regression] Chrono
|accept apostrophe as|literals don't accept
|separator |apostrophe as separator
Known to fail|5.1.0, 5.2.0, 5.3.0, 6.3.0, |6.4.0, 7.3.0, 8.0
|7.1.0, 7.2.0, 8.0.1 |
--- Comment #1 from Jonathan Wakely ---
Complete testcse:
#include
using namespace std::literals::chrono_literals;
auto ns_ok = 12113ns;
auto ns_fail = 12'113ns;
int main() { }
[Bug libstdc++/84671] [6/7/8 Regression] Chrono literals don't accept apostrophe as separator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84671 --- Comment #2 from Jonathan Wakely --- Presumably started with my commit r210513
[Bug target/6737] feature request: stack realignment attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6737
Eric Gallager changed:
What|Removed |Added
Keywords||patch
CC||egallager at gcc dot gnu.org
--- Comment #6 from Eric Gallager ---
(In reply to Andrew Pinski from comment #5)
> Patch for this was posted:
> http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01073.html
The -mstackrealign option and the force_align_arg_pointer attribute from this
patch have both been added; -mstackrealign doesn't work with
__attribute__((target(""))) though:
$ cat 6737.c && /usr/local/bin/gcc -c 6737.c
void foo(void) __attribute__((__target__("stackrealign")));
void foo(void)
{
// ...
}
void __attribute__((force_align_arg_pointer)) bar(void *baz)
{
// ...
}
6737.c:1:1: error: attribute(target("stackrealign")) is unknown
void foo(void) __attribute__((__target__("stackrealign")));
^~~~
$
[Bug libstdc++/84671] [6/7/8 Regression] Chrono literals don't accept apostrophe as separator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84671
Jonathan Wakely changed:
What|Removed |Added
CC|jwakely.gcc at gmail dot com |
Host|Linux x86 64-bit|
--- Comment #3 from Jonathan Wakely ---
Testing this fix:
--- a/libstdc++-v3/include/bits/parse_numbers.h
+++ b/libstdc++-v3/include/bits/parse_numbers.h
@@ -197,6 +197,13 @@ namespace __parse_int
"integer literal does not fit in unsigned long long");
};
+ // Skip past digit separators:
+ template
+struct _Number_help<_Base, _Pow, '\'', _Dig, _Digs...>
+: _Number_help<_Base, _Pow, _Dig, _Digs...>
+{ };
+
+ // Terminating case:
template
struct _Number_help<_Base, _Pow, _Dig>
{
[Bug tree-optimization/28364] poor optimization choices when iterating over a std::string (probably not c++-specific)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28364 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #29 from Eric Gallager --- (In reply to Zdenek Dvorak from comment #28) > Subject: Bug 28364 > > Author: rakdver > Date: Wed Aug 16 21:14:11 2006 > New Revision: 116189 > > URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116189 > Log: > PR tree-optimization/28364 > * tree-ssa-loop-ivopts.c (aff_combination_to_tree): Handle zero > correctly. > (fold_affine_expr): New function. > (may_eliminate_iv): Use fold_affine_expr. > > > Modified: > trunk/gcc/ChangeLog > trunk/gcc/tree-ssa-loop-ivopts.c Did this fix it?
[Bug target/84530] -mfunction-return=thunk does not work for simple_return_pop_internal insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84530 --- Comment #4 from hjl at gcc dot gnu.org --- Author: hjl Date: Fri Mar 2 13:05:18 2018 New Revision: 258134 URL: https://gcc.gnu.org/viewcvs?rev=258134&root=gcc&view=rev Log: i386: Update -mfunction-return= for return with pop When -mfunction-return= is used, simple_return_pop_internal should pop return address into ECX register, adjust stack by bytes to pop from stack and jump to the return thunk via ECX register. Revision 257992 removed the bool argument from ix86_output_indirect_jmp. Update comments to reflect it. Tested on i686 and x86-64. gcc/ Backport from mainline 2018-02-26 H.J. Lu * config/i386/i386.c (ix86_output_indirect_jmp): Update comments. 2018-02-26 H.J. Lu PR target/84530 * config/i386/i386-protos.h (ix86_output_indirect_jmp): Remove the bool argument. (ix86_output_indirect_function_return): New prototype. (ix86_split_simple_return_pop_internal): Likewise. * config/i386/i386.c (indirect_return_via_cx): New. (indirect_return_via_cx_bnd): Likewise. (indirect_thunk_name): Handle return va CX_REG. (output_indirect_thunk_function): Create alias for __x86_return_thunk_[re]cx and __x86_return_thunk_[re]cx_bnd. (ix86_output_indirect_jmp): Remove the bool argument. (ix86_output_indirect_function_return): New function. (ix86_split_simple_return_pop_internal): Likewise. * config/i386/i386.md (*indirect_jump): Don't pass false to ix86_output_indirect_jmp. (*tablejump_1): Likewise. (simple_return_pop_internal): Change it to define_insn_and_split. Call ix86_split_simple_return_pop_internal to split it for -mfunction-return=. (simple_return_indirect_internal): Call ix86_output_indirect_function_return instead of ix86_output_indirect_jmp. gcc/testsuite/ Backport from mainline 2018-02-26 H.J. Lu PR target/84530 * gcc.target/i386/ret-thunk-22.c: New test. * gcc.target/i386/ret-thunk-23.c: Likewise. * gcc.target/i386/ret-thunk-24.c: Likewise. * gcc.target/i386/ret-thunk-25.c: Likewise. * gcc.target/i386/ret-thunk-26.c: Likewise. Added: branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/ret-thunk-22.c branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/ret-thunk-23.c branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/ret-thunk-24.c branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/ret-thunk-25.c branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/ret-thunk-26.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/i386/i386-protos.h branches/gcc-7-branch/gcc/config/i386/i386.c branches/gcc-7-branch/gcc/config/i386/i386.md branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug ipa/84658] [7/8 Regression] -O3 -fmerge-all-constants causes incorrect for-each loop generation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84658
Richard Biener changed:
What|Removed |Added
Keywords||alias
Status|NEW |ASSIGNED
--- Comment #9 from Richard Biener ---
This is a points-to issue. After inlining we have
static const intD.9 aD.2281[16] = {0, 1, 2, 3, 4, 5, 8, 15, 16, 17, 512,
1020, 1021, 1022, 1023, 1024};
intD.9 bD.2313;
const intD.9 * __for_beginD.2314;
static const intD.9 aD.2291ptD.2281[16];
...
[100.00%]:
# PT = { D.2281 } (nonlocal)
# ALIGN = 4, MISALIGN = 0
# __for_begin_8 = PHI <&aD.2281(2), __for_begin_10(4)>
if (__for_begin_8 == &MEM[(voidD.43 *)&aD.2281 + 64B])
goto ; [5.88%]
good copy!
[100.00%]:
# PT = { D.2291 } (nonlocal)
# ALIGN = 4, MISALIGN = 0
# __for_begin_5 = PHI <&aD.2291ptD.2281(5), __for_begin_7(7)>
if (__for_begin_5 == &MEM[(voidD.43 *)&aD.2291ptD.2281 + 64B])
goto ; [5.88%]
else
goto ; [94.12%]
bad copy! See how __for_begin_5 only points to D.2291 -- remember the
points-to sets are just bits. But the DECL we check against has
been adjusted to the DECL_PT_UID of 2281...
I guess this is finally a case where we wondered if we get things correct... :/
I remember saying you need to adjust all existing points-to sets
Note for the function bodies after inlining I see foo () has points-to
retained but bar () has it seemingly cleared? But maybe this just dump
before applying the IPA ICF transform.
The ICF dump says:
Unified; Variable alias has been created.
Setting points-to UID of [a.2291] as 2281
but then existing points-to sets containing 2291 are not adjusted.
[Bug target/84039] x86 retpolines and CFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84039
--- Comment #4 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Fri Mar 2 13:09:55 2018
New Revision: 258135
URL: https://gcc.gnu.org/viewcvs?rev=258135&root=gcc&view=rev
Log:
i386: Add TARGET_INDIRECT_BRANCH_REGISTER
For
---
struct C {
virtual ~C();
virtual void f();
};
void
f (C *p)
{
p->f();
p->f();
}
---
-mindirect-branch=thunk-extern -O2 on x86-64 GNU/Linux generates:
_Z1fP1C:
.LFB0:
.cfi_startproc
pushq %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movq(%rdi), %rax
movq%rdi, %rbx
jmp .LIND1
.LIND0:
pushq 16(%rax)
jmp __x86_indirect_thunk
.LIND1:
call.LIND0
movq(%rbx), %rax
movq%rbx, %rdi
popq%rbx
.cfi_def_cfa_offset 8
movq16(%rax), %rax
jmp __x86_indirect_thunk_rax
.cfi_endproc
x86-64 is supposed to have asynchronous unwind tables by default, but
there is nothing that reflects the change in the (relative) frame
address after .LIND0. That region really has to be moved outside of
the .cfi_startproc/.cfi_endproc bracket.
This patch adds TARGET_INDIRECT_BRANCH_REGISTER to force indirect
branch via register whenever -mindirect-branch= is used. Now,
-mindirect-branch=thunk-extern -O2 on x86-64 GNU/Linux generates:
_Z1fP1C:
.LFB0:
.cfi_startproc
pushq %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movq(%rdi), %rax
movq%rdi, %rbx
movq16(%rax), %rax
call__x86_indirect_thunk_rax
movq(%rbx), %rax
movq%rbx, %rdi
popq%rbx
.cfi_def_cfa_offset 8
movq16(%rax), %rax
jmp __x86_indirect_thunk_rax
.cfi_endproc
so that "-mindirect-branch=thunk-extern" is equivalent to
"-mindirect-branch=thunk-extern -mindirect-branch-register", which is
used by Linux kernel.
gcc/
Backport from mainline
PR target/84039
2018-02-26 H.J. Lu
* config/i386/constraints.md (Bs): Replace
ix86_indirect_branch_register with
TARGET_INDIRECT_BRANCH_REGISTER.
(Bw): Likewise.
* config/i386/i386.md (indirect_jump): Likewise.
(tablejump): Likewise.
(*sibcall_memory): Likewise.
(*sibcall_value_memory): Likewise.
Peepholes of indirect call and jump via memory: Likewise.
(*sibcall_GOT_32): Disallowed for TARGET_INDIRECT_BRANCH_REGISTER.
(*sibcall_value_GOT_32): Likewise.
* config/i386/predicates.md (indirect_branch_operand): Likewise.
(GOT_memory_operand): Likewise.
(call_insn_operand): Likewise.
(sibcall_insn_operand): Likewise.
(GOT32_symbol_operand): Likewise.
* config/i386/i386.h (TARGET_INDIRECT_BRANCH_REGISTER): New.
gcc/testsuite/
Backport from mainline
2018-02-26 H.J. Lu
PR target/84039
* gcc.target/i386/indirect-thunk-1.c: Updated.
* gcc.target/i386/indirect-thunk-2.c: Likewise.
* gcc.target/i386/indirect-thunk-3.c: Likewise.
* gcc.target/i386/indirect-thunk-4.c: Likewise.
* gcc.target/i386/indirect-thunk-5.c: Likewise.
* gcc.target/i386/indirect-thunk-6.c: Likewise.
* gcc.target/i386/indirect-thunk-7.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-1.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-2.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-3.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-4.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-5.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-6.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-7.c: Likewise.
* gcc.target/i386/indirect-thunk-bnd-1.c: Likewise.
* gcc.target/i386/indirect-thunk-bnd-2.c: Likewise.
* gcc.target/i386/indirect-thunk-bnd-3.c: Likewise.
* gcc.target/i386/indirect-thunk-bnd-4.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-1.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-2.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-3.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-4.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-5.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-6.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-7.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-1.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-2.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-3.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-4.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-5.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-6.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-7.c: Likewise.
* gcc.target/i386/ret-thunk-9.c: Likewise.
* gc
[Bug preprocessor/19753] different LANG settings and ccache don't work together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19753 Eric Gallager changed: What|Removed |Added Keywords||patch CC||egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- (In reply to patch...@dberlin.org from comment #2) > Subject: Bug number PR preprocessor/19753 > > A patch for this bug has been added to the patch tracker. > The mailing list url for the patch is > http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01851.html Do you know if it still applies/works?
[Bug c++/84667] unreasonable refusal to use assignment operator method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84667 Elmar Stellnberger changed: What|Removed |Added Attachment #43542|0 |1 is obsolete|| --- Comment #1 from Elmar Stellnberger --- Created attachment 43549 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43549&action=edit reduced sample program that evokes the given error sample program that evokes the error reduced to 20% of its original size
[Bug ipa/84658] [7/8 Regression] -O3 -fmerge-all-constants causes incorrect for-each loop generation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84658 --- Comment #10 from Jakub Jelinek --- If ICF needs to adjust all points-to if it makes any variable aliases, perhaps it should as well adjust the code to use the variables rather than their aliases.
[Bug ipa/84658] [7/8 Regression] -O3 -fmerge-all-constants causes incorrect for-each loop generation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84658 --- Comment #11 from Martin Liška --- (In reply to Jakub Jelinek from comment #10) > If ICF needs to adjust all points-to if it makes any variable aliases, > perhaps it should as well adjust the code to use the variables rather than > their aliases. Similar to what we do in sanopt.c:rewrite_usage_of_param? If so, I can do that.
[Bug fortran/84672] New: -fcheck=bounds gives runtime error on allocation on assignment with implicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84672 Bug ID: 84672 Summary: -fcheck=bounds gives runtime error on allocation on assignment with implicit type conversion Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: eh.toussaint at gmail dot com Target Milestone: --- The following program gives a runtime error when compiled with -fcheck=bounds. program foo implicit none real :: x(2) integer, allocatable :: iy(:) x = 1 iy = x write(*, *) iy end program $ gfortran -fcheck=bounds foo.f90 -o foo.exe && ./foo.exe At line 8 of file foo.f90 Fortran runtime error: Array bound mismatch for dimension 1 of array 'iy' (18711 90219/2) Error termination. Backtrace: Could not print backtrace: libbacktrace could not find executable to open #0 0x6f8aecb4 #1 0x6f8a11ce #2 0x6f88105c #3 0x40160b #4 0x4017b5 #5 0x401287
[Bug c++/84669] Error displaying in wrong file for unclosed scopes in headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84669
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||dmalcolm at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #1 from David Malcolm ---
I've fixed this for gcc 8 (as of r251026).
gcc 7 and earlier emit just this:
/tmp/main.cpp:11:1: error: expected ‘}’ at end of input
}
^
gcc 8 emits:
/tmp/main.cpp:11:1: error: expected ‘}’ at end of input
}
^
In file included from /tmp/main.cpp:1:
/tmp/other.hpp:2:1: note: to match this ‘{’
{
^
[Bug tree-optimization/28364] poor optimization choices when iterating over a std::string (probably not c++-specific)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28364
--- Comment #30 from Zack Weinberg ---
It's been a very long time and I don't know exactly what changed, but GCC 7.3
generates essentially the same code for both of the functions in the "C test
case" and I would not describe that code as "bad".
I can still make it duplicate the entire body of the loop by relatively small
tweaks, though. For instance,
int has_bad_chars(char *str, __SIZE_TYPE__ len)
{
for (char *c = str; c < str + len; c++)
{
unsigned char x = (unsigned char)(*c);
if (x <= 0x1f || x == 0x5c || x == 0x7f)
return 1;
}
return 0;
}
generates significantly worse code (doubling cache footprint for no gain in
branch predictability or any other metric) with -O2 than -Os.
Also, the code generated for the body of the loop (with both the original test
case and the above) is more complicated than it needs to be, but perhaps that
should be a new bug report.
[Bug c++/84632] [8 Regression] internal compiler error: tree check: expected record_type or union_type or qual_union_type, have array_type in reduced_constant_expression_p, at cp/constexpr.c:1778
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84632 --- Comment #7 from Paolo Carlini --- In fact, not considering error-recovery issues a la c++/72825, we have another rather serious issue here: for the already mentioned init/array testcases we shouldn't give first an error message about the initializer failing to determine the size and then one explaining that the array must be initialized with a brace-enclosed initializer, we should emit only the latter. This isn't trivial to fix. I'll see what I can do.
[Bug c++/84667] unreasonable refusal to use assignment operator method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84667
--- Comment #2 from Elmar Stellnberger ---
Princess17b29a just found out that the problem can be resolved by adding the
const keyword to the constructor in line 233:
inline xstrbuf( const xstrbuf& s ) ...
... as neither "xstrbuf( base_str_const s )" nor "xstrbuf& operator = (
base_str_const s )" are used directly. An error message of clang has hinted us
to do so:
test_it.cpp:11:11: error: no viable constructor copying variable of type
'estrbuf' (aka 'xstrbuf')
estrbuf copybuf1 = varbuf4.as_const(); // copybuf.bufParams =
xstrbuf_constBuf;
^ ~~
./auxtypes.h:233:10: note: candidate constructor not viable: expects an l-value
for 1st argument
inline xstrbuf( xstrbuf& s ) : base_str( s ) { bufParams = s.bufParams |
xstrbuf_bufUserAllocatedBit; }; // new xstrbuf then holds a temporary copy
of the initial xstrbuf
^
1 error generated.
[Bug tree-optimization/84673] New: Overcomplicated code generation for a chain of mutually exclusive conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84673
Bug ID: 84673
Summary: Overcomplicated code generation for a chain of
mutually exclusive conditions
Product: gcc
Version: 7.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zackw at panix dot com
Target Milestone: ---
This function
int has_bad_chars(unsigned char *str, __SIZE_TYPE__ len)
{
for (unsigned char *c = str; c < str + len; c++)
{
unsigned char x = *c;
if (__builtin_expect (x <= 0x1f || x == 0x5c || x == 0x7f,
0))
return 1;
}
return 0;
}
compiles with GCC 7.3.1 at -Os -march=native on a current-generation x86-64 to
has_bad_chars:
addq%rdi, %rsi
.L2:
cmpq%rsi, %rdi
jnb .L7
movb(%rdi), %al
cmpb$31, %al
setbe %cl
cmpb$92, %al
sete%dl
orb %dl, %cl
jne .L5
cmpb$127, %al
je .L5
incq%rdi
jmp .L2
.L7:
xorl%eax, %eax
ret
.L5:
movl$1, %eax
ret
It is six bytes shorter, and also I think more efficient, to generate this
instead:
has_bad_chars:
.LFB0:
.cfi_startproc
addq%rdi, %rsi
.L2:
cmpq%rsi, %rdi
jnb .L7
movb(%rdi), %al
cmpb$31, %al
jbe .L5
cmpb$92, %al
je .L5
cmpb$127, %al
je .L5
incq%rdi
jmp .L2
.L7:
xorl%eax, %eax
ret
.L5:
movl$1, %eax
ret
The same thing happens at -O2, but also a chunk of the loop body gets
pointlessly duplicated above the loop (it looks like it tried to unroll the
loop and got stuck halfway).
[Bug c++/84657] Wrong exception type matched in catch clause when compiled with address sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84657 --- Comment #3 from Zachary Michaels --- Interesting, thanks for the quick follow-up!
