[PATCH committed] avoid name lookup warning in tree.c

[Markus Trippelsdorf]

In stage1 with -std=gnu++98 I see:

/home/markus/gcc/gcc/tree.c: In function ‘void inchash::add_expr(const_tree, 
inchash::hash&, unsigned int)’:
/home/markus/gcc/gcc/tree.c:8013:11: warning: name lookup of ‘i’ changed
  for (i = TREE_OPERAND_LENGTH (t) - 1; i >= 0; --i)
   ^
/home/markus/gcc/gcc/tree.c:7773:7: warning:   matches this ‘i’ under ISO 
standard rules
   int i;
   ^
/home/markus/gcc/gcc/tree.c:7869:16: warning:   matches this ‘i’ under old rules
   for (int i = 0; i < TREE_VEC_LENGTH (t); ++i)
^

Fix committed as obvious.
 
PR tree-optimization/880216
* tree.c (add_expr): Avoid name lookup warning.

diff --git a/gcc/tree.c b/gcc/tree.c
index 8f87e7cfacb2..c87b7695c82a 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -7866,7 +7866,7 @@ add_expr (const_tree t, inchash::hash , unsigned 
int flags)
return;
   }
 case TREE_VEC:
-  for (int i = 0; i < TREE_VEC_LENGTH (t); ++i)
+  for (i = 0; i < TREE_VEC_LENGTH (t); ++i)
inchash::add_expr (TREE_VEC_ELT (t, i), hstate, flags);
   return;
 case FUNCTION_DECL:
-- 
Markus

[PATCH][P1][PR tree-optimization/80216] Avoid infinite recursion in DOM

[Jeff Law]

A dumb mistake on my part, we can have a self-referencing definition 
statement inside a loop.  That will cause the recently added code to 
walk back through BIT_IOR_EXPRs to recurse forever.


I've added a trivial recursion depth limit.

Bootstrapped and regression tested on x86_64-linux-gnu.  Installed on 
the trunk.  Sorry for the breakage.


Jeff
commit 602ce767e82ba30364603155d18290f8f02aeded
Author: law 
Date:   Tue Mar 28 03:22:25 2017 +

PR tree-optimization/80162
* tree-ssa-dom.c (derive_equivalences_from_bit_ior): Fix typo in
function name.  Limit recursion depth.
(record_temporary_equivalences): Corresponding changes.

PR tree-optimization/80162
* gcc.c-torture/compile/pr80216.c: New test.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@246517 
138bc75d-0d04-0410-961f-82ee72b054a4

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index a45168e..10bb56b 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,10 @@
+017-03-27  Jeff Law  
+
+PR tree-optimization/80162
+   * tree-ssa-dom.c (derive_equivalences_from_bit_ior): Fix typo in
+   function name.  Limit recursion depth.
+   (record_temporary_equivalences): Corresponding changes.
+
 2017-03-27  Jonathan Wakely  
 
* doc/invoke.texi (-Wno-narrowing): Reorder so default behavior is
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 14f6d6b..9c7f2cf 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2017-03-27  Jeff Law  
+
+   PR tree-optimization/80162
+   * gcc.c-torture/compile/pr80216.c: New test.
+
 2017-03-27  Jakub Jelinek  
 
PR middle-end/80162
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr80216.c 
b/gcc/testsuite/gcc.c-torture/compile/pr80216.c
new file mode 100644
index 000..cf5b27d
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr80216.c
@@ -0,0 +1,37 @@
+int u4, lx, e0, zy, pz;
+
+void
+tb (int m6)
+{
+  for (pz = 0; pz < 1; ++pz)
+{
+  for (zy = 0; zy < 1; ++zy)
+for (u4 = 0; u4 < 1; ++u4)
+  for (e0 = 0; e0 < 1; ++e0)
+{
+ as:
+  for (;;)
+{
+}
+}
+
+  if (e0 != 0)
+goto ql;
+
+  if (0)
+{
+ o3:
+  for (lx = 0; lx < 1; ++lx)
+{
+  m6 |= lx;
+  if (m6 == 0)
+lx = 0;
+ ql:
+  ;
+}
+  goto as;
+}
+}
+  goto o3;
+}
+
diff --git a/gcc/tree-ssa-dom.c b/gcc/tree-ssa-dom.c
index c6ffc38..d2263bb 100644
--- a/gcc/tree-ssa-dom.c
+++ b/gcc/tree-ssa-dom.c
@@ -692,11 +692,18 @@ back_propagate_equivalences (tree lhs, edge e,
 }
 
 /* Record NAME has the value zero and if NAME was set from a BIT_IOR_EXPR
-   recurse into both operands recording their values as zero too.  */
+   recurse into both operands recording their values as zero too. 
+   RECURSION_DEPTH controls how far back we recurse through the operands
+   of the BIT_IOR_EXPR.  */
 
 static void
-derive_equivalencs_from_bit_ior (tree name, const_and_copies *const_and_copies)
+derive_equivalences_from_bit_ior (tree name,
+ const_and_copies *const_and_copies,
+ int recursion_limit)
 {
+  if (recursion_limit == 0)
+return;
+
   if (TREE_CODE (name) == SSA_NAME)
 {
   tree value = fold_convert (TREE_TYPE (name), integer_zero_node);
@@ -710,10 +717,12 @@ derive_equivalencs_from_bit_ior (tree name, 
const_and_copies *const_and_copies)
   if (is_gimple_assign (def_stmt)
  && gimple_assign_rhs_code (def_stmt) == BIT_IOR_EXPR)
{
- derive_equivalencs_from_bit_ior (gimple_assign_rhs1 (def_stmt),
-  const_and_copies);
- derive_equivalencs_from_bit_ior (gimple_assign_rhs2 (def_stmt),
-  const_and_copies);
+ derive_equivalences_from_bit_ior (gimple_assign_rhs1 (def_stmt),
+   const_and_copies,
+   recursion_limit - 1);
+ derive_equivalences_from_bit_ior (gimple_assign_rhs2 (def_stmt),
+   const_and_copies,
+   recursion_limit - 1);
}
 }
 }
@@ -751,7 +760,7 @@ record_temporary_equivalences (edge e,
  enum tree_code code = eq->cond.ops.binary.op;
  if ((code == EQ_EXPR && eq->value == boolean_true_node)
  || (code == NE_EXPR && eq->value == boolean_false_node))
-   derive_equivalencs_from_bit_ior (op0, const_and_copies);
+   derive_equivalences_from_bit_ior (op0, const_and_copies, 4);
 
  /* TODO: We could handle BIT_AND_EXPR in a similar fashion

Re: [patch] Clarify interaction of -Wnarrowing with -std

[Jonathan Wakely]

On 27/03/17 10:09 +0100, Jonathan Wakely wrote:

On 26/03/17 14:32 -0600, Sandra Loosemore wrote:

On 03/26/2017 02:13 PM, Gerald Pfeifer wrote:

Hi Jonathan,

On Tue, 23 Feb 2016, Jonathan Wakely wrote:

On 19/02/16 13:17 -0700, Sandra Loosemore wrote:

I suppose the patch is OK as it stands, but I was going to suggest
restructuring it so that it talks about the default behavior first
and what
it does with non-default -std= options after that, instead of
vice-versa.
Unfortunately I am backlogged on other things right now and it might
take me
a day or two before I have time to come up with some alternate
wording.  If
we are in a rush, go ahead and commit the existing patch meanwhile, I
guess.

Is this better?


I believe your follow-up patch did not get committed, nor did I
see any response from anyone.

To me it looks fine.  Did you hold of intentionally, or did this
get lost for lack of responses?

Sandra, what do you think?


Looks OK to me.  I apologize for losing track of this patch previously.  :-(


OK, thanks, I'll commit it today.


I've committed the attached patch.


commit 77d4b96ba46e57a761e6844b89de9412011ef583
Author: Jonathan Wakely 
Date:   Mon Mar 27 19:37:01 2017 +0100

Restructure -Wno-narrowing documentation

	* doc/invoke.texi (-Wno-narrowing): Reorder so default behavior is
	covered first.

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 3f0eb2f..8d3821e 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -2869,10 +2869,17 @@ During the link-time optimization warn about type mismatches in
 global declarations from different compilation units.
 Requires @option{-flto} to be enabled.  Enabled by default.
 
-@item -Wnarrowing @r{(C++ and Objective-C++ only)}
+@item -Wno-narrowing @r{(C++ and Objective-C++ only)}
 @opindex Wnarrowing
 @opindex Wno-narrowing
-With @option{-std=gnu++98} or @option{-std=c++98}, warn when a narrowing
+For C++11 and later standards, narrowing conversions are diagnosed by default,
+as required by the standard.  A narrowing conversion from a constant produces
+an error, and a narrowing conversion from a non-constant produces a warning,
+but @option{-Wno-narrowing} suppresses the diagnostic.
+Note that this does not affect the meaning of well-formed code;
+narrowing conversions are still considered ill-formed in SFINAE contexts.
+
+With @option{-Wnarrowing} in C++98, warn when a narrowing
 conversion prohibited by C++11 occurs within
 @samp{@{ @}}, e.g.
 
@@ -2882,14 +2889,6 @@ int i = @{ 2.2 @}; // error: narrowing from double to int
 
 This flag is included in @option{-Wall} and @option{-Wc++11-compat}.
 
-When a later standard is in effect, e.g. when using @option{-std=c++11},
-narrowing conversions are diagnosed by default, as required by the standard.
-A narrowing conversion from a constant produces an error,
-and a narrowing conversion from a non-constant produces a warning,
-but @option{-Wno-narrowing} suppresses the diagnostic.
-Note that this does not affect the meaning of well-formed code;
-narrowing conversions are still considered ill-formed in SFINAE contexts.
-
 @item -Wnoexcept @r{(C++ and Objective-C++ only)}
 @opindex Wnoexcept
 @opindex Wno-noexcept

Re: [PATCH] Fix calls.c for a _complex type (PR ipa/80104).

[Martin Jambor]

Hi,

On Mon, Mar 27, 2017 at 12:15:10PM -0600, Jeff Law wrote:
> On 03/27/2017 05:40 AM, Martin Liška wrote:
> > Hello.
> > 
> > There's alternative approach suggested by Martin Jambor.
> > Patch can bootstrap on ppc64le-redhat-linux and survives regression tests 
> > and
> > s390x cross compiler does not ICE.
> > 
> > Martin
> > 
> > 2017-03-23  Martin Liska  
> > 
> > PR ipa/80104
> > * cgraphunit.c (cgraph_node::expand_thunk): Mark argument of a
> > thunk call as DECL_GIMPLE_REG_P when vector or complex type.
> Can you fix the documentation for DECL_GIMPLE_REG_P to indiate that it can
> be set on parameters.
> 
> In gimplify_function_tree we have this:
> 
>  for (parm = DECL_ARGUMENTS (fndecl); parm ; parm = DECL_CHAIN (parm))
> {
>   /* Preliminarily mark non-addressed complex variables as eligible
>  for promotion to gimple registers.  We'll transform their uses
>  as we find them.  */
>   if ((TREE_CODE (TREE_TYPE (parm)) == COMPLEX_TYPE
>|| TREE_CODE (TREE_TYPE (parm)) == VECTOR_TYPE)
>   && !TREE_THIS_VOLATILE (parm)
>   && !needs_to_live_in_memory (parm))
> DECL_GIMPLE_REG_P (parm) = 1;
> }
> 
> Aren't you essentially doing the same thing for thunks?

Yes.

> Does it make sense
> to pull that into a little function and just call it from both places?

Possibly...

> 
> If not, do we need to add the !TREE_THIS_VOLATILE and
> !needs_to_live_in_memory checks to the thunks version?

...although if any of these checks fail, the bug will re-surface.

I do not really know what a volatile parameter means, let alone a
volatile parameter of a hunk.  Unless, I am mistaken, hunk parameters
are never made TREE_ADDRESSABLE, so needs_to_live_in_memory can be
omitted.

> 
> Generally OK, just want to work through these couple niggling details.
> 

Thanks for looking at this,

Martin

Re: [Patch, Fortran, OOP] PR 78661: Namelist output missing object designator under DTIO

[Janus Weil]

Forgot to mention: The patch was pre-approved by Jerry, but of course
I'm happy to make corrections (if necessary).

Cheers,
Janus


2017-03-27 22:50 GMT+02:00 Janus Weil :
> Hi all,
>
> I intend to commit the attached patch for a problem with derived-type
> I/O and namelist output by tomorrow, if there are no objections. The
> dtio_25.f90 test case needed some adjustments (see the discussion on
> bugzilla) and still contains a FIXME note, which will be fixed by
> Jerry's upcoming patch for PR 78670, I hope.
>
> Cheers,
> Janus

[Patch, Fortran, OOP] PR 78661: Namelist output missing object designator under DTIO

[Janus Weil]

Hi all,

I intend to commit the attached patch for a problem with derived-type
I/O and namelist output by tomorrow, if there are no objections. The
dtio_25.f90 test case needed some adjustments (see the discussion on
bugzilla) and still contains a FIXME note, which will be fixed by
Jerry's upcoming patch for PR 78670, I hope.

Cheers,
Janus
Index: gcc/fortran/trans-io.c
===
--- gcc/fortran/trans-io.c  (revision 246508)
+++ gcc/fortran/trans-io.c  (working copy)
@@ -1701,23 +1701,54 @@ transfer_namelist_element (stmtblock_t * block, co
   /* Check if the derived type has a specific DTIO for the mode.
  Note that although namelist io is forbidden to have a format
  list, the specific subroutine is of the formatted kind.  */
-  if (ts->type == BT_DERIVED)
+  if (ts->type == BT_DERIVED || ts->type == BT_CLASS)
 {
-  gfc_symbol *dtio_sub = NULL;
-  gfc_symbol *vtab;
-  dtio_sub = gfc_find_specific_dtio_proc (ts->u.derived,
- last_dt == WRITE,
- true);
-  if (dtio_sub != NULL)
+  gfc_symbol *derived;
+  if (ts->type==BT_CLASS)
+   derived = ts->u.derived->components->ts.u.derived;
+  else
+   derived = ts->u.derived;
+
+  gfc_symtree *tb_io_st = gfc_find_typebound_dtio_proc (derived,
+   last_dt == WRITE, true);
+
+  if (ts->type == BT_CLASS && tb_io_st)
{
- dtio_proc = gfc_get_symbol_decl (dtio_sub);
- dtio_proc = gfc_build_addr_expr (NULL, dtio_proc);
- vtab = gfc_find_derived_vtab (ts->u.derived);
- vtable = vtab->backend_decl;
- if (vtable == NULL_TREE)
-   vtable = gfc_get_symbol_decl (vtab);
- vtable = gfc_build_addr_expr (pvoid_type_node, vtable);
+ // polymorphic DTIO call  (based on the dynamic type)
+ gfc_se se;
+ gfc_symtree *st = gfc_find_symtree (sym->ns->sym_root, sym->name);
+ // build vtable expr
+ gfc_expr *expr = gfc_get_variable_expr (st);
+ gfc_add_vptr_component (expr);
+ gfc_init_se (, NULL);
+ se.want_pointer = 1;
+ gfc_conv_expr (, expr);
+ vtable = se.expr;
+ // build dtio expr
+ gfc_add_component_ref (expr,
+   tb_io_st->n.tb->u.generic->specific_st->name);
+ gfc_init_se (, NULL);
+ se.want_pointer = 1;
+ gfc_conv_expr (, expr);
+ gfc_free_expr (expr);
+ dtio_proc = se.expr;
}
+  else
+   {
+ // non-polymorphic DTIO call (based on the declared type)
+ gfc_symbol *dtio_sub = gfc_find_specific_dtio_proc (derived,
+   last_dt == WRITE, true);
+ if (dtio_sub != NULL)
+   {
+ dtio_proc = gfc_get_symbol_decl (dtio_sub);
+ dtio_proc = gfc_build_addr_expr (NULL, dtio_proc);
+ gfc_symbol *vtab = gfc_find_derived_vtab (derived);
+ vtable = vtab->backend_decl;
+ if (vtable == NULL_TREE)
+   vtable = gfc_get_symbol_decl (vtab);
+ vtable = gfc_build_addr_expr (pvoid_type_node, vtable);
+   }
+   }
 }
 
   if (ts->type == BT_CHARACTER)
Index: gcc/testsuite/gfortran.dg/dtio_25.f90
===
--- gcc/testsuite/gfortran.dg/dtio_25.f90   (revision 246508)
+++ gcc/testsuite/gfortran.dg/dtio_25.f90   (working copy)
@@ -8,6 +8,8 @@ module m
   contains
 procedure :: write_formatted
 generic :: write(formatted) => write_formatted
+procedure :: read_formatted
+generic :: read(formatted) => read_formatted
   end type
 contains
   subroutine write_formatted(dtv, unit, iotype, v_list, iostat, iomsg)
@@ -18,11 +20,26 @@ contains
 integer, intent(out) :: iostat
 character(*), intent(inout) :: iomsg
 if (iotype.eq."NAMELIST") then
-  write (unit, '(a,a,a,a,i5)') 'x%c="',dtv%c,'",','x%k=', dtv%k
+  write (unit, '(a3,a1,i3)') dtv%c,',', dtv%k
 else
   write (unit,*) dtv%c, dtv%k
 end if
   end subroutine
+  subroutine read_formatted(dtv, unit, iotype, v_list, iostat, iomsg)
+class(t), intent(inout) :: dtv
+integer, intent(in) :: unit
+character(*), intent(in) :: iotype
+integer, intent(in) :: v_list(:)
+integer, intent(out) :: iostat
+character(*), intent(inout) :: iomsg
+character :: comma
+if (iotype.eq."NAMELIST") then
+  read (unit, '(a4,a1,i3)') dtv%c, comma, dtv%k! FIXME: need a4 here, 
with a3 above
+else
+  read (unit,*) dtv%c, comma, dtv%k
+end if
+if (comma /= ',') call abort()
+  end subroutine
 end module
 
 program p
@@ -33,9 +50,8 @@ program p
   namelist /nml/ x
   x = t('a', 5)
   write (buffer, nml)
-  if (buffer.ne.' x%c="a",x%k=5  /') call abort

[PATCH] S/390: Optimize atomic_compare_exchange and atomic_compare builtins.

[Dominik Vogt]

The attached patch optimizes the atomic_exchange and
atomic_compare patterns on s390 and s390x (mostly limited to
SImode and DImode).  Among general optimizaation, the changes fix
most of the problems reported in PR 80080:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80080

Bootstrapped and regression tested on a zEC12 with s390 and s390x
biarch.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany
gcc/ChangeLog-dv-atomic-gcc7

* (s390_expand_cs_hqi): Removed.
(s390_expand_cs, s390_expand_atomic_exchange_tdsi): New prototypes.
(s390_cc_modes_compatible): Export.
* config/s390/predicates.md ("memory_nosymref_operand"): New predicate
for compare-and-swap.
* config/s390/s390.c(s390_emit_compare_and_swap): Handle all integer
modes.
(s390_cc_modes_compatible): Remove static.
(s390_expand_cs_hqi): Make static.
(s390_expand_cs_tdsi): Generate an explicit compare before trying
compare-and-swap, in some cases.
(s390_expand_cs): Wrapper function.
(s390_expand_atomic_exchange_tdsi): New backend specific expander for
atomic_exchange.
* config/s390/s390.md (define_peephole2): New peephole to help
combining the load-and-test pattern with volatile memory.
("cstorecc4"): Deal with CCZmode too.
("sne", "sneccz1_ne", "sneccz1_eq"): Renamed and duplicated pattern.
("sneccz_ne", "sneccz_eq"): New.
("atomic_compare_and_swap"): Merge the patterns for small and
large integers.  Forbid symref memory operands.  Move expander to
s390.c.
("atomic_compare_and_swap_internal")
("*atomic_compare_and_swap_1")
("*atomic_compare_and_swap_2")
("*atomic_compare_and_swap_3"): Forbid symref memory operands.
("atomic_exchange"): Allow and implement all integer modes.
gcc/testsuite/ChangeLog-dv-atomic-gcc7

* gcc.target/s390/md/atomic_compare_exchange-1.c: New test.
* gcc.target/s390/md/atomic_compare_exchange-1.inc: New test.
* gcc.target/s390/md/atomic_exchange-1.inc: New test.
>From 17822384e33b4b98c299ab25969907eb2b9184ee Mon Sep 17 00:00:00 2001
From: Dominik Vogt 
Date: Thu, 23 Feb 2017 17:23:11 +0100
Subject: [PATCH] S/390: Optimize atomic_compare_exchange and
 atomic_compare builtins.

1) Use the load-and-test instructions for atomic_exchange if the value is 0.
2) If IS_WEAK is true, compare the memory contents before a compare-and-swap
   and skip the CS instructions if the value is not the expected one.
---
 gcc/config/s390/predicates.md  |  13 +
 gcc/config/s390/s390-protos.h  |   5 +-
 gcc/config/s390/s390.c | 178 ++-
 gcc/config/s390/s390.md| 217 +
 .../gcc.target/s390/md/atomic_compare_exchange-1.c |  84 ++
 .../s390/md/atomic_compare_exchange-1.inc  | 336 +
 .../gcc.target/s390/md/atomic_exchange-1.c | 309 +++
 7 files changed, 1075 insertions(+), 67 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/s390/md/atomic_compare_exchange-1.c
 create mode 100644 
gcc/testsuite/gcc.target/s390/md/atomic_compare_exchange-1.inc
 create mode 100644 gcc/testsuite/gcc.target/s390/md/atomic_exchange-1.c

diff --git a/gcc/config/s390/predicates.md b/gcc/config/s390/predicates.md
index 0c82efc..aadb454 100644
--- a/gcc/config/s390/predicates.md
+++ b/gcc/config/s390/predicates.md
@@ -67,6 +67,19 @@
   return true;
 })
 
+;; Like memory_operand, but rejects symbol references.
+(define_predicate "memory_nosymref_operand"
+  (match_operand 0 "memory_operand")
+{
+  if (SYMBOL_REF_P (XEXP (op, 0)))
+return false;
+  if (GET_CODE (op) == SUBREG
+  && GET_CODE (SUBREG_REG (op)) == MEM
+  && SYMBOL_REF_P (XEXP (XEXP (op, 0), 0)))
+return false;
+  return true;
+})
+
 ;; Return true if OP is a valid operand for the BRAS instruction.
 ;; Allow SYMBOL_REFs and @PLT stubs.
 
diff --git a/gcc/config/s390/s390-protos.h b/gcc/config/s390/s390-protos.h
index 7f06a20..81644b9 100644
--- a/gcc/config/s390/s390-protos.h
+++ b/gcc/config/s390/s390-protos.h
@@ -81,6 +81,7 @@ extern bool s390_overlap_p (rtx, rtx, HOST_WIDE_INT);
 extern bool s390_offset_p (rtx, rtx, rtx);
 extern int tls_symbolic_operand (rtx);
 
+extern machine_mode s390_cc_modes_compatible (machine_mode, machine_mode);
 extern bool s390_match_ccmode (rtx_insn *, machine_mode);
 extern machine_mode s390_tm_ccmode (rtx, rtx, bool);
 extern machine_mode s390_select_ccmode (enum rtx_code, rtx, rtx);
@@ -112,8 +113,8 @@ extern void s390_expand_vec_strlen (rtx, rtx, rtx);
 extern void s390_expand_vec_movstr (rtx, rtx, rtx);
 extern bool s390_expand_addcc (enum rtx_code, rtx, rtx, rtx, rtx, rtx);
 extern bool s390_expand_insv (rtx, rtx, rtx, rtx);
-extern void s390_expand_cs_hqi (machine_mode, rtx, rtx, rtx,
-   rtx, rtx, 

Re: [PATCH] [ARC] Define _REENTRANT when -pthread is passed.

[Andrew Burgess]

* Claudiu Zissulescu  [2017-03-27 13:13:13 
+0200]:

> Hi Andrew,
> 
> This is a patch which originally has been made by Thomas. As I did
> arange it, I cannot push it.
> 
> Original patch message:
> 
> The compiler is supposed to have the builtin defined _REENTRANT defined
> when -pthread is passed, which wasn't done on the ARC architecture.
> 
> When _REENTRANT is not passed, the C library will not use reentrant
> functions, and the latest version of ax_pthread.m4 from the
> autoconf-archive will no longer detect that thread support is
> available (see https://savannah.gnu.org/patch/?8186).
> 
> gcc/
> 2017-03-02  Claudiu Zissulescu  
>   Thomas Petazzoni 
> 
>   * config/arc/arc.h (CPP_SPEC): Add subtarget_cpp_spec.
>   (EXTRA_SPECS): Define.
>   (SUBTARGET_EXTRA_SPECS): Likewise.
>   (SUBTARGET_CPP_SPEC): Likewise.
>   * config/arc/elf.h (EXTRA_SPECS): Renamed to
>   SUBTARGET_EXTRA_SPECS.
>   * config/arc/linux.h (SUBTARGET_CPP_SPEC): Define.

Looks good.

Thanks,
Andrew



> ---
>  gcc/config/arc/arc.h   | 24 +++-
>  gcc/config/arc/elf.h   |  3 ++-
>  gcc/config/arc/linux.h |  5 +
>  3 files changed, 30 insertions(+), 2 deletions(-)
> 
> diff --git a/gcc/config/arc/arc.h b/gcc/config/arc/arc.h
> index d515eb0..24c2346 100644
> --- a/gcc/config/arc/arc.h
> +++ b/gcc/config/arc/arc.h
> @@ -61,7 +61,8 @@ along with GCC; see the file COPYING3.  If not see
>  %{mmac-d16:-D__Xxmac_d16} %{mmac-24:-D__Xxmac_24} \
>  %{mdsp-packa:-D__Xdsp_packa} %{mcrc:-D__Xcrc} %{mdvbf:-D__Xdvbf} \
>  %{mtelephony:-D__Xtelephony} %{mxy:-D__Xxy} %{mmul64: -D__Xmult32} \
> -%{mlock:-D__Xlock} %{mswape:-D__Xswape} %{mrtsc:-D__Xrtsc}"
> +%{mlock:-D__Xlock} %{mswape:-D__Xswape} %{mrtsc:-D__Xrtsc} \
> +%(subtarget_cpp_spec)"
>  
>  #undef CC1_SPEC
>  #define CC1_SPEC "\
> @@ -73,6 +74,27 @@ extern const char *arc_cpu_to_as (int argc, const char 
> **argv);
>  #define EXTRA_SPEC_FUNCTIONS \
>{ "cpu_to_as", arc_cpu_to_as },
>  
> +/* This macro defines names of additional specifications to put in the specs
> +   that can be used in various specifications like CC1_SPEC.  Its definition
> +   is an initializer with a subgrouping for each command option.
> +
> +   Each subgrouping contains a string constant, that defines the
> +   specification name, and a string constant that used by the GCC driver
> +   program.
> +
> +   Do not define this macro if it does not need to do anything.  */
> +#define EXTRA_SPECS\
> +  { "subtarget_cpp_spec",SUBTARGET_CPP_SPEC }, \
> +  SUBTARGET_EXTRA_SPECS
> +
> +#ifndef SUBTARGET_EXTRA_SPECS
> +#define SUBTARGET_EXTRA_SPECS
> +#endif
> +
> +#ifndef SUBTARGET_CPP_SPEC
> +#define SUBTARGET_CPP_SPEC ""
> +#endif
> +
>  #undef ASM_SPEC
>  #define ASM_SPEC  "%{mbig-endian|EB:-EB} %{EL} " \
>"%:cpu_to_as(%{mcpu=*:%*}) %{mspfp*} %{mdpfp*} %{mfpu=fpuda*:-mfpuda}"
> diff --git a/gcc/config/arc/elf.h b/gcc/config/arc/elf.h
> index 2b572a5..c5794f8 100644
> --- a/gcc/config/arc/elf.h
> +++ b/gcc/config/arc/elf.h
> @@ -26,7 +26,8 @@ along with GCC; see the file COPYING3.  If not see
>  
>  #define ARC_TLS_EXTRA_START_SPEC "crttls.o%s"
>  
> -#define EXTRA_SPECS \
> +#undef SUBTARGET_EXTRA_SPECS
> +#define SUBTARGET_EXTRA_SPECS \
>{ "arc_tls_extra_start_spec", ARC_TLS_EXTRA_START_SPEC }, \
>  
>  #undef STARTFILE_SPEC
> diff --git a/gcc/config/arc/linux.h b/gcc/config/arc/linux.h
> index 6e1a96e..83e5a1d 100644
> --- a/gcc/config/arc/linux.h
> +++ b/gcc/config/arc/linux.h
> @@ -78,3 +78,8 @@ along with GCC; see the file COPYING3.  If not see
>  /* Linux toolchains use r25 as the thread pointer register.  */
>  #undef TARGET_ARC_TP_REGNO_DEFAULT
>  #define TARGET_ARC_TP_REGNO_DEFAULT 25
> +
> +#undef SUBTARGET_CPP_SPEC
> +#define SUBTARGET_CPP_SPEC "\
> +   %{pthread:-D_REENTRANT} \
> +"
> -- 
> 1.9.1
> 

Re: [PATCH] [ARC] Update ARC SIMD patterns.

[Andrew Burgess]

* Claudiu Zissulescu  [2017-03-27 13:10:12 
+0200]:

> Hi Andrew,
> 
> vec_select expects in selection a list of subparts. The old ARC SIMD
> extension instructions were not up-to-date, update them.
> 
> Whithout this patch ARC backend is broken. It will be great if we can have it 
> in before gcc7.x branch is cut.
> 
> Thank you,
> Claudiu
> 
> gcc/
> 2017-03-27  Claudiu Zissulescu  
> 
>   * config/arc/simdext.md (vst64_insn): Update pattern.
>   (vld32wh_insn): Likewise.
>   (vld32wl_insn): Likewise.
>   (vld64_insn): Likewise.
>   (vld32_insn): Likewise.

Looks reasonable.

Thanks,
Andrew


> ---
>  gcc/config/arc/simdext.md | 98 
> ---
>  1 file changed, 67 insertions(+), 31 deletions(-)
> 
> diff --git a/gcc/config/arc/simdext.md b/gcc/config/arc/simdext.md
> index c9ec5f4..33bb330 100644
> --- a/gcc/config/arc/simdext.md
> +++ b/gcc/config/arc/simdext.md
> @@ -193,11 +193,16 @@
>  )
>  
>  (define_insn "vst64_insn"
> -  [(set  (mem:V4HI (plus:SI (zero_extend:SI (vec_select:HI 
> (match_operand:V8HI 0 "vector_register_operand"  "v")
> -   (parallel 
> [(match_operand:SI 1 "immediate_operand" "L")])))
> -(match_operand:SI 2 "immediate_operand" "P")))
> - (vec_select:V4HI (match_operand:V8HI 3 "vector_register_operand" "=v")
> -  (parallel [(const_int 0)])))]
> +  [(set  (mem:V4HI
> +  (plus:SI
> +   (zero_extend:SI
> +(vec_select:HI (match_operand:V8HI 0 "vector_register_operand"  "v")
> +   (parallel
> +[(match_operand:SI 1 "immediate_operand" "L")])))
> +   (match_operand:SI 2 "immediate_operand" "P")))
> + (vec_select:V4HI
> +  (match_operand:V8HI 3 "vector_register_operand" "=v")
> +  (parallel [(const_int 0) (const_int 1) (const_int 2) (const_int 3)])))]
>   "TARGET_SIMD_SET"
>   "vst64 %3, [i%1, %2]"
>   [(set_attr "type" "simd_vstore")
> @@ -1191,12 +1196,20 @@
> (set_attr "cond" "nocond")])
>  
>  (define_insn "vld32wh_insn"
> -  [(set (match_operand:V8HI 0 "vector_register_operand"   "=v")
> - (vec_concat:V8HI (zero_extend:V4HI (mem:V4QI (plus:SI (match_operand:SI 
> 1 "immediate_operand" "P")
> -   (zero_extend: SI 
> (vec_select:HI (match_operand:V8HI 2 "vector_register_operand"  "v")
> - 
>   (parallel [(match_operand:SI 3 "immediate_operand" "L")]))
> -  (vec_select:V4HI (match_dup 0)
> -   (parallel [(const_int 0)]]
> +  [(set (match_operand:V8HI 0 "vector_register_operand" "=v")
> + (vec_concat:V8HI
> +  (zero_extend:V4HI
> +   (mem:V4QI
> +(plus:SI
> + (match_operand:SI 1 "immediate_operand" "P")
> + (zero_extend:SI
> +  (vec_select:HI
> +   (match_operand:V8HI 2 "vector_register_operand"  "v")
> +   (parallel [(match_operand:SI 3 "immediate_operand" "L")]))
> +  (vec_select:V4HI
> +   (match_dup 0)
> +   (parallel [(const_int 0) (const_int 1) (const_int 2) (const_int 3)])
> +   )))]
>"TARGET_SIMD_SET"
>"vld32wh %0, [i%3,%1]"
>[(set_attr "type" "simd_vload")
> @@ -1204,12 +1217,20 @@
> (set_attr "cond" "nocond")])
>  
>  (define_insn "vld32wl_insn"
> -  [(set (match_operand:V8HI 0 "vector_register_operand"   "=v")
> - (vec_concat:V8HI (vec_select:V4HI (match_dup 0)
> -   (parallel [(const_int 1)]))
> -  (zero_extend:V4HI (mem:V4QI (plus:SI (match_operand:SI 
> 1 "immediate_operand" "P")
> -   (zero_extend: SI 
> (vec_select:HI (match_operand:V8HI 2 "vector_register_operand"  "v")
> - 
>   (parallel [(match_operand:SI 3 "immediate_operand" "L")])) 
> ))]
> +  [(set (match_operand:V8HI 0 "vector_register_operand" "=v")
> + (vec_concat:V8HI
> +  (vec_select:V4HI
> +   (match_dup 0)
> +   (parallel [(const_int 4) (const_int 5) (const_int 6) (const_int 7)]))
> +  (zero_extend:V4HI
> +   (mem:V4QI
> +(plus:SI
> + (match_operand:SI 1 "immediate_operand" "P")
> + (zero_extend:SI
> +  (vec_select:HI (match_operand:V8HI 2 "vector_register_operand" "v")
> + (parallel
> +  [(match_operand:SI 3 "immediate_operand" "L")]))
> +  ))]
>"TARGET_SIMD_SET"
>"vld32wl %0, [i%3,%1]"
>[(set_attr "type" "simd_vload")
> @@ -1229,12 +1250,19 @@
>  )
>  
>  (define_insn "vld64_insn"
> -  [(set (match_operand:V8HI 0 "vector_register_operand"   "=v")
> - 

Re: [PATCH #2, rs6000][GCC6] Fix PR78543, ICE in push_reload on powerpc64le-linux-gnu

[Michael Meissner]

On Fri, Mar 24, 2017 at 07:16:32PM -0500, Segher Boessenkool wrote:
> Hi Mike,
> 
> This patch is okay for trunk.  Also for 6, but what is the hurry there?

I applied the patch (svn id 246508 for trunk, svn id 246509 for gcc 6.0).  The
hurry up for GCC 6 is due to the fact that the bug does not show by default in
trunk (due to failing with RELOAD), but the bug shows up in GCC 6 (since RELOAD
is default there), and it affects some of the Linux distributions.

[gcc]
2017-03-27  Michael Meissner  

PR target/78543
* config/rs6000/rs6000.md (bswaphi2_extenddi): Combine bswap
HImode and SImode with zero extend to DImode to one insn.
(bswap2_extenddi): Likewise.
(bswapsi2_extenddi): Likewise.
(bswaphi2_extendsi): Likewise.
(bswaphi2): Combine bswap HImode and SImode into one insn.
Separate memory insns from swapping register.
(bswapsi2): Likewise.
(bswap2): Likewise.
(bswaphi2_internal): Delete, no longer used.
(bswapsi2_internal): Likewise.
(bswap2_load): Split bswap HImode/SImode into separate load,
store, and gpr<-gpr swap insns.
(bswap2_store): Likewise.
(bswaphi2_reg): Register only splitter, combine with the splitter.
(bswaphi2 splitter): Likewise.
(bswapsi2_reg): Likewise.
(bswapsi2 splitter): Likewise.
(bswapdi2): If we have the LDBRX and STDBRX instructions, split
the insns into load, store, and register/register insns.
(bswapdi2_ldbrx): Likewise.
(bswapdi2_load): Likewise.
(bswapdi2_store): Likewise.
(bswapdi2_reg): Likewise.

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

PR target/78543
* gcc.target/powerpc/pr78543.c: New test.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000.md
===
--- gcc/config/rs6000/rs6000.md (revision 246507)
+++ gcc/config/rs6000/rs6000.md (working copy)
@@ -2350,12 +2350,12 @@ (define_insn "cmpb3"
 
 ;; Since the hardware zeros the upper part of the register, save generating the
 ;; AND immediate if we are converting to unsigned
-(define_insn "*bswaphi2_extenddi"
+(define_insn "*bswap2_extenddi"
   [(set (match_operand:DI 0 "gpc_reg_operand" "=r")
(zero_extend:DI
-(bswap:HI (match_operand:HI 1 "memory_operand" "Z"]
+(bswap:HSI (match_operand:HSI 1 "memory_operand" "Z"]
   "TARGET_POWERPC64"
-  "lhbrx %0,%y1"
+  "lbrx %0,%y1"
   [(set_attr "length" "4")
(set_attr "type" "load")])
 
@@ -2368,34 +2368,52 @@ (define_insn "*bswaphi2_extendsi"
   [(set_attr "length" "4")
(set_attr "type" "load")])
 
-(define_expand "bswaphi2"
-  [(parallel [(set (match_operand:HI 0 "reg_or_mem_operand" "")
-  (bswap:HI
-   (match_operand:HI 1 "reg_or_mem_operand" "")))
- (clobber (match_scratch:SI 2 ""))])]
+;; Separate the bswap patterns into load, store, and gpr<-gpr.  This prevents
+;; the register allocator from converting a gpr<-gpr swap into a store and then
+;; load with byte swap, which can be slower than doing it in the registers.  It
+;; also prevents certain failures with the RELOAD register allocator.
+
+(define_expand "bswap2"
+  [(use (match_operand:HSI 0 "reg_or_mem_operand"))
+   (use (match_operand:HSI 1 "reg_or_mem_operand"))]
   ""
 {
-  if (!REG_P (operands[0]) && !REG_P (operands[1]))
-operands[1] = force_reg (HImode, operands[1]);
+  rtx dest = operands[0];
+  rtx src = operands[1];
+
+  if (!REG_P (dest) && !REG_P (src))
+src = force_reg (mode, src);
+
+  if (MEM_P (src))
+emit_insn (gen_bswap2_load (dest, src));
+  else if (MEM_P (dest))
+emit_insn (gen_bswap2_store (dest, src));
+  else
+emit_insn (gen_bswap2_reg (dest, src));
+  DONE;
 })
 
-(define_insn "bswaphi2_internal"
-  [(set (match_operand:HI 0 "reg_or_mem_operand" "=r,Z,")
+(define_insn "bswap2_load"
+  [(set (match_operand:HSI 0 "gpc_reg_operand" "=r")
+   (bswap:HSI (match_operand:HSI 1 "memory_operand" "Z")))]
+  ""
+  "lbrx %0,%y1"
+  [(set_attr "type" "load")])
+
+(define_insn "bswap2_store"
+  [(set (match_operand:HSI 0 "memory_operand" "=Z")
+   (bswap:HSI (match_operand:HSI 1 "gpc_reg_operand" "r")))]
+  ""
+  "stbrx %1,%y0"
+  [(set_attr "type" "store")])
+
+(define_insn_and_split "bswaphi2_reg"
+  [(set (match_operand:HI 0 "gpc_reg_operand" "=")
(bswap:HI
-(match_operand:HI 1 "reg_or_mem_operand" "Z,r,r")))
-   (clobber (match_scratch:SI 2 "=X,X,"))]
+(match_operand:HI 1 "gpc_reg_operand" "r")))
+   (clobber (match_scratch:SI 2 "="))]
   ""
-  "@
-   lhbrx %0,%y1
-   sthbrx %1,%y0
-   #"
-  [(set_attr "length" "4,4,12")
-   (set_attr "type" "load,store,*")])
-
-(define_split
-  [(set (match_operand:HI 0 

RE: [PATCH,testsuite] Skip pic-3,4.c and pie-3,4.c for mips*-*-linux-*.

[Matthew Fortune]

Toma Tabacu  writes:
> The pic-3,4.c and pie-3,4.c tests are failing for some configurations of
> mips*-*-linux-*.
> 
> This is because PIC is always on for MIPS Linux by default, except when the
> compiler is built with --with-mips-plt, in which case PIC is on by default 
> only
> for the n64 ABI, because in this case -mplt "has no effect without '-msym32'",
> to quote the documentation, so -mplt is not passed by default.
> 
> Richard Sandiford also talked about this in the summary of a patch which was
> skipping a test for mips*-*-linux-* because of PIC:
> https://gcc.gnu.org/ml/gcc-patches/2009-01/msg00801.html
> 
> Therefore, I think the most reasonable solution would be to just skip these
> tests for mips*-*-linux-*. The patch below does so.
> 
> Tested with mips-mti-linux-gnu.
> 
> Catherine, Matthew what do you think ?

Given the acceptance that MIPS PIC behaviour is semi-unique then checking MIPS
complies with the rules around pre-processor behaviour doesn't add much value.
I'm happy to skip these tests on the basis that software can't make the same
assumptions about MIPS and __PIC__ as other architectures do.

OK to commit.

Thanks,
Matthew

Re: Warning annoyances in list_read.c

[Dominique d'Humières]

> Le 27 mars 2017 à 20:34, Marek Polacek  a écrit :
> 
> On Mon, Mar 27, 2017 at 11:18:46AM -0700, Jerry DeLisle wrote:
>> Marek,
>> 
>> Flame wars can be a little fun once in a while.
>> 
>> I had previously tried the /* Fall through */ trick and it did not work as
>> Dominique clarified in his note. I had not tried putting it inside the Macro.
>> That makes it easy.
> 
> Yes, that's quite unfortunate (but known).  :(
> 
>> The hard part is catching these details/nuances on how things work.
> 
> Sure.  Too bad nobody brought this up to me.
> 
>> So we'll do this and move on.
> 
> Wholeheartedly agreed.
> 
>> PS Dominique Feel free to commit your patch
> 
> Thanks!
> 
>   Marek

Done as revision r246507.

Dominique

Re: [PATCH] Fix calls.c for a _complex type (PR ipa/80104).

[Jeff Law]

On 03/27/2017 05:40 AM, Martin Liška wrote:

Hello.

There's alternative approach suggested by Martin Jambor.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests and
s390x cross compiler does not ICE.

Martin


0001-Fix-calls.c-for-a-_complex-type-PR-ipa-80104.patch


From f9e40be62e525d29347339316073fae425b0d516 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Fri, 24 Mar 2017 15:47:34 +0100
Subject: [PATCH] Fix calls.c for a _complex type (PR ipa/80104).

gcc/ChangeLog:

2017-03-23  Martin Liska  

PR ipa/80104
* cgraphunit.c (cgraph_node::expand_thunk): Mark argument of a
thunk call as DECL_GIMPLE_REG_P when vector or complex type.
Can you fix the documentation for DECL_GIMPLE_REG_P to indiate that it 
can be set on parameters.


In gimplify_function_tree we have this:

 for (parm = DECL_ARGUMENTS (fndecl); parm ; parm = DECL_CHAIN (parm))
{
  /* Preliminarily mark non-addressed complex variables as eligible
 for promotion to gimple registers.  We'll transform their uses
 as we find them.  */
  if ((TREE_CODE (TREE_TYPE (parm)) == COMPLEX_TYPE
   || TREE_CODE (TREE_TYPE (parm)) == VECTOR_TYPE)
  && !TREE_THIS_VOLATILE (parm)
  && !needs_to_live_in_memory (parm))
DECL_GIMPLE_REG_P (parm) = 1;
}

Aren't you essentially doing the same thing for thunks?  Does it make 
sense to pull that into a little function and just call it from both places?


If not, do we need to add the !TREE_THIS_VOLATILE and 
!needs_to_live_in_memory checks to the thunks version?


Generally OK, just want to work through these couple niggling details.


jeff

Re: [PATCH] Don't cross-jump in between frame related and non-frame related insns (PR target/80102, take 4)

[Jeff Law]

On 03/26/2017 03:00 PM, Jakub Jelinek wrote:

Hi!

On Sat, Mar 25, 2017 at 07:45:53AM +0100, Jakub Jelinek wrote:

On Fri, Mar 24, 2017 at 06:37:46PM -0500, Segher Boessenkool wrote:

On Fri, Mar 24, 2017 at 08:36:16PM +0100, Jakub Jelinek wrote:

+ /* Skip over reg notes not related to CFI information.  */
+ while (n1)
+   {
+ for (i = 0; i < ARRAY_SIZE (cfa_note_kinds) - 1; i++)
+   if (REG_NOTE_KIND (n1) == cfa_note_kinds[i])
+ break;
+ if (i != ARRAY_SIZE (cfa_note_kinds))
+   break;
+ n1 = XEXP (n1, 1);
+   }


Maybe factor out reg_note_is_cfa_note and/or insns_have_identical_cfa_notes
functions?


Well, for the reg_note_is_cfa_note, actually it might be better to just
have a const bool array indexed by the note enum instead of the loop, I'll
implement it later.  And yes, I can outline insns_have_identical_cfa_notes.


Here is updated patch that does that, bootstrapped/regtested on
powerpc64le-linux, ok for trunk?

2017-03-26  Jakub Jelinek  

PR target/80102
* reg-notes.def (REG_CFA_NOTE): Define.  Use it for CFA related
notes.
* cfgcleanup.c (reg_note_cfa_p): New array.
(insns_have_identical_cfa_notes): New function.
(old_insns_match_p): Don't cross-jump in between /f
and non-/f instructions.  If both i1 and i2 are frame related,
verify all CFA notes, their order and content.

* g++.dg/opt/pr80102.C: New test.

OK.
jeff

Re: [PATCH] Fix r242743 change of gcc/system.h

[Jeff Law]

On 03/19/2017 03:17 PM, Gunther Nikl wrote:

Hello Paolo!

Building older GCC releases with clang tends to issue warnings. This
can be annoying especially when they originate from a header. While
backporting r242743 I noticed that the non-C++ cases of the changed
macro definitions in gcc/system.h are broken. Since GCC trunk is build
in C++ mode this is not an issue, but should be fixed nevertheless I
think.

Regards,
Gunther


gcc:
2017-03-XX  Gunther Nikl  

* system.h (HAVE_DESIGNATED_INITIALIZERS,
HAVE_DESIGNATED_UNION_INITIALIZERS): Fix non C++ case.

Thanks.  Installed.

jeff

[PATCH] Fix ICE in fold_comparison with -fsanitize=shift (PR sanitizer/80067)

[Marek Polacek]

The code in fold_comparison calls save_expr on an expression and then tries to
set a location of the expression.  But since save_expr calls fold, it can
produce an integer constant, so we must be more careful when setting its
location.  In this case we had

  (int) a > 646

where 'a' is signed char so we fold it to 0.

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

2017-03-27  Marek Polacek  

PR sanitizer/80067
* fold-const.c (fold_comparison): Use protected_set_expr_location
instead of SET_EXPR_LOCATION.

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

diff --git gcc/fold-const.c gcc/fold-const.c
index 1a9a264..6db16b5 100644
--- gcc/fold-const.c
+++ gcc/fold-const.c
@@ -8704,7 +8704,7 @@ fold_comparison (location_t loc, enum tree_code code, 
tree type,
  if (save_p)
{
  tem = save_expr (build2 (code, type, cval1, cval2));
- SET_EXPR_LOCATION (tem, loc);
+ protected_set_expr_location (tem, loc);
  return tem;
}
  return fold_build2_loc (loc, code, type, cval1, cval2);
diff --git gcc/testsuite/c-c++-common/ubsan/shift-10.c 
gcc/testsuite/c-c++-common/ubsan/shift-10.c
index e69de29..9202fcc 100644
--- gcc/testsuite/c-c++-common/ubsan/shift-10.c
+++ gcc/testsuite/c-c++-common/ubsan/shift-10.c
@@ -0,0 +1,10 @@
+/* PR sanitizer/80067 */
+/* { dg-do compile } */
+/* { dg-options "-fsanitize=shift" } */
+
+extern signed char a;
+void
+foo ()
+{
+  0 << ((647 > a) - 1);
+}

Marek

Re: [PATCH #2, rs6000][GCC6] Fix PR78543, ICE in push_reload on powerpc64le-linux-gnu

[Michael Meissner]

On Fri, Mar 24, 2017 at 07:16:32PM -0500, Segher Boessenkool wrote:
> Hi Mike,
> 
> On Fri, Mar 24, 2017 at 07:23:02PM -0400, Michael Meissner wrote:
> > Reload fumbles in certain conditions.
> 
> Yeah.  And it does not need bswap to get totally lost with this, so this
> patch is a workaround, not a fix.
> 
> It does make things nicer though :-)
> 
> > LRA generates working code, but the
> > store and the load with byte reverse from the same location, can slow things
> > down compared to the operation on registers.
> 
> How so?  You mean (say) lwbrx after doing a stw to that same address?
> We have that problem in general :-/

With the second code sample that shows the problem,

with:

-O1 -mlittle -mno-lra

the compiler aborts.  If you remove the -mno-lra (or use -mlra on GCC 6), the
compiler does not abort, however the code is sub-optimal.  LRA has the value in
a register it does:

lwa 9,108(1)
li 10,0
ori 10,10,0xc070
stdx 9,10,1
bl b

... other code

li 9,0
ori 9,9,0xc070
lwbrx 9,9,1

With my patches, it does:

lwa 14,108(1)
bl b

... other code

rotlwi 9,14,24
rlwimi 9,14,8,8,15
rlwimi 9,14,8,24,31

With -O3, it generates the same code (more or less) with both register 
allocators.

Sure, it would be nice to fold the bswap with the original load.


> 
> Thanks for the extensive testing.
> 
> > Can I apply the patch to the GCC 7 trunk?  Since the patch shows up as an 
> > abort
> > in GCC 6 and not in GCC 7 (unless you disable LRA), I would like to apply 
> > the
> > patch as soon as possible to the GCC 6 branch.
> 
> A few remarks:
> 
> > +; Types that have hardware load/store with byte reverse
> > +(define_mode_iterator BSWAP [HI
> > +SI
> > +(DI "TARGET_POWERPC64 && TARGET_LDBRX")])
> 
> The patch would be much easier to read if you had done this step (with HSI
> as well) separately.  Oh well.

Actually, I developed it that way, and I can easily go back to that.  I thought
I would be dinged because I didn't combine them. :-)

> > +(define_expand "bswap2"
> 
> > +  if (MEM_P (src))
> > +emit_insn (gen_bswap2_load (dest, src));
> > +  else
> > +{
> > +  if (MEM_P (dest))
> > +   emit_insn (gen_bswap2_store (dest, src));
> > +  else
> > +   emit_insn (gen_bswap2_reg (dest, src));
> > +}
> > +  DONE;
> 
> Please avoid the extra nesting, i.e. do
> 
> +  if (MEM_P (src))
> +emit_insn (gen_bswap2_load (dest, src));
> +  else if (MEM_P (dest))
> +emit_insn (gen_bswap2_store (dest, src));
> +  else
> +emit_insn (gen_bswap2_reg (dest, src));
> +  DONE;

Ok.  The patch originally had a force_reg in there, and I removed it when it
didn't seem necessary any more.

> (also for bswapdi2).
> 
> > +  [(set_attr "length" "12")
> > +   (set_attr "type" "*")])
> 
> Lose that last line?  You don't need to explicitly set things to their
> default value ;-)
> OTOH, you might want to make it type "three" instead?
> 
> > +  [(set_attr "length" "36")
> > +   (set_attr "type" "*")])
> 
> Same.
> 
> This patch is okay for trunk.  Also for 6, but what is the hurry there?

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797

Re: [C/C++ PATCH] Fix ICEs with vector subscripting of register variables (PR middle-end/80162)

[Marek Polacek]

On Mon, Mar 27, 2017 at 12:06:03PM -0400, Jason Merrill wrote:
> On Fri, Mar 24, 2017 at 2:55 PM, Jakub Jelinek  wrote:
> > c*_mark_addressable doesn't look through VIEW_CONVERT_EXPRs that
> > vector subscripts are turned into, which means we don't diagnose
> > taking address of e.g. a vector element in a hard register.
> >
> > On the other side, I think we want to support just normal vector
> > subscripting of vectors in hard registers, that can be expanded
> > into e.g. vector shift etc.
> >
> > So, this patch handles specially c*_mark_addressable calls from
> > array_ref building, otherwise diagnoses taking addresses of
> > vector elements in hard registers.
> >
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> OK if C doesn't object.

I'm fine with the C parts but I think you should use VECTOR_TYPE_P
(two spots).

Marek

Re: [C/C++ PATCH] Fix ICEs with vector subscripting of register variables (PR middle-end/80162)

[Jason Merrill]

On Fri, Mar 24, 2017 at 2:55 PM, Jakub Jelinek  wrote:
> c*_mark_addressable doesn't look through VIEW_CONVERT_EXPRs that
> vector subscripts are turned into, which means we don't diagnose
> taking address of e.g. a vector element in a hard register.
>
> On the other side, I think we want to support just normal vector
> subscripting of vectors in hard registers, that can be expanded
> into e.g. vector shift etc.
>
> So, this patch handles specially c*_mark_addressable calls from
> array_ref building, otherwise diagnoses taking addresses of
> vector elements in hard registers.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK if C doesn't object.

Jason

Re: PATCH for Re: Release notes for GCC 7?

[Joseph Myers]

On Mon, 27 Mar 2017, carl hansen wrote:

> suggested additions:
> 
> get and insert the latest libtool, which includes files:
> libtool.m4  ltgcc.m4  lt~obsolete.m4  ltoptions.m4  ltsugar.m4  ltversion.m4,
> all way-old currently in gcc-7

libtool and auto* updates are only reasonable in development stage 1.  
They are highly riskly changes that require extensive testing in a range 
of native, cross and Canadian cross configurations.  (And a reminder of 
the need to revert libtool commit 
3334f7ed5851ef1e96b052f2984c4acdbf39e20c, see 
.)

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

Re: [PATCH] Fix expansion of initializer extensions (PR c/80163)

[Jeff Law]

On 03/24/2017 12:58 PM, Jakub Jelinek wrote:

Hi!

As can be seen on the following testcase, when expanding an extension
in EXPAND_INITIALIZER context, we emit wrong extension operation
(one depending on the signedness of the result type rather than
on the signedness of the argument type, so e.g. extension of
unsigned int to long long int is done using SIGN_EXTEND instead of
ZERO_EXTEND, and extension of int to unsigned long long int using
ZERO_EXTEND instead of SIGN_EXTEND.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?

2017-03-24  Jakub Jelinek  

PR c/80163
* expr.c : For EXPAND_INITIALIZER determine SIGN_EXTEND
vs. ZERO_EXTEND based on signedness of treeop0's type rather than
signedness of the result type.

* gcc.dg/torture/pr80163.c: New test.

--- gcc/expr.c.jj   2017-03-07 09:04:04.0 +0100
+++ gcc/expr.c  2017-03-24 12:09:57.729854079 +0100
@@ -8333,7 +8333,8 @@ expand_expr_real_2 (sepops ops, rtx targ
}

   else if (modifier == EXPAND_INITIALIZER)
-   op0 = gen_rtx_fmt_e (unsignedp ? ZERO_EXTEND : SIGN_EXTEND, mode, op0);
+   op0 = gen_rtx_fmt_e (TYPE_UNSIGNED (TREE_TYPE (treeop0))
+? ZERO_EXTEND : SIGN_EXTEND, mode, op0);

?!?

Shouldn't the zero/sign extension be derived from the target's type not 
the source types?


treeop0 is the first source operand, isn't it?

Am I missing something here?
jeff

Re: [PATCH] Reject > word sign extensions in initializers (PR middle-end/80163)

[Jeff Law]

On 03/24/2017 01:27 PM, Jakub Jelinek wrote:

Hi!

I'm not aware of any target that would support sign extension of
something that can't be folded in the compiler into some type
larger than word/pointer.  Zero extension is doable and assemble_variable
is able to deal with it by emitting low/high subregs of it (where the
low one will contain some expression that needs to be computed by assembler
or even have relocation and upper part will be all zeros), but for
sign extension we'd need assembler support that would for some
asm expression shift it arithmetically right.

So, this patch just rejects it in initializers (in C++ handles through
dynamic initialization) in that case.  clang also rejects it, ICC silently
miscompiles (performs zero extension).

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

2017-03-24  Jakub Jelinek  

PR middle-end/80163
* varasm.c (initializer_constant_valid_p_1): Disallow sign-extending
conversions to integer types wider than word and pointer.

* gcc.dg/pr80163.c: New test.
FWIW, the old PA 32 bit SOM model had relocations that would allow 
supporting this case.  We never exposed them as never seemed worth the 
effort, given it's a relatively obscure issue on a dead platform, I 
don't think it's worth trying to do anything to support it there.


OK for the trunk.

jeff

Re: [PATCH] Real fix for AIX exception handling

[David Edelsohn]

> As far as I have discovered, the real problem with AIX exception handling is
> that the exception landing pads are symbols that must not (but still are)
> exported from shared libraries - even libstdc++.
>
> I'm wondering if attached libtool(!)-patch would fix even that GDB problem
> once applied to each(!) shared library creation procedure.
>
> However, each workaround still applies as long as there's a single shared
> library involved that has not stopped exporting these symbols yet.
>
> Thoughts?
>
> Maybe gcc's collect2 should apply this additional symbol filter itself when
> calling (AIX) ld, rather than leaving this to each build system?
>
> * m4/libtool.m4 (_LT_LINKER_SHLIBS): On AIX, GNU g++ generates
> _GLOBAL__ symbols as, amongst others, landing pads for C++ exceptions.
> These symbols must not be exported from shared libraries, or exception
> handling may break for applications with runtime linking enabled.

Hi, Michael

Thanks for the analysis.

The problem with EH for GDB involves static linking, not runtime
linking. And there seems to be different behavior for GCC 4.8 and GCC
4.9.

The patch seems correct for the runtime linking case, but I don't
believe that it solves all of the EH issues -- at least more
explanation is needed.

I think that the problem for static linking needs to be addressed by collect2.

Thanks, David

P.S. Please explicitly copy me on AIX patches.

Re: [PATCH] avoid cselib rtx_equal_for_cselib_1 infinite recursion (PR debug/80025)

[Jeff Law]

On 03/23/2017 02:39 PM, Jakub Jelinek wrote:

Hi!

On Thu, Mar 23, 2017 at 03:00:04PM +0100, Jakub Jelinek wrote:

On Tue, Mar 21, 2017 at 07:43:51PM -0300, Alexandre Oliva wrote:

When two VALUEs are recorded in the cselib equivalence table such that
they are equivalent to each other XORed with the same expression, if
we started a cselib equivalence test between say the odd one and the
even one, we'd end up recursing to compare the even one with the odd
one, and then again, indefinitely.

This patch cuts off this infinite recursion by recognizing the XOR
special case (it's the only binary commutative operation in which
applying one of the operands of an operation to the result of that
operation brings you back to the other operand) and determining
whether we have an equivalence without recursing down the infinite
path.


Is XOR the only special case though?  E.g. PLUS or MINUS with
the most negative constant act the same, and I don't see why if unlucky
enough with reverse ops etc. you couldn't get something similar through
combination thereof, perhaps indirectly through multiple VALUEs.

So I think it is safer to just put a cap on the rtx_equal_for_cselib_1
recursion depth (should be enough to bump the depth only when walking
locs of a VALUE).  I'll test such a patch.


Here is that patch, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?  Or shall I turn that 128 into a --param?

2017-03-23  Jakub Jelinek  

PR debug/80025
* cselib.h (rtx_equal_for_cselib_1): Add depth argument.
(rtx_equal_for_cselib_p): Pass 0 to it.
* cselib.c (cselib_hasher::equal): Likewise.
(rtx_equal_for_cselib_1): Add depth argument.  If depth
is 128, don't look up VALUE locs and punt.  Increment
depth in recursive calls when walking VALUE locs.

* gcc.dg/torture/pr80025.c: New test.

I don't think the depth for this case is worth exposing as a PARAM.


OK for the trunk.

Thanks,
Jeff

[doc] install.texi -- update www-01.ibm.com link

[Gerald Pfeifer]

www-01.ibm.com switched back to www.ibm.com and to https by default,
two changes I followed via the patch below.

Looking at the interesting URL and having found
https://www.ibm.com/support/knowledgecenter/ssw_aix_72/com.ibm.aix.cmds3/ld.html
(which is version-specific, but the latest and I don't think AIX 
does a new release multiple times a year), would it make sense to
use that link instead?

Let me know what you prefer.  I can make that change as a follow-up.

Gerald

2017-03-25  Gerald Pfeifer  

* doc/install.texi (Configuration) <--with-aix-soname>:
Update link to AIX ld.

Index: doc/install.texi
===
--- doc/install.texi(revision 246473)
+++ doc/install.texi(working copy)
@@ -1512,7 +1512,7 @@
 filenames with the @samp{-lNAME} linker flag.
 
 @anchor{AixLdCommand}For detailed information please refer to the AIX
-@uref{http://www-01.ibm.com/support/knowledgecenter/search/%22the%20ld%20command%2C%20also%20called%20the%20linkage%20editor%20or%20binder%22,,ld
+@uref{https://www.ibm.com/support/knowledgecenter/search/%22the%20ld%20command%2C%20also%20called%20the%20linkage%20editor%20or%20binder%22,,ld
 Command} reference.
 
 As long as shared library creation is enabled, upon:

Re: [PATCH] Handle PHI nodes w/o a argument (PR ipa/80205).

[Jeff Law]

On 03/27/2017 08:27 AM, Richard Biener wrote:

On Mon, Mar 27, 2017 at 4:14 PM, Richard Biener
 wrote:

On Mon, Mar 27, 2017 at 2:47 PM, Martin Liška  wrote:

Hello.

As described in the PR, we can create a PHI node in einline that has no 
argument.
That can cause ICE in devirtualization and should be thus handled.

Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.

Ready to be installed?


We shouldn't ever have a PHI w/o argument.


;;   basic block 14, loop depth 0
;;pred:
  # SR.2_19 = PHI <>
 [0.00%]:
  a::~a ();
  resx 12
;;succ:   17

the CFG has not been cleaned up here (this block is unreachable).

Hmm, I see we are called from fold_stmt.  I suppose we process
statements_to_fold before removing unreachable blocks to not
walk over dead stmts...  chicken-and-egg...

Still not creating that PHI should be possible.
Can't speak for this specific example, but could it be the case that the 
PHI exists with arguments, then becomes unreachable resulting in a PHI 
with no arguments?


jeff

Re: [v3 PATCH] Slight cleanup of tuple constraints.

[Jonathan Wakely]

On 27/03/17 17:44 +0300, Ville Voutilainen wrote:

This is not something that should go in at this stage, but I'm sending
it for review. Dinka quite astutely pointed out that the sizeof...(_Elements)>=1
tests seem unnecessary, and they are;

1) the helper aliases _TCC and _TMC already check that the incoming
pack and the element pack have the same size
2) if the element pack is empty, we wouldn't use these constructors
anyway, since we have a specialization for a zero-element tuple...
3) ...except that for the one taking const _Elements& we might, for
class template argument deduction cases, but we have a deduction
guide that deduces the zero-element specialization for 'tuple t;' so
we still won't use these constructors.


Sounds right, so this looks good for Stage 1.

[PATCH] Fix s390 testcase vcond-shift

[Robin Dapp]

Hi,

this patch fixes the vcond shift testcase that failed since setting
PARAM_MIN_VECT_LOOP_BOUND in the s390 backend.

Regards
 Robin

--

gcc/testsuite/ChangeLog:

2017-03-27  Robin Dapp  

* gcc.target/s390/vector/vcond-shift.c (void foo): Increase
iteration count and assume alignment.
(void foo2): Likewise.
(void foo3): Likewise.
(int baz): Likewise.
(int baf): Likewise.
(int bal): Likewise.
diff --git a/gcc/testsuite/gcc.target/s390/vector/vcond-shift.c b/gcc/testsuite/gcc.target/s390/vector/vcond-shift.c
index f58bd1f..cc40153 100644
--- a/gcc/testsuite/gcc.target/s390/vector/vcond-shift.c
+++ b/gcc/testsuite/gcc.target/s390/vector/vcond-shift.c
@@ -11,51 +11,63 @@
 /* { dg-final { scan-assembler "vesrlh\t%v.?,%v.?,15" } } */
 /* { dg-final { scan-assembler "vesrlb\t%v.?,%v.?,7" } } */
 
-#define SZ 4
-#define SZ2 8
-#define SZ3 16
+#define SZ 8
+#define SZ2 16
+#define SZ3 32
 
 void foo(int *w)
 {
   int i;
-  /* Should expand to (w + (w < 0 ? 1 : 0)) >> 1
- which in turn should get simplified to (w + (w >> 31)) >> 1.  */
+  int *ww = __builtin_assume_aligned (w, 8);
+
+  /* Should expand to (ww + (ww < 0 ? 1 : 0)) >> 1
+ which in turn should get simplified to (ww + (ww >> 31)) >> 1.  */
   for (i = 0; i < SZ; i++)
-w[i] = w[i] / 2;
+ww[i] = ww[i] / 2;
 }
 
 void foo2(short *w)
 {
   int i;
+  short *ww = __builtin_assume_aligned (w, 8);
+
   for (i = 0; i < SZ2; i++)
-w[i] = w[i] / 2;
+ww[i] = ww[i] / 2;
 }
 
 
 void foo3(signed char *w)
 {
   int i;
+  signed char *ww = __builtin_assume_aligned (w, 8);
+
   for (i = 0; i < SZ3; i++)
-w[i] = w[i] / 2;
+ww[i] = ww[i] / 2;
 }
 
 int baz(int *x)
 {
   int i;
+  int *xx = __builtin_assume_aligned (x, 8);
+
   for (i = 0; i < SZ; i++)
-x[i] = x[i] < 0 ? -1 : 0;
+xx[i] = xx[i] < 0 ? -1 : 0;
 }
 
 int baf(short *x)
 {
   int i;
+  short *xx = __builtin_assume_aligned (x, 8);
+
   for (i = 0; i < SZ2; i++)
-x[i] = x[i] >= 0 ? 0 : 1;
+xx[i] = xx[i] >= 0 ? 0 : 1;
 }
 
 int bal(signed char *x)
 {
   int i;
+  signed char *xx = __builtin_assume_aligned (x, 8);
+
   for (i = 0; i < SZ3; i++)
-x[i] = x[i] >= 0 ? 0 : -1;
+xx[i] = xx[i] >= 0 ? 0 : -1;
 }

Re: [PATCH 1/5] nvptx: implement SIMT enter/exit insns

[Bernd Schmidt]

On 03/27/2017 12:56 PM, Alexander Monakov wrote:

Hello Bernd,

Can you have a look at this patch (unchanged from previous posting in January)?
The rest of the patches in the set are reviewed.

On Wed, 22 Mar 2017, Alexander Monakov wrote:


This patch adds handling of new omp_simt_enter/omp_simt_exit named insns
in the NVPTX backend.

* config/nvptx/nvptx-protos.h (nvptx_output_simt_enter): Declare.
(nvptx_output_simt_exit): Declare.
* config/nvptx/nvptx.c (nvptx_init_unisimt_predicate): Use
cfun->machine->unisimt_location.  Handle NULL unisimt_predicate.
(init_softstack_frame): Move initialization of crtl->is_leaf to...
(nvptx_declare_function_name): ...here.  Emit declaration of local
memory space buffer for omp_simt_enter insn.
(nvptx_output_unisimt_switch): New.
(nvptx_output_softstack_switch): New.
(nvptx_output_simt_enter): New.
(nvptx_output_simt_exit): New.
* config/nvptx/nvptx.h (struct machine_function): New fields
has_simtreg, unisimt_location, simt_stack_size, simt_stack_align.
* config/nvptx/nvptx.md (UNSPECV_SIMT_ENTER): New unspec.
(UNSPECV_SIMT_EXIT): Ditto.
(omp_simt_enter_insn): New insn.
(omp_simt_enter): New expansion.
(omp_simt_exit): New insn.
* config/nvptx/nvptx.opt (msoft-stack-reserve-local): New option.


Technically this whole series isn't a regression fix, but since Jakub 
has acked the rest, this is OK too.



Bernd

[v3 PATCH] Slight cleanup of tuple constraints.

[Ville Voutilainen]

This is not something that should go in at this stage, but I'm sending
it for review. Dinka quite astutely pointed out that the sizeof...(_Elements)>=1
tests seem unnecessary, and they are;

1) the helper aliases _TCC and _TMC already check that the incoming
pack and the element pack have the same size
2) if the element pack is empty, we wouldn't use these constructors
anyway, since we have a specialization for a zero-element tuple...
3) ...except that for the one taking const _Elements& we might, for
class template argument deduction cases, but we have a deduction
guide that deduces the zero-element specialization for 'tuple t;' so
we still won't use these constructors.

When stage1 for gcc 8 opens, I expect to clean up tuple's constraints
a bit anyway: there's no actual need to have, for instance, _ConstructibleTuple
and _MoveConstructibleTuple separately. However, that's a topic for another day,
as mentioned.

Tested on Linux-x64.

2017-03-27  Ville Voutilainen  

Slight cleanup of tuple constraints.
* include/std/tuple (tuple(const _Elements&...)): Strike
the unnecessary sizeof... test.
(tuple(_UElements&&...)): Likewise.
* testsuite/20_util/tuple/element_access/get_neg.cc: Adjust.
diff --git a/libstdc++-v3/include/std/tuple b/libstdc++-v3/include/std/tuple
index 1f5365a..8af581c 100644
--- a/libstdc++-v3/include/std/tuple
+++ b/libstdc++-v3/include/std/tuple
@@ -602,8 +602,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  _TCC<_Dummy>::template
_ConstructibleTuple<_Elements...>()
  && _TCC<_Dummy>::template
-   _ImplicitlyConvertibleTuple<_Elements...>()
- && (sizeof...(_Elements) >= 1),
+   _ImplicitlyConvertibleTuple<_Elements...>(),
bool>::type=true>
 constexpr tuple(const _Elements&... __elements)
   : _Inherited(__elements...) { }
@@ -613,8 +612,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  _TCC<_Dummy>::template
_ConstructibleTuple<_Elements...>()
  && !_TCC<_Dummy>::template
-   _ImplicitlyConvertibleTuple<_Elements...>()
- && (sizeof...(_Elements) >= 1),
+   _ImplicitlyConvertibleTuple<_Elements...>(),
bool>::type=false>
   explicit constexpr tuple(const _Elements&... __elements)
   : _Inherited(__elements...) { }
@@ -640,8 +638,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  _TMC<_UElements...>::template
 _MoveConstructibleTuple<_UElements...>()
   && _TMC<_UElements...>::template
-_ImplicitlyMoveConvertibleTuple<_UElements...>()
-  && (sizeof...(_Elements) >= 1),
+_ImplicitlyMoveConvertibleTuple<_UElements...>(),
 bool>::type=true>
 constexpr tuple(_UElements&&... __elements)
 : _Inherited(std::forward<_UElements>(__elements)...) { }
@@ -651,8 +648,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  _TMC<_UElements...>::template
 _MoveConstructibleTuple<_UElements...>()
   && !_TMC<_UElements...>::template
-_ImplicitlyMoveConvertibleTuple<_UElements...>()
-  && (sizeof...(_Elements) >= 1),
+_ImplicitlyMoveConvertibleTuple<_UElements...>(),
 bool>::type=false>
 explicit constexpr tuple(_UElements&&... __elements)
: _Inherited(std::forward<_UElements>(__elements)...) { }
diff --git a/libstdc++-v3/testsuite/20_util/tuple/element_access/get_neg.cc 
b/libstdc++-v3/testsuite/20_util/tuple/element_access/get_neg.cc
index 03835f4..6648d5e 100644
--- a/libstdc++-v3/testsuite/20_util/tuple/element_access/get_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/tuple/element_access/get_neg.cc
@@ -17,7 +17,7 @@
 
 // { dg-options "-fno-show-column" }
 // { dg-do compile { target c++14 } }
-// { dg-error "in range" "" { target *-*-* } 1297 }
+// { dg-error "in range" "" { target *-*-* } 1293 }
 
 #include 
 

[pushed/ob] cplus_demangle_fill_component: Handle DEMANGLE_COMPONENT_RVALUE_REFERENCE (Re: [PATCH] libiberty: Initialize d_printing in all cplus_demangle_* functions.)

[Pedro Alves]

[added back gcc-patches, obvious libiberty patch below]

On 03/14/2017 10:50 AM, Pedro Alves wrote:
> On 03/14/2017 09:04 AM, Mark Wielaard wrote:
> 
>> That looks good. But note that there is one behavioral change.
>> cplus_demangle_fill_component is defined as:
>>
>> /* Fill in most component types with a left subtree and a right
>>subtree.  Returns non-zero on success, zero on failure, such as an
>>unrecognized or inappropriate component type.  */
>>
>> And gdb/cp-name-parser.y fill_comp does:
>>
>>   i = cplus_demangle_fill_component (ret, d_type, lhs, rhs);
>>   gdb_assert (i);
>>
>> So you have an extra sanity check. Where before you might have silently
>> created a bogus demangle_component. Which I assume is what you want.
> 
> Indeed, and I think it is.
> 
>> But it might depend on what gdb_assert precisely does 
> 
> gdb_assert triggers the infamous:
> 
>  A problem internal to GDB has been detected,
>  further debugging may prove unreliable.
>  Quit this debugging session? (y or n) 
> 
>> and if the parser input is normally "sane" or not.
> 
> The only thing that is validated is that we don't create
> a component with a left/right subtree when that doesn't make sense
> for the component type.  I think trying to create such a component
> would be a parser/grammar/production bug, even with invalid input.
> 
> I had run into that assert in fill_comp yesterday actually, with a slightly
> different/larger patch.  At first I saw the cplus_demangle_fill_component
> declaration in demangle.h, but didn't see the implementation in 
> cp-demangle.c, and
> thought that was just some oversight/left over.  So I though I'd add one.  I 
> factored
> out a cplus_demangle_fill_component out of cp-demangle.c:d_make_comp, 
> following the
> same pattern used by the other cplus_demangle_fill* / d_make* function pairs. 
>  
> Only after did I notice that actually, there's an implementation of
> cplus_demangle_fill_component in cplus-demint.c...  AFAICS, that's only
> used by GDB.  No other tool in the binutils-gdb repo, nor GCC's repo uses it, 
> AFAICS.
> So I figured that I'd remove the cplus-demint.c implementation, in favor of
> the new implementation in cp-demangle.c based on d_make_comp.  And _that_ ran 
> into the
> assertion, because the implementations are exactly the same.  GDB fills in 
> some types with
> NULL left components and fills them in later.  For example, for 
> DEMANGLE_COMPONENT_POINTER:
> 
>  ptr_operator   :   '*' qualifiers_opt
> -   { $$.comp = make_empty (DEMANGLE_COMPONENT_POINTER);
> - $$.comp->u.s_binary.left = 
> $$.comp->u.s_binary.right = NULL;
> +   { $$.comp = fill_comp (DEMANGLE_COMPONENT_POINTER, 
> NULL, NULL);
>   $$.last = _left ($$.comp);
>   $$.comp = d_qualify ($$.comp, $2, 0); }
> 
> Note how cp-demangle.c:d_make_comp's validations are stricter than 
> cp-demint.c:cplus_demangle_fill_component's.  The former only allows 
> lazy-filling for a few cases:
> 
> [...]
>   /* These are allowed to have no parameters--in some cases they
>will be filled in later.  */
> case DEMANGLE_COMPONENT_FUNCTION_TYPE:
> [...]
> 
> While cp-demint.c:cplus_demangle_fill_component, the version that
> GDB uses, allows that in all cases.  IOW, passing in a NULL left/right subtree
> to cplus_demangle_fill_component when the component type expects one is OK, 
> assuming
> that the caller will fill them in afterwards.  I crossed checked the types in
> the new fill_comp calls with the checks inside cplus_demangle_fill_component 
> now,
> and I believe they're all OK.
> 
> Maybe it'd be possible to avoid this lazy filling in, but I didn't
> bother trying.

Funny enough, I was going to apply the gdb patch today, but 
gdb meanwhile gained a new make_empty call for
DEMANGLE_COMPONENT_RVALUE_REFERENCE, and making that new code
use fill_comp/cplus_demangle_fill_component too triggered the
sanity check discussed above...  This is just a latent bug
being exposed now.

I've pushed the obvious patch below to both gcc trunk and binutils-gdb master.

>From b1a42fdfa31937d7e05df34afee970ac0ad239e1 Mon Sep 17 00:00:00 2001
From: Pedro Alves 
Date: Mon, 27 Mar 2017 13:56:49 +0100
Subject: [PATCH] cplus_demangle_fill_component: Handle
 DEMANGLE_COMPONENT_RVALUE_REFERENCE

This patch almost a decade ago:

...
2007-08-31  Douglas Gregor  

* cp-demangle.c (d_dump): Handle
DEMANGLE_COMPONENT_RVALUE_REFERENCE.
(d_make_comp): Ditto.
...

... missed doing the same change to cplus_demangle_fill_component that
was done to d_make_comp.  I.e., teach it to only validate that we're
not passing in a "right" subtree.  GDB has recently (finally) learned
about rvalue references, and a change to make it use
cplus_demangle_fill_component more ran into an assertion because of
this.

(GDB is the only user of 

Re: [PATCH] Handle PHI nodes w/o a argument (PR ipa/80205).

[Richard Biener]

On Mon, Mar 27, 2017 at 4:14 PM, Richard Biener
 wrote:
> On Mon, Mar 27, 2017 at 2:47 PM, Martin Liška  wrote:
>> Hello.
>>
>> As described in the PR, we can create a PHI node in einline that has no 
>> argument.
>> That can cause ICE in devirtualization and should be thus handled.
>>
>> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>>
>> Ready to be installed?
>
> We shouldn't ever have a PHI w/o argument.

;;   basic block 14, loop depth 0
;;pred:
  # SR.2_19 = PHI <>
 [0.00%]:
  a::~a ();
  resx 12
;;succ:   17

the CFG has not been cleaned up here (this block is unreachable).

Hmm, I see we are called from fold_stmt.  I suppose we process
statements_to_fold before removing unreachable blocks to not
walk over dead stmts...  chicken-and-egg...

Still not creating that PHI should be possible.

Index: gcc/tree-inline.c
===
--- gcc/tree-inline.c   (revision 246500)
+++ gcc/tree-inline.c   (working copy)
@@ -2344,6 +2344,13 @@ copy_phis_for_bb (basic_block bb, copy_b
   if (!virtual_operand_p (res))
{
  walk_tree (_res, copy_tree_body_r, id, NULL);
+ if (EDGE_COUNT (new_bb->preds) == 0)
+   {
+ /* Technically we'd want a SSA_DEFAULT_DEF here... */
+ SSA_NAME_DEF_STMT (new_res) = gimple_build_nop ();
+   }
+ else
+   {
  new_phi = create_phi_node (new_res, new_bb);
  FOR_EACH_EDGE (new_edge, ei, new_bb->preds)
{
@@ -2389,6 +2396,7 @@ copy_phis_for_bb (basic_block bb, copy_b

  add_phi_arg (new_phi, new_arg, new_edge, locus);
}
+   }
}
 }



>> Martin

Re: [PATCH] Handle PHI nodes w/o a argument (PR ipa/80205).

[Jeff Law]

On 03/27/2017 08:14 AM, Richard Biener wrote:

On Mon, Mar 27, 2017 at 2:47 PM, Martin Liška  wrote:

Hello.

As described in the PR, we can create a PHI node in einline that has no 
argument.
That can cause ICE in devirtualization and should be thus handled.

Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.

Ready to be installed?


We shouldn't ever have a PHI w/o argument.

Yea.  Sounds like there's a deeper problem somewhere.

jeff

Re: [PATCH] Handle PHI nodes w/o a argument (PR ipa/80205).

[Richard Biener]

On Mon, Mar 27, 2017 at 2:47 PM, Martin Liška  wrote:
> Hello.
>
> As described in the PR, we can create a PHI node in einline that has no 
> argument.
> That can cause ICE in devirtualization and should be thus handled.
>
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>
> Ready to be installed?

We shouldn't ever have a PHI w/o argument.

> Martin

Re: [testsuite] Add missing dg-require-effective-target alloca to gcc testsuite

[Tom de Vries]

On 24/03/17 18:13, Mike Stump wrote:

On Mar 24, 2017, at 5:58 AM, Rainer Orth  wrote:

-  { /* { dg-warning "statement may fall through" "" { target c } 23 } */
-   int a[i]; /* { dg-warning "statement may fall through" "" { target c++ 
} 24 } */
+  { /* { dg-warning "statement may fall through" "" { target c } 24 } */
+   int a[i]; /* { dg-warning "statement may fall through" "" { target c++ 
} 25 } */


Any reason to not use relative line numbers?  See testsuite/gcc.dg/dg-test-1.c 
for a template for how to do it.  I think they should work and be better.  
Indeed, all line numbers should be relative, generally speaking.



FYI, I've written a script to convert all tests to relative line 
numbers. See PR80221 - "Contrib script to rewrite testcase from absolute 
to relative line numbers" ( 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80221 ).


Thanks,
- Tom

Re: [testsuite] Add missing dg-require-effective-target alloca to gcc testsuite

[Tom de Vries]

On 24/03/17 13:38, Rainer Orth wrote:

Hi Tom,


On 23/03/17 18:25, Mike Stump wrote:

On Mar 23, 2017, at 8:46 AM, Tom de Vries  wrote:

I've run the gcc testsuite for target nvptx-none and ran into "test for
excess errors" FAILs due to:
...
sorry, unimplemented: target cannot support alloca.

We'd encourage ports to support alloca.  :-)


OK for trunk for stage1?

Ok.  Ok for release branches and trunk as well, if you want.  I'd
recommend trunk, if your port is meant to work and test out nicely in gcc
7.


Committed to trunk.

seems you didn't properly test this patchset.


Sorry, indeed I just tested the non-alloca target, but forgot the alloca 
target.


Thanks for cleaning up the mess.

- Tom

[PATCH] Fix PR80181

[Richard Biener]

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

Richard.

2017-03-27  Richard Biener  

PR tree-optimization/80181
* tree-ssa-ccp.c (likely_value): UNDEFINED ^ X is UNDEFINED.

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

Index: gcc/tree-ssa-ccp.c
===
*** gcc/tree-ssa-ccp.c  (revision 246490)
--- gcc/tree-ssa-ccp.c  (working copy)
*** likely_value (gimple *stmt)
*** 741,749 
case PLUS_EXPR:
case MINUS_EXPR:
case POINTER_PLUS_EXPR:
  /* Not MIN_EXPR, MAX_EXPR.  One VARYING operand may be selected.
 Not bitwise operators, one VARYING operand may specify the
!result completely.  Not logical operators for the same reason.
 Not COMPLEX_EXPR as one VARYING operand makes the result partly
 not UNDEFINED.  Not *DIV_EXPR, comparisons and shifts because
 the undefined operand may be promoted.  */
--- 741,751 
case PLUS_EXPR:
case MINUS_EXPR:
case POINTER_PLUS_EXPR:
+   case BIT_XOR_EXPR:
  /* Not MIN_EXPR, MAX_EXPR.  One VARYING operand may be selected.
 Not bitwise operators, one VARYING operand may specify the
!result completely.
!Not logical operators for the same reason, apart from XOR.
 Not COMPLEX_EXPR as one VARYING operand makes the result partly
 not UNDEFINED.  Not *DIV_EXPR, comparisons and shifts because
 the undefined operand may be promoted.  */
Index: gcc/testsuite/gcc.dg/torture/pr80181.c
===
*** gcc/testsuite/gcc.dg/torture/pr80181.c  (nonexistent)
--- gcc/testsuite/gcc.dg/torture/pr80181.c  (working copy)
***
*** 0 
--- 1,19 
+ /* { dg-do compile } */
+ 
+ int
+ nr (void)
+ {
+ }
+ 
+ void
+ it (int dl)
+ {
+   int vp = 0;
+ 
+   for (;;)
+ {
+   dl = vp ^ nr ();
+   dl ^= vp;
+   vp = 1;
+ }
+ }

[PATCH] Handle PHI nodes w/o a argument (PR ipa/80205).

[Martin Liška]

Hello.

As described in the PR, we can create a PHI node in einline that has no 
argument.
That can cause ICE in devirtualization and should be thus handled.

Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.

Ready to be installed?
Martin
>From d0dc319a8df5d9f00434f54fef13b3dc427061e1 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Mon, 27 Mar 2017 13:32:52 +0200
Subject: [PATCH] Handle PHI nodes w/o a argument (PR ipa/80205).

gcc/testsuite/ChangeLog:

2017-03-27  Martin Liska  

	* g++.dg/ipa/pr80205.C: New test.

gcc/ChangeLog:

2017-03-27  Martin Liska  

	PR ipa/80205
	* ipa-polymorphic-call.c (walk_ssa_copies): Handle phi nodes
	w/o a argument.
---
 gcc/ipa-polymorphic-call.c |  2 +-
 gcc/testsuite/g++.dg/ipa/pr80205.C | 34 ++
 2 files changed, 35 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/ipa/pr80205.C

diff --git a/gcc/ipa-polymorphic-call.c b/gcc/ipa-polymorphic-call.c
index e690d05158d..89c008ee5c0 100644
--- a/gcc/ipa-polymorphic-call.c
+++ b/gcc/ipa-polymorphic-call.c
@@ -828,7 +828,7 @@ walk_ssa_copies (tree op, hash_set **global_visited = NULL)
 	{
 	  gimple *phi = SSA_NAME_DEF_STMT (op);
 
-	  if (gimple_phi_num_args (phi) > 2)
+	  if (gimple_phi_num_args (phi) == 0 || gimple_phi_num_args (phi) > 2)
 	goto done;
 	  if (gimple_phi_num_args (phi) == 1)
 	op = gimple_phi_arg_def (phi, 0);
diff --git a/gcc/testsuite/g++.dg/ipa/pr80205.C b/gcc/testsuite/g++.dg/ipa/pr80205.C
new file mode 100644
index 000..460bdcb02ca
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ipa/pr80205.C
@@ -0,0 +1,34 @@
+// PR ipa/80205
+// { dg-options "-fnon-call-exceptions --param early-inlining-insns=100 -O2" }
+
+class a
+{
+public:
+  virtual ~a ();
+};
+class b
+{
+public:
+  template  b (c);
+  ~b () { delete d; }
+  void
+  operator= (b e)
+  {
+b (e).f (*this);
+  }
+  void
+  f (b )
+  {
+a g;
+d = e.d;
+e.d = 
+  }
+  a *d;
+};
+void
+h ()
+{
+  b i = int();
+  void j ();
+  i = j;
+}
-- 
2.12.0

Re: [PATCH] gcov: Mark BBs that do not correspond to a line in source code (PR gcov-profile/79891).

[Martin Liška]

On 03/21/2017 07:39 PM, Nathan Sidwell wrote:
> Martin, Richard,
> I've read up on the thread, but I'm not sure where you guys are with an 
> actual patch.  From what I Richard nailed it in BZ with the comment that the 
> BB should not be associated with any source line.  That's a new thing, so I 
> think the gcov format needs extending (at least).
> 
> gcov must associate every BB with source line, so that it can present data to 
> users.  That's a conflict with the above observation.

Hi.

Well, discussion shows that currently gcov is based on mapping between basic 
blocks and source lines. More precisely, when
a basic block is reached than we know that a bunch of source lines is executed. 
We also assume that all basic blocks must belong
to a line in a source code (counter example triggered this discussion). I 
believe the proper approach should be more focused on
edges to cover situations like:

int main()
{
  foo (); goto baz; lab: bar ();

  baz:
if (a == 1)
  goto lab;
}

Moreover, there are 2 uncovered situations:
a) creation of a deleting constructor maps counters from 2 functions to a 
single line of code (PR 48463).
b) multi-versioning of a function can do very similar stuff; I know that it's 
rare that one has a valid profile
compound of 2 runs on a different machine

I'm planning to come back the these in next stage1. I would be happy for any 
feedback.

Martin

> 
> I don't understand why gcov does NOT think the line is executed when -a is 
> not used:
> 
> -:   29:/* Following line falsely marked as 
> covered when parameter "--rc lcov_branch_coverage=1" is set */
> #:   30:ReturnStatus_t = 0;
> 
> At least one block associated with line 30 is executed.  Why's it not being 
> counted?
> 
> But that does seem to be the right output -- we shouldn't count this 
> 'artificial' block.  So then the question morphs into the -a case:
> 
> 1:   30:ReturnStatus_t = 0;
> $:   30-block  0
> 1:   30-block  1
> 
> We do count the artificial block.  Which is inconsistent.
> 
> Sorry, at this point I'm lost as to what is being suggested as a solution.
> 
> nathan
> 

Re: [PATCH] Fix calls.c for a _complex type (PR ipa/80104).

[Martin Liška]

Hello.

There's alternative approach suggested by Martin Jambor.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests and
s390x cross compiler does not ICE.

Martin
>From f9e40be62e525d29347339316073fae425b0d516 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Fri, 24 Mar 2017 15:47:34 +0100
Subject: [PATCH] Fix calls.c for a _complex type (PR ipa/80104).

gcc/ChangeLog:

2017-03-23  Martin Liska  

	PR ipa/80104
	* cgraphunit.c (cgraph_node::expand_thunk): Mark argument of a
	thunk call as DECL_GIMPLE_REG_P when vector or complex type.

gcc/testsuite/ChangeLog:

2017-03-23  Martin Liska  

	* gcc.dg/ipa/pr80104.c: New test.
---
 gcc/cgraphunit.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
index c82a88a599c..8635e3bd0e9 100644
--- a/gcc/cgraphunit.c
+++ b/gcc/cgraphunit.c
@@ -1806,6 +1806,10 @@ cgraph_node::expand_thunk (bool output_asm_thunks, bool force_gimple_thunk)
 	for (; i < nargs; i++, arg = DECL_CHAIN (arg))
 	  {
 	tree tmp = arg;
+	if (VECTOR_TYPE_P (TREE_TYPE (arg))
+		|| TREE_CODE (TREE_TYPE (arg)) == COMPLEX_TYPE)
+	  DECL_GIMPLE_REG_P (arg) = 1;
+
 	if (!is_gimple_val (arg))
 	  {
 		tmp = create_tmp_reg (TYPE_MAIN_VARIANT
-- 
2.12.0

RE: [PATCH 0/5] [ARC] Fixes backend issues

[Claudiu Zissulescu]

Hi Andrew,

>   [ARC] Save/restore blink when in ISR.
>   [ARC] Fix detection of long immediate for load/store operands.
>   [ARC] Disable TP register when building for bare metal.
>   [ARC] Fix divdf3 emulation for arcem.
>   [ARC] Fix move_double_src_operand predicate.
> 

All the above patches were successfully committed having the indicated mods.

Thank you for your review,
Claudiu

P.S. The ARC backend is broken due to some wrong patterns in simd.md. I've 
prepared a patch which fixes that.

[PATCH] [ARC] Define _REENTRANT when -pthread is passed.

[Claudiu Zissulescu]

Hi Andrew,

This is a patch which originally has been made by Thomas. As I did
arange it, I cannot push it.

Original patch message:

The compiler is supposed to have the builtin defined _REENTRANT defined
when -pthread is passed, which wasn't done on the ARC architecture.

When _REENTRANT is not passed, the C library will not use reentrant
functions, and the latest version of ax_pthread.m4 from the
autoconf-archive will no longer detect that thread support is
available (see https://savannah.gnu.org/patch/?8186).

gcc/
2017-03-02  Claudiu Zissulescu  
Thomas Petazzoni 

* config/arc/arc.h (CPP_SPEC): Add subtarget_cpp_spec.
(EXTRA_SPECS): Define.
(SUBTARGET_EXTRA_SPECS): Likewise.
(SUBTARGET_CPP_SPEC): Likewise.
* config/arc/elf.h (EXTRA_SPECS): Renamed to
SUBTARGET_EXTRA_SPECS.
* config/arc/linux.h (SUBTARGET_CPP_SPEC): Define.
---
 gcc/config/arc/arc.h   | 24 +++-
 gcc/config/arc/elf.h   |  3 ++-
 gcc/config/arc/linux.h |  5 +
 3 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/gcc/config/arc/arc.h b/gcc/config/arc/arc.h
index d515eb0..24c2346 100644
--- a/gcc/config/arc/arc.h
+++ b/gcc/config/arc/arc.h
@@ -61,7 +61,8 @@ along with GCC; see the file COPYING3.  If not see
 %{mmac-d16:-D__Xxmac_d16} %{mmac-24:-D__Xxmac_24} \
 %{mdsp-packa:-D__Xdsp_packa} %{mcrc:-D__Xcrc} %{mdvbf:-D__Xdvbf} \
 %{mtelephony:-D__Xtelephony} %{mxy:-D__Xxy} %{mmul64: -D__Xmult32} \
-%{mlock:-D__Xlock} %{mswape:-D__Xswape} %{mrtsc:-D__Xrtsc}"
+%{mlock:-D__Xlock} %{mswape:-D__Xswape} %{mrtsc:-D__Xrtsc} \
+%(subtarget_cpp_spec)"
 
 #undef CC1_SPEC
 #define CC1_SPEC "\
@@ -73,6 +74,27 @@ extern const char *arc_cpu_to_as (int argc, const char 
**argv);
 #define EXTRA_SPEC_FUNCTIONS   \
   { "cpu_to_as", arc_cpu_to_as },
 
+/* This macro defines names of additional specifications to put in the specs
+   that can be used in various specifications like CC1_SPEC.  Its definition
+   is an initializer with a subgrouping for each command option.
+
+   Each subgrouping contains a string constant, that defines the
+   specification name, and a string constant that used by the GCC driver
+   program.
+
+   Do not define this macro if it does not need to do anything.  */
+#define EXTRA_SPECS  \
+  { "subtarget_cpp_spec",  SUBTARGET_CPP_SPEC }, \
+  SUBTARGET_EXTRA_SPECS
+
+#ifndef SUBTARGET_EXTRA_SPECS
+#define SUBTARGET_EXTRA_SPECS
+#endif
+
+#ifndef SUBTARGET_CPP_SPEC
+#define SUBTARGET_CPP_SPEC ""
+#endif
+
 #undef ASM_SPEC
 #define ASM_SPEC  "%{mbig-endian|EB:-EB} %{EL} "   \
   "%:cpu_to_as(%{mcpu=*:%*}) %{mspfp*} %{mdpfp*} %{mfpu=fpuda*:-mfpuda}"
diff --git a/gcc/config/arc/elf.h b/gcc/config/arc/elf.h
index 2b572a5..c5794f8 100644
--- a/gcc/config/arc/elf.h
+++ b/gcc/config/arc/elf.h
@@ -26,7 +26,8 @@ along with GCC; see the file COPYING3.  If not see
 
 #define ARC_TLS_EXTRA_START_SPEC "crttls.o%s"
 
-#define EXTRA_SPECS \
+#undef SUBTARGET_EXTRA_SPECS
+#define SUBTARGET_EXTRA_SPECS \
   { "arc_tls_extra_start_spec", ARC_TLS_EXTRA_START_SPEC }, \
 
 #undef STARTFILE_SPEC
diff --git a/gcc/config/arc/linux.h b/gcc/config/arc/linux.h
index 6e1a96e..83e5a1d 100644
--- a/gcc/config/arc/linux.h
+++ b/gcc/config/arc/linux.h
@@ -78,3 +78,8 @@ along with GCC; see the file COPYING3.  If not see
 /* Linux toolchains use r25 as the thread pointer register.  */
 #undef TARGET_ARC_TP_REGNO_DEFAULT
 #define TARGET_ARC_TP_REGNO_DEFAULT 25
+
+#undef SUBTARGET_CPP_SPEC
+#define SUBTARGET_CPP_SPEC "\
+   %{pthread:-D_REENTRANT} \
+"
-- 
1.9.1

[PATCH, GCC/ARM, gcc-6-branch] Fix PR80082: LDRD erronously used for 64bit load on ARMv7-R

[Thomas Preudhomme]

Hi,

Currently GCC is happy to use LDRD to perform a 64bit load on ARMv7-R,
as shown by the testcase on this patch. However, LDRD is only atomic
when LPAE extensions is available, which they are not for ARMv7-R. This
commit solve the issue by introducing a new feature bit to distinguish
LPAE extensions instead of deducing it from div instruction
availability.

ChangeLog entries are as follow:

*** gcc/ChangeLog ***

2017-03-22  Thomas Preud'homme  

PR target/80082
* config/arm/arm-protos.h (FL_LPAE): Define macro.
(FL_FOR_ARCH7VE): Add FL_LPAE.
(arm_arch_lpae): Declare extern.
* config/arm/arm.c (arm_arch_lpae): Declare.
(arm_option_override): Define arm_arch_lpae.
* config/arm/arm.h (TARGET_HAVE_LPAE): Redefine in term of
arm_arch_lpae.

*** gcc/testsuite/ChangeLog ***

2017-03-22  Thomas Preud'homme  

PR target/80082
* gcc.target/arm/atomic_loaddi_10.c: New testcase.
* gcc.target/arm/atomic_loaddi_11.c: Likewise.


Testing: bootstrapped for -march=armv7ve and testsuite shows no regression.

Is this ok for gcc-6-branch?

Best regards,

Thomas
diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h
index 0083673b161a49e19388c72d3a413aeb481dbfa3..dea00e42551c8295f7e83a72ddb81ae8e9c8e02d 100644
--- a/gcc/config/arm/arm-protos.h
+++ b/gcc/config/arm/arm-protos.h
@@ -360,7 +360,7 @@ extern bool arm_is_constant_pool_ref (rtx);
 #define FL_STRONG (1 << 8)	  /* StrongARM */
 #define FL_ARCH5E (1 << 9)/* DSP extensions to v5 */
 #define FL_XSCALE (1 << 10)	  /* XScale */
-/* spare	  (1 << 11)	*/
+#define FL_LPAE   (1 << 11)   /* ARMv7-A LPAE.  */
 #define FL_ARCH6  (1 << 12)   /* Architecture rel 6.  Adds
 	 media instructions.  */
 #define FL_VFPV2  (1 << 13)   /* Vector Floating Point V2.  */
@@ -412,7 +412,7 @@ extern bool arm_is_constant_pool_ref (rtx);
 #define FL_FOR_ARCH6M	(FL_FOR_ARCH6 & ~FL_NOTM)
 #define FL_FOR_ARCH7	((FL_FOR_ARCH6T2 & ~FL_NOTM) | FL_ARCH7)
 #define FL_FOR_ARCH7A	(FL_FOR_ARCH7 | FL_NOTM | FL_ARCH6K)
-#define FL_FOR_ARCH7VE	(FL_FOR_ARCH7A | FL_THUMB_DIV | FL_ARM_DIV)
+#define FL_FOR_ARCH7VE	(FL_FOR_ARCH7A | FL_THUMB_DIV | FL_ARM_DIV | FL_LPAE)
 #define FL_FOR_ARCH7R	(FL_FOR_ARCH7A | FL_THUMB_DIV)
 #define FL_FOR_ARCH7M	(FL_FOR_ARCH7 | FL_THUMB_DIV)
 #define FL_FOR_ARCH7EM  (FL_FOR_ARCH7M | FL_ARCH7EM)
@@ -608,6 +608,9 @@ extern int arm_arch_thumb2;
 extern int arm_arch_arm_hwdiv;
 extern int arm_arch_thumb_hwdiv;
 
+/* Nonzero if this chip supports the Large Physical Address Extension.  */
+extern int arm_arch_lpae;
+
 /* Nonzero if chip disallows volatile memory access in IT block.  */
 extern int arm_arch_no_volatile_ce;
 
diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index ad123dde991a3e4c4b9563ee6ebb84981767988f..e93ff7f7d8583b653570cbb8605df5a10bfcc6f4 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -254,8 +254,7 @@ extern void (*arm_lang_output_object_attributes_hook)(void);
 #define TARGET_HAVE_LDREX((arm_arch6 && TARGET_ARM) || arm_arch7)
 
 /* Nonzero if this chip supports LPAE.  */
-#define TARGET_HAVE_LPAE		\
-  (arm_arch7 && ARM_FSET_HAS_CPU1 (insn_flags, FL_FOR_ARCH7VE))
+#define TARGET_HAVE_LPAE	(arm_arch_lpae)
 
 /* Nonzero if this chip supports ldrex{bh} and strex{bh}.  */
 #define TARGET_HAVE_LDREXBH ((arm_arch6k && TARGET_ARM) || arm_arch7)
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index c3c89b866355708d91dd2a3dab1e4b33f2215ff8..44bfb53a288f57fbc43a0bd146e193b768d939d2 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -859,6 +859,9 @@ int arm_arch_thumb2;
 int arm_arch_arm_hwdiv;
 int arm_arch_thumb_hwdiv;
 
+/* Nonzero if this chip supports the Large Physical Address Extension.  */
+int arm_arch_lpae;
+
 /* Nonzero if chip disallows volatile memory access in IT block.  */
 int arm_arch_no_volatile_ce;
 
@@ -3181,6 +3184,7 @@ arm_option_override (void)
   arm_arch_iwmmxt2 = ARM_FSET_HAS_CPU1 (insn_flags, FL_IWMMXT2);
   arm_arch_thumb_hwdiv = ARM_FSET_HAS_CPU1 (insn_flags, FL_THUMB_DIV);
   arm_arch_arm_hwdiv = ARM_FSET_HAS_CPU1 (insn_flags, FL_ARM_DIV);
+  arm_arch_lpae = ARM_FSET_HAS_CPU1 (insn_flags, FL_LPAE);
   arm_arch_no_volatile_ce = ARM_FSET_HAS_CPU1 (insn_flags, FL_NO_VOLATILE_CE);
   arm_tune_cortex_a9 = (arm_tune == cortexa9) != 0;
   arm_arch_crc = ARM_FSET_HAS_CPU1 (insn_flags, FL_CRC32);
diff --git a/gcc/testsuite/gcc.target/arm/atomic_loaddi_10.c b/gcc/testsuite/gcc.target/arm/atomic_loaddi_10.c
new file mode 100644
index ..ecc3d06d0c9f5966daa3ce7e2d52e09d14e0cbc8
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/atomic_loaddi_10.c
@@ -0,0 +1,15 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target arm_arch_v7ve_ok } */
+/* { dg-options "-O2" } */
+/* { dg-add-options arm_arch_v7ve } */
+
+#include 
+
+atomic_llong x = 0;
+

[PATCH] [ARC] Update ARC SIMD patterns.

[Claudiu Zissulescu]

Hi Andrew,

vec_select expects in selection a list of subparts. The old ARC SIMD
extension instructions were not up-to-date, update them.

Whithout this patch ARC backend is broken. It will be great if we can have it 
in before gcc7.x branch is cut.

Thank you,
Claudiu

gcc/
2017-03-27  Claudiu Zissulescu  

* config/arc/simdext.md (vst64_insn): Update pattern.
(vld32wh_insn): Likewise.
(vld32wl_insn): Likewise.
(vld64_insn): Likewise.
(vld32_insn): Likewise.
---
 gcc/config/arc/simdext.md | 98 ---
 1 file changed, 67 insertions(+), 31 deletions(-)

diff --git a/gcc/config/arc/simdext.md b/gcc/config/arc/simdext.md
index c9ec5f4..33bb330 100644
--- a/gcc/config/arc/simdext.md
+++ b/gcc/config/arc/simdext.md
@@ -193,11 +193,16 @@
 )
 
 (define_insn "vst64_insn"
-  [(set(mem:V4HI (plus:SI (zero_extend:SI (vec_select:HI 
(match_operand:V8HI 0 "vector_register_operand"  "v")
- (parallel 
[(match_operand:SI 1 "immediate_operand" "L")])))
-  (match_operand:SI 2 "immediate_operand" "P")))
-   (vec_select:V4HI (match_operand:V8HI 3 "vector_register_operand" "=v")
-(parallel [(const_int 0)])))]
+  [(set(mem:V4HI
+(plus:SI
+ (zero_extend:SI
+  (vec_select:HI (match_operand:V8HI 0 "vector_register_operand"  "v")
+ (parallel
+  [(match_operand:SI 1 "immediate_operand" "L")])))
+ (match_operand:SI 2 "immediate_operand" "P")))
+   (vec_select:V4HI
+(match_operand:V8HI 3 "vector_register_operand" "=v")
+(parallel [(const_int 0) (const_int 1) (const_int 2) (const_int 3)])))]
  "TARGET_SIMD_SET"
  "vst64 %3, [i%1, %2]"
  [(set_attr "type" "simd_vstore")
@@ -1191,12 +1196,20 @@
(set_attr "cond" "nocond")])
 
 (define_insn "vld32wh_insn"
-  [(set (match_operand:V8HI 0 "vector_register_operand"   "=v")
-   (vec_concat:V8HI (zero_extend:V4HI (mem:V4QI (plus:SI (match_operand:SI 
1 "immediate_operand" "P")
- (zero_extend: SI 
(vec_select:HI (match_operand:V8HI 2 "vector_register_operand"  "v")
-   
  (parallel [(match_operand:SI 3 "immediate_operand" "L")]))
-(vec_select:V4HI (match_dup 0)
- (parallel [(const_int 0)]]
+  [(set (match_operand:V8HI 0 "vector_register_operand" "=v")
+   (vec_concat:V8HI
+(zero_extend:V4HI
+ (mem:V4QI
+  (plus:SI
+   (match_operand:SI 1 "immediate_operand" "P")
+   (zero_extend:SI
+(vec_select:HI
+ (match_operand:V8HI 2 "vector_register_operand"  "v")
+ (parallel [(match_operand:SI 3 "immediate_operand" "L")]))
+(vec_select:V4HI
+ (match_dup 0)
+ (parallel [(const_int 0) (const_int 1) (const_int 2) (const_int 3)])
+ )))]
   "TARGET_SIMD_SET"
   "vld32wh %0, [i%3,%1]"
   [(set_attr "type" "simd_vload")
@@ -1204,12 +1217,20 @@
(set_attr "cond" "nocond")])
 
 (define_insn "vld32wl_insn"
-  [(set (match_operand:V8HI 0 "vector_register_operand"   "=v")
-   (vec_concat:V8HI (vec_select:V4HI (match_dup 0)
- (parallel [(const_int 1)]))
-(zero_extend:V4HI (mem:V4QI (plus:SI (match_operand:SI 
1 "immediate_operand" "P")
- (zero_extend: SI 
(vec_select:HI (match_operand:V8HI 2 "vector_register_operand"  "v")
-   
  (parallel [(match_operand:SI 3 "immediate_operand" "L")])) ))]
+  [(set (match_operand:V8HI 0 "vector_register_operand" "=v")
+   (vec_concat:V8HI
+(vec_select:V4HI
+ (match_dup 0)
+ (parallel [(const_int 4) (const_int 5) (const_int 6) (const_int 7)]))
+(zero_extend:V4HI
+ (mem:V4QI
+  (plus:SI
+   (match_operand:SI 1 "immediate_operand" "P")
+   (zero_extend:SI
+(vec_select:HI (match_operand:V8HI 2 "vector_register_operand" "v")
+   (parallel
+[(match_operand:SI 3 "immediate_operand" "L")]))
+))]
   "TARGET_SIMD_SET"
   "vld32wl %0, [i%3,%1]"
   [(set_attr "type" "simd_vload")
@@ -1229,12 +1250,19 @@
 )
 
 (define_insn "vld64_insn"
-  [(set (match_operand:V8HI 0 "vector_register_operand"   "=v")
-   (vec_concat:V8HI (vec_select:V4HI (match_dup 0)
- (parallel [(const_int 1)]))
-(mem:V4HI (plus:SI (match_operand:SI 1 
"immediate_operand" "P")
-

Re: [PATCH 1/5] nvptx: implement SIMT enter/exit insns

[Alexander Monakov]

Hello Bernd,

Can you have a look at this patch (unchanged from previous posting in January)?
The rest of the patches in the set are reviewed.

On Wed, 22 Mar 2017, Alexander Monakov wrote:

> This patch adds handling of new omp_simt_enter/omp_simt_exit named insns
> in the NVPTX backend.
> 
>   * config/nvptx/nvptx-protos.h (nvptx_output_simt_enter): Declare.
> (nvptx_output_simt_exit): Declare.
> * config/nvptx/nvptx.c (nvptx_init_unisimt_predicate): Use
> cfun->machine->unisimt_location.  Handle NULL unisimt_predicate.
> (init_softstack_frame): Move initialization of crtl->is_leaf to...
> (nvptx_declare_function_name): ...here.  Emit declaration of local
> memory space buffer for omp_simt_enter insn.
> (nvptx_output_unisimt_switch): New.
> (nvptx_output_softstack_switch): New.
> (nvptx_output_simt_enter): New.
> (nvptx_output_simt_exit): New.
> * config/nvptx/nvptx.h (struct machine_function): New fields
> has_simtreg, unisimt_location, simt_stack_size, simt_stack_align.
> * config/nvptx/nvptx.md (UNSPECV_SIMT_ENTER): New unspec.
> (UNSPECV_SIMT_EXIT): Ditto.
> (omp_simt_enter_insn): New insn.
> (omp_simt_enter): New expansion.
> (omp_simt_exit): New insn.
> * config/nvptx/nvptx.opt (msoft-stack-reserve-local): New option.

Thanks.
Alexander

[PATCH] Fix PR79776

[Richard Biener]

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

Richard.

2017-03-27  Richard Biener  

PR ipa/79776
* tree-ssa-structalias.c (associate_varinfo_to_alias): Skip
inlined thunk clones.

* g++.dg/ipa/pr79776.C: New testcase.

Index: gcc/tree-ssa-structalias.c
===
*** gcc/tree-ssa-structalias.c  (revision 246489)
--- gcc/tree-ssa-structalias.c  (working copy)
*** struct pt_solution ipa_escaped_pt
*** 7615,7621 
  static bool
  associate_varinfo_to_alias (struct cgraph_node *node, void *data)
  {
!   if ((node->alias || node->thunk.thunk_p)
&& node->analyzed)
  insert_vi_for_tree (node->decl, (varinfo_t)data);
return false;
--- 7615,7623 
  static bool
  associate_varinfo_to_alias (struct cgraph_node *node, void *data)
  {
!   if ((node->alias
!|| (node->thunk.thunk_p
!  && ! node->global.inlined_to))
&& node->analyzed)
  insert_vi_for_tree (node->decl, (varinfo_t)data);
return false;
Index: gcc/testsuite/g++.dg/ipa/pr79776.C
===
*** gcc/testsuite/g++.dg/ipa/pr79776.C  (nonexistent)
--- gcc/testsuite/g++.dg/ipa/pr79776.C  (working copy)
***
*** 0 
--- 1,29 
+ // PR ipa/71146
+ // { dg-do compile }
+ // { dg-options "-O3 -fipa-pta" }
+ 
+ typedef enum { X } E;
+ struct A {
+   virtual void bar ();
+ };
+ struct B {
+   virtual E fn (const char *, int, int *) = 0;
+ };
+ struct C : A, B {
+   E fn (const char *, int, int *);
+   void fn2 ();
+   B *foo;
+ };
+ void C::fn2 () {
+   if (!foo)
+ return;
+   foo->fn (0, 0, 0);
+ }
+ E
+ C::fn (const char *, int, int *)
+ {
+   fn2 ();
+   foo = 0;
+   fn (0, 0, 0);
+   return X;
+ }

[PATCH] Real fix for AIX exception handling

[Michael Haubenwallner]

Hi,

as far as I have discovered, the real problem with AIX exception handling is
that the exception landing pads are symbols that must not (but still are)
exported from shared libraries - even libstdc++.

I'm wondering if attached libtool(!)-patch would fix even that GDB problem
once applied to each(!) shared library creation procedure.

However, each workaround still applies as long as there's a single shared
library involved that has not stopped exporting these symbols yet.

Thoughts?

Maybe gcc's collect2 should apply this additional symbol filter itself when
calling (AIX) ld, rather than leaving this to each build system?

Thanks!
/haubi/
>From 32ca0e6f7bf8d096cc653ac455d66c270b75fdf0 Mon Sep 17 00:00:00 2001
From: Michael Haubenwallner 
Date: Wed, 2 Mar 2016 15:06:48 +0100
Subject: [PATCH 1/4] AIX: Stop exporting more _GLOBAL__ symbols.

* m4/libtool.m4 (_LT_LINKER_SHLIBS): On AIX, GNU g++ generates
_GLOBAL__ symbols as, amongst others, landing pads for C++ exceptions.
These symbols must not be exported from shared libraries, or exception
handling may break for applications with runtime linking enabled.
---
 m4/libtool.m4 | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index ee292af..c2e996c 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -4943,6 +4943,7 @@ m4_if([$1], [CXX], [
 else
   _LT_TAGVAR(export_symbols_cmds, $1)='`func_echo_all $NM | $SED -e '\''s/B\([[^B]]*\)$/P\1/'\''` -PCpgl $libobjs $convenience | awk '\''{ if (((\$ 2 == "T") || (\$ 2 == "D") || (\$ 2 == "B") || (\$ 2 == "L") || (\$ 2 == "W") || (\$ 2 == "V") || (\$ 2 == "Z")) && ([substr](\$ 1,1,1) != ".")) { if ((\$ 2 == "W") || (\$ 2 == "V") || (\$ 2 == "Z")) { print \$ 1 " weak" } else { print \$ 1 } } }'\'' | sort -u > $export_symbols'
 fi
+_LT_TAGVAR(exclude_expsyms, $1)='_GLOBAL_OFFSET_TABLE_|_GLOBAL__F[ID]_.*|_GLOBAL__[FID]_.*'
 ;;
   pw32*)
 _LT_TAGVAR(export_symbols_cmds, $1)=$ltdll_cmds
@@ -5398,6 +5399,7 @@ _LT_EOF
 	else
 	  _LT_TAGVAR(export_symbols_cmds, $1)='`func_echo_all $NM | $SED -e '\''s/B\([[^B]]*\)$/P\1/'\''` -PCpgl $libobjs $convenience | awk '\''{ if (((\$ 2 == "T") || (\$ 2 == "D") || (\$ 2 == "B") || (\$ 2 == "L") || (\$ 2 == "W") || (\$ 2 == "V") || (\$ 2 == "Z")) && ([substr](\$ 1,1,1) != ".")) { if ((\$ 2 == "W") || (\$ 2 == "V") || (\$ 2 == "Z")) { print \$ 1 " weak" } else { print \$ 1 } } }'\'' | sort -u > $export_symbols'
 	fi
+	_LT_TAGVAR(exclude_expsyms, $1)='_GLOBAL_OFFSET_TABLE_|_GLOBAL__F[ID]_.*|_GLOBAL__[FID]_.*'
 	aix_use_runtimelinking=no
 
 	# Test if we are trying to use run time linking or normal
-- 
2.10.2

Re: [patch] Clarify interaction of -Wnarrowing with -std

[Jonathan Wakely]

On 26/03/17 14:32 -0600, Sandra Loosemore wrote:

On 03/26/2017 02:13 PM, Gerald Pfeifer wrote:

Hi Jonathan,

On Tue, 23 Feb 2016, Jonathan Wakely wrote:

On 19/02/16 13:17 -0700, Sandra Loosemore wrote:

I suppose the patch is OK as it stands, but I was going to suggest
restructuring it so that it talks about the default behavior first
and what
it does with non-default -std= options after that, instead of
vice-versa.
Unfortunately I am backlogged on other things right now and it might
take me
a day or two before I have time to come up with some alternate
wording.  If
we are in a rush, go ahead and commit the existing patch meanwhile, I
guess.

Is this better?


I believe your follow-up patch did not get committed, nor did I
see any response from anyone.

To me it looks fine.  Did you hold of intentionally, or did this
get lost for lack of responses?

Sandra, what do you think?


Looks OK to me.  I apologize for losing track of this patch previously.  :-(


OK, thanks, I'll commit it today.

Re: PATCH for Re: Release notes for GCC 7?

[carl hansen]

suggested additions:

get and insert the latest libtool, which includes files:
libtool.m4  ltgcc.m4  lt~obsolete.m4  ltoptions.m4  ltsugar.m4  ltversion.m4,
all way-old currently in gcc-7

get latest autoconf. 2.64 in use, latest is 2.69

get latest texinfo.tex, not one 5 years old

GNU is supposed to be a unified system, but it's not even up-to-date with
its own software.  I'm trying to debug a libtool bug but I am forced to
downgrade autoconf... getting too hard to bother.

It's not too late to fix it in gcc-7...


On Mon, Mar 13, 2017 at 1:31 AM, Richard Biener
 wrote:
> On Sun, Mar 12, 2017 at 11:45 PM, Gerald Pfeifer  wrote:
>> On Wed, 24 Aug 2016, Richard Biener wrote:
>>> We've been creating those lazily over the last decade.  We can change
>>> that, an entry for releasing.html is appreciated then so we don't forget.
>>
>> And here we go, in time for the release of GCC 7 / branching of GCC 8.
>>
>> (Except, this time I went ahead and already created gcc-8/changes.html
>> so that you guys don't have to worry about that. ;-)
>>
>> Note, I added this to branching.html, not releasing.html, not the least
>> since branching.html already had the creation of other web pages for the
>> new release series and that also seems the more appropriate point time-
>> wise.  Agreed?
>
> Yes.
>
> Thanks,
> Richard.
>
>> Gerald
>>
>>
>> Index: branching.html
>> ===
>> RCS file: /cvs/gcc/wwwdocs/htdocs/branching.html,v
>> retrieving revision 1.32
>> diff -u -r1.32 branching.html
>> --- branching.html  28 Jun 2014 10:34:16 -  1.32
>> +++ branching.html  12 Mar 2017 22:37:59 -
>> @@ -7,6 +7,8 @@
>>  
>>  This page documents the procedure for making a new release branch.
>>
>> +Preparations
>> +
>>  
>>  Execute the following commands, substituting appropriate version
>>  numbers:
>> @@ -38,15 +40,25 @@
>>  for the next major release in the wwwdocs repository and
>>  populate it with initial copies of changes.html and
>>  criteria.html.
>> +
>>
>> -Add index.html and buildstat.html pages
>> -to the directory corresponding to the newly created release branch.
>> -Update the toplevel buildstat.html accordingly.
>> +Web Site Updates
>> +
>> +
>> +Add index.html and changes.html pages
>> +based on the previous release branch to the directory corresponding to
>> +the newly created release branch.
>> +
>> +Add buildstat.html and update the toplevel
>> +buildstat.html accordingly.
>>
>>  Update the toplevel index.html page to show the new active
>>  release branch, the current release series, and active development
>>  (mainline).  Update the version and development stage for mainline.
>> +
>>
>> +
>>  Update maintainer-scripts/crontab on the mainline by
>>  adding an entry to make snapshots of the new branch and adjusting the
>>  version number of the mainline snapshots.
>> @@ -67,7 +79,11 @@
>>  Send them
>>  to the translation project if no snapshot of this version was sent
>>  during development stage 3 or 4.
>> +
>>
>> +Bugzilla Updates
>> +
>> +
>>  Create new versions in Bugzilla corresponding to the new mainline
>>  version.  This can be accomplished by choosing "products", choosing "gcc",
>>  and editing the versions.  Please do not delete old
>> @@ -85,7 +101,6 @@
>>  Ask Daniel Berlin to adjust all PRs with the just-branched version
>>  in their summary to also contain the new version corresponding to
>>  mainline.
>> -
>>  
>>
>>  

[PATCH] Fix PR80170

[Richard Biener]

The following fixes a latent bug in vect dataref alignment analysis.

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

Richard.

2017-03-27  Richard Biener  

PR tree-optimization/80170
* tree-vect-data-refs.c (vect_compute_data_ref_alignment): Make
sure DR/SCEV didnt fold in constants we do not see when looking
at the reference base alignment.

* gcc.dg/pr80170.c: New testcase.

Index: gcc/tree-vect-data-refs.c
===
--- gcc/tree-vect-data-refs.c   (revision 246489)
+++ gcc/tree-vect-data-refs.c   (working copy)
@@ -779,7 +779,7 @@ vect_compute_data_ref_alignment (struct
   base = ref;
   while (handled_component_p (base))
 base = TREE_OPERAND (base, 0);
-  unsigned int base_alignment;
+  unsigned int base_alignment = 0;
   unsigned HOST_WIDE_INT base_bitpos;
   get_object_alignment_1 (base, _alignment, _bitpos);
   /* As data-ref analysis strips the MEM_REF down to its base operand
@@ -788,8 +788,17 @@ vect_compute_data_ref_alignment (struct
  DR_BASE_ADDRESS.  */
   if (TREE_CODE (base) == MEM_REF)
 {
-  base_bitpos -= mem_ref_offset (base).to_short_addr () * BITS_PER_UNIT;
-  base_bitpos &= (base_alignment - 1);
+  /* Note all this only works if DR_BASE_ADDRESS is the same as
+MEM_REF operand zero, otherwise DR/SCEV analysis might have factored
+in other offsets.  We need to rework DR to compute the alingment
+of DR_BASE_ADDRESS as long as all information is still available.  */
+  if (operand_equal_p (TREE_OPERAND (base, 0), base_addr, 0))
+   {
+ base_bitpos -= mem_ref_offset (base).to_short_addr () * BITS_PER_UNIT;
+ base_bitpos &= (base_alignment - 1);
+   }
+  else
+   base_bitpos = BITS_PER_UNIT;
 }
   if (base_bitpos != 0)
 base_alignment = base_bitpos & -base_bitpos;
Index: gcc/testsuite/gcc.dg/pr80170.c
===
--- gcc/testsuite/gcc.dg/pr80170.c  (nonexistent)
+++ gcc/testsuite/gcc.dg/pr80170.c  (working copy)
@@ -0,0 +1,42 @@
+/* { dg-do run } */
+/* { dg-options "-fgimple -O2 -ftree-slp-vectorize" } */
+
+struct  A
+{
+  void * a;
+  void * b;
+};
+
+struct __attribute__((aligned(16))) B
+{
+  void * pad;
+  void * misaligned;
+  void * pad2;
+
+  struct A a;
+};
+
+__attribute__((noclone, noinline))
+void __GIMPLE (startwith("slp"))
+NullB (void * misalignedPtr)
+{
+  struct B * b;
+
+  bb_2:
+#if __SIZEOF_LONG__ == 8
+  b_2 = misalignedPtr_1(D) + 18446744073709551608ul;
+#else
+  b_2 = misalignedPtr_1(D) + 4294967292ul;
+#endif
+  __MEM  (b_2).a.a = _Literal (void *) 0;
+  __MEM  (b_2).a.b = _Literal (void *) 0;
+  return;
+
+}
+
+int main()
+{
+  struct B b;
+  NullB ();
+  return 0;
+}

Re: [PATCH] Fix asan/ubsan bitfield handling in VL structures (PR sanitizer/80168)

[Richard Biener]

On Fri, 24 Mar 2017, Jakub Jelinek wrote:

> Hi!
> 
> We ICE on the following testcase, because we attempt to use
> DECL_BIT_FIELD_REPRESENTATIVE instead of original FIELD_DECL
> in a COMPONENT_REF in a VL structure, but DECL_BIT_FIELD_REPRESENTATIVE's
> DECL_FIELD_OFFSET is not really gimplified and even if it was,
> it wouldn't be current.  From the expr.c and stor-layout.c comments,
> seems DECL_BIT_FIELD_REPRESENTATIVE's DECL_FIELD_OFFSET is guaranteed
> to be the same as the corresponding field's by construction if it is not
> constant, all the differences if any are in DECL_FIELD_BIT_OFFSET.

Yes.

> Therefore, it should be safe to reuse 3rd COMPONENT_REF operand.
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Ok.

Richard.

> 2017-03-24  Jakub Jelinek  
> 
>   PR sanitizer/80168
>   * asan.c (instrument_derefs): Copy over last operand from
>   original COMPONENT_REF to the new COMPONENT_REF with
>   DECL_BIT_FIELD_REPRESENTATIVE.
>   * ubsan.c (instrument_object_size): Likewise.
> 
>   * gcc.dg/asan/pr80168.c: New test.
> 
> --- gcc/asan.c.jj 2017-03-21 07:57:00.0 +0100
> +++ gcc/asan.c2017-03-24 17:02:35.451865004 +0100
> @@ -1868,7 +1868,8 @@ instrument_derefs (gimple_stmt_iterator
>tree repr = DECL_BIT_FIELD_REPRESENTATIVE (TREE_OPERAND (t, 1));
>instrument_derefs (iter, build3 (COMPONENT_REF, TREE_TYPE (repr),
>  TREE_OPERAND (t, 0), repr,
> -NULL_TREE), location, is_store);
> +TREE_OPERAND (t, 2)),
> +  location, is_store);
>return;
>  }
>  
> --- gcc/ubsan.c.jj2017-03-07 07:10:00.0 +0100
> +++ gcc/ubsan.c   2017-03-24 17:02:58.439568314 +0100
> @@ -1772,7 +1772,7 @@ instrument_object_size (gimple_stmt_iter
>   {
> tree repr = DECL_BIT_FIELD_REPRESENTATIVE (TREE_OPERAND (t, 1));
> t = build3 (COMPONENT_REF, TREE_TYPE (repr), TREE_OPERAND (t, 0),
> -   repr, NULL_TREE);
> +   repr, TREE_OPERAND (t, 2));
>   }
>break;
>  case ARRAY_REF:
> --- gcc/testsuite/gcc.dg/asan/pr80168.c.jj2017-03-24 17:08:14.440489868 
> +0100
> +++ gcc/testsuite/gcc.dg/asan/pr80168.c   2017-03-24 17:09:08.567791277 
> +0100
> @@ -0,0 +1,12 @@
> +/* PR sanitizer/80168 */
> +/* { dg-do compile } */
> +
> +int a;
> +
> +int
> +foo (void)
> +{
> +  struct S { int c[a]; int q : 8; int e : 4; } f;
> +  f.e = 4;
> +  return f.e;
> +}
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

[PATCH] Fix PR80171

[Richard Biener]

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

Richard.

2017-03-27  Richard Biener  

PR middle-end/80171
* gimple-fold.c (fold_ctor_reference): Properly guard against
NULL return value from canonicalize_constructor_val.

* g++.dg/torture/pr80171.C: New testcase.

Index: gcc/gimple-fold.c
===
--- gcc/gimple-fold.c   (revision 246437)
+++ gcc/gimple-fold.c   (working copy)
@@ -6239,9 +6239,12 @@ fold_ctor_reference (tree type, tree cto
   && !compare_tree_int (TYPE_SIZE (TREE_TYPE (ctor)), size))
 {
   ret = canonicalize_constructor_val (unshare_expr (ctor), from_decl);
-  ret = fold_unary (VIEW_CONVERT_EXPR, type, ret);
   if (ret)
-   STRIP_USELESS_TYPE_CONVERSION (ret);
+   {
+ ret = fold_unary (VIEW_CONVERT_EXPR, type, ret);
+ if (ret)
+   STRIP_USELESS_TYPE_CONVERSION (ret);
+   }
   return ret;
 }
   /* For constants and byte-aligned/sized reads try to go through
Index: gcc/testsuite/g++.dg/torture/pr80171.C
===
--- gcc/testsuite/g++.dg/torture/pr80171.C  (nonexistent)
+++ gcc/testsuite/g++.dg/torture/pr80171.C  (working copy)
@@ -0,0 +1,183 @@
+// { dg-do compile }
+
+template  struct remove_reference;
+template  struct remove_reference<_Tp &> { typedef _Tp type; };
+template  typename remove_reference<_Tp>::type move(_Tp &) {
+  return static_cast::type &&>(p1);
+}
+void *operator new(__SIZE_TYPE__, void *p2) { return p2; }
+struct Trans_NS__v1_GenericTlv {
+  virtual int getMinimumValueLength();
+  virtual unsigned long getValueLength() const;
+};
+struct IPv4NeighborAddressSubTlv;
+struct Trans_NS__v1_GenericTlvBase : Trans_NS__v1_GenericTlv {
+  virtual bool operator==(const IPv4NeighborAddressSubTlv &) const;
+};
+struct Trans_NS__v1_GenericUnsupportedTlv;
+template  struct backup_holder {
+  Trans_NS__v1_GenericUnsupportedTlv *backup_;
+  Trans_NS__v1_GenericUnsupportedTlv () { return *backup_; }
+};
+template  struct make_reference_content {
+  typedef IPv4NeighborAddressSubTlv type;
+};
+template  struct unwrap_recursive {
+  typedef IPv4NeighborAddressSubTlv type;
+};
+template  struct begin_impl;
+template  struct begin {
+  typedef typename Sequence::tag tag_;
+  typedef typename begin_impl::template apply::type type;
+};
+struct long_ {
+  static const int value = 0;
+};
+template  struct O1_size_impl;
+template 
+struct O1_size
+: O1_size_impl::template apply {};
+template 
+struct apply_wrap2 : F::template apply {};
+template  struct iter_fold_impl;
+template 
+struct iter_fold_impl<0, First, ForwardOp> {
+  typedef typename apply_wrap2::type state;
+};
+template  struct iter_fold {
+  typedef
+  typename iter_fold_impl::state
+  type;
+};
+template  struct deref;
+template  struct pair { typedef T1 first; };
+struct make_initializer_node {
+  template  struct apply {
+struct initializer_node {
+  typedef typename deref::type recursive_enabled_T;
+  static int
+  initialize(void *p1,
+ typename unwrap_recursive::type) {
+new (p1) typename make_reference_content::type;
+  }
+};
+typedef pair type;
+  };
+};
+struct l_item {
+  typedef int tag;
+  typedef l_item type;
+  typedef long_ size;
+  typedef int item;
+};
+template <> struct O1_size_impl {
+  template  struct apply : List::size {};
+};
+template  struct l_iter;
+template  struct deref {
+  typedef typename Node::item type;
+};
+template <> struct begin_impl {
+  template  struct apply {
+typedef l_iter type;
+  };
+};
+template 
+struct list : l_item {};
+template  struct make_variant_list { typedef list type; };
+template  T cast_storage(void *p1) { return *static_cast(p1); 
}
+struct visitation_impl_step {
+  typedef Trans_NS__v1_GenericUnsupportedTlv type;
+};
+template 
+void visitation_impl_invoke_impl(Visitor p1, VoidPtrCV p2, T *) {
+  backup_holder __trans_tmp_8 =
+  cast_storage(p2);
+  p1.internal_visit(__trans_tmp_8, 0);
+}
+template 
+void visitation_impl_invoke(Visitor p1, VoidPtrCV p2, T p3, NoBackupFlag) {
+  visitation_impl_invoke_impl(p1, p2, p3);
+}
+template 
+void visitation_impl(Visitor p1, VoidPtrCV p2, NoBackupFlag, Which, step0 *) {
+  visitation_impl_invoke(p1, p2, static_cast(0), 0);
+}
+struct move_into {
+  move_into(void *);
+  template  void internal_visit(backup_holder p1, int) {
+T __trans_tmp_2 = p1.get();
+new (0) T(__trans_tmp_2);
+  }
+};
+template  struct variant {
+  struct initializer : iter_fold::type,
+ 

Re: [patch, libgfortran] PR78881 [F03] reading from string with DTIO procedure does not work properly

[Christophe Lyon]

Hi,


On 25 March 2017 at 19:49, Jerry DeLisle  wrote:
> On 03/25/2017 11:00 AM, Paul Richard Thomas wrote:
>>
>> Hi Jerry,
>>
>> This looks fine to me. OK for trunk.
>>
>> Thanks for the patch.
>>
>> Paul
>>
>
> Thanks for review Paul.
>
> A   gcc/testsuite/gfortran.dg/dtio_26.f03
> M   gcc/testsuite/ChangeLog
> M   libgfortran/ChangeLog
> M   libgfortran/io/io.h
> M   libgfortran/io/list_read.c
> M   libgfortran/io/transfer.c
> Committed r246478
>

Besides the typo in the ChangeLog (the new testcase is dtio_26.f03,
not dtio_26.f90),
I've noticed that the new test fails on arm-linux-gnueabihf targets, but passes
on arm-linux-gnueabi targets.
My gfortran.log only says:
Program aborted.

Christophe



> Jerry