[Bug c++/84840] [6/7/8 Regression] ICE (in poplevel_class) for `auto` in alias declaration

2018-03-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84840

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-13
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |6.5
Summary|ICE (in poplevel_class) for |[6/7/8 Regression] ICE (in
   |`auto` in alias declaration |poplevel_class) for `auto`
   ||in alias declaration
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r202612.  This one wouldn't be fixed even with an error in there
instead of pedwarn - the ICE happens even with -pedantic-errors.

[Bug c++/84839] [6/7/8 Regression] ICE (Segmentation fault) when `decltype` is used with parameter pack

2018-03-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84839

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-13
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |6.5
Summary|ICE (Segmentation fault)|[6/7/8 Regression] ICE
   |when `decltype` is used |(Segmentation fault) when
   |with parameter pack |`decltype` is used with
   ||parameter pack
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
This got rejected still in r182662
pr84839.C: In instantiation of ‘struct S’:
pr84839.C:6:17:   required from here
pr84839.C:3:51: error: expansion pattern ‘int’ contains no argument packs
and segfaults already in r182686, don't have the revisions in between, but most
likely either r182668 or r182667.
The segfault is infinite recursion of tsubst_pack_expansion -> tsubst_decl ->
tsubst -> tsubst_decl, wonder why the instantiation depth limits don't catch
it.

[Bug tree-optimization/84830] [8 Regression] ICE in compute_antic, at tree-ssa-pre.c:2388

2018-03-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84830

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |8.0

[Bug ipa/84833] [8 Regression] target_clones regression since r251047

2018-03-13 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84833

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Let me take care of it.

[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

2018-03-13 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84811

--- Comment #5 from Martin Liška  ---
> gcc version 8.0.1 20180310 (experimental) [trunk revision 258413] (GCC)

Just a nit, this revision mentioned above is actually from GCC 7 branch. Isn't
that the issue?

[Bug ipa/84833] [8 Regression] target_clones regression since r251047

2018-03-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84833

--- Comment #2 from Jakub Jelinek  ---
Just a note, as can be seen e.g. on
static volatile int a;
static int my_foo1 (void) { return 1; }
static int my_foo2 (void) { return 2; }
typedef int (*F) (void);
static F resolve_foo (void) { if (a) return my_foo1; else return my_foo2; }
static int foo (void) __attribute__ ((ifunc ("resolve_foo")));

int
main ()
{
  if (foo () != 2)
__builtin_abort ();
}
there is no reason why any of the target clones, resolver or the ifunc function
should be .globl, they can all be local to the TU, IFUNC work just fine that
way too.  So, if the function with target_clones attribute is not TREE_PUBLIC,
neither should be any of the multiple_targets.c created symbols.

[Bug target/84786] [miscompilation] vunpcklpd accessing xmm16-22 targeting KNL

2018-03-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84786

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Tue Mar 13 08:03:28 2018
New Revision: 258475

URL: https://gcc.gnu.org/viewcvs?rev=258475&root=gcc&view=rev
Log:
PR target/84786
* config/i386/sse.md (sse2_loadhpd): Use Yv constraint rather than v
on the last operand.

* gcc.target/i386/avx512f-pr84786-1.c: New test.
* gcc.target/i386/avx512f-pr84786-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/avx512f-pr84786-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-pr84786-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

[Bug target/84828] ICE in verify_flow_info at gcc/cfghooks.c:265

2018-03-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84828

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Tue Mar 13 08:04:54 2018
New Revision: 258476

URL: https://gcc.gnu.org/viewcvs?rev=258476&root=gcc&view=rev
Log:
PR target/84828
* reg-stack.c (change_stack): Change update_end var from int to
rtx_insn *, if non-NULL don't update just BB_END (current_block), but
also call set_block_for_insn on the newly added insns and rescan.

* g++.dg/ext/pr84828.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/pr84828.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/reg-stack.c
trunk/gcc/testsuite/ChangeLog

[Bug target/84827] [7/8 Regression] ICE in extract_insn, at recog.c:2311

2018-03-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84827

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Mar 13 08:05:58 2018
New Revision: 258477

URL: https://gcc.gnu.org/viewcvs?rev=258477&root=gcc&view=rev
Log:
PR target/84827
* config/i386/i386.md (round2): For 387 fancy math, disable
pattern if -ftrapping-math -fno-fp-int-builtin-inexact.

* gcc.target/i386/pr84827.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr84827.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog

[Bug target/84786] [miscompilation] vunpcklpd accessing xmm16-22 targeting KNL

2018-03-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84786

--- Comment #7 from Jakub Jelinek  ---
Fixed for 8.1+ so far.

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

2018-03-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84827

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[7/8 Regression] ICE in |[7 Regression] ICE in
   |extract_insn, at|extract_insn, at
   |recog.c:2311|recog.c:2311

--- Comment #4 from Jakub Jelinek  ---
Fixed for 8.1+ so far.

[Bug target/84828] ICE in verify_flow_info at gcc/cfghooks.c:265

2018-03-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84828

--- Comment #3 from Jakub Jelinek  ---
Fixed for 8.1+ so far.

[Bug middle-end/84831] Invalid memory read in parse_output_constraint

2018-03-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84831

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Tue Mar 13 08:12:07 2018
New Revision: 258478

URL: https://gcc.gnu.org/viewcvs?rev=258478&root=gcc&view=rev
Log:
PR middle-end/84831
* stmt.c (parse_output_constraint): If the CONSTRAINT_LEN (*p, p)
characters starting at p contain '\0' character, don't look beyond
that.

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

[Bug middle-end/84831] Invalid memory read in parse_output_constraint

2018-03-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84831

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Fixed.

[Bug middle-end/84834] [7/8 Regression] ICE: tree check: expected integer_cst, have complex_cst in to_wide, at tree.h:5527

2018-03-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84834

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Tue Mar 13 08:12:59 2018
New Revision: 258479

URL: https://gcc.gnu.org/viewcvs?rev=258479&root=gcc&view=rev
Log:
PR middle-end/84834
* match.pd ((A & C) != 0 ? D : 0): Use INTEGER_CST@2 instead of
integer_pow2p@2 and test integer_pow2p in condition.
(A < 0 ? C : 0): Similarly for @1.

* gcc.dg/pr84834.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr84834.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/84834] [7 Regression] ICE: tree check: expected integer_cst, have complex_cst in to_wide, at tree.h:5527

2018-03-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84834

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[7/8 Regression] ICE: tree  |[7 Regression] ICE: tree
   |check: expected |check: expected
   |integer_cst, have   |integer_cst, have
   |complex_cst in to_wide, at  |complex_cst in to_wide, at
   |tree.h:5527 |tree.h:5527

--- Comment #7 from Jakub Jelinek  ---
Fixed for 8.1+ so far.

[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4

2018-03-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906

--- Comment #16 from Jakub Jelinek  ---
So just add a gdb >= 8.1 version test in
libstdc++-v3/testsuite/lib/gdb-test.exp
and guard this test on effective target gdb_8_1?

[Bug ipa/84658] [7/8 Regression] -O3 -fmerge-all-constants causes incorrect for-each loop generation.

2018-03-13 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84658

--- Comment #24 from Martin Liška  ---
Author: marxin
Date: Tue Mar 13 08:20:27 2018
New Revision: 258480

URL: https://gcc.gnu.org/viewcvs?rev=258480&root=gcc&view=rev
Log:
Fix PTA info in IPA ICF (PR ipa/84658).

2018-03-13  Martin Liska  

PR ipa/84658.
* (sem_item_optimizer::sem_item_optimizer): Initialize new
vector.
(sem_item_optimizer::~sem_item_optimizer): Release it.
(sem_item_optimizer::merge_classes): Register variable aliases.
(sem_item_optimizer::fixup_pt_set): New function.
(sem_item_optimizer::fixup_points_to_sets): Likewise.
* ipa-icf.h: Declare new variables and functions.
2018-03-13  Martin Liska  

PR ipa/84658.
* g++.dg/ipa/pr84658.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ipa/pr84658.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-icf.c
trunk/gcc/ipa-icf.h
trunk/gcc/testsuite/ChangeLog

[Bug ipa/84658] [7/8 Regression] -O3 -fmerge-all-constants causes incorrect for-each loop generation.

2018-03-13 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84658

Martin Liška  changed:

   What|Removed |Added

  Known to work||8.0
  Known to fail|8.0 |

--- Comment #25 from Martin Liška  ---
Fixed on trunk so far.

[Bug go/84215] Random results in go/libgo tests

2018-03-13 Thread clyon at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84215

--- Comment #10 from Christophe Lyon  ---
Yesterday I noticed:
* on arm:
FAIL: libgo:database/sql
* on aarch64:
FAIL: libgo:runtime/pprof

[Bug tree-optimization/84841] New: [8 Regression] ICE: tree check: expected ssa_name, have real_cst in rewrite_expr_tree_parallel, at tree-ssa-reassoc.c:4624

2018-03-13 Thread asolokha at gmx dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84841

Bug ID: 84841
   Summary: [8 Regression] ICE: tree check: expected ssa_name,
have real_cst in rewrite_expr_tree_parallel, at
tree-ssa-reassoc.c:4624
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-8.0.0-alpha20180311 snapshot (r258438) ICEs when compiling the following
snippet w/ -O1 (-O2, -O3, -Ofast, -Os) -fassociative-math -frounding-math
-fno-signed-zeros -fno-trapping-math -fno-tree-forwprop:

double
ko (double ov)
{
  return -ov * 0.1 * 0.1;
}

% gcc-8.0.0-alpha20180311 -O1 -fassociative-math -frounding-math
-fno-signed-zeros -fno-trapping-math -fno-tree-forwprop -c ocd0zbx6.c
during GIMPLE pass: reassoc
ocd0zbx6.c: In function 'ko':
ocd0zbx6.c:2:1: internal compiler error: tree check: expected ssa_name, have
real_cst in rewrite_expr_tree_parallel, at tree-ssa-reassoc.c:4624
 ko (double ov)
 ^~
0x6c0245 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/tree.c:9335
0x69e70c tree_check(tree_node*, char const*, int, char const*, tree_code)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/tree.h:3132
0x69e70c rewrite_expr_tree_parallel
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/tree-ssa-reassoc.c:4624
0xe494c1 reassociate_bb
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/tree-ssa-reassoc.c:5923
0xe489e7 reassociate_bb
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/tree-ssa-reassoc.c:5983
0xe4b315 do_reassoc
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/tree-ssa-reassoc.c:6095
0xe4b315 execute_reassoc
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/tree-ssa-reassoc.c:6182
0xe4b315 execute
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/tree-ssa-reassoc.c:6221

[Bug rtl-optimization/84842] New: ICE in verify_target_availability, at sel-sched.c:1569

2018-03-13 Thread asolokha at gmx dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84842

Bug ID: 84842
   Summary: ICE in verify_target_availability, at sel-sched.c:1569
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-*-linux-gnu*

gcc-8.0.0-alpha20180311 snapshot (r258438) ICEs when compiling the following
snippet w/ -mcpu=power8 -O1 -frename-registers -fschedule-insns2
-fselective-scheduling2 -ftrapv:

int ad;
double cm;

void
tn (int on, int zt, int rc)
{
  if (cm != 0.0)
{
  while ((on + cm * ad * 2 / zt) < 1)
zt = -rc;

  ad = cm / 2 + rc;
  ad = -on - ad;
}
}

% powerpc-e300c3-linux-gnu-gcc-8.0.0-alpha20180311 -mcpu=power8 -O1
-frename-registers -fschedule-insns2 -fselective-scheduling2 -ftrapv -c
vvk0ahws.c
during RTL pass: sched2
vvk0ahws.c: In function 'tn':
vvk0ahws.c:15:1: internal compiler error: in verify_target_availability, at
sel-sched.c:1569
 }
 ^
0xc13856 verify_target_availability
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/sel-sched.c:1566
0xc13856 find_best_reg_for_expr
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/sel-sched.c:1679
0xc13856 fill_vec_av_set
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/sel-sched.c:3797
0xc13fd0 fill_ready_list
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/sel-sched.c:4027
0xc13fd0 find_best_expr
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/sel-sched.c:4387
0xc13fd0 fill_insns
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/sel-sched.c:5544
0xc163ee schedule_on_fences
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/sel-sched.c:7361
0xc163ee sel_sched_region_2
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/sel-sched.c:7499
0xc18bf1 sel_sched_region_1
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/sel-sched.c:7541
0xc18bf1 sel_sched_region(int)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/sel-sched.c:7642
0xc192c1 run_selective_scheduling()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/sel-sched.c:7718
0xbf012d rest_of_handle_sched2
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/sched-rgn.c:3729
0xbf012d execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/sched-rgn.c:3873

[Bug tree-optimization/84841] [8 Regression] ICE: tree check: expected ssa_name, have real_cst in rewrite_expr_tree_parallel, at tree-ssa-reassoc.c:4624

2018-03-13 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84841

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-13
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug tree-optimization/84841] [8 Regression] ICE: tree check: expected ssa_name, have real_cst in rewrite_expr_tree_parallel, at tree-ssa-reassoc.c:4624

2018-03-13 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84841

--- Comment #2 from Marek Polacek  ---
Started with r236564.

[Bug c++/84843] New: [8 Regression] C++ ICE on builtin redefinition since r258391

2018-03-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84843

Bug ID: 84843
   Summary: [8 Regression] C++ ICE on builtin redefinition since
r258391
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

extern "C" int __atomic_compare_exchange (int x, int y) { return x + y; }
ICEs starting with the above revision in:
0x8fc5c2 start_preparsed_function(tree_node*, tree_node*, int)
../../gcc/cp/decl.c:15060
0x8fe24c start_function(cp_decl_specifier_seq*, cp_declarator const*,
tree_node*)
../../gcc/cp/decl.c:15287
0x9e01b3 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.c:26700
0x9d1e88 cp_parser_init_declarator
../../gcc/cp/parser.c:19502
0x9c5be7 cp_parser_simple_declaration
../../gcc/cp/parser.c:13057
0x9c5750 cp_parser_block_declaration
../../gcc/cp/parser.c:12882
0x9c54d2 cp_parser_declaration
../../gcc/cp/parser.c:12780

[Bug tree-optimization/84841] [7/8 Regression] ICE: tree check: expected ssa_name, have real_cst in rewrite_expr_tree_parallel, at tree-ssa-reassoc.c:4624

2018-03-13 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84841

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |7.4
Summary|[8 Regression] ICE: tree|[7/8 Regression] ICE: tree
   |check: expected ssa_name,   |check: expected ssa_name,
   |have real_cst in|have real_cst in
   |rewrite_expr_tree_parallel, |rewrite_expr_tree_parallel,
   |at tree-ssa-reassoc.c:4624  |at tree-ssa-reassoc.c:4624

[Bug tree-optimization/84841] [7/8 Regression] ICE: tree check: expected ssa_name, have real_cst in rewrite_expr_tree_parallel, at tree-ssa-reassoc.c:4624

2018-03-13 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84841

--- Comment #3 from Richard Biener  ---
At least latent on the GCC 7 branch and earlier.

  /* We start expression rewriting from the top statements.
 So, in this loop we create a full list of statements
 we will work with.  */
  stmts[stmt_num - 1] = stmt;
  for (i = stmt_num - 2; i >= 0; i--)
stmts[i] = SSA_NAME_DEF_STMT (gimple_assign_rhs1 (stmts[i+1]));

assumes there are no unfolded CST +* CST ops in the IL.

OTOH we shouldn't rewrite any exprs with -frounding-math anyway?

That is, -fassociative-math and -frounding-math are (again) seemingly in
conflict?

[Bug tree-optimization/84841] [7/8 Regression] ICE: tree check: expected ssa_name, have real_cst in rewrite_expr_tree_parallel, at tree-ssa-reassoc.c:4624

2018-03-13 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84841

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/84843] [8 Regression] C++ ICE on builtin redefinition since r258391

2018-03-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84843

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code
   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-13
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
This is because of the return olddecl; for the builtins.

[Bug tree-optimization/84830] [8 Regression] ICE in compute_antic, at tree-ssa-pre.c:2388

2018-03-13 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84830

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Mine.

[Bug c++/84843] [8 Regression] C++ ICE on builtin redefinition since r258391

2018-03-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84843

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
The ICE is because of assertion that DECL_INITIAL is non-NULL; when
duplicate_decls is called, olddecl is the builtin from builtins.def with NULL
DECL_INITIAL, and newdecl is the user definition with error_mark_node as
DECL_INITIAL.  If the pedwarn errors, I guess we could return error_mark_node
instead of olddecl and the error-recovery would work fine, but for -fpermissive
I have no idea what to do, except for returning NULL_TREE, but that is
something you didn't like.

[Bug c++/84843] [8 Regression] C++ ICE on builtin redefinition since r258391

2018-03-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84843

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P4  |P1

--- Comment #3 from Jakub Jelinek  ---
Actually P1, with -fpermissive this isn't error-recovery.

[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4

2018-03-13 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906

--- Comment #17 from Jonathan Wakely  ---
Ideally I want the printer to still work for users with older versions of gdb.

[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4

2018-03-13 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906

--- Comment #18 from Jonathan Wakely  ---
But we can remove the [8 Regression] marker if it's messing with reports.

[Bug target/84521] aarch64: Frame-pointer corruption with __builtin_setjmp/__builtin_longjmp and -fomit-frame-pointer

2018-03-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84521

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P1  |P3
Summary|[8 Regression] aarch64: |aarch64: Frame-pointer
   |Frame-pointer corruption|corruption with
   |with|__builtin_setjmp/__builtin_
   |__builtin_setjmp/__builtin_ |longjmp and
   |longjmp and |-fomit-frame-pointer
   |-fomit-frame-pointer|

--- Comment #24 from Jakub Jelinek  ---
With the change of the default this actually isn't a regression anymore, so not
a release blocker.  That doesn't mean a simple fix, e.g. __builtin_setjmp
forcing frame pointer even if not otherwise needed, can't be accepted for GCC8
(as an exception), but it is unlikely right time for finding all issues with
the builtin and trying to fix all of them.  That can be done in GCC9.

[Bug c++/84843] [8 Regression] C++ ICE on builtin redefinition since r258391

2018-03-13 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84843

--- Comment #4 from Richard Biener  ---
I think if we have a definition we need to use newdecl ...

Now consider

extern "C" int __atomic_compare_exchange (int x, int y);

void bar() { __atomic_compare_exchange (1, 2); }

extern "C" int __atomic_compare_exchange (int x, int y)
{
  return x + y;
}

with -fpermissive and things get even more complicated.

> ./cc1plus -quiet t.ii  -fpermissive
t.ii:1:16: warning: new declaration ‘int __atomic_compare_exchange(int, int)’
ambiguates built-in declaration ‘bool __atomic_compare_exchange(long unsigned
int, volatile void*, void*, void*, int, int)’ [-fpermissive]
 extern "C" int __atomic_compare_exchange (int x, int y);
^
t.ii:1:16: note: ignoring the ‘int __atomic_compare_exchange(int, int)’
declaration
t.ii: In function ‘void bar()’:
t.ii:3:45: error: incorrect number of arguments to function
‘__atomic_compare_exchange’
 void bar() { __atomic_compare_exchange (1, 2); }
 ^
t.ii: At global scope:
t.ii:5:16: warning: new declaration ‘int __atomic_compare_exchange(int, int)’
ambiguates built-in declaration ‘bool __atomic_compare_exchange(long unsigned
int, volatile void*, void*, void*, int, int)’ [-fpermissive]
 extern "C" int __atomic_compare_exchange (int x, int y)
^
t.ii:5:16: note: ignoring the ‘int __atomic_compare_exchange(int, int)’
declaration
t.ii: In function ‘bool __atomic_compare_exchange(long unsigned int, volatile
void*, void*, void*, int, int)’:
t.ii:5:55: internal compiler error: in start_preparsed_function, at
cp/decl.c:15060
 extern "C" int __atomic_compare_exchange (int x, int y)
   ^
0x93685e start_preparsed_function(tree_node*, tree_node*, int)
...

[Bug libstdc++/83906] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4

2018-03-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8 Regression] Random FAIL: |Random FAIL:
   |libstdc++-prettyprinters/80 |libstdc++-prettyprinters/80
   |276.cc whatis p4|276.cc whatis p4

--- Comment #19 from Jakub Jelinek  ---
Ok, let's do it.

[Bug c++/84843] [8 Regression] C++ ICE on builtin redefinition since r258391

2018-03-13 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84843

--- Comment #5 from Richard Biener  ---
So, do we want to return newdecl unconditionally and scrap the olddecl
(builtin)
binding somehow?  For -fpermissive, of course?

[Bug ipa/84833] [8 Regression] target_clones regression since r251047

2018-03-13 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84833

--- Comment #3 from Martin Liška  ---
> Another (though preexisting) bug is lack of optimization, if we have a call
> or reference of a target_clones dispatcher in a function with the same
> target_clones attribute (or maybe even just target attribute or similar), we
> should optimize it at compile time into a reference to a particular target
> clone.
> 

Yes, I know about it and I'm planning to do it in next stage1. It's reported
here:
PR83411.

[Bug ipa/84833] [8 Regression] target_clones regression since r251047

2018-03-13 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84833

--- Comment #4 from Martin Liška  ---
I can confirm the issue, there's missing edge to foo->baz and thus the symbol
is removed. I'll fix that.

[Bug ipa/84833] [8 Regression] target_clones regression since r251047

2018-03-13 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84833

--- Comment #5 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #2)
> Just a note, as can be seen e.g. on
> static volatile int a;
> static int my_foo1 (void) { return 1; }
> static int my_foo2 (void) { return 2; }
> typedef int (*F) (void);
> static F resolve_foo (void) { if (a) return my_foo1; else return my_foo2; }
> static int foo (void) __attribute__ ((ifunc ("resolve_foo")));
> 
> int
> main ()
> {
>   if (foo () != 2)
> __builtin_abort ();
> }
> there is no reason why any of the target clones, resolver or the ifunc
> function should be .globl, they can all be local to the TU, IFUNC work just
> fine that way too.  So, if the function with target_clones attribute is not
> TREE_PUBLIC, neither should be any of the multiple_targets.c created symbols.

If I see correctly, we do not make these global:

nm pr84833-2.o 
 b a
 U abort
000c i foo
0022 T main
 t my_foo1
0006 t my_foo2
000c t resolve_foo

Note that it was subject of PR81213.

[Bug c++/84676] [6/7/8 Regression] internal compiler error: Segmentation fault (build_new_op_1)

2018-03-13 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84676

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c++/84843] [8 Regression] C++ ICE on builtin redefinition since r258391

2018-03-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84843

--- Comment #6 from Jakub Jelinek  ---
return newdecl is something we never do, we either return error_mark_node (an
error), or NULL_TREE (the olddecl and newdecl are different thing) or olddecl
(after merging the two decls).
One way out of this would be to change the permerror into just error and return
error_mark_node, or at least do that if DECL_INITIAL (newdecl) is non-NULL,
i.e. under -fpermissive allow and ignore redeclarations for builtins, but
always reject redefinitions.

[Bug c/82186] [7 Regression] ICE (segfault), VLA type with inlining

2018-03-13 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82186

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Assignee|mpolacek at gcc dot gnu.org|unassigned at gcc dot 
gnu.org
Summary|[7/8 Regression] ICE|[7 Regression] ICE
   |(segfault), VLA type with   |(segfault), VLA type with
   |inlining|inlining

--- Comment #8 from Marek Polacek  ---
Fixed on trunk by r257620.  Unsure about backporting...

[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV

2018-03-13 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #62 from Richard Biener  ---
Waiting for Solaris engineer input...  (or a machine to be able to debug this
directly - is there one on the CF?).

[Bug rtl-optimization/84844] New: [8 Regression] ICE in extract_constrain_insn_cached, at recog.c:2217 (error: insn does not satisfy its constraints)

2018-03-13 Thread asolokha at gmx dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84844

Bug ID: 84844
   Summary: [8 Regression] ICE in extract_constrain_insn_cached,
at recog.c:2217 (error: insn does not satisfy its
constraints)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-pc-linux-gnu-gcc

gcc-8.0.0-alpha20180311 snapshot (r258438) ICEs when compiling the following
snippet w/ -march=bdver1 (=bdver2) -O1 (-O2, -O3, -Ofast, -Og, -Os)
-fschedule-insns -fselective-scheduling:

double
vl (int *hm, int ue, int jy)
{
  *hm = ue;
  return jy;
}

% x86_64-pc-linux-gnu-gcc-8.0.0-alpha20180311 -march=bdver1 -O1
-fschedule-insns -fselective-scheduling -c iy3oz1yv.c
iy3oz1yv.c: In function 'vl':
iy3oz1yv.c:6:1: error: insn does not satisfy its constraints:
 }
 ^
(insn 19 0 0 (set (reg:DF 91)
(float:DF (reg:SI 1 dx [ jy ]))) 205 {*floatsidf2_mixed}
 (expr_list:REG_DEAD (reg/v:SI 90 [ jy ])
(nil)))
during RTL pass: sched1
iy3oz1yv.c:6:1: internal compiler error: in extract_constrain_insn_cached, at
recog.c:2217
0x64a621 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/rtl-error.c:108
0x64a647 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/rtl-error.c:118
0x648bc4 extract_constrain_insn_cached(rtx_insn*)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/recog.c:2217
0x118653d get_attr_type(rtx_insn*)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/config/i386/i386.md:2241
0x11b6f86 internal_dfa_insn_code_bdver1(rtx_insn*)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/config/i386/i386.md:15271
0x11a29a8 dfa_insn_code
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/build/gcc/insn-automata.c:150079
0x11a29a8 state_transition(void*, rtx_def*)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/build/gcc/insn-automata.c:150094
0xc5f1fd estimate_insn_cost
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/sel-sched.c:4291
0xc6b0ab get_expr_cost
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/sel-sched.c:4322
0xc6b0ab choose_best_insn
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/sel-sched.c:4351
0xc6b0ab find_best_expr
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/sel-sched.c:4401
0xc6b0ab fill_insns
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/sel-sched.c:5544
0xc6b0ab schedule_on_fences
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/sel-sched.c:7361
0xc6b0ab sel_sched_region_2
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/sel-sched.c:7499
0xc6d227 sel_sched_region_1
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/sel-sched.c:7541
0xc6d227 sel_sched_region(int)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/sel-sched.c:7642
0xc6e288 run_selective_scheduling()
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/sel-sched.c:7718
0xc4ddfd rest_of_handle_sched
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/sched-rgn.c:3715
0xc4ddfd execute
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/sched-rgn.c:3825

[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV

2018-03-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968

--- Comment #63 from Jakub Jelinek  ---
Are the remaining issues only related to .debug_macro, or other stuff too?
If only .debug_macro, does:
--- gcc/dwarf2out.c 2018-03-11 17:48:53.498068316 +0100
+++ gcc/dwarf2out.c 2018-03-13 10:58:03.477514623 +0100
@@ -28282,6 +28282,7 @@ output_macinfo (const char *debug_line_l
case DW_MACINFO_undef:
  if ((!dwarf_strict || dwarf_version >= 5)
  && HAVE_COMDAT_GROUP
+ && !flag_lto
  && vec_safe_length (files) != 1
  && i > 0
  && i + 1 < length
help?  If yes, we could go for && (!flag_lto || !HAVE_BROKEN_LD_WHATEVER)
and add configure test for that.

[Bug lto/84805] [8 Regression] ICE in get_odr_type, at ipa-devirt.c:2096 since r258133

2018-03-13 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84805

--- Comment #7 from Eric Botcazou  ---
Author: ebotcazou
Date: Tue Mar 13 10:04:51 2018
New Revision: 258481

URL: https://gcc.gnu.org/viewcvs?rev=258481&root=gcc&view=rev
Log:
PR lto/84805
* ipa-devirt.c (odr_subtypes_equivalent_p): Do not get the ODR type of
incomplete types.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-devirt.c

[Bug lto/84805] [8 Regression] ICE in get_odr_type, at ipa-devirt.c:2096 since r258133

2018-03-13 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84805

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #8 from Eric Botcazou  ---
Thanks for the reduced testcase.

[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV

2018-03-13 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968

--- Comment #64 from Eric Botcazou  ---
> Are the remaining issues only related to .debug_macro, or other stuff too?

The LTO testsuite is clean on SPARC/Solaris 10 for me (GNU as + Solaris ld) but
Rainer's testing exercises more combinations, in particular x86.

[Bug libstdc++/71660] [6/7/8 regression] alignment of std::atomic<8 byte primitive type> (long long, double) is wrong on x86

2018-03-13 Thread peter at cordes dot ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71660

--- Comment #17 from Peter Cordes  ---
(In reply to Jonathan Wakely from comment #16)
> But what we do care about is comment 2, i.e. _Atomic(T) and std::atomic
> should have the same alignment (both in an out of structs). Maybe that needs
> the C front-end to change how _Atomic works, or maybe it needs the C++
> library to change how std::atomic works, but I want to keep this bug open
> while comment 2 gives different answers for C and C++.

Right, gcc's C _Atomic ABI is still broken for long long on 32-bit x86.  It
only aligned _Atomic long long to 32 bits (inside structs), but then assumes
that 8-byte loads / stores (with x87 or SSE1/2) are atomic.

It also leads to abysmal performance for  LOCK CMPXCHG  or other RMW operations
if the atomic object is split across a cache line.

That's bug 65146, so we can close this one.  (I never got around to posting in
the google group for the ABI.  By far the best good solution is giving _Atomic
long long (and other 8-byte objects) a boost to their _Alignof, up to 8 byte
alignment even inside structs.)

[Bug target/84844] [8 Regression] ICE in extract_constrain_insn_cached, at recog.c:2217 (error: insn does not satisfy its constraints)

2018-03-13 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84844

Richard Biener  changed:

   What|Removed |Added

  Component|rtl-optimization|target
   Target Milestone|--- |8.0

[Bug middle-end/80283] [6/7/8 Regression] bad SIMD register allocation

2018-03-13 Thread rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80283

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #20 from rsandifo at gcc dot gnu.org  
---
(In reply to Wilco from comment #12)
> There are 2 separate issues in the ARMv7 case. One is scheduling, the -S
> output goes down from 437 lines to 305 lines with -fno-schedule-insns (stack
> size 276 rather than 448 bytes). So basically the "register pressure aware"
> scheduler introduces lots of unnecessary spills.

This is kind-of expected in general, though almost certainly wrong in this
case.  The default "weighted" algorithm tended to overemphasise decreasing
spills (at the cost of decreasing ILP) and slowed down some important
benchmarks for which some spilling was better.  The "model" algorithm was
supposed to be a compromise.

I'll have a look to see whether there's an easy way of handling this case
better without regressing others.  (I'm not assigning myself since it's
unrelated to the x86 problem.)

> The 2nd issue is related to use of single-element operations within vectors.
> If I change the define to do an explicit dup, eg. vmulq_f32((b),
> vdupq_n_f32(a)), I get 211 lines and no spills at all. Switching scheduling
> on again gives 326 lines so it's spilling like crazy.

Yeah, the way arm_neon.h handles vmulq_n_f32 seems to leave lots of
uninitialised pseudo registers, which means that the VFP registers appear to
start the loop almost 2-times oversubscribed.  Do you know if we have a
separate PR for that?

[Bug target/84844] [8 Regression] ICE in extract_constrain_insn_cached, at recog.c:2217 (error: insn does not satisfy its constraints)

2018-03-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84844

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-13
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r247036.

[Bug target/84844] [8 Regression] ICE in extract_constrain_insn_cached, at recog.c:2217 (error: insn does not satisfy its constraints)

2018-03-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84844

--- Comment #2 from Jakub Jelinek  ---
The problem is that if a constraint returns NO_REGS before RA (i.e. in
non-strict mode) then that alternative is ignored, and e.g. get_attr_type used
by sched1 needs to compute alternative.  As the instruction uses
nonimmediate_operand and the only alternative with "r" input has "Yc" output
which is NO_REGS for this -march=, if the operand is a register, there is no
alternative left.

The following patch fixes this for me:
--- gcc/config/i386/i386.md.jj  2018-03-13 09:05:22.480987994 +0100
+++ gcc/config/i386/i386.md 2018-03-13 12:44:21.372058947 +0100
@@ -5325,16 +5325,17 @@
 })

 (define_insn "*float2_mixed"
-  [(set (match_operand:MODEF 0 "register_operand" "=f,Yc,v")
+  [(set (match_operand:MODEF 0 "register_operand" "=f,Yc,v,!???v")
(float:MODEF
- (match_operand:SWI48 1 "nonimmediate_operand" "m,r,m")))]
+ (match_operand:SWI48 1 "nonimmediate_operand" "m,r,m,r")))]
   "SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH"
   "@
fild%Z1\t%1
%vcvtsi2\t{%1, %d0|%d0, %1}
+   %vcvtsi2\t{%1, %d0|%d0, %1}
%vcvtsi2\t{%1, %d0|%d0, %1}"
-  [(set_attr "type" "fmov,sseicvt,sseicvt")
-   (set_attr "prefix" "orig,maybe_vex,maybe_vex")
+  [(set_attr "type" "fmov,sseicvt,sseicvt,sseicvt")
+   (set_attr "prefix" "orig,maybe_vex,maybe_vex,maybe_vex")
(set_attr "mode" "")
(set (attr "prefix_rex")
  (if_then_else
@@ -5342,11 +5343,11 @@
(match_test "mode == DImode"))
(const_string "1")
(const_string "*")))
-   (set_attr "unit" "i387,*,*")
-   (set_attr "athlon_decode" "*,double,direct")
-   (set_attr "amdfam10_decode" "*,vector,double")
-   (set_attr "bdver1_decode" "*,double,direct")
-   (set_attr "znver1_decode" "double,*,*")
+   (set_attr "unit" "i387,*,*,*")
+   (set_attr "athlon_decode" "*,double,direct,double")
+   (set_attr "amdfam10_decode" "*,vector,double,vector")
+   (set_attr "bdver1_decode" "*,double,direct,double")
+   (set_attr "znver1_decode" "double,*,*,*")
(set_attr "fp_int_src" "true")
(set (attr "enabled")
  (cond [(eq_attr "alternative" "0")

The CPU does support this insn, just it is very undesirable for tuning.
So, the !??? should tell reload to try very hard not to use that alternative.

[Bug target/84844] [8 Regression] ICE in extract_constrain_insn_cached, at recog.c:2217 (error: insn does not satisfy its constraints)

2018-03-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84844

Jakub Jelinek  changed:

   What|Removed |Added

 CC||uros at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Or shall I got for ?*v instead, or ???*v, or !???*v ?

[Bug target/59833] ARM soft-float extendsfdf2 fails to quiet signaling NaN

2018-03-13 Thread ramana at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59833

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #17 from Ramana Radhakrishnan  ---
Fixed for GCC-7

[Bug target/65146] alignment of _Atomic structure member is not correct

2018-03-13 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65146

Jonathan Wakely  changed:

   What|Removed |Added

 Target||i386-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-13
 Ever confirmed|0   |1

[Bug c++/58407] [C++11] Should warn about deprecated implicit generation of copy constructor/assignment

2018-03-13 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58407

--- Comment #13 from Jonathan Wakely  ---
Thanks! I can take care of the rest of the library, but for now this makes all
the deque tests pass:


--- a/libstdc++-v3/include/bits/stl_deque.h
+++ b/libstdc++-v3/include/bits/stl_deque.h
@@ -149,9 +149,23 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   _Deque_iterator() _GLIBCXX_NOEXCEPT
   : _M_cur(), _M_first(), _M_last(), _M_node() { }

+#if __cplusplus < 201103L
+  // Conversion from iterator to const_iterator.
   _Deque_iterator(const iterator& __x) _GLIBCXX_NOEXCEPT
   : _M_cur(__x._M_cur), _M_first(__x._M_first),
_M_last(__x._M_last), _M_node(__x._M_node) { }
+#else
+  // Conversion from iterator to const_iterator.
+  template,
+  is_same<_Iter, iterator>>>
+   _Deque_iterator(const _Iter& __x) noexcept
+   : _M_cur(__x._M_cur), _M_first(__x._M_first),
+ _M_last(__x._M_last), _M_node(__x._M_node) { }
+
+  _Deque_iterator(const _Deque_iterator&) = default;
+  _Deque_iterator& operator=(const _Deque_iterator&) = default;
+#endif

   iterator
   _M_const_cast() const _GLIBCXX_NOEXCEPT
diff --git a/libstdc++-v3/include/ext/throw_allocator.h
b/libstdc++-v3/include/ext/throw_allocator.h
index 5d9caa2bcae..f773a2d79ba 100644
--- a/libstdc++-v3/include/ext/throw_allocator.h
+++ b/libstdc++-v3/include/ext/throw_allocator.h
@@ -403,6 +403,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   struct condition_base
   {
 virtual ~condition_base() { };
+#if __cplusplus >= 201103L
+condition_base() = default;
+condition_base(const condition_base&) = default;
+condition_base& operator=(const condition_base&) = default;
+#endif
   };

[Bug target/84845] New: [8 Regression] ICE: in extract_insn, at recog.c:2304: unrecognizable insn at -O2 and above at aarch64

2018-03-13 Thread zsojka at seznam dot cz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84845

Bug ID: 84845
   Summary: [8 Regression] ICE: in extract_insn, at recog.c:2304:
unrecognizable insn at -O2 and above at aarch64
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: aarch64-unknown-linux-gnu

Created attachment 43640
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43640&action=edit
reduced testcase

Compiler output:
$ aarch64-unknown-linux-gnu-gcc -O2 testcase.c
testcase.c: In function 'foo':
testcase.c:9:1: error: unrecognizable insn:
 }
 ^
(insn 30 29 26 2 (set (reg:DI 114)
(rotatert:DI (reg:DI 115 [ d ])
(subreg:QI (and:SI (reg:SI 118)
(const_int 65535 [0x])) 0))) "testcase.c":8 -1
 (expr_list:REG_DEAD (reg:SI 118)
(expr_list:REG_DEAD (reg:DI 115 [ d ])
(nil
during RTL pass: sched1
testcase.c:9:1: internal compiler error: in extract_insn, at recog.c:2304
0x5b87a4 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.c:108
0x5b8828 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.c:116
0xbbd41c extract_insn(rtx_insn*)
/repo/gcc-trunk/gcc/recog.c:2304
0xa68ad7 scan_one_insn
/repo/gcc-trunk/gcc/ira-costs.c:1449
0xa68ad7 process_bb_for_costs
/repo/gcc-trunk/gcc/ira-costs.c:1613
0xa696c4 find_costs_and_classes
/repo/gcc-trunk/gcc/ira-costs.c:1720
0xa6abaa ira_set_pseudo_classes(bool, _IO_FILE*)
/repo/gcc-trunk/gcc/ira-costs.c:2267
0x1487e00 alloc_global_sched_pressure_data
/repo/gcc-trunk/gcc/haifa-sched.c:7157
0x1487e00 sched_init()
/repo/gcc-trunk/gcc/haifa-sched.c:7314
0x148978d haifa_sched_init()
/repo/gcc-trunk/gcc/haifa-sched.c:7326
0xc220b9 schedule_insns()
/repo/gcc-trunk/gcc/sched-rgn.c:3504
0xc22973 schedule_insns()
/repo/gcc-trunk/gcc/sched-rgn.c:3498
0xc22973 rest_of_handle_sched
/repo/gcc-trunk/gcc/sched-rgn.c:3717
0xc22973 execute
/repo/gcc-trunk/gcc/sched-rgn.c:3825
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


$ aarch64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-258459-checking-yes-rtl-df-extra-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/8.0.1/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl
--with-sysroot=/usr/aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu
--with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld
--with-as=/usr/bin/aarch64-unknown-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-258459-checking-yes-rtl-df-extra-aarch64
Thread model: posix
gcc version 8.0.1 20180312 (experimental) (GCC)

[Bug target/84845] [8 Regression] ICE: in extract_insn, at recog.c:2304: unrecognizable insn at -O2 and above at aarch64

2018-03-13 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84845

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug gcov-profile/84846] New: GCOV intermediate format improvements

2018-03-13 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84846

Bug ID: 84846
   Summary: GCOV intermediate format improvements
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

This comes from:
https://github.com/linux-test-project/lcov/issues/38#issuecomment-371203750

All ideas make sense, so I will implement that in next stage1.

[Bug gcov-profile/84846] GCOV intermediate format improvements

2018-03-13 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84846

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-03-13
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

[Bug target/84844] [8 Regression] ICE in extract_constrain_insn_cached, at recog.c:2217 (error: insn does not satisfy its constraints)

2018-03-13 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84844

--- Comment #4 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #3)
> Or shall I got for ?*v instead, or ???*v, or !???*v ?

Or we can revert PR78090 fix and use preferred_for_speed attribute again. This
will allow the compiler to emit reg->xmm for cold parts.

BTW: we shouldn't just grep assembly dumps for unoptimal insns, as was done and
reported in PR78090. There is no harm to emit reg->xmm form of the insn in the
cold parts.

Based on this, I prefer the revert of PR78090 patch, perhaps with a run of
462.libquantum to assess the performance impact.

[Bug target/84844] [8 Regression] ICE in extract_constrain_insn_cached, at recog.c:2217 (error: insn does not satisfy its constraints)

2018-03-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84844

--- Comment #5 from Jakub Jelinek  ---
(In reply to Uroš Bizjak from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > Or shall I got for ?*v instead, or ???*v, or !???*v ?
> 
> Or we can revert PR78090 fix and use preferred_for_speed attribute again.
> This will allow the compiler to emit reg->xmm for cold parts.
> 
> BTW: we shouldn't just grep assembly dumps for unoptimal insns, as was done
> and reported in PR78090. There is no harm to emit reg->xmm form of the insn
> in the cold parts.
> 
> Based on this, I prefer the revert of PR78090 patch, perhaps with a run of
> 462.libquantum to assess the performance impact.

I can test the reversion, but don't have any setup for SPEC testing nor AMD HW,
so that would need to be done by somebody else.

[Bug target/78090] [x86_64]: GCC allows integer register for inter unit conversion under -mtune-ctrl=^inter_unit_conversions .

2018-03-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78090

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
This caused PR84844 regression.

[Bug go/84215] Random results in go/libgo tests

2018-03-13 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84215

--- Comment #11 from Ian Lance Taylor  ---
Please include all the output from each failure, if possible.  Thanks.

[Bug target/78090] [x86_64]: GCC allows integer register for inter unit conversion under -mtune-ctrl=^inter_unit_conversions .

2018-03-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78090

--- Comment #8 from Jakub Jelinek  ---
Even with this patch reverted, I can't reproduce the #c0 difference, neither in
7.3.1 nor on the trunk.  And even if we emit the direct inter-unit conversions
in cold sections, it is significantly smaller (4 vs. 10 bytes when going
through stack), so it is what we are looking for.

[Bug lto/84805] [8 Regression] ICE in get_odr_type, at ipa-devirt.c:2096 since r258133

2018-03-13 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84805

--- Comment #9 from Martin Liška  ---
(In reply to Eric Botcazou from comment #8)
> Thanks for the reduced testcase.

I thank you for the fast fix. I can confirm that libreoffice now builds fine.
Are you considering adding the reduced test-case to our test-suite?

[Bug tree-optimization/84737] [8 Regression] 20% degradation in CPU2000 172.mgrid starting with r256888

2018-03-13 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84737

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||jamborm at gcc dot gnu.org

--- Comment #6 from Martin Liška  ---
I see, the change is only in resid_.constprop.1 that is created after the
patch:

before:

Evaluating opportunities for resid/1.
 - considering value &x.u for param #0 u (caller_count: 3)
 good_cloning_opportunity_p (time: 1, size: 169, freq_sum: 38778) ->
evaluation: 229, threshold: 500
 good_cloning_opportunity_p (time: 1, size: 169, freq_sum: 38778) ->
evaluation: 229, threshold: 500
 - considering value &x.v for param #1 v (caller_count: 3)
 good_cloning_opportunity_p (time: 1, size: 169, freq_sum: 38778) ->
evaluation: 229, threshold: 500
 good_cloning_opportunity_p (time: 1, size: 169, freq_sum: 38778) ->
evaluation: 229, threshold: 500
 - considering value &x.r for param #2 r (caller_count: 3)
 good_cloning_opportunity_p (time: 1, size: 169, freq_sum: 38778) ->
evaluation: 229, threshold: 500
 good_cloning_opportunity_p (time: 2, size: 246, freq_sum: 38778) ->
evaluation: 315, threshold: 500
 - considering value &x.a for param #4 a (caller_count: 4)
 good_cloning_opportunity_p (time: 1, size: 169, freq_sum: 42518) ->
evaluation: 251, threshold: 500
 good_cloning_opportunity_p (time: 1, size: 169, freq_sum: 42518) ->
evaluation: 251, threshold: 500

after:

Evaluating opportunities for resid/1.
 - considering value &x.u for param #0 u (caller_count: 3)
 good_cloning_opportunity_p (time: 1, size: 169, freq_sum: 74554) ->
evaluation: 441, threshold: 500
 good_cloning_opportunity_p (time: 1, size: 169, freq_sum: 74554) ->
evaluation: 441, threshold: 500
 - considering value &x.v for param #1 v (caller_count: 3)
 good_cloning_opportunity_p (time: 1, size: 169, freq_sum: 74554) ->
evaluation: 441, threshold: 500
 good_cloning_opportunity_p (time: 1, size: 169, freq_sum: 74554) ->
evaluation: 441, threshold: 500
 - considering value &x.r for param #2 r (caller_count: 3)
 good_cloning_opportunity_p (time: 1, size: 169, freq_sum: 74554) ->
evaluation: 441, threshold: 500
 good_cloning_opportunity_p (time: 2, size: 246, freq_sum: 74554) ->
evaluation: 606, threshold: 500
  Creating a specialized node of resid/1.

Martin can you please take a look and evaluate how profitable is that
transformation? Maybe it can help you
with tuning of the param as in PR84149.

Thanks

[Bug libstdc++/84769] variant::get(): unscoped call to get

2018-03-13 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84769

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Fixed for 7.4 too.

[Bug libstdc++/84769] variant::get(): unscoped call to get

2018-03-13 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84769

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Tue Mar 13 13:24:36 2018
New Revision: 258482

URL: https://gcc.gnu.org/viewcvs?rev=258482&root=gcc&view=rev
Log:
PR libstdc++/84769 qualify std::get and std::get_if to avoid ADL

Backport from mainline
2018-03-09  Jonathan Wakely  

PR libstdc++/84769
* include/std/variant (get<_Tp, _Types...>, get_if<_Tp, _Types...>):
Qualify calls to get<_Np, Types...> and get_if<_Np, _Types...>.

Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/include/std/variant

[Bug target/84844] [8 Regression] ICE in extract_constrain_insn_cached, at recog.c:2217 (error: insn does not satisfy its constraints)

2018-03-13 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84844

--- Comment #6 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #2)
> The problem is that if a constraint returns NO_REGS before RA (i.e. in
> non-strict mode) then that alternative is ignored, and e.g. get_attr_type
> used by sched1 needs to compute alternative.  As the instruction uses
> nonimmediate_operand and the only alternative with "r" input has "Yc" output
> which is NO_REGS for this -march=, if the operand is a register, there is no
> alternative left.

OTOH, if the above is the problem - we have quite some constructs that declare
insn pattern with (match_operand "nonimmediate_operand" "m"), please see the
comment above floathi2. The comment also says that LRA will fix up this
during register allocation. Also, -fschedule-insns without
-fselective-scheduling is able to compile the testcase without errors, so it
looks that -fselective-scheduling should be made more robust.

[Bug c++/84798] [6/7/8 Regression] ICE (Segmentation fault) if `auto` appears in a template argument

2018-03-13 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84798

Jason Merrill  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |ice-on-invalid-code
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

[Bug target/84844] [8 Regression] ICE in extract_constrain_insn_cached, at recog.c:2217 (error: insn does not satisfy its constraints)

2018-03-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84844

--- Comment #7 from Jakub Jelinek  ---
I'm afraid I don't see what sel-sched could do.
It asks the DFA about cost estimate, and that ICEs.
And it ICEs because to determine the estimated cost it needs to estimate which
alternative is going to be used and for that it needs to compute get_attr_type,
which contains extract_constrain_insn_cached if there are multiple alternatives
with different types.

I assume
(match_operand "nonimmediate_operand" "m")
is not really a problem if there is just one alternative, or even if there are
multiple alternatives, but all of them have the same type attribute.  It is
just the case where type is different (or some other attribute that needs to be
queried before reload), which implies extract_constrain_insn_cached and that
ignores alternatives that have NO_REGS, or memory constraint on REG.  For most
constraints in !strict mode, it will win if reg_class_for_constraint (cn) !=
NO_REGS, or, if it is NO_REGS, if constraint_satisfied_p, or a couple of other
cases.

[Bug tree-optimization/84737] [8 Regression] 20% degradation in CPU2000 172.mgrid starting with r256888

2018-03-13 Thread jamborm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84737

--- Comment #7 from Martin Jambor  ---
Do I understand it correctly that you suspect that the new IPA-CP
clone that is created from r256888 on is harmful?  In that case, you
want to test that by trying higher values of ipa-cp-eval-threshold,
something like --param ipa-cp-eval-threshold 610 (i.e. bigger than
606).  Of course, if there are other clones with evaluations between
500 and 610, it would affect them too.

You may also want to try both fast and slow revisions with
-fno-ipa-cp-clone as the first step, actually.

[Bug c++/84843] [8 Regression] C++ ICE on builtin redefinition since r258391

2018-03-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84843

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Created attachment 43641
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43641&action=edit
gcc8-pr84843.patch

Untested fix.

[Bug lto/84847] New: [8 Regression] Incompatibility between early LTO debug and "-Wl,--gc-sections" leads to corrupt DWARF debuginfo

2018-03-13 Thread dmalcolm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84847

Bug ID: 84847
   Summary: [8 Regression] Incompatibility between early LTO debug
and "-Wl,--gc-sections" leads to corrupt DWARF
debuginfo
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
CC: marxin at gcc dot gnu.org, nickc at gcc dot gnu.org,
rguenth at gcc dot gnu.org
  Target Milestone: ---

The downstream bug report:
  https://bugzilla.redhat.com/show_bug.cgi?id=1543912
describes a problem building systemd and systemd-bootchart with gcc 8, which
turned out to be due to those packages' configure scripts injecting both
  -flto
and
  -Wl,--gc-sections

They build fine with just one of them, but with both, the binaries have corrupt
DWARF debuginfo.

Adding "-Wl,--print-gc-sections" shows the issue more clearly.

I created a minimal reproducer here:
  https://github.com/davidmalcolm/rhbz-1543912
with which I can reproduce the issue, using:
  gcc-8.0.1-0.16.fc29.x86_64
  binutils-2.30-6.fc29.x86_64
(this is on Fedora in a chroot via "mock -r fedora-rawhide-x86_64 shell"; I'm
still working on reproducing this outside a chroot)

$ make
gcc -I ./src -flto -O2 -g -c src/bootchart.c -o build/bootchart.o
gcc -I ./src -flto -O2 -g -c src/log.c -o build/log.o
gcc -flto -g -Wl,--gc-sections -Wl,--print-gc-sections \
  build/bootchart.o build/log.o \
  -o build/systemd-bootchart
/usr/bin/ld: Removing unused section '.rodata.cst4' in file
'/usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64/crt1.o'
/usr/bin/ld: Removing unused section '.data' in file
'/usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64/crt1.o'
/usr/bin/ld: Removing unused section '.rodata' in file
'/usr/lib/gcc/x86_64-redhat-linux/8/crtbegin.o'
/usr/bin/ld: Removing unused section '.debug_abbrev' in file
'/tmp/cc1vnNPxdebugobj'
/usr/bin/ld: Removing unused section '.debug_str' in file
'/tmp/cc1vnNPxdebugobj'
/usr/lib/rpm/debugedit build/systemd-bootchart
/usr/lib/rpm/debugedit: build/systemd-bootchart: Invalid .line_table offset
0x2b0803
/usr/lib/rpm/debugedit: build/systemd-bootchart: Could not find DWARF
abbreviation 7

In the above, note how ld has garbage-collected the '.debug_abbrev' and
'.debug_str' sections from the /tmp/cc*debugobj file.

Examining the binary via
  eu-readelf -w build/systemd-bootchart
shows bogus-looking compile_unit DIEs in the binary:

DWARF section [23] '.debug_info' at offset 0x10a6:
 [Offset]
 Compilation unit at offset 0:
 Version: 4, Abbreviation section offset: 0, Address size: 8, Offset size: 4
 [ b]  compile_unit
   producer (strp) "/builddir/build/BUILD/minimizing-2"
   language (data1) C99 (12)
   name (strp) "/builddir/build/BUILD/minimizing-2"
   comp_dir (strp) "/builddir/build/BUILD/minimizing-2"
   ranges   (sec_offset) range list [ 2]
   low_pc   (addr) 0x00250e030100
 Compilation unit at offset 105:
 Version: 4, Abbreviation section offset: 0, Address size: 8, Offset size: 4
 [74]  compile_unit
   producer (strp) "/builddir/build/BUILD/minimizing-2"
   language (data1) C99 (12)
   name (strp) "/builddir/build/BUILD/minimizing-2"
   comp_dir (strp) "/builddir/build/BUILD/minimizing-2"
   ranges   (sec_offset) range list [ 2]
   low_pc   (addr) 0x870006030100

Note how every string is using string 0.

Removing the -Wl,--gc-sections leads to sane-looking DIEs.

The issue seems to be that lto-wrapper generates /tmp/cc*debugobj files
containing "early LTO debug info", but, quoting Nick in:
  https://bugzilla.redhat.com/show_bug.cgi?id=1543912#c22
>   I have now found out what it happening, although I am still a little bit
>   confused as to why it should be occurring.  The LTO pass is producing an
>   object file that only contains debug information:
>
> /dev/shm/ccqhNEybdebugobj
>
>   (There was a clue in the filename, but I did not pay attention to this).
>
>   The linker's garbage collection code reasons that any file that does not
>   have *any* allocatable sections[1] can automatically be discarded, since it
>   cannot have any effect on the execution of the resulting binary, right ?
> ...
>
>   So this is why the .debug_abbrev and .debug_str sections are being
> discarded.
>   I do not know why the LTO pass is producing this file.  Perhaps someone
> else
>   more familiar with LTO can explain.
> 
>   A simple fix would be remove the code from the linker's garbage collector
>   that discards non-allocatable input files, but this seems rather heavy 
>   handed.  I would rather know if

[Bug fortran/84848] New: [8 Regression] FAIL: gfortran.dg/coarray/event_3.f08 -fcoarray=single -O2 -latomic execution test

2018-03-13 Thread danglin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84848

Bug ID: 84848
   Summary: [8 Regression] FAIL: gfortran.dg/coarray/event_3.f08
-fcoarray=single  -O2  -latomic execution test
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  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

spawn /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B/test/gnu/gcc
/objdir/gcc/testsuite/gfortran/../../
-B/test/gnu/gcc/objdir/hppa64-hp-hpux11.11
/./libgfortran/ /test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/coarray/event_3.f08
-fno-diagnostics-show-caret -fdiagnostics-color=never -fcoarray=single -O2
-lato
mic -B/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs
-L/test/gnu/g
cc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs
-L/test/gnu/gcc/objdir/hppa64-
hp-hpux11.11/./libgfortran/.libs
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./li
batomic/.libs -B/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libquadmath/.libs
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libquadmath/.libs
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libquadmath/.libs -lm -o
./event_3.exe
PASS: gfortran.dg/coarray/event_3.f08 -fcoarray=single  -O2  -latomic (test for
excess errors)
Setting LD_LIBRARY_PATH to
.:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libatomic/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libquadmath/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libquadmath/.libs:/test/gnu/gcc/objdir/gcc:.:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libatomic/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libquadmath/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libquadmath/.libs:/test/gnu/gcc/objdir/gcc
spawn [open ...]
ERROR STOP 1

Error termination. Backtrace:

Could not print backtrace: libbacktrace could not find executable to open
FAIL: gfortran.dg/coarray/event_3.f08 -fcoarray=single  -O2  -latomic execution
test

Revision 257793 was okay.

[Bug go/84215] Random results in go/libgo tests

2018-03-13 Thread clyon at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84215

--- Comment #12 from Christophe Lyon  ---
It's not very informative.

On arm:
PASS: crypto/x509
timed out in gotest
/home/tcwg-buildslave/workspace/tcwg-buildfarm/tcwg-apm_32-build/snapshots/gcc.git~master/libgo/testsuite/gotest:
line 624: 15642 Killed  ./a.out -test.short
-test.timeout=${timeout}s "$@"
FAIL: database/sql
PASS
PASS: database/sql/driver

On aarch64:
PASS: runtime/internal/sys
/home/tcwg-buildslave/workspace/tcwg-buildfarm/tcwg-apm_64-build/snapshots/gcc.git~master/libgo/testsuite/gotest:
line 624: 28388 Segmentation fault  (core dumped) ./a.out -test.short
-test.timeout=${timeout}s "$@"
FAIL: runtime/pprof
PASS
PASS: runtime/pprof/internal/profile

I included the PASS lines only to show the actual context around the FAIL
lines.

[Bug lto/84847] [8 Regression] Incompatibility between early LTO debug and "-Wl,--gc-sections" leads to corrupt DWARF debuginfo

2018-03-13 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84847

--- Comment #1 from rguenther at suse dot de  ---
On Tue, 13 Mar 2018, dmalcolm at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84847
> 
> Bug ID: 84847
>Summary: [8 Regression] Incompatibility between early LTO debug
> and "-Wl,--gc-sections" leads to corrupt DWARF
> debuginfo
>Product: gcc
>Version: 8.0
> Status: UNCONFIRMED
>   Severity: normal
>   Priority: P3
>  Component: lto
>   Assignee: unassigned at gcc dot gnu.org
>   Reporter: dmalcolm at gcc dot gnu.org
> CC: marxin at gcc dot gnu.org, nickc at gcc dot gnu.org,
> rguenth at gcc dot gnu.org
>   Target Milestone: ---
> 
> The downstream bug report:
>   https://bugzilla.redhat.com/show_bug.cgi?id=1543912
> describes a problem building systemd and systemd-bootchart with gcc 8, which
> turned out to be due to those packages' configure scripts injecting both
>   -flto
> and
>   -Wl,--gc-sections
> 
> They build fine with just one of them, but with both, the binaries have 
> corrupt
> DWARF debuginfo.
> 
> Adding "-Wl,--print-gc-sections" shows the issue more clearly.
> 
> I created a minimal reproducer here:
>   https://github.com/davidmalcolm/rhbz-1543912
> with which I can reproduce the issue, using:
>   gcc-8.0.1-0.16.fc29.x86_64
>   binutils-2.30-6.fc29.x86_64
> (this is on Fedora in a chroot via "mock -r fedora-rawhide-x86_64 shell"; I'm
> still working on reproducing this outside a chroot)
> 
> $ make
> gcc -I ./src -flto -O2 -g -c src/bootchart.c -o build/bootchart.o
> gcc -I ./src -flto -O2 -g -c src/log.c -o build/log.o
> gcc -flto -g -Wl,--gc-sections -Wl,--print-gc-sections \
>   build/bootchart.o build/log.o \
>   -o build/systemd-bootchart
> /usr/bin/ld: Removing unused section '.rodata.cst4' in file
> '/usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64/crt1.o'
> /usr/bin/ld: Removing unused section '.data' in file
> '/usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64/crt1.o'
> /usr/bin/ld: Removing unused section '.rodata' in file
> '/usr/lib/gcc/x86_64-redhat-linux/8/crtbegin.o'
> /usr/bin/ld: Removing unused section '.debug_abbrev' in file
> '/tmp/cc1vnNPxdebugobj'
> /usr/bin/ld: Removing unused section '.debug_str' in file
> '/tmp/cc1vnNPxdebugobj'
> /usr/lib/rpm/debugedit build/systemd-bootchart
> /usr/lib/rpm/debugedit: build/systemd-bootchart: Invalid .line_table offset
> 0x2b0803
> /usr/lib/rpm/debugedit: build/systemd-bootchart: Could not find DWARF
> abbreviation 7
> 
> In the above, note how ld has garbage-collected the '.debug_abbrev' and
> '.debug_str' sections from the /tmp/cc*debugobj file.
> 
> Examining the binary via
>   eu-readelf -w build/systemd-bootchart
> shows bogus-looking compile_unit DIEs in the binary:
> 
> DWARF section [23] '.debug_info' at offset 0x10a6:
>  [Offset]
>  Compilation unit at offset 0:
>  Version: 4, Abbreviation section offset: 0, Address size: 8, Offset size: 4
>  [ b]  compile_unit
>producer (strp) "/builddir/build/BUILD/minimizing-2"
>language (data1) C99 (12)
>name (strp) "/builddir/build/BUILD/minimizing-2"
>comp_dir (strp) "/builddir/build/BUILD/minimizing-2"
>ranges   (sec_offset) range list [ 2]
>low_pc   (addr) 0x00250e030100
>  Compilation unit at offset 105:
>  Version: 4, Abbreviation section offset: 0, Address size: 8, Offset size: 4
>  [74]  compile_unit
>producer (strp) "/builddir/build/BUILD/minimizing-2"
>language (data1) C99 (12)
>name (strp) "/builddir/build/BUILD/minimizing-2"
>comp_dir (strp) "/builddir/build/BUILD/minimizing-2"
>ranges   (sec_offset) range list [ 2]
>low_pc   (addr) 0x870006030100
> 
> Note how every string is using string 0.
> 
> Removing the -Wl,--gc-sections leads to sane-looking DIEs.
> 
> The issue seems to be that lto-wrapper generates /tmp/cc*debugobj files
> containing "early LTO debug info", but, quoting Nick in:
>   https://bugzilla.redhat.com/show_bug.cgi?id=1543912#c22
> >   I have now found out what it happening, although I am still a little bit
> >   confused as to why it should be occurring.  The LTO pass is producing an
> >   object file that only contains debug information:
> >
> > /dev/shm/ccqhNEybdebugobj
> >
> >   (There was a clue in the filename, but I did not pay attention to this).
> >
> >   The linker's garbage collection code reasons that any file that does not
> >   have *any* allocatable sections[1] can automatically be discarded, since 
> > it
> >   cannot have any effect on the execution of the resulting binary, right ?
> > ...
> >
> >   So this 

[Bug tree-optimization/84737] [8 Regression] 20% degradation in CPU2000 172.mgrid starting with r256888

2018-03-13 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84737

--- Comment #8 from Martin Liška  ---
(In reply to Martin Jambor from comment #7)
> Do I understand it correctly that you suspect that the new IPA-CP
> clone that is created from r256888 on is harmful?  In that case, you

Yes.

> want to test that by trying higher values of ipa-cp-eval-threshold,
> something like --param ipa-cp-eval-threshold 610 (i.e. bigger than
> 606).  Of course, if there are other clones with evaluations between
> 500 and 610, it would affect them too.
> 
> You may also want to try both fast and slow revisions with
> -fno-ipa-cp-clone as the first step, actually.

Btw. I can confirm that same clones is created on x86_64, but there's no speed
impact of the clone creation.

Is it also reproducible on ppc64{,le} ?

[Bug fortran/84848] [8 Regression] FAIL: gfortran.dg/coarray/event_3.f08 -fcoarray=single -O2 -latomic execution test

2018-03-13 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84848

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

Visit us at exhibitions worldwide--Noblelift E-Newsletter

2018-03-13 Thread Noblelift Equipment
https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=a19c01d77e&e=7264378baa
https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=16fd5683a7&e=7264378baa

Noblelift is the #1

manufacturer of pallet

trucks worldwide!
More information 
(https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=e6c12c8cca&e=7264378baa)

Standard

Applications
Nobelift offers full range of Electric Stackers including economic, standard, 
or heavy-duty, capacity from 1000kg up to 2000kg, lifting height from 1600mm up 
to 6000mm, Pedestrian or Ride-on types,Fork-over or Straddle leg, you will find 
the right one for your transport tasks, for more information, please feel free 
to contact us!

https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=3f30f8f624&e=7264378baa

https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=583b3f63f4&e=7264378baa

https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=ebe49cc10b&e=7264378baa

PSE10M---1000kg 
(https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=88eea6257e&e=7264378baa)

1.6/2.0m 
(https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=1cd056d1d2&e=7264378baa)

https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=2ceb2a40e5&e=7264378baa

https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=dd64d5b83a&e=7264378baa
https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=bbb6bdc3a4&e=7264378baa

PS12L/16L-1200/1600kg 
(https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=fdf9571398&e=7264378baa)

https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=3a6d5cbb30&e=7264378baa

* Monomast design with great view

* Compact design, AC drive unit

* Universal for low duty applications,   optional straddle-leg type


* Full electric operation(traveling & lifting)

* Compact design, DC drive unit

* Duplex mast with max. lift height up to  3.5m, optional straddle-leg type

* High performance German Vertical AC drive unit

* European top brand key components

* Long tiller with smallest turning radius
LEARN MORE 
(https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=6463182005&e=7264378baa)
 LEARN MORE 
(https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=c9b21ad586&e=7264378baa)
LEARN MORE 
(https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=f2b208df0b&e=7264378baa)
https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=a327b98ad8&e=7264378baa
https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=4034e920bc&e=7264378baa

https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=742d48acae&e=7264378baa

https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=2925224601&e=7264378baa

https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=226a943b42&e=7264378baa
 B12/15-1200/1500kg 
(https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=f16b664475&e=7264378baa)
https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=33e4015e07&e=7264378baa

https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=df8739ecc8&e=7264378baa

https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=7b3f92d8ee&e=7264378baa
 
(https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=7c5a7f79c6&e=7264378baa)
https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=8b40043f45&e=7264378baa

https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=42797bde20&e=7264378baa

https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=0c6385b626&e=7264378baa
 
(https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=8cd1956d6b&e=7264378baa)
https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=9ff80865ee&e=7264378baa

*  Noblelift powerful AC drive unit

* Optional ride-on foldable platform

* Triplex mast for PS B15 with extremely low overall height for combined space

* Noblelift powerful AC Vertical drive unit

* Optional ride-on foldable platform, optional straddle-leg type

* Optional electric power steering(EPS)

* European top brand key components, high performance Vertical AC drive unit

* Standard sideway battery replacement

* Long tiller with smallest turning radius
LEARN MORE 
(https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&id=5556a18448&e=7264378baa)
  LEARN MORE 
(https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a&i

[Bug c++/84840] [6/7/8 Regression] ICE (in poplevel_class) for `auto` in alias declaration

2018-03-13 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84840

Jason Merrill  changed:

   What|Removed |Added

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

[Bug tree-optimization/84005] [8 regression] gcc.dg/vect/bb-slp-1.c etc. FAIL

2018-03-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84005

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
This changed with r249896.
 Creating dr for *pin_64
 analyze_innermost: success.
-   base_address: &in
+   base_address: pin_64
offset from base address: 0
constant offset from base address: 0
-   step: 32
+   step: 0
aligned to: 128
base_object: *pin_64
 Creating dr for *pout_65
 analyze_innermost: success.
-   base_address: &out
+   base_address: pout_65
offset from base address: 0
constant offset from base address: 0
-   step: 32
+   step: 0
aligned to: 128
base_object: *pout_65
and similarly many times, 
-bb-slp-1.c:25:7: note: misalign = 0 bytes of ref *pin_64
+bb-slp-1.c:25:7: note: can't force alignment of ref: *pin_64
+bb-slp-1.c:25:7: note: Vectorizing an unaligned access.
... and finally
-bb-slp-1.c:15:3: note: basic block vectorized

[Bug tree-optimization/84005] [8 regression] gcc.dg/vect/bb-slp-1.c etc. FAIL

2018-03-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84005

--- Comment #7 from Jakub Jelinek  ---
This is from cross to powerpc64-linux,
-maltivec -mvsx -mno-allow-movmisalign -ftree-vectorize -fno-vect-cost-model
-fno-common -O2 bb-slp-1.c -nostdinc -fdump-tree-slp-details

[Bug lto/84847] [8 Regression] Incompatibility between early LTO debug and "-Wl,--gc-sections" leads to corrupt DWARF debuginfo

2018-03-13 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84847

Richard Biener  changed:

   What|Removed |Added

   Keywords||lto
   Target Milestone|--- |8.0

--- Comment #2 from Richard Biener  ---
Note this is clearly a binutils bug, not a GCC one.  Note I think we cannot
work around this ld bug in GCC.

The 20882 workaround cannot be removed from prettyprinters.exp when using
binutils 2.29.1.  I then still get

=== libstdc++ Summary ===

# of expected passes270
# of unsupported tests  14

instead of
=== libstdc++ Summary ===

# of expected passes512

errors are like


Dwarf Error: could not find abbrev number 100 [in module
/tmp/obj/x86_64-pc-linux-gnu/libstdc++-v3/testsuite/48362.exe]^M
skipping: Dwarf Error: could not find abbrev number 100 [in module
/tmp/obj/x86_64-pc-linux-gnu/libstdc++-v3/testsuite/48362.exe]^M
48362.gdb:5: Error in sourced command file:^M
No symbol table is loaded.  Use the "file" command.^M
skipping: 48362.gdb:5: Error in sourced command file:^M
skipping: No symbol table is loaded.  Use the "file" command.^M
UNSUPPORTED: libstdc++-prettyprinters/48362.cc

[Bug lto/84847] [8 Regression] Incompatibility between early LTO debug and "-Wl,--gc-sections" leads to corrupt DWARF debuginfo

2018-03-13 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84847

Richard Biener  changed:

   What|Removed |Added

   See Also||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=20882

--- Comment #3 from Richard Biener  ---
I have re-opened the binutils bug.

[Bug lto/84847] [8 Regression] Incompatibility between early LTO debug and "-Wl,--gc-sections" leads to corrupt DWARF debuginfo

2018-03-13 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84847

--- Comment #5 from H.J. Lu  ---
(In reply to David Malcolm from comment #0)
> The downstream bug report:
>   https://bugzilla.redhat.com/show_bug.cgi?id=1543912
> describes a problem building systemd and systemd-bootchart with gcc 8, which
> turned out to be due to those packages' configure scripts injecting both
>   -flto
> and
>   -Wl,--gc-sections
> 
> They build fine with just one of them, but with both, the binaries have
> corrupt DWARF debuginfo.
> 
> Adding "-Wl,--print-gc-sections" shows the issue more clearly.
> 
> I created a minimal reproducer here:
>   https://github.com/davidmalcolm/rhbz-1543912
> with which I can reproduce the issue, using:
>   gcc-8.0.1-0.16.fc29.x86_64
>   binutils-2.30-6.fc29.x86_64
> (this is on Fedora in a chroot via "mock -r fedora-rawhide-x86_64 shell";
> I'm still working on reproducing this outside a chroot)
> 
> $ make
> gcc -I ./src -flto -O2 -g -c src/bootchart.c -o build/bootchart.o
> gcc -I ./src -flto -O2 -g -c src/log.c -o build/log.o
> gcc -flto -g -Wl,--gc-sections -Wl,--print-gc-sections \
>   build/bootchart.o build/log.o \
>   -o build/systemd-bootchart
> /usr/bin/ld: Removing unused section '.rodata.cst4' in file
> '/usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64/crt1.o'
> /usr/bin/ld: Removing unused section '.data' in file
> '/usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64/crt1.o'
> /usr/bin/ld: Removing unused section '.rodata' in file
> '/usr/lib/gcc/x86_64-redhat-linux/8/crtbegin.o'
> /usr/bin/ld: Removing unused section '.debug_abbrev' in file
> '/tmp/cc1vnNPxdebugobj'
> /usr/bin/ld: Removing unused section '.debug_str' in file
> '/tmp/cc1vnNPxdebugobj'
> /usr/lib/rpm/debugedit build/systemd-bootchart
> /usr/lib/rpm/debugedit: build/systemd-bootchart: Invalid .line_table offset
> 0x2b0803
> /usr/lib/rpm/debugedit: build/systemd-bootchart: Could not find DWARF
> abbreviation 7
> 

With binutils master branch, I got

mkdir build
gcc -I ./src -flto -O2 -g -c src/bootchart.c -o build/bootchart.o
gcc -I ./src -flto -O2 -g -c src/log.c -o build/log.o
gcc -flto -g -Wl,--gc-sections -Wl,--print-gc-sections \
  build/bootchart.o build/log.o \
  -o build/systemd-bootchart
/usr/local/bin/ld: removing unused section '.rodata.cst4' in file
'/usr/lib/gcc/x86_64-redhat-linux/7/../../../../lib64/crt1.o'
/usr/local/bin/ld: removing unused section '.data' in file
'/usr/lib/gcc/x86_64-redhat-linux/7/../../../../lib64/crt1.o'
/usr/local/bin/ld: removing unused section '.rodata' in file
'/usr/lib/gcc/x86_64-redhat-linux/7/crtbegin.o'
/usr/lib/rpm/debugedit build/systemd-bootchart

Does it look OK?

[Bug lto/84847] [8 Regression] Incompatibility between early LTO debug and "-Wl,--gc-sections" leads to corrupt DWARF debuginfo

2018-03-13 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84847

--- Comment #4 from Richard Biener  ---
Note that back in time using gold made things work.

[Bug lto/84847] [8 Regression] Incompatibility between early LTO debug and "-Wl,--gc-sections" leads to corrupt DWARF debuginfo

2018-03-13 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84847

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-03-13
 CC||hjl.tools at gmail dot com
 Ever confirmed|0   |1

[Bug c++/84840] [6/7/8 Regression] ICE (in poplevel_class) for `auto` in alias declaration

2018-03-13 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84840

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Jason Merrill  ---
Same issue.

*** This bug has been marked as a duplicate of bug 84798 ***

[Bug c++/84798] [6/7/8 Regression] ICE (Segmentation fault) if `auto` appears in a template argument

2018-03-13 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84798

--- Comment #5 from Jason Merrill  ---
*** Bug 84840 has been marked as a duplicate of this bug. ***

[Bug lto/84847] [8 Regression] Incompatibility between early LTO debug and "-Wl,--gc-sections" leads to corrupt DWARF debuginfo

2018-03-13 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84847

--- Comment #6 from rguenther at suse dot de  ---
On Tue, 13 Mar 2018, hjl.tools at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84847
> 
> --- Comment #5 from H.J. Lu  ---
> (In reply to David Malcolm from comment #0)
> > The downstream bug report:
> >   https://bugzilla.redhat.com/show_bug.cgi?id=1543912
> > describes a problem building systemd and systemd-bootchart with gcc 8, which
> > turned out to be due to those packages' configure scripts injecting both
> >   -flto
> > and
> >   -Wl,--gc-sections
> > 
> > They build fine with just one of them, but with both, the binaries have
> > corrupt DWARF debuginfo.
> > 
> > Adding "-Wl,--print-gc-sections" shows the issue more clearly.
> > 
> > I created a minimal reproducer here:
> >   https://github.com/davidmalcolm/rhbz-1543912
> > with which I can reproduce the issue, using:
> >   gcc-8.0.1-0.16.fc29.x86_64
> >   binutils-2.30-6.fc29.x86_64
> > (this is on Fedora in a chroot via "mock -r fedora-rawhide-x86_64 shell";
> > I'm still working on reproducing this outside a chroot)
> > 
> > $ make
> > gcc -I ./src -flto -O2 -g -c src/bootchart.c -o build/bootchart.o
> > gcc -I ./src -flto -O2 -g -c src/log.c -o build/log.o
> > gcc -flto -g -Wl,--gc-sections -Wl,--print-gc-sections \
> >   build/bootchart.o build/log.o \
> >   -o build/systemd-bootchart
> > /usr/bin/ld: Removing unused section '.rodata.cst4' in file
> > '/usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64/crt1.o'
> > /usr/bin/ld: Removing unused section '.data' in file
> > '/usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64/crt1.o'
> > /usr/bin/ld: Removing unused section '.rodata' in file
> > '/usr/lib/gcc/x86_64-redhat-linux/8/crtbegin.o'
> > /usr/bin/ld: Removing unused section '.debug_abbrev' in file
> > '/tmp/cc1vnNPxdebugobj'
> > /usr/bin/ld: Removing unused section '.debug_str' in file
> > '/tmp/cc1vnNPxdebugobj'
> > /usr/lib/rpm/debugedit build/systemd-bootchart
> > /usr/lib/rpm/debugedit: build/systemd-bootchart: Invalid .line_table offset
> > 0x2b0803
> > /usr/lib/rpm/debugedit: build/systemd-bootchart: Could not find DWARF
> > abbreviation 7
> > 
> 
> With binutils master branch, I got
> 
> mkdir build
> gcc -I ./src -flto -O2 -g -c src/bootchart.c -o build/bootchart.o
> gcc -I ./src -flto -O2 -g -c src/log.c -o build/log.o
> gcc -flto -g -Wl,--gc-sections -Wl,--print-gc-sections \
>   build/bootchart.o build/log.o \
>   -o build/systemd-bootchart
> /usr/local/bin/ld: removing unused section '.rodata.cst4' in file
> '/usr/lib/gcc/x86_64-redhat-linux/7/../../../../lib64/crt1.o'
> /usr/local/bin/ld: removing unused section '.data' in file
> '/usr/lib/gcc/x86_64-redhat-linux/7/../../../../lib64/crt1.o'
> /usr/local/bin/ld: removing unused section '.rodata' in file
> '/usr/lib/gcc/x86_64-redhat-linux/7/crtbegin.o'
> /usr/lib/rpm/debugedit build/systemd-bootchart
> 
> Does it look OK?

Can you try

make check-target-libstdc++-v3 RUNTESTFLAGS="prettyprinters.exp"

with binutils master and the prettyprinters.exp hack removed?

Do you know what fixed it on master?

[Bug fortran/84848] [8 Regression] FAIL: gfortran.dg/coarray/event_3.f08 -fcoarray=single -O2 -latomic execution test

2018-03-13 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84848

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
WORKSFORME on x86_64-apple-darwin17. A target issue?

[Bug lto/84847] [8 Regression] Incompatibility between early LTO debug and "-Wl,--gc-sections" leads to corrupt DWARF debuginfo

2018-03-13 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84847

--- Comment #7 from H.J. Lu  ---
Binutils 2.30 branch looks normal:

[hjl@gnu-cfl-1 rhbz-1543912]$ gcc -flto -g -Wl,--gc-sections
-Wl,--print-gc-sections   build/bootchart.o build/log.o   -o
build/systemd-bootchart -B./ -Wl,-v
collect2 version 7.3.1 20180303 (Red Hat 7.3.1-5)
./ld -plugin /usr/libexec/gcc/x86_64-redhat-linux/7/liblto_plugin.so
-plugin-opt=/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper
-plugin-opt=-fresolution=/tmp/cc1PZVqG.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id
--no-add-needed --eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker
/lib64/ld-linux-x86-64.so.2 -o build/systemd-bootchart
/usr/lib/gcc/x86_64-redhat-linux/7/../../../../lib64/crt1.o
/usr/lib/gcc/x86_64-redhat-linux/7/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-redhat-linux/7/crtbegin.o -L.
-L/usr/lib/gcc/x86_64-redhat-linux/7
-L/usr/lib/gcc/x86_64-redhat-linux/7/../../../../lib64 -L/lib/../lib64
-L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/7/../../.. --gc-sections
--print-gc-sections build/bootchart.o build/log.o -v -lgcc --as-needed -lgcc_s
--no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/x86_64-redhat-linux/7/crtend.o
/usr/lib/gcc/x86_64-redhat-linux/7/../../../../lib64/crtn.o
GNU ld (GNU Binutils) 2.30.0.20180313
./ld: Removing unused section '.rodata.cst4' in file
'/usr/lib/gcc/x86_64-redhat-linux/7/../../../../lib64/crt1.o'
./ld: Removing unused section '.data' in file
'/usr/lib/gcc/x86_64-redhat-linux/7/../../../../lib64/crt1.o'
./ld: Removing unused section '.rodata' in file
'/usr/lib/gcc/x86_64-redhat-linux/7/crtbegin.o'
[hjl@gnu-cfl-1 rhbz-1543912]$ 

Please try FSF binutils 2.30, not from Fedora 28.

[Bug lto/84847] [8 Regression] Incompatibility between early LTO debug and "-Wl,--gc-sections" leads to corrupt DWARF debuginfo

2018-03-13 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84847

--- Comment #8 from rguenther at suse dot de  ---
On Tue, 13 Mar 2018, hjl.tools at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84847
> 
> --- Comment #7 from H.J. Lu  ---
> Binutils 2.30 branch looks normal:

I tried 2.30 branch at 4cd0043413 and that still has UNRESOLVED
libstdc++ prettyprinter tests.

[Bug lto/84847] [8 Regression] Incompatibility between early LTO debug and "-Wl,--gc-sections" leads to corrupt DWARF debuginfo

2018-03-13 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84847

--- Comment #9 from H.J. Lu  ---
(In reply to rguent...@suse.de from comment #6)
> 
> make check-target-libstdc++-v3 RUNTESTFLAGS="prettyprinters.exp"

I tried:

diff --git a/libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp
b/libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp
index c51b1ffb21c..fab6ef11947 100644
--- a/libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp
+++ b/libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp
@@ -47,14 +47,6 @@ global PCH_CXXFLAGS
 gdb-dg-runtest [lsort [glob $srcdir/$subdir/*.cc]] \
   "" "$DEFAULT_CXXFLAGS $PCH_CXXFLAGS"

-if { [check_effective_target_lto] } {
-  append cxxflags " -flto"
-  # work around sourceware.org 20882
-  regsub {^(.*)-Wl,--gc-sections(.*)$} $cxxldflags {\1\2} cxxldflags
-  gdb-dg-runtest [lsort [glob $srcdir/$subdir/*.cc]] \
-"" "$DEFAULT_CXXFLAGS -flto $PCH_CXXFLAGS"
-}
-
 if [info exists guality_gdb_name] {
 unsetenv GUALITY_GDB_NAME
 }

> with binutils master and the prettyprinters.exp hack removed?

=== libstdc++ Summary ===

# of expected passes140

> Do you know what fixed it on master?

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=b7c871edcd83ccdc5fcd8148a7f433efd6b52255

[Bug sanitizer/83392] FAIL: c-c++-common/ubsan/ptr-overflow-sanitization-1.c scan-tree-dump-times

2018-03-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83392

--- Comment #4 from Jakub Jelinek  ---
To me it looks like a sanopt bug.

The -m32 version is missing 3 checks, lines 28/29/30, but those are all present
before the sanopt pass:
  [ptr-overflow-sanitization-1.c:28:6] UBSAN_PTR
([ptr-overflow-sanitization-1.c:27:5] &MEM[(void
*)[ptr-overflow-sanitization-1.c:27:7] &b + -9223372036854775807B],
9223372036854775805);
for -m64 and corresponding -m32:
  [ptr-overflow-sanitization-1.c:28:6] UBSAN_PTR
([ptr-overflow-sanitization-1.c:27:5] &MEM[(void
*)[ptr-overflow-sanitization-1.c:27:7] &b + 2147483649B], 2147483645);
That is always &b + 0x80000001 and 0x7ffffffd, so from the POV of the
ptr overflow sanitization they should be handled the same.

  1   2   3   >