[Bug middle-end/69975] Missing uninitilized warning / optimized to use wrong value

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #1 from Markus Trippelsdorf  ---
You're using a garbage value, that can be anything.

icc and clang also don't warn (only the microsoft compiler and "clang
--analyze" warn).

Re: [PATCH] [RFA] [PR tree-optmization/69740] Schedule loop fixups when needed

[Jeff Law]

On 02/25/2016 03:00 AM, Richard Biener wrote:


So I fail to see how only successor edges are relevant.  Isn't the important
case to catch whether we remove an edge marked EDGE_IRREDUCIBLE_LOOP?
Even if the BB persists we might have exposed a new loop here.

Note that it is not safe to look at {BB,EDGE}_IRREDUCIBLE_LOOP if the loop
state does not have LOOPS_HAVE_MARKED_IRREDUCIBLE_REGIONS set
(the flags may be stale or missing).  So it might be that we can't rely on
non-loop passes modifying the CFG to handle this optimistically.

Thus, how about (my main point) moving this to remove_edge instead, like
Yea.  That works.  The !loops_state_satisfies_p check will almost 
certainly cause us to trigger loop cleanups more often, but I think it's 
the right/safe thing to do to catch cases where we haven't go the 
IRREDUCIBLE_LOOP flags set.



Bootstrapped and regression tested on x86_64-linux-gnu.  OK for the trunk?

Thanks,
Jeff

PR tree-optimization/69740
* cfghooks.c (remove_edge): Request loop fixups if we delete
an edge that might turn an irreducible loop into a natural
loop.

PR tree-optimization/69740
* gcc.c-torture/compile/pr69740-1.c: New test.
* gcc.c-torture/compile/pr69740-2.c: New test.

diff --git a/gcc/cfghooks.c b/gcc/cfghooks.c
index bbb1017..f80e455 100644
--- a/gcc/cfghooks.c
+++ b/gcc/cfghooks.c
@@ -408,7 +408,14 @@ void
 remove_edge (edge e)
 {
   if (current_loops != NULL)
-rescan_loop_exit (e, false, true);
+{
+  rescan_loop_exit (e, false, true);
+
+  if (!loops_state_satisfies_p (LOOPS_HAVE_MARKED_IRREDUCIBLE_REGIONS)
+ || (e->flags & EDGE_IRREDUCIBLE_LOOP)
+ || (e->dest->flags & BB_IRREDUCIBLE_LOOP))
+   loops_state_set (LOOPS_NEED_FIXUP);
+}
 
   /* This is probably not needed, but it doesn't hurt.  */
   /* FIXME: This should be called via a remove_edge hook.  */
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr69740-1.c 
b/gcc/testsuite/gcc.c-torture/compile/pr69740-1.c
new file mode 100644
index 000..ac867d8
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr69740-1.c
@@ -0,0 +1,12 @@
+char a;
+short b;
+void fn1() {
+  if (b)
+;
+  else {
+int c[1] = {0};
+  l1:;
+  }
+  if (a)
+goto l1;
+}
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr69740-2.c 
b/gcc/testsuite/gcc.c-torture/compile/pr69740-2.c
new file mode 100644
index 000..a89c9a0
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr69740-2.c
@@ -0,0 +1,19 @@
+inline int foo(int *p1, int p2) {
+  int z = *p1;
+  while (z > p2)
+p2 = 2;
+  return z;
+}
+int main() {
+  int i;
+  for (;;) {
+int j, k;
+i = foo(, 7);
+if (k)
+  j = i;
+else
+  k = j;
+if (2 != j)
+  __builtin_abort();
+  }
+}

[Bug bootstrap/69709] [6 Regression] profiled bootstrap error on s390x-linux-gnu with r233194

[krebbel at gcc dot gnu.org]

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

--- Comment #13 from Andreas Krebbel  ---
Yes. This was problem. Your patch fixes this. Thanks!

[Bug middle-end/69975] New: Missing uninitilized warning / optimized to use wrong value

[jan.sm...@alcatel-lucent.com]

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

Bug ID: 69975
   Summary: Missing uninitilized warning / optimized to use wrong
value
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.sm...@alcatel-lucent.com
  Target Milestone: ---

#include 

int X;

int foo(int yyy, int zzz)
{
int xxx;

if (yyy)
{
printf("in y\n");
xxx = 5;
}

if (zzz)
{
printf("in x\n");
X = xxx;
}

return X;
}

int main(void)
{
printf("got %d\n", foo(0,1));
return 0;
}


$ gcc test-uninit.c -o /tmp/bla -O1  -Wall -Wuninitialized  && /tmp/bla
in x
got 5

$ gcc test-uninit.c -o /tmp/bla -O0  -Wall -Wuninitialized  && /tmp/bla
in x
got 0


I would have expected random garbage from the stack, but never ever '5'. 
(which makes it seem as if the (yyy) condition was true.)

And this should really give a compile time warning.

If this is considered undefined behaviour, then it is not cought by
-fsanitize=undefined in GCC 5.3

[Bug c/69974] New: gcc ICE on invalid code on x86_64-linux-gnu in "create_tmp_from_val"

[helloqirun at gmail dot com]

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

Bug ID: 69974
   Summary: gcc ICE on invalid code on x86_64-linux-gnu in
"create_tmp_from_val"
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helloqirun at gmail dot com
  Target Milestone: ---

The following invalid code causes an ICE when compiled with the current gcc
trunk on x86_64-linux-gnu in both 32-bit and 64-bit modes.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20160225 (experimental) [trunk revision 233714] (GCC)



$ gcc-trunk abc.c
abc.c:1:11: error: expected '=', ',', ';', 'asm' or '__attribute__' before ')'
token
 char var1 );
   ^
abc.c: In function 'fn1':
abc.c:5:13: warning: implicit declaration of function 'var1'
[-Wimplicit-function-declaration]
 var3 &= var1 ( 
 ^~~~
abc.c:5:5: error: expected ')' at end of input
 var3 &= var1 ( 
 ^~~~
abc.c:5:5: error: expected declaration or statement at end of input
abc.c: At top level:
abc.c:2:11: error: storage size of 'var2' isn't known
 struct S1 var2;
   ^~~~
abc.c: In function 'fn1':
abc.c:5:13: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in create_tmp_from_val, at gimplify.c:497
 var3 &= var1 ( 

0xddd3b7 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/gcc/tree.c:9688
0x8f61ef tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc/gcc/tree.h:3129
0x8f61ef create_tmp_from_val
../../gcc/gcc/gimplify.c:497
0x8f61ef lookup_tmp_var
../../gcc/gcc/gimplify.c:533
0x8f61ef internal_get_tmp_var
../../gcc/gcc/gimplify.c:563
0x8fc462 get_initialized_tmp_var(tree_node*, gimple**, gimple**)
../../gcc/gcc/gimplify.c:600
0x8fc462 gimplify_save_expr
../../gcc/gcc/gimplify.c:4979
0x8fc462 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:10452
0x9015e6 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.c:5644
0x9021f1 gimplify_compound_expr
../../gcc/gcc/gimplify.c:4934
0x8fe64c gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:10153
0x9015e6 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.c:5644
0x902825 gimplify_bind_expr
../../gcc/gcc/gimplify.c:1142
0x8fc8b2 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:10363
0x9015e6 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.c:5644
0x903444 gimplify_body(tree_node*, bool)
../../gcc/gcc/gimplify.c:11295
0x903ad6 gimplify_function_tree(tree_node*)
../../gcc/gcc/gimplify.c:11451
0x786e27 cgraph_node::analyze()
../../gcc/gcc/cgraphunit.c:625
0x78a193 analyze_functions
../../gcc/gcc/cgraphunit.c:1086
0x78aed8 symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2540
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.



$ cat abc.c
char var1 );
struct S1 var2;
int var3;
void fn1() {
var3 &= var1 ( 

[Bug lto/69953] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail

[john.frankish at outlook dot com]

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

--- Comment #4 from john.frankish at outlook dot com ---
Created attachment 37800
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37800=edit
preprocessed gtkmm-3.16.0/gtk/gtkmm/treeviewcolumn.cc

I'm not too sure what I'm doing here, but Gtk::TreeViewColumn seems to be
implemented by gtkmm-3.16.0/gtk/gtkmm/treeviewcolumn.cc

Outout attached from:

$ g++ -flto -fuse-linker-plugin -mtune=generic -Os -pipe -std=c++11 -E
gtkmm-3.16.0/gtk/gtkmm/treeviewcolumn.cc -I/usr/local/include/glibmm-2.4
-I/usr/local/lib/glibmm-2.4/include -I/usr/local/include/glib-2.0
-I/usr/local/lib/glib-2.0/include -I/usr/local/include/sigc++-2.0
-I/usr/local/lib/sigc++-2.0/include -I/usr/local/include/gtkmm-3.0
-I/usr/local/lib/gtkmm-3.0/include -I/usr/local/lib/gdkmm-3.0/include
-I/usr/local/lib/pangomm-1.4/include -I/usr/local/include/gtk-3.0
-I/usr/local/include/pango-1.0 -I/usr/local/include/cairo
-I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/atk-1.0
-I/usr/local/include/pangomm-1.4 -I/usr/local/include/cairomm-1.0
-I/usr/local/include/freetype2 -I/usr/local/include/atkmm-1.6
-I/usr/local/include/gdkmm-3.0 -I/usr/local/include/giomm-2.4

[PATCH, rs6000] Fixing PR 67145

[Richard Henderson]

It's the simplify-rtx.c portion of the patch that fixes the i686 regression.

In the PR, Alan raises some good points, but I don't believe that we can 
address those for gcc6.  A new rtl reassoc optimization that takes loop 
invariance into account will have to wait.


But we do need to take care of the rs6000 ice that results, and that's the bulk 
of the patch -- allowing CA to be sorted to any register of the plus chain.


Some notes:

ca_operand doesn't work as written, since CA_REGNO is not an available 
register, and thus doesn't satisfy register_operand.


Is there any particular reason that subf<>3_carry_in_m1 was written with minus 
rather than plus like all of the other patterns?



Tested on ppc64le-linux.


r~
* simplify-rtx.c (simplify_plus_minus): If only PLUS of REG,
rematerialize the canonical chain.

* config/rs6000/predicates.md (ca_operand): Use match_code.
(gpc_ca_reg_operand): New.
* config/rs6000/rs6000.md (add3_carry_in): Expand by hand.
(subf3_carry_in): Likewise.
(*add3_carry_in_reg): Rename from *add3_carry_in_internal;
accept CA at any register position, exactly once.
(*add3_carry_in_0): Similarly.
(*add3_carry_in_m1): Similarly.
(*subf3_carry_in_reg): Similarly.
(*subf3_carry_in_0): Rename with leading *.
(*subf3_carry_in_m1): Rename with leading *; use the same
plus/plus/not form as subf3_carry_in_reg.

diff --git a/gcc/config/rs6000/predicates.md b/gcc/config/rs6000/predicates.md
index 072291e..98937bd 100644
--- a/gcc/config/rs6000/predicates.md
+++ b/gcc/config/rs6000/predicates.md
@@ -116,7 +116,7 @@
 
 ;; Return 1 if op is the carry register.
 (define_predicate "ca_operand"
-  (match_operand 0 "register_operand")
+  (match_code "reg,subreg")
 {
   if (GET_CODE (op) == SUBREG)
 op = SUBREG_REG (op);
@@ -230,6 +230,10 @@
   return INT_REGNO_P (REGNO (op)) || FP_REGNO_P (REGNO (op));
 })
 
+(define_predicate "gpc_ca_reg_operand"
+  (ior (match_operand 0 "gpc_reg_operand")
+   (match_operand 0 "ca_operand")))
+
 ;; Return 1 if op is a general purpose register.  Unlike gpc_reg_operand, don't
 ;; allow floating point or vector registers.
 (define_predicate "int_reg_operand"
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 0299a00..b300727 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -1770,50 +1770,65 @@
 (define_expand "add3_carry_in"
   [(parallel [
  (set (match_operand:GPR 0 "gpc_reg_operand")
- (plus:GPR (plus:GPR (match_operand:GPR 1 "gpc_reg_operand")
- (match_operand:GPR 2 "adde_operand"))
-   (reg:GPR CA_REGNO)))
+ (plus:GPR
+   (plus:GPR
+ (reg:GPR CA_REGNO)
+  (match_operand:GPR 1 "gpc_reg_operand"))
+   (match_operand:GPR 2 "adde_operand")))
  (clobber (reg:GPR CA_REGNO))])]
   ""
 {
-  if (operands[2] == const0_rtx)
-{
-  emit_insn (gen_add3_carry_in_0 (operands[0], operands[1]));
-  DONE;
-}
-  if (operands[2] == constm1_rtx)
-{
-  emit_insn (gen_add3_carry_in_m1 (operands[0], operands[1]));
-  DONE;
-}
+  rtx ca = gen_rtx_REG (mode, CA_REGNO);
+  rtx x, y;
+
+  x = gen_rtx_PLUS (mode, ca, operands[1]);
+  if (operands[2] != const0_rtx)
+x = gen_rtx_PLUS (mode, x, operands[2]);
+  x = gen_rtx_SET (operands[0], x);
+  y = gen_rtx_CLOBBER (VOIDmode, ca);
+
+  emit_insn (gen_rtx_PARALLEL (VOIDmode, gen_rtvec (2, x, y)));
+  DONE;
 })
 
-(define_insn "*add3_carry_in_internal"
-  [(set (match_operand:GPR 0 "gpc_reg_operand" "=r")
-   (plus:GPR (plus:GPR (match_operand:GPR 1 "gpc_reg_operand" "r")
-   (match_operand:GPR 2 "gpc_reg_operand" "r"))
- (reg:GPR CA_REGNO)))
+(define_insn "*add3_carry_in_reg"
+  [(set (match_operand:GPR 0 "gpc_reg_operand" "=r,r,r")
+   (plus:GPR
+ (plus:GPR
+   (match_operand:GPR 1 "gpc_ca_reg_operand" "z,r,r")
+   (match_operand:GPR 2 "gpc_ca_reg_operand" "r,z,r"))
+ (match_operand:GPR 3 "gpc_ca_reg_operand"   "r,r,z")))
(clobber (reg:GPR CA_REGNO))]
-  ""
-  "adde %0,%1,%2"
+  "ca_operand (operands[1], mode)
+   + ca_operand (operands[2], mode)
+   + ca_operand (operands[3], mode) == 1"
+  "@
+   adde %0,%2,%3
+   adde %0,%1,%3
+   adde %0,%1,%2"
   [(set_attr "type" "add")])
 
-(define_insn "add3_carry_in_0"
+(define_insn "*add3_carry_in_0"
   [(set (match_operand:GPR 0 "gpc_reg_operand" "=r")
-   (plus:GPR (match_operand:GPR 1 "gpc_reg_operand" "r")
- (reg:GPR CA_REGNO)))
+   (plus:GPR
+ (match_operand:GPR 1 "gpc_ca_reg_operand" "%r")
+ (match_operand:GPR 2 "gpc_ca_reg_operand" "z")))
(clobber (reg:GPR CA_REGNO))]
-  ""
+  "ca_operand (operands[1], mode)
+   + ca_operand (operands[2], mode) == 1"
   "addze %0,%1"
   [(set_attr "type" "add")])
 
-(define_insn "add3_carry_in_m1"
+(define_insn 

[Bug c++/69889] [6 Regression] ICE: in assign_temp, at function.c:961

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Fri Feb 26 04:53:58 2016
New Revision: 233733

URL: https://gcc.gnu.org/viewcvs?rev=233733=gcc=rev
Log:
PR c++/69889

* cp-tree.h (AGGR_INIT_FROM_THUNK_P): New.
* tree.c (build_aggr_init_expr): Set it.
* semantics.c (simplify_aggr_init_expr): Check it.
* cp-gimplify.c (cp_genericize_r): Don't walk into
a call/aggr_init from a thunk.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-conv10.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/semantics.c
trunk/gcc/cp/tree.c

C++ PATCH for c++/69889 (ICE with lambda conversion)

[Jason Merrill]

Here, we were crashing because the artificial thunk returned by the 
lambda conversion operator was dereferencing an invisible reference 
parameter instead of passing it through.  I needed to fix 
cp_genericize_r to avoid that like it already does for virtual function 
thunks.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 3180adca839ba43c21834ef6cb6af7bbc8eda478
Author: Jason Merrill 
Date:   Thu Feb 25 21:40:09 2016 -0500

	PR c++/69889

	* cp-tree.h (AGGR_INIT_FROM_THUNK_P): New.
	* tree.c (build_aggr_init_expr): Set it.
	* semantics.c (simplify_aggr_init_expr): Check it.
	* cp-gimplify.c (cp_genericize_r): Don't walk into
	a call/aggr_init from a thunk.

diff --git a/gcc/cp/cp-gimplify.c b/gcc/cp/cp-gimplify.c
index a77b242..6af3760 100644
--- a/gcc/cp/cp-gimplify.c
+++ b/gcc/cp/cp-gimplify.c
@@ -1021,10 +1021,16 @@ cp_genericize_r (tree *stmt_p, int *walk_subtrees, void *data)
   && omp_var_to_track (stmt))
 omp_cxx_notice_variable (wtd->omp_ctx, stmt);
 
-  if (is_invisiref_parm (stmt)
-  /* Don't dereference parms in a thunk, pass the references through. */
-  && !(DECL_THUNK_P (current_function_decl)
-	   && TREE_CODE (stmt) == PARM_DECL))
+  /* Don't dereference parms in a thunk, pass the references through. */
+  if ((TREE_CODE (stmt) == CALL_EXPR && CALL_FROM_THUNK_P (stmt))
+  || (TREE_CODE (stmt) == AGGR_INIT_EXPR && AGGR_INIT_FROM_THUNK_P (stmt)))
+{
+  *walk_subtrees = 0;
+  return NULL;
+}
+
+  /* Otherwise, do dereference invisible reference parms.  */
+  if (is_invisiref_parm (stmt))
 {
   *stmt_p = convert_from_reference (stmt);
   *walk_subtrees = 0;
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 88c6367..b1dc23c 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -3409,6 +3409,11 @@ extern void decl_shadowed_for_var_insert (tree, tree);
 #define AGGR_INIT_ZERO_FIRST(NODE) \
   TREE_LANG_FLAG_2 (AGGR_INIT_EXPR_CHECK (NODE))
 
+/* Nonzero means that the call is the jump from a thunk to the
+   thunked-to function.  */
+#define AGGR_INIT_FROM_THUNK_P(NODE) \
+  (AGGR_INIT_EXPR_CHECK (NODE)->base.protected_flag)
+
 /* AGGR_INIT_EXPR accessors.  These are equivalent to the CALL_EXPR
accessors, except for AGGR_INIT_EXPR_SLOT (which takes the place of
CALL_EXPR_STATIC_CHAIN).  */
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index fad233a..fd83c46 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -4067,6 +4067,7 @@ simplify_aggr_init_expr (tree *tp)
 AGGR_INIT_EXPR_ARGP (aggr_init_expr));
   TREE_NOTHROW (call_expr) = TREE_NOTHROW (aggr_init_expr);
   CALL_EXPR_LIST_INIT_P (call_expr) = CALL_EXPR_LIST_INIT_P (aggr_init_expr);
+  CALL_FROM_THUNK_P (call_expr) = AGGR_INIT_FROM_THUNK_P (aggr_init_expr);
 
   if (style == ctor)
 {
diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index ac38ce3..9e29a42 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -464,18 +464,25 @@ build_aggr_init_expr (tree type, tree init)
 {
   slot = build_local_temp (type);
 
-  if (TREE_CODE(init) == CALL_EXPR)
-	rval = build_aggr_init_array (void_type_node, fn, slot,
-  call_expr_nargs (init),
-  CALL_EXPR_ARGP (init));
+  if (TREE_CODE (init) == CALL_EXPR)
+	{
+	  rval = build_aggr_init_array (void_type_node, fn, slot,
+	call_expr_nargs (init),
+	CALL_EXPR_ARGP (init));
+	  AGGR_INIT_FROM_THUNK_P (rval)
+	= CALL_FROM_THUNK_P (init);
+	}
   else
-	rval = build_aggr_init_array (void_type_node, fn, slot,
-  aggr_init_expr_nargs (init),
-  AGGR_INIT_EXPR_ARGP (init));
+	{
+	  rval = build_aggr_init_array (void_type_node, fn, slot,
+	aggr_init_expr_nargs (init),
+	AGGR_INIT_EXPR_ARGP (init));
+	  AGGR_INIT_FROM_THUNK_P (rval)
+	= AGGR_INIT_FROM_THUNK_P (init);
+	}
   TREE_SIDE_EFFECTS (rval) = 1;
   AGGR_INIT_VIA_CTOR_P (rval) = is_ctor;
   TREE_NOTHROW (rval) = TREE_NOTHROW (init);
-  CALL_EXPR_LIST_INIT_P (rval) = CALL_EXPR_LIST_INIT_P (init);
 }
   else
 rval = init;
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-conv10.C b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-conv10.C
new file mode 100644
index 000..8e806c8
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-conv10.C
@@ -0,0 +1,34 @@
+// PR c++/69889
+// { dg-do compile { target c++11 } }
+
+template  struct Tag {
+  static void fp() { f()(0); }
+  static F f() {}
+};
+
+struct Dispatch {
+  template  Dispatch(F&&) : f(Tag::fp) {}
+  void (*f)();
+};
+
+struct Empty { Empty(Empty&&); };
+
+struct Value {
+  Value();
+  template  Value(U);
+  void call(Dispatch);
+  Empty e;
+};
+
+struct EmptyValue {
+  EmptyValue(EmptyValue&&);
+  EmptyValue();
+};
+
+struct User {
+  User() {
+Value().call([](Value) { return EmptyValue(); });
+  }
+};
+
+User user;

[Bug c/69973] New: ICE on excessive attribute vector_size

[msebor at gcc dot gnu.org]

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

Bug ID: 69973
   Summary: ICE on excessive attribute vector_size
   Product: gcc
   Version: 6.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: ---

Attribute vector_size with a size of 1 << 29 or greater causes an ICE in all
tested versions of GCC all the way back to 4.5 on powerpc64le as well as
x86_64.

$ cat t.c && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -S -Wall -Wextra
-Wpedantic -o/dev/null -xc t.c
typedef int v4si __attribute__ ((vector_size (1 << 29)));
t.c:1:1: internal compiler error: in layout_type, at stor-layout.c:2209
 typedef int v4si __attribute__ ((vector_size (1 << 29)));
 ^~~
0x10d0fe37 layout_type(tree_node*)
/src/gcc/trunk/gcc/stor-layout.c:2208
0x111dc6cb make_vector_type
/src/gcc/trunk/gcc/tree.c:9890
0x111e0e9b build_vector_type(tree_node*, int)
/src/gcc/trunk/gcc/tree.c:10703
0x10443b37 handle_vector_size_attribute
/src/gcc/trunk/gcc/c-family/c-common.c:9013
0x102fccaf decl_attributes(tree_node**, tree_node*, int)
/src/gcc/trunk/gcc/attribs.c:551
0x10315d2b c_decl_attributes
/src/gcc/trunk/gcc/c/c-decl.c:4413
0x1031648b start_decl(c_declarator*, c_declspecs*, bool, tree_node*)
/src/gcc/trunk/gcc/c/c-decl.c:4551
0x103a10a3 c_parser_declaration_or_fndef
/src/gcc/trunk/gcc/c/c-parser.c:1965
0x1039fedf c_parser_external_declaration
/src/gcc/trunk/gcc/c/c-parser.c:1551
0x1039f897 c_parser_translation_unit
/src/gcc/trunk/gcc/c/c-parser.c:1429
0x103db91b c_parse_file()
/src/gcc/trunk/gcc/c/c-parser.c:17843
0x10481e0b c_common_parse_file()
/src/gcc/trunk/gcc/c-family/c-opts.c:1064
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/69972] New: duplicate integer overflow diagnostic in constant expressions

[msebor at gcc dot gnu.org]

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

Bug ID: 69972
   Summary: duplicate integer overflow diagnostic in constant
expressions
   Product: gcc
   Version: 6.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: ---

Both the C and the C++ front ends issue duplicate diagnostics for integer
overflows in constant expressions.  For example, in C:

$ /home/msebor/build/gcc-4.9.3/gcc/xgcc -B/home/msebor/build/gcc-4.9.3/gcc -S
-Wall -Wextra -Wpedantic -o/dev/null -xc x.c
x.c:1:24: warning: integer overflow in expression [-Woverflow]
 enum { e = __INT_MAX__ + 1 };
^
x.c:1:8: warning: overflow in constant expression [-Woverflow]
 enum { e = __INT_MAX__ + 1 };
^

G++ issues two similar kinds of diagnostics for the following code, one
-Woverflow and another -fpermissive:

$ cat t.c && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -S -Wall -Wextra
-Wpedantic -o/dev/null -xc++ t.c
template  struct S { };
S<(__INT_MAX__ + 1)> s;
t.c:2:16: warning: integer overflow in expression [-Woverflow]
 S<(__INT_MAX__ + 1)> s;
^~~
t.c:2:20: error: overflow in constant expression [-fpermissive]
 S<(__INT_MAX__ + 1)> s;
^
t.c:2:20: note: in template argument for type ‘int’

[Bug c/69971] New: repetitive code with __builtin_return_address with a large level

[msebor at gcc dot gnu.org]

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

Bug ID: 69971
   Summary: repetitive code with __builtin_return_address with a
large level
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Calling __builtin_return_address with a large argument (say due to a coding bug
obscured by macros or template arguments) can result in resource exhaustion by
the compiler as it emits at least one instruction for each level.  It seems
that for levels greater some threshold GCC could emit a loop instead to avoid
this problem (as unlikely as it may be).

The following is an example run on powerpc64le where GCC emits a stream of ld
9,0(9) instructions, one for each level:

$ cat t.c && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -S -Wall -Wextra
-Wpedantic -o/dev/stdout t.c | grep "ld 9" | wc -l
void* foo (void)
{
void *p = __builtin_return_address (1024);
return p;
}
t.c: In function ‘foo’:
t.c:3:11: warning: calling ‘__builtin_return_address’ with a nonzero argument
is unsafe [-Wframe-address]
 void *p = __builtin_return_address (1024);
   ^
1027

[Bug c++/69889] [6 Regression] ICE: in assign_temp, at function.c:961

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[PATCH] add more style checks to check_GNU_style.sh

[Martin Sebor]

Recently I had the opportunity to learn about a number of rather
subtle style conventions sometimes enforced during code reviews
(though not inconsistently followed in GCC code).  To help find
these kinds of problems before a patch is submitted and cut down
on the subsequent back-and-forth, I've added checks for some of
these conventions to the check_GNU_style.sh script.  In addition,
since the script tends to produce lots of noise for things that
can't be fixed in tests like lines in excess of 80 characters
caused by dg-error directives, I tweaked it to suppress these.

To verify that the new checkers don't add too much noise I ran
the patched script on the last 1000 commits, both with and without
testsuite changes (all without libstdc++).  The results are below.
It's telling that over a quarter of all commits violate even the
limited subset of the GNU coding guidelines the script checks for.

  script w/o tests  w/tests
  baseline  258   434
  patched   282   466

FWIW, to make the script more usable (e.g., to check the rules
appropriate for each file type, including documentation), it
will need to be considerably enhanced.  I think most of it can
be done in AWK (already used by the script), and I might try
to tackle that at some point in the future.

Martin
contrib/ChangeLog:
2016-02-25  Martin Sebor  

	* check_GNU_style.sh: Add a new global variable.
	Add checks for trailing operators and spaces before left brackets.
	Tightened up a check for a trailing left curly brace.
	(g, ag, vg): Use color.
	(col): Don't complain about excessively long lines with DejaGnu
	directives.

Index: contrib/check_GNU_style.sh
===
--- contrib/check_GNU_style.sh	(revision 233722)
+++ contrib/check_GNU_style.sh	(working copy)
@@ -1,7 +1,7 @@
 #!/bin/sh
 
 # Checks some of the GNU style formatting rules in a set of patches.
-# Copyright (C) 2010, 2012  Free Software Foundation, Inc.
+# Copyright (C) 2010, 2012, 2016  Free Software Foundation, Inc.
 # Contributed by Sebastian Pop 
 
 # This program is free software; you can redistribute it and/or modify
@@ -15,8 +15,11 @@
 # GNU General Public License for more details.
 
 # You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software
-# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+# along with this program; if not, see the file COPYING3.  If not,
+# see .
+
+# Set to empty in the environment to override.
+: ${color:---color=always}
 
 usage() {
 cat < "$tmp" && found=true
 
 if $found; then
@@ -117,8 +120,8 @@ ag (){
 
 local found=false
 cat $inp \
-	| egrep --color=always -- "$arg1" \
-	| egrep --color=always -- "$arg2" \
+	| egrep $color -- "$arg1" \
+	| egrep $color -- "$arg2" \
 	> "$tmp" && found=true
 
 if $found; then
@@ -136,7 +139,7 @@ vg (){
 local found=false
 cat $inp \
 	| egrep -v -- "$varg" \
-	| egrep --color=always -- "$arg" \
+	| egrep $color -- "$arg" \
 	> "$tmp" && found=true
 
 if $found; then
@@ -171,10 +174,11 @@ col (){
 	# Expand tabs to spaces according to tab positions.
 	# Keep long lines, make short lines empty.  Print the part past 80 chars
 	# in red.
+# Don't complain about dg-xxx directives in tests.
 	cat "$tmp" \
 	| sed 's/^[0-9]*:+//' \
 	| expand \
-	| awk '{ \
+	| awk '$0 !~ /{[[:space:]]*dg-(error|warning|message)[[:space:]]/ { \
 		 if (length($0) > 80) \
 		   printf "%s\033[1;31m%s\033[0m\n", \
 			  substr($0,1,80), \
@@ -201,6 +205,7 @@ col (){
 done
 }
 
+
 col 'Lines should not exceed 80 characters.'
 
 g 'Blocks of 8 spaces should be replaced with tabs.' \
@@ -221,13 +226,20 @@ g 'Dot, space, space, end of comment.' \
 g 'Sentences should end with a dot.  Dot, space, space, end of the comment.' \
 '[[:alnum:]][[:blank:]]*\*/'
 
-vg 'There should be exactly one space between function name and parentheses.' \
+vg 'There should be exactly one space between function name and parenthesis.' \
 '\#define' \
 '[[:alnum:]]([[:blank:]]{2,})?\('
 
-g 'There should be no space before closing parentheses.' \
+g 'There should be no space before a left square bracket.' \
+   '[[:alnum:]][[:blank:]]+\['
+
+g 'There should be no space before closing parenthesis.' \
 '[[:graph:]][[:blank:]]+\)'
 
-ag 'Braces should be on a separate line.' \
-'\{' \
-'if[[:blank:]]\(|while[[:blank:]]\(|switch[[:blank:]]\('
+# This will give false positives for C99 compound literals.
+g 'Braces should be on a separate line.' \
+'(\)|else)[[:blank:]]*{'
+
+# Does this apply to definition of aggregate objects?
+g 'Trailing operator.' \
+  '(([^a-zA-Z_]\*)|([-%<=&|^?])|([^*]/)|([^:][+]))$'

[RFC][PATCH][PR63586] Convert x+x+x+x into 4*x

[kugan]

Hi,

This is an attempt to fix missed optimization: x+x+x+x -> 4*x as 
reported in PR63586.


Regression tested and bootstrapped on x86-64-linux-gnu with no new 
regressions.


Is this OK for next stage1?

Thanks,
Kugan


gcc/testsuite/ChangeLog:

2016-02-26  Kugan Vivekanandarajah  

PR middle-end/63586
* gcc.dg/tree-ssa/reassoc-14.c: Fix multiply count.

gcc/ChangeLog:

2016-02-26  Kugan Vivekanandarajah  

PR middle-end/63586
* tree-ssa-reassoc.c (transform_add_to_multiply): New.
(reassociate_bb): Call transform_add_to_multiply.


diff --git a/gcc/testsuite/gcc.dg/tree-ssa/reassoc-14.c 
b/gcc/testsuite/gcc.dg/tree-ssa/reassoc-14.c
index 62802d1..16ebc86 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/reassoc-14.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/reassoc-14.c
@@ -19,6 +19,7 @@ unsigned int test2 (unsigned int x, unsigned int y, unsigned 
int z,
   return tmp1 + tmp2 + tmp3;
 }
 
-/* There should be one multiplication left in test1 and three in test2.  */
+/* There should be two multiplication left in test1 (inculding one generated
+   when converting addition to multiplication) and three in test2.  */
 
-/* { dg-final { scan-tree-dump-times "\\\*" 4 "reassoc1" } } */
+/* { dg-final { scan-tree-dump-times "\\\*" 5 "reassoc1" } } */
diff --git a/gcc/tree-ssa-reassoc.c b/gcc/tree-ssa-reassoc.c
index dfd0da1..2454b9d 100644
--- a/gcc/tree-ssa-reassoc.c
+++ b/gcc/tree-ssa-reassoc.c
@@ -1698,6 +1698,61 @@ eliminate_redundant_comparison (enum tree_code opcode,
   return false;
 }
 
+/* Recursively transoform repeated addition of same values into multiply with
+   constant.  */
+static void
+transform_add_to_multiply (gimple_stmt_iterator *gsi, gimple *stmt, 
vec *ops)
+{
+  operand_entry *oe;
+  tree op = NULL_TREE;
+  int i, start = -1, end = 0, count = 0;
+
+  /* Look for repeated operands.  */
+  FOR_EACH_VEC_ELT (*ops, i, oe)
+{
+  if (start == -1)
+   {
+ count = 1;
+ op = oe->op;
+ start = i;
+   }
+  else if (operand_equal_p (oe->op, op, 0))
+   {
+ count++;
+ end = i;
+   }
+  else if (count == 1)
+   {
+ count = 1;
+ op = oe->op;
+ start = i;
+   }
+  else
+   break;
+}
+
+  if (count > 1)
+{
+  /* Convert repeated operand addition to multiplication.  */
+  for (i = end; i >= start; --i)
+   ops->unordered_remove (i);
+  tree tmp = make_temp_ssa_name (TREE_TYPE (op), NULL, "reassocmul");
+  gassign *mul_stmt = gimple_build_assign (tmp, MULT_EXPR,
+  op, build_int_cst 
(TREE_TYPE(op), count));
+  gimple_set_location (mul_stmt, gimple_location (stmt));
+  gimple_set_uid (mul_stmt, gimple_uid (stmt));
+  gsi_insert_before (gsi, mul_stmt, GSI_SAME_STMT);
+  oe = operand_entry_pool.allocate ();
+  oe->op = tmp;
+  oe->rank = get_rank (op) * count;
+  oe->id = 0;
+  oe->count = 1;
+  ops->safe_push (oe);
+  transform_add_to_multiply (gsi, stmt, ops);
+}
+}
+
+
 /* Perform various identities and other optimizations on the list of
operand entries, stored in OPS.  The tree code for the binary
operation between all the operands is OPCODE.  */
@@ -4854,6 +4909,12 @@ reassociate_bb (basic_block bb)
  && flag_unsafe_math_optimizations)
powi_result = attempt_builtin_powi (stmt, );
 
+ if (rhs_code == PLUS_EXPR)
+   {
+ transform_add_to_multiply (, stmt, );
+ ops.qsort (sort_by_operand_rank);
+   }
+
  /* If the operand vector is now empty, all operands were 
 consumed by the __builtin_powi optimization.  */
  if (ops.length () == 0)

[RFC][PATCH][PR40921] Convert x + (-y * z * z) into x - y * z * z

[kugan]

Hi,

This is an attempt to fix missed optimization: x + (-y * z * z) => x - y 
* z * z as reported in PR40921.


Regression tested and bootstrapped on x86-64-linux-gnu with no new 
regressions.


Is this OK for next stage1?

Thanks,
Kugan


gcc/ChangeLog:

2016-02-26  Kugan Vivekanandarajah  

PR middle-end/40921
* tree-ssa-reassoc.c (propagate_neg_to_sub_or_add): New.
(reassociate_bb): Call propagate_neg_to_sub_or_add.


gcc/testsuite/ChangeLog:

2016-02-26  Kugan Vivekanandarajah  

PR middle-end/40921
* gcc.dg/tree-ssa/pr40921.c: New test.
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr40921.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr40921.c
index e69de29..6a3529b 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/pr40921.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr40921.c
@@ -0,0 +1,11 @@
+
+/* PR middle-end/40921.  */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-reassoc1 -fno-rounding-math" } */
+
+double foo (double x, double y, double z)
+{
+return x + (-y * z*z);
+}
+
+/* { dg-final { scan-tree-dump-times "= -" 0 "reassoc1" } } */
diff --git a/gcc/tree-ssa-reassoc.c b/gcc/tree-ssa-reassoc.c
index e54700e..f99635b 100644
--- a/gcc/tree-ssa-reassoc.c
+++ b/gcc/tree-ssa-reassoc.c
@@ -4784,6 +4784,78 @@ transform_stmt_to_multiply (gimple_stmt_iterator *gsi, 
gimple *stmt,
 }
 }
 
+/* Propagate NEGATE_EXPR to MINUS_EXPR/PLUS_EXPR when the neageted
+   expression is multiplied and used in MINUS_EXPR/PLUS_EXPR.  */
+static void
+propagate_neg_to_sub_or_add (gimple_stmt_iterator *gsi, gimple *stmt)
+{
+  tree lhs = gimple_assign_lhs (stmt);
+  tree rhs1, rhs2, mult_lhs;
+  gimple *use_stmt;
+  gimple *use_stmt2;
+  use_operand_p use;
+  enum tree_code code;
+  gassign *g;
+
+  /* Note that -frounding-math should disable the proposed
+ optimization.  */
+  if (flag_rounding_math)
+return;
+
+  if (!single_imm_use (lhs, , _stmt))
+return;
+
+  if (!is_gimple_assign (use_stmt))
+return;
+
+  code = gimple_assign_rhs_code (use_stmt);
+  if (code != MULT_EXPR)
+return;
+  mult_lhs = gimple_assign_lhs (use_stmt);
+  while (code == MULT_EXPR)
+{
+  if (!single_imm_use (mult_lhs, , _stmt2))
+   break;
+  if (!is_gimple_assign (use_stmt2))
+   break;
+  code = gimple_assign_rhs_code (use_stmt2);
+  mult_lhs = gimple_assign_lhs (use_stmt2);
+  use_stmt = use_stmt2;
+}
+
+  if (code != PLUS_EXPR
+  && code != MINUS_EXPR)
+return;
+
+  lhs = gimple_assign_lhs (use_stmt);
+  rhs1 = gimple_assign_rhs1 (use_stmt);
+  rhs2 = gimple_assign_rhs2 (use_stmt);
+
+  if (rhs1 == USE_FROM_PTR (use))
+{
+  if (code == MINUS_EXPR)
+   return;
+  std::swap (rhs1, rhs2);
+  code = MINUS_EXPR;
+}
+  else
+{
+  if (code == PLUS_EXPR)
+   code = MINUS_EXPR;
+  else
+   code = PLUS_EXPR;
+}
+
+  g = gimple_build_assign (lhs, code, rhs1, rhs2);
+  gimple_stmt_iterator gsi2 = gsi_for_stmt (use_stmt);
+  gsi_replace (, g, true);
+
+  lhs = gimple_assign_lhs (stmt);
+  rhs1 = gimple_assign_rhs1 (stmt);
+  g = gimple_build_assign (lhs, SSA_NAME, rhs1);
+  gsi_replace (gsi, g, true);
+}
+
 /* Reassociate expressions in basic block BB and its post-dominator as
children.
 
@@ -4809,6 +4881,11 @@ reassociate_bb (basic_block bb)
{
  tree lhs, rhs1, rhs2;
  enum tree_code rhs_code = gimple_assign_rhs_code (stmt);
+ if (rhs_code == NEGATE_EXPR)
+   {
+ propagate_neg_to_sub_or_add (, stmt);
+ continue;
+   }
 
  /* If this is not a gimple binary expression, there is
 nothing for us to do with it.  */
@@ -4884,6 +4961,7 @@ reassociate_bb (basic_block bb)
  if (rhs_code == MULT_EXPR)
attempt_builtin_copysign ();
 
+
  if (reassoc_insert_powi_p
  && rhs_code == MULT_EXPR
  && flag_unsafe_math_optimizations)

[Bug fortran/49630] [OOP] ICE on obsolescent deferred-length type bound character function

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||gerhard.steinmetz.fortran@t
   ||-online.de

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

[Bug fortran/69965] ICE: tree check: expected tree that contains ‘typed’ structure, have ‘’ in gfc_get_character_type, at fortran/trans-types.c:1048

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
Duplicate of pr49630.

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

[Bug c++/69970] New: Surprising warning with -Wnonnull-compare - 'this' compared to NULL

[larsbj at gullik dot net]

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

Bug ID: 69970
   Summary: Surprising warning with -Wnonnull-compare - 'this'
compared to NULL
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: larsbj at gullik dot net
  Target Milestone: ---

Compiling this snippet:

class Foo {
public:
explicit Foo(bool)
{}
};

class Bar {
public:
Bar()
: foo_(new Foo(this))
{}
private:
Foo * foo_; 
};

int main()
{
Bar bar;
return 0;
}


With:
g++ -c -Wnonnull-compare nonnull.cpp

Gives:
nonnull.cpp: In constructor ‘Bar::Bar()’:
nonnull.cpp:10:21: warning: nonnull argument ‘this’ compared to NULL
[-Wnonnull-compare]
  : foo_(new Foo(this))


Removing explict makes no difference.

g++ -v
Using built-in specs.
COLLECT_GCC=/opt/gcc/gcc-6/bin/g++
COLLECT_LTO_WRAPPER=/opt/gcc/gcc-6/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/opt/gcc/gcc-6
--enable-checking=release --enable-languages=c,c++,lto
Thread model: posix
gcc version 6.0.0 20160225 (experimental) (GCC)

Re: How to use _Generic with bit-fields

[Wink Saville]

Thanks for the info. What I'll probably do is file a bug and reply to this
thread and the other one when I do.


On Thu, Feb 25, 2016, 2:50 PM Joseph Myers  wrote:
>
> On Wed, 24 Feb 2016, Wink Saville wrote:
>
> > Further more things like printing of "big" bit fields such as
> > unsigned long long int b:33 doesn't issue any warnings with -Wall on clang
>
> Of course, printing such a bit-field with %llu etc. isn't fully portable
> even with the C++ semantics for bit-field types.  With the C++ semantics,
> if int is 34 bits or more then it gets promoted to int; otherwise, if
> unsigned int is 33 bits or more then it gets promoted to unsigned int.  So
> as with many cases of using variadic functions, you need to include a cast
> to get the desired types.  It just so happens it's hard for warnings to
> tell how portable you want the code to be, or to tell whether an
> unportable format for a type was e.g. autoconf-detected to be correct.
>
> > If someone were to supply a patch that changed the behavior to match
> > what clang and apparently other compilers are doing, would you be likely
> > to accept it?
>
> Not without a clear direction from WG14 to require the C++ rules (in which
> case conditionals on the C standard version would be appropriate, given
> the previous direction from the C90 DRs).  You'd need to track the
> declared type for each bit-field alongside the reduced-width type, apply
> C++-style promotions and conversions to the declared type for relevant
> rvalue uses, and handle the types appropriately in _Generic and typeof -
> other changes could be needed if e.g. conversion from floating-point to
> bit-fields were defined to convert to the declared type and then convert
> from that to the bit-field.  (A narrower direction only defining types in
> _Generic might still require tracking declared types but not require so
> many other changes.)
>
> --
> Joseph S. Myers
> jos...@codesourcery.com

[Bug target/69969] [5/6 Regression] Function attribute no-vsx

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||rejects-valid
  Known to work||5.2.0
   Target Milestone|--- |5.4
Summary|[5.3.0 Regression] Function |[5/6 Regression] Function
   |attribute no-vsx|attribute no-vsx

Re: [PATCH] hurd: align -p and -pg behavior on Linux

[Samuel Thibault]

Samuel Thibault, on Thu 25 Feb 2016 00:18:21 +0100, wrote:
> Thomas Schwinge, on Wed 24 Feb 2016 23:46:36 +0100, wrote:
> > I guess getting -D_REENTRANT for -pthread won't do us any harm?
> 
> It won't.

(Actually we've been using this in Debian for a long time).

Samuel

[Bug bootstrap/69709] [6 Regression] profiled bootstrap error on s390x-linux-gnu with r233194

[rth at gcc dot gnu.org]

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

--- Comment #12 from Richard Henderson  ---
Created attachment 37799
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37799=edit
example patch

Or, for the purposes of combine, better like so.
This avoids creating a third (move) insn, which
will foil the 3->2 insn combination.

[Bug bootstrap/69709] [6 Regression] profiled bootstrap error on s390x-linux-gnu with r233194

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 CC||rth at gcc dot gnu.org

--- Comment #11 from Richard Henderson  ---
Ho hum.  I've been looking at this this afternoon too.
Just to be sure we're on the same page, it's the insv
splitters not handling overlapping inputs.


diff --git a/gcc/config/s390/s390.md b/gcc/config/s390/s390.md
index 2c90eae..a3f3f0a 100644
--- a/gcc/config/s390/s390.md
+++ b/gcc/config/s390/s390.md
@@ -3883,6 +3883,12 @@
 (ashift:GPR (match_dup 3) (match_dup 4]
 {
   operands[5] = GEN_INT ((1UL << UINTVAL (operands[4])) - 1);
+  if (rtx_equal_p (operands[0], operands[3]))
+{
+  if (!can_create_pseudo_p ())
+   FAIL;
+  operands[3] = copy_to_reg (operands[3]);
+}
 })

 (define_split
@@ -3903,6 +3909,12 @@
  (clobber (reg:CC CC_REGNUM))])]
 {
   operands[5] = GEN_INT ((1UL << UINTVAL (operands[4])) - 1);
+  if (rtx_equal_p (operands[0], operands[3]))
+{
+  if (!can_create_pseudo_p ())
+   FAIL;
+  operands[3] = copy_to_reg (operands[3]);
+}
 })

 (define_insn "*rsbg__noshift"

[Bug target/68273] [5/6 Regression] Wrong code on mips/mipsel due to (invalid?) peeking at alignments in function_arg.

[hector.oron at gmail dot com]

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

--- Comment #32 from Hector Oron  ---
(In reply to Richard Biener from comment #31)
> eipa_sra introduces the remaining SSA name with non-default alignment via

[PATCH]

> it would be nice to see this IL checking on trunk and thus results from
> testing on affected targets - I'll give it a try in x86_64.

I have backported the patch to 5.3.1, which I am using.. and applying the
following patch based on yours, dot does not fail here anymore.

I also have a gcc built with tests, which I'll try to submit to relevant
mailing list.

Extending already commited patch from comment #20 with:

Index: gcc-5-5.3.1/src/gcc/tree-sra.c
===
--- gcc-5-5.3.1.orig/src/gcc/tree-sra.c
+++ gcc-5-5.3.1/src/gcc/tree-sra.c
@@ -936,7 +936,7 @@ create_access (tree expr, gimple stmt, b

   access = create_access_1 (base, offset, size);
   access->expr = expr;
-  access->type = TREE_TYPE (expr);
+  access->type = TYPE_MAIN_VARIANT (TREE_TYPE (expr));
   access->write = write;
   access->grp_unscalarizable_region = unscalarizable_region;
   access->stmt = stmt;
@@ -1026,7 +1026,7 @@ completely_scalarize_var (tree var)

   access = create_access_1 (var, 0, size);
   access->expr = var;
-  access->type = TREE_TYPE (var);
+  access->type = TYPE_MAIN_VARIANT (TREE_TYPE (var));
   access->grp_total_scalarization = 1;

   completely_scalarize_record (var, var, 0, var);
Index: gcc-5-5.3.1/src/gcc/tree-ssa.c
===
--- gcc-5-5.3.1.orig/src/gcc/tree-ssa.c
+++ gcc-5-5.3.1/src/gcc/tree-ssa.c
@@ -965,6 +965,14 @@ verify_ssa (bool check_modified_stmt, bo
  name, stmt, virtual_operand_p (name)))
goto err;
}
+
+ if (TYPE_ALIGN (TREE_TYPE (name))
+ != TYPE_ALIGN (TYPE_MAIN_VARIANT (TREE_TYPE (name
+   {
+ error ("type with non-default alignment");
+ goto err;
+   }
+
}
 }

[Bug c/69969] [5.3.0 Regression] Function attribute no-vsx

[cyrilbur at gmail dot com]

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

--- Comment #1 from Cyril Bur  ---
Created attachment 37798
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37798=edit
minimal test case in c

[Bug c/69969] New: [5.3.0 Regression] Function attribute no-vsx

[cyrilbur at gmail dot com]

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

Bug ID: 69969
   Summary: [5.3.0 Regression] Function attribute no-vsx
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cyrilbur at gmail dot com
  Target Milestone: ---

Created attachment 37797
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37797=edit
preprocessed file

$ powerpc64-buildroot-linux-gnu-gcc -v   
Using built-in specs.
COLLECT_GCC=/scratch/cyrilb/buildroot/builds/be64/host/usr/bin/powerpc64-buildroot-linux-gnu-gcc.br_real
COLLECT_LTO_WRAPPER=/scratch/cyrilb/buildroot/builds/be64/host/usr/libexec/gcc/powerpc64-buildroot-linux-gnu/5.3.0/lto-wrapper
Target: powerpc64-buildroot-linux-gnu
Configured with: ./configure
--prefix=/scratch/cyrilb/buildroot/builds/be64/host/usr
--sysconfdir=/scratch/cyrilb/buildroot/builds/be64/host/etc --enable-static
--target=powerpc64-buildroot-linux-gnu
--with-sysroot=/scratch/cyrilb/buildroot/builds/be64/host/usr/powerpc64-buildroot-linux-gnu/sysroot
--disable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib
--with-gmp=/scratch/cyrilb/buildroot/builds/be64/host/usr
--with-mpfr=/scratch/cyrilb/buildroot/builds/be64/host/usr
--with-pkgversion='Buildroot 2016.02-rc2-00080-gae4daa3'
--with-bugurl=http://bugs.buildroot.net/ --disable-libquadmath --enable-tls
--disable-libmudflap --enable-threads
--with-mpc=/scratch/cyrilb/buildroot/builds/be64/host/usr --without-isl
--without-cloog --disable-decimal-float --with-cpu=power8 --enable-languages=c
--with-build-time-tools=/scratch/cyrilb/buildroot/builds/be64/host/usr/powerpc64-buildroot-linux-gnu/bin
--enable-shared --disable-libgomp --enable-targets=powerpc64-linux
Thread model: posix
gcc version 5.3.0 (Buildroot 2016.02-rc2-00080-gae4daa3)


Cross compiling (x86 host) for PowerPC64


$ powerpc64-buildroot-linux-gnu-gcc no-vsx-test.c -Wall -Wextra -maltivec -mvsx
-save-temps
no-vsx-test.c:7:1: error: -mallow-movmisalign requires -mvsx
 {
 ^
no-vsx-test.c: In function 'main':
no-vsx-test.c:11:14: warning: unused parameter 'argc' [-Wunused-parameter]
 int main(int argc, char *argv[])
  ^
no-vsx-test.c:11:26: warning: unused parameter 'argv' [-Wunused-parameter]
 int main(int argc, char *argv[])
  ^



The issue appears be simply using __attribute__((__target__("no-vsx")))
in order to force the use of Altivec instructions.

Both GCC 4.9.x and 5.2.x (despite having different command line requirements)
will accept this test case and use the correct facility.

[Bug fortran/69834] Collision in derived type hashes

[pault at gcc dot gnu.org]

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

--- Comment #7 from Paul Thomas  ---
(In reply to Dominique d'Humieres from comment #6)

Hi Dominique,

I do not know what is going on here.

> > Created attachment 37791 [details]
> >   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37791=edit
> > Better Patch
> 
> Withe patch applied to my working tree (many patches) fixes the PR but I see
> several regressions at run time
>

These were precisely the regressions that I spent most of last night trying to
fix.

> FAIL: gfortran.dg/allocate_with_source_(7|8).f08   *  execution test
> FAIL: gfortran.dg/unlimited_polymorphic_zzz.f03   *  execution test
> 
> with zzz in (1, 5, 6, 14, 17, 18, 20, 22). AFAICT it "fixes"
>

It looks as if the final part of the patch, at least, did not apply. Since
there is another field in the vtable, I took out the right brace, which is
still there in your output.

> FAIL: gfortran.dg/finalize_21.f90   -O   scan-tree-dump original "static
> struct __vtype__STAR __vtab__STAR = {._hash=0, ._size=., ._extends=0B,
> ._def_init=0B, ._copy=0B, ._final=0B};"

I'll come back to you tomorrow.

Cheers

Paul

Re: How to use _Generic with bit-fields

[Joseph Myers]

On Wed, 24 Feb 2016, Wink Saville wrote:

> Further more things like printing of "big" bit fields such as
> unsigned long long int b:33 doesn't issue any warnings with -Wall on clang

Of course, printing such a bit-field with %llu etc. isn't fully portable 
even with the C++ semantics for bit-field types.  With the C++ semantics, 
if int is 34 bits or more then it gets promoted to int; otherwise, if 
unsigned int is 33 bits or more then it gets promoted to unsigned int.  So 
as with many cases of using variadic functions, you need to include a cast 
to get the desired types.  It just so happens it's hard for warnings to 
tell how portable you want the code to be, or to tell whether an 
unportable format for a type was e.g. autoconf-detected to be correct.

> If someone were to supply a patch that changed the behavior to match
> what clang and apparently other compilers are doing, would you be likely
> to accept it?

Not without a clear direction from WG14 to require the C++ rules (in which 
case conditionals on the C standard version would be appropriate, given 
the previous direction from the C90 DRs).  You'd need to track the 
declared type for each bit-field alongside the reduced-width type, apply 
C++-style promotions and conversions to the declared type for relevant 
rvalue uses, and handle the types appropriately in _Generic and typeof - 
other changes could be needed if e.g. conversion from floating-point to 
bit-fields were defined to convert to the declared type and then convert 
from that to the bit-field.  (A narrower direction only defining types in 
_Generic might still require tracking declared types but not require so 
many other changes.)

-- 
Joseph S. Myers
jos...@codesourcery.com

[Bug other/69968] RFC: Use Damerau-Levenshtein within spellcheck.c, rather than Levenshtein

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug other/69968] New: RFC: Use Damerau-Levenshtein within spellcheck.c, rather than Levenshtein

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 69968
   Summary: RFC: Use Damerau-Levenshtein within spellcheck.c,
rather than Levenshtein
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

(quoting Steven Bosscher)

--
$ cat t.c
void foo (void);

struct {
  int coordx, coordy, coordz;
  int coordx1, coordy1, coordz1;
} c;

void foo (void)
{
  c.coordx1 = c.coordy1* c.coordz;
  c.coorzd1 = c.coordy;
}

$ ./cc1 -quiet -Wall -Wextra t.c
t.c: In function 'foo':
t.c:11:4: error: 'struct ' has no member named 'coorzd1';
did you mean 'coordx'?
   c.coorzd1 = c.coordy;
^
--

Note that z and d are swapped. The Levenshtein metric returns "coordx"
as the best match, but it requires 2 insertions and one deletion to go
from "coorzd1" to "coordx", or to "coordz"/"coordy" -- "coordx" is just the
first of 3 with the same Levenshtein distance.

With Damerau-Levenshtein, we'd be able to recognize the (apparently
most common) mistake of having 2 characters swapped. The
Damerau-Levenshtein distance to "coordz1" is 1 and there is no field in
the struct with a smaller distance.

[Bug bootstrap/69709] [6 Regression] profiled bootstrap error on s390x-linux-gnu with r233194

[vogt at linux dot vnet.ibm.com]

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

--- Comment #10 from Dominik Vogt  ---
We've located the bug in the s390 backend.  No further help is needed.

[Bug c++/69967] #pragma GCC diagnostic ignored being ignored for -Wunused-variable in some cases

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Most likely this warning does not happen until all of the translation unit has
been parsed in.  The variables are not marked as being used.

[PATCH][SPARC] sparc: switch -fasynchronous-unwind-tables on by default.

[Jose E. Marchesi]

In sparc systems glibc uses libgcc's unwinder to implement the
backtrace(3) function, defaulting to a simple non-dwarf unwinder if
libgcc_s doesn't provide a working _Unwind_Backtrace.

However, libgcc's unwinder uses .eh_frame instead of .frame_debug, and
.eh_frame is fully populated only if applications are built with
-fexceptions or -fasynchronous-unwind-tables.

This patch changes GCC to assume -fasynchronous-unwind-tables by default
in sparcv9 and sparc64, like other ports (notably x86) do.

Tested in both sparcv9-*-* and sparc64-*-* targets.

   * common/config/sparc/sparc-common.c (sparc_option_init_struct):
 New function.
 (TARGET_OPTION_INIT_STRUCT): Defined.
---
 gcc/ChangeLog  |  6 ++
 gcc/common/config/sparc/sparc-common.c | 10 ++
 2 files changed, 16 insertions(+)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 3a13f5f..ba7befe 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2016-02-25  Jose E. Marchesi  
+
+   * common/config/sparc/sparc-common.c (sparc_option_init_struct):
+   New function.
+   (TARGET_OPTION_INIT_STRUCT): Defined.
+
 2016-02-25  Richard Biener  
 
PR tree-optimization/48795
diff --git a/gcc/common/config/sparc/sparc-common.c 
b/gcc/common/config/sparc/sparc-common.c
index 3958b7e..1c5bc06 100644
--- a/gcc/common/config/sparc/sparc-common.c
+++ b/gcc/common/config/sparc/sparc-common.c
@@ -24,6 +24,14 @@ along with GCC; see the file COPYING3.  If not see
 #include "common/common-target.h"
 #include "common/common-target-def.h"
 
+/* Implement TARGET_OPTION_INIT_STRUCT.  */
+
+static void
+sparc_option_init_struct (struct gcc_options *opts)
+{
+  opts->x_flag_asynchronous_unwind_tables = 2;
+}
+
 /* Implement TARGET_OPTION_OPTIMIZATION_TABLE.  */
 static const struct default_options sparc_option_optimization_table[] =
   {
@@ -31,6 +39,8 @@ static const struct default_options 
sparc_option_optimization_table[] =
 { OPT_LEVELS_NONE, 0, NULL, 0 }
   };
 
+#undef TARGET_OPTION_INIT_STRUCT
+#define TARGET_OPTION_INIT_STRUCT sparc_option_init_struct
 #undef TARGET_DEFAULT_TARGET_FLAGS
 #define TARGET_DEFAULT_TARGET_FLAGS TARGET_DEFAULT
 #undef TARGET_OPTION_OPTIMIZATION_TABLE
-- 
2.3.4

[Bug fortran/69962] ICE on missing parameter attribute, in gfc_set_constant_character_len

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
This is fairly easy to fix.

[Bug tree-optimization/69666] [5 Regression] gcc ICE at -O2 and -O3 on valid code on x86_64-linux-gnu in "verify_gimple failed"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from Jakub Jelinek  ---
That is already tracked in PR69920.

Re: [PATCH] Fix DW_OP_GNU_implicit_pointer referring to DW_TAG_dwarf_procedure (PR debug/69947)

[Jakub Jelinek]

On Thu, Feb 25, 2016 at 05:46:40PM +0100, Jakub Jelinek wrote:
> On Thu, Feb 25, 2016 at 04:53:58PM +0100, Pierre-Marie de Rodat wrote:
> > I introduced a DW_OP_call* traversal for this:
> > 
> >   * prune_unused_types_mark traverses attributes using
> > prune_unused_types_walk_attribs;
> > 
> >   * …_walk_attribs walks location descriptions and location lists using
> > …_walk_loc_descr
> > 
> >   * …_walk_loc_descr marks DWARF procedures referenced by DW_OP_call*
> > operations.
> 
> Ah, I've been looking for something that would set die_perennial_p, but
> actually you just set die_mark later on instead for those.
> So IMHO the right fix is just handle all the ops that could directly or
> indirectly contain references to other DIEs, rather than just handling
> the 3 you have there.
> 
> Going to bootstrap/regtest this on x86_64-linux and i686-linux now.
> 
> Is this ok for trunk if it passes testing?

Successfully bootstrapped/regtested on x86_64-linux and i686-linux.

> 2016-02-25  Jakub Jelinek  
> 
>   PR debug/69947
>   * dwarf2out.c (prune_unused_types_walk_loc_descr): Handle
>   all other ops that have dw_val_class_die_ref operands,
>   and DW_OP_GNU_entry_value.
> 
>   * gcc.dg/guality/pr69947.c: New test.

Jakub

[PATCH 2/3] Add x86_64-*-rtems* target

[Joel Sherrill]

* gcc/config.gcc, libgcc/config.host: Add x86_64-*-rtems*.
* gcc/config/i386/rtems-64.h: New file.
---
 gcc/config.gcc |  3 +++
 gcc/config/i386/rtems-64.h | 30 ++
 libgcc/config.host |  2 +-
 3 files changed, 34 insertions(+), 1 deletion(-)
 create mode 100644 gcc/config/i386/rtems-64.h

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 3b280e0..4cc6438 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1421,6 +1421,9 @@ i[34567]86-*-elf*)
 x86_64-*-elf*)
tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h 
newlib-stdint.h i386/i386elf.h i386/x86-64.h"
;;
+x86_64-*-rtems*)
+   tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h 
newlib-stdint.h i386/i386elf.h i386/x86-64.h i386/rtems-64.h"
+   ;;
 i[34567]86-*-rdos*)
 tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h 
newlib-stdint.h i386/i386elf.h i386/rdos.h"
 ;;
diff --git a/gcc/config/i386/rtems-64.h b/gcc/config/i386/rtems-64.h
new file mode 100644
index 000..b087d44
--- /dev/null
+++ b/gcc/config/i386/rtems-64.h
@@ -0,0 +1,30 @@
+/* Definitions for rtems targeting an x86_64
+   Copyright (C) 2016 Free Software Foundation, Inc.
+   Contributed by Joel Sherrill (j...@oarcorp.com).
+
+This file is part of GCC.
+
+GCC 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.
+
+GCC 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 GCC; see the file COPYING3.  If not see
+.  */
+
+/* Specify predefined symbols in preprocessor.  */
+
+#define TARGET_OS_CPP_BUILTINS()   \
+  do   \
+{  \
+   builtin_define ("__rtems__");   \
+   builtin_define ("__USE_INIT_FINI__");   \
+   builtin_assert ("system=rtems");\
+}  \
+  while (0)
diff --git a/libgcc/config.host b/libgcc/config.host
index 1f85c46..b61a579 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -577,7 +577,7 @@ i[34567]86-*-elfiamcu)
 i[34567]86-*-elf*)
tmake_file="$tmake_file i386/t-crtstuff t-crtstuff-pic t-libgcc-pic"
;;
-x86_64-*-elf*)
+x86_64-*-elf* | x86_64-*-rtems*)
tmake_file="$tmake_file i386/t-crtstuff t-crtstuff-pic t-libgcc-pic"
;;
 i[34567]86-*-dragonfly*)
-- 
1.8.3.1

[PATCH 1/3] Add aarch64-*-rtems* target

[Joel Sherrill]

* gcc/config.gcc, libgcc/config.host: Add aarch64-*-rtems*.
* gcc/config/aarch64/rtems.h: New file.
---
 gcc/config.gcc | 11 +--
 gcc/config/aarch64/rtems.h | 28 
 libgcc/config.host |  2 +-
 3 files changed, 38 insertions(+), 3 deletions(-)
 create mode 100644 gcc/config/aarch64/rtems.h

diff --git a/gcc/config.gcc b/gcc/config.gcc
index e26742e..3b280e0 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -906,11 +906,18 @@ case ${target} in
 esac
 
 case ${target} in
-aarch64*-*-elf)
+aarch64*-*-elf | aarch64*-*-rtems*)
tm_file="${tm_file} dbxelf.h elfos.h newlib-stdint.h"
tm_file="${tm_file} aarch64/aarch64-elf.h aarch64/aarch64-elf-raw.h"
tmake_file="${tmake_file} aarch64/t-aarch64"
-   use_gcc_stdint=wrap
+   case $target in
+   aarch64-*-elf*)
+   use_gcc_stdint=wrap
+   ;;
+   aarch64-*-rtems*)
+   tm_file="${tm_file} rtems.h aarch64/rtems.h"
+   ;;
+   esac
case $target in
aarch64_be-*)
tm_defines="${tm_defines} TARGET_BIG_ENDIAN_DEFAULT=1"
diff --git a/gcc/config/aarch64/rtems.h b/gcc/config/aarch64/rtems.h
new file mode 100644
index 000..a166034
--- /dev/null
+++ b/gcc/config/aarch64/rtems.h
@@ -0,0 +1,28 @@
+/* Definitions for RTEMS based AARCH64 system.
+   Copyright (C) 2016 Free Software Foundation, Inc.
+ 
+   This file is part of GCC.
+ 
+   GCC 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.
+ 
+   GCC 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 GCC; see the file COPYING3.  If not see
+   .  */
+
+#define HAS_INIT_SECTION
+
+#undef TARGET_OS_CPP_BUILTINS
+#define TARGET_OS_CPP_BUILTINS()   \
+do {   \
+   builtin_define ("__rtems__");   \
+   builtin_define ("__USE_INIT_FINI__");   \
+   builtin_assert ("system=rtems");\
+} while (0)
diff --git a/libgcc/config.host b/libgcc/config.host
index ef7dfd0..1f85c46 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -327,7 +327,7 @@ i[34567]86-*-mingw* | x86_64-*-mingw*)
 esac
 
 case ${host} in
-aarch64*-*-elf)
+aarch64*-*-elf | aarch64*-*-rtems*)
extra_parts="$extra_parts crtbegin.o crtend.o crti.o crtn.o"
extra_parts="$extra_parts crtfastmath.o"
tmake_file="${tmake_file} ${cpu_type}/t-aarch64"
-- 
1.8.3.1

[PATCH 3/3] contrib/config-list.mk: Add aarch64-rtems and x86_64-rtems

[Joel Sherrill]

* contrib/config-list.mk: Add aarch64-rtems and x86_64-rtems
---
 contrib/config-list.mk | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/contrib/config-list.mk b/contrib/config-list.mk
index 0f15464..6a83a84 100644
--- a/contrib/config-list.mk
+++ b/contrib/config-list.mk
@@ -11,7 +11,7 @@ TEST=all-gcc
 # nohup nice make -j25 -l36 -f ../gcc/contrib/config-list.mk > make.out 2>&1 &
 #
 # v850e1-elf is rejected by config.sub
-LIST = aarch64-elf aarch64-linux-gnu \
+LIST = aarch64-elf aarch64-linux-gnu aarch64-rtems \
   alpha-linux-gnu alpha-freebsd6 alpha-netbsd alpha-openbsd \
   alpha64-dec-vms alpha-dec-vms am33_2.0-linux \
   arc-elf32OPT-with-cpu=arc600 arc-elf32OPT-with-cpu=arc700 \
@@ -76,7 +76,8 @@ LIST = aarch64-elf aarch64-linux-gnu \
   x86_64-pc-linux-gnuOPT-with-fpmath=avx \
   x86_64-elfOPT-with-fpmath=sse x86_64-freebsd6 x86_64-netbsd \
   x86_64-knetbsd-gnuOPT-enable-obsolete x86_64-w64-mingw32 \
-  x86_64-mingw32OPT-enable-sjlj-exceptions=yes xstormy16-elf xtensa-elf \
+  x86_64-mingw32OPT-enable-sjlj-exceptions=yes x86_64-rtems \
+  xstormy16-elf xtensa-elf \
   xtensa-linux \
   i686-interix3OPT-enable-obsolete
 
-- 
1.8.3.1

Re: [PATCH] libffi testsuite: Use split to ensure valid tcl list

[Thomas Schwinge]

Hi!

On Thu, 25 Feb 2016 11:45:06 -0800, Mike Stump  wrote:
> On Feb 25, 2016, at 11:10 AM, Thomas Schwinge  wrote:
> > +set lines [libffi_target_compile $src /dev/null assembly “"]
> 
> Does this work on a dos box, or windows or other random non-posix systems?

I don't know, and can't easily test.  However, I had seen the same
pattern be used elsewhere, for example:

$ git grep dev/null -- libstdc++-v3/testsuite/lib/
libstdc++-v3/testsuite/lib/libstdc++.exp:   set lines 
[v3_target_compile $src /dev/null executable ""]
[several more]

..., so assumed that to be OK.

Now that I'm reading [dejagnu]/target.exp:default_target_compile, I see
that for "[is_remote host]", it *always* passes "-o a.out" and then
"remote_upload host a.out $destfile", so "/dev/null" never escapes from
the system that DejaGnu/runtest is running on, which is always a POSIX
system as far as I know.

Otherwise, we could easily switch all these to a temporary output file,
which is then deleted right away...


Grüße
 Thomas

[Bug c++/69967] New: #pragma GCC diagnostic ignored being ignored for -Wunused-variable in some cases

[yaghmour.shafik at gmail dot com]

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

Bug ID: 69967
   Summary: #pragma GCC diagnostic ignored being ignored for
-Wunused-variable in some cases
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yaghmour.shafik at gmail dot com
  Target Milestone: ---

Given the following example:

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-variable"
#include 
#pragma GCC diagnostic pop

int main()
{
}

and the following command line options:

  --std=c++11 -Wno-deprecated-declarations -Wunused-variable -Werror -O2

gcc 5.3 produces the following diagnostics:

error: ‘boost::system::posix_category’ defined but not used
[-Werror=unused-variable]
 static const error_category &  posix_category = generic_category();
^

error: ‘boost::system::errno_ecat’ defined but not used
[-Werror=unused-variable]
 static const error_category &  errno_ecat = generic_category();
^

rror: ‘boost::system::native_ecat’ defined but not used
[-Werror=unused-variable]
 static const error_category &  native_ecat= system_category();
^


even though it should be ignored due to the:

  #pragma GCC diagnostic ignored "-Wunused-variable"

You can find an online example that reproduces this here
http://melpon.org/wandbox/permlink/LhOgWD7JOFrf95ZQ

This issue only shows up when optimization is turned on with -O1 or above.

GCC 4.9.2 and 6.0.0 do not have this issue. In the case of GCC 6.0.0 it is hard
to tell if the issue is fixed since the diagnostic does not show up all even
when reduce the test case to the following:

#include 

int main(){}

So in 6.0.0 the warning appears to be less aggressive but now we don't know if
the underlying issue with the pragma is fixed or just hidden by change in
behavior of the warning.

Re: [patch, libstdc++] In debug mode, diagnose empty initializer_list in min/max/minmax

[Eelis van der Weegen]

On 2016-02-23 23:39, Jonathan Wakely wrote:

On 23/02/16 22:03 +0100, Eelis wrote:

The std::min, std::max, and std::minmax overloads that take a 
std::initializer_list all require that the list is not empty. The attached 
patch adds debug mode checks for this.


Nice, thanks for the patch.


Hi Jonathan,

Thanks for the review! Updated patch attached.

I couldn't find precedent in the libstdc++ testsuite of tests that test 
__glibcxx_assert assertions, so I put these under {min,max,minmax}/assert/, 
analogous to {min,max,minmax}/debug/. Is that ok?


Otherwise this looks good, but will have to wait until after the GCC 6 release 
now.


No hurry at all. :)

Cheers,

Eelis
Index: libstdc++-v3/include/debug/formatter.h
===
--- libstdc++-v3/include/debug/formatter.h	(revision 233636)
+++ libstdc++-v3/include/debug/formatter.h	(working copy)
@@ -127,7 +127,8 @@
 // others
 __msg_equal_allocs,
 __msg_insert_range_from_self,
-__msg_irreflexive_ordering
+__msg_irreflexive_ordering,
+__msg_empty_init_list
   };
 
   class _Error_formatter
Index: libstdc++-v3/src/c++11/debug.cc
===
--- libstdc++-v3/src/c++11/debug.cc	(revision 233636)
+++ libstdc++-v3/src/c++11/debug.cc	(working copy)
@@ -188,7 +188,8 @@
 "allocators must be equal",
 "attempt to insert with an iterator range [%1.name;, %2.name;) from this"
 " container",
-"comparison doesn't meet irreflexive requirements, assert(!(a < a))"
+"comparison doesn't meet irreflexive requirements, assert(!(a < a))",
+"%1;(): empty initializer_list"
   };
 
   void
Index: libstdc++-v3/include/debug/macros.h
===
--- libstdc++-v3/include/debug/macros.h	(revision 233636)
+++ libstdc++-v3/include/debug/macros.h	(working copy)
@@ -69,6 +69,12 @@
 		  ._M_iterator(_First, #_First)			\
 		  ._M_iterator(_Last, #_Last))
 
+// Verify that the initializer_list is non-empty.
+#define __glibcxx_check_non_empty_init_list(_List)			\
+_GLIBCXX_DEBUG_VERIFY(_List.size() != 0,\
+		  _M_message(__gnu_debug::__msg_empty_init_list)	\
+		  ._M_string(__func__))
+
 /** Verify that we can insert into *this with the iterator _Position.
  *  Insertion into a container at a specific position requires that
  *  the iterator be nonsingular, either dereferenceable or past-the-end,
Index: libstdc++-v3/include/debug/debug.h
===
--- libstdc++-v3/include/debug/debug.h	(revision 233636)
+++ libstdc++-v3/include/debug/debug.h	(working copy)
@@ -87,9 +87,13 @@
 // Verify that the container is nonempty
 # define __glibcxx_requires_nonempty() \
   __glibcxx_assert(! this->empty())
+// Verify that the initializer_list is non-empty.
+# define __glibcxx_requires_non_empty_init_list(_List) \
+  __glibcxx_assert(_List.size() != 0)
 #else
 # define __glibcxx_requires_non_empty_range(_First,_Last)
 # define __glibcxx_requires_nonempty()
+# define __glibcxx_requires_non_empty_init_list(_List)
 #endif
 
 #else
@@ -99,6 +103,8 @@
 # define __glibcxx_requires_cond(_Cond,_Msg) _GLIBCXX_DEBUG_VERIFY(_Cond,_Msg)
 # define __glibcxx_requires_valid_range(_First,_Last)	\
   __glibcxx_check_valid_range(_First,_Last)
+# define __glibcxx_requires_non_empty_init_list(_List)	\
+  __glibcxx_check_non_empty_init_list(_List)
 # define __glibcxx_requires_non_empty_range(_First,_Last)	\
   __glibcxx_check_non_empty_range(_First,_Last)
 # define __glibcxx_requires_sorted(_First,_Last)	\
Index: libstdc++-v3/include/bits/stl_algo.h
===
--- libstdc++-v3/include/bits/stl_algo.h	(revision 233636)
+++ libstdc++-v3/include/bits/stl_algo.h	(working copy)
@@ -3452,25 +3452,37 @@
 _GLIBCXX14_CONSTEXPR
 inline _Tp
 min(initializer_list<_Tp> __l)
-{ return *std::min_element(__l.begin(), __l.end()); }
+{
+  __glibcxx_requires_non_empty_init_list(__l);
+  return *std::min_element(__l.begin(), __l.end());
+}
 
   template
 _GLIBCXX14_CONSTEXPR
 inline _Tp
 min(initializer_list<_Tp> __l, _Compare __comp)
-{ return *std::min_element(__l.begin(), __l.end(), __comp); }
+{
+  __glibcxx_requires_non_empty_init_list(__l);
+  return *std::min_element(__l.begin(), __l.end(), __comp);
+}
 
   template
 _GLIBCXX14_CONSTEXPR
 inline _Tp
 max(initializer_list<_Tp> __l)
-{ return *std::max_element(__l.begin(), __l.end()); }
+{
+  __glibcxx_requires_non_empty_init_list(__l);
+  return *std::max_element(__l.begin(), __l.end());
+}
 
   template
 _GLIBCXX14_CONSTEXPR
 inline _Tp
 max(initializer_list<_Tp> __l, _Compare __comp)
-{ return *std::max_element(__l.begin(), __l.end(), __comp); }
+{
+  __glibcxx_requires_non_empty_init_list(__l);
+  return 

[Bug go/69966] libgo: Port syscall.SetsockoptUcred from golang

[doko at gcc dot gnu.org]

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

Matthias Klose  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

Re: [PATCH] libffi testsuite: Use split to ensure valid tcl list

[Mike Stump]

On Feb 25, 2016, at 11:10 AM, Thomas Schwinge  wrote:
> +set lines [libffi_target_compile $src /dev/null assembly “"]

Does this work on a dos box, or windows or other random non-posix systems?

[Bug go/69966] New: libgo: Port syscall.SetsockoptUcred from golang

[doko at gcc dot gnu.org]

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

Bug ID: 69966
   Summary: libgo: Port syscall.SetsockoptUcred from golang
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: doko at gcc dot gnu.org
CC: cmang at google dot com
  Target Milestone: ---

Created attachment 37796
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37796=edit
patch

Michael Vogt noticed a missing syscall in gccgo, which is available in golang.
Backport is attached.

[Bug fortran/66310] Problems with intrinsic repeat for large number of copies

[jvdelisle at gcc dot gnu.org]

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

--- Comment #6 from Jerry DeLisle  ---
When using the REPEAT intrinsic as a parameter, the frontend is simplifying
this to an actual string constant of the requested length. In this process it
is attempting to allocate length + 1 in order to internally NULL terminate the
string.  The NULL termination is not strictly needed and when I remove it on my
system I get the expected results:

f951: out of memory allocating 8589934588 bytes after a total of 569344 bytes

Each character is a wide character to accommodate different encodings and in
this case is 4 bytes.

When trying to allocate len + 1 where len is huge, the result is wrapped,
signed vs unsigned integers.

I am tempted to put in an arbitrary limit on the size of string constants and
issue a warning when it happens and truncate the result to the allowed limit. 
This would give a more useful message.

If I were to do this, what would be a reasonable limit for string constants?

How about 2^30 = 1073741824?

The other choice we have here is do nothing and close this as WON'T FIX.
Although the error message we get from the OS: "f951: out of memory allocating
18446744065119617024 " is confusing.

I can cast the signed integer length to uint32_t and avoid the big number.

Any opinions?

[Bug fortran/69965] ICE: tree check: expected tree that contains ‘typed’ structure, have ‘’ in gfc_get_character_type, at fortran/trans-types.c:1048

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---
Compiles if abstract "class(tab)" is replaced with extended "class(t)" :


$ cat z2.f90
module m
   type, abstract :: tab
   contains
  procedure(fab), deferred :: f
   end type

   type, extends(tab) :: t
   contains
  procedure :: f
   end type

   abstract interface
  function fab(x) result(z)
 import tab
 class(tab) :: x
 character(*) :: z
  end
   end interface

contains

   function f(x)
  class(t) :: x
  character(1) :: f
  f = 'a'
   end

   subroutine s(x)
  class(t) :: x
  print *, x%f()
   end
end module

[Bug fortran/69965] New: ICE: tree check: expected tree that contains ‘typed’ structure, have ‘’ in gfc_get_character_type, at fortran/trans-types.c:1048

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 69965
   Summary: ICE: tree check: expected tree that contains ‘typed’
structure, have ‘’ in
gfc_get_character_type, at fortran/trans-types.c:1048
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

With an abstract class dummy argument :


$ cat z1.f90
module m
   type, abstract :: tab
   contains
  procedure(fab), deferred :: f
   end type

   type, extends(tab) :: t
   contains
  procedure :: f
   end type

   abstract interface
  function fab(x) result(z)
 import tab
 class(tab) :: x
 character(*) :: z
  end
   end interface

contains

   function f(x)
  class(t) :: x
  character(1) :: f
  f = 'a'
   end

   subroutine s(x)
  class(tab) :: x
  print *, x%f()
   end
end module


$ gfortran-6 --version
GNU Fortran (SUSE Linux) 6.0.0 20160202 (experimental) [trunk revision 233076]


$ gfortran-6 -c z1.f90
z1.f90:30:0:

   print *, x%f()

internal compiler error: Segmentation fault


In approximately 3 out of 100 runs the error message is :

internal compiler error: tree check: expected tree that contains ‘typed’
structure, have ‘’ in gfc_get_character_type, at
fortran/trans-types.c:1048

[Bug fortran/69964] New: ICE on misspelled end block data, in gfc_ascii_statement

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 69964
   Summary: ICE on misspelled end block data, in
gfc_ascii_statement
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

With a typo :


$ cat z1.f90
block data q
end blook data q
block data q2
end block data q2


$ cat z2.f90
block data q
end block q
block data q2
end block data q2


$ gfortran-6 z1.f90
f951: internal compiler error: gfc_ascii_statement(): Bad statement code

[Bug fortran/69963] ICE out of memory on displaced implicit character

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---
Created attachment 37795
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37795=edit
More tiny examples

[Bug fortran/69963] New: ICE out of memory on displaced implicit character

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 69963
   Summary: ICE out of memory on displaced implicit character
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Something goes wrong when a "implicit character" statement is mixed in
at wrong places. There is NO ice, NO out of memory if "implicit none"
or "implicit real" etc. is mixed in instead.

In most runs "out of memory" hits, but segfault or other error messages
are possible too, depending on compile options and additional statements.



$ cat z01.f90
program p
   character(4) c
   implicit character(8) (a-z)
end


$ cat z02.f90
program p
   x = 1
   implicit character(8) (a-z)
end


$ cat z03.f90
module m
   private
   implicit character(8) (a-z)
end


$ gfortran-6 -c z01.f90
f951: out of memory allocating 22352811504 bytes after a total of 634880 bytes


$ gfortran-6 -c z02.f90
f951: out of memory allocating 22352811504 bytes after a total of 634880 bytes


$ gfortran-6 -c z03.f90
f951: out of memory allocating 22352811504 bytes after a total of 634880 bytes


Please find attached a list with several more examples.

[Bug fortran/69962] New: ICE on missing parameter attribute, in gfc_set_constant_character_len

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 69962
   Summary: ICE on missing parameter attribute, in
gfc_set_constant_character_len
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

The following snippet is wrong because n is not declared as parameter :


$ cat z1.f90
program p
   integer :: n = 1
   character(3), parameter :: x(2) = ['abc', 'xyz']
   character(2), parameter :: y(2) = [x(2)(2:3), x(n)(1:2)]
end


$ gfortran-6 z1.f90
f951: internal compiler error: in gfc_set_constant_character_len, at
fortran/decl.c:1304

---

Correct with parameter attribute :


$ cat z2.f90
program p
   integer, parameter :: n = 1
   character(3), parameter :: x(2) = ['abc', 'xyz']
   character(2), parameter :: y(2) = [x(2)(2:3), x(n)(1:2)]
   print *, x
   print *, y
end


$ gfortran-6 z2.f90
$ a.out
 abcxyz
 yzab

---

Thematically related to pr66107.

Re: [PATCH] libffi testsuite: Use split to ensure valid tcl list

[Thomas Schwinge]

Hi!

Already had noticed something odd here months ago; now finally looked
into it...

On Sat, 28 Mar 2015 13:59:30 -0400, John David Anglin  
wrote:
> The attached change fixes tcl errors that occur running the complex.exp and 
> go.exp test sets.
> See: .
> 
> Tested on hppa2.0w-hp-hpux11.11.  Okay for trunk?

(Got approved, and installed as r221765.)

> 2015-03-28  John David Anglin  
> 
>   PR libffi/65567
>   * testsuite/lib/libffi.exp (libffi_feature_test): Use split to ensure
>   lindex is applied to a list.
> 
> Index: testsuite/lib/libffi.exp
> ===
> --- testsuite/lib/libffi.exp  (revision 221591)
> +++ testsuite/lib/libffi.exp  (working copy)
> @@ -238,7 +239,7 @@
>  set lines [libffi_target_compile $src "" "preprocess" ""]
>  file delete $src
>  
> -set last [lindex $lines end]
> +set last [lindex [split $lines] end]
>  return [regexp -- "xyzzy" $last]
>  }

On my several systems, this has the effect that any user of
libffi_feature_test has their test results regress from PASS to
UNSUPPORTED.  Apparently the regexp xyzzy matching doesn't work as
intended.  If I revert your patch, it's OK for me -- but still not for
you, I suppose.  ;-)

How about the followinginstead?  It's conceptually simpler (and similar
to what other such tests are doing), works for me -- but can you also
please test this?

--- libffi/testsuite/lib/libffi.exp
+++ libffi/testsuite/lib/libffi.exp
@@ -227,20 +227,21 @@ proc libffi_target_compile { source dest type options } {
 
 # TEST should be a preprocessor condition.  Returns true if it holds.
 proc libffi_feature_test { test } {
-set src "ffitest.c"
+set src "ffitest[pid].c"
 
 set f [open $src "w"]
 puts $f "#include "
 puts $f $test
-puts $f "xyzzy"
+puts $f "/* OK */"
+puts $f "#else"
+puts $f "# error Failed $test"
 puts $f "#endif"
 close $f
 
-set lines [libffi_target_compile $src "" "preprocess" ""]
+set lines [libffi_target_compile $src /dev/null assembly ""]
 file delete $src
 
-set last [lindex [split $lines] end]
-return [regexp -- "xyzzy" $last]
+return [string match "" $lines]
 }
 
 # Utility routines.


Grüße
 Thomas


signature.asc
Description: PGP signature

[Bug c/69960] "initializer element is not constant"

[felix-gcc at fefe dot de]

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

--- Comment #4 from felix-gcc at fefe dot de ---
So which part of it is not constant, you would say?

It all looks constant to me. It only operates on constants.
If 3+4 is constant, why should this not be constant?

[Bug c++/69903] Function template specialization with CRTP-class causes compiler segfault

[ppalka at gcc dot gnu.org]

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

--- Comment #6 from Patrick Palka  ---
Smaller test case:

struct A {
  template 
  static void f() { };
};

struct B : A { };

template<>
void B::f<0>() { };

int main() {
  B::f<0> ();
}


If f is made non-static then the compiler rejects the specialization and
there's no ICE.

And if "void B::f<0>" is replaced with "void A::f<0>" then the code is accepted
without errors.

[Bug c/69960] "initializer element is not constant"

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
The C standard says it's not a constant, but clang accepts it as an extension.
That doesn't make it valid C though.

[Bug c++/69903] Function template specialization with CRTP-class causes compiler segfault

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #5 from Patrick Palka  ---
Looks like you don't need to use CRTP to trigger the segfault:

template 
struct A {
  template 
  static void f() { };

  static void F() { f<0>(); }
};

struct B : A { };

template<>
void B::f<0>() { };

int main() {
  B::F();
}


I wonder if this code is valid, though.  Is it legal to declare an explicit
specialization of an inherited template function like that?

Re: [PATCH] Do not gather mem stats in run_exit_handles (PR middle-end/69919)

[David Malcolm]

On Thu, 2016-02-25 at 12:07 +0100, Martin Liška wrote:
> Hello.
> 
> As discussed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69919#c3
> , following patch
> guards usage of memory statistics infrastructure after a
> mem_alloc_description is already
> destructed.
> 
> Patch can lto-bootstrap on x86_64-linux-gnu with --enable-gather
> -detailed-mem-stats and
> survives bootstrap with --enable-gather-detailed-mem-stats
> on x86_64-linux-gnu with.
> 
> Ready to be installed?
> Martin
> 
> gcc/ChangeLog:
> 
> 2016-02-25  Martin Liska  
> 
>   PR middle-end/69919
>   * alloc-pool.c (after_memory_report): New variable.
>   * alloc-pool.h (base_pool_allocator ::release): Do not use
>   the infrastructure if after_memory_report.
>   * toplev.c (toplev::main): Mark after memory report.
> ---
>  gcc/alloc-pool.c | 1 +
>  gcc/alloc-pool.h | 5 -
>  gcc/toplev.c | 3 +++
>  3 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/gcc/alloc-pool.c b/gcc/alloc-pool.c
> index ae5e232..43d06f6 100644
> --- a/gcc/alloc-pool.c
> +++ b/gcc/alloc-pool.c
> @@ -25,6 +25,7 @@ along with GCC; see the file COPYING3.  If not see
>  
>  ALLOC_POOL_ID_TYPE last_id;
>  mem_alloc_description pool_allocator_usage;
> +bool after_memory_report = false;
>  
>  /* Output per-alloc_pool memory usage statistics.  */
>  void
> diff --git a/gcc/alloc-pool.h b/gcc/alloc-pool.h
> index 8ccf089..3ead101 100644
> --- a/gcc/alloc-pool.h
> +++ b/gcc/alloc-pool.h
> @@ -25,6 +25,9 @@ along with GCC; see the file COPYING3.  If not see
>  
>  extern void dump_alloc_pool_statistics (void);
>  
> +/* Flag indicates whether memory statistics are gathered any longer.
>   */
> +extern bool after_memory_report;
> +
>  typedef unsigned long ALLOC_POOL_ID_TYPE;
>  
>  /* Last used ID.  */
> @@ -306,7 +309,7 @@ base_pool_allocator ::release ()
>TBlockAllocator::release (block);
>  }
>  
> -  if (GATHER_STATISTICS)
> +  if (GATHER_STATISTICS && !after_memory_report)
>  {
>pool_allocator_usage.release_instance_overhead
>   (this, (m_elts_allocated - m_elts_free) * m_elt_size);
> diff --git a/gcc/toplev.c b/gcc/toplev.c
> index 28c115d..c480bfc 100644
> --- a/gcc/toplev.c
> +++ b/gcc/toplev.c
> @@ -2107,6 +2107,9 @@ toplev::main (int argc, char **argv)
>  
>finalize_plugins ();
>location_adhoc_data_fini (line_table);
> +
> +  after_memory_report = true;
> +
>if (seen_error () || werrorcount)
>  return (FATAL_EXIT_CODE);

Was this tested with "jit" in --enable-languages?   I ask because
toplev::main can be run repeatedly by libgccjit, and it looks like
nothing can reset after_memory_report.  (Though I don't typically build
with --enable-gather-detailed-mem-stats, and the jit docs don't mention
it).

Re: [PATCH] Add -funknown-commons to work around PR/69368 (and others) in SPEC2006

[Alan Lawrence]

On 22/02/16 12:03, Jakub Jelinek wrote:
> (f) A global command-line option, which we check alongside DECL_COMMON and
> further tests (basically, we want only DECL_COMMON decls that either have
> ARRAY_TYPE, or some other aggregate type with flexible array member or some
> other trailing array in the struct), and use the resulting predicate in
> places where we optimize based on DECL_SIZE{,_UNIT} of the decl - if that
> predicate returns true, we assume the DECL_SIZE is
> "variable"/"unlimited"/whatever.
> The two spots known to me that would need to use this new predicate would
> be:
> tree.c (array_at_struct_end_p):
[...]
> tree-dfa.c (get_ref_base_and_extent):
[...]

Close enough to what I meant by (a)/(b), but never mind that, and I hadn't
looked at where the change for aggressive loop opts needed to be. However...
Well you are essentially writing the patch for me at this point (so, thanks!),
 but here's a patch that puts that under a global -funknown-commons flag.
Testcase as before.

Bootstrapped (with flag overridden to true) on x86_64 and aarch64, check-gcc,
check-fortran, and tested 416.gamess on AArch64, where this patch enables
running *without* the -fno-aggressive-loop-opts previously required.

In the gcc testsuite, these fail with the option turned on:
gcc.dg/pr53265.c  (test for warnings, line 137)
gcc.dg/pr53265.c  (test for warnings, line 138)
gcc.dg/pr64277.c scan-tree-dump cunroll ... (*2)
gcc.dg/tree-ssa/cunroll-{1,2,3,4,9,10,11}.c scan-tree-dump 
cunroll/cunrolli/ivcanon (various)
gcc.dg/tree-ssa/loop-38.c scan-tree-dump cunrolli "Loop 1 iterates at most 11 
times"
...which all appear harmless.

Thomas Koenig suggests (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368#c80)
that this be combined with some flag fiddling and warnings in the Fortran
front-end; this patch doesn't do that, as I'm not very familiar with the
frontends, but that can follow in a separate patch. (Thomas?)

OK for trunk?

Cheers, Alan

gcc/ChangeLog:

DATE  Alan Lawrence  
  Jakub Jelinek  

* common.opt (funknown-commons, flag_unknown_commons): New.
* tree.c (array_at_struct_end_p): Do not limit to size of decl for
DECL_COMMONS if flag_unknown_commons is set.
* tree-dfa.c (get_ref_base_and_extent): Likewise.

gcc/testsuite/ChangeLog:

* gfortran.dg/unknown_commons.f: New.
---
 gcc/common.opt  |  4 
 gcc/testsuite/gfortran.dg/unknown_commons.f | 20 
 gcc/tree-dfa.c  | 15 ++-
 gcc/tree.c  |  6 --
 4 files changed, 42 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/unknown_commons.f

diff --git a/gcc/common.opt b/gcc/common.opt
index 520fa9c..b5b1282 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2455,6 +2455,10 @@ funit-at-a-time
 Common Report Var(flag_unit_at_a_time) Init(1)
 Compile whole compilation unit at a time.
 
+funknown-commons
+Common Var(flag_unknown_commons)
+Assume common declarations may be overridden with unknown larger sizes
+
 funroll-loops
 Common Report Var(flag_unroll_loops) Optimization
 Perform loop unrolling when iteration count is known.
diff --git a/gcc/testsuite/gfortran.dg/unknown_commons.f 
b/gcc/testsuite/gfortran.dg/unknown_commons.f
new file mode 100644
index 000..97e3ce3
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/unknown_commons.f
@@ -0,0 +1,20 @@
+! { dg-do compile }
+! { dg-options "-O3 -funknown-commons -fdump-tree-dom2-details" }
+
+! Test for PR69368: a single-element array in a common block, which will be
+! overridden with a larger size at link time (contrary to language spec).
+! Dominator opts considers accesses to differently-computed elements of X as
+! equivalent, unless -funknown-commons is passed in.
+  SUBROUTINE FOO
+  IMPLICIT DOUBLE PRECISION (X)
+  INTEGER J
+  COMMON /MYCOMMON / X(1)
+  DO 10 J=1,1024
+ X(J+1)=X(J+7)
+  10  CONTINUE
+  RETURN
+  END
+! { dg-final { scan-tree-dump-not "FIND" "dom2" } }
+! We should retain both a read and write of mycommon.x.
+! { dg-final { scan-tree-dump-times "  _\[0-9\]+ = 
mycommon\\.x\\\[_\[0-9\]+\\\];" 1 "dom2" } }
+! { dg-final { scan-tree-dump-times "  mycommon\\.x\\\[_\[0-9\]+\\\] = 
_\[0-9\]+;" 1 "dom2" } }
diff --git a/gcc/tree-dfa.c b/gcc/tree-dfa.c
index 0e98056..017e98e 100644
--- a/gcc/tree-dfa.c
+++ b/gcc/tree-dfa.c
@@ -612,9 +612,22 @@ get_ref_base_and_extent (tree exp, HOST_WIDE_INT *poffset,
 
   if (DECL_P (exp))
 {
+  if (flag_unknown_commons
+ && TREE_CODE (exp) == VAR_DECL && DECL_COMMON (exp))
+   {
+ tree sz_tree = TYPE_SIZE (TREE_TYPE (exp));
+ /* If size is unknown, or we have read to the end, assume there
+may be more to the structure than we are told.  */
+ if (TREE_CODE (TREE_TYPE (exp)) == ARRAY_TYPE
+ || (seen_variable_array_ref
+ 

Re: Importance of transformations that turn data dependencies into control dependencies?

[Torvald Riegel]

On Thu, 2016-02-25 at 18:33 +0100, Torvald Riegel wrote:
> On Wed, 2016-02-24 at 13:14 +0100, Richard Biener wrote:
> > On Tue, Feb 23, 2016 at 8:38 PM, Torvald Riegel  wrote:
> > > I'd like to know, based on the GCC experience, how important we consider
> > > optimizations that may turn data dependencies of pointers into control
> > > dependencies.  I'm thinking about all optimizations or transformations
> > > that guess that a pointer might have a specific value, and then create
> > > (specialized) code that assumes this value that is only executed if the
> > > pointer actually has this value.  For example:
> > >
> > > int d[2] = {23, compute_something()};
> > >
> > > int compute(int v) {
> > >   if (likely(v == 23)) return 23;
> > >   else ;
> > > }
> > >
> > > int bar() {
> > >   int *p = ptr.load(memory_order_consume);
> > >   size_t reveal_that_p_is_in_d = p - d[0];
> > >   return compute(*p);
> > > }
> > >
> > > Could be transformed to (after inlining compute(), and specializing for
> > > the likely path):
> > >
> > > int bar() {
> > >   int *p = ptr.load(memory_order_consume);
> > >   if (p == d) return 23;
> > >   else ;
> > > }
> > 
> > Note that if a user writes
> > 
> >   if (p == d)
> >{
> >  ... do lots of stuff via p ...
> >}
> > 
> > GCC might rewrite accesses to p as accesses to d and thus expose
> > those opportunities.  Is that a transform that isn't valid then or is
> > the code written by the user (establishing the equivalency) to blame?
> 
> In the context of this memory_order_consume proposal, this transform
> would be valid because the program has already "reveiled" what value p
> has after the branch has been taken.
> 
> > There's a PR where this kind of equivalencies lead to unexpected (wrong?)
> > points-to results for example.
> > 
> > > Other potential examples that come to mind are de-virtualization, or
> > > feedback-directed optimizations that has observed at runtime that a
> > > certain pointer is likely to be always equal to some other pointer (eg.,
> > > if p is almost always d[0], and specializing for that).
> > 
> > That's the cases that are quite important in practice.
> 
> Could you quantify this somehow, even if it's a very rough estimate?
> I'm asking because it's significant and widely used, then this would
> require users or compiler implementors to make a difficult trade-off
> (ie, do you want mo_consume performance or performance through those
> other optimizations?).
> 
> > > Also, it would be interesting to me to know how often we may turn data
> > > dependencies into control dependencies in cases where this doesn't
> > > affect performance significantly.
> > 
> > I suppose we try to avoid that but can we ever know for sure?  Like
> > speculative devirtualization does this (with the intent that it _does_ 
> > matter,
> > of course).

Due to a think-o on my behalf, I need to add that the transformations
that turn data into control dependencies would need to operate on data
that is not considered "constant" during the lifetime of the
application; IOW, all modifications to the data accessed through the
original data dependence would always have to happen-before any of the
accesses that get turned into a control dependency.

In the de-virtualization case I suppose this would be the case, because
the vtables won't change, so if the compiler turns this:
  func = p->vtable[23];
into this
  if (p->vtable == structA)
func = structA.vtable[23];  // or inlines func directly...
then this would not matter for the memory_order_consume load because all
the vtables wouldn't get modified concurrently.

[Bug tree-optimization/69666] [5 Regression] gcc ICE at -O2 and -O3 on valid code on x86_64-linux-gnu in "verify_gimple failed"

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||segher at gcc dot gnu.org
 Resolution|FIXED   |---

--- Comment #11 from Segher Boessenkool  ---
This new testcase ICEs on powerpc, for example on powerpc64-linux:

69666.c:16:1: internal compiler error: Segmentation fault
 }
 ^
0x10878acb crash_signal
/home/segher/src/gcc/gcc/toplev.c:335
0x105375e0 is_gimple_reg_type
/home/segher/src/gcc/gcc/gimple-expr.h:75
0x105375e0 is_gimple_val(tree_node*)
/home/segher/src/gcc/gcc/gimple-expr.c:781
0x108bad5f verify_gimple_assign_unary
/home/segher/src/gcc/gcc/tree-cfg.c:3539
0x108bad5f verify_gimple_assign
/home/segher/src/gcc/gcc/tree-cfg.c:4333
0x108bad5f verify_gimple_stmt
/home/segher/src/gcc/gcc/tree-cfg.c:4590
0x108ce2c3 verify_gimple_in_cfg(function*, bool)
/home/segher/src/gcc/gcc/tree-cfg.c:5052
0x107741e3 execute_function_todo
/home/segher/src/gcc/gcc/passes.c:1958
0x10774d93 do_per_function
/home/segher/src/gcc/gcc/passes.c:1645
0x107750cf execute_todo
/home/segher/src/gcc/gcc/passes.c:2010

(it doesn't ICE with a compiler two weeks or so old)

[Bug target/69841] Wrong template instantiation in C++11 on armv7l

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 CC||alan.lawrence at arm dot com,
   ||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #3 from James Greenhalgh  ---
I'm still confused by this. After coming out of the front end I checked the
DECL_ALIGN for each field of each of the parameters being passed to this
function. I see:


f1.ii

std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::iterator
std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_M_emplace_hint_unique(std::_Rb_tree<_Key, _Val, _KeyOfValue,
_Compare, _Alloc>::const_iterator, _Args&& ...)  
  (struct _Rb_tree * const this
   (decl alignment: 32),
   struct const_iterator __pos
 Fields:
   _M_node (decl alignment: 32)
   _Rb_tree_const_iterator (decl alignment: 8)
   value_type (decl alignment: 8)
   reference (decl alignment: 32)
   pointer (decl alignment: 32)
   iterator (decl alignment: 8)
   iterator_category (decl alignment: 8)
   difference_type (decl alignment: 32)
   _Self (decl alignment: 8)
   _Base_ptr (decl alignment: 32)
   _Link_type (decl alignment: 32)
   (decl alignment: 32, max field alignment: 32),
   const struct piecewise_construct_t & __args#0
   (decl alignment: 32),
   struct tuple & __args#1
   (decl alignment: 32),
   struct tuple & __args#2
   (decl alignment: 32))

f2.ii

std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::iterator
std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_M_emplace_hint_unique(std::_Rb_tree<_Key, _Val, _KeyOfValue,
_Compare, _Alloc>::const_iterator, _Args&& ...) 
  (struct _Rb_tree * const this
   (decl alignment: 32),
   struct const_iterator __pos
 Fields:
   _M_node (decl alignment: 32)
   _Rb_tree_const_iterator (decl alignment: 8)
   value_type (decl alignment: 64)
   reference (decl alignment: 32)
   pointer (decl alignment: 32)
   iterator (decl alignment: 32)
   iterator_category (decl alignment: 8)
   difference_type (decl alignment: 32)
   _Self (decl alignment: 8)
   _Base_ptr (decl alignment: 32)
   _Link_type (decl alignment: 32)
   (decl alignment: 32, max field alignment: 64),
   const struct piecewise_construct_t & __args#0
   (decl alignment: 32),
   struct tuple & __args#1
   (decl alignment: 32),
   struct tuple & __args#2
   (decl alignment: 32))
---

That is to say, after gimplification we've already decided that the alignment
of the value_type field of the std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::const_iterator parameter to std::_Rb_tree<_Key, _Val, _KeyOfValue,
_Compare, _Alloc>::_M_emplace_hint_unique in f2.ii is 64, whereas in f1.ii we
don't have any extra alignment information.

I know nothing about the C++ front-end and how we could end up in this
situation. I can understand why, given this, we would generate the code we do
for ARM.

[Bug c/69960] "initializer element is not constant"

[felix-gcc at fefe dot de]

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

--- Comment #2 from felix-gcc at fefe dot de ---
uh, yes in C.

$ cat test.c
#define TOLOWER(x) (x&~0x20)
#define Word(s) \
  s[1] ? s[2] ? s[3] ? \
(TOLOWER(s[0]) << 24) + (TOLOWER(s[1]) << 16) + (TOLOWER(s[2]) << 8) +
TOLOWER(s[3]) : \
(TOLOWER(s[0]) << 16) + (TOLOWER(s[1]) << 8) + TOLOWER(s[2]) : \
(TOLOWER(s[0]) << 8) + TOLOWER(s[1]) : \
TOLOWER(s[0])

const unsigned int _the = Word("the");
$ clang -c test.c
$ clang --version
clang version 3.9.0 (trunk 261746)

Re: Importance of transformations that turn data dependencies into control dependencies?

[Torvald Riegel]

On Wed, 2016-02-24 at 13:14 +0100, Richard Biener wrote:
> On Tue, Feb 23, 2016 at 8:38 PM, Torvald Riegel  wrote:
> > I'd like to know, based on the GCC experience, how important we consider
> > optimizations that may turn data dependencies of pointers into control
> > dependencies.  I'm thinking about all optimizations or transformations
> > that guess that a pointer might have a specific value, and then create
> > (specialized) code that assumes this value that is only executed if the
> > pointer actually has this value.  For example:
> >
> > int d[2] = {23, compute_something()};
> >
> > int compute(int v) {
> >   if (likely(v == 23)) return 23;
> >   else ;
> > }
> >
> > int bar() {
> >   int *p = ptr.load(memory_order_consume);
> >   size_t reveal_that_p_is_in_d = p - d[0];
> >   return compute(*p);
> > }
> >
> > Could be transformed to (after inlining compute(), and specializing for
> > the likely path):
> >
> > int bar() {
> >   int *p = ptr.load(memory_order_consume);
> >   if (p == d) return 23;
> >   else ;
> > }
> 
> Note that if a user writes
> 
>   if (p == d)
>{
>  ... do lots of stuff via p ...
>}
> 
> GCC might rewrite accesses to p as accesses to d and thus expose
> those opportunities.  Is that a transform that isn't valid then or is
> the code written by the user (establishing the equivalency) to blame?

In the context of this memory_order_consume proposal, this transform
would be valid because the program has already "reveiled" what value p
has after the branch has been taken.

> There's a PR where this kind of equivalencies lead to unexpected (wrong?)
> points-to results for example.
> 
> > Other potential examples that come to mind are de-virtualization, or
> > feedback-directed optimizations that has observed at runtime that a
> > certain pointer is likely to be always equal to some other pointer (eg.,
> > if p is almost always d[0], and specializing for that).
> 
> That's the cases that are quite important in practice.

Could you quantify this somehow, even if it's a very rough estimate?
I'm asking because it's significant and widely used, then this would
require users or compiler implementors to make a difficult trade-off
(ie, do you want mo_consume performance or performance through those
other optimizations?).

> > Also, it would be interesting to me to know how often we may turn data
> > dependencies into control dependencies in cases where this doesn't
> > affect performance significantly.
> 
> I suppose we try to avoid that but can we ever know for sure?  Like
> speculative devirtualization does this (with the intent that it _does_ matter,
> of course).
> 
> I suppose establishing non-dependence isn't an issue, like with the
> vectorizer adding runtime dependence checks and applying versioning
> to get a vectorized and a not vectorized loop (in case there are dependences)?

I'm not sure I understand you correctly.  Do you have a brief example,
perhaps?  For mo_consume and its data dependencies, if there might be a
dependence, the compiler would have to preserve it; but I guess that
both a vectorized loop an one that accessses each element separately
would preserve dependences because it's doing those accesses, and they
depend on the input data.
OTOH, peraps HW vector instructions don't get the ordering guarantees
from data dependences -- Paul, do you know of any such cases?

> > The background for this question is Paul McKenney's recently updated
> > proposal for a different memory_order_consume specification:
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0190r0.pdf
> >
> > In a nutshell, this requires a compiler to either prove that a pointer
> > value is not carrying a dependency (simplified, its value somehow
> > originates from a memory_order_consume load), or it has to
> > conservatively assume that it does; if it does, the compiler must not
> > turn data dependencies into control dependencies in generated code.
> > (The data dependencies, in contrast to control dependencies, enforce
> > memory ordering on archs such as Power and ARM; these orderings than
> > allow for not having to use an acquire HW barrier in the generated
> > code.)
> >
> > Given that such a proof will likely be hard for a compiler (dependency
> > chains propagate through assignments to variables on the heap and stack,
> > chains are not marked in the code, and points-to analysis can be hard),
> > a compiler faces a trade-off between either:
> > (1) trying to support this memory_order_consume specification and likely
> > disallowing all transformations that change data dependencies into
> > control dependencies, or
> > (2) not support the proposal by simply emitting memory_order_acquire
> > code, but get no new constraints on transformations in return (ie, what
> > we do for memory_order_consume today).
> >
> > A compiler could let users make this choice, but this will be hard for
> > users too, and the compiler would still have to pick a default.
> >
> > 

Re: [PATCH 1/4] Replace ENABLE_CHECKING macro with flag_checking in HSA

[Martin Jambor]

On Wed, Feb 24, 2016 at 02:59:11PM +0100, Martin Liska wrote:
> gcc/ChangeLog:
> 
> 2016-02-24  Martin Liska  
> 
>   * hsa-gen.c (generate_hsa): Replace ENABLE_CHECKING macro
>   with flag_checking.
>   * hsa-regalloc.c (linear_scan_regalloc): Likewise.


OK, thanks,

Martin

[Bug fortran/69834] Collision in derived type hashes

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
> Created attachment 37791
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37791=edit
> Better Patch

Withe patch applied to my working tree (many patches) fixes the PR but I see
several regressions at run time

FAIL: gfortran.dg/allocate_with_source_(7|8).f08   *  execution test
FAIL: gfortran.dg/unlimited_polymorphic_zzz.f03   *  execution test

with zzz in (1, 5, 6, 14, 17, 18, 20, 22). AFAICT it "fixes"

FAIL: gfortran.dg/finalize_21.f90   -O   scan-tree-dump original "static struct
__vtype__STAR __vtab__STAR = {._hash=0, ._size=., ._extends=0B, ._def_init=0B,
._copy=0B, ._final=0B};"

Re: [PATCH 3/9] S/390: Get rid of Y constraint in rotate patterns.

[Ulrich Weigand]

Andreas Krebbel wrote:

>   * config/s390/predicates.md (const_int_6bitset_operand): New
> predicates.
>   * config/s390/s390.md: Include subst.md.
>   ("rotl3"): New expander.
>   ("rotl3", "*rotl3_and"): Merge insn definitions into
>   ...
>   ("*rotl3"): New insn definition.
>   * config/s390/subst.md: New file.

This already looks much nicer (and shorter) :-)

In fact, I'm now wondering whether it couldn't be even shorter.  Would it
be possible to use instead of:

(define_insn "*rotl3"
  [(set (match_operand:GPR 0 "register_operand" "=d,d")
(rotate:GPR (match_operand:GPR 1 "register_operand"  "d,d")
(match_operand:SI  2 "nonmemory_operand" "a,n")))]
  "TARGET_CPU_ZARCH"
  "@
   rll\t%0,%1,(%2)
   rll\t%0,%1,%Y2"
  [(set_attr "op_type"  "RSE")
   (set_attr "atype""reg")
   (set_attr "enabled"  "*,")
   (set_attr "z10prop"  "z10_super_E1")])

simply something like:

(define_insn "*rotl3"
  [(set (match_operand:GPR 0 "register_operand" "=d")
(rotate:GPR (match_operand:GPR 1 "register_operand"  "d")
(match_operand:SI  2 "nonmemory_operand" "an")))]
  "TARGET_CPU_ZARCH"
  "rll\t%0,%1,
  [(set_attr "op_type"  "RSE")
   (set_attr "atype""reg")
   (set_attr "z10prop"  "z10_super_E1")])


where addr_style_op_ops is defined like:

(define_subst_attr "addr_style_op_ops" "addr_style_op_subst" "%Y2" "%Y3(%2)")

and we don't need addr_style_op_enabled any more?   %Y would continue
to emit both simple constants and register operands (and full address
operands e.g. for setmem) as before.


> +(define_subst "masked_op_subst"
> +  [(set (match_operand:DSI 0 ""   "")
> +(SUBST:DSI (match_operand:DSI 1 "" "")
> +(match_operand:SI  2 "" "")))]
> +  ""
> +  [(set (match_dup 0)
> +(SUBST:DSI (match_dup 1)
> +(and:SI (match_dup 2)
> +(match_operand:SI 3 "const_int_6bitset_operand" 
> ""])

Do we need a constraint letter here?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  ulrich.weig...@de.ibm.com

[Bug middle-end/69919] pool allocator and mem-stat race at program exit

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Liška  ---
Fixed in trunk.

[Bug middle-end/69919] pool allocator and mem-stat race at program exit

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Author: marxin
Date: Thu Feb 25 16:57:39 2016
New Revision: 233722

URL: https://gcc.gnu.org/viewcvs?rev=233722=gcc=rev
Log:
Do not gather mem stats in run_exit_handles (PR

PR middle-end/69919
* alloc-pool.c (after_memory_report): New variable.
* alloc-pool.h (base_pool_allocator ::release): Do not use
the infrastructure if after_memory_report.
* toplev.c (toplev::main): Mark after memory report.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/alloc-pool.c
trunk/gcc/alloc-pool.h
trunk/gcc/toplev.c

[PATCH] Fix DW_OP_GNU_implicit_pointer referring to DW_TAG_dwarf_procedure (PR debug/69947)

[Jakub Jelinek]

On Thu, Feb 25, 2016 at 04:53:58PM +0100, Pierre-Marie de Rodat wrote:
> I introduced a DW_OP_call* traversal for this:
> 
>   * prune_unused_types_mark traverses attributes using
> prune_unused_types_walk_attribs;
> 
>   * …_walk_attribs walks location descriptions and location lists using
> …_walk_loc_descr
> 
>   * …_walk_loc_descr marks DWARF procedures referenced by DW_OP_call*
> operations.

Ah, I've been looking for something that would set die_perennial_p, but
actually you just set die_mark later on instead for those.
So IMHO the right fix is just handle all the ops that could directly or
indirectly contain references to other DIEs, rather than just handling
the 3 you have there.

Going to bootstrap/regtest this on x86_64-linux and i686-linux now.

Is this ok for trunk if it passes testing?

2016-02-25  Jakub Jelinek  

PR debug/69947
* dwarf2out.c (prune_unused_types_walk_loc_descr): Handle
all other ops that have dw_val_class_die_ref operands,
and DW_OP_GNU_entry_value.

* gcc.dg/guality/pr69947.c: New test.

--- gcc/dwarf2out.c.jj  2016-02-25 17:04:11.465781368 +0100
+++ gcc/dwarf2out.c 2016-02-25 17:41:26.785371399 +0100
@@ -25641,11 +25641,29 @@ prune_unused_types_walk_loc_descr (dw_lo
   for (; loc != NULL; loc = loc->dw_loc_next)
 switch (loc->dw_loc_opc)
   {
+  case DW_OP_GNU_implicit_pointer:
+  case DW_OP_GNU_convert:
+  case DW_OP_GNU_reinterpret:
+   if (loc->dw_loc_oprnd1.val_class == dw_val_class_die_ref)
+ prune_unused_types_mark (loc->dw_loc_oprnd1.v.val_die_ref.die, 1);
+   break;
   case DW_OP_call2:
   case DW_OP_call4:
   case DW_OP_call_ref:
+  case DW_OP_GNU_const_type:
+  case DW_OP_GNU_parameter_ref:
+   gcc_assert (loc->dw_loc_oprnd1.val_class == dw_val_class_die_ref);
prune_unused_types_mark (loc->dw_loc_oprnd1.v.val_die_ref.die, 1);
break;
+  case DW_OP_GNU_regval_type:
+  case DW_OP_GNU_deref_type:
+   gcc_assert (loc->dw_loc_oprnd2.val_class == dw_val_class_die_ref);
+   prune_unused_types_mark (loc->dw_loc_oprnd2.v.val_die_ref.die, 1);
+   break;
+  case DW_OP_GNU_entry_value:
+   gcc_assert (loc->dw_loc_oprnd1.val_class == dw_val_class_loc);
+   prune_unused_types_walk_loc_descr (loc->dw_loc_oprnd1.v.val_loc);
+   break;
   default:
break;
   }
--- gcc/testsuite/gcc.dg/guality/pr69947.c.jj   2016-02-25 17:22:13.729098931 
+0100
+++ gcc/testsuite/gcc.dg/guality/pr69947.c  2016-02-25 17:22:13.729098931 
+0100
@@ -0,0 +1,22 @@
+/* PR debug/69947 */
+/* { dg-do run } */
+/* { dg-options "-g" } */
+
+#include "../nop.h"
+
+static const char *c = "foobar";
+
+__attribute__((noinline, noclone)) void
+foo (void)
+{
+  static const char a[] = "abcdefg";
+  const char *b = a;   /* { dg-final { gdb-test 14 "c\[2\]" "'o'" } } 
*/
+  asm (NOP : : : "memory");/* { dg-final { gdb-test 14 "b\[4\]" "'e'" } } 
*/
+}
+
+int
+main ()
+{
+  foo ();
+  return 0;
+}


Jakub

[Bug rtl-optimization/67145] [6 Regression] associativity from pseudo-reg ordering

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #10 from Richard Henderson  ---
(In reply to Alan Modra from comment #1)
> 1) Why isn't "in + x" hoisted out of the loop?

With the patch in #c3, we do hoist indeed it during the rtl loop pass.
That said...

> 2) If we care about associativity, isn't the r224768 ordering correct in
> that it follows the gimple association?  See gimple below.
...
>   _13 = _11 + x_12(D);
>   _14 = (sizetype) _13;
>   _16 = in_15(D) + _14;

This is tricky.  The _11 + x_12 expression is signed, while of course
the in_15 + _14 POINTER_PLUS_EXPR requires a sizetype.  I don't see how
we could re-associate at the gimple level without changing semantics.

But once we lower to rtl, we lose signed vs unsigned, and can legitimately
re-associate the expressions.

> 3) If we want reverse associativity at the rtl level, isn't relying on
> sorting done according to pseudo reg numbering deep inside a function
> simplifying additive expressions, just a little bit fragile?

It isn't the best way, I'll grant you.  For this particular case, if x
had pseudo number 200, we wouldn't have formed the in+x subexpression that
turns out to be so helpful.

What would be better is a primary sort for loop invariability.  But
we don't have that here.  And when we're doing rtl loop optimizations
we don't re-associate (to my knowledge).

In the end, if we don't use *something* to produce a stable sort, then
we're unlikely to see that w+x+y+z is equal to z+y+x+w.

I still believe that the ppc backend should change to allow CA in any
order, as Jakub suggested.  I'll give it a go.

[Bug c++/69889] [6 Regression] ICE: in assign_temp, at function.c:961

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
Not r232168 but r232167 it seems.

[Bug c++/69959] [6 Regression] gcc-6 doesn't build gcc-5 anymore

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #4 from Markus Trippelsdorf  ---
Yes. Works fine now. Thanks for the quick fix.

[Bug c++/69889] [6 Regression] ICE: in assign_temp, at function.c:961

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
(In reply to Jakub Jelinek from comment #1)
> Started with r232168.

I don't think so; reverting that commit doesn't change anything.

[Bug rtl-optimization/69896] [6 Regression] wrong code with -frename-registers @ x64_64

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||segher at gcc dot gnu.org
 Resolution|FIXED   |---

--- Comment #6 from Segher Boessenkool  ---
This new testcase fails on powerpc64le-linux:

69896.c:16:1: internal compiler error: verify_gimple failed
0x1089ffb3 verify_gimple_in_cfg(function*, bool)
/home/segher/src/gcc/gcc/tree-cfg.c:5082
0x107412c3 execute_function_todo
/home/segher/src/gcc/gcc/passes.c:1958
0x10741eb3 do_per_function
/home/segher/src/gcc/gcc/passes.c:1645
0x107421df execute_todo
/home/segher/src/gcc/gcc/passes.c:2010

[Bug c++/69961] New: Segfault when calling constructor from variadic template by referring to T::T

[chatelet.guillaume at gmail dot com]

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

Bug ID: 69961
   Summary: Segfault when calling constructor from variadic
template by referring to T::T
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chatelet.guillaume at gmail dot com
  Target Milestone: ---

Created attachment 37794
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37794=edit
The preprocessed file


- source code (test.cc)
- This is the reduced example that triggers the bug, the c

#include 

using std::string;

class Format {
 public:
  explicit Format(string formatted) {}
  string buffer;
};

string StrCat(const string& a) {
  return "";
}

template 
Format Message(string msg, const AV&... args) {
  return Format::Format(StrCat(msg, args...));
}

int main(int, char**) {
  Message("msg");
}


- Command line

> g++ -std=c++11 test.cc && ./a.out
> segmentation fault (core dumped)  ./a.out


- Description - credits to richard-gccbugzilla at metafoo dot co.uk

"The relevant language rule was (depending on your interpretation of the old
rule) either clarified or changed by C++ core issue 1310:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1310

Format::Format is ambiguous: it either names a constructor of Format or it
names the type Format (the name of a class is implicitly injected into the
scope of that class, more or less as if it contained a "typedef ::Format
Format;"; this is called the injected-class-name). In a function-style explicit
cast expression, such as yours above, the name before the left paren must name
a type (you cannot explicitly call a constructor).

The new language rule says that T::T only names the injected-class-name if the
name appears in a context where functions would not even be considered --
specifically, in a nested-name-specifier (T::T::), in an
elaborated-type-specifier (class T::T), and in a base-specifier (class U : T::T
{...};). (As it happens, there are no other cases where function names are
ignored.)

Clang does not implement that (new?) rule yet, which is why it accepts the
program (and compiles it to working code). GCC *does* implement the rule.
However, it apparently has a bug when the call has dependent arguments, and
doesn't enforce it in that case. If I were to guess, my guess would be that GCC
decides that this must be a static member function call, but whatever the
reason, it doesn't pass in a 'this' pointer to the constructor, which seems to
be what causes the segfault."


- gcc environment

> g++ -v -save-temps -std=c++11 test.cc
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.8.4-2ubuntu1~14.04.1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.1)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/4.8/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE test.cc -mtune=generic -march=x86-64 -std=c++11
-fpch-preprocess -fstack-protector -Wformat -Wformat-security -o 

[Bug c/69960] New: "initializer element is not constant"

[felix-gcc at fefe dot de]

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

Bug ID: 69960
   Summary: "initializer element is not constant"
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: felix-gcc at fefe dot de
  Target Milestone: ---

This is the code:

#define TOLOWER(x) (x&~0x20)
#define Word(s) \
  s[1] ? s[2] ? s[3] ? \
(TOLOWER(s[0]) << 24) + (TOLOWER(s[1]) << 16) + (TOLOWER(s[2]) << 8) +
TOLOWER(s[3]) : \
(TOLOWER(s[0]) << 16) + (TOLOWER(s[1]) << 8) + TOLOWER(s[2]) : \
(TOLOWER(s[0]) << 8) + TOLOWER(s[1]) : \
TOLOWER(s[0])

const unsigned int _the = Word("the");



When compiling, this happens:

test.c:9:32: error: initializer element is not constant
 const unsigned int _the = Word("the");
^
test.c:3:3: note: in definition of macro ‘Word’
   s[1] ? s[2] ? s[3] ? \
   ^


How is this not constant? clang thinks it is constant.

[Bug c/69960] "initializer element is not constant"

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
(In reply to felix-gcc from comment #0)
> How is this not constant? clang thinks it is constant.

Not in C:

$ clang q.c -c
q.c:9:27: error: initializer element is not a compile-time constant

Re: [PATCH] [RFA] [PR tree-optmization/69740] Schedule loop fixups when needed

[Jeff Law]

On 02/25/2016 03:00 AM, Richard Biener wrote:


+  /* Look at BB's successors, if any are marked as BB_IRREDUCIBLE_LOOP,
then
+ removing BB (and its outgoing edges) may make the loop a natural
+ loop.  In which case we need to schedule loop fixups.  */
+  if (current_loops)
+for (edge_iterator ei = ei_start (bb->succs); !ei_end_p (ei); ei_next
())
+  if (ei_edge (ei)->dest->flags & BB_IRREDUCIBLE_LOOP)
+   loops_state_set (LOOPS_NEED_FIXUP);


So I fail to see how only successor edges are relevant.  Isn't the important
case to catch whether we remove an edge marked EDGE_IRREDUCIBLE_LOOP?
Even if the BB persists we might have exposed a new loop here.

Yea, let me give that a spin.



Note that it is not safe to look at {BB,EDGE}_IRREDUCIBLE_LOOP if the loop
state does not have LOOPS_HAVE_MARKED_IRREDUCIBLE_REGIONS set
(the flags may be stale or missing).  So it might be that we can't rely on
non-loop passes modifying the CFG to handle this optimistically.
I was concerned about this as well.   The problem case would be if we 
have an irreducible loop with nodes not marked.  In that case we could 
fail to ask for loop fixups leading to failure again.  The other cases 
shouldn't cause failures, but can cause us to spend time fixing up loops 
which perhaps we didn't need to.


Anyway, I'll have a closer look at that too.



Jeff

Re: [PATCHES, PING*5] Enhance standard DWARF for Ada

[Pierre-Marie de Rodat]

On 02/25/2016 04:51 PM, Jakub Jelinek wrote:

Do you have some short Ada testcase where the DW_OP_call4 referring to
DW_TAG_dwarf_procedure is supposed to be emitted?  I believe you must be
getting there the .Ldebug_info0+0 invalid reference in the DW_OP_call4
operand.


Sure! Here’s one:

$ gcc -S -g -fgnat-encodings=minimal -dA foo.adb && grep DW_OP_call4 foo.s
foo.s:313:  .byte   0x99# DW_OP_call4


--
Pierre-Marie de Rodat
procedure Foo is

   type Record_Type (N : Natural) is record
  S1 : String (1 .. N);
  S2 : String (1 .. N);
   end record;

   procedure Process (R : Record_Type) is
   begin
  null;
   end Process;

   R : Record_Type (4) := (4, "abcd", "efgh");

begin
   Process (R);
end Foo;

Re: [PATCHES, PING*5] Enhance standard DWARF for Ada

[Pierre-Marie de Rodat]

On 02/25/2016 10:48 AM, Jakub Jelinek wrote:

The first one just fixes what I mainly care about, the committed patch
assumed that DW_TAG_dwarf_procedure is always only created for the Ada
variable sized structures or whatever it was meant for, which is not the
case, and thus if we emit DW_TAG_dwarf_procedure for some other reason,
it would be pruned as unused even when it is actually used (and result in
a DIE reference to the compilation unit header, which is always invalid).


This first patch looks good to me, as a good enough and simple fix.


But, looking at the points where you use DW_TAG_dwarf_procedure for the Ada
things, I can't see how it can actually work at all, though there is no
testsuite coverage, so it is hard to find out for real.
The thing is, current code sets die_perennial_p on type DIEs and their
parents, but nothing else.  In particular, type DIEs are identified by
being returned from lookup_type_die, thus earlier passed to
equate_type_number_to_die.  I don't see that this would ever be the case
of DW_TAG_dwarf_procedure though, I see the return of
function_to_dwarf_procedure being used as dw_loc_oprnd1.v.val_die_ref.die
of a DW_OP_call4 that is somewhere used in some location description that is
perhaps used somewhere in some type DIE computation.


I introduced a DW_OP_call* traversal for this:

  * prune_unused_types_mark traverses attributes using
prune_unused_types_walk_attribs;

  * …_walk_attribs walks location descriptions and location lists using
…_walk_loc_descr

  * …_walk_loc_descr marks DWARF procedures referenced by DW_OP_call*
operations.

So all DWARF procedures referenced this way are not supposed to be 
pruned (I checked: no problem for the Ada types I tested). As you 
noticed, I did not realize that there were other DWARF procedure 
producers, hence the assumption that this was enought to mark all DWARF 
procs.



So IMHO the second patch
makes more sense, and if you (for GCC 7?) want to prune really unused
DW_TAG_dwarf_procedure, you need to add code that will really walk all of
the debuginfo, rather than just type DIEs themselves, and look if location
descriptions (in .debug_info or .debug_loc) reference those
DW_TAG_dwarf_procedure and mark the DW_TAG_dwarf_procedure.


I just had a look: the prune_unused_type_mark pass already reaches the 
DW_OP_GNU_implicit_pointer operation, it’s just that 
prune_unused_types_walk_loc_descr does not know about this kind of 
operation. I think the attached patch is a more general fix for that. 
What do you think?


(bootstrapped and regtested on x86_64-linux)

--
Pierre-Marie de Rodat
>From 671199e8a7da326e54e081b5c368f93428455e98 Mon Sep 17 00:00:00 2001
From: Pierre-Marie de Rodat 
Date: Thu, 25 Feb 2016 11:37:22 +0100
Subject: [PATCH] DWARF: fix debug info for implicit pointers to string
 constants

2016-02-25  Pierre-Marie de Rodat  

PR debug/69947
* dwarf2out.c (prune_unused_types_walk_loc_descr): Recurse on
  all dw_val_class_die_ref operands, not just the ones for
  DW_OP_call* operations.

2016-02-25  Jakub Jelinek  

PR debug/69947
* gcc.dg/guality/pr69947.c: New test.
---
 gcc/dwarf2out.c| 16 +++-
 gcc/testsuite/gcc.dg/guality/pr69947.c | 22 ++
 2 files changed, 29 insertions(+), 9 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/guality/pr69947.c

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 97e192b..37ccd3a 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -25639,16 +25639,14 @@ static void
 prune_unused_types_walk_loc_descr (dw_loc_descr_ref loc)
 {
   for (; loc != NULL; loc = loc->dw_loc_next)
-switch (loc->dw_loc_opc)
-  {
-  case DW_OP_call2:
-  case DW_OP_call4:
-  case DW_OP_call_ref:
+{
+  if (loc->dw_loc_oprnd1.val_class == dw_val_class_die_ref
+	  && !loc->dw_loc_oprnd1.v.val_die_ref.external)
 	prune_unused_types_mark (loc->dw_loc_oprnd1.v.val_die_ref.die, 1);
-	break;
-  default:
-	break;
-  }
+  if (loc->dw_loc_oprnd2.val_class == dw_val_class_die_ref
+	  && !loc->dw_loc_oprnd2.v.val_die_ref.external)
+	prune_unused_types_mark (loc->dw_loc_oprnd2.v.val_die_ref.die, 1);
+}
 }
 
 /* Given DIE that we're marking as used, find any other dies
diff --git a/gcc/testsuite/gcc.dg/guality/pr69947.c b/gcc/testsuite/gcc.dg/guality/pr69947.c
new file mode 100644
index 000..6280ed5
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/guality/pr69947.c
@@ -0,0 +1,22 @@
+/* PR debug/69947 */
+/* { dg-do run } */
+/* { dg-options "-g" } */
+
+#include "../nop.h"
+
+static const char *c = "foobar";
+
+__attribute__((noinline, noclone)) void
+foo (void)
+{
+  static const char a[] = "abcdefg";
+  const char *b = a;		/* { dg-final { gdb-test 14 "c\[2\]" "'o'" } } */
+  asm (NOP : : : "memory");	/* { dg-final { gdb-test 14 "b\[4\]" "'e'" } } */
+}
+
+int
+main ()
+{
+  foo ();
+  return 0;
+}
-- 

Re: [PATCH] powerpc: Handle DImode rotatert implemented with rlwinm (PR69946)

[David Edelsohn]

On Wed, Feb 24, 2016 at 5:57 PM, Segher Boessenkool
 wrote:
> Some DImode rotate-right-and-mask can be implemented best with a rlwinm
> instruction: those that could be a lshiftrt instead of a rotatert, while
> the mask is not right-aligned.  Why the rotate in the testcase is not
> optimised to a plain shift is another question, but we need to handle
> it here anyway.  We compute the shift amount for a 64-bit rotate.  This
> is 32 too high in this case; if we print using %h that is masked out (and
> this doesn't silently let through invalid instructions, everything is
> checked by rs6000_is_valid_shift_mask which is much more thorough).
>
> Built and tested on powerpc64-linux, -m32,-m64 and -mlra,-mno-lra.  Also
> tested the new test on powerpc64le-linux (where the test is skipped).
> Is this okay for trunk?
>
>
> Segher
>
>
> 2016-02-24  Segher Boessenkool  
>
> PR target/69946
> * config/rs6000/rs6000.c (rs6000_insn_for_shift_mask): Print rlwinm
> shift amount using %h.
>
> gcc/testsuite/
> * pr69946.c: New file.

Okay.

Please add a short comment explaining why rs6000_insn_for_shift_mask
doesn't need to match the logic in rs6000_is_valid_shift_mask
converting rotates to simple shifts.

Thanks, David

Re: [PATCHES, PING*5] Enhance standard DWARF for Ada

[Jakub Jelinek]

On Thu, Feb 25, 2016 at 11:35:07AM +0100, Pierre-Marie de Rodat wrote:
> On 02/25/2016 10:48 AM, Jakub Jelinek wrote:
> >Unfortunately, this broke the DW_OP_GNU_implicit_pointer support, on vast
> >majority of binaries and libraries gcc now emits invalid DWARF (which both
> >gdb and dwz complain about and dwz refuses to optimize because of that).
> 
> Arg, sorry about this!
> 
> >I'm attaching two possible patches, so far untested.
> 
> Thanks, I’m having a look as we speak.
> 
> >So, Pierre-Marie, can I ask you to run whatever Ada debug info testsuite
> >you have with the second patch?  And for GCC 7 really please consider adding
> >gnat.dg/guality/ and fill it with tests.
> 
> Testing in progress…
> 
> I have a tiny Python/pyelftools-based testsuite that checks the DIE patterns
> GCC emits for several Ada types. I really wish I could somehow integrate
> them to the GCC testsuite, but right now I don’t know how I could do similar
> things, there.

Do you have some short Ada testcase where the DW_OP_call4 referring to
DW_TAG_dwarf_procedure is supposed to be emitted?  I believe you must be
getting there the .Ldebug_info0+0 invalid reference in the DW_OP_call4
operand.

Jakub

[Bug c++/69959] [6 Regression] gcc-6 doesn't build gcc-5 anymore

[bernd.edlinger at hotmail dot de]

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

--- Comment #3 from Bernd Edlinger  ---
Hi Markus,

it should work now.
Please update gcc-5 to r233720 and try again.

Bernd.

[Bug sanitizer/69839] cross-compiling programs w/-fsanitize=address fails: ld: warning: libstdc++.so.6, needed by libasan.so, not found (try using -rpath or -rpath-link)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #9 from Jakub Jelinek  ---
(In reply to Joakim Tjernlund from comment #8)
> > That is correct.
> 
> hmm, this feels a bit odd. Using

I'm not the author of --sysroot changes, but I'd say that it is again user
error:

> sudo /usr/powerpc-g2.20-linux-gnu/sbin/ldconfig -v  -C
> /usr/powerpc-g2.20-linux-gnu/etc/ld.so.cache -f
> /usr/powerpc-g2.20-linux-gnu/etc/ld.so.conf

If you have sysrooted file, you should use .../ldconfig -r
/usr/powerpc-g2.20-linux-gnu/ ...
(of course only if you actually can run the binaries, in most cases you are
cross-compiling for incompatible architecture and you need either emulator, or
can't run it at all).
Anyway, I don't think gcc bugzilla is the right forum to learn about sysroots.

[PATCH 1/4] Replace ENABLE_CHECKING macro with flag_checking in HSA

[marxin]

gcc/ChangeLog:

2016-02-24  Martin Liska  

* hsa-gen.c (generate_hsa): Replace ENABLE_CHECKING macro
with flag_checking.
* hsa-regalloc.c (linear_scan_regalloc): Likewise.
---
 gcc/hsa-gen.c  | 25 +
 gcc/hsa-regalloc.c |  7 +++
 2 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/gcc/hsa-gen.c b/gcc/hsa-gen.c
index 28e8b6f..8e2144c 100644
--- a/gcc/hsa-gen.c
+++ b/gcc/hsa-gen.c
@@ -6091,21 +6091,22 @@ generate_hsa (bool kernel)
 s->m_gridified_kernel_p);
 }
 
-#ifdef ENABLE_CHECKING
-  for (unsigned i = 0; i < hsa_cfun->m_ssa_map.length (); i++)
-if (hsa_cfun->m_ssa_map[i])
-  hsa_cfun->m_ssa_map[i]->verify_ssa ();
-
-  basic_block bb;
-  FOR_EACH_BB_FN (bb, cfun)
+  if (flag_checking)
 {
-  hsa_bb *hbb = hsa_bb_for_bb (bb);
+  for (unsigned i = 0; i < hsa_cfun->m_ssa_map.length (); i++)
+   if (hsa_cfun->m_ssa_map[i])
+ hsa_cfun->m_ssa_map[i]->verify_ssa ();
 
-  for (hsa_insn_basic *insn = hbb->m_first_insn; insn; insn = insn->m_next)
-   insn->verify ();
-}
+  basic_block bb;
+  FOR_EACH_BB_FN (bb, cfun)
+   {
+ hsa_bb *hbb = hsa_bb_for_bb (bb);
 
-#endif
+ for (hsa_insn_basic *insn = hbb->m_first_insn; insn;
+  insn = insn->m_next)
+   insn->verify ();
+   }
+}
 
   hsa_regalloc ();
   hsa_brig_emit_function ();
diff --git a/gcc/hsa-regalloc.c b/gcc/hsa-regalloc.c
index f8e83ecf..9437132 100644
--- a/gcc/hsa-regalloc.c
+++ b/gcc/hsa-regalloc.c
@@ -580,10 +580,9 @@ linear_scan_regalloc (struct m_reg_class_desc *classes)
   /* Sort all intervals by increasing start point.  */
   gcc_assert (ind2reg.length () == (size_t) hsa_cfun->m_reg_count);
 
-#ifdef ENABLE_CHECKING
-  for (unsigned i = 0; i < ind2reg.length (); i++)
-gcc_assert (ind2reg[i]);
-#endif
+  if (flag_checking)
+for (unsigned i = 0; i < ind2reg.length (); i++)
+  gcc_assert (ind2reg[i]);
 
   ind2reg.qsort (cmp_begin);
   for (i = 0; i < 4; i++)
-- 
2.7.0

[Bug sanitizer/69839] cross-compiling programs w/-fsanitize=address fails: ld: warning: libstdc++.so.6, needed by libasan.so, not found (try using -rpath or -rpath-link)

[joakim.tjernlund at infinera dot com]

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

--- Comment #8 from Joakim Tjernlund  ---
(In reply to Jakub Jelinek from comment #7)
> (In reply to Joakim Tjernlund from comment #6)
> > (In reply to Jakub Jelinek from comment #5)
> > > Likely a bug on the Gentoo side.
> > > The linker handles differently libraries specified on the command line and
> > > libraries that are needed by those shared libraries, but are not mentioned
> > > on the command line.  See binutils documentation.
> > 
> > Digging into this I noticed ld searches $sysroot/etc/ld.so.conf so
> > I tried adding /usr/lib/gcc/powerpc-g2.20-linux-gnu/4.9.3/, like so:
> > # ld.so.conf autogenerated by env-update; make all changes to
> > # contents of /etc/env.d directory
> > /usr/powerpc-g2.20-linux-gnu/lib
> > /usr/lib/gcc/powerpc-g2.20-linux-gnu/4.9.3/
> > 
> > However I see using strace that ld tries to open:
> > "/usr/powerpc-g2.20-linux-gnu/usr/lib/gcc/powerpc-g2.20-linux-gnu/4.9.3/
> > libstdc++.so.6
> > 
> > That is, ld prefixes every path in ld.so.conf with $sysroot.
> > Is that correct or a bug in binutils?
> 
> That is correct.

hmm, this feels a bit odd. Using
sudo /usr/powerpc-g2.20-linux-gnu/sbin/ldconfig -v  -C
/usr/powerpc-g2.20-linux-gnu/etc/ld.so.cache -f
/usr/powerpc-g2.20-linux-gnu/etc/ld.so.conf

and then printing the cache:
/usr/powerpc-g2.20-linux-gnu/sbin/ldconfig -v -p -C
/usr/powerpc-g2.20-linux-gnu/etc/ld.so.cache 50 libs found in cache
`/usr/powerpc-g2.20-linux-gnu/etc/ld.so.cache'

libz.so.1 (libc6) => /usr/powerpc-g2.20-linux-gnu/lib/libz.so.1
libutil.so.1 (libc6, OS ABI: Linux 2.6.32) =>
/usr/powerpc-g2.20-linux-gnu/lib/libutil.so.1
libubsan.so.0 (libc6) =>
/usr/lib/gcc/powerpc-g2.20-linux-gnu/4.9.3/libubsan.so.0
libubsan.so (libc6) =>
/usr/lib/gcc/powerpc-g2.20-linux-gnu/4.9.3/libubsan.so
libthread_db.so.1 (libc6, OS ABI: Linux 2.6.32) =>
/usr/powerpc-g2.20-linux-gnu/lib/libthread_db.so.1
libstdc++.so.6 (libc6) =>
/usr/lib/gcc/powerpc-g2.20-linux-gnu/4.9.3/libstdc++.so.6
libstdc++.so (libc6) =>
/usr/lib/gcc/powerpc-g2.20-linux-gnu/4.9.3/libstdc++.so
librt.so.1 (libc6, OS ABI: Linux 2.6.32) =>
/usr/powerpc-g2.20-linux-gnu/lib/librt.so.1

it finds and prints my libs.
to it would make more sense to honor the exact paths in ld.so.conf instead.
It is much more flexible.

Why is the current behaviour correct(what problem does it solve)?

[PATCH 0/4] Replace remaining ENABLE_CHECKING macros

[marxin]

Hello

Following series removes remaining usage of ENABLE_CHECKING macro, where
the last patch eventually poisons the macro.

The series has been tested in common and survives regbootstrap on
x86_64-linux-gnu with default options (and Ada enabled)
and --enable-checking=none.

Ready for trunk?
Martin

marxin (4):
  Replace ENABLE_CHECKING macro with flag_checking in HSA
  Replace ENABLE_CHECKING macro with flag_checking in GNAT
  Replace ENABLE_CHECKING with CHECKING_P in dwarf2out
  Poison ENABLE_CHECKING macro

 gcc/ada/gcc-interface/utils.c | 12 +++-
 gcc/dwarf2out.c   |  6 +++---
 gcc/dwarf2out.h   |  2 +-
 gcc/hsa-gen.c | 25 +
 gcc/hsa-regalloc.c|  7 +++
 gcc/system.h  |  4 
 6 files changed, 31 insertions(+), 25 deletions(-)

-- 
2.7.0

[PATCH 3/4] Replace ENABLE_CHECKING with CHECKING_P in dwarf2out

[marxin]

gcc/ChangeLog:

2016-02-25  Martin Liska  

* dwarf2out.c (new_loc_descr): Replace ENABLE_CHECKING with
CHECKING_P.
(resolve_args_picking_1): Likewise.
* dwarf2out.h (struct GTY): Likewise.
---
 gcc/dwarf2out.c | 6 +++---
 gcc/dwarf2out.h | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 97e192b..a8c21d8 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -1325,7 +1325,7 @@ new_loc_descr (enum dwarf_location_atom op, unsigned 
HOST_WIDE_INT oprnd1,
   dw_loc_descr_ref descr = ggc_cleared_alloc ();
 
   descr->dw_loc_opc = op;
-#if ENABLE_CHECKING
+#if CHECKING_P
   descr->dw_loc_frame_offset = -1;
 #endif
   descr->dw_loc_oprnd1.val_class = dw_val_class_unsigned_const;
@@ -15369,14 +15369,14 @@ resolve_args_picking_1 (dw_loc_descr_ref loc, 
unsigned initial_frame_offset,
   /* If we already met this node, there is nothing to compute anymore.  */
   if (visited.add (l))
{
-#if ENABLE_CHECKING
+#if CHECKING_P
  /* Make sure that the stack size is consistent wherever the execution
 flow comes from.  */
  gcc_assert ((unsigned) l->dw_loc_frame_offset == frame_offset_);
 #endif
  break;
}
-#if ENABLE_CHECKING
+#if CHECKING_P
   l->dw_loc_frame_offset = frame_offset_;
 #endif
 
diff --git a/gcc/dwarf2out.h b/gcc/dwarf2out.h
index a96ac38..91b3d6b 100644
--- a/gcc/dwarf2out.h
+++ b/gcc/dwarf2out.h
@@ -239,7 +239,7 @@ struct GTY((chain_next ("%h.dw_loc_next"))) 
dw_loc_descr_node {
  frame offset.  */
   unsigned int frame_offset_rel : 1;
   int dw_loc_addr;
-#if ENABLE_CHECKING
+#if CHECKING_P
   /* When translating a function into a DWARF procedure, contains the frame
  offset *before* evaluating this operation.  It is -1 when not yet
  initialized.  */
-- 
2.7.0

[PATCH 4/4] Poison ENABLE_CHECKING macro

[marxin]

gcc/ChangeLog:

2016-02-25  Martin Liska  

* system.h: Poison ENABLE_CHECKING macro.
---
 gcc/system.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/gcc/system.h b/gcc/system.h
index 445073c..cb54541 100644
--- a/gcc/system.h
+++ b/gcc/system.h
@@ -1014,6 +1014,10 @@ extern void fancy_abort (const char *, int, const char 
*) ATTRIBUTE_NORETURN;
 #undef rindex
  #pragma GCC poison bcopy bzero bcmp rindex
 
+/* Poison ENABLE_CHECKING macro that should be replaced with
+   'if (flag_checking)', or with CHECKING_P macro.  */
+#pragma GCC poison ENABLE_CHECKING
+
 #endif /* GCC >= 3.0 */
 
 /* This macro allows casting away const-ness to pass -Wcast-qual
-- 
2.7.0

[PATCH 2/4] Replace ENABLE_CHECKING macro with flag_checking in GNAT

[marxin]

gcc/ada/ChangeLog:

2016-02-24  Martin Liska  

* gcc-interface/utils.c (set_reverse_storage_order_on_pad_type):
Replace ENABLE_CHECKING macro with flag_checking.
---
 gcc/ada/gcc-interface/utils.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/gcc/ada/gcc-interface/utils.c b/gcc/ada/gcc-interface/utils.c
index ff21e7b..4f81f1d 100644
--- a/gcc/ada/gcc-interface/utils.c
+++ b/gcc/ada/gcc-interface/utils.c
@@ -1486,11 +1486,13 @@ set_reverse_storage_order_on_pad_type (tree type)
 {
   tree field, canonical_pad_type;
 
-#ifdef ENABLE_CHECKING
-  /* If the inner type is not scalar then the function does nothing.  */
-  tree inner_type = TREE_TYPE (TYPE_FIELDS (type));
-  gcc_assert (!AGGREGATE_TYPE_P (inner_type) && !VECTOR_TYPE_P (inner_type));
-#endif
+  if (flag_checking)
+{
+  /* If the inner type is not scalar then the function does nothing.  */
+  tree inner_type = TREE_TYPE (TYPE_FIELDS (type));
+  gcc_assert (!AGGREGATE_TYPE_P (inner_type)
+ && !VECTOR_TYPE_P (inner_type));
+}
 
   /* This is required for the canonicalization.  */
   gcc_assert (TREE_CONSTANT (TYPE_SIZE (type)));
-- 
2.7.0

[Bug fortran/54687] Use gcc option machinery for gfortran

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #12 from Manuel López-Ibáñez  ---
(In reply to Dominique d'Humieres from comment #11)
> What is left in this PR before closing it as FIXED?

My understanding is that almost all entries in gfc_option_t are duplicated in
the common machinery (and if not, that would be quite strange and possibly
buggy, or just they are not command-line options, so why they reside in
gfc_option_t?).

My intuition is that almost all the code in gfc_handle_option can be generated
automatically by using the appropriate flags in fortran/lang.opt
(https://gcc.gnu.org/onlinedocs/gccint/Option-properties.html). But that could 
be done incrementally apart from this bug.

There are some things that both the common machinery and Fortran do manually
(PR64334). Factoring out that code (possibly generating it automatically from
the .opt files) would be nice, but not essential (so PR64334 does not actually
block this).

[Bug target/61949] [6 regression] SEGV compiling gcc.dg/pch/import-[12].c

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #23 from Richard Biener  ---
> Well, looks like same analysis as the last time ;)  Sth is broken on solaris -
> please check with gdb how the stack is aligned on function entry.

I've checked stack alignment on entry to md5_finish_ctx and found 8-byte
alignment on Solaris 10, 4-byte alignment on Solaris 11 and 12 (where
the test never failed).

Very strange.  We still have PR target/62281 which claims that 32-bit
Solaris/x86 still only guarantees 4-byte alignment, in accordance with
the 32-bit x86 psABI.  Unfortunately, the submitter never responded to
my questions; I'll have to ask my contacts for details.

Maybe we'll need the Solaris 9-only fix from PR libgomp/60107 on Solaris
10+, too.

Rainer

[Bug sanitizer/69839] cross-compiling programs w/-fsanitize=address fails: ld: warning: libstdc++.so.6, needed by libasan.so, not found (try using -rpath or -rpath-link)

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
(In reply to Joakim Tjernlund from comment #6)
> (In reply to Jakub Jelinek from comment #5)
> > Likely a bug on the Gentoo side.
> > The linker handles differently libraries specified on the command line and
> > libraries that are needed by those shared libraries, but are not mentioned
> > on the command line.  See binutils documentation.
> 
> Digging into this I noticed ld searches $sysroot/etc/ld.so.conf so
> I tried adding /usr/lib/gcc/powerpc-g2.20-linux-gnu/4.9.3/, like so:
> # ld.so.conf autogenerated by env-update; make all changes to
> # contents of /etc/env.d directory
> /usr/powerpc-g2.20-linux-gnu/lib
> /usr/lib/gcc/powerpc-g2.20-linux-gnu/4.9.3/
> 
> However I see using strace that ld tries to open:
> "/usr/powerpc-g2.20-linux-gnu/usr/lib/gcc/powerpc-g2.20-linux-gnu/4.9.3/
> libstdc++.so.6
> 
> That is, ld prefixes every path in ld.so.conf with $sysroot.
> Is that correct or a bug in binutils?

That is correct.

Re: [C++ PATCH] Fix option handling when -std=gnu++14 is not used (PR 69865)

[Jakub Jelinek]

On Sat, Feb 20, 2016 at 06:38:05AM +, Bernd Edlinger wrote:
> Hi,
> 
> as almost expected r233572 needs to be back-ported to gcc-5 and gcc-4.9
> branches in order to be built by gcc-6.  It applies cleanly to both
> branches.  But unfortunately PR 69881 prevents boot-strapping gcc-4.9
> in the moment.
> 
> Boot-strap and regression-test of gcc-5 on x86_64-pc-linux-gnu.
> OK for gcc-5 and gcc-4.9 when PR 69881 is resolved?

Ok for 5/4.9.

> 2016-02-20  Bernd Edlinger  
> 
>   Backported from mainline
>   2016-02-19  Jakub Jelinek  
>   Bernd Edlinger  
> 
>   * Make-lang.in: Invoke gperf with -L C++.
>   * cfns.gperf: Remove prototypes for hash and libc_name_p
>   inlines.
>   * cfns.h: Regenerated.
>   * except.c (nothrow_libfn_p): Adjust.

Jakub

[Bug sanitizer/69839] cross-compiling programs w/-fsanitize=address fails: ld: warning: libstdc++.so.6, needed by libasan.so, not found (try using -rpath or -rpath-link)

[joakim.tjernlund at infinera dot com]

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

--- Comment #6 from Joakim Tjernlund  ---
(In reply to Jakub Jelinek from comment #5)
> Likely a bug on the Gentoo side.
> The linker handles differently libraries specified on the command line and
> libraries that are needed by those shared libraries, but are not mentioned
> on the command line.  See binutils documentation.

Digging into this I noticed ld searches $sysroot/etc/ld.so.conf so
I tried adding /usr/lib/gcc/powerpc-g2.20-linux-gnu/4.9.3/, like so:
# ld.so.conf autogenerated by env-update; make all changes to
# contents of /etc/env.d directory
/usr/powerpc-g2.20-linux-gnu/lib
/usr/lib/gcc/powerpc-g2.20-linux-gnu/4.9.3/

However I see using strace that ld tries to open:
"/usr/powerpc-g2.20-linux-gnu/usr/lib/gcc/powerpc-g2.20-linux-gnu/4.9.3/libstdc++.so.6

That is, ld prefixes every path in ld.so.conf with $sysroot.
Is that correct or a bug in binutils?

[Bug c++/69958] sizeof... computes wrong size

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Trunk also fails the two static assertions, clang++ 3.8 accepts it.

[Bug c++/69959] [6 Regression] gcc-6 doesn't build gcc-5 anymore

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #2 from Bernd Edlinger  ---
(In reply to Jakub Jelinek from comment #1)
> We want r233572 on the branches that use C++ compiler (or you need to
> bootstrap older compilers with g++ -std=gnu++98).

yes. I asked for permission here:
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01409.html

should I ping for it?

[Bug c++/69842] [6 Regression] Parameter deduction in polymorphic lambdas

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Jason Merrill  ---
Fixed more.  :)