Re: Refactor gcc/tree-vectorize.c:vectorize_loops

[Jakub Jelinek]

On Tue, Apr 28, 2015 at 09:53:24PM -0600, Jeff Law wrote:
> On 04/28/2015 08:20 PM, Aditya K wrote:
> >Hi,
> >This is a small patch where I moved a portion of code from the function 
> >vectorize_loops outside to improve readability.
> >Please see the patch attached and give comments for improvements.
> You need to add a comment for the new function.  These function comments
> should describe what the function does, in terms of its arguments and return
> value (if any).
> 
> With a function comment, this refactoring would be fine.

--- a/gcc/tree-vectorizer.c
+++ b/gcc/tree-vectorizer.c
@@ -399,6 +399,39 @@ fold_loop_vectorized_call (gimple g, tree value)
 }
 }
 
+static void
+set_uid_loop_bbs(loop_vec_info loop_vinfo, gimple loop_vectorized_call)

The formatting is incorrect too, missing space before ( here.

+{
+tree arg = gimple_call_arg (loop_vectorized_call, 1);

Lines should be indented by 2 spaces rather than after {

+basic_block *bbs;
+unsigned int i;
+struct loop *scalar_loop = get_loop (cfun, tree_to_shwi (arg));
+
+LOOP_VINFO_SCALAR_LOOP (loop_vinfo) = scalar_loop;
+gcc_checking_assert (vect_loop_vectorized_call
+(LOOP_VINFO_SCALAR_LOOP (loop_vinfo))
+ == loop_vectorized_call);
+bbs = get_loop_body (scalar_loop);
+for (i = 0; i < scalar_loop->num_nodes; i++)
+  {
+basic_block bb = bbs[i];
+gimple_stmt_iterator gsi;
+for (gsi = gsi_start_phis (bb); !gsi_end_p (gsi);
+ gsi_next (&gsi))

With the refactoring, this for should fit on one line.

+  {
+gimple phi = gsi_stmt (gsi);
+gimple_set_uid (phi, 0);
+  }
+for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi);
+ gsi_next (&gsi))

Likewise.

if (loop_vectorized_call)
- {
+  set_uid_loop_bbs(loop_vinfo, loop_vectorized_call);

Again, missing space before (.  And you are using only spaces
when a tab plus two spaces should be used.

Jakub

New template for 'cpplib' made available

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.  (If you have
any questions, send them to .)

A new POT file for textual domain 'cpplib' has been made available
to the language teams for translation.  It is archived as:

http://translationproject.org/POT-files/cpplib-5.1.0.pot

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

Below is the URL which has been provided to the translators of your
package.  Please inform the translation coordinator, at the address
at the bottom, if this information is not current:

https://ftp.gnu.org/gnu/gcc/gcc-5.1.0/gcc-5.1.0.tar.bz2

Translated PO files will later be automatically e-mailed to you.

Thank you for all your work,

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

[Fortran, Patch] (RFC, Coarray) Implement TS18508's EVENTS

[Tobias Burnus]

Dear all,

attached patch fixes a bug and implements EVENTS. I think the patch is
finished, but I still have to extend the test cases, to re-read the
patch and to write a changelog. As I am not sure how soon I will able
to do so, I follow the paradigm: release soon, release often and post
it here. Comments and reviews are welcome.

The patch fixes two bug in the "errmsg" handling, found by Alessandro:
I don't pass on the address of the actual argument and in libcaf_single,
I copy only 8 characters (sizeof pointer) instead of all of the the
characters of the error message.

Regarding events: Events is a way to permit barrier/locking-free
programming: One sends the finished data to an other image and then
tells that image that the data is there ("event post(msg_var[idx])").
That image can then either wait for the event by querying the status
on the local variable ("event wait(msg_var)") or only check the status
and if it is not ready do something else (e.g. another iteration);
that's done via "call event_query(msg_var, count)".

Technically, event_post works like atomic_add(msg_var[idx], 1) and
event_query like "atomic_ref(msg_var, count)". event_wait is the same
as event_query plus a spin/sleep loop waiting for the status change,
followed by an atomic_add(msg_var, -until_count). Except that
event_post/event_wait are image control statements. (Otherwise it
could happen that the event is there before the data for which the
event has been posted.)

Regarding the implementation in this patch, the limitations are the
same as for locking: Currently, neither lock_type nor event_type
variables are permitted as (nonallocatable) components
of a derived type - and type extension of them also not yet supported.*

The spec can be found at http://bitly.com/sc22wg5 -> 2015 -> TS draft
or directly at
http://isotc.iso.org/livelink/livelink?func=ll&objId=17064344&objAction=Open

Tobias


* Doing so is not really difficult but I need to handle cases like
the following. For "allocatable" with SOURCE= I also need to handle
it with polymorphic types.

type t1
  type(event_type) :: EV
  type(lock_type) :: LK
end type1
type t2
  type(t1) :: a(5)
end type t2
type t3
  type(t2) :: b(8)
end type t3

type(t3), save :: caf(3)[*]

For those, I need to call _gfortran_caf_register for
  caf(:)%b(:)%a(:)%ev and caf(:)%b(:)%a(:)%lk
Looping though all array references.

Similar for
  type(t3), allocatable :: caf2(:)[:]
  allocate(caf2(n)[*])
for the allocate call.
 gcc/fortran/check.c   |  54 +++
 gcc/fortran/dump-parse-tree.c |  27 
 gcc/fortran/expr.c|  13 ++
 gcc/fortran/gfortran.h|   8 +-
 gcc/fortran/gfortran.texi | 141 --
 gcc/fortran/interface.c   |  31 +++-
 gcc/fortran/intrinsic.c   |   7 +
 gcc/fortran/intrinsic.h   |   2 +
 gcc/fortran/iresolve.c|   8 ++
 gcc/fortran/iso-fortran-env.def   |   5 +
 gcc/fortran/match.c   | 199 ++
 gcc/fortran/match.h   |   2 +
 gcc/fortran/module.c  |   8 +-
 gcc/fortran/parse.c   |  69 -
 gcc/fortran/resolve.c |  94 ++--
 gcc/fortran/st.c  |   2 +
 gcc/fortran/trans-decl.c  |  28 +++-
 gcc/fortran/trans-expr.c  |   8 +-
 gcc/fortran/trans-intrinsic.c | 150 +++
 gcc/fortran/trans-stmt.c  | 163 +
 gcc/fortran/trans-stmt.h  |   1 +
 gcc/fortran/trans-types.c |   5 +
 gcc/fortran/trans.c   |  17 ++-
 gcc/fortran/trans.h   |   7 +-
 gcc/testsuite/gfortran.dg/coarray/event_1.f90 |  51 +++
 gcc/testsuite/gfortran.dg/coarray/event_2.f90 |  89 
 26 files changed, 1151 insertions(+), 38 deletions(-)

diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index cdb5ff1..d3570b3 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -1151,6 +1151,60 @@ gfc_check_atomic_cas (gfc_expr *atom, gfc_expr *old, gfc_expr *compare,
 
 
 bool
+gfc_check_event_query (gfc_expr *event, gfc_expr *count, gfc_expr *stat)
+{
+  if (event->ts.type != BT_DERIVED
+  || event->ts.u.derived->from_intmod != INTMOD_ISO_FORTRAN_ENV
+  || event->ts.u.derived->intmod_sym_id != ISOFORTRAN_EVENT_TYPE)
+{
+  gfc_error ("EVENT argument at %L to the intrinsic EVENT_QUERY "
+		 "shall be of type EVENT_TYPE", &event->where);
+  return false;
+}
+
+  if (!scalar_check (event, 0))
+return false;
+
+  if (!gfc_check_vardef_context (count, false, false, false, NULL))
+{
+  gfc_error ("COUNT argument of the EVENT_QUERY intrinsic function at %L "
+		 "shall be definable", &count->whe

Re: [PATCH, RFC]: Next stage1, refactoring: propagating rtx subclasses

[Mikhail Maltsev]

On 28.04.2015 16:46, Richard Sandiford wrote:
>> +inline void rtx_jump_insn::set_jump_target (rtx_insn *target) +{
>> + JUMP_LABEL(this) = target;
Fixed.

> Could these two operate on rtx_code_labels rather than rtx_insns?
Indeed, right now [set_]jump_target are not used with NOTE's, so I could
promote the type to rtx_code_label with no regressions.

> Long line -- can break before "(CASE_LABEL"
Fixed. Others too. Rechecked with contrib/check_GNU_style.sh (no
warnings, except one special case in gcc/recog.h).

On 28.04.2015 20:08, Jeff Law wrote:
> Agreed.  These corner cases are precisely the kinds of things we
> want to be identifying and cleaning up as we go.   I haven't looked
> at the updated patch yet, but if there isn't a comment about this
> case, then there should be.
Done.

> Needs a ChangeLog.  I know it's a bit tedious...  But please include
> it.  It makes patch review easier, and we need one for the ChangeLog
> file anyway.
Attached.

> In general, probably more as_a conversions than I'd like.  But that
> may be unavoidable at this point.  On a positive note, I do see some
> going away as you strengthen various return and parameter types.

Also some conversions are, perhaps, unavoidable when they come right
after a check, so the type is indeed narrowed.

> I probably would have done separate patches for the std::swap
> changes. They're not really related to the rtx subclasses work.
OK, sending 2 separate patches. Note that they a not "commutative":
std::swap should be applied before the main one, because one of the
swaps in do_compare_rtx_and_jump uses a single temporary variable of
type rtx for swapping labels and for storing generic rtl expressions
(this could be worked around, of course, but I think that would be just
a waste of time).

> I'm not sure why you added indention in expand_expr_real_2's switch
> statement.  It certainly makes the patch harder to review.  I'm going
> to assume there was a good reason for the new {} pair and added
> indention.
Sorry for that. I had to introduce a couple of variables, and I decided
to limit their scope in order to make their use less error-prone.


-- 
Regards,
Mikhail Maltsev
gcc/ChangeLog:

2015-04-29  Mikhail Maltsev  

Promote types of RTL expressions to more derived ones.
* bb-reorder.c (set_edge_can_fallthru_flag): Use rtx_jump_insn where
feasible.
(fix_up_fall_thru_edges): Likewise.
(fix_crossing_conditional_branches): Likewise. Promote jump targets
from to rtx_insn to rtx_code_label where feasible.
* bt-load.c (move_btr_def): Remove as-a cast of the value returned by
gen_move_insn (returned type changed to rtx_insn).
* builtins.c (expand_errno_check): Fix arguments of
do_compare_rtx_and_jump (now expects rtx_code_label).
(expand_builtin_acc_on_device): Likewise.
* cfgcleanup.c (try_simplify_condjump): Add cast when calling
invert_jump (now exprects rtx_jump_insn).
* cfgexpand.c (label_rtx_for_bb): Promote return type to
rtx_code_label.
(construct_init_block): Use rtx_code_label.
* cfgrtl.c (block_label): Promote return type to rtx_code_label.
(try_redirect_by_replacing_jump): Use cast to rtx_jump_insn when
calling redirect_jump.
(patch_jump_insn): Likewise.
(redirect_branch_edge): Likewise.
(force_nonfallthru_and_redirect): Likewise.
(fixup_reorder_chain): Explicitly use rtx_jump_insn instead of rtx_insn
when suitable.
(rtl_lv_add_condition_to_bb): Update call of do_compare_rtx_and_jump.
* cfgrtl.h: Promote return type of block_label to rtx_code_label.
* config/i386/i386.c (ix86_emit_cmove): Explicitly use rtx_code_label
to store the value retured by gen_label_rtx.
* dojump.c (jumpifnot): Promote argument type from rtx to
rtx_code_label.
(jumpifnot_1): Likewise.
(jumpif): Likewise.
(jumpif_1): Likewise.
(do_jump_1): Likewise.
(do_jump): Likewise. Use rtx_code_label when feasible.
(do_jump_by_parts_greater_rtx): Likewise.
(do_jump_by_parts_zero_rtx): Likewise.
(do_jump_by_parts_equality_rtx): Likewise.
(do_compare_rtx_and_jump): Likewise.
* dojump.h: Update function prototypes.
* dse.c (emit_inc_dec_insn_before): Remove case (gen_move_insn now
returns rtx_insn).
* emit-rtl.c (emit_label_before): Promote return type to
rtx_code_label.
(emit_label): Likewise.
* except.c (sjlj_emit_dispatch_table): Use jump_target_rtx.
* explow.c (emit_stack_save): Update for new return type of
gen_move_insn.
(emit_stack_restore): Likewise.
* expmed.c (emit_store_flag_force): Fix calls of
do_compare_rtx_and_jump.
(do_cmp_and_jump): Likewise.
* expr.c (expand_expr_real_2): Likewise. Promote some local variables
from rtx to rtx_code_l

New template for 'gcc' made available

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.  (If you have
any questions, send them to .)

A new POT file for textual domain 'gcc' has been made available
to the language teams for translation.  It is archived as:

http://translationproject.org/POT-files/gcc-5.1.0.pot

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

Below is the URL which has been provided to the translators of your
package.  Please inform the translation coordinator, at the address
at the bottom, if this information is not current:

https://ftp.gnu.org/gnu/gcc/gcc-5.1.0/gcc-5.1.0.tar.bz2

Translated PO files will later be automatically e-mailed to you.

Thank you for all your work,

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

[PATCH] PR target/48904 x86_64-knetbsd-gnu missing defs

[Bernhard Reutner-Fischer]

2012-09-21  H.J. Lu  

PR target/48904
* config.gcc (x86_64-*-knetbsd*-gnu): Add i386/knetbsd-gnu64.h.
* config/i386/knetbsd-gnu64.h: New file

Signed-off-by: Bernhard Reutner-Fischer 
---

This fixes config-list.mk all-gcc for x86_64-knetbsd-gnu.
Ok for trunk?

 gcc/config.gcc  |2 +-
 gcc/config/i386/knetbsd-gnu64.h |   27 +++
 2 files changed, 28 insertions(+), 1 deletion(-)
 create mode 100644 gcc/config/i386/knetbsd-gnu64.h

diff --git a/gcc/config.gcc b/gcc/config.gcc
index a1df043..77ef473 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1517,7 +1517,7 @@ x86_64-*-linux* | x86_64-*-kfreebsd*-gnu | 
x86_64-*-knetbsd*-gnu)
tm_file="${tm_file} kfreebsd-gnu.h i386/kfreebsd-gnu64.h"
;;
x86_64-*-knetbsd*-gnu)
-   tm_file="${tm_file} knetbsd-gnu.h"
+   tm_file="${tm_file} knetbsd-gnu.h i386/knetbsd-gnu64.h"
;;
esac
tmake_file="${tmake_file} i386/t-linux64"
diff --git a/gcc/config/i386/knetbsd-gnu64.h b/gcc/config/i386/knetbsd-gnu64.h
new file mode 100644
index 000..d621bbe
--- /dev/null
+++ b/gcc/config/i386/knetbsd-gnu64.h
@@ -0,0 +1,27 @@
+/* Definitions for AMD x86-64 running kNetBSD-based GNU systems with ELF format
+   Copyright (C) 2012
+   Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+#define GNU_USER_LINK_EMULATION32 "elf_i386"
+#define GNU_USER_LINK_EMULATION64 "elf_x86_64"
+#define GNU_USER_LINK_EMULATIONX32 "elf32_x86_64"
+
+#define GNU_USER_DYNAMIC_LINKER32 "/lib/ld.so.1"
+#define GNU_USER_DYNAMIC_LINKER64 "/lib/ld-knetbsd-x86-64.so.1"
+#define GNU_USER_DYNAMIC_LINKERX32 "/lib/ld-knetbsd-x32.so.1"
-- 
1.7.10.4

[PATCH] gimple-walk.c #include TLC

[Bernhard Reutner-Fischer]

Hi there,

I noticed that gimple-walk.c has a creative list of #includes.
Furthermore, in walk_gimple_asm parse_{in,out}put_constraint was called
even if neither allows_mem, allows_reg nor is_inout were used -- i.e. if
wi is NULL -- and the return value of the constraint parsing was not
taken into account which looks wrong or at least odd. Note that several
other spots in the tree do ignore the parse_{in,out}put_constraint return
values and should be adjusted too AFAIU. Otherwise we might attempt
(and use!) to extract information from otherwise illegal constraints,
it seems?

Bootstrapped and regtested on x86_64-unknown-linux with no regressions.
Ok for trunk?

gcc/ChangeLog:

* gimple-walk.c: Prune duplicate or unneeded includes.
(walk_gimple_asm): Only call parse_input_constraint or
parse_output_constraint if their findings are used.
Honour parse_input_constraint and parse_output_constraint
result.

diff --git a/gcc/gimple-walk.c b/gcc/gimple-walk.c
index 45ff859..53462b5 100644
--- a/gcc/gimple-walk.c
+++ b/gcc/gimple-walk.c
@@ -2,75 +2,69 @@
 
Copyright (C) 2007-2015 Free Software Foundation, Inc.
Contributed by Aldy Hernandez 
 
 This file is part of GCC.
 
 GCC is free software; you can redistribute it and/or modify it under
 the terms of the GNU General Public License as published by the Free
 Software Foundation; either version 3, or (at your option) any later
 version.
 
 GCC is distributed in the hope that it will be useful, but WITHOUT ANY
 WARRANTY; without even the implied warranty of MERCHANTABILITY or
 FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 for more details.
 
 You should have received a copy of the GNU General Public License
 along with GCC; see the file COPYING3.  If not see
 .  */
 
 #include "config.h"
 #include "system.h"
 #include "coretypes.h"
 #include "tm.h"
 #include "hash-set.h"
-#include "machmode.h"
 #include "vec.h"
 #include "double-int.h"
 #include "input.h"
 #include "alias.h"
 #include "symtab.h"
-#include "wide-int.h"
 #include "inchash.h"
 #include "tree.h"
-#include "fold-const.h"
-#include "stmt.h"
 #include "predict.h"
 #include "hard-reg-set.h"
-#include "input.h"
 #include "function.h"
-#include "basic-block.h"
-#include "tree-ssa-alias.h"
-#include "internal-fn.h"
 #include "gimple-expr.h"
 #include "is-a.h"
+#include "tree-ssa-alias.h"
+#include "basic-block.h"
+#include "fold-const.h"
 #include "gimple.h"
 #include "gimple-iterator.h"
 #include "gimple-walk.h"
-#include "gimple-walk.h"
-#include "demangle.h"
+#include "stmt.h"
 
 /* Walk all the statements in the sequence *PSEQ calling walk_gimple_stmt
on each one.  WI is as in walk_gimple_stmt.
 
If walk_gimple_stmt returns non-NULL, the walk is stopped, and the
value is stored in WI->CALLBACK_RESULT.  Also, the statement that
produced the value is returned if this statement has not been
removed by a callback (wi->removed_stmt).  If the statement has
been removed, NULL is returned.
 
Otherwise, all the statements are walked and NULL returned.  */
 
 gimple
 walk_gimple_seq_mod (gimple_seq *pseq, walk_stmt_fn callback_stmt,
 walk_tree_fn callback_op, struct walk_stmt_info *wi)
 {
   gimple_stmt_iterator gsi;
 
   for (gsi = gsi_start (*pseq); !gsi_end_p (gsi); )
 {
   tree ret = walk_gimple_stmt (&gsi, callback_stmt, callback_op, wi);
   if (ret)
{
  /* If CALLBACK_STMT or CALLBACK_OP return a value, WI must exist
 to hold it.  */
@@ -107,71 +101,76 @@ walk_gimple_seq (gimple_seq seq, walk_stmt_fn 
callback_stmt,
 
 /* Helper function for walk_gimple_stmt.  Walk operands of a GIMPLE_ASM.  */
 
 static tree
 walk_gimple_asm (gasm *stmt, walk_tree_fn callback_op,
 struct walk_stmt_info *wi)
 {
   tree ret, op;
   unsigned noutputs;
   const char **oconstraints;
   unsigned i, n;
   const char *constraint;
   bool allows_mem, allows_reg, is_inout;
 
   noutputs = gimple_asm_noutputs (stmt);
   oconstraints = (const char **) alloca ((noutputs) * sizeof (const char *));
 
   if (wi)
 wi->is_lhs = true;
 
   for (i = 0; i < noutputs; i++)
 {
   op = gimple_asm_output_op (stmt, i);
   constraint = TREE_STRING_POINTER (TREE_VALUE (TREE_PURPOSE (op)));
   oconstraints[i] = constraint;
-  parse_output_constraint (&constraint, i, 0, 0, &allows_mem, &allows_reg,
-  &is_inout);
   if (wi)
-   wi->val_only = (allows_reg || !allows_mem);
+   {
+ if (parse_output_constraint (&constraint, i, 0, 0, &allows_mem,
+  &allows_reg, &is_inout))
+   wi->val_only = (allows_reg || !allows_mem);
+   }
   ret = walk_tree (&TREE_VALUE (op), callback_op, wi, NULL);
   if (ret)
return ret;
 }
 
   n = gimple_asm_ninputs (stmt);
   for (i = 0; i < n; i++)
 {
   op = gimple_asm_input_op (stmt

[PATCH] Some SLP with gaps related fixes

[Richard Biener]

These are bugfixes that prepare handling of SLP loads with gaps
and more SLP permutation kinds.

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

Richard.

2015-04-29  Richard Biener  

* tree-vect-data-refs.c (vect_analyze_group_access): Properly
compute GROUP_SIZE for basic-block SLP.
* tree-vect-slp.c (vect_get_place_in_interleaving_chain): Properly
take into account gaps.
(vect_get_mask_element): Properly reject references to previous
vectors.
(vect_transform_slp_perm_load): Likewise.

Index: gcc/tree-vect-data-refs.c
===
*** gcc/tree-vect-data-refs.c   (revision 222514)
--- gcc/tree-vect-data-refs.c   (working copy)
*** vect_analyze_group_access (struct data_r
*** 2245,2251 
  }
  
if (groupsize == 0)
! groupsize = count;
  
GROUP_SIZE (vinfo_for_stmt (stmt)) = groupsize;
if (dump_enabled_p ())
--- 2271,2277 
  }
  
if (groupsize == 0)
! groupsize = count + gaps;
  
GROUP_SIZE (vinfo_for_stmt (stmt)) = groupsize;
if (dump_enabled_p ())
Index: gcc/tree-vect-slp.c
===
*** gcc/tree-vect-slp.c (revision 222514)
--- gcc/tree-vect-slp.c (working copy)
*** vect_get_place_in_interleaving_chain (gi
*** 223,230 
  {
if (next_stmt == stmt)
return result;
-   result++;
next_stmt = GROUP_NEXT_ELEMENT (vinfo_for_stmt (next_stmt));
  }
while (next_stmt);
  
--- 223,231 
  {
if (next_stmt == stmt)
return result;
next_stmt = GROUP_NEXT_ELEMENT (vinfo_for_stmt (next_stmt));
+   if (next_stmt)
+   result += GROUP_GAP (vinfo_for_stmt (next_stmt));
  }
while (next_stmt);
  
*** vect_get_mask_element (gimple stmt, int
*** 3008,3013 
--- 3033,3050 
/* Adjust the value in case it's a mask for second and third vectors.  */
*current_mask_element -= mask_nunits * (*number_of_mask_fixes - 1);
  
+   if (*current_mask_element < 0)
+ {
+   if (dump_enabled_p ())
+   {
+ dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
+  "permutation requires past vector ");
+ dump_gimple_stmt (MSG_MISSED_OPTIMIZATION, TDF_SLIM, stmt, 0);
+ dump_printf (MSG_MISSED_OPTIMIZATION, "\n");
+   }
+   return false;
+ }
+ 
if (*current_mask_element < mask_nunits)
  *needs_first_vector = true;
  
*** vect_transform_slp_perm_load (slp_tree n
*** 3178,3184 
  &number_of_mask_fixes, &mask_fixed,
  &needs_first_vector))
return false;
! gcc_assert (current_mask_element < 2 * nunits);
  mask[index++] = current_mask_element;
  
if (index == nunits)
--- 3215,3222 
  &number_of_mask_fixes, &mask_fixed,
  &needs_first_vector))
return false;
! gcc_assert (current_mask_element >= 0
! && current_mask_element < 2 * nunits);
  mask[index++] = current_mask_element;
  
if (index == nunits)

Re: gcc/c-family/c-pragma.h:pragma_omp_clause (was: Pragma parsing)

[Jakub Jelinek]

On Tue, Apr 28, 2015 at 06:59:12PM +0200, Thomas Schwinge wrote:
> We're getting ready to submit patches extending the C/C++ front ends for
> the remaining OpenACC clauses, and given the current layout of
> gcc/c-family/c-pragma.h:pragma_omp_clause, we're then at 69 unique
> clauses, which is more than the 64-bit bitmask limit.
> 
> > [...] I understand,
> > for example, PRAGMA_OMP_CLAUSE_REDUCTION to just be a "numeric
> > representation" of the "reduction" string [...]
> 
> Should we now further split parsing of Cilk+/OpenACC/OpenMP pragmas (but
> I think you and I agreed that we don't want to go that route), or
> revisist Chung-Lin's std::bitset proposal (see below), or something else?
> 
> Regarding std::bitset, you've been worried about performance,
> ,
> but I'm not sure about this: aren't these code paths only exercised for
> pragma parsing, and aren't there really only ever one handful (or, a few)
> of pragmas per source code file, so this could hardly be an observable
> performance hit?

As I said earlier, I run into this during OpenMP 4.1 work too.  The
std::bitset variant generates significantly larger code to what I've
bootstrapped/regtested on x86_64-linux and i686-linux and committed to
trunk.  Furthermore, there are severe issues with including STL headers
in the middle of GCC include files, and not even C++14 allows bitsets to be
readably initialized (...set(X).set(Y).set(Z).set(W) doesn't IMHO count).

2015-04-29  Jakub Jelinek  

* c-common.h (omp_clause_mask): Unconditionally define as a class.
Use uint64_t instead of unsigned HOST_WIDE_INT and 64 instead of
HOST_BITS_PER_WIDE_INT.

--- gcc/c-family/c-common.h.jj  2015-04-11 15:55:57.0 +0200
+++ gcc/c-family/c-common.h 2015-04-29 10:19:17.629643284 +0200
@@ -1096,16 +1096,11 @@ extern void pp_dir_change (cpp_reader *,
 extern bool check_missing_format_attribute (tree, tree);
 
 /* In c-omp.c  */
-#if HOST_BITS_PER_WIDE_INT >= 64
-typedef unsigned HOST_WIDE_INT omp_clause_mask;
-# define OMP_CLAUSE_MASK_1 ((omp_clause_mask) 1)
-#else
 struct omp_clause_mask
 {
   inline omp_clause_mask ();
-  inline omp_clause_mask (unsigned HOST_WIDE_INT l);
-  inline omp_clause_mask (unsigned HOST_WIDE_INT l,
- unsigned HOST_WIDE_INT h);
+  inline omp_clause_mask (uint64_t l);
+  inline omp_clause_mask (uint64_t l, uint64_t h);
   inline omp_clause_mask &operator &= (omp_clause_mask);
   inline omp_clause_mask &operator |= (omp_clause_mask);
   inline omp_clause_mask operator ~ () const;
@@ -1115,7 +1110,7 @@ struct omp_clause_mask
   inline omp_clause_mask operator << (int);
   inline bool operator == (omp_clause_mask) const;
   inline bool operator != (omp_clause_mask) const;
-  unsigned HOST_WIDE_INT low, high;
+  uint64_t low, high;
 };
 
 inline
@@ -1124,14 +1119,13 @@ omp_clause_mask::omp_clause_mask ()
 }
 
 inline
-omp_clause_mask::omp_clause_mask (unsigned HOST_WIDE_INT l)
+omp_clause_mask::omp_clause_mask (uint64_t l)
 : low (l), high (0)
 {
 }
 
 inline
-omp_clause_mask::omp_clause_mask (unsigned HOST_WIDE_INT l,
- unsigned HOST_WIDE_INT h)
+omp_clause_mask::omp_clause_mask (uint64_t l, uint64_t h)
 : low (l), high (h)
 {
 }
@@ -1177,18 +1171,17 @@ inline omp_clause_mask
 omp_clause_mask::operator << (int amount)
 {
   omp_clause_mask ret;
-  if (amount >= HOST_BITS_PER_WIDE_INT)
+  if (amount >= 64)
 {
   ret.low = 0;
-  ret.high = low << (amount - HOST_BITS_PER_WIDE_INT);
+  ret.high = low << (amount - 64);
 }
   else if (amount == 0)
 ret = *this;
   else
 {
   ret.low = low << amount;
-  ret.high = (low >> (HOST_BITS_PER_WIDE_INT - amount))
-| (high << amount);
+  ret.high = (low >> (64 - amount)) | (high << amount);
 }
   return ret;
 }
@@ -1197,17 +1190,16 @@ inline omp_clause_mask
 omp_clause_mask::operator >> (int amount)
 {
   omp_clause_mask ret;
-  if (amount >= HOST_BITS_PER_WIDE_INT)
+  if (amount >= 64)
 {
-  ret.low = high >> (amount - HOST_BITS_PER_WIDE_INT);
+  ret.low = high >> (amount - 64);
   ret.high = 0;
 }
   else if (amount == 0)
 ret = *this;
   else
 {
-  ret.low = (high << (HOST_BITS_PER_WIDE_INT - amount))
-| (low >> amount);
+  ret.low = (high << (64 - amount)) | (low >> amount);
   ret.high = high >> amount;
 }
   return ret;
@@ -1225,8 +1217,7 @@ omp_clause_mask::operator != (omp_clause
   return low != b.low || high != b.high;
 }
 
-# define OMP_CLAUSE_MASK_1 omp_clause_mask (1)
-#endif
+#define OMP_CLAUSE_MASK_1 omp_clause_mask (1)
 
 enum c_omp_clause_split
 {


Jakub

Re: Mostly rewrite genrecog

[Eric Botcazou]

> I think it's been the case for a while that parallel builds of GCC tend
> to serialise around the compilation of insn-recog.c, especially with
> higher --enable-checking settings.  This patch tries to speed that
> up by replacing most of genrecog with a new algorithm.

I can confirm this, especially with --enable-checking=rtl.

> Also, the code is all goto-based, which makes it rather hard to step
> through.

Do you mean the code in genrecog.c or the generated code in insn-recog.c?

> The patch deals with these as follows:
> 
> 1. Detect subpatterns that differ only by mode, code and/or integer
>(e.g. unspec number) and split them out into a common routine.
> 
> 2. Match the "shape" of the instruction first, in terms of codes,
>integers and vector lengths, and only then check the modes, predicates
>and dups.  When checking the shape, handle SET_SRCs before SET_DESTs.
>In practice this seems to greatly reduce the amount of backtracking.
> 
> 3. Have one local variable per rtx position.  I tested the patch with
>and without the change and it helped a lot with rtl-checking builds
>without seeming to affect release builds much either way.
> 
> As far as debuggability goes, the new code avoids gotos and just
> uses "natural" control flow.

See below.

> The headline stat is that a stage 3 --enable-checking=yes,rtl,df
> build of insn-recog.c on my box goes from 7m43s to 2m2s (using the
> same stage 2 compiler).  The corresponding --enable-checking=release
> change is from 49s to 24s (less impressive, as expected).

The first figure is quite impressive, great work!

> PS. I've attached the new genrecog.c since the diff version is unreadable.

Small request: you didn't change a single line of the head comment, yet the 
size of the file is doubled.  Could you add a sketch of the algorithm to the 
head comment, e.g. by copy-and-pasting the above part of your message?

The old code contained a couple of DEBUG_FUNCTIONs but the new one doesn't.

-- 
Eric Botcazou

[PATCH] XFAIL PR65917

[Richard Biener]

The testcase gcc.dg/tree-ssa/20030922-2.c FAILs on m68k (and possibly
elsewhere), not on x86_64 though.

So on x86_64 ifcombine has "removed" the if but after dom1 we still have

  _14 = *_13;
  if (_8 != _14)
goto ;
  else
goto ;

  :
  target_bb.1_15 = target_bb;
  _16 = _8 != target_bb.1_15;
  _17 = _14 == target_bb.1_15;
  _18 = _16 & _17;
  if (_18 != 0)

which shows that running ifcombine before DOM might not be the best idea.

It also shows that the testcase should disable ifcombine to really test 
what it was supposed to test.  And then it also fails on x86_64.

VRP does optimize this case because it has a more powerful way to track
equivalences (and does a quadratic job in trying to simplify compares 
using
all equivalences of the lhs vs all equivalences of the rhs).

Which is another hint at the fact that DOM maybe shouldn't treat 
equivalences
derived from conditionals in the SSA_VALUE table where you can't really 
record
both _14 = target_bb.1_15 and target_bb.1_15 = _14 (which would get you a
nice cycle there).

For the existing way of DOM handlign this I don't see anything in the 
testcase
that could be used to build a new heuristic (in fact another heuristic
would say that what we do now is good -- _14 dies at the point where we
build the equivalency, target_bb.1_15 does not, so we don't want to 
propagate
_14 because that will increase its lifetime!)

So the following "fixes" the testcase to also FAIL on x86_64 and
XFAILs it.

Tested on x86_64, applied.

Richard.

2015-04-29  Richard Biener  

PR tree-optimization/65917
* gcc.dg/tree-ssa/20030922-2.c: Disable ifcombine and XFAIL.

Index: gcc/testsuite/gcc.dg/tree-ssa/20030922-2.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/20030922-2.c  (revision 222560)
+++ gcc/testsuite/gcc.dg/tree-ssa/20030922-2.c  (working copy)
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O1 -fdump-tree-dom1" } */
+/* { dg-options "-O1 -fdump-tree-dom1 -fdisable-tree-ifcombine" } */
 
 struct rtx_def;
 typedef struct rtx_def *rtx;
@@ -20,5 +20,9 @@ rgn_rank (rtx insn1, rtx insn2)
 }
 
 /* There should be two IF conditionals.  */
-/* { dg-final { scan-tree-dump-times "if " 2 "dom1" } } */
+/* This now fails as it requires a very specific decision of DOM which
+   SSA name to record as a copy of the other when DOM derives copies
+   from temporary equivalences.  The heuristics there no longer do
+   the correct thing.  VRP still optimizes this testcase.  */
+/* { dg-final { scan-tree-dump-times "if " 2 "dom1" { xfail *-*-* } } } */
 /* { dg-final { cleanup-tree-dump "dom1" } } */

Re: Fix OpenMP's target update directive in templated code

[Jakub Jelinek]

On Tue, Apr 28, 2015 at 08:45:50PM +0200, Thomas Schwinge wrote:
> I guess nobody so far ;-) has been using OpenMP's target update directive
> in templated code -- OK to commit the following, and to which branches
> (4.9, 5, trunk)?

Seems I've missed testcases for target {,update,data} in templates indeed,
generally for C++ I'm trying to add testcases for templates, both when
relevant types are type dependent and whey aren't.

>   gcc/cp/
>   * pt.c (tsubst_expr) : Use
>   OMP_TARGET_UPDATE_CLAUSES instead of OMP_CLAUSES.
>   gcc/testsuite/
>   * g++.dg/gomp/tpl-target-update.C: New file.

This is ok for trunk, 5.2 and 4.9.3, thanks for fixing that.

> That said, what is the preferred approach to add support for
> OACC_ENTER_DATA, OACC_EXIT_DATA, OACC_UPDATE?  I'm not sure hard-coding
> TREE_OPERAND (t, 0) in gcc/cp/pt.c:tsubst_expr is the way to go, and also
> duplicating the OMP_TARGET_UPDATE code for each of the three OACC_*
> doesn't sound appealing -- especially given that we just "switch"ed on
> the respective tree code, so the O*_CHECK of the respective O*_CLAUSES
> macro is completely redundant.  Is it OK to extend gcc/tree.h:OMP_CLAUSES
> so that it can also be used for tree codes that keep clauses in operand
> 0, and then use that here (and also in
> gcc/gimplify.c:gimplify_omp_target_update, for example)?

How could it work when it is operand 1 on some and operand 0 in others.
IMHO, if you want to reuse the same code for OMP_TARGET_UPDATE,
various OACC_* standalone directives (and
OMP_TARGET_ENTER_DATA/OMP_TARGET_EXIT_DATA in OpenMP 4.1), then
you should make sure they are consecutive in target.def and
define OMP_STANDALONE_CLAUSES or OMP_TARGET_STANDALONE_CLAUSES as
a range check between OMP_TARGET_UPDATE and the last OpenACC directive
without body, just clauses.

Jakub

[PATCH][PR65893] Move pass_stdarg to after pass_dce in pass_all_optimizations

[Tom de Vries]

Hi,

After moving the expansion of va_arg from gimplification to pass_stdarg, we 
execute less optimization passes on the expanded va_arg.


For example, in PR65893 the optimized-dump code for a va_arg expansion for 
aarch64 is less optimal than it was before, because pass_tree_ifcombine is no 
longer executed for the expanded va_arg.


This patch fixes the problem by moving pass_stdarg a bit earlier, to after 
pass_dce:
...
   NEXT_PASS (pass_vrp);
   NEXT_PASS (pass_chkp_opt);
   NEXT_PASS (pass_dce);
+  NEXT_PASS (pass_stdarg);
   NEXT_PASS (pass_call_cdce);
   NEXT_PASS (pass_cselim);
   NEXT_PASS (pass_copy_prop);
   NEXT_PASS (pass_tree_ifcombine);
   NEXT_PASS (pass_phiopt);
   NEXT_PASS (pass_tail_recursion);
   NEXT_PASS (pass_ch);
-  NEXT_PASS (pass_stdarg);
   NEXT_PASS (pass_lower_complex);
   NEXT_PASS (pass_sra);
   NEXT_PASS (pass_rename_ssa_copies);
...

Bootstrapped and reg-tested on x86_64.

OK for trunk?

Thanks,
- Tom
Move pass_stdarg to after pass_dce in pass_all_optimizations

2015-04-29  Tom de Vries  

	PR tree-optimization/65893
	* passes.def (pass_all_optimizations): Move pass_stdarg to after
	pass_dce.
---
 gcc/passes.def | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/passes.def b/gcc/passes.def
index 6dce141..32213e8 100644
--- a/gcc/passes.def
+++ b/gcc/passes.def
@@ -172,6 +172,7 @@ along with GCC; see the file COPYING3.  If not see
   NEXT_PASS (pass_vrp);
   NEXT_PASS (pass_chkp_opt);
   NEXT_PASS (pass_dce);
+  NEXT_PASS (pass_stdarg);
   NEXT_PASS (pass_call_cdce);
   NEXT_PASS (pass_cselim);
   NEXT_PASS (pass_copy_prop);
@@ -179,7 +180,6 @@ along with GCC; see the file COPYING3.  If not see
   NEXT_PASS (pass_phiopt);
   NEXT_PASS (pass_tail_recursion);
   NEXT_PASS (pass_ch);
-  NEXT_PASS (pass_stdarg);
   NEXT_PASS (pass_lower_complex);
   NEXT_PASS (pass_sra);
   NEXT_PASS (pass_rename_ssa_copies);
-- 
1.9.1

[PATCH, ARM] Fix for pr65924

[Yvan Roux]

Hi,

here is the patch for PR65924, only tested on the original testcase so far.

Thanks
Yvan

gcc/
2015-04-29  Yvan Roux  

PR target/65924
* config/arm/thumb2.md (*thumb2_addsi3_compare0_scratch): Fix operand
number in type attribute expression.

gcc/testsuite/
2015-04-29  Yvan Roux  

PR target/65924
gcc.target/arm/pr65924.c: New test.
diff --git a/gcc/config/arm/thumb2.md b/gcc/config/arm/thumb2.md
index 4f9faac..2c91542 100644
--- a/gcc/config/arm/thumb2.md
+++ b/gcc/config/arm/thumb2.md
@@ -1305,7 +1305,7 @@
   "
   [(set_attr "conds" "set")
(set_attr "length" "2,4")
-   (set (attr "type") (if_then_else (match_operand 2 "const_int_operand" "")
+   (set (attr "type") (if_then_else (match_operand 1 "const_int_operand" "")
 (const_string "alus_imm")
 (const_string "alus_sreg")))]
 )
diff --git a/gcc/testsuite/gcc.target/arm/pr65924.c 
b/gcc/testsuite/gcc.target/arm/pr65924.c
new file mode 100644
index 000..746749f
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/pr65924.c
@@ -0,0 +1,8 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mthumb" } */
+
+int a, b, c;
+int fn1() {
+  if (b + a < 0)
+c = 0;
+}

Re: [PATCH] gimple-walk.c #include TLC

[Richard Biener]

On Wed, Apr 29, 2015 at 10:01 AM, Bernhard Reutner-Fischer
 wrote:
> Hi there,
>
> I noticed that gimple-walk.c has a creative list of #includes.
> Furthermore, in walk_gimple_asm parse_{in,out}put_constraint was called
> even if neither allows_mem, allows_reg nor is_inout were used -- i.e. if
> wi is NULL -- and the return value of the constraint parsing was not
> taken into account which looks wrong or at least odd. Note that several
> other spots in the tree do ignore the parse_{in,out}put_constraint return
> values and should be adjusted too AFAIU. Otherwise we might attempt
> (and use!) to extract information from otherwise illegal constraints,
> it seems?
>
> Bootstrapped and regtested on x86_64-unknown-linux with no regressions.
> Ok for trunk?

Ok.

Thanks,
Richard.

> gcc/ChangeLog:
>
> * gimple-walk.c: Prune duplicate or unneeded includes.
> (walk_gimple_asm): Only call parse_input_constraint or
> parse_output_constraint if their findings are used.
> Honour parse_input_constraint and parse_output_constraint
> result.
>
> diff --git a/gcc/gimple-walk.c b/gcc/gimple-walk.c
> index 45ff859..53462b5 100644
> --- a/gcc/gimple-walk.c
> +++ b/gcc/gimple-walk.c
> @@ -2,75 +2,69 @@
>
> Copyright (C) 2007-2015 Free Software Foundation, Inc.
> Contributed by Aldy Hernandez 
>
>  This file is part of GCC.
>
>  GCC is free software; you can redistribute it and/or modify it under
>  the terms of the GNU General Public License as published by the Free
>  Software Foundation; either version 3, or (at your option) any later
>  version.
>
>  GCC is distributed in the hope that it will be useful, but WITHOUT ANY
>  WARRANTY; without even the implied warranty of MERCHANTABILITY or
>  FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>  for more details.
>
>  You should have received a copy of the GNU General Public License
>  along with GCC; see the file COPYING3.  If not see
>  .  */
>
>  #include "config.h"
>  #include "system.h"
>  #include "coretypes.h"
>  #include "tm.h"
>  #include "hash-set.h"
> -#include "machmode.h"
>  #include "vec.h"
>  #include "double-int.h"
>  #include "input.h"
>  #include "alias.h"
>  #include "symtab.h"
> -#include "wide-int.h"
>  #include "inchash.h"
>  #include "tree.h"
> -#include "fold-const.h"
> -#include "stmt.h"
>  #include "predict.h"
>  #include "hard-reg-set.h"
> -#include "input.h"
>  #include "function.h"
> -#include "basic-block.h"
> -#include "tree-ssa-alias.h"
> -#include "internal-fn.h"
>  #include "gimple-expr.h"
>  #include "is-a.h"
> +#include "tree-ssa-alias.h"
> +#include "basic-block.h"
> +#include "fold-const.h"
>  #include "gimple.h"
>  #include "gimple-iterator.h"
>  #include "gimple-walk.h"
> -#include "gimple-walk.h"
> -#include "demangle.h"
> +#include "stmt.h"
>
>  /* Walk all the statements in the sequence *PSEQ calling walk_gimple_stmt
> on each one.  WI is as in walk_gimple_stmt.
>
> If walk_gimple_stmt returns non-NULL, the walk is stopped, and the
> value is stored in WI->CALLBACK_RESULT.  Also, the statement that
> produced the value is returned if this statement has not been
> removed by a callback (wi->removed_stmt).  If the statement has
> been removed, NULL is returned.
>
> Otherwise, all the statements are walked and NULL returned.  */
>
>  gimple
>  walk_gimple_seq_mod (gimple_seq *pseq, walk_stmt_fn callback_stmt,
>  walk_tree_fn callback_op, struct walk_stmt_info *wi)
>  {
>gimple_stmt_iterator gsi;
>
>for (gsi = gsi_start (*pseq); !gsi_end_p (gsi); )
>  {
>tree ret = walk_gimple_stmt (&gsi, callback_stmt, callback_op, wi);
>if (ret)
> {
>   /* If CALLBACK_STMT or CALLBACK_OP return a value, WI must exist
>  to hold it.  */
> @@ -107,71 +101,76 @@ walk_gimple_seq (gimple_seq seq, walk_stmt_fn 
> callback_stmt,
>
>  /* Helper function for walk_gimple_stmt.  Walk operands of a GIMPLE_ASM.  */
>
>  static tree
>  walk_gimple_asm (gasm *stmt, walk_tree_fn callback_op,
>  struct walk_stmt_info *wi)
>  {
>tree ret, op;
>unsigned noutputs;
>const char **oconstraints;
>unsigned i, n;
>const char *constraint;
>bool allows_mem, allows_reg, is_inout;
>
>noutputs = gimple_asm_noutputs (stmt);
>oconstraints = (const char **) alloca ((noutputs) * sizeof (const char *));
>
>if (wi)
>  wi->is_lhs = true;
>
>for (i = 0; i < noutputs; i++)
>  {
>op = gimple_asm_output_op (stmt, i);
>constraint = TREE_STRING_POINTER (TREE_VALUE (TREE_PURPOSE (op)));
>oconstraints[i] = constraint;
> -  parse_output_constraint (&constraint, i, 0, 0, &allows_mem, 
> &allows_reg,
> -  &is_inout);
>if (wi)
> -   wi->val_only = (allows_reg || !allows_mem);
> +   {
> + if (parse_output_constraint (&constraint, i, 0, 0, &allows_mem,
> +

Re: [PATCH][PR65893] Move pass_stdarg to after pass_dce in pass_all_optimizations

[Richard Biener]

On Wed, Apr 29, 2015 at 10:52 AM, Tom de Vries  wrote:
> Hi,
>
> After moving the expansion of va_arg from gimplification to pass_stdarg, we
> execute less optimization passes on the expanded va_arg.
>
> For example, in PR65893 the optimized-dump code for a va_arg expansion for
> aarch64 is less optimal than it was before, because pass_tree_ifcombine is
> no longer executed for the expanded va_arg.
>
> This patch fixes the problem by moving pass_stdarg a bit earlier, to after
> pass_dce:
> ...
>NEXT_PASS (pass_vrp);
>NEXT_PASS (pass_chkp_opt);
>NEXT_PASS (pass_dce);
> +  NEXT_PASS (pass_stdarg);
>NEXT_PASS (pass_call_cdce);
>NEXT_PASS (pass_cselim);
>NEXT_PASS (pass_copy_prop);
>NEXT_PASS (pass_tree_ifcombine);
>NEXT_PASS (pass_phiopt);
>NEXT_PASS (pass_tail_recursion);
>NEXT_PASS (pass_ch);
> -  NEXT_PASS (pass_stdarg);
>NEXT_PASS (pass_lower_complex);
>NEXT_PASS (pass_sra);
>NEXT_PASS (pass_rename_ssa_copies);
> ...
>
> Bootstrapped and reg-tested on x86_64.
>
> OK for trunk?

Ok.

Thanks,
Richard.

> Thanks,
> - Tom

Re: [PATCH] Remove some restrictions on loop shape in tree-if-conv.c

[Alan Lawrence]

Sorry, I realize I forgot to attach the patch to the original email, this 
followed a couple of minutes later in message <553f91b9.7050...@arm.com> at 
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01745.html .


Cheers, Alan

Jeff Law wrote:

On 04/28/2015 07:55 AM, Alan Lawrence wrote:

Tree if-conversion currently bails out for loops that (a) contain nested
loops; (b) have more than one exit; (c) where the exit block (source of
the exit edge) does not dominate the loop latch; (d) where the exit
block is the loop header, or there are statements after the exit.

This patch removes restrictions (c) and (d). The intuition is that, for
(c), "if (P) {... if (Q) break;}" is equivalent to "if (P) {...}; if
(P&&Q) break;" and this is mostly handled by existing code for
propagating conditions. For (d), "if (P) break; stmts" is equivalent to
"if (!P) stmts; if (P) break;" - this requires inserting the predicated
stmts before the branch rather than after.

Mostly thus this patch is just removing assumptions about when we
do/don't need to store predicates. One 'gotcha' was in some test cases
the latch block passed into if-conversion is non-empty; in such cases,
if-conversion will now restore "good form" by moving the statement into
the exit block (predicated with !exit-condition).

The condition on dominance in add_to_predicate_list, I haven't quite
managed to convince myself is right; we _do_ want to store a predicate
for the latch block to handle the above case, but I'm not totally sure
of the postdominance condition - I think it may store conditions in
cases where we don't really need to (e.g. "for (;;) { ... if (P) { for
(;;) ; } }" which might look nested but isn't, and has no route to the
function exit). However, storing conditions when we don't need to, is
OK, unlike failing to store when we do need to ;).

A simple example of the patch at work:

int
foo ()
{
   for (int i = 0; i < N ; i++)
   {
 int m = (a[i] & i) ? 5 : 4;
 b[i] = a[i] * m;
   }
}

compiled at -O3, -fdump-tree-ivcanon shows this immediately before
tree-if-conversion:

...function entry, variables, etc...
   :
   _10 = a[0];
   goto ;

   :
   _5 = a[i_9];
   _6 = _5 & i_9;
   if (_6 != 0)
 goto ;
   else
 goto ;

   :

   :
   # m_14 = PHI <5(3), 4(4)>

   :
   # m_2 = PHI 
   # _15 = PHI <_5(5), _10(2)>
   # i_16 = PHI 
   # ivtmp_13 = PHI 
   _7 = m_2 * _15;
   b[i_16] = _7;
   i_9 = i_16 + 1;
   ivtmp_3 = ivtmp_13 - 1;
   if (ivtmp_3 != 0)
 goto ;
   else
 goto ;

which previously was not if-converted. With this patch:

   :
   _10 = a[0];
   goto ;

   :

   :
   # m_2 = PHI 
   # _15 = PHI <_5(3), _10(2)>
   # i_16 = PHI 
   # ivtmp_13 = PHI 
   _7 = m_2 * _15;
   b[i_16] = _7;
   i_9 = i_16 + 1;
   ivtmp_3 = ivtmp_13 - 1;
   _5 = a[i_9];
   _6 = _5 & i_9;
   m_14 = _6 != 0 ? 5 : 4;
   if (ivtmp_3 != 0)
 goto ;
   else
 goto ;

   :
   return;

(Unfortunately the vectorizer still doesn't handle this loop either, but
that's another issue/patch...)

Bootstrapped + check-gcc on x86_64-unknown-linux-gnu and
aarch64-none-linux-gnu.
Cross-tested check-gcc on aarch64-none-elf.
I'm investigating impact on benchmarks - on AArch64 Spec2k6, this
touches a number of object files, leading to an overall slight decrease
in the number of instructions, but no change that looks significant
(specifically, no more or less vectorization).

Is this OK for trunk?

ENOPATCH
jeff

[RFC]: Remove Mem/address type assumption in combiner

[Kumar, Venkataramanan]

Hi Jeff/Segher, 

Restarting the discussion on the GCC combiner assumption about Memory/address 
type.
Ref: https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01298.html
https://gcc.gnu.org/ml/gcc/2015-04/msg00028.html

While working on the test case in PR 63949,  I came across the below code in 
combine.c: make_compound_operation.

--snip---
  /* Select the code to be used in recursive calls.  Once we are inside an
 address, we stay there.  If we have a comparison, set to COMPARE,
 but once inside, go back to our default of SET.  */

  next_code = (code == MEM ? MEM
   : ((code == PLUS || code == MINUS)
  && SCALAR_INT_MODE_P (mode)) ? MEM
   : ((code == COMPARE || COMPARISON_P (x))
  && XEXP (x, 1) == const0_rtx) ? COMPARE
   : in_code == COMPARE ? SET : in_code);
---snip--

When we see an  RTX code with PLUS or MINUS then it is treated as  MEM/address 
type (we are inside address RTX). 
Is there any significance on that assumption?  I removed this assumption and 
the test case in the PR 63949 passed.

diff --git a/gcc/combine.c b/gcc/combine.c
index 5c763b4..945abdb 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -7703,8 +7703,6 @@ make_compound_operation (rtx x, enum rtx_code in_code)
  but once inside, go back to our default of SET.  */

   next_code = (code == MEM ? MEM
-  : ((code == PLUS || code == MINUS)
- && SCALAR_INT_MODE_P (mode)) ? MEM
   : ((code == COMPARE || COMPARISON_P (x))
  && XEXP (x, 1) == const0_rtx) ? COMPARE
   : in_code == COMPARE ? SET : in_code);


On X86_64, it passes bootstrap and regression tests.
But on Aarch64 the test in PR passed, but I got a few test case failures.

Tests that now fail, but worked before:

gcc.target/aarch64/adds1.c scan-assembler adds\tw[0-9]+, w[0-9]+, w[0-9]+, lsl 3
gcc.target/aarch64/adds1.c scan-assembler adds\tx[0-9]+, x[0-9]+, x[0-9]+, lsl 3
gcc.target/aarch64/adds3.c scan-assembler-times adds\tx[0-9]+, x[0-9]+, x[0-9]+,
 sxtw 2
gcc.target/aarch64/extend.c scan-assembler add\tw[0-9]+,.*uxth #?1
gcc.target/aarch64/extend.c scan-assembler add\tx[0-9]+,.*uxtw #?3
gcc.target/aarch64/extend.c scan-assembler sub\tw[0-9]+,.*uxth #?1
gcc.target/aarch64/extend.c scan-assembler sub\tx[0-9]+,.*uxth #?1
gcc.target/aarch64/extend.c scan-assembler sub\tx[0-9]+,.*uxtw #?3
gcc.target/aarch64/subs1.c scan-assembler subs\tw[0-9]+, w[0-9]+, w[0-9]+, lsl 3
gcc.target/aarch64/subs1.c scan-assembler subs\tx[0-9]+, x[0-9]+, x[0-9]+, lsl 3
gcc.target/aarch64/subs3.c scan-assembler-times subs\tx[0-9]+, x[0-9]+, x[0-9]+,
 sxtw 2

Based on  in_code , If it is of "MEM"  type combiner converts shifts to 
multiply operations.

--snip--
  switch (code)
{
case ASHIFT:
  /* Convert shifts by constants into multiplications if inside
 an address.  */
  if (in_code == MEM && CONST_INT_P (XEXP (x, 1))
  && INTVAL (XEXP (x, 1)) < HOST_BITS_PER_WIDE_INT
  && INTVAL (XEXP (x, 1)) >= 0
  && SCALAR_INT_MODE_P (mode))
 ---snip

There are few patterns based on multiplication operations in Aarch64 backend 
which are used to match with the pattern combiner generated.
Now those patterns have to be fixed to use SHIFTS.  Also need to see any impact 
on other targets.

But  before that  I wanted to check if the assumption in combiner,  can simply 
be removed ?

Regards,
Venkat.

PS:  I am starting a new thread since I no more have access to Linaro ID from 
where I sent the earlier mail.

Re: Fix OpenMP's target update directive in templated code

[Thomas Schwinge]

Hi Jakub!

On Wed, 29 Apr 2015 10:53:32 +0200, Jakub Jelinek  wrote:
> On Tue, Apr 28, 2015 at 08:45:50PM +0200, Thomas Schwinge wrote:
> > I guess nobody so far ;-) has been using OpenMP's target update directive
> > in templated code -- OK to commit the following, and to which branches
> > (4.9, 5, trunk)?
> 
> Seems I've missed testcases for target {,update,data} in templates indeed,
> generally for C++ I'm trying to add testcases for templates, both when
> relevant types are type dependent and whey aren't.
> 
> > gcc/cp/
> > * pt.c (tsubst_expr) : Use
> > OMP_TARGET_UPDATE_CLAUSES instead of OMP_CLAUSES.
> > gcc/testsuite/
> > * g++.dg/gomp/tpl-target-update.C: New file.
> 
> This is ok for trunk, 5.2 and 4.9.3, thanks for fixing that.

Committed in r222564, r222565, r222566, respectively.


Grüße,
 Thomas


pgp95WUjpPpsS.pgp
Description: PGP signature

OMP_CLAUSES with clauses in operand 0 (was: Fix OpenMP's target update directive in templated code)

[Thomas Schwinge]

Hi Jakub!

On Wed, 29 Apr 2015 10:53:32 +0200, Jakub Jelinek  wrote:
> On Tue, Apr 28, 2015 at 08:45:50PM +0200, Thomas Schwinge wrote:
> > That said, what is the preferred approach to add support for
> > OACC_ENTER_DATA, OACC_EXIT_DATA, OACC_UPDATE?  I'm not sure hard-coding
> > TREE_OPERAND (t, 0) in gcc/cp/pt.c:tsubst_expr is the way to go, and also
> > duplicating the OMP_TARGET_UPDATE code for each of the three OACC_*
> > doesn't sound appealing -- especially given that we just "switch"ed on
> > the respective tree code, so the O*_CHECK of the respective O*_CLAUSES
> > macro is completely redundant.  Is it OK to extend gcc/tree.h:OMP_CLAUSES
> > so that it can also be used for tree codes that keep clauses in operand
> > 0, and then use that here (and also in
> > gcc/gimplify.c:gimplify_omp_target_update, for example)?
> 
> How could it work when it is operand 1 on some and operand 0 in others.

Something like (untested):

 #define OMP_CLAUSES(NODE) \
-  TREE_OPERAND (TREE_RANGE_CHECK (NODE, OACC_PARALLEL, OMP_SINGLE), 1) \
+  (tree_code (NODE) <= OMP_SINGLE) \
+  ? TREE_OPERAND (TREE_RANGE_CHECK (NODE, OACC_PARALLEL, OMP_SINGLE), 1) \
+  : TREE_OPERAND (TREE_RANGE_CHECK (NODE, OACC_CACHE, OMP_TARGET_UPDATE), 
0)

Rationale: I'm not expecting another variant to be added later on
(clauses are either in operand 0 or 1).  Encoding explicit tree code
(ordering) assuptions is already done with the usage of TREE_RANGE_CHECK
macros, so the additional tree code check doesn't make this much worse.
It has the benefit of offering the same known OMP_CLAUSES interface.

Yet, if that's a non-starter, I'll pursue this one:

> IMHO, if you want to reuse the same code for OMP_TARGET_UPDATE,
> various OACC_* standalone directives (and
> OMP_TARGET_ENTER_DATA/OMP_TARGET_EXIT_DATA in OpenMP 4.1), then
> you should make sure they are consecutive in target.def

(tree.def; we've already made sure they're grouped consecutively.)

> and
> define OMP_STANDALONE_CLAUSES or OMP_TARGET_STANDALONE_CLAUSES as
> a range check between OMP_TARGET_UPDATE and the last OpenACC directive
> without body, just clauses.


Grüße,
 Thomas


pgpStG6NDIEr5.pgp
Description: PGP signature

Re: [PATCH][PR65818][bootstrap,hppa] Return side-effect free result in gimplify_va_arg_internal

[Richard Biener]

On Tue, Apr 28, 2015 at 10:29 PM, Tom de Vries  wrote:
> On 28-04-15 12:34, Richard Biener wrote:
>>
>> On Mon, Apr 27, 2015 at 5:04 PM, Tom de Vries 
>> wrote:
>>>
>>> On 27-04-15 15:40, Richard Biener wrote:


 On Mon, Apr 27, 2015 at 3:06 PM, Tom de Vries 
 wrote:
>
>
> On 27-04-15 10:17, Richard Biener wrote:
>>>
>>>
>>>
>>> This patch fixes that by gimplifying the address expression of the
>>> mem-ref


 returned by the target hook (borrowing code from gimplify_expr, case
 MEM_REF).

 Bootstrapped and reg-tested on x86_64.

 Bootstrapped and reg-tested on hppa2.0w-hp-hpux11.11.

 OK for trunk?
>>
>>
>>
>> Hmm, that assert looks suspicious...
>>
>> Can't you simply always do
>>
>>  gimplify_expr (expr, pre_p, post_p, is_gimple_lvalue, fb_lvalue);
>
>
>
>
> It's a bit counter-intuitive for me, using is_gimple_lvalue for
> something
> (the result of va_arg) we use as rvalue.



 Yeah, choosing that was done because you could assert it's a MEM_REF
 and tree-stdarg eventually builds a WITH_SIZE_EXPR around it.

 It would possibly be easier to simply "inline" gimplify_va_arg_internal
 at its use and only gimplify the assignment.  Though in that case the
 original code probably worked - just in the lhs == NULL case it didn't,
 which hints at a better place for the fix - in expand_ifn_va_arg_1 do

if (lhs != NULL_TREE)
  {
 ...
  }
else
  gimplify_expr (&expr, &pre, &post, is_gimple_val, fb_either);

 So ... if you can re-try that one it's pre-approved.

>>>
>>> Using that proposed patch, we run into the following problem.
>>>
>>> Consider this testcase with ignored-result-va_arg:
>>> ...
>>> #include 
>>>
>>> void
>>> f2 (int i, ...)
>>> {
>>>va_list ap;
>>>va_start (ap, i);
>>>va_arg (ap, long);
>>>va_end (ap);
>>> }
>>> ...
>>>
>>> after gimplify_va_arg_internal we have:
>>> ...
>>> (gdb) call debug_generic_expr (expr)
>>> *(long int * {ref-all}) addr.2
>>> ...
>>>
>>> In a bit more detail:
>>> ...
>>> (gdb) call debug_tree (expr)
>>>   >>  type >>  size 
>>>  unit size 
>>>  align 64 symtab 0 alias set -1 canonical type 0x764a77e0
>>> precision 64 min  max
>>> 
>>>  pointer_to_this >
>>>
>>>  arg 0 >>  type >> 0x764a77e0
>>> long int>
>>>  public static unsigned DI size >> 64>
>>> unit size 
>>>  align 64 symtab 0 alias set -1 canonical type
>>> 0x765e0498>
>>>
>>>  arg 0 >> 0x764c2150>
>>>  used unsigned ignored DI file stdarg-1.c line 4 col 1 size
>>>  unit size 
>>>  align 64 context >>
>>>  arg 1 
>>> constant 0>>
>>> ...
>>>
>>> During 'gimplify_expr (&expr, &pre, &post, is_gimple_val, fb_either)' we
>>> ICE
>>> here:
>>> ...
>>> 8886  gcc_assert ((*gimple_test_f) (*expr_p));
>>> ...
>>>
>>> At this point expr is:
>>> ...
>>> (gdb) call debug_generic_expr (*expr_p)
>>> *addr.2
>>> ...
>>>
>>> In more detail:
>>> ...
>>> (gdb) call debug_tree (*expr_p)
>>>   >>  type >>  align 8 symtab 0 alias set -1 canonical type 0x764c2000
>>>  pointer_to_this >
>>>
>>>  arg 0 >>  type >> void>
>>>  sizes-gimplified public unsigned DI
>>>  size 
>>>  unit size 
>>>  align 64 symtab 0 alias set -1 canonical type 0x764c2150
>>>  pointer_to_this >
>>>  used unsigned ignored DI file stdarg-1.c line 4 col 1 size
>>>  unit size 
>>>  align 64 context >
>>>  arg 1 
>>> constant 0>>
>>> ...
>>>
>>> The memref is now VOID type. And that's not a gimple_val:
>>> ...
>>> (gdb) p is_gimple_val (*expr_p)
>>> $1 = false
>>> ...
>>
>>
>> On which target?  I can't seem to reproduce on x86_64 or i?86.  I also
>> can't see how this
>> could happen.
>>
>
> Reproduced using attached patch on top of r222537, for target x86_64, with
> and without -m32.

Ok, I see now.  The gimplifier seems to be confused with fb_lvalue.
all is_gimple_addressable ()s are already is_gimple_lvalue so

Index: gcc/gimplify.c
===
--- gcc/gimplify.c  (revision 222537)
+++ gcc/gimplify.c  (working copy)
@@ -8844,15 +8844,9 @@ gimplify_expr (tree *expr_p, gimple_seq
  rvalue.  */
   if ((fallback & fb_lvalue)
   && gimple_seq_empty_p (internal_post)
-  && is_gimple_addressable (*expr_p))
-{
-  /* An lvalue will do.  Take the address of the expression, store it
-in a temporary, and replace the expression with an INDIRECT_REF of
-that temporary.  */
-  tmp = build_fold_addr_expr_loc (input_location, *expr_p);
-  gimplify_expr (&tmp, pre_p, post_p, is_gimple_reg, fb_rvalue);
-  *expr_p = build_simple_me

Re: OMP_CLAUSES with clauses in operand 0 (was: Fix OpenMP's target update directive in templated code)

[Jakub Jelinek]

On Wed, Apr 29, 2015 at 11:28:55AM +0200, Thomas Schwinge wrote:
> Yet, if that's a non-starter, I'll pursue this one:

Yeah, it is a non-starter, it has unnecessary runtime overhead everywhere
where it is used.

Jakub

[patch] Perform anonymous constant propagation during inlining

[Eric Botcazou]

Historically the pragma Inline_Always of GNAT had been implemented in the FE 
because the RTL inliner and then the Tree inliner weren't invoked at -O0 or 
powerful enough to inline some constructs.  But this approach had drawbacks, 
especially wrt debug info.  These restrictions were gradually lifted and now 
the pragma is entirely piggybacked on the Tree inliner.

This went mostly OK, except for a few cases where intrisinc operations that 
used to be reasonably handled at -O0 now generate awful code, the typical 
example being a modulus or division instrinsic by a power-of-2 generating a 
fully-fledged modulus or division instruction instead of a simple shift.

Therefore the attached patch implements anonymous constant propagation in the 
inliner to fix the code quality regression.

Tested on x86_64-suse-linux, OK for the mainline?


2015-04-29  Eric Botcazou  

* tree-inline.c (remap_gimple_op_r): Do anonymous constant propagation.
(copy_bb): Fold conversions of constants immediately.


2015-04-29  Eric Botcazou  

* gnat.dg/inline12.adb: New test.


-- 
Eric Botcazou-- { dg-do compile }

with System.Storage_Elements; use System, System.Storage_Elements;

function Inline12 return Natural is
   A : Address := Inline12'Code_Address;
begin
   while A mod Address'Alignment /= 0 loop
  A := A + 1;
   end loop;
   return Natural (A - Inline12'Code_Address);
end;

-- { dg-final { scan-assembler-not "mod|div" } }Index: tree-inline.c
===
--- tree-inline.c	(revision 222439)
+++ tree-inline.c	(working copy)
@@ -898,7 +898,19 @@ remap_gimple_op_r (tree *tp, int *walk_s
 
   if (TREE_CODE (*tp) == SSA_NAME)
 {
-  *tp = remap_ssa_name (*tp, id);
+  tree t = remap_ssa_name (*tp, id);
+  /* Perform anonymous constant propagation, this makes it possible to
+ generate reasonable code even at -O0 for operators implemented as
+ inline functions.  */
+  if (TREE_CODE (t) == SSA_NAME
+	  && SSA_NAME_DEF_STMT (t)
+	  && (!SSA_NAME_VAR (t) || DECL_IGNORED_P (SSA_NAME_VAR (t)))
+	  && gimple_assign_copy_p (SSA_NAME_DEF_STMT (t))
+	  && is_gimple_min_invariant
+	 (gimple_assign_rhs1 (SSA_NAME_DEF_STMT (t
+	*tp = gimple_assign_rhs1 (SSA_NAME_DEF_STMT (t));
+  else
+	*tp = t;
   *walk_subtrees = 0;
   return NULL;
 }
@@ -1965,7 +1977,7 @@ copy_bb (copy_body_data *id, basic_block
 
 	  /* Statements produced by inlining can be unfolded, especially
 	 when we constant propagated some operands.  We can't fold
-	 them right now for two reasons:
+	 them right now in the general case for two reasons:
 	 1) folding require SSA_NAME_DEF_STMTs to be correct
 	 2) we can't change function calls to builtins.
 	 So we just mark statement for later folding.  We mark
@@ -1974,7 +1986,10 @@ copy_bb (copy_body_data *id, basic_block
 	 foldable indirectly are updated.  If this turns out to be
 	 expensive, copy_body can be told to watch for nontrivial
 	 changes.  */
-	  if (id->statements_to_fold)
+	  if (gimple_assign_cast_p (stmt)
+	  && is_gimple_min_invariant (gimple_assign_rhs1 (stmt)))
+	fold_stmt (©_gsi);
+	  else if (id->statements_to_fold)
 	id->statements_to_fold->add (stmt);
 
 	  /* We're duplicating a CALL_EXPR.  Find any corresponding

Re: [PATCH, ARM] Fix for pr65924

[Kyrill Tkachov]

Hi Yvan,

On 29/04/15 09:57, Yvan Roux wrote:

Hi,

here is the patch for PR65924, only tested on the original testcase so far.


Can you please double check that the problem doesn't appear
in the other patterns you touched with your cleanup patch?
i.e. that you don't do match_operand on an out-of-bounds operand number?

Thanks,
Kyrill



Thanks
Yvan

gcc/
2015-04-29  Yvan Roux  

 PR target/65924
 * config/arm/thumb2.md (*thumb2_addsi3_compare0_scratch): Fix operand
 number in type attribute expression.

gcc/testsuite/
2015-04-29  Yvan Roux  

 PR target/65924
 gcc.target/arm/pr65924.c: New test.

[rs6000] Fix compare debug failure on AIX

[Eric Botcazou]

You can easily get -fcompare-debug failures on AIX with small functions, in 
fact you get the failure for the empty function:

void foo (void) {}

eric@polaris:~/build/gcc/powerpc-ibm-aix7.1> gcc/xgcc -Bgcc -S t.c -O -
fcompare-debug
xgcc: error: t.c: -fcompare-debug failure (length)

Fixed thusly, tested on powerpc-ibm-aix7.1, OK for the mainline?


2015-04-29  Eric Botcazou  

* config/rs6000/rs6000.c (rs6000_stack_info): For XCOFF, replace test
on debug info with test on optimization to decide stack pushing.


2015-04-29  Eric Botcazou  

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


-- 
Eric BotcazouIndex: config/rs6000/rs6000.c
===
--- config/rs6000/rs6000.c	(revision 222439)
+++ config/rs6000/rs6000.c	(working copy)
@@ -21932,8 +21932,8 @@ rs6000_stack_info (void)
   /* Determine if we need to allocate any stack frame:
 
  For AIX we need to push the stack if a frame pointer is needed
- (because the stack might be dynamically adjusted), if we are
- debugging, if we make calls, or if the sum of fp_save, gp_save,
+ (because the stack might be dynamically adjusted), if we are not
+ optimizing, if we make calls, or if the sum of fp_save, gp_save,
  and local variables are more than the space needed to save all
  non-volatile registers: 32-bit: 18*8 + 19*4 = 220 or 64-bit: 18*8
  + 18*8 = 288 (GPR13 reserved).
@@ -21950,7 +21950,7 @@ rs6000_stack_info (void)
   else if (frame_pointer_needed)
 info_ptr->push_p = 1;
 
-  else if (TARGET_XCOFF && write_symbols != NO_DEBUG)
+  else if (TARGET_XCOFF && !optimize)
 info_ptr->push_p = 1;
 
   else/* { dg-options "-O -fcompare-debug" } */

void foo (void) {}

Re: [rs6000] Fix compare debug failure on AIX

[pinskia]

> On Apr 29, 2015, at 3:22 AM, Eric Botcazou  wrote:
> 
> You can easily get -fcompare-debug failures on AIX with small functions, in 
> fact you get the failure for the empty function:
> 
> void foo (void) {}
> 
> eric@polaris:~/build/gcc/powerpc-ibm-aix7.1> gcc/xgcc -Bgcc -S t.c -O -
> fcompare-debug
> xgcc: error: t.c: -fcompare-debug failure (length)
> 
> Fixed thusly, tested on powerpc-ibm-aix7.1, OK for the mainline?
> 
> 
> 2015-04-29  Eric Botcazou  
> 
>* config/rs6000/rs6000.c (rs6000_stack_info): For XCOFF, replace test
>on debug info with test on optimization to decide stack pushing.

We might want to check if doing -Og and not just -O0. 

Thanks,
Andrew

> 
> 
> 2015-04-29  Eric Botcazou  
> 
>* gcc.dg/empty3.c: New test.
> 
> 
> -- 
> Eric Botcazou
> 
> 

RE: [RFC: Patch, PR 60158] gcc/varasm.c : Pass actual alignment value to output_constant_pool_2

[rohitarul...@freescale.com]

> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Wednesday, April 29, 2015 4:01 AM
> To: Dharmakan Rohit-B30502; gcc-patches@gcc.gnu.org;
> rguent...@suse.de; Jakub Jelinek
> Cc: Alan Modra; David Edelsohn; Wienskoski Edmar-RA8797
> Subject: Re: [RFC: Patch, PR 60158] gcc/varasm.c : Pass actual alignment value
> to output_constant_pool_2
> 
> On 04/28/2015 12:38 PM, rohitarul...@freescale.com wrote:
> >
> >
> >> -Original Message-
> >> From: Jeff Law [mailto:l...@redhat.com]
> >> Sent: Tuesday, April 28, 2015 11:48 PM
> >> To: Dharmakan Rohit-B30502; gcc-patches@gcc.gnu.org;
> >> rguent...@suse.de; Jakub Jelinek
> >> Cc: Alan Modra; David Edelsohn; Wienskoski Edmar-RA8797
> >> Subject: Re: [RFC: Patch, PR 60158] gcc/varasm.c : Pass actual
> >> alignment value to output_constant_pool_2
> >>
> >> On 04/28/2015 03:44 AM, rohitarul...@freescale.com wrote:
> >>> Ping.
> >>>
> >>> -Original Message-
> >>> From: Dharmakan Rohit-B30502
> >>> Sent: Friday, March 27, 2015 7:57 PM
> >>> To: gcc-patches@gcc.gnu.org; rguent...@suse.de; Jakub Jelinek
> >>> Cc: Alan Modra; David Edelsohn; Wienskoski Edmar-RA8797; Dharmakan
> >>> Rohit-B30502
> >>> Subject: RE: [RFC: Patch, PR 60158] gcc/varasm.c : Pass actual
> >>> alignment value to output_constant_pool_2
> >>>
> >>> Hi,
> >>>
> >>> I would like to resubmit these patches for comments. The previous
> detailed discussion is available in the below mentioned link.
> >>> https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01679.html
> >>> https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00489.html
> >>>
> >>> The issue is still reproducible on GCC v4.8 branch.
> >>>
> >>> I have tested both the attached patches with e500v2 tool chain on GCC
> v4.8 branch [rev 221667] and GCC trunk [rev 221310] with no regressions.
> >>>
> >>> Patch1 [gcc.fix_pr60158_fixup_table_fsf_1]: Pass actual alignment value
> to output_constant_pool_2.
> >>> Patch2 [gcc.fix_pr60158_fixup_table_fsf_2]: Use the alignment data
> available in the first argument (constant_descriptor_rtx) of
> output_constant_pool_1.
> >>>   (Note: this generates ".align" directive twice).
> >> Are you asking for both patches to be applied or just one?
> > Just one, needed your comments on which would be better.
> Just wanted to be sure.  Particularly since I could make a case for either or
> both.
> 
> I think this is the better patch:
> 
> 
> https://gcc.gnu.org/ml/gcc-patches/2014-
> 05/msg00489/gcc.fix_pr60158_fixup_table-fsf
> 
> The change I would request would be to add some comments.  So before
> this code:
> 
> output_constant_pool_1 (desc, 1);
> 
> A comment about why passing "1" for the alignment is OK here (because all
> the data is already aligned, so no need to realign it).
> 
> And for this change:
> 
> -  output_constant_pool_2 (desc->mode, x, align);
> +  output_constant_pool_2 (desc->mode, x, desc->align);
> 
> I would suggest a comment why we're using desc->align rather than align.
>   You'll probably want/need to refer back to the call where "1" is passed for
> the alignment in that comment.
> 
> 
> With those two comments added, and a fresh bootstrap & regression test
> on the trunk, it'll be good to go.
> 

Jeff, I have made the changes as per your comments and attached the patch.
If the patch is OK, I will proceed with the regression tests.

Regards,
Rohit



gcc.fix_pr60158_fixup_table_trunk_fsf
Description: gcc.fix_pr60158_fixup_table_trunk_fsf

New French PO file for 'gcc' (version 5.1.0)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

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

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

All other PO files for your package are available in:

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

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

Re: [PATCH, ARM] Fix for pr65924

[Yvan Roux]

Hi Kyrill,

On 29 April 2015 at 12:06, Kyrill Tkachov  wrote:
> Hi Yvan,
>
> On 29/04/15 09:57, Yvan Roux wrote:
>>
>> Hi,
>>
>> here is the patch for PR65924, only tested on the original testcase so
>> far.
>
>
> Can you please double check that the problem doesn't appear
> in the other patterns you touched with your cleanup patch?
> i.e. that you don't do match_operand on an out-of-bounds operand number?

Sure, I just re-check all the patterns and there is no other issue.

Cheers,
Yvan

> Thanks,
> Kyrill
>
>
>>
>> Thanks
>> Yvan
>>
>> gcc/
>> 2015-04-29  Yvan Roux  
>>
>>  PR target/65924
>>  * config/arm/thumb2.md (*thumb2_addsi3_compare0_scratch): Fix operand
>>  number in type attribute expression.
>>
>> gcc/testsuite/
>> 2015-04-29  Yvan Roux  
>>
>>  PR target/65924
>>  gcc.target/arm/pr65924.c: New test.
>
>

Re: [PATCH] gimple-walk.c #include TLC

[Bernhard Reutner-Fischer]

On 29 April 2015 at 11:00, Richard Biener  wrote:
> On Wed, Apr 29, 2015 at 10:01 AM, Bernhard Reutner-Fischer
>  wrote:
>> Hi there,
>>
>> I noticed that gimple-walk.c has a creative list of #includes.
>> Furthermore, in walk_gimple_asm parse_{in,out}put_constraint was called
>> even if neither allows_mem, allows_reg nor is_inout were used -- i.e. if
>> wi is NULL -- and the return value of the constraint parsing was not
>> taken into account which looks wrong or at least odd. Note that several
>> other spots in the tree do ignore the parse_{in,out}put_constraint return
>> values and should be adjusted too AFAIU. Otherwise we might attempt
>> (and use!) to extract information from otherwise illegal constraints,
>> it seems?
>>
>> Bootstrapped and regtested on x86_64-unknown-linux with no regressions.
>> Ok for trunk?
>
> Ok.

r222569.
Thanks!

Re: [PATCH, ARM] Fix for pr65924

[Kyrill Tkachov]

On 29/04/15 11:43, Yvan Roux wrote:

Hi Kyrill,

On 29 April 2015 at 12:06, Kyrill Tkachov  wrote:

Hi Yvan,

On 29/04/15 09:57, Yvan Roux wrote:

Hi,

here is the patch for PR65924, only tested on the original testcase so
far.


Can you please double check that the problem doesn't appear
in the other patterns you touched with your cleanup patch?
i.e. that you don't do match_operand on an out-of-bounds operand number?

Sure, I just re-check all the patterns and there is no other issue.


Thanks,
Ok for trunk then as it fixes a build failure.

Kyrill



Cheers,
Yvan


Thanks,
Kyrill



Thanks
Yvan

gcc/
2015-04-29  Yvan Roux  

  PR target/65924
  * config/arm/thumb2.md (*thumb2_addsi3_compare0_scratch): Fix operand
  number in type attribute expression.

gcc/testsuite/
2015-04-29  Yvan Roux  

  PR target/65924
  gcc.target/arm/pr65924.c: New test.

Re: [PATCH][AARCH64]Add ACLE 2.0 predefined macros: __ARM_ALIGN_MAX_PWR and __ARM_ALIGN_MAX_STACK_PWR

[Marcus Shawcroft]

On 29 April 2015 at 01:24, Andrew Pinski  wrote:
> On Tue, Dec 16, 2014 at 2:19 AM, Renlin Li  wrote:
>> Hi all,
>>
>> This is a simple patch to add another two ACLE 2.0 predefined macros into
>> aarch64 backend.
>> They are __ARM_ALIGN_MAX_PWR and __ARM_ALIGN_MAX_STACK_PWR. Currently, those
>> two values are hard-wired to 16.
>>
>> The following clauses from ACLE 2.0 documentation indicate the meaning of
>> those two macros:
>>
>> The macro __ARM_ALIGN_MAX_STACK_PWR indicates (as the exponent of a power of
>> 2) the maximum available stack alignment.
>> The macro __ARM_ALIGN_MAX_PWR indicates (as the exponent of a power of 2)
>> the maximum available alignment of static data.
>>
>> aarch64-none-elf target is tested on on the model. No new regression.
>>
>> Is it Okay for trunk?
>
> Have you tested these alignments?  That is have we tested 65536
> alignment for both stack and static data?
> I suspect the stack alignment that is support is not 64k but much
> smaller.  And the supported static data alignment is much larger,
> maybe 20 or more.

Looks to me  __ARM_ALIGN_MAX_STACK_PWR can be lifted to 2^16 without
issue.  GCC won't gripe about the static data alignment until 2^29.
Aside from the latter being rather conservative I think we should add
a test case to the testsuite for each. RenLin can you prep a testcase?

/Marcus

Re: OMP_CLAUSES with clauses in operand 0

[Thomas Schwinge]

Hi!

On Wed, 29 Apr 2015 11:32:31 +0200, Jakub Jelinek  wrote:
> Yeah, it is a non-starter, it has unnecessary runtime overhead everywhere
> where it is used.

Huh.  OMP_CLAUSES is currently used in a dozen places in
cp/cp-gimplify.c, cp/pt.c, and gimplify.c.  I've been expecting my
changed code to be well-optimizable, for the compiler already knows
TREE_CODE(NODE) in a lot of these places.  Doing a quick before (1)/after
(2) comparison test with -g -O2 on x86_64 GNU/Linux using GCC 4.8.3, the
object file sizes are as follows:

   textdata bss dec hex filename
  37027   0  16   3704390b3 1/build-gcc/gcc/cp/cp-gimplify.o
  36307   0  16   363238de3 2/build-gcc/gcc/cp/cp-gimplify.o
   textdata bss dec hex filename
 458742   0 136  458878   7007e 1/build-gcc/gcc/cp/pt.o
 458630   0 136  458766   7000e 2/build-gcc/gcc/cp/pt.o
   textdata bss dec hex filename
 166056   0  48  166104   288d8 1/build-gcc/gcc/gimplify.o
 166200   0  48  166248   28968 2/build-gcc/gcc/gimplify.o

..., so actually smaller for the first two files.  Admittedly, there is a
144 bytes (0.0867 %) size increase in gimplify.o, and I have not measured
the actual runtime overhead (which I'm totally expecting to be "in the
noise", but...), so I'm assuming that my proposal to keep the interface
simple does not pay for the presumed runtime overhead, so I guess I'm
posting this patch just for the archives...

--- gcc/tree.h
+++ gcc/tree.h
@@ -1200,7 +1200,9 @@ extern void protected_set_expr_location (tree, 
location_t);
 #define OMP_BODY(NODE) \
   TREE_OPERAND (TREE_RANGE_CHECK (NODE, OACC_PARALLEL, OMP_CRITICAL), 0)
 #define OMP_CLAUSES(NODE) \
-  TREE_OPERAND (TREE_RANGE_CHECK (NODE, OACC_PARALLEL, OMP_SINGLE), 1)
+  ((TREE_CODE (NODE) <= OMP_SINGLE) \
+   ? TREE_OPERAND (TREE_RANGE_CHECK (NODE, OACC_PARALLEL, OMP_SINGLE), 1) \
+   : TREE_OPERAND (TREE_RANGE_CHECK (NODE, OACC_CACHE, OMP_TARGET_UPDATE), 0))
 
 #define OACC_PARALLEL_BODY(NODE) \
   TREE_OPERAND (OACC_PARALLEL_CHECK (NODE), 0)

If that's not been obvious, I favor code readability (one generic
OMP_CLAUSES interface instead of having both OMP_CLAUSES and
OMP_CLAUSES_STANDALONE) over a tiny code size regression, but you seem to
think differently, set a different policy for code changes, which I'll
have to yield to.


Grüße,
 Thomas


pgpbO21Daph6t.pgp
Description: PGP signature

Re: Use wi:: in canon_condition

[Richard Sandiford]

Jeff Law  writes:
> On 04/28/2015 07:49 AM, Richard Sandiford wrote:
>> Fix a simple case where we can generalise the CONST_INT handling to all
>> integer constants (CONST_DOUBLE or CONST_WIDE_INT).
>>
>> Tested on x86_64-linux-gnu.  OK to install?
>>
>> Thanks,
>> Richard
>>
>>
>> gcc/
>>  * loop-iv.c (canon_condition): Generalize to all types of integer
>>  constant.
> OK.

Thanks, applied.

> If you have some test/code where this generalization helps, then it'd be 
> greatly appreciated if you could add it as a test to the test suite.

This was just by inspection, so unfortunately I don't have any testcases.
Just trying to gradually reduce the specialness of host integers.

Richard

[gomp4.1] Initial support for some OpenMP 4.1 construct parsing

[Jakub Jelinek]

Hi!

Here is what I've committed to gomp-4_1-branch, a new branch for OpenMP 4.1
support.  The intent is to develop OpenMP 4.1 support on the branch and
merge to trunk either when OpenMP 4.1 standard is released, or when
sufficiently close to the release, ideally before end of stage1.

I'll probably work on taskloop construct next.

2015-04-29  Jakub Jelinek  

gcc/
* gimple.h (enum gf_mask): Increment GF_OMP_TARGET_KIND_MASK
to 15 from 7.  Add GF_OMP_TARGET_KIND_ENTER_DATA and
GF_OMP_TARGET_KIND_EXIT_DATA, renumber GF_OMP_TARGET_KIND_OACC*.
* tree.h (OMP_ORDERED_CLAUSES, OMP_TARGET_ENTER_DATA_CLAUSES,
OMP_TARGET_EXIT_DATA_CLAUSES, OMP_CLAUSE_NUM_TASKS_EXPR,
OMP_CLAUSE_GRAINSIZE_EXPR, OMP_CLAUSE_PRIORITY_EXPR,
OMP_CLAUSE_ORDERED_EXPR): Define.
* tree.def (OMP_TASKLOOP, OMP_TARGET_ENTER_DATA,
OMP_TARGET_EXIT_DATA): New tree codes.
(OMP_ORDERED): Add second operand - OMP_ORDERED_CLAUSES.  Move
before OMP_SINGLE, so that OMP_CLAUSES can be used on it too.
* gimplify.c (gimplify_scan_omp_clauses): Handle
OMP_CLAUSE_{PRIORITY,GRAINSIZE,NUM_TASKS,NOGROUP,THREADS,SIMD,SIMDLEN}
clauses.
(gimplify_adjust_omp_clauses): Likewise.
(gimplify_omp_target_update): Handle OMP_TARGET_ENTER_DATA
and OMP_TARGET_EXIT_DATA.
(gimplify_expr): Likewise.
* tree.c (omp_clause_num_ops): Change OMP_CLAUSE_ORDERED operand
count to 1 from 0.  Add entries for
OMP_CLAUSE_{PRIORITY,GRAINSIZE,NUM_TASKS,NOGROUP,THREADS,SIMD}.
(omp_clause_code_name): Add names for
OMP_CLAUSE_{PRIORITY,GRAINSIZE,NUM_TASKS,NOGROUP,THREADS,SIMD}
clauses.
(walk_tree_1): Handle
OMP_CLAUSE_{PRIORITY,GRAINSIZE,NUM_TASKS,NOGROUP,THREADS,SIMD}
clauses.  Handle OMP_CLAUSE_ORDERED as other 1 operand clauses.
* tree-nested.c (convert_nonlocal_omp_clauses): Handle
OMP_CLAUSE_{PRIORITY,GRAINSIZE,NUM_TASKS,NOGROUP,THREADS,SIMD,SIMDLEN}
clauses.
(convert_local_omp_clauses): Likewise.
* gimple-pretty-print.c (dump_gimple_omp_target): Handle
GF_OMP_TARGET_KIND_ENTER_DATA and GF_OMP_TARGET_KIND_EXIT_DATA.
* tree-core.h (enum omp_clause_code): Add
OMP_CLAUSE_{PRIORITY,GRAINSIZE,NUM_TASKS,NOGROUP,THREADS,SIMD}.
(enum omp_clause_depend_kind): Add OMP_CLAUSE_DEPEND_{SOURCE,SINK}.
* omp-low.c (scan_sharing_clauses): Handle
OMP_CLAUSE_{PRIORITY,GRAINSIZE,NUM_TASKS,NOGROUP,THREADS,SIMD,SIMDLEN}
clauses.
(check_omp_nesting_restrictions): Handle
GF_OMP_TARGET_KIND_ENTER_DATA and GF_OMP_TARGET_KIND_EXIT_DATA.
Formatting fixes.
(expand_omp_target): Handle GF_OMP_TARGET_KIND_ENTER_DATA and
GF_OMP_TARGET_KIND_EXIT_DATA.
(build_omp_regions_1, make_gimple_omp_edges): Likewise.
(lower_omp_target): Likewise.  Don't assert is_gimple_omp_oacc
for certain OpenMP 4.1 map kinds + modifiers.
* tree-pretty-print.c (dump_omp_clause): Handle
OMP_CLAUSE_ORDERED_EXPR on OMP_CLAUSE_ORDERED.  Handle
OMP_CLAUSE_DEPEND_SOURCE on OMP_CLAUSE_DEPEND.  Adjust printing
OpenMP 4.1 new map kinds and modifiers.  Handle
OMP_CLAUSE_{PRIORITY,GRAINSIZE,NUM_TASKS,NOGROUP,THREADS,SIMD}
clauses.
(dump_generic_node): Handle OMP_{TASKLOOP,TARGET_{ENTER,EXIT}_DATA}.
Dump OMP_ORDERED_CLAUSES for OMP_ORDERED.
gcc/c-family/
* c-omp.c (c_finish_omp_ordered): Add CLAUSES argument, adjust
for building 2 operand tree instead of single operand tree.
(c_omp_split_clauses): Add taskloop simd splitting support.
* c-pragma.h (enum pragma_kind): Add PRAGMA_OMP_TASKLOOP.
(enum pragma_omp_clause): Add
PRAGMA_OMP_CLAUSE_{PRIORITY,GRAINSIZE,NUM_TASKS,NOGROUP,THREADS,SIMD}.
* c-common.h (enum c_omp_clause_split): Add C_OMP_CLAUSE_SPLIT_TASKLOOP
as alias to C_OMP_CLAUSE_SPLIT_FOR.
(c_finish_omp_ordered): Adjust prototype for CLAUSES argument addition.
gcc/c/
* c-typeck.c (c_finish_omp_clauses): Allow NULL OMP_CLAUSE_DECL
for OMP_CLAUSE_DEPEND_SOURCE.  Diagnose simdlen > safelen.  Handle
OMP_CLAUSE_{PRIORITY,GRAINSIZE,NUM_TASKS,NOGROUP,THREADS,SIMD}
clauses.
* c-parser.c (c_parser_pragma): Handle PRAGMA_OMP_ORDERED.
(c_parser_omp_clause_name): Handle grainsize, nogroup, num_tasks,
priority, simd and threads clauses.
(c_parser_omp_clause_num_tasks, c_parser_omp_clause_grainsize,
c_parser_omp_clause_priority): New functions.
(c_parser_omp_clause_ordered): Handle parsing of optional argument.
(c_parser_omp_clause_nogroup, c_parser_omp_clause_orderedkind):
New functions.
(c_parser_omp_clause_depend): Handle parsing of depend(source)
and partially handle depend(sink:vec).
(c_parser_omp_clause_map): Parse optional always map type m

Re: C++ PATCH for c++/50800 (ICE with may_alias and templates)

[Markus Trippelsdorf]

On 2015.04.28 at 10:42 -0400, Jason Merrill wrote:
> On 04/23/2015 01:45 PM, H.J. Lu wrote:
> > On Thu, Apr 23, 2015 at 8:52 AM, Jason Merrill  wrote:
> >> We try to strip attributes that aren't reflected in mangling from template
> >> arguments, but were failing to do that in this case.  Fixed by making
> >> strip_typedefs strip such attributes as well.
> >>
> >> Tested x86_64-pc-linux-gnu, applying to trunk.
> >
> > This caused:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65865
> 
> This turned out to be because of a thinko in apply_identity_attributes; 
> we weren't actually applying the identity attributes.  Fixed thus.

I'm getting hundreds of new warnings when building LLVM, e.g.:

trippels@gcc2-power8 Sema % cat AttributeList.ii
template  struct A;
template  struct A<_Up *> { typedef _Up type; };
template  struct B { typedef typename A::type type; };
template  struct C;
template  struct C {
  typedef typename B::type SimpleType;
};
template  struct D { typedef int ret_type; };
template  struct F {
  typedef typename D::SimpleType>::ret_type ret_type;
};
template  typename F::ret_type cast(Y &);
class CompoundStmt;
class alignas(8) Stmt {
  Stmt *Children[];
  CompoundStmt *getBlock() const { cast(Children[0]); }
};

trippels@gcc2-power8 Sema % g++ -c -std=c++11 AttributeList.ii
AttributeList.ii: In instantiation of ‘struct F’:
AttributeList.ii:12:51:   required by substitution of ‘template 
typename F::ret_type cast(Y&) [with  = CompoundStmt; 
Y = Stmt* const]’
AttributeList.ii:16:66:   required from here
AttributeList.ii:10:62: warning: ignoring attributes applied to ‘Stmt’ after 
definition [-Wattributes]
   typedef typename D::SimpleType>::ret_type ret_type;
  ^
AttributeList.ii:10:62: warning: ignoring attributes on template argument 
‘C::SimpleType {aka Stmt}’

-- 
Markus

Re: OMP_CLAUSES with clauses in operand 0

[Jakub Jelinek]

On Wed, Apr 29, 2015 at 01:13:29PM +0200, Thomas Schwinge wrote:
> On Wed, 29 Apr 2015 11:32:31 +0200, Jakub Jelinek  wrote:
> > Yeah, it is a non-starter, it has unnecessary runtime overhead everywhere
> > where it is used.
> 
> Huh.  OMP_CLAUSES is currently used in a dozen places in
> cp/cp-gimplify.c, cp/pt.c, and gimplify.c.  I've been expecting my
> changed code to be well-optimizable, for the compiler already knows
> TREE_CODE(NODE) in a lot of these places.  Doing a quick before (1)/after
> (2) comparison test with -g -O2 on x86_64 GNU/Linux using GCC 4.8.3, the
> object file sizes are as follows:
> 
>textdata bss dec hex filename
>   37027   0  16   3704390b3 1/build-gcc/gcc/cp/cp-gimplify.o
>   36307   0  16   363238de3 2/build-gcc/gcc/cp/cp-gimplify.o
>textdata bss dec hex filename
>  458742   0 136  458878   7007e 1/build-gcc/gcc/cp/pt.o
>  458630   0 136  458766   7000e 2/build-gcc/gcc/cp/pt.o
>textdata bss dec hex filename
>  166056   0  48  166104   288d8 1/build-gcc/gcc/gimplify.o
>  166200   0  48  166248   28968 2/build-gcc/gcc/gimplify.o
> 
> ..., so actually smaller for the first two files.  Admittedly, there is a
> 144 bytes (0.0867 %) size increase in gimplify.o, and I have not measured
> the actual runtime overhead (which I'm totally expecting to be "in the
> noise", but...), so I'm assuming that my proposal to keep the interface
> simple does not pay for the presumed runtime overhead, so I guess I'm
> posting this patch just for the archives...

I really don't understand how you could get smaller code out of that, that
doesn't make any sense.  And I don't see where it would make sense to share
the same code for handling the standalone directives and directives with
associated blocks, in all the places I've looked at you want a different
code.  And in many cases you don't have just a single TREE_CODE, but
multiple, likely all of them from the same category (either all of them
smaller/equal or all larger than OMP_SINGLE), but VRP doesn't have to be
able to fix up the weirdnesses.

So yes, I really prefer OMP_STANDALONE_CLAUSES over OMP_CLAUSES for
everything.  And, tree checking which is on by default should catch this
properly, it was just a matter of tests not being written when they should
have been.

Jakub

Re: [gomp4.1] Initial support for some OpenMP 4.1 construct parsing

[Thomas Schwinge]

Hi Jakub!

(I have not yet read any version of the OpenMP 4.1 standard.)

On Wed, 29 Apr 2015 13:14:06 +0200, Jakub Jelinek  wrote:
> --- gcc/tree.def.jj   2015-04-29 10:58:01.663745452 +0200
> +++ gcc/tree.def  2015-04-29 11:34:18.293302684 +0200

> +/* OpenMP - #pragma omp target enter data [clause1 ... clauseN]
> +   Operand 0: OMP_TARGET_ENTER_DATA_CLAUSES: List of clauses.  */
> +DEFTREECODE (OMP_TARGET_ENTER_DATA, "omp_target_enter_data", tcc_statement, 
> 1)
> +
> +/* OpenMP - #pragma omp target exit data [clause1 ... clauseN]
> +   Operand 0: OMP_TARGET_EXIT_DATA_CLAUSES: List of clauses.  */
> +DEFTREECODE (OMP_TARGET_EXIT_DATA, "omp_target_exit_data", tcc_statement, 1)

;-) Heh, OpenMP catching up with OpenACC?

> --- gcc/c/c-parser.c.jj   2015-04-29 10:59:20.760504260 +0200
> +++ gcc/c/c-parser.c  2015-04-29 11:03:04.641991095 +0200

> map ( variable-list )
>  
> map-kind:
> - alloc | to | from | tofrom  */
> + alloc | to | from | tofrom
> +
> +   OpenMP 4.1:
> +   map-kind:
> + alloc | to | from | tofrom | delete
> +
> +   map ( always [,] map-kind: variable-list ) */

"Funnily", OpenACC 2.5 is said to be dropping the "always" semantics that
OpenMP 4.1 is now adding...  That is, OpenACC 2.5's "copy" will then be
the same as "present_or_copy", and so on.

>  static tree
>  c_parser_omp_target_data (location_t loc, c_parser *parser)
>  {
> -  tree stmt = make_node (OMP_TARGET_DATA);
> -  TREE_TYPE (stmt) = void_type_node;
> -
> -  OMP_TARGET_DATA_CLAUSES (stmt)
> +  tree clauses
>  = c_parser_omp_all_clauses (parser, OMP_TARGET_DATA_CLAUSE_MASK,
>   "#pragma omp target data");
> +  if (find_omp_clause (clauses, OMP_CLAUSE_MAP) == NULL_TREE)
> +{
> +  error_at (loc,
> + "%<#pragma omp target data%> must contain at least one "
> + "% clause");
> +  return NULL_TREE;
> +}
> +
> +  tree stmt = make_node (OMP_TARGET_DATA);
> +  TREE_TYPE (stmt) = void_type_node;
> +  OMP_TARGET_DATA_CLAUSES (stmt) = clauses;

Even if it doesn't make a lot of sense, my reading of OpenMP 4.0 has been
that a target data construct without any map clauses is still valid.
(But I have not verified that now.)

> --- gcc/omp-low.c.jj  2015-04-29 10:58:01.489748182 +0200
> +++ gcc/omp-low.c 2015-04-29 11:03:04.646991017 +0200
> @@ -8994,6 +9017,11 @@ expand_omp_target (struct omp_region *re
>  case GF_OMP_TARGET_KIND_UPDATE:
>start_ix = BUILT_IN_GOMP_TARGET_UPDATE;
>break;
> +case GF_OMP_TARGET_KIND_ENTER_DATA:
> +case GF_OMP_TARGET_KIND_EXIT_DATA:
> +  /* FIXME */
> +  start_ix = BUILT_IN_GOMP_TARGET_UPDATE;
> +  break;

Actually, I've also wondered (but never verified) whether all of the
OpenACC enter, exit, and update constructs can be implemented via the
same libgomp API.

> @@ -11488,6 +11520,9 @@ lower_omp_target (gimple_stmt_iterator *
> default:
>   gcc_unreachable ();
> }
> + /* FIXME: Temporary hack.  */
> + if (talign_shift == 3)
> +   tkind &= ~GOMP_MAP_FLAG_FORCE;
>   gcc_checking_assert (tkind
>< (HOST_WIDE_INT_C (1U) << talign_shift));
>   talign = ceil_log2 (talign);

Assuming you'll be changing the relevant functions' APIs, and assigning
new ABI versions, don't forget to also drop the unused offload_table
formal parameter (assuming that it remains unused).

> --- gcc/tree-pretty-print.c.jj2015-04-29 10:58:01.663745452 +0200
> +++ gcc/tree-pretty-print.c   2015-04-29 11:03:04.648990986 +0200
> @@ -550,22 +560,22 @@ dump_omp_clause (pretty_printer *pp, tre
> pp_string (pp, "tofrom");
> break;
>   case GOMP_MAP_FORCE_ALLOC:
> -   pp_string (pp, "force_alloc");
> +   pp_string (pp, "always,alloc");
> break;
>   case GOMP_MAP_FORCE_TO:
> -   pp_string (pp, "force_to");
> +   pp_string (pp, "always,to");
> break;
>   case GOMP_MAP_FORCE_FROM:
> -   pp_string (pp, "force_from");
> +   pp_string (pp, "always,from");
> break;
>   case GOMP_MAP_FORCE_TOFROM:
> -   pp_string (pp, "force_tofrom");
> +   pp_string (pp, "always,tofrom");
> break;
>   case GOMP_MAP_FORCE_PRESENT:
> pp_string (pp, "force_present");
> break;
>   case GOMP_MAP_FORCE_DEALLOC:
> -   pp_string (pp, "force_dealloc");
> +   pp_string (pp, "always,delete");
> break;
>   case GOMP_MAP_FORCE_DEVICEPTR:
> pp_string (pp, "force_deviceptr");

Makes some sense to me to use the same "always,*" syntax also for the
other "force_*" ones, given that these are artificial ("non-OpenACC")
descriptions anyway.


Grüße,
 Thomas


pgpjMXZF07u4u.pgp
Description: PGP signature

Re: [patch] Perform anonymous constant propagation during inlining

[Richard Biener]

On Wed, Apr 29, 2015 at 11:50 AM, Eric Botcazou  wrote:
> Historically the pragma Inline_Always of GNAT had been implemented in the FE
> because the RTL inliner and then the Tree inliner weren't invoked at -O0 or
> powerful enough to inline some constructs.  But this approach had drawbacks,
> especially wrt debug info.  These restrictions were gradually lifted and now
> the pragma is entirely piggybacked on the Tree inliner.
>
> This went mostly OK, except for a few cases where intrisinc operations that
> used to be reasonably handled at -O0 now generate awful code, the typical
> example being a modulus or division instrinsic by a power-of-2 generating a
> fully-fledged modulus or division instruction instead of a simple shift.
>
> Therefore the attached patch implements anonymous constant propagation in the
> inliner to fix the code quality regression.
>
> Tested on x86_64-suse-linux, OK for the mainline?

Hmm, special-casing this in the inliner looks odd to me.  ISTR the inliner
already propagates constant parameters to immediate uses, so I guess
you run into the casting case you handle specially.

But then if any constant propagation is ok at -O0 why not perform full-fledged
constant propagation (with !DECL_IGNORED_P vars as a propagation barrier)
as a regular SSA pass?  That is, if you'd had a Inline_Always function like

int foo (int i)
{
  return (i + 1) / i;
}

you'd not get the desired result as the i + 1 stmt wouldn't be folded
and thus the (i + 1) / i stmt wouldn't either.

That said - why does RTL optimization not save you here anyway?
After all, it is responsible for turning divisions into shifts.

Soo - if you use the existing CCP pass and make surely_varying_stmt_p
return true for defs of !DECL_IGNORED_P stmts at -O0 (strictly needed to make
setting vars in gdb possible) and somehow arrange for ccp to run at -O0...

It might help other obscure cases with inline-asms to behave consistently
with -O0 vs. -On as well.

Richard.

> 2015-04-29  Eric Botcazou  
>
> * tree-inline.c (remap_gimple_op_r): Do anonymous constant 
> propagation.
> (copy_bb): Fold conversions of constants immediately.
>
>
> 2015-04-29  Eric Botcazou  
>
> * gnat.dg/inline12.adb: New test.
>
>
> --
> Eric Botcazou

[PATCH, testsuite]: Add ieee options to gfortran.dg/namelist_87.f90

[Uros Bizjak]

Hello!

This test uses NaN, so it has to be compiled with ieee options.

2015-04-29  Uros Bizjak  

* gfortran.dg/namelist_87.f90: Use dg-add-options ieee.

Tested on alphaev68-linux-gnu and committed to mainline.

Uros.

Index: gfortran.dg/namelist_87.f90
===
--- gfortran.dg/namelist_87.f90 (revision 222558)
+++ gfortran.dg/namelist_87.f90 (working copy)
@@ -1,4 +1,5 @@
 ! { dg-do run }
+! { dg-add-options ieee }
 !
 ! PR fortran/56743
 !

Re: [PATCH][AARCH64]Use shl for vec_shr_ rtx pattern.

[Marcus Shawcroft]

On 28 April 2015 at 16:41, Renlin Li  wrote:
> Hi all,
>
> unsigned shift left dosen't support immediate shift. Previouly, gcc will
> generate asm instruction like this: "ushl d1, d0, 32", which is not a legal
> insn and will be rejected by assembler. This patch change the use of ushl in
> vec_shr_ into shl.
>
> A test case is added, and it passes on both aarch64-none-elf and
> aarch64_be-none-elf tool-chain.
>
> Okay to commit?
>
> Regards,
> Renlin Li
>
> gcc/ChangeLog:
>
> 2015-04-28  Renlin Li  
>
> * config/aarch64/aarch64-simd.md (vec_shr_): Use shl.
>
> gcc/testsuite/ChangeLog:
>
> 2015-04-28  Renlin Li  
> Alan Lawrence  
>
> * gcc.target/aarch64/vect-reduc-or_1.c: New.


I think there is another issue here, this change:

 if (BYTES_BIG_ENDIAN)
-  return "ushl %d0, %d1, %2";
+  return "shl %d0, %d1, %2";
 else
   return "ushr %d0, %d1, %2";

is in the context of:

(define_insn "vec_shr_"
  [(set (match_operand:VD 0 "register_operand" "=w")
(lshiftrt:VD (match_operand:VD 1 "register_operand" "w")
 (match_operand:SI 2 "immediate_operand" "i")))]

The RTL describes a right shift of the bits within each element in the
vector while the optab expects  a right shift of the elements within
the vector?

/Marcus

Re: [gomp4.1] Initial support for some OpenMP 4.1 construct parsing

[Jakub Jelinek]

On Wed, Apr 29, 2015 at 01:52:24PM +0200, Thomas Schwinge wrote:
> Hi Jakub!
> 
> (I have not yet read any version of the OpenMP 4.1 standard.)

There is no OpenMP 4.1 standard, just the public TR3 released in November
last year, and then some non-public WIP.

> > +  tree stmt = make_node (OMP_TARGET_DATA);
> > +  TREE_TYPE (stmt) = void_type_node;
> > +  OMP_TARGET_DATA_CLAUSES (stmt) = clauses;
> 
> Even if it doesn't make a lot of sense, my reading of OpenMP 4.0 has been
> that a target data construct without any map clauses is still valid.
> (But I have not verified that now.)

Yes, it is valid in OpenMP 4.0.  But in GCC we're just supporting the latest
standard, there is no -fopenmp={2.5,3.0,3.1,4.0,4.1} like there is
-std=c{89,99,11}.

> > --- gcc/omp-low.c.jj2015-04-29 10:58:01.489748182 +0200
> > +++ gcc/omp-low.c   2015-04-29 11:03:04.646991017 +0200
> > @@ -8994,6 +9017,11 @@ expand_omp_target (struct omp_region *re
> >  case GF_OMP_TARGET_KIND_UPDATE:
> >start_ix = BUILT_IN_GOMP_TARGET_UPDATE;
> >break;
> > +case GF_OMP_TARGET_KIND_ENTER_DATA:
> > +case GF_OMP_TARGET_KIND_EXIT_DATA:
> > +  /* FIXME */
> > +  start_ix = BUILT_IN_GOMP_TARGET_UPDATE;
> > +  break;
> 
> Actually, I've also wondered (but never verified) whether all of the
> OpenACC enter, exit, and update constructs can be implemented via the
> same libgomp API.

Well, the behavior is different.  The draft requires only alloc or to
(or always, variants) for enter data and only from or delete (or always,
variants) for exit data, so in theory it is possible to figure that from
the call without extra args, but not so for update - enter data is supposed
to increment reference counts, exit data decrement.  And, we'll need new
arguments for async (pass through info that it is async (nowait) or sync,
and the depend clause address(es)).

> 
> > @@ -11488,6 +11520,9 @@ lower_omp_target (gimple_stmt_iterator *
> >   default:
> > gcc_unreachable ();
> >   }
> > +   /* FIXME: Temporary hack.  */
> > +   if (talign_shift == 3)
> > + tkind &= ~GOMP_MAP_FLAG_FORCE;
> > gcc_checking_assert (tkind
> >  < (HOST_WIDE_INT_C (1U) << talign_shift));
> > talign = ceil_log2 (talign);
> 
> Assuming you'll be changing the relevant functions' APIs, and assigning
> new ABI versions, don't forget to also drop the unused offload_table
> formal parameter (assuming that it remains unused).

Yeah, we'll need new GOMP_target{,_data,_end_data,_update} replacements.

> > --- gcc/tree-pretty-print.c.jj  2015-04-29 10:58:01.663745452 +0200
> > +++ gcc/tree-pretty-print.c 2015-04-29 11:03:04.648990986 +0200
> > @@ -550,22 +560,22 @@ dump_omp_clause (pretty_printer *pp, tre
> >   pp_string (pp, "tofrom");
> >   break;
> > case GOMP_MAP_FORCE_ALLOC:
> > - pp_string (pp, "force_alloc");
> > + pp_string (pp, "always,alloc");
> >   break;
> > case GOMP_MAP_FORCE_TO:
> > - pp_string (pp, "force_to");
> > + pp_string (pp, "always,to");
> >   break;
> > case GOMP_MAP_FORCE_FROM:
> > - pp_string (pp, "force_from");
> > + pp_string (pp, "always,from");
> >   break;
> > case GOMP_MAP_FORCE_TOFROM:
> > - pp_string (pp, "force_tofrom");
> > + pp_string (pp, "always,tofrom");
> >   break;
> > case GOMP_MAP_FORCE_PRESENT:
> >   pp_string (pp, "force_present");
> >   break;
> > case GOMP_MAP_FORCE_DEALLOC:
> > - pp_string (pp, "force_dealloc");
> > + pp_string (pp, "always,delete");
> >   break;
> > case GOMP_MAP_FORCE_DEVICEPTR:
> >   pp_string (pp, "force_deviceptr");
> 
> Makes some sense to me to use the same "always,*" syntax also for the
> other "force_*" ones, given that these are artificial ("non-OpenACC")
> descriptions anyway.

Ok.  Are the GOMP_MAP_FORCE_* artificial too?  If yes, I can change that
to GOMP_MAP_ALWAYS_*.

Anyway, for most of the further 4.1 offloading I'll defer to Ilya Verbin and
Kyrill as agreed privately on IRC, I'll focus for now on the task / doacross
etc. stuff for now (and, hopefully if enough of the OpenACC stuff is merged
in soon, restart work on the OpenMP 4.0 / NVPTX offloading too, but that not
on this branch).

Jakub

Re: [PATCH 3/3] Fix indentation issues seen by -Wmisleading-indentation

[Mikael Morin]

Hello,

Le 29/04/2015 02:02, David Malcolm a écrit :
> diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c
> index 2c7c554..30e4eab 100644
> --- a/gcc/fortran/parse.c
> +++ b/gcc/fortran/parse.c
> @@ -4283,7 +4283,7 @@ parse_oacc_structured_block (gfc_statement acc_st)
>   unexpected_eof ();
>else if (st != acc_end_st)
>   gfc_error ("Expecting %s at %C", gfc_ascii_statement (acc_end_st));
> - reject_statement ();
> +  reject_statement ();
>  }
>while (st != acc_end_st);
>  
I think this one is a bug; there should be braces around 'gfc_error' and
'reject_statement'.
At least that's the pattern in 'parse_oacc_loop', and how the
'unexpected_statement' function is used.
Author CC'ed in any case.

Mikael

[Patch, fortran, pr65548, 2nd take] [5/6 Regression] gfc_conv_procedure_call

[Andre Vehreschild]

Hi all,

after the first patch to fix the issue reported in the pr, some more issues were
reported, which are now fixed by this new patch, aka the 2nd take.

The patch modifies the gfc_trans_allocate() in order to pre-evaluate all source=
expressions. It no longer rejects array valued source= expressions, but just
uses gfc_conv_expr_descriptor () for most of them. Furthermore, is the allocate
now again able to allocate arrays of strings. This feature previously slipped
my attention.

Although the reporter has not yet reported, that the patch fixes his issue, I
like to post it for review, because there are more patches in my pipeline, that
depend on this one. 

Bootstraps and regtests ok on x86_64-linux-gnu/F21.

Ok, for trunk?

Regards,
Andre
-- 
Andre Vehreschild * Email: vehre ad gmx dot de 


pr65548_2.clog
Description: Binary data
diff --git a/gcc/fortran/trans-stmt.c b/gcc/fortran/trans-stmt.c
index 53e9bcc..1e435be 100644
--- a/gcc/fortran/trans-stmt.c
+++ b/gcc/fortran/trans-stmt.c
@@ -5148,14 +5148,11 @@ gfc_trans_allocate (gfc_code * code)
   TREE_USED (label_finish) = 0;
 }
 
-  /* When an expr3 is present, try to evaluate it only once.  In most
- cases expr3 is invariant for all elements of the allocation list.
- Only exceptions are arrays.  Furthermore the standards prevent a
- dependency of expr3 on the objects in the allocate list.  Therefore
- it is safe to pre-evaluate expr3 for complicated expressions, i.e.
- everything not a variable or constant.  When an array allocation
- is wanted, then the following block nevertheless evaluates the
- _vptr, _len and element_size for expr3.  */
+  /* When an expr3 is present evaluate it only once.  The standards prevent a
+ dependency of expr3 on the objects in the allocate list.  An expr3 can
+ be pre-evaluated in all cases.  One just has to make sure, to use the
+ correct way, i.e., to get the descriptor or to get a reference
+ expression.  */
   if (code->expr3)
 {
   bool vtab_needed = false;
@@ -5168,75 +5165,86 @@ gfc_trans_allocate (gfc_code * code)
 	   al = al->next)
 	vtab_needed = (al->expr->ts.type == BT_CLASS);
 
-  /* A array expr3 needs the scalarizer, therefore do not process it
-	 here.  */
-  if (code->expr3->expr_type != EXPR_ARRAY
-	  && (code->expr3->rank == 0
-	  || code->expr3->expr_type == EXPR_FUNCTION)
-	  && (!code->expr3->symtree
-	  || !code->expr3->symtree->n.sym->as)
-	  && !gfc_is_class_array_ref (code->expr3, NULL))
-	{
-	  /* When expr3 is a variable, i.e., a very simple expression,
+  /* When expr3 is a variable, i.e., a very simple expression,
 	 then convert it once here.  */
-	  if ((code->expr3->expr_type == EXPR_VARIABLE)
-	  || code->expr3->expr_type == EXPR_CONSTANT)
-	{
-	  if (!code->expr3->mold
-		  || code->expr3->ts.type == BT_CHARACTER
-		  || vtab_needed)
-		{
-		  /* Convert expr3 to a tree.  */
-		  gfc_init_se (&se, NULL);
-		  se.want_pointer = 1;
-		  gfc_conv_expr (&se, code->expr3);
-		  if (!code->expr3->mold)
-		expr3 = se.expr;
-		  else
-		expr3_tmp = se.expr;
-		  expr3_len = se.string_length;
-		  gfc_add_block_to_block (&block, &se.pre);
-		  gfc_add_block_to_block (&post, &se.post);
-		}
-	  /* else expr3 = NULL_TREE set above.  */
-	}
-	  else
+  if (code->expr3->expr_type == EXPR_VARIABLE
+	  || code->expr3->expr_type == EXPR_ARRAY
+	  || code->expr3->expr_type == EXPR_CONSTANT)
+	{
+	  if (!code->expr3->mold
+	  || code->expr3->ts.type == BT_CHARACTER
+	  || vtab_needed)
 	{
-	  /* In all other cases evaluate the expr3 and create a
-		 temporary.  */
+	  /* Convert expr3 to a tree.  */
 	  gfc_init_se (&se, NULL);
-	  if (code->expr3->rank != 0
-		  && code->expr3->expr_type == EXPR_FUNCTION
-		  && code->expr3->value.function.isym)
+	  /* For all "simple" expression just get the descriptor or the
+		 reference, respectively, depending on the rank of the expr.  */
+	  if (code->expr3->rank != 0)
 		gfc_conv_expr_descriptor (&se, code->expr3);
 	  else
 		gfc_conv_expr_reference (&se, code->expr3);
-	  if (code->expr3->ts.type == BT_CLASS)
-		gfc_conv_class_to_class (&se, code->expr3,
-	 code->expr3->ts,
-	 false, true,
-	 false, false);
+	  if (!code->expr3->mold)
+		expr3 = se.expr;
+	  else
+		expr3_tmp = se.expr;
+	  expr3_len = se.string_length;
 	  gfc_add_block_to_block (&block, &se.pre);
 	  gfc_add_block_to_block (&post, &se.post);
-	  /* Prevent aliasing, i.e., se.expr may be already a
+	}
+	  /* else expr3 = NULL_TREE set above.  */
+	}
+  else
+	{
+	  /* In all other cases evaluate the expr3 and create a
+		 temporary.  */
+	  gfc_init_se (&se, NULL);
+	  /* For more complicated expression, the decision when to get the
+	 descriptor and when to get a reference is depending on more
+	 conditions.  The descriptor is only retrieved for functions
+	 that are i

Re: [PATCH 3/8] add default for PCC_BITFIELD_TYPE_MATTERS

[Andreas Schwab]

spawn /daten/aranym/gcc/gcc-20150429/Build/gcc/xgcc 
-B/daten/aranym/gcc/gcc-20150429/Build/gcc/ 
/daten/aranym/gcc/gcc-20150429/gcc/testsuite/objc/execute/bf-1.m 
-fno-diagnostics-show-caret -fdiagnostics-color=never -w -O0 -fgnu-runtime 
-I/daten/aranym/gcc/gcc-20150429/gcc/testsuite/../../libobjc 
-B/daten/aranym/gcc/gcc-20150429/Build/m68k-linux/./libobjc/.libs 
-L/daten/aranym/gcc/gcc-20150429/Build/m68k-linux/./libobjc/.libs -lobjc -lm -o 
/daten/aranym/gcc/gcc-20150429/Build/gcc/testsuite/objc/bf-1.x0
PASS: objc/execute/bf-1.m compilation,  -O0 -fgnu-runtime
Executing on aranym: OMP_NUM_THREADS=2 
LD_LIBRARY_PATH=.::/daten/aranym/gcc/gcc-20150429/Build/gcc:/daten/aranym/gcc/gcc-20150429/Build/m68k-linux/./libobjc/.libs
 timeout 600 /daten/aranym/gcc/gcc-20150429/Build/gcc/testsuite/objc/bf-1.x0
(timeout = 300)
Executed /daten/aranym/gcc/gcc-20150429/Build/gcc/testsuite/objc/bf-1.x0, 
status 1
Output: type = {class_vars=#fc{?=b0i2b2i3b5i12}c}
ivar 'isa', type '#', offset 0d
ivar 'f', type 'f', offset 4d
ivar 'a', type 'c', offset 8d
ivar 'flags', type '{?="i"b0i2"j"b2i3"k"b5i12}', offset 9d
ivar 'c', type 'c', offset 12d
real ivar 'isa' offset 0d
computed type '#fc{?=b0i2b2i3b5i12}c}' offset 0
real ivar 'f' offset 4d
computed type 'fc{?=b0i2b2i3b5i12}c}' offset 4
real ivar 'a' offset 8d
computed type 'c{?=b0i2b2i3b5i12}c}' offset 8
real ivar 'flags' offset 9d
computed type '{?=b0i2b2i3b5i12}c}' offset 10
offset 9d and computed position 10 don't match on ivar 'flags' (i = 3)
child process exited abnormally
FAIL: objc/execute/bf-1.m execution,  -O0 -fgnu-runtime

Andreas.

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

[C++ Patch] PR 64667

[Paolo Carlini]

Hi,

Jonathan noticed in the audit trail the probably his work for c++/18016 
could be easily extended to handle references: simply looking through 
INDIRECT_REFs appears to do the trick. Tested x86_64-linux.


Thanks,
Paolo.


/cp
2015-04-29  Paolo Carlini  

PR c++/64667
* init.c (perform_member_init): Handle references for -Winit-self.

/testsuite
2015-04-29  Paolo Carlini  

PR c++/64667
* g++.dg/warn/Winit-self-3.C: New.
Index: cp/init.c
===
--- cp/init.c   (revision 222561)
+++ cp/init.c   (working copy)
@@ -625,6 +625,9 @@ perform_member_init (tree member, tree init)
   && TREE_CHAIN (init) == NULL_TREE)
 {
   tree val = TREE_VALUE (init);
+  /* Handle references.  */
+  if (TREE_CODE (val) == INDIRECT_REF)
+   val = TREE_OPERAND (val, 0);
   if (TREE_CODE (val) == COMPONENT_REF && TREE_OPERAND (val, 1) == member
  && TREE_OPERAND (val, 0) == current_class_ref)
warning_at (DECL_SOURCE_LOCATION (current_function_decl),
Index: testsuite/g++.dg/warn/Winit-self-3.C
===
--- testsuite/g++.dg/warn/Winit-self-3.C(revision 0)
+++ testsuite/g++.dg/warn/Winit-self-3.C(working copy)
@@ -0,0 +1,26 @@
+// PR c++/64667
+// { dg-options "-Winit-self" }
+
+class A
+{
+public:
+  A(const A&) : a(a) {}  // { dg-warning "initialized with itself" }
+private:
+  int a;
+};
+
+class B
+{
+public:
+  B(const B&) : b(b) {}  // { dg-warning "initialized with itself" }
+private:
+  int* b;
+};
+
+class C
+{
+public:
+  C(const C&) : c(c) {}  // { dg-warning "initialized with itself" }
+private:
+  int& c;
+};

Re: [PATCH 5/13] microblaze musl support

[Michael Eager]

On 04/27/2015 07:35 AM, Szabolcs Nagy wrote:


On 20/04/15 19:54, Szabolcs Nagy wrote:

Set up dynamic linker name for microblaze.



Patch v2.
(undef MUSL_DYNAMIC_LINKER that comes from config/linux.h)

gcc/Changelog:

2015-04-24  Gregor Richards  

* config/microblaze/linux.h (MUSL_DYNAMIC_LINKER): Define.
(DYNAMIC_LINKER): Change.



Are you building with both glibc and musl to verify these patches?

--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: [PATCH,rs6000] Change -mcrypto to only affect Category:Vector.Crypto instructions

[David Edelsohn]

On Wed, Mar 4, 2015 at 3:14 PM, Bill Schmidt
 wrote:
> Hi,
>
> I recently observed that -mno-crypto disables all instructions in
> section 5.11 of the 2.07 ISA, rather than just those flagged as
> Category:Vector.Crypto.  This patch fixes that undesirable situation.
>
> The main fix is to ensure the remaining instructions are gated by
> TARGET_P8_VECTOR rather than TARGET_CRYPTO.  This leaves us in a
> somewhat ugly state where we have builtins named __builtin_crypto_* that
> are not controlled by -mcrypto.  However, we have to keep support for
> these existing builtins.  As discussed elsewhere, the longer-term plan
> is to implement a different common naming scheme for these builtins
> across all POWER compilers, at which point the __builtin_crypto_* forms
> will be deprecated.
>
> The changes to rs6000-builtin.def aren't the prettiest in the world, but
> were the best I could think of that continues support for the existing
> builtins while changing their predicates.  Let me know if there's a
> better way.
>
> Ok for trunk once GCC 5 branches?  I would eventually like to fix this
> in 4.8, 4.9, and 5 as well.

> Index: gcc/testsuite/gcc.target/powerpc/crypto-builtin-2.c
> ===
> --- gcc/testsuite/gcc.target/powerpc/crypto-builtin-2.c (revision 0)
> +++ gcc/testsuite/gcc.target/powerpc/crypto-builtin-2.c (working copy)
> @@ -0,0 +1,36 @@
> +/* { dg-do compile { target { powerpc*-*-* } } } */
> +/* { dg-skip-if "" { powerpc*-*-darwin* } { "*" } { "" } } */
> +/* { dg-require-effective-target powerpc_vsx_ok } */
> +/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
> "-mcpu=power8" } } */
> +/* { dg-options "-O2 -mcpu=power8 -mno-crypto" } */

Bill,

I think this test criterion is wrong and should be

Index: crypto-builtin-2.c
===
--- crypto-builtin-2.c  (revision 222534)
+++ crypto-builtin-2.c  (working copy)
@@ -1,6 +1,6 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
 /* { dg-skip-if "" { powerpc*-*-darwin* } { "*" } { "" } } */
-/* { dg-require-effective-target powerpc_vsx_ok } */
+/* { dg-require-effective-target powerpc_p8vector_ok } */
 /* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*"
} { "-mcpu=power8" } } */
 /* { dg-options "-O2 -mcpu=power8 -mno-crypto" } */

Thoughts?

- David

Re: [patch] Perform anonymous constant propagation during inlining

[Jan Hubicka]

> Historically the pragma Inline_Always of GNAT had been implemented in the FE 
> because the RTL inliner and then the Tree inliner weren't invoked at -O0 or 
> powerful enough to inline some constructs.  But this approach had drawbacks, 
> especially wrt debug info.  These restrictions were gradually lifted and now 
> the pragma is entirely piggybacked on the Tree inliner.
> 
> This went mostly OK, except for a few cases where intrisinc operations that 
> used to be reasonably handled at -O0 now generate awful code, the typical 
> example being a modulus or division instrinsic by a power-of-2 generating a 
> fully-fledged modulus or division instruction instead of a simple shift.
> 
> Therefore the attached patch implements anonymous constant propagation in the 
> inliner to fix the code quality regression.
> 
> Tested on x86_64-suse-linux, OK for the mainline?
> 
>if (TREE_CODE (*tp) == SSA_NAME)
>  {
> -  *tp = remap_ssa_name (*tp, id);
> +  tree t = remap_ssa_name (*tp, id);
> +  /* Perform anonymous constant propagation, this makes it possible to
> + generate reasonable code even at -O0 for operators implemented as
> + inline functions.  */
> +  if (TREE_CODE (t) == SSA_NAME
> +   && SSA_NAME_DEF_STMT (t)
> +   && (!SSA_NAME_VAR (t) || DECL_IGNORED_P (SSA_NAME_VAR (t)))
> +   && gimple_assign_copy_p (SSA_NAME_DEF_STMT (t))
> +   && is_gimple_min_invariant
> +  (gimple_assign_rhs1 (SSA_NAME_DEF_STMT (t
> + *tp = gimple_assign_rhs1 (SSA_NAME_DEF_STMT (t));
> +  else
> + *tp = t;

This looks like a good idea to me (though i can't approve it).  We may want to
lift the (!SSA_NAME_VAR (t) || DECL_IGNORED_P (SSA_NAME_VAR (t))) when optimize
is set - the amount of garbage inliner produce is large and killing it early is
better than killing it later.  This has chance to help early opts where
ordering between ccp and einline is quite hard.
>*walk_subtrees = 0;
>return NULL;
>  }
> @@ -1965,7 +1977,7 @@ copy_bb (copy_body_data *id, basic_block
>  
> /* Statements produced by inlining can be unfolded, especially
>when we constant propagated some operands.  We can't fold
> -  them right now for two reasons:
> +  them right now in the general case for two reasons:
>1) folding require SSA_NAME_DEF_STMTs to be correct
>2) we can't change function calls to builtins.
>So we just mark statement for later folding.  We mark
> @@ -1974,7 +1986,10 @@ copy_bb (copy_body_data *id, basic_block
>foldable indirectly are updated.  If this turns out to be
>expensive, copy_body can be told to watch for nontrivial
>changes.  */
> -   if (id->statements_to_fold)
> +   if (gimple_assign_cast_p (stmt)
> +   && is_gimple_min_invariant (gimple_assign_rhs1 (stmt)))
> + fold_stmt (©_gsi);
> +   else if (id->statements_to_fold)

Why this is needed? Is it just an optimization because we know that folding of
casts will not do crazy stuff like SSA graph walking (that was original reason
for delaying the folidng) or just an optimization to reudce the size of the 
list?

Honza
>   id->statements_to_fold->add (stmt);
>  
> /* We're duplicating a CALL_EXPR.  Find any corresponding

Re: [PATCH][AArch64] Fix PR/65770 vstN_lane on bigendian

[Alan Lawrence]

Alan Lawrence wrote:
As per bugzilla entry, indices in the generated assembly for bigendian are 
flipped when they should not be (and, flipped always relative to a Q-register!).


This flips the lane indices back again at assembly time, fixing PR. The 
"indices" contained in the RTL are still wrong for D registers, but these are 
only parameters to an UNSPEC and so never acted upon. (Nonetheless I intend to 
fix this anomaly in later patches).


Tested check-gcc on aarch64-none-elf and aarch64_be-none-elf.
New test (initially failing on bigendian) now passing on both.

gcc/ChangeLog:

PR target/65770
config/aarch64/aarch64-simd.md (vec_store_lanesoi_lane,
vec_store_lanesci_lane, vec_store_lanesxi_lane):
Flip lane index back at assembly time for bigendian.

gcc/testsuite/ChangeLog:

PR target/65770
gcc.target/aarch64/vstN_lane_1.c: New file.


Ping.

Re: [C++ Patch] PR 64667

[Jason Merrill]

On 04/29/2015 08:52 AM, Paolo Carlini wrote:

+  /* Handle references.  */
+  if (TREE_CODE (val) == INDIRECT_REF)


Let's use REFERENCE_REF_P here.  OK with that change.

Jason

Re: [PATCH 0/13] Add musl support to GCC

[Szabolcs Nagy]

On 29/04/15 00:27, Joseph Myers wrote:
> On Mon, 20 Apr 2015, Szabolcs Nagy wrote:
> 
>> * On powerpc it seems the only configure option to choose the default
>> long-double abi is --with-long-double-128, but that's the default with
>> sufficiently new glibc. (musl gets 64bit long-double because the glibc
>> version check fails, this is ok, because there is no ibm128 support in
>> musl, but it would be better if --with-long-double-64 could be set
>> explicitly or even ieee128 abi if gcc supports that).
> 
> It should be possible to use --without-long-double-128 (if not, that's a 
> bug).
> 

ok, --without-long-double-128 works, i thought i tested it

>> * gcc stdatomic.h has some incompatible typedefs with musl stdint.h
> 
> If musl has chosen stdint.h types different from those in glibc, you need 
> to make the *_TYPE macros appropriately conditional (possibly making 
> glibc-stdint.h include conditionals to select the musl types when musl is 
> in use).
> 

only affects [u]int_fastN_t types
(on 64bit systems for N=16,32 musl uses int but glibc uses long)

i can fix glibc-stdint.h, but it's yet another way in which the
compiler is tied to a particular libc.

(using musl-stdint.h would be nicer, but that would require more
changes i think, i have a fix now where the glibc-stdint.h types
depend on OPTION_MUSL, but i still have to make sure OPTION_MUSL
is always defined when this header is used).

(i'd prefer if the compiler did not know about these types, but
the standard requires them in stdatomic.h without including stdint.h
and in stdint.h in freestanding mode, i'm not sure if there is a
workaround without depending on libc)

Re: [PATCH][AArch64] Fix PR/65770 vstN_lane on bigendian

[Marcus Shawcroft]

On 16 April 2015 at 18:27, Alan Lawrence  wrote:
> As per bugzilla entry, indices in the generated assembly for bigendian are
> flipped when they should not be (and, flipped always relative to a
> Q-register!).
>
> This flips the lane indices back again at assembly time, fixing PR. The
> "indices" contained in the RTL are still wrong for D registers, but these
> are only parameters to an UNSPEC and so never acted upon. (Nonetheless I
> intend to fix this anomaly in later patches).
>
> Tested check-gcc on aarch64-none-elf and aarch64_be-none-elf.
> New test (initially failing on bigendian) now passing on both.
>
> gcc/ChangeLog:
>
> PR target/65770
> config/aarch64/aarch64-simd.md (vec_store_lanesoi_lane,
> vec_store_lanesci_lane, vec_store_lanesxi_lane):
> Flip lane index back at assembly time for bigendian.
>
> gcc/testsuite/ChangeLog:
>
> PR target/65770
> gcc.target/aarch64/vstN_lane_1.c: New file.

OK and backport to 5 please. /Marcus

Re: [patch] Perform anonymous constant propagation during inlining

[Richard Biener]

On Wed, Apr 29, 2015 at 3:23 PM, Jan Hubicka  wrote:
>> Historically the pragma Inline_Always of GNAT had been implemented in the FE
>> because the RTL inliner and then the Tree inliner weren't invoked at -O0 or
>> powerful enough to inline some constructs.  But this approach had drawbacks,
>> especially wrt debug info.  These restrictions were gradually lifted and now
>> the pragma is entirely piggybacked on the Tree inliner.
>>
>> This went mostly OK, except for a few cases where intrisinc operations that
>> used to be reasonably handled at -O0 now generate awful code, the typical
>> example being a modulus or division instrinsic by a power-of-2 generating a
>> fully-fledged modulus or division instruction instead of a simple shift.
>>
>> Therefore the attached patch implements anonymous constant propagation in the
>> inliner to fix the code quality regression.
>>
>> Tested on x86_64-suse-linux, OK for the mainline?
>>
>>if (TREE_CODE (*tp) == SSA_NAME)
>>  {
>> -  *tp = remap_ssa_name (*tp, id);
>> +  tree t = remap_ssa_name (*tp, id);
>> +  /* Perform anonymous constant propagation, this makes it possible to
>> + generate reasonable code even at -O0 for operators implemented as
>> + inline functions.  */
>> +  if (TREE_CODE (t) == SSA_NAME
>> +   && SSA_NAME_DEF_STMT (t)
>> +   && (!SSA_NAME_VAR (t) || DECL_IGNORED_P (SSA_NAME_VAR (t)))
>> +   && gimple_assign_copy_p (SSA_NAME_DEF_STMT (t))
>> +   && is_gimple_min_invariant
>> +  (gimple_assign_rhs1 (SSA_NAME_DEF_STMT (t
>> + *tp = gimple_assign_rhs1 (SSA_NAME_DEF_STMT (t));
>> +  else
>> + *tp = t;
>
> This looks like a good idea to me (though i can't approve it).  We may want to
> lift the (!SSA_NAME_VAR (t) || DECL_IGNORED_P (SSA_NAME_VAR (t))) when 
> optimize
> is set - the amount of garbage inliner produce is large and killing it early 
> is
> better than killing it later.  This has chance to help early opts where
> ordering between ccp and einline is quite hard.

Early opts run CCP as pretty much the first pass, so I don't see what
you are refering to here.

>>*walk_subtrees = 0;
>>return NULL;
>>  }
>> @@ -1965,7 +1977,7 @@ copy_bb (copy_body_data *id, basic_block
>>
>> /* Statements produced by inlining can be unfolded, especially
>>when we constant propagated some operands.  We can't fold
>> -  them right now for two reasons:
>> +  them right now in the general case for two reasons:
>>1) folding require SSA_NAME_DEF_STMTs to be correct
>>2) we can't change function calls to builtins.
>>So we just mark statement for later folding.  We mark
>> @@ -1974,7 +1986,10 @@ copy_bb (copy_body_data *id, basic_block
>>foldable indirectly are updated.  If this turns out to be
>>expensive, copy_body can be told to watch for nontrivial
>>changes.  */
>> -   if (id->statements_to_fold)
>> +   if (gimple_assign_cast_p (stmt)
>> +   && is_gimple_min_invariant (gimple_assign_rhs1 (stmt)))
>> + fold_stmt (©_gsi);
>> +   else if (id->statements_to_fold)
>
> Why this is needed? Is it just an optimization because we know that folding of
> casts will not do crazy stuff like SSA graph walking (that was original reason
> for delaying the folidng) or just an optimization to reudce the size of the 
> list?

Beause this folding turns the cast into sth the above hunk handles...

It's basically a hack ;)

A better approach might be to simply fold stmts we copy during the
stmt copy itself by using gimple_build intead of gimple_copy + fold_stmt.
Note that the match-and-simplify machinery does not perform constant
propgation but relies on a valueization hook.

Richard.

> Honza
>>   id->statements_to_fold->add (stmt);
>>
>> /* We're duplicating a CALL_EXPR.  Find any corresponding

Re: Mostly rewrite genrecog

[Richard Sandiford]

Eric Botcazou  writes:
>> Also, the code is all goto-based, which makes it rather hard to step
>> through.
>
> Do you mean the code in genrecog.c or the generated code in insn-recog.c?

The generated code.  genrecog.c itself isn't bad. :-)

>> PS. I've attached the new genrecog.c since the diff version is unreadable.
>
> Small request: you didn't change a single line of the head comment, yet the 
> size of the file is doubled.  Could you add a sketch of the algorithm to the 
> head comment, e.g. by copy-and-pasting the above part of your message?

OK.  I'd left the head comment alone because it just described the
interface, which hasn't changed.  But I suppose past lack of commentary
doesn't justify future lack of commentary.  Here's what I added:

   At a high level, the algorithm used in this file is as follows:

   1. Build up a decision tree for each routine, using the following
  approach to matching an rtx:

  - First determine the "shape" of the rtx, based on GET_CODE,
XVECLEN and XINT.  This phase examines SET_SRCs before SET_DESTs
since SET_SRCs tend to be more distinctive.  It examines other
operands in numerical order, since the canonicalization rules
prefer putting complex operands of commutative operators first.

  - Next check modes and predicates.  This phase examines all
operands in numerical order, even for SETs, since the mode of a
SET_DEST is exact while the mode of a SET_SRC can be VOIDmode
for constant integers.

  - Next check match_dups.

  - Finally check the C condition and (where appropriate) pnum_clobbers.

   2. Try to optimize the tree by removing redundant tests, CSEing tests,
  folding tests together, etc.

   3. Look for common subtrees and split them out into "pattern" routines.
  These common subtrees can be identical or they can differ in mode,
  code, or integer (usually an UNSPEC or UNSPEC_VOLATILE code).
  In the latter case the users of the pattern routine pass the
  appropriate mode, etc., as argument.  For example, if two patterns
  contain:

 (plus:SI (match_operand:SI 1 "register_operand")
  (match_operand:SI 2 "register_operand"))

  we can split the associated matching code out into a subroutine.
  If a pattern contains:

 (minus:DI (match_operand:DI 1 "register_operand")
   (match_operand:DI 2 "register_operand"))

  then we can consider using the same matching routine for both
  the plus and minus expressions, passing PLUS and SImode in the
  former case and MINUS and DImode in the latter case.

  The main aim of this phase is to reduce the compile time of the
  insn-recog.c code and to reduce the amount of object code in
  insn-recog.o.

   4. Split the matching trees into functions, trying to limit the
  size of each function to a sensible amount.

  Again, the main aim of this phase is to reduce the compile time
  of insn-recog.c.  (It doesn't help with the size of insn-recog.o.)

   5. Write out C++ code for each function.

BTW, hope at least part of the doubling in size is due to more commentary
in the code itself.

> The old code contained a couple of DEBUG_FUNCTIONs but the new one doesn't.

Yeah, but I don't know how useful they were.  I had to debug the old
code several times and never used them.

I'd rather leave stuff like that to someone who wants it rather than try
to write routines speculatively in the hope that someone would find them
useful.

Thanks,
Richard

Re: Mostly rewrite genrecog

[Richard Sandiford]

Jeff Law  writes:
> On 04/27/2015 04:20 AM, Richard Sandiford wrote:
>> Tested on x86_64-linux-gnu, aarch64-linux-gnu and arm-none-eabi.
>> Also tested by building the testsuite for each of the targets above
>> and making sure there were no assembly differences.  Made sure that no
>> objects in spec2k6 changed for aarch64-linux-gnu (except for perlbench
>> perl.o and cactusADM datestamp.o, where the differences are timestamps).
>> OK to install?
> To be very blunt, I'm probably not capable of reviewing the new code. 
> You're going to know it best and you should probably own it.
>
> Given your history with gcc and attention to detail, I'm comfortable 
> with approving this knowing you'll deal with any issues as they arise.

Thanks, applied.

> The one thing I would ask is that you make sure to include the recently 
> added matching constraint checking bits in genrecog.  I'm assuming all 
> the older sanity checks that have been in genrecog for a longer period 
> of time have been kept.

Yeah, Chen Gang's changes are all still in there.  All the older checks
should still be in there too.

Richard

Re: [PATCH 5/13] microblaze musl support

[Szabolcs Nagy]

On 29/04/15 14:17, Michael Eager wrote:
> On 04/27/2015 07:35 AM, Szabolcs Nagy wrote:
>>
>> On 20/04/15 19:54, Szabolcs Nagy wrote:
>>> Set up dynamic linker name for microblaze.
>>>
>>
>> Patch v2.
>> (undef MUSL_DYNAMIC_LINKER that comes from config/linux.h)
>>
>> gcc/Changelog:
>>
>> 2015-04-24  Gregor Richards  
>>
>>  * config/microblaze/linux.h (MUSL_DYNAMIC_LINKER): Define.
>>  (DYNAMIC_LINKER): Change.
>>
> 
> Are you building with both glibc and musl to verify these patches?
> 

i tested various aarch64 and x86 configurations with both glibc
and musl, but not everything was tested.

in particular microblaze (big and little endian) was only built
with musl.

note that microblaze does not use the GNU_USER_DYNAMIC_LINKER
macro so the -mglibc etc options don't work.
(that should be changed probably, assuming -muclibc and -mbionic
have no side effects when they are not supported)

Re: [PATCH][AArch64] Increase static buffer size in aarch64_rewrite_selected_cpu

[Kyrill Tkachov]

On 20/04/15 21:30, James Greenhalgh wrote:

On Mon, Apr 20, 2015 at 05:24:39PM +0100, Kyrill Tkachov wrote:

Hi all,

When trying to compile a testcase with -mcpu=cortex-a57+crypto+nocrc I got
the weird assembler error:
Assembler messages:
Error: missing architectural extension
Error: unrecognized option -mcpu=cortex-a57+crypto+no

The problem is the aarch64_rewrite_selected_cpu that is used to rewrite -mcpu
for big.LITTLE options has a limit of 20 characters in what it handles, which
we can exhaust quickly if we specify architectural extensions in a
fine-grained manner.

This patch increases that character limit to 128 and adds an assert to
confirm that no bad things happen.

You've implemented this as a hard ICE, was that intended?


It also fixes another problem: If we pass a big.LITTLE combination with
feature modifiers like: -mcpu=cortex-a57.cortex-a53+nosimd

the code will truncate everything after '.', thus destroying the extensions
that we want to pass.  The patch adds code to stitch the extensions back on
after the LITTLE cpu is removed.

UGH, I should not be allowed near strings! This code is on my list of
things I'd love to rewrite to this year! For now, this is OK and please
also queue it for 5.2 when that opens for patches.


Hi all,
Just to confirm.
Is it ok to backport this patch to the GCC 5 branch?

Thanks,
Kyrill




Ok for trunk?

Yes, thanks. And sorry again for introducing this in the first place.

James

Re: [patch] Perform anonymous constant propagation during inlining

[Jan Hubicka]

> On Wed, Apr 29, 2015 at 3:23 PM, Jan Hubicka  wrote:
> >> Historically the pragma Inline_Always of GNAT had been implemented in the 
> >> FE
> >> because the RTL inliner and then the Tree inliner weren't invoked at -O0 or
> >> powerful enough to inline some constructs.  But this approach had 
> >> drawbacks,
> >> especially wrt debug info.  These restrictions were gradually lifted and 
> >> now
> >> the pragma is entirely piggybacked on the Tree inliner.
> >>
> >> This went mostly OK, except for a few cases where intrisinc operations that
> >> used to be reasonably handled at -O0 now generate awful code, the typical
> >> example being a modulus or division instrinsic by a power-of-2 generating a
> >> fully-fledged modulus or division instruction instead of a simple shift.
> >>
> >> Therefore the attached patch implements anonymous constant propagation in 
> >> the
> >> inliner to fix the code quality regression.
> >>
> >> Tested on x86_64-suse-linux, OK for the mainline?
> >>
> >>if (TREE_CODE (*tp) == SSA_NAME)
> >>  {
> >> -  *tp = remap_ssa_name (*tp, id);
> >> +  tree t = remap_ssa_name (*tp, id);
> >> +  /* Perform anonymous constant propagation, this makes it possible to
> >> + generate reasonable code even at -O0 for operators implemented as
> >> + inline functions.  */
> >> +  if (TREE_CODE (t) == SSA_NAME
> >> +   && SSA_NAME_DEF_STMT (t)
> >> +   && (!SSA_NAME_VAR (t) || DECL_IGNORED_P (SSA_NAME_VAR (t)))
> >> +   && gimple_assign_copy_p (SSA_NAME_DEF_STMT (t))
> >> +   && is_gimple_min_invariant
> >> +  (gimple_assign_rhs1 (SSA_NAME_DEF_STMT (t
> >> + *tp = gimple_assign_rhs1 (SSA_NAME_DEF_STMT (t));
> >> +  else
> >> + *tp = t;
> >
> > This looks like a good idea to me (though i can't approve it).  We may want 
> > to
> > lift the (!SSA_NAME_VAR (t) || DECL_IGNORED_P (SSA_NAME_VAR (t))) when 
> > optimize
> > is set - the amount of garbage inliner produce is large and killing it 
> > early is
> > better than killing it later.  This has chance to help early opts where
> > ordering between ccp and einline is quite hard.
> 
> Early opts run CCP as pretty much the first pass, so I don't see what
> you are refering to here.

Hmm, you are right. I remember playing with similar patch but that was before
we turned off iteration in early inliner and it was motivated to do more
of indirect  call promotion.

Since ipa-prop is no longer complete joke on propagating devirutalization info
perhaps this is no longer too important.

honza

Re: Bare bones of type verifier

[Jan Hubicka]

Hi,
this is updated patch that passes all languages LTO and non-LTO testing on 
ppc64.
I found few issues
 - C++ FE messes up METHOD pointers becuase sometimes it duplicated a type while
   METHOD list is incomplete, so there are type variants that points to the 
middle
   of the final list. (I suppose we want to track this only on main variant)
 - C FE messes TYPE_VFIELD in libgo build because it uses it to link
   C_TYPE_INCOMPLETE_VARS. Sometimes it produce type variant and forgets to 
clear
   the pointer and sometimes it never walks the lists and never clears it.
   I added code to free_lang_data to clear it since it is not quite clear
   how to track this in FE.  
 - Java FE messes up with TYPE_BINFO because it produces dummy BINFO by:
/* Unfortunately we must create the binfo here, so that class
   loading works.  */
TYPE_BINFO (type) = make_tree_binfo (0);
   and in some variants it forgets to replace it by real thing later.
   I just relaxed the check for the moment and will look into it incrementally.
   Again I think we may want TYPE_BINFO on main variants only or Java may just
   propagate proper info to all vairant copies. Both would work.
 - Java FE sometimes unnecesarily recomputes TYPE_SIZE_UNIT in different type
   so pointer compare fails even when it could pass (TYPE_SIZE is fine)
   Again I relaxed the sanity check to require sizes to be equal but not pointer
   equivalent and will look into it.

This only covers the few checks implemented in verify_type_variant.  There are
clearly many issues to look into. I will commit this version of patch tomorrow
if there are no complains and will start chasing issues in small stemps.

Honza

* dwarf2out.c (gen_type_die_with_usage): Call verify_type.
* ipa-chkp.c (chkp_copy_function_type_adding_bounds): Do not produce
bugus variants.
* tree.c: Include print-tree.h and ipa-utils.h
(free_lang_data_in_type): Clear TYPE_VFIELD leaked by C FE.
(free_lang_data_in_cgraph): Call verify_type.
(verify_type_variant): New function.
(verify_type): New function.
* tree.h (verify_type): Declare.

* lto.c (lto_fixup_state): Call verify_type.
Index: dwarf2out.c
===
--- dwarf2out.c (revision 222526)
+++ dwarf2out.c (working copy)
@@ -20238,6 +20238,11 @@ gen_type_die_with_usage (tree type, dw_d
   if (type == NULL_TREE || type == error_mark_node)
 return;
 
+#ifdef ENABLE_CHECKING
+  if (type)
+ verify_type (type);
+#endif
+
   if (TYPE_NAME (type) != NULL_TREE
   && TREE_CODE (TYPE_NAME (type)) == TYPE_DECL
   && is_redundant_typedef (TYPE_NAME (type))
Index: ipa-chkp.c
===
--- ipa-chkp.c  (revision 222526)
+++ ipa-chkp.c  (working copy)
@@ -244,7 +244,7 @@ tree
 chkp_copy_function_type_adding_bounds (tree orig_type)
 {
   tree type;
-  tree arg_type, attrs, t;
+  tree arg_type, attrs;
   unsigned len = list_length (TYPE_ARG_TYPES (orig_type));
   unsigned *indexes = XALLOCAVEC (unsigned, len);
   unsigned idx = 0, new_idx = 0;
@@ -327,20 +327,6 @@ chkp_copy_function_type_adding_bounds (t
   TYPE_ATTRIBUTES (type) = attrs;
 }
 
-  t = TYPE_MAIN_VARIANT (orig_type);
-  if (orig_type != t)
-{
-  TYPE_MAIN_VARIANT (type) = t;
-  TYPE_NEXT_VARIANT (type) = TYPE_NEXT_VARIANT (t);
-  TYPE_NEXT_VARIANT (t) = type;
-}
-  else
-{
-  TYPE_MAIN_VARIANT (type) = type;
-  TYPE_NEXT_VARIANT (type) = NULL;
-}
-
-
   return type;
 }
 
Index: lto/lto.c
===
--- lto/lto.c   (revision 222526)
+++ lto/lto.c   (working copy)
@@ -2844,6 +2844,10 @@ lto_fixup_state (struct lto_in_decl_stat
   for (i = 0; i < vec_safe_length (trees); i++)
{
  tree t = (*trees)[i];
+#ifdef ENABLE_CHECKING
+ if (TYPE_P (t))
+   verify_type (t);
+#endif
  if (VAR_OR_FUNCTION_DECL_P (t)
  && (TREE_PUBLIC (t) || DECL_EXTERNAL (t)))
(*trees)[i] = lto_symtab_prevailing_decl (t);
Index: tree.c
===
--- tree.c  (revision 222526)
+++ tree.c  (working copy)
@@ -102,6 +102,8 @@ along with GCC; see the file COPYING3.
 #include "debug.h"
 #include "intl.h"
 #include "builtins.h"
+#include "print-tree.h"
+#include "ipa-utils.h"
 
 /* Tree code classes.  */
 
@@ -5077,6 +5079,11 @@ free_lang_data_in_type (tree type)
   else
TYPE_FIELDS (type) = NULL_TREE;
 
+  /* FIXME: C FE uses TYPE_VFIELD to record C_TYPE_INCOMPLETE_VARS
+and danagle the pointer from time to time.  */
+  if (TYPE_VFIELD (type) && TREE_CODE (TYPE_VFIELD (type)) != FIELD_DECL)
+TYPE_VFIELD (type) = NULL_TREE;
+
   TYPE_METHODS (type) = NULL_TREE;
   if (TYPE_BINFO (type))
{
@@ -5784,6 +5791,10 @@ free_lang_data_in_cgraph (void)
 

Re: OMP_CLAUSES with clauses in operand 0

[Thomas Schwinge]

Hi Jakub!

On Wed, 29 Apr 2015 13:43:55 +0200, Jakub Jelinek  wrote:
> On Wed, Apr 29, 2015 at 01:13:29PM +0200, Thomas Schwinge wrote:
> > On Wed, 29 Apr 2015 11:32:31 +0200, Jakub Jelinek  wrote:
> > > Yeah, it is a non-starter, it has unnecessary runtime overhead everywhere
> > > where it is used.
> > 
> > Huh.  OMP_CLAUSES is currently used in a dozen places in
> > cp/cp-gimplify.c, cp/pt.c, and gimplify.c.  I've been expecting my
> > changed code to be well-optimizable, for the compiler already knows
> > TREE_CODE(NODE) in a lot of these places.  Doing a quick before (1)/after
> > (2) comparison test with -g -O2 on x86_64 GNU/Linux using GCC 4.8.3, the
> > object file sizes are as follows:
> > 
> >textdata bss dec hex filename
> >   37027   0  16   3704390b3 1/build-gcc/gcc/cp/cp-gimplify.o
> >   36307   0  16   363238de3 2/build-gcc/gcc/cp/cp-gimplify.o
> >textdata bss dec hex filename
> >  458742   0 136  458878   7007e 1/build-gcc/gcc/cp/pt.o
> >  458630   0 136  458766   7000e 2/build-gcc/gcc/cp/pt.o
> >textdata bss dec hex filename
> >  166056   0  48  166104   288d8 1/build-gcc/gcc/gimplify.o
> >  166200   0  48  166248   28968 2/build-gcc/gcc/gimplify.o
> > 
> > ..., so actually smaller for the first two files.  Admittedly, there is a
> > 144 bytes (0.0867 %) size increase in gimplify.o, and I have not measured
> > the actual runtime overhead (which I'm totally expecting to be "in the
> > noise", but...), so I'm assuming that my proposal to keep the interface
> > simple does not pay for the presumed runtime overhead, so I guess I'm
> > posting this patch just for the archives...
> 
> I really don't understand how you could get smaller code out of that, that
> doesn't make any sense.

I tried a quick -fdump-tree-all comparison but that doesn't lead
anywhere, because a vast number of IDs change.  Any tricks how to tackle
such a thing?


> So yes, I really prefer OMP_STANDALONE_CLAUSES over OMP_CLAUSES for
> everything.

Like this (for trunk)?

commit 300e28fce192cb56d73cb61f787872643030f0bf
Author: Thomas Schwinge 
Date:   Wed Apr 29 16:18:49 2015 +0200

Add OMP_STANDALONE_CLAUSES.

gcc/
* tree.h (OACC_CACHE_CLAUSES, OACC_DECLARE_CLAUSES)
(OACC_ENTER_DATA_CLAUSES, OACC_EXIT_DATA_CLAUSES)
(OACC_UPDATE_CLAUSES, OMP_TARGET_UPDATE_CLAUSES): Merge into...
(OMP_STANDALONE_CLAUSES): ... this new macro.  Adjust all users.
---
 gcc/c/c-parser.c|   11 ---
 gcc/cp/parser.c |   11 ---
 gcc/cp/pt.c |4 ++--
 gcc/gimplify.c  |   18 --
 gcc/tree-pretty-print.c |   12 ++--
 gcc/tree.def|   12 ++--
 gcc/tree.h  |   19 ++-
 7 files changed, 32 insertions(+), 55 deletions(-)

diff --git gcc/c/c-parser.c gcc/c/c-parser.c
index f5e2ac2c..86b77f3 100644
--- gcc/c/c-parser.c
+++ gcc/c/c-parser.c
@@ -11987,7 +11987,7 @@ c_parser_oacc_cache (location_t loc, c_parser *parser)
 
   stmt = make_node (OACC_CACHE);
   TREE_TYPE (stmt) = void_type_node;
-  OACC_CACHE_CLAUSES (stmt) = clauses;
+  OMP_STANDALONE_CLAUSES (stmt) = clauses;
   SET_EXPR_LOCATION (stmt, loc);
   add_stmt (stmt);
 
@@ -12155,10 +12155,7 @@ c_parser_oacc_enter_exit_data (c_parser *parser, bool 
enter)
 
   stmt = enter ? make_node (OACC_ENTER_DATA) : make_node (OACC_EXIT_DATA);
   TREE_TYPE (stmt) = void_type_node;
-  if (enter)
-OACC_ENTER_DATA_CLAUSES (stmt) = clauses;
-  else
-OACC_EXIT_DATA_CLAUSES (stmt) = clauses;
+  OMP_STANDALONE_CLAUSES (stmt) = clauses;
   SET_EXPR_LOCATION (stmt, loc);
   add_stmt (stmt);
 }
@@ -12285,7 +12282,7 @@ c_parser_oacc_update (c_parser *parser)
 
   tree stmt = make_node (OACC_UPDATE);
   TREE_TYPE (stmt) = void_type_node;
-  OACC_UPDATE_CLAUSES (stmt) = clauses;
+  OMP_STANDALONE_CLAUSES (stmt) = clauses;
   SET_EXPR_LOCATION (stmt, loc);
   add_stmt (stmt);
 }
@@ -13858,7 +13855,7 @@ c_parser_omp_target_update (location_t loc, c_parser 
*parser,
 
   tree stmt = make_node (OMP_TARGET_UPDATE);
   TREE_TYPE (stmt) = void_type_node;
-  OMP_TARGET_UPDATE_CLAUSES (stmt) = clauses;
+  OMP_STANDALONE_CLAUSES (stmt) = clauses;
   SET_EXPR_LOCATION (stmt, loc);
   add_stmt (stmt);
   return false;
diff --git gcc/cp/parser.c gcc/cp/parser.c
index 4ea2ca2..61fd34f 100644
--- gcc/cp/parser.c
+++ gcc/cp/parser.c
@@ -31386,7 +31386,7 @@ cp_parser_omp_target_update (cp_parser *parser, 
cp_token *pragma_tok,
 
   tree stmt = make_node (OMP_TARGET_UPDATE);
   TREE_TYPE (stmt) = void_type_node;
-  OMP_TARGET_UPDATE_CLAUSES (stmt) = clauses;
+  OMP_STANDALONE_CLAUSES (stmt) = clauses;
   SET_EXPR_LOCATION (stmt, pragma_tok->location);
   add_stmt (stmt);
   return false;
@@ -31496,7 +31496,7 @@ cp_parser_oacc_cache (cp_parser *parser, cp_token 
*pragma_tok)
 
   stmt = make_node (OACC_CACHE);
   TREE_TY

Re: OMP_CLAUSES with clauses in operand 0

[Jakub Jelinek]

On Wed, Apr 29, 2015 at 04:31:32PM +0200, Thomas Schwinge wrote:
> > So yes, I really prefer OMP_STANDALONE_CLAUSES over OMP_CLAUSES for
> > everything.
> 
> Like this (for trunk)?
> 
> commit 300e28fce192cb56d73cb61f787872643030f0bf
> Author: Thomas Schwinge 
> Date:   Wed Apr 29 16:18:49 2015 +0200
> 
> Add OMP_STANDALONE_CLAUSES.
> 
>   gcc/
>   * tree.h (OACC_CACHE_CLAUSES, OACC_DECLARE_CLAUSES)
>   (OACC_ENTER_DATA_CLAUSES, OACC_EXIT_DATA_CLAUSES)
>   (OACC_UPDATE_CLAUSES, OMP_TARGET_UPDATE_CLAUSES): Merge into...
>   (OMP_STANDALONE_CLAUSES): ... this new macro.  Adjust all users.

I would keep the specific *_CLAUSES macros, just add
OMP_STANDALONE_CLAUSES and change the uses only if you are dealing with
multiple different codes.  That will match OMP_CLAUSES vs. OMP_FOR_CLAUSES,
OMP_PARALLEL_CLAUSES etc.

> --- gcc/c/c-parser.c
> +++ gcc/c/c-parser.c
> @@ -11987,7 +11987,7 @@ c_parser_oacc_cache (location_t loc, c_parser *parser)
>  
>stmt = make_node (OACC_CACHE);
>TREE_TYPE (stmt) = void_type_node;
> -  OACC_CACHE_CLAUSES (stmt) = clauses;
> +  OMP_STANDALONE_CLAUSES (stmt) = clauses;
>SET_EXPR_LOCATION (stmt, loc);
>add_stmt (stmt);
>  

So, drop hunks like this.

> @@ -12155,10 +12155,7 @@ c_parser_oacc_enter_exit_data (c_parser *parser, 
> bool enter)
>  
>stmt = enter ? make_node (OACC_ENTER_DATA) : make_node (OACC_EXIT_DATA);
>TREE_TYPE (stmt) = void_type_node;
> -  if (enter)
> -OACC_ENTER_DATA_CLAUSES (stmt) = clauses;
> -  else
> -OACC_EXIT_DATA_CLAUSES (stmt) = clauses;
> +  OMP_STANDALONE_CLAUSES (stmt) = clauses;
>SET_EXPR_LOCATION (stmt, loc);
>add_stmt (stmt);
>  }

And just keep ones like this.

Jakub

RE: Refactor gcc/tree-vectorize.c:vectorize_loops

[Aditya K]

Thanks for the feedback. I have added comment and properly indented the code.

-Aditya


> Date: Wed, 29 Apr 2015 09:31:46 +0200
> From: ja...@redhat.com
> To: l...@redhat.com
> CC: hiradi...@msn.com; gcc-patches@gcc.gnu.org
> Subject: Re: Refactor gcc/tree-vectorize.c:vectorize_loops
>
> On Tue, Apr 28, 2015 at 09:53:24PM -0600, Jeff Law wrote:
>> On 04/28/2015 08:20 PM, Aditya K wrote:
>>>Hi,
>>>This is a small patch where I moved a portion of code from the function 
>>>vectorize_loops outside to improve readability.
>>>Please see the patch attached and give comments for improvements.
>> You need to add a comment for the new function. These function comments
>> should describe what the function does, in terms of its arguments and return
>> value (if any).
>>
>> With a function comment, this refactoring would be fine.
>
> --- a/gcc/tree-vectorizer.c
> +++ b/gcc/tree-vectorizer.c
> @@ -399,6 +399,39 @@ fold_loop_vectorized_call (gimple g, tree value)
> }
> }
>
> +static void
> +set_uid_loop_bbs(loop_vec_info loop_vinfo, gimple loop_vectorized_call)
>
> The formatting is incorrect too, missing space before ( here.
>
> +{
> + tree arg = gimple_call_arg (loop_vectorized_call, 1);
>
> Lines should be indented by 2 spaces rather than after {
>
> + basic_block *bbs;
> + unsigned int i;
> + struct loop *scalar_loop = get_loop (cfun, tree_to_shwi (arg));
> +
> + LOOP_VINFO_SCALAR_LOOP (loop_vinfo) = scalar_loop;
> + gcc_checking_assert (vect_loop_vectorized_call
> + (LOOP_VINFO_SCALAR_LOOP (loop_vinfo))
> + == loop_vectorized_call);
> + bbs = get_loop_body (scalar_loop);
> + for (i = 0; i < scalar_loop->num_nodes; i++)
> + {
> + basic_block bb = bbs[i];
> + gimple_stmt_iterator gsi;
> + for (gsi = gsi_start_phis (bb); !gsi_end_p (gsi);
> + gsi_next (&gsi))
>
> With the refactoring, this for should fit on one line.
>
> + {
> + gimple phi = gsi_stmt (gsi);
> + gimple_set_uid (phi, 0);
> + }
> + for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi);
> + gsi_next (&gsi))
>
> Likewise.
>
> if (loop_vectorized_call)
> - {
> + set_uid_loop_bbs(loop_vinfo, loop_vectorized_call);
>
> Again, missing space before (. And you are using only spaces
> when a tab plus two spaces should be used.
>
> Jakub
  

refactor-vectorize-loops.patch
Description: Binary data

Re: [gomp4.1] Initial support for some OpenMP 4.1 construct parsing

[Thomas Schwinge]

Hi Jakub!

On Wed, 29 Apr 2015 14:06:44 +0200, Jakub Jelinek  wrote:
> On Wed, Apr 29, 2015 at 01:52:24PM +0200, Thomas Schwinge wrote:
> > > --- gcc/tree-pretty-print.c.jj2015-04-29 10:58:01.663745452 +0200
> > > +++ gcc/tree-pretty-print.c   2015-04-29 11:03:04.648990986 +0200
> > > @@ -550,22 +560,22 @@ dump_omp_clause (pretty_printer *pp, tre
> > > pp_string (pp, "tofrom");
> > > break;
> > >   case GOMP_MAP_FORCE_ALLOC:
> > > -   pp_string (pp, "force_alloc");
> > > +   pp_string (pp, "always,alloc");
> > > break;
> > >   case GOMP_MAP_FORCE_TO:
> > > -   pp_string (pp, "force_to");
> > > +   pp_string (pp, "always,to");
> > > break;
> > >   case GOMP_MAP_FORCE_FROM:
> > > -   pp_string (pp, "force_from");
> > > +   pp_string (pp, "always,from");
> > > break;
> > >   case GOMP_MAP_FORCE_TOFROM:
> > > -   pp_string (pp, "force_tofrom");
> > > +   pp_string (pp, "always,tofrom");
> > > break;
> > >   case GOMP_MAP_FORCE_PRESENT:
> > > pp_string (pp, "force_present");
> > > break;
> > >   case GOMP_MAP_FORCE_DEALLOC:
> > > -   pp_string (pp, "force_dealloc");
> > > +   pp_string (pp, "always,delete");
> > > break;
> > >   case GOMP_MAP_FORCE_DEVICEPTR:
> > > pp_string (pp, "force_deviceptr");
> > 
> > Makes some sense to me to use the same "always,*" syntax also for the
> > other "force_*" ones, given that these are artificial ("non-OpenACC")
> > descriptions anyway.
> 
> Ok.  Are the GOMP_MAP_FORCE_* artificial too?  If yes, I can change that
> to GOMP_MAP_ALWAYS_*.

Yes, fine with me.  (Though, what about that »names are sticky« thing,
?)


Grüße,
 Thomas


pgpjurL6NHBRx.pgp
Description: PGP signature

[ubsan] Add -fsanitize=bounds-strict

[Marek Polacek]

This patch adds the -fsanitize=bounds-strict option Martin U. wanted; it is
actually based on his earlier patch, I did only some small adjustments.

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

2015-04-29  Marek Polacek  
Martin Uecker  

* c-ubsan.c (ubsan_instrument_bounds): Don't skip instrumenting
flexible member array-like members if SANITIZE_BOUNDS_STRICT.

* doc/invoke.texi: Document -fsanitize=bounds-strict.
* flag-types.h (enum sanitize_code): Add SANITIZE_BOUNDS_STRICT, or it
into SANITIZE_NONDEFAULT.
* opts.c (common_handle_option): Handle -fsanitize=bounds-strict.

* c-c++-common/ubsan/bounds-10.c: New test.

diff --git gcc/c-family/c-ubsan.c gcc/c-family/c-ubsan.c
index a14426f..dbbdc5b 100644
--- gcc/c-family/c-ubsan.c
+++ gcc/c-family/c-ubsan.c
@@ -301,9 +301,11 @@ ubsan_instrument_bounds (location_t loc, tree array, tree 
*index,
 bound = fold_build2 (PLUS_EXPR, TREE_TYPE (bound), bound,
 build_int_cst (TREE_TYPE (bound), 1));
 
-  /* Detect flexible array members and suchlike.  */
+  /* Detect flexible array members and suchlike, unless
+ -fsanitize=bounds-strict.  */
   tree base = get_base_address (array);
-  if (TREE_CODE (array) == COMPONENT_REF
+  if ((flag_sanitize & SANITIZE_BOUNDS_STRICT) == 0
+  && TREE_CODE (array) == COMPONENT_REF
   && base && (TREE_CODE (base) == INDIRECT_REF
  || TREE_CODE (base) == MEM_REF))
 {
diff --git gcc/doc/invoke.texi gcc/doc/invoke.texi
index 7d2f6e5..d050ba6 100644
--- gcc/doc/invoke.texi
+++ gcc/doc/invoke.texi
@@ -5728,6 +5728,13 @@ This option enables instrumentation of array bounds.  
Various out of bounds
 accesses are detected.  Flexible array members, flexible array member-like
 arrays, and initializers of variables with static storage are not instrumented.
 
+@item -fsanitize=bounds-strict
+@opindex fsanitize=bounds-strict
+This option enables strict instrumentation of array bounds.  Most out of bounds
+accesses are detected, including flexible array members and flexible array
+member-like arrays.  Initializers of variables with static storage are not
+instrumented.
+
 @item -fsanitize=alignment
 @opindex fsanitize=alignment
 
diff --git gcc/flag-types.h gcc/flag-types.h
index bfdce44..2f820a5 100644
--- gcc/flag-types.h
+++ gcc/flag-types.h
@@ -238,6 +238,7 @@ enum sanitize_code {
   SANITIZE_RETURNS_NONNULL_ATTRIBUTE = 1UL << 19,
   SANITIZE_OBJECT_SIZE = 1UL << 20,
   SANITIZE_VPTR = 1UL << 21,
+  SANITIZE_BOUNDS_STRICT = 1UL << 22,
   SANITIZE_UNDEFINED = SANITIZE_SHIFT | SANITIZE_DIVIDE | SANITIZE_UNREACHABLE
   | SANITIZE_VLA | SANITIZE_NULL | SANITIZE_RETURN
   | SANITIZE_SI_OVERFLOW | SANITIZE_BOOL | SANITIZE_ENUM
@@ -246,6 +247,7 @@ enum sanitize_code {
   | SANITIZE_RETURNS_NONNULL_ATTRIBUTE
   | SANITIZE_OBJECT_SIZE | SANITIZE_VPTR,
   SANITIZE_NONDEFAULT = SANITIZE_FLOAT_DIVIDE | SANITIZE_FLOAT_CAST
+   | SANITIZE_BOUNDS_STRICT
 };
 
 /* flag_vtable_verify initialization levels. */
diff --git gcc/opts.c gcc/opts.c
index 39c190d..8c6716b 100644
--- gcc/opts.c
+++ gcc/opts.c
@@ -1584,6 +1584,8 @@ common_handle_option (struct gcc_options *opts,
  { "float-cast-overflow", SANITIZE_FLOAT_CAST,
sizeof "float-cast-overflow" - 1 },
  { "bounds", SANITIZE_BOUNDS, sizeof "bounds" - 1 },
+ { "bounds-strict", SANITIZE_BOUNDS | SANITIZE_BOUNDS_STRICT,
+   sizeof "bounds-strict" - 1 },
  { "alignment", SANITIZE_ALIGNMENT, sizeof "alignment" - 1 },
  { "nonnull-attribute", SANITIZE_NONNULL_ATTRIBUTE,
sizeof "nonnull-attribute" - 1 },
diff --git gcc/testsuite/c-c++-common/ubsan/bounds-10.c 
gcc/testsuite/c-c++-common/ubsan/bounds-10.c
index e69de29..a6187b5 100644
--- gcc/testsuite/c-c++-common/ubsan/bounds-10.c
+++ gcc/testsuite/c-c++-common/ubsan/bounds-10.c
@@ -0,0 +1,16 @@
+/* { dg-do run } */
+/* { dg-options "-fsanitize=bounds-strict" } */
+
+struct V { int l; int a[1]; };
+
+int
+main (void)
+{
+  /* For strict, do instrument last array in a struct.  */
+  struct V *v = (struct V *) __builtin_malloc (sizeof (struct V) + 10);
+  v->a[1] = 1;
+
+  return 0;
+}
+
+/* { dg-output "index 1 out of bounds for type 'int \\\[1\\\]'" } */

Marek

Re: [PATCH, AArch64] [4.8] [4.9] Backport PR64304 fix (miscompilation with -mgeneral-regs-only )

[Marcus Shawcroft]

Picking up this old back port request...


On 5 March 2015 at 06:36, Chen Shanyao  wrote:

> +2015-03-05  Shanyao Chen

There should be two spaces after the date and two before the < marker
in a ChangeLog name line.  This comment applies to each of the
ChangeLogs presented.

> +/* { dg-final { cleanup-saved-temps } } */
> +

An additional line appears to have been inserted at the end of this
test case. I would have expected the test case to be identical to the
one committed on trunk.

By convention we only post one patch per email to gcc-patches.  Please
fix the comments above and re-post in separate emails for each patch.

Thanks /Marcus

[patch] libstdc++/64657 support iterators with overloaded comma operator

[Jonathan Wakely]

I think this covers all the places in the library where we do:

 ++i, ++j

Tested powerpc64le-linux, committed to trunk.
commit 572881116b98ee50027dbd5e8880ea6d92e86cca
Author: Jonathan Wakely 
Date:   Sun Jan 18 17:04:10 2015 +

	PR libstdc++/64657
	* include/bits/basic_string (basic_string::_S_copy_chars): Cast
	expression to void.
	* include/bits/locale_facets_nonio.tcc (money_get::_M_extract,
	time_get::_M_extract_num, time_get::_M_extract_name,
	time_get::_M_extract_wday_or_month): Likewise.
	* include/bits/stl_algo.h (__includes, __replace_copy_if,
	__is_sorted_until, __is_permutation, transform): Likewise.
	* include/bits/stl_algobase.h (swap_ranges, __copy_move::__copy_m,
	__equal::equal, __lexicographical_compare_impl, equal): Likewise.
	* include/bits/stl_numeric.h (inner_product): Likewise.
	* include/bits/stl_uninitialized.h (__uninitialized_copy_a): Likewise.
	* testsuite/util/testsuite_iterators.h (output_iterator_wrapper,
	input_iterator_wrapper): Declare unusable comma operator.
	* testsuite/21_strings/basic_string/cons/char/64657.cc: New.
	* testsuite/21_strings/basic_string/modifiers/assign/char/64657.cc:
	New.

diff --git a/libstdc++-v3/include/bits/basic_string.h b/libstdc++-v3/include/bits/basic_string.h
index 3b2603f..3e3eef4 100644
--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -324,7 +324,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
 _S_copy_chars(_CharT* __p, _Iterator __k1, _Iterator __k2)
 	_GLIBCXX_NOEXCEPT
 {
-	  for (; __k1 != __k2; ++__k1, ++__p)
+	  for (; __k1 != __k2; ++__k1, (void)++__p)
 	traits_type::assign(*__p, *__k1); // These types are off.
 	}
 
@@ -2779,7 +2779,7 @@ _GLIBCXX_END_NAMESPACE_CXX11
 _S_copy_chars(_CharT* __p, _Iterator __k1, _Iterator __k2)
 	_GLIBCXX_NOEXCEPT
 {
-	  for (; __k1 != __k2; ++__k1, ++__p)
+	  for (; __k1 != __k2; ++__k1, (void)++__p)
 	traits_type::assign(*__p, *__k1); // These types are off.
 	}
 
diff --git a/libstdc++-v3/include/bits/locale_facets_nonio.tcc b/libstdc++-v3/include/bits/locale_facets_nonio.tcc
index 188d07b..2e73b5d 100644
--- a/libstdc++-v3/include/bits/locale_facets_nonio.tcc
+++ b/libstdc++-v3/include/bits/locale_facets_nonio.tcc
@@ -202,7 +202,7 @@ _GLIBCXX_BEGIN_NAMESPACE_LDBL_OR_CXX11
 		size_type __j = 0;
 		for (; __beg != __end && __j < __len
 			   && *__beg == __lc->_M_curr_symbol[__j];
-			 ++__beg, ++__j);
+			 ++__beg, (void)++__j);
 		if (__j != __len
 			&& (__j || __io.flags() & ios_base::showbase))
 		  __testvalid = false;
@@ -298,7 +298,7 @@ _GLIBCXX_BEGIN_NAMESPACE_LDBL_OR_CXX11
 	 : __lc->_M_positive_sign;
 	size_type __i = 1;
 	for (; __beg != __end && __i < __sign_size
-		   && *__beg == __sign[__i]; ++__beg, ++__i);
+		   && *__beg == __sign[__i]; ++__beg, (void)++__i);
 	
 	if (__i != __sign_size)
 	  __testvalid = false;
@@ -858,7 +858,7 @@ _GLIBCXX_END_NAMESPACE_LDBL_OR_CXX11
   ++__min;
   size_t __i = 0;
   int __value = 0;
-  for (; __beg != __end && __i < __len; ++__beg, ++__i)
+  for (; __beg != __end && __i < __len; ++__beg, (void)++__i)
 	{
 	  const char __c = __ctype.narrow(*__beg, '*');
 	  if (__c >= '0' && __c <= '9')
@@ -923,7 +923,8 @@ _GLIBCXX_END_NAMESPACE_LDBL_OR_CXX11
 	  for (size_t __i2 = 1; __i2 < __nmatches; ++__i2)
 	__minlen = std::min(__minlen,
 			  __traits_type::length(__names[__matches[__i2]]));
-	  ++__beg, ++__pos;
+	  ++__beg;
+	  ++__pos;
 	  if (__pos < __minlen && __beg != __end)
 	for (size_t __i3 = 0; __i3 < __nmatches;)
 	  {
@@ -940,11 +941,12 @@ _GLIBCXX_END_NAMESPACE_LDBL_OR_CXX11
   if (__nmatches == 1)
 	{
 	  // Make sure found name is completely extracted.
-	  ++__beg, ++__pos;
+	  ++__beg;
+	  ++__pos;
 	  __name = __names[__matches[0]];
 	  const size_t __len = __traits_type::length(__name);
 	  while (__pos < __len && __beg != __end && __name[__pos] == *__beg)
-	++__beg, ++__pos;
+	++__beg, (void)++__pos;
 
 	  if (__len == __pos)
 	__member = __matches[0];
@@ -987,7 +989,8 @@ _GLIBCXX_END_NAMESPACE_LDBL_OR_CXX11
 
   if (__nmatches)
 	{
-	  ++__beg, ++__pos;
+	  ++__beg;
+	  ++__pos;
 
 	  __matches_lengths
 	= static_cast(__builtin_alloca(sizeof(size_t)
@@ -997,7 +1000,7 @@ _GLIBCXX_END_NAMESPACE_LDBL_OR_CXX11
 	  = __traits_type::length(__names[__matches[__i]]);
 	}
 
-  for (; __beg != __end; ++__beg, ++__pos)
+  for (; __beg != __end; ++__beg, (void)++__pos)
 	{
 	  size_t __nskipped = 0;
 	  const char_type __c = *__beg;
diff --git a/libstdc++-v3/include/bits/stl_algo.h b/libstdc++-v3/include/bits/stl_algo.h
index 56cc743..93e834a 100644
--- a/libstdc++-v3/include/bits/stl_algo.h
+++ b/libstdc++-v3/include/bits/stl_algo.h
@@ -2805,7 +2805,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 	else if (__comp(__first1, __first2))
 	  ++__first1;
 	else
-	  +

Re: Fix librayr name of __builtin_allocal_with_align

[Sandra Loosemore]

On 04/28/2015 08:22 PM, Jan Hubicka wrote:


I also looked into extend.texi and both __builtin_alloca and 
__builtin_alloca_with_align
is missing (along with many other builtins) which is probably quite bad omission
(__builtin_alloca_with_align is used at some places, i.e. in Firefox)

Sandra, since you d oreat job on updating the docs recently, perhaps this could
get at your radar?


H.  I have quite a lot of other stuff in my queue at the moment 
(including a bunch of nios2 patches, not just documentation work) and I 
might forget about this before I have time to work on it.  I'd encourage 
people who notice omissions in the manual to take a stab at fixing it 
themselves.  Alternatively, you could file PRs for documentation bugs, 
or maybe we should have a documentation improvements section on the wiki 
so that people besides me who have time/interest could find chunks of 
the backlog to chip away at.


-Sandra

Re: [Patch, fortran, PR44672, v4] [F08] ALLOCATE with SOURCE and no array-spec

[Andre Vehreschild]

Hi all,

this is the fourth version of the patch, adapting to the current state of
trunk. This patch is based on my patch for 65584 version 2 and needs that patch
applied beforehand to apply cleanly. The patch for 65548 is available from:

https://gcc.gnu.org/ml/fortran/2015-04/msg00121.html

Scope:

Allow allocate of arrays w/o having to give an array-spec as specified in
F2008:C633. An example is:

integer, dimension(:) :: arr
allocate(arr, source = [1,2,3])

Solution:

While resolving an allocate, the objects to allocate are analyzed whether they
carry an array-spec, if not the array-spec of the source=-expression is
transferred. Unfortunately some source=-expressions are not easy to handle and
have to be assigned to a temporary variable first. Only with the temporary
variable the gfc_trans_allocate() is then able to compute the array descriptor
correctly and allocate with correct array bounds.

Side notes:

This patch creates a regression in alloc_comp_constructor_1.f90 where two
free()'s are gone missing. This will be fixed by the patch for pr58586 and
therefore not repeated here.

Bootstraps and regtests ok on x86_64-linux-gnu/f21.

Ok for trunk?

Regards,
Andre

-- 
Andre Vehreschild * Email: vehre ad gmx dot de 


pr44672_4.clog
Description: Binary data
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 832a6ce..9b5f4cf 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -2394,6 +2394,9 @@ typedef struct gfc_code
 {
   gfc_typespec ts;
   gfc_alloc *list;
+  /* Take the array specification from expr3 to allocate arrays
+	 without an explicit array specification.  */
+  unsigned arr_spec_from_expr3:1;
 }
 alloc;
 
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 316b413..41b128a 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -6804,7 +6804,7 @@ conformable_arrays (gfc_expr *e1, gfc_expr *e2)
have a trailing array reference that gives the size of the array.  */
 
 static bool
-resolve_allocate_expr (gfc_expr *e, gfc_code *code)
+resolve_allocate_expr (gfc_expr *e, gfc_code *code, bool *array_alloc_wo_spec)
 {
   int i, pointer, allocatable, dimension, is_abstract;
   int codimension;
@@ -7103,13 +7103,24 @@ resolve_allocate_expr (gfc_expr *e, gfc_code *code)
   if (!ref2 || ref2->type != REF_ARRAY || ref2->u.ar.type == AR_FULL
   || (dimension && ref2->u.ar.dimen == 0))
 {
-  gfc_error ("Array specification required in ALLOCATE statement "
-		 "at %L", &e->where);
-  goto failure;
+  /* F08:C633.  */
+  if (code->expr3)
+	{
+	  if (!gfc_notify_std (GFC_STD_F2008, "Array specification required "
+			   "in ALLOCATE statement at %L", &e->where))
+	goto failure;
+	  *array_alloc_wo_spec = true;
+	}
+  else
+	{
+	  gfc_error ("Array specification required in ALLOCATE statement "
+		 "at %L", &e->where);
+	  goto failure;
+	}
 }
 
   /* Make sure that the array section reference makes sense in the
-context of an ALLOCATE specification.  */
+ context of an ALLOCATE specification.  */
 
   ar = &ref2->u.ar;
 
@@ -7124,7 +7135,7 @@ resolve_allocate_expr (gfc_expr *e, gfc_code *code)
 
   for (i = 0; i < ar->dimen; i++)
 {
-  if (ref2->u.ar.type == AR_ELEMENT)
+  if (ar->type == AR_ELEMENT || ar->type == AR_FULL)
 	goto check_symbols;
 
   switch (ar->dimen_type[i])
@@ -7201,12 +7212,18 @@ failure:
   return false;
 }
 
+
 static void
 resolve_allocate_deallocate (gfc_code *code, const char *fcn)
 {
   gfc_expr *stat, *errmsg, *pe, *qe;
   gfc_alloc *a, *p, *q;
 
+  /* When this flag is set already, then this allocate has already been
+ resolved.  Doing so again, would result in an endless loop.  */
+  if (code->ext.alloc.arr_spec_from_expr3)
+return;
+
   stat = code->expr1;
   errmsg = code->expr2;
 
@@ -7375,8 +7392,96 @@ resolve_allocate_deallocate (gfc_code *code, const char *fcn)
 
   if (strcmp (fcn, "ALLOCATE") == 0)
 {
+  bool arr_alloc_wo_spec = false;
   for (a = code->ext.alloc.list; a; a = a->next)
-	resolve_allocate_expr (a->expr, code);
+	resolve_allocate_expr (a->expr, code, &arr_alloc_wo_spec);
+
+  if (arr_alloc_wo_spec && code->expr3)
+	{
+	  /* Mark the allocate to have to take the array specification
+	 from the expr3.  */
+	  code->ext.alloc.arr_spec_from_expr3 = 1;
+
+	  if (code->expr3->expr_type == EXPR_ARRAY
+	  || code->expr3->expr_type == EXPR_FUNCTION)
+	{
+	  /* The trans stage can not cope with expr3->expr_type
+		 being EXPR_ARRAY or EXPR_FUNCTION, therefore create a
+		 temporary variable and assign expr3 to it, substituting
+		 the variable in expr3.  */
+	  char name[25];
+	  static unsigned int alloc_sym_count = 0;
+	  gfc_symbol *temp_var_sym;
+	  gfc_expr *temp_var;
+	  gfc_code *ass, *old_alloc;
+	  gfc_namespace *ns = code->ext.alloc.list->expr->symtree->n.sym->ns;
+	  gfc_array_spec *as;
+	  int dim;
+	  mpz_t dim_size;
+
+

Re: OMP_CLAUSES with clauses in operand 0

[Jakub Jelinek]

On Wed, Apr 29, 2015 at 05:25:39PM +0200, Thomas Schwinge wrote:
> Done.  (I also reverted the gcc/cp/pt.c:tsubst_expr change which
> motivated this patch; will include that with the patch adding support for
> C++ templates usage with OpenACC directives.)  OK for trunk?

Ok, thanks.

Jakub

Re: OMP_CLAUSES with clauses in operand 0

[Thomas Schwinge]

Hi Jakub!

On Wed, 29 Apr 2015 16:36:24 +0200, Jakub Jelinek  wrote:
> On Wed, Apr 29, 2015 at 04:31:32PM +0200, Thomas Schwinge wrote:
> > > So yes, I really prefer OMP_STANDALONE_CLAUSES over OMP_CLAUSES for
> > > everything.
> > 
> > Like this (for trunk)?
> > 
> > commit 300e28fce192cb56d73cb61f787872643030f0bf
> > Author: Thomas Schwinge 
> > Date:   Wed Apr 29 16:18:49 2015 +0200
> > 
> > Add OMP_STANDALONE_CLAUSES.
> > 
> > gcc/
> > * tree.h (OACC_CACHE_CLAUSES, OACC_DECLARE_CLAUSES)
> > (OACC_ENTER_DATA_CLAUSES, OACC_EXIT_DATA_CLAUSES)
> > (OACC_UPDATE_CLAUSES, OMP_TARGET_UPDATE_CLAUSES): Merge into...
> > (OMP_STANDALONE_CLAUSES): ... this new macro.  Adjust all users.
> 
> I would keep the specific *_CLAUSES macros, just add
> OMP_STANDALONE_CLAUSES and change the uses only if you are dealing with
> multiple different codes.  That will match OMP_CLAUSES vs. OMP_FOR_CLAUSES,
> OMP_PARALLEL_CLAUSES etc.

My (non-explicit) rationale has been:

> > --- gcc/c/c-parser.c
> > +++ gcc/c/c-parser.c
> > @@ -11987,7 +11987,7 @@ c_parser_oacc_cache (location_t loc, c_parser 
> > *parser)
> >  
> >stmt = make_node (OACC_CACHE);

We have just created a OACC_CACHE node here...

> >TREE_TYPE (stmt) = void_type_node;
> > -  OACC_CACHE_CLAUSES (stmt) = clauses;
> > +  OMP_STANDALONE_CLAUSES (stmt) = clauses;

..., so there is no point in checking here that we're indeed dealing
specifically with an OACC_CACHE node.

> So, drop hunks like this.
> 
> > @@ -12155,10 +12155,7 @@ c_parser_oacc_enter_exit_data (c_parser *parser, 
> > bool enter)
> >  
> >stmt = enter ? make_node (OACC_ENTER_DATA) : make_node (OACC_EXIT_DATA);
> >TREE_TYPE (stmt) = void_type_node;
> > -  if (enter)
> > -OACC_ENTER_DATA_CLAUSES (stmt) = clauses;
> > -  else
> > -OACC_EXIT_DATA_CLAUSES (stmt) = clauses;
> > +  OMP_STANDALONE_CLAUSES (stmt) = clauses;
> >SET_EXPR_LOCATION (stmt, loc);
> >add_stmt (stmt);
> >  }
> 
> And just keep ones like this.

Done.  (I also reverted the gcc/cp/pt.c:tsubst_expr change which
motivated this patch; will include that with the patch adding support for
C++ templates usage with OpenACC directives.)  OK for trunk?

commit 82e588b6d62f9e7254e76a3dfcc46efceb2075a5
Author: Thomas Schwinge 
Date:   Wed Apr 29 17:08:17 2015 +0200

Add OMP_STANDALONE_CLAUSES.

gcc/
* tree.h (OMP_STANDALONE_CLAUSES): New macro.
* gimplify.c (gimplify_omp_workshare): Use it.
gcc/c/
* c-parser.c (c_parser_oacc_enter_exit_data): Use
OMP_STANDALONE_CLAUSES.
gcc/cp/
* parser.c (cp_parser_oacc_enter_exit_data): Use
OMP_STANDALONE_CLAUSES.
---
 gcc/c/c-parser.c |5 +
 gcc/cp/parser.c  |5 +
 gcc/gimplify.c   |   13 +
 gcc/tree.h   |6 ++
 4 files changed, 13 insertions(+), 16 deletions(-)

diff --git gcc/c/c-parser.c gcc/c/c-parser.c
index f5e2ac2c..015de7f 100644
--- gcc/c/c-parser.c
+++ gcc/c/c-parser.c
@@ -12155,10 +12155,7 @@ c_parser_oacc_enter_exit_data (c_parser *parser, bool 
enter)
 
   stmt = enter ? make_node (OACC_ENTER_DATA) : make_node (OACC_EXIT_DATA);
   TREE_TYPE (stmt) = void_type_node;
-  if (enter)
-OACC_ENTER_DATA_CLAUSES (stmt) = clauses;
-  else
-OACC_EXIT_DATA_CLAUSES (stmt) = clauses;
+  OMP_STANDALONE_CLAUSES (stmt) = clauses;
   SET_EXPR_LOCATION (stmt, loc);
   add_stmt (stmt);
 }
diff --git gcc/cp/parser.c gcc/cp/parser.c
index 4ea2ca2..cfb512b 100644
--- gcc/cp/parser.c
+++ gcc/cp/parser.c
@@ -31606,10 +31606,7 @@ cp_parser_oacc_enter_exit_data (cp_parser *parser, 
cp_token *pragma_tok,
 
   stmt = enter ? make_node (OACC_ENTER_DATA) : make_node (OACC_EXIT_DATA);
   TREE_TYPE (stmt) = void_type_node;
-  if (enter)
-OACC_ENTER_DATA_CLAUSES (stmt) = clauses;
-  else
-OACC_EXIT_DATA_CLAUSES (stmt) = clauses;
+  OMP_STANDALONE_CLAUSES (stmt) = clauses;
   SET_EXPR_LOCATION (stmt, pragma_tok->location);
   add_stmt (stmt);
   return stmt;
diff --git gcc/gimplify.c gcc/gimplify.c
index c68bd47..bda62ce 100644
--- gcc/gimplify.c
+++ gcc/gimplify.c
@@ -7427,34 +7427,31 @@ gimplify_omp_workshare (tree *expr_p, gimple_seq *pre_p)
 static void
 gimplify_omp_target_update (tree *expr_p, gimple_seq *pre_p)
 {
-  tree expr = *expr_p, clauses;
+  tree expr = *expr_p;
   int kind;
   gomp_target *stmt;
 
   switch (TREE_CODE (expr))
 {
 case OACC_ENTER_DATA:
-  clauses = OACC_ENTER_DATA_CLAUSES (expr);
   kind = GF_OMP_TARGET_KIND_OACC_ENTER_EXIT_DATA;
   break;
 case OACC_EXIT_DATA:
-  clauses = OACC_EXIT_DATA_CLAUSES (expr);
   kind = GF_OMP_TARGET_KIND_OACC_ENTER_EXIT_DATA;
   break;
 case OACC_UPDATE:
-  clauses = OACC_UPDATE_CLAUSES (expr);
   kind = GF_OMP_TARGET_KIND_OACC_UPDATE;
   break;
 case OMP_TARGET_UPDATE:
-  clauses = OMP_TARGET_UPDATE_CLAUSES (expr);
   kind = GF_OMP_TARGET_KIND_UPDATE;
   break;
 default:
   

Re: OMP_CLAUSES with clauses in operand 0

[Thomas Schwinge]

Hi!

On Wed, 29 Apr 2015 17:28:54 +0200, Jakub Jelinek  wrote:
> On Wed, Apr 29, 2015 at 05:25:39PM +0200, Thomas Schwinge wrote:
> > Done.  (I also reverted the gcc/cp/pt.c:tsubst_expr change which
> > motivated this patch; will include that with the patch adding support for
> > C++ templates usage with OpenACC directives.)  OK for trunk?
> 
> Ok, thanks.

Committed in r222580:

commit 95cfd3918aef02196f24de30a1e7cbd34e45e827
Author: tschwinge 
Date:   Wed Apr 29 15:44:41 2015 +

Add OMP_STANDALONE_CLAUSES.

gcc/
* tree.h (OMP_STANDALONE_CLAUSES): New macro.
* gimplify.c (gimplify_omp_workshare): Use it.
gcc/c/
* c-parser.c (c_parser_oacc_enter_exit_data): Use
OMP_STANDALONE_CLAUSES.
gcc/cp/
* parser.c (cp_parser_oacc_enter_exit_data): Use
OMP_STANDALONE_CLAUSES.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@222580 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog|5 +
 gcc/c/ChangeLog  |5 +
 gcc/c/c-parser.c |5 +
 gcc/cp/ChangeLog |5 +
 gcc/cp/parser.c  |5 +
 gcc/gimplify.c   |   13 +
 gcc/tree.h   |6 ++
 7 files changed, 28 insertions(+), 16 deletions(-)

diff --git gcc/ChangeLog gcc/ChangeLog
index 4fb5490..11cb62a 100644
--- gcc/ChangeLog
+++ gcc/ChangeLog
@@ -1,3 +1,8 @@
+2015-04-29  Thomas Schwinge  
+
+   * tree.h (OMP_STANDALONE_CLAUSES): New macro.
+   * gimplify.c (gimplify_omp_workshare): Use it.
+
 2015-04-29  Richard Sandiford  
 
* Makefile.in (build/genrecog.o): Depend on inchash.h.
diff --git gcc/c/ChangeLog gcc/c/ChangeLog
index 9c769ca..6d8dbb1 100644
--- gcc/c/ChangeLog
+++ gcc/c/ChangeLog
@@ -1,3 +1,8 @@
+2015-04-29  Thomas Schwinge  
+
+   * c-parser.c (c_parser_oacc_enter_exit_data): Use
+   OMP_STANDALONE_CLAUSES.
+
 2015-04-28  Marek Polacek  
 
* c-parser.c (c_parser_binary_expression): Remove duplicate line.
diff --git gcc/c/c-parser.c gcc/c/c-parser.c
index cc8a4e3..bf0e4c57 100644
--- gcc/c/c-parser.c
+++ gcc/c/c-parser.c
@@ -12154,10 +12154,7 @@ c_parser_oacc_enter_exit_data (c_parser *parser, bool 
enter)
 
   stmt = enter ? make_node (OACC_ENTER_DATA) : make_node (OACC_EXIT_DATA);
   TREE_TYPE (stmt) = void_type_node;
-  if (enter)
-OACC_ENTER_DATA_CLAUSES (stmt) = clauses;
-  else
-OACC_EXIT_DATA_CLAUSES (stmt) = clauses;
+  OMP_STANDALONE_CLAUSES (stmt) = clauses;
   SET_EXPR_LOCATION (stmt, loc);
   add_stmt (stmt);
 }
diff --git gcc/cp/ChangeLog gcc/cp/ChangeLog
index 3ee050c..9442faa 100644
--- gcc/cp/ChangeLog
+++ gcc/cp/ChangeLog
@@ -1,3 +1,8 @@
+2015-04-29  Thomas Schwinge  
+
+   * parser.c (cp_parser_oacc_enter_exit_data): Use
+   OMP_STANDALONE_CLAUSES.
+
 2015-04-29  Paolo Carlini  
 
PR c++/64667
diff --git gcc/cp/parser.c gcc/cp/parser.c
index 4ea2ca2..cfb512b 100644
--- gcc/cp/parser.c
+++ gcc/cp/parser.c
@@ -31606,10 +31606,7 @@ cp_parser_oacc_enter_exit_data (cp_parser *parser, 
cp_token *pragma_tok,
 
   stmt = enter ? make_node (OACC_ENTER_DATA) : make_node (OACC_EXIT_DATA);
   TREE_TYPE (stmt) = void_type_node;
-  if (enter)
-OACC_ENTER_DATA_CLAUSES (stmt) = clauses;
-  else
-OACC_EXIT_DATA_CLAUSES (stmt) = clauses;
+  OMP_STANDALONE_CLAUSES (stmt) = clauses;
   SET_EXPR_LOCATION (stmt, pragma_tok->location);
   add_stmt (stmt);
   return stmt;
diff --git gcc/gimplify.c gcc/gimplify.c
index 1d5341e..9ce3dd9 100644
--- gcc/gimplify.c
+++ gcc/gimplify.c
@@ -7411,34 +7411,31 @@ gimplify_omp_workshare (tree *expr_p, gimple_seq *pre_p)
 static void
 gimplify_omp_target_update (tree *expr_p, gimple_seq *pre_p)
 {
-  tree expr = *expr_p, clauses;
+  tree expr = *expr_p;
   int kind;
   gomp_target *stmt;
 
   switch (TREE_CODE (expr))
 {
 case OACC_ENTER_DATA:
-  clauses = OACC_ENTER_DATA_CLAUSES (expr);
   kind = GF_OMP_TARGET_KIND_OACC_ENTER_EXIT_DATA;
   break;
 case OACC_EXIT_DATA:
-  clauses = OACC_EXIT_DATA_CLAUSES (expr);
   kind = GF_OMP_TARGET_KIND_OACC_ENTER_EXIT_DATA;
   break;
 case OACC_UPDATE:
-  clauses = OACC_UPDATE_CLAUSES (expr);
   kind = GF_OMP_TARGET_KIND_OACC_UPDATE;
   break;
 case OMP_TARGET_UPDATE:
-  clauses = OMP_TARGET_UPDATE_CLAUSES (expr);
   kind = GF_OMP_TARGET_KIND_UPDATE;
   break;
 default:
   gcc_unreachable ();
 }
-  gimplify_scan_omp_clauses (&clauses, pre_p, ORT_WORKSHARE);
-  gimplify_adjust_omp_clauses (pre_p, &clauses);
-  stmt = gimple_build_omp_target (NULL, kind, clauses);
+  gimplify_scan_omp_clauses (&OMP_STANDALONE_CLAUSES (expr), pre_p,
+ORT_WORKSHARE);
+  gimplify_adjust_omp_clauses (pre_p, &OMP_STANDALONE_CLAUSES (expr));
+  stmt = gimple_build_omp_target (NULL, kind, OMP_STANDALONE_CLAUSES (expr));
 
   gimplify_seq_add_stmt (pre_p, stmt);
   *expr_p = NULL_TREE;
diff --git gcc/tree.h gcc/tree.h
index 2ec9708..e17bd9b 100644
--- gcc/tree.h
+++ gcc/tree.h
@@ -1197,11 +1197,17 @

Re: [PATCH] libstdc++: Fix list.cc xmethods test.

[Doug Evans]

On Mon, Apr 27, 2015 at 3:41 PM, Jonathan Wakely  wrote:
> On 27 April 2015 at 23:33, Doug Evans wrote:
>> Hi.
>>
>> While we should eventually get the xmethods to handle cxx11,
>> this patch fixes the current failure.
>> The xmethod matcher doesn't currently handle __cxx11 in the type name.
>>
>> Adding cxx11 support can be a follow up patch.
>
> Agreed. And when that's done we should backport it to the gcc-5-branch too.
>
>> Ok to commit?
>
> OK for trunk, thanks

Tested the same patch on the gcc 5.0 branch.
Just double checking ... ok to apply there too?

btw, the test is currently marked as unsupported by the test run.
I don't know what would be involved in marking it as failing instead,
but I noticed this happening a lot while I was working with this code.
I can imagine more failures going unnoticed because of this.

[PATCH] PR ld/18355: --enable-shared doesn't work

[H.J. Lu]

When bfd is configured as a shared library, we need to configure zlib
with --enable-host-shared since zlib is used by bfd.  Any comments,
feedbacks, objections?


H.J.
--
PR ld/18355
* Makefile.def: Add extra_configure_flags to host zlib.
* configure.ac (extra_host_zlib_configure_flags): New.  Set
to --enable-host-shared When bfd is to be built as shared
library.  AC_SUBST.
* Makefile.in: Regenerated.
* configure: Likewise.
---
 Makefile.def |  4 +++-
 Makefile.in  | 20 +---
 configure| 10 ++
 configure.ac |  9 +
 4 files changed, 35 insertions(+), 8 deletions(-)

diff --git a/Makefile.def b/Makefile.def
index 4e76450..4394188 100644
--- a/Makefile.def
+++ b/Makefile.def
@@ -104,7 +104,9 @@ host_modules= { module= readline; };
 host_modules= { module= sid; };
 host_modules= { module= sim; };
 host_modules= { module= texinfo; no_install= true; };
-host_modules= { module= zlib; no_install=true; no_check=true; bootstrap=true; 
};
+host_modules= { module= zlib; no_install=true; no_check=true;
+   bootstrap=true;
+   extra_configure_flags='@extra_host_zlib_configure_flags@';};
 host_modules= { module= gdb; };
 host_modules= { module= expect; };
 host_modules= { module= guile; };
diff --git a/Makefile.in b/Makefile.in
index cc05f7b..8ae261f 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -26714,7 +26714,7 @@ configure-zlib:
  $$s/$$module_srcdir/configure \
  --srcdir=$${topdir}/$$module_srcdir \
  $(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
- --target=${target_alias}  \
+ --target=${target_alias} @extra_host_zlib_configure_flags@ \
  || exit 1
 @endif zlib
 
@@ -26749,7 +26749,8 @@ configure-stage1-zlib:
  $(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
  --target=${target_alias} \
   \
- $(STAGE1_CONFIGURE_FLAGS)
+ $(STAGE1_CONFIGURE_FLAGS) \
+ @extra_host_zlib_configure_flags@
 @endif zlib-bootstrap
 
 .PHONY: configure-stage2-zlib maybe-configure-stage2-zlib
@@ -26782,7 +26783,8 @@ configure-stage2-zlib:
  $(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
  --target=${target_alias} \
   --with-build-libsubdir=$(HOST_SUBDIR)  \
- $(STAGE2_CONFIGURE_FLAGS)
+ $(STAGE2_CONFIGURE_FLAGS) \
+ @extra_host_zlib_configure_flags@
 @endif zlib-bootstrap
 
 .PHONY: configure-stage3-zlib maybe-configure-stage3-zlib
@@ -26815,7 +26817,8 @@ configure-stage3-zlib:
  $(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
  --target=${target_alias} \
   --with-build-libsubdir=$(HOST_SUBDIR)  \
- $(STAGE3_CONFIGURE_FLAGS)
+ $(STAGE3_CONFIGURE_FLAGS) \
+ @extra_host_zlib_configure_flags@
 @endif zlib-bootstrap
 
 .PHONY: configure-stage4-zlib maybe-configure-stage4-zlib
@@ -26848,7 +26851,8 @@ configure-stage4-zlib:
  $(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
  --target=${target_alias} \
   --with-build-libsubdir=$(HOST_SUBDIR)  \
- $(STAGE4_CONFIGURE_FLAGS)
+ $(STAGE4_CONFIGURE_FLAGS) \
+ @extra_host_zlib_configure_flags@
 @endif zlib-bootstrap
 
 .PHONY: configure-stageprofile-zlib maybe-configure-stageprofile-zlib
@@ -26881,7 +26885,8 @@ configure-stageprofile-zlib:
  $(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
  --target=${target_alias} \
   --with-build-libsubdir=$(HOST_SUBDIR)  \
- $(STAGEprofile_CONFIGURE_FLAGS)
+ $(STAGEprofile_CONFIGURE_FLAGS) \
+ @extra_host_zlib_configure_flags@
 @endif zlib-bootstrap
 
 .PHONY: configure-stagefeedback-zlib maybe-configure-stagefeedback-zlib
@@ -26914,7 +26919,8 @@ configure-stagefeedback-zlib:
  $(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
  --target=${target_alias} \
   --with-build-libsubdir=$(HOST_SUBDIR)  \
- $(STAGEfeedback_CONFIGURE_FLAGS)
+ $(STAGEfeedback_CONFIGURE_FLAGS) \
+ @extra_host_zlib_configure_flags@
 @endif zlib-bootstrap
 
 
diff --git a/configure b/configure
index 97250fa..426eece 100755
--- a/configure
+++ b/configure
@@ -643,6 +643,7 @@ CXXFLAGS_FOR_TARGET
 CFLAGS_FOR_TARGET
 DEBUG_PREFIX_CFLAGS_FOR_TARGET
 SYSROOT_CFLAGS_FOR_TARGET
+extra_host_zlib_configure_flags
 extra_host_libiberty_configure_flags
 stage1_languages
 extra_linker_plugin_flags
@@ -6585,15 +6586,24 @@ fi
 
 # Sometimes we have special requirements for the host libiberty.
 extra_host_libiberty_configure_flags=
+extra_host_zlib_configure_flags=
 case " $configdirs " in
   *" lto-plugin "* | *" libcc1 "*)
 # When these are to be built as shared libraries, the same applies to
 # libiberty.
 extra_host_libiberty_configure_flags=--enable-shared
 ;;
+  *" bfd "*)
+# When bfd is to be built as a shared library, the 

Re: Help needed debugging std::is_convertible problem (PR 65760)

[Jonathan Wakely]

On 17/04/15 01:03 +0200, Daniel Krügler wrote:

2015-04-16 14:33 GMT+02:00 Jonathan Wakely :

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

I don't understand why commenting out *any one* of the lines marked
(1), (2), (3), (4) causes this to compile:

#include 

struct C {
C() = default;

C(std::function);  // (1)
C(std::function); // (2)
template  C operator () (T&&); // (3)
template  C operator () (T&&, T&&); // (4)
};


My current understanding of the state of affairs is still complete in
some details, but let me still throw in my 2 cents: The compiler sees
an object of C constructed by an rvalue of C. Now we have - in
addition to the copy/move constructors - two corresponding pairs of
function call operator and converting constructor to consider. Let me
simplify the situation a bit more by removing the additional layer of
template deduction of the call operators to:

struct C
{
 C() = default;

 C(std::function);  // (1)
 C(std::function); // (2)
 C operator()(int); // (3)
 C operator()(int, int); // (4)
};

In the presence of all four members the compiler is allowed (I think
by [temp.inst] p7) to instantiate one or both of the different
std::function specializations, because it has to respect possible
conversions. When this happens, the converting template constructor
declaration of std::function also needs to be instantiated. While
doing this, we come to the point where within the SFINAE condition
std::is_convertible needs to be instantiated, effectively
leading to a situation that we have two different contexts, in which
the compiler needs to evaluate the result the self-conversion of C, C
never becoming completed to realize that during that attempt.

If *any* of the four members is missing, we don't have the situation
that two conversion sequences based on function template deduction
need to be partially ordered, we have only the non-template copy/move
constructor against exactly one possible function template. For this
to order, the compiler doesn't require instantiation of the converting
constructor of std::function.


[...]


Nonetheless, my understanding of your fix is that it actually is not
conforming to what the standard currently requires (This seems to
match you own thinking expressed above), because [func.wrap.func.con]
p8 requires:

"shall not participate in overload resolution unless f is Callable
(20.9.12.2) for argument types ArgTypes... and return type R."

and if we unroll this against the definition Callable (ending in
[func.require] p2) we finally end up in a required test whether the
return type of the invokable thingee has a value of
std::is_convertible::value == true (C has the role of the return
type R). This is so, *even*, if LWG issue

http://cplusplus.github.io/LWG/lwg-active.html#2420

would be fixed as described, because we have no void return type involved here.

My current position is that we presumably have a Standard Library
issue lurking around, because I see no way how any library can
implement std::function without breaking this seemingly valid example
case. Either the Standard Library needs to express stronger
constraints on the return type R of std::function (so
to make the example invalid), or - what I would currently prefer - the
library would need to reduce the SFINAE constraints of the
std::function template constructor basically ending in not requiring
that R is complete, or in other words: not requiring the final part of
the Callable test involving the implicit conversion of the functor
result to the described result type R of
std::function.

To follow the intention of std::functions design, the Library could
require that when the constructor definition of

template function(F);

becomes instantiated, the current SFINAE requirements are to be
tested, possibly making this definition instantiation ill-formed.

Summarizing this, I consider your suggested resolution as useful for
practical reasons.


While I agree with Daniel that my suggested fix may not be strictly
conforming, I think it is worth doing anyway, so I'm committing it.

Tested powerpc64le-linux, committed to trunk.


commit bc3d6d30fd620ea1d7d286512f983a7a1ddb99c0
Author: Jonathan Wakely 
Date:   Fri Apr 17 13:25:42 2015 +0100

	PR libstdc++/65760
	* include/std/functional (__check_func_return_type): Use is_same to
	avoid using _is_convertible on incomplete types.
	* testsuite/20_util/function/65760.cc: New.

diff --git a/libstdc++-v3/include/std/functional b/libstdc++-v3/include/std/functional
index e9d48e4..946cf63 100644
--- a/libstdc++-v3/include/std/functional
+++ b/libstdc++-v3/include/std/functional
@@ -1962,7 +1962,7 @@ _GLIBCXX_MEM_FN_TRAITS(&&, false_type, true_type)
 
   template
 using __check_func_return_type
-  = __or_, is_convertible<_From, _To>>;
+  = __or_, is_same<_From, _To>, is_convertible<_From, _To>>;
 
   /**
*  @brief Primary class template for std::function.
diff --git a/libstdc++-v3/testsuite/20_util/function/657

Re: [PATCH] libstdc++: Fix list.cc xmethods test.

[Jonathan Wakely]

On 29 April 2015 at 17:04, Doug Evans wrote:
> Tested the same patch on the gcc 5.0 branch.
> Just double checking ... ok to apply there too?

Yes, OK for the branch too.

> btw, the test is currently marked as unsupported by the test run.
> I don't know what would be involved in marking it as failing instead,
> but I noticed this happening a lot while I was working with this code.
> I can imagine more failures going unnoticed because of this.

That's due to:

(*): Shared library is missing debugging information.^M
skipping: (*): Shared library is missing debugging information.^M
list.gdb:10: Error in sourced command file:^M
Cannot evaluate function -- may be inlined^M
skipping: list.gdb:10: Error in sourced command file:^M
skipping: Cannot evaluate function -- may be inlined^M
UNSUPPORTED: libstdc++-xmethods/list.cc

But I can't say anything more useful than that.

Re: [PATCH 6/n] OpenMP 4.0 offloading infrastructure: option handling

[Thomas Schwinge]

Hi!

On Tue, 28 Apr 2015 15:24:08 +0200, Bernd Schmidt  
wrote:
> On 04/27/2015 06:08 PM, Thomas Schwinge wrote:
> 
> >>> OK to do the following instead?  (Coding style/code copied from
> >>> gcc/config/i386/intelmic-mkoffload.c for consistency.)
> 
> Err, was this a question for me? I'm fine with that too.

Yes -- you're the nvptx maintainer after all.  ;-)

Committed in r222583:

commit df615909263269988fd9611f8d007902580829d9
Author: tschwinge 
Date:   Wed Apr 29 16:23:26 2015 +

[PR libgomp/65099] nvptx mkoffload: pass "-m32" or "-m64" to the compiler

... depending on "-foffload-abi=[...]".

Coding style/code copied from gcc/config/i386/intelmic-mkoffload.c for
consistency.

gcc/
* config/nvptx/mkoffload.c (target_ilp32): New variable.
(main): Set it depending on "-foffload-abi=[...]".
(compile_native, main): Use it to pass "-m32" or "-m64" to the
compiler.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@222583 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog|8 
 gcc/config/nvptx/mkoffload.c |   18 +-
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git gcc/ChangeLog gcc/ChangeLog
index aaa06c3..d7455e4 100644
--- gcc/ChangeLog
+++ gcc/ChangeLog
@@ -1,3 +1,11 @@
+2015-04-29  Thomas Schwinge  
+
+   PR libgomp/65099
+   * config/nvptx/mkoffload.c (target_ilp32): New variable.
+   (main): Set it depending on "-foffload-abi=[...]".
+   (compile_native, main): Use it to pass "-m32" or "-m64" to the
+   compiler.
+
 2015-04-29  Alan Lawrence  
 
PR target/65770
diff --git gcc/config/nvptx/mkoffload.c gcc/config/nvptx/mkoffload.c
index dbc68bc..8687154 100644
--- gcc/config/nvptx/mkoffload.c
+++ gcc/config/nvptx/mkoffload.c
@@ -126,6 +126,9 @@ static id_map *var_ids, **vars_tail = &var_ids;
 static const char *ptx_name;
 static const char *ptx_cfile_name;
 
+/* Shows if we should compile binaries for i386 instead of x86-64.  */
+bool target_ilp32 = false;
+
 /* Delete tempfiles.  */
 
 /* Unlink a temporary file unless requested otherwise.  */
@@ -885,6 +888,7 @@ compile_native (const char *infile, const char *outfile, 
const char *compiler)
   struct obstack argv_obstack;
   obstack_init (&argv_obstack);
   obstack_ptr_grow (&argv_obstack, compiler);
+  obstack_ptr_grow (&argv_obstack, target_ilp32 ? "-m32" : "-m64");
   obstack_ptr_grow (&argv_obstack, infile);
   obstack_ptr_grow (&argv_obstack, "-c");
   obstack_ptr_grow (&argv_obstack, "-o");
@@ -962,11 +966,23 @@ main (int argc, char **argv)
  passed with @file.  Expand them into argv before processing.  */
   expandargv (&argc, &argv);
 
+  /* Find out whether we should compile binaries for i386 or x86-64.  */
+  for (int i = argc - 1; i > 0; i--)
+if (strncmp (argv[i], "-foffload-abi=", sizeof ("-foffload-abi=") - 1) == 
0)
+  {
+   if (strstr (argv[i], "ilp32"))
+ target_ilp32 = true;
+   else if (!strstr (argv[i], "lp64"))
+ fatal_error (input_location,
+  "unrecognizable argument of option -foffload-abi");
+   break;
+  }
+
   struct obstack argv_obstack;
   obstack_init (&argv_obstack);
   obstack_ptr_grow (&argv_obstack, driver);
   obstack_ptr_grow (&argv_obstack, "-xlto");
-  obstack_ptr_grow (&argv_obstack, "-m64");
+  obstack_ptr_grow (&argv_obstack, target_ilp32 ? "-m32" : "-m64");
   obstack_ptr_grow (&argv_obstack, "-S");
 
   for (int ix = 1; ix != argc; ix++)


Grüße,
 Thomas


pgp4nQYIGv1oG.pgp
Description: PGP signature

Re: [PATCH] Fix size & type for cold partition names (hot-cold function partitioning)

[Uros Bizjak]

Hello!

> 2015-03-27  Caroline Tice  
>
> * final.c (final_scan_insn): Change 'cold_function_name' to
> 'cold_partition_name' and make it a global variable; also output
> assembly to give it a 'FUNC' type, if appropriate.
> * varasm.c (cold_partition_name): Declare and initialize global
> variable.
> (assemble_start_function): Re-set value for cold_partition_name.
> (assemble_end_function): Output assembly to calculate size of cold
> partition, and associate size with name, if appropriate.
> * varash.h (cold_partition_name): Add extern declaration for global
> variable.
> * testsuite/gcc.dg/tree-prof/cold_partition_label.c: Add dg-final-use
> to scan assembly for cold partition name and size.

This patch caused PR 65929 [1].

Targets are (ab)using ASM_DECLARE_FUNCTION_NAME and
ASM_DECLARE_FUNCTION_SIZE for more things that their name suggests. As
shown in the PR, some directives that are generated through these
macros apply only to real functions, not to parts of function in the
middle of the function.

In the particular case in the PR, assembler doesn't tolerate nested
function declaration.

I suggest to revert the patch for now, until side effects of the patch
are resolved.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65929

Uros.

Re: C PATCH to reject va_arg (ap, void) (PR c/65901)

[Marek Polacek]

On Tue, Apr 28, 2015 at 09:07:09PM -0600, Martin Sebor wrote:
> The error message in the test cases below isn't quite right.
> The type of the aggregates isn't undefined, it's incomplete.
> Looking at the function, I wonder if the first argument
> should be EXPR rather than than NULL_TREE? Alternatively,
> experimenting with other cases where GCC diagnoses invalid
> uses of incomplete type, I see that it issues:
> 
>   "invalid application of %qs to incomplete type %qT"
> 
> which might work even better here since we could name the
> expression (va_arg).

Yeah, I haven't concerned myself with the exact wording of the error
message much, and I agree it could be improved.  But passing down the
EXPR would mean that the compiler outputs "'ap' has an incomplete type"
and that looks wrong as well.  I think I'm going to apply the following
tomorrow if I hear no objections (and it passes testing).  Thanks for noticing.

(And I think c_incomplete_type_error deserves some TLC; I'll post a separate
patch.)

2015-04-29  Marek Polacek  

* c-typeck.c (c_build_va_arg): Clarify the error message.

* gcc.dg/pr65901.c (foo): Adjust dg-error.

diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
index c58e918..028d2f81 100644
--- gcc/c/c-typeck.c
+++ gcc/c/c-typeck.c
@@ -12645,14 +12645,17 @@ c_build_qualified_type (tree type, int type_quals)
 tree
 c_build_va_arg (location_t loc, tree expr, tree type)
 {
-  if (warn_cxx_compat && TREE_CODE (type) == ENUMERAL_TYPE)
-warning_at (loc, OPT_Wc___compat,
-   "C++ requires promoted type, not enum type, in %");
-  if (type == error_mark_node || !COMPLETE_TYPE_P (type))
+  if (error_operand_p (type))
+return error_mark_node;
+  else if (!COMPLETE_TYPE_P (type))
 {
-  c_incomplete_type_error (NULL_TREE, type);
+  error_at (loc, "second argument to % is of incomplete "
+   "type %qT", type);
   return error_mark_node;
 }
+  else if (warn_cxx_compat && TREE_CODE (type) == ENUMERAL_TYPE)
+warning_at (loc, OPT_Wc___compat,
+   "C++ requires promoted type, not enum type, in %");
   return build_va_arg (loc, expr, type);
 }
 
diff --git gcc/testsuite/gcc.dg/pr65901.c gcc/testsuite/gcc.dg/pr65901.c
index 8708a1e..b40eea3 100644
--- gcc/testsuite/gcc.dg/pr65901.c
+++ gcc/testsuite/gcc.dg/pr65901.c
@@ -9,8 +9,8 @@ union U;
 void
 foo (__builtin_va_list ap)
 {
-  __builtin_va_arg (ap, void);  /* { dg-error "invalid use of void expression" 
} */
-  __builtin_va_arg (ap, struct S);  /* { dg-error "invalid use of undefined 
type" } */
-  __builtin_va_arg (ap, enum E);  /* { dg-error "invalid use of undefined 
type" } */
-  __builtin_va_arg (ap, union U);  /* { dg-error "invalid use of undefined 
type" } */
+  __builtin_va_arg (ap, void);  /* { dg-error "second argument to .va_arg. is 
of incomplete type .void." } */
+  __builtin_va_arg (ap, struct S);  /* { dg-error "second argument to .va_arg. 
is of incomplete type .struct S." } */
+  __builtin_va_arg (ap, enum E);  /* { dg-error "second argument to .va_arg. 
is of incomplete type .enum E." } */
+  __builtin_va_arg (ap, union U);  /* { dg-error "second argument to .va_arg. 
is of incomplete type .union U." } */
 }

Marek

[debug-early] adjust tests for new defined/used warnings

[Aldy Hernandez]

This fixes the remaining regressions.  With the new design for 
check_global_declaration*(), we diagnose many more warnings and so far, 
no false positives.


Committed to branch.
commit 7aeb35184b29f3c67470b63fcf107b54f075ffd7
Author: Aldy Hernandez 
Date:   Wed Apr 29 09:43:48 2015 -0700

Adjust tests with defined/used warnings.

diff --git a/gcc/objc/objc-gnu-runtime-abi-01.c 
b/gcc/objc/objc-gnu-runtime-abi-01.c
index b096fb9..cdf77b2 100644
--- a/gcc/objc/objc-gnu-runtime-abi-01.c
+++ b/gcc/objc/objc-gnu-runtime-abi-01.c
@@ -500,6 +500,8 @@ build_selector_table_decl (void)
   temp = build_array_type (objc_selector_template, NULL_TREE);
 
   UOBJC_SELECTOR_TABLE_decl = start_var_decl (temp, "_OBJC_SELECTOR_TABLE");
+  /* Squash `defined but not used' warning check_global_declaration.  */
+  TREE_USED (UOBJC_SELECTOR_TABLE_decl) = 1;
   OBJCMETA (UOBJC_SELECTOR_TABLE_decl, objc_meta, meta_base);
 }
 
diff --git a/gcc/testsuite/g++.dg/torture/pr46383.C 
b/gcc/testsuite/g++.dg/torture/pr46383.C
index 2b61039..e4810c5 100644
--- a/gcc/testsuite/g++.dg/torture/pr46383.C
+++ b/gcc/testsuite/g++.dg/torture/pr46383.C
@@ -69,9 +69,9 @@ template < class Tr, class Derived, class Element, class 
Previous, class Triangu
   Mesher_level(Previous_level& previous)
 : previous_level(previous)
   { }
-  Vertex_handle insert(Point p, Zone& z) ;
-  Zone conflicts_zone(const Point& p, Element e) ;
-  Element get_next_element() ;
+  Vertex_handle insert(Point p, Zone& z) ; // { dg-warning "used but never 
defined" }
+  Zone conflicts_zone(const Point& p, Element e) ; // { dg-warning "used but 
never defined" }
+  Element get_next_element() ; // { dg-warning "used but never defined" }
   template  void before_insertion(Element& e, const Point& 
p, Zone& zone, Mesh_visitor visitor) {
 visitor.before_insertion(e, p, zone);
   }
@@ -171,7 +171,7 @@ template  struct 
Triangulation_mesher_level_traits_3
   tr.is_infinite(f) ;
   new_facet(f);
 }
-template  void 
new_facet (const Facet& f) ;
+template  void 
new_facet (const Facet& f) ; // { dg-warning "used but never defined" }
 void after_insertion_handle_opposite_facet (const Facet& f) {
   after_insertion_handle_incident_facet (f);
 }
diff --git a/gcc/testsuite/gfortran.dg/intent_out_8.f90 
b/gcc/testsuite/gfortran.dg/intent_out_8.f90
index 674d833..6360314 100644
--- a/gcc/testsuite/gfortran.dg/intent_out_8.f90
+++ b/gcc/testsuite/gfortran.dg/intent_out_8.f90
@@ -10,7 +10,7 @@ end type t
 
 contains
 
-  subroutine foo(x)
+  subroutine foo(x) ! { dg-warning "defined but not used" }
 type(t), intent(out) :: x
   end subroutine
 
diff --git a/gcc/testsuite/gfortran.dg/warn_target_lifetime_3.f90 
b/gcc/testsuite/gfortran.dg/warn_target_lifetime_3.f90
index 9113a88..749f987 100644
--- a/gcc/testsuite/gfortran.dg/warn_target_lifetime_3.f90
+++ b/gcc/testsuite/gfortran.dg/warn_target_lifetime_3.f90
@@ -10,7 +10,7 @@ subroutine test
   integer, target :: t
   p => t
 contains
-  subroutine sub()
+  subroutine sub() ! { dg-warning "defined but not used" }
 if (p /= 0) return
   end subroutine
 end subroutine
@@ -22,7 +22,7 @@ contains
 integer, target :: t2
 p2 => t2 ! { dg-warning "Pointer at .1. in pointer assignment might 
outlive the pointer target" }
   contains
-subroutine sub()
+subroutine sub() ! { dg-warning "defined but not used" }
   if (p2 /= 0) return
 end subroutine
   end subroutine
diff --git a/gcc/toplev.c b/gcc/toplev.c
index 43e1577..3155595 100644
--- a/gcc/toplev.c
+++ b/gcc/toplev.c
@@ -505,6 +505,8 @@ wrapup_global_declarations (tree *vec, int len)
 void
 check_global_declaration (tree decl)
 {
+  // ?? Perhaps we should avoid all DECL_ARTIFICIALs here?
+
   /* Warn about any function declared static but not defined.  We don't
  warn about variables, because many programs have static variables
  that exist only to get some text into the object file.  */

[PATCH] Use consistent naming in libstdcxx/v6/xmethods.py

[Doug Evans]

Hi.

This patch splits out from the patch for 65839 the consistent naming
suggested here.
https://gcc.gnu.org/ml/libstdc++/2015-04/msg00155.html

Regression tested on amd64-linux.

Ok to commit?

2015-04-29  Doug Evans  

Use consistent naming for value type attributes.
* python/libstdcxx/v6/xmethods.py (ArrayWorkerBase): Rename _valtype
to _val_type.
(ArraySizeWorker, ArrayEmptyWorker): Ditto.
(ArrayFrontWorker, ArrayBackWorker): Ditto.
(ArrayAtWorker, ArraySubscriptWorker): Ditto.
(DequeWorkerBase): Rename elemtype to val_type.
(ForwardListWorkerBase): Rename _elem_type to _val_type.
(ForwardListFrontWorker): Ditto.  And rename elem_address to
val_address.
(ForwardListMethodsMatcher): Rename elem_type to val_type.
(VectorWorkerBase): Rename _elemtype to _val_type.

Index: xmethods.py
===
--- xmethods.py (revision 222551)
+++ xmethods.py (working copy)
@@ -29,17 +29,17 @@ class LibStdCxxXMethod(gdb.xmethod.XMethod):
 # Xmethods for std::array
 
 class ArrayWorkerBase(gdb.xmethod.XMethodWorker):
-def __init__(self, valtype, size):
-self._valtype = valtype
+def __init__(self, val_type, size):
+self._val_type = val_type
 self._size = size
 
 def null_value(self):
 nullptr = gdb.parse_and_eval('(void *) 0')
-return nullptr.cast(self._valtype.pointer()).dereference()
+return nullptr.cast(self._val_type.pointer()).dereference()
 
 class ArraySizeWorker(ArrayWorkerBase):
-def __init__(self, valtype, size):
-ArrayWorkerBase.__init__(self, valtype, size)
+def __init__(self, val_type, size):
+ArrayWorkerBase.__init__(self, val_type, size)
 
 def get_arg_types(self):
 return None
@@ -48,8 +48,8 @@ class ArraySizeWorker(ArrayWorkerBase):
 return self._size
 
 class ArrayEmptyWorker(ArrayWorkerBase):
-def __init__(self, valtype, size):
-ArrayWorkerBase.__init__(self, valtype, size)
+def __init__(self, val_type, size):
+ArrayWorkerBase.__init__(self, val_type, size)
 
 def get_arg_types(self):
 return None
@@ -58,8 +58,8 @@ class ArrayEmptyWorker(ArrayWorkerBase):
 return (int(self._size) == 0)
 
 class ArrayFrontWorker(ArrayWorkerBase):
-def __init__(self, valtype, size):
-ArrayWorkerBase.__init__(self, valtype, size)
+def __init__(self, val_type, size):
+ArrayWorkerBase.__init__(self, val_type, size)
 
 def get_arg_types(self):
 return None
@@ -71,8 +71,8 @@ class ArrayFrontWorker(ArrayWorkerBase):
 return self.null_value()
 
 class ArrayBackWorker(ArrayWorkerBase):
-def __init__(self, valtype, size):
-ArrayWorkerBase.__init__(self, valtype, size)
+def __init__(self, val_type, size):
+ArrayWorkerBase.__init__(self, val_type, size)
 
 def get_arg_types(self):
 return None
@@ -84,8 +84,8 @@ class ArrayBackWorker(ArrayWorkerBase):
 return self.null_value()
 
 class ArrayAtWorker(ArrayWorkerBase):
-def __init__(self, valtype, size):
-ArrayWorkerBase.__init__(self, valtype, size)
+def __init__(self, val_type, size):
+ArrayWorkerBase.__init__(self, val_type, size)
 
 def get_arg_types(self):
 return gdb.lookup_type('std::size_t')
@@ -97,8 +97,8 @@ class ArrayAtWorker(ArrayWorkerBase):
 return obj['_M_elems'][index]
 
 class ArraySubscriptWorker(ArrayWorkerBase):
-def __init__(self, valtype, size):
-ArrayWorkerBase.__init__(self, valtype, size)
+def __init__(self, val_type, size):
+ArrayWorkerBase.__init__(self, val_type, size)
 
 def get_arg_types(self):
 return gdb.lookup_type('std::size_t')
@@ -139,8 +139,8 @@ class ArrayMethodsMatcher(gdb.xmethod.XMethodMatch
 # Xmethods for std::deque
 
 class DequeWorkerBase(gdb.xmethod.XMethodWorker):
-def __init__(self, elemtype):
-self._bufsize = (512 / elemtype.sizeof) or 1
+def __init__(self, val_type):
+self._bufsize = (512 / val_type.sizeof) or 1
 
 def size(self, obj):
 first_node = obj['_M_impl']['_M_start']['_M_node']
@@ -232,8 +232,8 @@ class DequeMethodsMatcher(gdb.xmethod.XMethodMatch
 # Xmethods for std::forward_list
 
 class ForwardListWorkerBase(gdb.xmethod.XMethodMatcher):
-def __init__(self, elem_type, node_type):
-self._elem_type = elem_type
+def __init__(self, val_type, node_type):
+self._val_type = val_type
 self._node_type = node_type
 
 def get_arg_types(self):
@@ -246,8 +246,8 @@ class ForwardListEmptyWorker(ForwardListWorkerBase
 class ForwardListFrontWorker(ForwardListWorkerBase):
 def __call__(self, obj):
 node = obj['_M_impl']['_M_head']['_M_next'].cast(self._node_type)
-elem_address = node['_M_storage']['_M_storage'].address
-return elem_address.cast(self._elem_type.pointer()).derefe

Re: [RFC]: Remove Mem/address type assumption in combiner

[Segher Boessenkool]

Hello Venkat,

On Wed, Apr 29, 2015 at 09:25:21AM +, Kumar, Venkataramanan wrote:
> diff --git a/gcc/combine.c b/gcc/combine.c
> index 5c763b4..945abdb 100644
> --- a/gcc/combine.c
> +++ b/gcc/combine.c
> @@ -7703,8 +7703,6 @@ make_compound_operation (rtx x, enum rtx_code in_code)
>   but once inside, go back to our default of SET.  */
> 
>next_code = (code == MEM ? MEM
> -  : ((code == PLUS || code == MINUS)
> - && SCALAR_INT_MODE_P (mode)) ? MEM
>: ((code == COMPARE || COMPARISON_P (x))
>   && XEXP (x, 1) == const0_rtx) ? COMPARE
>: in_code == COMPARE ? SET : in_code);
> 
> 
> On X86_64, it passes bootstrap and regression tests.
> But on Aarch64 the test in PR passed, but I got a few test case failures.

> There are few patterns based on multiplication operations in Aarch64 backend 
> which are used to match with the pattern combiner generated.
> Now those patterns have to be fixed to use SHIFTS.  Also need to see any 
> impact on other targets.

Right.  It would be good if you could find out for what targets it matters.
The thing is, if a target expects only the patterns as combine used to make
them, it will regress (as you've seen on aarch64); but it will regress
_silently_.  Which isn't so nice.

> But  before that  I wanted to check if the assumption in combiner,  can 
> simply be removed ?

Seeing for what targets / patterns it makes a difference would tell us the
answer to that, too :-)

I'll run some tests with and without your patch.


Segher

Re: [PATCH] Tidy up locking for libgomp OpenACC entry points

[Thomas Schwinge]

Hi Julian!

On Fri, 24 Apr 2015 18:13:08 +0100, Julian Brown  
wrote:
> On Thu, 23 Apr 2015 18:41:34 +0200
> Thomas Schwinge  wrote:
> > On Wed, 22 Apr 2015 19:42:43 +0100, Julian Brown
> >  wrote:
> > > This patch is an attempt to fix some potential race conditions with
> > > accesses to shared data structures from multiple concurrent threads
> > > in libgomp's OpenACC entry points.

> > > Tests look OK (with offloading to NVidia PTX).
> > 
> > How did you test to get some confidence in the locking being
> > sufficient?
> 
> Merely by running the existing tests and via inspection, sadly. I'm not
> sure how much value we'd get from implementing an exhaustive threading
> testsuite at this stage: I guess testcases will be easier to come by in
> the future if/when people start to use e.g. OpenMP and OpenACC together.

;-) The poor person to be the first to actually exercise all that code...

Thanks for your explanations and the rework.

> Re-tested (libgomp), results look OK.
> 
> OK to apply now?

OK, thanks!


Grüße,
 Thomas


pgp6oCMUj9Siy.pgp
Description: PGP signature

Re: [PATCH] Fix size & type for cold partition names (hot-cold function partitioning)

[Caroline Tice]

The attached patch can revert the previous patch, if that is the way
we should proceed on this.  If you want me to apply the reversion,
please let me know.

I would be happy to fix to the problem, rather than just reverting the
patch, but I do not have expertise in assembly language on other
platforms, so I would need some help, if anyone would be interested in
helping me?

-- Caroline Tice
cmt...@google.com

ChangeLog (gcc):

2015-04-29  Caroline Tice  

Revert patch from 2015-04-27
* final.c (final_scan_insn): Remove code to output
cold_function_name as a function type in assembly.
* varasm.c (cold_function_name): Remove global declaration.
(assemble_start_function): Remove code to re-set
cold_function_name.
(assemble_end_function):  Do not output side of cold
partition.

ChangLog (gcc/testsuite):

2015-04-29  Caroline Tice  

Revert patch from 2015-04-27
* gcc.dg/tree-prof/cold_partition_label.c: Do not check
for cold partition size.




On Wed, Apr 29, 2015 at 9:33 AM, Uros Bizjak  wrote:
> Hello!
>
>> 2015-03-27  Caroline Tice  
>>
>> * final.c (final_scan_insn): Change 'cold_function_name' to
>> 'cold_partition_name' and make it a global variable; also output
>> assembly to give it a 'FUNC' type, if appropriate.
>> * varasm.c (cold_partition_name): Declare and initialize global
>> variable.
>> (assemble_start_function): Re-set value for cold_partition_name.
>> (assemble_end_function): Output assembly to calculate size of cold
>> partition, and associate size with name, if appropriate.
>> * varash.h (cold_partition_name): Add extern declaration for global
>> variable.
>> * testsuite/gcc.dg/tree-prof/cold_partition_label.c: Add dg-final-use
>> to scan assembly for cold partition name and size.
>
> This patch caused PR 65929 [1].
>
> Targets are (ab)using ASM_DECLARE_FUNCTION_NAME and
> ASM_DECLARE_FUNCTION_SIZE for more things that their name suggests. As
> shown in the PR, some directives that are generated through these
> macros apply only to real functions, not to parts of function in the
> middle of the function.
>
> In the particular case in the PR, assembler doesn't tolerate nested
> function declaration.
>
> I suggest to revert the patch for now, until side effects of the patch
> are resolved.
>
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65929
>
> Uros.
Index: gcc/final.c
===
--- gcc/final.c	(revision 222584)
+++ gcc/final.c	(working copy)
@@ -2233,16 +2233,10 @@
 	 suffixing "cold" to the original function's name.  */
 	  if (in_cold_section_p)
 	{
-	  cold_function_name
+	  tree cold_function_name
 		= clone_function_name (current_function_decl, "cold");
-#ifdef ASM_DECLARE_FUNCTION_NAME
-	  ASM_DECLARE_FUNCTION_NAME (asm_out_file,
-	 IDENTIFIER_POINTER (cold_function_name),
-	 current_function_decl);
-#else
 	  ASM_OUTPUT_LABEL (asm_out_file,
 IDENTIFIER_POINTER (cold_function_name));
-#endif
 	}
 	  break;
 
Index: gcc/testsuite/gcc.dg/tree-prof/cold_partition_label.c
===
--- gcc/testsuite/gcc.dg/tree-prof/cold_partition_label.c	(revision 222584)
+++ gcc/testsuite/gcc.dg/tree-prof/cold_partition_label.c	(working copy)
@@ -35,6 +35,4 @@
   return 0;
 }
 
-/* { dg-final-use { scan-assembler "foo\[._\]+cold\[\._\]+0" } } */
-/* { dg-final-use { scan-assembler "size\[ \ta-zA-Z0-0\]+foo\[._\]+cold\[\._\]+0" } } */
 /* { dg-final-use { cleanup-saved-temps } } */
Index: gcc/varasm.c
===
--- gcc/varasm.c	(revision 222584)
+++ gcc/varasm.c	(working copy)
@@ -187,13 +187,6 @@
at the cold section.  */
 bool in_cold_section_p;
 
-/* The following global holds the "function name" for the code in the
-   cold section of a function, if hot/cold function splitting is enabled
-   and there was actually code that went into the cold section.  A
-   pseudo function name is needed for the cold section of code for some
-   debugging tools that perform symbolization. */
-tree cold_function_name = NULL_TREE;
-
 /* A linked list of all the unnamed sections.  */
 static GTY(()) section *unnamed_sections;
 
@@ -1726,7 +1719,6 @@
   ASM_GENERATE_INTERNAL_LABEL (tmp_label, "LCOLDE", const_labelno);
   crtl->subsections.cold_section_end_label = ggc_strdup (tmp_label);
   const_labelno++;
-  cold_function_name = NULL_TREE;
 }
   else
 {
@@ -1864,12 +1856,6 @@
 
   save_text_section = in_section;
   switch_to_section (unlikely_text_section ());
-#ifdef ASM_DECLARE_FUNCTION_SIZE
-  if (cold_function_name != NULL_TREE)
-	ASM_DECLARE_FUNCTION_SIZE (asm_out_file,
-   IDENTIFIER_POINTER (cold_function_name),
-   decl);
-#endif
   ASM_OUTPUT_LABEL (asm_out_file,

Re: [PATCH] Fix size & type for cold partition names (hot-cold function partitioning)

[Uros Bizjak]

On Wed, Apr 29, 2015 at 7:38 PM, Caroline Tice  wrote:
> The attached patch can revert the previous patch, if that is the way
> we should proceed on this.  If you want me to apply the reversion,
> please let me know.
>
> I would be happy to fix to the problem, rather than just reverting the
> patch, but I do not have expertise in assembly language on other
> platforms, so I would need some help, if anyone would be interested in
> helping me?

How about adding ASM_DECLARE_COLD_FUNCTION_NAME and
ASM_DECLARE_COLD_FUNCTION_SIZE? If these are defined, they can be used
instead, and targets are free to define them in any way.

Uros.

Re: [PATCH] [libstdc++/65839] whatis support for xmethods

[Doug Evans]

On Tue, Apr 28, 2015 at 5:16 AM, Jonathan Wakely  wrote:
> On 27/04/15 15:44 -0700, Doug Evans wrote:
>>
>> PR libstdc++/65839
>> * python/libstdcxx/v6/xmethods.py (get_bool_type): New function.
>> Replace all lookups of "bool" with this.
>> (get_std_size_type): New function.  Replace all lookups of
>> std::size_t
>> with this.
>> (ArrayWorkerBase): Rename arg valtype to elem_type for
>> consistency,
>
>
> I'd say ArrayWorkerBase's _valtype is correct and deque and vector are
> wrong to use _elemtype.
>
> C++ containers use value_type for the type of the container objects.
> Smart pointers use element_type for the type of the owned object. So
> using _valtype for containers and _elemtype for unique_ptr would be
> consistent with the C++ library types.

Hi.
Here's v2.
It's assumes the naming cleanup patch has been applied.
https://gcc.gnu.org/ml/libstdc++/2015-04/msg00183.html

Regression tested on amd64-linux.
2015-04-29  Doug Evans  

PR libstdc++/65839
* python/libstdcxx/v6/xmethods.py (get_bool_type): New function.
Replace all lookups of "bool" with this.
(get_std_size_type): New function.  Replace all lookups of std::size_t
with this.
(*Worker): New method get_result_type.
(DequeWorkerBase.__init__): New arg val_type.  All callers updated.
(ListWorkerBase.__init__): New arg val_type.  All callers updated.
(UniquePtrGetWorker.__init__): New arg elem_type.  All callers updated.
Delete setting of name, enabled.
(UniquePtrDerefWorker.__init__): New arg elem_type.  All callers
updated.  Delete setting of name.
(UniquePtrMethodsMatcher): Rewrite for consistency with all other
libstdc++ xmethod matchers.
* testsuite/libstdc++-xmethods/array.cc: Add whatis tests.
* testsuite/libstdc++-xmethods/associative-containers.cc: Ditto.
* testsuite/libstdc++-xmethods/deque.cc: Ditto.
* testsuite/libstdc++-xmethods/forwardlist.cc: Ditto.
* testsuite/libstdc++-xmethods/list.cc: Ditto.
* testsuite/libstdc++-xmethods/unique_ptr.cc: Ditto.
* testsuite/libstdc++-xmethods/vector.cc: Ditto.

Index: python/libstdcxx/v6/xmethods.py
===
--- python/libstdcxx/v6/xmethods.py
+++ python/libstdcxx/v6/xmethods.py
@@ -21,6 +21,12 @@ import re
 
 matcher_name_prefix = 'libstdc++::'
 
+def get_bool_type():
+return gdb.lookup_type('bool')
+
+def get_std_size_type():
+return gdb.lookup_type('std::size_t')
+
 class LibStdCxxXMethod(gdb.xmethod.XMethod):
 def __init__(self, name, worker_class):
 gdb.xmethod.XMethod.__init__(self, name)
@@ -44,6 +50,9 @@ class ArraySizeWorker(ArrayWorkerBase):
 def get_arg_types(self):
 return None
 
+def get_result_type(self, obj):
+return get_std_size_type()
+
 def __call__(self, obj):
 return self._size
 
@@ -54,6 +63,9 @@ class ArrayEmptyWorker(ArrayWorkerBase):
 def get_arg_types(self):
 return None
 
+def get_result_type(self, obj):
+return get_bool_type()
+
 def __call__(self, obj):
 return (int(self._size) == 0)
 
@@ -64,6 +76,9 @@ class ArrayFrontWorker(ArrayWorkerBase):
 def get_arg_types(self):
 return None
 
+def get_result_type(self, obj):
+return self._val_type
+
 def __call__(self, obj):
 if int(self._size) > 0:
 return obj['_M_elems'][0]
@@ -77,6 +92,9 @@ class ArrayBackWorker(ArrayWorkerBase):
 def get_arg_types(self):
 return None
 
+def get_result_type(self, obj):
+return self._val_type
+
 def __call__(self, obj):
 if int(self._size) > 0:
 return obj['_M_elems'][self._size - 1]
@@ -88,7 +106,10 @@ class ArrayAtWorker(ArrayWorkerBase):
 ArrayWorkerBase.__init__(self, val_type, size)
 
 def get_arg_types(self):
-return gdb.lookup_type('std::size_t')
+return get_std_size_type()
+
+def get_result_type(self, obj, index):
+return self._val_type
 
 def __call__(self, obj, index):
 if int(index) >= int(self._size):
@@ -101,7 +122,10 @@ class ArraySubscriptWorker(ArrayWorkerBa
 ArrayWorkerBase.__init__(self, val_type, size)
 
 def get_arg_types(self):
-return gdb.lookup_type('std::size_t')
+return get_std_size_type()
+
+def get_result_type(self, obj, index):
+return self._val_type
 
 def __call__(self, obj, index):
 if int(self._size) > 0:
@@ -140,6 +164,7 @@ class ArrayMethodsMatcher(gdb.xmethod.XM
 
 class DequeWorkerBase(gdb.xmethod.XMethodWorker):
 def __init__(self, val_type):
+self._val_type = val_type
 self._bufsize = (512 / val_type.sizeof) or 1
 
 def size(self, obj):
@@ -158,6 +183,9 @@ class DequeEmptyWorker(DequeWorkerBase):
 def get_arg_types(self):
 return None
 
+def get_result_type(sel

Re: [PATCH] Use consistent naming in libstdcxx/v6/xmethods.py

[Jonathan Wakely]

On 29/04/15 09:49 -0700, Doug Evans wrote:

Hi.

This patch splits out from the patch for 65839 the consistent naming
suggested here.
https://gcc.gnu.org/ml/libstdc++/2015-04/msg00155.html

Regression tested on amd64-linux.

Ok to commit?


Thanks for doing this, OK to commit.

Re: [PATCH] [libstdc++/65839] whatis support for xmethods

[Jonathan Wakely]

On 29/04/15 10:57 -0700, Doug Evans wrote:

On Tue, Apr 28, 2015 at 5:16 AM, Jonathan Wakely  wrote:

On 27/04/15 15:44 -0700, Doug Evans wrote:


PR libstdc++/65839
* python/libstdcxx/v6/xmethods.py (get_bool_type): New function.
Replace all lookups of "bool" with this.
(get_std_size_type): New function.  Replace all lookups of
std::size_t
with this.
(ArrayWorkerBase): Rename arg valtype to elem_type for
consistency,



I'd say ArrayWorkerBase's _valtype is correct and deque and vector are
wrong to use _elemtype.

C++ containers use value_type for the type of the container objects.
Smart pointers use element_type for the type of the owned object. So
using _valtype for containers and _elemtype for unique_ptr would be
consistent with the C++ library types.


Hi.
Here's v2.
It's assumes the naming cleanup patch has been applied.
https://gcc.gnu.org/ml/libstdc++/2015-04/msg00183.html

Regression tested on amd64-linux.


Looks good, OK for trunk, thanks.

If you want to fix this on the branch too then the renaming patch and
this one are both OK for the gcc-5-branch as well.

Re: [PATCH] Fix size & type for cold partition names (hot-cold function partitioning)

[Uros Bizjak]

On Wed, Apr 29, 2015 at 7:47 PM, Uros Bizjak  wrote:
> On Wed, Apr 29, 2015 at 7:38 PM, Caroline Tice  wrote:
>> The attached patch can revert the previous patch, if that is the way
>> we should proceed on this.  If you want me to apply the reversion,
>> please let me know.
>>
>> I would be happy to fix to the problem, rather than just reverting the
>> patch, but I do not have expertise in assembly language on other
>> platforms, so I would need some help, if anyone would be interested in
>> helping me?
>
> How about adding ASM_DECLARE_COLD_FUNCTION_NAME and
> ASM_DECLARE_COLD_FUNCTION_SIZE? If these are defined, they can be used
> instead, and targets are free to define them in any way.

Something like the attached prototype RFC patch. Using this patch,
readelf -sW returns:

Symbol table '.symtab' contains 18 entries:
   Num:Value  Size TypeBind   Vis  Ndx Name
 0:  0 NOTYPE  LOCAL  DEFAULT  UND
 1:  0 SECTION LOCAL  DEFAULT1
 2:  0 SECTION LOCAL  DEFAULT3
 3:  0 SECTION LOCAL  DEFAULT4
 4:  0 SECTION LOCAL  DEFAULT5
 5:  0 SECTION LOCAL  DEFAULT6
 6:  0 SECTION LOCAL  DEFAULT8
 7:  8 FUNCLOCAL  DEFAULT6 main.cold.0
 8:  0 SECTION LOCAL  DEFAULT   10
 9:  0 SECTION LOCAL  DEFAULT   13
10:  0 SECTION LOCAL  DEFAULT   12
11:    312 FUNCGLOBAL DEFAULT [: 88] 8 main
12: 0008   160 OBJECT  GLOBAL DEFAULT  COM buf
13:  0 NOTYPE  GLOBAL DEFAULT  UND memset
14: 44 FUNCGLOBAL DEFAULT [: 88] 1 sub2
15:  0 NOTYPE  GLOBAL DEFAULT  UND strcmp
16:  0 NOTYPE  GLOBAL DEFAULT  UND exit
17:  0 NOTYPE  GLOBAL DEFAULT  UND abort

Uros.
Index: config/elfos.h
===
--- config/elfos.h  (revision 222585)
+++ config/elfos.h  (working copy)
@@ -284,6 +284,17 @@ see the files COPYING3 and COPYING.RUNTIME respect
   while (0)
 #endif
 
+#ifndef ASM_DECLARE_COLD_FUNCTION_NAME
+#define ASM_DECLARE_COLD_FUNCTION_NAME(FILE, NAME, DECL)   \
+  do   \
+{  \
+  ASM_OUTPUT_TYPE_DIRECTIVE (FILE, NAME, "function");  \
+  ASM_DECLARE_RESULT (FILE, DECL_RESULT (DECL));   \
+  ASM_OUTPUT_FUNCTION_LABEL (FILE, NAME, DECL);\
+}  \
+  while (0)
+#endif
+
 /* Write the extra assembler code needed to declare an object properly.  */
 
 #ifdef HAVE_GAS_GNU_UNIQUE_OBJECT
@@ -358,6 +369,16 @@ see the files COPYING3 and COPYING.RUNTIME respect
   while (0)
 #endif
 
+#ifndef ASM_DECLARE_COLD_FUNCTION_SIZE
+#define ASM_DECLARE_COLD_FUNCTION_SIZE(FILE, FNAME, DECL)  \
+  do   \
+{  \
+  if (!flag_inhibit_size_directive)\
+   ASM_OUTPUT_MEASURED_SIZE (FILE, FNAME); \
+}  \
+  while (0)
+#endif
+
 /* A table of bytes codes used by the ASM_OUTPUT_ASCII and
ASM_OUTPUT_LIMITED_STRING macros.  Each byte in the table
corresponds to a particular byte value [0..255].  For any
Index: final.c
===
--- final.c (revision 222585)
+++ final.c (working copy)
@@ -2235,10 +2235,10 @@ final_scan_insn (rtx_insn *insn, FILE *file, int o
{
  cold_function_name
= clone_function_name (current_function_decl, "cold");
-#ifdef ASM_DECLARE_FUNCTION_NAME
- ASM_DECLARE_FUNCTION_NAME (asm_out_file,
-IDENTIFIER_POINTER 
(cold_function_name),
-current_function_decl);
+#ifdef ASM_DECLARE_COLD_FUNCTION_NAME
+ ASM_DECLARE_COLD_FUNCTION_NAME
+   (asm_out_file, IDENTIFIER_POINTER (cold_function_name),
+current_function_decl);
 #else
  ASM_OUTPUT_LABEL (asm_out_file,
IDENTIFIER_POINTER (cold_function_name));
Index: varasm.c
===
--- varasm.c(revision 222585)
+++ varasm.c(working copy)
@@ -1864,11 +1864,10 @@ assemble_end_function (tree decl, const char *fnna
 
   save_text_section = in_section;
   switch_to_section (unlikely_text_section ());
-#ifdef ASM_DECLARE_FUNCTION_SIZE
+#ifdef ASM_DECLARE_COLD_FUNCTION_SIZE
   if (cold_function

[C PATCH] c_incomplete_type_error TLC

[Marek Polacek]

This patch cleans up c_incomplete_type_error a bit: today, we should prefer
using %qT over %<%s %E%> (the code is largely intact since 1992), and second,
we should print the type if we can.  The "invalid use of incomplete typedef"
error wasn't tested at all, so I'm also adding a test to exercise that code
path.

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

2015-04-29  Marek Polacek  

* c-typeck.c (c_incomplete_type_error): Refactor to use %qT.  Print
the type of a decl.

* gcc.dg/incomplete-typedef-1.c: New test.

diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
index c58e918..cc4acf7 100644
--- gcc/c/c-typeck.c
+++ gcc/c/c-typeck.c
@@ -229,15 +229,13 @@ require_complete_type (tree value)
 void
 c_incomplete_type_error (const_tree value, const_tree type)
 {
-  const char *type_code_string;
-
   /* Avoid duplicate error message.  */
   if (TREE_CODE (type) == ERROR_MARK)
 return;
 
   if (value != 0 && (TREE_CODE (value) == VAR_DECL
 || TREE_CODE (value) == PARM_DECL))
-error ("%qD has an incomplete type", value);
+error ("%qD has an incomplete type %qT", value, type);
   else
 {
 retry:
@@ -246,15 +244,8 @@ c_incomplete_type_error (const_tree value, const_tree type)
   switch (TREE_CODE (type))
{
case RECORD_TYPE:
- type_code_string = "struct";
- break;
-
case UNION_TYPE:
- type_code_string = "union";
- break;
-
case ENUMERAL_TYPE:
- type_code_string = "enum";
  break;
 
case VOID_TYPE:
@@ -280,11 +271,10 @@ c_incomplete_type_error (const_tree value, const_tree 
type)
}
 
   if (TREE_CODE (TYPE_NAME (type)) == IDENTIFIER_NODE)
-   error ("invalid use of undefined type %<%s %E%>",
-  type_code_string, TYPE_NAME (type));
+   error ("invalid use of undefined type %qT", type);
   else
/* If this type has a typedef-name, the TYPE_NAME is a TYPE_DECL.  */
-   error ("invalid use of incomplete typedef %qD", TYPE_NAME (type));
+   error ("invalid use of incomplete typedef %qT", type);
 }
 }
 
diff --git gcc/testsuite/gcc.dg/incomplete-typedef-1.c 
gcc/testsuite/gcc.dg/incomplete-typedef-1.c
index e69de29..622bf65 100644
--- gcc/testsuite/gcc.dg/incomplete-typedef-1.c
+++ gcc/testsuite/gcc.dg/incomplete-typedef-1.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "" } */
+
+typedef struct S TS;
+typedef union U TU;
+
+void
+foo (void)
+{
+  (TS) { }; /* { dg-error "invalid use of incomplete typedef" } */
+  (TU) { }; /* { dg-error "invalid use of incomplete typedef" } */
+}

Marek

Contents of PO file 'cpplib-5.1.0.sv.po'

[Translation Project Robot]

cpplib-5.1.0.sv.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.

New Swedish PO file for 'cpplib' (version 5.1.0)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

http://translationproject.org/latest/cpplib/sv.po

(This file, 'cpplib-5.1.0.sv.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/cpplib/

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

Re: [PATCH] Fix size & type for cold partition names (hot-cold function partitioning)

[Caroline Tice]

Thank you; I will work with your suggestions and try to get a new
patch done soon.

-- Caroline Tice
cmt...@google.com


On Wed, Apr 29, 2015 at 11:34 AM, Uros Bizjak  wrote:
> On Wed, Apr 29, 2015 at 7:47 PM, Uros Bizjak  wrote:
>> On Wed, Apr 29, 2015 at 7:38 PM, Caroline Tice  wrote:
>>> The attached patch can revert the previous patch, if that is the way
>>> we should proceed on this.  If you want me to apply the reversion,
>>> please let me know.
>>>
>>> I would be happy to fix to the problem, rather than just reverting the
>>> patch, but I do not have expertise in assembly language on other
>>> platforms, so I would need some help, if anyone would be interested in
>>> helping me?
>>
>> How about adding ASM_DECLARE_COLD_FUNCTION_NAME and
>> ASM_DECLARE_COLD_FUNCTION_SIZE? If these are defined, they can be used
>> instead, and targets are free to define them in any way.
>
> Something like the attached prototype RFC patch. Using this patch,
> readelf -sW returns:
>
> Symbol table '.symtab' contains 18 entries:
>Num:Value  Size TypeBind   Vis  Ndx Name
>  0:  0 NOTYPE  LOCAL  DEFAULT  UND
>  1:  0 SECTION LOCAL  DEFAULT1
>  2:  0 SECTION LOCAL  DEFAULT3
>  3:  0 SECTION LOCAL  DEFAULT4
>  4:  0 SECTION LOCAL  DEFAULT5
>  5:  0 SECTION LOCAL  DEFAULT6
>  6:  0 SECTION LOCAL  DEFAULT8
>  7:  8 FUNCLOCAL  DEFAULT6 main.cold.0
>  8:  0 SECTION LOCAL  DEFAULT   10
>  9:  0 SECTION LOCAL  DEFAULT   13
> 10:  0 SECTION LOCAL  DEFAULT   12
> 11:    312 FUNCGLOBAL DEFAULT [: 88] 8 main
> 12: 0008   160 OBJECT  GLOBAL DEFAULT  COM buf
> 13:  0 NOTYPE  GLOBAL DEFAULT  UND memset
> 14: 44 FUNCGLOBAL DEFAULT [: 88] 1 sub2
> 15:  0 NOTYPE  GLOBAL DEFAULT  UND strcmp
> 16:  0 NOTYPE  GLOBAL DEFAULT  UND exit
> 17:  0 NOTYPE  GLOBAL DEFAULT  UND abort
>
> Uros.

[PATCH, i386]: Fix PR 65871, bzhi builtin/intrinsic wrongly assumes bzhi instruction doesn't set the ZF flag

[Uros Bizjak]

Hello!

Attached patch implements a CCZ-only setting pattern for a couple of
BMI[,2] intrinsics.

2015-04-29  Uros Bizjak  

PR target/65871
* config/i386/i386.md (*bmi_bextr__cczonly): New pattern.
(*bmi2_bzhi_3_1_cczonly): Ditto.

testsuite/ChangeLog:

2015-04-29  Uros Bizjak  

PR target/65871
* gcc.target/i386/pr65871-1.c: New test
* gcc.target/i386/pr65871-2.c: Ditto.

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

Uros.
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 222585)
+++ config/i386/i386.md (working copy)
@@ -12594,6 +12594,20 @@
(set_attr "btver2_decode" "direct, double")
(set_attr "mode" "")])
 
+(define_insn "*bmi_bextr__cczonly"
+  [(set (reg:CCZ FLAGS_REG)
+   (compare:CCZ
+ (unspec:SWI48 [(match_operand:SWI48 1 "nonimmediate_operand" "r,m")
+(match_operand:SWI48 2 "register_operand" "r,r")]
+   UNSPEC_BEXTR)
+ (const_int 0)))
+   (clobber (match_scratch:SWI48 0 "=r,r"))]
+  "TARGET_BMI"
+  "bextr\t{%2, %1, %0|%0, %1, %2}"
+  [(set_attr "type" "bitmanip")
+   (set_attr "btver2_decode" "direct, double")
+   (set_attr "mode" "")])
+
 (define_insn "*bmi_blsi_"
   [(set (match_operand:SWI48 0 "register_operand" "=r")
 (and:SWI48
@@ -12667,6 +12681,7 @@
(set_attr "mode" "")])
 
 (define_mode_attr k [(SI "k") (DI "q")])
+
 (define_insn "*bmi2_bzhi_3_1"
   [(set (match_operand:SWI48 0 "register_operand" "=r")
(zero_extract:SWI48
@@ -12682,6 +12697,23 @@
(set_attr "prefix" "vex")
(set_attr "mode" "")])
 
+(define_insn "*bmi2_bzhi_3_1_cczonly"
+  [(set (reg:CCZ FLAGS_REG)
+   (compare:CCZ
+ (zero_extract:SWI48
+   (match_operand:SWI48 1 "nonimmediate_operand" "rm")
+   (umin:SWI48
+ (zero_extend:SWI48 (match_operand:QI 2 "register_operand" "r"))
+ (match_operand:SWI48 3 "const_int_operand" "n"))
+   (const_int 0))
+   (const_int 0)))
+   (clobber (match_scratch:SWI48 0 "=r"))]
+  "TARGET_BMI2 && INTVAL (operands[3]) ==  * BITS_PER_UNIT"
+  "bzhi\t{%2, %1, %0|%0, %1, %2}"
+  [(set_attr "type" "bitmanip")
+   (set_attr "prefix" "vex")
+   (set_attr "mode" "")])
+
 (define_insn "bmi2_pdep_3"
   [(set (match_operand:SWI48 0 "register_operand" "=r")
 (unspec:SWI48 [(match_operand:SWI48 1 "register_operand" "r")
Index: testsuite/gcc.target/i386/pr65871-1.c
===
--- testsuite/gcc.target/i386/pr65871-1.c   (revision 0)
+++ testsuite/gcc.target/i386/pr65871-1.c   (working copy)
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mbmi" } */
+
+int foo (unsigned int x, unsigned int y)
+{
+  if (__builtin_ia32_bextr_u32 (x, y))
+return 1;
+
+  return 0;
+}
+
+/* { dg-final { scan-assembler-not "test" } } */
Index: testsuite/gcc.target/i386/pr65871-2.c
===
--- testsuite/gcc.target/i386/pr65871-2.c   (revision 0)
+++ testsuite/gcc.target/i386/pr65871-2.c   (working copy)
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mbmi2" } */
+
+int foo (unsigned int x, unsigned int y)
+{
+  if (__builtin_ia32_bzhi_si (x, y))
+return 1;
+
+  return 0;
+}
+
+/* { dg-final { scan-assembler-not "test" } } */

Re: [RFC]: Remove Mem/address type assumption in combiner

[Jeff Law]

On 04/29/2015 03:25 AM, Kumar, Venkataramanan wrote:

Hi Jeff/Segher,

Restarting the discussion on the GCC combiner assumption about Memory/address 
type.
Ref: https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01298.html
https://gcc.gnu.org/ml/gcc/2015-04/msg00028.html



Regards,
Venkat.

PS:  I am starting a new thread since I no more have access to Linaro ID from 
where I sent the earlier mail.
Funny, I sent mail just a few days ago trying to get this restarted, but 
it went to your Linaro address.  I'll forward it separately.



Jeff

Re: [RFC]: Remove Mem/address type assumption in combiner

[Jeff Law]

On 04/29/2015 11:03 AM, Segher Boessenkool wrote:


Right.  It would be good if you could find out for what targets it matters.
The thing is, if a target expects only the patterns as combine used to make
them, it will regress (as you've seen on aarch64); but it will regress
_silently_.  Which isn't so nice.


But  before that  I wanted to check if the assumption in combiner,  can simply 
be removed ?


Seeing for what targets / patterns it makes a difference would tell us the
answer to that, too :-)
Right.  ANd that was one of the two general directions I recommended 
earlier this week ;-)


1. Figure out if this code still matters at all.
2. If the code still matters, accurately track if we're
   inside a MEM so that things canonicalize correctly.

jeff

Re: [RFC]: Remove Mem/address type assumption in combiner

[Jeff Law]

On 04/29/2015 03:25 AM, Kumar, Venkataramanan wrote:

Hi Jeff/Segher,

When we see an  RTX code with PLUS or MINUS then it is treated as  MEM/address 
type (we are inside address RTX).
Is there any significance on that assumption?  I removed this assumption and 
the test case in the PR 63949 passed.
When appearing inside a MEM, we have different canonicalization rules. 
The comment in make_compound_operation clearly indicates that the 
PLUS/MINUS support is a hack.  However, I'm pretty sure it was strictly 
for getting better code than for correctness.


One path forward is to properly track if we're in a MEM, at which point 
the hack for PLUS/MINUS could probably just go away.





diff --git a/gcc/combine.c b/gcc/combine.c
index 5c763b4..945abdb 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -7703,8 +7703,6 @@ make_compound_operation (rtx x, enum rtx_code in_code)
   but once inside, go back to our default of SET.  */

next_code = (code == MEM ? MEM
-  : ((code == PLUS || code == MINUS)
- && SCALAR_INT_MODE_P (mode)) ? MEM
: ((code == COMPARE || COMPARISON_P (x))
   && XEXP (x, 1) == const0_rtx) ? COMPARE
: in_code == COMPARE ? SET : in_code);


On X86_64, it passes bootstrap and regression tests.
But on Aarch64 the test in PR passed, but I got a few test case failures.

Tests that now fail, but worked before:

gcc.target/aarch64/adds1.c scan-assembler adds\tw[0-9]+, w[0-9]+, w[0-9]+, lsl 3
gcc.target/aarch64/adds1.c scan-assembler adds\tx[0-9]+, x[0-9]+, x[0-9]+, lsl 3
So that test seems to want to verify that you can generate a shift-add 
type instruction.  I suspect the others are similar.  I'd be curious to 
see the .combine dump as well as the final assembly for this test.



Which is a strong hint that we should be looking at target with 
shift-add style instructions.  ARM, AArch64, HPPA, x86 come immediately 
to mind.






There are few patterns based on multiplication operations in Aarch64 backend 
which are used to match with the pattern combiner generated.
Now those patterns have to be fixed to use SHIFTS.  Also need to see any impact 
on other targets.

But  before that  I wanted to check if the assumption in combiner,  can simply 
be removed ?
Given what I'm seeing now, I doubt it can simply be removed at this 
point (which is a change in my position) since ports with these 
shift-add style instructions have probably been tuned to work with 
existing combine behaviour.  We may need to do a deep test across 
various targets to identify those affected and fix them.


jeff

Re: [PATCH, i386]: Fix PR 65871, bzhi builtin/intrinsic wrongly assumes bzhi instruction doesn't set the ZF flag

[Jakub Jelinek]

On Wed, Apr 29, 2015 at 09:02:16PM +0200, Uros Bizjak wrote:
> Hello!
> 
> Attached patch implements a CCZ-only setting pattern for a couple of
> BMI[,2] intrinsics.

What about the case when the result is used, but also tested for zero or
non-zero?  Like e.g.
int bar (void);
int foo (unsigned int x, unsigned int y)
{
  int v = __builtin_ia32_bextr_u32 (x, y);
  if (v)
return v;
  return bar ();
}

Jakub

Re: [PATCH, i386]: Fix PR 65871, bzhi builtin/intrinsic wrongly assumes bzhi instruction doesn't set the ZF flag

[Uros Bizjak]

On Wed, Apr 29, 2015 at 9:23 PM, Jakub Jelinek  wrote:
> On Wed, Apr 29, 2015 at 09:02:16PM +0200, Uros Bizjak wrote:
>> Hello!
>>
>> Attached patch implements a CCZ-only setting pattern for a couple of
>> BMI[,2] intrinsics.
>
> What about the case when the result is used, but also tested for zero or
> non-zero?  Like e.g.
> int bar (void);
> int foo (unsigned int x, unsigned int y)
> {
>   int v = __builtin_ia32_bextr_u32 (x, y);
>   if (v)
> return v;
>   return bar ();
> }

Yes, I have considered this usage, but it would require *another*
pattern. I don't think it is worth just to have one test insn less...

Uros.

Re: [patch] Rewrite check_global_declarations() generically

[Jason Merrill]

On 04/28/2015 09:01 PM, Aldy Hernandez wrote:

The approach looks good to me.


-  analyze_functions ();
+  analyze_functions (true);


In the C++ front end at least we comment anonymous boolean arguments, i.e.

 analyze_functions (/*first_time*/true);

Let's do that here, too.  Similarly for the calls to referred_to_p (false).


+  /* ?? Why are we looking at TREE_USED?  Shouldn't the call to
+referred_to_p above be enough?  Apparently not, because the
+`__unused__' attribute is not being considered for
+referred_to_p.  */


Seems like you answered your question.  :)


+  /* Global ctors and dtors are called by the runtime.  */
+  && (TREE_CODE (decl) != FUNCTION_DECL
+ || (!DECL_STATIC_CONSTRUCTOR (decl)
+ && !DECL_STATIC_DESTRUCTOR (decl)))


Maybe check snode->needed_p instead?

Jason