[Bug debug/92442] Compiling Boost.Spirit.X3 code uses exuberant amount of RAM with -gsplit-dwarf

2019-11-10 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92442

Richard Biener  changed:

   What|Removed |Added

   Keywords||memory-hog
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-11
 CC||rguenth at gcc dot gnu.org
  Component|c++ |debug
Summary|Compiling Boost.Spirit.X3   |Compiling Boost.Spirit.X3
   |code uses exuberant amount  |code uses exuberant amount
   |of RAM  |of RAM with -gsplit-dwarf
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I see 3GB of max-rss with 9.2.0 on x86_64-linux when omitting -gsplit-dwarf
which is 2GB less than clang?

> /usr/bin/time /space/rguenther/install/gcc-9.2/bin/g++ test.ii -S -g -fPIE 
> -std=c++17 -pedantic-errors -Wextra -Wconversion -Winit-self 
> -Wmissing-include-dirs -Wstrict-aliasing -Werror  -ffunction-sections 
> -fdata-sections -MD -MT test.o
55.33user 2.40system 1:04.57elapsed 89%CPU (0avgtext+0avgdata
2984564maxresident)k

> /usr/bin/time /space/rguenther/install/gcc-9.2/bin/g++ test.ii -S -g -fPIE 
> -std=c++17 -pedantic-errors -Wextra -Wconversion -Winit-self 
> -Wmissing-include-dirs -Wstrict-aliasing -Werror  -ffunction-sections 
> -fdata-sections -MD -MT test.o -gsplit-dwarf
109.28user 5.43system 2:05.93elapsed 91%CPU (0avgtext+0avgdata
7422548maxresident)k
0inputs+4904512outputs (0major+1867256minor)pagefaults 0swaps

so not sure why -gsplit-dwarf adds this amount of memory use... (looks like
a memory leak maybe...), but -gsplit-dwarf is poorly maintained.

[Bug c++/92450] [10 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in cp_parser_member_declaration, at cp/parser.c:25055

2019-11-10 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92450

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug target/92449] [10 Regression] ICE in extract_insn, at recog.c:2311

2019-11-10 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92449

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug c++/92451] [10 Regression] ICE: Segmentation fault (in add_candidates)

2019-11-10 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92451

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug c++/92447] [10 Regression] ICE in poplevel, at cp/decl.c:585

2019-11-10 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92447

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug c++/92451] New: [10 Regression] ICE: Segmentation fault (in add_candidates)

2019-11-10 Thread asolokha at gmx dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92451

Bug ID: 92451
   Summary: [10 Regression] ICE: Segmentation fault (in
add_candidates)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: error-recovery, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-10.0.0-alpha20191110 snapshot (r278028) ICEs when compiling the following
testcase reduced from test/CXX/temp/temp.deduct.guide/p3.cpp from the clang
9.0.0 testsuite:

template struct Local {};
void f() {
  Local(int);
}

% g++-10.0.0-alpha20191110 -std=c++17 -c dlhpwdpu.cpp
dlhpwdpu.cpp: In function 'void f()':
dlhpwdpu.cpp:3:12: error: class template argument deduction failed:
3 |   Local(int);
  |^
dlhpwdpu.cpp:3:12: internal compiler error: Segmentation fault
0xe81bf0 crash_signal
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/toplev.c:329
0x7ec36a add_candidates
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/call.c:5772
0x7f20d2 add_candidates
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/call.c:5696
0x7f20d2 perform_overload_resolution
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/call.c:4461
0x7f57ea build_new_function_call(tree_node*, vec**, int)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/call.c:4535
0x950b30 do_class_deduction
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/pt.c:28070
0x950b30 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/pt.c:28118
0x9c07cf build_functional_cast(tree_node*, tree_node*, int)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/typeck2.c:2270
0x8e8a9f cp_parser_functional_cast
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/parser.c:29182
0x8fed45 cp_parser_postfix_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/parser.c:7122
0x8e40a7 cp_parser_binary_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/parser.c:9480
0x8e4f7f cp_parser_assignment_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/parser.c:9780
0x8e520c cp_parser_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/parser.c:9948
0x8e8685 cp_parser_expression_statement
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/parser.c:11599
0x8f32b5 cp_parser_statement
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/parser.c:11395
0x8f4785 cp_parser_statement_seq_opt
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/parser.c:11742
0x8f4852 cp_parser_compound_statement
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/parser.c:11696
0x9098cf cp_parser_function_body
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/parser.c:22866
0x9098cf cp_parser_ctor_initializer_opt_and_function_body
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/parser.c:22917
0x90ca15 cp_parser_function_definition_after_declarator
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/parser.c:28586

[Bug c++/92441] [10 regression] ICE: in strip_typedefs, at cp/tree.c:1681

2019-11-10 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92441

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0
Summary|[10-regression] ICE: in |[10 regression] ICE: in
   |strip_typedefs, at  |strip_typedefs, at
   |cp/tree.c:1681  |cp/tree.c:1681

[Bug middle-end/92436] SIMD integer subtract with constant always becomes add

2019-11-10 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92436

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-11
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed, I think we have dups for this (also applies to FP non-vector
constants).

[Bug rtl-optimization/92430] [9/10 Regression] Compile-time hog w/ -Os -fno-if-conversion -fno-tree-dce -fno-tree-loop-optimize -fno-tree-vrp

2019-11-10 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92430

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-11
 CC||iii at gcc dot gnu.org
  Component|tree-optimization   |rtl-optimization
   Target Milestone|--- |9.3
Summary|[10 Regression] |[9/10 Regression]
   |Compile-time hog w/ -Os |Compile-time hog w/ -Os
   |-fno-if-conversion  |-fno-if-conversion
   |-fno-tree-dce   |-fno-tree-dce
   |-fno-tree-loop-optimize |-fno-tree-loop-optimize
   |-fno-tree-vrp   |-fno-tree-vrp
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
(gdb) bt
#0  set_depth_add (occ=0x34d4e18, d=7) at /tmp/trunk/gcc/et-forest.c:78
#1  0x00c36aee in et_splay (occ=0x34d4bb0)
at /tmp/trunk/gcc/et-forest.c:415
#2  0x00c36ed3 in et_split (t=0x3459d30)
at /tmp/trunk/gcc/et-forest.c:581
#3  0x00c36c60 in et_free_tree (t=0x3459ca0)
at /tmp/trunk/gcc/et-forest.c:485
#4  0x00b8e3f5 in delete_from_dominance_info (dir=CDI_DOMINATORS, 
bb=) at /tmp/trunk/gcc/dominance.c:1568
#5  0x00adee87 in delete_basic_block (
bb=) at /tmp/trunk/gcc/cfghooks.c:626
#6  0x01f83e9b in try_optimize_cfg (mode=40)
at /tmp/trunk/gcc/cfgcleanup.c:2752
#7  0x01f8536f in cleanup_cfg (mode=40)
at /tmp/trunk/gcc/cfgcleanup.c:3175
#8  0x01f855f9 in (anonymous
namespace)::pass_jump_after_combine::execute (this=0x33304c0) at
/tmp/trunk/gcc/cfgcleanup.c:3315
#9  0x010b20b7 in execute_one_pass (
(gdb) fin
Run till exit from #0  set_depth_add (occ=0x34d4e18, d=7)
at /tmp/trunk/gcc/et-forest.c:78
et_splay (occ=0x34d4bb0) at /tmp/trunk/gcc/et-forest.c:419
419   occ->parent = ggf;
(gdb) 
Run till exit from #0  et_splay (occ=0x34d4bb0)
at /tmp/trunk/gcc/et-forest.c:419

(hangs)

Ilya, this is likely caused by your pass reorg.  As this was also backported
please see where fixes are necessary.

[Bug c++/92450] New: [10 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in cp_parser_member_declaration, at cp/parser.c:25055

2019-11-10 Thread asolokha at gmx dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92450

Bug ID: 92450
   Summary: [10 Regression] ICE: tree check: expected tree that
contains 'decl minimal' structure, have 'error_mark'
in cp_parser_member_declaration, at cp/parser.c:25055
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: error-recovery, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-10.0.0-alpha20191110 snapshot (r278028) ICEs when compiling the following
testcase reduced from test/SemaCXX/nested-name-spec.cpp from the clang 9.0.0
testsuite:

typedef int C2;
struct B1 {
  struct B2 {
  };
};

struct S6g {
  C2 : B1:B2;
};

% g++-10.0.0-alpha20191110 -std=c++2a -c bjooa7xf.cpp
bjooa7xf.cpp:8:6: error: found ':' in nested-name-specifier, expected '::'
8 |   C2 : B1:B2;
  |  ^
  |  ::
bjooa7xf.cpp:8:6: error: invalid use of '::'
bjooa7xf.cpp:8:8: internal compiler error: tree check: expected tree that
contains 'decl minimal' structure, have 'error_mark' in
cp_parser_member_declaration, at cp/parser.c:25055
8 |   C2 : B1:B2;
  |^~
0x76a10a tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/tree.c:9859
0x628ef8 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/tree.h:3386
0x628ef8 cp_parser_member_declaration
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/parser.c:25055
0x8ed788 cp_parser_member_specification_opt
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/parser.c:24558
0x8ed788 cp_parser_class_specifier_1
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/parser.c:23658
0x8ef662 cp_parser_class_specifier
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/parser.c:23965
0x8ef662 cp_parser_type_specifier
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/parser.c:17566
0x8f0516 cp_parser_decl_specifier_seq
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/parser.c:14239
0x8f1164 cp_parser_simple_declaration
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/parser.c:13502
0x91749a cp_parser_declaration
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/parser.c:13322
0x9179ad cp_parser_translation_unit
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/parser.c:4721
0x9179ad c_parse_file()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/parser.c:42900
0xa1a0d9 c_common_parse_file()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/c-family/c-opts.c:1183

[Bug bootstrap/92433] [10 regression] r276645 breaks bootstrap on powerpc

2019-11-10 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92433

--- Comment #3 from Jakub Jelinek  ---
(In reply to Andreas Schwab from comment #2)
> That doesn't fix the spurious warning, though.

Sure, it doesn't, that was just a random comment when I have spent a minute
looking at the code in question.

[Bug bootstrap/92433] [10 regression] r276645 breaks bootstrap on powerpc

2019-11-10 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92433

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
 Blocks||24639
   Target Milestone|--- |10.0


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug target/92449] New: [10 Regression] ICE in extract_insn, at recog.c:2311

2019-11-10 Thread asolokha at gmx dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92449

Bug ID: 92449
   Summary: [10 Regression] ICE in extract_insn, at recog.c:2311
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-*-linux-gnu

gcc-10.0.0-alpha20191110 snapshot (r278028) ICEs when compiling
gcc/testsuite/gcc.dg/pr44214-2.c w/ -Ofast -fno-cx-limited-range:

% powerpc-e300c3-linux-gnu-gcc-10.0.0-alpha20191110 -Ofast
-fno-cx-limited-range -c gcc/testsuite/gcc.dg/pr44214-2.c
gcc/testsuite/gcc.dg/pr44214-2.c: In function 'do_div':
gcc/testsuite/gcc.dg/pr44214-2.c:7:1: error: unrecognizable insn:
7 | }
  | ^
(jump_insn 26 25 27 2 (set (pc)
(if_then_else (ordered (reg:CCFP 141)
(const_int 0 [0]))
(label_ref 43)
(pc))) -1
 (int_list:REG_BR_PROB 1073204964 (nil))
 -> 43)
during RTL pass: vregs
gcc/testsuite/gcc.dg/pr44214-2.c:7:1: internal compiler error: in extract_insn,
at recog.c:2311
0x66771c _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/rtl-error.c:108
0x66773c _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/rtl-error.c:116
0x665957 extract_insn(rtx_insn*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/recog.c:2311
0xac1a63 instantiate_virtual_regs_in_insn
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/function.c:1607
0xac1a63 instantiate_virtual_regs
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/function.c:1977
0xac1a63 execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/function.c:2026

[Bug c++/92421] [10 Regression] ice in inline_small_functions, at ipa-inline.c:2001

2019-11-10 Thread asolokha at gmx dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92421

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #4 from Arseny Solokha  ---
template  class mr {
};

template  struct ny;

template  struct ny> {
  using j5 = Y1 *;

  static void f4 (mr, int);
};

struct q1 : ny> {
};

class hn {
private:
  ~hn ()
  {
if (th != 0)
{
  mr vo;
  q1::f4 (vo, ow + 1);
}
  }

  friend class qn;
  int ow;
  q1::j5 th;
};

class n1 {
public:
  virtual ~n1 ();
};

class he : n1 {
private:
  int gk;
};

class zl : virtual he {
};

class qn {
  hn cq;
};

class ph : zl {
  qn au;
};

class uo : ph {
public:
  uo ();
};

int
main ()
{
  uo ();
  return 0;
}

% g++-10.0.0-alpha20191110 -O3 -c i3gqhfra.C
during IPA pass: inline
i3gqhfra.C:62:1: internal compiler error: in inline_small_functions, at
ipa-inline.c:2004
   62 | }
  | ^
0x7c75c3 inline_small_functions
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/ipa-inline.c:2004
0x7c75c3 ipa_inline
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/ipa-inline.c:2618
0x7c75c3 execute
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/ipa-inline.c:3018

[Bug tree-optimization/88760] GCC unrolling is suboptimal

2019-11-10 Thread guojiufu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760

--- Comment #43 from Jiu Fu Guo  ---
Author: guojiufu
Date: Mon Nov 11 06:30:38 2019
New Revision: 278034

URL: https://gcc.gnu.org/viewcvs?rev=278034=gcc=rev
Log:

rs6000: Refine small loop unroll in loop_unroll_adjust hook

In this patch, loop unroll adjust hook is introduced for powerpc.  We
can do target related heuristic adjustment in this hook.  In this patch,
-funroll-loops is enabled for small loops at O2 and above with an option
-munroll-small-loops to guard the small loops unrolling, and it works
fine with -flto.


gcc/
2019-11-11  Jiufu Guo  

PR tree-optimization/88760
* gcc/config/rs6000/rs6000.opt (-munroll-only-small-loops): New option.
* gcc/common/config/rs6000/rs6000-common.c
(rs6000_option_optimization_table) [OPT_LEVELS_2_PLUS_SPEED_ONLY]:
Turn on -funroll-loops and -munroll-only-small-loops.
[OPT_LEVELS_ALL]: Turn off -fweb and -frename-registers.
* config/rs6000/rs6000.c (rs6000_option_override_internal): Remove
set of PARAM_MAX_UNROLL_TIMES and PARAM_MAX_UNROLLED_INSNS.
Turn off -munroll-only-small-loops for explicit -funroll-loops.
(TARGET_LOOP_UNROLL_ADJUST): Add loop unroll adjust hook.
(rs6000_loop_unroll_adjust): Define it.  Use -munroll-only-small-loops.

gcc.testsuite/
2019-11-11  Jiufu Guo  

PR tree-optimization/88760
* gcc.dg/pr59643.c: Update back to r277550.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/common/config/rs6000/rs6000-common.c
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/rs6000.opt
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/pr59643.c

[Bug target/92448] New: Confusing using of TARGET_PREFER_AVX128

2019-11-10 Thread crazylht at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92448

Bug ID: 92448
   Summary: Confusing using of TARGET_PREFER_AVX128
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
CC: hjl.tools at gmail dot com, rguenth at gcc dot gnu.org,
uros at gcc dot gnu.org
  Target Milestone: ---
Target: i386, x86-64

In x86 backend, we have 2 macros related to 128-bit vectorization, one is
TARGET_AVX128_OPTIMAL which is a tune option.

#define TARGET_AVX128_OPTIMAL \ 
 ix86_tune_features[X86_TUNE_AVX128_OPTIMAL]

/* X86_TUNE_AVX128_OPTIMAL: Enable 128-bit AVX instruction generation for   
   the auto-vectorizer.  */ 
DEF_TUNE (X86_TUNE_AVX128_OPTIMAL, "avx128_optimal", m_BDVER | m_BTVER2 
  | m_ZNVER1 | m_CORE_AVX)  
---

another is TARGET_PREFER_AVX128
--
/* Use 128-bit AVX instructions in the auto-vectorizer.  */ 
#define TARGET_PREFER_AVX128(prefer_vector_width_type == PVW_AVX128)  
---

As my understanding, TARGET_PREFER_AVX128 only related to vector width choosing
in auto vectorization, it shouldn't be used for insntruction generation in md
file.
but I find many using of TARGET_PREFER_AVX128/256 in sse.md and i386.md which
makes it quite confusing.
--
 grep --color -nH -e TARGET_PREFER_AVX *.md 
 i386.md:3534: (not (match_test "TARGET_PREFER_AVX256")))   
 i386.md:3551:(cond [(and (ior (not (match_test
"TARGET_PREFER_AVX256"))
 i386.md:3716: (not (match_test "TARGET_PREFER_AVX256")))   
 i386.md:3738:(cond [(and (ior (not (match_test
"TARGET_PREFER_AVX256"))
 sse.md:7052:  if (TARGET_AVX && !TARGET_PREFER_AVX128 &&
optimize_insn_for_speed_p ())   
sse.md:7114:  if (TARGET_AVX && !TARGET_PREFER_AVX128 &&
optimize_insn_for_speed_p ())   
sse.md:7229:  if (TARGET_AVX && !TARGET_PREFER_AVX128 &&
optimize_insn_for_speed_p ())   
sse.md:17996:  && TARGET_AVX && !TARGET_PREFER_AVX128 &&
optimize_insn_for_speed_p ())   
sse.md:18128:  && TARGET_AVX && !TARGET_PREFER_AVX128 &&
optimize_insn_for_speed_p ())   
--

Should we change those TARGET_PREFER_AVX128 to TARGET_AVX128_OPTIMAL in *.md
files? So did TARGET_PREFER_AVX256.

[Bug c++/92447] New: [10 Regression] ICE in poplevel, at cp/decl.c:585

2019-11-10 Thread asolokha at gmx dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92447

Bug ID: 92447
   Summary: [10 Regression] ICE in poplevel, at cp/decl.c:585
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-10.0.0-alpha20191110 snapshot (r278028) ICEs when compiling the following
testcase reduced from test/clang-tidy/readability-deleted-default.cpp from the
clang-tools-extra 9.0.0 testsuite:

template 
void TemplateFunctionWithInnerClass() {
  class InnerNotAssignable {
  public:
InnerNotAssignable =(InnerNotAssignable &) = default;
  private:
const T TVar{};
  };
};

void Foo() {
  TemplateFunctionWithInnerClass();
}

% g++-10.0.0-alpha20191110 -c zg7svuec.cpp
zg7svuec.cpp: In instantiation of 'void TemplateFunctionWithInnerClass() [with
T = int]':
zg7svuec.cpp:12:39:   required from here
zg7svuec.cpp:8:4: internal compiler error: in poplevel, at cp/decl.c:585
8 |   };
  |^
0x5fa0af poplevel(int, int, int)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/decl.c:585
0x974569 do_poplevel(tree_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/semantics.c:452
0x9777d4 finish_compound_stmt(tree_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/semantics.c:1534
0x93f13b tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/pt.c:17819
0x939e0a tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/pt.c:17497
0x939e0a instantiate_decl(tree_node*, bool, bool)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/pt.c:25299
0x96682c instantiate_pending_templates(int)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/pt.c:25415
0x88545e c_parse_final_cleanups()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/decl2.c:4852

[Bug target/92437] Unnecessary register duplication of vector constant in x86

2019-11-10 Thread zingaburga+gcc at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92437

--- Comment #2 from zingaburga+gcc at hotmail dot com ---
Thanks for the info Andrew!
Changing the add to `_mm_add_epi64` does seem to eliminate all instances of the
duplication.

[Bug c++/92446] New: [10, C++20] template argument deduction fails for custom non-type parameters

2019-11-10 Thread dimitri.gorokhovik at free dot fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92446

Bug ID: 92446
   Summary: [10, C++20] template argument deduction fails for
custom non-type parameters
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimitri.gorokhovik at free dot fr
  Target Milestone: ---

g++ (GCC) 10.0.0 20191110 (experimental)

The below snippet fails, g++ fails to deduce the type of 'i'.  The error
messages are different from those when failure is due to the custom type not
being structural. It works as expected for non-custom "old-style" NTTP (if
"BUG" is defined to 0).


/gcc-trunk/dist/bin/g++ -std=c++2a -c test-1.cpp
test-1.cpp: In function ‘int main()’:
test-1.cpp:19:18: error: no matching function for call to ‘f(qq)’
   19 |   return f (qq {});
  |  ^
test-1.cpp:14:20: note: candidate: ‘template int f(const pp<((const
p)i)>&)’
   14 | template  int f (pp  const &);
  |^
test-1.cpp:14:20: note:   template argument deduction/substitution failed:
test-1.cpp:19:18: note:   couldn’t deduce template parameter ‘i’
   19 |   return f (qq {});
  |  ^


#define BUG 1

#if BUG
struct p { unsigned p_ {}; };
#else
using p = unsigned;
#endif

template  struct pp {};
struct qq : public pp  {};

template  int f (pp  const &);


int main ()
{
  return f (qq {});
};

[Bug fortran/91413] [F2018]: Procedures are recursive by default; switching from stack to static allocation is not safe

2019-11-10 Thread jb at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91413

--- Comment #5 from Janne Blomqvist  ---
Author: jb
Date: Sun Nov 10 21:25:25 2019
New Revision: 278027

URL: https://gcc.gnu.org/viewcvs?rev=278027=gcc=rev
Log:
Don't print warning when moving to static with -fno-automatic

As part of PR 91413, GFortran now prints a warning when a variable is
moved from the stack to static storage. However, when the user
explicitly specifies that all local variables should be put in static
storage with the -fno-automatic option, don't print this warning.

Regtested on x86_64-pc-linux-gnu, committed as obvious.

gcc/fortran/ChangeLog:

2019-11-10  Janne Blomqvist  

PR fortran/91413
* trans-decl.c (gfc_finish_var_decl): Don't print warning when
-fno-automatic is enabled.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c

[Bug c++/88337] Implement P1002R1, P1327R1, P1330R0, C++20 relaxations of constexpr restrictions.

2019-11-10 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88337

--- Comment #9 from Marek Polacek  ---
Not entirely true, this template case should be accepted:

#include 

struct B { virtual void f(); };
struct B2 : B { };

template
constexpr bool
fn ()
{
  constexpr B2 b2;
  static_assert((b2) == (B2));
  return true;
}

static_assert (fn());

[Bug bootstrap/92445] New: gcc bootstrap fails on Darwin 19.0.0 in stage 1

2019-11-10 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92445

Bug ID: 92445
   Summary: gcc bootstrap fails on Darwin 19.0.0 in stage 1
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

Under macOS Catalina (Darwin 19.0.0) bootstrap fails with the following error
message:
libtool: compile:  /usr/local/packages/gcc_10.0/_build/./gcc/xgcc
-shared-libgcc -B/usr/local/packages/gcc_10.0/_build/./gcc -nostdinc++
-L/usr/local/packages/gcc_10.0/_build/x86_64-apple-darwin19.0.0/libstdc++-v3/src
-L/usr/local/packages/gcc_10.0/_build/x86_64-apple-darwin19.0.0/libstdc++-v3/src/.libs
-L/usr/local/packages/gcc_10.0/_build/x86_64-apple-darwin19.0.0/libstdc++-v3/libsupc++/.libs
-B/usr/local/x86_64-apple-darwin19.0.0/bin/
-B/usr/local/x86_64-apple-darwin19.0.0/lib/ -isystem
/usr/local/x86_64-apple-darwin19.0.0/include -isystem
/usr/local/x86_64-apple-darwin19.0.0/sys-include -fno-checking
-I/usr/local/packages/gcc_10.0/libstdc++-v3/../libgcc
-I/usr/local/packages/gcc_10.0/_build/x86_64-apple-darwin19.0.0/libstdc++-v3/include/x86_64-apple-darwin19.0.0
-I/usr/local/packages/gcc_10.0/_build/x86_64-apple-darwin19.0.0/libstdc++-v3/include
-I/usr/local/packages/gcc_10.0/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=atexit_thread.lo -g -O2 -c
../../../../libstdc++-v3/libsupc++/atexit_thread.cc  -fno-common -DPIC
-D_GLIBCXX_SHARED -o atexit_thread.o
In file included from
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/wait.h:110,
 from
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdlib.h:66,
 from
/usr/local/packages/gcc_10.0/_build/x86_64-apple-darwin19.0.0/libstdc++-v3/include/cstdlib:75,
 from ../../../../libstdc++-v3/libsupc++/atexit_thread.cc:25:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/resource.h:447:34:
error: expected initializer before ‘__OSX_AVAILABLE_STARTING’
  447 | int getiopolicy_np(int, int) __OSX_AVAILABLE_STARTING(__MAC_10_5,
__IPHONE_2_0);
  |  ^~~~
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/resource.h:453:39:
error: expected initializer before ‘__OSX_AVAILABLE_STARTING’
  453 | int setiopolicy_np(int, int, int)
__OSX_AVAILABLE_STARTING(__MAC_10_5, __IPHONE_2_0);
  |   ^~~~
In file included from
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdlib.h:128,
 from
/usr/local/packages/gcc_10.0/_build/x86_64-apple-darwin19.0.0/libstdc++-v3/include/cstdlib:75,
 from ../../../../libstdc++-v3/libsupc++/atexit_thread.cc:25:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/malloc/_malloc.h:52:74:
error: expected initializer before ‘__OSX_AVAILABLE_STARTING’
   52 | int   posix_memalign(void **__memptr, size_t __alignment, size_t
__size) __OSX_AVAILABLE_STARTING(__MAC_10_6, __IPHONE_3_0);
  |
 ^~~~
In file included from
/usr/local/packages/gcc_10.0/_build/x86_64-apple-darwin19.0.0/libstdc++-v3/include/cstdlib:75,
 from ../../../../libstdc++-v3/libsupc++/atexit_thread.cc:25:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdlib.h:270:53:
error: expected initializer before ‘__OSX_AVAILABLE_STARTIN’
  270 | void  arc4random_buf(void * __buf, size_t __nbytes)
__OSX_AVAILABLE_STARTING(__MAC_10_7, __IPHONE_4_3);
  |
^~~~
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdlib.h:273:46:
error: expected initializer before ‘__OSX_AVAILABLE_STARTIN’
  273 |   arc4random_uniform(uint32_t __upper_bound)
__OSX_AVAILABLE_STARTING(__MAC_10_7, __IPHONE_4_3);
  |  ^~~~
In file included from
/usr/local/packages/gcc_10.0/_build/x86_64-apple-darwin19.0.0/libstdc++-v3/include/cstdlib:75,
 from ../../../../libstdc++-v3/libsupc++/atexit_thread.cc:25:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdlib.h:292:45:
error: expected 

[Bug debug/92444] gcc generates wrong debug information at -O2 and -O3

2019-11-10 Thread qrzhang at gatech dot edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92444

Qirun Zhang  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #1 from Qirun Zhang  ---
Bisect points to r277424.

commit 096bdef978db42b89b3c173f61c8c102cd6bf470
Author: hubicka 
Date:   Thu Oct 24 22:19:09 2019 +

* cgraphunit.c (symbol_table::process_new_functions): Call
ipa_free_size_summary.
* ipa-cp.c (ipcp_cloning_candidate_p): Update.
(devirtualization_time_bonus): Update.
(ipcp_propagate_stage): Update.
* ipa-fnsummary.c (ipa_size_summaries): New.
(ipa_fn_summary_alloc): Alloc size summary.
(dump_ipa_call_summary): Update.
(ipa_dump_fn_summary): Update.
(analyze_function_body): Update.
(compute_fn_summary): Likewise.
(ipa_get_stack_frame_offset): New function.
(inline_update_callee_summaries): Do not update frame offsets.
(ipa_merge_fn_summary_after_inlining): Update frame offsets here;
remove call and function summary.
(ipa_update_overall_fn_summary): Update.
(inline_read_section): Update.
(ipa_fn_summary_write): Update.
(ipa_free_fn_summary): Do not remove summaries.
(ipa_free_size_summary): New.
(release summary pass): Also run at WPA.
* ipa-fnsummary.h (ipa_size_summary): Declare.
(ipa_fn_summary): Remove size, self_size, stack_frame_offset,
estimated_self_stack_size.
(ipa_size_summary_t): New type.
(ipa_size_summaries): Declare.
(ipa_free_size_summary): Declare.
(ipa_get_stack_frame_offset): Declare.
* ipa-icf.c (sem_function::merge): Update.
* ipa-inline-analysis.c (estimate_size_after_inlining): Update.
(estimate_growth): Update.
(growth_likely_positive): Update.
(clone_inlined_nodes): Update.
(inline_call): Update.
* ipa-inline.c (caller_growth_limits): Update.

<...>

[Bug c++/88337] Implement P1002R1, P1327R1, P1330R0, C++20 relaxations of constexpr restrictions.

2019-11-10 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88337

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #8 from Marek Polacek  ---
Patch posted:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00650.html

For the typeid case, it seems that all that needs to be done is to resolve

 356   /* FIXME when integrating with c_fully_fold, mark
 357  resolves_to_fixed_type_p case as a non-constant expression.  */
 358   if (TYPE_POLYMORPHIC_P (TREE_TYPE (exp))
 359   && ! resolves_to_fixed_type_p (exp, )
 360   && ! nonnull)

[Bug debug/92444] New: gcc generates wrong debug information at -O2 and -O3

2019-11-10 Thread qrzhang at gatech dot edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92444

Bug ID: 92444
   Summary: gcc generates wrong debug information at -O2 and -O3
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qrzhang at gatech dot edu
  Target Milestone: ---

It seems to be a recent regression. gcc-9 works fine.
The expected output is 1. With "-O2" and "-O3", gdb outputs 8.

$ gcc-trunk -v
Supported LTO compression algorithms: zlib
gcc version 10.0.0 20191110 (experimental) [trunk revision 278017] (GCC)


#Expected output
$ gcc-trunk -g abc.c
$ gdb-trunk -x cmds -batch a.out
Breakpoint 1 at 0x400592: file abc.c, line 46.

Breakpoint 1, o () at abc.c:46
46  }
$1 = 1

#Wrong output at O2 and O3
$ gcc-trunk -g abc.c -O2
$ gdb-trunk -x cmds -batch a.out
Breakpoint 1 at 0x4005ac: file abc.c, line 45.

Breakpoint 1, o () at abc.c:45
45}; // optimize_me_not()
$1 = 8



$ cat abc.c
int a[1];
char b;
char *c = 
int d, h, l, m, ag, ah;
int *e = 
short f, g;
unsigned j;
long n;
char aa[10];
static unsigned char o(void);
static int *p(int *);
static int y() {
  int q = 6, r = 0;
  int *s;
  short *t, *u = 
  l = p();
  o();
  if (n) {
int v = 0, w;
int x[] = {, };
b = *s;
w = 
  }
}
unsigned char o() {
  int l_1339[3];
  int *ab = _1339[2];
  int k;
  m = 0;
  for (; m < 3; m++)
l_1339[m] = 8;
  p(l_1339);
  for (; j <= 7; j++) {
for (;; f--)
  if (*a)
break;
char *ac;
char *ad[30];
char *ae = ad;
char *f = 
k = 0;
for (; k < 3; k++)
  ad[k] = 
*ab = 0 != 
  }; // optimize_me_not()
}
int *p(int *z) {
  long af = 5;
  for (; af < 30; af = af + 6)
h = *z;
  int i = 0;
  for (; i < 10; i++)
aa[i] = *a = *c ^ 2;
  *e = ag;
  return ah;
}
int main() { y(); }



$ cat cmds
b abc.c:45
r
p l_1339[2]
kill
q

[Bug c++/80635] std::optional and bogus -Wmaybe-uninitialized warning

2019-11-10 Thread jamborm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635

--- Comment #27 from Martin Jambor  ---
(In reply to Manuel López-Ibáñez from comment #26)
> Hi Martin,
> 
> Wouldn't it be better if the testcase tested that no warning is given for a
> true case? Otherwise if the bug is fixed, no warning will be given, no
> matter the option. Or have a testcase that the warning is given with the
> option and not without .

I had to change a few testcases to use the new option so it is tested
to exist and work in that way.  I definitely do not want to add a test
ensuring we produce a false-positive warning to the testcase and a
test that a true positive is not given with the weaker option seems of
little value for me too.  But if people think it is useful, I guess I
could add one.

[Bug c++/92443] [10 Regression] ICE in joust, at cp/call.c:11166

2019-11-10 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92443

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-10
 CC||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
   Target Milestone|--- |10.0
Summary|icein joust, at |[10 Regression] ICE in
   |cp/call.c:11166 |joust, at cp/call.c:11166
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with r277865.

[Bug tree-optimization/92429] [10 Regression] ICE in vect_transform_stmt, at tree-vect-stmts.c:10918

2019-11-10 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92429

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-11-10
 CC||marxin at gcc dot gnu.org
  Known to work||9.2.0
   Assignee|unassigned at gcc dot gnu.org  |avieira at gcc dot 
gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1
  Known to fail||10.0

--- Comment #1 from Martin Liška  ---
With --param vect-epilogues-nomask=1, it started with r277569.

[Bug c++/92443] New: icein joust, at cp/call.c:11166

2019-11-10 Thread dcb314 at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92443

Bug ID: 92443
   Summary: icein joust, at cp/call.c:11166
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

This C++ code:

struct a {
  constexpr a(long) : b() {}
  operator long() const;
  operator bool();
  constexpr friend a operator|(a, a c) { return c; }
  long b;
};
using d = a;
constexpr d e = 6, f = f | e;

does this:

bug563.cc:9:28: internal compiler error: in joust, at cp/call.c:11166
9 | constexpr d e = 6, f = f | e;
  |^
0x5e28de joust
../../trunk/gcc/cp/call.c:11166
0x8e67c0 tourney
../../trunk/gcc/cp/call.c:11565
0x8ef2d3 build_new_op_1
../../trunk/gcc/cp/call.c:6201
0x8efbdd build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node**, int)
../../trunk/gcc/cp/call.c:6490

with recent gcc trunk. The bug first seems to occur between revision
277850 and 277900.

[Bug c++/92442] New: Compiling Boost.Spirit.X3 code uses exuberant amount of RAM

2019-11-10 Thread vanboxem.ruben at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92442

Bug ID: 92442
   Summary: Compiling Boost.Spirit.X3 code uses exuberant amount
of RAM
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vanboxem.ruben at gmail dot com
  Target Milestone: ---

Created attachment 47207
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47207=edit
preprocessed source for reproduction

Compiling the attached preprocessed code like this:
g++ -pedantic-errors -Wextra -Wconversion -Winit-self -Wmissing-include-dirs
-Wstrict-aliasing -Werror  -ffunction-sections -fdata-sections -gsplit-dwarf -g
-fPIE   -std=c++17 -MD -MT test.o test.ii
consumes a peak amount of 7227,6 MB of RAM. Subsequent assembler call uses 2283
MB of RAM.

Clang 9 uses 4941 MB of RAM, which is also quite a lot, but almost 2 GB less.

[Bug fortran/92123] [F2018/array-descriptor] Scalar allocatable/pointer with array descriptor (via bind(C)): ICE with select rank or error scalar variable with POINTER or ALLOCATABLE in procedure wit

2019-11-10 Thread pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92123

--- Comment #3 from Paul Thomas  ---
Author: pault
Date: Sun Nov 10 18:33:00 2019
New Revision: 278025

URL: https://gcc.gnu.org/viewcvs?rev=278025=gcc=rev
Log:
2019-11-10  Paul Thomas  

PR fortran/92123
*decl.c (gfc_verify_c_interop_param): Remove error asserting
that pointer or allocatable variables in a bind C procedure are
not supported. Delete some trailing spaces.
* trans-stmt.c (trans_associate_var): Correct the attempt to
treat scalar pointer or allocatable temporaries as if they are
array descriptors.

2019-11-10  Paul Thomas  

PR fortran/92123
* gfortran.dg/bind_c_procs_3.f90 : New test.
* gfortran.dg/ISO_Fortran_binding_15.c : New test.
* gfortran.dg/ISO_Fortran_binding_15.f90 : Additional source.


Added:
trunk/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_15.c
trunk/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_15.f90
trunk/gcc/testsuite/gfortran.dg/bind_c_procs_3.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/92441] New: [10-regression] ICE: in strip_typedefs, at cp/tree.c:1681

2019-11-10 Thread h2+bugs at fsfe dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92441

Bug ID: 92441
   Summary: [10-regression] ICE: in strip_typedefs, at
cp/tree.c:1681
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: h2+bugs at fsfe dot org
  Target Milestone: ---

Created attachment 47206
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47206=edit
intermediate code

Intermediate code is attached. Build with -std=c++17 -fconcepts.

Possibly related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91930 (but not
fixed by the proposed patch).

GCC version: g++10 (FreeBSD Ports Collection) 10.0.0 20191103

Log:

In file included from
/home/hannes/devel/seqan3/submodules/range-v3/include/range/v3/iterator/concepts.hpp:30,
 from
/home/hannes/devel/seqan3/submodules/range-v3/include/range/v3/range/concepts.hpp:28,
 from /home/hannes/devel/seqan3/include/seqan3/std/ranges:28,
 from
/home/hannes/devel/seqan3/include/seqan3/core/concept/core_language.hpp:19,
 from
/home/hannes/devel/seqan3/include/seqan3/alphabet/concept.hpp:17,
 from
/home/hannes/devel/seqan3/test/unit/alphabet/nucleotide/../alphabet_constexpr_test_template.hpp:10,
 from
/home/hannes/devel/seqan3/test/unit/alphabet/nucleotide/dna4_test.cpp:8:
/home/hannes/devel/seqan3/submodules/range-v3/include/range/v3/iterator/access.hpp:222:76:
internal compiler error: in strip_typedefs, at cp/tree.c:1681
  222 | is_swappable_with,
iter_reference_t>::value>
  |
   ^~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c++/92440] New: Error output for first error truncated with -fmax-errors=1

2019-11-10 Thread travis.downs at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92440

Bug ID: 92440
   Summary: Error output for first error truncated with
-fmax-errors=1
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: travis.downs at gmail dot com
  Target Milestone: ---

Consider the following code snippet:

template 
struct S {
template 
friend struct S; 
};

S<0> s;

Compiled with gcc trunk 10.0.0 and any earlier version I tried, it produces
with following error without any explicit command line flags:

1
x86-64 gcc (trunk)
- cached

#2 with x86-64 gcc (trunk)

: In instantiation of 'struct S<0>':

:7:6:   required from here

:1:15: error: template parameter 'int T'

1 | template 

  |   ^

:4:19: error: redeclared here as 'class U'

4 | friend struct S;

  |   ^

Compiler returned: 1

That's logically a single error.

With -fmax-errors=1 the error is truncated in the middle of a "sentence" with
only the first part visible, which prevents understanding the error:

: In instantiation of 'struct S<0>':

:7:6:   required from here

:1:15: error: template parameter 'int T'

1 | template 

  |   ^

compilation terminated due to -fmax-errors=1.

Compiler returned: 1


Godbolt link:

https://godbolt.org/z/bX2z4f

[Bug fortran/67202] Fortran FE should load scalar pass-by-reference intent-in arguments at the beginning of a function

2019-11-10 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67202

Thomas Koenig  changed:

   What|Removed |Added

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

[Bug c++/92439] New: [10, concepts] trunk crashes on constraint satisfaction failure

2019-11-10 Thread dimitri.gorokhovik at free dot fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92439

Bug ID: 92439
   Summary: [10, concepts] trunk crashes on constraint
satisfaction failure
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimitri.gorokhovik at free dot fr
  Target Milestone: ---

Created attachment 47205
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47205=edit
Code sample reproducing teh crash

g++ (GCC) 10.0.0 20191110 (experimental)

~/gcc-trunk/dist/bin/g++ -std=c++2a -c bug.cpp


bug.cpp:60:70: error: template constraint failure for ‘template 
requires ((... && Bitf)) && (dont_overlap) struct encoding’
   60 | using b = encoding , bf <5, 2>, list , bf <0, 3>>>;
  |  ^
bug.cpp:60:70: note: constraints not satisfied
bug.cpp:58:61:   required by the constraints of ‘template 
requires ((... && Bitf)) && (dont_overlap) struct encoding’
bug.cpp:60:70: error: concept satisfaction failed
g++: internal compiler error: Segmentation fault signal terminated program
cc1plus


Program received signal SIGSEGV, Segmentation fault.
satisfy_constraint_r(tree_node*, tree_node*, subst_info) [clone .isra.0] () at
../../srcdir/gcc/tree.h:3271
3271  if (TREE_CODE (__t) != __c)
(gdb) bt
#0  satisfy_constraint_r(tree_node*, tree_node*, subst_info) [clone .isra.0] ()
at ../../srcdir/gcc/tree.h:3271
#1  0x0089659c in satisfy_constraint (t=0x770d07f8,
args=0x770ddbc0, info=..., info=...) at
../../srcdir/gcc/cp/constraint.cc:2554
#2  0x00896f30 in satisfy_constraint_expression(tree_node*, tree_node*,
subst_info) [clone .isra.0] () at ../../srcdir/gcc/cp/constraint.cc:2592
#3  0x0089749b in evaluate_concept_check(tree_node*, int) () at
../../srcdir/gcc/cp/constraint.cc:2735
#4  0x0099e171 in tsubst_copy_and_build(tree_node*, tree_node*, int,
tree_node*, bool, bool) [clone .part.0] () at ../../srcdir/gcc/cp/pt.c:18848
#5  0x009a5899 in tsubst_copy_and_build
(integral_constant_expression_p=false, function_p=false,
in_decl=0x770cd580, complain=3, args=, t=0x770cbf78)
at ../../srcdir/gcc/cp/pt.c:18752
#6  tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) [clone .part.0]
() at ../../srcdir/gcc/cp/pt.c:18410
#7  0x009adc2b in tsubst_expr (integral_constant_expression_p=false,
in_decl=0x770cd580, complain=3, args=0x770ddae0, t=0x770cbf78) at
../../srcdir/gcc/cp/pt.c:17497
#8  gen_elem_of_pack_expansion_instantiation (in_decl=,
complain=, args=, index=,
parm_packs=, 
pattern=) at ../../srcdir/gcc/cp/pt.c:12213
#9  tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*) () at
../../srcdir/gcc/cp/pt.c:12842
#10 0x009b29b9 in tsubst_fold_expr_pack (in_decl=0x770cd580,
complain=3, args=0x770dd700, t=0x770d) at
../../srcdir/gcc/tree.h:3337
#11 tsubst_unary_left_fold (in_decl=0x770cd580, complain=3,
args=0x770dd700, t=0x770d) at ../../srcdir/gcc/cp/pt.c:12329
#12 tsubst_copy(tree_node*, tree_node*, int, tree_node*) () at
../../srcdir/gcc/cp/pt.c:16643
#13 0x0099d551 in tsubst_copy_and_build(tree_node*, tree_node*, int,
tree_node*, bool, bool) [clone .part.0] () at ../../srcdir/gcc/cp/pt.c:20154
#14 0x009a5899 in tsubst_copy_and_build
(integral_constant_expression_p=false, function_p=false,
in_decl=0x770cd580, complain=3, args=, t=0x770d)
at ../../srcdir/gcc/cp/pt.c:18752
#15 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) [clone .part.0]
() at ../../srcdir/gcc/cp/pt.c:18410
#16 0x009ac157 in tsubst_expr (t=t@entry=0x770d,
args=args@entry=0x770dd700, complain=complain@entry=3,
in_decl=in_decl@entry=0x770cd580, 
integral_constant_expression_p=integral_constant_expression_p@entry=false)
at ../../srcdir/gcc/cp/pt.c:17497
#17 0x00895d34 in satisfy_constraint_r(tree_node*, tree_node*,
subst_info) [clone .isra.0] () at ../../srcdir/gcc/cp/constraint.cc:2480
#18 0x008959a3 in satisfy_constraint_r(tree_node*, tree_node*,
subst_info) [clone .isra.0] () at ../../srcdir/gcc/cp/constraint.cc:2530
#19 0x0089659c in satisfy_constraint (t=t@entry=0x770e12d0,
args=args@entry=0x770c8fc0, info=..., info=...) at
../../srcdir/gcc/cp/constraint.cc:2554
#20 0x0089737b in satisfy_associated_constraints (info=..., info=...,
args=0x770c8fc0, t=0x770e12d0) at
../../srcdir/gcc/cp/constraint.cc:2572
#21 constraints_satisfied_p(tree_node*, tree_node*, subst_info) [clone
.constprop.0] () at ../../srcdir/gcc/cp/constraint.cc:2698
#22 0x00897d27 in diagnose_constraints (loc=,
t=t@entry=0x770cd580, args=args@entry=0x770c8fc0) at
../../srcdir/gcc/cp/constraint.cc:3306
#23 0x009b

[Bug c++/92438] New: Function declaration parsed incorrectly with `-std=c++1z`

2019-11-10 Thread sagebar at web dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92438

Bug ID: 92438
   Summary: Function declaration parsed incorrectly with
`-std=c++1z`
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sagebar at web dot de
  Target Milestone: ---

Created attachment 47204
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47204=edit
Demonstration of incorrect parsing + several work-arounds

Functions declarations returning a typedef'ed struct-type, and having their
names wrapped by parenthesis, as well as a calling-convention attribute within
those parenthesis, causes g++ to think that it's a variable declaration, rather
than a function declaration.

Essentially, given something like this:
```
typedef struct myint_struct { int x; } MYINT;
```

All of the following declarations get parsed correctly:
```
MYINT (myabs1)(MYINT x);
MYINT __attribute__((stdcall)) myabs2(MYINT x);
struct myint_struct (__attribute__((stdcall)) myabs3)(MYINT x);
```

However, this declaration (incorrectly) causes a parser error:
```
MYINT (__attribute__((stdcall)) myabs4)(MYINT x);
```

Note that the problem only appears when `-std=c++1z` or `-std=gnu++1z` is
passed on the commandline, such that you can re-produce the problem with the
attached file and:
```
g++ -c -std=c++1z attached-file.cc
g++ -c -std=gnu++1z attached-file.cc
```

However, compiling it without any special std=... flag doesn't produce any
errors:
```
g++ -c attached-file.cc
```

[Bug fortran/92113] [8/9 regression] r276673 causes segfault in gfortran.dg/pr51434.f90

2019-11-10 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92113

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #12 from Thomas Koenig  ---
Fixed on all affected branches.

Thanks for the bug report!

[Bug fortran/92113] [8/9 regression] r276673 causes segfault in gfortran.dg/pr51434.f90

2019-11-10 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92113

--- Comment #11 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Nov 10 12:07:56 2019
New Revision: 278018

URL: https://gcc.gnu.org/viewcvs?rev=278018=gcc=rev
Log:
Put vtab into RO section, same for __def_init if it contains an initializer.


2019-11-10  Thomas Koenig  

Backport from trunk
PR fortran/92113
* trans-decl.c (gfc_get_symbol_decl): If __def_init actually
contains a value, put it into  the read-only section.

Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/trans-decl.c

[Bug fortran/92113] [8/9 regression] r276673 causes segfault in gfortran.dg/pr51434.f90

2019-11-10 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92113

--- Comment #10 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Nov 10 11:19:13 2019
New Revision: 278015

URL: https://gcc.gnu.org/viewcvs?rev=278015=gcc=rev
Log:
Put vtab into RO section, same for __def_init if it contains an initializer.

2019-11-10  Thomas Koenig  

Backport from trunk
PR fortran/92113
* trans-decl.c (gfc_get_symbol_decl): If __def_init actually
contains a value, put it into  the read-only section.


Modified:
branches/gcc-9-branch/gcc/fortran/ChangeLog
branches/gcc-9-branch/gcc/fortran/trans-decl.c

[Bug fortran/92321] [9 Regression] GCC 9.2.0 ICE: fexternal-blas with optimization

2019-11-10 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92321

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #8 from Thomas Koenig  ---
Fixed on all affected branches.

Thanks for the bug report!

[Bug fortran/92321] [9 Regression] GCC 9.2.0 ICE: fexternal-blas with optimization

2019-11-10 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92321

--- Comment #7 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Nov 10 09:34:42 2019
New Revision: 278014

URL: https://gcc.gnu.org/viewcvs?rev=278014=gcc=rev
Log:
Commit symbol for external BLAS routine when translating MATMUL to *GEMM. 

2019-11-10  Thomas Koenig  

Backport from trunk
PR fortran/92321
* frontend-passes.c (call_external_blas): Commit symbol for
external BLAS routine.

2019-11-10  Thomas Koenig  

Backport from trunk
PR fortran/92321
* gfortran.dg/matmul_blas_2.f90: New test.


Added:
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/matmul_blas_2.f90
Modified:
branches/gcc-9-branch/gcc/fortran/ChangeLog
branches/gcc-9-branch/gcc/fortran/frontend-passes.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug target/92437] Unnecessary register duplication of vector constant in x86

2019-11-10 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92437

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-10
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
Part of it is because GCC did the conversion to vector unsigned long but then
does not detect the following two const_vect's are the same:
(const_vector:V16QI [
(const_int 99 [0x63]) repeated x16
])

(const_vector:V2DI [
(const_int 7161677110969590627 [0x6363636363636363])
repeated x2
])

(except for the different modes).

[Bug target/92437] New: Unnecessary register duplication of vector constant in x86

2019-11-10 Thread zingaburga+gcc at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92437

Bug ID: 92437
   Summary: Unnecessary register duplication of vector constant in
x86
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zingaburga+gcc at hotmail dot com
  Target Milestone: ---

Consider the following code example:

#include 
void fn(__m128i* in, __m128i* out) {
int i=0;
const __m128i num = _mm_set1_epi8(99);
while(i<100) {
__m128i a = in[i];
__m128i b = _mm_add_epi8(a, num);
if(_mm_movemask_epi8(b))
a = _mm_or_si128(a, num);
if(_mm_movemask_epi8(a))
a = _mm_or_si128(a, num);
out[i] = a;
i++;
}
}

The vector `num` is referenced 3 times in the loop, and GCC seems to load it
into 3 separate registers, when 1 would suffice: https://godbolt.org/z/mP22ez
(in this link, the `99` vector is held in xmm2, xmm3 and xmm4).

This seems to be the case regardless of AVX being enabled or not.

I don't really get what a possible cause for this is, but it seems that the
`if` conditions are necessary to trigger this effect.

[Bug target/92140] clang vs gcc optimizing with adc/sbb

2019-11-10 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140

--- Comment #31 from Segher Boessenkool  ---
(In reply to Segher Boessenkool from comment #29)
> Does it help the i386 port if we disallow a hard reg dest as well?
> RA should be able to handle that just fine as well.

I tried this out, and it creates much worse code (much bigger, anyway),
on all targets.