[Bug c++/84943] New: internal compiler error: in build_call_a, at cp/call.c:374

[vegard.nossum at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84943

Bug ID: 84943
   Summary: internal compiler error: in build_call_a, at
cp/call.c:374
   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:

void a() { a[0]() }

Output:

$ cc1plus 
 void a()
:1:15: warning: pointer to a function used in arithmetic
[-Wpointer-arith]
:1:17: internal compiler error: in build_call_a, at cp/call.c:374
0x8bd3d7 build_call_a(tree_node*, int, tree_node**)
/home/vegard/git/gcc/gcc/cp/call.c:372
0x8c7d79 build_cxx_call(tree_node*, int, tree_node**, int)
/home/vegard/git/gcc/gcc/cp/call.c:8663
0x13f7f75 cp_build_function_call_vec(tree_node*, vec**, int)
/home/vegard/git/gcc/gcc/cp/typeck.c:3775
0x127d98e finish_call_expr(tree_node*, vec**,
bool, bool, int)
/home/vegard/git/gcc/gcc/cp/semantics.c:2521
0xf77968 cp_parser_postfix_expression
/home/vegard/git/gcc/gcc/cp/parser.c:7246
0xf2a4b7 cp_parser_unary_expression
/home/vegard/git/gcc/gcc/cp/parser.c:8322
0xebfeca cp_parser_cast_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9090
0xec24f6 cp_parser_binary_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9191
0xec62ca cp_parser_assignment_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9486
0xeca236 cp_parser_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9655
0xede7b6 cp_parser_expression_statement
/home/vegard/git/gcc/gcc/cp/parser.c:11131
0xefa0e0 cp_parser_statement
/home/vegard/git/gcc/gcc/cp/parser.c:10935
0xefe5eb cp_parser_statement_seq_opt
/home/vegard/git/gcc/gcc/cp/parser.c:11274
0xeff08a cp_parser_compound_statement
/home/vegard/git/gcc/gcc/cp/parser.c:11228
0xf9283b cp_parser_function_body
/home/vegard/git/gcc/gcc/cp/parser.c:21778
0xf9283b cp_parser_ctor_initializer_opt_and_function_body
/home/vegard/git/gcc/gcc/cp/parser.c:21813
0xf9ba45 cp_parser_function_definition_after_declarator
/home/vegard/git/gcc/gcc/cp/parser.c:26818
0xfa209d cp_parser_function_definition_from_specifiers_and_declarator
/home/vegard/git/gcc/gcc/cp/parser.c:26735
0xfa209d cp_parser_init_declarator
/home/vegard/git/gcc/gcc/cp/parser.c:19502
0xfa57a7 cp_parser_simple_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:13065
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Version:

GNU C++14 (GCC) version 8.0.1 20180306 (experimental) (x86_64-pc-linux-gnu)

The error itself looks VERY similar to bug #67533 but the code is sufficiently
different that I think it might be a different underlying problem so I'm
opening a new bug.

[Bug c++/84942] New: internal compiler error: in fold_convert_const_int_from_real, at fold-const.c:2011

[vegard.nossum at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84942

Bug ID: 84942
   Summary: internal compiler error: in
fold_convert_const_int_from_real, at fold-const.c:2011
   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:

a(__attribute__((b((int)__builtin_inf() * 1ULL / auto

Output:

$ cc1plus 
:1:41: internal compiler error: in fold_convert_const_int_from_real, at
fold-const.c:2011
0x1f571ab fold_convert_const_int_from_real
/home/vegard/git/gcc/gcc/fold-const.c:2011
0x1f571ab fold_convert_const
/home/vegard/git/gcc/gcc/fold-const.c:2257
0x1fc4255 const_unop(tree_code, tree_node*, tree_node*)
/home/vegard/git/gcc/gcc/fold-const.c:1729
0x1f9aff4 fold_unary_loc(unsigned int, tree_code, tree_node*, tree_node*)
/home/vegard/git/gcc/gcc/fold-const.c:7737
0x1fa2321 fold_build1_loc(unsigned int, tree_code, tree_node*, tree_node*)
/home/vegard/git/gcc/gcc/fold-const.c:12282
0xa34f93 cxx_eval_constant_expression
/home/vegard/git/gcc/gcc/cp/constexpr.c:4638
0xa4996a cxx_eval_outermost_constant_expr
/home/vegard/git/gcc/gcc/cp/constexpr.c:4832
0xa57256 maybe_constant_value(tree_node*, tree_node*)
/home/vegard/git/gcc/gcc/cp/constexpr.c:5049
0xab6bea cp_fully_fold(tree_node*)
/home/vegard/git/gcc/gcc/cp/cp-gimplify.c:2041
0x13cf877 cp_build_binary_op(unsigned int, tree_code, tree_node*, tree_node*,
int)
/home/vegard/git/gcc/gcc/cp/typeck.c:5391
0x940727 build_new_op_1
/home/vegard/git/gcc/gcc/cp/call.c:6017
0x944116 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:6062
0x1392a6b 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:4032
0x10f0d9c tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/vegard/git/gcc/gcc/cp/pt.c:17546
0xa5796a fold_non_dependent_expr(tree_node*)
/home/vegard/git/gcc/gcc/cp/constexpr.c:5102
0x105112f build_non_dependent_expr(tree_node*)
/home/vegard/git/gcc/gcc/cp/pt.c:25305
0x13933bf 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:4024
0xec484b cp_parser_binary_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9356
0xec62ca cp_parser_assignment_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9486
0xed4304 cp_parser_parenthesized_expression_list
/home/vegard/git/gcc/gcc/cp/parser.c:7764
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Version:

GNU C++14 (GCC) version 8.0.1 20180306 (experimental) (x86_64-pc-linux-gnu)

[Bug c++/84941] New: internal compiler error: in reg_overlap_mentioned_p, at rtlanal.c:1870 (reg_overlap_mentioned_p()/match_asm_constraints_1())

[vegard.nossum at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84941

Bug ID: 84941
   Summary: internal compiler error: in reg_overlap_mentioned_p,
at rtlanal.c:1870
(reg_overlap_mentioned_p()/match_asm_constraints_1())
   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 {
  ~a() {
short *b[]{0};
asm("" : "=m"(b), "=d"(b) : "1p"(b));
  }
} b;

Output:

$ cc1plus -O2
 a::~a() a::~a() a::~a() void __static_initialization_and_destruction_0(int,
int) void _GLOBAL__sub_I_b()
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data>   

  
 Assembling functions:
   a::~a()during RTL pass: asmcons

: In destructor 'a::~a()':
:5:3: internal compiler error: in reg_overlap_mentioned_p, at
rtlanal.c:1870
0x2f0c0e7 reg_overlap_mentioned_p(rtx_def const*, rtx_def const*)
/home/vegard/git/gcc/gcc/rtlanal.c:1870
0x2002163 match_asm_constraints_1
/home/vegard/git/gcc/gcc/function.c:6720
0x2005f43 execute
/home/vegard/git/gcc/gcc/function.c:6800
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Version:

GNU C++14 (GCC) version 8.0.1 20180306 (experimental) (x86_64-pc-linux-gnu)

Actually compiles at -O0, get the ICE at -O1.

[Bug c++/84940] New: internal compiler error: in build_value_init_noctor, at cp/init.c:465

[vegard.nossum at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84940

Bug ID: 84940
   Summary: internal compiler error: in build_value_init_noctor,
at cp/init.c:465
   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 b;
void c() {
  struct {
  } a[__builtin_constant_p(0)][b](-a[0])
}

Output:

$ cc1plus 
 void c()
:4:39: error: wrong type argument to unary minus
:4:39: internal compiler error: in build_value_init_noctor, at
cp/init.c:465
0xcf8133 build_value_init_noctor(tree_node*, int)
/home/vegard/git/gcc/gcc/cp/init.c:465
0xcf8474 build_value_init(tree_node*, int)
/home/vegard/git/gcc/gcc/cp/init.c:378
0xa429f6 cxx_eval_array_reference
/home/vegard/git/gcc/gcc/cp/constexpr.c:2472
0xa2f3d0 cxx_eval_constant_expression
/home/vegard/git/gcc/gcc/cp/constexpr.c:4475
0xa4996a cxx_eval_outermost_constant_expr
/home/vegard/git/gcc/gcc/cp/constexpr.c:4832
0xa57256 maybe_constant_value(tree_node*, tree_node*)
/home/vegard/git/gcc/gcc/cp/constexpr.c:5049
0xab6bea cp_fully_fold(tree_node*)
/home/vegard/git/gcc/gcc/cp/cp-gimplify.c:2041
0x1273a47 finish_unary_op_expr(unsigned int, tree_code, cp_expr, int)
/home/vegard/git/gcc/gcc/cp/semantics.c:2679
0xf2a14f cp_parser_unary_expression
/home/vegard/git/gcc/gcc/cp/parser.c:8303
0xebfeca cp_parser_cast_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9090
0xec24f6 cp_parser_binary_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9191
0xec62ca cp_parser_assignment_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9486
0xecc0a3 cp_parser_constant_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9770
0xed376b cp_parser_parenthesized_expression_list
/home/vegard/git/gcc/gcc/cp/parser.c:7758
0xedc2bc cp_parser_initializer
/home/vegard/git/gcc/gcc/cp/parser.c:21864
0xfa0f3d cp_parser_init_declarator
/home/vegard/git/gcc/gcc/cp/parser.c:19677
0xfa57a7 cp_parser_simple_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:13065
0xfab998 cp_parser_block_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:12883
0xfade64 cp_parser_declaration_statement
/home/vegard/git/gcc/gcc/cp/parser.c:12476
0xefab2b cp_parser_statement
/home/vegard/git/gcc/gcc/cp/parser.c:10925
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Version:

GNU C++14 (GCC) version 8.0.1 20180306 (experimental) (x86_64-pc-linux-gnu)

Possibly related to bug #80812?

[Bug c++/84939] New: internal compiler error: in gimplify_expr, at gimplify.c:12382

[vegard.nossum at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84939

Bug ID: 84939
   Summary: internal compiler error: in gimplify_expr, at
gimplify.c:12382
   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 {
  void b() {
struct c {
  int d struct d e(decltype(d));
};
  }
  a() { (sizeof(char[static_cast(d)])); }
} f;

Output:

$ cc1plus 
 void a::b()
:4:11: error: expected ';' at end of member declaration
 a::a() a::a() a::a() void __static_initialization_and_destruction_0(int, int)
void _GLOBAL__sub_I_f()
Analyzing compilation unit

: In constructor 'a::a()':
:7:43: internal compiler error: in gimplify_expr, at gimplify.c:12382
0x222617f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/vegard/git/gcc/gcc/gimplify.c:12382
0x2219625 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/vegard/git/gcc/gcc/gimplify.c:11375
0x2218312 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/vegard/git/gcc/gcc/gimplify.c:11556
0x2238683 gimplify_compound_lval
/home/vegard/git/gcc/gcc/gimplify.c:2969
0x22191c9 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/vegard/git/gcc/gcc/gimplify.c:11387
0x2219625 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/vegard/git/gcc/gcc/gimplify.c:11375
0x227604c gimplify_modify_expr
/home/vegard/git/gcc/gcc/gimplify.c:5626
0x221b0e6 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/vegard/git/gcc/gcc/gimplify.c:11435
0x221b493 gimplify_target_expr
/home/vegard/git/gcc/gcc/gimplify.c:6577
0x221b493 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/vegard/git/gcc/gcc/gimplify.c:11815
0x2219625 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/vegard/git/gcc/gcc/gimplify.c:11375
0x2218f62 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/vegard/git/gcc/gcc/gimplify.c:12159
0x227604c gimplify_modify_expr
/home/vegard/git/gcc/gcc/gimplify.c:5626
0x221b0e6 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/vegard/git/gcc/gcc/gimplify.c:11435
0x2228401 gimplify_stmt(tree_node**, gimple**)
/home/vegard/git/gcc/gcc/gimplify.c:6658
0x221a50d gimplify_cleanup_point_expr
/home/vegard/git/gcc/gcc/gimplify.c:6400
0x221a50d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/vegard/git/gcc/gcc/gimplify.c:11811
0x2228401 gimplify_stmt(tree_node**, gimple**)
/home/vegard/git/gcc/gcc/gimplify.c:6658
0x221bc6b gimplify_statement_list
/home/vegard/git/gcc/gcc/gimplify.c:1767
0x221bc6b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/vegard/git/gcc/gcc/gimplify.c:11863
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Version:

GNU C++14 (GCC) version 8.0.1 20180306 (experimental) (x86_64-pc-linux-gnu)

[Bug tree-optimization/71485] g++ ICE on x86_64-linux-gnu in “gimplify_expr”

[vegard.nossum at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71485

Vegard Nossum  changed:

   What|Removed |Added

 CC||vegard.nossum at gmail dot com

--- Comment #2 from Vegard Nossum  ---
This does not ICE for me with either 7.1 or trunk on godbolt.org (but 6.3 has
"confused by earlier errors, bailing out"), nor with 8.0.1 compiled with checks
enabled, so maybe it has been fixed?

[Bug c++/84938] New: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1187 (gen_reg_rtx()/maybe_legitimize_operand())

[vegard.nossum at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84938

Bug ID: 84938
   Summary: internal compiler error: in gen_reg_rtx, at
emit-rtl.c:1187
(gen_reg_rtx()/maybe_legitimize_operand())
   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 & = 1 / ~-1ULL;

Output:

$ cc1plus 
:1:13: warning: division by zero [-Wdiv-by-zero]

Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data>   

  Assembling functions:
  :1:21: internal compiler error: in
gen_reg_rtx, at emit-rtl.c:1187
0x1d84b67 gen_reg_rtx(machine_mode)
/home/vegard/git/gcc/gcc/emit-rtl.c:1187
0x2b0ee4c maybe_legitimize_operand
/home/vegard/git/gcc/gcc/optabs.c:7143
0x2b0ee4c maybe_legitimize_operands(insn_code, unsigned int, unsigned int,
expand_operand*)
/home/vegard/git/gcc/gcc/optabs.c:7222
0x2b0ee4c maybe_gen_insn(insn_code, unsigned int, expand_operand*)
/home/vegard/git/gcc/gcc/optabs.c:7240
0x2b0ee4c expand_unop_direct
/home/vegard/git/gcc/gcc/optabs.c:2695
0x2b07681 expand_unop(machine_mode, optab_tag, rtx_def*, rtx_def*, int)
/home/vegard/git/gcc/gcc/optabs.c:2737
0x1edee2a expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/home/vegard/git/gcc/gcc/expr.c:9222
0x1e76836 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/vegard/git/gcc/gcc/expr.c:11286
0x1eb0674 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/home/vegard/git/gcc/gcc/expr.c:8227
0x1eb0674 expand_expr
/home/vegard/git/gcc/gcc/expr.h:276
0x1eb0674 expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**,
rtx_def**, expand_modifier)
/home/vegard/git/gcc/gcc/expr.c:7825
0x1edc677 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/home/vegard/git/gcc/gcc/expr.c:8971
0x1e76836 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/vegard/git/gcc/gcc/expr.c:11286
0x41d9f62 expand_expr
/home/vegard/git/gcc/gcc/expr.h:276
0x41d9f62 output_constant
/home/vegard/git/gcc/gcc/varasm.c:4907
0x41dcc2b assemble_variable_contents
/home/vegard/git/gcc/gcc/varasm.c:2136
0x41fd542 assemble_variable(tree_node*, int, int, int)
/home/vegard/git/gcc/gcc/varasm.c:2312
0x4218599 varpool_node::assemble_decl()
/home/vegard/git/gcc/gcc/varpool.c:590
0x19a9497 output_in_order
/home/vegard/git/gcc/gcc/cgraphunit.c:2385
0x19a9497 symbol_table::compile()
/home/vegard/git/gcc/gcc/cgraphunit.c:2623
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Version:

GNU C++14 (GCC) version 8.0.1 20180306 (experimental) (x86_64-pc-linux-gnu)

Possibly related: bug #70420, bug #78380

Clang complains about UB (division by zero) but does compiles it.

[Bug fortran/82992] ICE in create_int_parameter_array, at fortran/module.c:6586

[anlauf at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82992

--- Comment #5 from Harald Anlauf  ---
Adding 'implicit none' after the use statements:

subroutine sub (c_int)
   use iso_c_binding, only: c_int
   implicit none  ! makes no difference
end

-> still no error message

module pr82992
  integer :: x
end module pr82992
subroutine sub (x)
  use pr82992, only : x
  implicit none   ! -> Error: Symbol 'x' at (1) has no IMPLICIT type
end

-> gives wrong/misleading error message

pr82992c.f90:4:17:

 subroutine sub (x)
 1
Error: Symbol 'x' at (1) has no IMPLICIT type

[Bug fortran/84931] Expansion of array constructor with constant implied-do-object goes sideways

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84931

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org

--- Comment #4 from Thomas Koenig  ---
Let's see.

[Bug c++/84937] New: [7/8 Regression] ICE with class template argument deduction and auto

[reichelt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84937

Bug ID: 84937
   Summary: [7/8 Regression] ICE with class template argument
deduction and auto
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following valid code snippet (compiled with "-std=c++17")
triggers an ICE since GCC 7.1.0:

==
template struct A {};

template struct B
{
  template B(A);
};

B b(A<0,0>{});
==

bug.cc: In substitution of 'template B(A)-> B [with int
I = ; auto J = ]':
bug.cc:8:13:   required from here
bug.cc:8:13: internal compiler error: in tsubst, at cp/pt.c:14007
 B b(A<0,0>{});
 ^
0x643561 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:14007
0x9699e8 unify
../../gcc/gcc/cp/pt.c:21239
0x968f44 unify
../../gcc/gcc/cp/pt.c:21434
0x989312 try_class_unification
../../gcc/gcc/cp/pt.c:20439
0x968fc5 unify
../../gcc/gcc/cp/pt.c:21471
0x985d13 unify_one_argument
../../gcc/gcc/cp/pt.c:19681
0x989763 type_unification_real
../../gcc/gcc/cp/pt.c:19801
0x98be55 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool)
../../gcc/gcc/cp/pt.c:19186
0x82af2f add_template_candidate_real
../../gcc/gcc/cp/call.c:3179
0x82b940 add_template_candidate
../../gcc/gcc/cp/call.c:3258
0x82b940 add_candidates
../../gcc/gcc/cp/call.c:5523
0x82bd61 add_candidates
../../gcc/gcc/cp/call.c:4195
0x82bd61 perform_overload_resolution
../../gcc/gcc/cp/call.c:4203
0x82dde2 build_new_function_call(tree_node*, vec**, int)
../../gcc/gcc/cp/call.c:4276
0x967298 do_class_deduction
../../gcc/gcc/cp/pt.c:26163
0x967298 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
../../gcc/gcc/cp/pt.c:26218
0x89e733 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/gcc/cp/decl.c:6909
0x93b893 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19723
0x942cc8 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13057
0x943ad8 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12882
Please submit a full bug report, [etc.]

[Bug fortran/84931] Expansion of array constructor with constant implied-do-object goes sideways

[mikael at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84931

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #3 from Mikael Morin  ---
Note that gfc_trans_assignment has short-circuit code to specifically handle
"simple" assignment such as assignment from an array constructor.
This may explain the difference between the integer and real version: they use
a completely different code path.

[Bug c++/84936] New: [8 Regression] ICE with unexpanded parameter pack

[reichelt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84936

Bug ID: 84936
   Summary: [8 Regression] ICE with unexpanded parameter pack
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following invalid code snippet triggers an ICE on trunk:

==
struct A
{
  template A(T... t) : decltype(t)() {}
};

A a;
==

bug.cc: In instantiation of 'A::A(T ...) [with T = {}]':
bug.cc:6:3:   required from here
bug.cc:3:51: internal compiler error: Segmentation fault
   template A(T... t) : decltype(t)() {}
   ^
0xebab0f crash_signal
../../gcc/gcc/toplev.c:325
0x9d5e09 invalid_nonstatic_memfn_p(unsigned int, tree_node*, int)
../../gcc/gcc/cp/typeck.c:1882
0x9b2529 finish_decltype_type(tree_node*, bool, int)
../../gcc/gcc/cp/semantics.c:8734
0x975ed5 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:14580
0x96ed2f tsubst_initializer_list
../../gcc/gcc/cp/pt.c:23825
0x96ed2f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16213
0x96d6cf tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16489
0x96c868 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16193
0x96c868 instantiate_decl(tree_node*, bool, bool)
../../gcc/gcc/cp/pt.c:23575
0x99146b instantiate_pending_templates(int)
../../gcc/gcc/cp/pt.c:23691
0x8b760b c_parse_final_cleanups()
../../gcc/gcc/cp/decl2.c:4721
Please submit a full bug report, [etc.]

The regression was introduced between 2017-05-06 and 2017-05-12.

[Bug tree-optimization/84935] New: FAIL: gcc.dg/tree-ssa/pr84512.c scan-tree-dump optimized "return 285;"

[danglin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84935

Bug ID: 84935
   Summary: FAIL: gcc.dg/tree-ssa/pr84512.c scan-tree-dump
optimized "return 285;"
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr84512.c  
-fno-diagnostics-show-c
aret -fdiagnostics-color=never   -O3 -fdump-tree-optimized -S   -o pr84512.s
(timeout = 300)
spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/test/gnu/gcc/gc
c/gcc/testsuite/gcc.dg/tree-ssa/pr84512.c -fno-diagnostics-show-caret
-fdiagnost
ics-color=never -O3 -fdump-tree-optimized -S -o pr84512.s
PASS: gcc.dg/tree-ssa/pr84512.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/pr84512.c scan-tree-dump optimized "return 285;"

[Bug lto/84934] Installing the lto plugin where binutils will look for it

[dilyan.palauzov at aegee dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84934

--- Comment #2 from Дилян Палаузов  ---
Builind a linux from scratch system, doing everywhere "./configure && make
install" shall work, taking all defaults into account.  For gcc+LTO+binutils
this does not work.  While distros can adjust the exact location, for binutils
doing "./configure && make install" the location is
"/usr/local/bin/bfd-plugins/", so with gcc's "./configure && make install "
this location shall be used by default.

[Bug lto/84934] Installing the lto plugin where binutils will look for it

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84934

--- Comment #1 from Andrew Pinski  ---
I think it is up to the distro/installer themselves to install the plugin in
the correct location.   Binutils might be installed in a fully differently
directory structure as gcc is.

[Bug lto/84934] New: Installing the lto plugin where binutils will look for it

[dilyan.palauzov at aegee dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84934

Bug ID: 84934
   Summary: Installing the lto plugin where binutils will look for
it
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dilyan.palauzov at aegee dot org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

For the LTO prime time to arise, "gcc/Makefile install" shall put the
liblto_plugin in a place, where the ar/ranlib/nm tools load it.  They load
search for plugins in the {libdir}/bfd-plugins directory.

Currently users detect in autoconf if they will do LTO, then switch
ar/nm/ranlib to gcc-ar/gcc-nm/gcc-ranlib in order to avoid dealing with the
--plugin and because they are unaware of the bfd-plugin directory.  This is
unacceptable.

There are several options:
*) ar/nm/ranlib provide a mechanism to show the directory, where they look for
plugins, and gcc installs the plugins there,
*) ar/nm/ranlib ask gcc, clang and the other compilers where they have put
their plugins.
*) gcc and binutils mutually agree on a directory where the plugins are
installed and install/read the plugins there.  Assuming that both gcc and
binutils share the same value for {libdir}, being it /usr/local/lib, or
/usr/lib64, gcc could install it in {libdir}/bfd-plugins, clang can do the same
for LLVMgold.so , and then binutils don't change, as they look for the files
there.

What speaks against the third option?

[Bug rtl-optimization/84635] gcc/regrename.c:1706:64: runtime error: index -1 out of bounds for type 'machine_mode [30]'

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84635

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Martin Liška  ---
Fixed.

[Bug rtl-optimization/84635] gcc/regrename.c:1706:64: runtime error: index -1 out of bounds for type 'machine_mode [30]'

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84635

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Sun Mar 18 20:17:10 2018
New Revision: 258634

URL: https://gcc.gnu.org/viewcvs?rev=258634=gcc=rev
Log:
Fix UBSAN in regrename.c (PR rtl-optimization/84635).

2018-03-18  Martin Liska  

PR rtl-optimization/84635
* regrename.c (build_def_use): Use matches_mode only when
matches >= 0.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/regrename.c

[Bug target/84926] error: inlining failed in call to always_inline ‘_mm_crc32_u64’: target specific option mismatch _mm_crc32_u64

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84926

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Martin Liška  ---
The issue is that it uses always_inline for a function that uses -msse3 and you
use -march=native and -mtune=generic.

If I configure postgres with :
CFLAGS="-mtune=generic -march=x86-64"
CXXFLAGS=...
LDFLAGS=...

then it builds fine. The file should not be built with the flags.
Clang has nicer error message:
 error: always_inline function '_mm_crc32_u64' requires target feature 'ssse3',
but would be inlined into function 'pg_comp_crc32c_sse42' that is compiled
without support for 'ssse3'

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 84902, which changed state.

Bug 84902 Summary: [8 Regression] 549.fotonik3d_r from SPEC2017 fails 
verification with -Ofast -march=native on Zen since r258518
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84902

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug target/84902] [8 Regression] 549.fotonik3d_r from SPEC2017 fails verification with -Ofast -march=native on Zen since r258518

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84902

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Martin Liška  ---
Thank you both, works for me. Thus closing.

[Bug middle-end/84048] [8 Regression] FAIL: gcc.dg/torture/tls/run-ld.c -O0 -pie -fPIE execution test

[danglin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84048

--- Comment #5 from John David Anglin  ---
With binutils-2.29,test passes:
https://sourceware.org/bugzilla/show_bug.cgi?id=22978

[Bug target/84926] error: inlining failed in call to always_inline ‘_mm_crc32_u64’: target specific option mismatch _mm_crc32_u64

[dilyan.palauzov at aegee dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84926

--- Comment #2 from Дилян Палаузов  ---
make -C src all
make[1]: Entering directory '/git/postgresql/src'
make -C common all
make[2]: Entering directory '/git/postgresql/src/common'
make -C ../backend submake-errcodes
make[3]: Entering directory '/git/postgresql/src/backend'
make[3]: Nothing to be done for 'submake-errcodes'.
make[3]: Leaving directory '/git/postgresql/src/backend'
make[2]: Leaving directory '/git/postgresql/src/common'
make -C port all
make[2]: Entering directory '/git/postgresql/src/port'
make -C ../backend submake-errcodes
make[3]: Entering directory '/git/postgresql/src/backend'
make[3]: Nothing to be done for 'submake-errcodes'.
make[3]: Leaving directory '/git/postgresql/src/backend'
gcc -flto --verbose -I../../src/port -DFRONTEND -I../../src/include 
-D_GNU_SOURCE -I/usr/local/include/libxml2   -c -o pg_crc32c_sse42.o
pg_crc32c_sse42.c
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-pc-linux-gnu
Configured with: ./configure --enable-threads=posix --enable-nls
--enable-interpreter --with-system-zlib --enable-libgcj-multifile
--enable-languages=all --enable-targets=all --with-system-unwind --without-x
--with-linker-hash-style=gnu --disable-multilib --enable-shared
--with-build-config='bootstrap-lto bootstrap-O3'
Thread model: posix
gcc version 7.3.1 20180316 (GCC) 
COLLECT_GCC_OPTIONS='-flto' '-v' '-I' '../../src/port' '-D' 'FRONTEND' '-I'
'../../src/include' '-D' '_GNU_SOURCE' '-I' '/usr/local/include/libxml2' '-c'
'-o' 'pg_crc32c_sse42.o' '-mtune=generic' '-march=x86-64'
 /usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/cc1 -quiet -v -I
../../src/port -I ../../src/include -I /usr/local/include/libxml2 -imultiarch
x86_64-linux-gnu -D FRONTEND -D _GNU_SOURCE pg_crc32c_sse42.c -quiet -dumpbase
pg_crc32c_sse42.c -mtune=generic -march=x86-64 -auxbase-strip pg_crc32c_sse42.o
-version -flto -o /tmp/cce8jOUn.s
GNU C11 (GCC) version 7.3.1 20180316 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.3.1 20180316, GMP version 6.1.2, MPFR
version 4.0.0, MPC version 1.1.0, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 ../../src/port
 ../../src/include
 /usr/local/include/libxml2
 /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include
 /usr/local/include
 /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C11 (GCC) version 7.3.1 20180316 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.3.1 20180316, GMP version 6.1.2, MPFR
version 4.0.0, MPC version 1.1.0, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: e97c32a4d3c4d8b00665455dd270ad26
In file included from
/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include/nmmintrin.h:31:0,
 from pg_crc32c_sse42.c:19:
pg_crc32c_sse42.c: In function ‘pg_comp_crc32c_sse42’:
/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include/smmintrin.h:846:1: error:
inlining failed in call to always_inline ‘_mm_crc32_u64’: target specific
option mismatch
 _mm_crc32_u64 (unsigned long long __C, unsigned long long __V)
 ^
pg_crc32c_sse42.c:37:18: note: called from here
   crc = (uint32) _mm_crc32_u64(crc, *((const uint64 *) p));
  ^
In file included from
/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include/nmmintrin.h:31:0,
 from pg_crc32c_sse42.c:19:
/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include/smmintrin.h:839:1: error:
inlining failed in call to always_inline ‘_mm_crc32_u32’: target specific
option mismatch
 _mm_crc32_u32 (unsigned int __C, unsigned int __V)
 ^
pg_crc32c_sse42.c:44:7: note: called from here
   crc = _mm_crc32_u32(crc, *((const unsigned int *) p));
   ^
In file included from
/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include/nmmintrin.h:31:0,
 from pg_crc32c_sse42.c:19:
/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include/smmintrin.h:827:1: error:
inlining failed in call to always_inline ‘_mm_crc32_u8’: target specific option
mismatch
 _mm_crc32_u8 (unsigned int __C, unsigned char __V)
 ^~~~
pg_crc32c_sse42.c:63:7: note: called from here
   crc = _mm_crc32_u8(crc, *p);
   ^~~
make[2]: *** [: pg_crc32c_sse42.o] Error 1
make[2]: Leaving directory '/git/postgresql/src/port'
make[1]: *** [Makefile:38: all-port-recurse] Error 2
make[1]: Leaving directory '/git/postgresql/src'
make: *** [GNUmakefile:11: all-src-recurse] Error 2

[Bug tree-optimization/84811] [8 Regression] ICE on valid code at -O3 in 64-bit mode on x86_64-linux-gnu: in smallest_mode_for_size, at stor-layout.c:355

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84811

--- Comment #23 from Martin Liška  ---
Isn't that caused by a undefined behavior in compiler?
Can you please run it in valgrind:
valgrind --leak-check=yes --trace-children=yes ...

Can you please test it with compiler that is built w/o optimization:
make all-host -k CFLAGS="-O0 -g" CXXFLAGS="-O0 -g"

[Bug target/84926] error: inlining failed in call to always_inline ‘_mm_crc32_u64’: target specific option mismatch _mm_crc32_u64

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84926

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-03-18
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
It will be unrelated, please attach content of --verbose for the problematic
source file.

[Bug tree-optimization/84929] [8 Regression] ICE at -O3 on valid code on x86_64-linux-gnu: tree check: expected polynomial_chrec, have nop_expr in analyze_siv_subscript_cst_affine, at tree-data-ref.c:

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84929

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||7.3.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2018-03-18
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|ICE at -O3 on valid code on |[8 Regression] ICE at -O3
   |x86_64-linux-gnu: tree  |on valid code on
   |check: expected |x86_64-linux-gnu: tree
   |polynomial_chrec, have  |check: expected
   |nop_expr in |polynomial_chrec, have
   |analyze_siv_subscript_cst_a |nop_expr in
   |ffine, at   |analyze_siv_subscript_cst_a
   |tree-data-ref.c:3018|ffine, at
   ||tree-data-ref.c:3018
   Target Milestone|--- |8.0
  Known to fail||8.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r257013.

[Bug target/84932] [8 Regression] i386/cpuinfo.h:293: 4 * bad bitshifts ?

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84932

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-18
 CC||marxin at gcc dot gnu.org
   Target Milestone|--- |8.0
Summary|i386/cpuinfo.h:293: 4 * |[8 Regression]
   |bad bitshifts ? |i386/cpuinfo.h:293: 4 *
   ||bad bitshifts ?
 Ever confirmed|0   |1
  Known to fail||8.0

--- Comment #2 from Martin Liška  ---
Confirmed.

[Bug tree-optimization/84933] [8 Regression] ICE in set_value_range, at tree-vrp.c:288 since r257852

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84933

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #1 from Jeffrey A. Law  ---
Looks like a bug in vrp_intersect_ranges_1 or its children to me.

We call vrp_intersect_range_1 with:


(gdb) p debug_value_range (vr0)
~[0, 2147483647]  EQUIVALENCES: { c.0_1 } (1 elements)
$16 = void
(gdb) p debug_value_range (vr1)
~[1, 2147483647]  EQUIVALENCES: { c.0_1 } (1 elements)
$17 = void


Which then proceeds to call set_and_canonicalize_value_range with min/max as:


(gdb) p debug_tree (min)
  constant
2147483648>
$18 = void
(gdb) p debug_tree (max)
  constant 1>
$19 = void


Which looks bogus to me.

I'll have to look deeper tues/wed if nobody gets to it before then..

[Bug tree-optimization/84933] [8 Regression] ICE in set_value_range, at tree-vrp.c:288 since r257852

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84933

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-18
  Known to work||7.3.0
   Target Milestone|--- |8.0
 Ever confirmed|0   |1
  Known to fail||8.0

[Bug tree-optimization/84933] New: [8 Regression] ICE in set_value_range, at tree-vrp.c:288 since r257852

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84933

Bug ID: 84933
   Summary: [8 Regression] ICE in set_value_range, at
tree-vrp.c:288 since r257852
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: law at gcc dot gnu.org, msebor at gcc dot gnu.org
  Target Milestone: ---

Following ICEs:

$ cat /tmp/ice.ii
enum a {};
int *d;
int b, e, f;
a c, g;
class h {
  virtual unsigned i();
};
class j : h {
  unsigned i() {
for (;;) {
  b = c <= 0;
  if (b)
e = *d;
  b = g && c;
  if (b)
f = *d;
}
  }
};
void k() { new j; }

$ gcc -fstrict-enums -O3 -fno-inline /tmp/ice.ii -c
during GIMPLE pass: printf-return-value
/tmp/ice.ii: In member function ‘virtual unsigned int j::i()’:
/tmp/ice.ii:9:12: internal compiler error: in set_value_range, at
tree-vrp.c:288
   unsigned i() {
^
c0x108f87f set_value_range(value_range*, value_range_type, tree_node*,
tree_node*, bitmap_head*)
../../gcc/tree-vrp.c:288
0x108f966 set_and_canonicalize_value_range(value_range*, value_range_type,
tree_node*, tree_node*, bitmap_head*)
../../gcc/tree-vrp.c:433
0x108fffc vrp_intersect_ranges_1
../../gcc/tree-vrp.c:6297
0x108fffc vrp_intersect_ranges(value_range*, value_range*)
../../gcc/tree-vrp.c:6334
0x1112b45 vr_values::extract_range_for_var_from_comparison_expr(tree_node*,
tree_code, tree_node*, tree_node*, value_range*)
../../gcc/vr-values.c:682
0x15b8bf5 evrp_range_analyzer::try_find_new_range(tree_node*, tree_node*,
tree_code, tree_node*)
../../gcc/gimple-ssa-evrp-analyze.c:89
0x15b9a62
evrp_range_analyzer::record_ranges_from_incoming_edge(basic_block_def*)
../../gcc/gimple-ssa-evrp-analyze.c:198
0x15ba06c evrp_range_analyzer::enter(basic_block_def*)
../../gcc/gimple-ssa-evrp-analyze.c:75
0x15dc8eb before_dom_children
../../gcc/gimple-ssa-sprintf.c:4018
0x159a0d7 dom_walker::walk(basic_block_def*)
../../gcc/domwalk.c:353
0x15d567a execute
../../gcc/gimple-ssa-sprintf.c:4053

[Bug fortran/66310] Problems with intrinsic repeat for large number of copies

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66310

--- Comment #27 from Jerry DeLisle  ---
(In reply to Dominique d'Humieres from comment #26)
> > I concur. Closing accordingly.
> 
> I disagree: if there is a limit, gfortran should emit an error.

Well you are hitting on an OS limit, we could put a check in the runtime but
how do we test that -m32 was used? The error message I get now is from our
memory.c:

  if (p == NULL)
os_error ("Memory allocation failed");

[Bug target/84932] i386/cpuinfo.h:293: 4 * bad bitshifts ?

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84932

David Binderman  changed:

   What|Removed |Added

 CC||jkoval at gcc dot gnu.org

--- Comment #1 from David Binderman  ---
Revision 258551 looks related. 

Maybe Julia can offer some assistance with this possible problem.

[Bug fortran/84931] Expansion of array constructor with constant implied-do-object goes sideways

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84931

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from 4.3.1 up to trunk (8.0).

[Bug target/84932] New: i386/cpuinfo.h:293: 4 * bad bitshifts ?

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84932

Bug ID: 84932
   Summary: i386/cpuinfo.h:293: 4 *  bad bitshifts ?
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

[trunk/libgcc/config/i386/cpuinfo.c:293]: (error) Shifting 32-bit value by 32
bits is undefined behaviour
[trunk/libgcc/config/i386/cpuinfo.c:295]: (error) Shifting 32-bit value by 33
bits is undefined behaviour
[trunk/libgcc/config/i386/cpuinfo.c:297]: (error) Shifting 32-bit value by 34
bits is undefined behaviour
[trunk/libgcc/config/i386/cpuinfo.c:299]: (error) Shifting 32-bit value by 35
bits is undefined behaviour

Source code is

  if (ecx & bit_GFNI)
features |= (1 << FEATURE_GFNI);
  if (ecx & bit_VPCLMULQDQ)
features |= (1 << FEATURE_VPCLMULQDQ);
  if (ecx & bit_AVX512VNNI)
features |= (1 << FEATURE_AVX512VNNI);
  if (ecx & bit_AVX512BITALG)
features |= (1 << FEATURE_AVX512BITALG);

There are more than 32 features. 1UL would be a better bitmask.
Local variable "features" could do with moving from int to size_t.

[Bug fortran/77414] ICE in create_function_arglist, at fortran/trans-decl.c:2410

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77414

--- Comment #7 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sun Mar 18 17:51:57 2018
New Revision: 258633

URL: https://gcc.gnu.org/viewcvs?rev=258633=gcc=rev
Log:
2018-03-18  Steven G. Kargl  

PR fortran/77414
* decl.c (get_proc_name):  Check for a subroutine re-defined in
the contain portion of a subroutine.  Change language of existing
error message to better describe the issue. While here fix whitespace
issues.

2018-03-18  Steven G. Kargl  

PR fortran/77414
* gfortran.dg/pr77414.f90: New test.
* gfortran.dg/internal_references_1.f90: Adjust error message.

Added:
trunk/gcc/testsuite/gfortran.dg/pr77414.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/internal_references_1.f90

[Bug fortran/66310] Problems with intrinsic repeat for large number of copies

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66310

--- Comment #26 from Dominique d'Humieres  ---
> I concur. Closing accordingly.

I disagree: if there is a limit, gfortran should emit an error.

[Bug fortran/84931] Expansion of array constructor with constant implied-do-object goes sideways

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84931

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-18
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
The following code does the correct thing with an
integer array 'y'.

program test
   implicit none
   integer, parameter :: n = 65536
   integer, dimension(n) :: y
   integer*4 :: i
   y = (/ (1, i=1, n) /)
   if (y(2) /= 1) stop 1
end program test

The expansion of the array constructor is implemented by 
creating a temporary array and filling it with '1'.  The
temporary array is then copied into 'y'.

This however does sideways

program test
   implicit none
   integer, parameter :: n = 65536
   real, dimension(n) :: y
   integer*4 :: i
   y = (/ (1, i=1, n) /)
   if (y(2) /= 1) stop 1
end program test

A temporary array is created, but only the first element of
the temporary array is initialized to 1.  The temporary array
is then copied into 'y', except the temporary array has not
assigned values for tmp(2:65536).

Tree dumps are here

https://gcc.gnu.org/ml/fortran/2018-03/msg00096.html

Problem found on Stack Overflow

https://stackoverflow.com/questions/49330816/strange-initialization-behavior-for-an-array-constructor-with-implied-do-in-gfor

[Bug fortran/79929] [7 Regression] Bogus Warning: '__builtin_memset': specified size 4294967291 exceeds maximum object size 2147483647

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79929

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #32 from Thomas Koenig  ---
So, fixed in gcc-8, backport too invasive / not needed for gcc-7.

[Bug fortran/84931] New: Expansion of array constructor with constant implied-do-object goes sideways

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84931

Bug ID: 84931
   Summary: Expansion of array constructor with constant
implied-do-object goes sideways
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kargl at gcc dot gnu.org
  Target Milestone: ---

[Bug fortran/66310] Problems with intrinsic repeat for large number of copies

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66310

Thomas Koenig  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||tkoenig at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #25 from Thomas Koenig  ---
(In reply to Jerry DeLisle from comment #24)
> (In reply to Jerry DeLisle from comment #23)
> > Ok I see it.
> > 
> > In fbuf.c (fbuf_alloc):
> > 
> >   /* Round up to nearest multiple of the current buffer length.  */
> >   newlen = ((u->fbuf->pos + len) / u->fbuf->len + 1) *u->fbuf->len;
> >   u->fbuf->buf = xrealloc (u->fbuf->buf, newlen);
> >   u->fbuf->len = newlen;
> > 
> > We are rounding up to make sure we have enough buffer. The size newlen is
> > calculated to 2147484160 which exceeds the limit of 2147483647 and xrealloc
> > fails.
> 
> There is a 2 GB limit on 32 bit processes, so this is not a bug. I suggest
> this be closed.

I concur. Closing accordingly.

[Bug fortran/65453] ICE in build_function_decl, at fortran/trans-decl.c:2001

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65453

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sun Mar 18 16:33:55 2018
New Revision: 258632

URL: https://gcc.gnu.org/viewcvs?rev=258632=gcc=rev
Log:
2018-03-18  Steven G. Kargl  

PR fortran/65453
* decl.c (get_proc_name): Catch clash between a procedure statement
and a contained subprogram

2018-03-18  Steven G. Kargl  

PR fortran/65453
* gfortran.dg/pr65453.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr65453.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/79929] [7 Regression] Bogus Warning: '__builtin_memset': specified size 4294967291 exceeds maximum object size 2147483647

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79929

--- Comment #31 from Thomas Koenig  ---
(In reply to Dominique d'Humieres from comment #30)
> Fixed by revision r256284?

r256284 is OK, r256283 fails.

We cannot backport r256284 because this is the ABI change for
long string lengths.

So, this is a candidate for "RESOLVED FIXED" unless somebody
comes up with an independent way to fix this (but frankly,
I wouldn't try to do it).

[Bug fortran/79685] [6/7/8 Regression] ICE on valid code in gfc_match_structur_constructor

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79685

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #4 from Thomas Koenig  ---
The problem seems to be in the renaming,
the test case

module omega_color
  implicit none

  type omega_color_factor
 integer :: i
  end type

end module

module foo
  use omega_color
  implicit none

  type(omega_color_factor) :: table_color_factors
  data table_color_factors / omega_color_factor(1) /

end module

works.

[Bug c++/84930] New: Brace-closed initialization of cstring (i.e."abcdefghi") to coresponding aggregate types fails in certain situation

[hotguest1 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84930

Bug ID: 84930
   Summary: Brace-closed initialization of cstring
(i.e."abcdefghi") to coresponding aggregate types
fails in certain situation
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hotguest1 at hotmail dot com
  Target Milestone: ---

We can do this in both GCC and clang

std::array, 2> arr_from_cstr1{{
{{"abcdefghi"}}, {{"abcdefghi"}}
}};

std::array arr_from_cstr2{{
{"abcdefghi"}, {"abcdefghi"}
}};

std::vector > vec_from_direct{{
{{ 'a','b','c','d','e','f','g','h','i','\0' }},
{{ 'a','b','c','d','e','f','g','h','i','\0' }}
}};

std::vector vec_from_ctor{{
std::array{ {"abcdefghi"} },
std::array{ {"abcdefghi"} }
}};

We can't do this in GCC but can do in clang

std::vector > vec_from_ctr1{{
{{"abcdefghi"}}, {{"abcdefghi"}}
}};

struct A {
  std::array x; 
  A(std::array arr) : x(arr) {}
};
A struct_from_ctr1{ {{"abcdefghi"}} };

You may see the error details in CE (tested with gcc 7.3):
https://godbolt.org/g/zV6dHd

I'm sorry that I can't describe the scenario good enough.

[Bug fortran/71066] [6/7/8 Regression] ICE in set_loop_bounds, at fortran/trans-array.c:4680

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71066

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #5 from Thomas Koenig  ---
OK, so the first example is indeed invalid.

What about the second one? I don't speak Coarray.

[Bug fortran/77680] [6/7/8 Regression] [F03] ICE in ctor_for_folding, at varpool.c:419

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77680

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||tkoenig at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from Thomas Koenig  ---
This is now correctly rejected:

ig25@flaemmli:/tmp> cat d.f90 
program p
   bind(c) :: x
   call s(x)
end
ig25@flaemmli:/tmp> gfortran d.f90 
d.f90:2:15:

bind(c) :: x
   1
Error: Variable ‘x’ at (1) cannot be BIND(C) because it is neither a COMMON
block nor declared at the module level scope

Closing.

[Bug c/84890] Overly verbose notes for missing headers

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84890

--- Comment #5 from David Malcolm  ---
A similar sentiment to comment #1:
https://www.reddit.com/r/cpp/comments/84op5c/usability_improvements_in_gcc_8/dvu7n5e/
> I find that "did you forget to '#include" is kind of personal message
> and it's quite clear that you forget to include something otherwise
> this notification would not appear, so it's like mocking you.

[Bug c++/53281] poor error message for calling a non-const method from a const object

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53281

--- Comment #7 from David Malcolm  ---
(In reply to David Malcolm from comment #6)
[...]
> We should also underline the param, or the "const" token.
(actually, if the member function or param is 'const', it's not a problem, I
think.  -ENOCOFFEE)

[Bug c++/53281] poor error message for calling a non-const method from a const object

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53281

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
   Target Milestone|--- |9.0

--- Comment #6 from David Malcolm  ---
Another example, given by reddit user "agcpp" here:
https://www.reddit.com/r/cpp/comments/84op5c/usability_improvements_in_gcc_8/dvvry8y/

> I'm little late to the party but want to add another example
> where diagnostics will improve overall experience -
> https://godbolt.org/g/kGKowz
>
> The diagnostics produced by MSVC here are just perfect, clang does
> seem a bit verbose but readable otoh gcc confuses anyone who
> hasn't been writing c++ for about 5 years :D



Code at that godbolt link:

#include 
using std::string;

void func(string ) {
s.clear();
}

int main() {
const string s = "20";
func(s);
}



MSVC 19 2017:

/opt/compiler-explorer/windows/19.10.25017/lib/native/include/xlocale(314):
warning C4530: C++ exception handler used, but unwind semantics are not
enabled. Specify /EHsc
(10): error C2664: 'void func(std::string &)': cannot convert argument
1 from 'const std::string' to 'std::string &'
(10): note: Conversion loses qualifiers



clang trunk:

:10:5: error: no matching function for call to 'func'
func(s);
^~~~
:4:6: note: candidate function not viable: 1st argument ('const
std::__cxx11::string' (aka 'const basic_string')) would lose const
qualifier
void func(string ) {
 ^
1 error generated.
Compiler returned: 1



gcc trunk:

: In function 'int main()':
:10:10: error: binding reference of type 'std::__cxx11::string&' {aka
'std::__cxx11::basic_string&'} to 'const string' {aka 'const
std::__cxx11::basic_string'} discards qualifiers
 func(s);
  ^
:4:6: note:   initializing argument 1 of 'void
func(std::__cxx11::string&)'
 void func(string ) {
  ^~~~
Compiler returned: 1



Part of the verbosity here relates to PR c++/84897 (reporting std::string
rather than std::__cxx11::string).

We're emitting a 28 words/~170 chars to seemingly talk about how:

  Compiler: "did you know that std::string is actually a
std::basic_string?"  mumble mumble, something
about a qualifier.

where the user has to spot the most pertinent word: "const" appearing in the
2nd pair of types, absent in the 1st pair of types.

Among other issues, the aka seems redundant/unhelpful here.

It seems best to special-case the "const member fn/param called with non-const"
cases and to report them directly in terms of the types in user's source with
and without "const", and to be explicit about which qualifier(s) are lost.

We should also underline the param, or the "const" token.

Proposed output for the above:

error: binding reference of type 'std::string&' to 'const string' discards
'const' qualifier
 func(s);
  ^
note:   initializing non-'const' argument 1 of 'void func(std::string&)'
 void func(string ) {
   ~~~^~

(though even that is a bit "compiler-ese"; might want to talk about it being a
call up-front)

Proposed output for the case in comment #3:

cv.cc: In member function ‘void Foo::bar2(const Foo&)’:
cv.cc:4:26: error: passing ‘const Foo’ as ‘this’ argument discards 'const'
qualifier [-fpermissive]
 foo.bar1();
  ^
cv.cc:2:14: note:   in call to ‘void Foo::bar1()’ which is non-const
 void bar1() {}
  ^~~~

I hope to fix these for gcc 9.

[Bug fortran/79929] [7 Regression] Bogus Warning: '__builtin_memset': specified size 4294967291 exceeds maximum object size 2147483647

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79929

--- Comment #30 from Dominique d'Humieres  ---
Fixed by revision r256284?

[Bug tree-optimization/84811] [8 Regression] ICE on valid code at -O3 in 64-bit mode on x86_64-linux-gnu: in smallest_mode_for_size, at stor-layout.c:355

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84811

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |8.0
Summary|ICE on valid code at -O3 in |[8 Regression] ICE on valid
   |64-bit mode on  |code at -O3 in 64-bit mode
   |x86_64-linux-gnu: in|on x86_64-linux-gnu: in
   |smallest_mode_for_size, at  |smallest_mode_for_size, at
   |stor-layout.c:355   |stor-layout.c:355

--- Comment #22 from Jakub Jelinek  ---
On #c21 this regressed with r255692.

[Bug tree-optimization/84811] ICE on valid code at -O3 in 64-bit mode on x86_64-linux-gnu: in smallest_mode_for_size, at stor-layout.c:355

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84811

Jakub Jelinek  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #21 from Jakub Jelinek  ---
Ah, ok, so the difference is in your case for some reason I don't understand
you get:
;; b[218][8] = 1;

(insn 28 27 29 (set (reg/f:DI 104)
(symbol_ref:DI ("b") [flags 0x2]  ))
"small.c":9 -1
 (nil))

(insn 29 28 30 (set (reg:DI 105)
(const_int 162675373468811328 [0x241f063e9500040])) "small.c":9 -1
 (nil))

(insn 30 29 31 (parallel [
(set (reg/f:DI 106)
(plus:DI (reg/f:DI 104)
(reg:DI 105)))
(clobber (reg:CC 17 flags))
]) "small.c":9 -1
 (nil))

(insn 31 30 0 (set (mem:DI (reg/f:DI 106) [2 b S8 A128])
(const_int 1 [0x1])) "small.c":9 -1
 (nil))
while I get:
;; b[218][8] = 1;

(insn 28 27 29 (set (reg/f:DI 104)
(symbol_ref:DI ("b") [flags 0x2]  ))
"small.c":9 -1
 (nil))

(insn 29 28 30 (set (reg:DI 105)
(const_int -9060696663385964480 [0x8241f063e9500040])) "small.c":9 -1
 (nil))

(insn 30 29 31 (parallel [
(set (reg/f:DI 106)
(plus:DI (reg/f:DI 104)
(reg:DI 105)))
(clobber (reg:CC 17 flags))
]) "small.c":9 -1
 (nil))

(insn 31 30 0 (set (mem:DI (reg/f:DI 106) [2 b S8 A128])
(const_int 1 [0x1])) "small.c":9 -1
 (nil))

Note that the topmost bit is lost.

Anyway, if I write what I see in your dump:
int a;
long b[1][9];
typedef long V __attribute__((vector_size (16), may_alias));

void
foo ()
{ 
  V *c = (V *) ((char *) b + -9060696663385964544);
  *c = (V) { 1, 1 };
  c++;
  *c = (V) { 1, 1 }; 
  c++;
  *c = (V) { 1, 1 };
  c++;
  *c = (V) { 1, 1 }; 
  long __attribute__((may_alias)) *d = (long *) ((char *) b +
162675373468811328);
  *d = 1;
}

then I get the ICE you are getting, so I'll have a look at that.

[Bug tree-optimization/84913] ICE vectorising chained conditional reduction

[rsandifo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84913

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Patch applied.

[Bug tree-optimization/84913] ICE vectorising chained conditional reduction

[rsandifo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84913

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Sun Mar 18 10:25:29 2018
New Revision: 258631

URL: https://gcc.gnu.org/viewcvs?rev=258631=gcc=rev
Log:
Don't try to vectorise COND_EXPR reduction chains (PR 84913)

The testcase ICEd for both SVE and AVX512 because we were trying
to vectorise a chain of COND_EXPRs as a reduction and getting
confused by reduc_index == -1.

2018-03-18  Richard Sandiford  

gcc/
PR tree-optimization/84913
* tree-vect-loop.c (vectorizable_reduction): Don't try to
vectorize chains of COND_EXPRs.

gcc/testsuite/
PR tree-optimization/84913
* gfortran.dg/vect/pr84913.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/vect/pr84913.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c

[Bug fortran/79929] [7 Regression] Bogus Warning: '__builtin_memset': specified size 4294967291 exceeds maximum object size 2147483647

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79929

--- Comment #29 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Mar 18 09:20:37 2018
New Revision: 258630

URL: https://gcc.gnu.org/viewcvs?rev=258630=gcc=rev
Log:
2018-03-18  Thomas Koenig  

PR fortran/79929
* gfortran.dg/warn_concat.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/warn_concat.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/84811] ICE on valid code at -O3 in 64-bit mode on x86_64-linux-gnu: in smallest_mode_for_size, at stor-layout.c:355

[su at cs dot ucdavis.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84811

--- Comment #20 from Zhendong Su  ---
Created attachment 43695
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43695=edit
output from "gcctk -O3 -S -da small.c"

[Bug tree-optimization/84811] ICE on valid code at -O3 in 64-bit mode on x86_64-linux-gnu: in smallest_mode_for_size, at stor-layout.c:355

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84811

--- Comment #19 from Jakub Jelinek  ---
Sorry, my fault, forgot about -da, can you repeat with that option as well?
Your optimized dump is identical to my, so if there is a difference (and there
must be, because the function in question isn't called for me), it must be
during the RTL passes.

[Bug fortran/77414] ICE in create_function_arglist, at fortran/trans-decl.c:2410

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77414

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|NEW |ASSIGNED
 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org

--- Comment #6 from kargl at gcc dot gnu.org ---
I have patch.