[PATCH] [PR82155] Fix crash in dwarf2out_abstract_function

2017-09-11 Thread Pierre-Marie de Rodat
Hello,

This patch is an attempt to fix the crash reported in PR82155.

When generating a C++ class method for a class that is itself nested in
a class method, dwarf2out_early_global_decl currently leaves the
existing context DIE as it is if it already exists.  However, it is
possible that this call happens at a point where this context DIE is
just a declaration that is itself not located in its own context.

>From there, if dwarf2out_early_global_decl is not called on any of the
FUNCTION_DECL in the context chain, DIEs will be left badly scoped and
some (such as the nested method) will be removed by the type pruning
machinery.  As a consequence, dwarf2out_abstract_function will will
crash when called on the corresponding DECL because it asserts that the
DECL has a DIE.

This patch fixes this crash making dwarf2out_early_global_decl process
context DIEs the same way we process abstract origins for FUNCTION_DECL:
if the corresponding DIE exists but is only a declaration, call
dwarf2out_decl anyway on it so that it is turned into a more complete
DIE and so that it is relocated in the proper context.

Bootstrapped and regtested on x86_64-linux.  The crash this addresses is
present both on trunk and on the gcc-7 branch: I suggest we commit this
patch on both branches.  Ok to commit? Thank you in advance!

gcc/

PR debug/82155
* dwarf2out.c (dwarf2out_early_global_decl): Call dwarf2out_decl
on the FUNCTION_DECL function context if it has a DIE that is a
declaration.

gcc/testsuite/

* g++.dg/pr82155.C: New testcase.
---
 gcc/dwarf2out.c| 10 --
 gcc/testsuite/g++.dg/pr82155.C | 36 
 2 files changed, 44 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/pr82155.C

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 00d6d951ba3..4cfc9c186af 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -25500,10 +25500,16 @@ dwarf2out_early_global_decl (tree decl)
 so that all nested DIEs are generated at the proper scope in the
 first shot.  */
  tree context = decl_function_context (decl);
- if (context != NULL && lookup_decl_die (context) == NULL)
+ if (context != NULL)
{
+ dw_die_ref context_die = lookup_decl_die (context);
  current_function_decl = context;
- dwarf2out_decl (context);
+
+ /* Avoid emitting DIEs multiple times, but still process CONTEXT
+enough so that it lands in its own context.  This avoids type
+pruning issues later on.  */
+ if (context_die == NULL || is_declaration_die (context_die))
+   dwarf2out_decl (context);
}
 
  /* Emit an abstract origin of a function first.  This happens
diff --git a/gcc/testsuite/g++.dg/pr82155.C b/gcc/testsuite/g++.dg/pr82155.C
new file mode 100644
index 000..75d9b615f39
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr82155.C
@@ -0,0 +1,36 @@
+/* { dg-do compile { target c++11 } } */
+/* { dg-options "-g -O2" } */
+
+template  struct b { a c; };
+template  struct e { d *operator->(); };
+template  class h {
+public:
+  typedef e ag;
+};
+class i {
+protected:
+  i(int);
+};
+class j {
+  virtual void k(int) = 0;
+
+public:
+  int f;
+  void l() { k(f); }
+};
+struct m : i {
+  int cn;
+  m() : i(cn) {
+struct n : j {
+  n() {}
+  void k(int) {}
+};
+  }
+};
+struct o {
+  o() {
+for (h>>::ag g;;)
+  g->c.c->l();
+  }
+};
+void fn1() { o(); }
-- 
2.14.1



Re: confirm subscribe to gcc-patches@gcc.gnu.org

2017-09-11 Thread Shane Matley


-- Shane

On Tue, Sep 12, 2017, at 09:56 AM, gcc-patches-h...@gcc.gnu.org wrote:
> Hi! This is the ezmlm program. I'm managing the
> gcc-patches@gcc.gnu.org mailing list.
> 
> To confirm that you would like
> 
>general+...@matley.com.au
> 
> added to the gcc-patches mailing list, please send
> an empty reply to this address:
> 
>
> gcc-patches-sc.1505174215.ncimaapkeeadlpneppim-general+gcc=matley.com...@gcc.gnu.org
> 
> Usually, this happens when you just hit the "reply" button.
> If this does not work, simply copy the address and paste it into
> the "To:" field of a new message.
> 
> This confirmation serves two purposes. First, it verifies that I am able
> to get mail through to you. Second, it protects you in case someone
> forges a subscription request in your name.
> 
> Some mail programs are broken and cannot handle long addresses. If you
> cannot reply to this request, instead send a message to
>  and put the
> entire address listed above into the "Subject:" line.
> 
> 
> --- Administrative commands for the gcc-patches list ---
> 
> I can handle administrative requests automatically. Please
> do not send them to the list address! Instead, send
> your message to the correct command address:
> 
> To subscribe to the list, send a message to:
>
> 
> To remove your address from the list, send a message to:
>
> 
> Send mail to the following for info and FAQ for this list:
>
>
> 
> Similar addresses exist for the digest list:
>
>
> 
> To get messages 123 through 145 (a maximum of 100 per request), mail:
>
> 
> To get an index with subject and author for messages 123-456 , mail:
>
> 
> They are always returned as sets of 100, max 2000 per request,
> so you'll actually get 100-499.
> 
> To receive all messages with the same subject as message 12345,
> send an empty message to:
>
> 
> The messages do not really need to be empty, but I will ignore
> their content. Only the ADDRESS you send to is important.
> 
> You can start a subscription for an alternate address,
> for example "john@host.domain", just add a hyphen and your
> address (with '=' instead of '@') after the command word:
> 
> 
> To stop subscription for this address, mail:
> 
> 
> In both cases, I'll send a confirmation message to that address. When
> you receive it, simply reply to it to complete your subscription.
> 
> If despite following these instructions, you do not get the
> desired results, please contact my owner at
> gcc-patches-ow...@gcc.gnu.org. Please be patient, my owner is a
> lot slower than I am ;-)
> 
> --- Enclosed is a copy of the request I received.
> 
> Return-Path: 
> Received: (qmail 50909 invoked by uid 48); 11 Sep 2017 23:56:54 -
> Message-ID: <20170911235654.50905.qm...@sourceware.org>
> From: anonym...@sourceware.org
> Date: Tue, 12 Sep 2017 05:26:54 +0530
> To: gcc-patches-subscribe-general+gcc=matley.com...@sourceware.org
> User-Agent: Heirloom mailx 12.4 7/29/08
> MIME-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> 
> 


Re: backwards threader cleanups

2017-09-11 Thread Jeff Law
On 09/02/2017 11:43 AM, Aldy Hernandez wrote:
> On Fri, Sep 1, 2017 at 6:11 PM, Jeff Law  wrote:
>> On 09/01/2017 02:18 PM, Aldy Hernandez wrote:
>>> Hi.
>>>
>>> Attached are misc cleanups to tree-ssa-threadbackwards.c and friends.
>>> The main gist of the patch is making the path vectors live in the
>>> heap, not GC.  But I also cleaned up some comments to reflect reality,
>>> and renamed VAR_BB which could use a more meaningful name.  Finally, I
>>> abstracted some common code to
>>> register_jump_thread_path_if_profitable() in preparation for some
>>> upcoming work by me :).
>>>
>>> Tested on x86-64 Linux.
>> It looks like you dropped a level of indirection for path in
>> profitable_jump_thread_path and perhaps others that push blocks onto the
>> path?   Does your change from having the vectors in the GC space to the
>> heap also change them from embeddable vectors to a space efficient
>> vector?  It has to for this change to be safe.
> 
> Part of my initial motivation was eliminating the double indirection
> as well as removing the out-of-line calls to vec_alloc() and
> vec_whatever_push().
> 
> And yes, the default plain vector<> uses the heap:
> 
> template  typename A = va_heap,
>  typename L = typename A::default_layout>
> struct GTY((user)) vec
> {
> };
> 
> ...and va_heap defaults to the space efficient vector:
> 
> struct va_heap
> {
>   typedef vl_ptr default_layout;
> ...
> }
> 
>>
>> See the discussion in vec.h
>>
>> I don't recall any inherent reason we use the embedded vector layout.
>> It's the default which is probably why it's used here more than anything.
> 
> Just a wild guess, but this may be why:
> 
>FIXME - Ideally, they would all be vl_ptr to encourage using regular
>instances for vectors, but the existing GTY machinery is limited
>in that it can only deal with GC objects that are pointers
>themselves.
> 
> and:
> 
>   /* Use vl_embed as the default layout for GC vectors.  Due to GTY
>  limitations, GC vectors must always be pointers, so it is more
>  efficient to use a pointer to the vl_embed layout, rather than
>  using a pointer to a pointer as would be the case with vl_ptr.  */
> 
>>
>> Otherwise the change looks good.  I think you just to make sure you're
>> not using the embedded layout.  Which I think is just a different type
>> when  you declare the vec.
> 
> I have made the vectors auto_vec as Trevor suggested.  As auto_vec is
> just an inherited plain vec<> with some magic allocation sauce, they
> can be passed around interchangeably.
> 
> I also changed the hash sets so they live on the stack as opposed to
> allocating memory dynamically, at Trevor's request as well.
> 
> Bootstraps.  OK pending another round of tests?
Yes.  Thanks for double-checking on the embedded vs space efficient stuff.

jeff


Re: [PATCH] fix PR translation/82185

2017-09-11 Thread Jeff Law
On 09/11/2017 03:59 PM, Max Filippov wrote:
> Hi Richard,
> 
> On Mon, Sep 11, 2017 at 2:36 PM, Richard Sandiford
>  wrote:
>> Max Filippov  writes:
>>> 2017-09-11  Max Filippov  
>>> gcc/
>>>   * expmed.c (emit_store_flag_int): Initialize rtx tem.
>>
>> LGTM, thanks, but I can't approve it.
>>
>> This makes the later "tem = 0;" redundant, so perhaps it would make
>> sense to delete that too?  There again, it was redundant before the
>> split as well.
>>
>> An alternative would be to only test tem when we've done something
>> with it, as below, but I don't know if that's better or a step backwards.
> 
> this works for me too, so whichever fix you like better.
I like narrowing the scope better -- it's a lot easier to reason about
the code when the def and uses are close and there's not a ton of
control flow.

Jeff


Re: Turn HARD_REGNO_NREGS into a target hook

2017-09-11 Thread Jeff Law
On 09/11/2017 11:18 AM, Richard Sandiford wrote:
> Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
> Also tested by comparing the testsuite assembly output on at least one
> target per CPU directory.  OK to install?
> 
> Richard
> 
> 
> gcc/
>   * target.def (hard_regno_nregs): New hook.
>   (class_max_nregs): Refer to it instead of HARD_REGNO_NREGS.
>   * targhooks.h (default_hard_regno_nregs): Declare.
>   * targhooks.c (default_hard_regno_nregs): New function.
>   * doc/tm.texi.in (HARD_REGNO_NREGS): Replace with...
>   (TARGET_HARD_REGNO_NREGS): ...this hook.
>   (HARD_REGNO_NREGS_HAS_PADDING): Update accordingly.
>   (CLASS_MAX_NREGS): Likewise.
>   * doc/tm.texi: Regenerate.
>   * reginfo.c (init_reg_modes_target): Use targetm.hard_regno_nregs
>   instead of HARD_REGNO_NREGS.
>   * rtl.h (REG_NREGS): Refer to TARGET_HARD_REGNO_NREGS rather than
>   HARD_REGNO_NREGS in the comment.
>   * config/aarch64/aarch64.h (HARD_REGNO_NREGS): Delete.
>   * config/aarch64/aarch64-protos.h (aarch64_hard_regno_nregs): Delete.
>   * config/aarch64/aarch64.c (aarch64_hard_regno_nregs): Make static.
>   Return an unsigned int.
>   (TARGET_HARD_REGNO_NREGS): Redefine.
>   * config/alpha/alpha.h (HARD_REGNO_NREGS): Delete.
>   * config/arc/arc.h (HARD_REGNO_NREGS): Delete.
>   * config/arc/arc.c (TARGET_HARD_REGNO_NREGS): Redefine.
>   (arc_hard_regno_nregs): New function.
>   * config/arm/arm.h (HARD_REGNO_NREGS): Delete.
>   * config/arm/arm.c (TARGET_HARD_REGNO_NREGS): Redefine.
>   (arm_hard_regno_nregs): New function.
>   * config/avr/avr.h (HARD_REGNO_NREGS): Delete.
>   * config/bfin/bfin.h (HARD_REGNO_NREGS): Delete.
>   * config/bfin/bfin.c (bfin_hard_regno_nregs): New function.
>   (TARGET_HARD_REGNO_NREGS): Redefine.
>   * config/c6x/c6x.h (HARD_REGNO_NREGS): Delete.
>   * config/cr16/cr16.h (LONG_REG_P): Use targetm.hard_regno_nregs.
>   (HARD_REGNO_NREGS): Delete.
>   * config/cr16/cr16.c (TARGET_HARD_REGNO_NREGS): Redefine.
>   (cr16_hard_regno_nregs): New function.
>   (cr16_memory_move_cost): Use it instead of HARD_REGNO_NREGS.
>   * config/cris/cris.h (HARD_REGNO_NREGS): Delete.
>   * config/cris/cris.c (TARGET_HARD_REGNO_NREGS): Redefine.
>   (cris_hard_regno_nregs): New function.
>   * config/epiphany/epiphany.h (HARD_REGNO_NREGS): Delete.
>   * config/fr30/fr30.h (HARD_REGNO_NREGS): Delete.
>   (CLASS_MAX_NREGS): Use targetm.hard_regno_nregs.
>   * config/frv/frv.h (HARD_REGNO_NREGS): Delete.
>   (CLASS_MAX_NREGS): Remove outdated copy of documentation.
>   * config/frv/frv-protos.h (frv_hard_regno_nregs): Delete.
>   * config/frv/frv.c (TARGET_HARD_REGNO_NREGS): Redefine.
>   (frv_hard_regno_nregs): Make static.  Take and return an
>   unsigned int.
>   (frv_class_max_nregs): Remove outdated copy of documentation.
>   * config/ft32/ft32.h (HARD_REGNO_NREGS): Delete.
>   * config/h8300/h8300.h (HARD_REGNO_NREGS): Delete.
>   * config/h8300/h8300-protos.h (h8300_hard_regno_nregs): Delete.
>   * config/h8300/h8300.c (h8300_hard_regno_nregs): Delete.
>   * config/i386/i386.h (HARD_REGNO_NREGS): Delete.
>   * config/i386/i386.c (ix86_hard_regno_nregs): New function.
>   (TARGET_HARD_REGNO_NREGS): Redefine.
>   * config/ia64/ia64.h (HARD_REGNO_NREGS): Delete.
>   (CLASS_MAX_NREGS): Update comment.
>   * config/ia64/ia64.c (TARGET_HARD_REGNO_NREGS): Redefine.
>   (ia64_hard_regno_nregs): New function.
>   * config/iq2000/iq2000.h (HARD_REGNO_NREGS): Delete.
>   * config/lm32/lm32.h (HARD_REGNO_NREGS): Delete.
>   * config/m32c/m32c.h (HARD_REGNO_NREGS): Delete.
>   * config/m32c/m32c-protos.h (m32c_hard_regno_nregs): Delete.
>   * config/m32c/m32c.c (m32c_hard_regno_nregs_1): Take and return
>   an unsigned int.
>   (m32c_hard_regno_nregs): Likewise.  Make static.
>   (TARGET_HARD_REGNO_NREGS): Redefine.
>   * config/m32r/m32r.h (HARD_REGNO_NREGS): Delete.
>   * config/m68k/m68k.h (HARD_REGNO_NREGS): Delete.
>   * config/m68k/m68k.c (TARGET_HARD_REGNO_NREGS): Redefine.
>   (m68k_hard_regno_nregs): New function.
>   * config/mcore/mcore.h (HARD_REGNO_NREGS): Delete.
>   * config/microblaze/microblaze.h (HARD_REGNO_NREGS): Delete.
>   * config/mips/mips.h (HARD_REGNO_NREGS): Delete.
>   * config/mips/mips-protos.h (mips_hard_regno_nregs): Delete.
>   * config/mips/mips.c (mips_hard_regno_nregs): Make static.
>   Take and return an unsigned int.
>   (TARGET_HARD_REGNO_NREGS): Redefine.
>   * config/mmix/mmix.h (HARD_REGNO_NREGS): Delete.
>   (CLASS_MAX_NREGS): Use targetm.hard_regno_nregs.
>   * config/mn10300/mn10300.h (HARD_REGNO_NREGS): Delete.
>   * config/moxie/moxie.h (HARD_REGNO_NREGS): Delete.
>   * config/msp430/msp430.h (HARD_REGNO_NREGS): Delete.
>

Re: [patch, fortran, RFC] warn about out-of-bounds errors in DO loops

2017-09-11 Thread Thomas Koenig

Well, here's a version which actually throws a hard error in
obvious cases; the other cases are reserved for -Wextra.

Turns up a few bugs in the testsuite, too.

An interesting one is unconstrained_commons.f, where
the code quite happily saves and stores outside a common
block array with a single element.  Illegal, but apparently
wanted with a special option.

So, what do you think?  Should I proceed like this and make
this a formal submission?

Regards

Thomas
Index: frontend-passes.c
===
--- frontend-passes.c	(Revision 251951)
+++ frontend-passes.c	(Arbeitskopie)
@@ -39,6 +39,8 @@ static bool optimize_lexical_comparison (gfc_expr
 static void optimize_minmaxloc (gfc_expr **);
 static bool is_empty_string (gfc_expr *e);
 static void doloop_warn (gfc_namespace *);
+static int do_intent (gfc_expr **);
+static int do_subscript (gfc_expr **);
 static void optimize_reduction (gfc_namespace *);
 static int callback_reduction (gfc_expr **, int *, void *);
 static void realloc_strings (gfc_namespace *);
@@ -98,10 +100,20 @@ static int iterator_level;
 
 /* Keep track of DO loop levels.  */
 
-static vec doloop_list;
+typedef struct {
+  gfc_code *c;
+  int branch_level;
+  bool seen_goto;
+} do_t;
 
+static vec doloop_list;
 static int doloop_level;
 
+/* Keep track of if and select case levels.  */
+
+static int if_level;
+static int select_level;
+
 /* Vector of gfc_expr * to keep track of DO loops.  */
 
 struct my_struct *evec;
@@ -133,6 +145,8 @@ gfc_run_passes (gfc_namespace *ns)
  change.  */
 
   doloop_level = 0;
+  if_level = 0;
+  select_level = 0;
   doloop_warn (ns);
   doloop_list.release ();
   int w, e;
@@ -2231,6 +2245,8 @@ doloop_code (gfc_code **c, int *walk_subtrees ATTR
   gfc_formal_arglist *f;
   gfc_actual_arglist *a;
   gfc_code *cl;
+  do_t loop, *lp;
+  bool seen_goto;
 
   co = *c;
 
@@ -2239,16 +2255,67 @@ doloop_code (gfc_code **c, int *walk_subtrees ATTR
   if ((unsigned) doloop_level < doloop_list.length())
 doloop_list.truncate (doloop_level);
 
+  seen_goto = false;
   switch (co->op)
 {
 case EXEC_DO:
 
   if (co->ext.iterator && co->ext.iterator->var)
-	doloop_list.safe_push (co);
+	loop.c = co;
   else
-	doloop_list.safe_push ((gfc_code *) NULL);
+	loop.c = NULL;
+
+  loop.branch_level = if_level + select_level;
+  loop.seen_goto = false;
+  doloop_list.safe_push (loop);
   break;
 
+  /* If anything could transfer control away from a suspicious
+	 subscript, make sure to set seen_goto in the current DO loop
+	 (if any).  */
+case EXEC_GOTO:
+case EXEC_EXIT:
+case EXEC_STOP:
+case EXEC_ERROR_STOP:
+case EXEC_CYCLE:
+  seen_goto = true;
+  break;
+
+case EXEC_OPEN:
+  if (co->ext.open->err)
+	seen_goto = true;
+  break;
+
+case EXEC_CLOSE:
+  if (co->ext.close->err)
+	seen_goto = true;
+  break;
+
+case EXEC_BACKSPACE:
+case EXEC_ENDFILE:
+case EXEC_REWIND:
+case EXEC_FLUSH:
+
+  if (co->ext.filepos->err)
+	seen_goto = true;
+  break;
+
+case EXEC_INQUIRE:
+  if (co->ext.filepos->err)
+	seen_goto = true;
+  break;
+
+case EXEC_READ:
+case EXEC_WRITE:
+  if (co->ext.dt->err || co->ext.dt->end || co->ext.dt->eor)
+	seen_goto = true;
+  break;
+
+case EXEC_WAIT:
+  if (co->ext.wait->err || co->ext.wait->end || co->ext.wait->eor)
+	loop.seen_goto = true;
+  break;
+
 case EXEC_CALL:
 
   if (co->resolved_sym == NULL)
@@ -2265,9 +2332,10 @@ doloop_code (gfc_code **c, int *walk_subtrees ATTR
 
   while (a && f)
 	{
-	  FOR_EACH_VEC_ELT (doloop_list, i, cl)
+	  FOR_EACH_VEC_ELT (doloop_list, i, lp)
 	{
 	  gfc_symbol *do_sym;
+	  cl = lp->c;
 
 	  if (cl == NULL)
 		break;
@@ -2282,14 +2350,14 @@ doloop_code (gfc_code **c, int *walk_subtrees ATTR
    "value inside loop  beginning at %L as "
    "INTENT(OUT) argument to subroutine %qs",
    do_sym->name, &a->expr->where,
-   &doloop_list[i]->loc,
+   &(doloop_list[i].c->loc),
    co->symtree->n.sym->name);
 		  else if (f->sym->attr.intent == INTENT_INOUT)
 		gfc_error_now ("Variable %qs at %L not definable inside "
    "loop beginning at %L as INTENT(INOUT) "
    "argument to subroutine %qs",
    do_sym->name, &a->expr->where,
-   &doloop_list[i]->loc,
+   &(doloop_list[i].c->loc),
    co->symtree->n.sym->name);
 		}
 	}
@@ -2301,20 +2369,314 @@ doloop_code (gfc_code **c, int *walk_subtrees ATTR
 default:
   break;
 }
+  if (seen_goto && doloop_level > 0)
+doloop_list[doloop_level-1].seen_goto = true;
+
   return 0;
 }
 
-/* Callback function for functions checking that we do not pass a DO variable
-   to an INTENT(OUT) or INTENT(INOUT) dummy variable.  */
+/* Callback function to warn about different things within DO loops.  */
 
 static int
 do_function (gfc_expr **e, int *walk_subtrees ATTRIBUTE_UNUSED,

Re: Turn SLOW_UNALIGNED_ACCESS into a target hook

2017-09-11 Thread Jeff Law
On 09/11/2017 11:13 AM, Richard Sandiford wrote:
> Pretty mechanical conversion.
> 
> Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
> Also tested by comparing the testsuite assembly output on at least one
> target per CPU directory.  OK to install?
> 
> Richard
> 
> 
> 2017-09-11  Richard Sandiford  
>   Alan Hayward  
>   David Sherwood 
> 
> gcc/
>   * defaults.h (SLOW_UNALIGNED_ACCESS): Delete.
>   * target.def (slow_unaligned_access): New hook.
>   * targhooks.h (default_slow_unaligned_access): Declare.
>   * targhooks.c (default_slow_unaligned_access): New function.
>   * doc/tm.texi.in (SLOW_UNALIGNED_ACCESS): Replace with...
>   (TARGET_SLOW_UNALIGNED_ACCESS): ...this.
>   * doc/tm.texi: Regenerate.
>   * config/alpha/alpha.h (SLOW_UNALIGNED_ACCESS): Delete.
>   * config/arm/arm.h (SLOW_UNALIGNED_ACCESS): Delete.
>   * config/i386/i386.h (SLOW_UNALIGNED_ACCESS): Delete commented-out
>   definition.
>   * config/powerpcspe/powerpcspe.h (SLOW_UNALIGNED_ACCESS): Delete.
>   * config/powerpcspe/powerpcspe.c (TARGET_SLOW_UNALIGNED_ACCESS):
>   Redefine.
>   (rs6000_slow_unaligned_access): New function.
>   (rs6000_emit_move): Use it instead of SLOW_UNALIGNED_ACCESS.
>   (expand_block_compare): Likewise.
>   (expand_strn_compare): Likewise.
>   (rs6000_rtx_costs): Likewise.
>   * config/riscv/riscv.h (SLOW_UNALIGNED_ACCESS): Delete.
>   (riscv_slow_unaligned_access): Likewise.
>   * config/riscv/riscv.c (riscv_slow_unaligned_access): Rename to...
>   (riscv_slow_unaligned_access_p): ...this and make static.
>   (riscv_option_override): Update accordingly.
>   (riscv_slow_unaligned_access): New function.
>   (TARGET_SLOW_UNALIGNED_ACCESS): Redefine.
>   * config/rs6000/rs6000.h (SLOW_UNALIGNED_ACCESS): Delete.
>   * config/rs6000/rs6000.c (TARGET_SLOW_UNALIGNED_ACCESS): Redefine.
>   (rs6000_slow_unaligned_access): New function.
>   (rs6000_emit_move): Use it instead of SLOW_UNALIGNED_ACCESS.
>   (rs6000_rtx_costs): Likewise.
>   * config/rs6000/rs6000-string.c (expand_block_compare)
>   (expand_strn_compare): Use targetm.slow_unaligned_access instead
>   of SLOW_UNALIGNED_ACCESS.
>   * config/tilegx/tilegx.h (SLOW_UNALIGNED_ACCESS): Delete.
>   * config/tilepro/tilepro.h (SLOW_UNALIGNED_ACCESS): Delete.
>   * calls.c (expand_call): Use targetm.slow_unaligned_access instead
>   of SLOW_UNALIGNED_ACCESS.
>   * expmed.c (simple_mem_bitfield_p): Likewise.
>   * expr.c (alignment_for_piecewise_move): Likewise.
>   (emit_group_load_1): Likewise.
>   (emit_group_store): Likewise.
>   (copy_blkmode_from_reg): Likewise.
>   (emit_push_insn): Likewise.
>   (expand_assignment): Likewise.
>   (store_field): Likewise.
>   (expand_expr_real_1): Likewise.
>   * gimple-fold.c (gimple_fold_builtin_memory_op): Likewise.
>   * lra-constraints.c (simplify_operand_subreg): Likewise.
>   * stor-layout.c (bit_field_mode_iterator::next_mode): Likewise.
>   * gimple-ssa-store-merging.c: Likewise in block comment at start
>   of file.
>   * tree-ssa-strlen.c: Include target.h.
>   (handle_builtin_memcmp): Use targetm.slow_unaligned_access instead
>   of SLOW_UNALIGNED_ACCESS.
>   * system.h (SLOW_UNALIGNED_ACCESS): Poison.
OK
jeff



Re: Use hard_regno_nregs instead of HARD_REGNO_NREGS

2017-09-11 Thread Jeff Law
On 09/11/2017 11:18 AM, Richard Sandiford wrote:
> This patch converts some places that use HARD_REGNO_NREGS to use
> hard_regno_nregs, in places where the initialisation has obviously
> already taken place.
> 
> Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
> Also tested by comparing the testsuite assembly output on at least one
> target per CPU directory.  OK to install?
> 
> Richard
> 
> 
> 2017-09-11  Richard Sandiford  
> 
> gcc/
>   * config/arm/arm.h (THUMB_SECONDARY_INPUT_RELOAD_CLASS): Use
>   hard_regno_nregs instead of HARD_REGNO_NREGS.
>   (THUMB_SECONDARY_OUTPUT_RELOAD_CLASS): Likewise.
>   * config/c6x/c6x.c (c6x_expand_prologue): Likewise.
>   (c6x_expand_epilogue): Likewise.
>   * config/frv/frv.c (frv_alloc_temp_reg): Likewise.
>   (frv_read_iacc_argument): Likewise.
>   * config/sh/sh.c: Include regs.h.
>   (sh_print_operand): Use hard_regno_nregs instead of HARD_REGNO_NREGS.
>   (regs_used): Likewise.
>   (output_stack_adjust): Likewise.
>   * config/xtensa/xtensa.c (xtensa_copy_incoming_a7): Likewise.
>   * expmed.c: Include regs.h.
>   (store_bit_field_1): Use hard_regno_nregs instead of HARD_REGNO_NREGS.
>   * ree.c: Include regs.h.
>   (combine_reaching_defs): Use hard_regno_nregs instead of
>   HARD_REGNO_NREGS.
>   (add_removable_extension): Likewise.
OK.
jeff


Re: Convert hard_regno_nregs to a function

2017-09-11 Thread Jeff Law
On 09/11/2017 11:17 AM, Richard Sandiford wrote:
> This patch converts hard_regno_nregs into an inline function, which
> in turn allows hard_regno_nregs to be used as the name of a targetm
> field.  This is just a mechanical change.
> 
> Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
> Also tested by comparing the testsuite assembly output on at least one
> target per CPU directory.  OK to install?
> 
> Richard
> 
> 
> 2017-09-11  Richard Sandiford  
> 
> gcc/
>   * regs.h (hard_regno_nregs): Turn into a function.
>   (end_hard_regno): Update accordingly.
>   * caller-save.c (setup_save_areas): Likewise.
>   (save_call_clobbered_regs): Likewise.
>   (replace_reg_with_saved_mem): Likewise.
>   (insert_restore): Likewise.
>   (insert_save): Likewise.
>   * combine.c (can_change_dest_mode): Likewise.
>   (move_deaths): Likewise.
>   (distribute_notes): Likewise.
>   * config/mips/mips.c (mips_hard_regno_call_part_clobbered): Likewise.
>   * config/powerpcspe/powerpcspe.c (rs6000_cannot_change_mode_class)
>   (rs6000_split_multireg_move): Likewise.
>   (rs6000_register_move_cost): Likewise.
>   (rs6000_memory_move_cost): Likewise.
>   * config/rs6000/rs6000.c (rs6000_cannot_change_mode_class): Likewise.
>   (rs6000_split_multireg_move): Likewise.
>   (rs6000_register_move_cost): Likewise.
>   (rs6000_memory_move_cost): Likewise.
>   * cselib.c (cselib_reset_table): Likewise.
>   (cselib_lookup_1): Likewise.
>   * emit-rtl.c (set_mode_and_regno): Likewise.
>   * function.c (aggregate_value_p): Likewise.
>   * ira-color.c (setup_profitable_hard_regs): Likewise.
>   (check_hard_reg_p): Likewise.
>   (calculate_saved_nregs): Likewise.
>   (assign_hard_reg): Likewise.
>   (improve_allocation): Likewise.
>   (calculate_spill_cost): Likewise.
>   * ira-emit.c (modify_move_list): Likewise.
>   * ira-int.h (ira_hard_reg_set_intersection_p): Likewise.
>   (ira_hard_reg_in_set_p): Likewise.
>   * ira.c (setup_reg_mode_hard_regset): Likewise.
>   (clarify_prohibited_class_mode_regs): Likewise.
>   (check_allocation): Likewise.
>   * lra-assigns.c (find_hard_regno_for_1): Likewise.
>   (lra_setup_reg_renumber): Likewise.
>   (setup_try_hard_regno_pseudos): Likewise.
>   (spill_for): Likewise.
>   (assign_hard_regno): Likewise.
>   (setup_live_pseudos_and_spill_after_risky_transforms): Likewise.
>   * lra-constraints.c (in_class_p): Likewise.
>   (lra_constraint_offset): Likewise.
>   (simplify_operand_subreg): Likewise.
>   (lra_constraints): Likewise.
>   (split_reg): Likewise.
>   (split_if_necessary): Likewise.
>   (invariant_p): Likewise.
>   (inherit_in_ebb): Likewise.
>   * lra-lives.c (process_bb_lives): Likewise.
>   * lra-remat.c (reg_overlap_for_remat_p): Likewise.
>   (get_hard_regs): Likewise.
>   (do_remat): Likewise.
>   * lra-spills.c (assign_spill_hard_regs): Likewise.
>   * mode-switching.c (create_pre_exit): Likewise.
>   * postreload.c (reload_combine_recognize_pattern): Likewise.
>   * recog.c (peep2_find_free_register): Likewise.
>   * regcprop.c (kill_value_regno): Likewise.
>   (set_value_regno): Likewise.
>   (copy_value): Likewise.
>   (maybe_mode_change): Likewise.
>   (find_oldest_value_reg): Likewise.
>   (copyprop_hardreg_forward_1): Likewise.
>   * regrename.c (check_new_reg_p): Likewise.
>   (regrename_do_replace): Likewise.
>   * reload.c (push_reload): Likewise.
>   (combine_reloads): Likewise.
>   (find_dummy_reload): Likewise.
>   (operands_match_p): Likewise.
>   (find_reloads): Likewise.
>   (find_equiv_reg): Likewise.
>   (reload_adjust_reg_for_mode): Likewise.
>   * reload1.c (count_pseudo): Likewise.
>   (count_spilled_pseudo): Likewise.
>   (find_reg): Likewise.
>   (clear_reload_reg_in_use): Likewise.
>   (free_for_value_p): Likewise.
>   (allocate_reload_reg): Likewise.
>   (choose_reload_regs): Likewise.
>   (reload_adjust_reg_for_temp): Likewise.
>   (emit_reload_insns): Likewise.
>   (delete_output_reload): Likewise.
>   * rtlanal.c (subreg_get_info): Likewise.
>   * sched-deps.c (sched_analyze_reg): Likewise.
>   * sel-sched.c (init_regs_for_mode): Likewise.
>   (mark_unavailable_hard_regs): Likewise.
>   (choose_best_reg_1): Likewise.
>   (verify_target_availability): Likewise.
>   * valtrack.c (dead_debug_insert_temp): Likewise.
>   * var-tracking.c (track_loc_p): Likewise.
>   (emit_note_insn_var_location): Likewise.
>   * varasm.c (make_decl_rtl): Likewise.
>   * reginfo.c (choose_hard_reg_mode): Likewise.
>   (init_reg_modes_target): Refer directly to
>   this_target_regs->x_hard_regno_nregs.
OK.
jeff



Re: Make more use of in_hard_reg_set_p

2017-09-11 Thread Jeff Law
On 09/11/2017 11:16 AM, Richard Sandiford wrote:
> An upcoming patch will convert hard_regno_nregs into an inline
> function, which in turn allows hard_regno_nregs to be used as the
> name of a targetm field.  This patch rewrites a use that can use
> in_hard_reg_set_p instead.
> 
> Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
> Also tested by comparing the testsuite assembly output on at least one
> target per CPU directory.  OK to install?
> 
> Richard
> 
> 
> 2017-09-11  Richard Sandiford  
> 
> gcc/
>   * ira-costs.c (record_operand_costs): Use in_hard_reg_set_p
>   instead of hard_regno_nregs.
OK.
jeff


Re: Make more use of end_hard_regno

2017-09-11 Thread Jeff Law
On 09/11/2017 11:16 AM, Richard Sandiford wrote:
> An upcoming patch will convert hard_regno_nregs into an inline
> function, which in turn allows hard_regno_nregs to be used as the
> name of a targetm field.  This patch rewrites uses that can use
> end_hard_regno instead.
> 
> Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
> Also tested by comparing the testsuite assembly output on at least one
> target per CPU directory.  OK to install?
> 
> Richard
> 
> 
> 2017-09-11  Richard Sandiford  
> 
> gcc/
>   * config/aarch64/aarch64.c (aarch64_hard_regno_mode_ok): Use
>   end_hard_regno instead of hard_regno_nregs.
>   * config/s390/s390.c (s390_reg_clobbered_rtx): Likewise.
>   * config/sparc/sparc.h (ASM_DECLARE_REGISTER_GLOBAL): Likewise.
>   * config/visium/visium.c (visium_hard_regno_mode_ok): Likewise.
>   * ira-color.c (improve_allocation): Likewise.
>   * lra-assigns.c (find_hard_regno_for_1): Likewise.
>   * lra-lives.c (mark_regno_live): Likewise.
>   (mark_regno_dead): Likewise.
>   * lra-remat.c (operand_to_remat): Likewise.
>   * lra.c (collect_non_operand_hard_regs): Likewise.
>   * postreload.c (reload_combine_note_store): Likewise.
>   (move2add_valid_value_p): Likewise.
>   * reload.c (regno_clobbered_p): Likewise.
OK.
Jeff


Re: std::forward_list optim for always equal allocator

2017-09-11 Thread Jonathan Wakely

On 11/09/17 22:39 +0200, Daniel Krügler wrote:

2017-09-11 22:36 GMT+02:00 François Dumont :
[..]

So my remark was rather for the:

  _Fwd_list_iterator() noexcept
  : _M_node() { }

that could simply be

_Fwd_list_iterator() = default;

no ?


Yes, that should be fine.


I'm not sure there's much benefit to that change.




Re: [PATCH] fix PR translation/82185

2017-09-11 Thread Max Filippov
Hi Richard,

On Mon, Sep 11, 2017 at 2:36 PM, Richard Sandiford
 wrote:
> Max Filippov  writes:
>> 2017-09-11  Max Filippov  
>> gcc/
>>   * expmed.c (emit_store_flag_int): Initialize rtx tem.
>
> LGTM, thanks, but I can't approve it.
>
> This makes the later "tem = 0;" redundant, so perhaps it would make
> sense to delete that too?  There again, it was redundant before the
> split as well.
>
> An alternative would be to only test tem when we've done something
> with it, as below, but I don't know if that's better or a step backwards.

this works for me too, so whichever fix you like better.

-- 
Thanks.
-- Max


[PATCH] PR libstdc++/70483 make std::string_view fully constexpr

2017-09-11 Thread Jonathan Wakely

This adds 'constexpr' everywhere it's missing from
std::basic_string_view.

PR libstdc++/70483
* include/bits/string_view.tcc (basic_string_view::find)
(basic_string_view::rfind, basic_string_view::find_first_of)
(basic_string_view::find_last_of, basic_string_view::find_first_not_of)
(basic_string_view::find_last_not_of): Add constexpr specifier.
* include/std/string_view (basic_string_view::operator=)
(basic_string_view::rbegin, basic_string_view::rend)
(basic_string_view::crbegin, basic_string_view::crend)
(basic_string_view::remove_prefix, basic_string_view::remove_suffix)
(basic_string_view::swap, basic_string_view::compare)
(basic_string_view::find, basic_string_view::rfind)
(basic_string_view::find_first_of, basic_string_view::find_last_of)
(basic_string_view::find_first_not_of)
(basic_string_view::find_last_not_of, basic_string_view::_M_check)
(basic_string_view::_M_limit, operator==, operator!=, operator<)
(operator>, operator<=, operator>=): Likewise.
* testsuite/21_strings/basic_string_view/modifiers/remove_prefix/
char/1.cc: Repeat tests in constexpr context.
* testsuite/21_strings/basic_string_view/modifiers/remove_prefix/
wchar_t/1.cc: Likewise.
* testsuite/21_strings/basic_string_view/modifiers/remove_suffix/
char/1.cc: Likewise.
* testsuite/21_strings/basic_string_view/modifiers/remove_suffix/
wchar_t/1.cc: Likewise.
* testsuite/21_strings/basic_string_view/operations/find/char/1.cc:
Likewise.
* testsuite/21_strings/basic_string_view/operations/find/char/2.cc:
Likewise.
* testsuite/21_strings/basic_string_view/operations/find/char/3.cc:
Likewise.
* testsuite/21_strings/basic_string_view/operations/find/wchar_t/1.cc:
Likewise.
* testsuite/21_strings/basic_string_view/operations/find/wchar_t/2.cc:
Likewise.
* testsuite/21_strings/basic_string_view/operations/find/wchar_t/3.cc:
Likewise.
* testsuite/21_strings/basic_string_view/operators/char/2.cc:
Likewise.
* testsuite/21_strings/basic_string_view/operators/wchar_t/2.cc:
Likewise.
* testsuite/21_strings/basic_string_view/range_access/char/1.cc: Test
cbegin, cend, rbegin, rend, crbegin and crend.
* testsuite/21_strings/basic_string_view/range_access/wchar_t/1.cc:
Likewise.
* testsuite/21_strings/basic_string_view/operations/compare/char/1.cc:
Remove trailing whitespace.
* testsuite/21_strings/basic_string_view/operations/compare/wchar_t/
1.cc: Likewise.
* testsuite/21_strings/basic_string_view/modifiers/swap/char/1.cc:
New.
* testsuite/21_strings/basic_string_view/modifiers/swap/wchar_t/1.cc:
New.
* testsuite/21_strings/basic_string_view/operations/compare/char/2.cc:
New.
* testsuite/21_strings/basic_string_view/operations/compare/wchar_t/
2.cc: New.

Tested powerpc64le-linux, committed to trunk.


commit 280c8e2870fc50a27a174a1b0fdb9d2a4d0a8d28
Author: Jonathan Wakely 
Date:   Mon Sep 11 22:03:23 2017 +0100

PR libstdc++/70483 make std::string_view fully constexpr

PR libstdc++/70483
* include/bits/string_view.tcc (basic_string_view::find)
(basic_string_view::rfind, basic_string_view::find_first_of)
(basic_string_view::find_last_of, 
basic_string_view::find_first_not_of)
(basic_string_view::find_last_not_of): Add constexpr specifier.
* include/std/string_view (basic_string_view::operator=)
(basic_string_view::rbegin, basic_string_view::rend)
(basic_string_view::crbegin, basic_string_view::crend)
(basic_string_view::remove_prefix, basic_string_view::remove_suffix)
(basic_string_view::swap, basic_string_view::compare)
(basic_string_view::find, basic_string_view::rfind)
(basic_string_view::find_first_of, basic_string_view::find_last_of)
(basic_string_view::find_first_not_of)
(basic_string_view::find_last_not_of, basic_string_view::_M_check)
(basic_string_view::_M_limit, operator==, operator!=, operator<)
(operator>, operator<=, operator>=): Likewise.
* testsuite/21_strings/basic_string_view/modifiers/remove_prefix/
char/1.cc: Repeat tests in constexpr context.
* testsuite/21_strings/basic_string_view/modifiers/remove_prefix/
wchar_t/1.cc: Likewise.
* testsuite/21_strings/basic_string_view/modifiers/remove_suffix/
char/1.cc: Likewise.
* testsuite/21_strings/basic_string_view/modifiers/remove_suffix/
wchar_t/1.cc: Likewise.
* testsuite/21_strings/basic_string_view/operations/find/char/1.cc:
Lik

Re: [PATCH] fix PR translation/82185

2017-09-11 Thread Richard Sandiford
Max Filippov  writes:
> 2017-09-11  Max Filippov  
> gcc/
>   * expmed.c (emit_store_flag_int): Initialize rtx tem.

LGTM, thanks, but I can't approve it.

This makes the later "tem = 0;" redundant, so perhaps it would make
sense to delete that too?  There again, it was redundant before the
split as well.

An alternative would be to only test tem when we've done something
with it, as below, but I don't know if that's better or a step backwards.

Thanks,
Richard

gcc/
* expmed.c (emit_store_flag_int): Only test tem if it has been
initialized.

Index: gcc/expmed.c
===
--- gcc/expmed.c(revision 251980)
+++ gcc/expmed.c(working copy)
@@ -5601,7 +5601,6 @@ emit_store_flag_int (rtx target, rtx sub
 {
   machine_mode target_mode = target ? GET_MODE (target) : VOIDmode;
   rtx_insn *last = get_last_insn ();
-  rtx tem;
 
   /* If this is an equality comparison of integers, we can try to exclusive-or
  (or subtract) the two operands and use a recursive call to try the
@@ -5610,8 +5609,8 @@ emit_store_flag_int (rtx target, rtx sub
 
   if ((code == EQ || code == NE) && op1 != const0_rtx)
 {
-  tem = expand_binop (mode, xor_optab, op0, op1, subtarget, 1,
- OPTAB_WIDEN);
+  rtx tem = expand_binop (mode, xor_optab, op0, op1, subtarget, 1,
+ OPTAB_WIDEN);
 
   if (tem == 0)
tem = expand_binop (mode, sub_optab, op0, op1, subtarget, 1,
@@ -5643,26 +5642,28 @@ emit_store_flag_int (rtx target, rtx sub
  && rtx_cost (GEN_INT (normalizep), mode, PLUS, 1,
   optimize_insn_for_speed_p ()) == 0)
{
- tem = emit_store_flag_1 (subtarget, rcode, op0, op1, mode, 0,
-  STORE_FLAG_VALUE, target_mode);
+ rtx tem = emit_store_flag_1 (subtarget, rcode, op0, op1, mode, 0,
+  STORE_FLAG_VALUE, target_mode);
  if (tem != 0)
tem = expand_binop (target_mode, add_optab, tem,
gen_int_mode (normalizep, target_mode),
target, 0, OPTAB_WIDEN);
+ if (tem != 0)
+   return tem;
}
   else if (!want_add
   && rtx_cost (trueval, mode, XOR, 1,
optimize_insn_for_speed_p ()) == 0)
{
- tem = emit_store_flag_1 (subtarget, rcode, op0, op1, mode, 0,
-  normalizep, target_mode);
+ rtx tem = emit_store_flag_1 (subtarget, rcode, op0, op1, mode, 0,
+  normalizep, target_mode);
  if (tem != 0)
tem = expand_binop (target_mode, xor_optab, tem, trueval, target,
INTVAL (trueval) >= 0, OPTAB_WIDEN);
+ if (tem != 0)
+   return tem;
}
 
-  if (tem != 0)
-   return tem;
   delete_insns_since (last);
 }
 
@@ -5680,7 +5681,7 @@ emit_store_flag_int (rtx target, rtx sub
   /* Try to put the result of the comparison in the sign bit.  Assume we can't
  do the necessary operation below.  */
 
-  tem = 0;
+  rtx tem = 0;
 
   /* To see if A <= 0, compute (A | (A - 1)).  A <= 0 iff that result has
  the sign bit set.  */


Re: [PATCH 1/13] D: The front-end (DMD) language implementation and license.

2017-09-11 Thread Walter Bright



On 9/11/2017 10:26 AM, Iain Buclaw wrote:

On 11 September 2017 at 17:12, Jeff Law  wrote:

On 05/28/2017 03:02 PM, Iain Buclaw wrote:

(Sorry, repost as I rushed the first one a bit).

This patch adds the DMD front-end proper and license (Boost) files,
comprised of a lexer, parser, and semantic analyzer.

Split 1/4

Gzipped because of size limitations.

So for 1/13, these are all bits that are maintained on github and we're
just a downstream user, right?  Meaning I don't need to do a deep dive
in this patch within the series, right?

Does this stuff get bound into GCC?  The reason I ask is the files are
under the Boost license with ownership by Digital Mars.  While we often
have a fair amount of leeway with runtime systems, we may not have the
same kind of license/ownership leeway with things that are actually part
of the compiler itself.

Did the discussions between the FSF, Digital Mars and Walter touch in
these issues at all?  Have you received any guidance from the parties on
this issue?

Is there any way this stuff could be a separate executable or DSO?  That
might make things easier on the licensing front.

Jeff


I am under the impression that Walter had assigned copyrights of the
DMD frontend to the FSF in 2011.  The license change to Boost came
about in 2014, all core maintainers of DMD did copyright assignments
to Digital Mars as a prerequisite for the transition.

Walter can you confirm the above is the case?


Yes.



I would be making an assumption here that there are no problems given
the current arrangement as I understand it, but would be best to check
this with the FSF legal be sure.

Iain.




Re: [PATCH] xtensa: fix PR target/82181

2017-09-11 Thread Max Filippov
On Mon, Sep 11, 2017 at 2:18 PM, augustine.sterl...@gmail.com
 wrote:
> On Mon, Sep 11, 2017 at 2:16 PM, Max Filippov  wrote:
>> 2017-09-11  Max Filippov  
>> gcc/
>> * config/xtensa/xtensa.c (xtensa_mem_offset): Check that both
>> words of E_DImode object are reachable by xtensa_uimm8x4 access.
>
> Approved. Please apply.

Applied to trunk, thanks.
I will also backport the fix to 5.x, 6.x and 7.x branches.

-- Max


Re: [PATCH] xtensa: fix PR target/82181

2017-09-11 Thread augustine.sterl...@gmail.com
On Mon, Sep 11, 2017 at 2:16 PM, Max Filippov  wrote:
> 2017-09-11  Max Filippov  
> gcc/
> * config/xtensa/xtensa.c (xtensa_mem_offset): Check that both
> words of E_DImode object are reachable by xtensa_uimm8x4 access.

Approved. Please apply.


[PATCH] xtensa: fix PR target/82181

2017-09-11 Thread Max Filippov
2017-09-11  Max Filippov  
gcc/
* config/xtensa/xtensa.c (xtensa_mem_offset): Check that both
words of E_DImode object are reachable by xtensa_uimm8x4 access.
---
 gcc/config/xtensa/xtensa.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/config/xtensa/xtensa.c b/gcc/config/xtensa/xtensa.c
index f7ce08478aa2..0f84cf3a7a04 100644
--- a/gcc/config/xtensa/xtensa.c
+++ b/gcc/config/xtensa/xtensa.c
@@ -615,6 +615,7 @@ xtensa_mem_offset (unsigned v, machine_mode mode)
 case E_HImode:
   return xtensa_uimm8x2 (v);
 
+case E_DImode:
 case E_DFmode:
   return (xtensa_uimm8x4 (v) && xtensa_uimm8x4 (v + 4));
 
-- 
2.1.4



[PATCH] fix PR translation/82185

2017-09-11 Thread Max Filippov
2017-09-11  Max Filippov  
gcc/
* expmed.c (emit_store_flag_int): Initialize rtx tem.
---
 gcc/expmed.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/expmed.c b/gcc/expmed.c
index 7f0cb0a0ec05..945ab3d656a2 100644
--- a/gcc/expmed.c
+++ b/gcc/expmed.c
@@ -5601,7 +5601,7 @@ emit_store_flag_int (rtx target, rtx subtarget, enum 
rtx_code code, rtx op0,
 {
   machine_mode target_mode = target ? GET_MODE (target) : VOIDmode;
   rtx_insn *last = get_last_insn ();
-  rtx tem;
+  rtx tem = NULL_RTX;
 
   /* If this is an equality comparison of integers, we can try to exclusive-or
  (or subtract) the two operands and use a recursive call to try the
-- 
2.1.4



Re: std::forward_list optim for always equal allocator

2017-09-11 Thread Daniel Krügler
2017-09-11 22:36 GMT+02:00 François Dumont :
[..]
> So my remark was rather for the:
>
>   _Fwd_list_iterator() noexcept
>   : _M_node() { }
>
> that could simply be
>
> _Fwd_list_iterator() = default;
>
> no ?

Yes, that should be fine.

- Daniel


Re: std::forward_list optim for always equal allocator

2017-09-11 Thread François Dumont

On 11/09/2017 14:11, Jonathan Wakely wrote:

On 11/09/17 07:44 +0200, Daniel Krügler wrote:

2017-09-11 7:12 GMT+02:00 François Dumont :

When user declare a container iterator like that:

std::forward_list::iterator it;

There is no reason to initialize it with a null node pointer. It is 
just an

uninitialized iterator which is invalid to use except to initialize it.


While that is correct, for every forward iterator (and
std::forward_list::iterator meets these requirements), it is also
required that a value-initialized iterator can be compared against
other initialized iterators, so this reduces the amount of freedom to
define a default constructor for such iterators even when used to
default-initialize. This is not meant as a showstopper argument, since
I have not fully understood of what you are planning, but just a
reminder.


Right, which means that
std::forward_list::iterator it = {};

must initialize the node pointer to nullptr. If we remove the
initialization of _Fwd_list_iterator::_M_node from the default
constructor then it would be left uninitialized.

But I'm confused, François was talking about removing the
initialization of _Fwd_list_node_base::_M_next, what has that got to
do with forward_list::iterator? Thee is no node-base in the
iterator.

So I'm still wondering why the initialization of _M_next should be
removed.


Indeed, the iterator contains a _Fwd_list_node_base*.

So my remark was rather for the:

  _Fwd_list_iterator() noexcept
  : _M_node() { }

that could simply be

_Fwd_list_iterator() = default;

no ?

François



Re: [patch] Fix wrong code with small structure return on PowerPC

2017-09-11 Thread Eric Botcazou
> I think the issue is that we set SUBREG_PROMOTED_* on something that is
> possibly not so (aka uninitialized in this case).

Yes, that's what I called inherent weakness of the promoted subregs mechanism.

> We may only set it if either the ABI or a previous operation forced it to.
> Maybe this is also the reason why we need this zero init pass in some cases
> (though that isn't a full solution either).

Do you think that we should zero-init all the unsigned promoted subregs (and 
sign-extend-init all the signed promoted subregs)?  That sounds like a big 
hammer to me, but I can give it a try.

-- 
Eric Botcazou


Re: Make more use of REG_NREGS

2017-09-11 Thread Jeff Law
On 09/11/2017 11:14 AM, Richard Sandiford wrote:
> An upcoming patch will convert hard_regno_nregs into an inline
> function, which in turn allows hard_regno_nregs to be used as the
> name of a targetm field.  This patch rewrites uses that are more
> easily (and efficiently) written as REG_NREGS.
> 
> Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
> Also tested by comparing the testsuite assembly output on at least one
> target per CPU directory.  OK to install?
> 
> Richard
> 
> 
> 2017-09-11  Richard Sandiford  
> 
> gcc/
>   * caller-save.c (add_used_regs): Use REG_NREGS instead of
>   hard_regno_nregs.
>   * config/aarch64/aarch64.c (aarch64_split_combinev16qi): Likewise.
>   * config/arm/arm.c (output_move_neon): Likewise.
>   (arm_attr_length_move_neon): Likewise.
>   (neon_split_vcombine): Likewise.
>   * config/c6x/c6x.c (c6x_mark_reg_read): Likewise.
>   (c6x_mark_reg_written): Likewise.
>   (c6x_dwarf_register_span): Likewise.
>   * config/i386/i386.c (ix86_save_reg): Likewise.
>   * config/ia64/ia64.c (mark_reg_gr_used_mask): Likewise.
>   (rws_access_reg): Likewise.
>   * config/s390/s390.c (s390_call_saved_register_used): Likewise.
>   * mode-switching.c (create_pre_exit): Likewise.
>   * ree.c (combine_reaching_defs): Likewise.
>   (add_removable_extension): Likewise.
>   * regcprop.c (find_oldest_value_reg): Likewise.
>   (copyprop_hardreg_forward_1): Likewise.
>   * reload.c (reload_inner_reg_of_subreg): Likewise.
>   (push_reload): Likewise.
>   (combine_reloads): Likewise.
>   (find_dummy_reload): Likewise.
>   (reload_adjust_reg_for_mode): Likewise.
>   * reload1.c (find_reload_regs): Likewise.
>   (forget_old_reloads_1): Likewise.
>   (reload_reg_free_for_value_p): Likewise.
>   (reload_adjust_reg_for_temp): Likewise.
>   (emit_reload_insns): Likewise.
>   (delete_output_reload): Likewise.
>   * sel-sched.c (choose_best_reg_1): Likewise.
>   (choose_best_pseudo_reg): Likewise.
OK.
jeff


Re: [Patch, fortran] PR82173 (PDT) - [meta-bug] Parameterized derived type errors

2017-09-11 Thread Janus Weil
Hi Paul,

> I have fixed all the PDT bugs that have been reported to me so far in
> the attached patch. The patch is straightforward and is commented for
> clarity where necessary. Please note that whitespace changes have been
> suppressed. For this reason, if you are tempted to try the patch use
> the -l option when you apply it.
>
> Bootstrapped and regtested on FC23/x86_64 - OK for trunk?

yes, looks good to me (except that you seem to confuse me with Thomas
- I recognize those test cases as mine ;)

Thanks for taking care of this so quickly!

Cheers,
Janus


Re: [Ada] Pragma Atomic wrongly rejected on composite component

2017-09-11 Thread Eric Botcazou
> That regresses on gnat.dg/specs/atomic1.ads for aarch64/-mabi=ilp32,
> missing the error on line 13.  The missing error on line 9 is
> preexisting.

That's sort of expected, since the point of the patch is to make the 2 
situations equivalent wrt atomicity.  Clearly the test is not portable and 
will fail on targets for which pointer size and word size are not equal.

-- 
Eric Botcazou


Re: [Patch, fortran] PR34640 - ICE when assigning item of a derived-component to a pointer

2017-09-11 Thread H.J. Lu
On Sun, Jul 9, 2017 at 11:43 AM, Paul Richard Thomas
 wrote:
> Hi Thomas, Hi All,
>
> Please find attached what I believe is the final version of the patch.
>
> The problem concerning temporaries being generated in lieu of the
> descriptor being passed directly - see pointer_array_7.f90 and the
> change to subref_array_4.f90. This latter necessitated a thread on clf
> to get right. Thanks are due to Thomas for initiating it.
>
> I took the opportunity of the delay, while the bounds issue was being
> discussed on clf, to fix class pointer arrays. They now function
> correctly, as evidenced by pointer_array_8.f90.
>
> A possible final tweak - as asked before, should I bump up the module
> version number? My inclination is to say that we should.
>
> Bootstrapped and regtested on FC23/x86_64 - OK for trunk?
>
> Paul
>
> 2017-07-09  Paul Thomas  
>
> PR fortran/34640
> PR fortran/40737
> PR fortran/55763
> PR fortran/57019
> PR fortran/57116
>
> * expr.c (is_subref_array): Add class pointer array dummies
> to the list of expressions that return true.
> * trans-array.c: Add SPAN_FIELD and update indices for
> subsequent fields.
> (gfc_conv_descriptor_span, gfc_conv_descriptor_span_get,
> gfc_conv_descriptor_span_set, is_pointer_array,
> get_array_span): New functions.
> (gfc_get_descriptor_offsets_for_info): New function to preserve
> API for access to descriptor fields for trans-types.c.
> (gfc_conv_scalarized_array_ref): If the expression is a subref
> array, make sure that info->descriptor is a descriptor type.
> Otherwise, if info->descriptor is a pointer array, set 'decl'
> and fix it if it is a component reference.
> (build_array_ref): Simplify handling of class array refs by
> passing the vptr to gfc_build_array_ref rather than generating
> the pointer arithmetic in this function.
> (gfc_conv_array_ref): As in gfc_conv_scalarized_array_ref, set
> 'decl'.
> (gfc_array_allocate): Set the span field if this is a pointer
> array. Use the expr3 element size if it is available, so that
> the dynamic type element size is used.
> (gfc_conv_expr_descriptor): Set the span field for pointer
> assignments.
> * trans-array.h: Prototypes for gfc_conv_descriptor_span_get
> gfc_conv_descriptor_span_set and
> gfc_get_descriptor_offsets_for_info added.
> trans-decl.c (gfc_get_symbol_decl): If a non-class pointer
> array, mark the declaration as a GFC_DECL_PTR_ARRAY_P. Remove
> the setting of GFC_DECL_SPAN.
> (gfc_trans_deferred_vars): Set the span field to zero in thge
> originating scope.
> * trans-expr.c (gfc_conv_procedure_call): Do not use copy-in/
> copy-out to pass subref expressions to a pointer dummy.
> (gfc_trans_pointer_assignment): Remove code for setting of
> GFC_DECL_SPAN. Set the 'span' field for non-class pointers to
> class function results. Likewise for rank remap.
> * trans-intrinsic.c (conv_expr_ref_to_caf_ref): Pick up the
> 'token' offset from the field decl in the descriptor.
> (conv_isocbinding_subroutine): Set the 'span' field.
> * trans-io.c (gfc_trans_transfer): Always scalarize pointer
> array io.
> * trans-stmt.c (trans_associate_var): Set the 'span' field.
> * trans-types.c (gfc_get_array_descriptor_base): Add the 'span'
> field to the array descriptor.
> (gfc_get_derived_type): Pointer array components are marked as
> GFC_DECL_PTR_ARRAY_P.
> (gfc_get_array_descr_info): Replaced API breaking code for
> descriptor offset calling gfc_get_descriptor_offsets_for_info.
> * trans.c (get_array_span): New function.
> (gfc_build_array_ref): Simplify by calling get_array_span and
> obtain 'span' if 'decl' or 'vptr' present.
> * trans.h : Rename DECL_LANG_FLAG_6, GFC_DECL_SUBREF_ARRAY_P,
> as GFC_DECL_PTR_ARRAY_P.
>
>
> 2017-07-09  Paul Thomas  
>
> PR fortran/34640
> * gfortran.dg/assumed_type_2.f90: Adjust some of the tree dump
> checks.
> * gfortran.dg/no_arg_check_2.f90: Likewise.
> * gfortran.dg/pointer_array_1.f90: New test.
> * gfortran.dg/pointer_array_2.f90: New test.
> * gfortran.dg/pointer_array_7.f90: New test.
> * gfortran.dg/pointer_array_8.f90: New test.
> * gfortran.dg/pointer_array_component_1.f90: New test.
> * gfortran.dg/pointer_array_component_2.f90: New test.
> * gfortran.dg/goacc/kernels-alias-4.f95: Bump up both tree scan
> counts by 1.
> * gfortran.dg/subref_array_pointer_4.f90: Use the passed lower
> bound for 'Q' to provide an offset for array element access.
>
> PR fortran/40737
> * gfortran.dg/pointer_array_3.f90: New test.
>
> PR fortran/57116
> * gfortran.dg/pointer_array_4.f90: New test.
>
> PR fortran/55763
> * gfortran.dg/pointer_array_5.f90: New test.
>
> PR fortran/57019
> * gfortran.dg/pointer_array_6.f90: New test.
>
> 2017-07-09  Paul Thomas  
>
> P

[Patch, fortran] PR82173 (PDT) - [meta-bug] Parameterized derived type errors

2017-09-11 Thread Paul Richard Thomas
Dear Thomas, dear All,

I have fixed all the PDT bugs that have been reported to me so far in
the attached patch. The patch is straightforward and is commented for
clarity where necessary. Please note that whitespace changes have been
suppressed. For this reason, if you are tempted to try the patch use
the -l option when you apply it.

Bootstrapped and regtested on FC23/x86_64 - OK for trunk?

Since I really want to get on with other things, if I do not receive
any contrary comments I will commit tomorrow night.

Cheers

Paul

2017-09-11  Paul Thomas  

PR fortran/82173
PR fortran/82168
* decl.c (variable_decl): Check pdt template components for
appearance of KIND/LEN components in the type parameter name
list, that components corresponding to type parameters have
either KIND or LEN attributes and that KIND or LEN components
are scalar. Copy the initializer to the parameter value.
(gfc_get_pdt_instance): Add a label 'error_return' and follow
it with repeated code, while replacing this code with a jump.
Check if a parameter appears as a component in the template.
Make sure that the parameter expressions are integer. Validate
KIND expressions.
(gfc_match_decl_type_spec): Search for pdt_types in the parent
namespace since they are instantiated in the template ns.
* expr.c (gfc_extract_int): Use a KIND parameter if it
appears as a component expression.
(gfc_check_init_expr): Allow expressions with the pdt_kind
attribute.
*primary.c (gfc_match_actual_arglist): Make sure that the first
keyword argument is recognised when 'pdt' is set.


2017-09-11  Paul Thomas  

PR fortran/82173
* gfortran.dg/pdt_4.f03 : Remove the 'is being used before it
is defined' error.
* gfortran.dg/pdt_6.f03 : New test.
* gfortran.dg/pdt_7.f03 : New test.
* gfortran.dg/pdt_8.f03 : New test.

PR fortran/82168
* gfortran.dg/pdt_9.f03 : New test.

-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein
Index: gcc/fortran/decl.c
===
*** gcc/fortran/decl.c  (revision 251948)
--- gcc/fortran/decl.c  (working copy)
*** variable_decl (int elem)
*** 2537,2542 
--- 2537,2575 
goto cleanup;
  }

+   if (gfc_current_state () == COMP_DERIVED
+   && gfc_current_block ()->attr.pdt_template)
+ {
+   gfc_symbol *param;
+   gfc_find_symbol (name, gfc_current_block ()->f2k_derived,
+  0, ¶m);
+   if (!param && (current_attr.pdt_kind || current_attr.pdt_len))
+   {
+ gfc_error ("The component with KIND or LEN attribute at %C does not "
+"not appear in the type parameter list at %L",
+&gfc_current_block ()->declared_at);
+ m = MATCH_ERROR;
+ goto cleanup;
+   }
+   else if (param && !(current_attr.pdt_kind || current_attr.pdt_len))
+   {
+ gfc_error ("The component at %C that appears in the type parameter "
+"list at %L has neither the KIND nor LEN attribute",
+&gfc_current_block ()->declared_at);
+ m = MATCH_ERROR;
+ goto cleanup;
+   }
+   else if (as && (current_attr.pdt_kind || current_attr.pdt_len))
+   {
+ gfc_error ("The component at %C which is a type parameter must be "
+"a scalar");
+ m = MATCH_ERROR;
+ goto cleanup;
+   }
+   else if (param && initializer)
+   param->value = gfc_copy_expr (initializer);
+ }
+
/* Add the initializer.  Note that it is fine if initializer is
   NULL here, because we sometimes also need to check if a
   declaration *must* have an initialization expression.  */
*** gfc_get_pdt_instance (gfc_actual_arglist
*** 3193,3200 
{
  gfc_error ("The type parameter spec list at %C cannot contain "
 "both ASSUMED and DEFERRED parameters");
! gfc_free_actual_arglist (type_param_spec_list);
! return MATCH_ERROR;
}
}

--- 3226,3232 
{
  gfc_error ("The type parameter spec list at %C cannot contain "
 "both ASSUMED and DEFERRED parameters");
! goto error_return;
}
}

*** gfc_get_pdt_instance (gfc_actual_arglist
*** 3202,3211 
name_seen = true;
param = type_param_name_list->sym;

kind_expr = NULL;
if (!name_seen)
{
! if (actual_param && actual_param->spec_type == SPEC_EXPLICIT)
kind_expr = gfc_copy_expr (actual_param->expr);
}
else
--- 3234,3260 
name_seen = true;
param = type_param_name_list->sym;

+   c1 = gfc_find_component (pdt, param->name, false, true, NULL);
+   if (!pdt->attr.use_assoc && !c1)
+   {
+ gfc_er

Re: [PATCH] Improve alloca alignment

2017-09-11 Thread Wilco Dijkstra
Jeff Law wrote:
> On 09/09/2017 02:51 AM, Eric Botcazou wrote:
> >> No, the stack never gets misaligned - my patch doesn't change that at all.
> > 
> > Yes, it does.  Dynamic allocation works like this: the amount to be 
> > allocated 
> > is added to VIRTUAL_STACK_DYNAMIC_REGNUM and the result is then dynamically 
> > aligned.  Your patch assumes that VIRTUAL_STACK_DYNAMIC_REGNUM is as 
> > aligned 
> > as the stack pointer, i.e. STACK_BOUNDARY, but that's wrong for 32-bit 
> > SPARC 
> > at least (that's why I put the ??? note at line 5746 in emit-rtl.c).
> This seems like a SPARC target problem to me -- essentially it's
> claiming a higher STACK_BOUNDARY than it really has.
> 
> Presumably there's a good reason for this and some kind of hack may be
> needed to deal with it in dynamically allocated space.  But it does not
> seem like we should be forcing all targets to allocate unnecessary space
> to deal with this.

It's not just STACK_BOUNDARY, the outgoing argument offset is incorrect too.
These snippets of code from PR78468 (comment 20) look very wrong:

sub %sp, %g2, %sp
add %sp, 108, %g3   ; g3 = fp - 28 (x)
sub %sp, %g2, %sp
add %sp, 108, %g2   ; g2 = fp - 44 (d)
sub %sp, %g1, %sp
add %sp, 112, %g1   ; g1 = fp - 56 (e)

There are several different outgoing argument offsets used here (108 and 112). 
This not only results in alloca blocks being unaligned (when they should be at 
least
aligned to STACK_BOUNDARY, ideally PREFERRED_STACK_BOUNDARY),
but this also means you end up with different alloca blocks overlapping and 
corrupting
each other in non-trivial ways...

Wilco

Re: Make more use of END_REGNO

2017-09-11 Thread Jeff Law
On 09/11/2017 11:15 AM, Richard Sandiford wrote:
> An upcoming patch will convert hard_regno_nregs into an inline
> function, which in turn allows hard_regno_nregs to be used as the
> name of a targetm field.  This patch rewrites uses that are more
> easily (and efficiently) written as END_REGNO.
> 
> Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
> Also tested by comparing the testsuite assembly output on at least one
> target per CPU directory.  OK to install?
> 
> Richard
> 
> 
> 2017-09-11  Richard Sandiford  
> 
> gcc/
>   * config/frv/frv.c (FOR_EACH_REGNO): Use END_REGNO instead of
>   hard_regno_nregs.
>   * config/v850/v850.c (v850_reorg): Likewise.
>   * reload.c (refers_to_regno_for_reload_p): Likewise.
>   (find_equiv_reg): Likewise.
>   * reload1.c (reload_reg_reaches_end_p): Likewise.
OK.
jeff


[PATCH] Fix PR 81096 (ttest failures)

2017-09-11 Thread Steve Ellcey
This patch fixes the ttest failures on aarch64 by adding AM_CFLAGS to
the test options, like btest already does and as Wilco says works for
him in Comment #4 of the bug report.

Tested by me on aarch64.  Ok to checkin?

Steve Ellcey
sell...@cavium.com


2017-09-11  Steve Ellcey  

PR other/81096
* libbacktrace/Makefile.in
(HAVE_PTHREAD_TRUE@@NATIVE_TRUE@ttest_CFLAGS): Add $(AM_CFLAGS)


diff --git a/libbacktrace/Makefile.in b/libbacktrace/Makefile.in
index 5b2159d..2d8c212 100644
--- a/libbacktrace/Makefile.in
+++ b/libbacktrace/Makefile.in
@@ -352,7 +352,7 @@ TESTS = $(check_PROGRAMS)
 @NATIVE_TRUE@edtest_SOURCES = edtest.c edtest2_build.c testlib.c
 @NATIVE_TRUE@edtest_LDADD = libbacktrace.la
 @HAVE_PTHREAD_TRUE@@NATIVE_TRUE@ttest_SOURCES = ttest.c testlib.c
-@HAVE_PTHREAD_TRUE@@NATIVE_TRUE@ttest_CFLAGS = -pthread
+@HAVE_PTHREAD_TRUE@@NATIVE_TRUE@ttest_CFLAGS = $(AM_CFLAGS) -pthread
 @HAVE_PTHREAD_TRUE@@NATIVE_TRUE@ttest_LDADD = libbacktrace.la
 
 # We can't use automake's automatic dependency tracking, because it


Re: [PATCH] Improve alloca alignment

2017-09-11 Thread Jeff Law
On 09/09/2017 02:51 AM, Eric Botcazou wrote:
>> No, the stack never gets misaligned - my patch doesn't change that at all.
> 
> Yes, it does.  Dynamic allocation works like this: the amount to be allocated 
> is added to VIRTUAL_STACK_DYNAMIC_REGNUM and the result is then dynamically 
> aligned.  Your patch assumes that VIRTUAL_STACK_DYNAMIC_REGNUM is as aligned 
> as the stack pointer, i.e. STACK_BOUNDARY, but that's wrong for 32-bit SPARC 
> at least (that's why I put the ??? note at line 5746 in emit-rtl.c).
This seems like a SPARC target problem to me -- essentially it's
claiming a higher STACK_BOUNDARY than it really has.

Presumably there's a good reason for this and some kind of hack may be
needed to deal with it in dynamically allocated space.  But it does not
seem like we should be forcing all targets to allocate unnecessary space
to deal with this.

Jeff


Re: [Ada] Pragma Atomic wrongly rejected on composite component

2017-09-11 Thread Andreas Schwab
On Sep 09 2017, Eric Botcazou  wrote:

>   * gcc-interface/decl.c (promote_object_alignment): New function taken
>   from...
>   (gnat_to_gnu_entity) : ...here.  Invoke it.
>   (gnat_to_gnu_field): If the field is Atomic or VFA, invoke it and
>   create a padding type on success before doing the atomic check.

That regresses on gnat.dg/specs/atomic1.ads for aarch64/-mabi=ilp32,
missing the error on line 13.  The missing error on line 9 is
preexisting.

Andreas.

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


Re: [PATCH v2 11/13] D: GCC builtins and runtime support.

2017-09-11 Thread Jakub Jelinek
On Mon, Sep 11, 2017 at 08:04:02PM +0200, Iain Buclaw wrote:
> > You may need to bump the copyright dates.
> >
> 
> I thought I bumped all copyright dates in v2 of the patch.  I will check 
> again.

Regarding copyright dates, after everything is committed, we should also
adjust
contrib/update-copyright.py
so that it is able to update the copyright on the D source files where we
want to bump them.

Jakub


Re: [PATCH v2 11/13] D: GCC builtins and runtime support.

2017-09-11 Thread Iain Buclaw
On 11 September 2017 at 18:40, Jeff Law  wrote:
> On 06/24/2017 11:53 AM, Iain Buclaw wrote:
>> On 28 May 2017 at 23:17, Iain Buclaw  wrote:
>>> This patch adds GCC builtins and runtime support for GDC compiled code.
>>>
>>>   - module __entrypoint defines the C main function.  Its contents are
>>> parsed and compiled in during compilation, but only if needed.
>>>   - module gcc.atomic is a deprecated module that defines templated
>>> __sync builtins.  It's original user, core.atomic, now uses the GCC
>>> __atomic builtins.
>>>   - module gcc.attribute exposes GDC-specific attributes.
>>>   - module gcc.backtrace implements backtrace support for GDC.
>>>   - module gcc.builtins exposes GCC builtins to D code.
>>>   - module gcc.config exposes things determined at configure time to D code.
>>>   - module gcc.deh implements D unwind EH.
>>>   - module gcc.libbacktrace defines C bindings to libbacktrace.
>>>   - module gcc.unwind defines C bindings to libgcc unwind library.
>>>   - libgphobos.spec contains a list of libraries to link in that are
>>> dependencies of D runtime and/or the Phobos standard library.  It is
>>> used by the GDC driver.
>>>
>>> ---
>> Added GCC Runtime Library Exception to gcc modules as requested.
> Nothing particularly concerning here now that the license is fixed.
> Based on my reading, this is all code that the FSF will own, so we don't
> have to worry about alternate upstreams, license exceptions, etc which
> makes things so much easier.
>
> You may need to bump the copyright dates.
>

I thought I bumped all copyright dates in v2 of the patch.  I will check again.

However, I will prep a v3 of the patch, as it has been some time since
June - I have made no changes to any of these files anyway.

Iain


Re: [PATCH 4/13] D: The front-end (GDC) config, makefile, and manpages.

2017-09-11 Thread Iain Buclaw
On 11 September 2017 at 18:05, Jeff Law  wrote:
> On 05/28/2017 03:12 PM, Iain Buclaw wrote:
>> This patch adds the D frontend language configure make files, as
>> described on the anatomy of a language front-end.
>>
>> ---
>>
>>
>> 04-d-frontend-misc.patch
>>
>>
>
>
>> +
>> +You can specify more than one input file on the @command{gdc} command line,
>> +in which case they will all be compiled.  If you specify a
>> +@code{-o @var{file}} option, all the input files will be compiled together,
>> +producing a single output file, named @var{file}.  This is allowed even
>> +when using @code{-S} or @code{-c}.
> So out of curiosity, when multiple sources are specified on the command
> line, are they subject to IPA as a group or are they handled individually?
>
>> +@item -fno-bounds-check
>> +@cindex @option{-fbounds-check}
>> +@cindex @option{-fno-bounds-check}
>> +Turns off array bounds checking for all functions, which can improve
>> +performance for code that uses array extensively.  Note that this
>> +can result in unpredictable behavior if the code in question actually
>> +does violate array bounds constraints.  It is safe to use this option
>> +if you are sure that your code will never throw a @code{RangeError}.
> So I don't know the internals of where you keep the bounds and how you
> generate code for checking, but it might be worth looking at what Roger
> Sayle did for Java array index checking back in 2016:
>
> https://gcc.gnu.org/ml/java-patches/2016-q1/msg00014.html
>
> I don't know if his trick of exposing an extra write would apply to D,
> but it's worth reviewing.
>

A dynamic array is a struct { size_t length, void* ptr }.  So if the
length was set in a place where the compiler can infer the value, then
it will be removed by the usual const propagation / dce passes.

Having a quick look, I am pretty sure that the code generation for D
is as such that, that particular case is handled without the extra
write - the length setting should already be exposed.

>> +
>> +@item -funittest
>> +@cindex @option{-funittest}
>> +@cindex @option{-fno-unittest}
>> +Turns on compilation of @code{unittest} code, and turns on the
>> +@code{version(unittest)} identifier.  This implies @option{-fassert}.
> I think we're using -fselftest elsewhere for unit testing bits within
> the compiler.  Can you look and see if your unit tests are comparable
> and perhaps consider using the same option if they are?
>

A unittest is a D language feature, D unittests are not compiled in by
default.  This turns them on.

Contrived example:

double pow2 (double x)
{
return x ^^ 2;
}

unittest
{
assert (pow2 (2) == 4);
}

>
>> +
>> +@node Code Generation
>> +@section Code Generation
>> +@cindex options, code generation
>> +
>> +In addition to the many @command{gcc} options controlling code generation,
>> +@command{gdc} has several options specific to itself.
>> +
>> +@table @gcctabopt
>> +
>> +@item -M
>> +@cindex @option{-M}
>> +Output the module dependencies of all source files being compiled in a
>> +format suitable for @command{make}.  The compiler outputs one
>> +@command{make} rule containing the object file name for that source file,
>> +a colon, and the names of all imported files.
> [ ... Many -M options ... ]
> Note we recently allowed generation of the dependency files even in the
> case some errors.  Please consider doing the same if it makes sense.
> See the Sept change to c_common_finish.
>

OK, thanks, I'll have a look.  The idea was to be closely resemble
C/C++, even though there is no preprocessor in D, and it outputs the
dependencies between module files.


>
>> +
>> +@c man begin ENVIRONMENT
>> +
>> +In addition to the many @command{gcc} environment variables that control
>> +its operation, @command{gdc} has a few environment variables specific to
>> +itself.
>> +
>> +@vtable @env
>> +
>> +@item D_IMPORT_PATH
>> +@findex D_IMPORT_PATH
>> +The value of @env{D_IMPORT_PATH} is a list of directories separated by a
>> +special character, much like @env{PATH}, in which to look for imports.
>> +The special character, @code{PATH_SEPARATOR}, is target-dependent and
>> +determined at GCC build time.  For Microsoft Windows-based targets it is a
>> +semicolon, and for almost all other targets it is a colon.
>> +
>> +@item DDOCFILE
>> +@findex DDOCFILE
>> +If @env{DDOCFILE} is set, it specifies a text file of macro definitions
>> +to be read and used by the Ddoc generator.  This overrides any macros
>> +defined in other @file{.ddoc} files.
> How important are the environment variables to the existing user base?
> We generally try to avoid changing much behavior based on environment
> variables.  Can these be made command line options?
>
> jeff

For D_IMPORT_PATH, there's -I /somedir, I wouldn't say that it needs
to be there, its just an equivalent of something that gcc exposes.

DDOCFILE I found in the DMD front-end implementation, and so thought
it best to say something about it.

Iain.


Re: [PATCH 3/13] D: The front-end (GDC) changelogs.

2017-09-11 Thread Iain Buclaw
On 11 September 2017 at 17:43, Jeff Law  wrote:
> On 05/28/2017 03:11 PM, Iain Buclaw wrote:
>> This patch just includes all changelogs for the D front-end (GDC),
>> going back to the dawn of time itself.
>>
>> Change logs for the DMD front-end and libraries are kept on the dlang site.
> Your call on how much of the historical record you want to keep.
>
> jeff

I'll paraphrase the words of Alan at the Cauldron last weekend: Would
you want your name removed from the Changelog without you knowing?

This front-end has been going for over a decade now, and I wouldn't
feel comfortable removing the original authors from that history.

Iain.


Re: [PATCH 2/13] D: The front-end (GDC) implementation.

2017-09-11 Thread Iain Buclaw
On 11 September 2017 at 17:42, Jeff Law  wrote:
> On 05/28/2017 03:11 PM, Iain Buclaw wrote:
>> This patch adds the D front-end implementation, the only part of the
>> compiler that interacts with GCC directly, and being the parts that I
>> maintain, is something that I can talk about more directly.
>>
>> For the actual code generation pass, that converts the front-end AST
>> to GCC trees, most parts use a separate Visitor interfaces to do a
>> certain kind of lowering, for instance, types.cc builds *_TYPE trees
>> from AST Type's.  The Visitor class is part of the DMD front-end, and
>> is defined in dfrontend/visitor.h.
>>
>> There are also a few interfaces which have their headers in the DMD
>> frontend, but are implemented here because they do something that
>> requires knowledge of the GCC backend (d-target.cc), does something
>> that may not be portable, or differ between D compilers
>> (d-frontend.cc) or are a thin wrapper around something that is managed
>> by GCC (d-diagnostic.cc).
>>
>> Many high level operations result in generation of calls to D runtime
>> library functions (runtime.def), all with require some kind of runtime
>> type information (typeinfo.cc).  The compiler also generates functions
>> for registering/deregistering compiled modules with the D runtime
>> library (modules.cc).
>>
>> As well as the D language having it's own built-in functions
>> (intrinsics.cc), we also expose GCC builtins to D code via a
>> `gcc.builtins' module (d-builtins.cc), and give special treatment to a
>> number of UDAs that could be applied to functions (d-attribs.cc).
>>
>>
>> That is roughly the high level jist of how things are currently organized.
>>
>> Regards
>> Iain
>>
>> ---
>>
> Presumably the types and interfaces which are capitalized in violation
> of GNU standards are done so to interface the the DMD implementation?
>

Correct, I define my own code generation "passes" which handle the AST
returned by DMD.

> Which implies the answer to a question in my prior message, namely that
> the DMD implementation does get linked into GCC itself.  So I think we
> need the SC to rule on whether or not that's allowed.
>
> I'm not going to dive deep into this code -- it's essentially converting
> between the different representations and is code that you'd be maintaining.
>
> You probably want to review the #ifdefs you've got in here to make sure
> they're not supposed to be checked via #if or runtime checks (there's
> only a half-dozen or so):
>
> +#ifdef STACK_GROWS_DOWNWARD
> +#ifdef HAVE_LD_STATIC_DYNAMIC
> +#ifdef HAVE_LD_STATIC_DYNAMIC
> +#ifdef BIGGEST_FIELD_ALIGNMENT
> +#ifdef ADJUST_FIELD_ALIGN
> +#ifdef ENABLE_TREE_CHECKING
>
> Joseph already commented on Target::critsecsize.
>

Target::critsecsize was dealt with in v2 of this patch.

I think I can justify all #ifdef's being there, except for
ENABLE_TREE_CHECKING which can be a runtime if (flag_checking).

Iain.


Re: [PATCH 6/13] D: Add D language support to GCC proper.

2017-09-11 Thread Jeff Law
On 09/11/2017 11:27 AM, Mike Stump wrote:
> On Sep 11, 2017, at 9:34 AM, Jeff Law  wrote:
>>
>> On 05/28/2017 03:15 PM, Iain Buclaw wrote:
>>> This patch adds D language support to GCC itself.
>>>
>>> ---
>>>
>>>
>>> 06-d-gcc-proper.patch
>>>
>>>
>>> gcc/ChangeLog
>>>
>>> * config/rs6000/rs6000.c (rs6000_output_function_epilogue):
>>> Support GNU D by using 0 as the language type.
>>> * dwarf2out.c (is_dlang): New function.
>>> (gen_compile_unit_die): Use DW_LANG_D for D.
>>> (declare_in_namespace): Return module die for D, instead of adding
>>> extra declarations into the namespace.
>>> (gen_namespace_die): Generate DW_TAG_module for D.
>>> (gen_decl_die, dwarf2out_decl): Handle CONST_DECLSs for D.
>>> * gcc.c (default_compilers): Add entries for ".d", ".dd" and ".di".This 
>>> is fine when prereqs are approved.
>>
>> jeff
> 
> ENOCOMMENT
Arggh.  It somehow got run onto the end of the ChangeLog.

"This is fine when the prereqs are approved." :-)

jeff



Re: [PATCH 6/13] D: Add D language support to GCC proper.

2017-09-11 Thread Mike Stump
On Sep 11, 2017, at 9:34 AM, Jeff Law  wrote:
> 
> On 05/28/2017 03:15 PM, Iain Buclaw wrote:
>> This patch adds D language support to GCC itself.
>> 
>> ---
>> 
>> 
>> 06-d-gcc-proper.patch
>> 
>> 
>> gcc/ChangeLog
>> 
>>  * config/rs6000/rs6000.c (rs6000_output_function_epilogue):
>>  Support GNU D by using 0 as the language type.
>>  * dwarf2out.c (is_dlang): New function.
>>  (gen_compile_unit_die): Use DW_LANG_D for D.
>>  (declare_in_namespace): Return module die for D, instead of adding
>>  extra declarations into the namespace.
>>  (gen_namespace_die): Generate DW_TAG_module for D.
>>  (gen_decl_die, dwarf2out_decl): Handle CONST_DECLSs for D.
>>  * gcc.c (default_compilers): Add entries for ".d", ".dd" and ".di".This 
>> is fine when prereqs are approved.
> 
> jeff

ENOCOMMENT

Re: [PATCH 1/13] D: The front-end (DMD) language implementation and license.

2017-09-11 Thread Iain Buclaw
On 11 September 2017 at 17:12, Jeff Law  wrote:
> On 05/28/2017 03:02 PM, Iain Buclaw wrote:
>> (Sorry, repost as I rushed the first one a bit).
>>
>> This patch adds the DMD front-end proper and license (Boost) files,
>> comprised of a lexer, parser, and semantic analyzer.
>>
>> Split 1/4
>>
>> Gzipped because of size limitations.
> So for 1/13, these are all bits that are maintained on github and we're
> just a downstream user, right?  Meaning I don't need to do a deep dive
> in this patch within the series, right?
>
> Does this stuff get bound into GCC?  The reason I ask is the files are
> under the Boost license with ownership by Digital Mars.  While we often
> have a fair amount of leeway with runtime systems, we may not have the
> same kind of license/ownership leeway with things that are actually part
> of the compiler itself.
>
> Did the discussions between the FSF, Digital Mars and Walter touch in
> these issues at all?  Have you received any guidance from the parties on
> this issue?
>
> Is there any way this stuff could be a separate executable or DSO?  That
> might make things easier on the licensing front.
>
> Jeff

I am under the impression that Walter had assigned copyrights of the
DMD frontend to the FSF in 2011.  The license change to Boost came
about in 2014, all core maintainers of DMD did copyright assignments
to Digital Mars as a prerequisite for the transition.

Walter can you confirm the above is the case?

I would be making an assumption here that there are no problems given
the current arrangement as I understand it, but would be best to check
this with the FSF legal be sure.

Iain.


Re: [PATCH] PR c++/81852 define feature-test macro for -fthreadsafe-statics

2017-09-11 Thread Jonathan Wakely

On 09/09/17 10:33 +0200, Jason Merrill wrote:

On Fri, Sep 8, 2017 at 10:03 PM, Jonathan Wakely  wrote:

Define the __cpp_lib_threadsafe_static_init feature-test macro as per
recent SD-6 drafts.

Tested powerpc64le-linux and x86_64-linux.

OK for trunk?

The branches too?


Yes.

Jason


I've committed this change to
https://gcc.gnu.org/projects/cxx-status.html documenting the new
macro.


Index: htdocs/projects/cxx-status.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cxx-status.html,v
retrieving revision 1.41
diff -u -r1.41 cxx-status.html
--- htdocs/projects/cxx-status.html	11 Apr 2017 22:28:24 -	1.41
+++ htdocs/projects/cxx-status.html	11 Sep 2017 17:19:49 -
@@ -866,7 +866,7 @@
   Dynamic initialization and destruction with concurrency
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2660.htm";>N2660
   GCC 4.3
-  
+  __cpp_threadsafe_static_init >= 200806
 
 
 


Turn HARD_REGNO_NREGS into a target hook

2017-09-11 Thread Richard Sandiford
Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
Also tested by comparing the testsuite assembly output on at least one
target per CPU directory.  OK to install?

Richard


gcc/
* target.def (hard_regno_nregs): New hook.
(class_max_nregs): Refer to it instead of HARD_REGNO_NREGS.
* targhooks.h (default_hard_regno_nregs): Declare.
* targhooks.c (default_hard_regno_nregs): New function.
* doc/tm.texi.in (HARD_REGNO_NREGS): Replace with...
(TARGET_HARD_REGNO_NREGS): ...this hook.
(HARD_REGNO_NREGS_HAS_PADDING): Update accordingly.
(CLASS_MAX_NREGS): Likewise.
* doc/tm.texi: Regenerate.
* reginfo.c (init_reg_modes_target): Use targetm.hard_regno_nregs
instead of HARD_REGNO_NREGS.
* rtl.h (REG_NREGS): Refer to TARGET_HARD_REGNO_NREGS rather than
HARD_REGNO_NREGS in the comment.
* config/aarch64/aarch64.h (HARD_REGNO_NREGS): Delete.
* config/aarch64/aarch64-protos.h (aarch64_hard_regno_nregs): Delete.
* config/aarch64/aarch64.c (aarch64_hard_regno_nregs): Make static.
Return an unsigned int.
(TARGET_HARD_REGNO_NREGS): Redefine.
* config/alpha/alpha.h (HARD_REGNO_NREGS): Delete.
* config/arc/arc.h (HARD_REGNO_NREGS): Delete.
* config/arc/arc.c (TARGET_HARD_REGNO_NREGS): Redefine.
(arc_hard_regno_nregs): New function.
* config/arm/arm.h (HARD_REGNO_NREGS): Delete.
* config/arm/arm.c (TARGET_HARD_REGNO_NREGS): Redefine.
(arm_hard_regno_nregs): New function.
* config/avr/avr.h (HARD_REGNO_NREGS): Delete.
* config/bfin/bfin.h (HARD_REGNO_NREGS): Delete.
* config/bfin/bfin.c (bfin_hard_regno_nregs): New function.
(TARGET_HARD_REGNO_NREGS): Redefine.
* config/c6x/c6x.h (HARD_REGNO_NREGS): Delete.
* config/cr16/cr16.h (LONG_REG_P): Use targetm.hard_regno_nregs.
(HARD_REGNO_NREGS): Delete.
* config/cr16/cr16.c (TARGET_HARD_REGNO_NREGS): Redefine.
(cr16_hard_regno_nregs): New function.
(cr16_memory_move_cost): Use it instead of HARD_REGNO_NREGS.
* config/cris/cris.h (HARD_REGNO_NREGS): Delete.
* config/cris/cris.c (TARGET_HARD_REGNO_NREGS): Redefine.
(cris_hard_regno_nregs): New function.
* config/epiphany/epiphany.h (HARD_REGNO_NREGS): Delete.
* config/fr30/fr30.h (HARD_REGNO_NREGS): Delete.
(CLASS_MAX_NREGS): Use targetm.hard_regno_nregs.
* config/frv/frv.h (HARD_REGNO_NREGS): Delete.
(CLASS_MAX_NREGS): Remove outdated copy of documentation.
* config/frv/frv-protos.h (frv_hard_regno_nregs): Delete.
* config/frv/frv.c (TARGET_HARD_REGNO_NREGS): Redefine.
(frv_hard_regno_nregs): Make static.  Take and return an
unsigned int.
(frv_class_max_nregs): Remove outdated copy of documentation.
* config/ft32/ft32.h (HARD_REGNO_NREGS): Delete.
* config/h8300/h8300.h (HARD_REGNO_NREGS): Delete.
* config/h8300/h8300-protos.h (h8300_hard_regno_nregs): Delete.
* config/h8300/h8300.c (h8300_hard_regno_nregs): Delete.
* config/i386/i386.h (HARD_REGNO_NREGS): Delete.
* config/i386/i386.c (ix86_hard_regno_nregs): New function.
(TARGET_HARD_REGNO_NREGS): Redefine.
* config/ia64/ia64.h (HARD_REGNO_NREGS): Delete.
(CLASS_MAX_NREGS): Update comment.
* config/ia64/ia64.c (TARGET_HARD_REGNO_NREGS): Redefine.
(ia64_hard_regno_nregs): New function.
* config/iq2000/iq2000.h (HARD_REGNO_NREGS): Delete.
* config/lm32/lm32.h (HARD_REGNO_NREGS): Delete.
* config/m32c/m32c.h (HARD_REGNO_NREGS): Delete.
* config/m32c/m32c-protos.h (m32c_hard_regno_nregs): Delete.
* config/m32c/m32c.c (m32c_hard_regno_nregs_1): Take and return
an unsigned int.
(m32c_hard_regno_nregs): Likewise.  Make static.
(TARGET_HARD_REGNO_NREGS): Redefine.
* config/m32r/m32r.h (HARD_REGNO_NREGS): Delete.
* config/m68k/m68k.h (HARD_REGNO_NREGS): Delete.
* config/m68k/m68k.c (TARGET_HARD_REGNO_NREGS): Redefine.
(m68k_hard_regno_nregs): New function.
* config/mcore/mcore.h (HARD_REGNO_NREGS): Delete.
* config/microblaze/microblaze.h (HARD_REGNO_NREGS): Delete.
* config/mips/mips.h (HARD_REGNO_NREGS): Delete.
* config/mips/mips-protos.h (mips_hard_regno_nregs): Delete.
* config/mips/mips.c (mips_hard_regno_nregs): Make static.
Take and return an unsigned int.
(TARGET_HARD_REGNO_NREGS): Redefine.
* config/mmix/mmix.h (HARD_REGNO_NREGS): Delete.
(CLASS_MAX_NREGS): Use targetm.hard_regno_nregs.
* config/mn10300/mn10300.h (HARD_REGNO_NREGS): Delete.
* config/moxie/moxie.h (HARD_REGNO_NREGS): Delete.
* config/msp430/msp430.h (HARD_REGNO_NREGS): Delete.
* config/msp430/msp430-protos.h (msp430_hard_regno_nregs):

Use hard_regno_nregs instead of HARD_REGNO_NREGS

2017-09-11 Thread Richard Sandiford
This patch converts some places that use HARD_REGNO_NREGS to use
hard_regno_nregs, in places where the initialisation has obviously
already taken place.

Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
Also tested by comparing the testsuite assembly output on at least one
target per CPU directory.  OK to install?

Richard


2017-09-11  Richard Sandiford  

gcc/
* config/arm/arm.h (THUMB_SECONDARY_INPUT_RELOAD_CLASS): Use
hard_regno_nregs instead of HARD_REGNO_NREGS.
(THUMB_SECONDARY_OUTPUT_RELOAD_CLASS): Likewise.
* config/c6x/c6x.c (c6x_expand_prologue): Likewise.
(c6x_expand_epilogue): Likewise.
* config/frv/frv.c (frv_alloc_temp_reg): Likewise.
(frv_read_iacc_argument): Likewise.
* config/sh/sh.c: Include regs.h.
(sh_print_operand): Use hard_regno_nregs instead of HARD_REGNO_NREGS.
(regs_used): Likewise.
(output_stack_adjust): Likewise.
* config/xtensa/xtensa.c (xtensa_copy_incoming_a7): Likewise.
* expmed.c: Include regs.h.
(store_bit_field_1): Use hard_regno_nregs instead of HARD_REGNO_NREGS.
* ree.c: Include regs.h.
(combine_reaching_defs): Use hard_regno_nregs instead of
HARD_REGNO_NREGS.
(add_removable_extension): Likewise.

Index: gcc/config/arm/arm.h
===
--- gcc/config/arm/arm.h2017-09-11 17:16:50.096976100 +0100
+++ gcc/config/arm/arm.h2017-09-11 17:23:20.345191442 +0100
@@ -1211,7 +1211,7 @@ #define THUMB_SECONDARY_INPUT_RELOAD_CLA
   (lra_in_progress ? NO_REGS   \
: ((CLASS) != LO_REGS && (CLASS) != BASE_REGS   \
   ? ((true_regnum (X) == -1 ? LO_REGS  \
- : (true_regnum (X) + HARD_REGNO_NREGS (0, MODE) > 8) ? LO_REGS
\
+ : (true_regnum (X) + hard_regno_nregs (0, MODE) > 8) ? LO_REGS
\
  : NO_REGS))   \
   : NO_REGS))
 
@@ -1219,7 +1219,7 @@ #define THUMB_SECONDARY_OUTPUT_RELOAD_CL
   (lra_in_progress ? NO_REGS   \
: (CLASS) != LO_REGS && (CLASS) != BASE_REGS
\
   ? ((true_regnum (X) == -1 ? LO_REGS  \
- : (true_regnum (X) + HARD_REGNO_NREGS (0, MODE) > 8) ? LO_REGS
\
+ : (true_regnum (X) + hard_regno_nregs (0, MODE) > 8) ? LO_REGS
\
  : NO_REGS))   \
   : NO_REGS)
 
Index: gcc/config/c6x/c6x.c
===
--- gcc/config/c6x/c6x.c2017-09-11 17:16:57.875552068 +0100
+++ gcc/config/c6x/c6x.c2017-09-11 17:23:20.346191298 +0100
@@ -2834,7 +2834,7 @@ c6x_expand_prologue (void)
 reg);
  RTX_FRAME_RELATED_P (insn) = 1;
 
- nsaved += HARD_REGNO_NREGS (regno, save_mode);
+ nsaved += hard_regno_nregs (regno, save_mode);
}
 }
   gcc_assert (nsaved == frame.nregs);
@@ -2922,7 +2922,7 @@ c6x_expand_epilogue (bool sibcall)
  emit_move_insn (reg, adjust_address (mem, save_mode, off));
 
  off += GET_MODE_SIZE (save_mode);
- nsaved += HARD_REGNO_NREGS (regno, save_mode);
+ nsaved += hard_regno_nregs (regno, save_mode);
}
 }
   if (!frame_pointer_needed)
Index: gcc/config/frv/frv.c
===
--- gcc/config/frv/frv.c2017-09-11 17:17:46.893352269 +0100
+++ gcc/config/frv/frv.c2017-09-11 17:23:20.347191155 +0100
@@ -1509,7 +1509,7 @@ frv_alloc_temp_reg (
}
 }
 
-  nr = HARD_REGNO_NREGS (regno, mode);
+  nr = hard_regno_nregs (regno, mode);
   info->next_reg[ (int)rclass ] = regno + nr;
 
   if (mark_as_used)
@@ -8650,7 +8650,7 @@ frv_read_iacc_argument (machine_mode mod
  avoid creating lots of unnecessary call_insn rtl when IACCs aren't
  being used.  */
   regno = INTVAL (op) + IACC_FIRST;
-  for (i = 0; i < HARD_REGNO_NREGS (regno, mode); i++)
+  for (i = 0; i < hard_regno_nregs (regno, mode); i++)
 global_regs[regno + i] = 1;
 
   return gen_rtx_REG (mode, regno);
Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c  2017-09-04 11:50:08.537340396 +0100
+++ gcc/config/sh/sh.c  2017-09-11 17:23:20.348191011 +0100
@@ -63,6 +63,7 @@ #define INCLUDE_VECTOR
 #include "context.h"
 #include "builtins.h"
 #include "rtl-iter.h"
+#include "regs.h"
 
 /* This file should be included last.  */
 #include "target-def.h"
@@ -1392,8 +1393,8 @@ sh_print_operand (FILE *stream, rtx x, i
/* Floating point register pairs are always big endian;
   general purpose registers are 64 bit wide.  */
regno = REGNO (inner);
-   regn

Convert hard_regno_nregs to a function

2017-09-11 Thread Richard Sandiford
This patch converts hard_regno_nregs into an inline function, which
in turn allows hard_regno_nregs to be used as the name of a targetm
field.  This is just a mechanical change.

Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
Also tested by comparing the testsuite assembly output on at least one
target per CPU directory.  OK to install?

Richard


2017-09-11  Richard Sandiford  

gcc/
* regs.h (hard_regno_nregs): Turn into a function.
(end_hard_regno): Update accordingly.
* caller-save.c (setup_save_areas): Likewise.
(save_call_clobbered_regs): Likewise.
(replace_reg_with_saved_mem): Likewise.
(insert_restore): Likewise.
(insert_save): Likewise.
* combine.c (can_change_dest_mode): Likewise.
(move_deaths): Likewise.
(distribute_notes): Likewise.
* config/mips/mips.c (mips_hard_regno_call_part_clobbered): Likewise.
* config/powerpcspe/powerpcspe.c (rs6000_cannot_change_mode_class)
(rs6000_split_multireg_move): Likewise.
(rs6000_register_move_cost): Likewise.
(rs6000_memory_move_cost): Likewise.
* config/rs6000/rs6000.c (rs6000_cannot_change_mode_class): Likewise.
(rs6000_split_multireg_move): Likewise.
(rs6000_register_move_cost): Likewise.
(rs6000_memory_move_cost): Likewise.
* cselib.c (cselib_reset_table): Likewise.
(cselib_lookup_1): Likewise.
* emit-rtl.c (set_mode_and_regno): Likewise.
* function.c (aggregate_value_p): Likewise.
* ira-color.c (setup_profitable_hard_regs): Likewise.
(check_hard_reg_p): Likewise.
(calculate_saved_nregs): Likewise.
(assign_hard_reg): Likewise.
(improve_allocation): Likewise.
(calculate_spill_cost): Likewise.
* ira-emit.c (modify_move_list): Likewise.
* ira-int.h (ira_hard_reg_set_intersection_p): Likewise.
(ira_hard_reg_in_set_p): Likewise.
* ira.c (setup_reg_mode_hard_regset): Likewise.
(clarify_prohibited_class_mode_regs): Likewise.
(check_allocation): Likewise.
* lra-assigns.c (find_hard_regno_for_1): Likewise.
(lra_setup_reg_renumber): Likewise.
(setup_try_hard_regno_pseudos): Likewise.
(spill_for): Likewise.
(assign_hard_regno): Likewise.
(setup_live_pseudos_and_spill_after_risky_transforms): Likewise.
* lra-constraints.c (in_class_p): Likewise.
(lra_constraint_offset): Likewise.
(simplify_operand_subreg): Likewise.
(lra_constraints): Likewise.
(split_reg): Likewise.
(split_if_necessary): Likewise.
(invariant_p): Likewise.
(inherit_in_ebb): Likewise.
* lra-lives.c (process_bb_lives): Likewise.
* lra-remat.c (reg_overlap_for_remat_p): Likewise.
(get_hard_regs): Likewise.
(do_remat): Likewise.
* lra-spills.c (assign_spill_hard_regs): Likewise.
* mode-switching.c (create_pre_exit): Likewise.
* postreload.c (reload_combine_recognize_pattern): Likewise.
* recog.c (peep2_find_free_register): Likewise.
* regcprop.c (kill_value_regno): Likewise.
(set_value_regno): Likewise.
(copy_value): Likewise.
(maybe_mode_change): Likewise.
(find_oldest_value_reg): Likewise.
(copyprop_hardreg_forward_1): Likewise.
* regrename.c (check_new_reg_p): Likewise.
(regrename_do_replace): Likewise.
* reload.c (push_reload): Likewise.
(combine_reloads): Likewise.
(find_dummy_reload): Likewise.
(operands_match_p): Likewise.
(find_reloads): Likewise.
(find_equiv_reg): Likewise.
(reload_adjust_reg_for_mode): Likewise.
* reload1.c (count_pseudo): Likewise.
(count_spilled_pseudo): Likewise.
(find_reg): Likewise.
(clear_reload_reg_in_use): Likewise.
(free_for_value_p): Likewise.
(allocate_reload_reg): Likewise.
(choose_reload_regs): Likewise.
(reload_adjust_reg_for_temp): Likewise.
(emit_reload_insns): Likewise.
(delete_output_reload): Likewise.
* rtlanal.c (subreg_get_info): Likewise.
* sched-deps.c (sched_analyze_reg): Likewise.
* sel-sched.c (init_regs_for_mode): Likewise.
(mark_unavailable_hard_regs): Likewise.
(choose_best_reg_1): Likewise.
(verify_target_availability): Likewise.
* valtrack.c (dead_debug_insert_temp): Likewise.
* var-tracking.c (track_loc_p): Likewise.
(emit_note_insn_var_location): Likewise.
* varasm.c (make_decl_rtl): Likewise.
* reginfo.c (choose_hard_reg_mode): Likewise.
(init_reg_modes_target): Refer directly to
this_target_regs->x_hard_regno_nregs.

Index: gcc/regs.h
===
--- gcc/regs.h  2017-09-04 11:48:57.532452460 +0100
+++ gcc/regs.h  2017

Make more use of in_hard_reg_set_p

2017-09-11 Thread Richard Sandiford
An upcoming patch will convert hard_regno_nregs into an inline
function, which in turn allows hard_regno_nregs to be used as the
name of a targetm field.  This patch rewrites a use that can use
in_hard_reg_set_p instead.

Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
Also tested by comparing the testsuite assembly output on at least one
target per CPU directory.  OK to install?

Richard


2017-09-11  Richard Sandiford  

gcc/
* ira-costs.c (record_operand_costs): Use in_hard_reg_set_p
instead of hard_regno_nregs.

Index: gcc/ira-costs.c
===
--- gcc/ira-costs.c 2017-09-04 11:48:57.531552460 +0100
+++ gcc/ira-costs.c 2017-09-11 17:21:26.382315018 +0100
@@ -1386,7 +1386,7 @@ record_operand_costs (rtx_insn *insn, en
  cost_classes_t cost_classes_ptr = regno_cost_classes[regno];
  enum reg_class *cost_classes = cost_classes_ptr->classes;
  reg_class_t rclass;
- int k, nr;
+ int k;
 
  i = regno == (int) REGNO (src) ? 1 : 0;
  for (k = cost_classes_ptr->num - 1; k >= 0; k--)
@@ -1398,18 +1398,9 @@ record_operand_costs (rtx_insn *insn, en
{
  if (reg_class_size[rclass] == 1)
op_costs[i]->cost[k] = -frequency;
- else
-   {
- for (nr = 0;
-  nr < hard_regno_nregs[other_regno][mode];
-  nr++)
-   if (! TEST_HARD_REG_BIT (reg_class_contents[rclass],
-other_regno + nr))
- break;
- 
- if (nr == hard_regno_nregs[other_regno][mode])
-   op_costs[i]->cost[k] = -frequency;
-   }
+ else if (in_hard_reg_set_p (reg_class_contents[rclass],
+ mode, other_regno))
+   op_costs[i]->cost[k] = -frequency;
}
}
}


Make more use of end_hard_regno

2017-09-11 Thread Richard Sandiford
An upcoming patch will convert hard_regno_nregs into an inline
function, which in turn allows hard_regno_nregs to be used as the
name of a targetm field.  This patch rewrites uses that can use
end_hard_regno instead.

Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
Also tested by comparing the testsuite assembly output on at least one
target per CPU directory.  OK to install?

Richard


2017-09-11  Richard Sandiford  

gcc/
* config/aarch64/aarch64.c (aarch64_hard_regno_mode_ok): Use
end_hard_regno instead of hard_regno_nregs.
* config/s390/s390.c (s390_reg_clobbered_rtx): Likewise.
* config/sparc/sparc.h (ASM_DECLARE_REGISTER_GLOBAL): Likewise.
* config/visium/visium.c (visium_hard_regno_mode_ok): Likewise.
* ira-color.c (improve_allocation): Likewise.
* lra-assigns.c (find_hard_regno_for_1): Likewise.
* lra-lives.c (mark_regno_live): Likewise.
(mark_regno_dead): Likewise.
* lra-remat.c (operand_to_remat): Likewise.
* lra.c (collect_non_operand_hard_regs): Likewise.
* postreload.c (reload_combine_note_store): Likewise.
(move2add_valid_value_p): Likewise.
* reload.c (regno_clobbered_p): Likewise.

Index: gcc/config/aarch64/aarch64.c
===
--- gcc/config/aarch64/aarch64.c2017-09-11 17:20:21.469287471 +0100
+++ gcc/config/aarch64/aarch64.c2017-09-11 17:20:21.705282714 +0100
@@ -1106,8 +1106,7 @@ aarch64_hard_regno_mode_ok (unsigned reg
   if (FP_REGNUM_P (regno))
 {
   if (aarch64_vect_struct_mode_p (mode))
-   return
- (regno + aarch64_hard_regno_nregs (regno, mode) - 1) <= V31_REGNUM;
+   return end_hard_regno (mode, regno) - 1 <= V31_REGNUM;
   else
return true;
 }
Index: gcc/config/s390/s390.c
===
--- gcc/config/s390/s390.c  2017-09-11 17:20:21.469287471 +0100
+++ gcc/config/s390/s390.c  2017-09-11 17:20:21.706282694 +0100
@@ -9630,7 +9630,7 @@ s390_reg_clobbered_rtx (rtx setreg, cons
 return;
 
   for (i = regno;
-   i < regno + HARD_REGNO_NREGS (regno, mode);
+   i < end_hard_regno (mode, regno);
i++)
 regs_ever_clobbered[i] = 1;
 }
Index: gcc/config/sparc/sparc.h
===
--- gcc/config/sparc/sparc.h2017-09-11 17:20:21.469287471 +0100
+++ gcc/config/sparc/sparc.h2017-09-11 17:20:21.707282674 +0100
@@ -1248,7 +1248,7 @@ #define ASM_DECLARE_REGISTER_GLOBAL(FILE
 do {   \
   if (TARGET_ARCH64)   \
 {  \
-  int end = HARD_REGNO_NREGS ((REGNO), DECL_MODE (decl)) + (REGNO); \
+  int end = end_hard_regno (DECL_MODE (decl), REGNO);  \
   int reg; \
   for (reg = (REGNO); reg < 8 && reg < end; reg++) \
if ((reg & ~1) == 2 || (reg & ~1) == 6) \
Index: gcc/config/visium/visium.c
===
--- gcc/config/visium/visium.c  2017-09-11 17:20:21.469287471 +0100
+++ gcc/config/visium/visium.c  2017-09-11 17:20:21.707282674 +0100
@@ -857,7 +857,7 @@ visium_hard_regno_rename_ok (unsigned in
 visium_hard_regno_mode_ok (unsigned int regno, machine_mode mode)
 {
   if (GP_REGISTER_P (regno))
-return GP_REGISTER_P (regno + HARD_REGNO_NREGS (regno, mode) - 1);
+return GP_REGISTER_P (end_hard_regno (mode, regno) - 1);
 
   if (FP_REGISTER_P (regno))
 return mode == SFmode || (mode == SImode && TARGET_FPU_IEEE);
Index: gcc/ira-color.c
===
--- gcc/ira-color.c 2017-09-11 17:20:21.469287471 +0100
+++ gcc/ira-color.c 2017-09-11 17:20:21.708282653 +0100
@@ -2893,7 +2893,7 @@ improve_allocation (void)
  conflict_nregs
= hard_regno_nregs[conflict_hregno][ALLOCNO_MODE (conflict_a)];
  for (r = conflict_hregno;
-  r >= 0 && r + hard_regno_nregs[r][mode] > conflict_hregno;
+  r >= 0 && (int) end_hard_regno (mode, r) > conflict_hregno;
   r--)
if (check_hard_reg_p (a, r,
  conflicting_regs, profitable_hard_regs))
Index: gcc/lra-assigns.c
===
--- gcc/lra-assigns.c   2017-09-11 17:20:21.469287471 +0100
+++ gcc/lra-assigns.c   2017-09-11 17:20:21.708282653 +0100
@@ -578,7 +578,7 @@ find_hard_regno_for_1 (int regno, int *c
   hr++)
SET_HARD_REG_BIT (impossible_start_hard_regs, hr);
  for (hr = conflict_hr - 1;
-  hr >= 0 && hr + hard_regno_nreg

Make more use of END_REGNO

2017-09-11 Thread Richard Sandiford
An upcoming patch will convert hard_regno_nregs into an inline
function, which in turn allows hard_regno_nregs to be used as the
name of a targetm field.  This patch rewrites uses that are more
easily (and efficiently) written as END_REGNO.

Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
Also tested by comparing the testsuite assembly output on at least one
target per CPU directory.  OK to install?

Richard


2017-09-11  Richard Sandiford  

gcc/
* config/frv/frv.c (FOR_EACH_REGNO): Use END_REGNO instead of
hard_regno_nregs.
* config/v850/v850.c (v850_reorg): Likewise.
* reload.c (refers_to_regno_for_reload_p): Likewise.
(find_equiv_reg): Likewise.
* reload1.c (reload_reg_reaches_end_p): Likewise.

Index: gcc/config/frv/frv.c
===
--- gcc/config/frv/frv.c2017-09-04 11:50:08.510328712 +0100
+++ gcc/config/frv/frv.c2017-09-11 17:17:46.893352269 +0100
@@ -135,9 +135,7 @@ #define CLEAR_PACKING_FLAG(INSN) PUT_MOD
 
 /* Loop with REG set to each hard register in rtx X.  */
 #define FOR_EACH_REGNO(REG, X) \
-  for (REG = REGNO (X);
\
-   REG < REGNO (X) + HARD_REGNO_NREGS (REGNO (X), GET_MODE (X));   \
-   REG++)
+  for (REG = REGNO (X); REG < END_REGNO (X); REG++)
 
 /* This structure contains machine specific function data.  */
 struct GTY(()) machine_function
Index: gcc/config/v850/v850.c
===
--- gcc/config/v850/v850.c  2017-09-04 11:50:08.540941953 +0100
+++ gcc/config/v850/v850.c  2017-09-11 17:17:46.893352269 +0100
@@ -1376,12 +1376,11 @@ v850_reorg (void)
 for the register */
  if (GET_CODE (dest) == REG)
{
- machine_mode mode = GET_MODE (dest);
  int regno;
  int endregno;
 
  regno = REGNO (dest);
- endregno = regno + HARD_REGNO_NREGS (regno, mode);
+ endregno = END_REGNO (dest);
 
  if (!use_ep)
{
Index: gcc/reload.c
===
--- gcc/reload.c2017-09-11 17:16:57.896550936 +0100
+++ gcc/reload.c2017-09-11 17:17:46.894352229 +0100
@@ -6439,10 +6439,7 @@ refers_to_regno_for_reload_p (unsigned i
  return 0;
}
 
-  return (endregno > r
- && regno < r + (r < FIRST_PSEUDO_REGISTER
- ? hard_regno_nregs[r][GET_MODE (x)]
- : 1));
+  return endregno > r && regno < END_REGNO (x);
 
 case SUBREG:
   /* If this is a SUBREG of a hard reg, we can see exactly which
@@ -6889,15 +6886,11 @@ find_equiv_reg (rtx goal, rtx_insn *insn
 {
   int i;
   for (i = 0; i < n_reloads; i++)
-   if (rld[i].reg_rtx != 0 && rld[i].in)
- {
-   int regno1 = REGNO (rld[i].reg_rtx);
-   int nregs1 = hard_regno_nregs[regno1]
-[GET_MODE (rld[i].reg_rtx)];
-   if (regno1 < valueno + valuenregs
-   && regno1 + nregs1 > valueno)
- return 0;
- }
+   if (rld[i].reg_rtx != 0
+   && rld[i].in
+   && (int) REGNO (rld[i].reg_rtx) < valueno + valuenregs
+   && (int) END_REGNO (rld[i].reg_rtx) > valueno)
+ return 0;
 }
 
   if (goal_mem)
@@ -6963,15 +6956,11 @@ find_equiv_reg (rtx goal, rtx_insn *insn
  if (REG_P (dest))
{
  int xregno = REGNO (dest);
- int xnregs;
- if (REGNO (dest) < FIRST_PSEUDO_REGISTER)
-   xnregs = hard_regno_nregs[xregno][GET_MODE (dest)];
- else
-   xnregs = 1;
- if (xregno < regno + nregs && xregno + xnregs > regno)
+ int end_xregno = END_REGNO (dest);
+ if (xregno < regno + nregs && end_xregno > regno)
return 0;
  if (xregno < valueno + valuenregs
- && xregno + xnregs > valueno)
+ && end_xregno > valueno)
return 0;
  if (goal_mem_addr_varies
  && reg_overlap_mentioned_for_reload_p (dest, goal))
@@ -7006,16 +6995,12 @@ find_equiv_reg (rtx goal, rtx_insn *insn
  if (REG_P (dest))
{
  int xregno = REGNO (dest);
- int xnregs;
- if (REGNO (dest) < FIRST_PSEUDO_REGISTER)
-   xnregs = hard_regno_nregs[xregno][GET_MODE (dest)];
- else
-   xnregs = 1;
+ int end_xregno = END_REGNO (dest);

Re: Turn SLOW_UNALIGNED_ACCESS into a target hook

2017-09-11 Thread Richard Sandiford
Richard Sandiford  writes:
> Pretty mechanical conversion.
>
> Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
> Also tested by comparing the testsuite assembly output on at least one
> target per CPU directory.  OK to install?
>
> Richard
>
>
> 2017-09-11  Richard Sandiford  
>   Alan Hayward  
>   David Sherwood 
>
> gcc/
>   * defaults.h (SLOW_UNALIGNED_ACCESS): Delete.
>   * target.def (slow_unaligned_access): New hook.
>   * targhooks.h (default_slow_unaligned_access): Declare.
>   * targhooks.c (default_slow_unaligned_access): New function.
>   * doc/tm.texi.in (SLOW_UNALIGNED_ACCESS): Replace with...
>   (TARGET_SLOW_UNALIGNED_ACCESS): ...this.
>   * doc/tm.texi: Regenerate.
>   * config/alpha/alpha.h (SLOW_UNALIGNED_ACCESS): Delete.
>   * config/arm/arm.h (SLOW_UNALIGNED_ACCESS): Delete.
>   * config/i386/i386.h (SLOW_UNALIGNED_ACCESS): Delete commented-out
>   definition.
>   * config/powerpcspe/powerpcspe.h (SLOW_UNALIGNED_ACCESS): Delete.
>   * config/powerpcspe/powerpcspe.c (TARGET_SLOW_UNALIGNED_ACCESS):
>   Redefine.
>   (rs6000_slow_unaligned_access): New function.
>   (rs6000_emit_move): Use it instead of SLOW_UNALIGNED_ACCESS.
>   (expand_block_compare): Likewise.
>   (expand_strn_compare): Likewise.
>   (rs6000_rtx_costs): Likewise.
>   * config/riscv/riscv.h (SLOW_UNALIGNED_ACCESS): Delete.
>   (riscv_slow_unaligned_access): Likewise.
>   * config/riscv/riscv.c (riscv_slow_unaligned_access): Rename to...
>   (riscv_slow_unaligned_access_p): ...this and make static.
>   (riscv_option_override): Update accordingly.
>   (riscv_slow_unaligned_access): New function.
>   (TARGET_SLOW_UNALIGNED_ACCESS): Redefine.
>   * config/rs6000/rs6000.h (SLOW_UNALIGNED_ACCESS): Delete.
>   * config/rs6000/rs6000.c (TARGET_SLOW_UNALIGNED_ACCESS): Redefine.
>   (rs6000_slow_unaligned_access): New function.
>   (rs6000_emit_move): Use it instead of SLOW_UNALIGNED_ACCESS.
>   (rs6000_rtx_costs): Likewise.
>   * config/rs6000/rs6000-string.c (expand_block_compare)
>   (expand_strn_compare): Use targetm.slow_unaligned_access instead
>   of SLOW_UNALIGNED_ACCESS.
>   * config/tilegx/tilegx.h (SLOW_UNALIGNED_ACCESS): Delete.
>   * config/tilepro/tilepro.h (SLOW_UNALIGNED_ACCESS): Delete.
>   * calls.c (expand_call): Use targetm.slow_unaligned_access instead
>   of SLOW_UNALIGNED_ACCESS.
>   * expmed.c (simple_mem_bitfield_p): Likewise.
>   * expr.c (alignment_for_piecewise_move): Likewise.
>   (emit_group_load_1): Likewise.
>   (emit_group_store): Likewise.
>   (copy_blkmode_from_reg): Likewise.
>   (emit_push_insn): Likewise.
>   (expand_assignment): Likewise.
>   (store_field): Likewise.
>   (expand_expr_real_1): Likewise.
>   * gimple-fold.c (gimple_fold_builtin_memory_op): Likewise.
>   * lra-constraints.c (simplify_operand_subreg): Likewise.
>   * stor-layout.c (bit_field_mode_iterator::next_mode): Likewise.
>   * gimple-ssa-store-merging.c: Likewise in block comment at start
>   of file.
>   * tree-ssa-strlen.c: Include target.h.
>   (handle_builtin_memcmp): Use targetm.slow_unaligned_access instead
>   of SLOW_UNALIGNED_ACCESS.
>   * system.h (SLOW_UNALIGNED_ACCESS): Poison.

Index: gcc/defaults.h
===
--- gcc/defaults.h  2017-09-11 17:11:24.124638853 +0100
+++ gcc/defaults.h  2017-09-11 17:13:33.706325564 +0100
@@ -1170,10 +1170,6 @@ #define MINIMUM_ALIGNMENT(EXP,MODE,ALIGN
 #define ATTRIBUTE_ALIGNED_VALUE BIGGEST_ALIGNMENT
 #endif
 
-#ifndef SLOW_UNALIGNED_ACCESS
-#define SLOW_UNALIGNED_ACCESS(MODE, ALIGN) STRICT_ALIGNMENT
-#endif
-
 /* For most ports anything that evaluates to a constant symbolic
or integer value is acceptable as a constant address.  */
 #ifndef CONSTANT_ADDRESS_P
Index: gcc/target.def
===
--- gcc/target.def  2017-09-11 17:11:24.124638853 +0100
+++ gcc/target.def  2017-09-11 17:13:33.712325341 +0100
@@ -3512,6 +3512,25 @@ negative number from this hook.",
  default_compare_by_pieces_branch_ratio)
 
 DEFHOOK
+(slow_unaligned_access,
+ "This hook returns true if memory accesses described by the\n\
+@var{mode} and @var{alignment} parameters have a cost many times greater\n\
+than aligned accesses, for example if they are emulated in a trap handler.\n\
+This hook is invoked only for unaligned accesses, i.e. when\n\
+@code{@var{alignment} < GET_MODE_ALIGNMENT (@var{mode})}.\n\
+\n\
+When this hook returns true, the compiler will act as if\n\
+@code{STRICT_ALIGNMENT} were true when generating code for block\n\
+moves.  This can cause significantly more instructions to be produced.\n\
+Therefore, do not make this hook return true if unaligned accesses only\n\
+add a cycle or two to the time

Make more use of REG_NREGS

2017-09-11 Thread Richard Sandiford
An upcoming patch will convert hard_regno_nregs into an inline
function, which in turn allows hard_regno_nregs to be used as the
name of a targetm field.  This patch rewrites uses that are more
easily (and efficiently) written as REG_NREGS.

Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
Also tested by comparing the testsuite assembly output on at least one
target per CPU directory.  OK to install?

Richard


2017-09-11  Richard Sandiford  

gcc/
* caller-save.c (add_used_regs): Use REG_NREGS instead of
hard_regno_nregs.
* config/aarch64/aarch64.c (aarch64_split_combinev16qi): Likewise.
* config/arm/arm.c (output_move_neon): Likewise.
(arm_attr_length_move_neon): Likewise.
(neon_split_vcombine): Likewise.
* config/c6x/c6x.c (c6x_mark_reg_read): Likewise.
(c6x_mark_reg_written): Likewise.
(c6x_dwarf_register_span): Likewise.
* config/i386/i386.c (ix86_save_reg): Likewise.
* config/ia64/ia64.c (mark_reg_gr_used_mask): Likewise.
(rws_access_reg): Likewise.
* config/s390/s390.c (s390_call_saved_register_used): Likewise.
* mode-switching.c (create_pre_exit): Likewise.
* ree.c (combine_reaching_defs): Likewise.
(add_removable_extension): Likewise.
* regcprop.c (find_oldest_value_reg): Likewise.
(copyprop_hardreg_forward_1): Likewise.
* reload.c (reload_inner_reg_of_subreg): Likewise.
(push_reload): Likewise.
(combine_reloads): Likewise.
(find_dummy_reload): Likewise.
(reload_adjust_reg_for_mode): Likewise.
* reload1.c (find_reload_regs): Likewise.
(forget_old_reloads_1): Likewise.
(reload_reg_free_for_value_p): Likewise.
(reload_adjust_reg_for_temp): Likewise.
(emit_reload_insns): Likewise.
(delete_output_reload): Likewise.
* sel-sched.c (choose_best_reg_1): Likewise.
(choose_best_pseudo_reg): Likewise.

Index: gcc/caller-save.c
===
--- gcc/caller-save.c   2017-09-11 17:15:13.626435353 +0100
+++ gcc/caller-save.c   2017-09-11 17:16:57.862552768 +0100
@@ -1341,8 +1341,7 @@ add_used_regs (rtx *loc, void *data)
{
  unsigned int regno = REGNO (x);
  if (HARD_REGISTER_NUM_P (regno))
-   bitmap_set_range ((regset) data, regno,
- hard_regno_nregs[regno][GET_MODE (x)]);
+   bitmap_set_range ((regset) data, regno, REG_NREGS (x));
  else
gcc_checking_assert (reg_renumber[regno] < 0);
}
Index: gcc/config/aarch64/aarch64.c
===
--- gcc/config/aarch64/aarch64.c2017-09-11 17:15:13.562442282 +0100
+++ gcc/config/aarch64/aarch64.c2017-09-11 17:16:57.864552661 +0100
@@ -13105,7 +13105,7 @@ aarch64_split_combinev16qi (rtx operands
   unsigned int src1 = REGNO (operands[1]);
   unsigned int src2 = REGNO (operands[2]);
   machine_mode halfmode = GET_MODE (operands[1]);
-  unsigned int halfregs = HARD_REGNO_NREGS (src1, halfmode);
+  unsigned int halfregs = REG_NREGS (operands[1]);
   rtx destlo, desthi;
 
   gcc_assert (halfmode == V16QImode);
Index: gcc/config/arm/arm.c
===
--- gcc/config/arm/arm.c2017-09-11 17:14:25.531400365 +0100
+++ gcc/config/arm/arm.c2017-09-11 17:16:57.874552121 +0100
@@ -18589,7 +18589,7 @@ output_move_neon (rtx *operands)
 
   gcc_assert (REG_P (reg));
   regno = REGNO (reg);
-  nregs = HARD_REGNO_NREGS (regno, mode) / 2;
+  nregs = REG_NREGS (reg) / 2;
   gcc_assert (VFP_REGNO_OK_FOR_DOUBLE (regno)
  || NEON_REGNO_OK_FOR_QUAD (regno));
   gcc_assert (VALID_NEON_DREG_MODE (mode)
@@ -18722,7 +18722,6 @@ arm_attr_length_move_neon (rtx_insn *ins
 
   gcc_assert (MEM_P (mem));
 
-  mode = GET_MODE (reg);
   addr = XEXP (mem, 0);
 
   /* Strip off const from addresses like (const (plus (...))).  */
@@ -18731,7 +18730,7 @@ arm_attr_length_move_neon (rtx_insn *ins
 
   if (GET_CODE (addr) == LABEL_REF || GET_CODE (addr) == PLUS)
 {
-  int insns = HARD_REGNO_NREGS (REGNO (reg), mode) / 2;
+  int insns = REG_NREGS (reg) / 2;
   return insns * 4;
 }
   else
@@ -23713,7 +23712,7 @@ neon_split_vcombine (rtx operands[3])
   unsigned int src1 = REGNO (operands[1]);
   unsigned int src2 = REGNO (operands[2]);
   machine_mode halfmode = GET_MODE (operands[1]);
-  unsigned int halfregs = HARD_REGNO_NREGS (src1, halfmode);
+  unsigned int halfregs = REG_NREGS (operands[1]);
   rtx destlo, desthi;
 
   if (src1 == dest && src2 == dest + halfregs)
Index: gcc/config/c6x/c6x.c
===
--- gcc/config/c6x/c6x.c2017-09-11 17:14:25.531400365 +0100
+++ gcc/config/c6x/c6x.c2017-09-11 17:16:57.875552068 +0100
@@ -4025,7 +4025,7 @@ c6x_mark_regno_

Turn SLOW_UNALIGNED_ACCESS into a target hook

2017-09-11 Thread Richard Sandiford
Pretty mechanical conversion.

Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
Also tested by comparing the testsuite assembly output on at least one
target per CPU directory.  OK to install?

Richard


2017-09-11  Richard Sandiford  
Alan Hayward  
David Sherwood 

gcc/
* defaults.h (SLOW_UNALIGNED_ACCESS): Delete.
* target.def (slow_unaligned_access): New hook.
* targhooks.h (default_slow_unaligned_access): Declare.
* targhooks.c (default_slow_unaligned_access): New function.
* doc/tm.texi.in (SLOW_UNALIGNED_ACCESS): Replace with...
(TARGET_SLOW_UNALIGNED_ACCESS): ...this.
* doc/tm.texi: Regenerate.
* config/alpha/alpha.h (SLOW_UNALIGNED_ACCESS): Delete.
* config/arm/arm.h (SLOW_UNALIGNED_ACCESS): Delete.
* config/i386/i386.h (SLOW_UNALIGNED_ACCESS): Delete commented-out
definition.
* config/powerpcspe/powerpcspe.h (SLOW_UNALIGNED_ACCESS): Delete.
* config/powerpcspe/powerpcspe.c (TARGET_SLOW_UNALIGNED_ACCESS):
Redefine.
(rs6000_slow_unaligned_access): New function.
(rs6000_emit_move): Use it instead of SLOW_UNALIGNED_ACCESS.
(expand_block_compare): Likewise.
(expand_strn_compare): Likewise.
(rs6000_rtx_costs): Likewise.
* config/riscv/riscv.h (SLOW_UNALIGNED_ACCESS): Delete.
(riscv_slow_unaligned_access): Likewise.
* config/riscv/riscv.c (riscv_slow_unaligned_access): Rename to...
(riscv_slow_unaligned_access_p): ...this and make static.
(riscv_option_override): Update accordingly.
(riscv_slow_unaligned_access): New function.
(TARGET_SLOW_UNALIGNED_ACCESS): Redefine.
* config/rs6000/rs6000.h (SLOW_UNALIGNED_ACCESS): Delete.
* config/rs6000/rs6000.c (TARGET_SLOW_UNALIGNED_ACCESS): Redefine.
(rs6000_slow_unaligned_access): New function.
(rs6000_emit_move): Use it instead of SLOW_UNALIGNED_ACCESS.
(rs6000_rtx_costs): Likewise.
* config/rs6000/rs6000-string.c (expand_block_compare)
(expand_strn_compare): Use targetm.slow_unaligned_access instead
of SLOW_UNALIGNED_ACCESS.
* config/tilegx/tilegx.h (SLOW_UNALIGNED_ACCESS): Delete.
* config/tilepro/tilepro.h (SLOW_UNALIGNED_ACCESS): Delete.
* calls.c (expand_call): Use targetm.slow_unaligned_access instead
of SLOW_UNALIGNED_ACCESS.
* expmed.c (simple_mem_bitfield_p): Likewise.
* expr.c (alignment_for_piecewise_move): Likewise.
(emit_group_load_1): Likewise.
(emit_group_store): Likewise.
(copy_blkmode_from_reg): Likewise.
(emit_push_insn): Likewise.
(expand_assignment): Likewise.
(store_field): Likewise.
(expand_expr_real_1): Likewise.
* gimple-fold.c (gimple_fold_builtin_memory_op): Likewise.
* lra-constraints.c (simplify_operand_subreg): Likewise.
* stor-layout.c (bit_field_mode_iterator::next_mode): Likewise.
* gimple-ssa-store-merging.c: Likewise in block comment at start
of file.
* tree-ssa-strlen.c: Include target.h.
(handle_builtin_memcmp): Use targetm.slow_unaligned_access instead
of SLOW_UNALIGNED_ACCESS.
* system.h (SLOW_UNALIGNED_ACCESS): Poison.


Re: [PATCH 10/13] D: The D runtime library and license.

2017-09-11 Thread Jeff Law
On 05/28/2017 03:47 PM, Iain Buclaw wrote:
> This patch adds the D runtime library and license (Boost) files.  D
> runtime is a low level that implements the building blocks of the
> runtime environment, as well as C and C++ platform bindings.  Many
> high level operations are lowered to generate calls to various
> functions defined in this library.
> 
> I've uploaded the patch to my ftp, sorry about the impromptu of this,
> I had everything neatly lined up, but stumbled after being rejected by
> the mail daemon.
So with libphobos the big question is whether or not the library is
supposed to be a part of GCC or if we're just a downstream user of a
library with a reasonably permissive license (and I'm going to assume
that all the files are under a suitable license, I spot checked, but did
not look at each and every one).

There's a lot of code in here I'd want to look at more closely if we're
maintaining it within the GCC project, but which I'd let go if we're
strictly downstream.

Jeff



Re: [PATCH] PR libstdc++/79162 ambiguity in string assignment due to string_view overload (LWG 2946)

2017-09-11 Thread Jonathan Wakely

On 04/09/17 16:48 +0100, Jonathan Wakely wrote:

On 30/07/17 15:01 +0200, Daniel Krügler wrote:

2017-07-28 22:40 GMT+02:00 Daniel Krügler :

2017-07-28 22:29 GMT+02:00 Daniel Krügler :

2017-07-28 22:25 GMT+02:00 Tim Song :

On Fri, Jul 28, 2017 at 4:10 PM, Daniel Krügler
 wrote:

+  // Performs an implicit conversion from _Tp to __sv_type.
+  template
+static __sv_type _S_to_string_view(const _Tp& __svt)
+{
+  return __svt;
+}


I might have gone for

+static __sv_type _S_to_string_view(__sv_type __svt) noexcept
+{
+  return __svt;
+}

With that, we can also use noexcept(_S_to_string_view(__t)) to make up
for the absence of is_nothrow_convertible (basically the same thing I
did in LWG 2993's PR).


Agreed, that makes very much sense. I will adjust the P/R, but before
I resubmit I would like to get feedback whether the other two compare
functions also should become conditionally noexcept.


Locally I have now performed the sole change of the _S_to_string_view
declaration getting rid of the template, but would also like to gather
feedback from the maintainers whether I should also change the form of
the conditional noexcept to use the expression

noexcept(_S_to_string_view(__t))

instead of the current

is_same<_Tp, __sv_type>::value

as suggested by Tim Song.

I'm asking also, because I have a paper proposing to standardize
is_nothrow_convertible submitted for the upcoming C++ mailing - This
would be one of the first applications in the library ;-)


A slightly revised patch update: It replaces the _S_to_string_view
template by a simpler _S_to_string_view function as of Tim Song's
suggestion, but still uses the simplified noexcept specification
deferring it to a future application case for is_nothrow_convertible.
Furthermore now all three compare function templates are now
(conditionally) noexcept by an (off-list) suggestion from Jonathan
Wakely.


I've committed this, after some whitespace fixes and testing.

Thanks!



We also need this tweak, to account for the fact that the old
std::string has this signature:

 basic_string& replace(iterator __i1, iterator __i2,
initializer_list<_CharT> __l)


Tested powerpc64le-linux, committed to trunk.


commit c435fd7ed919ae54fc8f730844c7466822787ff8
Author: Jonathan Wakely 
Date:   Mon Sep 11 17:29:34 2017 +0100

Adjust test to pass with old std::string

* testsuite/21_strings/basic_string/lwg2946.cc: Adjust for
compatibility with old COW std::string.

diff --git a/libstdc++-v3/testsuite/21_strings/basic_string/lwg2946.cc b/libstdc++-v3/testsuite/21_strings/basic_string/lwg2946.cc
index 74d5a5c89a7..fe1f15553fb 100644
--- a/libstdc++-v3/testsuite/21_strings/basic_string/lwg2946.cc
+++ b/libstdc++-v3/testsuite/21_strings/basic_string/lwg2946.cc
@@ -29,7 +29,7 @@ int main()
   s.assign({"abc", 1});
   s.insert(0, {"abc", 1});
   s.replace(0, 1, {"abc", 1});
-  s.replace(s.cbegin(), s.cbegin(), {"abc", 1});
+  s.replace(s.begin(), s.begin(), {"abc", 1});
   s.find({"abc", 1});
   s.rfind({"abc", 1});
   s.find_first_of({"abc", 1});


Re: [PATCH v2 11/13] D: GCC builtins and runtime support.

2017-09-11 Thread Jeff Law
On 06/24/2017 11:53 AM, Iain Buclaw wrote:
> On 28 May 2017 at 23:17, Iain Buclaw  wrote:
>> This patch adds GCC builtins and runtime support for GDC compiled code.
>>
>>   - module __entrypoint defines the C main function.  Its contents are
>> parsed and compiled in during compilation, but only if needed.
>>   - module gcc.atomic is a deprecated module that defines templated
>> __sync builtins.  It's original user, core.atomic, now uses the GCC
>> __atomic builtins.
>>   - module gcc.attribute exposes GDC-specific attributes.
>>   - module gcc.backtrace implements backtrace support for GDC.
>>   - module gcc.builtins exposes GCC builtins to D code.
>>   - module gcc.config exposes things determined at configure time to D code.
>>   - module gcc.deh implements D unwind EH.
>>   - module gcc.libbacktrace defines C bindings to libbacktrace.
>>   - module gcc.unwind defines C bindings to libgcc unwind library.
>>   - libgphobos.spec contains a list of libraries to link in that are
>> dependencies of D runtime and/or the Phobos standard library.  It is
>> used by the GDC driver.
>>
>> ---
> Added GCC Runtime Library Exception to gcc modules as requested.
Nothing particularly concerning here now that the license is fixed.
Based on my reading, this is all code that the FSF will own, so we don't
have to worry about alternate upstreams, license exceptions, etc which
makes things so much easier.

You may need to bump the copyright dates.

jeff


Re: [PATCH 6/13] D: Add D language support to GCC proper.

2017-09-11 Thread Jeff Law
On 05/28/2017 03:15 PM, Iain Buclaw wrote:
> This patch adds D language support to GCC itself.
> 
> ---
> 
> 
> 06-d-gcc-proper.patch
> 
> 
> gcc/ChangeLog
> 
>   * config/rs6000/rs6000.c (rs6000_output_function_epilogue):
>   Support GNU D by using 0 as the language type.
>   * dwarf2out.c (is_dlang): New function.
>   (gen_compile_unit_die): Use DW_LANG_D for D.
>   (declare_in_namespace): Return module die for D, instead of adding
>   extra declarations into the namespace.
>   (gen_namespace_die): Generate DW_TAG_module for D.
>   (gen_decl_die, dwarf2out_decl): Handle CONST_DECLSs for D.
>   * gcc.c (default_compilers): Add entries for ".d", ".dd" and ".di".This 
> is fine when prereqs are approved.

jeff


Re: [PATCH 5/13] D: GCC configuration file changes and documentation.

2017-09-11 Thread Jeff Law
On 05/28/2017 03:15 PM, Iain Buclaw wrote:
> This patch adds the D language front-end to GCC documentation and
> configuration files, as described on the anatomy of a language
> front-end.
> 
> ---
> 
> 
> 05-d-gcc-config.patch
> 
> 
> ChangeLog:
> 
>   * Makefile.def (target_modules): Add libphobos.
>   (flags_to_pass): Add GDC_FOR_TARGET.
>   (dependencies): Add dependency from configure-target-libphobos to
>   configure-target-zlib.  Add dependency from all-target-libphobos to
>   all-target-zlib.
>   (language): Add languge d.
>   * Makefile.in: Rebuild.
>   * Makefile.tpl (BUILT_EXPORTS): Add GDC.
>   (HOST_EXPORTS): Add GDC.
>   (BASE_TARGET_EXPORTS): Add GDC.
>   (GDC_FOR_BUILD, GDC_FOR_TARGET): New variables.
>   (EXTRA_HOST_FLAGS): Add GDC.
>   (EXTRA_TARGET_FLAGS): Add GDC.
>   * config-ml.in: Treat GDC and GDCFLAGS like other compiler/flag
>   environment variables.
>   * configure: Rebuild.
>   * configure.ac: Add target-libphobos to target_libraries.  Set and
>   substitute GDC_FOR_BUILD and GDC_FOR_TARGET.
> 
> config/ChangeLog:
> 
>   * multi.m4: Set GDC.
> 
> gcc/ChangeLog:
> 
>   * doc/contrib.texi (Contributors): Add self for the D frontend.
>   * doc/frontends.texi (G++ and GCC): Mention D as a supported language.
>   * doc/install.texi (Configuration): Mention libphobos as an option for
>   --enable-shared.  Mention d as an option for --enable-languages.
>   (Testing): Mention check-d as a target.
>   * doc/invoke.texi (Overall Options): Mention .d, .dd, and .di as file
>   name suffixes.  Mention d as a -x option.
>   * doc/sourcebuild.texi (Top Level): Mention libphobos.
>   * doc/standards.texi (Standards): Add section on D language.
I don't see anything in here which concerns me -- it's mostly
boilerplate stuff.

Jeff


[PATCH, rs6000] add vectorization to vec_mule and vec_mulo builtins

2017-09-11 Thread Carl Love
GCC Maintainers:

The following patch re-adds the vectorization support for the vec_mule()
and vec_mul0() builtins to the tree.  The vectorization support was part
of the original patch, commit 249424, to add the builtin funtionality.
But the vectorization part was pulled as part of commit 250295 due to an
underlying bug in the GCC vectorization support.  Bill Schmidt fixed the
underlying vectorization support in commit 251161 on 8/16/17 allowing
the vectorization support to be re-added for these builtins.

I have tested the patch on powerpc64le-unknown-linux-gnu (Power 8 LE),
powerpc64-unknown-linux-gnu (Power 8 BE) systems with no regressions.

Please let me know if the following patch is acceptable.  Thanks.

Carl Love


gcc/ChangeLog:

2017-09-11  Carl Love  

* config/rs6000/altivec.md (vec_widen_umult_even_v4si,
vec_widen_smult_even_v4si): Add define expands for vmuleuw, vmulesw,
vmulouw, vmulosw.
* config/rs6000/rs6000-builtin.def (VMLEUW, VMULESW, VMULOUW,
VMULOSW): Add definitions.
* config/rs6000/rs6000-c.c (altivec_overloaded_builtins): Add
ALTIVEC_BUILTIN_VMULESW, ALTIVEC_BUILTIN_VMULEUW,
ALTIVEC_BUILTIN_VMULOSW, ALTIVEC_BUILTIN_VMULOUW entries.
* config/rs6000/rs6000.c (rs6000_gimple_fold_builtin,
builtin_function_type): Add ALTIVEC_BUILTIN_* case statements.
---
 gcc/config/rs6000/altivec.md | 54 
 gcc/config/rs6000/rs6000-builtin.def |  8 +++---
 gcc/config/rs6000/rs6000-c.c |  9 ++
 gcc/config/rs6000/rs6000.c   |  4 +++
 4 files changed, 71 insertions(+), 4 deletions(-)

diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
index 0aa1e30..168cdb3 100644
--- a/gcc/config/rs6000/altivec.md
+++ b/gcc/config/rs6000/altivec.md
@@ -1428,6 +1428,32 @@
   DONE;
 })
 
+(define_expand "vec_widen_umult_even_v4si"
+  [(use (match_operand:V2DI 0 "register_operand"))
+   (use (match_operand:V4SI 1 "register_operand"))
+   (use (match_operand:V4SI 2 "register_operand"))]
+  "TARGET_P8_VECTOR"
+{
+ if (VECTOR_ELT_ORDER_BIG)
+emit_insn (gen_altivec_vmuleuw (operands[0], operands[1], operands[2]));
+  else
+emit_insn (gen_altivec_vmulouw (operands[0], operands[1], operands[2]));
+ DONE;
+})
+
+(define_expand "vec_widen_smult_even_v4si"
+  [(use (match_operand:V2DI 0 "register_operand"))
+   (use (match_operand:V4SI 1 "register_operand"))
+   (use (match_operand:V4SI 2 "register_operand"))]
+  "TARGET_P8_VECTOR"
+{
+  if (VECTOR_ELT_ORDER_BIG)
+emit_insn (gen_altivec_vmulesw (operands[0], operands[1], operands[2]));
+ else
+emit_insn (gen_altivec_vmulosw (operands[0], operands[1], operands[2]));
+  DONE;
+})
+
 (define_expand "vec_widen_umult_odd_v16qi"
   [(use (match_operand:V8HI 0 "register_operand" ""))
(use (match_operand:V16QI 1 "register_operand" ""))
@@ -1480,6 +1506,34 @@
   DONE;
 })
 
+(define_expand "vec_widen_umult_odd_v4si"
+  [(use (match_operand:V2DI 0 "register_operand"))
+   (use (match_operand:V4SI 1 "register_operand"))
+   (use (match_operand:V4SI 2 "register_operand"))]
+  "TARGET_P8_VECTOR"
+{
+  if (VECTOR_ELT_ORDER_BIG)
+emit_insn (gen_altivec_vmulouw (operands[0], operands[1], operands[2]));
+  else
+emit_insn (gen_altivec_vmuleuw (operands[0], operands[1], operands[2]));
+  DONE;
+})
+
+(define_expand "vec_widen_smult_odd_v4si"
+  [(use (match_operand:V2DI 0 "register_operand" ""))
+   (use (match_operand:V4SI 1 "register_operand" ""))
+   (use (match_operand:V4SI 2 "register_operand" ""))]
+  "TARGET_P8_VECTOR"
+{
+  if (VECTOR_ELT_ORDER_BIG)
+emit_insn (gen_altivec_vmulosw (operands[0], operands[1],
+   operands[2]));
+  else
+emit_insn (gen_altivec_vmulesw (operands[0], operands[1],
+   operands[2]));
+  DONE;
+})
+
 (define_insn "altivec_vmuleub"
   [(set (match_operand:V8HI 0 "register_operand" "=v")
 (unspec:V8HI [(match_operand:V16QI 1 "register_operand" "v")
diff --git a/gcc/config/rs6000/rs6000-builtin.def 
b/gcc/config/rs6000/rs6000-builtin.def
index 850164a..18db576 100644
--- a/gcc/config/rs6000/rs6000-builtin.def
+++ b/gcc/config/rs6000/rs6000-builtin.def
@@ -1031,14 +1031,14 @@ BU_ALTIVEC_2 (VMULEUB,"vmuleub",CONST,  
vec_widen_umult_even_v16qi)
 BU_ALTIVEC_2 (VMULESB,   "vmulesb",CONST,  
vec_widen_smult_even_v16qi)
 BU_ALTIVEC_2 (VMULEUH,   "vmuleuh",CONST,  
vec_widen_umult_even_v8hi)
 BU_ALTIVEC_2 (VMULESH,   "vmulesh",CONST,  
vec_widen_smult_even_v8hi)
-BU_ALTIVEC_2 (VMULEUW,   "vmuleuw",CONST,  altivec_vmuleuw)
-BU_ALTIVEC_2 (VMULESW,   "vmulesw",CONST,  altivec_vmulesw)
+BU_ALTIVEC_2 (VMULEUW,   "vmuleuw",CONST,  
vec_widen_umult_even_v4si)
+BU_ALTIVEC_2 (VMULESW,   "vmulesw",CONST,  
vec_widen_

Re: [PING, Makefile] improve libsubdir variable transmission to sub-makes (for Windows)

2017-09-11 Thread Olivier Hainque
Hello Michael,

> On Sep 11, 2017, at 17:28 , Michael Haubenwallner 
>  wrote:

>>>  Makefile.in:
>>>  ...
>>>  export libsubdir
>>> 
>>> This is not working well on cygwin environments where environment
>>> variable names are translated to uppercase (so sub-makes evaluating
>>> the variable with the lowercase name don't get the value).
> 
> just wondering if you can't update your Cygwin setup, as turning environment
> variables to uppercase is not done by default in recent Cygwin any more, see
> https://cygwin.com/cygwin-ug-net/using-cygwinenv.html

Thanks for your input and for the pointer! Maybe we could update our
environment locally and forget about it. This might be useful for other
contexts as well.

Now it might be difficult, if not impossible, for some people, so if passing
the variable through an explicit assignment is expected to work as well, the
change would remain of interest IMO, just removing a dependency on a particular
environment setup.

With Kind Regards,

Olivier



Re: [PATCH 4/13] D: The front-end (GDC) config, makefile, and manpages.

2017-09-11 Thread Jeff Law
On 05/28/2017 03:12 PM, Iain Buclaw wrote:
> This patch adds the D frontend language configure make files, as
> described on the anatomy of a language front-end.
> 
> ---
> 
> 
> 04-d-frontend-misc.patch
> 
> 


> +
> +You can specify more than one input file on the @command{gdc} command line,
> +in which case they will all be compiled.  If you specify a
> +@code{-o @var{file}} option, all the input files will be compiled together,
> +producing a single output file, named @var{file}.  This is allowed even
> +when using @code{-S} or @code{-c}.
So out of curiosity, when multiple sources are specified on the command
line, are they subject to IPA as a group or are they handled individually?

> +@item -fno-bounds-check
> +@cindex @option{-fbounds-check}
> +@cindex @option{-fno-bounds-check}
> +Turns off array bounds checking for all functions, which can improve
> +performance for code that uses array extensively.  Note that this
> +can result in unpredictable behavior if the code in question actually
> +does violate array bounds constraints.  It is safe to use this option
> +if you are sure that your code will never throw a @code{RangeError}.
So I don't know the internals of where you keep the bounds and how you
generate code for checking, but it might be worth looking at what Roger
Sayle did for Java array index checking back in 2016:

https://gcc.gnu.org/ml/java-patches/2016-q1/msg00014.html

I don't know if his trick of exposing an extra write would apply to D,
but it's worth reviewing.

> +
> +@item -funittest
> +@cindex @option{-funittest}
> +@cindex @option{-fno-unittest}
> +Turns on compilation of @code{unittest} code, and turns on the
> +@code{version(unittest)} identifier.  This implies @option{-fassert}.
I think we're using -fselftest elsewhere for unit testing bits within
the compiler.  Can you look and see if your unit tests are comparable
and perhaps consider using the same option if they are?


> +
> +@node Code Generation
> +@section Code Generation
> +@cindex options, code generation
> +
> +In addition to the many @command{gcc} options controlling code generation,
> +@command{gdc} has several options specific to itself.
> +
> +@table @gcctabopt
> +
> +@item -M
> +@cindex @option{-M}
> +Output the module dependencies of all source files being compiled in a
> +format suitable for @command{make}.  The compiler outputs one
> +@command{make} rule containing the object file name for that source file,
> +a colon, and the names of all imported files.
[ ... Many -M options ... ]
Note we recently allowed generation of the dependency files even in the
case some errors.  Please consider doing the same if it makes sense.
See the Sept change to c_common_finish.


> +
> +@c man begin ENVIRONMENT
> +
> +In addition to the many @command{gcc} environment variables that control
> +its operation, @command{gdc} has a few environment variables specific to
> +itself.
> +
> +@vtable @env
> +
> +@item D_IMPORT_PATH
> +@findex D_IMPORT_PATH
> +The value of @env{D_IMPORT_PATH} is a list of directories separated by a
> +special character, much like @env{PATH}, in which to look for imports.
> +The special character, @code{PATH_SEPARATOR}, is target-dependent and
> +determined at GCC build time.  For Microsoft Windows-based targets it is a
> +semicolon, and for almost all other targets it is a colon.
> +
> +@item DDOCFILE
> +@findex DDOCFILE
> +If @env{DDOCFILE} is set, it specifies a text file of macro definitions
> +to be read and used by the Ddoc generator.  This overrides any macros
> +defined in other @file{.ddoc} files.
How important are the environment variables to the existing user base?
We generally try to avoid changing much behavior based on environment
variables.  Can these be made command line options?

jeff


Re: [PATCH 3/13] D: The front-end (GDC) changelogs.

2017-09-11 Thread Jeff Law
On 05/28/2017 03:11 PM, Iain Buclaw wrote:
> This patch just includes all changelogs for the D front-end (GDC),
> going back to the dawn of time itself.
> 
> Change logs for the DMD front-end and libraries are kept on the dlang site.
Your call on how much of the historical record you want to keep.

jeff


Re: [PATCH 2/13] D: The front-end (GDC) implementation.

2017-09-11 Thread Jeff Law
On 05/28/2017 03:11 PM, Iain Buclaw wrote:
> This patch adds the D front-end implementation, the only part of the
> compiler that interacts with GCC directly, and being the parts that I
> maintain, is something that I can talk about more directly.
> 
> For the actual code generation pass, that converts the front-end AST
> to GCC trees, most parts use a separate Visitor interfaces to do a
> certain kind of lowering, for instance, types.cc builds *_TYPE trees
> from AST Type's.  The Visitor class is part of the DMD front-end, and
> is defined in dfrontend/visitor.h.
> 
> There are also a few interfaces which have their headers in the DMD
> frontend, but are implemented here because they do something that
> requires knowledge of the GCC backend (d-target.cc), does something
> that may not be portable, or differ between D compilers
> (d-frontend.cc) or are a thin wrapper around something that is managed
> by GCC (d-diagnostic.cc).
> 
> Many high level operations result in generation of calls to D runtime
> library functions (runtime.def), all with require some kind of runtime
> type information (typeinfo.cc).  The compiler also generates functions
> for registering/deregistering compiled modules with the D runtime
> library (modules.cc).
> 
> As well as the D language having it's own built-in functions
> (intrinsics.cc), we also expose GCC builtins to D code via a
> `gcc.builtins' module (d-builtins.cc), and give special treatment to a
> number of UDAs that could be applied to functions (d-attribs.cc).
> 
> 
> That is roughly the high level jist of how things are currently organized.
> 
> Regards
> Iain
> 
> ---
> 
Presumably the types and interfaces which are capitalized in violation
of GNU standards are done so to interface the the DMD implementation?

Which implies the answer to a question in my prior message, namely that
the DMD implementation does get linked into GCC itself.  So I think we
need the SC to rule on whether or not that's allowed.

I'm not going to dive deep into this code -- it's essentially converting
between the different representations and is code that you'd be maintaining.

You probably want to review the #ifdefs you've got in here to make sure
they're not supposed to be checked via #if or runtime checks (there's
only a half-dozen or so):

+#ifdef STACK_GROWS_DOWNWARD
+#ifdef HAVE_LD_STATIC_DYNAMIC
+#ifdef HAVE_LD_STATIC_DYNAMIC
+#ifdef BIGGEST_FIELD_ALIGNMENT
+#ifdef ADJUST_FIELD_ALIGN
+#ifdef ENABLE_TREE_CHECKING

Joseph already commented on Target::critsecsize.

Jeff


Jeff


Re: [RFC, vectorizer] Allow single element vector types for vector reduction operations

2017-09-11 Thread Vidya Praveen
On Tue, Sep 05, 2017 at 03:12:47PM +0200, Richard Biener wrote:
> On Tue, 5 Sep 2017, Tamar Christina wrote:
> 
> > 
> > 
> > > -Original Message-
> > > From: Richard Biener [mailto:rguent...@suse.de]
> > > Sent: 05 September 2017 13:51
> > > To: Tamar Christina
> > > Cc: Andrew Pinski; Andreas Schwab; Jon Beniston; gcc-patches@gcc.gnu.org;
> > > nd
> > > Subject: RE: [RFC, vectorizer] Allow single element vector types for 
> > > vector
> > > reduction operations
> > > 
> > > On Tue, 5 Sep 2017, Richard Biener wrote:
> > > 
> > > > On Tue, 5 Sep 2017, Tamar Christina wrote:
> > > >
> > > > > Hi Richard,
> > > > >
> > > > > That was an really interesting analysis, thanks for the details!
> > > > >
> > > > > Would you be submitting the patch you proposed at the end as a fix?
> > > >
> > > > I'm testing it currently.
> > > 
> > > Unfortunately it breaks some required lowering.  I'll have to more closely
> > > look at this.
> > 
> > Ah, ok. In the meantime, can this patch be reverted? It's currently 
> > breaking spec for us so we're
> > Not able to get any benchmarking numbers.
> 
> Testing the following instead:

Any news on this?

VP.


> 
> Index: gcc/tree-vect-generic.c
> ===
> --- gcc/tree-vect-generic.c (revision 251642)
> +++ gcc/tree-vect-generic.c (working copy)
> @@ -1640,7 +1640,7 @@ expand_vector_operations_1 (gimple_stmt_
>|| code == VEC_UNPACK_FLOAT_LO_EXPR)
>  type = TREE_TYPE (rhs1);
>  
> -  /* For widening/narrowing vector operations, the relevant type is of 
> the
> +  /* For widening vector operations, the relevant type is of the
>   arguments, not the widened result.  VEC_UNPACK_FLOAT_*_EXPR is
>   calculated in the same way above.  */
>if (code == WIDEN_SUM_EXPR
> @@ -1650,9 +1650,6 @@ expand_vector_operations_1 (gimple_stmt_
>|| code == VEC_WIDEN_MULT_ODD_EXPR
>|| code == VEC_UNPACK_HI_EXPR
>|| code == VEC_UNPACK_LO_EXPR
> -  || code == VEC_PACK_TRUNC_EXPR
> -  || code == VEC_PACK_SAT_EXPR
> -  || code == VEC_PACK_FIX_TRUNC_EXPR
>|| code == VEC_WIDEN_LSHIFT_HI_EXPR
>|| code == VEC_WIDEN_LSHIFT_LO_EXPR)
>  type = TREE_TYPE (rhs1);
> 
> 
> also fix for a bug uncovered by the previous one:
> 
> Index: gcc/gimple-ssa-strength-reduction.c
> ===
> --- gcc/gimple-ssa-strength-reduction.c (revision 251710)
> +++ gcc/gimple-ssa-strength-reduction.c (working copy)
> @@ -1742,8 +1742,7 @@ find_candidates_dom_walker::before_dom_c
> slsr_process_ref (gs);
>  
>else if (is_gimple_assign (gs)
> -  && SCALAR_INT_MODE_P
> -   (TYPE_MODE (TREE_TYPE (gimple_assign_lhs (gs)
> +  && INTEGRAL_TYPE_P (TREE_TYPE (gimple_assign_lhs (gs
> {
>   tree rhs1 = NULL_TREE, rhs2 = NULL_TREE;
>  
> 


Re: [PATCH][ARM] Remove Thumb-2 iordi_not patterns

2017-09-11 Thread Wilco Dijkstra
Any further comments?

    
Kyrill Tkachov wrote:

> > After Bernd's change almost all DI mode instructions are split before 
> > register
> > allocation. So instructions using DI mode no longer exist and thus these
> > extend variants can never be matched and are thus redundant.
>
> Bernd's patch splits them when we don't have NEON. When NEON is 
> available though
> they still maintain the DImode so we'd still benefit from these 
> transformations, no?

While you're right it may be possible to trigger these instructions, ORN is 
already
so rare that it is hardly beneficial to have an instruction for it, and ORN of 
an extended
value never ever happens. So there is absolutely no benefit in keeping these 
versions
temporarily until we fix Neon too.

For the Neon case my proposal is to use the VFP early expansion (so you get an 
efficient
expansion by default in all cases). You can then use -mneon-for-64bits to 
enable the use
of Neon instructions (which may be even better in some cases). There are quite 
a few
patches in this series already and more to come soon!

Wilco

Re: [PING, Makefile] improve libsubdir variable transmission to sub-makes (for Windows)

2017-09-11 Thread Michael Haubenwallner
Hi Oliver,

On 09/11/2017 04:30 PM, Olivier Hainque wrote:
> Hello,
> 
> Ping for https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00017.html
> 
>>   Makefile.in:
>>   ...
>>   export libsubdir
>>
>> This is not working well on cygwin environments where environment
>> variable names are translated to uppercase (so sub-makes evaluating
>> the variable with the lowercase name don't get the value).

just wondering if you can't update your Cygwin setup, as turning environment
variables to uppercase is not done by default in recent Cygwin any more, see
https://cygwin.com/cygwin-ug-net/using-cygwinenv.html

/haubi/


RE: [PATCH] Add 'short_call' attribute for MIPS targets

2017-09-11 Thread Matthew Fortune
Simon Atanasyan  writes:
> Here is the updated patch with chnaged e-mail address and fixed
> indentation issues:
> -8<
> Currently GCC supports 'long_call', 'far', and 'near' attributes. The
> 'long_call' and 'far' attributes are synonyms. This patch adds support
> for the 'short_call' attribute as a synonym for `near` to make this list
> complete, consistent with other targets, and compatible with attributes
> supported by the Clang.
> 
> Tested on mipsel-linux-gnu.
> 
> 2017-08-18  Simon Atanasyan  
> 
> gcc/
>   * config/mips/mips.c (mips_attribute_table): Add 'short_call'
>   attribute.
>   (mips_near_type_p): Add 'short_call' attribute as a synonym
>   for 'near'.
>   * doc/extend.texi (short_call): Document new function attribute.
> 
> gcc/testsuite
> 
>   * gcc.target/mips/near-far-1.c: Add check for 'short_call'
>   attribute.
>   * gcc.target/mips/near-far-2.c: Likewise.
>   * gcc.target/mips/near-far-3.c: Likewise.
>   * gcc.target/mips/near-far-4.c: Likewise.

OK to commit, thanks.

Matthew


Re: [PATCH 1/13] D: The front-end (DMD) language implementation and license.

2017-09-11 Thread Jeff Law
On 05/28/2017 03:02 PM, Iain Buclaw wrote:
> (Sorry, repost as I rushed the first one a bit).
> 
> This patch adds the DMD front-end proper and license (Boost) files,
> comprised of a lexer, parser, and semantic analyzer.
> 
> Split 1/4
> 
> Gzipped because of size limitations.
So for 1/13, these are all bits that are maintained on github and we're
just a downstream user, right?  Meaning I don't need to do a deep dive
in this patch within the series, right?

Does this stuff get bound into GCC?  The reason I ask is the files are
under the Boost license with ownership by Digital Mars.  While we often
have a fair amount of leeway with runtime systems, we may not have the
same kind of license/ownership leeway with things that are actually part
of the compiler itself.

Did the discussions between the FSF, Digital Mars and Walter touch in
these issues at all?  Have you received any guidance from the parties on
this issue?

Is there any way this stuff could be a separate executable or DSO?  That
might make things easier on the licensing front.

Jeff


Re: [PING, Makefile] improve default cpu selection for e500v2

2017-09-11 Thread Olivier Hainque
Hello,

Ping for https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01783.html

> config.gcc already has a provision for a good default
> cpu selection for SPE with double precision floats
> when the latter is explicitly requested with an explicit
> --enable command line option.
...
> The attached patch is a proposal to refine this to select 8548 also
> when we were configured for an e500v2 target cpu (canonicalized to
> match powerpc-*spe), regardless of enable_e500_double.

> 2017-08-31  Olivier Hainque  
> 
>* gcc/config.gcc (powerpc*-*-*spe*): Pick 8548 as the
>   default with_cpu for an e500v2 target cpu name, in addition
>   to --enable-e500-double.


Thanks in advance,

With Kind Regards,

Olivier



Re: [PING, Makefile] improve libsubdir variable transmission to sub-makes (for Windows)

2017-09-11 Thread Olivier Hainque
Hello,

Ping for https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00017.html

>   Makefile.in:
>   ...
>   export libsubdir
> 
> This is not working well on cygwin environments where environment
> variable names are translated to uppercase (so sub-makes evaluating
> the variable with the lowercase name don't get the value).

> 2017-09-01  Jerome Lambourg  
> 
>   * Makefile.in (FLAGS_TO_PASS): Add libsubdir.

Thanks much in advance!

With Kind Regards,

Olivier



Re: [COMMITTED][arm] Revert r251800 & r251799

2017-09-11 Thread Vidya Praveen
Now with the patch :-)

VP.

On Mon, Sep 11, 2017 at 03:20:12PM +0100, Vidya Praveen wrote:
> Hello,
> 
> The following two related patches need to be reverted as it causes 
> cross-native
> builds to fail with the following message:
> 
> g++ -c -DIN_GCC -DGENERATOR_FILE  -I. [...] \
>   -o build/genpreds.o /path/to/src/gcc/gcc/genpreds.c
> In file included from ./options.h:8:0,
>  from ./tm.h:23,
>  from /path/to/src/gcc/gcc/genpreds.c:26:
> /path/to/src/gcc/gcc/config/arm/arm-opts.h:29:21: fatal error: arm-isa.h: No 
> such file or directory
>  #include "arm-isa.h"
>   ^
> genpreds depends on GTM_H which does not depend on options.h, or any of its
> dependencies.  Nevertheless, it still tries to include options.h when reading
> tm.h, so we miss the rule to build arm-isa.h. It is unclear why it is only an
> issue with the cross-native builds.
> 
> For now, in order to keep the builds going, I am reverting these patches.
> 
> 
> r251800 | rearnsha | 2017-09-06 14:42:54 +0100 (Wed, 06 Sep 2017) | 16 lines
> 
> [arm] Improve error checking in parsecpu.awk
> 
> This patch adds a bit more error checking to parsecpu.awk to ensure
> that statements are not missing arguments or have excess arguments
> beyond those permitted.  It also slightly improves the handling of
> errors so that we terminate properly if parsing fails and be as
> helpful as we can while in the parsing phase.
> 
> * config/arm/parsecpu.awk (fatal): Note that we've encountered an
> error.  Only quit immediately if parsing is complete.
> (BEGIN): Initialize fatal_err and parse_done.
> (begin fpu, end fpu): Check number of arguments.
> (begin arch, end arch): Likewise.
> (begin cpu, end cpu): Likewise.
> (cname, tune for, tune flags, architecture, fpu, option): Likewise.
> (optalias): Likewise.
> 
> r251799 | rearnsha | 2017-09-06 14:42:46 +0100 (Wed, 06 Sep 2017) | 31 lines
> 
> [arm] auto-generate arm-isa.h from CPU descriptions
> 
> This patch autogenerates arm-isa.h from new entries in arm-cpus.in.
> This has the primary advantage that it makes the description file more
> self-contained, but it also solves the 'array dimensioning' problem
> that Tamar recently encountered.  It adds two new constructs to
> arm-cpus.in: features and fgroups.  Fgroups are simply a way of naming
> a group of feature bits so that they can be referenced together.  We
> follow the convention that feature bits are all lower case, while
> fgroups are (predominantly) upper case.  This is helpful as in some
> contexts they share the same namespace.  Most of the minor changes in
> this patch are related to adopting this new naming convention.
> 
> * config.gcc (arm*-*-*): Don't add arm-isa.h to tm_p_file.
> * config/arm/arm-isa.h: Delete.  Move definitions to ...
> * arm-cpus.in: ... here.  Use new feature and fgroup values.
> * config/arm/arm.c (arm_option_override): Use lower case for feature
> bit names.
> * config/arm/arm.h (TARGET_HARD_FLOAT): Likewise.
> (TARGET_VFP3, TARGET_VFP5, TARGET_FMA): Likewise.
> * config/arm/parsecpu.awk (END): Add new command 'isa'.
> (isa_pfx): Delete.
> (print_isa_bits_for): New function.
> (gen_isa): New function.
> (gen_comm_data): Use print_isa_bits_for.
> (define feature): New keyword.
> (define fgroup): New keyword.
> * config/arm/t-arm (OPTIONS_H_EXTRA): Add arm-isa.h
> (arm-isa.h): Add rule to generate file.
> * common/config/arm/arm-common.c: (arm_canon_arch_option): Use lower
> case for feature bit names.
> 
> Regards,
> VP.
> 
> 
> gcc/ChangeLog:
> 
> 2017-09-11  Vidya Praveen  
> 
>   Revert r251800 and r251799.
diff --git a/gcc/common/config/arm/arm-common.c b/gcc/common/config/arm/arm-common.c
index 7cb99ec..38bd3a7 100644
--- a/gcc/common/config/arm/arm-common.c
+++ b/gcc/common/config/arm/arm-common.c
@@ -574,7 +574,7 @@ arm_canon_arch_option (int argc, const char **argv)
 	{
 	  /* The easiest and safest way to remove the default fpu
 	 capabilities is to look for a '+no..' option that removes
-	 the base FPU bit (isa_bit_vfpv2).  If that doesn't exist
+	 the base FPU bit (isa_bit_VFPv2).  If that doesn't exist
 	 then the best we can do is strip out all the bits that
 	 might be part of the most capable FPU we know about,
 	 which is "crypto-neon-fp-armv8".  */
@@ -586,7 +586,7 @@ arm_canon_arch_option (int argc, const char **argv)
 		   ++ext)
 		{
 		  if (ext->remove
-		  && check_isa_bits_for (ext->isa_bits, isa_bit_vfpv2))
+		  && check_isa_bits_for (ext->isa_bits, isa_bit_VFPv2))
 		{
 		  arm_initialize_isa (fpu_isa, ext->isa_bits);
 		  bitmap_and_compl (target_isa, target_isa, fpu_isa);
@@ -620,7 +620,7 @@ arm_canon_arch_option (int argc, const char **argv)
 {
   /* Clearing the VFPv2

[COMMITTED][arm] Revert r251800 & r251799

2017-09-11 Thread Vidya Praveen
Hello,

The following two related patches need to be reverted as it causes cross-native
builds to fail with the following message:

g++ -c -DIN_GCC -DGENERATOR_FILE  -I. [...] \
-o build/genpreds.o /path/to/src/gcc/gcc/genpreds.c
In file included from ./options.h:8:0,
 from ./tm.h:23,
 from /path/to/src/gcc/gcc/genpreds.c:26:
/path/to/src/gcc/gcc/config/arm/arm-opts.h:29:21: fatal error: arm-isa.h: No 
such file or directory
 #include "arm-isa.h"
  ^
genpreds depends on GTM_H which does not depend on options.h, or any of its
dependencies.  Nevertheless, it still tries to include options.h when reading
tm.h, so we miss the rule to build arm-isa.h. It is unclear why it is only an
issue with the cross-native builds.

For now, in order to keep the builds going, I am reverting these patches.


r251800 | rearnsha | 2017-09-06 14:42:54 +0100 (Wed, 06 Sep 2017) | 16 lines

[arm] Improve error checking in parsecpu.awk

This patch adds a bit more error checking to parsecpu.awk to ensure
that statements are not missing arguments or have excess arguments
beyond those permitted.  It also slightly improves the handling of
errors so that we terminate properly if parsing fails and be as
helpful as we can while in the parsing phase.

* config/arm/parsecpu.awk (fatal): Note that we've encountered an
error.  Only quit immediately if parsing is complete.
(BEGIN): Initialize fatal_err and parse_done.
(begin fpu, end fpu): Check number of arguments.
(begin arch, end arch): Likewise.
(begin cpu, end cpu): Likewise.
(cname, tune for, tune flags, architecture, fpu, option): Likewise.
(optalias): Likewise.

r251799 | rearnsha | 2017-09-06 14:42:46 +0100 (Wed, 06 Sep 2017) | 31 lines

[arm] auto-generate arm-isa.h from CPU descriptions

This patch autogenerates arm-isa.h from new entries in arm-cpus.in.
This has the primary advantage that it makes the description file more
self-contained, but it also solves the 'array dimensioning' problem
that Tamar recently encountered.  It adds two new constructs to
arm-cpus.in: features and fgroups.  Fgroups are simply a way of naming
a group of feature bits so that they can be referenced together.  We
follow the convention that feature bits are all lower case, while
fgroups are (predominantly) upper case.  This is helpful as in some
contexts they share the same namespace.  Most of the minor changes in
this patch are related to adopting this new naming convention.

* config.gcc (arm*-*-*): Don't add arm-isa.h to tm_p_file.
* config/arm/arm-isa.h: Delete.  Move definitions to ...
* arm-cpus.in: ... here.  Use new feature and fgroup values.
* config/arm/arm.c (arm_option_override): Use lower case for feature
bit names.
* config/arm/arm.h (TARGET_HARD_FLOAT): Likewise.
(TARGET_VFP3, TARGET_VFP5, TARGET_FMA): Likewise.
* config/arm/parsecpu.awk (END): Add new command 'isa'.
(isa_pfx): Delete.
(print_isa_bits_for): New function.
(gen_isa): New function.
(gen_comm_data): Use print_isa_bits_for.
(define feature): New keyword.
(define fgroup): New keyword.
* config/arm/t-arm (OPTIONS_H_EXTRA): Add arm-isa.h
(arm-isa.h): Add rule to generate file.
* common/config/arm/arm-common.c: (arm_canon_arch_option): Use lower
case for feature bit names.

Regards,
VP.


gcc/ChangeLog:

2017-09-11  Vidya Praveen  

Revert r251800 and r251799.


Re: Announcing ARM and AArch64 port maintainers.

2017-09-11 Thread Kyrill Tkachov


On 09/09/17 12:44, Ramana Radhakrishnan wrote:

I'm pleased to announce that the steering committee has appointed

-  James Greenhalgh as a full maintainer for the AArch64 port

and

-  Kyrylo Tkachov as a full maintainer for the ARM port.

James & Kyrylo, if you could update your entries in the MAINTAINERS
file to reflect these roles, it would be appreciated.


Thank you for your trust. I look forward to continuing contributing to GCC!
I've committed this patch to trunk as r251979.

Kyrill

2017-09-11  Kyrylo Tkachov  

* MAINTAINERS (Reviewers): Move myself from here...
(CPU Port Maintainers): ... to here.

commit ec06d430aba1698fa4e653b8dc93bcad10852fb3
Author: Kyrylo Tkachov 
Date:   Mon Sep 11 10:27:00 2017 +0100

[MAINTAINERS] Add myself as ARM maintainer

diff --git a/MAINTAINERS b/MAINTAINERS
index 2ed1ef9..e5b9bc1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -47,6 +47,7 @@ arc port		Joern Rennecke		
 arm port		Nick Clifton		
 arm port		Richard Earnshaw	
 arm port		Ramana Radhakrishnan	
+arm port		Kyrylo Tkachov		
 avr port		Denis Chertykov		
 bfin port		Jie Zhang		
 c6x port		Bernd Schmidt		
@@ -252,7 +253,6 @@ check in changes outside of the parts of the compiler they maintain.
 
 arc port		Andrew Burgess		
 arc port		Claudiu Zissulescu	
-arm port		Kyrylo Tkachov		
 C front end		Marek Polacek		
 dataflow		Paolo Bonzini		
 dataflow		Seongbae Park		


Re: [PATCH] Improve alloca alignment

2017-09-11 Thread Wilco Dijkstra
Eric Botcazou wrote:
    
>> No, the stack never gets misaligned - my patch doesn't change that at all.
>
> Yes, it does.  

No. Look at the diffs, there is not a single change in alignment anywhere for 
all
of the alloca variants. If the alignment is incorrect after my patch, it is also
incorrect before my patch. This is the diff for pr78668.c on AArch64:

>diff pr78668.before pr78668.after
<   add x0, x0, 18
---
>   add x0, x0, 15
90c90
<   add x0, x0, 18
---
>   add x0, x0, 15
120c120
<   add x0, x0, 22
---
>   add x0, x0, 15
149c149
<   add x0, x0, 22
---
>   add x0, x0, 15
179c179
<   add x0, x0, 30
---
>   add x0, x0, 15
208c208
<   add x0, x0, 30
---
>   add x0, x0, 15
238c238
<   add x0, x0, 46
---
>   add x0, x0, 31
268c268
<   add x0, x0, 46
---
>   add x0, x0, 31


The mid-end always ensures that the stack is decremented by a value that is a
multiple of STACK_BOUNDARY. My change does not make any difference here,
but if SP is not aligned to STACK_BOUNDARY then it's obviously broken before
my patch. For example the relevant instructions for t2_a8 are:

add x0, x0, 15
and x0, x0, -16
sub sp, sp, x0
add x0, sp, 32

As you can see, it always rounds up and aligns to STACK_BOUNDARY
before adjusting SP. When computing the final alloca address (the last add 
above)
you must also keep that STACK_BOUNDARY alignment.

To conclude my change just avoids inserting redundant padding based on the
alignment promise that is made by the backend. The alignment itself is unchanged
and is already incorrect on Sparc before my change.

>> The issue is that Sparc backend doesn't correctly set STACK_BOUNDSARY and
>> neither aligns the outgoing args. Run my test which proves alloca was
>> broken before my patch.
>
> How could this have been broken for so long, realistically?  The SPARC back-
> end is parameterized according to the ABI and the documented interface 
> between 
> middle-end and back-end.

It clearly gets the ABI wrong as it sets STACK_BOUNDARY and then doesn't keep
the alignment promise it makes.

Wilco

Re: [PATCH] Add 'short_call' attribute for MIPS targets

2017-09-11 Thread Simon Atanasyan
Here is the updated patch with chnaged e-mail address and fixed
indentation issues:
-8<
Currently GCC supports 'long_call', 'far', and 'near' attributes. The
'long_call' and 'far' attributes are synonyms. This patch adds support
for the 'short_call' attribute as a synonym for `near` to make this list
complete, consistent with other targets, and compatible with attributes
supported by the Clang.

Tested on mipsel-linux-gnu.

2017-08-18  Simon Atanasyan  

gcc/
* config/mips/mips.c (mips_attribute_table): Add 'short_call'
attribute.
(mips_near_type_p): Add 'short_call' attribute as a synonym
for 'near'.
* doc/extend.texi (short_call): Document new function attribute.

gcc/testsuite

* gcc.target/mips/near-far-1.c: Add check for 'short_call'
attribute.
* gcc.target/mips/near-far-2.c: Likewise.
* gcc.target/mips/near-far-3.c: Likewise.
* gcc.target/mips/near-far-4.c: Likewise.

Index: gcc/config/mips/mips.c
===
--- gcc/config/mips/mips.c  (revision 251918)
+++ gcc/config/mips/mips.c  (working copy)
@@ -598,6 +598,7 @@ static const struct attribute_spec mips_attribute_
   /* { name, min_len, max_len, decl_req, type_req, fn_type_req, handler,
om_diagnostic } */
   { "long_call",   0, 0, false, true,  true,  NULL, false },
+  { "short_call",  0, 0, false, true,  true,  NULL, false },
   { "far",0, 0, false, true,  true,  NULL, false },
   { "near",0, 0, false, true,  true,  NULL, false },
   /* We would really like to treat "mips16" and "nomips16" as type
@@ -1171,13 +1172,14 @@ mflip_mips16_use_mips16_p (tree decl)
   return *slot;
 }
 
-/* Predicates to test for presence of "near" and "far"/"long_call"
+/* Predicates to test for presence of "near"/"short_call" and "far"/"long_call"
attributes on the given TYPE.  */
 
 static bool
 mips_near_type_p (const_tree type)
 {
-  return lookup_attribute ("near", TYPE_ATTRIBUTES (type)) != NULL;
+  return (lookup_attribute ("short_call", TYPE_ATTRIBUTES (type)) != NULL
+ || lookup_attribute ("near", TYPE_ATTRIBUTES (type)) != NULL);
 }
 
 static bool
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 251918)
+++ gcc/doc/extend.texi (working copy)
@@ -4528,10 +4528,12 @@ void __attribute__ ((interrupt("vector=hw3"))) v9
 @end smallexample
 
 @item long_call
+@itemx short_call
 @itemx near
 @itemx far
 @cindex indirect calls, MIPS
 @cindex @code{long_call} function attribute, MIPS
+@cindex @code{short_call} function attribute, MIPS
 @cindex @code{near} function attribute, MIPS
 @cindex @code{far} function attribute, MIPS
 These attributes specify how a particular function is called on MIPS@.
@@ -4539,8 +4541,9 @@ The attributes override the @option{-mlong-calls}
 command-line switch.  The @code{long_call} and @code{far} attributes are
 synonyms, and cause the compiler to always call
 the function by first loading its address into a register, and then using
-the contents of that register.  The @code{near} attribute has the opposite
-effect; it specifies that non-PIC calls should be made using the more
+the contents of that register.  The @code{short_call} and @code{near}
+attributes are synonyms, and have the opposite
+effect; they specify that non-PIC calls should be made using the more
 efficient @code{jal} instruction.
 
 @item mips16
Index: gcc/testsuite/gcc.target/mips/near-far-1.c
===
--- gcc/testsuite/gcc.target/mips/near-far-1.c  (revision 251918)
+++ gcc/testsuite/gcc.target/mips/near-far-1.c  (working copy)
@@ -3,6 +3,7 @@
 
 extern int long_call_func () __attribute__((long_call));
 extern int far_func () __attribute__((far));
+extern int short_call_func () __attribute__((short_call));
 extern int near_func () __attribute__((near));
 extern int normal_func ();
 
@@ -10,6 +11,7 @@ int test ()
 {
   return (long_call_func ()
   + far_func ()
+  + short_call_func ()
   + near_func ()
   + normal_func ());
 }
@@ -16,5 +18,6 @@ int test ()
 
 /* { dg-final { scan-assembler-not "\tjal\tlong_call_func\n" } } */
 /* { dg-final { scan-assembler-not "\tjal\tfar_func\n" } } */
+/* { dg-final { scan-assembler "\t(jal(|s)|balc)\tshort_call_func\n" } } */
 /* { dg-final { scan-assembler "\t(jal(|s)|balc)\tnear_func\n" } } */
 /* { dg-final { scan-assembler-not "\tjal\tnormal_func\n" } } */
Index: gcc/testsuite/gcc.target/mips/near-far-2.c
===
--- gcc/testsuite/gcc.target/mips/near-far-2.c  (revision 251918)
+++ gcc/testsuite/gcc.target/mips/near-far-2.c  (working copy)
@@ -3,6 +3,7 @@
 
 extern int long_call_func () __attribute__((long_call));
 extern int far_func () __attribute__((far));
+extern int short_call_func () __at

[PING] [PATCH] Add a -Wcast-align=strict warning

2017-09-11 Thread Bernd Edlinger
Ping...


On 09/04/17 10:07, Bernd Edlinger wrote:
> Hi,
> 
> as you know we have a -Wcast-align warning which works only for
> STRICT_ALIGNMENT targets.  But occasionally it would be nice to be
> able to switch this warning on even for other targets.
> 
> Therefore I would like to add a strict version of this option
> which can be invoked with -Wcast-align=strict.  With the only
> difference that it does not depend on STRICT_ALIGNMENT.
> 
> I used the code from check_effective_target_non_strict_align
> in target-supports.exp for the first version of the test case,
> where we have this:
> 
> return [check_no_compiler_messages non_strict_align assembly {
>   char *y;
>   typedef char __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__))) c;
>   c *z;
>   void foo(void) { z = (c *) y; }
> } "-Wcast-align"]
> 
> ... and to my big surprise it did _not_ work for C++ as-is,
> because same_type_p considers differently aligned types identical,
> and therefore cp_build_c_cast tries the conversion first via a
> const_cast which succeeds, but did not emit the cast-align warning
> in this case.
> 
> As a work-around I had to check the alignment in build_const_cast_1
> as well.
> 
> 
> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> Is it OK for trunk?
> 
> 
> Thanks
> Bernd.
> 


RE: [PATCH] Add 'short_call' attribute for MIPS targets

2017-09-11 Thread Matthew Fortune
Simon Atanasyan  writes:
> Currently GCC supports 'long_call', 'far', and 'near' attributes. The
> 'long_call' and 'far' attributes are synonyms. This patch adds support
> for the 'short_call' attribute as a synonym for `near` to make this list
> complete, consistent with other targets, and compatible with attributes
> supported by the Clang.

Sorry for the slow reply. Thanks for keeping GCC and Clang in sync.

> Tested on mipsel-linux-gnu.
> 
> 2017-08-22  Simon Atanasyan  

As you do not have a personal copyright assignment on file please can you
resubmit using your @imgtec.com address and use that address for the
changelog. There are just a couple of indentation issues below as well.

> gcc/
> 
> * config/mips/mips.c (mips_attribute_table): Add 'short_call' attribute.
> (mips_near_type_p): Add 'short_call' attribute as a synonym for 'near'.
> * doc/extend.texi (short_call): Document new function attribute.
> 
> gcc/testsuite/
> 
> * gcc.target/mips/near-far-1.c: Add check for 'short_call' attribute.
> * gcc.target/mips/near-far-2.c: Likewise.
> * gcc.target/mips/near-far-3.c: Likewise.
> * gcc.target/mips/near-far-4.c: Likewise.

There should be one tab before the lines in each entry * ,
lines here should be wrapped at 74 cols.

> 
> Index: gcc/config/mips/mips.c
> ===
> --- gcc/config/mips/mips.c (revision 251219)
> +++ gcc/config/mips/mips.c (working copy)
> @@ -598,6 +598,7 @@ static const struct attribute_spec mips_attribute_
>/* { name, min_len, max_len, decl_req, type_req, fn_type_req,
> handler,
> om_diagnostic } */
>{ "long_call",   0, 0, false, true,  true,  NULL, false },
> +  { "short_call",  0, 0, false, true,  true,  NULL, false },
>{ "far",   0, 0, false, true,  true,  NULL, false },
>{ "near",0, 0, false, true,  true,  NULL, false },
>/* We would really like to treat "mips16" and "nomips16" as type
> @@ -1171,13 +1172,14 @@ mflip_mips16_use_mips16_p (tree decl)
>return *slot;
>  }
> 
> -/* Predicates to test for presence of "near" and "far"/"long_call"
> +/* Predicates to test for presence of "near"/"short_call" and
> "far"/"long_call"
> attributes on the given TYPE.  */
> 
>  static bool
>  mips_near_type_p (const_tree type)
>  {
> -  return lookup_attribute ("near", TYPE_ATTRIBUTES (type)) != NULL;
> +  return (lookup_attribute ("short_call", TYPE_ATTRIBUTES (type)) !=
> NULL
> +  || lookup_attribute ("near", TYPE_ATTRIBUTES (type)) != NULL);

The || here should be lined up under the 'l' of lookup_attribute above
which will be 1-tab 2-space to save you figuring out the indent rules
for GCC again. The space indents in the testcases below are fine as
they match the existing lines.

If you can repost with your @imgtec address then I'll approve that
to commit.

Thanks,
Matthew


[Ada] Another freezing issue on expression function in nested package

2017-09-11 Thread Arnaud Charlet
This patch totally disables the freezing of an expression function at the
point its body is analyzed, as well the freezing of all the types that are
not yet frozen, in order to support more cases where the profile contains
a type which depends on a private type that is declared in an open scope
and does not yet have a completion.

The following package must compile quietly:

package P is

   type Forward_Cursor is private;

   package Nested is

  type Cursor is access Forward_Cursor;

  type Rec is record
 C : Forward_Cursor;
  end record;

  function Element (R : Rec; Current : Cursor) return Cursor is (Current);

   end Nested;

private

   type Forward_Cursor is null record;

end P;

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-09-11  Eric Botcazou  

* freeze.adb (Has_Incomplete_Compoent): Delete.
(Freeze_Profile):
Do not inhibit the freezing of the profile of an expression
function here.
(Freeze_Subprogram): Do not re-create extra formals.
* sem_ch6.adb (Analyze_Expression_Function): Always
pre-analyze the expression if the function is not a completion.
(Analyze_Subprogram_Body_Helper): For the body generated
from an expression function that is not a completion, do
not freeze the profile and temporary mask the types declared
outside the expression that are not yet frozen.
* sem_res.adb (Rewrite_Renamed_Operator): Also bail out if invoked
during the pre-analysis of an expression function.

Index: freeze.adb
===
--- freeze.adb  (revision 251956)
+++ freeze.adb  (working copy)
@@ -3423,72 +3423,10 @@
   
 
   function Freeze_Profile (E : Entity_Id) return Boolean is
- function Has_Incomplete_Component (T : Entity_Id) return Boolean;
- --  If a type includes a private component from an enclosing scope it
- --  cannot be frozen yet. This can happen in a package nested within
- --  another, when freezing an expression function whose profile
- --  depends on a type in some outer scope. Those types will be frozen
- --  at a later time in the enclosing unit.
-
- --
- -- Has_Incomplete_Component --
- --
-
- function Has_Incomplete_Component (T : Entity_Id) return Boolean is
-Comp : Entity_Id;
-Comp_Typ : Entity_Id;
-
- begin
-if Nkind (N) /= N_Subprogram_Body
-  or else not Was_Expression_Function (N)
-then
-   return False;
-
-elsif In_Instance then
-   return False;
-
-elsif Is_Record_Type (T) then
-   Comp := First_Entity (T);
-
-   while Present (Comp) loop
-  Comp_Typ := Etype (Comp);
-
-  if Ekind_In (Comp, E_Component, E_Discriminant)
-and then Is_Private_Type (Comp_Typ)
-and then No (Full_View (Comp_Typ))
-and then In_Open_Scopes (Scope (Comp_Typ))
-and then Scope (Comp_Typ) /= Current_Scope
-  then
- return True;
-  end if;
-
-  Comp := Next_Entity (Comp);
-   end loop;
-
-   return False;
-
-elsif Is_Array_Type (T) then
-   Comp_Typ := Component_Type (T);
-
-   return
- Is_Private_Type (Comp_Typ)
-   and then No (Full_View (Comp_Typ))
-   and then In_Open_Scopes (Scope (Comp_Typ))
-   and then Scope (Comp_Typ) /= Current_Scope;
-
-else
-   return False;
-end if;
- end Has_Incomplete_Component;
-
- --  Local variables
-
  F_Type: Entity_Id;
  R_Type: Entity_Id;
  Warn_Node : Node_Id;
 
-  --  Start of processing for Freeze_Profile
-
   begin
  --  Loop through formals
 
@@ -3508,12 +3446,6 @@
Set_Etype (Formal, F_Type);
 end if;
 
-if Has_Incomplete_Component (F_Type) then
-   Set_Is_Frozen (E, False);
-   Result := No_List;
-   return False;
-end if;
-
 if not From_Limited_With (F_Type) then
Freeze_And_Append (F_Type, N, Result);
 end if;
@@ -8302,7 +8234,9 @@
   --  that we know the convention.
 
   if not Has_Foreign_Convention (E) then
- Create_Extra_Formals (E);
+ if No (Extra_Formals (E)) then
+Create_Extra_Formals (E);
+ end if;
  Set_Mechanisms (E);
 
  --  If this is convention Ada and a Valued_Procedure, that's odd
Index: sem_ch6.adb
===
--- sem_c

Re: [PATCH]: PR target/80204 (Darwin macosx-version-min problem)

2017-09-11 Thread Iain Sandoe

> On 4 Sep 2017, at 21:48, Jakub Jelinek  wrote:
> 
> On Mon, Sep 04, 2017 at 08:47:07PM +0100, Simon Wright wrote:
>> On 1 Sep 2017, at 23:05, Simon Wright  wrote:
>>> 
>>> 2017-09-01 Simon Wright 
>>> 
>>> PR target/80204
>>> * config/darwin-driver.c (darwin_find_version_from_kernel): eliminate 
>>> calculation of the
>>>   minor version, always output as 0.
>> 
>> Like this?
>> 
>> Do you need the patch to be resubmitted as well?
>> 
>> gcc/Changelog
>> 
>> 2017-09-01 Simon Wright 
>> 
>>  PR target/80204
>>  * config/darwin-driver.c (darwin_find_version_from_kernel):
>>  Eliminate calculation of the minor version, always output as 0.
> 
> Better
> 
> 2017-09-01 Simon Wright 
> 
>   PR target/80204
>   * config/darwin-driver.c (darwin_find_version_from_kernel): Eliminate
>   calculation of the minor version, always output as 0.
> 
>   Jakub

Very sorry that no-one from the Darwin folks has reviewed this to date, and 
thanks for the patch (and to Jakub and Jeff for taking care of it).

In general, I would prefer that a change like this would be made to apply to 
only versions of Darwin >= to the ones affected (so that the behaviour for 
earlier versions is unchanged).  As I read your patch, it alters things for all 
versions.

Having said that, the risk of bad effects is fairly low, and we can deal with 
them if they occur, so it’s a reasonable patch (as has been OK’d).

Please CC me directly on Darwin patches; in case I miss them in other list 
traffic.   Whilst I cannot approve them - at least I will try to review and 
make suggestions.

Iain Sandoe
CodeSourcery / Mentor Embedded / Siemens



Re: std::forward_list optim for always equal allocator

2017-09-11 Thread Jonathan Wakely

On 11/09/17 07:44 +0200, Daniel Krügler wrote:

2017-09-11 7:12 GMT+02:00 François Dumont :

When user declare a container iterator like that:

std::forward_list::iterator it;

There is no reason to initialize it with a null node pointer. It is just an
uninitialized iterator which is invalid to use except to initialize it.


While that is correct, for every forward iterator (and
std::forward_list::iterator meets these requirements), it is also
required that a value-initialized iterator can be compared against
other initialized iterators, so this reduces the amount of freedom to
define a default constructor for such iterators even when used to
default-initialize. This is not meant as a showstopper argument, since
I have not fully understood of what you are planning, but just a
reminder.


Right, which means that 


std::forward_list::iterator it = {};

must initialize the node pointer to nullptr. If we remove the
initialization of _Fwd_list_iterator::_M_node from the default
constructor then it would be left uninitialized.

But I'm confused, François was talking about removing the
initialization of _Fwd_list_node_base::_M_next, what has that got to
do with forward_list::iterator? Thee is no node-base in the
iterator.

So I'm still wondering why the initialization of _M_next should be
removed.




Re: [patch] Fix wrong code with small structure return on PowerPC

2017-09-11 Thread Richard Biener
On September 11, 2017 12:26:09 PM GMT+02:00, Eric Botcazou 
 wrote:
>Hi,
>
>this is a bug originally reported in Ada on 32-bit PowerPC with the
>SVR4 ABI 
>(hence not Linux) and reproducible in C with the attached testcase at
>-O1.
>
>The problem lies in function 'foo':
>
>  struct S ret;
>  char r, s, c1, c2;
>  char *p = &r;
>
>  s = bar (&p);
>  if (s)
>c2 = *p;
>  c1 = 0;
>
>  ret.c1 = c1;
>  ret.c2 = c2;
>  return ret;
>
>Since the call to bar returns 0, c2 is uninitialized at run time (but
>this 
>doesn't matter for correctness since its value is never read).  Now
>both c1 
>and c2 are represented at the RTL level by unsigned promoted subregs,
>i.e. 
>SUBREGs verifying SUBREG_PROMOTED_VAR_P and SUBREG_PROMOTED_UNSIGNED_P
>
>As a consequence, when store_fixed_bit_field_1 stores the 8-bit values
>into 
>the 'ret' object, it considers that the underlying 32-bit objects have
>only 8 
>bits set and the rest cleared so it doesn't mask the other 24 bits. 
>That's 
>OK for c1 but not for c2, since c2 is uninitialized so the bits are
>random.
>
>This appears to be an inherent weakness of the promoted subregs
>mechanism, but 
>I don't think that we want to go for an upheaval at this point.  So the
>patch 
>addresses the problem in an ad-hoc manner directly in
>store_fixed_bit_field_1 
>and yields the expected 8-bit insertion:
>
>@@ -26,7 +26,7 @@
>lwz 9,12(1)
>lbz 31,0(9)
> .L3:
>-   slwi 3,31,16
>+   rlwinm 3,31,16,8,15
>lwz 0,36(1)
>mtlr 0
>lwz 31,28(1)
>
>Tested on x86-64/Linux and PowerPC64/Linux, OK for the mainline?

I think the issue is that we set SUBREG_PROMOTED_* on something that is 
possibly not so (aka uninitialized in this case). We may only set it if either 
the ABI or a previous operation forced it to. Maybe this is also the reason why 
we need this zero init pass in some cases (though that isn't a full solution 
either). 

Richard. 

>
>2017-09-11  Eric Botcazou  
>
>   * expmed.c (store_fixed_bit_field_1): Force the masking if the value
>   is an unsigned promoted SUBREG of a sufficiently large object.
>
>
>2017-09-11  Eric Botcazou  
>
>   * gcc.c-torture/execute/20170911-1.c: New test.



[testsuite, i386] Fix gcc.target/i386/pr81736-[34].c on 32-bit Solaris/x86 (PR target/81736)

2017-09-11 Thread Rainer Orth
The new gcc.target/i386/pr81736-[34].c tests currently FAIL on 32-bit
Solaris x86.  Fixed as suggested by HJ in the PR.  Tested with the
appropriate runtest invocation on i386-pc-solaris2.11,
x86_64-pc-linux-gnu, and x86_64-apple-darwin11.  Assembler output on
Linux and Darwin is unchanged.

Ok for mainline?

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


2017-09-11  Rainer Orth  

PR target/81736
* gcc.target/i386/pr81736-3.c: Add -mno-omit-leaf-frame-pointer.
* gcc.target/i386/pr81736-4.c: Likewise.

# HG changeset patch
# Parent  79870b011f66569412e6da49853b5bd7ee3e7b25
Fix gcc.target/i386/pr81736-[34].c on 32-bit Solaris/x86 (PR target/81736)

diff --git a/gcc/testsuite/gcc.target/i386/pr81736-3.c b/gcc/testsuite/gcc.target/i386/pr81736-3.c
--- a/gcc/testsuite/gcc.target/i386/pr81736-3.c
+++ b/gcc/testsuite/gcc.target/i386/pr81736-3.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -fno-omit-frame-pointer" } */
+/* { dg-options "-O2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer" } */
 
 void
 foo (void)
diff --git a/gcc/testsuite/gcc.target/i386/pr81736-4.c b/gcc/testsuite/gcc.target/i386/pr81736-4.c
--- a/gcc/testsuite/gcc.target/i386/pr81736-4.c
+++ b/gcc/testsuite/gcc.target/i386/pr81736-4.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -fno-omit-frame-pointer" } */
+/* { dg-options "-O2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer" } */
 
 int
 foo (int i1, int i2, int i3, int i4, int i5, int i6, int i7)


Re: [patch] Fix wrong code with small structure return on PowerPC

2017-09-11 Thread Eric Botcazou
> this is a bug originally reported in Ada on 32-bit PowerPC with the SVR4 ABI
> (hence not Linux) and reproducible in C with the attached testcase at -O1.

With the right C testcase this time...

-- 
Eric Botcazoustruct S { char c1, c2, c3, c4; } __attribute__((aligned(4)));

static char bar (char **p) __attribute__((noclone, noinline));
static struct S foo (void) __attribute__((noclone, noinline));

int i;

static char
bar (char **p)
{
  i = 1;
  return 0;
}

static struct S
foo (void)
{
  struct S ret;
  char r, s, c1, c2;
  char *p = &r;

  s = bar (&p);
  if (s)
c2 = *p;
  c1 = 0;

  ret.c1 = c1;
  ret.c2 = c2;
  return ret;
}

int main (void)
{
  struct S s = foo ();
  if (s.c1 != 0)
__builtin_abort ();
  return 0;
}


[patch] Fix wrong code with small structure return on PowerPC

2017-09-11 Thread Eric Botcazou
Hi,

this is a bug originally reported in Ada on 32-bit PowerPC with the SVR4 ABI 
(hence not Linux) and reproducible in C with the attached testcase at -O1.

The problem lies in function 'foo':

  struct S ret;
  char r, s, c1, c2;
  char *p = &r;

  s = bar (&p);
  if (s)
c2 = *p;
  c1 = 0;

  ret.c1 = c1;
  ret.c2 = c2;
  return ret;

Since the call to bar returns 0, c2 is uninitialized at run time (but this 
doesn't matter for correctness since its value is never read).  Now both c1 
and c2 are represented at the RTL level by unsigned promoted subregs, i.e. 
SUBREGs verifying SUBREG_PROMOTED_VAR_P and SUBREG_PROMOTED_UNSIGNED_P

As a consequence, when store_fixed_bit_field_1 stores the 8-bit values into 
the 'ret' object, it considers that the underlying 32-bit objects have only 8 
bits set and the rest cleared so it doesn't mask the other 24 bits.  That's 
OK for c1 but not for c2, since c2 is uninitialized so the bits are random.

This appears to be an inherent weakness of the promoted subregs mechanism, but 
I don't think that we want to go for an upheaval at this point.  So the patch 
addresses the problem in an ad-hoc manner directly in store_fixed_bit_field_1 
and yields the expected 8-bit insertion:

@@ -26,7 +26,7 @@
lwz 9,12(1)
lbz 31,0(9)
 .L3:
-   slwi 3,31,16
+   rlwinm 3,31,16,8,15
lwz 0,36(1)
mtlr 0
lwz 31,28(1)

Tested on x86-64/Linux and PowerPC64/Linux, OK for the mainline?


2017-09-11  Eric Botcazou  

* expmed.c (store_fixed_bit_field_1): Force the masking if the value
is an unsigned promoted SUBREG of a sufficiently large object.


2017-09-11  Eric Botcazou  

* gcc.c-torture/execute/20170911-1.c: New test.

-- 
Eric BotcazouIndex: expmed.c
===
--- expmed.c	(revision 251906)
+++ expmed.c	(working copy)
@@ -1213,13 +1213,25 @@ store_fixed_bit_field_1 (rtx op0, scalar
 }
   else
 {
-  int must_and = (GET_MODE_BITSIZE (value_mode) != bitsize
-		  && bitnum + bitsize != GET_MODE_BITSIZE (mode));
+  /* Compute whether we must mask the value in order to make sure that the
+	 bits outside the bitfield are all cleared.  Note that, even though the
+	 value has the right size, if it has a mode different from MODE, then
+	 converting it to MODE may unmask uninitialized bits in the case where
+	 it is an unsigned promoted SUBREG of a sufficiently large object.  */
+  const bool must_mask
+	= (GET_MODE_BITSIZE (value_mode) != bitsize
+	   || (value_mode != mode
+	   && GET_CODE (value) == SUBREG
+	   && SUBREG_PROMOTED_VAR_P (value)
+	   && SUBREG_PROMOTED_UNSIGNED_P (value)
+	   && GET_MODE_SIZE (GET_MODE (SUBREG_REG (value)))
+		  >= GET_MODE_SIZE (mode)))
+	  && bitnum + bitsize != GET_MODE_BITSIZE (mode);
 
   if (value_mode != mode)
 	value = convert_to_mode (mode, value, 1);
 
-  if (must_and)
+  if (must_mask)
 	value = expand_binop (mode, and_optab, value,
 			  mask_rtx (mode, 0, bitsize, 0),
 			  NULL_RTX, 1, OPTAB_LIB_WIDEN);
unsigned long foo (int x)
{
  return x > 0 ? (unsigned long) x : 0;
}

unsigned long bar (int x, int y)
{
  return x > y ? (unsigned long) x : (unsigned long) y;
}


[Ada] Rename runtime variant files under libgnat

2017-09-11 Thread Arnaud Charlet
Same renaming as just done for libgnarl, under libgnat this time.

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-09-11  Jerome Lambourg  

* libgnat: Rename ?-[a-z]*-* into ?-[a-z]*__*
* gcc-interface/Makefile.in, gcc-interface/Make-lang.in: Take this
renaming into account.

Index: gcc-interface/Makefile.in
===
--- gcc-interface/Makefile.in   (revision 251966)
+++ gcc-interface/Makefile.in   (working copy)
@@ -359,7 +359,7 @@
 s-inmaop.adb

Re: [HSA, PR 82119] Make HSA resilient to side-effects of split_edge

2017-09-11 Thread Richard Biener
On September 11, 2017 11:03:39 AM GMT+02:00, Martin Jambor  
wrote:
>Hi,
>
>in r251264 the code of split_edge was changed not to reallocate PHI
>vectors, but it reorders them along with the order of incoming edges
>to the BB.  There are two places in the HSA BE where we call
>split_edge while iterating over PHI node arguments and those broke,
>resulting in a number of libgomp testsuite failures.

Ah, interesting. I'll try to change split_edge to not reorder PHI arguments. 

Richard. 

>Fixed thusly.  I have tested the patch on HSA capable APU and also did
>full bootstrap and testing, I will commit in a few moments.
>
>Martin
>
>
>2017-09-11  Martin Jambor  
>
>   PR hsa/82119
>   * hsa-gen.c (gen_hsa_phi_from_gimple_phi): Process ADDR_EXPRs in
>   arguments in advance.
>   * hsa-regalloc.c (naive_process_phi): New parameter predecessors,
>   use it to find predecessor edges.
>   (naive_outof_ssa): Collect vector of predecessors.
>---
>gcc/hsa-gen.c  | 51
>++-
> gcc/hsa-regalloc.c | 14 +++---
> 2 files changed, 49 insertions(+), 16 deletions(-)
>
>diff --git a/gcc/hsa-gen.c b/gcc/hsa-gen.c
>index bd227626e83..6e054c0ce82 100644
>--- a/gcc/hsa-gen.c
>+++ b/gcc/hsa-gen.c
>@@ -5657,8 +5657,37 @@ gen_hsa_phi_from_gimple_phi (gimple *phi_stmt,
>hsa_bb *hbb)
>   hphi = new hsa_insn_phi (count, dest);
>   hphi->m_bb = hbb->m_bb;
> 
>-  tree lhs = gimple_phi_result (phi_stmt);
>+  auto_vec  aexprs;
>+  auto_vec  aregs;
>+
>+  /* Calling split_edge when processing a PHI node messes up with the
>order of
>+ gimple phi node arguments (it moves the one associated with the
>edge to
>+ the end).  We need to keep the order of edges and arguments of
>HSA phi
>+ node arguments consistent, so we do all required splitting as the
>first
>+ step, and in reverse order as to not be affected by the
>re-orderings.  */
>+  for (unsigned j = count; j != 0; j--)
>+{
>+  unsigned i = j - 1;
>+  tree op = gimple_phi_arg_def (phi_stmt, i);
>+  if (TREE_CODE (op) != ADDR_EXPR)
>+  continue;
> 
>+  edge e = gimple_phi_arg_edge (as_a  (phi_stmt), i);
>+  hsa_bb *hbb_src = hsa_init_new_bb (split_edge (e));
>+  hsa_op_address *addr = gen_hsa_addr (TREE_OPERAND (op, 0),
>+ hbb_src);
>+
>+  hsa_op_reg *dest
>+  = new hsa_op_reg (hsa_get_segment_addr_type (BRIG_SEGMENT_FLAT));
>+  hsa_insn_basic *insn
>+  = new hsa_insn_basic (2, BRIG_OPCODE_LDA, BRIG_TYPE_U64,
>+dest, addr);
>+  hbb_src->append_insn (insn);
>+  aexprs.safe_push (op);
>+  aregs.safe_push (dest);
>+}
>+
>+  tree lhs = gimple_phi_result (phi_stmt);
>   for (unsigned i = 0; i < count; i++)
> {
>   tree op = gimple_phi_arg_def (phi_stmt, i);
>@@ -5684,18 +5713,14 @@ gen_hsa_phi_from_gimple_phi (gimple *phi_stmt,
>hsa_bb *hbb)
>   }
> else if (TREE_CODE (op) == ADDR_EXPR)
>   {
>-edge e = gimple_phi_arg_edge (as_a  (phi_stmt), i);
>-hsa_bb *hbb_src = hsa_init_new_bb (split_edge (e));
>-hsa_op_address *addr = gen_hsa_addr (TREE_OPERAND (op, 0),
>- hbb_src);
>-
>-hsa_op_reg *dest
>-  = new hsa_op_reg (hsa_get_segment_addr_type 
>(BRIG_SEGMENT_FLAT));
>-hsa_insn_basic *insn
>-  = new hsa_insn_basic (2, BRIG_OPCODE_LDA, BRIG_TYPE_U64,
>-dest, addr);
>-hbb_src->append_insn (insn);
>-
>+hsa_op_reg *dest = NULL;
>+for (unsigned a_idx = 0; a_idx < aexprs.length (); a_idx++)
>+  if (aexprs[a_idx] == op)
>+{
>+  dest = aregs[a_idx];
>+  break;
>+}
>+gcc_assert (dest);
> hphi->set_op (i, dest);
>   }
> else
>diff --git a/gcc/hsa-regalloc.c b/gcc/hsa-regalloc.c
>index 2a17254c3b2..7fc3a8afa3d 100644
>--- a/gcc/hsa-regalloc.c
>+++ b/gcc/hsa-regalloc.c
>@@ -42,7 +42,7 @@ along with GCC; see the file COPYING3.  If not see
>/* Process a PHI node PHI of basic block BB as a part of naive
>out-f-ssa.  */
> 
> static void
>-naive_process_phi (hsa_insn_phi *phi)
>+naive_process_phi (hsa_insn_phi *phi, const vec &predecessors)
> {
>   unsigned count = phi->operand_count ();
>   for (unsigned i = 0; i < count; i++)
>@@ -55,7 +55,7 @@ naive_process_phi (hsa_insn_phi *phi)
>   if (!op)
>   break;
> 
>-  e = EDGE_PRED (phi->m_bb, i);
>+  e = predecessors[i];
>   if (single_succ_p (e->src))
>   hbb = hsa_bb_for_bb (e->src);
>   else
>@@ -89,10 +89,18 @@ naive_outof_ssa (void)
> hsa_bb *hbb = hsa_bb_for_bb (bb);
> hsa_insn_phi *phi;
> 
>+/* naive_process_phi can call split_edge on an incoming edge which
>order if
>+   the incoming edges to the basic block and thus make it
>inconsistent with
>+  

Re: [PATCH][PR sanitizer/77631] Support separate debug info in libbacktrace

2017-09-11 Thread Denis Khalikov

Thanks for answer.
I understood all points which you mentioned, but can't
find last one
> It seems to work
> out the file name a second time, even though the file name must
> already be known.

Can you please show me where I've missed that, if you have a time for that.

Anyway, your patch works for me.
Thanks.

On 09/11/2017 12:11 AM, Ian Lance Taylor wrote:

On Sat, Jul 29, 2017 at 1:42 PM, Denis Khalikov
 wrote:


Hello Ian,
thanks for review.
I've updated the patch, can you please take a look.


Apologies again for the length of time it took to reply.  I've had a
hard time understanding the patch.  It's quite likely that I don't
understand how it works, but it seems to pass the same file descriptor
to process_elf_header twice.  It seems to look for debug files with
the buildid in places where they will not be found.  It seems to work
out the file name a second time, even though the file name must
already be known.  I eventually just wrote my own implementation.

Could you try this patch and see if it works for your cases?  The
patch is against current mainline.  Thanks.

Ian



[Ada] Rename runtime variant files under libgnarl

2017-09-11 Thread Arnaud Charlet
This is the next step in the source file and directory reorg in GNAT sources.
This time, we rename all files of the form ?-[a-z]*-* into ?-[a-z]*_*,
for example s-tpopsp-posix.adb becomes s-tpopsp__posix.adb. This is done
so that it's easier to see which files are platform specific variants (such
files will now always contain a double underscore).

This change is for the libgnarl directory, the next change will do the same
for the libgnat directory.

As with the previous changes, there's a small chance that some target got
forgotten in Makefile.in, but hopefully not! If this is the case, fixing it
is purely mechanical and is preapproved.

The diff is huge and mechanical, I'm only including the part in
gcc-interface/Makefile.in.

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-09-11  Jerome Lambourg  

* libgnarl: Rename ?-[a-z]*-* into ?-[a-z]*__*
* gcc-interface/Makefile.in: Take this renaming into account.

Index: gcc-interface/Makefile.in
===
--- gcc-interface/Makefile.in   (revision 251956)
+++ gcc-interface/Makefile.in   (working copy)
@@ -355,13 +355,13 @@
 # Non-tasking case:
 
 LIBGNAT_TARGET_PAIRS = \
-a-intnam.ads

[HSA, PR 82119] Make HSA resilient to side-effects of split_edge

2017-09-11 Thread Martin Jambor
Hi,

in r251264 the code of split_edge was changed not to reallocate PHI
vectors, but it reorders them along with the order of incoming edges
to the BB.  There are two places in the HSA BE where we call
split_edge while iterating over PHI node arguments and those broke,
resulting in a number of libgomp testsuite failures.

Fixed thusly.  I have tested the patch on HSA capable APU and also did
full bootstrap and testing, I will commit in a few moments.

Martin


2017-09-11  Martin Jambor  

PR hsa/82119
* hsa-gen.c (gen_hsa_phi_from_gimple_phi): Process ADDR_EXPRs in
arguments in advance.
* hsa-regalloc.c (naive_process_phi): New parameter predecessors,
use it to find predecessor edges.
(naive_outof_ssa): Collect vector of predecessors.
---
 gcc/hsa-gen.c  | 51 ++-
 gcc/hsa-regalloc.c | 14 +++---
 2 files changed, 49 insertions(+), 16 deletions(-)

diff --git a/gcc/hsa-gen.c b/gcc/hsa-gen.c
index bd227626e83..6e054c0ce82 100644
--- a/gcc/hsa-gen.c
+++ b/gcc/hsa-gen.c
@@ -5657,8 +5657,37 @@ gen_hsa_phi_from_gimple_phi (gimple *phi_stmt, hsa_bb 
*hbb)
   hphi = new hsa_insn_phi (count, dest);
   hphi->m_bb = hbb->m_bb;
 
-  tree lhs = gimple_phi_result (phi_stmt);
+  auto_vec  aexprs;
+  auto_vec  aregs;
+
+  /* Calling split_edge when processing a PHI node messes up with the order of
+ gimple phi node arguments (it moves the one associated with the edge to
+ the end).  We need to keep the order of edges and arguments of HSA phi
+ node arguments consistent, so we do all required splitting as the first
+ step, and in reverse order as to not be affected by the re-orderings.  */
+  for (unsigned j = count; j != 0; j--)
+{
+  unsigned i = j - 1;
+  tree op = gimple_phi_arg_def (phi_stmt, i);
+  if (TREE_CODE (op) != ADDR_EXPR)
+   continue;
 
+  edge e = gimple_phi_arg_edge (as_a  (phi_stmt), i);
+  hsa_bb *hbb_src = hsa_init_new_bb (split_edge (e));
+  hsa_op_address *addr = gen_hsa_addr (TREE_OPERAND (op, 0),
+  hbb_src);
+
+  hsa_op_reg *dest
+   = new hsa_op_reg (hsa_get_segment_addr_type (BRIG_SEGMENT_FLAT));
+  hsa_insn_basic *insn
+   = new hsa_insn_basic (2, BRIG_OPCODE_LDA, BRIG_TYPE_U64,
+ dest, addr);
+  hbb_src->append_insn (insn);
+  aexprs.safe_push (op);
+  aregs.safe_push (dest);
+}
+
+  tree lhs = gimple_phi_result (phi_stmt);
   for (unsigned i = 0; i < count; i++)
 {
   tree op = gimple_phi_arg_def (phi_stmt, i);
@@ -5684,18 +5713,14 @@ gen_hsa_phi_from_gimple_phi (gimple *phi_stmt, hsa_bb 
*hbb)
}
  else if (TREE_CODE (op) == ADDR_EXPR)
{
- edge e = gimple_phi_arg_edge (as_a  (phi_stmt), i);
- hsa_bb *hbb_src = hsa_init_new_bb (split_edge (e));
- hsa_op_address *addr = gen_hsa_addr (TREE_OPERAND (op, 0),
-  hbb_src);
-
- hsa_op_reg *dest
-   = new hsa_op_reg (hsa_get_segment_addr_type 
(BRIG_SEGMENT_FLAT));
- hsa_insn_basic *insn
-   = new hsa_insn_basic (2, BRIG_OPCODE_LDA, BRIG_TYPE_U64,
- dest, addr);
- hbb_src->append_insn (insn);
-
+ hsa_op_reg *dest = NULL;
+ for (unsigned a_idx = 0; a_idx < aexprs.length (); a_idx++)
+   if (aexprs[a_idx] == op)
+ {
+   dest = aregs[a_idx];
+   break;
+ }
+ gcc_assert (dest);
  hphi->set_op (i, dest);
}
  else
diff --git a/gcc/hsa-regalloc.c b/gcc/hsa-regalloc.c
index 2a17254c3b2..7fc3a8afa3d 100644
--- a/gcc/hsa-regalloc.c
+++ b/gcc/hsa-regalloc.c
@@ -42,7 +42,7 @@ along with GCC; see the file COPYING3.  If not see
 /* Process a PHI node PHI of basic block BB as a part of naive out-f-ssa.  */
 
 static void
-naive_process_phi (hsa_insn_phi *phi)
+naive_process_phi (hsa_insn_phi *phi, const vec &predecessors)
 {
   unsigned count = phi->operand_count ();
   for (unsigned i = 0; i < count; i++)
@@ -55,7 +55,7 @@ naive_process_phi (hsa_insn_phi *phi)
   if (!op)
break;
 
-  e = EDGE_PRED (phi->m_bb, i);
+  e = predecessors[i];
   if (single_succ_p (e->src))
hbb = hsa_bb_for_bb (e->src);
   else
@@ -89,10 +89,18 @@ naive_outof_ssa (void)
 hsa_bb *hbb = hsa_bb_for_bb (bb);
 hsa_insn_phi *phi;
 
+/* naive_process_phi can call split_edge on an incoming edge which order if
+   the incoming edges to the basic block and thus make it inconsistent with
+   the ordering of PHI arguments, so we collect them in advance.  */
+auto_vec predecessors;
+unsigned pred_count = EDGE_COUNT (bb->preds);
+for (unsigned i = 0; i < pred_count; i++)
+  predecessors.safe_push (EDGE_PRED (bb, i));
+

Re: backwards threader cleanups

2017-09-11 Thread Aldy Hernandez
PING.

An this time with an actual patch ;-).
Aldy

On Sat, Sep 2, 2017 at 1:43 PM, Aldy Hernandez  wrote:
> On Fri, Sep 1, 2017 at 6:11 PM, Jeff Law  wrote:
>> On 09/01/2017 02:18 PM, Aldy Hernandez wrote:
>>> Hi.
>>>
>>> Attached are misc cleanups to tree-ssa-threadbackwards.c and friends.
>>> The main gist of the patch is making the path vectors live in the
>>> heap, not GC.  But I also cleaned up some comments to reflect reality,
>>> and renamed VAR_BB which could use a more meaningful name.  Finally, I
>>> abstracted some common code to
>>> register_jump_thread_path_if_profitable() in preparation for some
>>> upcoming work by me :).
>>>
>>> Tested on x86-64 Linux.
>> It looks like you dropped a level of indirection for path in
>> profitable_jump_thread_path and perhaps others that push blocks onto the
>> path?   Does your change from having the vectors in the GC space to the
>> heap also change them from embeddable vectors to a space efficient
>> vector?  It has to for this change to be safe.
>
> Part of my initial motivation was eliminating the double indirection
> as well as removing the out-of-line calls to vec_alloc() and
> vec_whatever_push().
>
> And yes, the default plain vector<> uses the heap:
>
> template  typename A = va_heap,
>  typename L = typename A::default_layout>
> struct GTY((user)) vec
> {
> };
>
> ...and va_heap defaults to the space efficient vector:
>
> struct va_heap
> {
>   typedef vl_ptr default_layout;
> ...
> }
>
>>
>> See the discussion in vec.h
>>
>> I don't recall any inherent reason we use the embedded vector layout.
>> It's the default which is probably why it's used here more than anything.
>
> Just a wild guess, but this may be why:
>
>FIXME - Ideally, they would all be vl_ptr to encourage using regular
>instances for vectors, but the existing GTY machinery is limited
>in that it can only deal with GC objects that are pointers
>themselves.
>
> and:
>
>   /* Use vl_embed as the default layout for GC vectors.  Due to GTY
>  limitations, GC vectors must always be pointers, so it is more
>  efficient to use a pointer to the vl_embed layout, rather than
>  using a pointer to a pointer as would be the case with vl_ptr.  */
>
>>
>> Otherwise the change looks good.  I think you just to make sure you're
>> not using the embedded layout.  Which I think is just a different type
>> when  you declare the vec.
>
> I have made the vectors auto_vec as Trevor suggested.  As auto_vec is
> just an inherited plain vec<> with some magic allocation sauce, they
> can be passed around interchangeably.
>
> I also changed the hash sets so they live on the stack as opposed to
> allocating memory dynamically, at Trevor's request as well.
>
> Bootstraps.  OK pending another round of tests?
>
> Aldy


curr
Description: Binary data


Re: [AArch64], patch] PR71727 fix -mstrict-align

2017-09-11 Thread Andrew Pinski
On Tue, Jul 18, 2017 at 5:50 AM, Christophe Lyon
 wrote:
> Hello,
>
> I've received a complaint that GCC for AArch64 would generate
> vectorized code relying on unaligned memory accesses even when using
> -mstrict-align. This is a problem for code where such accesses lead to
> memory faults.
>
> A previous patch (r24) introduced
> aarch64_builtin_support_vector_misalignment, which rejects such
> accesses when the element size is 64 bits, and accept them otherwise,
> which I think it shouldn't. The testcase added at that time only used
> 64 bits elements, and therefore didn't fully test the patch.
>
> The report I received is about vectorized accesses to an array of
> unsigned chars, whose start address is not aligned on a 128 bits
> boundary.
>
> The attached patch fixes the problem by making
> aarch64_builtin_support_vector_misalignment always return false when
> the misalignment is not known at compile time.
>
> I've also added a testcase, which tries to check if the array start
> address alignment is checked (using %16, and-ing with #15), so that
> loop peeling is performed *before* using vectorized accesses. Without
> the patch, vectorized accesses are used at the beginning of the array,
> and byte accesses are used for the remainder at the end, and there is
> not such 'and wX,wX,15'.
>
> BTW, I'm not sure about the same hook for arm... it seems to me it has
> a similar problem.
>
> OK?

I would keep part of the comment:
-  /* Misalignment factor is unknown at compile time but we know
- it's word aligned.  */

Something like:
/* Misalignment factor is unknown at compile time. */

Otherwise it is not obvious what -1 means.

Other than I think this patch is good (I cannot approve though).

Thanks,
Andrew

>
> Thanks,
>
> Christophe


Re: [AArch64], patch] PR71727 fix -mstrict-align

2017-09-11 Thread Christophe Lyon
ping^3 ?

https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01063.html

On 31 August 2017 at 11:22, Christophe Lyon  wrote:
> ping^2 ?
>
>
> On 21 August 2017 at 15:04, Christophe Lyon  
> wrote:
>> ping ?
>> https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01063.html
>>
>> Christophe
>>
>>
>> On 18 July 2017 at 14:50, Christophe Lyon  wrote:
>>> Hello,
>>>
>>> I've received a complaint that GCC for AArch64 would generate
>>> vectorized code relying on unaligned memory accesses even when using
>>> -mstrict-align. This is a problem for code where such accesses lead to
>>> memory faults.
>>>
>>> A previous patch (r24) introduced
>>> aarch64_builtin_support_vector_misalignment, which rejects such
>>> accesses when the element size is 64 bits, and accept them otherwise,
>>> which I think it shouldn't. The testcase added at that time only used
>>> 64 bits elements, and therefore didn't fully test the patch.
>>>
>>> The report I received is about vectorized accesses to an array of
>>> unsigned chars, whose start address is not aligned on a 128 bits
>>> boundary.
>>>
>>> The attached patch fixes the problem by making
>>> aarch64_builtin_support_vector_misalignment always return false when
>>> the misalignment is not known at compile time.
>>>
>>> I've also added a testcase, which tries to check if the array start
>>> address alignment is checked (using %16, and-ing with #15), so that
>>> loop peeling is performed *before* using vectorized accesses. Without
>>> the patch, vectorized accesses are used at the beginning of the array,
>>> and byte accesses are used for the remainder at the end, and there is
>>> not such 'and wX,wX,15'.
>>>
>>> BTW, I'm not sure about the same hook for arm... it seems to me it has
>>> a similar problem.
>>>
>>> OK?
>>>
>>> Thanks,
>>>
>>> Christophe