[Bug libgcc/81199] fallback definition of count_leading_zeros references hidden symbol

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
This actually usually means some shared library has been linked without linking
against -lgcc_s or -lgcc (common reason is e.g. linking with ld -shared instead
of gcc -shared or g++ -shared) and you are trying to link against that shared
library.

[Bug tree-optimization/80928] SLP vectorization does not handle induction in outer loop vectorization

[rguenth at gcc dot gnu.org]

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

--- Comment #25 from Richard Biener  ---
Author: rguenth
Date: Mon Jun 26 07:19:37 2017
New Revision: 249638

URL: https://gcc.gnu.org/viewcvs?rev=249638&root=gcc&view=rev
Log:
2017-06-26  Richard Biener  

PR tree-optimization/80928
* cfghooks.c (duplicate_block): Do not copy BB_DUPLICATED flag.
(copy_bbs): Set BB_DUPLICATED flag early.
(execute_on_growing_pred): Do not execute for BB_DUPLICATED
marked blocks.
(execute_on_shrinking_pred): Likewise.
* tree-ssa.c (ssa_redirect_edge): Do not look for PHI args in
BB_DUPLICATED blocks.
* tree-ssa-phionlycoprop.c (eliminate_degenerate_phis_1): Properly
iterate over all PHIs considering removal of *gsi.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfghooks.c
trunk/gcc/tree-ssa-phionlycprop.c
trunk/gcc/tree-ssa.c

[Bug tree-optimization/79483] [7 Regression] [graphite] ICE: verify_ssa failed (error: definition in block 31 does not dominate use in block 28)

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener  ---
(In reply to David Binderman from comment #14)
> (In reply to Richard Biener from comment #13)
> > Fixed on trunk sofar.
> 
> Odd. Looks broken to me in 20170622. Did the patch go in ?

Your reduced testcase triggers a similar ICE but from a different pass.  I'll
open a new bug for that.

[Bug tree-optimization/81203] New: [8 Regression] tail recursion: internal compiler error: verify_ssa failed

[rguenth at gcc dot gnu.org]

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

Bug ID: 81203
   Summary: [8 Regression] tail recursion: internal compiler
error: verify_ssa failed
   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: rguenth at gcc dot gnu.org
  Target Milestone: ---

a;
b() {
  int c, d;
if (a)
  d = b();
  return 1 + c + d;
}

with -O2 causes

t9.c:7:1: error: definition in block 3 does not dominate use in block 4
 }
 ^
for SSA_NAME: _2 in statement:
_10 = _2 + d_3;
during GIMPLE pass: tailr
t9.c:7:1: internal compiler error: verify_ssa failed
0x11b735a verify_ssa(bool, bool)
/space/rguenther/src/svn/early-lto-debug/gcc/tree-ssa.c:1186
0xddbe23 execute_function_todo
/space/rguenther/src/svn/early-lto-debug/gcc/passes.c:1996
0xddadbd do_per_function
/space/rguenther/src/svn/early-lto-debug/gcc/passes.c:1655
0xddbfc4 execute_todo
/space/rguenther/src/svn/early-lto-debug/gcc/passes.c:2043
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/81203] [8 Regression] tail recursion: internal compiler error: verify_ssa failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-06-26
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

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

[Bug tree-optimization/81203] [8 Regression] tail recursion: internal compiler error: verify_ssa failed

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
I think the proper fix would be a larger rewrite of tree-tailcall to properly
isolate the path from call to return stmt.  This particular PR can be fixed
with sth like the following which lacks handling of dealing with copying
multiple stmts and updating the uses in those.  Path isolation would solve
that issue trivially and we could then even simply re-use the stmts computing
the accumulation ...

Not sth I can handle time-wise at this very moment so I'm going to paper over
this :/

Index: gcc/tree-ssa-loop-niter.c
===
--- gcc/tree-ssa-loop-niter.c   (revision 249638)
+++ gcc/tree-ssa-loop-niter.c   (working copy)
@@ -1792,7 +1792,7 @@ number_of_iterations_cond (struct loop *

 /* Substitute NEW for OLD in EXPR and fold the result.  */

-static tree
+tree
 simplify_replace_tree (tree expr, tree old, tree new_tree)
 {
   unsigned i, n;
Index: gcc/tree-tailcall.c
===
--- gcc/tree-tailcall.c (revision 249638)
+++ gcc/tree-tailcall.c (working copy)
@@ -392,6 +392,9 @@ propagate_through_phis (tree var, edge e
   return var;
 }

+tree
+simplify_replace_tree (tree expr, tree old, tree new_tree);
+
 /* Finds tailcalls falling into basic block BB. The list of found tailcalls is
added to the start of RET.  */

@@ -532,8 +535,8 @@ find_tail_calls (basic_block bb, struct
  since we are running after dce.  */
   m = NULL_TREE;
   a = NULL_TREE;
-  auto_bitmap to_move_defs;
-  auto_vec to_move_stmts;
+  auto_bitmap to_copy_defs;
+  auto_vec to_copy_stmts;

   abb = bb;
   agsi = gsi;
@@ -566,7 +569,7 @@ find_tail_calls (basic_block bb, struct

   /* This is a gimple assign. */
   par ret = process_assignment (as_a  (stmt), gsi,
-   &tmp_m, &tmp_a, &ass_var, to_move_defs);
+   &tmp_m, &tmp_a, &ass_var, to_copy_defs);
   if (ret == FAIL)
return;
   else if (ret == TRY_MOVE)
@@ -576,12 +579,12 @@ find_tail_calls (basic_block bb, struct
  for (unsigned opno = 1; opno < gimple_num_ops (stmt); ++opno)
{
  tree op = gimple_op (stmt, opno);
- if (independent_of_stmt_p (op, stmt, gsi, to_move_defs) != op)
+ if (independent_of_stmt_p (op, stmt, gsi, to_copy_defs) != op)
return;
}
- bitmap_set_bit (to_move_defs,
+ bitmap_set_bit (to_copy_defs,
  SSA_NAME_VERSION (gimple_assign_lhs (stmt)));
- to_move_stmts.safe_push (stmt);
+ to_copy_stmts.safe_push (stmt);
  continue;
}

@@ -628,10 +631,19 @@ find_tail_calls (basic_block bb, struct
   if (tail_recursion)
 {
   unsigned i;
-  FOR_EACH_VEC_ELT (to_move_stmts, i, stmt)
+  FOR_EACH_VEC_ELT (to_copy_stmts, i, stmt)
{
- gimple_stmt_iterator mgsi = gsi_for_stmt (stmt);
- gsi_move_before (&mgsi, &gsi);
+ gimple *copy = gimple_copy (stmt);
+ def_operand_p defp = SINGLE_SSA_DEF_OPERAND (copy, SSA_OP_DEF);
+ tree def = DEF_FROM_PTR (defp);
+ tree new_def = copy_ssa_name (def);
+ SET_DEF (defp, new_def);
+ SSA_NAME_DEF_STMT (new_def) = copy;
+ gsi_insert_before (&gsi, copy, GSI_SAME_STMT);
+ if (m)
+   m = simplify_replace_tree (m, def, new_def);
+ if (a)
+   a = simplify_replace_tree (a, def, new_def);
}
 }

[Bug bootstrap/80779] MPX bootstrap does not work on real hardware supporting that

[aivchenk at gcc dot gnu.org]

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

--- Comment #2 from Alexander Ivchenko  ---
I made some progress a while back with that, mostly by adding
__attribute__((bnd_legacy)) just as in Martin's patches. I don't like that
approach though, as it does not look natural. The two thinks that I found are:

1) There are cases where we have union at the end of the struct, where one
field of the union is a flexible array. I marked those fields of the struct
with corresponding attribute, but, probably, more natural would be to add that
by default when "-fchkp-flexible-struct-trailing-arrays" option is used. We
have a lot of false positives because of that

2) I found a real bounds violation :) In ipa-chkp.c in
chkp_map_attr_arg_indexes  there is a "idx = indexes[idx - 1] + 1;" in the
loop. Here, "idx" may be zero

[Bug tree-optimization/38497] PRE missing a load PRE which causes a loop to have two BBs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed|2010-03-03 10:57:32 |2017-6-26

--- Comment #9 from Richard Biener  ---
I think the issue is we are not able to value-number both loads of *a to the
same value because DoHuffIteration clobbers *a.  So the *a in the block
leading to exit and the *a inserted in the latch do not have the same value.

I don't see how we can fix that easily inside PRE - we'd have to somehow
fix the value-numbering done during PHI translation to catch this case.

Iterating VN/PRE makes the value-numbering part work but hoisting still
fails because we look at ANTIC_IN & ~AVAIL_OUT but *a_6(D) is cleared
from ANTIC_OUT(3) as DoHuffIteration clobbers it.  So we really want
to look at ANTIC_OUT & ~AVAIL_OUT in do_hoist_insertion (ANTIC_IN is
a good approximation but it doesn't work here).  Of course ANTIC_OUT
we'd have to re-compute as we don't retain it.  There's the slight
complication that hoist insertion possibly inserts before the last
stmt though (that makes using ANTIC_IN a "fix" for that stmt possibly
clobbering the value).  Anyway, w/o fixing the value-numbering part
fixing hoisting is pointless of course.

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #55 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #54 from Daniel Santos  ---
> Created attachment 41627
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41627&action=edit
> darwin fixup (on top of v6) -- second attempt
[...]
> The macro has only two uses, so if you prefer, I can remove it and just 
> replace
> it with inline #if blocks, e.g.,
>
> #ifdef __MACH__
> "   mov " ASMNAME(test_data) "@GOTPCREL(%%rip), %%rax\n"
> #else
> "   lea " ASMNAME(test_data) "(%%rip), %%rax\n"
> #endif

I'm fine either way, with a slight preference for the macro version (the
less code duplication, the better ;-)

I've tested this patch last night on both x86_64-apple-darwin11.4.2 and
i386-pc-solaris2.12 and it worked just fine on both!

Thanks a lot.

Rainer

[Bug c++/81204] New: [7/8 Regression] Rejects boost headers

[rguenth at gcc dot gnu.org]

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

Bug ID: 81204
   Summary: [7/8 Regression] Rejects boost headers
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

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

Works with G++6, fails with G++7 with

In file included from
/usr/include/boost/geometry/geometries/helper_geometry.hpp:21:0,
 from
/usr/include/boost/geometry/algorithms/detail/disjoint/point_point.hpp:41,
 from
/usr/include/boost/geometry/algorithms/detail/equals/point_point.hpp:24,
 from
/usr/include/boost/geometry/strategies/cartesian/intersection.hpp:29,
 from
/usr/include/boost/geometry/strategies/intersection_strategies.hpp:28,
 from /usr/include/boost/geometry/strategies/strategies.hpp:37,
 from /usr/include/boost/geometry/geometry.hpp:50,
 from /usr/include/boost/geometry.hpp:17,
 from test.cpp:9:
/usr/include/boost/geometry/geometries/point.hpp: In static member function
‘static void
boost::geometry::traits::access,
Dimension>::set(boost::geometry::model::point&, const CoordinateType&)’:
/usr/include/boost/geometry/geometries/point.hpp:290:33: error: type/value
mismatch at argument 1 in template parameter list for ‘template class std::set’
/usr/include/boost/geometry/geometries/point.hpp:290:33: note:   expected a
type, got ‘Dimension’
/usr/include/boost/geometry/geometries/point.hpp:290:33: error: template
argument 2 is invalid
/usr/include/boost/geometry/geometries/point.hpp:290:33: error: template
argument 3 is invalid
In file included from
/usr/include/boost/geometry/algorithms/detail/normalize.hpp:27:0,
 from
/usr/include/boost/geometry/algorithms/detail/disjoint/point_point.hpp:45,
 from
/usr/include/boost/geometry/algorithms/detail/equals/point_point.hpp:24,
 from
/usr/include/boost/geometry/strategies/cartesian/intersection.hpp:29,
 from
/usr/include/boost/geometry/strategies/intersection_strategies.hpp:28,
 from /usr/include/boost/geometry/strategies/strategies.hpp:37,
 from /usr/include/boost/geometry/geometry.hpp:50,
 from /usr/include/boost/geometry.hpp:17,
 from test.cpp:9:
/usr/include/boost/geometry/views/detail/indexed_point_view.hpp: In static
member function ‘static void
boost::geometry::traits::access, Dimension>::set(boost::geometry::detail::indexed_point_view&, const coordinate_type&)’:
/usr/include/boost/geometry/views/detail/indexed_point_view.hpp:113:33: error:
type/value mismatch at argument 1 in template parameter list for
‘template class std::set’
...

[Bug c++/81204] [7/8 Regression] Rejects boost headers

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||6.3.1
   Target Milestone|--- |7.2
  Known to fail||7.1.1, 8.0

--- Comment #1 from Richard Biener  ---
Original boost testcase:

#include 

#include 

using namespace std;

#include 
#include 

int main()
{
cout << "Hello World!" << endl;
return 0;
}


clang++4 is said to accept the code as well.

[Bug middle-end/81191] `-fsplit-paths` is listed as `-O2`instead of `-O3` flag

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-26
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug tree-optimization/81192] [8 Regression] gcc ICE at -Os on x86_64-linux-gnu: Segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |ASSIGNED
   Keywords||ice-on-valid-code
   Last reconfirmed||2017-06-26
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1
Summary|gcc ICE at -Os on   |[8 Regression] gcc ICE at
   |x86_64-linux-gnu:   |-Os on x86_64-linux-gnu:
   |Segmentation fault  |Segmentation fault
   Target Milestone|--- |8.0

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

[Bug fortran/80164] ICE in gfc_format_decoder at gcc/fortran/error.c:933

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
> I will take this over, test the proposed patch, and see where we get soon.

Great!

I have the patch in my working tree and it fixes the issue (even the ieee ones)
without regression.

[Bug rtl-optimization/81194] [8 Regression] ICE during RTL pass: expand

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Target||x86_64-*-*
 CC||bergner at gcc dot gnu.org
   Target Milestone|--- |8.0
Summary|ICE during RTL pass: expand |[8 Regression] ICE during
   ||RTL pass: expand

--- Comment #2 from Richard Biener  ---
Peter, can you investigate?

[Bug tree-optimization/81192] [8 Regression] gcc ICE at -Os on x86_64-linux-gnu: Segmentation fault

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

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

[Bug libfortran/81195] SPEC CPU2017 621.wrf_s failure with 40+ openmp threads

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||openmp, wrong-code
 Status|WAITING |NEW

[Bug tree-optimization/81196] Number of iterations found for p!=q but not for p

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-26
 CC||amker at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Probably some more elaborate handling in number_of_iterations_cond is required:

  /* We can handle the case when neither of the sides of the comparison is
 invariant, provided that the test is NE_EXPR.  This rarely occurs in
 practice, but it is simple enough to manage.  */
  if (!integer_zerop (iv0->step) && !integer_zerop (iv1->step))
{
  tree step_type = POINTER_TYPE_P (type) ? sizetype : type;
  if (code != NE_EXPR)
return false;

  iv0->step = fold_binary_to_constant (MINUS_EXPR, step_type,
   iv0->step, iv1->step);
  iv0->no_overflow = false;
  iv1->step = build_int_cst (step_type, 0);
  iv1->no_overflow = true;
}

I think this exit is premature and the following works for the testcase.
I suppose exiting is still required but can be moved to a later point,
or the helpers now fully handle the case of non-constant iv1 ...
Vectorization still fails with this due to runtime aliasing so it
probably exposes some wrong-code issue.  CCing Bin who is now most
familiar with the niter code.

Index: gcc/tree-ssa-loop-niter.c
===
--- gcc/tree-ssa-loop-niter.c   (revision 249638)
+++ gcc/tree-ssa-loop-niter.c   (working copy)
@@ -1674,14 +1674,14 @@ number_of_iterations_cond (struct loop *
   if (!integer_zerop (iv0->step) && !integer_zerop (iv1->step))
 {
   tree step_type = POINTER_TYPE_P (type) ? sizetype : type;
-  if (code != NE_EXPR)
-   return false;
-
-  iv0->step = fold_binary_to_constant (MINUS_EXPR, step_type,
-  iv0->step, iv1->step);
-  iv0->no_overflow = false;
-  iv1->step = build_int_cst (step_type, 0);
-  iv1->no_overflow = true;
+  if (code == NE_EXPR)
+   {
+ iv0->step = fold_binary_to_constant (MINUS_EXPR, step_type,
+  iv0->step, iv1->step);
+ iv0->no_overflow = false;
+ iv1->step = build_int_cst (step_type, 0);
+ iv1->no_overflow = true;
+   }
 }

   /* If the result of the comparison is a constant,  the loop is weird.  More

[Bug c/80116] Warn about macros expanding to multiple statements

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Author: mpolacek
Date: Mon Jun 26 10:02:27 2017
New Revision: 249643

URL: https://gcc.gnu.org/viewcvs?rev=249643&root=gcc&view=rev
Log:
PR c/80116
* c-common.h (warn_for_multistatement_macros): Declare.
* c-warn.c: Include "c-family/c-indentation.h".
(warn_for_multistatement_macros): New function.
* c.opt (Wmultistatement-macros): New option.
* c-indentation.c (guard_tinfo_to_string): No longer static.
Change the parameter type to "enum rid".  Handle RID_SWITCH.
* c-indentation.h (guard_tinfo_to_string): Declare.

* c-parser.c (c_parser_if_body): Set the location of the
body of the conditional after parsing all the labels.  Call
warn_for_multistatement_macros.
(c_parser_else_body): Likewise.
(c_parser_switch_statement): Likewise.
(c_parser_while_statement): Likewise.
(c_parser_for_statement): Likewise.
(c_parser_statement): Add a default argument.  Save the location
after labels have been parsed.
(c_parser_c99_block_statement): Likewise.

* parser.c (cp_parser_statement): Add a default argument.  Save the
location of the expression-statement after labels have been parsed.
(cp_parser_implicitly_scoped_statement): Set the location of the
body of the conditional after parsing all the labels.  Call
warn_for_multistatement_macros.
(cp_parser_already_scoped_statement): Likewise.

* doc/invoke.texi: Document -Wmultistatement-macros.

* c-c++-common/Wmultistatement-macros-1.c: New test.
* c-c++-common/Wmultistatement-macros-2.c: New test.
* c-c++-common/Wmultistatement-macros-3.c: New test.
* c-c++-common/Wmultistatement-macros-4.c: New test.
* c-c++-common/Wmultistatement-macros-5.c: New test.
* c-c++-common/Wmultistatement-macros-6.c: New test.
* c-c++-common/Wmultistatement-macros-7.c: New test.
* c-c++-common/Wmultistatement-macros-8.c: New test.
* c-c++-common/Wmultistatement-macros-9.c: New test.
* c-c++-common/Wmultistatement-macros-10.c: New test.
* c-c++-common/Wmultistatement-macros-11.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/Wmultistatement-macros-1.c
trunk/gcc/testsuite/c-c++-common/Wmultistatement-macros-10.c
trunk/gcc/testsuite/c-c++-common/Wmultistatement-macros-11.c
trunk/gcc/testsuite/c-c++-common/Wmultistatement-macros-2.c
trunk/gcc/testsuite/c-c++-common/Wmultistatement-macros-3.c
trunk/gcc/testsuite/c-c++-common/Wmultistatement-macros-4.c
trunk/gcc/testsuite/c-c++-common/Wmultistatement-macros-5.c
trunk/gcc/testsuite/c-c++-common/Wmultistatement-macros-6.c
trunk/gcc/testsuite/c-c++-common/Wmultistatement-macros-7.c
trunk/gcc/testsuite/c-c++-common/Wmultistatement-macros-8.c
trunk/gcc/testsuite/c-c++-common/Wmultistatement-macros-9.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.h
trunk/gcc/c-family/c-indentation.c
trunk/gcc/c-family/c-indentation.h
trunk/gcc/c-family/c-warn.c
trunk/gcc/c-family/c.opt
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-parser.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog

[Bug fortran/81205] New: Hybrid MPI and OpenMp: Blocking code in loops

[pasha.313 at hotmail dot com]

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

Bug ID: 81205
   Summary: Hybrid MPI and OpenMp: Blocking code in loops
   Product: gcc
   Version: 4.4.7
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pasha.313 at hotmail dot com
  Target Milestone: ---

I am developing a CFD code which was paralleled via MPI. I am adding OpenMp to
make it a hybrid parallel code.
I am using Gfortan (GCC version 4.4.7) right now.
The first thing that I noticed is the code blocks when a subroutine ,which has
a loop inside itself with index variable such as I,J for example, is called
from a loop which has the same index variable(counter I,J) of that subroutine.
When I disable OMP command of just those subroutine everything is fine and the
code works well.
Do you have any remedy for it?
I tried to use some update version such as GCC 4.7.2 and even 5.2.1, but the
condition exacerbated as the code block in early stage in comparison with
previous situation even if disabling those OMP commands.
I was wondering if you could kindly offer a solution to fix this problem.
Best regards

[Bug fortran/81205] Hybrid MPI and OpenMp: Blocking code in loops

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-06-26
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I assume I and J are locals, if not you need to add proper OMP annotations. 
Anyway, without a testcase exhibiting the "problem" there's nothing to do.

[Bug c++/81204] [7/8 Regression] Rejects boost headers

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Started with r236221

[Bug tree-optimization/81203] [8 Regression] tail recursion: internal compiler error: verify_ssa failed

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Mon Jun 26 10:33:12 2017
New Revision: 249644

URL: https://gcc.gnu.org/viewcvs?rev=249644&root=gcc&view=rev
Log:
2017-06-26  Richard Biener  

PR tree-optimization/81203
* tree-tailcall.c (find_tail_calls): Do not move stmts into
non-dominating BBs.

* gcc.dg/torture/pr81203.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr81203.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-tailcall.c

[Bug target/81175] [7 Regression] EXC_BAD_ACCESS in ::slpeel_duplicate_current_defs_from_edges(edge, edge, edge, edge) at is-a.h:192

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Mon Jun 26 10:34:49 2017
New Revision: 249645

URL: https://gcc.gnu.org/viewcvs?rev=249645&root=gcc&view=rev
Log:
2017-06-26  Richard Biener  

PR target/81175
* config/i386/i386.c (ix86_init_mmx_sse_builtins):
Use def_builtin_pure for all gather builtins.

* gfortran.dg/pr81175.f: New testcase.

Added:
trunk/gcc/testsuite/gfortran.dg/pr81175.f
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug target/81175] [7 Regression] EXC_BAD_ACCESS in ::slpeel_duplicate_current_defs_from_edges(edge, edge, edge, edge) at is-a.h:192

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Component|tree-optimization   |target
   Target Milestone|--- |7.2
Summary|[7/8 Regression]|[7 Regression]
   |EXC_BAD_ACCESS in   |EXC_BAD_ACCESS in
   |::slpeel_duplicate_current_ |::slpeel_duplicate_current_
   |defs_from_edges(edge, edge, |defs_from_edges(edge, edge,
   |edge, edge) at is-a.h:192   |edge, edge) at is-a.h:192

--- Comment #4 from Richard Biener  ---
Fixed on trunk sofar.

[Bug rtl-optimization/81194] [8 Regression] ICE during RTL pass: expand

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
I don't see g++ options mentioned anywhere, the testcase compiles even with
latest trunk just fine with -O0 -std=c++17 or -O2 -std=c++17.

[Bug tree-optimization/81203] [8 Regression] tail recursion: internal compiler error: verify_ssa failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Fixed.

[Bug middle-end/66313] Unsafe factorization of a*b+a*c

[rguenth at gcc dot gnu.org]

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

Bug 81203 Summary: [8 Regression] tail recursion: internal compiler error: 
verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81203

   What|Removed |Added

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

[Bug tree-optimization/81206] New: missed tail recursion

[rguenth at gcc dot gnu.org]

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

Bug ID: 81206
   Summary: missed tail recursion
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

We do not handle the tail-recursion in gcc.dg/torture/pr81203.c because there's
a stmt in the way (see PR81203).  A proper fix is to re-do tail-recursion
elimination isolating the individual paths to the return I think.

[Bug c/80116] Warn about macros expanding to multiple statements

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
Done for GCC 8.

[Bug tree-optimization/81192] [8 Regression] gcc ICE at -Os on x86_64-linux-gnu: Segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||tom at codesourcery dot com

--- Comment #3 from Richard Biener  ---
Ugh.  Tail-merging does very stupid stuff here, commoning a loop header with an
inner loop latch.

Now it _seems_ to me we run into a pre-existing bug in same_succ_flush_bbs
that 'same' might be NULL.  But it seems to be NULL from the start...

The following fixes it but not tail-mergings stupid (dangerous?) transform
that messes up loops.  Where do we get a chance to "cancel" merging
candidates?  We should cancel any that do not belong to the same loop father.

Index: gcc/tree-ssa-tail-merge.c
===
--- gcc/tree-ssa-tail-merge.c   (revision 249645)
+++ gcc/tree-ssa-tail-merge.c   (working copy)
@@ -810,7 +810,9 @@ same_succ_flush_bb (basic_block bb)
 {
   same_succ *same = BB_SAME_SUCC (bb);
   BB_SAME_SUCC (bb) = NULL;
-  if (bitmap_single_bit_set_p (same->bbs))
+  if (! same)
+;
+  else if (bitmap_single_bit_set_p (same->bbs))
 same_succ_htab->remove_elt_with_hash (same, same->hashval);
   else
 bitmap_clear_bit (same->bbs, bb->index);


Tom?

[Bug tree-optimization/81196] Number of iterations found for p!=q but not for p

[amker at gcc dot gnu.org]

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

--- Comment #2 from amker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> Probably some more elaborate handling in number_of_iterations_cond is
> required:
> 
>   /* We can handle the case when neither of the sides of the comparison is
>  invariant, provided that the test is NE_EXPR.  This rarely occurs in
>  practice, but it is simple enough to manage.  */
>   if (!integer_zerop (iv0->step) && !integer_zerop (iv1->step))
> {
>   tree step_type = POINTER_TYPE_P (type) ? sizetype : type;
>   if (code != NE_EXPR)
> return false;
> 
>   iv0->step = fold_binary_to_constant (MINUS_EXPR, step_type,
>iv0->step, iv1->step);
>   iv0->no_overflow = false;
>   iv1->step = build_int_cst (step_type, 0);
>   iv1->no_overflow = true;
> }
> 
> I think this exit is premature and the following works for the testcase.
> I suppose exiting is still required but can be moved to a later point,
> or the helpers now fully handle the case of non-constant iv1 ...
> Vectorization still fails with this due to runtime aliasing so it
> probably exposes some wrong-code issue.  CCing Bin who is now most
> familiar with the niter code.
> 
> Index: gcc/tree-ssa-loop-niter.c
> ===
> --- gcc/tree-ssa-loop-niter.c   (revision 249638)
> +++ gcc/tree-ssa-loop-niter.c   (working copy)
> @@ -1674,14 +1674,14 @@ number_of_iterations_cond (struct loop *
>if (!integer_zerop (iv0->step) && !integer_zerop (iv1->step))
>  {
>tree step_type = POINTER_TYPE_P (type) ? sizetype : type;
> -  if (code != NE_EXPR)
> -   return false;
> -
> -  iv0->step = fold_binary_to_constant (MINUS_EXPR, step_type,
> -  iv0->step, iv1->step);
> -  iv0->no_overflow = false;
> -  iv1->step = build_int_cst (step_type, 0);
> -  iv1->no_overflow = true;
> +  if (code == NE_EXPR)
> +   {
> + iv0->step = fold_binary_to_constant (MINUS_EXPR, step_type,
> +  iv0->step, iv1->step);
> + iv0->no_overflow = false;
> + iv1->step = build_int_cst (step_type, 0);
> + iv1->no_overflow = true;
> +   }
>  }
>  
>/* If the result of the comparison is a constant,  the loop is weird. 
> More

thanks for ccing, I will study the case.

[Bug c/81207] New: tree check fail in simplify_builtin_call

[dcb314 at hotmail dot com]

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

Bug ID: 81207
   Summary: tree check fail in simplify_builtin_call
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

This code

typedef a;
static *b[] = {"'", ""};
c(d) {
  for (a e = 0; b[0]; e++)
if (strstr(d, b[e]))
  return 1;
}

does this

$ ~/gcc/results/bin/gcc -c -w -O2 bug361.c
during GIMPLE pass: forwprop
bug361.c: In function ‘c’:
bug361.c:3:1: internal compiler error: tree check: expected ssa_name, have
var_decl in simplify_builtin_call, at tree-ssa-forwprop.c:1244
 c(d) {
 ^
0x5793ee tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../trunk/gcc/tree.c:9861
0xda5f8d tree_check(tree_node*, char const*, int, char const*, tree_code)
../../trunk/gcc/tree.h:3083
0xda5f8d simplify_builtin_call
../../trunk/gcc/tree-ssa-forwprop.c:1244
0xda76bc execute
../../trunk/gcc/tree-ssa-forwprop.c:2473
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

This seems to be going wrong since some time before gcc revision 236947.

[Bug c/81207] tree check fail in simplify_builtin_call

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-26
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug middle-end/81207] [7/8 Regression] tree check fail in simplify_builtin_call

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

  Component|c   |middle-end
   Target Milestone|--- |7.2
Summary|tree check fail in  |[7/8 Regression] tree check
   |simplify_builtin_call   |fail in
   ||simplify_builtin_call

[Bug tree-optimization/81196] Number of iterations found for p!=q but not for p

[amker at gcc dot gnu.org]

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

--- Comment #3 from amker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> Probably some more elaborate handling in number_of_iterations_cond is
> required:
> 
>   /* We can handle the case when neither of the sides of the comparison is
>  invariant, provided that the test is NE_EXPR.  This rarely occurs in
>  practice, but it is simple enough to manage.  */
>   if (!integer_zerop (iv0->step) && !integer_zerop (iv1->step))
> {
>   tree step_type = POINTER_TYPE_P (type) ? sizetype : type;
>   if (code != NE_EXPR)
> return false;
> 
>   iv0->step = fold_binary_to_constant (MINUS_EXPR, step_type,
>iv0->step, iv1->step);
>   iv0->no_overflow = false;
>   iv1->step = build_int_cst (step_type, 0);
>   iv1->no_overflow = true;
> }
> 
> I think this exit is premature and the following works for the testcase.
> I suppose exiting is still required but can be moved to a later point,
> or the helpers now fully handle the case of non-constant iv1 ...
> Vectorization still fails with this due to runtime aliasing so it
> probably exposes some wrong-code issue.  CCing Bin who is now most
> familiar with the niter code.
> 
> Index: gcc/tree-ssa-loop-niter.c
> ===
> --- gcc/tree-ssa-loop-niter.c   (revision 249638)
> +++ gcc/tree-ssa-loop-niter.c   (working copy)
> @@ -1674,14 +1674,14 @@ number_of_iterations_cond (struct loop *
>if (!integer_zerop (iv0->step) && !integer_zerop (iv1->step))
>  {
>tree step_type = POINTER_TYPE_P (type) ? sizetype : type;
> -  if (code != NE_EXPR)
> -   return false;
> -
> -  iv0->step = fold_binary_to_constant (MINUS_EXPR, step_type,
> -  iv0->step, iv1->step);
> -  iv0->no_overflow = false;
> -  iv1->step = build_int_cst (step_type, 0);
> -  iv1->no_overflow = true;
> +  if (code == NE_EXPR)
> +   {
> + iv0->step = fold_binary_to_constant (MINUS_EXPR, step_type,
> +  iv0->step, iv1->step);
> + iv0->no_overflow = false;
> + iv1->step = build_int_cst (step_type, 0);
> + iv1->no_overflow = true;
> +   }
No, at least we need to adjust for other code like LT_EXPR/LE_EXPR too. 
Following code can't handle comparison with both sides non-zero ivs.
I guess it only handles NE_EXPR, otherwise it's possible to end up with wrong
result because of wrapping behavior.  Considering below test:

unsigned int i = 0xfff0, j=0xfff8;
for (; i < j; i++, j+=2)
it only iterates for 4 times before j wrapping to 0.  It's not equal to:
unsigned int i = 0xfff0, j=0xfff8;
for (; i < j; i--)

The tricky part is to identify safe cases.  I will try to improve this.

Thanks.

[Bug middle-end/81207] [7/8 Regression] tree check fail in simplify_builtin_call

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Apparently in the IR we have
# VUSE <.MEM>
_13 = __builtin_strchr (_12, 39);

(gdb) p vuse
$1 = 

and SSA_NAME_DEF_STMT crashes on that.

[Bug bootstrap/70173] make distclean: leaves stage_final and libcc1/compiler-name.h

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #9 from Segher Boessenkool  ---
Fixed.

[Bug target/70098] PowerPC64: eigen hits ICE following invalid register assignment

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #15 from Segher Boessenkool  ---
This has been fixed.

[Bug middle-end/81207] [7/8 Regression] tree check fail in simplify_builtin_call

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
I'll have a look.

[Bug target/68690] PowerPC64: TOC save in PHP core loop results in load hit store

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
This now compiles to

main:
.LCF1:
0:  addis 2,12,.TOC.-.LCF1@ha
addi 2,2,.TOC.-.LCF1@l
.localentry main,.-main
addis 9,2,.LC0@toc@ha   # gpr load fusion, type long
ld 9,.LC0@toc@l(9)
addis 10,2,do_nothing@toc@ha
li 3,0
addi 10,10,do_nothing@toc@l
std 10,0(9)
blr

but the problem is still there, just this testcase is defeated; remove
the assignment to fn to make the problem pop up again.

[Bug c++/81204] [7/8 Regression] Rejects boost headers

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-26
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
Reduced:

namespace std {
  template struct set { };
}

using namespace std;

template 
inline void set(Result & res)
{
res.template set();
}

[Bug rtl-optimization/67856] callee-saved register saves should be shrink-wrapped

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

--- Comment #6 from Segher Boessenkool  ---
There now is generic code (in trunk and 7) for -fshrink-wrap-separate;
for this to do anything on x86, someone who understands the i386 backend
will have to write an implementation for the hooks.

[Bug libstdc++/81138] [DR 2983] std::money_put facet does not write '0' before decimal point

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |SUSPENDED
Summary|std::money_put facet does   |[DR 2983] std::money_put
   |not write '0' before|facet does not write '0'
   |decimal point   |before decimal point

--- Comment #3 from Jonathan Wakely  ---
This is now https://wg21.link/lwg2983

[Bug rtl-optimization/67483] combine.c sanitizer detects undefined negative left shift

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #4 from Segher Boessenkool  ---
Fixed.

[Bug fortran/81205] Hybrid MPI and OpenMp: Blocking code in loops

[pasha.313 at hotmail dot com]

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

--- Comment #2 from Pasha  ---
This is my main routine for example
.
.
.
!!$OMP PARALLEL DO DEFAULT(SHARED) PRIVATE(K,jL)
DO k=1,nG3
   DO jL=1,nL2
  j = idx2start + jL
  IF(masque(j,k))THEN

 ! dudx
 CALL fvec (nG1,curC(1:nG1,jL,k), difles1C(1:nG1,jL,k))
 CALL tridgn (ff,s1,w1,difles1C(1:nG1,jL,k), nG1,1)
  ENDIF
   ENDDO
ENDDO
!!$OMP END PARALLEL DO
.
.
.

This is one of those subroutine

SUBROUTINE fvec (n,y,q)
!
!Multiplie le vecteur y par les coefs de la matrice
!passee en common (param6) et le retourne dans q
USE OMP_LIB
IMPLICIT NONE

INTEGER,INTENT(IN) :: n
REAL(prec), DIMENSION(n), INTENT(IN)  :: y
REAL(prec), DIMENSION(n), INTENT(OUT) :: q

INTEGER :: i,nm,nmm
!
nmm=n-2
nm =n-1

q(1) = af0*y(1)+bf0*y(2) +cf0*y(3)  +df0*y(4)  +ef0*y(5)
q(2) = af1*y(3)-af1*y(1)
q(nm)= af1*y(n)-af1*y(nmm)
q(n) =-ag0*y(n)-bg0*y(nm)-cg0*y(nmm)-dg0*y(n-3)-eg0*y(n-4)
!
IF(bf2.EQ.ZERO)THEN
!!$OMP PARALLEL DO DEFAULT(SHARED) PRIVATE(I)
DO i=3,nmm
  q(i)=af2*y(i+1)-af2*y(i-1)
ENDDO
!!$OMP END PARALLEL DO
ELSE
!!$OMP PARALLEL DO DEFAULT(SHARED) PRIVATE(I)
DO i=3,nmm
  q(i)=af2*y(i+1)-af2*y(i-1)+bf2*y(i+2)-bf2*y(i-2)
ENDDO
!!$OMP END PARALLEL DO
ENDIF

  END SUBROUTINE fvec

please be aware that OMP commands works well in other subroutines except those
who has loops and calling from inside a main code.
So for running the program, I disabled all OMP commands in these subroutines
and some part of codes as you can see.

[Bug c++/81147] [avr] C++ for -mmcu=atmega2560 doesn't do NRVO or RVO when class inherits from empty base

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||gjl at gcc dot gnu.org

--- Comment #2 from Georg-Johann Lay  ---
Your testcase doesn't compile:

$ avr-g++ pr81147.cpp
pr81147.cpp:1:20: fatal error: iterator: No such file or directory
 #include 
^
compilation terminated.

[Bug c++/81147] [avr] C++ for -mmcu=atmega2560 doesn't do NRVO or RVO when class inherits from empty base

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Priority|P3  |P5

[Bug fortran/81205] Hybrid MPI and OpenMp: Blocking code in loops

[pasha.313 at hotmail dot com]

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

--- Comment #3 from Pasha  ---
For example, in this case index variables are not the same in both subroutines
but it blocks running.

[Bug libgomp/81177] Dump cubin module to file before offloading in nvptx libgomp plugin

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Tom de Vries  ---
https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01918.html

[Bug rtl-optimization/81194] [8 Regression] ICE during RTL pass: expand

[bergner at gcc dot gnu.org]

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

--- Comment #4 from Peter Bergner  ---
Will do, but as Jakub said, we'll need the compiler options used.

[Bug c/81208] New: 'uninitialized' warning is missed while self initializing

[streletsaa at mail dot ru]

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

Bug ID: 81208
   Summary: 'uninitialized' warning is missed while self
initializing
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: streletsaa at mail dot ru
  Target Milestone: ---

Created attachment 41630
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41630&action=edit
example project that reproduces the bug

The following code does not produce an 'uninitialized' warning in gcc for 'px':

{
int x = 3, *px = &x;
printf("main: %p\n", px);   // suppress 'unused variable px'

do {
int *px = px;// <--- here must be a WARNING
...
} while(0);
}

See the attached project for more details.

gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609

Linux ubuntu 4.4.0-81-generic #104-Ubuntu SMP Wed Jun 14 08:17:06 UTC 2017
x86_64 x86_64 x86_64 GNU/Linux

[Bug sanitizer/81209] New: [7/8 Regression] -fsanitize=undefined ICE on darwin

[dominiq at lps dot ens.fr]

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

Bug ID: 81209
   Summary: [7/8 Regression] -fsanitize=undefined ICE on darwin
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
iains at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at 
gcc dot gnu.org,
marxin at gcc dot gnu.org, ro at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-apple-darwin16
Target: x86_64-apple-darwin16
 Build: x86_64-apple-darwin16

The test is still failing on darwin (r249645):

FAIL: g++.dg/ubsan/pr81125.C   -O0  (internal compiler error)
FAIL: g++.dg/ubsan/pr81125.C   -O0  (test for excess errors)
FAIL: g++.dg/ubsan/pr81125.C   -O1  (internal compiler error)
FAIL: g++.dg/ubsan/pr81125.C   -O1  (test for excess errors)
FAIL: g++.dg/ubsan/pr81125.C   -O2  (internal compiler error)
FAIL: g++.dg/ubsan/pr81125.C   -O2  (test for excess errors)
FAIL: g++.dg/ubsan/pr81125.C   -O2 -flto  (internal compiler error)
FAIL: g++.dg/ubsan/pr81125.C   -O2 -flto  (test for excess errors)
FAIL: g++.dg/ubsan/pr81125.C   -O2 -flto -flto-partition=none  (internal
compiler error)
FAIL: g++.dg/ubsan/pr81125.C   -O2 -flto -flto-partition=none  (test for excess
errors)
FAIL: g++.dg/ubsan/pr81125.C   -O3 -g  (internal compiler error)
FAIL: g++.dg/ubsan/pr81125.C   -O3 -g  (test for excess errors)

With trunk the ICE is

/opt/gcc/_clean/gcc/testsuite/g++.dg/ubsan/pr81125.C:19:14: internal compiler
error: in gimple_add_tmp_var, at gimplify.c:716
   long b = a % c;
~~^~~

With gcc-7 it is

/opt/gcc/_clean/gcc/testsuite/g++.dg/ubsan/pr81125.C:19:14: internal compiler
error: in make_decl_rtl, at varasm.c:1311
   long b = a % c;
~~^~~

[Bug target/81210] New: FAIL: gcc.dg/torture/pr68037-*.c -O* execution test

[dominiq at lps dot ens.fr]

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

Bug ID: 81210
   Summary: FAIL: gcc.dg/torture/pr68037-*.c   -O*  execution test
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: hjl at gnu dot org, iains at gcc dot gnu.org, ro at gcc dot 
gnu.org
  Target Milestone: ---
  Host: x86_64-apple-darwin16
Target: x86_64-apple-darwin16
 Build: x86_64-apple-darwin16

The test gcc.dg/torture/pr68037-*.c fail on darwin (r249645) with a
"Segmentation fault"

FAIL: gcc.dg/torture/pr68037-1.c   -O0  execution test
FAIL: gcc.dg/torture/pr68037-2.c   -O1  execution test
FAIL: gcc.dg/torture/pr68037-2.c   -O2  execution test
FAIL: gcc.dg/torture/pr68037-2.c   -O2 -flto  execution test
FAIL: gcc.dg/torture/pr68037-2.c   -O2 -flto -flto-partition=none  execution
test
FAIL: gcc.dg/torture/pr68037-2.c   -O3 -g  execution test
FAIL: gcc.dg/torture/pr68037-2.c   -Os  execution test
FAIL: gcc.dg/torture/pr68037-3.c   -O1  execution test
FAIL: gcc.dg/torture/pr68037-3.c   -O2  execution test
FAIL: gcc.dg/torture/pr68037-3.c   -O2 -flto  execution test
FAIL: gcc.dg/torture/pr68037-3.c   -O2 -flto -flto-partition=none  execution
test
FAIL: gcc.dg/torture/pr68037-3.c   -O3 -g  execution test
FAIL: gcc.dg/torture/pr68037-3.c   -Os  execution test

[Bug tree-optimization/71815] SLSR misses several PHI candidate cases

[wschmidt at gcc dot gnu.org]

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

--- Comment #11 from Bill Schmidt  ---
Author: wschmidt
Date: Mon Jun 26 14:19:33 2017
New Revision: 249649

URL: https://gcc.gnu.org/viewcvs?rev=249649&root=gcc&view=rev
Log:
[gcc]

2016-06-26  Bill Schmidt  

PR tree-optimization/71815
* gimple-ssa-strength-reduction.c (uses_consumed_by_stmt): New
function.
(find_basis_for_candidate): Call uses_consumed_by_stmt rather than
has_single_use.
(slsr_process_phi): Likewise.
(replace_uncond_cands_and_profitable_phis): Don't replace a
multiply candidate with a stride of 1 (copy or cast).
(phi_incr_cost): Call uses_consumed_by_stmt rather than
has_single_use.
(lowest_cost_path): Likewise.
(total_savings): Likewise.

[gcc/testsuite]

2016-06-26  Bill Schmidt  

PR tree-optimization/71815
* gcc.dg/tree-ssa/slsr-35.c: Remove -fno-code-hoisting workaround.
* gcc.dg/tree-ssa/slsr-36.c: Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog

[Bug target/68037] x86 interrupt attribute doesn't work with DRAP

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
Some tests are failing on darwin: see pr81210.

[Bug tree-optimization/71815] SLSR misses several PHI candidate cases

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #12 from Bill Schmidt  ---
Fixed.  Actual fix revision is 249648 (forgot the PR line).

[Bug tree-optimization/81196] Number of iterations found for p!=q but not for p

[amker at gcc dot gnu.org]

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

--- Comment #4 from amker at gcc dot gnu.org ---
Hmm, the function can only be vectorized with "-march=skylake"?  So what
requirement is needed to add a test case for this?

Thanks.

[Bug testsuite/81058] FAIL: gcc.target/i386/avx512bw-vpmovu?swb-1.c scan-assembler-times vpmovu?swb.*

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-26
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Any chance to have these failures fixed in a near future?

[Bug target/81210] FAIL: gcc.dg/torture/pr68037-*.c -O* execution test

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-06-26
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
Is this a regression?

[Bug c++/81211] New: Unhelpful error messages using template instance with non-copyable type argument

[srk31 at srcf dot ucam.org]

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

Bug ID: 81211
   Summary: Unhelpful error messages using template instance with
non-copyable type argument
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: srk31 at srcf dot ucam.org
  Target Milestone: ---

Created attachment 41631
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41631&action=edit
Small test case

The following code (also attached) fails to compile, and experiments show that
the fix is to make T copy-constructible or move-constructible.

The bug is that the error messages are worse than useless, because they are
about constructing a std::function rather than a T.

(It may also be a bug in libstdc++ that std::function should require this of
its argument type, although that's not completely bonkers.)

#include 
struct T
{
T() {}
// uncomment one of the  below to make the code compile
//T(const T&) {}
//T(T&& t) {}
T& operator=(const T& arg) { return *this; }
T& operator=(T&& arg) { return *this; }
};
int main(int argc, char **argv)
{
std::function f([](T x) -> bool {
return false;
});
return 0;
}


gcc 4.9 (Debian 4.9.2-10) says:

test.cc: In function ‘int main(int, char**)’:
test.cc:15:3: error: no matching function for call to
‘std::function::function(main(int, char**)::)’
  });
   ^
test.cc:15:3: note: candidates are:
In file included from test.cc:1:0:
/usr/include/c++/4.9/functional:2226:2: note: template
std::function<_Res(_ArgTypes ...)>::function(_Functor)
  function(_Functor);
  ^
/usr/include/c++/4.9/functional:2226:2: note:   template argument
deduction/substitution failed:
/usr/include/c++/4.9/functional:2201:7: note: std::function<_Res(_ArgTypes
...)>::function(std::function<_Res(_ArgTypes ...)>&&) [with _Res = bool;
_ArgTypes = {T}]
   function(function&& __x) : _Function_base()
   ^
/usr/include/c++/4.9/functional:2201:7: note:   no known conversion for
argument 1 from ‘main(int, char**)::’ to ‘std::function&&’
/usr/include/c++/4.9/functional:2404:5: note: std::function<_Res(_ArgTypes
...)>::function(const std::function<_Res(_ArgTypes ...)>&) [with _Res = bool;
_ArgTypes = {T}]
 function<_Res(_ArgTypes...)>::
 ^
/usr/include/c++/4.9/functional:2404:5: note:   no known conversion for
argument 1 from ‘main(int, char**)::’ to ‘const
std::function&’
/usr/include/c++/4.9/functional:2181:7: note: std::function<_Res(_ArgTypes
...)>::function(std::nullptr_t) [with _Res = bool; _ArgTypes = {T};
std::nullptr_t = std::nullptr_t]
   function(nullptr_t) noexcept
   ^
/usr/include/c++/4.9/functional:2181:7: note:   no known conversion for
argument 1 from ‘main(int, char**)::’ to ‘std::nullptr_t’
/usr/include/c++/4.9/functional:2174:7: note: std::function<_Res(_ArgTypes
...)>::function() [with _Res = bool; _ArgTypes = {T}]
   function() noexcept
   ^
/usr/include/c++/4.9/functional:2174:7: note:   candidate expects 0 arguments,
1 provided


Meanwhile, g++ 6 (Debian 6.3.0-18) says basically the same thing.

Naively at least, I'd expect the error trace to reveal something about trying
to copy a T, presumably in some non-viable constructor of std::function.

[Bug libstdc++/70472] is_copy_constructible>>::value is true

[safinaskar at mail dot ru]

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

--- Comment #8 from Askar Safin  ---
Recently I noticed this bug can be easily fixed simply by manually implementing
is_copy_constructible. So, please, apply the fix. And same for other type
traits (is_copy_assignable etc).

#include 
#include 
#include 
#include 

namespace std{
template  struct is_copy_constructible> : public
is_copy_constructible<_Tp>
{
};
}

struct foo
{
  std::vector x; 
};

struct bar
{
  std::vector x;
  std::unique_ptr y;
};

// First column is what we want, second is actual result
int
main ()
{
  std::cout << "1 " << std::is_copy_constructible>::value <<
"\n";
  std::cout << "0 " <<
std::is_copy_constructible>>::value << "\n";
  std::cout << "1 " << std::is_copy_constructible::value << "\n";
  std::cout << "0 " << std::is_copy_constructible::value << "\n";
}

[Bug target/81210] FAIL: gcc.dg/torture/pr68037-*.c -O* execution test

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #2 from Dominique d'Humieres  ---
> Is this a regression?

AFAICT the tests have never passed.

[Bug c++/81211] Unhelpful error messages using template instance with non-copyable type argument

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Stephen Kell from comment #0)
> (It may also be a bug in libstdc++ that std::function should require this of
> its argument type, although that's not completely bonkers.)

It's explicitly required by the standard.

[Bug c/81208] 'uninitialized' warning is missed while self initializing

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
This is by design.

See
https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Warning-Options.html#index-Winit-self
.

[Bug target/81193] PowerPC GCC __builtin_cpu_is and __builtin_cpu_supports should warn about old libraries

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-26
 Ever confirmed|0   |1

--- Comment #4 from Michael Meissner  ---
I have no problems with restricting use of __builtin_cpu_ and target_clone
to GLIBC 2.19 or newer (or whatever the release version is).  Now that I think
of it, yeah, we don't want to run ifunc resolvers if it has relocations.  I
don't know whether the linker should warn about problematic code (it probably
should, or at least we need to document it somewhere).  I was just surprised
that the compiler silently sets the test to 0.

Alternatively, we would need to do two passes.  On the first pass resolve all
of the normal functions and data locations, setting the location of ifunc
functions in the TOC to be an error function.  The second pass would resolve
the ifunc functions.  If an ifunc function calls another ifunc function that
hasn't been resolved yet, it would go to the error function.

I think for the problem of using __builtin_cpu_, we should issue a warning
(not a fatal error) if the configured GLIBC is too old saying you need to link
against a newer library, but generate the same code that we normally do.  Given
there is a reference to an external provided with the new glibc, it should be
safe, because you would get a linker error if you actually tried to use it with
an old library.  It would allow creation of libraries with functions using
__builtin_cpu_* and target_clone with an old compiler, providing the library is
linked appropriately.

It would also allow the tests for target_clone to work.  Though I probably will
switch my builds to use --with-advance-toolchain to always get the new library
(now that works with bootstrap).

[Bug target/81210] FAIL: gcc.dg/torture/pr68037-*.c -O* execution test

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
(In reply to Dominique d'Humieres from comment #2)
> > Is this a regression?
> 
> AFAICT the tests have never passed.

These tests try to emulate interrupt in user space.  If the emulation
doesn't work on darwin, they should be skipped on darwin.

[Bug c++/81211] Unhelpful error messages using template instance with non-copyable type argument

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Stephen Kell from comment #0)
> > (It may also be a bug in libstdc++ that std::function should require this of
> > its argument type, although that's not completely bonkers.)
> 
> It's explicitly required by the standard.

Oh, you're talking about the argument to the call operator not the argument to
the constructor (which is required to be CopyConstructible).

If you declare std::function then obviously it takes a T by value,
because that's what the type "bool(T)" means. If you can't pass the type by
value, you can't call the function.

(In reply to Stephen Kell from comment #0)
> Meanwhile, g++ 6 (Debian 6.3.0-18) says basically the same thing.

Note really, all supported releases (which 4.9 is not one of) say:

/home/jwakely/gcc/6/include/c++/6.3.1/functional:1914:2: note:   template
argument deduction/substitution failed:
/home/jwakely/gcc/6/include/c++/6.3.1/functional:1913:9: error: no type named
‘type’ in ‘class std::result_of&(T)>’
 typename = _Requires<_Callable<_Functor>, void>>
 ^~~~

Because your lambda with a parameter of type T is not callable with an argument
of type T.


> Naively at least, I'd expect the error trace to reveal something about
> trying to copy a T, presumably in some non-viable constructor of
> std::function.

It tells you the lambda can't be called, which is why the constructor isn't
viable.

[Bug libstdc++/70472] is_copy_constructible>>::value is true

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
That would only work for vector not vector , for the reasons given
above.

[Bug middle-end/81212] New: -Wreturn-type is disabled when used together with -fsanitize=return

[vanyacpp at gmail dot com]

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

Bug ID: 81212
   Summary: -Wreturn-type is disabled when used together with
-fsanitize=return
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vanyacpp at gmail dot com
  Target Milestone: ---

Consider this code snippet:

struct X
{
X(void* p);

void* p;
};


X f(bool x, void* p)
{
if (x)
return X(p);
}

Compiling it with gcc 7.1 -Wreturn-type gives a warning:
warning: control reaches end of non-void function [-Wreturn-type]

But compiling it with gcc 7.1 -Wreturn-type and -fsanitize=return gives no
warning. Clang 4.0 gives the warning in both cases. It would be great if gcc
gave the warning in both cases too.

[Bug c++/81211] Unhelpful error messages using template instance with non-copyable type argument

[srk31 at srcf dot ucam.org]

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

--- Comment #3 from Stephen Kell  ---
I agree that this message is better (my bad for not trying a supported
release).

It'd be nice if I didn't have to guess that the reason it's not callable is
that I omitted the copy constructor. The rules for when constructors are
defaulted/deleted are baroque enough to catch anybody out from time to time.

[Bug ipa/81213] New: GCC target_clone support does not work for static functions

[meissner at gcc dot gnu.org]

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

Bug ID: 81213
   Summary: GCC target_clone support does not work for static
functions
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 41632
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41632&action=edit
Test case.

The current target_clone support does not work if the function is static.  The
ifunc entry has to be a global entry point for ifunc to work.  The code does
not change the name for the ifunc handler to be unique.

With attached source compiled for -O3, the following are the symbols in the
object file.

-> ~/fsf-install-x86_64/trunk-249567-x86_64/bin/gcc -O3  -save-temps -c
test-x86-clone2.c && nm test-x86-clone2.o
 U __cpu_indicator_init
 U __cpu_model
0540 i vadd
0380 t vadd.arch_core_avx2.2.default.3
02a0 t vadd.arch_slm.1.default.4
00e0 t vadd.avx.0.default.5
 t vadd.default.6
0540 T vadd._GLOBAL___vdbl.resolver
0590 T vdbl

Note that vadd is external (which it needs to be), but it isn't unique.

The resolver function is external, but it doesn't need to be external.  It can
be internal.  The function name is changed by calling make_unique_name in the
i386.c function make_resolver_func.  The i386 code explicitly sets the resolver
function to static, but it is changed in the machine dependent code.

[Bug middle-end/80775] [8 Regression] -O3 produces ice in group_case_labels_stmt

[bergner at gcc dot gnu.org]

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

--- Comment #14 from Peter Bergner  ---
I don't see this on powerpc64le-linux using -O3.  What target are you using? 
Any options other than -O3?

[Bug ipa/81214] New: GCC target_clone support does not work for global functions with no references

[meissner at gcc dot gnu.org]

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

Bug ID: 81214
   Summary: GCC target_clone support does not work for global
functions with no references
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 41633
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41633&action=edit
Test case.

If you define a global target_clone function but there are no references to it,
because the references will be in another file, the compiler deletes the ifunc
entry and the ifunc resolver function, but it leaves the target clone functions
(which no longer have references to them once the resolver function was
deleted).

The following is the NM output from the attached file compiled with -O3:

$ file="test-x86-clone3"; ~/fsf-install-x86_64/trunk-249567-x86_64/bin/gcc -O3 
-save-temps -c $file.c && nm $file.o
01b0 t vadd.arch_core_avx2.2.default.3
0150 t vadd.arch_slm.1.default.4
0060 t vadd.avx.0.default.5
 T vadd.default.6

[Bug target/81210] FAIL: gcc.dg/torture/pr68037-*.c -O* execution test

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
The following reduced test segfault also on darwin

#define IP  0x12345671
#define CS  0x12345672
#define FLAGS   0x12345673
#define SP  0x12345674
#define SS  0x12345675

#define STRING(x)   XSTRING(x)
#define XSTRING(x)  #x

int
main ()
{
  asm ("push$" STRING (SS) ";   \
push$" STRING (SP) ";   \
push$" STRING (FLAGS) ";\
push$" STRING (CS) ";   \
push$" STRING (IP) ";");
  return 0;
}

[Bug middle-end/81207] [7/8 Regression] tree check fail in simplify_builtin_call

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug c++/81147] [avr] C++ for -mmcu=atmega2560 doesn't do NRVO or RVO when class inherits from empty base

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-06-26
 Ever confirmed|0   |1

[Bug middle-end/80775] [8 Regression] -O3 produces ice in group_case_labels_stmt

[bergner at gcc dot gnu.org]

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

--- Comment #15 from Peter Bergner  ---
(In reply to Peter Bergner from comment #14)
> I don't see this on powerpc64le-linux using -O3.  What target are you using?
> Any options other than -O3?

Doesn't fail for me on x86_64 either, so I'll need target/configure options as
well as full compile options.

[Bug rtl-optimization/81194] [8 Regression] ICE during RTL pass: expand

[bergner at gcc dot gnu.org]

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

--- Comment #5 from Peter Bergner  ---
(In reply to Jakub Jelinek from comment #3)
> I don't see g++ options mentioned anywhere, the testcase compiles even with
> latest trunk just fine with -O0 -std=c++17 or -O2 -std=c++17.

...and compiles fine with -O1 -std=c++17 and -O3 -std=c++17 too, so I'll need
more info to be able to recreate this.

[Bug c++/81169] [8 Regression] gcc 8.0dev -Wclass-memaccess illegitimate warning related to volatile

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
Fixed in r249660.

[Bug c++/81169] [8 Regression] gcc 8.0dev -Wclass-memaccess illegitimate warning related to volatile

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Author: msebor
Date: Mon Jun 26 17:19:15 2017
New Revision: 249660

URL: https://gcc.gnu.org/viewcvs?rev=249660&root=gcc&view=rev
Log:
PR c++/81169 - -Wclass-memaccess illegitimate warning related to volatile

gcc/cp/ChangeLog:

PR c++/81169
* call.c (maybe_warn_class_memaccess): Preserve explicit conversions
to detect casting away cv-qualifiers.

gcc/testsuite/ChangeLog:

PR c++/81169
* g++.dg/Wclass-memaccess-2.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/Wclass-memaccess-2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/81211] Unhelpful error messages using template instance with non-copyable type argument

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
That's not really very practical. std::function uses std::result_of to check
for a callable type, and it's not an error for std::result_of to decide the
type isn't callable. The error happens when std::function requests the
std::result_of<>::type member, which doesn't exist. But the reason for it not
existing is long gone by that point, decided earlier in the internals of
std::result_of and not available to the compiler.

Using decltype(std::declval<_Func&>()(std::declval<_ArgTypes>()...)) instead of
result_of gives a nice diagnostic:

/home/jwakely/gcc/8/include/c++/8.0.0/bits/std_function.h:465:2: note:
candidate: ‘template std::function<_Res(_ArgTypes
...)>::function(_Functor)’
  function(_Functor);
  ^~~~
/home/jwakely/gcc/8/include/c++/8.0.0/bits/std_function.h:465:2: note:  
template argument deduction/substitution failed:
/home/jwakely/gcc/8/include/c++/8.0.0/bits/std_function.h:394:55: error: use of
deleted function ‘constexpr T::T(const T&)’
 typename _Res2 =
decltype(std::declval<_Func&>()(std::declval<_ArgTypes>()...))>
   ^~
func.cc:2:8: note: ‘constexpr T::T(const T&)’ is implicitly declared as deleted
because ‘T’ declares a move constructor or move assignment operator
 struct T
^
func.cc:16:33: note:   initializing argument 1 of ‘main()::’
   std::function f{ [](T) { } };
 ^

But using decltype there is incorrect, it wouldn't work for pointers to
members. Which is why we use result_of.

We can't add something like:

static_assert( __and_...>::value,
   "arguments can be passed to the target function" );

Because that would reject this valid code:

#include 

struct T
{
T(int) {}
// uncomment one of the  below to make the code compile
//T(const T&) {}
//T(T&& t) {}
T& operator=(const T&) { return *this; }
T& operator=(T&&) { return *this; }
};

int main()
{
std::function f{ [](T&&) {} };
f( {1} );
}

I don't see anything that can really be done to improve things here.

(In reply to Stephen Kell from comment #3)
> It'd be nice if I didn't have to guess that the reason it's not callable is
> that I omitted the copy constructor. The rules for when constructors are
> defaulted/deleted are baroque enough to catch anybody out from time to time.

Not if you follow the rule of five:
http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#c21-if-you-define-or-delete-any-default-operation-define-or-delete-them-all

Your class has user-provided assignment operators and fails to declare copy and
move constructors. Define them (maybe as =default) and there's no problem.

[Bug tree-optimization/81196] Number of iterations found for p!=q but not for p

[glisse at gcc dot gnu.org]

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

--- Comment #5 from Marc Glisse  ---
(In reply to amker from comment #4)
> Hmm, the function can only be vectorized with "-march=skylake"?

Er, it also vectorizes without any -march on x86_64 (with shorter vectors).

[Bug c++/81211] Unhelpful error messages using template instance with non-copyable type argument

[srk31 at srcf dot ucam.org]

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

--- Comment #5 from Stephen Kell  ---
I take the point in general, and I see the specific difficulty in how result_of
works.

In this specific case, there still seems to be a more low-hanging solution.
Perhaps having a lambda that is not callable ought to raise a warning? That
seems like a more straightforward diagnostic. In particular, by addressing the
lambda rather than the std::function, the problem with pointers to member
functions doesn't arise.

As for the rule of five: a fine reference, but it's rather circular to say what
amounts to "don't make mistakes in your code". :-) This error came up after a
rather large bout of refactoring that deleted slightly too much stuff

[Bug fortran/81205] Hybrid MPI and OpenMp: Blocking code in loops

[anlauf at gmx dot de]

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

--- Comment #4 from Harald Anlauf  ---
(In reply to Pasha from comment #2)
> This is my main routine for example
> .
> .
> .
> !!$OMP PARALLEL DO DEFAULT(SHARED) PRIVATE(K,jL)
> DO k=1,nG3
>DO jL=1,nL2
>   j = idx2start + jL

Any reason you didn't declare j as private?

>   IF(masque(j,k))THEN
> 
>  ! dudx
>  CALL fvec (nG1,curC(1:nG1,jL,k), difles1C(1:nG1,jL,k))
>  CALL tridgn (ff,s1,w1,difles1C(1:nG1,jL,k), nG1,1)
>   ENDIF
>ENDDO
> ENDDO
> !!$OMP END PARALLEL DO

Have you tried some thread-checking tool to debug the code,
or cross-checked with another compiler?

[Bug rtl-optimization/81194] [8 Regression] ICE during RTL pass: expand

[marc.mutz at kdab dot com]

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

--- Comment #6 from Marc Mutz  ---
Sorry. Here it comes:

make[2]: Entering directory
'/home/marc/Qt/qt5-build/qtdeclarative/src/qmldevtools'
g++ -c -pipe -Wno-error=expansion-to-defined -Wno-error=maybe-uninitialized
-Wno-error=expansion-to-defined -Wno-error=maybe-uninitialized
-Wno-c++0x-compat -ffunction-sections -O2 -fPIC -std=c++1z -fvisibility=hidden
-fvisibility-inlines-hidden -fno-exceptions -Wall -W
-Wno-error=expansion-to-defined -Wno-error=maybe-uninitialized
-Wno-error=expansion-to-defined -Wno-error=maybe-uninitialized
-Wno-c++0x-compat -Wvla -Wdate-time -Wshift-overflow=2 -Wduplicated-cond
-Werror -Wno-error=cpp -Wno-error=deprecated-declarations
-Wno-error=strict-overflow -Wno-error=implicit-fallthrough
-Wno-error=class-memaccess -D_REENTRANT -DWTF_EXPORT_PRIVATE=
-DJS_EXPORT_PRIVATE= -DENABLE_ASSEMBLER_WX_EXCLUSIVE=1
-DWTFReportAssertionFailure=qmlWTFReportAssertionFailure
-DWTFReportBacktrace=qmlWTFReportBacktrace
-DWTFInvokeCrashHook=qmlWTFInvokeCrashHook -DENABLE_LLINT=0 -DENABLE_DFG_JIT=0
-DENABLE_DFG_JIT_UTILITY_METHODS=1 -DENABLE_JIT_CONSTANT_BLINDING=0
-DBUILDING_QT__ -DWTF_USE_UDIS86=0 -DNDEBUG -DWTF_EXPORT_PRIVATE=
-DJS_EXPORT_PRIVATE= -DENABLE_ASSEMBLER_WX_EXCLUSIVE=1
-DWTFReportAssertionFailure=qmlWTFReportAssertionFailure
-DWTFReportBacktrace=qmlWTFReportBacktrace
-DWTFInvokeCrashHook=qmlWTFInvokeCrashHook -DENABLE_LLINT=0 -DENABLE_DFG_JIT=0
-DENABLE_DFG_JIT_UTILITY_METHODS=1 -DENABLE_JIT_CONSTANT_BLINDING=0
-DBUILDING_QT__ -DWTF_USE_UDIS86=0 -DNDEBUG
-DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_QMLDEVTOOLS_LIB
-DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT
-DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS
-DQT_DISABLE_DEPRECATED_BEFORE=0x05 -DQT_NO_EXCEPTIONS
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_CORE_LIB
-I/home/marc/Qt/qt5/qtdeclarative/src/qmldevtools -I.
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/jit
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/assembler
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/runtime
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/wtf
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/stubs
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/stubs/wtf
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/disassembler
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/disassembler/udis86
-I/home/marc/Qt/qt5/qtdeclarative/src/qml/jsruntime -I.
-I/home/marc/Qt/qt5/qtdeclarative/src/qml/compiler -I.
-I/home/marc/Qt/qt5/qtdeclarative/src/qml/memory -I.
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/jit
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/assembler
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/runtime
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/wtf
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/stubs
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/stubs/wtf
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/disassembler
-I/home/marc/Qt/qt5/qtdeclarative/src/3rdparty/masm/disassembler/udis86
-I/home/marc/Qt/qt5/qtdeclarative/src/qml/jit -I. -I.generated
-I/home/marc/Qt/qt5-build/qtbase/include
-I/home/marc/Qt/qt5-build/qtbase/include/QtQml
-I/home/marc/Qt/qt5-build/qtbase/include/QtQml/5.10.0
-I/home/marc/Qt/qt5-build/qtbase/include/QtQml/5.10.0/QtQml
-I/home/marc/Qt/qt5-build/qtbase/include/QtCore/5.10.0
-I/home/marc/Qt/qt5-build/qtbase/include/QtCore/5.10.0/QtCore
-I/home/marc/Qt/qt5-build/qtbase/include/QtCore -I.moc
-I/home/marc/Qt/qt5/qtbase/mkspecs/linux-g++ -o .obj/qv4isel_masm.o
/home/marc/Qt/qt5/qtdeclarative/src/qml/jit/qv4isel_masm.cpp

[Bug c++/81215] New: [7/8 Regression] deduction failure with variadic template template parameter

[jason at gcc dot gnu.org]

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

Bug ID: 81215
   Summary: [7/8 Regression] deduction failure with variadic
template template parameter
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: jason at gcc dot gnu.org
  Reporter: jason at gcc dot gnu.org
  Target Milestone: ---

From https://bugzilla.redhat.com/show_bug.cgi?id=1464612

template struct X { };
template struct set { };

template  class C>
void bar (const X>&)
{
}

void
foo (X>& x)
{
  bar (x);
}

[Bug c++/81215] [7/8 Regression] deduction failure with variadic template template parameter

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-06-26
 Ever confirmed|0   |1

[Bug fortran/81205] Hybrid MPI and OpenMp: Blocking code in loops

[pasha.313 at hotmail dot com]

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

--- Comment #5 from Pasha  ---
(In reply to Harald Anlauf from comment #4)
> (In reply to Pasha from comment #2)
> > This is my main routine for example
> > .
> > .
> > .
> > !!$OMP PARALLEL DO DEFAULT(SHARED) PRIVATE(K,jL)
> > DO k=1,nG3
> >DO jL=1,nL2
> >   j = idx2start + jL
> 
> Any reason you didn't declare j as private?
That did not solve the problem as I have other subroutines in main which
declared all of index number in main program and in subroutines but again the
code Blocks. Even when I disabled OMP commands in the loop of main program, the
code get inside the subroutine but again blocks in the loop of that
subroutines.
I used ulimit -s 1000 or ulimit -Hd to increase the capacity of each CPU
but still get nowhere.   
> 
> >   IF(masque(j,k))THEN
> > 
> >  ! dudx
> >  CALL fvec (nG1,curC(1:nG1,jL,k), difles1C(1:nG1,jL,k))
> >  CALL tridgn (ff,s1,w1,difles1C(1:nG1,jL,k), nG1,1)
> >   ENDIF
> >ENDDO
> > ENDDO
> > !!$OMP END PARALLEL DO
> 
> Have you tried some thread-checking tool to debug the code,
> or cross-checked with another compiler?

Some of my friends suggested to compile the code with ifort, but I do not
access to that. I asked my supervisor to buy or find it on other lab to check
it.
Will you please offer a name of thread-checking tools? can I do it with visual
studio? or you mean something else?

[Bug c++/81215] [7/8 Regression] deduction failure with variadic template template parameter

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  ---
Author: jason
Date: Mon Jun 26 18:49:18 2017
New Revision: 249664

URL: https://gcc.gnu.org/viewcvs?rev=249664&root=gcc&view=rev
Log:
PR c++/81215 - deduction failure with variadic TTP.

* pt.c (unify_bound_ttp_args): Restore old logic for C++14 and down.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/variadic-ttp7.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c++/81215] [7/8 Regression] deduction failure with variadic template template parameter

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Mon Jun 26 18:49:25 2017
New Revision: 249665

URL: https://gcc.gnu.org/viewcvs?rev=249665&root=gcc&view=rev
Log:
PR c++/81215

* pt.c (unify_bound_ttp_args): Restore old logic for C++14 and down.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp0x/variadic-ttp7.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/pt.c

[Bug fortran/81205] Hybrid MPI and OpenMp: Blocking code in loops

[anlauf at gmx dot de]

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

--- Comment #6 from Harald Anlauf  ---
(In reply to Pasha from comment #5)
> (In reply to Harald Anlauf from comment #4)
> > (In reply to Pasha from comment #2)
> > > This is my main routine for example
> > > .
> > > .
> > > .
> > > !!$OMP PARALLEL DO DEFAULT(SHARED) PRIVATE(K,jL)
> > > DO k=1,nG3
> > >DO jL=1,nL2
> > >   j = idx2start + jL
> > 
> > Any reason you didn't declare j as private?
> That did not solve the problem as I have other subroutines in main which
> declared all of index number in main program and in subroutines but again
> the code Blocks. Even when I disabled OMP commands in the loop of main
> program, the code get inside the subroutine but again blocks in the loop of
> that subroutines.
> I used ulimit -s 1000 or ulimit -Hd to increase the capacity of each CPU
> but still get nowhere.   

You're saying your code blocks even without OpenMP?
Then it's not an OpenMP problem.

Your comments sound your code has a more serious issue that
cannot be understood given the code parts you've shown.

> > 
> > >   IF(masque(j,k))THEN
> > > 
> > >  ! dudx
> > >  CALL fvec (nG1,curC(1:nG1,jL,k), difles1C(1:nG1,jL,k))
> > >  CALL tridgn (ff,s1,w1,difles1C(1:nG1,jL,k), nG1,1)
> > >   ENDIF
> > >ENDDO
> > > ENDDO
> > > !!$OMP END PARALLEL DO
> > 
> > Have you tried some thread-checking tool to debug the code,
> > or cross-checked with another compiler?
> 
> Some of my friends suggested to compile the code with ifort, but I do not
> access to that. I asked my supervisor to buy or find it on other lab to
> check it.
> Will you please offer a name of thread-checking tools? can I do it with
> visual studio? or you mean something else?

I can't say anything about visual whatever.

I'd recommend valgrind (for memory and thread checking),
or a newer gcc release supporting thread and memory sanitizing.

With the Intel compiler (you could try an evaluation license) I've
used the tools belonging to the Intel suite for doing the same.  They
have a fancy GUI, if that's what you prefer.

[Bug bootstrap/81216] New: [8 Regression] bootstrap failed on i386

[hjl.tools at gmail dot com]

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

Bug ID: 81216
   Summary: [8 Regression] bootstrap failed on i386
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: wschmidt at linux dot vnet.ibm.com
  Target Milestone: ---

On i386, r249648 gave

libtool: compile:  /export/gnu/import/git/gcc-test-ia32/bld/./gcc/xgcc
-shared-libgcc -B/export/gnu/import/git/gcc-test-ia32/bld/./gcc -nostdinc++
-L/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/src
-L/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/src/.libs
-L/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/libsupc++/.libs
-B/usr/8.0.0/i686-linux/bin/ -B/usr/8.0.0/i686-linux/lib/ -isystem
/usr/8.0.0/i686-linux/include -isystem /usr/8.0.0/i686-linux/sys-include
-I/export/gnu/import/git/gcc-test-ia32/src-trunk/libstdc++-v3/../libgcc
-I/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/include/i686-linux
-I/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/include
-I/export/gnu/import/git/gcc-test-ia32/src-trunk/libstdc++-v3/libsupc++
-std=gnu++98 -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra
-Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections -frandom-seed=codecvt.lo -g -O2
-D_GNU_SOURCE -c ../../../../../src-trunk/libstdc++-v3/src/c++98/codecvt.cc 
-fPIC -DPIC -D_GLIBCXX_SHARED -o codecvt.o
In file included from
/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/include/bits/char_traits.h:39:0,
 from
/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/include/string:40,
 from
/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/include/bits/locale_classes.h:40,
 from
/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/include/locale:39,
 from
../../../../../src-trunk/libstdc++-v3/src/c++98/codecvt.cc:25:
/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/include/bits/stl_algobase.h:
In static member function ‘static bool std::__equal<_BoolType>::equal(_II1,
_II1, _II2)’:
/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/include/bits/stl_algobase.h:801:20:
internal compiler error: Segmentation fault
return false;
^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Makefile:565: recipe for target 'codecvt.lo' failed
make[9]: *** [codecvt.lo] Error 1
make[9]: *** Waiting for unfinished jobs
make[9]: Leaving directory
'/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/src/c++98'
Makefile:641: recipe for target 'all-recursive' failed
make[8]: *** [all-recursive] Error 1
make[8]: Leaving directory
'/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3/src'
Makefile:510: recipe for target 'all-recursive' failed
make[7]: *** [all-recursive] Error 1
make[7]: Leaving directory
'/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3'
Makefile:417: recipe for target 'all' failed
make[6]: *** [all] Error 2
make[6]: Leaving directory
'/export/gnu/import/git/gcc-test-ia32/bld/i686-linux/libstdc++-v3'
Makefile:15088: recipe for target 'all-stage2-target-libstdc++-v3' failed
make[5]: *** [all-stage2-target-libstdc++-v3] Error 2
make[5]: Leaving directory '/export/gnu/import/git/gcc-test-ia32/bld'
Makefile:24033: recipe for target 'stage2-bubble' failed
make[4]: *** [stage2-bubble] Error 2
make[4]: Leaving directory '/export/gnu/import/git/gcc-test-ia32/bld'
Makefile:24236: recipe for target 'bootstrap' failed
make[3]: *** [bootstrap] Error 2

r249645 is OK.  GCC is configured with

 --prefix=/usr/8.0.0 --enable-clocale=gnu --with-system-zlib --enable-shared
--with-demangler-in-ld --enable-libmpx i686-linux --with-fpmath=sse

[Bug sanitizer/81209] [7/8 Regression] -fsanitize=undefined ICE on darwin

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-06-26
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

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

Untested fix.

[Bug rtl-optimization/81194] [8 Regression] ICE during RTL pass: expand

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-26
 Ever confirmed|0   |1

--- Comment #7 from Peter Bergner  ---
Ok, with -O2 -std=c++17 -fno-exceptions I have it recreated.  I'll have a look.

[Bug bootstrap/81217] New: Makefile:22754: warning: overriding recipe for target 'profiledbootstrap'

[hjl.tools at gmail dot com]

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

Bug ID: 81217
   Summary: Makefile:22754: warning: overriding recipe for target
'profiledbootstrap'
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: mliska at suse dot cz
  Target Milestone: ---

r249366 caused:

Makefile:22754: warning: overriding recipe for target 'profiledbootstrap'
Makefile:22614: warning: ignoring old recipe for target 'profiledbootstrap'
Makefile:22765: warning: overriding recipe for target 'profiledbootstrap-lean'
Makefile:22625: warning: ignoring old recipe for target
'profiledbootstrap-lean'
[ -f stage_final ] || echo stage3 > stage_final
make[1]: Entering directory
'/export/gnu/import/git/gcc-regression-bootstrap/mas
ter/249645/bld'
Makefile:22754: warning: overriding recipe for target 'profiledbootstrap'
Makefile:22614: warning: ignoring old recipe for target 'profiledbootstrap'
Makefile:22765: warning: overriding recipe for target 'profiledbootstrap-lean'
Makefile:22625: warning: ignoring old recipe for target
'profiledbootstrap-lean'
make[2]: Entering directory
'/export/gnu/import/git/gcc-regression-bootstrap/mas
ter/249645/bld'
Makefile:22754: warning: overriding recipe for target 'profiledbootstrap'
Makefile:22614: warning: ignoring old recipe for target 'profiledbootstrap'
Makefile:22765: warning: overriding recipe for target 'profiledbootstrap-lean'
Makefile:22625: warning: ignoring old recipe for target
'profiledbootstrap-lean'
make[2]: Leaving directory
'/export/gnu/import/git/gcc-regression-bootstrap/mast
er/249645/bld'
make[2]: Entering directory
'/export/gnu/import/git/gcc-regression-bootstrap/mas
ter/249645/bld'
Makefile:22754: warning: overriding recipe for target 'profiledbootstrap'
Makefile:22614: warning: ignoring old recipe for target 'profiledbootstrap'
Makefile:22765: warning: overriding recipe for target 'profiledbootstrap-lean'
Makefile:22625: warning: ignoring old recipe for target
'profiledbootstrap-lean'

[Bug bootstrap/81217] Makefile:22754: warning: overriding recipe for target 'profiledbootstrap'

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-26
 Ever confirmed|0   |1

[Bug bootstrap/81217] Makefile:22754: warning: overriding recipe for target 'profiledbootstrap'

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Confirmed, I saw this over the weekend also.

[Bug libgcc/81218] New: libgcc_s.so.1 call to __get_cpuid does not correctly code around 486 cpus lacking cpuid instruction

[tedheadster at gmail dot com]

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

Bug ID: 81218
   Summary: libgcc_s.so.1 call to __get_cpuid does not correctly
code around 486 cpus lacking cpuid instruction
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tedheadster at gmail dot com
  Target Milestone: ---

Programs calling libgcc_s.so.1 are failing with an "illegal instruction" signal
on old i486 processors that do not support the cpuid instruction. Later i486
had the instruction, but earlier ones lacked it. The code looks like it
attempts to detect support for the instruction, but it is not working. 

Below is a backtrace (with only partial symbols available):

(gdb) bt
#0  0xb74b5142 in __get_cpuid (__edx=0xbfe5fd18, __ecx=0xbfe5fd14,
__ebx=0xbfe5fd10, __eax=0xbfe5fd0c, __level=0)
at
/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/build/gcc/include/cpuid.h:2\
42

#1  __get_cpuid_output (__level=__level@entry=0, __eax=__eax@entry=0xbfe5fd0c,
__ebx=__ebx@entry=0xbfe5fd10, __ecx=0xbfe5fd14, __edx=0xbfe5fd18)
at
/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/gcc-5.4.0/libgcc/config/i38\
6/cpuinfo.c:337

#2  0xb74b51ba in __cpu_indicator_init ()
at
/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/gcc-5.4.0/libgcc/config/i38\
6/cpuinfo.c:362

#3  0xb77385b6 in ?? () from /lib/ld-linux.so.2
#4  0xb77386dd in ?? () from /lib/ld-linux.so.2
#5  0xb77289cf in ?? () from /lib/ld-linux.so.2
(gdb)

I can move the hard drive between an i486DX/75 and an x86_64 machine. It fails
on the i486 and succeeds on the x86_64 machine.

[Bug bootstrap/81219] New: [8 regression] SEGV in linemap_location_from_macro_expansion_p

[ro at gcc dot gnu.org]

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

Bug ID: 81219
   Summary: [8 regression] SEGV in
linemap_location_from_macro_expansion_p
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: mpolacek at gcc dot gnu.org
  Target Milestone: ---
Target: i386-pc-solaris2.12, i686-pc-linux-gnu,
sparc-sun-solaris2.12

Between 20170625 (r249632) and 20170626 (r249656), bootstrap broke on several
targets.

E.g on i686-pc-linux-gnu and sparc-sun-solaris2.12, building stage2 libstdc++:

In file included from
/var/gcc/regression/trunk/12-gcc/build.bad/sparc-sun-solaris2.12/libstdc++-v3/include/bits/char_traits.h:39:0,
 from
/var/gcc/regression/trunk/12-gcc/build.bad/sparc-sun-solaris2.12/libstdc++-v3/include/string:40,
 from
/var/gcc/regression/trunk/12-gcc/build.bad/sparc-sun-solaris2.12/libstdc++-v3/include/bits/locale_classes.h:40,
 from
/var/gcc/regression/trunk/12-gcc/build.bad/sparc-sun-solaris2.12/libstdc++-v3/include/bits/ios_base.h:41,
 from
/var/gcc/regression/trunk/12-gcc/build.bad/sparc-sun-solaris2.12/libstdc++-v3/include/streambuf:41,
 from
/vol/gcc/src/hg/trunk/local/libstdc++-v3/src/c++98/streambuf.cc:29:
/var/gcc/regression/trunk/12-gcc/build.bad/sparc-sun-solaris2.12/libstdc++-v3/include/bits/stl_algobase.h:
In static member function âstatic bool std::__equal<_BoolType>::equal(_II1,
_II1, _II2)â:
/var/gcc/regression/trunk/12-gcc/build.bad/sparc-sun-solaris2.12/libstdc++-v3/include/bits/stl_algobase.h:801:20:
internal compiler error: Segmentation Fault
return false;
^
0x15201ff crash_signal
/vol/gcc/src/hg/trunk/local/gcc/toplev.c:338
0x20c3ea0 linemap_location_from_macro_expansion_p(line_maps const*, unsigned
int)
/vol/gcc/src/hg/trunk/local/libcpp/line-map.c:1254
0x20c3e6b linemap_location_from_macro_expansion_p(line_maps const*, unsigned
int)
/vol/gcc/src/hg/trunk/local/libcpp/line-map.c:1252

cc1plus -quiet -nostdinc++ -v -I
/vol/gcc/src/hg/trunk/local/libstdc++-v3/../libgcc -I
/var/gcc/regression/trunk/12-gcc/build.bad/sparc-sun-solaris2.12/libstdc++-v3/include/sparc-sun-solaris2.12
-I
/var/gcc/regression/trunk/12-gcc/build.bad/sparc-sun-solaris2.12/libstdc++-v3/include
-I /vol/gcc/src/hg/trunk/local/libstdc++-v3/libsupc++ -iprefix
/var/gcc/regression/trunk/12-gcc/build.bad/gcc/../lib/gcc/sparc-sun-solaris2.12/8.0.0/
-isystem /var/gcc/regression/trunk/12-gcc/build.bad/./gcc/include -isystem
/var/gcc/regression/trunk/12-gcc/build.bad/./gcc/include-fixed -D__sparcv8 -D
_GLIBCXX_SHARED -D PIC -D _GLIBCXX_SHARED -isystem
/vol/gcc/sparc-sun-solaris2.12/include -isystem
/vol/gcc/sparc-sun-solaris2.12/sys-include
/vol/gcc/src/hg/trunk/local/libstdc++-v3/src/c++98/streambuf.cc -quiet
-dumpbase streambuf.cc -mcpu=v9 -auxbase-strip streambuf.o -g -O2 -Wall -Wextra
-Wwrite-strings -Wcast-qual -Wabi -std=gnu++98 -version -fno-implicit-templates
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=streambuf.lo -fPIC -o streambuf.s

Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x020c3ea0 in linemap_location_from_macro_expansion_p (set=0xfbbf6000, 
location=4209776568) at /vol/gcc/src/hg/trunk/local/libcpp/line-map.c:1254
1254 &
MAX_SOURCE_LOCATION].locus;
(gdb) where
#0  0x020c3ea0 in linemap_location_from_macro_expansion_p (set=0xfbbf6000, 
location=4209776568) at /vol/gcc/src/hg/trunk/local/libcpp/line-map.c:1254
#1  0x00cb2e78 in warn_for_multistatement_macros (body_loc=4209776568, 
next_loc=72017509, guard_loc=72005218, keyword=RID_FOR)
at /vol/gcc/src/hg/trunk/local/gcc/c-family/c-warn.c:2431
#2  0x009e72c4 in cp_parser_already_scoped_statement (parser=0xfac27e98, 
if_p=0x0, guard_tinfo=...)
at /vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:12452
#3  0x009e6348 in cp_parser_iteration_statement (parser=0xfac27e98, if_p=0x0, 
ivdep=false) at /vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:12113
#4  0x009e1b34 in cp_parser_statement (parser=0xfac27e98, 
in_statement_expr=0x0, in_compound=true, if_p=0x0, chain=0x0, 
loc_after_labels=0x0) at /vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:10696
#5  0x009e3264 in cp_parser_statement_seq_opt (parser=0xfac27e98, 
in_statement_expr=0x0) at /vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:11165
#6  0x009e30f0 in cp_parser_compound_statement (parser=0xfac27e98, 
in_statement_expr=0x0, bcs_flags=0, function_body=true)
at /vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:9
#7  0x009fed84 in cp_parser_function_body (parser=0xfac27e98, 
in_function_try_block=false)
at /vol/gcc/sr