Re: [PATCH C++] document order of C++ ctors and attribute constructor is unspecified

[Jason Merrill]

On Wed, Mar 15, 2017 at 6:59 PM, Martin Sebor  wrote:
> In bug 52477 - Wrong initialization order?  attribute constructor
> vs static data access, the reporter expects C++ objects with static
> storage duration to have their ctors called in the same order as
> those of functions declared with attribute constructor interleaved
> with them.
>
> In his comment on the bug Richard opines that relying on the order
> is undefined.  The attached patch updates the manual to make this
> clear.

I disagree with that comment, and have added one of my own, but I
think your patch is appropriate for GCC 7 since we aren't going to fix
it in this release.

Jason

[Bug c++/52477] Wrong initialization order? __attribute__((constructor)) vs static data access

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
   Last reconfirmed||2017-03-16
 CC||jason at gcc dot gnu.org
 Resolution|INVALID |---
 Ever confirmed|0   |1

--- Comment #6 from Jason Merrill  ---
I don't think this is undefined; it seems natural for these functions to be
ordered with a translation unit along with dynamic initialization of non-local
variables.  So for

---
extern "C" int printf (const char *, ...);

struct A { A() { printf ("A\n"); } } a;

static void B() __attribute__((constructor));
static void B()
{
  printf ("B\n");
}

struct C { C() { printf ("C\n"); } } c;

int main() {}
---

I would expect A B C, and gcc currently outputs B A C.  Instead of emitting
constructor functions directly into .init_array as we do now, we should
remember them and call them from __static_initialization_and_destruction_0.

Note that 4.6 gave the differently wrong A C B, due to running .init_array in
the opposite order, so this isn't really a regression.

[Bug tree-optimization/71437] [7 regression] Performance regression after r235817

[law at gcc dot gnu.org]

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

--- Comment #18 from Jeffrey A. Law  ---
Author: law
Date: Thu Mar 16 03:19:35 2017
New Revision: 246186

URL: https://gcc.gnu.org/viewcvs?rev=246186=gcc=rev
Log:
PR tree-optimization/71437
* tree-ssa-dom.c (struct cond_equivalence): Moved from here into
tree-ssa-scopedtables.
(lookup_avail_expr, build_and_record_new_cond): Likewise.
(record_conditions, record_cond, vuse_eq): Likewise.
(record_edge_info): Adjust to API tweak of record_conditions.
(simplify_stmt_for_jump_threading): Similarly for lookup_avail_expr.
(record_temporary_equivalences, optimize_stmt): Likewise.
(eliminate_redundant_computations): Likewise.
(record_equivalences_from_stmt): Likewise.
* tree-ssa-scopedtables.c: Include options.h and params.h.
(vuse_eq): New function, moved from tree-ssa-dom.c
(build_and_record_new_cond): Likewise.
(record_conditions): Likewise.  Accept vector of conditions rather
than edge_equivalence structure for first argument.
for the first argument.
(avail_exprs_stack::lookup_avail_expr): New member function, moved
from tree-ssa-dom.c.
(avail_exprs_stack::record_cond): Likewise.
* tree-ssa-scopedtables.h (struct cond_equivalence): Moved here
from tree-ssa-dom.c.
(avail_exprs_stack): Add new member functions lookup_avail_expr
and record_cond.
(record_conditions): Declare.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-dom.c
trunk/gcc/tree-ssa-scopedtables.c
trunk/gcc/tree-ssa-scopedtables.h

--- Comment #19 from Jeffrey A. Law  ---
Author: law
Date: Thu Mar 16 03:19:46 2017
New Revision: 246187

URL: https://gcc.gnu.org/viewcvs?rev=246187=gcc=rev
Log:
PR tree-optimization/71437
* tree-ssa-dom.c (derive_equivalences_from_bit_ior): New function.
(record_temporary_equivalences): Use it.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-dom.c

[Bug tree-optimization/71437] [7 regression] Performance regression after r235817

[law at gcc dot gnu.org]

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

--- Comment #18 from Jeffrey A. Law  ---
Author: law
Date: Thu Mar 16 03:19:35 2017
New Revision: 246186

URL: https://gcc.gnu.org/viewcvs?rev=246186=gcc=rev
Log:
PR tree-optimization/71437
* tree-ssa-dom.c (struct cond_equivalence): Moved from here into
tree-ssa-scopedtables.
(lookup_avail_expr, build_and_record_new_cond): Likewise.
(record_conditions, record_cond, vuse_eq): Likewise.
(record_edge_info): Adjust to API tweak of record_conditions.
(simplify_stmt_for_jump_threading): Similarly for lookup_avail_expr.
(record_temporary_equivalences, optimize_stmt): Likewise.
(eliminate_redundant_computations): Likewise.
(record_equivalences_from_stmt): Likewise.
* tree-ssa-scopedtables.c: Include options.h and params.h.
(vuse_eq): New function, moved from tree-ssa-dom.c
(build_and_record_new_cond): Likewise.
(record_conditions): Likewise.  Accept vector of conditions rather
than edge_equivalence structure for first argument.
for the first argument.
(avail_exprs_stack::lookup_avail_expr): New member function, moved
from tree-ssa-dom.c.
(avail_exprs_stack::record_cond): Likewise.
* tree-ssa-scopedtables.h (struct cond_equivalence): Moved here
from tree-ssa-dom.c.
(avail_exprs_stack): Add new member functions lookup_avail_expr
and record_cond.
(record_conditions): Declare.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-dom.c
trunk/gcc/tree-ssa-scopedtables.c
trunk/gcc/tree-ssa-scopedtables.h

--- Comment #19 from Jeffrey A. Law  ---
Author: law
Date: Thu Mar 16 03:19:46 2017
New Revision: 246187

URL: https://gcc.gnu.org/viewcvs?rev=246187=gcc=rev
Log:
PR tree-optimization/71437
* tree-ssa-dom.c (derive_equivalences_from_bit_ior): New function.
(record_temporary_equivalences): Use it.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-dom.c

Re: [PATCH 2/5][P1][tree-optimization/71437] Record more equivalences in some cases

[Jeff Law]

On 03/15/2017 09:17 PM, Jeff Law wrote:


Patch #3 will remove handle_dominating_asserts from the core of the jump
threading code and push it into VRP's callbacks where it should always
have been.

As a side effect it causes some code which was previously only used for
threading from VRP to be used unconditionally.  It's actually a good
thing as that code will find more jump threads.  But in one case  the
resulting code is tougher for tree-ssa-uninit.c to handle and we get a
false positive uninit warning.

As it turns out for that case we're better off improving DOM slightly
which allows DOM to simplify the test even further.  This patch
implements the DOM improvement so that we don't see a regression when
patch #3 is installed.

The particular case we're looking to improve looks like

t = a | b;
if (t == 0)
...

In the TRUE arm we know that a must be zero and b must be zero.
Discovering those equivalences allows DOM to do a better job for the
uninit testcase from the testsuite.

There's clearly more that could be done with this code, but I didn't
want to take it any further than was needed to address the regression
that would be caused by patch #3.

Bootstrapped and regression tested on x86_64-linux-gnu.  Installing on
the trunk.  I'll be testing this in combination with patch #1 tomorrow
on ppc64le to get additional coverage.

Jeff

Whoops.  This time with the patch.

Jeff
PR tree-optimization/71437
* tree-ssa-dom.c (derive_equivalences_from_bit_ior): New function.
(record_temporary_equivalences): Use it.

diff --git a/gcc/tree-ssa-dom.c b/gcc/tree-ssa-dom.c
index ad71269..0ebe892 100644
--- a/gcc/tree-ssa-dom.c
+++ b/gcc/tree-ssa-dom.c
@@ -691,6 +691,33 @@ back_propagate_equivalences (tree lhs, edge e,
 BITMAP_FREE (domby);
 }
 
+/* Record NAME has the value zero and if NAME was set from a BIT_IOR_EXPR
+   recurse into both operands recording their values as zero too.  */
+
+static void
+derive_equivalencs_from_bit_ior (tree name, const_and_copies *const_and_copies)
+{
+  if (TREE_CODE (name) == SSA_NAME)
+{
+  tree value = fold_convert (TREE_TYPE (name), integer_zero_node);
+
+  /* This records the equivalence for the toplevel object.  */
+  record_equality (name, value, const_and_copies);
+
+  /* And we can recurse into each operand to potentially find more
+equivalences.  */
+  gimple *def_stmt = SSA_NAME_DEF_STMT (name);
+  if (is_gimple_assign (def_stmt)
+ && gimple_assign_rhs_code (def_stmt) == BIT_IOR_EXPR)
+   {
+ derive_equivalencs_from_bit_ior (gimple_assign_rhs1 (def_stmt),
+  const_and_copies);
+ derive_equivalencs_from_bit_ior (gimple_assign_rhs2 (def_stmt),
+  const_and_copies);
+   }
+}
+}
+
 /* Record into CONST_AND_COPIES and AVAIL_EXPRS_STACK any equivalences implied
by traversing edge E (which are cached in E->aux).
 
@@ -711,7 +738,28 @@ record_temporary_equivalences (edge e,
   /* If we have 0 = COND or 1 = COND equivalences, record them
 into our expression hash tables.  */
   for (i = 0; edge_info->cond_equivalences.iterate (i, ); ++i)
-   avail_exprs_stack->record_cond (eq);
+   {
+ avail_exprs_stack->record_cond (eq);
+
+ /* If the condition is testing that X == 0 is true or X != 0 is false
+and X is set from a BIT_IOR_EXPR, then we can record equivalences
+for the operands of the BIT_IOR_EXPR (and recurse on those).  */
+ tree op0 = eq->cond.ops.binary.opnd0;
+ tree op1 = eq->cond.ops.binary.opnd1;
+ if (TREE_CODE (op0) == SSA_NAME && integer_zerop (op1))
+   {
+ enum tree_code code = eq->cond.ops.binary.op;
+ if ((code == EQ_EXPR && eq->value == boolean_true_node)
+ || (code == NE_EXPR && eq->value == boolean_false_node))
+   derive_equivalencs_from_bit_ior (op0, const_and_copies);
+
+ /* TODO: We could handle BIT_AND_EXPR in a similar fashion
+recording that the operands have a nonzero value.  */
+
+ /* TODO: We can handle more cases here, particularly when OP0 is
+known to have a boolean range.  */
+   }
+   }
 
   tree lhs = edge_info->lhs;
   if (!lhs || TREE_CODE (lhs) != SSA_NAME)

[PATCH 2/5][P1][tree-optimization/71437] Record more equivalences in some cases

[Jeff Law]

Patch #3 will remove handle_dominating_asserts from the core of the jump 
threading code and push it into VRP's callbacks where it should always 
have been.


As a side effect it causes some code which was previously only used for 
threading from VRP to be used unconditionally.  It's actually a good 
thing as that code will find more jump threads.  But in one case  the 
resulting code is tougher for tree-ssa-uninit.c to handle and we get a 
false positive uninit warning.


As it turns out for that case we're better off improving DOM slightly 
which allows DOM to simplify the test even further.  This patch 
implements the DOM improvement so that we don't see a regression when 
patch #3 is installed.


The particular case we're looking to improve looks like

t = a | b;
if (t == 0)
...

In the TRUE arm we know that a must be zero and b must be zero. 
Discovering those equivalences allows DOM to do a better job for the 
uninit testcase from the testsuite.


There's clearly more that could be done with this code, but I didn't 
want to take it any further than was needed to address the regression 
that would be caused by patch #3.


Bootstrapped and regression tested on x86_64-linux-gnu.  Installing on 
the trunk.  I'll be testing this in combination with patch #1 tomorrow 
on ppc64le to get additional coverage.


Jeff

[PATCH 1/5][P1][tree-optimization/71437] Refactoring to avoid duplication

[Jeff Law]

As mentioned in the cover message, this is strictly a refactoring patch.

lookup_avail_expr should always have been a class member of the 
available expression stack.  That (of course) allows it to be used by 
any instance of the class (which we'll take advantage of later from 
within VRP's instance of jump threading).  We bring along vuse_eq as a 
dependency.


Similarly for record_cond which knows some internals of the hash table 
implementation.


record_conditions doesn't directly use the hash tables, but builds up a 
vector of conditions in hashable_expr form.  We're going to want to use 
this within the VRP threading instance as well.  We bring along 
build_and_record_new_cond as a dependency.


These routines all move with no significant change in their 
implementation except for avoiding dom_valueize, which we open code in 
the one spot it was previously used.



This has been bootstrapped and regression tested on x86_64-linux-gnu. 
Installing on the trunk.  I'll be doing a bootstrap and regression test 
of patch #1+#2 tomorrow on ppc64le for additional testing coverage.


Jeff
PR tree-optimization/71437
* tree-ssa-dom.c (struct cond_equivalence): Moved from here into
tree-ssa-scopedtables.
(lookup_avail_expr, build_and_record_new_cond): Likewise.
(record_conditions, record_cond, vuse_eq): Likewise.
(record_edge_info): Adjust to API tweak of record_conditions.
(simplify_stmt_for_jump_threading): Similarly for lookup_avail_expr.
(record_temporary_equivalences, optimize_stmt): Likewise.
(eliminate_redundant_computations): Likewise.
(record_equivalences_from_stmt): Likewise.
* tree-ssa-scopedtables.c: Include options.h and params.h.
(vuse_eq): New function, moved from tree-ssa-dom.c
(build_and_record_new_cond): Likewise.
(record_conditions): Likewise.  Accept vector of conditions rather
than edge_equivalence structure for first argument.
for the first argument.
(avail_exprs_stack::lookup_avail_expr): New member function, moved
from tree-ssa-dom.c.
(avail_exprs_stack::record_cond): Likewise.
* tree-ssa-scopedtables.h (struct cond_equivalence): Moved here
from tree-ssa-dom.c.
(avail_exprs_stack): Add new member functions lookup_avail_expr
and record_cond.
(record_conditions): Declare.


diff --git a/gcc/tree-ssa-dom.c b/gcc/tree-ssa-dom.c
index 2ec3f97..ad71269 100644
--- a/gcc/tree-ssa-dom.c
+++ b/gcc/tree-ssa-dom.c
@@ -48,15 +48,6 @@ along with GCC; see the file COPYING3.  If not see
 
 /* This file implements optimizations on the dominator tree.  */
 
-/* Structure for recording known values of a conditional expression
-   at the exits from its block.  */
-
-struct cond_equivalence
-{
-  struct hashable_expr cond;
-  tree value;
-};
-
 /* Structure for recording edge equivalences.
 
Computing and storing the edge equivalences instead of creating
@@ -103,9 +94,6 @@ static struct opt_stats_d opt_stats;
 static edge optimize_stmt (basic_block, gimple_stmt_iterator,
   class const_and_copies *,
   class avail_exprs_stack *);
-static tree lookup_avail_expr (gimple *, bool, class avail_exprs_stack *,
-  bool = true);
-static void record_cond (cond_equivalence *, class avail_exprs_stack *);
 static void record_equality (tree, tree, class const_and_copies *);
 static void record_equivalences_from_phis (basic_block);
 static void record_equivalences_from_incoming_edge (ba:sic_block,
@@ -175,148 +163,6 @@ free_all_edge_infos (void)
 }
 }
 
-/* Build a cond_equivalence record indicating that the comparison
-   CODE holds between operands OP0 and OP1 and push it to **P.  */
-
-static void
-build_and_record_new_cond (enum tree_code code,
-   tree op0, tree op1,
-   vec *p,
-  bool val = true)
-{
-  cond_equivalence c;
-  struct hashable_expr *cond = 
-
-  gcc_assert (TREE_CODE_CLASS (code) == tcc_comparison);
-
-  cond->type = boolean_type_node;
-  cond->kind = EXPR_BINARY;
-  cond->ops.binary.op = code;
-  cond->ops.binary.opnd0 = op0;
-  cond->ops.binary.opnd1 = op1;
-
-  c.value = val ? boolean_true_node : boolean_false_node;
-  p->safe_push (c);
-}
-
-/* Record that COND is true and INVERTED is false into the edge information
-   structure.  Also record that any conditions dominated by COND are true
-   as well.
-
-   For example, if a < b is true, then a <= b must also be true.  */
-
-static void
-record_conditions (struct edge_info *edge_info, tree cond, tree inverted)
-{
-  tree op0, op1;
-  cond_equivalence c;
-
-  if (!COMPARISON_CLASS_P (cond))
-return;
-
-  op0 = TREE_OPERAND (cond, 0);
-  op1 = TREE_OPERAND (cond, 1);
-
-  switch (TREE_CODE (cond))
-{
-case LT_EXPR:
-case GT_EXPR:
-  if (FLOAT_TYPE_P (TREE_TYPE (op0)))
-   {

[PATCH 0/5 ][P1] [PR tree-optimization/71437]

[Jeff Law]

So as noted in the PR, we're failing to discover an important jump 
thread during threading from VRP.  This is a case where the symbolic 
range is actually more useful than constants in the range.


There's some talk of improving this in VRP for gcc-8, but in the mean 
time, fixing this by improving threading is feasible and actually takes 
a useful step in the long term plan.


The central idea here is to allow the VRP instance of jump threading to 
record conditions from ASSERT_EXPRs into the available expression table. 
 We can see the symbolic ranges from those expressions.  Of course, 
there's some bits to put in place first.


Patch #1 is pure refactoring/movement.  A couple routines are turned 
into member functions of the scoped hash tables and another is kept as 
normal function but moved into a more natural location which also makes 
it available in DOM and VRP.


Patch #2 improves DOM's ability to discover implied equivalences when an 
object is known to have the value 0.  This avoids a regression due to 
changes in patch #3.  There's more that could be done here.  But I've 
tried to keep the scope of what's changing small due to being in stage4.


Patch #3 pushes ASSERT_EXPR handling out of the core of the threader and 
into callbacks used by VRP.  It should have been done this way to begin 
with.  It's so painfully obvious 10+ years later.


Patch #4 turns random order walk for threading from VRP into a domwalk 
and refactors some common code from VRP/DOM into the threader itself.


Patch #5 allows recording equivalences from ASSERT_EXPRs and looking up 
objects in the expression hash table in the VRP threading callback.  At 
which point we're done.  Not surprisingly, with the infrastructure in 
place patch #5 is actually trivial.


The set looks much bigger than it really is.  That's largely because of 
refactoring that's going on.


Commit plan:

I'm committing patches #1 and #2 together and giving them ~12hrs to 
simmer.  The improvements in DOM could possibly trigger the need to 
adjust expected outputs of tests.  I haven't seen in the need on x86.


I'm going to be doing some ppc64le testing tomorrow.  It's been 
surprisingly hard to get a machine from our testpool.


Assuming no issues with #1/#2, then I'll proceed to #3/#4.  I don't have 
any real concerns with #3/#4, but I want to isolate them from #5 just in 
case #5 needs further testsuite tweakage.  Assuming all goes well, #5 
would be committed Friday.



Jeff

[Bug c++/58054] [DR 372] 11.3 Friends, example from standard not compiled

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
  Known to work||4.9.0, 5.3.0, 6.3.0, 7.0
 Resolution|--- |FIXED

--- Comment #5 from Martin Sebor  ---
The test cases in comment #0 and comment #2 both compile with recent versions
of GCC.  Bisection points to r206933 (gcc 4.9.0) as the commit that fixed it. 
Resolving as fixed.

[Bug middle-end/51428] Some code after SSA expand does nothing

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-03-16
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
After some grepping I found the comment you are referring to in gcc/expr.c.  It
sounds to me as though you are suggesting that the whole if statement below is
dead and should be removed.  Some light testing seems to confirm that removing
it has no effect on the C test suite.  The comment that starts with ??? below
the part you quoted seems to imply it's intentional, so I'm not sure what to
make of this report.

Andrew, before I close this bug, would you like to shed some light on what you
had in mind here?  What sort of a resolution are you looking for?

rtx
expand_expr_real_1 (tree exp, rtx target, machine_mode tmode,
enum expand_modifier modifier, rtx *alt_rtl,
bool inner_reference_p)
{
  ...
case MODIFY_EXPR:
  {
tree lhs = treeop0;
tree rhs = treeop1;
gcc_assert (ignore);

/* Check for |= or &= of a bitfield of size one into another bitfield
   of size 1.  In this case, (unless we need the result of the
   assignment) we can do this more efficiently with a
   test followed by an assignment, if necessary.

   ??? At this point, we can't get a BIT_FIELD_REF here.  But if
   things change so we do, this code should be enhanced to
   support it.  */
if (TREE_CODE (lhs) == COMPONENT_REF
&& (TREE_CODE (rhs) == BIT_IOR_EXPR
|| TREE_CODE (rhs) == BIT_AND_EXPR)
&& TREE_OPERAND (rhs, 0) == lhs
&& TREE_CODE (TREE_OPERAND (rhs, 1)) == COMPONENT_REF
&& integer_onep (DECL_SIZE (TREE_OPERAND (lhs, 1)))
&& integer_onep (DECL_SIZE (TREE_OPERAND (TREE_OPERAND (rhs, 1),
1
  {
rtx_code_label *label = gen_label_rtx ();
int value = TREE_CODE (rhs) == BIT_IOR_EXPR;
do_jump (TREE_OPERAND (rhs, 1),
 value ? label : 0,
 value ? 0 : label, -1);
expand_assignment (lhs, build_int_cst (TREE_TYPE (rhs), value),
   false);
do_pending_stack_adjust ();
emit_label (label);
return const0_rtx;
  }

expand_assignment (lhs, rhs, false);
return const0_rtx;
  }

[Bug middle-end/80042] gcc thinks sin/cos don't set errno

[craig.topper at gmail dot com]

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

--- Comment #3 from Craig Topper  ---
No -fmath-errno has no effect. It does have effect on other functions such as
cosh or acos.

[Bug c++/70515] Nested lambdas causing invalid captured pointers on some platforms

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-03-16
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Martin Sebor  ---
I also cannot reproduce it with 7.0 on powepc64le or with 5.x on x86_64.  Can
you please list the processor architectures you see this problem on? 
(Providing the output of gcc -v should help.)

[Bug c++/79790] [C++17] ICE class template argument deduction failed

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-16
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Martin Sebor  ---
Oddly, I'm not able to reproduce the ICE with the test case with today's top of
trunk or any recent revisions (February through March 2017).  They all issue
the error below and exit:

t.C:4:29: error: cannot deduce template arguments for ‘std::array<_Tp, _Nm>’,
as it has no deduction guides or user-declared constructors
   constexpr const int& operator[](int i) const { return a[i]; }
 ^

But the following test case does reproduce it:

$ cat t.C && gcc -Wall -Wextra -Wpedantic -std=c++1z t.C
template 
struct array
{
  int a [N];
};

array a = { 1, 2, 3 };
t.C:7:21: error: class template argument deduction failed:
 array a = { 1, 2, 3 };
 ^
t.C:7:21: internal compiler error: Segmentation fault
0x1174c74 crash_signal
/src/gcc/svn/gcc/toplev.c:337
0x7b8893 print_error_for_call_failure
/src/gcc/svn/gcc/cp/call.c:4170
0x7b8ab9 build_new_function_call(tree_node*, vec**, bool, int)
/src/gcc/svn/gcc/cp/call.c:4224
0x8a5474 do_class_deduction
/src/gcc/svn/gcc/cp/pt.c:25270
0x8a562b do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
/src/gcc/svn/gcc/cp/pt.c:25322
0x7f5d61 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
/src/gcc/svn/gcc/cp/decl.c:6835
0x9419c3 cp_parser_init_declarator
/src/gcc/svn/gcc/cp/parser.c:19384
0x935b04 cp_parser_simple_declaration
/src/gcc/svn/gcc/cp/parser.c:12781
0x93567c cp_parser_block_declaration
/src/gcc/svn/gcc/cp/parser.c:12599
0x9353fe cp_parser_declaration
/src/gcc/svn/gcc/cp/parser.c:12496
0x934f5d cp_parser_declaration_seq_opt
/src/gcc/svn/gcc/cp/parser.c:12372
0x923dc1 cp_parser_translation_unit
/src/gcc/svn/gcc/cp/parser.c:4366
0x9742a4 c_parse_file()
/src/gcc/svn/gcc/cp/parser.c:38423
0xb27abd c_common_parse_file()
/src/gcc/svn/gcc/c-family/c-opts.c:1107
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/80042] gcc thinks sin/cos don't set errno

[egall at gwmail dot gwu.edu]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #2 from Eric Gallager  ---
Does toggling the flag -fmath-errno have any effect?

[Bug debug/43989] g++ missing the debug information of unused local static variable

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
  Known to work||5.3.0, 6.3.0, 7.0
 Resolution|--- |WORKSFORME

--- Comment #1 from Martin Sebor  ---
I cannot reproduce the GDB problem with supported versions of GCC.  Resolving
as WorksForSome.  (Please report bugs in Red Hat GCC to Red Hat at
https://bugzilla.redhat.com.

$ (cat t.C && cc='/build/gcc-git/gcc/xg++ -B /build/gcc-git/gcc -L
/build/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs'; $cc -g t.C &&
objdump -W a.out | grep ": varIn" && gdb -batch -ex 'b main' -ex 'b Function'
-ex r -ex c -ex 'p varInFunc' -ex fin -ex 'p varInMain' a.out)
void Function()
{
  static int varInFunction = 2;
}

int main()
{
   static int varInMain = 1;
   Function();
}
<4f>   DW_AT_name: (indirect string, offset: 0x19): varInMain
<89>   DW_AT_name: (indirect string, offset: 0x0): varInFunction
Breakpoint 1 at 0x40053d: file t.C, line 9.
Breakpoint 2 at 0x400536: file t.C, line 4.

Breakpoint 1, main () at t.C:9
9  Function();

Breakpoint 2, Function () at t.C:4
4   }
No symbol "varInFunc" in current context.
main () at t.C:10
10  }
$1 = 1

[Bug bootstrap/47591] libiberty Makefile uses native cc (solaris) with option -print-multi-os-directory

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||build
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-03-16
 CC||msebor at gcc dot gnu.org
  Component|other   |bootstrap
 Ever confirmed|0   |1

--- Comment #3 from Martin Sebor  ---
I can't reproduce this with GCC 7.0 in a similar environment.  Can you please
confirm that this is still an issue with a recent/supported version of GCC?

[Bug c++/70377] "unexpected AST" and "confused by earlier errors, bailing out" from throw in simple constexpr fn

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
I've raised bug 80061 for the error GCC issues for the submitted test case
after the bug(s) in have been corrected.

[Bug c++/80061] New: error on constexpr function with an unevaluated throw

[msebor at gcc dot gnu.org]

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

Bug ID: 80061
   Summary: error on constexpr function with an unevaluated throw
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The following valid test case was reduced from the invalid one submitted with
bug 70377.  GCC rejects the constexpr function simple_find because it contains
a throw statement even though the statement is not evaluated in the (constexpr)
contexts the function is called.  Clang 5.0 and EDG eccp 4.13 both accept the
program.

$ cat t.C && gcc -Wall -Wextra -Wpedantic t.C
struct array
{
  int a [3];
  constexpr const int& operator[](int i) const { return a[i]; }
};

constexpr int
simple_find (const array , int x)
{
  for (int i = 0; i != 3; ++i)
if (a[i] == x)
  return i;

  throw;
}

static constexpr array some_ints { { 10, 11 } };

static_assert (simple_find (some_ints, 10) == 0, "#1");
static_assert (simple_find (some_ints, 11) == 1, "#2");
t.C: In function ‘constexpr int simple_find(const array&, int)’:
t.C:14:3: error: expression ‘’ is not a constant expression
   throw;
   ^
t.C: At global scope:
t.C:19:1: error: non-constant condition for static assertion
 static_assert (simple_find (some_ints, 10) == 0, "#1");
 ^
t.C:19:28: error: ‘constexpr int simple_find(const array&, int)’ called in a
constant expression
 static_assert (simple_find (some_ints, 10) == 0, "#1");
^~~
t.C:20:1: error: non-constant condition for static assertion
 static_assert (simple_find (some_ints, 11) == 1, "#2");
 ^
t.C:20:28: error: ‘constexpr int simple_find(const array&, int)’ called in a
constant expression
 static_assert (simple_find (some_ints, 11) == 1, "#2");
^~~

[Bug c++/70377] "unexpected AST" and "confused by earlier errors, bailing out" from throw in simple constexpr fn

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-16
 CC||msebor at gcc dot gnu.org
Version|unknown |5.4.1
 Ever confirmed|0   |1
  Known to fail||5.4.0

--- Comment #1 from Martin Sebor  ---
The ICE is reproducible with 5.x but it's gone in 6.x and 7.0 (those fail to
compile the code due to what looks like a bug in the test case, hence
ice-on-invalid-code, error-recovery).

The GCC 5 ICE for the submitted test case is below:

t.C:19:1: error: non-constant condition for static assertion
 static_assert( simple_find( some_ints, 10 ) == static_cast( 0 ), "" );
 ^
t.C:19:27: error: ‘constexpr size_t simple_find(const std::array&,
const int&) [with long unsigned int N = 3ul; size_t = long unsigned int]’
called in a constant expression
 static_assert( simple_find( some_ints, 10 ) == static_cast( 0 ), "" );
   ^
t.C:6:18: note: ‘constexpr size_t simple_find(const std::array&, const
int&) [with long unsigned int N = 3ul; size_t = long unsigned int]’ is not
usable as a constexpr function because:
 constexpr size_t simple_find(const std::array _array,
  ^
t.C:6:18: sorry, unimplemented: unexpected AST of kind loop_expr
t.C:6:18: internal compiler error: in potential_constant_expression_1, at
cp/constexpr.c:4780
0x9ab300 potential_constant_expression_1
/src/gcc/5-branch/gcc/cp/constexpr.c:4780
0x9a9a50 potential_constant_expression_1
/src/gcc/5-branch/gcc/cp/constexpr.c:4376
0x9a9a50 potential_constant_expression_1
/src/gcc/5-branch/gcc/cp/constexpr.c:4376
0x9aa7c3 potential_constant_expression_1
/src/gcc/5-branch/gcc/cp/constexpr.c:4564
0x9a9a50 potential_constant_expression_1
/src/gcc/5-branch/gcc/cp/constexpr.c:4376
0x9aa7c3 potential_constant_expression_1
/src/gcc/5-branch/gcc/cp/constexpr.c:4564
0x9ab3d4 require_potential_rvalue_constant_expression(tree_node*)
/src/gcc/5-branch/gcc/cp/constexpr.c:4821
0x99c9cc explain_invalid_constexpr_fn(tree_node*)
/src/gcc/5-branch/gcc/cp/constexpr.c:853
0x99df02 cxx_eval_call_expression
/src/gcc/5-branch/gcc/cp/constexpr.c:1271
0x9a5acf cxx_eval_constant_expression
/src/gcc/5-branch/gcc/cp/constexpr.c:3331
0x99f55f cxx_eval_binary_expression
/src/gcc/5-branch/gcc/cp/constexpr.c:1648
0x9a6b0a cxx_eval_constant_expression
/src/gcc/5-branch/gcc/cp/constexpr.c:3600
0x9a7b35 cxx_eval_outermost_constant_expr
/src/gcc/5-branch/gcc/cp/constexpr.c:3864
0x9a8191 cxx_constant_value(tree_node*, tree_node*)
/src/gcc/5-branch/gcc/cp/constexpr.c:3953
0x91a03d finish_static_assert(tree_node*, tree_node*, unsigned int, bool)
/src/gcc/5-branch/gcc/cp/semantics.c:7203
0x86bb74 cp_parser_static_assert
/src/gcc/5-branch/gcc/cp/parser.c:12233
0x86ace6 cp_parser_block_declaration
/src/gcc/5-branch/gcc/cp/parser.c:11478
0x86aa89 cp_parser_declaration
/src/gcc/5-branch/gcc/cp/parser.c:11379
0x86a63e cp_parser_declaration_seq_opt
/src/gcc/5-branch/gcc/cp/parser.c:11265
0x85db76 cp_parser_translation_unit
/src/gcc/5-branch/gcc/cp/parser.c:4100
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/80043] [6/7 Regression] ICE with pointer-to-member-function and -fpermissive

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |ice-on-invalid-code
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Jason Merrill  ---
Fixed for gcc 7.

[Bug c++/39982] Fail to use constructor to initialize volatile declaration (no matching function for call)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
  Known to work||4.9.0, 5.3.0, 6.3.0, 7.0
 Resolution|--- |FIXED
  Known to fail||4.3.2

--- Comment #2 from Martin Sebor  ---
The code is accepted by GCC 7.0.  Looks like the bug was fixed in r210284 (gcc
4.10.0):

r210284 | jason | 2014-05-09 14:16:11 -0400 (Fri, 09 May 2014) | 4 lines

DR 5
PR c++/60019
* call.c (build_user_type_conversion_1): The copy-init temporary
is cv-unqualified.

[Bug c++/69054] g++ fails to diagnose ambiguous overload resolution when implicit conversions are involved

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-16
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.1.3, 4.2.2, 4.3.2, 4.6.0,
   ||5.4.0, 6.3.0, 7.0

--- Comment #1 from Martin Sebor  ---
Confirmed with today's top of trunk (GCC 7.0) and all released versions.

EDG eccp 4.13 reports:

"t.C", line 19: error: more than one operator "[]" matches these operands:
built-in operator "integer[pointer-to-object]"
function "Something::operator[](const foo &)"
operand types are: Something [ const char [3] ]
  d["32"];
   ^

1 error detected in the compilation of "t.C".

[Bug bootstrap/53731] [4.7] Bootstrap fails for libgfortran on Solaris 10 x86 with error "Where has __float128 gone?"

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #3 from Martin Sebor  ---
GCC 4.7 is no longer maintained.  Current trunk of GCC 7.0 has been reported to
successfully bootstrap on Solaris 11
(https://gcc.gnu.org/ml/gcc-testresults/2017-03/msg01380.html) and Solaris 12
(https://gcc.gnu.org/ml/gcc-testresults/2017-03/msg01377.html).  There are no
recent reports for older Solaris and I'm not sure it's supported/maintained
there.  Please try a more recent GCC (ideally on newer Solaris if you can). 
I'm closing this as won't fix due to 4 years with no activity.

[Bug middle-end/68069] -fstack-protector does not protect from buffer overflow attack

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Resolving as invalid on the basis of comment #3 (and due to no
counterargument).  

The problem is caught by -fsanitize=undefined (although the handling isn't the
most elegant -- the program is stuck in the fscanf loop and never terminates).

$ gcc -fsanitize=undefined t.c && ./a.out 
t.c: In function ‘f’:
t.c:13:20: warning: cast from pointer to integer of different size
[-Wpointer-to-int-cast]
 printf("%d\n", (int) f2);
^
t.c:19:11: warning: assignment makes pointer from integer without a cast
[-Wint-conversion]
  arr[++i] = cur;
   ^
4196614
1
t.c:19:5: runtime error: index 2 out of bounds for type 'int *[1]'
t.c:19:11: runtime error: store to address 0x7ffe793c7f60 with insufficient
space for an object of type 'int *'
0x7ffe793c7f60: note: pointer points here
 02 00 00 00  00 00 00 00 00 00 00 00  10 08 40 00 00 00 00 00  80 7f 3c 79 fe
7f 00 00  37 0a 40 00
  ^ 
4196614

[Bug c/44943] Need documentation on the intended semantics of "volatile" (in C)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from Martin Sebor  ---
I believe this request was largely resolved in r163400 by moving the C++
documentation of volatile accesses to the C manual.

The additional sentence (underlined in comment #0) wasn't added but to me the
text just before it implies it.  If you'd still like it added please reopen the
bug.

[Bug bootstrap/57683] Parallel build failure: generated prerequisite header not built in time (insn-opinit.h)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-03-15
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Does the commit referenced in comment #1 fix the problem?

[Bug target/60515] Compiler crash with -g and -mpoke-function-name option combined

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from Martin Sebor  ---
I cannot reproduce the ICE with today's top of trunk (GCC 7.0) so it has
apparently been fixed.

[Bug c/67479] Support for -Wformat-pedantic

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=78014,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80060

--- Comment #7 from Martin Sebor  ---
See also bug 78014 and bug 80060.  They're not about exactly the same thing but
similarly to this report they also discuss adding a new -Wformat option to
subset the checker into two (or more) portability categories.

[PATCH rs6000] Fix PR79951, ICE for unrecognizable insn with -mno-cmpb

[Pat Haugen]

The define_expand for copysign3 will call
gen_copysign3_fcpsgn if either TARGET_CMPB || VECTOR_UNIT_VSX_P
(mode) are true, but gen_copysign3_fcpsgn is missing the
check of VECTOR_UNIT_VSX_P (mode) which results in an
unrecognizable insn ICE. This is fixed with the following patch.

Bootstrap/regtest on powerpc64le with no new regressions. Ok for trunk?
Ok for backport to GCC 5/6 branches after testing?

-Pat


2017-03-15  Pat Haugen  

PR target/79951
* config/rs6000/rs6000.md (copysign3_fcpsgn): Test
for VECTOR_UNIT_VSX_P (mode) too.

testsuite/ChangeLog:
2017-03-15  Pat Haugen  

* gcc.target/powerpc/pr79951.c: New.



Index: config/rs6000/rs6000.md
===
--- config/rs6000/rs6000.md (revision 246180)
+++ config/rs6000/rs6000.md (working copy)
@@ -4831,7 +4831,7 @@ (define_insn "copysign3_fcpsgn"
(unspec:SFDF [(match_operand:SFDF 1 "gpc_reg_operand" ",")
  (match_operand:SFDF 2 "gpc_reg_operand" ",")]
 UNSPEC_COPYSIGN))]
-  "TARGET__FPR && TARGET_CMPB"
+  "TARGET__FPR && (TARGET_CMPB || VECTOR_UNIT_VSX_P (mode))"
   "@
fcpsgn %0,%2,%1
xscpsgndp %x0,%x2,%x1"
Index: testsuite/gcc.target/powerpc/pr79951.c
===
--- testsuite/gcc.target/powerpc/pr79951.c  (nonexistent)
+++ testsuite/gcc.target/powerpc/pr79951.c  (working copy)
@@ -0,0 +1,10 @@
+/* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-require-effective-target powerpc_p8vector_ok } */
+/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" }
{ "-mcpu=power8" } } */
+/* { dg-options "-mcpu=power8 -S -mno-cmpb" } */
+
+float testf (float x, float y)
+{
+  return __builtin_copysignf (x, y);
+}
+

[Bug c++/78014] -Wformat -vs- size_t

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-15
 Ever confirmed|0   |1

--- Comment #6 from Martin Sebor  ---
Confirmed on the same basis as bug 80060.

[Bug c/80060] RFE: -Wformat knob to ignore same-width incorrect types

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-15
 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=78014,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=77970
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Martin Sebor  ---
Confirmed.  I think this request falls into the same class as bug 78014 and bug
77970.

patch to fix PR80017

[Vladimir Makarov]

The following patch fixes

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

The patch was successfully bootstrapped and tested on x86-64, ppc64, and 
aarch64.


Committed as rev. 246181.

Index: ChangeLog
===
--- ChangeLog	(revision 246180)
+++ ChangeLog	(working copy)
@@ -1,3 +1,9 @@
+2017-03-15  Vladimir Makarov  
+
+	PR target/80017
+	* lra-constraints.c (process_alt_operands): Increase reject for
+	reloading an input/output operand.
+
 2017-03-15  Michael Meissner  
 
 	PR target/79038
Index: lra-constraints.c
===
--- lra-constraints.c	(revision 246180)
+++ lra-constraints.c	(working copy)
@@ -2713,6 +2713,15 @@ process_alt_operands (int only_alternati
 
 	  if (MEM_P (op) && offmemok)
 		addr_losers++;
+	  else if (curr_static_id->operand[nop].type == OP_INOUT)
+		{
+		  if (lra_dump_file != NULL)
+		fprintf
+		  (lra_dump_file,
+		   "%d Input/Output reload: reject+=%d\n",
+		   nop, LRA_LOSER_COST_FACTOR);
+		  reject += LRA_LOSER_COST_FACTOR;
+		}
 	}
 
 	  if (early_clobber_p && ! scratch_p)

Re: [v3 PATCH] Implement LWG 2857, {variant,optional,any}::emplace should return the constructed value.

[Jonathan Wakely]

On 16/03/17 00:43 +0200, Ville Voutilainen wrote:

On 16 March 2017 at 00:31, Jonathan Wakely  wrote:

  emplace(_Args&&... __args)
  {
__do_emplace<_Decay<_ValueType>>
  (std::forward<_Args>(__args)...);
+   return *(std::any_cast<_Decay<_ValueType>>(this));



Can we avoid the branch in any_cast to check the stored type?
We know it's the right type, because we just stored it.


While I would hope the compiler to be smart enough to realize some of
that (we are passing in
this), the other branches might not be so easy. But certainly, we can
axe every one of the extraneous
branches, like in the attached amendment.


And then we don't need the forward declarations of any and any_ast,
right?

OK for trunk like that, thanks.

[Bug target/80017] [5/6/7 Regression] ICE: Max. number of generated reload insns per insn is achieved (90)

[vmakarov at gcc dot gnu.org]

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

--- Comment #2 from Vladimir Makarov  ---
Author: vmakarov
Date: Wed Mar 15 23:04:09 2017
New Revision: 246181

URL: https://gcc.gnu.org/viewcvs?rev=246181=gcc=rev
Log:
2017-03-15  Vladimir Makarov  

PR target/80017
* lra-constraints.c (process_alt_operands): Increase reject for
reloading an input/output operand.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c

[Bug c++/52477] Wrong initialization order? __attribute__((constructor)) vs static data access

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #5 from Martin Sebor  ---
Resolving as invalid based on comment #3.  The manual does seem to suggest that
this should work:

   "The priorities for constructor and destructor functions are the same as
those specified for namespace-scope C++ objects (see C++ Attributes)."

Let me add a blurb to make clear that the order between C++ ctors and functions
declared attribute constructor is unspecified.

Blurb posted for review:
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00863.html

[PATCH C++] document order of C++ ctors and attribute constructor is unspecified

[Martin Sebor]

In bug 52477 - Wrong initialization order?  attribute constructor
vs static data access, the reporter expects C++ objects with static
storage duration to have their ctors called in the same order as
those of functions declared with attribute constructor interleaved
with them.

In his comment on the bug Richard opines that relying on the order
is undefined.  The attached patch updates the manual to make this
clear.

Jason, can you please review it for 7.0?

Martin
PR c++/52477 - Wrong initialization order? __attribute__((constructor)) vs static data access

gcc/ChangeLog:

	PR c++/52477
	* doc/extend.texi (attribute constructor): Mention order of C++ ctors.

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 143a7b7..159f1be 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -2510,7 +2510,11 @@ if you have a constructor that allocates a resource and a destructor
 that deallocates the same resource, both functions typically have the
 same priority.  The priorities for constructor and destructor
 functions are the same as those specified for namespace-scope C++
-objects (@pxref{C++ Attributes}).
+objects (@pxref{C++ Attributes}).  However, the order in which
+constructors for C++ objects with static storage duration and functions
+decorated with attribute @code{constructor} are invoked is unspecified.
+In mixed declarations, attribute @code{init_priority} can be used to
+impose a specific ordering.
 
 @item deprecated
 @itemx deprecated (@var{msg})

Re: [v3 PATCH] Implement LWG 2857, {variant,optional,any}::emplace should return the constructed value.

[Ville Voutilainen]

On 16 March 2017 at 00:31, Jonathan Wakely  wrote:
>>   emplace(_Args&&... __args)
>>   {
>> __do_emplace<_Decay<_ValueType>>
>>   (std::forward<_Args>(__args)...);
>> +   return *(std::any_cast<_Decay<_ValueType>>(this));
>
>
> Can we avoid the branch in any_cast to check the stored type?
> We know it's the right type, because we just stored it.

While I would hope the compiler to be smart enough to realize some of
that (we are passing in
this), the other branches might not be so easy. But certainly, we can
axe every one of the extraneous
branches, like in the attached amendment.
diff --git a/libstdc++-v3/include/std/any b/libstdc++-v3/include/std/any
index fff13d9..ef6efa5 100644
--- a/libstdc++-v3/include/std/any
+++ b/libstdc++-v3/include/std/any
@@ -278,7 +278,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   {
__do_emplace<_Decay<_ValueType>>
  (std::forward<_Args>(__args)...);
-   return *(std::any_cast<_Decay<_ValueType>>(this));
+   any::_Arg __arg;
+   this->_M_manager(any::_Op_access, this, &__arg);
+   return *static_cast<_Decay<_ValueType>*>(__arg._M_obj);
   }
 
 /// Emplace with an object created from @p __il and @p __args as
@@ -292,7 +294,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   {
__do_emplace<_Decay<_ValueType>, _Up>
  (__il, std::forward<_Args>(__args)...);
-   return *(std::any_cast<_Decay<_ValueType>>(this));
+   any::_Arg __arg;
+   this->_M_manager(any::_Op_access, this, &__arg);
+   return *static_cast<_Decay<_ValueType>*>(__arg._M_obj);
   }
 
 // modifiers
diff --git a/libstdc++-v3/testsuite/20_util/any/misc/any_cast_neg.cc 
b/libstdc++-v3/testsuite/20_util/any/misc/any_cast_neg.cc
index 2d2b3d3..8e3ca73 100644
--- a/libstdc++-v3/testsuite/20_util/any/misc/any_cast_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/any/misc/any_cast_neg.cc
@@ -26,5 +26,5 @@ void test01()
   using std::any_cast;
 
   const any y(1);
-  any_cast(y); // { dg-error "invalid static_cast" "" { target { *-*-* } 
} 461 }
+  any_cast(y); // { dg-error "invalid static_cast" "" { target { *-*-* } 
} 465 }
 }

[Bug c/80060] New: RFE: -Wformat knob to ignore same-width incorrect types

[eblake at redhat dot com]

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

Bug ID: 80060
   Summary: RFE: -Wformat knob to ignore same-width incorrect
types
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eblake at redhat dot com
  Target Milestone: ---

When porting from one machine to another, especially when porting from 32-bit
to 64-bit software, getting warnings about mismatches such as printf("%ld",
(uint32_t)1) is awesome.  But once something has been ported to a given
platform, if two types have the same size but different rank, getting warnings
about something that is not portable to other machines but which works in
practice on the given machine is very noisy.  And sometimes, the noise is
unavoidable - there are many situations in which different implementations can
pick a type that is consistent for their platform, but uses a different rank
than what another platform chose - not all the world uses the  types,
but has a variety of other typedefs in place.

Here's some examples: on 64-bit Linux, the header 
declares a struct with members specified with a typedef __u64:

struct uffd_msg msg;
struct uffd_msg {
..
union {
struct {
__u64   flags;
__u64   address;
} pagefault;
..
} arg;
}

Printing one of these values is obvious - the typedef name tells you it should
be an unsigned 64-bit quantity, so let's try printf("%"PRIx64,
msg.arg.pagefault.flags).  Oops, on 64-bit Linux, that fails under -Wformat,
because "%ld" is incompatible with 'unsigned long long'.  But since the kernel
headers typedef'd __u64 without any counterpart to something like PRIx64, there
is no sane way to print a __u64 without writing an extra cast at every caller,
which is prone to introduce more bugs than the warnings it silences:
printf("%"PRIx64, (uint64_t)msg.arg.pagefault.flags).

Another case: on 32-bit mingw, the declaration for ntohl() says that it returns
a 'u_long', which is a 32-bit type.  But POSIX says that ntohl() returns
'uint32_t'.  So the obvious printf("%"PRIx32, ntohl(1)) fails to compile on
mingw, because 'u_long' (which is 'unsigned long') is incompatible with
'uint32_t' (which is 'unsigned int') on that platform (arguably a bug in
mingw's headers, but such is life).  Again, the mismatch warning can be avoided
with a cast, but that does not scale well: printf("%"PRIx32,
(uint32_t)ntohl(1))

gcc recently introduced -Wformat-signedness (and it's counterpart
-Wno-format-signedness) to let developers fine-tune how MUCH verbosity they
want during warning checks.  Are you porting code to a platform where 'int' and
'unsigned int' have different widths? (Some weirdnix hardware might exist like
that, and C seems to make it possible, even though I can't name such a system)
- then turn the warning on. But if you really DON'T care about "%d" used with
'unsigned', or "%x" used with 'int' (because in the end, the 32-bit value
passed through varargs gets reinterpreted into the correct 32-bit value that
gets printed, regardless of intermediate sign-incorrectness), then turn it off.

So I'd love to have a new knob, maybe named -Wformat-same-rank, which controls
whether gcc warns about using the wrong format specifier EVEN THOUGH the type
passed to varargs has the same rank and therefore will print accurately; and
projects can then use -Wno-format-same-rank to silence __u64/uint64_t or
u_long/uint32_t differences while still getting warnings about real bugs of
32-bit vs. 64-bit mismatches.

Re: [v3 PATCH] Implement LWG 2857, {variant,optional,any}::emplace should return the constructed value.

[Jonathan Wakely]

On 16/03/17 00:21 +0200, Ville Voutilainen wrote:

Tested on Linux-x64.

2017-03-16  Ville Voutilainen  

   Implement LWG 2857, {variant,optional,any}::emplace should
   return the constructed value.
   * include/std/any (any_cast(any*)): Forward-declare.
   (emplace(_Args&&...)): Change the return type and
   return a reference to the constructed value.
   (emplace(initializer_list<_Up>, _Args&&...)): Likewise.
   * include/std/optional (emplace(_Args&&...)): Likewise.
   (emplace(initializer_list<_Up>, _Args&&...)): Likewise.
   * include/std/variant (emplace<_Tp>(_Args&&...)): Likewise.
   (emplace<_Tp>(initializer_list<_Up>, _Args&&...)): Likewise.
   (emplace<_Np>(_Args&&...)): Likewise.
   (emplace<_Np>(initializer_list<_Up>, _Args&&...)): Likewise.
   * testsuite/20_util/any/assign/emplace.cc: Add tests for
   checking the return value of emplace.
   * testsuite/20_util/any/misc/any_cast_neg.cc: Adjust.
   * testsuite/20_util/optional/assignment/6.cc: Add tests for
   checking the return value of emplace.
   * testsuite/20_util/variant/run.cc: Likewise.



diff --git a/libstdc++-v3/include/std/any b/libstdc++-v3/include/std/any
index e807617..fff13d9 100644
--- a/libstdc++-v3/include/std/any
+++ b/libstdc++-v3/include/std/any
@@ -74,6 +74,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   *  An @c any object's state is either empty or it stores a contained object
   *  of CopyConstructible type.
   */
+  class any;
+  template
+inline _ValueType* any_cast(any* __any) noexcept;
+
  class any
  {
// Holds either pointer to a heap object or the contained object itself.
@@ -268,18 +272,19 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION

/// Emplace with an object created from @p __args as the contained object.
template 
-  typename __any_constructible&,
   _Decay<_ValueType>, _Args&&...>::type
  emplace(_Args&&... __args)
  {
__do_emplace<_Decay<_ValueType>>
  (std::forward<_Args>(__args)...);
+   return *(std::any_cast<_Decay<_ValueType>>(this));


Can we avoid the branch in any_cast to check the stored type?
We know it's the right type, because we just stored it.

[PATCH], PR target/71294, Fix compiler segfault for reload & power8

[Michael Meissner]

This patch is a simpler approach to fixing PR 71294, then I proposed last year.

The core of the problem is when we are creating V2DI/V2DF vectors via a splat
operation, the predicate for the second argument allows memory addresses, GPR
registers as well as VSX registers, but when we compile for power8, the
constraints only allow memory addresses and VSX registers.

I fixed this by allowing a GPR -> VSX splat operation and after reload,
splitting it to the appropriate scalar direct move and then XXPERMDI to form
the vector.  I did look at changing the splat_input_operation predicate to not
allow GPR registers in this case, but reload generates worse code in this case.

I have built compilers on a little endian Power8 system (64-bit only), big
endian Power8 system (64-bit only) and big endian Power7 system (32-bit and
64-bit).  At the moment, the two power8 systems have no regressions, and the
power7 system is still building.  Assuming the power7 system completes without
regressions, can I check this patch into the trunk?

Assuming the patch applies and causes no regressions, can I check this patch
into GCC 6 and 5 as well.  Since GCC 6/5 do run with reload as the default,
they would likely see the issue.  GCC 7 has switched to LRA, which is more
robust, and doesn't show the problem (unless you use the -mno-lra switch).

[gcc]
2017-03-15  Michael Meissner  

PR target/71294
* config/rs6000/vsx.md (vsx_splat_, VSX_D iterator): Allow a
SPLAT operation on ISA 2.07 64-bit systems that have direct move,
but no MTVSRDD support, by doing MTVSRD and XXPERMDI.

[gcc/testsuite]
2017-03-15  Michael Meissner  

PR target/71294
* g++.dg/pr71294.C: New test.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/vsx.md
===
--- gcc/config/rs6000/vsx.md(revision 246137)
+++ gcc/config/rs6000/vsx.md(working copy)
@@ -3067,16 +3067,29 @@ (define_expand "vsx_mergeh_"
 })
 
 ;; V2DF/V2DI splat
-(define_insn "vsx_splat_"
-  [(set (match_operand:VSX_D 0 "vsx_register_operand" "=,,we")
+(define_insn_and_split "vsx_splat_"
+  [(set (match_operand:VSX_D 0 "vsx_register_operand"
+   "=,,we,")
(vec_duplicate:VSX_D
-(match_operand: 1 "splat_input_operand" ",Z,b")))]
+(match_operand: 1 "splat_input_operand"
+   ",Z,b, wr")))]
   "VECTOR_MEM_VSX_P (mode)"
   "@
xxpermdi %x0,%x1,%x1,0
lxvdsx %x0,%y1
-   mtvsrdd %x0,%1,%1"
-  [(set_attr "type" "vecperm,vecload,vecperm")])
+   mtvsrdd %x0,%1,%1
+   #"
+  "&& reload_completed && TARGET_POWERPC64 && !TARGET_P9_VECTOR
+   && int_reg_operand (operands[1], mode)"
+  [(set (match_dup 2)
+   (match_dup 1))
+   (set (match_dup 0)
+   (vec_duplicate:VSX_D (match_dup 2)))]
+{
+  operands[2] = gen_rtx_REG (mode, reg_or_subregno (operands[0]));
+}
+  [(set_attr "type" "vecperm,vecload,vecperm,vecperm")
+   (set_attr "length" "4,4,4,8")])
 
 ;; V4SI splat support
 (define_insn "vsx_splat_v4si"
Index: gcc/testsuite/g++.dg/pr71294.C
===
--- gcc/testsuite/g++.dg/pr71294.C  (revision 0)
+++ gcc/testsuite/g++.dg/pr71294.C  (working copy)
@@ -0,0 +1,60 @@
+// { dg-do compile { target { powerpc64*-*-* && lp64 } } }
+// { dg-require-effective-target powerpc_p8vector_ok } */
+// { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power8" } }
+// { dg-options "-mcpu=power8 -O3 -fstack-protector -mno-lra" }
+
+// PAR target/71294 failed because RELOAD could not figure how create a V2DI
+// vector that auto vectorization created with each element being the same
+// stack address, with stack-protector turned on.
+
+class A;
+template  class B {
+public:
+  _Tp val[m * n];
+};
+class C {
+public:
+  C(A);
+};
+struct D {
+  D();
+  unsigned long [](int);
+  unsigned long *p;
+};
+class A {
+public:
+  template  A(const B<_Tp, m, n> &, bool);
+  int rows, cols;
+  unsigned char *data;
+  unsigned char *datastart;
+  unsigned char *dataend;
+  unsigned char *datalimit;
+  D step;
+};
+template 
+A::A(const B<_Tp, m, n> , bool)
+: rows(m), cols(n) {
+  step[0] = cols * sizeof(_Tp);
+  datastart = data = (unsigned char *)p1.val;
+  datalimit = dataend = datastart + rows * step[0];
+}
+class F {
+public:
+  static void compute(C);
+  template 
+  static void compute(const B<_Tp, m, n> &, B<_Tp, nm, 1> &, B<_Tp, m, nm> &,
+  B<_Tp, n, nm> &);
+};
+D::D() {}
+unsigned long ::operator[](int p1) { return p[p1]; }
+template 
+void F::compute(const B<_Tp, m, n> &, B<_Tp, nm, 1> &, B<_Tp, m, nm> &,
+B<_Tp, n, nm> ) {
+  A a(p4, false);
+  compute(a);
+}
+void fn1() {
+  B

[Bug bootstrap/52471] ICE bootstrapping GCC 4.7.0-20120302 on x86_64 OpenBSD

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-03-15
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Martin Sebor  ---
It's been a few years since this report.  Can you try a more recent/supported
version of GCC (preferably 6 or 7) and verify whether the problem has cleared
up?

[v3 PATCH] Implement LWG 2857, {variant,optional,any}::emplace should return the constructed value.

[Ville Voutilainen]

Tested on Linux-x64.

2017-03-16  Ville Voutilainen  

Implement LWG 2857, {variant,optional,any}::emplace should
return the constructed value.
* include/std/any (any_cast(any*)): Forward-declare.
(emplace(_Args&&...)): Change the return type and
return a reference to the constructed value.
(emplace(initializer_list<_Up>, _Args&&...)): Likewise.
* include/std/optional (emplace(_Args&&...)): Likewise.
(emplace(initializer_list<_Up>, _Args&&...)): Likewise.
* include/std/variant (emplace<_Tp>(_Args&&...)): Likewise.
(emplace<_Tp>(initializer_list<_Up>, _Args&&...)): Likewise.
(emplace<_Np>(_Args&&...)): Likewise.
(emplace<_Np>(initializer_list<_Up>, _Args&&...)): Likewise.
* testsuite/20_util/any/assign/emplace.cc: Add tests for
checking the return value of emplace.
* testsuite/20_util/any/misc/any_cast_neg.cc: Adjust.
* testsuite/20_util/optional/assignment/6.cc: Add tests for
checking the return value of emplace.
* testsuite/20_util/variant/run.cc: Likewise.
diff --git a/libstdc++-v3/include/std/any b/libstdc++-v3/include/std/any
index e807617..fff13d9 100644
--- a/libstdc++-v3/include/std/any
+++ b/libstdc++-v3/include/std/any
@@ -74,6 +74,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
*  An @c any object's state is either empty or it stores a contained object
*  of CopyConstructible type.
*/
+  class any;
+  template
+inline _ValueType* any_cast(any* __any) noexcept;
+
   class any
   {
 // Holds either pointer to a heap object or the contained object itself.
@@ -268,18 +272,19 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
 /// Emplace with an object created from @p __args as the contained object.
 template 
-  typename __any_constructible&,
   _Decay<_ValueType>, _Args&&...>::type
   emplace(_Args&&... __args)
   {
__do_emplace<_Decay<_ValueType>>
  (std::forward<_Args>(__args)...);
+   return *(std::any_cast<_Decay<_ValueType>>(this));
   }
 
 /// Emplace with an object created from @p __il and @p __args as
 /// the contained object.
 template 
-  typename __any_constructible&,
   _Decay<_ValueType>,
   initializer_list<_Up>,
   _Args&&...>::type
@@ -287,6 +292,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   {
__do_emplace<_Decay<_ValueType>, _Up>
  (__il, std::forward<_Args>(__args)...);
+   return *(std::any_cast<_Decay<_ValueType>>(this));
   }
 
 // modifiers
diff --git a/libstdc++-v3/include/std/optional 
b/libstdc++-v3/include/std/optional
index 5e796ac..3f540ec 100644
--- a/libstdc++-v3/include/std/optional
+++ b/libstdc++-v3/include/std/optional
@@ -592,20 +592,22 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 }
 
   template
-   enable_if_t::value>
+   enable_if_t::value, _Tp&>
emplace(_Args&&... __args)
{
  this->_M_reset();
  this->_M_construct(std::forward<_Args>(__args)...);
+ return this->_M_get();
}
 
   template
enable_if_t&,
-_Args&&...>::value>
+_Args&&...>::value, _Tp&>
emplace(initializer_list<_Up> __il, _Args&&... __args)
{
  this->_M_reset();
  this->_M_construct(__il, std::forward<_Args>(__args)...);
+ return this->_M_get();
}
 
   // Destructor is implicit, implemented in _Optional_base.
diff --git a/libstdc++-v3/include/std/variant b/libstdc++-v3/include/std/variant
index 46d7b92..58bf8c7 100644
--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -1007,25 +1007,33 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
 
   template
-   enable_if_t && __exactly_once<_Tp>>
+   enable_if_t && __exactly_once<_Tp>,
+   _Tp&>
emplace(_Args&&... __args)
{
- this->emplace<__index_of<_Tp>>(std::forward<_Args>(__args)...);
+ auto& ret =
+   this->emplace<__index_of<_Tp>>(std::forward<_Args>(__args)...);
  __glibcxx_assert(holds_alternative<_Tp>(*this));
+ return ret;
}
 
   template
enable_if_t&, _Args...>
-   && __exactly_once<_Tp>>
+   && __exactly_once<_Tp>,
+   _Tp&>
emplace(initializer_list<_Up> __il, _Args&&... __args)
{
- this->emplace<__index_of<_Tp>>(__il, std::forward<_Args>(__args)...);
+ auto& ret =
+   

[Bug target/33777] Crash during a build of zsh

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #6 from Martin Sebor  ---
In the absence of feedback nearly a decade and in light of comment #2 resolving
as WorksForSome.

[Bug fortran/69499] [F03] ICE-on-invalid on combining select type with wrong statement

[jvdelisle at gcc dot gnu.org]

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

--- Comment #11 from Jerry DeLisle  ---
Always helps to double check.  The three original test cases do not ICE on
trunk and gfc_release_symbol is already NULL guarded internally.  I would not
chase this further on trunk for the first three cases.

Also, we don't care about the listed versions under "known to fail". especially
for invalid.  Its not worth our time on older gfortran releases. However, it is
worth investigating on trunk, especially for learning the internals

So which cases actually ICE or segfault on trunk currently? z4.f90 is
definitely something different.

[Bug middle-end/51769] bootstrap fails when using -O2 -funswitch-loops -floop-flatten

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #2 from Martin Sebor  ---
The -floop-flatten functionality was removed in r84820 (the option does nothing
now).

[Bug middle-end/50398] ICE when compiling openssl-1.0.0d with -O2 -floop-flatten

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #2 from Martin Sebor  ---
The -floop-flatten functionality was removed in r84820 (the option does nothing
now).

Re: Obsolete powerpc*-*-*spe*

[Andrew Jenner]

On 15/03/2017 14:26, Segher Boessenkool wrote:

I do not think VLE can get in, not in its current shape at least.


That's unfortunate. Disregarding the SPE splitting plan for a moment, 
what do you think would need to be done to get it into shape? I had 
thought we were almost there with the patches that I sent to you and 
David off-list last year.


> VLE

is very unlike PowerPC in many ways so it comes at a very big cost to
the port (maintenance and otherwise -- maintenance is what I care about
most).


I completely understand.


Since SPE and VLE only share the part of the rs6000 port that doesn't
change at all (except for a bug fix once or twice a year), and everything
else needs special cases all over the place, it seems to me it would be
best for everyone if we split the rs6000 port in two, one for SPE and VLE
and one for the rest.  Both ports could then be very significantly
simplified.

I am assuming SPE and VLE do not support AltiVec or 64-bit PowerPC,
please correct me if that is incorrect.  Also, is "normal" floating
point supported at all?


My understanding is that SPE is only present in the e500v1, e500v2 and 
e200z[3-7] cores, all of which are 32-bit only and do not have classic 
floating-point units. SPE and Altivec cannot coexist as they have some 
overlapping instruction encodings. The successor to e500v2 (e500mc) 
reinstated classic floating-point and got rid of SPE.



Do you (AdaCore and Mentor) think splitting the port is a good idea?


It wouldn't have been my preference, but I can understand the appeal of 
that plan for you. I'm surprised that the amount of shared code between 
SPE and PowerPC is as little as you say, but you have much more 
experience with the PowerPC port than I do, so I'll defer to your 
expertise on that matter.


Are you proposing to take on the task of actually splitting it yourself? 
If so, that would make me a lot happier about it.



>> -te200z0
>> -te200z3
>> -te200z4
>
> These are VLE?

Yes.

> Do some of those also support PowerPC?

All the e200 cores apart from e200z0 can execute 32-bit instructions as 
well as VLE, though we'll always generate VLE code when targetting them 
(otherwise they're fairly standard).


Andrew

[Bug c++/80059] New: [7 Regression] ICE with invalid noexcept for __transaction_atomic

[reichelt at gcc dot gnu.org]

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

Bug ID: 80059
   Summary: [7 Regression] ICE with invalid noexcept for
__transaction_atomic
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, trans-mem
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following invalid code snippet (compiled with -fgnu-tm) triggers
an ICE on trunk:

=
template int foo(bool b)
{
  return __transaction_atomic noexcept(b) (0);
}

void bar()
{
  foo(true);
}
=

bug.cc: In function 'int foo(bool)':
bug.cc:3:45: internal compiler error: unexpected expression 'b' of kind
implicit_conv_expr
   return __transaction_atomic noexcept(b) (0);
 ^
0x83f890 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4575
0x842ece cxx_eval_outermost_constant_expr
../../gcc/gcc/cp/constexpr.c:4633
0x776f2a build_must_not_throw_expr(tree_node*, tree_node*)
../../gcc/gcc/cp/except.c:274
0x7ac6ff build_transaction_expr(unsigned int, tree_node*, int, tree_node*)
../../gcc/gcc/cp/semantics.c:8747
0x72628f cp_parser_transaction_expression
../../gcc/gcc/cp/parser.c:37871
0x72628f cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:7895
0x726c93 cp_parser_cast_expression
../../gcc/gcc/cp/parser.c:8780
0x7273e7 cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:8881
0x727cb4 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:9168
0x72b9c8 cp_parser_expression
../../gcc/gcc/cp/parser.c:9337
0x719f9a cp_parser_jump_statement
../../gcc/gcc/cp/parser.c:12147
0x719f9a cp_parser_statement
../../gcc/gcc/cp/parser.c:10581
0x71a84d cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11027
0x71a91f cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:10981
0x71aab3 cp_parser_function_body
../../gcc/gcc/cp/parser.c:21428
0x71aab3 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:21466
0x71b331 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:26253
0x71c01d cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:26165
0x71c01d cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19155
0x71c5ca cp_parser_single_declaration
../../gcc/gcc/cp/parser.c:26711
Please submit a full bug report, [etc.]

This is a recent regression introduced between 2017-03-02 and 2017-03-06.

[Bug bootstrap/47923] Errors when installing GCC 4.5.2 on AIX 6.1

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #10 from Martin Sebor  ---
Based on comment #9 it sounds like the problems may have been caused by the
environment.  Regardless, GCC 4.5 is no longer supported and current trunk (GCC
7.0) has been reported to bootstrap successfully on AIX 7.2
(https://gcc.gnu.org/ml/gcc-testresults/2017-03/msg01700.html).  Please try a
more recent version of GCC and AIX and if the problems persist either open a
new bug or ask on gcc-h...@gcc.gnu.org.

[Bug fortran/69499] [F03] ICE-on-invalid on combining select type with wrong statement

[jvdelisle at gcc dot gnu.org]

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

--- Comment #10 from Jerry DeLisle  ---
Very good question, maybe we do:


if (p)
  gfc_release_symbol (p);

I will try it.

[Bug c++/80043] [6/7 Regression] ICE with pointer-to-member-function and -fpermissive

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Wed Mar 15 21:32:43 2017
New Revision: 246180

URL: https://gcc.gnu.org/viewcvs?rev=246180=gcc=rev
Log:
PR c++/80043 - ICE with -fpermissive

* typeck.c (convert_for_assignment): Handle instantiate_type
not giving an error.

Added:
trunk/gcc/testsuite/g++.dg/parse/ptrmem7.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c

C++ PATCH for c++/80043, ICE with PMF and -fpermissive

[Jason Merrill]

The issue here was that can_convert_bad doesn't allow this ill-formed
conversion, but instantiate_type does (with -fpermissive).  Fixed by
recognizing that case.  It might be nice to make can_convert_bad
smarter, but that doesn't seem worth the effort.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 8c545e7c3e1babf7a97e22f061953c4fa5c7871a
Author: Jason Merrill 
Date:   Wed Mar 15 17:08:42 2017 -0400

PR c++/80043 - ICE with -fpermissive

* typeck.c (convert_for_assignment): Handle instantiate_type
not giving an error.

diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index d24..4e9a1c0 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -8486,7 +8486,12 @@ convert_for_assignment (tree type, tree rhs,
 overloaded function.  Call instantiate_type to get error
 messages.  */
  if (rhstype == unknown_type_node)
-   instantiate_type (type, rhs, tf_warning_or_error);
+   {
+ tree r = instantiate_type (type, rhs, tf_warning_or_error);
+ /* -fpermissive might allow this.  */
+ if (!seen_error ())
+   return r;
+   }
  else if (fndecl)
error ("cannot convert %qT to %qT for argument %qP to %qD",
   rhstype, type, parmnum, fndecl);
diff --git a/gcc/testsuite/g++.dg/parse/ptrmem7.C 
b/gcc/testsuite/g++.dg/parse/ptrmem7.C
new file mode 100644
index 000..37b2689
--- /dev/null
+++ b/gcc/testsuite/g++.dg/parse/ptrmem7.C
@@ -0,0 +1,16 @@
+// PR c++/80043
+// { dg-options -fpermissive }
+
+struct A
+{
+  template void foo()
+  {
+void (A::* fp)();
+fp = A::foo<0>;// { dg-warning "assuming pointer to member" }
+  }
+};
+
+void bar()
+{
+  A().foo<0>();
+}

[Bug target/60808] Typo in definition of ATxmega256A3BU

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from Martin Sebor  ---
Fixed in r209446.

[Bug regression/59608] Unable to build working poedit v.1.5.x using gcc 4.8.2

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #3 from Martin Sebor  ---
There is insufficient information to know what's going on.  Please review the
Summarized bug reporting instructions in https://gcc.gnu.org/bugs and either
reopen this bug or open a new one with the requested details.

[Bug target/79038] Improve PowerPC ISA 3.0 conversion between integers and hardware _Float128

[meissner at gcc dot gnu.org]

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

--- Comment #5 from Michael Meissner  ---
Author: meissner
Date: Wed Mar 15 21:17:35 2017
New Revision: 246178

URL: https://gcc.gnu.org/viewcvs?rev=246178=gcc=rev
Log:
[gcc]
2017-03-15  Michael Meissner  

PR target/79038
* config/rs6000/rs6000.md (float2): Define
insns to convert from signed/unsigned char/short to IEEE 128-bit
floating point.
(floatuns2): Likewise.

[gcc/testsuite]
2017-03-15  Michael Meissner  

PR target/79038
* gcc.target/powerpc/pr79038-1.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr79038-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.md
trunk/gcc/testsuite/ChangeLog

[Bug target/54584] m68k-uclinux error: Link tests are not allowed after GCC_NO_EXECUTABLES

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-03-15
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|blocker |normal

--- Comment #8 from Martin Sebor  ---
Is this still a problem with any currently supported version of GCC?

Since there's been no update on this in almost 5 years and no other reports of
the same problem (AFAICS) I'm lowering Severity to Normal.  If the problem
persists and you feel like it meets the definition of Critical Severity
(https://gcc.gnu.org/bugs/management.html) please feel to bump it up.

[Bug target/80057] typo in mips.opt: Virtualization Application Specific

[roland.illig at gmx dot de]

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

--- Comment #2 from Roland Illig  ---
Citing from the PDF document:

> The Virtualization Application-Specific Extension (Module) requires the 
> following base architecture support:

The current GCC code split these words at the following boundaries:

> The "Virtualization Application Specific" "Module"

This would imply that there is a module called VAS.

The usual reading is different, though:

> The "Virtualization" "application-specific module"

This means there is an application-specific module called "Virtualization".

The words "Application-Specific Extension" are probably only capitalized
because they have been defined somewhere as a concept. In GCC, these words
should not be capitalized, and there should be a hyphen between
"application-specific", to be consistent with the grammar in other places.

[PATCH] Fix tree-prof/pr66295.c

[Segher Boessenkool]

This testcase can only ever be built on x86 (it needs the "avx*"
attributes).  This patch skips the test elsewhere.

Is this okay for trunk?


Segher


2017-03-15  Segher Boessenkool  

gcc/testsuite/
* gcc.dg/tree-prof/pr66295.c: Skip unless on an x86 target.

---
 gcc/testsuite/gcc.dg/tree-prof/pr66295.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/gcc.dg/tree-prof/pr66295.c 
b/gcc/testsuite/gcc.dg/tree-prof/pr66295.c
index b90ef84..d7d64c4 100644
--- a/gcc/testsuite/gcc.dg/tree-prof/pr66295.c
+++ b/gcc/testsuite/gcc.dg/tree-prof/pr66295.c
@@ -1,4 +1,5 @@
 /* { dg-require-ifunc "" } */
+/* { dg-skip-if "" { ! { i?86-*-* x86_64-*-* } } } */
 /* { dg-options "-O2" } */
 
 static double bar (double *__restrict, double *__restrict, int)
-- 
1.9.3

[Bug c++/80043] [6/7 Regression] ICE with pointer-to-member-function and -fpermissive

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

New German PO file for 'gcc' (version 7.1-b20170226)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the German team of translators.  The file is available at:

http://translationproject.org/latest/gcc/de.po

(This file, 'gcc-7.1-b20170226.de.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

[Bug fortran/33271] nint_2.f90 abort compiled with -O0

[segher at gcc dot gnu.org]

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

--- Comment #22 from Segher Boessenkool  ---
Author: segher
Date: Wed Mar 15 20:48:49 2017
New Revision: 246174

URL: https://gcc.gnu.org/viewcvs?rev=246174=gcc=rev
Log:
rs6000: Do not xfail nint_2.f90 on Linux systems

It was XFAILed because there was a bug in glibc, but that bug was fixed
nine years ago.  Nowadays everyone uses a version of glibc with the bug
fixed, so we should no longer XFAIL the test.


gcc/testsuite/
PR fortran/33271
* gfortran.dg/nint_2.f90: Do not xfail powerpc*-*-linux*.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/nint_2.f90

[Bug bootstrap/80047] fixincludes/fixincl.c: PVS-Studio: Improper Release of Memory Before Removing Last Reference (CWE-401)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Component|other   |bootstrap

--- Comment #3 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00853.html

(In reply to Andrew Pinski from comment #2)
> >char cwdbuf[MAXPATHLEN];
> 
> This is not a GNU style thing.  GNU style mentions against using arbitrary
> limits.

There are existing uses of MAXPATHLEN to declare local arrays in this file
(create_file, quoted_file_exists) so this one doesn't make things any worse
than they already are.

Re: [PATCH] Fix location of typeid() (PR c++/80014)

[Jason Merrill]

On Tue, Mar 14, 2017 at 9:05 PM, David Malcolm  wrote:
> OK for trunk now, or should this wait until stage 1?

Stage 1.

> +   cp_token *close_paren = cp_parser_require (parser, CPP_CLOSE_PAREN,
> +  RT_CLOSE_PAREN);
> +   location_t end_loc = close_paren ?
> + close_paren->location : UNKNOWN_LOCATION;
> /* If all went well, simply lookup the type-id.  */
> if (cp_parser_parse_definitely (parser))
>   postfix_expression = get_typeid (type, tf_warning_or_error);
> @@ -6527,13 +6530,23 @@ cp_parser_postfix_expression (cp_parser *parser, bool 
> address_p, bool cast_p,
> /* Compute its typeid.  */
> postfix_expression = build_typeid (expression, 
> tf_warning_or_error);
> /* Look for the `)' token.  */
> -   cp_parser_require (parser, CPP_CLOSE_PAREN, RT_CLOSE_PAREN);
> +   close_paren
> + = cp_parser_require (parser, CPP_CLOSE_PAREN, RT_CLOSE_PAREN);
> +   end_loc = close_paren ? close_paren->location : UNKNOWN_LOCATION;

In both cases you're setting end_loc from close_paren, so how about
only computing it once, closer to where it's used?

Jason

Document PR79806 as a non-bug

[Bernd Schmidt]

I suggest we apply the following and close the PR as INVALID (not a 
bug). Ok?



Bernd

Index: pr65693.c
===
--- pr65693.c   (revision 245685)
+++ pr65693.c   (working copy)
@@ -2,6 +2,11 @@
 /* { dg-do compile } */
 /* { dg-options "-O2" } */

+/* This test relies on -O2 to optimize away the division operation
+   that's expanded as part of the alloca.  With -O0, the explicit use
+   of edx causes a compilation failure, which is expected
+   behaviour.  */
+
 int a;

 void

[PATCH] avoid relying on getcwd extensions (PR 80047)

[Martin Sebor]

PR 80047 - fixincludes/fixincl.c: PVS-Studio: Improper Release
of Memory Before Removing Last Reference (CWE-401) points out
that the fixincludes program calls getcwd with the first argument
set to NULL, apparently a Glibc extension, to have the function
allocate the memory to which it then returns a pointer.

The attached patch avoids this and also avoids assuming the
function cannot fail.

This is not a regression so I assume it's not suitable for
GCC 7 but rather for GCC 8 when stage 1 opens.

Martin
PR other/80047 - fixincludes/fixincl.c: PVS-Studio: Improper Release of Memory Before Removing Last Reference (CWE-401)

fixincludes/ChangeLog:

	PR other/80047
	* fixincl.c (process): Avoid relying on getcwd extensions and assuming
	the function will succeed.

diff --git a/fixincludes/fixincl.c b/fixincludes/fixincl.c
index 6dba2f6..6e6eb21 100644
--- a/fixincludes/fixincl.c
+++ b/fixincludes/fixincl.c
@@ -1353,8 +1353,10 @@ process (void)
   if (access (pz_curr_file, R_OK) != 0)
 {
   int erno = errno;
+  char cwdbuf[MAXPATHLEN];
+  char *cwd = getcwd (cwdbuf, sizeof cwdbuf);
   fprintf (stderr, "Cannot access %s from %s\n\terror %d (%s)\n",
-   pz_curr_file, getcwd ((char *) NULL, MAXPATHLEN),
+   pz_curr_file, cwd ? cwd : "current working directory",
erno, xstrerror (erno));
   return;
 }

Re: [PATCH] Fix location of sizeof/alignof (PR c++/80016)

[Jason Merrill]

This looks very safe, but not critical enough for stage 4.  So I think
wait for stage 1, and maybe also put it on the branch later.

Jason

On Tue, Mar 14, 2017 at 9:05 PM, David Malcolm  wrote:
> PR c++/80016 reports an issue with bizarre underlined range
> for a complicated expression.
>
> The root cause for the incorrect *starting* location of that range
> is that alignof and sizeof expressions currently have
> start == finish == caret at the opening parenthesis of the
> expression.
>
> This patch fixes this by generating appropriate start and finish
> locations for alignof and sizeof expressions.
>
> Successfully bootstrapped on x86_64-pc-linux-gnu.
>
> OK for trunk now, or should this wait until stage 1?
>
> gcc/cp/ChangeLog:
> PR c++/80016
> * parser.c (cp_parser_unary_expression):  Generate a location
> range for alignof and sizeof expressions.
>
> gcc/testsuite/ChangeLog:
> PR c++/80016
> * g++.dg/plugin/diagnostic-test-expressions-1.C (test_sizeof): New
> test function.
> (test_alignof): New test function.
> ---
>  gcc/cp/parser.c| 19 +--
>  .../g++.dg/plugin/diagnostic-test-expressions-1.C  | 66 
> ++
>  2 files changed, 81 insertions(+), 4 deletions(-)
>
> diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
> index aecf9a5..0d9667e 100644
> --- a/gcc/cp/parser.c
> +++ b/gcc/cp/parser.c
> @@ -7817,12 +7817,11 @@ cp_parser_unary_expression (cp_parser *parser, 
> cp_id_kind * pidk,
>   {
> tree operand, ret;
> enum tree_code op;
> -   location_t first_loc;
> +   location_t start_loc = token->location;
>
> op = keyword == RID_ALIGNOF ? ALIGNOF_EXPR : SIZEOF_EXPR;
> /* Consume the token.  */
> cp_lexer_consume_token (parser->lexer);
> -   first_loc = cp_lexer_peek_token (parser->lexer)->location;
> /* Parse the operand.  */
> operand = cp_parser_sizeof_operand (parser, keyword);
>
> @@ -7858,9 +7857,21 @@ cp_parser_unary_expression (cp_parser *parser, 
> cp_id_kind * pidk,
> TREE_SIDE_EFFECTS (ret) = 0;
> TREE_READONLY (ret) = 1;
>   }
> -   SET_EXPR_LOCATION (ret, first_loc);
>   }
> -   return ret;
> +
> +   /* Construct a location e.g. :
> +  alignof (expr)
> +  ^~
> +  with start == caret at the start of the "alignof"/"sizeof"
> +  token, with the endpoint at the final closing paren.  */
> +   location_t finish_loc
> + = cp_lexer_previous_token (parser->lexer)->location;
> +   location_t compound_loc
> + = make_location (start_loc, start_loc, finish_loc);
> +
> +   cp_expr ret_expr (ret);
> +   ret_expr.set_location (compound_loc);
> +   return ret_expr;
>   }
>
> case RID_NEW:
> diff --git a/gcc/testsuite/g++.dg/plugin/diagnostic-test-expressions-1.C 
> b/gcc/testsuite/g++.dg/plugin/diagnostic-test-expressions-1.C
> index 3554086..64eb660 100644
> --- a/gcc/testsuite/g++.dg/plugin/diagnostic-test-expressions-1.C
> +++ b/gcc/testsuite/g++.dg/plugin/diagnostic-test-expressions-1.C
> @@ -101,6 +101,72 @@ int test_postfix_incdec (int i)
>
>  /* Unary operators.  /
>
> +int test_sizeof (int i)
> +{
> +  __emit_expression_range (0, sizeof(int) + i); /* { dg-warning "range" } */
> +/* { dg-begin-multiline-output "" }
> +   __emit_expression_range (0, sizeof(int) + i);
> +   ^~~
> +   { dg-end-multiline-output "" } */
> +
> +  __emit_expression_range (0, i + sizeof(int)); /* { dg-warning "range" } */
> +/* { dg-begin-multiline-output "" }
> +   __emit_expression_range (0, i + sizeof(int));
> +   ~~^
> +   { dg-end-multiline-output "" } */
> +
> +  __emit_expression_range (0, sizeof i + i); /* { dg-warning "range" } */
> +/* { dg-begin-multiline-output "" }
> +   __emit_expression_range (0, sizeof i + i);
> +   ~^~~
> +   { dg-end-multiline-output "" } */
> +
> +  __emit_expression_range (0, i + sizeof i); /* { dg-warning "range" } */
> +/* { dg-begin-multiline-output "" }
> +   __emit_expression_range (0, i + sizeof i);
> +   ~~^~
> +   { dg-end-multiline-output "" } */
> +}
> +
> +int test_alignof (int i)
> +{
> +  __emit_expression_range (0, alignof(int) + i); /* { dg-warning "range" } */
> +/* { dg-begin-multiline-output "" }
> +   __emit_expression_range (0, alignof(int) + i);
> +   ~^~~
> +   { dg-end-multiline-output "" } */
> +
> +  __emit_expression_range (0, i + alignof(int)); /* { dg-warning "range" } */
> +/* { dg-begin-multiline-output "" }
> +   __emit_expression_range (0, i 

[Bug other/80058] New: fix double spaces is string literals everywhere

[roland.illig at gmx dot de]

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

Bug ID: 80058
   Summary: fix double spaces is string literals everywhere
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

Searching the whole GCC source code for the following regular expression finds
a few places in the code:

[ ]"\n[ \t]+"[ ]

This expression finds concatenated string literals where the first ends with a
space and the second starts with a space, like these:

  gfc_warning_now (w, "Change of value in conversion from "
   " %qs to %qs at %L",
   gfc_typename (>ts), gfc_typename (>ts),
   >where);

The above code and all similar places should be fixed so that they only have a
single space character.

[Bug other/80047] fixincludes/fixincl.c: PVS-Studio: Improper Release of Memory Before Removing Last Reference (CWE-401)

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
>char cwdbuf[MAXPATHLEN];

This is not a GNU style thing.  GNU style mentions against using arbitrary
limits.

[Bug other/80047] fixincludes/fixincl.c: PVS-Studio: Improper Release of Memory Before Removing Last Reference (CWE-401)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||build
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-15
 CC||msebor at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  Since the Glibc extension may not be provided by other systems I
think the portable solution is to avoid relying on it.  Since getcwd() may fail
by returning 0, the caller should also avoid assuming it succeeds.  Let me post
the following patch:

diff --git a/fixincludes/fixincl.c b/fixincludes/fixincl.c
index 6dba2f6..6e6eb21 100644
--- a/fixincludes/fixincl.c
+++ b/fixincludes/fixincl.c
@@ -1353,8 +1353,10 @@ process (void)
   if (access (pz_curr_file, R_OK) != 0)
 {
   int erno = errno;
+  char cwdbuf[MAXPATHLEN];
+  char *cwd = getcwd (cwdbuf, sizeof cwdbuf);
   fprintf (stderr, "Cannot access %s from %s\n\terror %d (%s)\n",
-   pz_curr_file, getcwd ((char *) NULL, MAXPATHLEN),
+   pz_curr_file, cwd ? cwd : "current working directory",
erno, xstrerror (erno));
   return;
 }

[Bug libstdc++/62045] [5/6 Regression] __gnu_pbds::priority_queue<int, less, binary_heap_tag> is too slow

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|[5/6/7 Regression]  |[5/6 Regression]
   |__gnu_pbds::priority_queue< |__gnu_pbds::priority_queue<
   |int, less, |int, less,
   |binary_heap_tag> is too |binary_heap_tag> is too
   |slow|slow

--- Comment #11 from Jonathan Wakely  ---
Fixed on trunk so far.

Re: [PATCH] Remove __gnu_pbds::detail::binary_heap::is_heap (PR libstdc++/62045) [resend]

[Jonathan Wakely]

On 10/03/17 11:54 +, Jonathan Wakely wrote:

On 10/03/17 19:36 +0800, Xi Ruoyao wrote:

Hi,

This was resent to be in both libstdc++ and gcc-patches list.


Thanks.


The ill-formed checking in binary_heap::push_heap has made it
O(n). Remove this checking.


The checking certainly looks redundant, I wouldn't say ill-formed
though (that's a formal term in the C++ standard meaning the code
isn't valid C++).


Since assert_valid also checks if (*this) is a legal heap, we can
remove is_heap and the assertions using it completely.


The patch looks good, and since you're just removing code I don't
think we need a copyright assignment. I'll get this applied to the
active branches, thanks!



I've committed the patch, with a new test to verify that we don't do
too many comparisons on insertion. Thanks again.

Tested powerpc64le-linux, committed to trunk. Backports to follow.


commit e81a1a7754ec90d3ecd3478e397d554d69c81d04
Author: Jonathan Wakely 
Date:   Wed Mar 15 19:01:42 2017 +

PR libstdc++/62045 fix O(N) insertion in pd_ds binary heap

2017-03-15Xi Ruoyao

	PR libstdc++/62045
	* include/ext/pb_ds/qdetail/binary_heap_/binary_heap_.hpp
	(is_heap): Remove.
	(push_heap): Remove the wrong checking using is_heap.
	(make_heap): Remove the assertion using is_heap.
	* include/ext/pb_ds/detail/binary_heap_/insert_fn_imps.hpp
	(modify): Ditto.
	(resize_for_insert_if_needed): Add PB_DS_ASSERT_VALID after
	calling make_heap.

2017-03-15  Jonathan Wakely  

	PR libstdc++/62045
	* testsuite/ext/pb_ds/regression/priority_queue_binary_heap-62045.cc:
	New test.
	* testsuite/ext/pb_ds/regression/priority_queues.cc: Fix copy
	error in comment.

diff --git a/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/binary_heap_.hpp b/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/binary_heap_.hpp
index 2755f06..f653a1e 100644
--- a/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/binary_heap_.hpp
+++ b/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/binary_heap_.hpp
@@ -266,20 +266,14 @@ namespace __gnu_pbds
 	const entry_cmp& m_cmp = static_cast(*this);
 	entry_pointer end = m_a_entries + m_size;
 	std::make_heap(m_a_entries, end, m_cmp);
-	_GLIBCXX_DEBUG_ASSERT(is_heap());
   }
 
   void
   push_heap()
   {
-	if (!is_heap())
-	  make_heap();
-	else
-	  {
-	const entry_cmp& m_cmp = static_cast(*this);
-	entry_pointer end = m_a_entries + m_size;
-	std::push_heap(m_a_entries, end, m_cmp);
-	  }
+	const entry_cmp& m_cmp = static_cast(*this);
+	entry_pointer end = m_a_entries + m_size;
+	std::push_heap(m_a_entries, end, m_cmp);
   }
 
   void
@@ -290,15 +284,6 @@ namespace __gnu_pbds
 	std::pop_heap(m_a_entries, end, m_cmp);
   }
 
-  bool
-  is_heap()
-  {
-	const entry_cmp& m_cmp = static_cast(*this);
-	entry_pointer end = m_a_entries + m_size;
-	bool p = std::__is_heap(m_a_entries, end, m_cmp);
-	return p;
-  }
-
 #ifdef _GLIBCXX_DEBUG
   void
   assert_valid(const char*, int) const;
diff --git a/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/insert_fn_imps.hpp b/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/insert_fn_imps.hpp
index f82dd52..d21fe3c 100644
--- a/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/insert_fn_imps.hpp
+++ b/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/insert_fn_imps.hpp
@@ -103,7 +103,6 @@ modify(point_iterator it, const_reference r_new_val)
   swap_value_imp(it.m_p_e, r_new_val, s_no_throw_copies_ind);
   fix(it.m_p_e);
   PB_DS_ASSERT_VALID((*this))
-  _GLIBCXX_DEBUG_ASSERT(is_heap());
 }
 
 PB_DS_CLASS_T_DEC
diff --git a/libstdc++-v3/testsuite/ext/pb_ds/regression/priority_queue_binary_heap-62045.cc b/libstdc++-v3/testsuite/ext/pb_ds/regression/priority_queue_binary_heap-62045.cc
new file mode 100644
index 000..a61d36f
--- /dev/null
+++ b/libstdc++-v3/testsuite/ext/pb_ds/regression/priority_queue_binary_heap-62045.cc
@@ -0,0 +1,51 @@
+// Copyright (C) 2017 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-do run }
+
+#include 
+#include 
+
+int count = 0;
+
+struct less
+{
+  bool operator()(int i, int 

[Bug libstdc++/62045] [5/6/7 Regression] __gnu_pbds::priority_queue<int, less, binary_heap_tag> is too slow

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
Author: redi
Date: Wed Mar 15 20:11:48 2017
New Revision: 246173

URL: https://gcc.gnu.org/viewcvs?rev=246173=gcc=rev
Log:
PR libstdc++/62045 fix O(N) insertion in pd_ds binary heap

2017-03-15  Xi Ruoyao  

PR libstdc++/62045
* include/ext/pb_ds/qdetail/binary_heap_/binary_heap_.hpp
(is_heap): Remove.
(push_heap): Remove the wrong checking using is_heap.
(make_heap): Remove the assertion using is_heap.
* include/ext/pb_ds/detail/binary_heap_/insert_fn_imps.hpp
(modify): Ditto.
(resize_for_insert_if_needed): Add PB_DS_ASSERT_VALID after
calling make_heap.

2017-03-15  Jonathan Wakely  

PR libstdc++/62045
* testsuite/ext/pb_ds/regression/priority_queue_binary_heap-62045.cc:
New test.
* testsuite/ext/pb_ds/regression/priority_queues.cc: Fix copy
error in comment.

Added:
   
trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/priority_queue_binary_heap-62045.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/binary_heap_.hpp
trunk/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/insert_fn_imps.hpp
trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/priority_queues.cc

[Bug target/71294] [6 Regression] ICE in gen_add2_insn, at optabs.c:4442 on powerpc64le-linux

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

  Attachment #38580|0   |1
is obsolete||

--- Comment #17 from Michael Meissner  ---
Created attachment 40980
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40980=edit
Proposed patch to fix the problem

[Bug target/71294] [6 Regression] ICE in gen_add2_insn, at optabs.c:4442 on powerpc64le-linux

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

[Bug target/71294] [6 Regression] ICE in gen_add2_insn, at optabs.c:4442 on powerpc64le-linux

[meissner at gcc dot gnu.org]

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

--- Comment #16 from Michael Meissner  ---
You need power8 support for the bug to show itself.  In order to have power8
(ISA 2.07) support, you need a binutils that supports at least the power8
instructions.

[Bug translation/80055] do not mark internal compiler error messages for i18n

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-15
 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=79856
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  See also the related discussion in bug 79856.

[Bug target/71294] [6 Regression] ICE in gen_add2_insn, at optabs.c:4442 on powerpc64le-linux

[segher at gcc dot gnu.org]

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

--- Comment #15 from Segher Boessenkool  ---
You need to build GCC with a new enough binutils, 2.24 I believe.

[Bug fortran/69499] [F03] ICE-on-invalid on combining select type with wrong statement

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres  ---
Just a quick question: are you sure that removing 'gfc_release_symbol (p);'
does not cause a memory leak in the normal case?

[Bug c++/62181] [C/C++] Expected new warning: "adding 'char' to a string does not append to the string" [-Wstring-plus-int]

[msebor at gcc dot gnu.org]

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

--- Comment #9 from Martin Sebor  ---
(In reply to Xi Ruoyao from comment #8)
> (In reply to Xi Ruoyao from comment #7)
> 
> > We should make a new PR requesting for clang -Warray-bounds as well.  It's
> > a part of meta-bug PR30334.
> 
> Sorry. We have -Warray-bounds, but not as well as clang's.  For example clang
> warns for "aa"[4], but GCC doesn't.

Right.  It only warns on arrays, and only with optimization.  That seems to be
because array_at_struct_end_p() in tree.c (called from check_array_ref() in
tree-vrp.c) doesn't handle ARRAY_REF with a STRING_CST operand correctly.  It
treats it as if it were a reference to an array at the end of a structure. 
This only superficially tested change lets GCC warn on that case as well (as
long as the result is used).  To detect this without optimization
-Warray-bounds would need to also do some checking much earlier.

diff --git a/gcc/tree.c b/gcc/tree.c
index 8f87e7c..5fcbf65 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -13229,6 +13229,9 @@ array_at_struct_end_p (tree ref, bool allow_compref)
   ref = TREE_OPERAND (ref, 0);
 }

+  if (TREE_CODE (ref) == STRING_CST)
+return false;
+
   tree size = NULL;

   if (TREE_CODE (ref) == MEM_REF

Re: [PATCH doc] use "cannot" consistently

[Richard Kenner]

> > The latter references other documents, which advocate for more use of
> > contractions even in formal writing.
> 
> These are legal guides, not obviously relevant in the context
> of technical writing.

Yes and no.  The argument for them is that legal writing is the most formal
of all and has been the slowest to adopt contractions.

Re: [PATCH doc] use "cannot" consistently

[Toon Moene]

On 03/14/2017 09:53 PM, Richard Kenner wrote:


The GCC manual uses "cannot" in most places (280 lines) but there
are a few instances of "can't" (33 lines).

The attached patch replaces the informal "can't" with the former
for consistency.


In my opinion, this is the wrong direction.  Contractions are becoming
more acceptable in even more formal writing and there's even a current
US Supreme Court justice who uses them in her opinions.

I certainly don't think it's worth a change to use "can't" throughout,
but I'm not in favor of eliminating it either.


I think for non-native speakers of English, using the full word is 
easier to read (you can't take my experience as an example, as I was 
exposed to written English 48 years ago).


I think replacing the few instances of can't with cannot is worth the 
clarity.


Kind regards,

--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news

[Bug target/71294] [6 Regression] ICE in gen_add2_insn, at optabs.c:4442 on powerpc64le-linux

[bernds at gcc dot gnu.org]

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

--- Comment #14 from Bernd Schmidt  ---
I can't reproduce this, but that's probably because of
  cc1plus: warning: will not generate power8 instructions because assembler
lacks power8 support

Binutils was just configured for ppc64le-linux - do I need any special options
on the configure command line there?

[Bug c++/62181] [C/C++] Expected new warning: "adding 'char' to a string does not append to the string" [-Wstring-plus-int]

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #8 from Xi Ruoyao  ---
(In reply to Xi Ruoyao from comment #7)

> We should make a new PR requesting for clang -Warray-bounds as well.  It's
> a part of meta-bug PR30334.

Sorry. We have -Warray-bounds, but not as well as clang's.  For example clang
warns for "aa"[4], but GCC doesn't.

Re: [PATCH] MPX: fix PR middle-end/79753

[Ilya Enkovich]

2017-03-15 20:09 GMT+03:00 Jeff Law :
> On 03/15/2017 04:15 AM, Martin Liška wrote:
>>
>> On 03/14/2017 11:27 PM, Ilya Enkovich wrote:
>>>
>>> 2017-03-10 16:15 GMT+03:00 Martin Liška :

 Hello.

 Currently, __builtin_ia32_bndret is used for all functions that have
 non-void
 return type. I think the right fix is to return bounds just for a
 bounded type.

 Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

 Ready to be installed?
 Martin
>>>
>>>
>>> Hi,
>>>
>>> The fix makes sense and allows you to pass the test but it seems like we
>>> still have the issue in inlining which can result in bndret call with
>>> wrong arg.
>>
>>
>> Hi.
>>
>> The test I added does probably what you mean: a return value of integer
>> is casted
>> to a pointer type. Or?
>>
>>> Do you avoid all such cases by this fix? Can we still have similar
>>> problem
>>> if cast function with integer return type to a function with pointer
>>> return type
>>> and the inline the call (not sure if we can inline such calls)?
>>>
>>> I think this fix still should go to trunk anyway.
>>
>>
>> Good, may I consider this as patch approval?
>
> Yes.  Ilya knows this stuff better than anyone, even if he's not listed as
> an official maintainer.

I'm still in the list :)

Ilya

>
> jeff
>

Re: [PATCH] MPX: fix PR middle-end/79753

[Ilya Enkovich]

2017-03-15 13:15 GMT+03:00 Martin Liška :
> On 03/14/2017 11:27 PM, Ilya Enkovich wrote:
>>
>> 2017-03-10 16:15 GMT+03:00 Martin Liška :
>>>
>>> Hello.
>>>
>>> Currently, __builtin_ia32_bndret is used for all functions that have
>>> non-void
>>> return type. I think the right fix is to return bounds just for a bounded
>>> type.
>>>
>>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>>
>>> Ready to be installed?
>>> Martin
>>
>>
>> Hi,
>>
>> The fix makes sense and allows you to pass the test but it seems like we
>> still have the issue in inlining which can result in bndret call with
>> wrong arg.
>
>
> Hi.
>
> The test I added does probably what you mean: a return value of integer is
> casted
> to a pointer type. Or?

I suspect problem may still exist when you cast function, not just
returned value.
Inline is supposed to always remove retbnd corresponding to expanded call.
You avoid the problem in the testcase by not producing retbnd call. But in
case of calling a function casted to another function type we might
still hit this
issue in inline. I'll try to make a test.

Thanks,
Ilya

>
>> Do you avoid all such cases by this fix? Can we still have similar problem
>> if cast function with integer return type to a function with pointer
>> return type
>> and the inline the call (not sure if we can inline such calls)?
>>
>> I think this fix still should go to trunk anyway.
>
>
> Good, may I consider this as patch approval?
> Thanks,
> Martin
>
>>
>> Thanks,
>> Ilya
>>
>

[Bug c++/62181] [C/C++] Expected new warning: "adding 'char' to a string does not append to the string" [-Wstring-plus-int]

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #7 from Xi Ruoyao  ---
(In reply to Martin Sebor from comment #6)
> With constant arguments (or those whose value or range is known), GCC should
> warn on the first declaration in comment #0 (copied below) not necessarily
> because the addition doesn't append 'c' to "aa" (i.e., with
> -Wstring-plus-char warns) but mainly because it results in an invalid
> pointer.
> 
>   const char *a = "aa" + 'c';
> 
> GCC should warn for a constant operand that results in an out-of-bounds
> pointer regardless of its type, such as the following:
> 
>   const char *a = "aa" + 4;
> 

Clang-5.0 is doing this now for -Wstring-plus-int.  I'll try to do this.

> GCC could (and, in my view, should) also warn on the following where the
> value of i isn't known but where its range is such that the addition will
> never result in a valid pointer:
> 
>   void f (int i)
>   {
> if (i < 4) return;
> const char *a = "aa" + i;
> ...
>   }

We should make a new PR requesting for clang -Warray-bounds as well.  It's
a part of meta-bug PR30334.

[Bug target/80057] typo in mips.opt: Virtualization Application Specific

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-03-15
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
https://imagination-technologies-cloudfront-assets.s3.amazonaws.com/documentation/MD00849-2B-VZmicroMIPS64-AFP-01.06.pdf


"The Virtualization Application-Specific Extension (Module) requires the
following base architecture support:"

Or did I misunderstand your issue with it?

[Bug fortran/69499] [F03] ICE-on-invalid on combining select type with wrong statement

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle  ---
I will take care of it. Thanks Nicolas

Re: [PATCH][GCC][AArch64] Fix incorrect INS in SIMD mov pattern

[James Greenhalgh]

On Wed, Mar 15, 2017 at 04:09:05PM +, Tamar Christina wrote:
> This patch fixes a bug in the SIMD mov pattern where we were doing an
> insert and leaving the rest of the vector in an undetermined state. This
> could cause a bug if something else expects the other lanes to be 0.
>
> Semantically we wanted a mov here and not an insert. This is in line
> with other patterns that use an fmov for the same reason,
> e.g. aarch64_combinez*.
>
> Regression tested on aarch64-none-linux-gnu and no regressions.
>
> OK for trunk?

This isn't technically a regression, but the bug would be subtle enough,
and hard enough to debug that I think we should fix it for GCC 7.

OK for trunk, where else does this need backported to?

Thanks,
James

> gcc/
> 2017-03-15 Tamar Christina; 
>
>   * config/aarch64/aarch64-simd.md (*aarch64_simd_mov)
>   Change ins into fmov.

[Bug target/80057] New: typo in mips.opt: Virtualization Application Specific

[roland.illig at gmx dot de]

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

Bug ID: 80057
   Summary: typo in mips.opt: Virtualization Application Specific
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

from mips.opt:

mvirt
Target Report Var(TARGET_VIRT)
Use Virtualization Application Specific instructions.

The words "Virtualization Application Specific" are not the official name of an
instruction set extension, therefore they should not look like an abbreviation.

[Bug other/80056] New: gcc.dg/tree-prof/pr66295.c fails on powerpc

[seurer at gcc dot gnu.org]

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

Bug ID: 80056
   Summary: gcc.dg/tree-prof/pr66295.c fails on powerpc
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

This new test case doesn't compile correct on powerpc.

spawn /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/tree-prof/pr66295.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -fprofile-generate
-D_PROFILE_GENERATE -lm -o
/home/seurer/gcc/build/gcc-test2/gcc/testsuite/gcc/pr66295.x01
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/tree-prof/pr66295.c:14:1:
error: __attribute__((__target__("avx"))) is invalid
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/tree-prof/pr66295.c:14:1:
error: __attribute__((__target__("avx2"))) is invalid
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/tree-prof/pr66295.c:14:1:
error: __attribute__((__target__("avx512f"))) is invalid
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/tree-prof/pr66295.c:14:1:
error: __attribute__((__target__("default"))) is invalid
compiler exited with status 1
output is:
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/tree-prof/pr66295.c:14:1:
error: __attribute__((__target__("avx"))) is invalid
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/tree-prof/pr66295.c:14:1:
error: __attribute__((__target__("avx2"))) is invalid
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/tree-prof/pr66295.c:14:1:
error: __attribute__((__target__("avx512f"))) is invalid
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/tree-prof/pr66295.c:14:1:
error: __attribute__((__target__("default"))) is invalid

FAIL: gcc.dg/tree-prof/pr66295.c compilation,  -fprofile-generate
-D_PROFILE_GENERATE
UNRESOLVED: gcc.dg/tree-prof/pr66295.c execution,-fprofile-generate
-D_PROFILE_GENERATE
UNRESOLVED: gcc.dg/tree-prof/pr66295.c compilation,  -fprofile-use
-D_PROFILE_USE
UNRESOLVED: gcc.dg/tree-prof/pr66295.c execution,-fprofile-use
-D_PROFILE_USE
UNSUPPORTED:
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/tree-prof/pr66295.c
-fauto-profile
testcase
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/tree-prof/tree-prof.exp
completed in 0 seconds

=== gcc Summary ===

# of unexpected failures1
# of unresolved testcases   3
# of unsupported tests  1

Re: [PATCH 0/3] Introduce internal_error_cont and exclude it from pot files

[David Malcolm]

On Wed, 2017-03-15 at 14:53 +0100, Martin Liška wrote:
> Hello.
> 
> Following small series exclude some strings from pot files via
> introduction of internal_error_cont function.
> 
> Patch can bootstrap and survives regression tests.
> 
> (Sorry for broken threading because my cover letter was rejected).
> 
> Martin
> 
> marxin (3):
>Introduce internal_error_cont function and use it in cfgrtl.c (PR
>  rtl-optimization/79856).
>Replace error with internal_error_cont in cgraph.c (PR ipa/79857).
>Regenerate gcc.pot.
> 
>   gcc/cfgrtl.c  |   349 +-
>   gcc/cgraph.c  |   139 +-
>   gcc/diagnostic-core.h | 1 +
>   gcc/diagnostic.c  |16 +
>   gcc/diagnostic.def| 1 +
>   gcc/po/exgettext  | 6 +-
>   gcc/po/gcc.pot| 14892 -
> ---
>   7 files changed, 7589 insertions(+), 7815 deletions(-)

[For some reason I only received the 0/3 and 3/3 mail, not 1/3 and 2/3]

In patch 1:

2017-03-13  Martin Liska  

PR rtl-optimization/79856
* cfgrtl.c (try_redirect_by_replacing_jump): Fix GNU coding
style.
(fixup_partition_crossing): Likewise.
(fixup_new_cold_bb): Likewise.
(emit_barrier_after_bb): Likewise.
(force_nonfallthru_and_redirect): Likewise.
(last_bb_in_partition): Likewise.
(rtl_split_edge): Likewise.
(commit_one_edge_insertion): Likewise.
(print_rtl_with_bb): Likewise.
(find_partition_fixes): Use internal_error_cont instead of
error.
(verify_hot_cold_block_grouping): Likewise.
(rtl_verify_edges): Likewise.
(rtl_verify_bb_insns): Likewise.
(rtl_verify_bb_pointers): Likewise.
(rtl_verify_bb_insn_chain): Likewise.
(rtl_verify_fallthru): Likewise.
(purge_dead_edges): Fix GNU coding style.
(fixup_abnormal_edges): Likewise.
(fixup_reorder_chain): Likewise.
(duplicate_insn_chain): Likewise.
* diagnostic-core.h (internal_error_cont): Declare new
function.
* diagnostic.c (diagnostic_action_after_output): Handle
newly added DK_INTERNAL_ERROR.
(internal_error_cont): New function.
* diagnostic.def (DK_INTERNAL_ERROR): New enum value.

...the cfgrtl.c changes are a mixture of hunks that are (mostly)
whitespace fixes, combined with hunks that move over to using
internal_error_cont.

Please can you split this patch up to move the cfgrtl.c coding style
fixes into a separate patch, since this obscures the diagnostic
changes?

Also, as Joseph notes, if a function accepts a string param that isn't
to be translated, don't use "gmsgid" or "msgid" as the param name (just
call it "msg" or somesuch).

Thanks
Dave

Re: [PATCH] Fix PR79908

[Bill Schmidt]

> On Mar 14, 2017, at 9:25 AM, Richard Biener  
> wrote:
> 
> On Tue, Mar 14, 2017 at 3:20 PM, Bill Schmidt
>  wrote:
>> 
>>> On Mar 14, 2017, at 7:50 AM, Bill Schmidt  
>>> wrote:
>>> 
>>> 
 On Mar 14, 2017, at 3:57 AM, Richard Biener  
 wrote:
 
 On Tue, Mar 14, 2017 at 1:04 AM, Bill Schmidt
  wrote:
> 
> Index: gcc/tree-stdarg.c
> ===
> --- gcc/tree-stdarg.c   (revision 246109)
> +++ gcc/tree-stdarg.c   (working copy)
> @@ -1057,7 +1057,7 @@ expand_ifn_va_arg_1 (function *fun)
> types.  */
>  gimplify_assign (lhs, expr, );
>}
> -   else
> +   else if (is_gimple_addressable (expr))
>gimplify_expr (, , , is_gimple_lvalue, fb_lvalue);
 
 This is wrong - we lose side-effects this way and the only reason we 
 gimplify
 is to _not_ lose them.
 
 Better is sth like
 
 Index: gcc/tree-stdarg.c
 ===
 --- gcc/tree-stdarg.c   (revision 246082)
 +++ gcc/tree-stdarg.c   (working copy)
 @@ -1058,7 +1058,7 @@ expand_ifn_va_arg_1 (function *fun)
  gimplify_assign (lhs, expr, );
}
  else
 - gimplify_expr (, , , is_gimple_lvalue, fb_lvalue);
 + gimplify_expr (, , , is_gimple_val, fb_either);
 
  input_location = saved_location;
  pop_gimplify_context (NULL);
>>> 
>>> OK, thanks for the explanation.  Unfortunately this fails bootstrap with a 
>>> failed
>>> assert a little later.  I'll dig further.
>> 
>> Looks like is_gimple_val is too restrictive for MEM_REFs, for which 
>> is_gimple_lvalue
>> passes.  Trying this now:
> 
> Hmm, it should simply gimplify to a load if it's not aggregate.  Can
> you share a testcase
> where it doesn't work?

So taking a step back...

The original problem is that most VA_ARGs get gimplified to a single SSA var,
which always passes the is_gimple_addressable check, so if the LHS has either
been cast away or gone dead, we get a nice lvalue to work with and everyone is
happy.

For a VA_ARG of _Complex type, gimplification instead produces a
COMPLEX_EXPR  where a and b have been reduced to SSA vars.
The is_gimple_addressable check does not pass in this case, so we can't
find the mandated lvalue and ICE in the gimplifier after doing all the work.

I suppose we could paper over this with:

Index: gcc/tree-stdarg.c
===
--- gcc/tree-stdarg.c   (revision 246109)   
+++ gcc/tree-stdarg.c   (working copy)  
@@ -1058,7 +1058,10 @@ expand_ifn_va_arg_1 (function *fun)
gimplify_assign (lhs, expr, );  
  } 
else
- gimplify_expr (, , , is_gimple_lvalue, fb_lvalue);  
+ gimplify_expr (, , , is_gimple_lvalue,  
+fb_lvalue | fb_mayfail);   

...but that is perhaps opening the gate too wide (though we could throw
an error if gimplify_expr fails and expr is not a COMPLEX_EXPR).  The 
COMPLEX_EXPR really is not addressable, but forcing any COMPLEX_EXPR
to a variable in gimplify_expr also seems like overkill.  (All of the tcc_binary
expressions are treated the same; we would fail if somebody asked for an
lvalue of a PLUS_EXPR just the same.)  So offhand I don't see anything
better than the above.

Thoughts?

Thanks,
Bill 

[Bug target/71294] [6 Regression] ICE in gen_add2_insn, at optabs.c:4442 on powerpc64le-linux

[meissner at gcc dot gnu.org]

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

--- Comment #13 from Michael Meissner  ---
FWIW, it does not fail for -mcpu=power7 or -mcpu=power9.  If you use
-mcpu=power7, there is no direct move.  If you use -mcpu=power9, the MTVSRDD
instruction is generated which bypasses the part that is failing under reload.

[Bug fortran/79860] i18n: single-word translation in "Character-valued %s %qs"

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
Resolved in source tree by r246170 for next time gcc.pot is regenerated.

[Bug fortran/69499] [F03] ICE-on-invalid on combining select type with wrong statement

[koenigni at student dot ethz.ch]

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

--- Comment #7 from Nicolas Koenig  ---
(In reply to Jerry DeLisle from comment #6)
>
> This falls into the PITA classification. Also known as simple enough,
> regression test and commit. (consider it approved)

I don't think I can submit patches yet (no write access to the repo, working on
it), so it would be great if you or someone else could commit for me :)

[Bug fortran/79860] i18n: single-word translation in "Character-valued %s %qs"

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Author: dmalcolm
Date: Wed Mar 15 18:05:06 2017
New Revision: 246170

URL: https://gcc.gnu.org/viewcvs?rev=246170=gcc=rev
Log:
Fix translation issue with character length * errors (PR fortran/79860)

gcc/fortran/ChangeLog:
PR fortran/79860
* resolve.c (resolve_contained_fntype): Make error messages more
amenable to translation.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c

[Bug tree-optimization/78687] inefficient code generated for eggs.variant

[jamborm at gcc dot gnu.org]

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

--- Comment #6 from Martin Jambor  ---
Created attachment 40979
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40979=edit
Possible fix

This patch addresses the issue and passes bootstrap and testing on
x86_64-linux.  It is definitely too late to submit it for GCC 7 but if
we do not come a more substantial overhaul of SRA in the GCC 8 time
frame, I will submit it on the mailing list.

[Bug rtl-optimization/79856] rtl_verify_edges: use internal_error instead of error

[roland.illig at gmx dot de]

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

--- Comment #8 from Roland Illig  ---
(In reply to Martin Liška from comment #7)
> I like your rules. My question was more about how practically do you
> distinguish between such strings? My plan is to create a new
> DK_INTERNAL_ERROR type, which I would like to ignore in the translations.

I don't know what you mean by "distinguish". As I suggested in
https://gcc.gnu.org/ml/gcc/2017-03/msg00049.html, I would solve this by having
two separate functions for errors: error() and error_no_i18n().

Can you elaborate a bit on what you meant?

Re: Obsolete powerpc*-*-*spe*

[David Edelsohn]

On Wed, Mar 15, 2017 at 1:12 PM, Sandra Loosemore
 wrote:
> On 03/15/2017 08:26 AM, Segher Boessenkool wrote:
>
>> Since SPE and VLE only share the part of the rs6000 port that doesn't
>> change at all (except for a bug fix once or twice a year), and everything
>> else needs special cases all over the place, it seems to me it would be
>> best for everyone if we split the rs6000 port in two, one for SPE and VLE
>> and one for the rest.  Both ports could then be very significantly
>> simplified.
>>
>> I am assuming SPE and VLE do not support AltiVec or 64-bit PowerPC,
>> please correct me if that is incorrect.  Also, is "normal" floating
>> point supported at all?
>>
>> Do you (AdaCore and Mentor) think splitting the port is a good idea?
>
>
> I can't speak on behalf of Mentor, and Andrew is the target expert here, but
> we currently do ship all of SPE, VLE, and AltiVec multilibs in the same
> powerpc-eabi toolchain.  Specifically, the list is
>
> default (603e, e300c3, G2, etc)
> -te500v1
> -te500v2
> -te500mc
> -te600
> -te200z0
> -te200z3
> -te200z4
>
> plus some soft-float variants, etc.  Splitting these up into multiple
> toolchains that have to be statically configured for a particular
> architecture wouldn't be zero-cost either for us, other groups in Mentor
> that repackage our toolchains, or our end users.
>
> I'm wondering whether the code in the rs6000 backend could be refactored to
> better abstract and separate the complicated processor-dependent bits?

Sandra,

PowerPC, SPE and VLE are, to a large extent, different ISAs that share
some instruction mnemonics.  It requires overloading basic,
fundamental patterns in the GCC machine description.  Regardless of
way in which it is abstracted and refactored, it is going to be
complicated and difficult to maintain.

VLE is not going to be merged into the current rs6000 port of GCC.  If
AdaCore, Mentor and its customers want that functionality in FSF GCC,
they are going to have to take on the burden of a separate port.

I realize that splitting the port is not zero cost for Mentor, but
currently the vast majority of the maintenance cost is falling to the
IBM GCC Toolchain team.  That is not equitable and no longer
sustainable.  IBM can't shoulder the burden of lowering the
development expense for other vendors.

Thanks, David