date:20140714

On Fri, 11 Jul 2014, Jakub Jelinek wrote:

 On Fri, Jul 11, 2014 at 03:36:15PM +0200, Richard Biener wrote:
  *** c_strlen (tree src, int only_value)
  *** 606,612 

  /* If the offset is known to be out of bounds, warn, and call strlen at
 runtime.  */
  !   if (offset  0 || offset  max)
{
 /* Suppress multiple warnings for propagated constant strings.  */
  if (! TREE_NO_WARNING (src))
  --- 610,617 

  /* If the offset is known to be out of bounds, warn, and call strlen at
 runtime.  */
  !   if (only_value != 2
  !(offset  0 || offset  max))
{
 /* Suppress multiple warnings for propagated constant strings.  */
  if (! TREE_NO_WARNING (src))
 
 This looks wrong.  I'd say you only want to disable the warning for
 only_value != 2, but still return NULL_TREE, otherwise the strlen call will
 be out of bounds in the compiler.  So move only_value != 2 down to the
 second if ?

Hmm, yeah.  Probably doesn't matter for this use but I'm testing the
obvious fix.

Richard.

Re: [PATCH] libstdc++: add uniform on sphere distribution

2014-07-14 Thread Andreas Schwab

FAIL: ext/random/arcsine_distribution/cons/default.cc (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20140714/libstdc++-v3/include/ext/random.tcc:1587:22: 
error: '_M_n' was not declared in this scope
/daten/aranym/gcc/gcc-20140714/libstdc++-v3/include/ext/random.tcc:1598:22: 
error: '_M_n' was not declared in this scope

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
And now for something completely different.

Re: [PATCH, i386]: Optimize ix86_atomic_assign_expand_fenv a bit



On 12/07/14 10:07, Uros Bizjak wrote:

Hello!

Attached patch optimizes ix86_atomic_assign_expand_fenv by using
register form of fnstsw %ax instead of fnstsw mem. This way a
memory RW cycle is removed for a temporary.


Hi Uros,

The patch you attached seems to be the hook implementation for alpha...

Kyrill


2014-07-12  Uros Bizjak  ubiz...@gmail.com

 * config/i386/i386-builtin-types.def: Add USHORT_FTYPE_VOID.
 Remove VOID_FTYPE_PUSHORT.
 * config/i386/i386.c (bdesc_special_args) __builtin_ia32_fnstsw:
 Change code to USHORT_FTYPE_VOID.
 (ix86_expand_special_args_builtin): Handle USHORT_FTYPE_VOID.
 (ix86_expand_builtin): Remove IX86_BUILTIN_FNSTSW handling.
 (ix86_atomic_assign_expand_fenv): Update for
 __builtin_ia32_fnstsw changes.
 * config/i386/i386.md (x86_fnstsw_1): Set length unconditionally to 2.
 (fnstsw): Change operand 0 to nonimmediate operand.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32} and
committed to mainline SVN.

Uros.

Re: [PATCH] Fix INSN_TICK heuristic for SCHED_PRESSURE

2014-07-14 Thread Steven Bosscher

On Mon, Jul 14, 2014 at 6:12 AM, Maxim Kuvyrkov wrote:
 Hi,

 This patch fixes 2 of the [several] problems in rank_for_schedule heuristics 
 for SCHED_PRESSURE_MODEL.  SCHED_PRESSURE_MODEL is used for first scheduling 
 pass in ARM backend by default.

 The first one is when INSN_TICK of both instructions are equal, and 
 rank_for_schedule returns a tie result, even though there are more 
 heuristics down the path to break the tie.

 The second one is to account for the fact that model_index() of two 
 instructions is meaningful only when both instructions are in the current 
 basic block.

 Bootstrapped and tested on {x86_64,arm,aarch64}-linux.

 OK to apply?

s/INSN_BB/BLOCK_FOR_INSN/

OK with that change.

Ciao!
Steven

Re: [PATCH] Fix INSN_TICK heuristic for SCHED_PRESSURE

2014-07-14 Thread Maxim Kuvyrkov

On Jul 14, 2014, at 8:05 PM, Steven Bosscher stevenb@gmail.com wrote:

 On Mon, Jul 14, 2014 at 6:12 AM, Maxim Kuvyrkov wrote:
 Hi,
 
 This patch fixes 2 of the [several] problems in rank_for_schedule heuristics 
 for SCHED_PRESSURE_MODEL.  SCHED_PRESSURE_MODEL is used for first scheduling 
 pass in ARM backend by default.
 
 The first one is when INSN_TICK of both instructions are equal, and 
 rank_for_schedule returns a tie result, even though there are more 
 heuristics down the path to break the tie.
 
 The second one is to account for the fact that model_index() of two 
 instructions is meaningful only when both instructions are in the current 
 basic block.
 
 Bootstrapped and tested on {x86_64,arm,aarch64}-linux.
 
 OK to apply?
 
 s/INSN_BB/BLOCK_FOR_INSN/

That would be a mistake, see definition of INSN_BB in sched-int.h.  Scheduler 
uses its own basic block numbering.

 
 OK with that change.

I assume OK without the change?

Thank you,

--
Maxim Kuvyrkov
www.linaro.org

Re: [PATCH, i386]: Optimize ix86_atomic_assign_expand_fenv a bit

2014-07-14 Thread Uros Bizjak

On Mon, Jul 14, 2014 at 10:05 AM, Kyrill Tkachov kyrylo.tkac...@arm.com wrote:

 Attached patch optimizes ix86_atomic_assign_expand_fenv by using
 register form of fnstsw %ax instead of fnstsw mem. This way a
 memory RW cycle is removed for a temporary.

 The patch you attached seems to be the hook implementation for alpha...

Eh, the complete i386 patch follows the alpha hook. I have diffed from
config/ directory instead of config/i386.

Uros.

Re: [PATCH] libstdc++: add uniform on sphere distribution

2014-07-14 Thread Paolo Carlini


Hi,

On 07/14/2014 09:58 AM, Andreas Schwab wrote:

FAIL: ext/random/arcsine_distribution/cons/default.cc (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20140714/libstdc++-v3/include/ext/random.tcc:1587:22: 
error: '_M_n' was not declared in this scope
/daten/aranym/gcc/gcc-20140714/libstdc++-v3/include/ext/random.tcc:1598:22: 
error: '_M_n' was not declared in this scope
Ulrich please fix those _M_n to __x._M_n and remove the obsolete 
comments. We could also add the usual minimal set of tests exercising 
serialization. Thanks.


Paolo.

Re: [RFC] Making fold-const sane WRT symbol visibilities

2014-07-14 Thread Andreas Schwab

Jan Hubicka hubi...@ucw.cz writes:

   * cgraph.h (symtab_node): Add nonzero_address.
   (decl_in_symtab_p): Break out from ...
   (symtab_get_node): ... here.
   * fold-const.c: Include cgraph.h
   (tree_single_nonzero_warnv_p): Use symtab to determine
   if symbol is non-zero.
   * symtab.c (symtab_node::nonzero_address): New method.

   * gcc.dg/pr36901.h: Simplify because non-zero symbol folding no
   longer happens during parsing.
   * gcc.dg/pr44024.c: Update template.
   * g++.dg/tree-ssa/nonzero-2.C: New testcase.
   * g++.dg/tree-ssa/nonzero-1.C: New testcase.
   * gcc.dg/tree-ssa/nonzero-1.c: New testcase.

FAIL: g++.dg/cpp0x/static_assert9.C  -std=c++11 (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20140714/gcc/testsuite/g++.dg/cpp0x/static_assert9.C:5:1: 
error: non-constant condition for static assertion
/daten/aranym/gcc/gcc-20140714/gcc/testsuite/g++.dg/cpp0x/static_assert9.C:5:1: 
error: '(f != 0u)' is not a constant expression

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
And now for something completely different.

Re: [RFC] Making fold-const sane WRT symbol visibilities

 Jan Hubicka hubi...@ucw.cz writes:
 
  * cgraph.h (symtab_node): Add nonzero_address.
  (decl_in_symtab_p): Break out from ...
  (symtab_get_node): ... here.
  * fold-const.c: Include cgraph.h
  (tree_single_nonzero_warnv_p): Use symtab to determine
  if symbol is non-zero.
  * symtab.c (symtab_node::nonzero_address): New method.
 
  * gcc.dg/pr36901.h: Simplify because non-zero symbol folding no
  longer happens during parsing.
  * gcc.dg/pr44024.c: Update template.
  * g++.dg/tree-ssa/nonzero-2.C: New testcase.
  * g++.dg/tree-ssa/nonzero-1.C: New testcase.
  * gcc.dg/tree-ssa/nonzero-1.c: New testcase.
 
 FAIL: g++.dg/cpp0x/static_assert9.C  -std=c++11 (test for excess errors)
 Excess errors:
 /daten/aranym/gcc/gcc-20140714/gcc/testsuite/g++.dg/cpp0x/static_assert9.C:5:1:
  error: non-constant condition for static assertion
 /daten/aranym/gcc/gcc-20140714/gcc/testsuite/g++.dg/cpp0x/static_assert9.C:5:1:
  error: '(f != 0u)' is not a constant expression

Ah, sorry, missed this one.  I think the error is correct (based on earlier 
discussion we can
not really expect addresses of symbols to be non-NULL), so I would just update 
the testcase?

Honza
 
 Andreas.
 
 -- 
 Andreas Schwab, SUSE Labs, sch...@suse.de
 GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
 And now for something completely different.

Re: Move DECL_ARGUMENTS into tree_function_decl

 Hi,
 this patch moves DECL_ARGUMENTS into FUNCTION_DECL.  For this I needed to 
 solve
 reuse in C++ and objC frontends.  In C++ I think I actually run out of places
 to use for TEMPLATE_DECL (well, perhaps DECL_ATTRIBUTES but I would definitely
 run out of pointers fro DECL_RESULT I want to move next) so I decided to go
 ahead and allow lang frontends to make their own structures for their own 
 decls
 as we currently support for exceptional trees.
 
 This allows me to make TEMPLATE_DECL decl_common and save there quite few 
 pointers
 that go with decl_non_common (rtl, assembler name, symtab etc).
 
 I think other DECL_NON_COMMON declarations in C++ FE can now be put on the 
 diet
 too.
 
 In objc I simply used DECL_SIZE. I have noticed that the accesors was never
 updated for type checking and added these (sincerely hope I won't be asked to
 fix bugs found by those at daily basis).
 
 Similarly objc can use some custom layouts for the decls, but I did not do it.
 
 THe added tree_size langhook is there only becuase I changed generic code to
 die when lang does not handle its decls correctly.
 
 Ada/C++/Fortran do not add its own decl trees.
 
 Honza
 
   * tree.c (tree_code_size): Add TRANSLATION_UNIT_DECL,
   NAMESPACE_DECL, IMPORTED_DECL and NAMELIST_DECL;
   call langhook for unknown declaration.
   (find_decls_types_r): Do not walk DECL_ARGUMENT_FLD.
   * tree.h (DECL_ARGUMENTS): Update.
   * print-tree.c (print_node): Update.
   * tree-core.h (tree_decl_non_common): Remove arguments.
   (tree_function_decl): Add arguments.
 
   * class.c (build_clone): Do not clear assembler names of
   templates.
   * decl.c (cp_tree_node_structure): Add TEMPLATE_DECL.
   * cp-objcp-common.c (cp_tree_size): Add TEMPLATE_DECL
   as a special case return sizeof (struct tree_decl_non_common)
   for other decls.
   (cp_common_init_ts): Do not initialize NAMESPACE_DECL;
   initialize TEMPLATE_DECL as MARK_TS_DECL_COMMON.
   * cp/cp-tree.h (tree_template_decl): New structure.
   (cp_tree_node_structure_enum): Add TS_CP_TEMPLATE_DECL.
   (union cp_lang_tree_node): Add template_decl.
   (DECL_TEMPLATE_PARMS, DECL_TEMPLATE_RESULT): Update.
 
   * lto/lto.c (mentions_vars_p_decl_non_common): Skip
   DECL_ARGUMENT_FLD.
   mentions_vars_p_function): Do DECL_ARGUMENTS.
   (lto_fixup_prevailing_decls): Update.
 
   * objc-act.c (objc_common_tree_size): New function.
   * objc-act.h (KEYWORD_KEY_NAME, KEYWORD_ARG_NAME): Add type
   checking.
   (INSTANCE_METHOD_OR_CLASS_METHOD_DECL_CHECK): New macro.
   (METHOD_SEL_NAME, METHOD_SEL_ARGS, METHOD_ADD_ARGS,
   METHOD_ADD_ARGS_ELLIPSIS_P, METHOD_DEFINITION, METHOD_ENCODING,
   METHOD_TYPE_ATTRIBUTES, METHOD_PROPERTY_CONTEXT): Add type checking.
   (METHOD_SEL_ARGS): Use decl_common.size instead of
   decl_non_common.result.
   (PROPERTY_NAME, PROPERTY_GETTER_NAME, PROPERTY_SETTER_NAME,
   PROPERTY_READONLY, PROPERTY_NONATOMIC, PROPERTY_ASSIGN_SEMANTICS,
   PROPERTY_IVAR_NAME, PROPERTY_DYNAMIC, PROPERTY_HAS_NO_GETTER,
   PROPERTY_HAS_NO_SETTER, PROPERTY_OPTIONAL): Add type checking.
   (objc_common_tree_size): Declare.
   * objc/objc-lang.c (LANG_HOOKS_TREE_SIZE): New macro.

Ping...
I would really like to finish the transition here and decompose
decl_non_common/decl_with_vis so we can get the inehriatance hiearchy more
explicit.

Honza

Re: [PING][PATCH] Fix for PR 61561

2014-07-14 Thread Christophe Lyon

On 14 July 2014 09:45, Marat Zakirov m.zaki...@samsung.com wrote:
 Unfortunately, I didn't reproduce the issue...

 Could you please provide full info? Including gcc trunk version, configure
 line, failed test command line.

 Thank you.

I'm not at office, so I am not going to be able to provide full details.
However, the trunk version is the one where you committed your patch.
configure: --target arm-none-linux-gnueabihf --with-thumb
should be sufficient, then just make check and look at the results of
the test you introduced.


Christophe.

 --Marat


 On 07/11/2014 11:19 PM, Christophe Lyon wrote:

 The new testcase causes an ICE when the compile is configured
 --with-thumb or when forcing -mthumb.

 Christophe.


 On 11 July 2014 11:08, Marat Zakirov m.zaki...@samsung.com wrote:

 Thank to you all.

 Committed revision 212450.

 --Marat


  Original Message 
 Subject:Re: [PING][PATCH] Fix for PR 61561
 Date:   Thu, 10 Jul 2014 14:01:24 +0100
 From:   Ramana Radhakrishnan ramana.radhakrish...@arm.com
 To: Marat Zakirov m.zaki...@samsung.com, gcc-patches@gcc.gnu.org
 gcc-patches@gcc.gnu.org
 CC: Richard Earnshaw richard.earns...@arm.com, Kyrylo Tkachov
 kyrylo.tkac...@arm.com, Slava Garbuzov v.garbu...@samsung.com, Yuri
 Gribov tetra2...@gmail.com, mara...@gmail.com mara...@gmail.com





 On 30/06/14 16:21, Marat Zakirov wrote:


 Thank for your attention.


 This is OK for trunk - Sorry about the delayed response.

 Ramana

 Marat.

Re: [patch,libgfortran] Bug 61632 - memory corruption when writing formatted data

2014-07-14 Thread Janne Blomqvist

On Mon, Jul 14, 2014 at 12:39 AM, Jerry DeLisle jvdeli...@charter.net wrote:
 Hi all,

 This bug was caused by an access to an invalid pointer offset to the format
 string. This was only a problem on the second error using the same format
 string.  I suspect it has to do with caching the format strings.  Regardless,
 the patch fixes this by using the fortran style string lengths to calculate 
 the
 position in the string where the error occurs.

 Test case attached.

 Regression tested on x86-64.

 OK for trunk?

Ok, thanks.


 2014-07-12  Jerry DeLisle  jvdeli...@gcc.gnu.org

 PR libgfortran/61632
 * io/format.c (format_error): Avoid invalid string pointer by
 using the fortran string length values to generate error string.



-- 
Janne Blomqvist

Re: [wwwdocs] Clarify and simplify how to get SVN write access

2014-07-14 Thread Gerald Pfeifer

On Tue, 8 Jul 2014, Gerald Pfeifer wrote:
 A couple of us noticed, over time, that our instructions on who
 can sponsor SVN write access and how to get it are not as clear
 as they could be.  This tries to improve that.

Further clarifications and strengthening the Else part based
on feedback from CGF.

Gerald

Index: svnwrite.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/svnwrite.html,v
retrieving revision 1.32
diff -u -r1.32 svnwrite.html
--- svnwrite.html   8 Jul 2014 00:15:20 -   1.32
+++ svnwrite.html   14 Jul 2014 08:17:19 -
@@ -36,14 +36,14 @@
 be sponsored by an existing maintainer (someone with write after approval
 is not sufficient)./p
 
-pIf you already have an account on sourceware.org, ask
+pIf you already have an account on sourceware.org/gcc.gnu.org, ask
 codeoverse...@gcc.gnu.org/code to add access to the GCC repository.
 Include the name of your sponsor and CC: her.
-Else use a
+If you do not have an account yet, use a
 href=http://sourceware.org/cgi-bin/pdw/ps_form.cgi;this form/a,
 again specifying your sponsor./p
 
-pOnce we have this information we will set up an account on
+pWe will then provision you on  
 codegcc.gnu.org/code and inform you by mail. At this point,
 check out a tree using the instructions below and add yourself
 to the MAINTAINERS file.  Note: Your first and last names emmust/em

[PATCH] Fix PR61757, bogus jump threading


The following reverts the proper part of the loop depth dependent
copy-propagation restriction patch.  The canonicalization that
record_equality does is important for correctness when threading
over backedges (that must be accidential?  I can't see how it
might not be possible to trigger this without the change).

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Release-checking bootstrap on x86_64-unknown-linux-gnu in progress,
bootstrap on i586-linux-gnu in progress.

Richard.

2014-07-14  Richard Biener  rguent...@suse.de

PR tree-optimization/61757
PR tree-optimization/61783
* tree-ssa-dom.c (record_equality): Revert canonicalization
change and add comment.
(propagate_rhs_into_lhs): Revert previous fix, removing
loop depth restriction again.

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

Index: gcc/testsuite/gcc.dg/torture/pr61757.c
===
--- gcc/testsuite/gcc.dg/torture/pr61757.c  (revision 0)
+++ gcc/testsuite/gcc.dg/torture/pr61757.c  (working copy)
@@ -0,0 +1,33 @@
+/* { dg-do run } */
+
+extern void abort (void);
+
+struct X { void *p; int res; } a[32];
+
+int foo (unsigned i, unsigned n, void *q)
+{
+  if (i + 1  n  q == a[i + 1].p)
+{
+  do {
+ ++i;
+  } while (i  n  q == a[i].p);
+  --i;
+  return a[i].res;
+}
+  else
+return a[i].res;
+}
+
+int main ()
+{
+  int x;
+  a[0].p = x;
+  a[0].res = -1;
+  a[1].p = x;
+  a[1].res = 1;
+  a[2].p = (void *)0;
+  a[2].res = 0;
+  if (foo (0, 3, x) != 1)
+abort ();
+  return 0;
+}
Index: gcc/tree-ssa-dom.c
===
--- gcc/tree-ssa-dom.c  (revision 212510)
+++ gcc/tree-ssa-dom.c  (working copy)
@@ -1589,6 +1589,33 @@ record_const_or_copy (tree x, tree y)
   record_const_or_copy_1 (x, y, prev_x);
 }
 
+/* Return the loop depth of the basic block of the defining statement of X.
+   This number should not be treated as absolutely correct because the loop
+   information may not be completely up-to-date when dom runs.  However, it
+   will be relatively correct, and as more passes are taught to keep loop info
+   up to date, the result will become more and more accurate.  */
+
+static int
+loop_depth_of_name (tree x)
+{
+  gimple defstmt;
+  basic_block defbb;
+
+  /* If it's not an SSA_NAME, we have no clue where the definition is.  */
+  if (TREE_CODE (x) != SSA_NAME)
+return 0;
+
+  /* Otherwise return the loop depth of the defining statement's bb.
+ Note that there may not actually be a bb for this statement, if the
+ ssa_name is live on entry.  */
+  defstmt = SSA_NAME_DEF_STMT (x);
+  defbb = gimple_bb (defstmt);
+  if (!defbb)
+return 0;
+
+  return bb_loop_depth (defbb);
+}
+
 /* Similarly, but assume that X and Y are the two operands of an EQ_EXPR.
This constrains the cases in which we may treat this as assignment.  */
 
@@ -1608,7 +1635,10 @@ record_equality (tree x, tree y)
  long as we canonicalize on one value.  */
   if (is_gimple_min_invariant (y))
 ;
-  else if (is_gimple_min_invariant (x))
+  else if (is_gimple_min_invariant (x)
+  /* ???  When threading over backedges the following is important
+ for correctness.  See PR61757.  */
+  || (loop_depth_of_name (x) = loop_depth_of_name (y)))
 prev_x = x, x = y, y = prev_x, prev_x = prev_y;
   else if (prev_x  is_gimple_min_invariant (prev_x))
 x = y, y = prev_x, prev_x = prev_y;
@@ -2638,33 +2668,6 @@ get_lhs_or_phi_result (gimple stmt)
 gcc_unreachable ();
 }
 
-/* Return the loop depth of the basic block of the defining statement of X.
-   This number should not be treated as absolutely correct because the loop
-   information may not be completely up-to-date when dom runs.  However, it
-   will be relatively correct, and as more passes are taught to keep loop info
-   up to date, the result will become more and more accurate.  */
-
-static int
-loop_depth_of_name (tree x)
-{
-  gimple defstmt;
-  basic_block defbb;
-
-  /* If it's not an SSA_NAME, we have no clue where the definition is.  */
-  if (TREE_CODE (x) != SSA_NAME)
-return 0;
-
-  /* Otherwise return the loop depth of the defining statement's bb.
- Note that there may not actually be a bb for this statement, if the
- ssa_name is live on entry.  */
-  defstmt = SSA_NAME_DEF_STMT (x);
-  defbb = gimple_bb (defstmt);
-  if (!defbb)
-return 0;
-
-  return bb_loop_depth (defbb);
-}
-
 /* Propagate RHS into all uses of LHS (when possible).
 
RHS and LHS are derived from STMT, which is passed in solely so
@@ -2680,8 +2683,7 @@ static void
 propagate_rhs_into_lhs (gimple stmt, tree lhs, tree rhs, bitmap 
interesting_names)
 {
   /* First verify that propagation is valid.  */
-  if (may_propagate_copy (lhs, rhs)
-   loop_depth_of_name (lhs) = loop_depth_of_name (rhs))
+  if (may_propagate_copy (lhs, rhs))
 {

[PATCH] Fix release checking bootstrap


Committed as obvious.

Richard.

2014-07-14  Richard Biener  rguent...@suse.de

* cgraph.h (decl_in_symtab_p): Make inline.

Index: gcc/cgraph.h
===
--- gcc/cgraph.h(revision 212510)
+++ gcc/cgraph.h(working copy)
@@ -1154,7 +1154,7 @@ extern void change_decl_assembler_name (
 /* Return true if DECL should have entry in symbol table if used.
Those are functions and static  external veriables*/
 
-static bool
+static inline bool
 decl_in_symtab_p (const_tree decl)
 {
   return (TREE_CODE (decl) == FUNCTION_DECL

Re: [PATCH][sched-deps] Generalise usage of macro fusion to work on any two insns



On 11/07/14 14:20, Alexander Monakov wrote:

On Fri, 11 Jul 2014, Kyrill Tkachov wrote:

On 10/07/14 22:53, Maxim Kuvyrkov wrote:

The patch looks good to me, but some cleanup suggestions below.

Thanks, here's an updated patch.
How's this?

You need to remove 'if (targetm. ...) SCHED_GROUP_P (insn) = 1;' from the
first if branch, keeping only one SCHED_GROUP_P assignment at the end of the
function.

Alexander


Thanks for the pointer, I had hurried a bit.
Here is the updated patch.

Kyrill

2014-07-14  Ramana Radhakrishnan ramana.radhakrish...@arm.com
Kyrylo Tkachov  kyrylo.tkac...@arm.com

* sched-deps.c (try_group_insn): Generalise macro fusion hook usage
to any two insns.  Update comment.  Rename to sched_macro_fuse_insns.
(sched_analyze_insn): Update use of try_group_insn to
sched_macro_fuse_insns.
* config/i386/i386.c (ix86_macro_fusion_pair_p): Reject 2nd arguments
that are not conditional jumps.commit 643a8658f1788de2301d9d6a0457979c06afbdf9
Author: Kyrylo Tkachov kyrylo.tkac...@arm.com
Date:   Fri Jun 13 11:41:41 2014 +0100

[sched-deps] Generalise macro fusion hook usage

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 1b5cbeb..6951ddd 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -25820,6 +25820,9 @@ ix86_macro_fusion_pair_p (rtx condgen, rtx condjmp)
   rtx compare_set = NULL_RTX, test_if, cond;
   rtx alu_set = NULL_RTX, addr = NULL_RTX;
 
+  if (!any_condjump_p (condjmp))
+return false;
+
   if (get_attr_type (condgen) != TYPE_TEST
get_attr_type (condgen) != TYPE_ICMP
get_attr_type (condgen) != TYPE_INCDEC
diff --git a/gcc/sched-deps.c b/gcc/sched-deps.c
index 7cafc8b..ae2fff2 100644
--- a/gcc/sched-deps.c
+++ b/gcc/sched-deps.c
@@ -2820,35 +2820,42 @@ sched_analyze_2 (struct deps_desc *deps, rtx x, rtx insn)
 sched_deps_info-finish_rhs ();
 }
 
-/* Try to group comparison and the following conditional jump INSN if
-   they're already adjacent. This is to prevent scheduler from scheduling
-   them apart.  */
+/* Try to group two fuseable insns together to prevent scheduler
+   from scheduling them apart.  */
 
 static void
-try_group_insn (rtx insn)
+sched_macro_fuse_insns (rtx insn)
 {
-  unsigned int condreg1, condreg2;
-  rtx cc_reg_1;
   rtx prev;
 
-  if (!any_condjump_p (insn))
-return;
+  if (any_condjump_p (insn))
+{
+  unsigned int condreg1, condreg2;
+  rtx cc_reg_1;
+  targetm.fixed_condition_code_regs (condreg1, condreg2);
+  cc_reg_1 = gen_rtx_REG (CCmode, condreg1);
+  prev = prev_nonnote_nondebug_insn (insn);
+  if (!reg_referenced_p (cc_reg_1, PATTERN (insn))
+  || !prev
+  || !modified_in_p (cc_reg_1, prev))
+return;
+}
+  else
+{
+  rtx insn_set = single_set (insn);
 
-  targetm.fixed_condition_code_regs (condreg1, condreg2);
-  cc_reg_1 = gen_rtx_REG (CCmode, condreg1);
-  prev = prev_nonnote_nondebug_insn (insn);
-  if (!reg_referenced_p (cc_reg_1, PATTERN (insn))
-  || !prev
-  || !modified_in_p (cc_reg_1, prev))
-return;
+  prev = prev_nonnote_nondebug_insn (insn);
+  if (!prev
+  || !insn_set
+  || !single_set (prev)
+  || !modified_in_p (SET_DEST (insn_set), prev))
+return;
 
-  /* Different microarchitectures support macro fusions for different
- combinations of insn pairs.  */
-  if (!targetm.sched.macro_fusion_pair_p
-  || !targetm.sched.macro_fusion_pair_p (prev, insn))
-return;
+}
+
+  if (targetm.sched.macro_fusion_pair_p (prev, insn))
+SCHED_GROUP_P (insn) = 1;
 
-  SCHED_GROUP_P (insn) = 1;
 }
 
 /* Analyze an INSN with pattern X to find all dependencies.  */
@@ -2877,7 +2884,7 @@ sched_analyze_insn (struct deps_desc *deps, rtx x, rtx insn)
   /* Group compare and branch insns for macro-fusion.  */
   if (targetm.sched.macro_fusion_p
targetm.sched.macro_fusion_p ())
-try_group_insn (insn);
+sched_macro_fuse_insns (insn);
 
   if (may_trap_p (x))
 /* Avoid moving trapping instructions across function calls that might

[PATCH][ARM] Handle clz, rbit types in arm pipeline descriptions


Hi all,

I noticed that we don't have scheduling information for the clz and rbit 
instructions in any of the arm pipeline

models except the Cortex-A8 one.

This patch adds those insn types to the relevant models. They're treated 
as simple ALU operations.


Tested arm-none-eabi.

Ok for trunk?

Thanks,
Kyrill

2014-07-14  Kyrylo Tkachov  kyrylo.tkac...@arm.com

* config/arm/cortex-a15.md (cortex_a15_alu): Handle clz, rbit.
* config/arm/cortex-a5.md (cortex_a5_alu): Likewise.
* config/arm/cortex-a53.md (cortex_a53_alu): Likewise.
* config/arm/cortex-a7.md (cortex_a7_alu_reg): Likewise.
* config/arm/cortex-a9.md (cortex_a9_dp): Likewise.
* config/arm/cortex-m4.md (cortex_m4_alu): Likewise.
* config/arm/cortex-r4.md (cortex_r4_alu): Likewise.commit 6aea17465cba2980f803bc3e8e8dbee5fded68a4
Author: Kyrylo Tkachov kyrylo.tkac...@arm.com
Date:   Thu Jul 10 10:58:14 2014 +0100

[ARM] Add clz, rbit types in pipeline descriptions

diff --git a/gcc/config/arm/cortex-a15.md b/gcc/config/arm/cortex-a15.md
index 28f5dc4..209d872 100644
--- a/gcc/config/arm/cortex-a15.md
+++ b/gcc/config/arm/cortex-a15.md
@@ -64,7 +64,7 @@
(eq_attr type alu_imm,alus_imm,logic_imm,logics_imm,\
 alu_reg,alus_reg,logic_reg,logics_reg,\
 adc_imm,adcs_imm,adc_reg,adcs_reg,\
-adr,bfm,rev,\
+adr,bfm,clz,rbit,rev,\
 shift_imm,shift_reg,\
 mov_imm,mov_reg,\
 mvn_imm,mvn_reg,\
diff --git a/gcc/config/arm/cortex-a5.md b/gcc/config/arm/cortex-a5.md
index eed098e..8b037ae 100644
--- a/gcc/config/arm/cortex-a5.md
+++ b/gcc/config/arm/cortex-a5.md
@@ -61,7 +61,7 @@
(eq_attr type alu_imm,alus_imm,logic_imm,logics_imm,\
 alu_reg,alus_reg,logic_reg,logics_reg,\
 adc_imm,adcs_imm,adc_reg,adcs_reg,\
-adr,bfm,rev,\
+adr,bfm,clz,rbit,rev,\
 shift_imm,shift_reg,\
 mov_imm,mov_reg,mvn_imm,mvn_reg,\
 mrs,multiple,no_insn))
diff --git a/gcc/config/arm/cortex-a53.md b/gcc/config/arm/cortex-a53.md
index 72262d7..7fd7b1a 100644
--- a/gcc/config/arm/cortex-a53.md
+++ b/gcc/config/arm/cortex-a53.md
@@ -75,7 +75,7 @@
(eq_attr type alu_imm,alus_imm,logic_imm,logics_imm,\
 alu_reg,alus_reg,logic_reg,logics_reg,\
 adc_imm,adcs_imm,adc_reg,adcs_reg,\
-adr,bfm,csel,rev,\
+adr,bfm,csel,clz,rbit,rev,\
 shift_imm,shift_reg,\
 mov_imm,mov_reg,mvn_imm,mvn_reg,\
 mrs,multiple,no_insn))
diff --git a/gcc/config/arm/cortex-a7.md b/gcc/config/arm/cortex-a7.md
index 8291d7f..2613750 100644
--- a/gcc/config/arm/cortex-a7.md
+++ b/gcc/config/arm/cortex-a7.md
@@ -137,7 +137,7 @@
   (and (eq_attr tune cortexa7)
(eq_attr type alu_reg,alus_reg,logic_reg,logics_reg,\
 adc_imm,adcs_imm,adc_reg,adcs_reg,\
-bfm,rev,\
+bfm,clz,rbit,rev,\
 shift_imm,shift_reg,mov_reg,mvn_reg))
   cortex_a7_ex1)
 
diff --git a/gcc/config/arm/cortex-a9.md b/gcc/config/arm/cortex-a9.md
index a96..a47813d 100644
--- a/gcc/config/arm/cortex-a9.md
+++ b/gcc/config/arm/cortex-a9.md
@@ -83,7 +83,7 @@ cortex_a9_p1_e2 + cortex_a9_p0_e1 + cortex_a9_p1_e1)
(eq_attr type alu_imm,alus_imm,logic_imm,logics_imm,\
 alu_reg,alus_reg,logic_reg,logics_reg,\
 adc_imm,adcs_imm,adc_reg,adcs_reg,\
-adr,bfm,rev,\
+adr,bfm,clz,rbit,rev,\
 shift_imm,shift_reg,\
 mov_imm,mov_reg,mvn_imm,mvn_reg,\
 mov_shift_reg,mov_shift,\
diff --git a/gcc/config/arm/cortex-m4.md b/gcc/config/arm/cortex-m4.md
index 690ce75..7b59353 100644
--- a/gcc/config/arm/cortex-m4.md
+++ b/gcc/config/arm/cortex-m4.md
@@ -34,7 +34,7 @@
(ior (eq_attr type alu_imm,alus_imm,logic_imm,logics_imm,\
  alu_reg,alus_reg,logic_reg,logics_reg,\
  adc_imm,adcs_imm,adc_reg,adcs_reg,\
- adr,bfm,rev,\
+ adr,bfm,clz,rbit,rev,\
  shift_imm,shift_reg,extend,\
  alu_shift_imm,alus_shift_imm,\
  logic_shift_imm,logics_shift_imm,\
diff --git a/gcc/config/arm/cortex-r4.md b/gcc/config/arm/cortex-r4.md
index f000124..6e420ef 100644
--- a/gcc/config/arm/cortex-r4.md
+++ b/gcc/config/arm/cortex-r4.md
@@ -81,7 +81,7 @@
(eq_attr type alu_imm,alus_imm,logic_imm,logics_imm,\
 alu_reg,alus_reg,logic_reg,logics_reg,\

Re: possible negative patch for gcc/tree-ssa-loop-im.c (or removal of an assert)

On Fri, Jul 11, 2014 at 6:41 PM, Gaius Mulley
gaius.mul...@southwales.ac.uk wrote:


 Hello,

 I've been looking through tree-ssa-loop-im.c (while hunting down a bug
 in the modula-2 front end) and found a curiosity in
 gcc/tree-ssa-loop-im.c.

 It seems that there is dead code in function determine_max_movement
 as mem_ref_in_stmt can never return NULL.

?

static mem_ref_p
mem_ref_in_stmt (gimple stmt)
{
  bool store;
  tree *mem = simple_mem_ref_in_stmt (stmt, store);
  hashval_t hash;
  mem_ref_p ref;

  if (!mem)
return NULL;

and simple_mem_ref_in_stmt _can_ return NULL.

Richard.



 static mem_ref_p
 mem_ref_in_stmt (gimple stmt)
 {
   ...

   gcc_assert (ref != NULL);
   return ref;
 }

 so the patch below could logically be applied as the else statement is
 currently unreachable.



 --- tree-ssa-loop-im.c.orig 2014-07-11 16:54:41.0 +0100
 +++ tree-ssa-loop-im.c  2014-07-11 16:55:38.0 +0100
 @@ -798,21 +798,11 @@
  {
mem_ref_p ref = mem_ref_in_stmt (stmt);

 -  if (ref)
 -   {
 - lim_data-max_loop
 - = outermost_indep_loop (lim_data-max_loop, loop, ref);
 - if (!lim_data-max_loop)
 -   return false;
 -   }
 -  else
 -   {
 - if ((val = gimple_vuse (stmt)) != NULL_TREE)
 -   {
 - if (!add_dependency (val, lim_data, loop, false))
 -   return false;
 -   }
 -   }
 +  gcc_assert (ref != NULL);
 +  lim_data-max_loop
 +   = outermost_indep_loop (lim_data-max_loop, loop, ref);
 +  if (!lim_data-max_loop)
 +   return false;
  }

lim_data-cost += stmt_cost (stmt);


 However my question is whether the assert in mem_ref_in_stmt is correct?
 Since the author of determine_max_movement must have thought ref could
 be NULL.

 Anyhow, it seems that either the above patch should be applied or the
 'gcc_assert (ref != NULL);' from mem_ref_p should be removed.

 regards,
 Gaius

[PATCH][ARM] Enable arm target in ira-shrinkwrap-prep* testcases

2014-07-14 Thread Jiong Wang


currently the following testcases are disabled for arm target,

gcc.dg/ira-shrinkwrap-prep-1.c
gcc.dg/ira-shrinkwrap-prep-2.c
gcc.dg/pr10474.c
 


the reason is on arm target, register r3 is caller-saved.  Normally it does
not need to be saved on entry by the prologue.  However if we choose to save
it for padding then we may confuse the compiler into thinking a prologue 
sequence
is required when in fact it is not.  This will occur when shrink-wrapping if r3
is used as a scratch register and there are no other callee-saved writes.

This situation can be avoided when other callee-saved registers are available
and r3 is not mandatory if we choose a callee-saved register for padding.


Dejagnu improvements
===
-UNSUPPORTED: gcc.dg/ira-shrinkwrap-prep-1.c
-UNSUPPORTED: gcc.dg/ira-shrinkwrap-prep-2.c
+PASS: gcc.dg/ira-shrinkwrap-prep-1.c (test for excess errors)
+PASS: gcc.dg/ira-shrinkwrap-prep-1.c scan-rtl-dump ira Will split live ranges of 
parameters
+PASS: gcc.dg/ira-shrinkwrap-prep-1.c scan-rtl-dump ira Split live-range of 
register
+PASS: gcc.dg/ira-shrinkwrap-prep-1.c scan-rtl-dump pro_and_epilogue Performing 
shrink-wrapping
+PASS: gcc.dg/ira-shrinkwrap-prep-2.c (test for excess errors)
+PASS: gcc.dg/ira-shrinkwrap-prep-2.c scan-rtl-dump ira Will split live ranges of 
parameters
+PASS: gcc.dg/ira-shrinkwrap-prep-2.c scan-rtl-dump ira Split live-range of 
register
+PASS: gcc.dg/ira-shrinkwrap-prep-2.c scan-rtl-dump pro_and_epilogue Performing 
shrink-wrapping
-UNSUPPORTED: gcc.dg/pr10474.c
+PASS: gcc.dg/pr10474.c (test for excess errors)
+PASS: gcc.dg/pr10474.c scan-rtl-dump pro_and_epilogue Performing 
shrink-wrapping

ok for trunk ?

thanks.

-- Jiong

gcc/
  * config/arm/arm.c (arm_get_frame_offsets): If both r3 and other callee-saved
registers are available for padding purpose, and r3 is not mandatory, then
prefer use those callee-saved instead of r3.

gcc/testsuite/
  * gcc.dg/ira-shrinkwrap-prep-1.c (target): Add arm_nothumb
  * gcc.dg/ira-shrinkwrap-prep-2.c (target): Add arm_nothumb
  * gcc.dg/pr10474.c (target): Add arm_nothumb
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 78cae73..d33c62c 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -20780,30 +20780,47 @@ arm_get_frame_offsets (void)
 	{
 	  int reg = -1;

+	  /* Register r3 is caller-saved.  Normally it does not need to be
+	 saved on entry by the prologue.  However if we choose to save
+	 it for padding then we may confuse the compiler into thinking
+	 a prologue sequence is required when in fact it is not.  This
+	 will occur when shrink-wrapping if r3 is used as a scratch
+	 register and there are no other callee-saved writes.
+
+	 This situation can be avoided when other callee-saved registers
+	 are available and r3 is not mandatory if we choose a callee-saved
+	 register for padding.  */
+	  bool prefer_callee_reg_p = false;
+
 	  /* If it is safe to use r3, then do so.  This sometimes
 	 generates better code on Thumb-2 by avoiding the need to
 	 use 32-bit push/pop instructions.  */
   if (! any_sibcall_could_use_r3 ()
 	   arm_size_return_regs () = 12
 	   (offsets-saved_regs_mask  (1  3)) == 0
-   (TARGET_THUMB2
+	   (TARGET_THUMB2
 		  || !(TARGET_LDRD  current_tune-prefer_ldrd_strd)))
 	{
 	  reg = 3;
+	  if (!(TARGET_LDRD  current_tune-prefer_ldrd_strd))
+		prefer_callee_reg_p = true;
+	}
+	  if (reg == -1
+	  || prefer_callee_reg_p)
+	{
+	  for (i = 4; i = (TARGET_THUMB1 ? LAST_LO_REGNUM : 11); i++)
+		{
+		  /* Avoid fixed registers; they may be changed at
+		 arbitrary times so it's unsafe to restore them
+		 during the epilogue.  */
+		  if (!fixed_regs[i]
+		   (offsets-saved_regs_mask  (1  i)) == 0)
+		{
+		  reg = i;
+		  break;
+		}
+		}
 	}
-	  else
-	for (i = 4; i = (TARGET_THUMB1 ? LAST_LO_REGNUM : 11); i++)
-	  {
-		/* Avoid fixed registers; they may be changed at
-		   arbitrary times so it's unsafe to restore them
-		   during the epilogue.  */
-		if (!fixed_regs[i]
-		 (offsets-saved_regs_mask  (1  i)) == 0)
-		  {
-		reg = i;
-		break;
-		  }
-	  }

 	  if (reg != -1)
 	{
diff --git a/gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-1.c b/gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-1.c
index fc7b142..5360844 100644
--- a/gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-1.c
+++ b/gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-1.c
@@ -1,4 +1,4 @@
-/* { dg-do compile { target { { x86_64-*-*  lp64 } || { powerpc*-*-*  lp64 } } } } */
+/* { dg-do compile { target { { x86_64-*-*  lp64 } || { { powerpc*-*-*  lp64 } || arm_nothumb } } } } */
 /* { dg-options -O3 -fdump-rtl-ira -fdump-rtl-pro_and_epilogue -fno-use-caller-save  } */

 long __attribute__((noinline, noclone))
diff --git a/gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-2.c b/gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-2.c
index 2e5a9cf..d242cac 100644
---

Re: [PATCH][ARM] Handle clz, rbit types in arm pipeline descriptions

2014-07-14 Thread Richard Earnshaw

On 14/07/14 11:04, Kyrill Tkachov wrote:
 Hi all,
 
 I noticed that we don't have scheduling information for the clz and rbit 
 instructions in any of the arm pipeline
 models except the Cortex-A8 one.
 
 This patch adds those insn types to the relevant models. They're treated 
 as simple ALU operations.
 
 Tested arm-none-eabi.
 
 Ok for trunk?
 
OK.

R.

 Thanks,
 Kyrill
 
 2014-07-14  Kyrylo Tkachov  kyrylo.tkac...@arm.com
 
  * config/arm/cortex-a15.md (cortex_a15_alu): Handle clz, rbit.
  * config/arm/cortex-a5.md (cortex_a5_alu): Likewise.
  * config/arm/cortex-a53.md (cortex_a53_alu): Likewise.
  * config/arm/cortex-a7.md (cortex_a7_alu_reg): Likewise.
  * config/arm/cortex-a9.md (cortex_a9_dp): Likewise.
  * config/arm/cortex-m4.md (cortex_m4_alu): Likewise.
  * config/arm/cortex-r4.md (cortex_r4_alu): Likewise.

Re: [PATCH] Extended if-conversion for loops marked with pragma omp simd.

2014-07-14 Thread Yuri Rumyantsev

Ping!

2014-06-25 18:06 GMT+04:00 Yuri Rumyantsev ysrum...@gmail.com:
 Hi All,

 We implemented additional support for pragma omp simd in part of
 extended if-conversion loops with such pragma. These extensions
 include:

 1. All extensions are performed only if considered loop or its outer
loop was marked with pragma omp simd (force_vectorize); For ordinary
loops behavior was not changed.
 2. Took off cfg restriction on basic block which can have more than 2
predecessors.
 3. Put additional restriction on phi nodes which was missed in current design:
all phi nodes must be in non-predicated basic block to conform
semantic of COND_EXPR which is used for transformation.
 4. Extend predication of phi nodes: phi may have more than 2 arguments
 with some limitations:
- for phi nodes which have more than 2 arguments, but only two
arguments are different and one of them has the only occurence,
 transformation to  single COND_EXPR can be done.
- if phi node has more different arguments and all edge predicates
correspondent to phi-arguments are disjoint, a chain of COND_EXPR
will be generated for it. In current design very simple check is used:
check starting from end that two edges correspondent to neighbor
 arguments have common predecessor which is used for further check
 with next edge.
  These guarantee that phi predication will produce the correct result.

 Here is example of such extended predication (compile with -march=core-avx2):
 #pragma omp simd safelen(8)
   for (i=0; i512; i++)
   {
 float t = a[i];
 if (t  0  t  1.0e+17f)
   if (c[i] != 0)
 res += 1;
   }
   bb 4:
   # res_15 = PHI res_1(5), 0(3)
   # i_16 = PHI i_11(5), 0(3)
   # ivtmp_17 = PHI ivtmp_14(5), 512(3)
   t_5 = a[i_16];
   _6 = t_5  0.0;
   _7 = t_5  9.998430674944e+16;
   _8 = _7  _6;
   _ifc__28 = (unsigned int) _8;
   _10 = c[i_16];
   _ifc__36 = _ifc__28 != 0 ? 4294967295 : 0;
   _9 = MASK_LOAD (_10, 0B, _ifc__36);
   _ifc__29 = _ifc__28 != 0 ? 1 : 0;
   _ifc__30 = (int) _ifc__29;
   _ifc__31 = _9 != 0 ? _ifc__30 : 0;
   _ifc__32 = _ifc__28 != 0 ? 1 : 0;
   _ifc__33 = (int) _ifc__32;
   _ifc__34 = _9 == 0 ? _ifc__33 : 0;
   _ifc__35 = _ifc__31 != 0 ? 1 : 0;
   res_1 = res_15 + _ifc__35;
   i_11 = i_16 + 1;
   ivtmp_14 = ivtmp_17 - 1;
   if (ivtmp_14 != 0)
 goto bb 4;

 Bootstrap and regression testing did not show any new failures.

 gcc/ChageLog

 2014-06-25  Yuri Rumyantsev  ysrum...@gmail.com

 * tree-if-conv.c (flag_force_vectorize): New variable.
 (struct bb_predicate_s): Add negate_predicate field.
 (bb_negate_predicate): New function.
 (set_bb_negate_predicate): New function.
 (bb_copy_predicate): New function.
 (add_stmt_to_bb_predicate_gimplified_stmts): New function.
 (init_bb_predicate): Add initialization of negate_predicate field.
 (reset_bb_predicate): Reset negate_predicate to NULL_TREE.
 (convert_name_to_cmp): New function.
 (get_type_for_cond): New function.
 (convert_bool_predicate): New function.
 (predicate_disjunction): New function.
 (predicate_conjunction): New function.
 (add_to_predicate_list): Add convert_bool argument.
 Add call of predicate_disjunction if convert_bool argument is true.
 (add_to_dst_predicate_list): Add convert_bool argument.
 Add early function exit if edge target block is always executed.
 Add call of predicate_conjunction if convert_bool argument is true.
 Pass convert_bool argument for add_to_predicate_list.
 (equal_phi_args): New function.
 (phi_has_two_different_args): New function.
 (phi_args_disjoint): New function.
 (if_convertible_phi_p): Accept phi nodes with more than two args
 for loops marked with pragma omp simd. Add check that phi nodes are
 in non-predicated basic blocks.
 (ifcvt_can_use_mask_load_store): Use flag_force_vectorize.
 (all_edges_are_critical): New function.
 (if_convertible_bb_p): Allow bb has more than two predecessors if
 flag_force_vectorize was setup. Use call of all_edges_are_critical
 to reject block if-conversion with imcoming critical edges only if
 flag_force_vectorize was not setup.
 (walk_cond_tree): New function.
 (vect_bool_pattern_is_applicable): New function.
 (predicate_bbs): Add convert_bool argument that is used to transform
 comparison expressions of boolean type into conditional expressions
 with integral operands. If bool_conv argument is false or both
 outgoing edges are not critical old algorithm of predicate assignments
 is used, otherwise the following code was added: check on applicable
 of vect-bool-pattern recognition and trnasformation of
 (bool) x != 0  -- y = (int) x; x != 0;
 compute predicates for both outgoing edges one of which is critical
 one using 'normal' edge, i.e. compute true and false predicates using
 normal outgoing edge only; evaluated predicates are stored in
 predicate and negate_predicate fields of struct bb_predicate_s and
 negate_predicate of normal edge conatins predicate of critical edge,
 but generated gimplified statements are stored in their

Re: [MIPS r5900] libgcc floating point fixes

2014-07-14 Thread Richard Sandiford

Jürgen Urban juergenur...@gmx.de writes:
 The problem happens with the r5900 hard float configurations, e.g.:
 configure --target=mipsel-linux-gnu --with-float=hard --with-fpu=single
 --with-arch=r5900
 I created the attached patch which fixes this problem for r5900 and
 another problem explained later.
 The fixed code generates the following code which should be correct
 (mipsr5900el-ps2-elf):

 00105440 __extendsfdf2:
   105440:   27bdffc8addiu   sp,sp,-56
   105444:   27a40028addiu   a0,sp,40
   105448:   27a50018addiu   a1,sp,24
   10544c:   afbf0034sw  ra,52(sp)
   105450:   0c0417b5jal 105ed4 __unpack_f
   105454:   e7ac0028swc1$f12,40(sp)
   105458:   8fa20024lw  v0,36(sp)
   10545c:   8fa40018lw  a0,24(sp)
   105460:   8fa5001clw  a1,28(sp)
   105464:   8fa60020lw  a2,32(sp)
   105468:   00021882srl v1,v0,0x2
   10546c:   00021780sll v0,v0,0x1e
   105470:   afa20010sw  v0,16(sp)
   105474:   0c041789jal 105e24 __make_dp
   105478:   afa30014sw  v1,20(sp)
   10547c:   8fbf0034lw  ra,52(sp)
   105480:   03e8jr  ra
   105484:   27bd0038addiu   sp,sp,56

 The default targets mipsr5900el and mips64r5900el are not affected by
 the problem, because soft float is the default.

 It also seems that the same problem occurs with the following configuration:
 configure --target=mipsel-linux-gnu --with-float=hard --with-fpu=single
 I expected that this combination should work and a problem should
 already be detected. Can somebody confirm that the problem also occurs
 with default mipsel?

Although that configuration is in theory supported by GCC (said like that
because I don't know the state of the glibc support for single-float),
I don't think anyone uses it for any target other than r5900.  But you're
right that this is a --with-fpu=single thing rather than an r5900 thing,
so I don't think the patch is correct.  It should be keyed off whether
the target is single-float or double-float, which you can test by
checking whether the preprocessor macro __mips_single_float is defined.

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.

Thanks,
Richard

Re: [PATCH] libstdc++: add uniform on sphere distribution

2014-07-14 Thread Dominique Dhumieres

 I've checked in a patch to save the _M_n state.

If it is r212496, did you test it?

It breaks many tests (see 
https://gcc.gnu.org/ml/gcc-regression/2014-07/msg00213.html)

/opt/gcc/work/libstdc++-v3/include/ext/random.tcc: In function 
'std::basic_ostream_CharT, _Traits 
__gnu_cxx::operator(std::basic_ostream_CharT, _Traits, const 
__gnu_cxx::uniform_on_sphere_distribution_Dimen, _RealType)':
/opt/gcc/work/libstdc++-v3/include/ext/random.tcc:1587:22: error: '_M_n' was 
not declared in this scope
   return __os  _M_n;
  ^
/opt/gcc/work/libstdc++-v3/include/ext/random.tcc: In function 
'std::basic_istream_CharT, _Traits 
__gnu_cxx::operator(std::basic_istream_CharT, _Traits, 
__gnu_cxx::uniform_on_sphere_distribution_Dimen, _RealType)':
/opt/gcc/work/libstdc++-v3/include/ext/random.tcc:1598:22: error: '_M_n' was 
not declared in this scope
   return __is  _M_n
  ^

TIA

Dominique

Re: [GSoC] Addition of ISL AST generation to Graphite



On 05/07/14 21:20, Rainer Orth wrote:

Rainer Orth r...@cebitec.uni-bielefeld.de writes:


Roman Gareev gareevro...@gmail.com writes:


It seems the patch1/patch2 files you attach have the Content-Type:
application/octet-stream. This makes it impossible to view them inline.
Could you send them as text files? Just calling them patch1.patch or
patch1.txt should make this work.

Yes, sure.

This patch broke bootstrap with --enable-cloog-backend=isl when using
isl 0.10:

/vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:27:27: fatal 
error: isl/ast_build.h: No such file or directory
compilation terminated.
make[3]: *** [graphite-isl-ast-to-gimple.o] Error 1

isl/ast_build.h is missing in in isl 0.10.  Seems it was introduced in
0.11, but no idea if that works.

Toplevel configure.ac accepts 0.10, while install.texi states 0.12.2 is
required.  Configuration and/or docs should be changed to match reality.

I've now commited the following patch as obvious: it requires isl 0.11
which is the first that includes isl/ast_build.h.

I'm seeing the error:

gcc/graphite-isl-ast-to-gimple.c:31:25: warning: isl/val_gmp.h: No such file or 
directory

when building for aarch64.

isl/val_gmp.h is included in 0.12 AFAICS so perhaps we should demand 0.12 
instead of 0.11 ?

Kyrill





Bootstrapped on i386-pc-solaris2.11 with isl 0.12.2.

Rainer


2014-07-05  Rainer Orth  r...@cebitec.uni-bielefeld.de

* configure.ac: Don't accept isl 0.10.
* configure: Regenerate.

Re: [PATCH][RFC] Fix PR61473, inline small memcpy/memmove during tree opts

On Mon, 14 Jul 2014, Richard Biener wrote:

 On Fri, 11 Jul 2014, Jakub Jelinek wrote:
 
  On Fri, Jul 11, 2014 at 03:36:15PM +0200, Richard Biener wrote:
   *** c_strlen (tree src, int only_value)
   *** 606,612 
 
   /* If the offset is known to be out of bounds, warn, and call strlen 
   at
  runtime.  */
   !   if (offset  0 || offset  max)
 {
  /* Suppress multiple warnings for propagated constant strings.  */
   if (! TREE_NO_WARNING (src))
   --- 610,617 
 
   /* If the offset is known to be out of bounds, warn, and call strlen 
   at
  runtime.  */
   !   if (only_value != 2
   !(offset  0 || offset  max))
 {
  /* Suppress multiple warnings for propagated constant strings.  */
   if (! TREE_NO_WARNING (src))
  
  This looks wrong.  I'd say you only want to disable the warning for
  only_value != 2, but still return NULL_TREE, otherwise the strlen call will
  be out of bounds in the compiler.  So move only_value != 2 down to the
  second if ?
 
 Hmm, yeah.  Probably doesn't matter for this use but I'm testing the
 obvious fix.

Fixed like so, bootstrapped and tested on x86_64-unknown-linux-gnu.

Richard.

2014-07-14  Richard Biener  rguent...@suse.de

* builtins.c (c_strlen): Make only_value == 2 really only
affect warning generation.

Index: gcc/builtins.c
===
--- gcc/builtins.c  (revision 212513)
+++ gcc/builtins.c  (working copy)
@@ -610,11 +610,11 @@ c_strlen (tree src, int only_value)
 
   /* If the offset is known to be out of bounds, warn, and call strlen at
  runtime.  */
-  if (only_value != 2
-   (offset  0 || offset  max))
+  if (offset  0 || offset  max)
 {
  /* Suppress multiple warnings for propagated constant strings.  */
-  if (! TREE_NO_WARNING (src))
+  if (only_value != 2
+  !TREE_NO_WARNING (src))
 {
   warning_at (loc, 0, offset outside bounds of constant string);
   TREE_NO_WARNING (src) = 1;

[PATCH] Testcases for PR61786


Fixed by the PR61757 fix.

Richard.

2014-06-14  Richard Biener  rguent...@suse.de

PR tree-optimization/61786
* gcc.dg/torture/pr61786.c: New testcase.
* gcc.dg/lto/pr61786_0.c: Likewise.
* gcc.dg/lto/pr61786_1.c: Likewise.

Index: gcc/testsuite/gcc.dg/torture/pr61786.c
===
--- gcc/testsuite/gcc.dg/torture/pr61786.c  (revision 0)
+++ gcc/testsuite/gcc.dg/torture/pr61786.c  (working copy)
@@ -0,0 +1,31 @@
+/* { dg-do run } */
+
+int a, *c = a, d; 
+char b = 1;
+
+void
+fn1 ()
+{
+  d = 1;
+lbl:
+  if (b == d)
+{
+  d = *c;
+  if (b)
+   goto lbl;
+}
+}
+
+int
+fn2 ()
+{
+  fn1 ();
+  return 0;
+}
+
+int
+main ()
+{
+  fn2 ();
+  return 0;
+}
Index: gcc/testsuite/gcc.dg/lto/pr61786_1.c
===
--- gcc/testsuite/gcc.dg/lto/pr61786_1.c(revision 0)
+++ gcc/testsuite/gcc.dg/lto/pr61786_1.c(working copy)
@@ -0,0 +1,8 @@
+int fn2 (void);
+
+int
+main ()
+{
+  fn2 ();
+  return 0;
+}
Index: gcc/testsuite/gcc.dg/lto/pr61786_0.c
===
--- gcc/testsuite/gcc.dg/lto/pr61786_0.c(revision 0)
+++ gcc/testsuite/gcc.dg/lto/pr61786_0.c(working copy)
@@ -0,0 +1,27 @@
+/* { dg-lto-do run } */
+/* { dg-lto-options { { -flto } } } */
+/* { dg-extra-ld-options -O } */
+
+int a, *c = a, d;
+char b = 1;
+
+void
+fn1 (void)
+{
+  d = 1;
+lbl:
+  if (b == d)
+{
+  d = *c;
+  if (b)
+   goto lbl;
+}
+}
+
+int
+fn2 (void)
+{
+  fn1 ();
+  return 0;
+}
+

Re: [PATCH] Generate more efficient memory barriers for LEON3

2014-07-14 Thread Daniel Cederman

LEON3 has a store buffer of length 1, so an additional store is required 
to be sure that the one preceding it has been written to memory. I am 
not familiar enough with the internals of gcc to pick the optimal place 
to encode this behavior, so any suggestions from you are appreciated :)


On 2014-07-12 11:18, Eric Botcazou wrote:

That was an error on my side. The wrong memory model had gotten cached
in a generated make script. Lets drop membar_leon3 also then :)


Fine with me but, on second thoughts, if a mere stb is a #StoreLoad memory
barrier for LEON3, doesn't this simply mean that the memory model of the LEON3
is Strong Consistency and not TSO?  In which case, the only thing to change is
the default setting for LEON3 in sparc_option_override.



--
Daniel Cederman

RE: [Patch, avr] Add atmel ata5782 and ata5831 devices

2014-07-14 Thread S, Pitchumani

 -Original Message-
 From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org]
 On Behalf Of Denis Chertykov
 Sent: Friday, July 11, 2014 9:53 PM
 To: S, Pitchumani
 Cc: gcc-patches@gcc.gnu.org; Georg-Johann Lay
 Subject: Re: [Patch, avr] Add atmel ata5782 and ata5831 devices

 2014-07-11 12:50 GMT+04:00 S, Pitchumani pitchuman...@atmel.com:
  This patch adds supports for Atmel's ata5782 and ata5831 devices.

  These devices ISA matches with AVR5 architecture except that text
 section
  start for these two devices is 0x8000. By default 0x0 is used as the
 text
  start address. This patch adds a device attribute for text start and
 that
  is passed to Linker via -Ttext option.

  If OK, could someone commit please?

  Regards,
  Pitchumani

  2014-07-11  Pitchumani Sivanupandi  pitchuman...@atmel.com

  * config/avr/avr-arch.h (avr_mcu_t): Add text section start
 attribute.
  * config/avr/avr-devices.c (AVR_MCU): Same.
  (avr_mcu_types): add text start value to end of device list.
  * config/avr/avr-mcus.def: Add text section start for all devices.
  (ata5782): Add new avr5 device.
  (ata5831): Same.
  * config/avr/avr-tables.opt: Regenerate.
  * config/avr/avr.h: Add declaration for text section start handler.
  (EXTRA_SPEC_FUNCTIONS): Add text section start handler to SPEC
 functions.
  (LINK_SPEC): Include text section start handler to linker spec.
  * config/avr/driver-avr.c (avr_device_to_text_start): New function
 to
  pass -Ttext option to linker if the text section start for the
 device is
  not zero.
  * config/avr/t-multilib: Regenerate.
  * doc/avr-mmcu.texi: Regenerate.

 Committed.

Hi Denis,

Thanks.

It seems you missed to include gcc/doc/avr-mmcu.texi file changes.

Regards,
Pitchumani

Re: [PATCH] Implement -fsanitize=object-size

2014-07-14 Thread Jakub Jelinek

On Sun, Jul 13, 2014 at 07:55:44PM +0200, Marek Polacek wrote:
 2014-07-13  Marek Polacek  pola...@redhat.com
 
   * ubsan.h (struct ubsan_mismatch_data):

Missing description.


 +/* Expand UBSAN_OBJECT_SIZE internal call.  */
 +
 +void
 +ubsan_expand_objsize_ifn (gimple_stmt_iterator *gsi)
 +{
 +  gimple stmt = gsi_stmt (*gsi);
 +  location_t loc = gimple_location (stmt);
 +  gcc_assert (gimple_call_num_args (stmt) == 4);
 +
 +  tree base = gimple_call_arg (stmt, 0);
 +  tree ptr = gimple_call_arg (stmt, 1);
 +  tree size = gimple_call_arg (stmt, 2);
 +  tree ckind = gimple_call_arg (stmt, 3);
 +  gimple_stmt_iterator gsi_orig = *gsi;
 +  gimple g;
 +
 +  gcc_assert (TREE_CODE (size) == INTEGER_CST);
 +  /* See if we can discard the check.  */
 +  if (tree_to_uhwi (size) == (unsigned HOST_WIDE_INT) -1)

This would be integer_all_onesp (size).

 +static void
 +instrument_object_size (gimple_stmt_iterator *gsi, bool is_lhs)
 +{
 +  gimple stmt = gsi_stmt (*gsi);
 +  location_t loc = gimple_location (stmt);
 +  tree t = is_lhs ? gimple_get_lhs (stmt) : gimple_assign_rhs1 (stmt);
 +
 +  if (TREE_CODE (t) != MEM_REF)
 +return;

I think this is undesirable.  IMHO you want to call here
get_inner_reference, and if the given size is equal to maxsize, consider
instrumenting it, otherwise you don't instrument e.g. COMPONENT_REFs and
many other things.  Look at what e.g. asan.c or even ubsan.c does; the
question is what exactly to do with bitfields, but supposedly we should
require that the DECL_BIT_FIELD_REPRESENTATIVE is accessible in that case.

Also, I wonder if using base, ptr, objsz, ckind arguments are best for the
builtin, I'd think you want instead base, ptr+size-base, objsz, ckind.
Reasons:
a) the size addition when expanding UBSAN_OBJECT_SIZE will not work
   reliably, the middle end considers all pointer conversions useless,
   so you can very well end up with a different TREE_TYPE of the pointer
   type
b) sanopt runs very late, there aren't many GIMPLE optimization passes,
   so to optimize the condition checks you pretty much rely on RTL passes
c) for e.g. gimple_fold_call it will be much easier if it can remove
   redundant UBSAN_OBJECT_SIZE calls if it can just compare two constants

 +  tree ptr = TREE_OPERAND (t, 0);
 +  tree sizet, base = ptr;
 +  gimple g;
 +  gimple def_stmt;
 +
 +  while (TREE_CODE (base) == SSA_NAME)
 +{
 +  def_stmt = SSA_NAME_DEF_STMT (base);
 +  if (is_gimple_assign (def_stmt))
 + base = gimple_assign_rhs1 (def_stmt);

This looks too dangerous.  All you should look through are:
a) gimple_assign_ssa_name_copy_p
b) gimple_assign_cast_p if the rhs1 also has POINTER_TYPE_P
c) gimple_assign_rhs_code == POINTER_PLUS_EXPR

I'm also including a testcase, which shows why instrumenting
also COMPONENT_REFs etc. is important (see my reference to
get_inner_reference above) and also that IMHO we should instrument
not just when the base is a pointer, but also when it is a decl,
but in that case we should avoid instrumenting when -fsanitize=bounds
is on and we know it will handle it (in particular, if there was e.g.
char d[8]; int e; in the struct definition instead).

Note, the testcase ICEs with -O2 -fsanitize=bounds, can you please look
at that first and fix it separately?

struct S { int a; int b; };
struct T { int c; char d[]; };

static inline __attribute__((always_inline)) int
foo (struct S *p)
{
  return p-b;
}

int
bar (void)
{
  struct S *p = __builtin_calloc (sizeof (int) + sizeof (int) / 2, 1);
  return foo (p);
}

struct T t = { 1, abcdefg };

int
baz (int i)
{
  return t.d[i];
}

Other comments, in a form of a patch:
1) the gimple_fold_call bit shows that we should for the quite common
   case where __bos is folded into -1 remove the UBSAN_OBJECT_SIZE call
   immediately, not worth keeping it around through many other passes
2) if you add -O2 to the dg-options, that just means the tests are done
   8 times or how many with -O2 all the time.  Better skip it unless
   -O2
3) when the second argument is something that can be directly compared
   against the third argument, you can in gimple_fold_call fold not just
   the don't know cases, but also when the third argument is = the
   second and both are INTEGER_CSTs - then we know at compile time
   we are ok.

--- gcc/gimple-fold.c.jj2014-07-07 10:39:45.0 +0200
+++ gcc/gimple-fold.c   2014-07-14 12:41:15.419687543 +0200
@@ -1209,6 +1209,15 @@ gimple_fold_call (gimple_stmt_iterator *
gimple_call_arg (stmt, 1),
gimple_call_arg (stmt, 2));
  break;
+case IFN_UBSAN_OBJECT_SIZE:
+ if (integer_all_onesp (gimple_call_arg (stmt, 2)))
+   {
+ gsi_replace (gsi, gimple_build_nop (), true);
+ unlink_stmt_vdef (stmt);
+ release_defs (stmt);
+ return true;
+   }
+ break;
case IFN_UBSAN_CHECK_ADD:
  subcode =

Re: [GSoC] symbol to denote multiple operators

On Fri, Jul 11, 2014 at 4:59 PM, Prathamesh Kulkarni
bilbotheelffri...@gmail.com wrote:
 On 7/11/14, Richard Biener richard.guent...@gmail.com wrote:
 On Thu, Jul 10, 2014 at 8:05 PM, Prathamesh Kulkarni
 bilbotheelffri...@gmail.com wrote:
 Hi,
I have attempted to add syntax for symbol to denote multiple
 operators.

 I tried it with few bogus patterns and it appears to work hopefully
 -:)
 eg: (bogus pattern):
 (for op in plus minus
   (match_and_simplify
 (op @0 @1)
 (op @0 @0)))

 generates following patterns:
 (plus @0 @1) - (plus @0 @0)  // simplify_0
 (plus @0 @1) - (mult @0 @0)  // simplify_1
 (mult @0 @1) - (plus @0 @0)  // simplify_2
 (mult @0 @1) - (mult @0 @0)  // simplify_3

 s/mult/minus/?  I think it should only generate

  (plus @0 @1) - (plus @0 @0)
  (minus @0 @1) - (minus @0 @0)

 to get the what you write we should need to write

  (for op1 in plus minus
(for op2 in plus minus
  (match_and_simplify
 (op1 @0 @1)
 (op2 @0 @0

 root (0xab6b10), 0, 2
 |--(PLUS_EXPR) (0xab6b30), 1, 1
 |true (0xab6ba0), 2, 1
 |--true (0xab6c10), 3, 2
 |simplify_0 { 0xab6ba0, 0xab6c10, (nil), (nil),  }  (0xab6c80), 4,
 0
 |simplify_1 { 0xab6ba0, 0xab6c10, (nil), (nil),  }  (0xab6d40), 4,
 0
 |--(MULT_EXPR) (0xab6d00), 1, 1
 |true (0xab6d90), 2, 1
 |--true (0xab6e00), 3, 2
 |simplify_2 { 0xab6d90, 0xab6e00, (nil), (nil),  }  (0xab6e70), 4,
 0
 |simplify_3 { 0xab6d90, 0xab6e00, (nil), (nil),  }  (0xab6f30), 4,
 0

 * Changes to rest of the code:
 a) commutating patterns was interfering with this, because
 parse_match_and_simplify, immediately commutated match operand. Symbol
 should be replaced by operators before commutating. This required
 adjusting simplify (back to operand *match), and commutating is done
 in new function lower_commutative. Ideally this should be done during
 insertion in decision tree ?

 Yes, commutating should be done by inserting a pattern multiple
 times with adjusted AST walk order.

 b) adjustments required to e_operation constructor, so it doesn't
 call fatal, when it does not find id to be in the hash table.

 Eventually just temporarily insert a new operator in the hash table
 when parsing comes along a (for OP ...?  That is, add a new kind,
 USER and just re-use base-id?

 * Caveats
 a) new e_operation constructor taking id_base * argument. Not sure
 if that's required.
 b) e_operation::user_id denotes user-defined identifier (opname),
 a rather apologetic name ...
 c) Similar to commutate(), replace_user_id() does not clone AST's.
 So we have multiple AST's sharing same nodes.

 I wonder if we want to parse the 'for' into an AST node instead,
 thus not expand it on-the-fly.  Applying could then happen during
 DT insertion.  Or as a separate lowering like you introduce
 lower_commutative - that looks  cleaner.

 Or if we can simply parse the match-and-simplify multiple times, with
 the for op replaces, using _cpp_backup_tokens.  Ok, no - that
 sounds like too much of a hack.

 * add multiple symbols ?
 should we have
 (for opname in operator-list1, opname2 in operator-list2
   (match_and_simplify
  ...))
 or have nested for ?
 (for opname in operator-list1
(for opname2 in operator-list2
(match_and_simplify
   )))

 It depends on the desired semantics.  It's a lot clearer with
 single opname for only (but then we eventually need nested for).

 * we don't detect functions with wrong arguments
 for example, we dont give error on:
 (built_in_sqrt @0 @1)
 I guess that's because we don't have an easy way to figure out
 number of arguments a function expects ?
 (is there a built-in equivalent of tree_code_length[] ?)

 Yeah, the function stuff is still very simplistic and no, there isn't
 any easy way of extracting the number of expected arguments
 from builtins.def (it's encoded in the type).  The easiest way
 would be to change builtins.def to add a number-of-args argument ...

 Let's just defer that issue.


 As for the patch, we shouldn't do the cartesian_product - that's
 hardly ever what the user intends and it means there isn't any
 way of repeating the same pattern for multiple operators.

 A common use for 'for' would be (for OP in ne eq (...)) as most
 equality foldings are valid for ne and eq.  Another is
 for the various division kinds we have - trunc_div ceil_div floor_div
 and round_div (same for mod):

 (for op in trunc_div ceil_div floor_div round_div
   (match_and_simplify
  (op @0 integer_onep)
  @0))

 (good example for match.pd to exercise the code)

 Can you fix the cartesian product thing (it should only simplify the
 patch)?
 This version of the patch, removes cartesian_product, and reuses
 id_base::id for user-defined symbols.

 eg:
 (for op in plus minus
   (match_and_simplify
 (op (op @0 @1) @2)
 (op @0 @0)))

 generates following patterns:
 (plus (plus @0 @1) @2) - (plus @0 @0)
 (minus (minus @0 @1) @2) - (minus @0 @0)
 Is this

Re: [GSoC][match-and-simplify] Add DEBUG_FUNCTION attribute

On Sun, Jul 13, 2014 at 2:31 PM, Prathamesh Kulkarni
bilbotheelffri...@gmail.com wrote:
 This patch adds DEBUG_FUNCTION attribute to print_* functions
 in genmatch.c

Thanks, applied.

Richard.

 * genmatch.c (print_operand): Add attribute DEBUG_FUNCTION.
   (print_matches): Likewise.
   (decision_tree::print_node): Likewise.
   (decision_tree::print): Likewise.

 Thanks and Regards,
 Prathamesh

Re: [GSoC][match-and-simplify] use integral_op_p

On Sun, Jul 13, 2014 at 7:23 PM, Prathamesh Kulkarni
bilbotheelffri...@gmail.com wrote:
 Hi,
This patch uses integral_op_p instead of
 if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))

 * match.pd: Remove INTEGRAL_TYPE_P (TREE_TYPE (@0)) in bitwise
 patterns and use integral_op_p@0

Hmm, so this removes if-exprs and instead uses predicates in the match.
That's probably good as then multiple evaluations of the same predicate
can be avoided in case multiple patterns share the same bit in the
decision tree.

Applied.

Thanks,
Richard.

 Thanks and Regards,
 Prathamesh

[patch, avr] Device macro correction for rev devices

2014-07-14 Thread S, Pitchumani

Attached patch changes the device name macro of two rev devices, from REV
to rev in the name.

Device name macro:
__AVR_ATmega16HVBREVB__
__AVR_ATmega32HVBREVB__

Change to:
__AVR_ATmega16HVBrevB__
__AVR_ATmega32HVBrevB__

'rev' in small letters emphasizes the revision of the device.

If OK, could someone commit please?

Regards,
Pitchumani

gcc/ChangeLog

2014-07-14  Pitchumani Sivanupandi  pitchuman...@atmel.com

* config/avr/avr-mcus.def (atmega16hvbrevb): Change device name macro
to __AVR_ATmega16HVBrevB__.
(atmega32hvbrevb): Change device name macro to __AVR_ATmega32HVBrevB__.



avr-gcc-device-macro-change.patch
Description: avr-gcc-device-macro-change.patch

Re: [PATCH] Extended if-conversion for loops marked with pragma omp simd.

On Mon, Jul 14, 2014 at 12:16 PM, Yuri Rumyantsev ysrum...@gmail.com wrote:
 Ping!

It's in my queue (pretty large patch for a drive-by review - maybe there is
an opportunity to split the patch up?).

Won't get to it before the Cauldron though.

Richard.

 2014-06-25 18:06 GMT+04:00 Yuri Rumyantsev ysrum...@gmail.com:
 Hi All,

 We implemented additional support for pragma omp simd in part of
 extended if-conversion loops with such pragma. These extensions
 include:

 1. All extensions are performed only if considered loop or its outer
loop was marked with pragma omp simd (force_vectorize); For ordinary
loops behavior was not changed.
 2. Took off cfg restriction on basic block which can have more than 2
predecessors.
 3. Put additional restriction on phi nodes which was missed in current 
 design:
all phi nodes must be in non-predicated basic block to conform
semantic of COND_EXPR which is used for transformation.
 4. Extend predication of phi nodes: phi may have more than 2 arguments
 with some limitations:
- for phi nodes which have more than 2 arguments, but only two
arguments are different and one of them has the only occurence,
 transformation to  single COND_EXPR can be done.
- if phi node has more different arguments and all edge predicates
correspondent to phi-arguments are disjoint, a chain of COND_EXPR
will be generated for it. In current design very simple check is used:
check starting from end that two edges correspondent to neighbor
 arguments have common predecessor which is used for further check
 with next edge.
  These guarantee that phi predication will produce the correct result.

 Here is example of such extended predication (compile with -march=core-avx2):
 #pragma omp simd safelen(8)
   for (i=0; i512; i++)
   {
 float t = a[i];
 if (t  0  t  1.0e+17f)
   if (c[i] != 0)
 res += 1;
   }
   bb 4:
   # res_15 = PHI res_1(5), 0(3)
   # i_16 = PHI i_11(5), 0(3)
   # ivtmp_17 = PHI ivtmp_14(5), 512(3)
   t_5 = a[i_16];
   _6 = t_5  0.0;
   _7 = t_5  9.998430674944e+16;
   _8 = _7  _6;
   _ifc__28 = (unsigned int) _8;
   _10 = c[i_16];
   _ifc__36 = _ifc__28 != 0 ? 4294967295 : 0;
   _9 = MASK_LOAD (_10, 0B, _ifc__36);
   _ifc__29 = _ifc__28 != 0 ? 1 : 0;
   _ifc__30 = (int) _ifc__29;
   _ifc__31 = _9 != 0 ? _ifc__30 : 0;
   _ifc__32 = _ifc__28 != 0 ? 1 : 0;
   _ifc__33 = (int) _ifc__32;
   _ifc__34 = _9 == 0 ? _ifc__33 : 0;
   _ifc__35 = _ifc__31 != 0 ? 1 : 0;
   res_1 = res_15 + _ifc__35;
   i_11 = i_16 + 1;
   ivtmp_14 = ivtmp_17 - 1;
   if (ivtmp_14 != 0)
 goto bb 4;

 Bootstrap and regression testing did not show any new failures.

 gcc/ChageLog

 2014-06-25  Yuri Rumyantsev  ysrum...@gmail.com

 * tree-if-conv.c (flag_force_vectorize): New variable.
 (struct bb_predicate_s): Add negate_predicate field.
 (bb_negate_predicate): New function.
 (set_bb_negate_predicate): New function.
 (bb_copy_predicate): New function.
 (add_stmt_to_bb_predicate_gimplified_stmts): New function.
 (init_bb_predicate): Add initialization of negate_predicate field.
 (reset_bb_predicate): Reset negate_predicate to NULL_TREE.
 (convert_name_to_cmp): New function.
 (get_type_for_cond): New function.
 (convert_bool_predicate): New function.
 (predicate_disjunction): New function.
 (predicate_conjunction): New function.
 (add_to_predicate_list): Add convert_bool argument.
 Add call of predicate_disjunction if convert_bool argument is true.
 (add_to_dst_predicate_list): Add convert_bool argument.
 Add early function exit if edge target block is always executed.
 Add call of predicate_conjunction if convert_bool argument is true.
 Pass convert_bool argument for add_to_predicate_list.
 (equal_phi_args): New function.
 (phi_has_two_different_args): New function.
 (phi_args_disjoint): New function.
 (if_convertible_phi_p): Accept phi nodes with more than two args
 for loops marked with pragma omp simd. Add check that phi nodes are
 in non-predicated basic blocks.
 (ifcvt_can_use_mask_load_store): Use flag_force_vectorize.
 (all_edges_are_critical): New function.
 (if_convertible_bb_p): Allow bb has more than two predecessors if
 flag_force_vectorize was setup. Use call of all_edges_are_critical
 to reject block if-conversion with imcoming critical edges only if
 flag_force_vectorize was not setup.
 (walk_cond_tree): New function.
 (vect_bool_pattern_is_applicable): New function.
 (predicate_bbs): Add convert_bool argument that is used to transform
 comparison expressions of boolean type into conditional expressions
 with integral operands. If bool_conv argument is false or both
 outgoing edges are not critical old algorithm of predicate assignments
 is used, otherwise the following code was added: check on applicable
 of vect-bool-pattern recognition and trnasformation of
 (bool) x != 0  -- y = (int) x; x != 0;
 compute predicates for both outgoing edges one of which is critical
 one using 'normal' edge, i.e. compute true and false predicates using

[PATCH] Fix bootstrap with gcc 4.3


Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.

Richard.

2014-07-14  Richard Biener  rguent...@suse.de

* libgcov.h (struct gcov_fn_info): Make ctrs size 1.

Index: libgcc/libgcov.h
===
--- libgcc/libgcov.h(revision 212515)
+++ libgcc/libgcov.h(working copy)
@@ -181,7 +181,7 @@ struct gcov_fn_info
   gcov_unsigned_t ident;   /* unique ident of function */
   gcov_unsigned_t lineno_checksum; /* function lineo_checksum */
   gcov_unsigned_t cfg_checksum;/* function cfg checksum */
-  struct gcov_ctr_info ctrs[0];/* instrumented counters */
+  struct gcov_ctr_info ctrs[1];/* instrumented counters */
 };
 
 /* Type of function used to merge counters.  */

[PATCH] Fix PR61779


The following makes copyprop simplify conditions properly (it's
now also copy-propagating constants, thus more opportunities
arise).  That fixes the testcase which previously failed to
constant-propagate the __builtin_constant_p result into the asm.

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.

Richard.

2014-07-14  Richard Biener  rguent...@suse.de

* tree-ssa-copy.c (copy_prop_visit_cond_stmt): Always try
simplifying a condition.

* gcc.dg/tree-ssa/ssa-copyprop-2.c: New testcase.

Index: gcc/tree-ssa-copy.c
===
--- gcc/tree-ssa-copy.c (revision 212514)
+++ gcc/tree-ssa-copy.c (working copy)
@@ -237,38 +237,26 @@ copy_prop_visit_cond_stmt (gimple stmt,
   enum ssa_prop_result retval = SSA_PROP_VARYING;
   location_t loc = gimple_location (stmt);
 
-  tree op0 = gimple_cond_lhs (stmt);
-  tree op1 = gimple_cond_rhs (stmt);
+  tree op0 = valueize_val (gimple_cond_lhs (stmt));
+  tree op1 = valueize_val (gimple_cond_rhs (stmt));
 
-  /* The only conditionals that we may be able to compute statically
- are predicates involving two SSA_NAMEs.  */
-  if (TREE_CODE (op0) == SSA_NAME  TREE_CODE (op1) == SSA_NAME)
+  /* See if we can determine the predicate's value.  */
+  if (dump_file  (dump_flags  TDF_DETAILS))
 {
-  op0 = valueize_val (op0);
-  op1 = valueize_val (op1);
-
-  /* See if we can determine the predicate's value.  */
-  if (dump_file  (dump_flags  TDF_DETAILS))
-   {
- fprintf (dump_file, Trying to determine truth value of );
- fprintf (dump_file, predicate );
- print_gimple_stmt (dump_file, stmt, 0, 0);
-   }
+  fprintf (dump_file, Trying to determine truth value of );
+  fprintf (dump_file, predicate );
+  print_gimple_stmt (dump_file, stmt, 0, 0);
+}
 
-  /* We can fold COND and get a useful result only when we have
-the same SSA_NAME on both sides of a comparison operator.  */
-  if (op0 == op1)
-   {
- tree folded_cond = fold_binary_loc (loc, gimple_cond_code (stmt),
-  boolean_type_node, op0, op1);
- if (folded_cond)
-   {
- basic_block bb = gimple_bb (stmt);
- *taken_edge_p = find_taken_edge (bb, folded_cond);
- if (*taken_edge_p)
-   retval = SSA_PROP_INTERESTING;
-   }
-   }
+  /* Fold COND and see whether we get a useful result.  */
+  tree folded_cond = fold_binary_loc (loc, gimple_cond_code (stmt),
+ boolean_type_node, op0, op1);
+  if (folded_cond)
+{
+  basic_block bb = gimple_bb (stmt);
+  *taken_edge_p = find_taken_edge (bb, folded_cond);
+  if (*taken_edge_p)
+   retval = SSA_PROP_INTERESTING;
 }
 
   if (dump_file  (dump_flags  TDF_DETAILS)  *taken_edge_p)
Index: gcc/testsuite/gcc.dg/tree-ssa/ssa-copyprop-2.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/ssa-copyprop-2.c  (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/ssa-copyprop-2.c  (working copy)
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options -Og -fdump-tree-optimized } */
+
+extern long long __sdt_unsp;
+void
+f(void)
+{
+  for (;;)
+__asm__ (%0 :: i (((!__extension__ (__builtin_constant_p unsigned 
long long) (__typeof (__builtin_choose_expr (((__builtin_classify_type (0) + 3) 
 -4) == 4, (0), 0U))) __sdt_unsp) ) == 0) )) ? 1 : -1) ));
+}
+
+/* { dg-final { scan-tree-dump-not PHI optimized } } */
+/* { dg-final { cleanup-tree-dump optimized } } */

Re: [RFC] Making fold-const sane WRT symbol visibilities


On 07/14/2014 04:36 AM, Jan Hubicka wrote:

FAIL: g++.dg/cpp0x/static_assert9.C  -std=c++11 (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20140714/gcc/testsuite/g++.dg/cpp0x/static_assert9.C:5:1: 
error: non-constant condition for static assertion
/daten/aranym/gcc/gcc-20140714/gcc/testsuite/g++.dg/cpp0x/static_assert9.C:5:1: 
error: '(f != 0u)' is not a constant expression


Ah, sorry, missed this one.  I think the error is correct (based on earlier 
discussion we can
not really expect addresses of symbols to be non-NULL), so I would just update 
the testcase?


Hmm.  I think the C++ standard says this is constant, and of course 
whether an expression is constant is more significant in C++ because of 
templates and constexpr.  clang doesn't give this error, EDG does.


For C++, my inclination would be to say that if a symbol is declared 
weak, it needs to be declared weak before the first use, just like 
inline functions.


Jason

Re: Move DECL_ARGUMENTS into tree_function_decl


On 06/25/2014 02:51 AM, Jan Hubicka wrote:

@@ -4388,7 +4388,8 @@ build_clone (tree fn, tree name)
clone = copy_decl (fn);
/* Reset the function name.  */
DECL_NAME (clone) = name;
-  SET_DECL_ASSEMBLER_NAME (clone, NULL_TREE);
+  if (TREE_CODE (clone) != TEMPLATE_DECL)
+SET_DECL_ASSEMBLER_NAME (clone, NULL_TREE);


Instead of this, move the SET_DECL_ASSEMBLER_NAME down below the 
template block.


OK with that change.

Jason

Re: [RFC] Making fold-const sane WRT symbol visibilities

2014-07-14 Thread Jakub Jelinek

On Mon, Jul 14, 2014 at 09:50:34AM -0400, Jason Merrill wrote:
 /daten/aranym/gcc/gcc-20140714/gcc/testsuite/g++.dg/cpp0x/static_assert9.C:5:1:
  error: non-constant condition for static assertion
 /daten/aranym/gcc/gcc-20140714/gcc/testsuite/g++.dg/cpp0x/static_assert9.C:5:1:
  error: '(f != 0u)' is not a constant expression
 
 Ah, sorry, missed this one.  I think the error is correct (based on earlier 
 discussion we can
 not really expect addresses of symbols to be non-NULL), so I would just 
 update the testcase?
 
 Hmm.  I think the C++ standard says this is constant, and of course whether
 an expression is constant is more significant in C++ because of templates
 and constexpr.  clang doesn't give this error, EDG does.
 
 For C++, my inclination would be to say that if a symbol is declared weak,
 it needs to be declared weak before the first use, just like inline
 functions.

I'd say that even for C we should require that, and thus for
non-weak symbols expect they are non-NULL, unless
-fno-delete-null-pointer-checks tells us not to.

Jakub

Re: [PATCH, i386] Add prefixes avoidance tuning for silvermont target

2014-07-14 Thread Ilya Enkovich

Ping

2014-07-03 17:38 GMT+04:00 Ilya Enkovich enkovich@gmail.com:
 2014-07-03 16:07 GMT+04:00 Uros Bizjak ubiz...@gmail.com:
 On Thu, Jul 3, 2014 at 1:50 PM, Ilya Enkovich enkovich@gmail.com wrote:

 I didn't find a nice way to fix peephole2 patterns to take register
 constraints into account. Is there any way to do it?

 Use REX_SSE_REGNO_P (REGNO (operands[...])) in the insn C constraint.

 Peephole doesn't know whether it works with tuned instruction or not,
 right? I would need to mark all instructions I modify with some
 attribute and then check for it in peephole.


 Also fully restrict xmm8-15 does not seem right.  It is just costly
 but not fully disallowed.

 As said earlier, you can try Ya*x as a constraint.

 I tried it. It does not seem to affect allocation much. I do not see
 any gain on targeted tests.

 Ilya


 Uros.

[patch] Add libstdc++ type printers for class templates


This defines a new style of Python type printer that recognizes
templates and can be used to omit default template arguments from the
typename GDB prints, e.g. showing std::vectorT, std::allocatorT as
simply std::vectorT.  Additionally, T will get processed by the type
recognizers so if it's a standard typedef or template it will also get
displayed in its abbreviated form.

e.g. with current trunk:

Breakpoint 1, main () at p.cc:45
45std::vectorstd::dequestd::listint nested;
(gdb) whatis nested
type = std::vectorstd::dequestd::listint, std::allocatorint , std::allocatorstd::listint, std::allocatorint   , 
std::allocatorstd::dequestd::listint, std::allocatorint , std::allocatorstd::listint, std::allocatorint 


and with this patch:

(gdb) whatis nested
type = std::vectorstd::dequestd::listint

N.B. I am not printing spaces between the closing angle brackets. If
people prefer I can put them in, or only do it for C++11 types, so
that copying and pasting types from GDB will always work (if you're
copying a C++11 type then you must be planning to use it with a C++11
compiler, which will handle  without spaces).

This passes the python testsuite but I'll wait for comments before
committing, in case my use of the GDB API or Python can be improved by
anyone.
commit 538e6eddc52681d9b3ca8fb5d97f194492ee68da
Author: Jonathan Wakely jwak...@redhat.com
Date:   Thu Jul 10 20:31:11 2014 +0100

	* python/libstdcxx/v6/printers.py (TemplateTypePrinter): Add type
	printer for class templates.
	(register_type_printers): Use TemplateTypePrinter for containers
	and other class templates with default template arguments.
	* testsuite/libstdc++-prettyprinters/whatis.cc: Test new recognizers.

diff --git a/libstdc++-v3/python/libstdcxx/v6/printers.py b/libstdc++-v3/python/libstdcxx/v6/printers.py
index 1fa08fb..ea34f22 100644
--- a/libstdc++-v3/python/libstdcxx/v6/printers.py
+++ b/libstdc++-v3/python/libstdcxx/v6/printers.py
@@ -922,6 +922,57 @@ class Printer(object):
 
 libstdcxx_printer = None
 
+class TemplateTypePrinter(object):
+A type printer for class templates.
+
+Recognizes type names that match a regular expression.
+Replaces them with a formatted string which can use replacement field
+{N} to refer to the \N subgroup of the regex match.
+Type printers are recusively applied to the subgroups.
+
+This allows recognizing e.g. std::vector(.*), std::allocator\\1 
+and replacing it with std::vector{1}, omitting the template argument
+that uses the default type.
+
+
+def __init__(self, name, pattern, subst):
+self.name = name
+self.pattern = re.compile(pattern)
+self.subst = subst
+self.enabled = True
+
+class _recognizer(object):
+def __init__(self, pattern, subst):
+self.pattern = pattern
+self.subst = subst
+self.type_obj = None
+
+def recognize(self, type_obj):
+if type_obj.tag is None:
+return None
+
+m = self.pattern.match(type_obj.tag)
+if m:
+subs = list(m.groups())
+for i, sub in enumerate(subs):
+if ('{%d}' % (i+1)) in self.subst:
+# apply recognizers to subgroup
+rep = gdb.types.apply_type_recognizers(
+gdb.types.get_type_recognizers(),
+gdb.lookup_type(sub))
+if rep:
+subs[i] = rep
+subs = [None] + subs
+return self.subst.format(*subs)
+return None
+
+def instantiate(self):
+return self._recognizer(self.pattern, self.subst)
+
+def add_one_template_type_printer(obj, name, match, subst):
+printer = TemplateTypePrinter(name, '^std::' + match + '$', 'std::' + subst)
+gdb.types.register_type_printer(obj, printer)
+
 class FilteringTypePrinter(object):
 def __init__(self, match, name):
 self.match = match
@@ -1013,6 +1064,56 @@ def register_type_printers(obj):
 add_one_type_printer(obj, 'discard_block_engine', 'ranlux48')
 add_one_type_printer(obj, 'shuffle_order_engine', 'knuth_b')
 
+# Do not show defaulted template arguments in class templates
+add_one_template_type_printer(obj, 'unique_ptrT',
+'unique_ptr(.*), std::default_delete\\1 ? ',
+'unique_ptr{1}')
+
+add_one_template_type_printer(obj, 'dequeT',
+'deque(.*), std::allocator\\1 ? ',
+'deque{1}')
+add_one_template_type_printer(obj, 'forward_listT',
+'forward_list(.*), std::allocator\\1 ? ',
+'forward_list{1}')
+add_one_template_type_printer(obj, 'listT',
+'list(.*), std::allocator\\1 ? ',
+'list{1}')
+add_one_template_type_printer(obj, 'vectorT',
+'vector(.*), std::allocator\\1 ? ',
+'vector{1}')
+

[PATCH, AArch64] Fix type of add_losym_mode

2014-07-14 Thread Richard Earnshaw

Noticed while browsing the code.  The add_losym_mode instruction takes
an immediate field as the third operand.  Hence it's type is alu_imm,
not alu_reg.

Probably doesn't have any major effect on current pipeline models, but
could do one day...

Committed to trunk.

2014-07-14  Richard Earnshaw  rearn...@arm.com

* aarch64.md (add_losym_mode): Set type to alu_imm.diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 3eb783c..ded49a4 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -3790,7 +3790,7 @@
  (match_operand 2 aarch64_valid_symref S)))]
   
   add\\t%w0, %w1, :lo12:%a2
-  [(set_attr type alu_reg)]
+  [(set_attr type alu_imm)]
 )
 
 (define_insn ldr_got_small_mode

Re: [RFC] Making fold-const sane WRT symbol visibilities

 On Mon, Jul 14, 2014 at 09:50:34AM -0400, Jason Merrill wrote:
  /daten/aranym/gcc/gcc-20140714/gcc/testsuite/g++.dg/cpp0x/static_assert9.C:5:1:
   error: non-constant condition for static assertion
  /daten/aranym/gcc/gcc-20140714/gcc/testsuite/g++.dg/cpp0x/static_assert9.C:5:1:
   error: '(f != 0u)' is not a constant expression
  
  Ah, sorry, missed this one.  I think the error is correct (based on 
  earlier discussion we can
  not really expect addresses of symbols to be non-NULL), so I would just 
  update the testcase?
  
  Hmm.  I think the C++ standard says this is constant, and of course whether
  an expression is constant is more significant in C++ because of templates
  and constexpr.  clang doesn't give this error, EDG does.
  
  For C++, my inclination would be to say that if a symbol is declared weak,
  it needs to be declared weak before the first use, just like inline
  functions.
 
 I'd say that even for C we should require that, and thus for
 non-weak symbols expect they are non-NULL, unless
 -fno-delete-null-pointer-checks tells us not to.

OK, I suppose we can't go without bit of code duplication here (at parsing time 
and with symtab built).
Will prepare patch for this.

Honza
   Jakub

Re: Move DECL_ARGUMENTS into tree_function_decl

 On 06/25/2014 02:51 AM, Jan Hubicka wrote:
 @@ -4388,7 +4388,8 @@ build_clone (tree fn, tree name)
 clone = copy_decl (fn);
 /* Reset the function name.  */
 DECL_NAME (clone) = name;
 -  SET_DECL_ASSEMBLER_NAME (clone, NULL_TREE);
 +  if (TREE_CODE (clone) != TEMPLATE_DECL)
 +SET_DECL_ASSEMBLER_NAME (clone, NULL_TREE);
 
 Instead of this, move the SET_DECL_ASSEMBLER_NAME down below the
 template block.
 
 OK with that change.
Thanks a lot!
I wonder how necessary are those DECL_RTL/DECL_ASSEMBLER_NAME hacks
these days. THeoretically those should be computed only late once clonning is 
done.

Honza
 
 Jason

Re: [PATCH, AArch64] Fix type of add_losym_mode



On 14/07/14 15:34, Richard Earnshaw wrote:

Noticed while browsing the code.  The add_losym_mode instruction takes
an immediate field as the third operand.  Hence it's type is alu_imm,
not alu_reg.

Probably doesn't have any major effect on current pipeline models, but
could do one day...

Committed to trunk.

2014-07-14  Richard Earnshaw  rearn...@arm.com

* aarch64.md (add_losym_mode): Set type to alu_imm.

Hi Richard,

Path should be config/aarch64/aarch64.md

Kyrill

[C++ Patch/RFC] PR 60608

2014-07-14 Thread Paolo Carlini


Hi,

I have been looking a bit into this bug, using a reduced testcase which 
simplifies the debugging quite a bit for me (a non-variadic variant is 
ok). I cannot say to already understand all the details of the issue, 
but something which strikes me as interesting, is that the DEDUCE_CALL 
passed down by add_candidate gets lost and we end up calling 
type_unification_real from unify with DEDUCE_EXACT. If I change it to an 
unconditional DEDUCE_CALL, the testcase is accepted and the testsuite 
passes with no regressions. Is that all there is to the issue?!?


Thanks!
Paolo.


Index: cp/pt.c
===
--- cp/pt.c (revision 212510)
+++ cp/pt.c (working copy)
@@ -18198,7 +18198,7 @@ unify (tree tparms, tree targs, tree parm, tree ar
nargs = i;
 
return type_unification_real (tparms, targs, TYPE_ARG_TYPES (parm),
- args, nargs, 1, DEDUCE_EXACT,
+ args, nargs, 1, DEDUCE_CALL,
  LOOKUP_NORMAL, NULL, explain_p);
   }
 
Index: testsuite/g++.dg/cpp0x/variadic161.C
===
--- testsuite/g++.dg/cpp0x/variadic161.C(revision 0)
+++ testsuite/g++.dg/cpp0x/variadic161.C(working copy)
@@ -0,0 +1,14 @@
+// PR c++/60608
+// { dg-do compile { target c++11 } }
+
+templatetypename... Args
+void
+wrapper(void (*)(Args...));
+
+void myfun(int);
+
+void
+test()
+{
+  wrapperconst int(myfun);
+}

Re: [RFC, PATCH 1/n] IPA C++ refactoring

2014-07-14 Thread Martin Liška


Hello

On 07/11/2014 12:07 PM, Jan Hubicka wrote:

Hi,
this first patch continues with rafactoring of IPA infrastructure so that 
we will have C++ API. In the patch, I transformed many global functions to 
members of symtab_node and cgraph_node.

Example:
cgraph_remove_node (struct cgraph_node *node) - cgraph_node::remove (void)
symtab_unregister_node (symtab_node *node) - symtab_node::unregister (void)

The patch is being consulted with Honza and will iterate. We want to inform 
folk that we plan to do following changes.

After the patch is applied, I would like to transform varpool_node and 
cgraph_edge in the following patch.

Thank you for your comments,
Martin
  
  /* Remove the node from cgraph.  */


Perhaps Remove function from symbol table.
(similarly for varpool, perhaps few other block comments needs revisiting.
We may do that incrementally.)
  
+  /* Add node into symbol table.  This function is not used directly, but via

+ cgraph/varpool node creation routines.  */
+  void register_symbol (void);
+
+  /* Remove symtab node from the symbol table.  */
+  void remove (void);
+
+  /* Dump symtab node to F.  */
+  void dump (FILE *f);
+
+  /* Dump symtab node to stderr.  */
+  void DEBUG_FUNCTION debug (void);
+
+  /* Verify consistency of node.  */
+  void DEBUG_FUNCTION verify (void);
+
+  /* Return ipa reference from this symtab_node to
+ REFERED_NODE or REFERED_VARPOOL_NODE. USE_TYPE specify type
+ of the use and STMT the statement (if it exists).  */
+  struct ipa_ref *add_reference (symtab_node *referred_node,
+   enum ipa_ref_use use_type);
+
+  /* Return ipa reference from this symtab_node to
+ REFERED_NODE or REFERED_VARPOOL_NODE. USE_TYPE specify type
+ of the use and STMT the statement (if it exists).  */
+  struct ipa_ref *add_reference (symtab_node *referred_node,
+enum ipa_ref_use use_type, gimple stmt);
+
+  /* If VAL is a reference to a function or a variable, add a reference from
+ this symtab_node to the corresponding symbol table node.  USE_TYPE specify
+ type of the use and STMT the statement (if it exists).  Return the new
+ reference or NULL if none was created.  */
+  struct ipa_ref *maybe_add_reference (tree val, enum ipa_ref_use use_type,
+  gimple stmt);
+
+  /* Clone all references from symtab NODE to this symtab_node.  */
+  void clone_references (symtab_node *node);
+
+  /* Remove all stmt references in non-speculative references.
+ Those are not maintained during inlining  clonning.
+ The exception are speculative references that are updated along
+ with callgraph edges associated with them.  */
+  void clone_referring (symtab_node *node);
+
+  /* Clone reference REF to this symtab_node and set its stmt to STMT.  */
+  struct ipa_ref *clone_reference (struct ipa_ref *ref, gimple stmt);
+
+  /* Find the structure describing a reference to REFERRED_NODE
+ and associated with statement STMT.  */
+  struct ipa_ref *find_reference (symtab_node *, gimple, unsigned int);
+
+  /* Remove all references that are associated with statement STMT.  */
+  void remove_stmt_references (gimple stmt);
+
+  /* Remove all stmt references in non-speculative references.
+ Those are not maintained during inlining  clonning.
+ The exception are speculative references that are updated along
+ with callgraph edges associated with them.  */
+  void clear_stmts_in_references (void);
+
+  /* Remove all references in ref list.  */
+  void remove_all_references (void);
+
+  /* Remove all referring items in ref list.  */
+  void remove_all_referring (void);
+
+  /* Dump references in ref list to FILE.  */
+  void dump_references (FILE *file);
+
+  /* Dump referring in list to FILE.  */
+  void dump_referring (FILE *);
+
+  /* Return true if symtab node and TARGET represents
+ semantically equivalent symbols.  */
+  bool semantically_equivalent_p (symtab_node *target);
+
+  /* Classify symbol symtab node for partitioning.  */
+  enum symbol_partitioning_class get_partitioning_class (void);
+
+  /* Return comdat group.  */
+  tree get_comdat_group ()
+{
+  return x_comdat_group;
+}
+
+  /* Return comdat group as identifier_node.  */
+  tree get_comdat_group_id ()
+{
+  if (x_comdat_group  TREE_CODE (x_comdat_group) != IDENTIFIER_NODE)
+   x_comdat_group = DECL_ASSEMBLER_NAME (x_comdat_group);
+  return x_comdat_group;
+}
+
+  /* Set comdat group.  */
+  void set_comdat_group (tree group)
+{
+  gcc_checking_assert (!group || TREE_CODE (group) == IDENTIFIER_NODE
+  || DECL_P (group));
+  x_comdat_group = group;
+}
+
+  /* Return section as string.  */
+  const char * get_section ()
+{
+  if (!x_section)
+   return NULL;
+  return x_section-name;
+}
+
+  /* Remove node from same comdat group.   */
+  void remove_from_same_comdat_group (void);
+
+  /*

[jit] Reject creating arrays of fieldless structs

2014-07-14 Thread David Malcolm

Committed the following to branch dmalcolm/jit:

Investigating a bug in a project using libgccjit revealed a problem where
fields within a struct within the JIT-created code weren't laid out in the
same places as the supposedly same struct in normally-built code:

  struct foo
  {
int a;
int b;
int c;
  };

  struct bar
  {
int d;
struct foo e[20];
int f; /*  error here */
  };

Field f was erroneously compiled as if e was only 4 bytes in size.

The root cause turned out to be that the client code was creating the
array type for
struct foo e[20]
before the fields of struct foo had been set, hence the call to
layout_type for the array type would fail this conditional:
  2168  /* We need to know both bounds in order to compute the size.  */
  2169  if (index  TYPE_MAX_VALUE (index)  TYPE_MIN_VALUE (index)
  2170   TYPE_SIZE (element))
because TYPE_SIZE(element) was 0 at that time.

Add an error for this case, to ensure that client code can only create an
array of structs once the fields of the struct have been set up.

gcc/jit/
* internal-api.c (gcc::jit::recording::context::new_array_type):
Reject attempts to create an array of a struct if the fields of
the struct haven't yet been set.
* internal-api.h (gcc::jit::recording::type::dyn_cast_struct): New
virtual function.
(gcc::jit::recording::struct_::dyn_cast_struct): New, overriding
for this subclass.
(gcc::jit::recording::struct_::get_name): New.
---
 gcc/jit/ChangeLog.jit  | 11 +++
 gcc/jit/internal-api.c |  9 +
 gcc/jit/internal-api.h |  6 +-
 3 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/gcc/jit/ChangeLog.jit b/gcc/jit/ChangeLog.jit
index f5c4742..65fba51 100644
--- a/gcc/jit/ChangeLog.jit
+++ b/gcc/jit/ChangeLog.jit
@@ -1,3 +1,14 @@
+2014-07-14  David Malcolm  dmalc...@redhat.com
+
+   * internal-api.c (gcc::jit::recording::context::new_array_type):
+   Reject attempts to create an array of a struct if the fields of
+   the struct haven't yet been set.
+   * internal-api.h (gcc::jit::recording::type::dyn_cast_struct): New
+   virtual function.
+   (gcc::jit::recording::struct_::dyn_cast_struct): New, overriding
+   for this subclass.
+   (gcc::jit::recording::struct_::get_name): New.
+
 2014-05-07  David Malcolm  dmalc...@redhat.com
 
* Make-lang.in (LIBGCCJIT_LINKER_NAME): New.
diff --git a/gcc/jit/internal-api.c b/gcc/jit/internal-api.c
index f45595e..768d41c 100644
--- a/gcc/jit/internal-api.c
+++ b/gcc/jit/internal-api.c
@@ -345,6 +345,15 @@ recording::context::new_array_type (recording::location 
*loc,
recording::type *element_type,
int num_elements)
 {
+  if (struct_ *s = element_type-dyn_cast_struct ())
+if (!s-get_fields ())
+  {
+   add_error (NULL,
+  cannot create an array of type %s
+   until the fields have been set,
+  s-get_name ()-c_str ());
+   return NULL;
+  }
   recording::type *result =
 new recording::array_type (this, loc, element_type, num_elements);
   record (result);
diff --git a/gcc/jit/internal-api.h b/gcc/jit/internal-api.h
index 34c1de3..1612a22 100644
--- a/gcc/jit/internal-api.h
+++ b/gcc/jit/internal-api.h
@@ -477,8 +477,9 @@ public:
  The caller is responsible for setting an error.  */
   virtual type *dereference () = 0;
 
-  /* Dynamic cast.  */
+  /* Dynamic casts.  */
   virtual function_type *as_a_function_type() { gcc_unreachable (); return 
NULL; }
+  virtual struct_ *dyn_cast_struct () { return NULL; }
 
   /* Is it typesafe to copy to this type from rtype?  */
   virtual bool accepts_writes_from (type *rtype)
@@ -755,9 +756,12 @@ public:
   location *loc,
   string *name);
 
+  struct_ *dyn_cast_struct () { return this; }
+
   type *
   as_type () { return this; }
 
+  string *get_name () const { return m_name; }
   fields * get_fields () { return m_fields; }
 
   void
-- 
1.8.5.3

[Patch, Fortran] Fix atomic_ref with -fcoarray=lib

2014-07-14 Thread Tobias Burnus

If the atomic_ref VALUE argument is of a different kind than the ATOM 
argument, the result was wrong with -fcoarray=lib. That showed up with 
gfortran.dg/coarray/atomic_1.f90 - but for some reasons only with -m32.


The fix is to create a temporary variable in this case, what the patch does.
OK for the trunk?

Tobias
2014-06-14  Tobias Burnus  bur...@net-b.de

	* trans-intrinsic.c (conv_intrinsic_atomic_ref): Fix handling
	for kind mismatch with -fcoarray=lib.

diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 57b7f4d..3de0b09 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -8563,7 +8563,8 @@ conv_intrinsic_atomic_ref (gfc_code *code)
   atom = argse.expr;
 
   gfc_init_se (argse, NULL);
-  if (gfc_option.coarray == GFC_FCOARRAY_LIB)
+  if (gfc_option.coarray == GFC_FCOARRAY_LIB
+   code-ext.actual-expr-ts.kind == atom_expr-ts.kind)
 argse.want_pointer = 1;
   gfc_conv_expr (argse, code-ext.actual-expr);
   gfc_add_block_to_block (block, argse.pre);
@@ -8589,6 +8590,7 @@ conv_intrinsic_atomic_ref (gfc_code *code)
   if (gfc_option.coarray == GFC_FCOARRAY_LIB)
 {
   tree image_index, caf_decl, offset, token;
+  tree orig_value = NULL_TREE, vardecl = NULL_TREE;
 
   caf_decl = gfc_get_tree_for_caf_expr (atom_expr);
   if (TREE_CODE (TREE_TYPE (caf_decl)) == REFERENCE_TYPE)
@@ -8601,6 +8603,14 @@ conv_intrinsic_atomic_ref (gfc_code *code)
 
   get_caf_token_offset (token, offset, caf_decl, atom, atom_expr);
 
+  /* Different type, need type conversion.  */
+  if (!POINTER_TYPE_P (TREE_TYPE (value)))
+	{
+	  vardecl = gfc_create_var (TREE_TYPE (TREE_TYPE (atom)), value);
+  orig_value = value;
+  value = gfc_build_addr_expr (NULL_TREE, vardecl);
+	}
+
   tmp = build_call_expr_loc (input_location, gfor_fndecl_caf_atomic_ref, 7,
  token, offset, image_index, value, stat,
  build_int_cst (integer_type_node,
@@ -8608,6 +8618,9 @@ conv_intrinsic_atomic_ref (gfc_code *code)
  build_int_cst (integer_type_node,
 		(int) atom_expr-ts.kind));
   gfc_add_expr_to_block (block, tmp);
+  if (vardecl != NULL_TREE)
+	gfc_add_modify (block, orig_value,
+			fold_convert (TREE_TYPE (orig_value), vardecl));
   gfc_add_block_to_block (block, post_block);
   return gfc_finish_block (block);
 }

[jit] Clean out state within ipa-cp.c

2014-07-14 Thread David Malcolm

Committed to branch dmalcolm/jit:

Certain client code that repeatedly performed in-process compilations with
optimizations and inlinable functions led to a segfault within
ipa-cp.c:propagate_effects, whilst traversing the values_topo list.

The root cause was that values_topo was not reset to NULL, and hence could
contain entities allocated by a previous compile within a then-defunct
alloc_pool.

Introduce ipa_cp_c_finalize to clean out state within ipa-cp.c and call
it from toplev::finalize.  In particular, reset values_topo back to NULL.

gcc/
* cgraph.h (ipa_cp_c_finalize): Add prototype.
* ipa-cp.c (ipa_cp_c_finalize): New.
* toplev.c (toplev::finalize): Add call to ipa_cp_c_finalize.
---
 gcc/ChangeLog.jit | 6 ++
 gcc/cgraph.h  | 2 ++
 gcc/ipa-cp.c  | 9 +
 gcc/toplev.c  | 1 +
 4 files changed, 18 insertions(+)

diff --git a/gcc/ChangeLog.jit b/gcc/ChangeLog.jit
index f8235f1..3a6ea52 100644
--- a/gcc/ChangeLog.jit
+++ b/gcc/ChangeLog.jit
@@ -1,3 +1,9 @@
+2014-07-14  David Malcolm  dmalc...@redhat.com
+
+   * cgraph.h (ipa_cp_c_finalize): Add prototype.
+   * ipa-cp.c (ipa_cp_c_finalize): New.
+   * toplev.c (toplev::finalize): Add call to ipa_cp_c_finalize.
+
 2014-05-08  David Malcolm  dmalc...@redhat.com
 
* params.c (global_init_params): Require that params_finished be
diff --git a/gcc/cgraph.h b/gcc/cgraph.h
index 2e2eb97..2d7e574 100644
--- a/gcc/cgraph.h
+++ b/gcc/cgraph.h
@@ -866,6 +866,8 @@ void symtab_initialize_asm_name_hash (void);
 void symtab_prevail_in_asm_name_hash (symtab_node node);
 void varpool_remove_initializer (struct varpool_node *);
 
+/* In ipa-cp.c  */
+void ipa_cp_c_finalize (void);
 
 /* Return callgraph node for given symbol and check it is a function. */
 static inline struct cgraph_node *
diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index 57ec2db..39650f0 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -3689,3 +3689,12 @@ make_pass_ipa_cp (gcc::context *ctxt)
 {
   return new pass_ipa_cp (ctxt);
 }
+
+void
+ipa_cp_c_finalize (void)
+{
+  max_count = 0;
+  overall_size = 0;
+  max_new_size = 0;
+  values_topo = NULL;
+}
diff --git a/gcc/toplev.c b/gcc/toplev.c
index 5123dbe..8fa92c5 100644
--- a/gcc/toplev.c
+++ b/gcc/toplev.c
@@ -2014,6 +2014,7 @@ toplev::finalize (void)
   dwarf2out_c_finalize ();
   gcse_c_finalize ();
   ipa_c_finalize ();
+  ipa_cp_c_finalize ();
   ipa_reference_c_finalize ();
   params_c_finalize ();
   predict_c_finalize ();
-- 
1.8.5.3

Re: [GSoC] symbol to denote multiple operators

2014-07-14 Thread Prathamesh Kulkarni

On Mon, Jul 14, 2014 at 5:36 PM, Richard Biener
richard.guent...@gmail.com wrote:
 On Fri, Jul 11, 2014 at 4:59 PM, Prathamesh Kulkarni
 bilbotheelffri...@gmail.com wrote:
 On 7/11/14, Richard Biener richard.guent...@gmail.com wrote:
 On Thu, Jul 10, 2014 at 8:05 PM, Prathamesh Kulkarni
 bilbotheelffri...@gmail.com wrote:
 Hi,
I have attempted to add syntax for symbol to denote multiple
 operators.

 I tried it with few bogus patterns and it appears to work hopefully
 -:)
 eg: (bogus pattern):
 (for op in plus minus
   (match_and_simplify
 (op @0 @1)
 (op @0 @0)))

 generates following patterns:
 (plus @0 @1) - (plus @0 @0)  // simplify_0
 (plus @0 @1) - (mult @0 @0)  // simplify_1
 (mult @0 @1) - (plus @0 @0)  // simplify_2
 (mult @0 @1) - (mult @0 @0)  // simplify_3

 s/mult/minus/?  I think it should only generate

  (plus @0 @1) - (plus @0 @0)
  (minus @0 @1) - (minus @0 @0)

 to get the what you write we should need to write

  (for op1 in plus minus
(for op2 in plus minus
  (match_and_simplify
 (op1 @0 @1)
 (op2 @0 @0

 root (0xab6b10), 0, 2
 |--(PLUS_EXPR) (0xab6b30), 1, 1
 |true (0xab6ba0), 2, 1
 |--true (0xab6c10), 3, 2
 |simplify_0 { 0xab6ba0, 0xab6c10, (nil), (nil),  }  (0xab6c80), 4,
 0
 |simplify_1 { 0xab6ba0, 0xab6c10, (nil), (nil),  }  (0xab6d40), 4,
 0
 |--(MULT_EXPR) (0xab6d00), 1, 1
 |true (0xab6d90), 2, 1
 |--true (0xab6e00), 3, 2
 |simplify_2 { 0xab6d90, 0xab6e00, (nil), (nil),  }  (0xab6e70), 4,
 0
 |simplify_3 { 0xab6d90, 0xab6e00, (nil), (nil),  }  (0xab6f30), 4,
 0

 * Changes to rest of the code:
 a) commutating patterns was interfering with this, because
 parse_match_and_simplify, immediately commutated match operand. Symbol
 should be replaced by operators before commutating. This required
 adjusting simplify (back to operand *match), and commutating is done
 in new function lower_commutative. Ideally this should be done during
 insertion in decision tree ?

 Yes, commutating should be done by inserting a pattern multiple
 times with adjusted AST walk order.

 b) adjustments required to e_operation constructor, so it doesn't
 call fatal, when it does not find id to be in the hash table.

 Eventually just temporarily insert a new operator in the hash table
 when parsing comes along a (for OP ...?  That is, add a new kind,
 USER and just re-use base-id?

 * Caveats
 a) new e_operation constructor taking id_base * argument. Not sure
 if that's required.
 b) e_operation::user_id denotes user-defined identifier (opname),
 a rather apologetic name ...
 c) Similar to commutate(), replace_user_id() does not clone AST's.
 So we have multiple AST's sharing same nodes.

 I wonder if we want to parse the 'for' into an AST node instead,
 thus not expand it on-the-fly.  Applying could then happen during
 DT insertion.  Or as a separate lowering like you introduce
 lower_commutative - that looks  cleaner.

 Or if we can simply parse the match-and-simplify multiple times, with
 the for op replaces, using _cpp_backup_tokens.  Ok, no - that
 sounds like too much of a hack.

 * add multiple symbols ?
 should we have
 (for opname in operator-list1, opname2 in operator-list2
   (match_and_simplify
  ...))
 or have nested for ?
 (for opname in operator-list1
(for opname2 in operator-list2
(match_and_simplify
   )))

 It depends on the desired semantics.  It's a lot clearer with
 single opname for only (but then we eventually need nested for).

 * we don't detect functions with wrong arguments
 for example, we dont give error on:
 (built_in_sqrt @0 @1)
 I guess that's because we don't have an easy way to figure out
 number of arguments a function expects ?
 (is there a built-in equivalent of tree_code_length[] ?)

 Yeah, the function stuff is still very simplistic and no, there isn't
 any easy way of extracting the number of expected arguments
 from builtins.def (it's encoded in the type).  The easiest way
 would be to change builtins.def to add a number-of-args argument ...

 Let's just defer that issue.


 As for the patch, we shouldn't do the cartesian_product - that's
 hardly ever what the user intends and it means there isn't any
 way of repeating the same pattern for multiple operators.

 A common use for 'for' would be (for OP in ne eq (...)) as most
 equality foldings are valid for ne and eq.  Another is
 for the various division kinds we have - trunc_div ceil_div floor_div
 and round_div (same for mod):

 (for op in trunc_div ceil_div floor_div round_div
   (match_and_simplify
  (op @0 integer_onep)
  @0))

 (good example for match.pd to exercise the code)

 Can you fix the cartesian product thing (it should only simplify the
 patch)?
 This version of the patch, removes cartesian_product, and reuses
 id_base::id for user-defined symbols.

 eg:
 (for op in plus minus
   (match_and_simplify
 (op (op @0 @1) @2)
 (op @0 @0)))

 generates following patterns:

[PATCH, rs6000, v2] Fix ELFv2 homogeneous float aggregate ABI bug

Hello,

this patch updates the prior version:
https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00632.html
to add a -Wpsabi note as discussed.

(We may need to change the GCC 4.10 string if the next release turns out
to get a different name ...)

In a testsuite run, this note triggers only in those two ABI compat suite
test cases mentioned in the previous patch email (only on ELFv2, of course).

Tested on powerpc64le-linux.

OK for mainline?

Bye,
Ulrich


gcc/testsuite/ChangLog:

* config/rs6000/rs6000.c (rs6000_function_arg): If a float argument
does not fit fully into floating-point registers, and there is still
space in the register parameter area, use GPRs to pass those parts
of the argument.  Issue -Wpsabi note if any parameter is now treated
differently than before.
(rs6000_arg_partial_bytes): Update.

gcc/testsuite/ChangLog:

* gcc.target/powerpc/ppc64-abi-warn-2.c: New test.


Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 212147)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -10227,6 +10227,7 @@
  rtx r, off;
  int i, k = 0;
  unsigned long n_fpreg = (GET_MODE_SIZE (elt_mode) + 7)  3;
+ int fpr_words;
 
  /* Do we also need to pass this argument in the parameter
 save area?  */
@@ -10255,6 +10256,47 @@
  rvec[k++] = gen_rtx_EXPR_LIST (VOIDmode, r, off);
}
 
+ /* If there were not enough FPRs to hold the argument, the rest
+usually goes into memory.  However, if the current position
+is still within the register parameter area, a portion may
+actually have to go into GPRs.
+
+Note that it may happen that the portion of the argument
+passed in the first half of the first GPR was already
+passed in the last FPR as well.
+
+For unnamed arguments, we already set up GPRs to cover the
+whole argument in rs6000_psave_function_arg, so there is
+nothing further to do at this point.  */
+ fpr_words = (i * GET_MODE_SIZE (elt_mode)) / (TARGET_32BIT ? 4 : 8);
+ if (i  n_elts  align_words + fpr_words  GP_ARG_NUM_REG
+  cum-nargs_prototype  0)
+{
+ static bool warned;
+
+ enum machine_mode rmode = TARGET_32BIT ? SImode : DImode;
+ int n_words = rs6000_arg_size (mode, type);
+
+ align_words += fpr_words;
+ n_words -= fpr_words;
+
+ do
+   {
+ r = gen_rtx_REG (rmode, GP_ARG_MIN_REG + align_words);
+ off = GEN_INT (fpr_words++ * GET_MODE_SIZE (rmode));
+ rvec[k++] = gen_rtx_EXPR_LIST (VOIDmode, r, off);
+   }
+ while (++align_words  GP_ARG_NUM_REG  --n_words != 0);
+
+ if (!warned  warn_psabi)
+   {
+ warned = true;
+ inform (input_location,
+ the ABI of passing homogeneous float aggregates
+  has changed in GCC 4.10);
+   }
+   }
+
  return rs6000_finish_function_arg (mode, rvec, k);
}
   else if (align_words  GP_ARG_NUM_REG)
@@ -10330,8 +10372,23 @@
   /* Otherwise, we pass in FPRs only.  Check for partial copies.  */
   passed_in_gprs = false;
   if (cum-fregno + n_elts * n_fpreg  FP_ARG_MAX_REG + 1)
-   ret = ((FP_ARG_MAX_REG + 1 - cum-fregno)
-  * MIN (8, GET_MODE_SIZE (elt_mode)));
+   {
+ /* Compute number of bytes / words passed in FPRs.  If there
+is still space available in the register parameter area
+*after* that amount, a part of the argument will be passed
+in GPRs.  In that case, the total amount passed in any
+registers is equal to the amount that would have been passed
+in GPRs if everything were passed there, so we fall back to
+the GPR code below to compute the appropriate value.  */
+ int fpr = ((FP_ARG_MAX_REG + 1 - cum-fregno)
+* MIN (8, GET_MODE_SIZE (elt_mode)));
+ int fpr_words = fpr / (TARGET_32BIT ? 4 : 8);
+
+ if (align_words + fpr_words  GP_ARG_NUM_REG)
+   passed_in_gprs = true;
+ else
+   ret = fpr;
+   }
 }
 
   if (passed_in_gprs
Index: gcc/testsuite/gcc.target/powerpc/ppc64-abi-warn-1.c
===
--- /dev/null
+++ gcc/testsuite/gcc.target/powerpc/ppc64-abi-warn-1.c (revision 0)
@@ -0,0 +1,12 @@
+/* { dg-do compile { target { powerpc*-*-linux*  lp64 } } } */
+/* { dg-options -mabi=elfv2 } */
+
+struct f8
+  {
+float x[8];
+  };
+
+void test (struct f8 a, struct f8 b) /* { dg-message note: the ABI of passing 
homogeneous float aggregates has changed } */
+{
+}
+
--

[PATCH, rs6000, v2] Fix aggregate alignment ABI issue

Hello,

this patch updates the prior version:
https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00634.html
to add a -Wpsabi note as discussed.

Note that the warning triggers whenever type is encountered whose alignment
*requirement* changes due to this patch.  In some cases, this does not actually
change the ABI of a given function call since the argument happened to be
already aligned for the higher requirement as well.

Except for a few cases in the ABI compat suite (as expected), this note
triggers in three test cases:

In the ELFv1 ABI only:
gcc.c-torture/compile/20040709-1.c:7:1: note: the ABI of passing aggregates 
with 16-byte alignment has changed in GCC 4.10
union foo {
  long double ld;
} bar;

Note that this union counts as homogeneous aggregate according to
the ELFv2 ABI, so it is treated the same before and after this patch
(i.e. aligned to 8 bytes).

In the ELFv1 ABI, however, this union does *not* count as a single-element
float struct (because its mode is TImode, not TFmode, since common code
does the latter only for single-element structs, not unions).  Therefore,
this union used to be 8-byte aligned but is now 16-byte aligned.

In both the ELFv1 and ELFv2 ABIs:
gcc.dg/pr32293.c:46:1: note: the ABI of passing aggregates with 16-byte 
alignment has changed in GCC 4.10
typedef
__attribute__ ((aligned(16)))
 struct {
   UINT64 w[2];
 } UINT128;

g++.dg/abi/param2.C:9:1: note: the ABI of passing aggregates with 16-byte 
alignment has changed in GCC 4.10
struct S { union {} a; } __attribute__((aligned));

In both cases, we have a struct of size 16 bytes (in the second case due to
alignment padding) and alignment requirement 16 bytes, which is recognized
as TImode and not BLKmode by common code, and thus used to be 8-byte aligned
but is now 16-byte aligned.

The tests still PASS since the dg-test infrastructure prunes all informational
messages from the GCC output.

Based on the discussion after the previous patch submission, the patch
leaves the Darwin ABI unchanged.

Tested on powerpc64-linux and powerpc64le-linux.

OK for mainline?

Bye,
Ulrich


gcc/ChangeLog:

* config/rs6000/rs6000.c (rs6000_function_arg_boundary): In the AIX
and ELFv2 ABI, do not use the mode == BLKmode check to test for
aggregate types.  Instead, *all* aggregate types, except for single-
element or homogeneous float/vector aggregates, are quadword-aligned
if required by their type alignment.  Issue -Wpsabi note when a type
is now treated differently than before.

gcc/testsuite/ChangLog:

* gcc.target/powerpc/ppc64-abi-warn-2.c: New test.


Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 212147)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -9182,14 +9182,48 @@
   || (type  TREE_CODE (type) == VECTOR_TYPE
int_size_in_bytes (type) = 16))
 return 128;
-  else if (((TARGET_MACHO  rs6000_darwin64_abi)
-   || DEFAULT_ABI == ABI_ELFv2
-|| (DEFAULT_ABI == ABI_AIX  !rs6000_compat_align_parm))
-   mode == BLKmode
-   type  TYPE_ALIGN (type)  64)
+
+  /* Aggregate types that need  8 byte alignment are quadword-aligned
+ in the parameter area in the ELFv2 ABI, and in the AIX ABI unless
+ -mcompat-align-parm is used.  */
+  if (((DEFAULT_ABI == ABI_AIX  !rs6000_compat_align_parm)
+   || DEFAULT_ABI == ABI_ELFv2)
+   type  TYPE_ALIGN (type)  64)
+{
+  /* Aggregate means any AGGREGATE_TYPE except for single-element
+ or homogeneous float/vector aggregates here.  We already handled
+ vector aggregates above, but still need to check for float here. */
+  bool aggregate_p = (AGGREGATE_TYPE_P (type)
+  !SCALAR_FLOAT_MODE_P (elt_mode));
+
+  /* We used to check for BLKmode instead of the above aggregate type
+check.  Warn when this results in any difference to the ABI.  */
+  if (aggregate_p != (mode == BLKmode))
+   {
+ static bool warned;
+ if (!warned  warn_psabi)
+   {
+ warned = true;
+ inform (input_location,
+ the ABI of passing aggregates with %d-byte alignment
+  has changed in GCC 4.10,
+ (int) TYPE_ALIGN (type) / BITS_PER_UNIT);
+   }
+   }
+
+  if (aggregate_p)
+   return 128;
+}
+
+  /* Similar for the Darwin64 ABI.  Note that for historical reasons we
+ implement the aggregate type check as a BLKmode check here; this
+ means certain aggregate types are in fact not aligned.  */
+  if (TARGET_MACHO  rs6000_darwin64_abi
+   mode == BLKmode
+   type  TYPE_ALIGN (type)  64)
 return 128;
-  else
-return PARM_BOUNDARY;
+
+  return PARM_BOUNDARY;
 }
 
 /* The offset in words to the start of the parameter save area.  */
Index:

[RFC, rs6000, v2] Fix alignment of non-Altivec vector struct fields

Hello,

this is an attempt to update the prior patch:
https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00635.html
to add a -Wpsabi note as discussed.

However, this is causing a bit of difficulties.  First of all, the warning
triggers in a larger number of tests -- which was probably to be expected
since a number of tests in the suite explicitly work on GCC vectors defined
using various vector_size values, and any size except 16 will result in the
warning.  Note that the warning gets issued at the site of definition of
the structure type -- it does not have to be used in a function call.

More problematic is that this new warning causes four tests to fail
(it's actually 38 new FAILS since each of the tests fails in multiple
optimization levels):

FAIL: gcc.c-torture/execute/20050316-1.c compilation
gcc.c-torture/execute/20050316-1.c:53:9: note: the layout of aggregates 
containing vectors with 8-byte alignment has changed in GCC 4.10
FAIL: gcc.c-torture/execute/20050316-3.c compilation
gcc.c-torture/execute/20050316-3.c:26:9: note: the layout of aggregates 
containing vectors with 8-byte alignment has changed in GCC 4.10
FAIL: gcc.c-torture/execute/20050604-1.c compilation
gcc.c-torture/execute/20050604-1.c:12:1: note: the layout of aggregates 
containing vectors with 8-byte alignment has changed in GCC 4.10
FAIL: gcc.c-torture/execute/pr23135.c compilation
gcc.c-torture/execute/pr23135.c:20:1: note: the layout of aggregates containing 
vectors with 8-byte alignment has changed in GCC 4.10

Unfortunately, while most of the tests in the suite use the dg-test
framework which ignores note messages, the gcc.c-torture/execute
tests still use the old torture test framework, which does *not*.
(Also, in the old framework you cannot even add dg-... commands to
ignore those messages for a certain test, or add a -Wno-psabi option.)

Therefore, I'm not proposing to commit this patch as-is, but would
like to ask for feedback on how to best proceed with this.

One option might be to  move the affected tests to the dg-test framework.
Or else we might decide we don't actually need a warning for this change,
since it only affects GCC synthetic vectors, where we might not have made
strict ABI guarantees anyway ...

Thoughts?

Bye,
Ulrich


gcc/ChangeLog:

* config/rs6000/rs6000-protos.h (rs6000_special_adjust_field_align_p):
Add prototype.
* config/rs6000/rs6000.c (rs6000_special_adjust_field_align_p): New
function.
* config/rs6000/sysv4.h (ADJUST_FIELD_ALIGN): Call it.
* config/rs6000/linux64.h (ADJUST_FIELD_ALIGN): Likewise.
* config/rs6000/freebsd64.h (ADJUST_FIELD_ALIGN): Likewise.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/ppc64-abi-warn-3.c: New test.



Index: gcc/config/rs6000/rs6000-protos.h
===
--- gcc/config/rs6000/rs6000-protos.h   (revision 212147)
+++ gcc/config/rs6000/rs6000-protos.h   (working copy)
@@ -155,6 +155,7 @@
 
 #ifdef TREE_CODE
 extern unsigned int rs6000_data_alignment (tree, unsigned int, enum 
data_align);
+extern bool rs6000_special_adjust_field_align_p (tree, unsigned int);
 extern unsigned int rs6000_special_round_type_align (tree, unsigned int,
 unsigned int);
 extern unsigned int darwin_rs6000_special_round_type_align (tree, unsigned int,
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 212147)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -5878,6 +5878,32 @@
   return align;
 }
 
+/* Previous GCC releases forced all vector types to have 16-byte alignment.  */
+
+bool
+rs6000_special_adjust_field_align_p (tree field, unsigned int computed)
+{
+  if (TARGET_ALTIVEC  TREE_CODE (TREE_TYPE (field)) == VECTOR_TYPE)
+{
+  if (computed != 128)
+   {
+ static bool warned;
+ if (!warned  warn_psabi)
+   {
+ warned = true;
+ inform (input_location,
+ the layout of aggregates containing vectors with
+  %d-byte alignment has changed in GCC 4.10,
+ computed / BITS_PER_UNIT);
+   }
+   }
+  /* In current GCC there is no special case.  */
+  return false;
+}
+
+  return false;
+}
+
 /* AIX increases natural record alignment to doubleword if the first
field is an FP double while the FP fields remain word aligned.  */
 
Index: gcc/config/rs6000/sysv4.h
===
--- gcc/config/rs6000/sysv4.h   (revision 212147)
+++ gcc/config/rs6000/sysv4.h   (working copy)
@@ -292,7 +292,7 @@
 /* An expression for the alignment of a structure field FIELD if the
alignment computed in the usual way is COMPUTED.  */
 #define ADJUST_FIELD_ALIGN(FIELD, COMPUTED)  \
-   ((TARGET_ALTIVEC  TREE_CODE (TREE_TYPE

Re: [RFC, rs6000, v2] Fix alignment of non-Altivec vector struct fields

[ Sorry, re-sending with fixed email address.  ]

Hello,

this is an attempt to update the prior patch:
https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00635.html
to add a -Wpsabi note as discussed.

However, this is causing a bit of difficulties.  First of all, the warning
triggers in a larger number of tests -- which was probably to be expected
since a number of tests in the suite explicitly work on GCC vectors defined
using various vector_size values, and any size except 16 will result in the
warning.  Note that the warning gets issued at the site of definition of
the structure type -- it does not have to be used in a function call.

More problematic is that this new warning causes four tests to fail
(it's actually 38 new FAILS since each of the tests fails in multiple
optimization levels):

FAIL: gcc.c-torture/execute/20050316-1.c compilation
gcc.c-torture/execute/20050316-1.c:53:9: note: the layout of aggregates 
containing vectors with 8-byte alignment has changed in GCC 4.10
FAIL: gcc.c-torture/execute/20050316-3.c compilation
gcc.c-torture/execute/20050316-3.c:26:9: note: the layout of aggregates 
containing vectors with 8-byte alignment has changed in GCC 4.10
FAIL: gcc.c-torture/execute/20050604-1.c compilation
gcc.c-torture/execute/20050604-1.c:12:1: note: the layout of aggregates 
containing vectors with 8-byte alignment has changed in GCC 4.10
FAIL: gcc.c-torture/execute/pr23135.c compilation
gcc.c-torture/execute/pr23135.c:20:1: note: the layout of aggregates containing 
vectors with 8-byte alignment has changed in GCC 4.10

Unfortunately, while most of the tests in the suite use the dg-test
framework which ignores note messages, the gcc.c-torture/execute
tests still use the old torture test framework, which does *not*.
(Also, in the old framework you cannot even add dg-... commands to
ignore those messages for a certain test, or add a -Wno-psabi option.)

Therefore, I'm not proposing to commit this patch as-is, but would
like to ask for feedback on how to best proceed with this.

One option might be to  move the affected tests to the dg-test framework.
Or else we might decide we don't actually need a warning for this change,
since it only affects GCC synthetic vectors, where we might not have made
strict ABI guarantees anyway ...

Thoughts?

Bye,
Ulrich


gcc/ChangeLog:

* config/rs6000/rs6000-protos.h (rs6000_special_adjust_field_align_p):
Add prototype.
* config/rs6000/rs6000.c (rs6000_special_adjust_field_align_p): New
function.
* config/rs6000/sysv4.h (ADJUST_FIELD_ALIGN): Call it.
* config/rs6000/linux64.h (ADJUST_FIELD_ALIGN): Likewise.
* config/rs6000/freebsd64.h (ADJUST_FIELD_ALIGN): Likewise.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/ppc64-abi-warn-3.c: New test.



Index: gcc/config/rs6000/rs6000-protos.h
===
--- gcc/config/rs6000/rs6000-protos.h   (revision 212147)
+++ gcc/config/rs6000/rs6000-protos.h   (working copy)
@@ -155,6 +155,7 @@
 
 #ifdef TREE_CODE
 extern unsigned int rs6000_data_alignment (tree, unsigned int, enum 
data_align);
+extern bool rs6000_special_adjust_field_align_p (tree, unsigned int);
 extern unsigned int rs6000_special_round_type_align (tree, unsigned int,
 unsigned int);
 extern unsigned int darwin_rs6000_special_round_type_align (tree, unsigned int,
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 212147)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -5878,6 +5878,32 @@
   return align;
 }
 
+/* Previous GCC releases forced all vector types to have 16-byte alignment.  */
+
+bool
+rs6000_special_adjust_field_align_p (tree field, unsigned int computed)
+{
+  if (TARGET_ALTIVEC  TREE_CODE (TREE_TYPE (field)) == VECTOR_TYPE)
+{
+  if (computed != 128)
+   {
+ static bool warned;
+ if (!warned  warn_psabi)
+   {
+ warned = true;
+ inform (input_location,
+ the layout of aggregates containing vectors with
+  %d-byte alignment has changed in GCC 4.10,
+ computed / BITS_PER_UNIT);
+   }
+   }
+  /* In current GCC there is no special case.  */
+  return false;
+}
+
+  return false;
+}
+
 /* AIX increases natural record alignment to doubleword if the first
field is an FP double while the FP fields remain word aligned.  */
 
Index: gcc/config/rs6000/sysv4.h
===
--- gcc/config/rs6000/sysv4.h   (revision 212147)
+++ gcc/config/rs6000/sysv4.h   (working copy)
@@ -292,7 +292,7 @@
 /* An expression for the alignment of a structure field FIELD if the
alignment computed in the usual way is COMPUTED.  */
 #define ADJUST_FIELD_ALIGN(FIELD, COMPUTED)

Re: [patch] Add libstdc++ type printers for class templates

On 14/07/14 15:21 +0100, Jonathan Wakely wrote:

This defines a new style of Python type printer that recognizes
templates and can be used to omit default template arguments from the
typename GDB prints, e.g. showing std::vectorT, std::allocatorT as
simply std::vectorT. Additionally, T will get processed by the type
recognizers so if it's a standard typedef or template it will also get
displayed in its abbreviated form.

e.g. with current trunk:

Breakpoint 1, main () at p.cc:45
45std::vectorstd::dequestd::listint nested;
(gdb) whatis nested
type = std::vectorstd::dequestd::listint, std::allocatorint , std::allocatorstd::listint, std::allocatorint ,
std::allocatorstd::dequestd::listint, std::allocatorint , std::allocatorstd::listint, std::allocatorint

and with this patch:

(gdb) whatis nested
type = std::vectorstd::dequestd::listint

N.B. I am not printing spaces between the closing angle brackets. If
people prefer I can put them in, or only do it for C++11 types, so
that copying and pasting types from GDB will always work (if you're
copying a C++11 type then you must be planning to use it with a C++11
compiler, which will handle without spaces).

This passes the python testsuite but I'll wait for comments before
committing, in case my use of the GDB API or Python can be improved by
anyone.

I forgot to say that with these type recognizers we might want to
revisit the output of the existing printers for the containers, so
that instead of:

std::map with 3 elements = { ... }

GDB could print the map type:

std::mapint, int with 3 elements = { ... }

[patch] Add libstdc++ pretty printers for Library Fundamentals TS types


This is another patch for the python printers, so the diff is relative
to my patch from earlier today, but it's actually independent.

This adds printers for the types in the std::experimental namespace.

For 'any' and 'optional' the printer will say no contained value
when that's the case, otherwise it will display the contained value
using its own printer, so the output looks like one of:

No contained value:

 std::experimental::any [no contained value]

Contained value is a single object:

 std::experimental::any containing int = {[contained value] = 6}

Contained value contains other object:

 std::experimental::any containing std::map with 2 elements = {[1] = 2, [3] = 4}

I'd rather not have the [contained value] part in the second one, but
the design of the printers assumes that the children() method always
returns a 2-tuple with a label and a value, so I decided that
 [contained value] = x
looks better than some arbitrary index such as:
 [0] = x

Printing the contained value was quite tricky to do for any, where the
type is completely erased. I'm considering using a similar trick for
shared_ptr, so that the printer can show the owned pointer as well as
the pointer that will be returned by get(), since they are not always
the same.

I had to remove the assumption that libstdc++ printers always work on
templates, because std::experimental::any is not a template (this will
also be true for std::experimental::filesystem::path and other types
in the Filesystem TS which I'm currently implementing). The relevant
part of the patch is:

@@ -865,12 +1001,12 @@ class Printer(object):
self.subprinters = []
self.lookup = {}
self.enabled = True
-self.compiled_rx = re.compile('^([a-zA-Z0-9_:]+).*$')
+self.compiled_rx = re.compile('^([a-zA-Z0-9_:]+)(.*)?$')

def add(self, name, function):
# A small sanity check.
# FIXME
-if not self.compiled_rx.match(name + ''):
+if not self.compiled_rx.match(name):
raise ValueError('libstdc++ programming error: %s does not match' 
% name)
printer = RxPrinter(name, function)
self.subprinters.append(printer)
commit 6a3842ae658fe9693a0989a9aa5ea7b42d01fe28
Author: Jonathan Wakely jwak...@redhat.com
Date:   Mon Jul 14 15:41:22 2014 +0100

	* python/libstdcxx/v6/printers.py (SingleObjContainerPrinter): New
	base class for experimental::any and experimental::optional printers.
	(StdExpAnyPrinter, StdExpOptionalPrinter, StdExpStringViewPrinter):
	New printers for Fundamentals TS types.
	* testsuite/libstdc++-prettyprinters/libfundts.cc: New.

diff --git a/libstdc++-v3/python/libstdcxx/v6/printers.py b/libstdc++-v3/python/libstdcxx/v6/printers.py
index ea34f22..994668d 100644
--- a/libstdc++-v3/python/libstdcxx/v6/printers.py
+++ b/libstdc++-v3/python/libstdcxx/v6/printers.py
@@ -836,6 +836,142 @@ class StdForwardListPrinter:
 return 'empty %s' % (self.typename)
 return '%s' % (self.typename)
 
+class SingleObjContainerPrinter(object):
+Base class for printers of containers of single objects
+
+def __init__ (self, val, viz):
+self.contained_value = val
+self.visualizer = viz
+
+class _contained:
+def __init__ (self, val):
+self.val = val
+
+def __iter__ (self):
+return self
+
+def next (self):
+if self.val is None:
+raise StopIteration
+retval = self.val
+self.val = None
+return ('[contained value]', retval)
+
+def children (self):
+if self.contained_value:
+if hasattr (self.visualizer, 'children'):
+return self.visualizer.children ()
+else:
+return self._contained (self.contained_value)
+return self._contained (None)
+
+def display_hint (self):
+# if contained value is a map we want to display in the same way
+if hasattr (self.visualizer, 'children') and hasattr (self.visualizer, 'display_hint'):
+return self.visualizer.display_hint ()
+return None
+
+
+class StdExpAnyPrinter(SingleObjContainerPrinter):
+Print a std::experimental::any
+
+def __init__ (self, typename, val):
+self.typename = 'std::experimental::any'
+self.val = val
+self.contained_type = None
+contained_value = None
+visualizer = None
+mgr = self.val['_M_manager']
+if mgr != 0:
+func = gdb.block_for_pc(int(mgr.cast(gdb.lookup_type('intptr_t'
+if not func:
+raise ValueError(Invalid function pointer in std::experimental::any)
+rx = r({0}::_Manager_\w+.*)::_S_manage\({0}::_Op, {0} const\*, {0}::_Arg\*\).format(typename)
+m = re.match(rx, func.function.name)
+if not m:
+raise ValueError(Unknown manager function in std::experimental::any)
+
+# FIXME need to expand

Re: [C++ Patch/RFC] PR 60608


On 07/14/2014 12:20 PM, Paolo Carlini wrote:

I have been looking a bit into this bug, using a reduced testcase which
simplifies the debugging quite a bit for me (a non-variadic variant is
ok). I cannot say to already understand all the details of the issue,
but something which strikes me as interesting, is that the DEDUCE_CALL
passed down by add_candidate gets lost and we end up calling
type_unification_real from unify with DEDUCE_EXACT. If I change it to an
unconditional DEDUCE_CALL, the testcase is accepted and the testsuite
passes with no regressions. Is that all there is to the issue?!?


Unfortunately, that goes too far.  I think we want a new DEDUCE_PARMS 
that is like DEDUCE_EXACT but does the same transformations as 
tsubst_arg_types in this part of unify_pack_expansion:



  /* If we had explicit template arguments, substitute them into the
 pattern before deduction.  */
  if (any_explicit)
{
  /* Some arguments might still be unspecified or dependent.  */
  bool dependent;
  ++processing_template_decl;
  dependent = any_dependent_template_arguments_p (targs);
  if (!dependent)
--processing_template_decl;
  parm = tsubst (pattern, targs,
 explain_p ? tf_warning_or_error : tf_none,
 NULL_TREE);
  if (dependent)
--processing_template_decl;
  if (parm == error_mark_node)
return 1;
}


Jason

Re: [patch, avr] Device macro correction for rev devices

2014-07-14 Thread Georg-Johann Lay


S, Pitchumani schrieb:

Attached patch changes the device name macro of two rev devices, from REV
to rev in the name.

Device name macro:
__AVR_ATmega16HVBREVB__
__AVR_ATmega32HVBREVB__

Change to:
__AVR_ATmega16HVBrevB__
__AVR_ATmega32HVBrevB__

'rev' in small letters emphasizes the revision of the device.


This is *NOT* OK.

The built-in macros for these devices have been uppercase in avr-gcc and 
AVR-Libc aver since, and they have always be compatible.


Just because one vendor (Atmel) lost track of their patches is no reason 
to introduce changes that render tools incompatible with existing code 
or with bit older versions of AVR-Libc or GCC.


BTW; the same change has been rejected for AVR-Libc for the same reason:

http://savannah.nongnu.org/bugs/?42696

Johann





Regards,
Pitchumani

gcc/ChangeLog

2014-07-14  Pitchumani Sivanupandi  pitchuman...@atmel.com

* config/avr/avr-mcus.def (atmega16hvbrevb): Change device name macro
to __AVR_ATmega16HVBrevB__.
(atmega32hvbrevb): Change device name macro to __AVR_ATmega32HVBrevB__.

Re: [PATCH, i386] Add prefixes avoidance tuning for silvermont target

2014-07-14 Thread Uros Bizjak

On Thu, Jul 3, 2014 at 3:38 PM, Ilya Enkovich enkovich@gmail.com wrote:
 2014-07-03 16:07 GMT+04:00 Uros Bizjak ubiz...@gmail.com:
 On Thu, Jul 3, 2014 at 1:50 PM, Ilya Enkovich enkovich@gmail.com wrote:

 I didn't find a nice way to fix peephole2 patterns to take register
 constraints into account. Is there any way to do it?

 Use REX_SSE_REGNO_P (REGNO (operands[...])) in the insn C constraint.

 Peephole doesn't know whether it works with tuned instruction or not,
 right? I would need to mark all instructions I modify with some
 attribute and then check for it in peephole.


 Also fully restrict xmm8-15 does not seem right.  It is just costly
 but not fully disallowed.

 As said earlier, you can try Ya*x as a constraint.

 I tried it. It does not seem to affect allocation much. I do not see
 any gain on targeted tests.

Strange, because the documentation claims:

'*'
 Says that the following character should be ignored when choosing
 register preferences.  '*' has no effect on the meaning of the
 constraint as a constraint, and no effect on reloading.  For LRA
 '*' additionally disparages slightly the alternative if the
 following character matches the operand.

Let me rethink this a bit. Prehaps we could reconsider Jakub's
proposal with Ya,!x (with two alternatives). IIRC this approach was
needed for some MMX alternatives, where we didn't want RA to allocate
a MMX register when the value could be passed in integer regs, but the
value was still allowed in MMX register.

As a side note, I'll investigate pushdf pattern, if it needs to be
updated. The proposed approach is from reload era, and things changed
substantially since then.

Uros.

Re: Some DWARFv5 proposal prototypes (atomic_type, aligned_type)

2014-07-14 Thread Tom Tromey

 Mark == Mark Wielaard m...@redhat.com writes:

Hi Mark.

Mark The following two patches are based on the earlier dwarf2out.c: Pass
Mark one cv_quals argument and Emit DW_tag_restrict_type patches I posted
Mark earlier. Since there currently is not even an early draft yet for DWARFv5,
Mark just a collection of proposals that might or might not be adopted these
Mark patches are not meant to be integrated just yet. But I would like to get
Mark feedback on the code and whether the new debug information is useful.

I didn't read the patches I'm afraid.
However, the new debug information is definitely useful for the gcc/gdb
integration project.  Without it I think the user can end up with
mysterious failures in their compiled expressions.

Tom

Re: [Patch, Fortran] Fix atomic_ref with -fcoarray=lib

2014-07-14 Thread Paul Richard Thomas

Dear Tobias,

It looks OK to me - good for trunk

Thanks for the patch

Paul

On 14 July 2014 19:19, Tobias Burnus bur...@net-b.de wrote:
 If the atomic_ref VALUE argument is of a different kind than the ATOM
 argument, the result was wrong with -fcoarray=lib. That showed up with
 gfortran.dg/coarray/atomic_1.f90 - but for some reasons only with -m32.

 The fix is to create a temporary variable in this case, what the patch does.
 OK for the trunk?

 Tobias



-- 
The knack of flying is learning how to throw yourself at the ground and miss.
   --Hitchhikers Guide to the Galaxy

Re: [PATCH] Fix INSN_TICK heuristic for SCHED_PRESSURE

2014-07-14 Thread Steven Bosscher

On Mon, Jul 14, 2014 at 10:09 AM, Maxim Kuvyrkov wrote:
 On Jul 14, 2014, at 8:05 PM, Steven Bosscher wrote:

 On Mon, Jul 14, 2014 at 6:12 AM, Maxim Kuvyrkov wrote:
 Hi,

 This patch fixes 2 of the [several] problems in rank_for_schedule 
 heuristics for SCHED_PRESSURE_MODEL.  SCHED_PRESSURE_MODEL is used for 
 first scheduling pass in ARM backend by default.

 The first one is when INSN_TICK of both instructions are equal, and 
 rank_for_schedule returns a tie result, even though there are more 
 heuristics down the path to break the tie.

 The second one is to account for the fact that model_index() of two 
 instructions is meaningful only when both instructions are in the current 
 basic block.

 Bootstrapped and tested on {x86_64,arm,aarch64}-linux.

 OK to apply?

 s/INSN_BB/BLOCK_FOR_INSN/

 That would be a mistake, see definition of INSN_BB in sched-int.h.  Scheduler 
 uses its own basic block numbering.

Eh, right. I seem to be confused here with older sched CFG oddities
but this isn't one of those...



 OK with that change.

 I assume OK without the change?

Yup.

Ciao!
Steven

[Patch, Fortran] Add missing coarray check

2014-07-14 Thread Tobias Burnus

While checking whether gfortran already handles the new constraint at 
http://j3-fortran.org/doc/year/14/14-140r2.txt (it does), I found the 
following issues:


a) Coarray variables with pointer attribute weren't rejected.
b) There was a copy'n'paste error in symbol.c, having cray_pointer at 
places where one should have cray_pointee, such that the cray-pointer 
test had been done twice.


Build and regtested on x86-64-gnu-linux.
OK for the trunk?

* * *

Admittedly, I cannot find the constraint for (a), but I am certain that 
it is not intended to permit the POINTER attribute. Even using C526 plus 
C528 still seem to permit integer, save, pointer :: caf[*]. I have now 
asked at the J3 mailing list for a pointer to the right constraint. At 
least Cray's compiler (correctly?!?) rejects coarrays with pointer 
attribute.


Tobias
2014-06-14  Tobias Burnus  bur...@net-b.de

gcc/fortran/
	* symbol.c (check_conflict): Add codimension conflict with
	pointer; fix cray-pointee check.

gcc/testsuite/
	* gfortran.dg/coarray_34.f90: New.
	* gfortran.dg/coarray_6.f90: Update test case.

diff --git a/gcc/fortran/symbol.c b/gcc/fortran/symbol.c
index aee7510..2e04598 100644
--- a/gcc/fortran/symbol.c
+++ b/gcc/fortran/symbol.c
@@ -458,6 +458,7 @@ check_conflict (symbol_attribute *attr, const char *name, locus *where)
   conf (pointer, target);
   conf (pointer, intrinsic);
   conf (pointer, elemental);
+  conf (pointer, codimension);
   conf (allocatable, elemental);
 
   conf (target, external);
@@ -534,8 +535,8 @@ check_conflict (symbol_attribute *attr, const char *name, locus *where)
   conf (cray_pointer, entry);
 
   conf (cray_pointee, allocatable);
-  conf (cray_pointer, contiguous);
-  conf (cray_pointer, codimension);
+  conf (cray_pointee, contiguous);
+  conf (cray_pointee, codimension);
   conf (cray_pointee, intent);
   conf (cray_pointee, optional);
   conf (cray_pointee, dummy);
diff --git a/gcc/testsuite/gfortran.dg/coarray_34.f90 b/gcc/testsuite/gfortran.dg/coarray_34.f90
new file mode 100644
index 000..f2bc910
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray_34.f90
@@ -0,0 +1,26 @@
+! { dg-do compile }
+! { dg-options -fcoarray=single }
+!
+use iso_fortran_env
+implicit none
+
+type t
+  integer, pointer :: caf2[:] ! { dg-error must be allocatable with deferred shape }
+end type t
+
+integer, pointer :: caf[*] ! { dg-error POINTER attribute conflicts with CODIMENSION attribute }
+
+type t2
+  type(lock_type), pointer :: lock_it ! { dg-error Component lock_it at .1. of type LOCK_TYPE must have a codimension or be a subcomponent of a coarray, which is not possible as the component has the pointer attribute }
+end type t2
+type(t2) :: caf3[*]
+
+type t3
+  type(lock_type) :: x
+end type t3
+
+type t4
+  type(t3), pointer :: y ! { dg-error Pointer component y at .1. has a noncoarray subcomponent of type LOCK_TYPE, which must have a codimension or be a subcomponent of a coarray }
+end type t4
+
+end
diff --git a/gcc/testsuite/gfortran.dg/coarray_6.f90 b/gcc/testsuite/gfortran.dg/coarray_6.f90
index f44ac01..d30567a 100644
--- a/gcc/testsuite/gfortran.dg/coarray_6.f90
+++ b/gcc/testsuite/gfortran.dg/coarray_6.f90
@@ -32,7 +32,7 @@ end module m
 
 subroutine bar()
   integer, parameter :: a[*] = 4 ! { dg-error PARAMETER attribute conflicts with CODIMENSION }
-  integer, pointer :: b[:] ! { dg-error is not ALLOCATABLE, SAVE nor a dummy }
+  integer :: b[*] ! { dg-error is not ALLOCATABLE, SAVE nor a dummy }
 end subroutine bar
 
 subroutine vol()

Re: [DOC Patch] gnat updates for makeinfo 5.2 - updated

2014-07-14 Thread David Wohlferd


I changed more than I should have.  A slightly smaller patch.

dw

On 7/14/2014 12:31 AM, David Wohlferd wrote:

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

Problem description:
 gnat docs have warning messages when compiled with makeinfo 5.2. Most 
of them revolve around the fact that nodes must be defined in the same 
order as they appear in menus.


ChangeLog:
2014-07-14  David Wohlferd d...@limegreensocks.com

* ada/gnat_rm.texi: Various cleanups for makeinfo 5.2.

dw


Index: gnat_rm.texi
===
--- gnat_rm.texi	(revision 212420)
+++ gnat_rm.texi	(working copy)
@@ -84,8 +84,9 @@
 * Implementation of Ada 2012 Features::
 * Obsolescent Features::
 * GNU Free Documentation License::
-* Index::
+* Index:Concept Index.
 
+@detailmenu
  --- The Detailed Node Listing ---
 
 About This Guide
@@ -110,8 +111,8 @@
 * Pragma Assertion_Policy::
 * Pragma Assume::
 * Pragma Assume_No_Invalid_Values::
+* Pragma Ast_Entry::
 * Pragma Attribute_Definition::
-* Pragma Ast_Entry::
 * Pragma C_Pass_By_Copy::
 * Pragma Check::
 * Pragma Check_Float_Overflow::
@@ -677,6 +678,7 @@
 GNU Free Documentation License
 
 Index
+@end detailmenu
 @end menu
 
 @end ifnottex
@@ -939,8 +941,8 @@
 * Pragma Assertion_Policy::
 * Pragma Assume::
 * Pragma Assume_No_Invalid_Values::
+* Pragma Ast_Entry::
 * Pragma Attribute_Definition::
-* Pragma Ast_Entry::
 * Pragma C_Pass_By_Copy::
 * Pragma Check::
 * Pragma Check_Float_Overflow::
@@ -18826,19 +18828,6 @@
 @cindex Time
 @cindex @code{GNAT.Calendar.Time_IO} (@file{g-catiio.ads})
 
-@node GNAT.CRC32 (g-crc32.ads)
-@section @code{GNAT.CRC32} (@file{g-crc32.ads})
-@cindex @code{GNAT.CRC32} (@file{g-crc32.ads})
-@cindex CRC32
-@cindex Cyclic Redundancy Check
-
-@noindent
-This package implements the CRC-32 algorithm.  For a full description
-of this algorithm see
-``Computation of Cyclic Redundancy Checks via Table Look-Up'',
-@cite{Communications of the ACM}, Vol.@: 31 No.@: 8, pp.@: 1008-1013,
-Aug.@: 1988.  Sarwate, D.V@.
-
 @node GNAT.Case_Util (g-casuti.ads)
 @section @code{GNAT.Case_Util} (@file{g-casuti.ads})
 @cindex @code{GNAT.Case_Util} (@file{g-casuti.ads})
@@ -18913,6 +18902,19 @@
 @noindent
 Provides a simple interface to handle Ctrl-C keyboard events.
 
+@node GNAT.CRC32 (g-crc32.ads)
+@section @code{GNAT.CRC32} (@file{g-crc32.ads})
+@cindex @code{GNAT.CRC32} (@file{g-crc32.ads})
+@cindex CRC32
+@cindex Cyclic Redundancy Check
+
+@noindent
+This package implements the CRC-32 algorithm.  For a full description
+of this algorithm see
+``Computation of Cyclic Redundancy Checks via Table Look-Up'',
+@cite{Communications of the ACM}, Vol.@: 31 No.@: 8, pp.@: 1008-1013,
+Aug.@: 1988.  Sarwate, D.V@.
+
 @node GNAT.Current_Exception (g-curexc.ads)
 @section @code{GNAT.Current_Exception} (@file{g-curexc.ads})
 @cindex @code{GNAT.Current_Exception} (@file{g-curexc.ads})
@@ -19558,17 +19560,6 @@
 single global task lock.  Appropriate for use in situations where contention
 between tasks is very rarely expected.
 
-@node GNAT.Time_Stamp (g-timsta.ads)
-@section @code{GNAT.Time_Stamp} (@file{g-timsta.ads})
-@cindex @code{GNAT.Time_Stamp} (@file{g-timsta.ads})
-@cindex Time stamp
-@cindex Current time
-
-@noindent
-Provides a simple function that returns a string -MM-DD HH:MM:SS.SS that
-represents the current date and time in ISO 8601 format. This is a very simple
-routine with minimal code and there are no dependencies on any other unit.
-
 @node GNAT.Threads (g-thread.ads)
 @section @code{GNAT.Threads} (@file{g-thread.ads})
 @cindex @code{GNAT.Threads} (@file{g-thread.ads})
@@ -19581,6 +19572,17 @@
 further details if your program has threads that are created by a non-Ada
 environment which then accesses Ada code.
 
+@node GNAT.Time_Stamp (g-timsta.ads)
+@section @code{GNAT.Time_Stamp} (@file{g-timsta.ads})
+@cindex @code{GNAT.Time_Stamp} (@file{g-timsta.ads})
+@cindex Time stamp
+@cindex Current time
+
+@noindent
+Provides a simple function that returns a string -MM-DD HH:MM:SS.SS that
+represents the current date and time in ISO 8601 format. This is a very simple
+routine with minimal code and there are no dependencies on any other unit.
+
 @node GNAT.Traceback (g-traceb.ads)
 @section @code{GNAT.Traceback} (@file{g-traceb.ads})
 @cindex @code{GNAT.Traceback} (@file{g-traceb.ads})
@@ -22469,7 +22471,7 @@
 @include fdl.texi
 @c GNU Free Documentation License
 
-@node Index,,GNU Free Documentation License, Top
+@node Concept Index
 @unnumbered Index
 
 @printindex cp
@@ -22477,5 +22479,3 @@
 @contents
 
 @bye
-tablishes the following set of restrictions:
-Pragma Shared

Re: [patch] Add libstdc++ type printers for class templates

2014-07-14 Thread Tom Tromey

 Jonathan == Jonathan Wakely jwak...@redhat.com writes:

Jonathan This defines a new style of Python type printer that
Jonathan recognizes templates and can be used to omit default template
Jonathan arguments from the typename GDB prints, e.g. showing
Jonathan std::vectorT, std::allocatorT as simply std::vectorT.
Jonathan Additionally, T will get processed by the type recognizers so
Jonathan if it's a standard typedef or template it will also get
Jonathan displayed in its abbreviated form.

Nice.

I'd hoped to eventually implement this automatically using some
information from gcc; see:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49090
https://sourceware.org/bugzilla/show_bug.cgi?id=15251

However I haven't gotten around to it; and anyway your approach is nice
and not only doesn't conflict with the above, but may continue to be
useful even if the above is implemented.

Jonathan This passes the python testsuite but I'll wait for comments before
Jonathan committing, in case my use of the GDB API or Python can be improved by
Jonathan anyone.

It looked fine to me.

Tom

Re: [PATCH 2/2] Enable elimination of zext/sext

2014-07-14 Thread Bernhard Reutner-Fischer


On 14 July 2014 04:58:17 Kugan kugan.vivekanandara...@linaro.org wrote:


On 11/07/14 22:47, Richard Biener wrote:
 On Fri, Jul 11, 2014 at 1:52 PM, Kugan
 kugan.vivekanandara...@linaro.org wrote:
 Thanks foe the review and suggestions.

 On 10/07/14 22:15, Richard Biener wrote:
 On Mon, Jul 7, 2014 at 8:55 AM, Kugan 
kugan.vivekanandara...@linaro.org wrote:


 [...]


 For -fwrapv, it is due to how PROMOTE_MODE is defined in arm back-end.
 In the test-case, a function (which has signed char return type) returns
 -1 in one of the paths. ARM PROMOTE_MODE changes that to 255 and relies
 on zero/sign extension generated by RTL again for the correct value. I
 saw some other targets also defining similar think. I am therefore
 skipping removing zero/sign extension if the ssa variable can be set to
 negative integer constants.

 Hm?  I think you should rather check that you are removing a
 sign-/zero-extension - PROMOTE_MODE tells you if it will sign- or
 zero-extend.  Definitely

 +  /* In some architectures, negative integer constants are truncated and
 + sign changed with target defined PROMOTE_MODE macro. This will impact
 + the value range seen here and produce wrong code if zero/sign 
extensions

 + are eliminated. Therefore, return false if this SSA can have negative
 + integers.  */
 +  if (is_gimple_assign (stmt)
 +   (TREE_CODE_CLASS (gimple_assign_rhs_code (stmt)) == tcc_unary))
 +{
 +  tree rhs1 = gimple_assign_rhs1 (stmt);
 +  if (TREE_CODE (rhs1) == INTEGER_CST
 +  !TYPE_UNSIGNED (TREE_TYPE (ssa))
 +  tree_int_cst_compare (rhs1, integer_zero_node) == -1)
 +   return false;

 looks completely bogus ... (an unary op with a constant operand?)
 instead you want to do sth like

 I see that unary op with a constant operand is not possible in gimple.
 What I wanted to check here is any sort of constant loads; but seems
 that will not happen in gimple. Is PHI statements the only possible
 statements where we will end up with such constants.

 No, in theory you can have

   ssa_1 = -1;

 but that's not unary but a GIMPLE_SINGLE_RHS and thus
 gimple_assign_rhs_code (stmt) == INTEGER_CST.

   mode = TYPE_MODE (TREE_TYPE (ssa));
   rhs_uns = TYPE_UNSIGNED (TREE_TYPE (ssa));
   PROMOTE_MODE (mode, rhs_uns, TREE_TYPE (ssa));

 instead of initializing rhs_uns from ssas type.  That is, if
 PROMOTE_MODE tells you to promote _not_ according to ssas sign then
 honor that.

 This is triggered in pr43017.c in function foo for arm-none-linux-gnueabi.

 where, the gimple statement that cause this looks like:
 .
   # _3 = PHI _17(7), -1(2)
 bb43:
   return _3;

 ARM PROMOTE_MODE changes the sign for integer constants only and hence
 looking at the variable with PROMOTE_MODE is not changing the sign in
 this case.

 #define PROMOTE_MODE(MODE, UNSIGNEDP, TYPE) \
   if (GET_MODE_CLASS (MODE) == MODE_INT \
GET_MODE_SIZE (MODE)  4)  \
 {   \
   if (MODE == QImode)   \
 UNSIGNEDP = 1;  \
   else if (MODE == HImode)  \
 UNSIGNEDP = 1;  \
   (MODE) = SImode;  \
 }

 Where does it only apply for constants?  It applies to all QImode and
 HImode entities.

oops, sorry. I don’t know what I was thinking or looking at when I wrote
that :( It indeed fixes my problems. Thanks for that.

Here is the modified patch. Bootstrapped and regression tested for
86_64-unknown-linux-gnu and arm-none-linux-gnueabi with no new regressions.


Is this OK?

Thanks,
Kugan


gcc/

2014-07-14  Kugan Vivekanandarajah  kug...@linaro.org

* calls.c (precompute_arguments): Check is_promoted_for_type
and set the promoted mode.
(is_promoted_for_type): New function.


Don't we name predicates more like promoted_for_type_p?

Thanks,

(expand_expr_real_1): Check is_promoted_for_type
and set the promoted mode.
* expr.h (is_promoted_for_type): New function definition.
* cfgexpand.c (expand_gimple_stmt_1): Call emit_move_insn if
SUBREG is promoted with SRP_SIGNED_AND_UNSIGNED.


gcc/testsuite
2014-07-14  Kugan Vivekanandarajah  kug...@linaro.org

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




Sent with AquaMail for Android
http://www.aqua-mail.com

Re: [patch] Add libstdc++ type printers for class templates

2014-07-14 Thread Tom Tromey

 Jonathan == Jonathan Wakely jwak...@redhat.com writes:

Jonathan I forgot to say that with these type recognizers we might want to
Jonathan revisit the output of the existing printers for the containers, so
Jonathan that instead of:
Jonathan  std::map with 3 elements = { ... }
Jonathan GDB could print the map type:
Jonathan  std::mapint, int with 3 elements = { ... }

I think the reason for the brevity right now is just that, even eliding
the defaults, the type names can get rather long.  It's not absurd
though, just maybe not always desirable.  One possible approach would be
to make a new gdb.Parameter in the libstdc++ code to control it.

Tom

C++ PATCH for c++/61445 (ICE with local class)

When I fixed 56947 in 4.7, I added an assert to make sure that the trunk 
was being sensible in the way I expected: local class member functions 
are supposed to be instantiated from the TAG_DEFN.  But we can get to 
instantiate_decl before that if it's used from another local class 
member function, so the assert is wrong; let's just remove it.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 3115f729a22d8244965b68807561eef04019757a
Author: Jason Merrill ja...@redhat.com
Date:   Mon Jul 14 01:39:33 2014 -0400

	PR c++/61445
	PR c++/56947
	* pt.c (instantiate_decl): Don't check defer_ok for local class
	members.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 7b79280..b32cf6c 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -19775,11 +19775,6 @@ instantiate_decl (tree d, int defer_ok,
   if (external_p  !always_instantiate_p (d))
 return d;
 
-  /* Any local class members should be instantiated from the TAG_DEFN
- with defer_ok == 0.  */
-  gcc_checking_assert (!defer_ok || !decl_function_context (d)
-		   || LAMBDA_TYPE_P (DECL_CONTEXT (d)));
-
   gen_tmpl = most_general_template (tmpl);
   gen_args = DECL_TI_ARGS (d);
 
diff --git a/gcc/testsuite/g++.dg/template/local9.C b/gcc/testsuite/g++.dg/template/local9.C
new file mode 100644
index 000..90f14bb
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/local9.C
@@ -0,0 +1,15 @@
+// PR c++/61445
+
+template typename T void f (T)
+{
+  struct A
+  {
+struct B { B(); };
+void g () { B b; }
+  };
+}
+
+int main()
+{
+  f(0);
+}

[GOOGLE] replace getline with fgets

2014-07-14 Thread Dehao Chen

This patch replaces getline with fgets so that gcc builts fine in darwin.

Testing on going, ok for google-4_9 if test passes?

Thanks,
Dehao

Index: gcc/coverage.c
===
--- gcc/coverage.c (revision 212523)
+++ gcc/coverage.c (working copy)
@@ -584,9 +584,9 @@ static void
 reorder_module_groups (const char *imports_file, unsigned max_group)
 {
   FILE *f;
-  int n, order = 0;
-  size_t len;
-  char *line = NULL;
+  int order = 0;
+  const int max_line_size = (1  16);
+  char line[max_line_size];

   module_name_tab.create (20);

@@ -594,20 +594,23 @@ reorder_module_groups (const char *imports_file, u
   if (!f)
 error (Can't open file %s, imports_file);

-  while ((n = getline (line, len, f)) != -1)
+  while (fgets (line, max_line_size, f))
 {
+  size_t n = strlen (line);
+  gcc_assert (n  max_line_size - 1);
+  if (line[n - 1] == '\n')
+ line[n - 1] = '\0';
+
   module_name_entry **slot;
   module_name_entry *m_e = XCNEW (module_name_entry);

-  line[n - 1] = '\0';
-  m_e-source_name = line;
+  m_e-source_name = xstrdup (line);
   m_e-order = order;

   slot = module_name_tab.find_slot (m_e, INSERT);
   gcc_assert (!*slot);
   *slot = m_e;

-  line = NULL;
   order++;
 }

Re: [C++ Patch/RFC] PR 60608

2014-07-14 Thread Paolo Carlini


Hi,

On 07/14/2014 09:47 PM, Jason Merrill wrote:

On 07/14/2014 12:20 PM, Paolo Carlini wrote:

I have been looking a bit into this bug, using a reduced testcase which
simplifies the debugging quite a bit for me (a non-variadic variant is
ok). I cannot say to already understand all the details of the issue,
but something which strikes me as interesting, is that the DEDUCE_CALL
passed down by add_candidate gets lost and we end up calling
type_unification_real from unify with DEDUCE_EXACT. If I change it to an
unconditional DEDUCE_CALL, the testcase is accepted and the testsuite
passes with no regressions. Is that all there is to the issue?!?


Unfortunately, that goes too far.  I think we want a new DEDUCE_PARMS 
that is like DEDUCE_EXACT but does the same transformations as 
tsubst_arg_types in this part of unify_pack_expansion:


Thanks. This helps me a lot. In particular I see now, in tsubst_arg_types:

/* Do array-to-pointer, function-to-pointer conversion, and ignore
   top-level qualifiers as required.  */
type = cv_unqualified (type_decays_to (type));

which is exactly the ingredient we are missing. A rough draft already 
appears to work on the testcase, now I have only to figure out what 
happens of the various switches over unification_kind_t and adjust the 
other details (also, comments).


Thanks again,
Paolo.

symtab PATCH for c++/61623 (comdat issue in verify_symtab)

The problem in this testcase is that we inlined the decloned constructor 
into the calling thunks, so it was removed by 
symtab_remove_unreachable_nodes.  verify_symtab sees that it is no 
longer linked to the calling thunks with same_comdat_group and complains.


Here I've changed verify_symtab to only look at TREE_PUBLIC decls, since 
comdat-local symbols can be removed if they aren't needed.  I also 
adjusted the diagnostic so it would print the two symbols in question 
rather than the same one twice.  :)


OK for trunk?
commit e29dc7a675fdbc1adce40908fda4d5408f0103a0
Author: Jason Merrill ja...@redhat.com
Date:   Mon Jul 14 16:58:57 2014 -0400

	PR c++/61623
	* symtab.c (verify_symtab): Don't worry about comdat-internal
	symbols.

diff --git a/gcc/symtab.c b/gcc/symtab.c
index 3a59935..dc4d84d 100644
--- a/gcc/symtab.c
+++ b/gcc/symtab.c
@@ -1202,7 +1202,8 @@ verify_symtab (void)
   FOR_EACH_SYMBOL (node)
 {
   verify_symtab_node (node);
-  if (node-get_comdat_group ())
+  if (node-get_comdat_group ()
+	   TREE_PUBLIC (node-decl))
 	{
 	  symtab_node **entry, *s;
 	  bool existed;
@@ -1217,7 +1218,7 @@ verify_symtab (void)
 		{
 		  error (Two symbols with same comdat_group are not linked by the same_comdat_group list.);
 		  dump_symtab_node (stderr, *entry);
-		  dump_symtab_node (stderr, s);
+		  dump_symtab_node (stderr, node);
 		  internal_error (verify_symtab failed);
 		}
 	}
diff --git a/gcc/testsuite/g++.dg/opt/declone2.C b/gcc/testsuite/g++.dg/opt/declone2.C
new file mode 100644
index 000..e725d8e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/opt/declone2.C
@@ -0,0 +1,10 @@
+// PR c++/61623
+// { dg-options -Os }
+
+struct C {};
+struct B : virtual C {};
+struct A : B {
+  A (int) {}
+};
+
+A a (0);

Re: [C++ Patch/RFC] PR 60608


On 07/14/2014 05:12 PM, Paolo Carlini wrote:

Thanks. This helps me a lot. In particular I see now, in tsubst_arg_types:

 /* Do array-to-pointer, function-to-pointer conversion, and ignore
top-level qualifiers as required.  */
 type = cv_unqualified (type_decays_to (type));

which is exactly the ingredient we are missing.


I think we probably want to share the void and abstract checks too.

Jason

Re: [patch,gomp-4_0-branch] misc reduction clause bug fixes

2014-07-14 Thread Cesar Philippidis

On 07/11/2014 02:15 AM, Thomas Schwinge wrote:
 Hi Cesar!
 
 On Thu, 10 Jul 2014 11:43:11 -0700, Cesar Philippidis 
 ce...@codesourcery.com wrote:
 This patch addresses two bugs openacc reduction clause bugs.
 
 Thanks!  OK; one question/suggestion, though:
 
 --- a/gcc/omp-low.c
 +++ b/gcc/omp-low.c
 @@ -9679,11 +9679,23 @@ process_reduction_data (gimple_seq *body, gimple_seq 
 *in_stmt_seqp,
gcc_assert (is_gimple_omp_oacc_specifically (ctx-stmt));
  
gimple_stmt_iterator gsi;
 +  gimple_seq inner;
 +  gimple stmt;
 +
 +  /* A collapse clause may have inserted a new bind block.  */
 +  stmt = gimple_seq_first (*body);
 +  if (stmt  gimple_code (stmt) == GIMPLE_BIND)
 +{
 +  inner = gimple_bind_body (gimple_seq_first (*body));
 +  body = inner;
 +}
  
for (gsi = gsi_start (*body); !gsi_end_p (gsi); gsi_next (gsi))
  {
gimple stmt = gsi_stmt (gsi);
 
 Can get rid of this shadow variable stmt?

I've committed the attach patch which incorporates that change.

Cesar

2014-07-14  Cesar Philippidis  ce...@codesourcery.com

	gcc/
	* omp-low.c (process_reduction_data): Check for new
	binding level and skip for-loops which don't have a
	reduction clause.


diff --git a/gcc/omp-low.c b/gcc/omp-low.c
index 227ff1b..b08bc6b 100644
--- a/gcc/omp-low.c
+++ b/gcc/omp-low.c
@@ -9679,11 +9679,24 @@ process_reduction_data (gimple_seq *body, gimple_seq *in_stmt_seqp,
   gcc_assert (is_gimple_omp_oacc_specifically (ctx-stmt));
 
   gimple_stmt_iterator gsi;
+  gimple_seq inner;
+  gimple stmt;
+
+  /* A collapse clause may have inserted a new bind block.  */
+  stmt = gimple_seq_first (*body);
+  if (stmt  gimple_code (stmt) == GIMPLE_BIND)
+{
+  inner = gimple_bind_body (gimple_seq_first (*body));
+  body = inner;
+}
 
   for (gsi = gsi_start (*body); !gsi_end_p (gsi); gsi_next (gsi))
 {
-  gimple stmt = gsi_stmt (gsi);
   tree call;
+  tree clauses, nthreads, t, c;
+  bool reduction_found = false;
+ 
+  stmt = gsi_stmt (gsi);
 
   switch (gimple_code (stmt))
 	{
@@ -9691,6 +9704,18 @@ process_reduction_data (gimple_seq *body, gimple_seq *in_stmt_seqp,
 	  tree clauses, nthreads, t;
 
 	  clauses = gimple_omp_for_clauses (stmt);
+
+	  /* Search for a reduction clause.  */
+	  for (c = clauses; c; c = OMP_CLAUSE_CHAIN (c))
+	if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_REDUCTION)
+	  {
+		reduction_found = true;
+		break;
+	  }
+
+	  if (!reduction_found)
+	break;
+
 	  ctx = maybe_lookup_ctx (stmt);
 	  t = NULL_TREE;
 
@@ -9698,8 +9723,6 @@ process_reduction_data (gimple_seq *body, gimple_seq *in_stmt_seqp,
 	 Scan for the innermost vector_length clause.  */
 	  for (omp_context *oc = ctx; oc; oc = oc-outer)
 	{
-	  tree c;
-
 	  switch (gimple_code (oc-stmt))
 		{
 		case GIMPLE_OACC_PARALLEL:

Re: [patch,gomp-4_0-branch] openacc collapse clause

2014-07-14 Thread Cesar Philippidis

On 07/11/2014 02:27 AM, Thomas Schwinge wrote:
 Hi Cesar!
 
 On Thu, 10 Jul 2014 11:47:42 -0700, Cesar Philippidis 
 ce...@codesourcery.com wrote:
 These patch enables the collapse clause with a value greater than one.
 
 Thanks!
 
 Is this patch OK for gomp-4_0-branch?
 
 OK with the following addressed:
 
 --- a/gcc/c/c-parser.c
 +++ b/gcc/c/c-parser.c
 @@ -11260,6 +11260,10 @@ c_parser_oacc_all_clauses (c_parser *parser, 
 omp_clause_mask mask,
  
switch (c_kind)
  {
 +case PRAGMA_OMP_CLAUSE_COLLAPSE:
 +  clauses = c_parser_omp_clause_collapse (parser, clauses);
 +  c_name = collapse;
 +  break;
 
 Annotate c_parser_omp_clause_collapse that it is now used for OpenACC,
 too.
 
 
  #define OACC_LOOP_CLAUSE_MASK   
 \
 -(OMP_CLAUSE_MASK_1  PRAGMA_OMP_CLAUSE_REDUCTION)
 +( (OMP_CLAUSE_MASK_1  PRAGMA_OMP_CLAUSE_COLLAPSE) \
 +| (OMP_CLAUSE_MASK_1  PRAGMA_OMP_CLAUSE_REDUCTION))
 
 Given the syntax generally used, add a space between the two closing
 parens.
 
 
 Even though we're re-using OpenMP's tested implementation, please add
 some basic front end test coverage for OpenACC: reject invalid, accept
 valid syntax.

Thanks for the feedback. I've committed the attach patch with those changes.

Cesar

2014-07-14  Cesar Philippidis  ce...@codesourcery.com

	gcc/c/
	* c-parser.c (c_parser_oacc_all_clauses): Handle
	PRAGMA_OMP_CLAUSE_COLLAPSE.
	(OACC_LOOP_CLAUSE_MASK): Add PRAGMA_OMP_CLAUSE_COLLAPSE.
	(c_parser_omp_for_loop): Remove asserts.

	gcc/
	* omp-low.c (extract_omp_for_data): Likewise.
	(expand_omp_for_static_nochunk): Likewise.

	gcc/testsuite/
	* c-c++-common/goacc/collapse-1.c: New test.


diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index d638930..4e2ea33 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -10057,7 +10057,7 @@ c_parser_oacc_data_clause_deviceptr (c_parser *parser, tree list)
   return list;
 }
 
-/* OpenMP 3.0:
+/* OpenACC 2.0, OpenMP 3.0:
collapse ( constant-expression ) */
 
 static tree
@@ -11260,6 +11260,10 @@ c_parser_oacc_all_clauses (c_parser *parser, omp_clause_mask mask,
 
   switch (c_kind)
 	{
+	case PRAGMA_OMP_CLAUSE_COLLAPSE:
+	  clauses = c_parser_omp_clause_collapse (parser, clauses);
+	  c_name = collapse;
+	  break;
 	case PRAGMA_OMP_CLAUSE_COPY:
 	  clauses = c_parser_oacc_data_clause (parser, c_kind, clauses);
 	  c_name = copy;
@@ -11702,7 +11706,8 @@ c_parser_oacc_kernels (location_t loc, c_parser *parser, char *p_name)
 */
 
 #define OACC_LOOP_CLAUSE_MASK		\
-	(OMP_CLAUSE_MASK_1  PRAGMA_OMP_CLAUSE_REDUCTION)
+	( (OMP_CLAUSE_MASK_1  PRAGMA_OMP_CLAUSE_COLLAPSE)		\
+	| (OMP_CLAUSE_MASK_1  PRAGMA_OMP_CLAUSE_REDUCTION) )
 
 static tree
 c_parser_oacc_loop (location_t loc, c_parser *parser, char *p_name)
@@ -12306,10 +12311,7 @@ c_parser_omp_for_loop (location_t loc, c_parser *parser, enum tree_code code,
 
   for (cl = clauses; cl; cl = OMP_CLAUSE_CHAIN (cl))
 if (OMP_CLAUSE_CODE (cl) == OMP_CLAUSE_COLLAPSE)
-  {
-	gcc_assert (code != OACC_LOOP);
   collapse = tree_to_shwi (OMP_CLAUSE_COLLAPSE_EXPR (cl));
-  }
 
   gcc_assert (collapse = 1);
 
diff --git a/gcc/omp-low.c b/gcc/omp-low.c
index b08bc6b..6345e14 100644
--- a/gcc/omp-low.c
+++ b/gcc/omp-low.c
@@ -381,9 +381,6 @@ extract_omp_for_data (gimple for_stmt, struct omp_for_data *fd,
   case OMP_CLAUSE_COLLAPSE:
 	if (fd-collapse  1)
 	  {
-	if (is_gimple_omp_oacc_specifically (for_stmt))
-	  sorry (collapse (1) clause not supported yet);
-
 	collapse_iter = OMP_CLAUSE_COLLAPSE_ITERVAR (t);
 	collapse_count = OMP_CLAUSE_COLLAPSE_COUNT (t);
 	  }
@@ -6684,9 +6681,6 @@ expand_omp_for_static_nochunk (struct omp_region *region,
 
   if (fd-collapse  1)
 {
-  gcc_assert (gimple_omp_for_kind (fd-for_stmt)
-		  != GF_OMP_FOR_KIND_OACC_LOOP);
-
   int first_zero_iter = -1;
   basic_block l2_dom_bb = NULL;
 
@@ -6697,12 +6691,7 @@ expand_omp_for_static_nochunk (struct omp_region *region,
   t = NULL_TREE;
 }
   else if (gimple_omp_for_combined_into_p (fd-for_stmt))
-{
-  gcc_assert (gimple_omp_for_kind (fd-for_stmt)
-		  != GF_OMP_FOR_KIND_OACC_LOOP);
-
 t = integer_one_node;
-}
   else
 t = fold_binary (fd-loop.cond_code, boolean_type_node,
 		 fold_convert (type, fd-loop.n1),
@@ -6736,9 +6725,6 @@ expand_omp_for_static_nochunk (struct omp_region *region,
   ep-probability = REG_BR_PROB_BASE / 2000 - 1;
   if (gimple_in_ssa_p (cfun))
 	{
-	  gcc_assert (gimple_omp_for_kind (fd-for_stmt)
-		  != GF_OMP_FOR_KIND_OACC_LOOP);
-
 	  int dest_idx = find_edge (entry_bb, fin_bb)-dest_idx;
 	  for (gsi = gsi_start_phis (fin_bb);
 	   !gsi_end_p (gsi); gsi_next (gsi))
@@ -6865,9 +6851,6 @@ expand_omp_for_static_nochunk (struct omp_region *region,
 
   if (gimple_omp_for_combined_p (fd-for_stmt))
 {
-  gcc_assert (gimple_omp_for_kind (fd-for_stmt)
-		  != GF_OMP_FOR_KIND_OACC_LOOP);
-
   tree clauses =

Re: [GOOGLE] replace getline with fgets

2014-07-14 Thread Andrew Pinski

On Mon, Jul 14, 2014 at 1:40 PM, Dehao Chen de...@google.com wrote:
 This patch replaces getline with fgets so that gcc builts fine in darwin.


Why not add getline to libiberty instead?  This patch causes a huge stack usage.

Thanks,
Andrew Pinski


 Testing on going, ok for google-4_9 if test passes?

 Thanks,
 Dehao

 Index: gcc/coverage.c
 ===
 --- gcc/coverage.c (revision 212523)
 +++ gcc/coverage.c (working copy)
 @@ -584,9 +584,9 @@ static void
  reorder_module_groups (const char *imports_file, unsigned max_group)
  {
FILE *f;
 -  int n, order = 0;
 -  size_t len;
 -  char *line = NULL;
 +  int order = 0;
 +  const int max_line_size = (1  16);
 +  char line[max_line_size];

module_name_tab.create (20);

 @@ -594,20 +594,23 @@ reorder_module_groups (const char *imports_file, u
if (!f)
  error (Can't open file %s, imports_file);

 -  while ((n = getline (line, len, f)) != -1)
 +  while (fgets (line, max_line_size, f))
  {
 +  size_t n = strlen (line);
 +  gcc_assert (n  max_line_size - 1);
 +  if (line[n - 1] == '\n')
 + line[n - 1] = '\0';
 +
module_name_entry **slot;
module_name_entry *m_e = XCNEW (module_name_entry);

 -  line[n - 1] = '\0';
 -  m_e-source_name = line;
 +  m_e-source_name = xstrdup (line);
m_e-order = order;

slot = module_name_tab.find_slot (m_e, INSERT);
gcc_assert (!*slot);
*slot = m_e;

 -  line = NULL;
order++;
  }

Re: [GOOGLE] replace getline with fgets

2014-07-14 Thread Xinliang David Li

On Mon, Jul 14, 2014 at 2:37 PM, Andrew Pinski pins...@gmail.com wrote:
 On Mon, Jul 14, 2014 at 1:40 PM, Dehao Chen de...@google.com wrote:
 This patch replaces getline with fgets so that gcc builts fine in darwin.


 Why not add getline to libiberty instead?  This patch causes a huge stack 
 usage.

The callee is only called when a debug option (for developer) is
turned on so the stack usage is not big concern. Longer term, we may
want to add getline as you suggested.

David



 Thanks,
 Andrew Pinski


 Testing on going, ok for google-4_9 if test passes?

 Thanks,
 Dehao

 Index: gcc/coverage.c
 ===
 --- gcc/coverage.c (revision 212523)
 +++ gcc/coverage.c (working copy)
 @@ -584,9 +584,9 @@ static void
  reorder_module_groups (const char *imports_file, unsigned max_group)
  {
FILE *f;
 -  int n, order = 0;
 -  size_t len;
 -  char *line = NULL;
 +  int order = 0;
 +  const int max_line_size = (1  16);
 +  char line[max_line_size];

module_name_tab.create (20);

 @@ -594,20 +594,23 @@ reorder_module_groups (const char *imports_file, u
if (!f)
  error (Can't open file %s, imports_file);

 -  while ((n = getline (line, len, f)) != -1)
 +  while (fgets (line, max_line_size, f))
  {
 +  size_t n = strlen (line);
 +  gcc_assert (n  max_line_size - 1);
 +  if (line[n - 1] == '\n')
 + line[n - 1] = '\0';
 +
module_name_entry **slot;
module_name_entry *m_e = XCNEW (module_name_entry);

 -  line[n - 1] = '\0';
 -  m_e-source_name = line;
 +  m_e-source_name = xstrdup (line);
m_e-order = order;

slot = module_name_tab.find_slot (m_e, INSERT);
gcc_assert (!*slot);
*slot = m_e;

 -  line = NULL;
order++;
  }

Re: [patch] Add libstdc++ type printers for class templates


On 14/07/14 14:08 -0600, Tom Tromey wrote:

Jonathan This passes the python testsuite but I'll wait for comments before
Jonathan committing, in case my use of the GDB API or Python can be improved by
Jonathan anyone.

It looked fine to me.


Thanks for checking it. One thing I should have mentioned is the
inconsistency between regex subgroups and string replacement fields:

   add_one_template_type_printer(obj, 'unique_ptrT',
   'unique_ptr(.*), std::default_delete\\1 ? ',
   'unique_ptr{1}')

It might seem odd that the last argument uses {1} not \\1 but the
reason is that what gets substituted there is not actually \\1 but
rather the result of applying type printers to \\1, and I implemented
the substitution via string.format(), rather than reimplementing most
of re.sub() by hand.

Re: [patch] Add libstdc++ type printers for class templates