Re: [GSoC] generation of Gimple code from isl_ast_node_if

[Tobias Grosser]

On 27/07/2014 08:12, Roman Gareev wrote:

Can you explain why you believe it is hard/impossible to generate a test
case without reduction?


I don't believe this. I only know that all the test cases considered
by me have the same problem.

Could you please explain what is 'reduction'? I've found out that,
according to the comment of the rewrite_reductions_out_of_ssa (this
function duplicates pbbs), the rewrite_reductions_out_of_ssa  rewrite
out of SSA all the reduction phi nodes of SCOP. What are reduction phi
nodes? How are they related to 'reduction'?


A reduction is an operation that combines a set of elements into a 
single element.


for (i = 0; i < 100; i++)
   sum += i;

combines the different elements 'i' into the single element 'sum'. 
Reductions where the combine operation *here '+') is associative and 
commutative can be reordered. This means you can e.g. write the loop as


for (i = 99; i >= 0; i--)
   sum += i;

and you get the same result. There are two ways to ensure something is 
not optimized as a reduction


1) Destroy associativity/commutativity

Floating point operations are generally not associative/commutative, 
except if -ffast-math is given to the compiler


2) Do not reduce into one element.

If we just assign to different elements of an array, there is no 
possibility we have a reduction.


Let's get back to the earlier test case:

for (i = 0; i < n; i++) {
   if (i <= m)
T: A[i] = i;

S: A[i + p] = j;
}

What is the ast generated for this one? I just created this input file 
for isl_codegen:


[n,m] -> {S[i] -> [i]: 0<= i <= n;T[i] -> [i]: 0<= i <= m and i <= n}
[n,m] -> {:n,m > 1}
{}

$ isl_codegen < input.file

for (int c0 = 0; c0 <= n; c0 += 1) {
  if (m >= c0)
T(c0);
  S(c0);
}

Is something in graphite preventing us to generate this simple loop with 
just one if-condition and no statement duplication?


Cheers,
Tobias

[Patch] PR 61692 - Fix for inline asm ICE

[David Wohlferd]

I'm not sure which maintainer to cc for inline asm stuff?

I have a release on file with the FSF, but don't have SVN write access.

Problem:
extract_insn() in recog.c will ICE if (noperands > MAX_RECOG_OPERANDS).  
Normally this isn't a problem since expand_asm_operands() in cfgexpand.c 
catches and reports a proper error for this condition.  However, 
expand_asm_operands() only checks (ninputs + noutputs) instead of 
(ninputs + noutputs + nlabels), so you can get the ICE when using "asm 
goto."  See the bugzilla entry for sample code.


ChangeLog:
2014-07-27  David Wohlferd  

PR target/61692
* cfgexpand.c (expand_asm_operands): Count all inline asm 
parameters.


dw
Index: cfgexpand.c
===
--- cfgexpand.c	(revision 212900)
+++ cfgexpand.c	(working copy)
@@ -2554,7 +2554,7 @@
 }
 
   ninputs += ninout;
-  if (ninputs + noutputs > MAX_RECOG_OPERANDS)
+  if (ninputs + noutputs + nlabels > MAX_RECOG_OPERANDS)
 {
   error ("more than %d operands in %", MAX_RECOG_OPERANDS);
   return;

Re: [PATCH, rs6000, 4.8/4.9] Fix alignment of non-Altivec vector struct fields

[Alan Modra]

On Sat, Jul 26, 2014 at 01:45:12PM +0200, Matthias Klose wrote:
> Am 17.07.2014 02:41, schrieb Ulrich Weigand:
> > Hello,
> > 
> > this is the variant intended for the 4.8/4.9 branches of the patch:
> > https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01072.html
> > 
> > As discussed, it does *not* actually change ABI, but only warn when
> > encountering a situation where the ABI will change in a future GCC.
> > (Avoiding the specific term "GCC 4.10" here since I'm not certain
> > whether the next GCC release will in fact be called that ...)
> > 
> > Tested on powerpc64-linux and powerpc64le-linux; also verified using
> > the ABI compat suite (against an unpatched GCC) that this patch does
> > not change the ABI.
> 
> this causes PR libobjc/61920, link failures with -lobjc.

Try this.

Index: libobjc/encoding.c
===
--- libobjc/encoding.c  (revision 213090)
+++ libobjc/encoding.c  (working copy)
@@ -192,6 +192,7 @@
? MAX (MAX (COMPUTED, SPECIFIED), 64)   \
: MAX (COMPUTED, SPECIFIED));})
 
+#define rs6000_special_adjust_field_align_p false
 
 /* Skip a variable name, enclosed in quotes (").  */
 static inline

-- 
Alan Modra
Australia Development Lab, IBM

[MIPS, committed] Reverse argument order in const-anchor tests

[Richard Sandiford]

gcc.target/mips/const-anchor-[12].c started failing after:

2014-04-29  James Greenhalgh  

* calls.c (initialize_argument_information): Always treat
PUSH_ARGS_REVERSED as 1, simplify code accordingly.
(expand_call): Likewise.
(emit_library_call_calue_1): Likewise.
* expr.c (PUSH_ARGS_REVERSED): Do not define.
(emit_push_insn): Always treat PUSH_ARGS_REVERSED as 1, simplify
code accordingly.

because we now evaluate the arguments in reverse order and because the
way that the const-anchor optimisation is written is (knowingly, I think)
sensitive to instruction order.

I've filed enhancement PR61926 for a version that could cope with both
orders.  In the meantime, and in order to make sure that the optimisation
is still tested, I've committed the patch below to reverse the arguments.
I've added the old order as new XFAILed tests, linked to the PR.

Tested on mips64-linux-gnu and applied.

Thanks,
Richard


gcc/testsuite/
PR rtl-optimization/61926
* gcc.target/mips/const-anchor-1.c, gcc.target/mips/const-anchor-2.c:
Reverse argument order.
* gcc.target/mips/const-anchor-3.c, gcc.target/mips/const-anchor-4.c:
New XFAILed tests that match the original order.

Index: gcc/testsuite/gcc.target/mips/const-anchor-1.c
===
--- gcc/testsuite/gcc.target/mips/const-anchor-1.c  2014-07-27 
10:28:49.047970043 +0100
+++ gcc/testsuite/gcc.target/mips/const-anchor-1.c  2014-07-27 
10:37:18.023945982 +0100
@@ -2,9 +2,9 @@
(0x1234000) used to build another constant.  */
 /* { dg-skip-if "code quality test" { *-*-* } { "-O0" } { "" } } */
 /* { dg-final { scan-assembler-not "0x1233|305332224" } } */
-/* { dg-final { scan-assembler "\td?addiu\t\\\$5,\\\$\[0-9\]*,-1" } } */
+/* { dg-final { scan-assembler "\td?addiu\t\\\$4,\\\$\[0-9\]*,-1" } } */
 
 NOMIPS16 void f ()
 {
-  g (0x12340001, 0x1233);
+  g (0x1233, 0x12340001);
 }
Index: gcc/testsuite/gcc.target/mips/const-anchor-2.c
===
--- gcc/testsuite/gcc.target/mips/const-anchor-2.c  2014-07-27 
10:28:49.047970043 +0100
+++ gcc/testsuite/gcc.target/mips/const-anchor-2.c  2014-07-27 
10:37:18.024945992 +0100
@@ -1,9 +1,9 @@
 /* Derive a constant (0x30001) from another constant.  */
 /* { dg-skip-if "code quality test" { *-*-* } { "-O0" } { "" } } */
 /* { dg-final { scan-assembler-not "0x30|196608" } } */
-/* { dg-final { scan-assembler "\td?addiu\t\\\$5,\\\$\[0-9\]*,32763" } } */
+/* { dg-final { scan-assembler "\td?addiu\t\\\$4,\\\$\[0-9\]*,32763" } } */
 
 NOMIPS16 void f ()
 {
-  g (0x28006, 0x30001);
+  g (0x30001, 0x28006);
 }
Index: gcc/testsuite/gcc.target/mips/const-anchor-3.c
===
--- /dev/null   2014-07-15 07:39:28.965430757 +0100
+++ gcc/testsuite/gcc.target/mips/const-anchor-3.c  2014-07-27 
10:44:18.927185095 +0100
@@ -0,0 +1,11 @@
+/* Derive a constant (0x1233) from an intermediate value
+   (0x1234000) used to build another constant.  */
+/* { dg-skip-if "code quality test" { *-*-* } { "-O0" } { "" } } */
+/* See PR61926 for the XFAILs.  */
+/* { dg-final { scan-assembler-not "0x1233|305332224" { xfail *-*-* } } } 
*/
+/* { dg-final { scan-assembler "\td?addiu\t\\\$5,\\\$\[0-9\]*,-1" { xfail 
*-*-* } } } */
+
+NOMIPS16 void f ()
+{
+  g (0x12340001, 0x1233);
+}
Index: gcc/testsuite/gcc.target/mips/const-anchor-4.c
===
--- /dev/null   2014-07-15 07:39:28.965430757 +0100
+++ gcc/testsuite/gcc.target/mips/const-anchor-4.c  2014-07-27 
10:44:23.721233442 +0100
@@ -0,0 +1,10 @@
+/* Derive a constant (0x30001) from another constant.  */
+/* { dg-skip-if "code quality test" { *-*-* } { "-O0" } { "" } } */
+/* See PR61926 for the XFAILs.  */
+/* { dg-final { scan-assembler-not "0x30|196608" { xfail *-*-* } } } */
+/* { dg-final { scan-assembler "\td?addiu\t\\\$5,\\\$\[0-9\]*,32763" { xfail 
*-*-* }  } } */
+
+NOMIPS16 void f ()
+{
+  g (0x28006, 0x30001);
+}

Re: [GSoC] generation of Gimple code from isl_ast_node_if

[Roman Gareev]

Thank you! I've attached patches with a test case (it is located in
patch1.txt), which generates the following ISL AST:

for (int c1 = 0; c1 <= 49; c1 += 1) {
  if (c1 <= 24)
S_4(c1);
  S_5(c1);
}

I think that it doesn't contain reduction and doesn't yield several
bbs. I've also checked that pbbs correspond to pbbs of pbb->domain and
pbb->transformed.

--
   Cheers, Roman Gareev.
2014-07-23  Roman Gareev  

[gcc/]

* graphite-isl-ast-to-gimple.c:
(graphite_create_new_guard): New function.
(translate_isl_ast_node_if): New function.
(translate_isl_ast): Add calling of translate_isl_ast_node_if.

[gcc/testsuite]

* gcc.dg/graphite/isl-ast-gen-if-1.c: New testcase.
2014-07-23  Roman Gareev  

[gcc/]

* graphite-sese-to-poly.c:
(new_pbb_from_pbb): Set a new id of pbb1->domain (instead of using the
id of the pbb), which contains pointer to the pbb1.

[gcc/testsuite]

* gcc.dg/graphite/isl-ast-gen-if-2.c: New testcase.
Index: gcc/graphite-isl-ast-to-gimple.c
===
--- gcc/graphite-isl-ast-to-gimple.c(revision 212995)
+++ gcc/graphite-isl-ast-to-gimple.c(working copy)
@@ -646,6 +646,43 @@
   return next_e;
 }
 
+/* Creates a new if region corresponding to ISL's cond.  */
+
+static edge
+graphite_create_new_guard (edge entry_edge, __isl_take isl_ast_expr *if_cond,
+  ivs_params &ip)
+{
+  tree type =
+build_nonstandard_integer_type (graphite_expression_type_precision, 0);
+  tree cond_expr = gcc_expression_from_isl_expression (type, if_cond, ip);
+  edge exit_edge = create_empty_if_region_on_edge (entry_edge, cond_expr);
+  return exit_edge;
+}
+
+/* Translates an isl_ast_node_if to Gimple.  */
+
+static edge
+translate_isl_ast_node_if (loop_p context_loop,
+  __isl_keep isl_ast_node *node,
+  edge next_e, ivs_params &ip)
+{
+  gcc_assert (isl_ast_node_get_type (node) == isl_ast_node_if);
+  isl_ast_expr *if_cond = isl_ast_node_if_get_cond (node);
+  edge last_e = graphite_create_new_guard (next_e, if_cond, ip);
+
+  edge true_e = get_true_edge_from_guard_bb (next_e->dest);
+  isl_ast_node *then_node = isl_ast_node_if_get_then (node);
+  translate_isl_ast (context_loop, then_node, true_e, ip);
+  isl_ast_node_free (then_node);
+
+  edge false_e = get_false_edge_from_guard_bb (next_e->dest);
+  isl_ast_node *else_node = isl_ast_node_if_get_else (node);
+  if (isl_ast_node_get_type (else_node) != isl_ast_node_error)
+translate_isl_ast (context_loop, else_node, false_e, ip);
+  isl_ast_node_free (else_node);
+  return last_e;
+}
+
 /* Translates an ISL AST node NODE to GCC representation in the
context of a SESE.  */
 
@@ -663,7 +700,8 @@
 next_e, ip);
 
 case isl_ast_node_if:
-  return next_e;
+  return translate_isl_ast_node_if (context_loop, node,
+   next_e, ip);
 
 case isl_ast_node_user:
   return translate_isl_ast_node_user (node, next_e, ip);
Index: gcc/testsuite/gcc.dg/graphite/isl-ast-gen-if-1.c
===
--- gcc/testsuite/gcc.dg/graphite/isl-ast-gen-if-1.c(revision 0)
+++ gcc/testsuite/gcc.dg/graphite/isl-ast-gen-if-1.c(working copy)
@@ -0,0 +1,37 @@
+/* { dg-do run } */
+/* { dg-options "-O2 -fgraphite-identity -fgraphite-code-generator=isl" } */
+
+int st = 1;
+static void __attribute__((noinline))
+foo (int a[], int n)
+{
+  int i;
+  for (i = 0; i < n; i++)
+{
+  if (i < 25)
+a[i] = i;
+  a[n - i] = 1;
+}
+}
+
+static int __attribute__((noinline))
+array_sum (int a[])
+{
+  int i, res = 0;
+  for(i = 0; i < 50; i += st)
+res += a[i];
+  return res;
+}
+
+extern void abort ();
+
+int
+main (void)
+{
+  int a[50];
+  foo (a, 50);
+  int res = array_sum (a);
+  if (res != 49)
+abort ();
+  return 0;
+}
Index: gcc/graphite-sese-to-poly.c
===
--- gcc/graphite-sese-to-poly.c (revision 212995)
+++ gcc/graphite-sese-to-poly.c (working copy)
@@ -2044,7 +2044,8 @@
   break;
 
   pbb1->domain = isl_set_copy (pbb->domain);
-
+  pbb1->domain = isl_set_set_tuple_id (pbb1->domain,
+  isl_id_for_pbb (scop, pbb1));
   GBB_PBB (gbb1) = pbb1;
   GBB_CONDITIONS (gbb1) = GBB_CONDITIONS (gbb).copy ();
   GBB_CONDITION_CASES (gbb1) = GBB_CONDITION_CASES (gbb).copy ();
Index: gcc/testsuite/gcc.dg/graphite/isl-ast-gen-if-2.c
===
--- gcc/testsuite/gcc.dg/graphite/isl-ast-gen-if-2.c(revision 0)
+++ gcc/testsuite/gcc.dg/graphite/isl-ast-gen-if-2.c(working copy)
@@ -0,0 +1,31 @@
+/* { dg-do run } */
+/* { dg-options "-O2 -fgraphite-identity -fgraphite-code-generator=isl" } */
+
+/* This test case tests 

Re: [GSoC] generation of Gimple code from isl_ast_node_if

[Tobias Grosser]

On 27/07/2014 12:48, Roman Gareev wrote:

Thank you! I've attached patches with a test case (it is located in
patch1.txt), which generates the following ISL AST:

for (int c1 = 0; c1 <= 49; c1 += 1) {
   if (c1 <= 24)
 S_4(c1);
   S_5(c1);
}

I think that it doesn't contain reduction and doesn't yield several
bbs. I've also checked that pbbs correspond to pbbs of pbb->domain and
pbb->transformed.


OK. LGTM.

Tobias

[PATCH] Fix ICE with -Wodr (PR middle-end/61913)

[Marek Polacek]

Wodr in common.opt was missing a Var, which means:
1) we ICE with -Wodr, since -Wodr isn't handled in opts.c;
2) -Wno-odr wouldn't work.
Thus fixed.  I'd think this doesn't need a testcase...

Bootstrapped/regtested on x86_64-linux, ok for trunk?

2014-07-27  Marek Polacek  

PR middle-end/61913
* common.opt (Wodr): Add Var.

diff --git gcc/common.opt gcc/common.opt
index a385ee0..3b04044 100644
--- gcc/common.opt
+++ gcc/common.opt
@@ -588,7 +588,7 @@ Wmissing-noreturn
 Common Alias(Wsuggest-attribute=noreturn)
 
 Wodr
-Common Warning
+Common Var(warn_odr_violations) Warning
 Warn about some C++ One Definition Rule violations during link time 
optimization
 
 Woverflow

Marek

Re: update address taken: don't drop clobbers

[Marc Glisse]

On Thu, 10 Jul 2014, Richard Biener wrote:


--- gcc/tree-into-ssa.c (revision 212109)
+++ gcc/tree-into-ssa.c (working copy)
@@ -1831,26 +1831,38 @@ maybe_register_def (def_operand_p def_p,
 {
   tree def = DEF_FROM_PTR (def_p);
   tree sym = DECL_P (def) ? def : SSA_NAME_VAR (def);

   /* If DEF is a naked symbol that needs renaming, create a new
  name for it.  */
   if (marked_for_renaming (sym))
 {
   if (DECL_P (def))
{
- tree tracked_var;
-
- def = make_ssa_name (def, stmt);
+ if (gimple_clobber_p (stmt) && is_gimple_reg (sym))


sym should always be a gimple reg here (it's marked for renaming).


Not quite. If I remove the is_gimple_reg check, I get:

/data/repos/gcc/sra/libgcc/libgcc2.c: In function '__divti3':
/data/repos/gcc/sra/libgcc/libgcc2.c:1246:1: error: non-trivial conversion at 
assignment
 }
 ^
const union DWunion
void
# .MEM_149 = VDEF <.MEM_148>
nn ={v} .MEM_7(D);



+   {
+ /* Replace clobber stmts with a default def.  Create a new
+variable so we don't later think we must coalesce, which
would
+fail with some ada abnormal PHIs.  Still, we try to keep a
+similar name so error messages make sense.  */
+ unlink_stmt_vdef (stmt);


I think that's redundant with gsi_replace (note that using gsi_replace
looks dangerous here as it calls update_stmt during SSA rewrite...
that might open a can of worms).


+ gsi_replace (&gsi, gimple_build_nop (), true);
+ tree id = DECL_NAME (sym);
+ const char* name = id ? IDENTIFIER_POINTER (id) : 0;
+ tree newvar = create_tmp_var (TREE_TYPE (sym), name);
+ def = get_or_create_ssa_default_def (cfun, newvar);


So - can't you simply do

   gimple_assign_set_rhs_from_tree (&gsi,
get_or_create_dda_default_def (cfun, sym));

?  Thus replace x = CLOBBER; with x_3 = x_2(D);


If I write just that, I get a failure because of a missing USE. I need to 
run update_stmt (but then you are saying it is dangerous...).


And it also fails to warn for the C++ testcase because SRA sets 
nowarning_flag (it doesn't if I create a new variable), but I guess we can 
see about changing that next.


--
Marc Glisse

Re: [PATCH, rs6000, 4.8/4.9] Fix alignment of non-Altivec vector struct fields

[Alan Modra]

On Sun, Jul 27, 2014 at 07:16:07PM +0930, Alan Modra wrote:
> On Sat, Jul 26, 2014 at 01:45:12PM +0200, Matthias Klose wrote:
> > Am 17.07.2014 02:41, schrieb Ulrich Weigand:
> > > Hello,
> > > 
> > > this is the variant intended for the 4.8/4.9 branches of the patch:
> > > https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01072.html
> > > 
> > > As discussed, it does *not* actually change ABI, but only warn when
> > > encountering a situation where the ABI will change in a future GCC.
> > > (Avoiding the specific term "GCC 4.10" here since I'm not certain
> > > whether the next GCC release will in fact be called that ...)
> > > 
> > > Tested on powerpc64-linux and powerpc64le-linux; also verified using
> > > the ABI compat suite (against an unpatched GCC) that this patch does
> > > not change the ABI.
> > 
> > this causes PR libobjc/61920, link failures with -lobjc.
> 
> Try this.
> 
> Index: libobjc/encoding.c
> ===
> --- libobjc/encoding.c(revision 213090)
> +++ libobjc/encoding.c(working copy)
> @@ -192,6 +192,7 @@
> ? MAX (MAX (COMPUTED, SPECIFIED), 64) \
> : MAX (COMPUTED, SPECIFIED));})
>  
> +#define rs6000_special_adjust_field_align_p false
>  
>  /* Skip a variable name, enclosed in quotes (").  */
>  static inline

Blah, that won't work of course.  The macro needs to take two
parameters.

#define rs6000_special_adjust_field_align_p(FIELD, COMPUTED) false

-- 
Alan Modra
Australia Development Lab, IBM

Re: [PATCH, rs6000, 4.8/4.9] Fix alignment of non-Altivec vector struct fields

[pinskia]

> On Jul 27, 2014, at 4:53 AM, Alan Modra  wrote:
> 
>> On Sun, Jul 27, 2014 at 07:16:07PM +0930, Alan Modra wrote:
>>> On Sat, Jul 26, 2014 at 01:45:12PM +0200, Matthias Klose wrote:
>>> Am 17.07.2014 02:41, schrieb Ulrich Weigand:
 Hello,
 
 this is the variant intended for the 4.8/4.9 branches of the patch:
 https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01072.html
 
 As discussed, it does *not* actually change ABI, but only warn when
 encountering a situation where the ABI will change in a future GCC.
 (Avoiding the specific term "GCC 4.10" here since I'm not certain
 whether the next GCC release will in fact be called that ...)
 
 Tested on powerpc64-linux and powerpc64le-linux; also verified using
 the ABI compat suite (against an unpatched GCC) that this patch does
 not change the ABI.
>>> 
>>> this causes PR libobjc/61920, link failures with -lobjc.
>> 
>> Try this.
>> 
>> Index: libobjc/encoding.c
>> ===
>> --- libobjc/encoding.c(revision 213090)
>> +++ libobjc/encoding.c(working copy)
>> @@ -192,6 +192,7 @@
>>? MAX (MAX (COMPUTED, SPECIFIED), 64)\
>>: MAX (COMPUTED, SPECIFIED));})
>> 
>> +#define rs6000_special_adjust_field_align_p false
>> 
>> /* Skip a variable name, enclosed in quotes (").  */
>> static inline
> 
> Blah, that won't work of course.  The macro needs to take two
> parameters.
> 
> #define rs6000_special_adjust_field_align_p(FIELD, COMPUTED) false

This is pre-approved if it works.  I really should finish off the branch I 
started years ago :). 

Thanks,
Andrew

> 
> -- 
> Alan Modra
> Australia Development Lab, IBM

[PATH wwwdocs] Mention avx-512vlbwdq branch in svn.html

[Kirill Yukhin]

Hello,
Patch below introduces mention of avx-512vlbwdq SVN
branch in htdocs/svn.html

Same prefix for e-mail (w/ avx-512) put intentionally.

Is it ok to install?

--
Thanks, K

===
RCS file: /cvs/gcc/wwwdocs/htdocs/svn.html,v
retrieving revision 1.198
diff -p -r1.198 svn.html
*** htdocs/svn.html 21 Jun 2014 19:01:11 -  1.198
--- htdocs/svn.html 27 Jul 2014 12:25:46 -
*** the command svn log --stop-on-copy
*** 364,369 
--- 364,377 
  Architecture-specific
  
  
+   avx-512vlbwdq
+   The goal of this branch is to implement Intel AVX-512{VL,BW,DQ}
+   Programming Reference
+   (https://software.intel.com/sites/default/files/managed/c6/a9/319433-020.pdf";>link).
+   The branch is maintained by Yukhin Kirill kirill.yuk...@intel.com>.
+   Patches should be marked with the tag [AVX512] in the subject
+   line.
  
avx512
The goal of this branch is to implement Intel AVX-512 and SHA

[PATCH i386 AVX512] [1/n] Introduce `-mavx512dq' switch

[Kirill Yukhin]

Hello,
With this patch we'd like to start merge process of avx-512vlbwdq
branch into main trunk.

This patch introduces new switch `-mavx512dq'

Bootstrapped.

Is it ok for trunk?

* common/config/i386/i386-common.c
(OPTION_MASK_ISA_AVX512DQ_SET): Define.
(OPTION_MASK_ISA_AVX512DQ_UNSET): Ditto.
(ix86_handle_option): Handle OPT_mavx512dq.
* config/i386/cpuid.h (bit_AVX512DQ): Define.
* config/i386/driver-i386.c (host_detect_local_cpu): Detect avx512dq,
set -mavx512dq accordingly.
* config/i386/i386-c.c (ix86_target_macros_internal): Handle
OPTION_MASK_ISA_AVX512DQ.
* config/i386/i386.c (ix86_target_string): Handle -mavx512dq.
(ix86_option_override_internal): Define PTA_AVX512DQ, handle
PTA_AVX512DQ and OPTION_MASK_ISA_AVX512DQ.
(ix86_valid_target_attribute_inner_p): Handle OPT_mavx512dq.
* config/i386/i386.h (TARGET_AVX512DQ): Define.
(TARGET_AVX512DQ_P(x)): Ditto.
* config/i386/i386.opt: Add mavx512dq.

--
Thanks, K

diff --git a/gcc/common/config/i386/i386-common.c 
b/gcc/common/config/i386/i386-common.c
index 3012783..3db1535 100644
--- a/gcc/common/config/i386/i386-common.c
+++ b/gcc/common/config/i386/i386-common.c
@@ -65,6 +65,8 @@ along with GCC; see the file COPYING3.  If not see
   (OPTION_MASK_ISA_AVX512PF | OPTION_MASK_ISA_AVX512F_SET)
 #define OPTION_MASK_ISA_AVX512ER_SET \
   (OPTION_MASK_ISA_AVX512ER | OPTION_MASK_ISA_AVX512F_SET)
+#define OPTION_MASK_ISA_AVX512DQ_SET \
+  (OPTION_MASK_ISA_AVX512DQ | OPTION_MASK_ISA_AVX512F_SET)
 #define OPTION_MASK_ISA_RTM_SET OPTION_MASK_ISA_RTM
 #define OPTION_MASK_ISA_PRFCHW_SET OPTION_MASK_ISA_PRFCHW
 #define OPTION_MASK_ISA_RDSEED_SET OPTION_MASK_ISA_RDSEED
@@ -156,6 +158,7 @@ along with GCC; see the file COPYING3.  If not see
 #define OPTION_MASK_ISA_AVX512CD_UNSET OPTION_MASK_ISA_AVX512CD
 #define OPTION_MASK_ISA_AVX512PF_UNSET OPTION_MASK_ISA_AVX512PF
 #define OPTION_MASK_ISA_AVX512ER_UNSET OPTION_MASK_ISA_AVX512ER
+#define OPTION_MASK_ISA_AVX512DQ_UNSET OPTION_MASK_ISA_AVX512DQ
 #define OPTION_MASK_ISA_RTM_UNSET OPTION_MASK_ISA_RTM
 #define OPTION_MASK_ISA_PRFCHW_UNSET OPTION_MASK_ISA_PRFCHW
 #define OPTION_MASK_ISA_RDSEED_UNSET OPTION_MASK_ISA_RDSEED
@@ -393,6 +396,19 @@ ix86_handle_option (struct gcc_options *opts,
}
   return true;
 
+case OPT_mavx512dq:
+  if (value)
+   {
+ opts->x_ix86_isa_flags |= OPTION_MASK_ISA_AVX512DQ_SET;
+ opts->x_ix86_isa_flags_explicit |= OPTION_MASK_ISA_AVX512DQ_SET;
+   }
+  else
+   {
+ opts->x_ix86_isa_flags &= ~OPTION_MASK_ISA_AVX512DQ_UNSET;
+ opts->x_ix86_isa_flags_explicit |= OPTION_MASK_ISA_AVX512DQ_UNSET;
+   }
+  return true;
+
 case OPT_mfma:
   if (value)
{
diff --git a/gcc/config/i386/cpuid.h b/gcc/config/i386/cpuid.h
index 7ac22a1..dc65053 100644
--- a/gcc/config/i386/cpuid.h
+++ b/gcc/config/i386/cpuid.h
@@ -73,6 +73,7 @@
 #define bit_BMI2   (1 << 8)
 #define bit_RTM(1 << 11)
 #define bit_AVX512F(1 << 16)
+#define bit_AVX512DQ   (1 << 17)
 #define bit_RDSEED (1 << 18)
 #define bit_ADX(1 << 19)
 #define bit_CLFLUSHOPT (1 << 23)
diff --git a/gcc/config/i386/driver-i386.c b/gcc/config/i386/driver-i386.c
index 4cd0b3d..8ff49ac 100644
--- a/gcc/config/i386/driver-i386.c
+++ b/gcc/config/i386/driver-i386.c
@@ -411,6 +411,7 @@ const char *host_detect_local_cpu (int argc, const char 
**argv)
   unsigned int has_avx512er = 0, has_avx512pf = 0, has_avx512cd = 0;
   unsigned int has_avx512f = 0, has_sha = 0, has_prefetchwt1 = 0;
   unsigned int has_clflushopt = 0, has_xsavec = 0, has_xsaves = 0;
+  unsigned int has_avx512dq = 0;
 
   bool arch;
 
@@ -488,6 +489,7 @@ const char *host_detect_local_cpu (int argc, const char 
**argv)
   has_avx512cd = ebx & bit_AVX512CD;
   has_sha = ebx & bit_SHA;
   has_clflushopt = ebx & bit_CLFLUSHOPT;
+  has_avx512dq = ebx & bit_AVX512DQ;
 
   has_prefetchwt1 = ecx & bit_PREFETCHWT1;
 }
@@ -900,6 +902,7 @@ const char *host_detect_local_cpu (int argc, const char 
**argv)
   const char *clflushopt = has_clflushopt ? " -mclflushopt" : " 
-mno-clflushopt";
   const char *xsavec = has_xsavec ? " -mxsavec" : " -mno-xsavec";
   const char *xsaves = has_xsaves ? " -mxsaves" : " -mno-xsaves";
+  const char *avx512dq = has_avx512dq ? " -mavx512dq" : " -mno-avx512dq";
 
   options = concat (options, mmx, mmx3dnow, sse, sse2, sse3, ssse3,
sse4a, cx16, sahf, movbe, aes, sha, pclmul,
@@ -908,7 +911,7 @@ const char *host_detect_local_cpu (int argc, const char 
**argv)
hle, rdrnd, f16c, fsgsbase, rdseed, prfchw, adx,
fxsr, xsave, xsaveopt, avx512f, avx512er,
avx512cd, avx512pf, prefetchwt1, clflushopt,
-   xsavec, xsaves, NULL);
+   xsavec, xsaves, avx512dq, NULL);
 }
 

Re: [PATCH, rs6000, 4.8/4.9] Fix alignment of non-Altivec vector struct fields

[Matthias Klose]

Am 27.07.2014 13:59, schrieb pins...@gmail.com:
> 
> 
>> On Jul 27, 2014, at 4:53 AM, Alan Modra  wrote:
>>
>>> On Sun, Jul 27, 2014 at 07:16:07PM +0930, Alan Modra wrote:
 On Sat, Jul 26, 2014 at 01:45:12PM +0200, Matthias Klose wrote:
 Am 17.07.2014 02:41, schrieb Ulrich Weigand:
> Hello,
>
> this is the variant intended for the 4.8/4.9 branches of the patch:
> https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01072.html
>
> As discussed, it does *not* actually change ABI, but only warn when
> encountering a situation where the ABI will change in a future GCC.
> (Avoiding the specific term "GCC 4.10" here since I'm not certain
> whether the next GCC release will in fact be called that ...)
>
> Tested on powerpc64-linux and powerpc64le-linux; also verified using
> the ABI compat suite (against an unpatched GCC) that this patch does
> not change the ABI.

 this causes PR libobjc/61920, link failures with -lobjc.
>>>
>>> Try this.
>>>
>>> Index: libobjc/encoding.c
>>> ===
>>> --- libobjc/encoding.c(revision 213090)
>>> +++ libobjc/encoding.c(working copy)
>>> @@ -192,6 +192,7 @@
>>>? MAX (MAX (COMPUTED, SPECIFIED), 64)\
>>>: MAX (COMPUTED, SPECIFIED));})
>>>
>>> +#define rs6000_special_adjust_field_align_p false
>>>
>>> /* Skip a variable name, enclosed in quotes (").  */
>>> static inline
>>
>> Blah, that won't work of course.  The macro needs to take two
>> parameters.
>>
>> #define rs6000_special_adjust_field_align_p(FIELD, COMPUTED) false
> 
> This is pre-approved if it works.  I really should finish off the branch I 
> started years ago :). 

#define rs6000_special_adjust_field_align_p(FIELD, COMPUTED) 0

is what succeeds for me. false is not defined for ObjC. Checked in on the trunk
and the branches.

these are still regressions, because the new warnings trigger on these test 
cases:

Running
/home/doko/gcc/gcc-4.9-4.9.1/src/gcc/testsuite/objc.dg/gnu-encoding/gnu-encoding.exp
...
FAIL: objc.dg-struct-layout-encoding-1/t025_main.m execution test
FAIL: objc.dg-struct-layout-encoding-1/t027_main.m execution test
FAIL: objc.dg-struct-layout-encoding-1/t028_main.m execution test
FAIL: objc.dg-struct-layout-encoding-1/t029_main.m execution test
FAIL: objc.dg-struct-layout-encoding-1/t030_main.m execution test
FAIL: objc.dg-struct-layout-encoding-1/t031_main.m execution test

No regressions in the obj-c++ tests.

  Matthias

[Patch, moxie] Add moxiebox target

[Anthony Green]

The following binutils patches introduce a new moxie-based target
called moxiebox.  Moxiebox is a VM developed by the bitcoin community
to act as a secure, sandboxed execution environment for bitcoin
automation.

See http://github.com/jgarzik/moxiebox for more information.

I'm checking these changes in.  There's a config.sub change as well
that I'll submit through the regular process.

Thanks,

AG


For gcc...

2014-07-27  Anthony Green  

* config.gcc: Add moxie-*-moxiebox* configuration.
* config/moxie/moxiebox.h: New file.

For libgcc...

2014-07-27  Anthony Green  

* config.host: Add moxiebox configuration suppport.



Index: gcc/config/moxie/moxiebox.h
===
--- gcc/config/moxie/moxiebox.h (revision 0)
+++ gcc/config/moxie/moxiebox.h (working copy)
@@ -0,0 +1,47 @@
+/* Definitions for the moxiebox.
+   Copyright (C) 2014 Free Software Foundation, Inc.
+   Contributed by Anthony Green (gr...@moxielogic.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
+.  */
+
+/* Target OS preprocessor built-ins.  */
+#define TARGET_OS_CPP_BUILTINS()   \
+  do   \
+{  \
+  builtin_define_std ("moxie");\
+  builtin_define ("__moxiebox__"); \
+  builtin_assert ("system=moxiebox");  \
+}  \
+  while (0)
+
+#undef LIB_SPEC
+#define LIB_SPEC \
+"%{!T*:-Tmoxiebox.ld} \
+ %{!nostdlib: --start-group -lsandboxrt -lc -lgcc --end-group }"
+
+#undef LINK_SPEC
+#define LINK_SPEC "%{h*} %{v:-V} -EL -Bstatic"
+
+#undef  ASM_SPEC
+#define ASM_SPEC "-EL"
+
+#undef MULTILIB_DEFAULTS
+
+#undef SIZE_TYPE
+#undef PTRDIFF_TYPE
+#undef WCHAR_TYPE
+#undef WCHAR_TYPE_SIZE
Index: gcc/config.gcc
===
--- gcc/config.gcc  (revision 212980)
+++ gcc/config.gcc  (working copy)
@@ -1168,6 +1168,12 @@
tmake_file="${tmake_file} moxie/t-moxie"
tm_file="moxie/moxie.h dbxelf.h elfos.h moxie/rtems.h rtems.h 
newlib-stdint.h"
;;
+moxie-*-moxiebox*)
+   gas=yes
+   gnu_ld=yes
+   tm_file="${tm_file} dbxelf.h elfos.h moxie/moxiebox.h newlib-stdint.h"
+   tmake_file="${tmake_file} moxie/t-moxiebox"
+   ;;
 h8300-*-rtems*)
tmake_file="${tmake_file} h8300/t-h8300 h8300/t-rtems"
tm_file="h8300/h8300.h dbxelf.h elfos.h h8300/elf.h h8300/rtems.h 
rtems.h newlib-stdint.h"
Index: libgcc/config.host
===
--- libgcc/config.host  (revision 212980)
+++ libgcc/config.host  (working copy)
@@ -881,9 +881,9 @@
 mn10300-*-*)
tmake_file=t-fdpbit
;;
-moxie-*-elf | moxie-*-uclinux*)
+moxie-*-elf | moxie-*-moxiebox* | moxie-*-uclinux*)
tmake_file="moxie/t-moxie t-softfp-sfdf t-softfp-excl t-softfp"
-   extra_parts="$extra_parts crti.o crtn.o"
+   extra_parts="$extra_parts crti.o crtn.o crtbegin.o crtend.o"
;;
 moxie-*-rtems*)
tmake_file="$tmake_file moxie/t-moxie t-softfp-sfdf t-softfp-excl 
t-softfp"

[Patch, Fortran] Add first coarray ABI documentation to gfortran.texi

[Tobias Burnus]

Dear all,

attached is a first patch to gfortran.texi which add documentation about 
libcaf*.c. The things are still a bit in a flux and it is incomplete 
(atomics, locking, error stop and vector subscripts are still missing), 
but one has to start somewhere …


OK for the trunk?

Comments on the language, the technical description and on the API 
itself are welcome.


Tobias
2014-07-27  Tobias Burnus  

	* gfortran.texi (Coarray Programming): Add first ABI
	documentation.

diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 66e78e8..5f6bf5d 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -184,6 +184,7 @@ Part II: Language Reference
 * Compiler Characteristics::  User-visible implementation details.
 * Extensions::Language extensions implemented by GNU Fortran.
 * Mixed-Language Programming::Interoperability with C
+* Coarray Programming::
 * Intrinsic Procedures:: Intrinsic procedures supported by GNU Fortran.
 * Intrinsic Modules::Intrinsic modules supported by GNU Fortran.
 
@@ -3176,6 +3177,380 @@ of such a type
 @end itemize
 
 
+@c -
+@c Coarray Programming
+@c -
+
+@node Coarray Programming
+@chapter Coarray Programming
+@cindex Coarrays
+
+@menu
+* Type and enum ABI Documentation::
+* Function ABI Documentation::
+@end menu
+
+
+@node Type and enum ABI Documentation
+@section Type and enum ABI Documentation
+
+@menu
+* caf_token_t::
+* caf_register_t::
+@end menu
+
+@node caf_token_t
+@subsection @code{caf_token_t}
+
+Typedef of type @code{void *} on the compiler side. Can be any data
+type on the library side.
+
+@node caf_register_t
+@subsection @code{caf_register_t}
+
+Indicates which kind of coarray variable should be registered.
+
+@verbatim
+typedef enum caf_register_t {
+  CAF_REGTYPE_COARRAY_STATIC,
+  CAF_REGTYPE_COARRAY_ALLOC,
+  CAF_REGTYPE_LOCK_STATIC,
+  CAF_REGTYPE_LOCK_ALLOC
+}
+caf_register_t;
+@end verbatim
+
+
+@node Function ABI Documentation
+@section Function ABI Documentation
+
+@menu
+* _gfortran_caf_init:: Initialiation function
+* _gfortran_caf_finish:: Finalization function
+* _gfortran_caf_this_image:: Querying the image number
+* _gfortran_caf_num_images:: Querying the maximal number of images
+* _gfortran_caf_register:: Registering coarrays
+* _gfortran_caf_deregister:: Deregistering coarrays
+* _gfortran_caf_send:: Sending data from a local image to a remote image
+* _gfortran_caf_get:: Getting data from a remote image
+* _gfortran_caf_sendget:: Sending data between remote images
+@end menu
+
+
+@node _gfortran_caf_init
+@subsection @code{_gfortran_caf_init} --- Initialiation function
+@cindex Coarray, _gfortran_caf_init
+
+@table @asis
+@item @emph{Description}:
+This function is called at startup of the program before the Fortran main
+program, if the latter has been compiled with @option{-fcoarray=lib}.
+It takes as arguments the command-line arguments of the program.  It is
+permitted to pass to @code{NULL} pointers as argument; if non-@code{NULL},
+the library is permitted to modify the arguments.
+
+@item @emph{Syntax}:
+@code{void _gfortran_caf_init (int *argc, char ***argv)}
+
+@item @emph{Arguments}:
+@multitable @columnfractions .15 .70
+@item @var{argc} @tab intent(inout) An integer pointer with the number of
+arguments passed to the program or @code{NULL}.
+@item @var{argv} @tab intent(inout) A pointer to an array of strings with the
+command-line arguments or @code{NULL}.
+@end multitable
+
+@item @emph{NOTES}
+The function is modelled after the initialization function of the Message
+Passing Interface (MPI) specification.  Due to the way coarray registration
+works, it might not be the first call to the libaray.  If the main program is
+not written in Fortran and only a library uses coarrays, it can happen that
+this function is never called.  Therefore, it is recommended that the library
+does not rely on the passed arguments and whether the call has been done.
+@end table
+
+
+@node _gfortran_caf_finish
+@subsection @code{_gfortran_caf_finish} --- Finalization function
+@cindex Coarray, _gfortran_caf_finish
+
+@table @asis
+@item @emph{Description}:
+This function is called at the end of the Fortran main program, if it has
+been compiled with the @option{-fcoarray=lib} option.
+
+@item @emph{Syntax}:
+@code{void _gfortran_caf_finish (void)}
+
+@item @emph{NOTES}
+For non-Fortran programs, it is recommended to call the function at the end
+of the main program.  To ensure that the shutdown is also performed for
+programs where this function is not explicitly invoked, for instance
+non-Fortran programs or calls to the system's exit() function, the library
+can use a destructor function.  Note that programs can also be terminated
+using the STOP and ERROR STOP statements; those use different library calls.
+@end table
+
+
+@node _gfortran_caf_th

Re: Patch for constexpr variable templates

[Adam Butcher]

On 2014-07-26 17:14, Jason Merrill wrote:

On 07/26/2014 12:11 PM, Jason Merrill wrote:

On 07/26/2014 03:04 AM, Braden Obrzut wrote:

On 07/25/2014 05:24 PM, Jason Merrill wrote:


Fair enough, but in that case let's use 'sorry' rather then 
'error' to

be clear that it's a missing feature.


Tests like g++.dg/cpp1y/pr59638.C produce extra failures if this is
changed.  Is there something I'm supposed to do to account for 
that?


Changing dg-error to dg-message should cover it.


Actually, we shouldn't be treating that testcase as declaring
variable templates at all.  Adam, any thoughts?


In the 59638 case, the declarations

  void (*a)(auto);
  void (*b)(auto) = 0;

are shorthand for

  template  void (*a)(T);
  template  void (*b)(T) = 0;

which, unless there's some constraint with variable templates that I'm 
not aware of, ought to define two variable templates 'a' and 'b' to be 
ptr-to-function-taking-T.  So I think it's correct that the variable 
template stuff should be triggering here.


Prefixing the two decls with constexpr does allow them to compile 
(albeit with an "uninitialized const 'a'" permerror in the first case).


The issue with 59638 was that the errors were not correctly unwinding 
the template scope so declarations further down the file were considered 
templates when the weren't.


There may be similar recovery issues with not supporting non-constexpr 
variable templates defined with 'auto' (if that's permitted at all).


Cheers,
Adam

Re: update address taken: don't drop clobbers

[Marc Glisse]

On Thu, 10 Jul 2014, Richard Biener wrote:


--- gcc/tree-into-ssa.c (revision 212109)
+++ gcc/tree-into-ssa.c (working copy)
@@ -1831,26 +1831,38 @@ maybe_register_def (def_operand_p def_p,
 {
   tree def = DEF_FROM_PTR (def_p);
   tree sym = DECL_P (def) ? def : SSA_NAME_VAR (def);

   /* If DEF is a naked symbol that needs renaming, create a new
  name for it.  */
   if (marked_for_renaming (sym))
 {
   if (DECL_P (def))
{
- tree tracked_var;
-
- def = make_ssa_name (def, stmt);
+ if (gimple_clobber_p (stmt) && is_gimple_reg (sym))


sym should always be a gimple reg here (it's marked for renaming).


+   {
+ /* Replace clobber stmts with a default def.  Create a new
+variable so we don't later think we must coalesce, which
would
+fail with some ada abnormal PHIs.  Still, we try to keep a
+similar name so error messages make sense.  */
+ unlink_stmt_vdef (stmt);


I think that's redundant with gsi_replace (note that using gsi_replace
looks dangerous here as it calls update_stmt during SSA rewrite...
that might open a can of worms).


+ gsi_replace (&gsi, gimple_build_nop (), true);
+ tree id = DECL_NAME (sym);
+ const char* name = id ? IDENTIFIER_POINTER (id) : 0;
+ tree newvar = create_tmp_var (TREE_TYPE (sym), name);
+ def = get_or_create_ssa_default_def (cfun, newvar);


So - can't you simply do

   gimple_assign_set_rhs_from_tree (&gsi,
get_or_create_dda_default_def (cfun, sym));

?  Thus replace x = CLOBBER; with x_3 = x_2(D);


+   }
+ else


and of course still rewrite the DEF then.  IMHO the copy-propagation
you do is premature optimization.


Using your version, I end up with spurious warnings, in particular for 
va_list. pass_fold_builtins stops va_start/va_end taking the address of 
the list, so we get:


  list_6 = list_2(D);

in place of the clobber at the end of the function. And there is no 
DCE-like pass afterwards, so we warn for the use of list_2(D).

(passes.def contains a comment about running dce before uninit)

I don't know if update_address_taken could avoid generating this 
assignment where the lhs has 0 use, but this shows the optimization is not 
completely premature.


(uninit could also check for this case, but that feels like a bad hack)

--
Marc Glisse

PR61919: Invalid rtx sharing in tree-outof-ssa.c

[Richard Sandiford]

PR 61919 is another ripple from the patch to take advantage of rtx
sharing rules when instantiating virtual registers.  In this case
the invalid sharing is coming from tree-outof-ssa.c, where the same
MEM rtx is being used in several moves.  (Note that despite the name,
partition_to_pseudo maps to stack slot MEMs as well as pseudos.)

Tested on x86_64-linux-gnu.  Also tested by Andreas on ia64,
where the testsuite regression showed up.  OK to install?

Thanks,
Richard


gcc/
PR middle-end/61919
* tree-outof-ssa.c (insert_partition_copy_on_edge)
(insert_value_copy_on_edge, insert_rtx_to_part_on_edge)
(insert_part_to_rtx_on_edge): Copy partition_to_pseudo rtxes before
inserting them in the insn stream.

Index: gcc/tree-outof-ssa.c
===
--- gcc/tree-outof-ssa.c2014-07-26 21:14:51.074755469 +0100
+++ gcc/tree-outof-ssa.c2014-07-26 21:14:51.590759910 +0100
@@ -260,8 +260,8 @@ insert_partition_copy_on_edge (edge e, i
 set_curr_insn_location (locus);
 
   var = partition_to_var (SA.map, src);
-  seq = emit_partition_copy (SA.partition_to_pseudo[dest],
-SA.partition_to_pseudo[src],
+  seq = emit_partition_copy (copy_rtx (SA.partition_to_pseudo[dest]),
+copy_rtx (SA.partition_to_pseudo[src]),
 TYPE_UNSIGNED (TREE_TYPE (var)),
 var);
 
@@ -274,7 +274,7 @@ insert_partition_copy_on_edge (edge e, i
 static void
 insert_value_copy_on_edge (edge e, int dest, tree src, source_location locus)
 {
-  rtx seq, x;
+  rtx dest_rtx, seq, x;
   enum machine_mode dest_mode, src_mode;
   int unsignedp;
   tree var;
@@ -289,7 +289,8 @@ insert_value_copy_on_edge (edge e, int d
   fprintf (dump_file, "\n");
 }
 
-  gcc_assert (SA.partition_to_pseudo[dest]);
+  dest_rtx = copy_rtx (SA.partition_to_pseudo[dest]);
+  gcc_assert (dest_rtx);
 
   set_location_for_edge (e);
   /* If a locus is provided, override the default.  */
@@ -300,9 +301,9 @@ insert_value_copy_on_edge (edge e, int d
 
   var = SSA_NAME_VAR (partition_to_var (SA.map, dest));
   src_mode = TYPE_MODE (TREE_TYPE (src));
-  dest_mode = GET_MODE (SA.partition_to_pseudo[dest]);
+  dest_mode = GET_MODE (dest_rtx);
   gcc_assert (src_mode == TYPE_MODE (TREE_TYPE (var)));
-  gcc_assert (!REG_P (SA.partition_to_pseudo[dest])
+  gcc_assert (!REG_P (dest_rtx)
  || dest_mode == promote_decl_mode (var, &unsignedp));
 
   if (src_mode != dest_mode)
@@ -312,15 +313,14 @@ insert_value_copy_on_edge (edge e, int d
 }
   else if (src_mode == BLKmode)
 {
-  x = SA.partition_to_pseudo[dest];
+  x = dest_rtx;
   store_expr (src, x, 0, false);
 }
   else
-x = expand_expr (src, SA.partition_to_pseudo[dest],
-dest_mode, EXPAND_NORMAL);
+x = expand_expr (src, dest_rtx, dest_mode, EXPAND_NORMAL);
 
-  if (x != SA.partition_to_pseudo[dest])
-emit_move_insn (SA.partition_to_pseudo[dest], x);
+  if (x != dest_rtx)
+emit_move_insn (dest_rtx, x);
   seq = get_insns ();
   end_sequence ();
 
@@ -356,7 +356,7 @@ insert_rtx_to_part_on_edge (edge e, int
  mems.  Usually we give the source.  As we result from SSA names
  the left and right size should be the same (and no WITH_SIZE_EXPR
  involved), so it doesn't matter.  */
-  seq = emit_partition_copy (SA.partition_to_pseudo[dest],
+  seq = emit_partition_copy (copy_rtx (SA.partition_to_pseudo[dest]),
 src, unsignedsrcp,
 partition_to_var (SA.map, dest));
 
@@ -390,7 +390,7 @@ insert_part_to_rtx_on_edge (edge e, rtx
 
   var = partition_to_var (SA.map, src);
   seq = emit_partition_copy (dest,
-SA.partition_to_pseudo[src],
+copy_rtx (SA.partition_to_pseudo[src]),
 TYPE_UNSIGNED (TREE_TYPE (var)),
 var);
 

Re: Patch for constexpr variable templates

[Andrew Sutton]

> In the 59638 case, the declarations
>
>   void (*a)(auto);
>   void (*b)(auto) = 0;
>
> are shorthand for
>
>   template  void (*a)(T);
>   template  void (*b)(T) = 0;
>
> which, unless there's some constraint with variable templates that I'm not
> aware of, ought to define two variable templates 'a' and 'b' to be
> ptr-to-function-taking-T.  So I think it's correct that the variable
> template stuff should be triggering here.

There isn't, but this interpretation isn't consistent with the use of
auto in variable declarations. For example, this:

  const auto& x = 0;

does not mean:

  template const T& x = 0;

So I would be surprised if any of:

  void (*p1)(auto);
  auto (*p2)(int);
  vector x;

did mean "create a template" instead of "deduce the type of x".

Also, if we did have this interpretation of auto for some (but not
all?) variable declarations, we would have to know to write those as
template-ids:

  void (*p)(auto);
  p = some_f;

since one cannot refer to a template specialization without arguments.

I'm much, much happier if, for variable templates, we always deduce
the type from the initializer.. Besides, that wording (or some
approximation thereof) is already in the TS for concepts. A question
came up during the CWG review as to whether we could declare function
parameters as void (*p)(auto), and EWG said, "sure, go for it". We
also have the ability to declare function parameters as, e.g.,
vector or pair. I applied that to variable
templates as well, since it would have been a bit inconsistent,
otherwise.

Andrew

[committed] Remove my MIPS maintainer entry

[Richard Sandiford]

as per https://gcc.gnu.org/ml/gcc/2014-07/msg00231.html

Richard


* MAINTAINERS: Remove my MIPS maintainer entry.

Index: MAINTAINERS
===
--- MAINTAINERS 2014-07-24 16:13:22.686714267 +0100
+++ MAINTAINERS 2014-07-27 19:01:59.931740086 +0100
@@ -79,7 +79,6 @@ mcore portNick Cliftonnickc@redhat.c
 mep port   DJ Delorie  d...@redhat.com
 microblaze Michael Eager   ea...@eagercon.com
 mips port  Eric Christopherechri...@gmail.com
-mips port  Richard Sandiford   rdsandif...@googlemail.com
 mmix port  Hans-Peter Nilsson  h...@bitrange.com
 mn10300 port   Jeff Lawl...@redhat.com
 mn10300 port   Alexandre Oliva aol...@redhat.com

Re: Warn when returning the address of a temporary (middle-end) v2

[Richard Sandiford]

Marc Glisse  writes:
> Hello,
>
> I followed the advice in this discussion:
> https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00269.html
>
> and here is a new patch. I made an effort to isolate a path in at least 
> one subcase so it doesn't look too strange that the warning is in this 
> file. Computing the dominance info just to tweak the warning message may 
> be a bit excessive.

How about only calculating it once you've decided to issue a message?

> +   if (always_executed)
> + msg = "function returns address of local variable";
> +   else
> + msg = "function may return address of local variable";

I think you need _(...) here, unless some magic makes that unnecessary now.

Thanks,
Richard

Re: [PATH wwwdocs] Mention avx-512vlbwdq branch in svn.html

[Gerald Pfeifer]

Hi Kirill,

On Sun, 27 Jul 2014, Kirill Yukhin wrote:
> Patch below introduces mention of avx-512vlbwdq SVN
> branch in htdocs/svn.html
> 
> Same prefix for e-mail (w/ avx-512) put intentionally.
> 
> Is it ok to install?

you don't need to get explicit approval for release notes related to 
your areas of expertise, svn.html maintenance, and the like, though 
I'm happy to provide editorial review whenever you desire so.

So, yes this is okay.

> +   The goal of this branch is to implement Intel AVX-512{VL,BW,DQ}
> +   Programming Reference
> +   ( href="https://software.intel.com/sites/default/files/managed/c6/a9/319433-020.pdf";>link).

This probably might be better as "the Intel AVX-512..." (with an extra
"the")?

Gerald

Re: Warn when returning the address of a temporary (middle-end) v2

[Marc Glisse]

On Sun, 27 Jul 2014, Richard Sandiford wrote:


Marc Glisse  writes:

Hello,

I followed the advice in this discussion:
https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00269.html

and here is a new patch. I made an effort to isolate a path in at least
one subcase so it doesn't look too strange that the warning is in this
file. Computing the dominance info just to tweak the warning message may
be a bit excessive.


How about only calculating it once you've decided to issue a message?


Good idea! I'll post the updated patch after testing.


+ if (always_executed)
+   msg = "function returns address of local variable";
+ else
+   msg = "function may return address of local variable";


I think you need _(...) here, unless some magic makes that unnecessary now.


I just tried to see how the magic happens when someone calls error_at, and 
it goes through diagnostic_set_info, which contains:


diagnostic_set_info_translated (diagnostic, _(gmsgid), args, location, kind);

So I think the _(...) is already taken care of. But I don't know that code 
at all and I could easily have looked at it wrong.


Thanks for the help,

--
Marc Glisse

Re: Patch for constexpr variable templates

[Adam Butcher]

On 2014-07-27 19:01, Andrew Sutton wrote:

In the 59638 case, the declarations

  void (*a)(auto);
  void (*b)(auto) = 0;

are shorthand for

  template  void (*a)(T);
  template  void (*b)(T) = 0;

which, unless there's some constraint with variable templates that 
I'm not

aware of, ought to define two variable templates 'a' and 'b' to be
ptr-to-function-taking-T.  So I think it's correct that the variable
template stuff should be triggering here.


There isn't, but this interpretation isn't consistent with the use of
auto in variable declarations.

True.  It's just what GCC currently does when it see's 'auto' in a 
function parameter list.  Sounds like it needs to be prevented from 
doing that in [at least] this case.



For example, this:

  const auto& x = 0;

does not mean:

  template const T& x = 0;

So I would be surprised if any of:

  void (*p1)(auto);
  auto (*p2)(int);
  vector x;

did mean "create a template" instead of "deduce the type of x".

Indeed.  I accept the argument.  The only reason GCC does this is that 
it has a general implementation that introduces a template parameter 
list to the primary declaration whenever it sees 'auto' in a function 
parameter list; including a function parameter list in a function type.


If we know that we are not declaring a function (or know that we are 
declaring a variable), then we can prevent 'auto' from having the 
currently implemented meaning.  That would be an alternative resolution 
to 59638 (and friends) too.



Also, if we did have this interpretation of auto for some (but not
all?) variable declarations, we would have to know to write those as
template-ids:

  void (*p)(auto);
  p = some_f;

since one cannot refer to a template specialization without 
arguments.


Agreed.  That's not pleasant.  And I question whether there's a 
motivating use case for variable templates that are function pointers 
(but I confess I haven't thought much about it).



I'm much, much happier if, for variable templates, we always deduce
the type from the initializer.. Besides, that wording (or some
approximation thereof) is already in the TS for concepts. A question
came up during the CWG review as to whether we could declare function
parameters as void (*p)(auto), and EWG said, "sure, go for it". We
also have the ability to declare function parameters as, e.g.,
vector or pair. I applied that to variable
templates as well, since it would have been a bit inconsistent,
otherwise.

Sounds good.  For function parameters this is implemented in GCC by 
introducing a template declaration; i.e. making the function in question 
a function template.  For variables we want a different solution that 
relies on doing some sort of tsubst of an initializer expression into 
the 'auto'-expressed variable type; effectively generalizing the 
handling of 'auto x = ...'.  We could probably leverage the current 
behavior to get the generalized ("generic") type including template 
parameters, then do a substitution using the initializer expression to 
determine what they are (and error if no initializer is given).


Adam

Convert more incremental hash users to inchash

[Andi Kleen]

This patchkit converts more incremental hash users to the new 
inchash class. The only larger change is for rtl hashing,
which I had to move to a new file to avoid problems
with the generator program. All changes should only
minimally change behavior.

Bootstrapped and tested on x86_64-linux. Ok to commit?

-Andi

[PATCH 2/6] Convert asan.c to inchash

[Andi Kleen]

From: Andi Kleen 

gcc/:

2014-07-25  Andi Kleen  

* asan.c (asan_mem_ref_hasher::hash): Convert to inchash.
---
 gcc/asan.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/gcc/asan.c b/gcc/asan.c
index 475dd82..f7fa55f 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -348,9 +348,10 @@ struct asan_mem_ref_hasher
 inline hashval_t
 asan_mem_ref_hasher::hash (const asan_mem_ref *mem_ref)
 {
-  hashval_t h = iterative_hash_expr (mem_ref->start, 0);
-  h = iterative_hash_host_wide_int (mem_ref->access_size, h);
-  return h;
+  inchash hstate;
+  iterative_hstate_expr (mem_ref->start, hstate);
+  hstate.add_wide_int (mem_ref->access_size);
+  return hstate.end ();
 }
 
 /* Compare two memory references.  We accept the length of either
-- 
2.0.1

[PATCH 3/6] Convert ipa-devirt to inchash

[Andi Kleen]

From: Andi Kleen 

gcc/:

2014-07-25  Andi Kleen  

* ipa-devirt.c (polymorphic_call_target_hasher::hash):
Convert to inchash.
---
 gcc/ipa-devirt.c | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/gcc/ipa-devirt.c b/gcc/ipa-devirt.c
index 127d58d..5f529a9 100644
--- a/gcc/ipa-devirt.c
+++ b/gcc/ipa-devirt.c
@@ -1633,17 +1633,15 @@ struct polymorphic_call_target_hasher
 inline hashval_t
 polymorphic_call_target_hasher::hash (const value_type *odr_query)
 {
-  hashval_t hash;
-
-  hash = iterative_hash_host_wide_int
- (odr_query->otr_token,
-  odr_query->type->id);
-  hash = iterative_hash_hashval_t (TYPE_UID (odr_query->context.outer_type),
-  hash);
-  hash = iterative_hash_host_wide_int (odr_query->context.offset, hash);
-  return iterative_hash_hashval_t
-   (((int)odr_query->context.maybe_in_construction << 1)
-| (int)odr_query->context.maybe_derived_type, hash);
+  inchash hstate (odr_query->otr_token);
+
+  hstate.add_wide_int (odr_query->type->id);
+  hstate.add_wide_int (TYPE_UID (odr_query->context.outer_type));
+  hstate.add_wide_int (odr_query->context.offset);
+  hstate.add_flag (odr_query->context.maybe_in_construction);
+  hstate.add_flag (odr_query->context.maybe_derived_type);
+  hstate.commit_flag ();
+  return hstate.end ();
 }
 
 /* Compare cache entries T1 and T2.  */
-- 
2.0.1

[PATCH 4/6] Convert tree-ssa-dom to inchash

[Andi Kleen]

From: Andi Kleen 

gcc/:

2014-07-25  Andi Kleen  

* tree-ssa-dom.c (iterative_hash_exprs_commutative): Convert to inchash.
(iterative_hash_hashable_expr): Dito.
(avail_expr_hash): Dito.
---
 gcc/tree-ssa-dom.c | 79 +-
 1 file changed, 36 insertions(+), 43 deletions(-)

diff --git a/gcc/tree-ssa-dom.c b/gcc/tree-ssa-dom.c
index 08fd2fa..abf2b2e4 100644
--- a/gcc/tree-ssa-dom.c
+++ b/gcc/tree-ssa-dom.c
@@ -55,6 +55,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "params.h"
 #include "tree-ssa-threadedge.h"
 #include "tree-ssa-dom.h"
+#include "inchash.h"
 
 /* This file implements optimizations on the dominator tree.  */
 
@@ -557,45 +558,40 @@ hashable_expr_equal_p (const struct hashable_expr *expr0,
 }
 
 /* Generate a hash value for a pair of expressions.  This can be used
-   iteratively by passing a previous result as the VAL argument.
+   iteratively by passing a previous result in HSTATE.
 
The same hash value is always returned for a given pair of expressions,
regardless of the order in which they are presented.  This is useful in
hashing the operands of commutative functions.  */
 
-static hashval_t
+static void
 iterative_hash_exprs_commutative (const_tree t1,
-  const_tree t2, hashval_t val)
+  const_tree t2, inchash &hstate)
 {
-  hashval_t one = iterative_hash_expr (t1, 0);
-  hashval_t two = iterative_hash_expr (t2, 0);
-  hashval_t t;
-
-  if (one > two)
-t = one, one = two, two = t;
-  val = iterative_hash_hashval_t (one, val);
-  val = iterative_hash_hashval_t (two, val);
+  inchash one, two;
 
-  return val;
+  iterative_hstate_expr (t1, one);
+  iterative_hstate_expr (t2, two);
+  hstate.add_commutative (one, two);
 }
 
 /* Compute a hash value for a hashable_expr value EXPR and a
previously accumulated hash value VAL.  If two hashable_expr
values compare equal with hashable_expr_equal_p, they must
hash to the same value, given an identical value of VAL.
-   The logic is intended to follow iterative_hash_expr in tree.c.  */
+   The logic is intended to follow iterative_hstate_expr in tree.c.  */
 
-static hashval_t
-iterative_hash_hashable_expr (const struct hashable_expr *expr, hashval_t val)
+static void
+iterative_hash_hashable_expr (const struct hashable_expr *expr, inchash 
&hstate)
 {
   switch (expr->kind)
 {
 case EXPR_SINGLE:
-  val = iterative_hash_expr (expr->ops.single.rhs, val);
+  iterative_hstate_expr (expr->ops.single.rhs, hstate);
   break;
 
 case EXPR_UNARY:
-  val = iterative_hash_object (expr->ops.unary.op, val);
+  hstate.add_object (expr->ops.unary.op);
 
   /* Make sure to include signedness in the hash computation.
  Don't hash the type, that can lead to having nodes which
@@ -603,34 +599,34 @@ iterative_hash_hashable_expr (const struct hashable_expr 
*expr, hashval_t val)
  have different hash codes.  */
   if (CONVERT_EXPR_CODE_P (expr->ops.unary.op)
   || expr->ops.unary.op == NON_LVALUE_EXPR)
-val += TYPE_UNSIGNED (expr->type);
+hstate.add_int (TYPE_UNSIGNED (expr->type));
 
-  val = iterative_hash_expr (expr->ops.unary.opnd, val);
+  iterative_hstate_expr (expr->ops.unary.opnd, hstate);
   break;
 
 case EXPR_BINARY:
-  val = iterative_hash_object (expr->ops.binary.op, val);
+  hstate.add_object (expr->ops.binary.op);
   if (commutative_tree_code (expr->ops.binary.op))
-   val = iterative_hash_exprs_commutative (expr->ops.binary.opnd0,
-   expr->ops.binary.opnd1, val);
+   iterative_hash_exprs_commutative (expr->ops.binary.opnd0,
+ expr->ops.binary.opnd1, hstate);
   else
 {
-  val = iterative_hash_expr (expr->ops.binary.opnd0, val);
-  val = iterative_hash_expr (expr->ops.binary.opnd1, val);
+  iterative_hstate_expr (expr->ops.binary.opnd0, hstate);
+  iterative_hstate_expr (expr->ops.binary.opnd1, hstate);
 }
   break;
 
 case EXPR_TERNARY:
-  val = iterative_hash_object (expr->ops.ternary.op, val);
+  hstate.add_object (expr->ops.ternary.op);
   if (commutative_ternary_tree_code (expr->ops.ternary.op))
-   val = iterative_hash_exprs_commutative (expr->ops.ternary.opnd0,
-   expr->ops.ternary.opnd1, val);
+   iterative_hash_exprs_commutative (expr->ops.ternary.opnd0,
+ expr->ops.ternary.opnd1, hstate);
   else
 {
-  val = iterative_hash_expr (expr->ops.ternary.opnd0, val);
-  val = iterative_hash_expr (expr->ops.ternary.opnd1, val);
+  iterative_hstate_expr (expr->ops.ternary.opnd0, hstate);
+  iterative_hstate_expr (expr->ops.ternary.opnd1, hstate);
 }
-  val =

[PATCH 6/6] Convert tree-ssa-tail-merge to inchash

[Andi Kleen]

From: Andi Kleen 

gcc/:

2014-07-25  Andi Kleen  

* tree-ssa-tail-merge.c (same_succ_hash): Convert to inchash.
---
 gcc/tree-ssa-tail-merge.c | 22 ++
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/gcc/tree-ssa-tail-merge.c b/gcc/tree-ssa-tail-merge.c
index 9600e28..a27af5b 100644
--- a/gcc/tree-ssa-tail-merge.c
+++ b/gcc/tree-ssa-tail-merge.c
@@ -451,7 +451,7 @@ stmt_update_dep_bb (gimple stmt)
 static hashval_t
 same_succ_hash (const_same_succ e)
 {
-  hashval_t hashval = bitmap_hash (e->succs);
+  inchash hstate (bitmap_hash (e->succs));
   int flags;
   unsigned int i;
   unsigned int first = bitmap_first_set_bit (e->bbs);
@@ -472,37 +472,35 @@ same_succ_hash (const_same_succ e)
continue;
   size++;
 
-  hashval = iterative_hash_hashval_t (gimple_code (stmt), hashval);
+  hstate.add_int (gimple_code (stmt));
   if (is_gimple_assign (stmt))
-   hashval = iterative_hash_hashval_t (gimple_assign_rhs_code (stmt),
-   hashval);
+   hstate.add_int (gimple_assign_rhs_code (stmt));
   if (!is_gimple_call (stmt))
continue;
   if (gimple_call_internal_p (stmt))
-   hashval = iterative_hash_hashval_t
- ((hashval_t) gimple_call_internal_fn (stmt), hashval);
+hstate.add_int (gimple_call_internal_fn (stmt));
   else
{
- hashval = iterative_hash_expr (gimple_call_fn (stmt), hashval);
+ iterative_hstate_expr (gimple_call_fn (stmt), hstate);
  if (gimple_call_chain (stmt))
-   hashval = iterative_hash_expr (gimple_call_chain (stmt), hashval);
+   iterative_hstate_expr (gimple_call_chain (stmt), hstate);
}
   for (i = 0; i < gimple_call_num_args (stmt); i++)
{
  arg = gimple_call_arg (stmt, i);
  arg = vn_valueize (arg);
- hashval = iterative_hash_expr (arg, hashval);
+ iterative_hstate_expr (arg, hstate);
}
 }
 
-  hashval = iterative_hash_hashval_t (size, hashval);
+  hstate.add_int (size);
   BB_SIZE (bb) = size;
 
   for (i = 0; i < e->succ_flags.length (); ++i)
 {
   flags = e->succ_flags[i];
   flags = flags & ~(EDGE_TRUE_VALUE | EDGE_FALSE_VALUE);
-  hashval = iterative_hash_hashval_t (flags, hashval);
+  hstate.add_int (flags);
 }
 
   EXECUTE_IF_SET_IN_BITMAP (e->succs, 0, s, bs)
@@ -521,7 +519,7 @@ same_succ_hash (const_same_succ e)
}
 }
 
-  return hashval;
+  return hstate.end ();
 }
 
 /* Returns true if E1 and E2 have 2 successors, and if the successor flags
-- 
2.0.1

[PATCH 5/6] Convert tree-ssa-sccvn to inchash

[Andi Kleen]

From: Andi Kleen 

gcc/:

2014-07-25  Andi Kleen  

* tree-ssa-sccvn.c (vn_reference_op_compute_hash):
(vn_reference_compute_hash):
(vn_nary_op_compute_hash):
(vn_phi_compute_hash):
* tree-ssa-sccvn.h (vn_hash_constant_with_type):
---
 gcc/tree-ssa-sccvn.c | 44 ++--
 gcc/tree-ssa-sccvn.h |  6 --
 2 files changed, 26 insertions(+), 24 deletions(-)

diff --git a/gcc/tree-ssa-sccvn.c b/gcc/tree-ssa-sccvn.c
index 93314fc..160ca00 100644
--- a/gcc/tree-ssa-sccvn.c
+++ b/gcc/tree-ssa-sccvn.c
@@ -594,17 +594,16 @@ value_id_constant_p (unsigned int v)
 
 /* Compute the hash for a reference operand VRO1.  */
 
-static hashval_t
-vn_reference_op_compute_hash (const vn_reference_op_t vro1, hashval_t result)
+static void
+vn_reference_op_compute_hash (const vn_reference_op_t vro1, inchash &hstate)
 {
-  result = iterative_hash_hashval_t (vro1->opcode, result);
+  hstate.add_int (vro1->opcode);
   if (vro1->op0)
-result = iterative_hash_expr (vro1->op0, result);
+iterative_hstate_expr (vro1->op0, hstate);
   if (vro1->op1)
-result = iterative_hash_expr (vro1->op1, result);
+iterative_hstate_expr (vro1->op1, hstate);
   if (vro1->op2)
-result = iterative_hash_expr (vro1->op2, result);
-  return result;
+iterative_hstate_expr (vro1->op2, hstate);
 }
 
 /* Compute a hash for the reference operation VR1 and return it.  */
@@ -612,7 +611,8 @@ vn_reference_op_compute_hash (const vn_reference_op_t vro1, 
hashval_t result)
 hashval_t
 vn_reference_compute_hash (const vn_reference_t vr1)
 {
-  hashval_t result = 0;
+  inchash hstate;
+  hashval_t result;
   int i;
   vn_reference_op_t vro;
   HOST_WIDE_INT off = -1;
@@ -634,7 +634,7 @@ vn_reference_compute_hash (const vn_reference_t vr1)
{
  if (off != -1
  && off != 0)
-   result = iterative_hash_hashval_t (off, result);
+   hstate.add_int (off);
  off = -1;
  if (deref
  && vro->opcode == ADDR_EXPR)
@@ -642,14 +642,16 @@ vn_reference_compute_hash (const vn_reference_t vr1)
  if (vro->op0)
{
  tree op = TREE_OPERAND (vro->op0, 0);
- result = iterative_hash_hashval_t (TREE_CODE (op), result);
- result = iterative_hash_expr (op, result);
+ hstate.add_int (TREE_CODE (op));
+ iterative_hstate_expr (op, hstate);
}
}
  else
-   result = vn_reference_op_compute_hash (vro, result);
+   vn_reference_op_compute_hash (vro, hstate);
}
 }
+  result = hstate.end ();
+  /* ??? We would ICE later if we hash instead of adding that in. */
   if (vr1->vuse)
 result += SSA_NAME_VERSION (vr1->vuse);
 
@@ -2236,7 +2238,7 @@ vn_reference_insert_pieces (tree vuse, alias_set_type 
set, tree type,
 hashval_t
 vn_nary_op_compute_hash (const vn_nary_op_t vno1)
 {
-  hashval_t hash;
+  inchash hstate;
   unsigned i;
 
   for (i = 0; i < vno1->length; ++i)
@@ -2252,11 +2254,11 @@ vn_nary_op_compute_hash (const vn_nary_op_t vno1)
   vno1->op[1] = temp;
 }
 
-  hash = iterative_hash_hashval_t (vno1->opcode, 0);
+  hstate.add_int (vno1->opcode);
   for (i = 0; i < vno1->length; ++i)
-hash = iterative_hash_expr (vno1->op[i], hash);
+iterative_hstate_expr (vno1->op[i], hstate);
 
-  return hash;
+  return hstate.end ();
 }
 
 /* Compare nary operations VNO1 and VNO2 and return true if they are
@@ -2536,26 +2538,24 @@ vn_nary_op_insert_stmt (gimple stmt, tree result)
 static inline hashval_t
 vn_phi_compute_hash (vn_phi_t vp1)
 {
-  hashval_t result;
+  inchash hstate (vp1->block->index);
   int i;
   tree phi1op;
   tree type;
 
-  result = vp1->block->index;
-
   /* If all PHI arguments are constants we need to distinguish
  the PHI node via its type.  */
   type = vp1->type;
-  result += vn_hash_type (type);
+  hstate.merge_hash (vn_hash_type (type));
 
   FOR_EACH_VEC_ELT (vp1->phiargs, i, phi1op)
 {
   if (phi1op == VN_TOP)
continue;
-  result = iterative_hash_expr (phi1op, result);
+  iterative_hstate_expr (phi1op, hstate);
 }
 
-  return result;
+  return hstate.end ();
 }
 
 /* Compare two phi entries for equality, ignoring VN_TOP arguments.  */
diff --git a/gcc/tree-ssa-sccvn.h b/gcc/tree-ssa-sccvn.h
index f52783a..f420656 100644
--- a/gcc/tree-ssa-sccvn.h
+++ b/gcc/tree-ssa-sccvn.h
@@ -140,8 +140,10 @@ vn_hash_type (tree type)
 static inline hashval_t
 vn_hash_constant_with_type (tree constant)
 {
-  return (iterative_hash_expr (constant, 0)
- + vn_hash_type (TREE_TYPE (constant)));
+  inchash hstate;
+  iterative_hstate_expr (constant, hstate);
+  hstate.merge_hash (vn_hash_type (TREE_TYPE (constant)));
+  return hstate.end ();
 }
 
 /* Compare the constants C1 and C2 with distinguishing type incompatible
-- 
2.0.1

[PATCH 1/6] RTL & dwarf2out changes

[Andi Kleen]

From: Andi Kleen 

Convert dwarf2out and rtl.c to the new inchash interface.

I moved the rtl hash code to another file to avoid having to link
all the hash code into the generator functions.

gcc/:

2014-07-25  Andi Kleen  

* Makefile.in (OBJS): Add rtlhash.o
* dwarf2out.c (addr_table_entry_do_hash): Convert to inchash.
(loc_checksum): Dito.
(loc_checksum_ordered): Dito.
(hash_loc_operands): Dito.
(hash_locs): Dito.
(hash_loc_list): Dito.
* rtl.c (iterative_hash_rtx): Moved to rtlhash.c
* rtl.h (iterative_hash_rtx): Moved to rtlhash.h
* rtlhash.c: New file.
* rtlhash.h: New file.
---
 gcc/Makefile.in |   1 +
 gcc/dwarf2out.c | 126 +---
 gcc/rtl.c   |  79 +--
 gcc/rtl.h   |   1 -
 gcc/rtlhash.c   | 102 +
 gcc/rtlhash.h   |  27 
 6 files changed, 197 insertions(+), 139 deletions(-)
 create mode 100644 gcc/rtlhash.c
 create mode 100644 gcc/rtlhash.h

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 4c578b3..a2fb5f5 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1350,6 +1350,7 @@ OBJS = \
resource.o \
rtl-error.o \
rtl.o \
+   rtlhash.o \
rtlanal.o \
rtlhooks.o \
sbitmap.o \
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 8fd1945..26fb34c 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -71,6 +71,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "flags.h"
 #include "hard-reg-set.h"
 #include "regs.h"
+#include "rtlhash.h"
 #include "insn-config.h"
 #include "reload.h"
 #include "function.h"
@@ -3277,7 +3278,7 @@ static void gen_scheduled_generic_parms_dies (void);
 
 static const char *comp_dir_string (void);
 
-static hashval_t hash_loc_operands (dw_loc_descr_ref, hashval_t);
+static void hash_loc_operands (dw_loc_descr_ref, inchash &);
 
 /* enum for tracking thread-local variables whose address is really an offset
relative to the TLS pointer, which will need link-time relocation, but will
@@ -4190,17 +4191,22 @@ static hashval_t
 addr_table_entry_do_hash (const void *x)
 {
   const addr_table_entry *a = (const addr_table_entry *) x;
+  inchash hstate;
   switch (a->kind)
 {
   case ate_kind_rtx:
-return iterative_hash_rtx (a->addr.rtl, 0);
+   hstate.add_int (0);
+   break;
   case ate_kind_rtx_dtprel:
-return iterative_hash_rtx (a->addr.rtl, 1);
+   hstate.add_int (1);
+   break;
   case ate_kind_label:
 return htab_hash_string (a->addr.label);
   default:
 gcc_unreachable ();
 }
+  iterative_hstate_rtx (a->addr.rtl, hstate);
+  return hstate.end ();
 }
 
 /* Determine equality for two address_table_entries.  */
@@ -5544,11 +5550,14 @@ static inline void
 loc_checksum (dw_loc_descr_ref loc, struct md5_ctx *ctx)
 {
   int tem;
-  hashval_t hash = 0;
+  inchash hstate;
+  hashval_t hash;
 
   tem = (loc->dtprel << 8) | ((unsigned int) loc->dw_loc_opc);
   CHECKSUM (tem);
-  hash = hash_loc_operands (loc, hash);
+  hash_loc_operands (loc, hstate);
+  /* ??? MD5 of another hash doesn't make a lot of sense... */
+  hash = hstate.end();
   CHECKSUM (hash);
 }
 
@@ -5758,11 +5767,13 @@ loc_checksum_ordered (dw_loc_descr_ref loc, struct 
md5_ctx *ctx)
   /* Otherwise, just checksum the raw location expression.  */
   while (loc != NULL)
 {
-  hashval_t hash = 0;
+  inchash hstate;
+  hashval_t hash;
 
   CHECKSUM_ULEB128 (loc->dtprel);
   CHECKSUM_ULEB128 (loc->dw_loc_opc);
-  hash = hash_loc_operands (loc, hash);
+  hash_loc_operands (loc, hstate);
+  hash = hstate.end ();
   CHECKSUM (hash);
   loc = loc->dw_loc_next;
 }
@@ -23619,10 +23630,10 @@ resolve_addr (dw_die_ref die)
This pass tries to share identical local lists in .debug_loc
section.  */
 
-/* Iteratively hash operands of LOC opcode.  */
+/* Iteratively hash operands of LOC opcode into HSTATE.  */
 
-static hashval_t
-hash_loc_operands (dw_loc_descr_ref loc, hashval_t hash)
+static void
+hash_loc_operands (dw_loc_descr_ref loc, inchash &hstate)
 {
   dw_val_ref val1 = &loc->dw_loc_oprnd1;
   dw_val_ref val2 = &loc->dw_loc_oprnd2;
@@ -23681,7 +23692,7 @@ hash_loc_operands (dw_loc_descr_ref loc, hashval_t hash)
 case DW_OP_piece:
 case DW_OP_deref_size:
 case DW_OP_xderef_size:
-  hash = iterative_hash_object (val1->v.val_int, hash);
+  hstate.add_object (val1->v.val_int);
   break;
 case DW_OP_skip:
 case DW_OP_bra:
@@ -23690,36 +23701,35 @@ hash_loc_operands (dw_loc_descr_ref loc, hashval_t 
hash)
 
gcc_assert (val1->val_class == dw_val_class_loc);
offset = val1->v.val_loc->dw_loc_addr - (loc->dw_loc_addr + 3);
-   hash = iterative_hash_object (offset, hash);
+   hstate.add_object (offset);
   }
   break;
 case DW_OP_implicit_value:

Re: Warn when returning the address of a temporary (middle-end) v2

[Andreas Schwab]

Marc Glisse  writes:

> On Sun, 27 Jul 2014, Richard Sandiford wrote:
>
>> Marc Glisse  writes:
>>> + if (always_executed)
>>> +   msg = "function returns address of local variable";
>>> + else
>>> +   msg = "function may return address of local variable";
>>
>> I think you need _(...) here, unless some magic makes that unnecessary now.
>
> I just tried to see how the magic happens when someone calls error_at, and
> it goes through diagnostic_set_info, which contains:
>
> diagnostic_set_info_translated (diagnostic, _(gmsgid), args, location, kind);
>
> So I think the _(...) is already taken care of. But I don't know that code
> at all and I could easily have looked at it wrong.

If the msgid is not a direct argument of the diagnostic function you
need to mark the string with N_(...).

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

[GSoC][match-and-simplify] sanitize option checking

[Prathamesh Kulkarni]

Added checks to see if either cmmand-line options is not repeated,
and generates match-and-simplify code on both GENERIC and GIMPLE
if both -generic and -gimple are specified.

* genmatch.c (cmd_options): New struct.
(check_repeated_arg): New function.
(parse_cmd_arg): Likewise.
(main): Emit diagnostic if no command line options are given.
   Add call to parse_cmd_arg.

Thanks,
Prathamesh
Index: genmatch.c
===
--- genmatch.c	(revision 212928)
+++ genmatch.c	(working copy)
@@ -2118,6 +2118,34 @@ parse_pattern (cpp_reader *r, vec

Re: Warn when returning the address of a temporary (middle-end) v2

[Marc Glisse]

On Sun, 27 Jul 2014, Andreas Schwab wrote:


Marc Glisse  writes:


On Sun, 27 Jul 2014, Richard Sandiford wrote:


Marc Glisse  writes:

+ if (always_executed)
+   msg = "function returns address of local variable";
+ else
+   msg = "function may return address of local variable";


I think you need _(...) here, unless some magic makes that unnecessary now.


I just tried to see how the magic happens when someone calls error_at, and
it goes through diagnostic_set_info, which contains:

diagnostic_set_info_translated (diagnostic, _(gmsgid), args, location, kind);

So I think the _(...) is already taken care of. But I don't know that code
at all and I could easily have looked at it wrong.


If the msgid is not a direct argument of the diagnostic function you
need to mark the string with N_(...).


Ah, ok, thanks.
Actually, shouldn't it be G_ instead? That's what ABOUT-GCC-NLS seems to 
suggest since 2005, though I don't expect it makes any difference for 
simple strings.


--
Marc Glisse

[GSoC][match-and-simplify] include is-a.h

[Prathamesh Kulkarni]

Is it okay to include is-a.h ?
I have adjusted print_operand to use is_a<> and as_a<> in this patch.

* genmatch.c (is-a.h): Include.
(is_a_helper::test): Specialize for operand subclasses.
(print_operand): Adjust to use is_a and as_a.

Thanks,
Prathamesh.
Index: genmatch.c
===
--- genmatch.c	(revision 212928)
+++ genmatch.c	(working copy)
@@ -29,6 +29,7 @@ along with GCC; see the file COPYING3.
 #include "hashtab.h"
 #include "hash-table.h"
 #include "vec.h"
+#include "is-a.h"
 
 /* libccp helpers.  */
 
@@ -256,6 +257,39 @@ struct capture : public operand
   virtual void gen_transform (FILE *f, const char *, bool);
 };
 
+template<>
+template<>
+inline bool
+is_a_helper ::test (operand *op)
+{
+  return op->type == operand::OP_CAPTURE;
+}
+
+template<>
+template<>
+inline bool
+is_a_helper ::test (operand *op)
+{
+  return op->type == operand::OP_PREDICATE;
+}
+
+template<>
+template<>
+inline bool
+is_a_helper ::test (operand *op)
+{
+  return op->type == operand::OP_C_EXPR;
+}
+
+template<>
+template<>
+inline bool
+is_a_helper ::test (operand *op)
+{
+  return op->type == operand::OP_EXPR;
+}
+
+
 e_operation::e_operation (const char *id, bool is_commutative_, bool add_new_id)
 {
   is_commutative = is_commutative_;
@@ -415,10 +449,10 @@ struct decision_tree
 DEBUG_FUNCTION void
 print_operand (operand *o, FILE *f = stderr, bool flattened = false)
 {
-  if (o->type == operand::OP_CAPTURE)
+  if (is_a (o))
 {
-  capture *c = static_cast (o);
-  fprintf (f, "@%s", (static_cast (o))->where);
+  capture *c = as_a (o); 
+  fprintf (f, "@%s", c->where);
   if (c->what && flattened == false) 
 	{
 	  putc (':', f);
@@ -427,15 +461,15 @@ print_operand (operand *o, FILE *f = std
 	}
 }
 
-  else if (o->type == operand::OP_PREDICATE)
-fprintf (f, "%s", (static_cast (o))->ident);
+  else if (is_a (o))
+fprintf (f, "%s", (as_a (o))->ident);
 
-  else if (o->type == operand::OP_C_EXPR)
+  else if (is_a (o))
 fprintf (f, "c_expr");
 
-  else if (o->type == operand::OP_EXPR)
+  else if (is_a (o))
 {
-  expr *e = static_cast (o);
+  expr *e = as_a (o); 
   fprintf (f, "(%s", e->operation->op->id);
 
   if (flattened == false)

Aw: RE: Re: [MIPS r5900] libgcc floating point fixes

[Jürgen Urban]

> "Jürgen Urban" writes:
> > > "Jürgen Urban"  writes:
> > > > Hello Richard,
> > > >
> > > > > "Jürgen Urban"  writes:
> > > Is this something you
> > > have recently developed outside of the mainline kernel or does it already
> > exist.
> > > I'm not aware of such logic in the MIPS kernel yet.
> > 
> > Yes, this is developed in my kernel which currently is still based on Linux
> > 2.6.35.4. I added a TIF_R5900FPU flag to thread_info.h. I plan that this
> > will get part of the mainline kernel. As the patch is too large to get
> > accepted, I need to change the binutils, so that sync.p will be added after
> > or before the right instruction automatically.
> 
> Is the TIF_R5900FPU flag to do something more than just change the register
> model used by the FPU emulator or does it do something more/less?

Currently it just enables or disables the FPU. When FPU is disabled the 
software emulation is used.

> I'm afraid I don’t know the significance of the sync.p.
> 
> > > > double the FPU emulator gets activated. Currently it only checks whether
> > the
> > > > architecture is mips r5900 or not. For non r5900 the FPU emulator is
> > > > activated. It seems that we also need to add something to the ELF file
> > to
> > > > specify the 32 bit or 64 bit for float. It would be good when it is not
> > at a
> > > > so complicated position as the soft vs hard float flag, because it needs
> > to
> > > > be read by the kernel when starting a ELF file. This way it would also
> > be
> > >
> > > I have a series of patches that will add this kind of support to the MIPS
> > > ABI in the coming weeks for similar reasons but relating to O32 and
> > double-float
> > > ABI extensions. You will be able to directly hang off the changes once I
> > commit
> > > (testing is taking some time). There should be no need for extra changes
> > to
> > > gcc or binutils to get the information you need. Kernel changes to respond
> > > to new ABI information are also in progress and will be easily extendable.
> > >
> > > > possible to emulate the r5900 FPU on a TX79 system. The TX79 is the same
> > as
> > > > r5900, but the FPU is 64 bit and compliant to IEEE 754.
> > > >
> > > > > Note that this won't really be correct for r5900 anyway because of its
> > > > > non-IEEE FPU.  E.g. the soft-float routines will treat 0x7f80 as
> > > > > infinity and 0x7fff as a NaN, whereas for r5900 they should be
> > treated
> > > > > as normal numbers.
> > > >
> > > > The code looked like it uses the configured floating point configuration
> > for
> > > > hard float, but you are right the conversion is not working in these
> > cases.
> > > >
> > > > I think there is no problem with the second part of the patch which
> > disables
> > > > t-mips16 for r5900. So could you commit the last part of the patch?
> > >
> > > Are you looking to add support for a single-float FPU to a number of
> > > packages as part of this? One thing that comes to mind would be libffi but
> > the
> > > double-precision ABIs are assumed to be the only ones used in Linux in a
> > number
> > > of places. Just trying to get a feel for your end goal out of curiosity.
> > 
> > The libffi doesn't look like that there is a change needed for floating
> > point.
> 
> Libffi and most other hand crafted code for linux are written to follow the
> standard double-precision O32/N32 ABI. The single-precision variants are
> link-incompatible as they change the calling convention. I.e. when you pass
> a double-precision value using a single-precision calling-convention then it
> gets passed in GPRs instead of FPRs.
> 
> > It is possible that it needs a change for TImode or for 2 or 3 of the other
> > co-processors which are currently not under discussion.
> > The long term plan is to have 32 bit floating point operations compliant to
> > IEEE 754 with ABI o32 and n32. Everything should stay inside gcc, libgcc and
> > the kernel (i.e. Linux or PS2SDK). I want to fix it at the lowest level and
> > not in any high level library.
> 
> Due to the calling convention change you won't be able to restrict the work
> to just the toolchain and kernel. MIPS linux theoretically supports two ABI
> extensions 'hard-float (double-precision)' and soft-float. I have a feeling
> that the soft-float extension is not supported everywhere but may be a better
> start point for what you want to achieve, i.e. use a soft-float calling
> convention but add support for using FPU instructions at the same time. This
> would be akin to arm's softfp float-abi.
> 
> > Fixes for high level libraries should also be
> > high level (dmult vs __FLT_MAX_EXP__); i.e. there should be no change in a
> > different package which is specific for MIPS. The type double should stay
> > double and is handled without a problem when the FPU is 32 bit in ABI o32.
> > The problem is only with the single/double conversion functions and the ABI
> > n32.
> 
> I didn't quite follow why you specifically say n32 in the last sentence...
> What is harder

Re: [PATCH, rs6000, 4.8/4.9] Fix alignment of non-Altivec vector struct fields

[Alan Modra]

On Sun, Jul 27, 2014 at 03:16:03PM +0200, Matthias Klose wrote:
> >> Blah, that won't work of course.  The macro needs to take two
> >> parameters.
> >>
> >> #define rs6000_special_adjust_field_align_p(FIELD, COMPUTED) false
> > 
> > This is pre-approved if it works.  I really should finish off the branch I 
> > started years ago :). 
> 
> #define rs6000_special_adjust_field_align_p(FIELD, COMPUTED) 0
> 
> is what succeeds for me. false is not defined for ObjC. Checked in on the 
> trunk
> and the branches.

Heh, that's what I found this morning too, when checking the bootstrap
I'd fired off after posting the "correction".

-- 
Alan Modra
Australia Development Lab, IBM

Re: Patch for constexpr variable templates

[Braden Obrzut]

So given this, should I leave the test cases that fail for this reason 
alone or should I still change them to dg-message?  It sounds like GCC's 
behavior with auto in function parameters needs to be changed, but that 
definitely sounds like a separate patch to me.


- Braden Obrzut

Re: [PATCH, PR61776] verify_flow_info failed: control flow in the middle of basic block with -fprofile-generate

[Wei Mi]

> But fact is that it is _not_ necessary to split the block because there
> are no outgoing abnormal edges from it.
>
> The verifier failure is an artifact from using the same predicates during
> CFG building and CFG verifying (usually ok, but for this particular
> case it leads to this issue).
>
> So I don't think your patch is the proper way to address this issue
> (while it certainly works).
>
> Instead whether a call can make abnormal gotos should be recorded
> per-call and stored on the gimple-call.  Martin - this is exactly
> one of the cases your patch would address?
>

Thanks for the comment and thanks to Martin's patch. I try the patch.
It works well to address both pr60449 and pr61776 after some
extension. One extension is to replace GF_CALL_LEAF attribute using
GF_CALL_NO_ABNORMAL_GOTO. That is because not only dropping "leaf"
attribute in lto symbol merge could introduce the control flow
verification problem in pr60449, dropping "const/pure" attributes
could introduce the same problem too. It is unnecessary to introduce
per-call attributes for all these three: ECF_LEAF/ECF_CONST/ECF_PURE,
so GF_CALL_NO_ABNORMAL_GOTO is introduced to indicate that a call stmt
has no abnormal goto.

GF_CALL_NO_ABNORMAL_GOTO will be set according to gimple_call_flags()
once gimple call stmt is created, then updated in execute_fixup_cfg
and cleanup_tree_cfg.

I posted the extended patch here. I didn't add the noreturn part in
because it has no direct impact on pr60449 and pr61776. I can help
Martin to test and post that part as an independent patch later.

bootstrap and regression pass on x86_64-linux-gnu. Is it ok?

Thanks,
Wei.
ChangeLog:

2014-07-27  Martin Jambor  
Wei Mi  

PR ipa/60449
PR middle-end/61776
* tree-cfgcleanup.c (update_no_abnormal_goto_attr): New function.
(cleanup_tree_cfg_1): Use update_no_abnormal_goto_attr.
* gimple.c (gimple_call_initialize_no_abnormal_goto): New function.
(gimple_build_call_1): Use gimple_call_initialize_no_abnormal_goto.
(gimple_build_call_internal_1): Ditto.
* gimple.h (enum gf_mask): Added GF_NO_ABNORMAL_GOTO.
(gimple_call_set_no_abnormal_goto): New function.
(gimple_call_no_abnormal_goto_p): Ditto.
* tree-cfg.c (call_can_make_abnormal_goto):
Use gimple_call_no_abnormal_goto_p.
(execute_fixup_cfg): Use gimple_call_set_no_abnormal_goto.

2014-07-27  Martin Jambor  
Wei Mi  

PR ipa/60449
PR middle-end/61776
* testsuite/gcc.dg/pr61776.c: New test.
* testsuite/gcc.dg/lto/pr60449_1.c: New test.
* testsuite/gcc.dg/lto/pr60449_0.c: New test.

Index: tree-cfgcleanup.c
===
--- tree-cfgcleanup.c   (revision 212442)
+++ tree-cfgcleanup.c   (working copy)
@@ -621,6 +621,28 @@ split_bbs_on_noreturn_calls (void)
   return changed;
 }
 
+/* Update GF_NO_ABNORMAL_GOTO attribute for call stmts in BB according
+   to gimple_call_flags.  */
+
+static void
+update_no_abnormal_goto_attr (basic_block bb)
+{
+  gimple_stmt_iterator gsi;
+  for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
+{
+  gimple stmt = gsi_stmt (gsi);
+
+  if (!is_gimple_call (stmt))
+   continue;
+
+  int flags = gimple_call_flags (stmt);
+  if ((flags & (ECF_CONST | ECF_PURE)
+   && !(flags & ECF_LOOPING_CONST_OR_PURE))
+ || (flags & ECF_LEAF))
+   gimple_call_set_no_abnormal_goto (stmt, true);
+}
+}
+
 /* Tries to cleanup cfg in basic block BB.  Returns true if anything
changes.  */
 
@@ -672,7 +694,10 @@ cleanup_tree_cfg_1 (void)
 {
   bb = BASIC_BLOCK_FOR_FN (cfun, i);
   if (bb)
-   retval |= cleanup_tree_cfg_bb (bb);
+   {
+ update_no_abnormal_goto_attr (bb);
+ retval |= cleanup_tree_cfg_bb (bb);
+   }
 }
 
   /* Now process the altered blocks, as long as any are available.  */
@@ -687,6 +712,7 @@ cleanup_tree_cfg_1 (void)
   if (!bb)
continue;
 
+  update_no_abnormal_goto_attr (bb);
   retval |= cleanup_tree_cfg_bb (bb);
 
   /* Rerun split_bbs_on_noreturn_calls, in case we have altered any 
noreturn
Index: gimple.c
===
--- gimple.c(revision 212442)
+++ gimple.c(working copy)
@@ -186,6 +186,19 @@ gimple_build_return (tree retval)
   return s;
 }
 
+/* Set GF_NO_ABNORMAL_GOTO attribute according to gimple_call_flags(STMT).  */
+
+void
+gimple_call_initialize_no_abnormal_goto (gimple stmt)
+{
+  int flags = gimple_call_flags (stmt);
+
+  if ((flags & (ECF_CONST | ECF_PURE)
+   && !(flags & ECF_LOOPING_CONST_OR_PURE))
+  || (flags & ECF_LEAF))
+gimple_call_set_no_abnormal_goto (stmt, true);
+}
+
 /* Reset alias information on call S.  */
 
 void
@@ -215,6 +228,7 @@ gimple_build_call_1 (tree fn, unsigned n
   gimple_set_op (s, 1, fn);
   gimple_call_set_fntype (s, TREE_TYP

[PATCH][PING] Fix mklog to support running from arbitrary folder

[Yury Gribov]

 Forwarded Message 
Subject: [PATCH] Fix mklog to support running from arbitrary folder
Date: Mon, 21 Jul 2014 12:32:45 +0400
From: Yury Gribov 
To: GCC Patches 
CC: Diego Novillo , Trevor Saunders 



Hi all,

Current mklog works only if run from GCC top-level folder. The patch
allows running from arbitrary directory.

I've used Linux directory separators which is probably ok because script
already expects Linux environment (dirname, basename, etc.).

Ok to commit?

-Y



commit aa8d7cd3db1f1eba8ee77b902cff1b2ab2a3f83a
Author: Yury Gribov 
Date:   Mon Jul 21 12:05:10 2014 +0400

2014-07-21  Yury Gribov  

	* mklog: Allow running from arbitrary folder.

diff --git a/contrib/mklog b/contrib/mklog
index cdc6455..3d17dc5 100755
--- a/contrib/mklog
+++ b/contrib/mklog
@@ -30,16 +30,15 @@
 $username = $ENV{'USER'};
 $name = `finger $username | grep -o 'Name: .*'`;
 @n = split(/: /, $name);
-$name = @n[1]; chop($name);
+$name = $n[1]; chop($name);
 $addr = $username . "\@my.domain.org";
 $date = `date +%Y-%m-%d`; chop ($date);
 
 $gcc_root = $0;
 $gcc_root =~ s/[^\\\/]+$/../;
-chdir $gcc_root;
 
 # if this is a git tree then take name and email from the git configuration
-if (-d .git) {
+if (-d "$gcc_root/.git") {
   $gitname = `git config user.name`;
   chomp($gitname);
   if ($gitname) {
@@ -80,7 +79,7 @@ sub get_clname ($) {
 	my $dirname = $_[0];
 	while ($dirname) {
 		my $clname = "$dirname/ChangeLog";
-		if (-f $clname) {
+		if (-f "$gcc_root/$clname") {
 			my $relname = substr ($_[0], length ($dirname) + 1);
 			return ($clname, $relname);
 		} else {

Re: [PATCH 2/2] allow running mklog as a filter

[Yury Gribov]

On 07/21/2014 12:55 PM, Trevor Saunders wrote:

I'm not really sure which is the better UI,
but I'd rather time be spent
on better automatic change log generation.


Yeah. Do you have some particular complaints btw?


I may or may not hope we'll
eventually have a mklog that can autogenerate most ChangeLogs and then
people will have a hard time arguing they're useful.


I wonder how many GCC developers actually use the script (our team does).

-Y

Re: [PATH] Intel offload library

[Andrey Turetskiy]

Ping.

On Mon, Jul 21, 2014 at 1:25 PM, Andrey Turetskiy
 wrote:
> Ping.
>
> On Wed, Jul 2, 2014 at 3:13 PM, Andrey Turetskiy
>  wrote:
>>> * Don't duplicate the logic for what's a hosted POSIX system; refactor it
>>> to a common fragment in config/ (I guess it needs to be a shell script
>>> fragment there rather than an actual autoconf macro, since you're using
>>> that logic in configure.tgt which is itself such a fragment).
>>
>> I've attached the patch with changes related to the point.
>> Do you mean something like this?
>>
>> --
>> Best regards,
>> Andrey Turetskiy
>
>
>
> --
> Best regards,
> Andrey Turetskiy



-- 
Best regards,
Andrey Turetskiy