[Bug target/85401] New: segfault building code for VAX

[coypu at sdf dot org]

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

Bug ID: 85401
   Summary: segfault building code for VAX
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: coypu at sdf dot org
  Target Milestone: ---

Created attachment 43929
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43929=edit
Reproduce test

build with the following flags fails:
  -O2 -fno-pic -c ip_icmp.i



here is a backtrace, from trunk as of April 14 2018.

Starting program: /home/fly/gcc/build/gcc/cc1 -fpreprocessed ip_icmp.i -quiet
-dumpbase ip_icmp.i -auxbase ip_icmp -O2 -fno-pic -o /var/tmp//ccO5AxRb.s
In file included from ../../../../sys/timevar.h:66,
 from ../../../../sys/time.h:307,
 from ../../../../sys/param.h:145,
 from ../../../../netinet/ip_icmp.c:103:
../../../../sys/systm.h:225:6: warning: conflicting types for built-in function
'printf' [-Wbuiltin-declaration-mismatch]
../../../../sys/systm.h:229:6: warning: conflicting types for built-in function
'vprintf' [-Wbuiltin-declaration-mismatch]
In file included from ../../../../netinet/ip_icmp.c:112:
../../../../sys/syslog.h:233:6: warning: conflicting types for built-in
function 'log' [-Wbuiltin-declaration-mismatch]

Program received signal SIGSEGV, Segmentation fault.
0x00bfd868 in allocno_copy_cost_saving (allocno=0x7e3c3e791190,
hard_regno=11) at ../../gcc/ira-color.c:2832
2832  cost += cp->freq *
ira_register_move_cost[allocno_mode][rclass][rclass];
1: rclass = ALL_REGS
2: allocno_mode = E_QImode
3: ira_register_move_cost[allocno_mode][rclass][rclass] = 
4: cp->freq = 36
5: ira_register_move_cost = {0x0, 0x0, 0x0, 0x0, 0x0, 0x7e3c3ed98850,
0x7e3c3ed98850, 0x0 }
(gdb) bt full
#0  0x00bfd868 in allocno_copy_cost_saving (allocno=0x7e3c3e791190,
hard_regno=11) at ../../gcc/ira-color.c:2832
cost = 0
allocno_mode = E_QImode
rclass = ALL_REGS
cp = 0x7e3c3e511380
next_cp = 0x0
__FUNCTION__ = "allocno_copy_cost_saving"
#1  0x00bfdbb9 in improve_allocation () at ../../gcc/ira-color.c:2905
i = 2
j = 11
k = 11
n = 5
hregno = 11
conflict_hregno = 1
base_cost = 2232
class_size = 12
word = 1
nwords = 1
check = 3
spill_cost = 4068
min_cost = -594
nregs = 1
conflict_nregs = 1
r = 2
best = 10
try_p = true
aclass = ALL_REGS
mode = E_SImode
allocno_costs = 0x7e3c3e7313c8
costs = {-1740536, 40443, 0, 484, 552, 0, -2232, -2232, -2232, -2232,
-2232, 0, 1050933376, 32316, -1741856, 32639}
conflicting_regs = {18446744073709547521, 140187730799504}
profitable_hard_regs = 4032
a = 0x7e3c3e791190
bi = {elt1 = 0x7e3c3e7b1a90, elt2 = 0x0, word_no = 0, bits =
4611686018427387903}
__FUNCTION__ = "improve_allocation"
#2  0x00bfea51 in color_allocnos () at ../../gcc/ira-color.c:3201
i = 256
n = 32316
bi = {elt1 = 0x0, elt2 = 0x0, word_no = 2, bits = 0}
a = 0x7e3c3e799050
__FUNCTION__ = "color_allocnos"
#3  0x00bff13f in color_pass (loop_tree_node=0x7e3c3ed2fc00) at
../../gcc/ira-color.c:3310
regno = 32316
hard_regno = -1741504
index = -1
n = 81
cost = 0
exit_freq = 1048255088
enter_freq = 0
j = 256
bi = {elt1 = 0x0, elt2 = 0x0, word_no = 2, bits = 0}
mode = 32639
rclass = NO_REGS
aclass = (unknown: 33152352)
pclass = (ALL_REGS | LIM_REG_CLASSES | unknown: 9049864)
a = 0x7e3c3e799050
subloop_allocno = 0xb8
subloop_node = 0x7f7fffe56d20
__FUNCTION__ = "color_pass"
#4  0x00be8146 in ira_traverse_loop_tree (bb_p=false,
loop_node=0x7e3c3ed2fc00, 
preorder_func=0xbfef25 ,
postorder_func=0x0) at ../../gcc/ira-build.c:1781
subloop_node = 0xbd6ab8 
__FUNCTION__ = "ira_traverse_loop_tree"
#5  0x00bffa0d in do_coloring () at ../../gcc/ira-color.c:3461
No locals.
#6  0x00c03501 in color () at ../../gcc/ira-color.c:4838
No locals.
#7  0x00c039d3 in ira_color () at ../../gcc/ira-color.c:4953
a = 0x7e3c3e799050
ai = {n = 172}
#8  0x00be30ff in ira (f=0x0) at ../../gcc/ira.c:5308
loops_p = true
ira_max_point_before_emit = 524288
saved_flag_caller_saves = true
saved_flag_ira_region = IRA_REGION_MIXED
__FUNCTION__ = "ira"
#9  0x00be3887 in (anonymous namespace)::pass_ira::execute
(this=0x7e3c3ed86bc0) at ../../gcc/ira.c:5606
No locals.
#10 0x00d142af in execute_one_pass (pass=0x7e3c3ed86bc0) at

[Bug target/85397] New: -mcet -fcf-protection doesn't work with label in nested function

[hjl.tools at gmail dot com]

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

Bug ID: 85397
   Summary: -mcet -fcf-protection doesn't work with label in
nested function
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: igor.v.tsimbalist at intel dot com
Blocks: 81652
  Target Milestone: ---
Target: x86_64

[hjl@gnu-cet-1 cet-3]$ cat x.i
int
s(int i)
{
  if(i>0)
{
  __label__ l1;
  int f(int i)
{
  if(i==2)
goto l1;
  return 0;
}
  return f(i);
l1:
  ;
}
  return 1;
}

int
x(void)
{
  return s(0)==1&(1)==0&(2)==1;
}
int
main()
{
  if(x()!=1)
__builtin_abort();
  return 0;
}
[hjl@gnu-cet-1 cet-3]$ make
gcc -O2 -mcet -fcf-protection -S x.i
gcc -g -O2 -mcet -fcf-protection -o x x.s
./x
make: *** [Makefile:10: all] Segmentation fault
[hjl@gnu-cet-1 cet-3]$ gdb x
GNU gdb (GDB) Fedora 8.1-11.fc28
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from x...done.
(gdb) r
Starting program: /export/home/hjl/bugs/gcc/cet-3/x 
Missing separate debuginfos, use: dnf debuginfo-install
glibc-2.27-8.6.fc28.x86_64

Program received signal SIGSEGV, Segmentation fault.
s () at x.s:76
76  ret
(gdb) bt
#0  s () at x.s:76
#1  0x00401238 in x () at x.s:136
#2  0x0040106d in main () at x.s:157
(gdb)


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652
[Bug 81652] [meta-bug] -fcf-protection=full -mcet bugs

[Bug other/85398] New: g++ reports "array subscript is above array bounds" when it cannot be sure

[patrickdepinguin at gmail dot com]

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

Bug ID: 85398
   Summary: g++ reports "array subscript is above array bounds"
when it cannot be sure
   Product: gcc
   Version: 6.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrickdepinguin at gmail dot com
  Target Milestone: ---

In following test program:


--
#define NB_DEV 1
extern unsigned int max;

unsigned long left[NB_DEV];
unsigned long right[NB_DEV];

void foo()
{
unsigned int i;

for (i=1; i < max; i++)
  left[i] = right[i-1];
}
--

compiled with:

$(CXX) -Werror -Wall -O2 -c reprod.cc

g++ gives following warning/error:

reprod.cc: In function 'void foo()':
reprod.cc:13:13: error: array subscript is above array bounds
[-Werror=array-bounds]
   left[i] = right[i-1];
   ~~^
cc1plus: all warnings being treated as errors
make: *** [Makefile:4: all] Error 1


While there _could_ be an array overflow, g++ cannot know for sure because the
loop boundary 'max' is an external variable. The code is perfectly fine in case
max == 1. In that case, the loop does nothing.

This is a reduced version of real code where the arrays left and right are
dimensioned to some maximum value NB_DEV, and 'max' will be at most that NB_DEV
but possibly smaller. We are thus sure there will not be an array overflow.


Going back to the reproduction code above, if you change NB_DEV to 2 (for
example), no warning is thrown, even though there could still be an overflow in
case max == 5, for example.

According to me, no warning should be thrown because g++ cannot surely say
there is a problem.

Same problem is seen if you compile this as C code rather than C++.
Problem is not seen with -O1, only with -O2 or -O3.

This problem was tested with gcc 6.4.0 (x86_64), gcc 6.3.0 (armeb), gcc 5.4.0
(armeb) and gcc 4.9.4 (armeb).

[Bug other/85398] g++ reports "array subscript is above array bounds" when it cannot be sure

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic,
   ||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-13
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  It doesn't look like the assignment to left[i] affects the
determination of the maximum number of iterations of the loop during unrolling.
 This is also a missed optimization opportunity since the whole loop could be
eliminated.

[Bug rtl-optimization/85393] [8 Regression] Miscompilation with hot/cold partitioning starting with r254832

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/85399] New: Redundant SSP clearing before rdssp

[hjl.tools at gmail dot com]

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

Bug ID: 85399
   Summary: Redundant SSP clearing before rdssp
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: igor.v.tsimbalist at intel dot com
Blocks: 81652
  Target Milestone: ---

Since rdssp has been changed to

;; CET instructions
(define_insn "rdssp"
  [(set (match_operand:SWI48x 0 "register_operand" "=r")
(unspec_volatile:SWI48x [(const_int 0)] UNSPECV_NOP_RDSSP))]
  "TARGET_SHSTK"
  "xor{l}\t%k0, %k0\n\trdssp\t%0"
  [(set_attr "length" "6")
   (set_attr "type" "other")])

  emit_insn (gen_rtx_SET (reg_ssp, const0_rtx));
   This is redundant now.
  emit_insn ((word_mode == SImode)
 ? gen_rdsspsi (reg_ssp)
 : gen_rdsspdi (reg_ssp));


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652
[Bug 81652] [meta-bug] -fcf-protection=full -mcet bugs

[Bug target/83660] ICE with vec_extract inside expression statement

[acsawdey at gcc dot gnu.org]

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

--- Comment #12 from acsawdey at gcc dot gnu.org ---
This function is called from cp/semantics.c maybe_cleanup_point_expr()

tree
fold_build_cleanup_point_expr (tree type, tree expr)
{
  /* If the expression does not have side effects then we don't have to wrap
 it with a cleanup point expression.  */
  if (!TREE_SIDE_EFFECTS (expr))
return expr;

In the vec_extract case it bails out due to no side effects and does not put in
the cleanup point.

So in fact a more minimal version of Jakub's patch also works. If you mark that
this has side effects, then the cleanup point is added for us by the existing
code:

Index: config/rs6000/rs6000-c.c
===
--- config/rs6000/rs6000-c.c(revision 259353)
+++ config/rs6000/rs6000-c.c(working copy)
@@ -6704,6 +6704,8 @@
   stmt = convert (innerptrtype, stmt);
   stmt = build_binary_op (loc, PLUS_EXPR, stmt, arg2, 1);
   stmt = build_indirect_ref (loc, stmt, RO_NULL);
+  if (c_dialect_cxx ())
+   TREE_SIDE_EFFECTS (stmt) = 1;

   return stmt;
 }

Any comments on whether this is the right way to fix this? I think the
vec_insert case does not need to be changed because the MODIFY_EXPR used there
will mark that there are side effects for us.

[Bug target/83660] ICE with vec_extract inside expression statement

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
(In reply to acsawdey from comment #12)
> This function is called from cp/semantics.c maybe_cleanup_point_expr()
> 
> tree
> fold_build_cleanup_point_expr (tree type, tree expr)
> {
>   /* If the expression does not have side effects then we don't have to wrap
>  it with a cleanup point expression.  */
>   if (!TREE_SIDE_EFFECTS (expr))
> return expr;
> 
> In the vec_extract case it bails out due to no side effects and does not put
> in the cleanup point.
> 
> So in fact a more minimal version of Jakub's patch also works. If you mark
> that this has side effects, then the cleanup point is added for us by the
> existing code:
> 
> Index: config/rs6000/rs6000-c.c
> ===
> --- config/rs6000/rs6000-c.c(revision 259353)
> +++ config/rs6000/rs6000-c.c(working copy)
> @@ -6704,6 +6704,8 @@
>stmt = convert (innerptrtype, stmt);
>stmt = build_binary_op (loc, PLUS_EXPR, stmt, arg2, 1);
>stmt = build_indirect_ref (loc, stmt, RO_NULL);
> +  if (c_dialect_cxx ())
> +   TREE_SIDE_EFFECTS (stmt) = 1;
>  
>return stmt;
>  }
> 
> Any comments on whether this is the right way to fix this? I think the
> vec_insert case does not need to be changed because the MODIFY_EXPR used
> there will mark that there are side effects for us.

I think this is reasonable, but should have a comment why we do that.

[Bug rtl-optimization/85393] [8 Regression] Miscompilation with hot/cold partitioning starting with r254832

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Fri Apr 13 19:55:15 2018
New Revision: 259378

URL: https://gcc.gnu.org/viewcvs?rev=259378=gcc=rev
Log:
PR rtl-optimization/85393
* except.h (expand_dw2_landing_pad_for_region): Remove declaration.
* except.c (expand_dw2_landing_pad_for_region): Make static.
* bb-reorder.c (fix_up_crossing_landing_pad): In new_bb emit just
a label and unconditional jump to old_bb, rather than
expand_dw2_landing_pad_for_region insn(s) and jump to single_succ
basic block.

* g++.dg/opt/pr85393.C: New test.
* g++.dg/opt/pr85393-aux.cc: New file.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr85393-aux.cc
trunk/gcc/testsuite/g++.dg/opt/pr85393.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/bb-reorder.c
trunk/gcc/except.c
trunk/gcc/except.h
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/85376] [8 Regression] wrong code with -Og -fno-dce -fgcse -fno-tree-ccp -fno-tree-copy-prop

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Fri Apr 13 19:39:11 2018
New Revision: 259377

URL: https://gcc.gnu.org/viewcvs?rev=259377=gcc=rev
Log:
PR rtl-optimization/85376
* simplify-rtx.c (simplify_const_unary_operation): For CLZ and CTZ and
zero op0, if C?Z_DEFINED_VALUE_AT_ZERO is false, return NULL_RTX
instead of a specific value.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr85376.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/simplify-rtx.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/85376] [8 Regression] wrong code with -Og -fno-dce -fgcse -fno-tree-ccp -fno-tree-copy-prop

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/85397] -mcet -fcf-protection doesn't work with label in nested function

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-13
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
Do we need to define save_stack_nonlocal and restore_stack_nonlocal to
save and restore shadow stack pointers?

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

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #4 from Alexander Monakov  ---
Can you please share tree and rtl dumps for the nice testcase in comment #3 by
re-running it with -fdump-tree-all -fdump-rtl-all and attaching a tar.gz with
those? I could not reproduce it either, so having the dumps might help us see
what's different on our side.

(and an additional archive for a non-failing run without
-fselective-scheduling2 might be helpful too)

[Bug c++/82099] internal compiler error: in type_throw_all_p, at cp/except.c:1186 when using a function pointer for templated predicate

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

   Last reconfirmed|2017-09-04 00:00:00 |2018-4-13
 CC||reichelt at gcc dot gnu.org

--- Comment #5 from Volker Reichelt  ---
On trunk (GCC 8) the testcases of comment #2 and comment #4 only crash with
-std=c++17, but don't crash with -std=c++11 or -std=c++14.

[Bug rtl-optimization/79985] ICE in code_motion_path_driver, at sel-sched.c:6580

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |amonakov at gcc dot 
gnu.org

--- Comment #6 from Alexander Monakov  ---
Candidate patch for gcc-9 stage 1:

diff --git a/gcc/df-scan.c b/gcc/df-scan.c
index 95e1e0df2d5..4708fc328c6 100644
--- a/gcc/df-scan.c
+++ b/gcc/df-scan.c
@@ -3207,7 +3207,8 @@ df_insn_refs_collect (struct df_collection_rec
*collection_rec,
   if (CALL_P (insn_info->insn))
 df_get_call_refs (collection_rec, bb, insn_info, flags);

-  if (asm_noperands (PATTERN (insn_info->insn)) >= 0)
+  if (asm_noperands (PATTERN (insn_info->insn)) >= 0
+  && volatile_insn_p (PATTERN (insn_info->insn)))
 for (unsigned i = 0; i < FIRST_PSEUDO_REGISTER; i++)
   if (global_regs[i])
{

[Bug libstdc++/85396] New: _M_t._M_emplace_hint_unique

[microprogs at mail dot ru]

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

Bug ID: 85396
   Summary: _M_t._M_emplace_hint_unique
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: microprogs at mail dot ru
  Target Milestone: ---

Created attachment 43927
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43927=edit
preprocessed test.cpp, you can see that src in comment, it's short

// gcc (Raspbian 6.3.0-18+rpi1+deb9u1) 6.3.0 20170516
// cat /etc/debian_version = 9.4
// Linux hostname 4.14.30-v7+ #1102 SMP Mon Mar 26 16:45:49 BST 2018 armv7l
GNU/Linux
// Raspberry Pi 3B
//
// C++11: ERROR, cannot compile
//g++ -std=c++11 -o test test.cpp
//
// C++14: OK
//g++ -std=c++14 -o test test.cpp
//
// old C++: OK
//g++ -o test test.cpp


#include 

struct MyType
{
double x;
};

int main(int argc, char** argv)
{
std::map t;
MyType  = t[""];
return 0;
}

/*
ERROR:
In file included from /usr/include/c++/6/map:61:0,
 from test.cpp:17:
/usr/include/c++/6/bits/stl_map.h: In member function ‘std::map<_Key, _Tp,
_Compare, _Alloc>::mapped_type& std::map<_Key, _Tp, _Compare,
_Alloc>::operator[](std::map<_Key, _Tp, _Compare, _Alloc>::key_type&&) [with
_Key = std::__cxx11::basic_string; _Tp = MyType; _Compare =
std::less; _Alloc =
std::allocator >]’:
/usr/include/c++/6/bits/stl_map.h:502:4: note: parameter passing for argument
of type ‘std::_Rb_tree, std::_Select1st >,
std::less, std::allocator > >::const_iterator {aka
std::_Rb_tree_const_iterator >}’ will change in GCC 7.1
__i = _M_t._M_emplace_hint_unique(__i, std::piecewise_construct,
^~~
In file included from /usr/include/c++/6/map:60:0,
 from test.cpp:17:
/usr/include/c++/6/bits/stl_tree.h: In member function ‘std::_Rb_tree<_Key,
_Val, _KeyOfValue, _Compare, _Alloc>::iterator std::_Rb_tree<_Key, _Val,
_KeyOfValue, _Compare, _Alloc>::_M_emplace_hint_unique(std::_Rb_tree<_Key,
_Val, _KeyOfValue, _Compare, _Alloc>::const_iterator, _Args&& ...) [with _Args
= {const std::piecewise_construct_t&,
std::tuple&&>, std::tuple<>}; _Key =
std::__cxx11::basic_string; _Val = std::pair, MyType>; _KeyOfValue =
std::_Select1st >;
_Compare = std::less; _Alloc =
std::allocator >]’:
/usr/include/c++/6/bits/stl_tree.h:2193:7: note: parameter passing for argument
of type ‘std::_Rb_tree, std::_Select1st >,
std::less, std::allocator > >::const_iterator {aka
std::_Rb_tree_const_iterator >}’ will change in GCC 7.1
   _Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::
   ^~~
/usr/include/c++/6/bits/stl_tree.h: In member function
‘std::pair
std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_M_get_insert_hint_unique_pos(std::_Rb_tree<_Key, _Val, _KeyOfValue,
_Compare, _Alloc>::const_iterator, const key_type&) [with _Key =
std::__cxx11::basic_string; _Val = std::pair, MyType>; _KeyOfValue =
std::_Select1st >;
_Compare = std::less; _Alloc =
std::allocator >]’:
/usr/include/c++/6/bits/stl_tree.h:1928:5: note: parameter passing for argument
of type ‘std::_Rb_tree, std::_Select1st >,
std::less, std::allocator > >::const_iterator {aka
std::_Rb_tree_const_iterator >}’ will change in GCC 7.1
 _Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::
 ^~~

*/

[Bug c/85365] -Wrestrict false positives with -fsanitize=undefined

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #6 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00676.html

[Bug c++/85400] New: R_SPARC_TLS_*: invalid relocations generated for optimized builds on sparc

[phantall at gmail dot com]

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

Bug ID: 85400
   Summary: R_SPARC_TLS_*: invalid relocations generated for
optimized builds on sparc
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: phantall at gmail dot com
  Target Milestone: ---

In Solaris 10 & 11 using GCC versions 4.8, 4.9.2, 7.2.0 I get relocation errors
when thread_local variables are used in a struct/class.  Example code that
reproduces the problem:

> struct Test {
>   int blah( int y ) {
> thread_local mything = 3;
> mything = y > 0 ? y : mything;
> return mything;
>   }
> };
> int stuff( Test& test, int y ) {
>   return test.blah(y);
> }

When compiled:

> $ g++ -m32 -fPIC -std=gnu++14 blah.cc -c -o blah1.o
> $ g++ -m32 -fPIC -std=gnu++14 blah.cc -c -o blah2.o -O3
> $ objdump -xC blah1.o | grep mything
> (...)
> 0038 R_SPARC_TLS_GD_HI22  Test::blah(int)::mything
> 003c R_SPARC_TLS_GD_LO10  Test::blah(int)::mything
> (...)
> $ objdump -xC blah2.o | grep mything
> (...)
> 0014 R_SPARC_TLS_LDM_HI22  Test::blah(int)::mything
> 001c R_SPARC_TLS_LDO_HIX22  Test::blah(int)::mything
> 0020 R_SPARC_TLS_LDM_LO10  Test::blah(int)::mything
> 0024 R_SPARC_TLS_LDO_LOX10  Test::blah(int)::mything
> (...)
> $ g++ -m32 -fPIC -shared blah2.o -o libblah.so
> ld: fatal: relocation error: R_SPARC_TLS_LDM_HI22: file blah2.o: symbol: 
> _ZZN4Test4blahEiE7mything: bound to: blah.o: relocation illegal when not 
> bound to object being created
> ld: fatal: relocation error: R_SPARC_TLS_LDM_HIX22: file blah2.o: symbol: 
> _ZZN4Test4blahEiE7mything: bound to: blah.o: relocation illegal when not 
> bound to object being created
> ...


For reference:

* It happens at all optimization levels above -O0 and for all combinations of
-std={c,gnu}++{11,14}
* This was discovered while building boost 1.66.0 with -std=gnu++14.  The error
occurs while linking libboost_fiber.so and comes from work_stealing.cpp for
boost::fibers::detail::spinlock_ttas::lock()::generator ... where "generator"
in that code is a static thread_local at member-function scope.
* The compilers I built and those produced by OpenCSW use the Solaris assembler
(/usr/ccs/bin/as) instead of gas.

[Bug target/85397] -mcet -fcf-protection doesn't work with label in nested function

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
builtin_longjmp has also the same issue as PR 85025.  I fixed it on
hjl/cet/master branch.

[Bug target/83402] PPC64 implementation of ./rs6000/emmintrin.h gives out of range for _mm_slli_epi32

[segher at gcc dot gnu.org]

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

--- Comment #12 from Segher Boessenkool  ---
Author: segher
Date: Fri Apr 13 23:13:40 2018
New Revision: 259380

URL: https://gcc.gnu.org/viewcvs?rev=259380=gcc=rev
Log:
rs6000: Fix _mm_slli_epi{32,64} for shift values 16 through 31 and negative
(PR84302)

The powerpc versions of _mm_slli_epi32 and __mm_slli_epi64 in emmintrin.h
do not properly handle shift values between 16 and 31, inclusive.
These are setting up the shift with vec_splat_s32, which only accepts
*5 bit signed* shift values, or a range of -16 to 15.  Values above 15
produce an error:

  error: argument 1 must be a 5-bit signed literal

Fix is to effectively reduce the range for which vec_splat_s32 is used
to < 32 and use vec_splats otherwise.

Also, __mm_slli_epi{16,32,64}, when given a negative shift value,
should always return a vector of {0}.


PR target/83402
* config/rs6000/emmintrin.h (_mm_slli_epi{16,32,64}):
Ensure that vec_splat_s32 is only called with 0 <= shift < 16.
Ensure negative shifts result in {0}.

gcc/testsuite/
PR target/83402
* gcc.target/powerpc/sse2-psllw-1.c: Refactor and add tests for
several values:  positive, negative, and zero.
* gcc.target/powerpc/sse2-pslld-1.c: Same.
* gcc.target/powerpc/sse2-psllq-1.c: Same.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/emmintrin.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/sse2-pslld-1.c
trunk/gcc/testsuite/gcc.target/powerpc/sse2-psllq-1.c
trunk/gcc/testsuite/gcc.target/powerpc/sse2-psllw-1.c

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

[pthaugen at gcc dot gnu.org]

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

--- Comment #14 from Pat Haugen  ---
Created attachment 43928
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43928=edit
r256888 pcom dump

So the difference appears to be occurring in predictive commoning. In the
ipa-cp clone, resid.constprop, pcom is failing to hoist some loads/expressions
from the vectorized loop. This results in an additional 9 vector loads and 5
vector adds being executed each iteration of the loop.

I've attached a pcom dump of the original resid() and the clone
resid.constprop(). You can see that in the original resid(), pcom is moving
some loads/adds, but not in resid.constprop(). BB 6 is the vectorized loop in
resid(), BB 5 is the same loop in resid.constprop().

Not sure if this is a similar issue to pr55334 wrt losing restrict.

[Bug tree-optimization/85360] FAIL: gfortran.dg/deallocate_stat.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (ICE)

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from John David Anglin  ---
Not seen in next build.  It's probably a OS problem.

[Bug middle-end/85344] Constant constraint check sign extends unsigned constant input operands

[thopre01 at gcc dot gnu.org]

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

--- Comment #5 from Thomas Preud'homme  ---
(In reply to Thomas Preud'homme from comment #4)
> (In reply to Thomas Preud'homme from comment #3)
> > More worrying is that this code compiles without error when it should error
> > out:
> > 
> > void
> > foo (void)
> > {
> >   __asm( "%0" :: "J" ((unsigned char) 0x80));
> > }
> 
> In which case we end up with #-128 in the assembly which is not what the
> user wrote. Thus adding wrong-code tag.

I have difficulty to make up my mind about what is the expected behavior for
constant input in inline asm, esp. for immediate constraint. But first let's
look at register constraint:

asm ("mov %0, %0" : "=r"(result) : "0"((signed char) -128));

will put 0x0080 in the register holding result. It basically set the
register in the mode of the immediate, so QImode here. I would have expected
for a 32bit register to have the immediate as 2-complement 32bit value, ie
0xFF80 in this case. The documentation says that a general register should
be used which is true in both case.

Now what about asm ("%0" :: "i"((unsigned char) 128));

This gives -128 in the assembly code, on at least ARM and x86_64 targets but I
would expect likewise on all targets. Likewise:

asm ("%0" :: "i"(0x8000));

gives #-2147483648 in assembly for the similar reason. Here my expectation is
that provided that the constant can be represented in a const_int its value as
a C level constant is what should be printed in assembly and the constraint
check (eg for constraint I in ARM backend) should be based on that value as
well.

Thoughts?

[Bug target/85397] -mcet -fcf-protection doesn't work with label in nested function

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
Please take a look at hjl/cet/master branch at

https://github.com/hjl-tools/gcc/tree/hjl/cet/master

I replaced builtin_setjmp_setup and builtin_longjmp with save_stack_nonlocal
and restore_stack_nonlocal to save and restore shadow stack to support both
builtin setjmp/longjmp as well as non-local goto in nested functions.

[Bug rtl-optimization/79916] ICE in Max. number of generated reload insns per insn is achieved (90)

[vmakarov at gcc dot gnu.org]

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

--- Comment #10 from Vladimir Makarov  ---
Author: vmakarov
Date: Fri Apr 13 22:55:16 2018
New Revision: 259379

URL: https://gcc.gnu.org/viewcvs?rev=259379=gcc=rev
Log:
2018-04-13  Vladimir Makarov  

PR rtl-optimization/79916
* config/rs6000/rs6000.c (rs6000_emit_move): Use assigned hard
regs (if any) to define how to gnerate SD moves when LRA is in
progress.

2018-04-13  Vladimir Makarov  

PR rtl-optimization/79916
* gcc.target/powerpc/pr79916.c: New.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr79916.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/testsuite/ChangeLog

[Bug c/85365] -Wrestrict false positives with -fsanitize=undefined

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
void
foo (char *p, char *q)
{
  __builtin_strcpy (p, q);
  __builtin_strcat (p, q + 32);
}

warns too and there is no check that could be removable (with extra specialized
code to detect stuff like this; note, we intentionally for sanitizers use
-fno-delete-null-exceptions etc. so that the checks aren't all removed).  There
is redundancy (p checked twice), that is something sanopt pass handles, but it
runs late.
What we could do is defer all or almost all UBSAN sanitizations in form of ifns
until sanopt time, so jump threading wouldn't affect it and only sanopt would
lower it into comparison and the cold diagnostics.  Or improve jump threading
so that it doesn't try to thread these checks with cold calls in it.  Or don't
warn on non-sensical dead code that is going to be optimized away immediately
(on these testcases, gimple_fold sees (dead) strcpy (0, 0), -Wrestrict warns on
it and it is immediately turned into a GIMPLE_NOP.

[Bug middle-end/81657] [8 Regression] FAIL: gcc.dg/20050503-1.c scan-assembler-not call

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug sanitizer/85230] asan: false positives in kernel on allocas

[dvyukov at google dot com]

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

--- Comment #21 from Dmitry Vyukov  ---
I guess it just used my system binutils. Used to work before.
I now used an older distribution to build it. Seems to work.

[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE

[jakub at gcc dot gnu.org]

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

--- Comment #23 from Jakub Jelinek  ---
We aim to do GCC 8 rc1 in the middle of next week, I'm afraid if powerpcspe is
still in this sorry state by then, then it is better to remove it and re-add
when/if it is in better shape.  Or at least declare it deprecated, to be
removed in next release.

[Bug sanitizer/85389] New: posix_memalign() crash with address sanitizer when passing invalid arguments

[gabriel.ganne at mindmaze dot ch]

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

Bug ID: 85389
   Summary: posix_memalign() crash with address sanitizer when
passing invalid arguments
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabriel.ganne at mindmaze dot ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Created attachment 43924
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43924=edit
posix_memalign() test

Hi,

exact gcc version is : gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516

The attached file tests posix_memalign() with an invalid alignment of 1.
The expected behavior is for posix_memalign() to return EINVAL and to leave
memptr untouched, or to set it to NULL.

This works as expected *without* address sanitizer, but fails when enabled :

$ gcc  posix-memalign.c ;  ./a.out
rv = 22
ptr = 0x

$ gcc -fsanitize=address posix-memalign.c && ./a.out
ASAN:DEADLYSIGNAL
=
==2682==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc
0x7f16dbe25fb3 bp 0x sp 0x7ffc4a3c0150 T0)
#0 0x7f16dbe25fb2  (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x23fb2)
#1 0x7f16dbec473d in posix_memalign
(/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc273d)
#2 0x5625796e7bd5 in main (/tmp/posix_memalign/a.out+0xbd5)
#3 0x7f16dba832e0 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
#4 0x5625796e7aa9 in _start (/tmp/posix_memalign/a.out+0xaa9)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV
(/usr/lib/x86_64-linux-gnu/libasan.so.3+0x23fb2)
==2682==ABORTING

[Bug c/51628] __attribute__((packed)) is unsafe in some cases

[dingcurie at icloud dot com]

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

--- Comment #51 from W.H. Ding  ---
(In reply to Sven from comment #49)

> This doesn't work. The aligned attribute is for providing additional
> alignment hints. The GCC documentation clearly states, that aligned can
> increase the alignment. So g_d is still 4 byte aligned, and correctly so.

It's really confusing about using 'aligned' attributes in various situations.

Under the title "Specifying Attributes of Variables", the doc says "When used
as part of a typedef, the aligned attribute can both increase and decrease
alignment" without an example. While under the title "Specifying Attributes of
Types", the doc gives an example of typedef but states at the end "The aligned
attribute can only increase alignment."

So perhaps, my test case should have been:

typedef int unaligned_int __attribute__((aligned(1)));

char g_c = 'x';
unaligned_int g_d = 13;

int main(void)
{
g_c = 'z';
//
g_d = 33;// Crash on, in my case, ARM Cortex-M0
//
return 0;
}

But the result is the same. After all, the 'aligned' attribute took effect in
either case since g_d is at an odd address as a consequence.

[Bug fortran/85387] [8 Regression] incorrect output with optimization /= 0

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
  Known to work||7.3.0
   Keywords||wrong-code
   Last reconfirmed||2018-04-13
 CC||tkoenig at gcc dot gnu.org
   Host|x86_64-pc-linux-gnu |
 Ever confirmed|0   |1
Summary|incorrect output with   |[8 Regression] incorrect
   |optimization /= 0   |output with optimization /=
   ||0
   Target Milestone|--- |8.0
  Known to fail||8.0.1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed. The code works as expected ig compiled with -fno-frontend-optimize.

The change appeared between revisions r248853 (2017-06-03, OK) and r249632
(2017-06-25, wrong), likely r248877 (pr35339) or its sequel r249092 (pr80988).

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

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #84 from Rainer Orth  ---
Last patch posted and installed for GCC 8:

https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00654.html

No more remaining failures, so closing.

Thanks for all your help investigating this.

  Rainer

[Bug tree-optimization/85390] New: possible missed optimisation / regression from 6.3 with conditional expression

[vegard.nossum at oracle dot com]

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

Bug ID: 85390
   Summary: possible missed optimisation / regression from 6.3
with conditional expression
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vegard.nossum at oracle dot com
  Target Milestone: ---

Input:

extern int a, b, c;

int f(int x)
{
__builtin_prefetch((void *) (x ? a : b));
return c;
}

Current trunk with -O3 produces this:

f(int):
  testl %edi, %edi
  je .L2
  movslq a(%rip), %rax
  prefetcht0 (%rax)
  movl c(%rip), %eax
  ret
.L2:
  movslq b(%rip), %rax
  prefetcht0 (%rax)
  movl c(%rip), %eax
  ret

While 6.3.0 did not have a branch:

f(int):
  movslq a(%rip), %rdx
  movslq b(%rip), %rax
  testl %edi, %edi
  cmovne %rdx, %rax
  prefetcht0 (%rax)
  movl c(%rip), %eax
  ret

For reference, clang also outputs a branchless (but slightly longer) version:

f(int): # @f(int)
  testl %edi, %edi
  movl $a, %eax
  movl $b, %ecx
  cmovneq %rax, %rcx
  movslq (%rcx), %rax
  prefetcht0 (%rax)
  movl c(%rip), %eax
  retq

In my tests, the 6.3.0 code is equally fast in the x == 0 and x != 0 cases,
whereas trunk/8.0.1 is only half as fast as 6.3.0 in the x == 0 (branch taken)
case. In the branch not taken case, the 8.0.1 code has the same speed as the
6.3.0 code.

[Bug middle-end/81657] [8 Regression] FAIL: gcc.dg/20050503-1.c scan-assembler-not call

[jakub at gcc dot gnu.org]

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

--- Comment #22 from Jakub Jelinek  ---
Author: jakub
Date: Fri Apr 13 08:35:32 2018
New Revision: 259366

URL: https://gcc.gnu.org/viewcvs?rev=259366=gcc=rev
Log:
PR middle-end/81657
* expr.h (enum block_op_methods): Add BLOCK_OP_NO_LIBCALL_RET.
* expr.c (emit_block_move_hints): Handle BLOCK_OP_NO_LIBCALL_RET.
* builtins.c (expand_builtin_memory_copy_args): Use
BLOCK_OP_NO_LIBCALL_RET method for mempcpy with non-ignored target,
handle dest_addr == pc_rtx.

* gcc.dg/string-opt-1.c: Remove bogus comment.  Expect a mempcpy
call.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/expr.c
trunk/gcc/expr.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/string-opt-1.c

[Bug lto/85391] New: [8 Regression] ICE in add_type_duplicate, at ipa-devirt.c:1887

[marxin at gcc dot gnu.org]

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

Bug ID: 85391
   Summary: [8 Regression] ICE in add_type_duplicate, at
ipa-devirt.c:1887
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

Happens during build of libreoffice:

$ lto1: internal compiler error: in add_type_duplicate, at ipa-devirt.c:1887
0xaccb4b add_type_duplicate
../../gcc/ipa-devirt.c:1887
0xacd11b get_odr_type(tree_node*, bool)
../../gcc/ipa-devirt.c:2040
0xac6994 odr_subtypes_equivalent_p
../../gcc/ipa-devirt.c:695
0xac9c2f odr_types_equivalent_p
../../gcc/ipa-devirt.c:1385
0xac6b5a odr_subtypes_equivalent_p
../../gcc/ipa-devirt.c:716
0xacac6d odr_types_equivalent_p
../../gcc/ipa-devirt.c:1563
0xacc85b add_type_duplicate
../../gcc/ipa-devirt.c:1860
0xacd11b get_odr_type(tree_node*, bool)
../../gcc/ipa-devirt.c:2040
0xac69b0 odr_subtypes_equivalent_p
../../gcc/ipa-devirt.c:696
0xacac6d odr_types_equivalent_p
../../gcc/ipa-devirt.c:1563
0xacc85b add_type_duplicate
../../gcc/ipa-devirt.c:1860
0xacd11b get_odr_type(tree_node*, bool)
../../gcc/ipa-devirt.c:2040
0xac69b0 odr_subtypes_equivalent_p
../../gcc/ipa-devirt.c:696
0xacac6d odr_types_equivalent_p
../../gcc/ipa-devirt.c:1563
0xacc85b add_type_duplicate
../../gcc/ipa-devirt.c:1860
0xacd11b get_odr_type(tree_node*, bool)
../../gcc/ipa-devirt.c:2040
0xac69b0 odr_subtypes_equivalent_p
../../gcc/ipa-devirt.c:696
0xacac6d odr_types_equivalent_p
../../gcc/ipa-devirt.c:1563
0xacc85b add_type_duplicate
../../gcc/ipa-devirt.c:1860
0xacd11b get_odr_type(tree_node*, bool)
../../gcc/ipa-devirt.c:2040
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[2]: *** [/tmp/ccKp93tD.mk:74: /tmp/cczeeOnm.ltrans24.ltrans.o] Error 1

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

[ro at gcc dot gnu.org]

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

--- Comment #83 from Rainer Orth  ---
Author: ro
Date: Fri Apr 13 08:02:15 2018
New Revision: 259364

URL: https://gcc.gnu.org/viewcvs?rev=259364=gcc=rev
Log:
Fix gcc.dg/debug/pr41893-1.c with Solaris ld (PR lto/81968)

PR lto/81968
* simple-object.c (handle_lto_debug_sections): Keep .comment
section.

Modified:
trunk/libiberty/ChangeLog
trunk/libiberty/simple-object.c

[Bug c++/85363] Throwing exception from member constructor (brace initializer vs initializer list)

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
That implemented the rule that aggregates can't have NSDMIs.

It started working in C++14 mode with r216750, which implements the C++14 rule
that aggregates _can_ have NSDMIs.

So the problem seems to be when it's an aggregate.

[Bug tree-optimization/83991] [8 regression] gcc.dg/vect/pr79347.c fail

[hubicka at gcc dot gnu.org]

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

--- Comment #9 from Jan Hubicka  ---
Author: hubicka
Date: Fri Apr 13 08:59:05 2018
New Revision: 259368

URL: https://gcc.gnu.org/viewcvs?rev=259368=gcc=rev
Log:
PR tree-optimization/82965
PR tree-optimization/83991
* cfgloopanal.c (expected_loop_iterations_unbounded): Add
by_profile_only parameter.
* cfgloopmanip.c (scale_loop_profile): Further scale loop's profile
information if the loop was predicted to iterate too many times.
* cfgloop.h (expected_loop_iterations_unbounded): Update prototype

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgloop.h
trunk/gcc/cfgloopanal.c
trunk/gcc/cfgloopmanip.c

[Bug tree-optimization/82965] [8 regression] gcc.dg/vect/pr79347.c starts failing after r254379

[hubicka at gcc dot gnu.org]

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

--- Comment #15 from Jan Hubicka  ---
Author: hubicka
Date: Fri Apr 13 08:59:05 2018
New Revision: 259368

URL: https://gcc.gnu.org/viewcvs?rev=259368=gcc=rev
Log:
PR tree-optimization/82965
PR tree-optimization/83991
* cfgloopanal.c (expected_loop_iterations_unbounded): Add
by_profile_only parameter.
* cfgloopmanip.c (scale_loop_profile): Further scale loop's profile
information if the loop was predicted to iterate too many times.
* cfgloop.h (expected_loop_iterations_unbounded): Update prototype

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgloop.h
trunk/gcc/cfgloopanal.c
trunk/gcc/cfgloopmanip.c

[Bug lto/85391] [8 Regression] ICE in add_type_duplicate, at ipa-devirt.c:1887

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2018-4-13
Version|unknown |8.0.1
   Target Milestone|--- |8.0

[Bug libgcc/85388] config/i386/morestack.S is incompatible with CET

[igor.v.tsimbalist at intel dot com]

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

--- Comment #2 from igor.v.tsimbalist at intel dot com ---
You are fixing 64bit part. There is similar place for 32bit

 movl-8(%ebp),%eax   # Restore the last register.

 call*-12(%ebp)  # Call our caller!

What do we call here? Is it returning back to a function that causes more stack
allocation? Is it possible for the compiler to insert ENDBR there based on some
knowledge of morestack was called?

[Bug lto/85391] [8 Regression] ICE in add_type_duplicate, at ipa-devirt.c:1887

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Ok so I have 6 pre-processed source files having in total ~40MB. Hope I can
reduce that.

[Bug target/81685] FAIL: g++.dg/debug/dwarf2/inline-ns-2.C -std=gnu++* (internal compiler error) on darwin

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
*** Bug 85392 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/85393] [8 Regression] Miscompilation with hot/cold partitioning starting with r254832

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 43925
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43925=edit
gcc8-pr85393-test.patch

Testcase in patch form.

[Bug rtl-optimization/83852] [6/7/8 Regression] ICE in sel_redirect_edge_and_branch, at sel-sched-ir.c:5644 on 32-bit BE powerpc targets

[abel at gcc dot gnu.org]

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

--- Comment #3 from Andrey Belevantsev  ---
Author: abel
Date: Fri Apr 13 10:24:02 2018
New Revision: 259373

URL: https://gcc.gnu.org/viewcvs?rev=259373=gcc=rev
Log:
PR rtl-optimization/83852
* gcc.dg/pr83852.c: New testcase.


Added:
trunk/gcc/testsuite/gcc.dg/pr83852.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/85389] posix_memalign() crash with address sanitizer when passing invalid arguments

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Confirmed. Note that with GCC 8 there's more verbose assert:

gcc pr85329.c -fsanitize=address && ./a.out
==6101==AddressSanitizer's allocator is terminating the process instead of
returning 0
==6101==If you don't like this behavior set allocator_may_return_null=1
==6101==AddressSanitizer CHECK failed:
../../../../libsanitizer/sanitizer_common/sanitizer_allocator.cc:216 "((0)) !=
(0)" (0x0, 0x0)
#0 0x76f061a9 in AsanCheckFailed
../../../../libsanitizer/asan/asan_rtl.cc:67
#1 0x76f212ed in __sanitizer::CheckFailed(char const*, int, char
const*, unsigned long long, unsigned long long)
../../../../libsanitizer/sanitizer_common/sanitizer_termination.cc:77
#2 0x76f0b50a in __sanitizer::ReportAllocatorCannotReturnNull()
../../../../libsanitizer/sanitizer_common/sanitizer_allocator.cc:216
#3 0x76f0b557 in __sanitizer::ReturnNullOrDieOnFailure::OnBadRequest()
../../../../libsanitizer/sanitizer_common/sanitizer_allocator.cc:232
#4 0x76e38d5e in __asan::asan_posix_memalign(void**, unsigned long,
unsigned long, __sanitizer::BufferedStackTrace*)
../../../../libsanitizer/asan/asan_allocator.cc:863
#5 0x76efc078 in __interceptor_posix_memalign
../../../../libsanitizer/asan/asan_malloc_linux.cc:157
#6 0x40086b in main (/home/marxin/Programming/testcases/a.out+0x40086b)
#7 0x76a72a86 in __libc_start_main (/lib64/libc.so.6+0x21a86)
#8 0x400799 in _start (/home/marxin/Programming/testcases/a.out+0x400799)

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

[abel at gcc dot gnu.org]

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

Andrey Belevantsev  changed:

   What|Removed |Added

 CC||abel at gcc dot gnu.org

--- Comment #1 from Andrey Belevantsev  ---
I can't reproduce it even with the same revision and rs6000.c:unavailable_cpu
set to 0 (to allow me choose power8).  Is there anything else I can do?

[Bug rtl-optimization/85393] [8 Regression] Miscompilation with hot/cold partitioning starting with r254832

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-13
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

[Bug target/71991] Inconsistency for __attribute__ ((__always_inline__)) among LTO and non-LTO compilation

[hubicka at gcc dot gnu.org]

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

--- Comment #12 from Jan Hubicka  ---
Author: hubicka
Date: Fri Apr 13 08:51:47 2018
New Revision: 259367

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

PR lto/71991
* config/i386/i386.c (ix86_can_inline_p): Allow safe transitions for
always inline.
* gcc.target/i386/pr71991.c: New testcase.

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

[Bug tree-optimization/82965] [8 regression] gcc.dg/vect/pr79347.c starts failing after r254379

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #16 from Jan Hubicka  ---
Fixed.

[Bug testsuite/85326] `make check` fails with `--disable-bootstrap` and `--enable-languages=c`

[krebbel at gcc dot gnu.org]

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

--- Comment #4 from Andreas Krebbel  ---
Author: krebbel
Date: Fri Apr 13 09:14:32 2018
New Revision: 259369

URL: https://gcc.gnu.org/viewcvs?rev=259369=gcc=rev
Log:
IBM Z: Get rid of target specific C++ testcase

gcc/testsuite/ChangeLog:

2018-04-13  Andreas Krebbel  

PR testsuite/85326
* gcc.target/s390/pr77822-1.C: Rename to ...
* gcc.target/s390/pr77822-1.c: ... this. Add asm scan check.
* gcc.target/s390/pr77822-2.c: Add asm scan check.
* gcc.target/s390/s390.exp: Remove C from testcase regexps.


Added:
trunk/gcc/testsuite/gcc.target/s390/pr77822-1.c
Removed:
trunk/gcc/testsuite/gcc.target/s390/pr77822-1.C
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/s390/pr77822-2.c
trunk/gcc/testsuite/gcc.target/s390/s390.exp

[Bug lto/85391] [8 Regression] ICE in add_type_duplicate, at ipa-devirt.c:1887

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #3 from Martin Liška  ---
Started with r258481.

[Bug c++/84733] [8 Regression] internal compiler error: Segmentation fault (check_local_shadow())

[nathan at gcc dot gnu.org]

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

--- Comment #8 from Nathan Sidwell  ---
I think assert (error_count || binding->type == decl) would be better.

[Bug lto/85391] [8 Regression] ICE in add_type_duplicate, at ipa-devirt.c:1887

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
With following debug patch:

diff --git a/gcc/ipa-devirt.c b/gcc/ipa-devirt.c
index fa9380cce80..7d14a923b4d 100644
--- a/gcc/ipa-devirt.c
+++ b/gcc/ipa-devirt.c
@@ -1869,7 +1869,7 @@ add_type_duplicate (odr_type val, tree type)
 }
   gcc_assert (val->odr_violated || !odr_must_violate);
   /* Sanity check that all bases will be build same way again.  */
-  if (flag_checking
+  if (true//flag_checking
   && COMPLETE_TYPE_P (type) && COMPLETE_TYPE_P (val->type)
   && TREE_CODE (val->type) == RECORD_TYPE
   && TREE_CODE (type) == RECORD_TYPE
@@ -1884,7 +1884,23 @@ add_type_duplicate (odr_type val, tree type)
if (polymorphic_type_binfo_p (BINFO_BASE_BINFO
 (TYPE_BINFO (type), i)))
  num_poly_bases++;
+
+  if (num_poly_bases != val->bases.length ())
+  {
+   fprintf(stderr, "poly bases: %d\n", num_poly_bases);
+   for (i = 0; i < BINFO_N_BASE_BINFOS (TYPE_BINFO (type)); i++)
+ if (polymorphic_type_binfo_p (BINFO_BASE_BINFO
+  (TYPE_BINFO (type), i)))
+   debug_tree(BINFO_BASE_BINFO (TYPE_BINFO (type), i));
+   fprintf(stderr, "val bases: %d\n", val->bases.length ());
+
+   for (unsigned i = 0; i < val->bases.length (); i++)
+   debug_tree(val->bases[i]->type);
+  }
+
+
   gcc_assert (num_poly_bases == val->bases.length ());
+
   for (j = 0, i = 0; i < BINFO_N_BASE_BINFOS (TYPE_BINFO (type));
   i++)
if (polymorphic_type_binfo_p (BINFO_BASE_BINFO

I see:

poly bases: 2
 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x75871690
attributes 
value 
readonly constant static "default\000">>>
fields 
ignored BLK
/home/marxin/BIG/Programming/libreoffice/include/sfx2/viewsh.hxx:145:22
size 
unit-size 
align:64 warn_if_not_align:0 offset_align 128
offset 
bit-offset  context
 chain > context 
chain >
bases:4 offset >
 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x756fb5e8
fields 
unsigned virtual DI
/home/marxin/BIG/Programming/libreoffice/sc/source/ui/inc/dbfunc.hxx:39:0
size 
unit-size 
align:64 warn_if_not_align:0 offset_align 128
offset 
bit-offset  context
 chain > context 
chain >
bases:1 offset >
val bases: 1
  constant 1344>
unit-size  constant 168>
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x75871690
attributes 
value 
readonly constant static "default\000">>>
fields 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x75d490a8 attributes  fields  context 
chain >
ignored BLK
/home/marxin/BIG/Programming/libreoffice/include/sfx2/viewsh.hxx:145:22 size
 unit-size 
align:64 warn_if_not_align:0 offset_align 128
offset 
bit-offset  context 
chain 
ignored BLK
/home/marxin/BIG/Programming/libreoffice/include/sfx2/viewsh.hxx:145:22
size 
unit-size 
align:64 warn_if_not_align:0 offset_align 128
offset 
bit-offset  context
 chain >> context 
chain >

[Bug rtl-optimization/83852] [6/7/8 Regression] ICE in sel_redirect_edge_and_branch, at sel-sched-ir.c:5644 on 32-bit BE powerpc targets

[abel at gcc dot gnu.org]

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

Andrey Belevantsev  changed:

   What|Removed |Added

 CC||abel at gcc dot gnu.org

--- Comment #2 from Andrey Belevantsev  ---
This is fixed by the patch for PR83962.  I will close this PR after adding the
testcase.

[Bug debug/85392] New: [7/8 Regression] FAIL: gcc.dg/debug/dwarf2/pr82718-[12].c (internal compiler error) on darwin

[dominiq at lps dot ens.fr]

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

Bug ID: 85392
   Summary: [7/8 Regression] FAIL:
gcc.dg/debug/dwarf2/pr82718-[12].c (internal compiler
error) on darwin
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
  Target Milestone: ---
  Host: x86_64-apple-darwin17
Target: x86_64-apple-darwin17
 Build: x86_64-apple-darwin17

The tests gcc.dg/debug/dwarf2/pr82718-[12].c  fail on darwin with

% /opt/gcc/gcc8w/bin/gcc -S -O2 -gdwarf-5
/opt/gcc/_clean/gcc/testsuite/gcc.dg/debug/dwarf2/pr82718-1.c
/opt/gcc/_clean/gcc/testsuite/gcc.dg/debug/dwarf2/pr82718-1.c:41:1: internal
compiler error: in darwin_asm_output_dwarf_offset, at config/darwin.c:2903
 }
 ^

[Bug debug/85392] [7/8 Regression] FAIL: gcc.dg/debug/dwarf2/pr82718-[12].c (internal compiler error) on darwin

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Dominique d'Humieres  ---
It looks like a duplicate of pr81685.

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

[Bug libgcc/61152] Missing GCC Runtime Library Exception in some files that are included in libgcc

[egallager at gcc dot gnu.org]

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

--- Comment #9 from Eric Gallager  ---
There have been a bunch of commits for this bug; is it fixed yet?

[Bug rtl-optimization/85393] New: [8 Regression] Miscompilation with hot/cold partitioning starting with r254832

[jakub at gcc dot gnu.org]

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

Bug ID: 85393
   Summary: [8 Regression] Miscompilation with hot/cold
partitioning starting with r254832
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

test.C:
#include 
#include 

void foo (char const *s);

struct S {
  ~S () noexcept (false) {
throw std::runtime_error ("foo");
  }
};

int
main(int argc, char *argv[])
{
  std::vector > args;
  try
{
  {
S k;
foo ("A");
  }

  if (argv)
throw std::runtime_error ("foo");
  args.push_back ({});
}
  catch (std::runtime_error const& e)
{}
}
test2.C:
void foo (char const *) {}

g++ -g -O2 -o test{,.C,2.C}
segfaults because vector dtor is called with NULL this.  My bisection points to 
r254832, Marek's to r250360 (I've used 7.x STL headers, dunno what has Marek
used).  In any case, the segfault goes away with
-fno-reorder-blocks-and-partition, and the only r254832 vs. r254831 differences
in *.optimized dump I see are branch probabilities, so it must be RTL
optimization related (or target issue).

[Bug fortran/85364] -fopenmp should not put array in program on the stack

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-13
 Ever confirmed|0   |1

--- Comment #5 from Dominique d'Humieres  ---
The test always succeeds for me with

stack size  (kbytes, -s) 65532

[Bug libgcc/85388] config/i386/morestack.S is incompatible with CET

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
(In reply to igor.v.tsimbalist from comment #2)
> You are fixing 64bit part. There is similar place for 32bit
> 
>  movl-8(%ebp),%eax   # Restore the last register.
> 
>  call*-12(%ebp)  # Call our caller!
> 
> What do we call here? Is it returning back to a function that causes more
> stack allocation? Is it possible for the compiler to insert ENDBR there
> based on some knowledge of morestack was called?

Please take a look if we can insert ENDBR in ix86_expand_split_stack_prologue.

[Bug rtl-optimization/85393] [8 Regression] Miscompilation with hot/cold partitioning starting with r254832

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Index 6 (hash value 34; max distance 0)
  (plus:DI (reg/f:DI 20 frame)
(const_int -64 [0xffc0]))

scanning new insn with uid = 160.
deleting insn with uid = 117.
PRE: redundant insn 117 (expression 6) in bb 25, reaching reg is 123
scanning new insn with uid = 161.
deleting insn with uid = 74.
PRE: redundant insn 74 (expression 6) in bb 13, reaching reg is 123
PRE: edge (8,13), copy expression 6
PRE: edge (15,24), copy expression 6
PRE: edge (17,24), copy expression 6
PRE: edge (23,24), copy expression 6

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

[asolokha at gmx dot com]

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

--- Comment #3 from Arseny Solokha  ---
Here's another one:

long long int
xa (long long int ae, int yr)
{
  long long int b3 = ae / (!ae + 2);
  long long int mx = yr + 1.0;
  long long int em = 1 / mx / (yr + 2.0);

  return b3 + em;
}

% powerpc-e300c3-linux-gnu-gcc-8.0.0-alpha20180408 -mcpu=power8 -O2
-fselective-scheduling2 -fno-tree-ter -c xqrerdpm.c
during RTL pass: sched2
xqrerdpm.c: In function 'xa':
xqrerdpm.c:9:1: internal compiler error: in verify_target_availability, at
sel-sched.c:1569
 }
 ^
0xc141e6 verify_target_availability
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180408/work/gcc-8-20180408/gcc/sel-sched.c:1566
0xc141e6 find_best_reg_for_expr
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180408/work/gcc-8-20180408/gcc/sel-sched.c:1679
0xc141e6 fill_vec_av_set
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180408/work/gcc-8-20180408/gcc/sel-sched.c:3797
0xc14960 fill_ready_list
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180408/work/gcc-8-20180408/gcc/sel-sched.c:4027
0xc14960 find_best_expr
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180408/work/gcc-8-20180408/gcc/sel-sched.c:4387
0xc14960 fill_insns
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180408/work/gcc-8-20180408/gcc/sel-sched.c:5544
0xc16d7e schedule_on_fences
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180408/work/gcc-8-20180408/gcc/sel-sched.c:7361
0xc16d7e sel_sched_region_2
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180408/work/gcc-8-20180408/gcc/sel-sched.c:7499
0xc19581 sel_sched_region_1
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180408/work/gcc-8-20180408/gcc/sel-sched.c:7541
0xc19581 sel_sched_region(int)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180408/work/gcc-8-20180408/gcc/sel-sched.c:7642
0xc19c51 run_selective_scheduling()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180408/work/gcc-8-20180408/gcc/sel-sched.c:7718
0xbf0abd rest_of_handle_sched2
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180408/work/gcc-8-20180408/gcc/sched-rgn.c:3729
0xbf0abd execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180408/work/gcc-8-20180408/gcc/sched-rgn.c:3873

gcc ICEs on both w/ -mcpu=power8, power9, and powerpc64le.

[Bug rtl-optimization/85393] [8 Regression] Miscompilation with hot/cold partitioning starting with r254832

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Looking at cprop2 now, before that we have:
(insn 74 73 75 13 (parallel [
(set (reg/f:DI 108)
(plus:DI (reg/f:DI 20 frame)
(const_int -64 [0xffc0])))
(clobber (reg:CC 17 flags))
]) "rh1564790.C":15 222 {*adddi_1}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))

(insn 75 74 76 13 (set (reg:DI 5 di)
(reg/f:DI 108)) "rh1564790.C":15 85 {*movdi_internal}
 (expr_list:REG_DEAD (reg/f:DI 108)
(expr_list:REG_EQUAL (plus:DI (reg/f:DI 20 frame)
(const_int -64 [0xffc0]))
(nil
before the _ZNSt6vectorIS_IcSaIcEESaIS1_EED1Ev call, but cprop2 replaces it
with:
rescanning insn with uid = 62.
LOCAL COPY-PROP: Replacing reg 107 in insn 62 with reg 123
rescanning insn with uid = 75.
LOCAL COPY-PROP: Replacing reg 108 in insn 75 with reg 123
rescanning insn with uid = 118.
LOCAL COPY-PROP: Replacing reg 121 in insn 118 with reg 123
reg 123 isn't set in all paths that reach this basic block though (and, isn't
local copy-prop something supposed to be local anyway?).

[Bug c++/84733] [8 Regression] internal compiler error: Segmentation fault (check_local_shadow())

[paolo.carlini at oracle dot com]

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

--- Comment #9 from Paolo Carlini  ---
Indeed, Nathan, at some point I had that too. Or even seen_error () which we
often use lately in such cases. If nobody objects I'll send a patchlet +
testcase.

[Bug target/85388] Missing ENDBR after __morestack call

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-13
  Component|libgcc  |target
Summary|config/i386/morestack.S is  |Missing ENDBR after
   |incompatible with CET   |__morestack call
 Ever confirmed|0   |1

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

[asolokha at gmx dot com]

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

--- Comment #2 from Arseny Solokha  ---
I still can reproduce it as of r259224.

% powerpc-e300c3-linux-gnu-gcc-8.0.0-alpha20180408 -v   
Using built-in specs.   
COLLECT_GCC=powerpc-e300c3-linux-gnu-gcc-8.0.0-alpha20180408
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/powerpc-e300c3-linux-gnu/8.0.0-alpha20180408/lto-wrapper
Target: powerpc-e300c3-linux-gnu
Configured with:
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180408/work/gcc-8-20180408/configure
--host=x86_64-pc-linux-gnu --target=powerpc-e300c3-linux-gnu
--build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/powerpc-e300c3-linux-gnu/gcc-bin/8.0.0-alpha20180408
--includedir=/usr/lib/gcc/powerpc-e300c3-linux-gnu/8.0.0-alpha20180408/include
--datadir=/usr/share/gcc-data/powerpc-e300c3-linux-gnu/8.0.0-alpha20180408
--mandir=/usr/share/gcc-data/powerpc-e300c3-linux-gnu/8.0.0-alpha20180408/man
--infodir=/usr/share/gcc-data/powerpc-e300c3-linux-gnu/8.0.0-alpha20180408/info
--with-gxx-include-dir=/usr/lib/gcc/powerpc-e300c3-linux-gnu/8.0.0-alpha20180408/include/g++-v8
--with-python-dir=/share/gcc-data/powerpc-e300c3-linux-gnu/8.0.0-alpha20180408/python
--enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror
--with-system-zlib --disable-nls --enable-checking=yes --disable-esp
--enable-libstdcxx-time --enable-poison-system-directories
--with-sysroot=/usr/powerpc-e300c3-linux-gnu --disable-bootstrap
--enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-altivec
--disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp
--disable-libmudflap --disable-libssp --disable-libcilkrts --disable-libmpx
--disable-vtable-verify --disable-libvtv --disable-libquadmath --enable-lto
--with-isl --disable-isl-version-check --disable-libsanitizer
Thread model: posix
gcc version 8.0.0-alpha20180408 20180408 (experimental) (GCC)

[Bug rtl-optimization/85393] [8 Regression] Miscompilation with hot/cold partitioning starting with r254832

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Ah, it is the pre pass already, in the dump it dumps the function with (set
(reg:DI 108) (plus:DI (frame) (const_int -64))) and later on with (set (reg:DI
108) (reg:DI 123)), but the latter is incorrect.

[Bug libgcc/85388] config/i386/morestack.S is incompatible with CET

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
This works:

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 03e5c433574..324e2ec60fc 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -15242,7 +15242,13 @@ ix86_expand_split_stack_prologue (void)
  instruction--we need control flow to continue at the subsequent
  label.  Therefore, we use an unspec.  */
   gcc_assert (crtl->args.pops_args < 65536);
-  emit_insn (gen_split_stack_return (GEN_INT (crtl->args.pops_args)));
+  rtx_insn *ret_insn
+= emit_insn (gen_split_stack_return (GEN_INT (crtl->args.pops_args)));
+  if ((flag_cf_protection & CF_BRANCH) && TARGET_IBT)
+{
+  rtx cet_eb = gen_nop_endbr ();
+  emit_insn_after (cet_eb, ret_insn);
+}

   /* If we are in 64-bit mode and this function uses a static chain,
  we saved %r10 in %rax before calling _morestack.  */

[Bug target/85388] Missing ENDBR after __morestack call

[igor.v.tsimbalist at intel dot com]

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

--- Comment #5 from igor.v.tsimbalist at intel dot com ---
I think it's the right place.

[Bug sanitizer/85394] Unable to run sanitized executables on ppc64le Ubuntu and SLES

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug sanitizer/85394] New: Unable to run sanitized executables on ppc64le Ubuntu and SLES

[segher at gcc dot gnu.org]

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

Bug ID: 85394
   Summary: Unable to run sanitized executables on ppc64le Ubuntu
and SLES
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: segher at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

See external bug
https://github.com/google/sanitizers/issues/933

[Bug sanitizer/85394] [8 Regression] Unable to run sanitized executables on ppc64le Ubuntu and SLES

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-13
Version|unknown |8.0
   Target Milestone|--- |8.0
Summary|Unable to run sanitized |[8 Regression] Unable to
   |executables on ppc64le  |run sanitized executables
   |Ubuntu and SLES |on ppc64le Ubuntu and SLES
 Ever confirmed|0   |1

[Bug sanitizer/85394] Unable to run sanitized executables on ppc64le Ubuntu and SLES

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Fedora too.

[Bug sanitizer/85394] [8 Regression] Unable to run sanitized executables on ppc64le Ubuntu and SLES

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
--- libsanitizer/asan/asan_allocator.h  2017-10-19 13:20:58.926958939 +0200
+++ libsanitizer/asan/asan_allocator.h  2018-04-13 00:24:53.331985820 +0200
@@ -122,7 +122,7 @@ const uptr kAllocatorSpace = ~(uptr)0;
 const uptr kAllocatorSize  =  0x400ULL;  // 4T.
 typedef DefaultSizeClassMap SizeClassMap;
 # elif defined(__powerpc64__)
-const uptr kAllocatorSpace =  0xa00ULL;
+const uptr kAllocatorSpace = ~(uptr)0;
 const uptr kAllocatorSize  =  0x200ULL;  // 2T.
 typedef DefaultSizeClassMap SizeClassMap;
 # elif defined(__aarch64__) && SANITIZER_ANDROID

works, but the performance effects of it are unknown yet.

[Bug fortran/85395] New: [7/8] F03 private clause contained in derived type acquires spurious scope

[c...@mnet-mail.de]

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

Bug ID: 85395
   Summary: [7/8] F03 private clause contained in derived type
acquires spurious scope
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: c...@mnet-mail.de
  Target Milestone: ---

The following valid Fortran2003 sample code fails to compile with gfortran
7.2.0/8.0.1, apparently because the private clause contained in derived
type "base2" obtains a spurious scope and affects the declaration of 
variables in the (subsequently defined) derived type "options":

$ cat scope.f90 
module defs

   implicit none

   private
   public :: base2, options

   abstract interface
  subroutine proc( res,a )
 real(8), dimension(:,:), intent(out) :: res
 real(8), dimension(:,:), intent(in) :: a
  end subroutine proc
   end interface

   type, abstract :: base1
   contains
   end type base1

   type, abstract :: base2
   contains
  ! This private clause acquires spurious scope
  private
   end type base2

   type, abstract, extends(base1) :: options
  procedure(proc), pointer, nopass :: ptr1
  procedure(proc), pointer, nopass :: ptr2
   contains
   end type options

end module defs


module setup

   use defs, only: options

   implicit none

   private
   public :: settings

   type, extends(options) :: settings
   contains
  procedure :: init
   end type settings

contains

   subroutine init(self)
  class(settings) :: self
  ! initialize procedure pointers
  self%ptr1 => null()
  self%ptr2 => null()
   end subroutine init

end module setup

Trying to compile this gives:

$ gfortran8 -c scope.f90 
scope.f90:53:15:

   self%ptr1 => null()
   1
Error: Component ‘ptr1’ at (1) is a PRIVATE component of ‘options’
scope.f90:54:15:

   self%ptr2 => null()
   1
Error: Component ‘ptr2’ at (1) is a PRIVATE component of ‘options’


Presently the only ways to get the above code to compile with gfortran
are by
i)  deleting the aforementioned private clause, or
ii) explicitly declaring the procedure pointers in type options as "public".

The original code compiles fine with pgfortran 17.4 and flang 6.0.
Gfortran version 8.0.1 used is:


Using built-in specs.
COLLECT_GCC=/home/kk/Gcc-8/bin/gfortran8
COLLECT_LTO_WRAPPER=/home/kk/Gcc-8/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-checking
--enable-languages=c,c++,fortran --disable-multilib --enable-multiarch
--enable-shared --enable-threads=posix --program-suffix=8
--with-gmp=/usr/local/lib --with-mpc=/usr/lib --with-mpfr=/usr/lib
--without-included-gettext --with-system-zlib --with-tune=generic
--prefix=/home/kk/GCC-8
Thread model: posix
gcc version 8.0.1 20180409 (experimental) (GCC)

[Bug c/85365] -Wrestrict false positives with -fsanitize=undefined

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
Simply avoiding -Wrestrict for null arguments would be a simple workaround for
this case.  Beyond that and your other suggestions in comment #4, improving
jump threading would be worthwhile not just to avoid interactions with the
sanitizers but in general.

Let me put together a patch with the first change for now and see about the
threader improvements in GCC 9.

[Bug fortran/85395] private clause contained in derived type acquires spurious scope

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-13
Summary|[7/8] F03 private clause|private clause contained in
   |contained in derived type   |derived type acquires
   |acquires spurious scope |spurious scope
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from at least 4.8 up to trunk (8.0).

[Bug fortran/85395] [F03] private clause contained in derived type acquires spurious scope

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

Summary|private clause contained in |[F03] private clause
   |derived type acquires   |contained in derived type
   |spurious scope  |acquires spurious scope

--- Comment #2 from Dominique d'Humieres  ---
Adjust summary.

[Bug rtl-optimization/85393] [8 Regression] Miscompilation with hot/cold partitioning starting with r254832

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Actually, PRE does the right thing; the ~S () call is in bb3 and there is EH
edge from there to bb23, which has another EH predecessor, and PRE inserts the
initialization of pseudo 123 in that bb23.  Then comes bbpart, determines that
one of the EH edges is crossing and duplicates the bb (.gcc_except_table
contains expressions relative to the start of the partition in the current
function, so EH edges need to be non-crossing).  The pseudo 123 initialization
is not duplicated though.  So, likely bbpart bug then.

[Bug rtl-optimization/85393] [8 Regression] Miscompilation with hot/cold partitioning starting with r254832

[jakub at gcc dot gnu.org]

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

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  ---
Ok, it is the fix_up_crossing_landing_pad function that is buggy.
It simply assumes that a landing pad basic block contains only the landing pad
instructions and nothing else; as this testcase proves, it is a wrong
assumption.
Either we could really duplicate the bb, or, IMHO better, instead of partially
duplicating it just emit a label and jump (cross partition) to the existing
landing pad.

[Bug rtl-optimization/85393] [8 Regression] Miscompilation with hot/cold partitioning starting with r254832

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Created attachment 43926
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43926=edit
gcc8-pr85393.patch

Untested fix.

[Bug rtl-optimization/85393] [8 Regression] Miscompilation with hot/cold partitioning starting with r254832

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #5 from Marek Polacek  ---
I used gcc 8 headers when bisecting it.  And commenting out
+ /* Do not expect profile insanities when profile was not adjusted.  */
+ if (e->probability == profile_probability::never ()
+ || e->count == profile_count::zero ())
+   continue;
+
helped.  I saw differences in .bbpart so I thought something went wrong in
hot/cold partitioning.

[Bug rtl-optimization/85393] [8 Regression] Miscompilation with hot/cold partitioning starting with r254832

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug lto/85391] [8 Regression] ICE in add_type_duplicate, at ipa-devirt.c:1887

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  ---
Let's just back out my couple of patches to ipa-devirt.c.  Nobody seems to care
about PR ipa/83983 so I guess I no longer do either.