Substitute all "the the" with "the"

[Дилян Палаузов]

… by applying

sed -i "s/the the/the/" `git grep -l "the the"`

[PATCH] PR88777, Out-of-range offsets building glibc test-tgmath2.c

[Alan Modra]

bb-reorder is quite seriously broken if get_attr_min_length should
return INT_MAX, which it does for hppa on branches with r267666.

I went the wrong way with my min_attr_value r267666 change.  It seems
that it isn't important that a "can't calculate" value is returned
from recursive calls, but rather that it returns the minimum among
those the function can calculate, ie. a conservative minimum length.
That's what this patch does, going back to the behaviour of
min_attr_value prior to r267666, with an added comment to stop foolish
patches in future.

Bootstrapped and regression tested powerpc64le-linux.  OK?

PR 88777
PR 88614
* genattrtab.c (min_fn): Don't translate values.
(min_attr_value): Return INT_MAX when the value can't be calculated.
Return minimum among any values that can be calculated.
(max_attr_value): Adjust.

diff --git a/gcc/genattrtab.c b/gcc/genattrtab.c
index 1dd4f142672..78816ba3179 100644
--- a/gcc/genattrtab.c
+++ b/gcc/genattrtab.c
@@ -1556,10 +1556,7 @@ max_fn (rtx exp)
 static rtx
 min_fn (rtx exp)
 {
-  int val = min_attr_value (exp);
-  if (val < 0)
-val = INT_MAX;
-  return make_numeric_value (val);
+  return make_numeric_value (min_attr_value (exp));
 }
 
 static void
@@ -3786,11 +3783,10 @@ max_attr_value (rtx exp)
   current_max = max_attr_value (XEXP (exp, 0));
   if (current_max != INT_MAX)
{
- n = min_attr_value (XEXP (exp, 1));
- if (n == INT_MIN)
-   current_max = INT_MAX;
- else
-   current_max -= n;
+ n = current_max;
+ current_max = min_attr_value (XEXP (exp, 1));
+ if (current_max != INT_MAX)
+   current_max = n - current_max;
}
   break;
 
@@ -3831,8 +3827,11 @@ max_attr_value (rtx exp)
 }
 
 /* Given an attribute value expression, return the minimum value that
-   might be evaluated.  Return INT_MIN if the value can't be
-   calculated by this function.  */
+   might be evaluated.  Return INT_MAX if the value can't be
+   calculated by this function.  Note that when this function can
+   calculate one value inside IF_THEN_ELSE or some but not all values
+   inside COND, then it returns the minimum among those values it can
+   calculate.  */
 
 static int
 min_attr_value (rtx exp)
@@ -3852,34 +3851,33 @@ min_attr_value (rtx exp)
 
 case PLUS:
   current_min = min_attr_value (XEXP (exp, 0));
-  if (current_min != INT_MIN)
+  if (current_min != INT_MAX)
{
  n = current_min;
  current_min = min_attr_value (XEXP (exp, 1));
- if (current_min != INT_MIN)
+ if (current_min != INT_MAX)
current_min += n;
}
   break;
 
 case MINUS:
   current_min = min_attr_value (XEXP (exp, 0));
-  if (current_min != INT_MIN)
+  if (current_min != INT_MAX)
{
- n = max_attr_value (XEXP (exp, 1));
- if (n == INT_MAX)
-   current_min = INT_MIN;
- else
-   current_min -= n;
+ n = current_min;
+ current_min = max_attr_value (XEXP (exp, 1));
+ if (current_min != INT_MAX)
+   current_min = n - current_min;
}
   break;
 
 case MULT:
   current_min = min_attr_value (XEXP (exp, 0));
-  if (current_min != INT_MIN)
+  if (current_min != INT_MAX)
{
  n = current_min;
  current_min = min_attr_value (XEXP (exp, 1));
- if (current_min != INT_MIN)
+ if (current_min != INT_MAX)
current_min *= n;
}
   break;
@@ -3902,7 +3900,7 @@ min_attr_value (rtx exp)
   break;
 
 default:
-  current_min = INT_MIN;
+  current_min = INT_MAX;
   break;
 }
 

-- 
Alan Modra
Australia Development Lab, IBM

RE: [PATCH 6/9][GCC][AArch64] Add Armv8.3-a complex intrinsics

[Tamar Christina]

Hi James,

Committed with the refactoring requested and the addition of a few trivial
Defines and iterators that were missing due to the patch series being split.

Thanks,
Tamar

-Original Message-
From: James Greenhalgh  
Sent: Wednesday, January 9, 2019 3:37 PM
To: Tamar Christina 
Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw 
; Marcus Shawcroft 
Subject: Re: [PATCH 6/9][GCC][AArch64] Add Armv8.3-a complex intrinsics

On Fri, Dec 21, 2018 at 11:57:55AM -0600, Tamar Christina wrote:
> Hi All,
> 
> This updated patch adds NEON intrinsics and tests for the Armv8.3-a 
> complex multiplication and add instructions with a rotate along the Argand 
> plane.
> 
> The instructions are documented in the ArmARM[1] and the intrinsics 
> specification will be published on the Arm website [2].
> 
> The Lane versions of these instructions are special in that they always 
> select a pair.
> using index 0 means selecting lane 0 and 1.  Because of this the range 
> check for the intrinsics require special handling.
> 
> There're a few complexities with the intrinsics for the laneq variants for 
> AArch64:
> 
> 1) The architecture does not have a version for V2SF. However since the 
> instructions always
>selects a pair of values, the only valid index for V2SF would have been 0. 
> As such the lane
>versions for V2SF are all mapped to the 3SAME variant of the instructions 
> and not the By element
>variant.
> 
> 2) Because of no# 1 above, the laneq versions of the instruction become 
> tricky. The valid indices are 0 and 1.
>For index 0 we treat it the same as the lane version of this instruction 
> and just pass the lower half of the
>register to the 3SAME instruction.  When index is 1 we extract the upper 
> half of the register and pass that to
>the 3SAME version of the instruction.
> 
> 2) The architecture forbits the laneq version of the V4HF instruction from 
> having an index greater than 1.  For index 0-1
>we do no extra work. For index 2-3 we extract the upper parts of the 
> register and pass that to the instruction it would
>have normally used, and re-map the index into a range of 0-1.
> 
> [1] 
> https://developer.arm.com/docs/ddi0487/latest/arm-architecture-referen
> ce-manual-armv8-for-armv8-a-architecture-profile
> [2] https://developer.arm.com/docs/101028/latest
> 
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> Additional runtime checks done but not posted with the patch.
> 
> Ok for trunk?

OK with a refactor.

This isn't a great fit for Stage 4, but it is also completely self-contained.

I hope we can slow down new content in the AArch64 back-end and start 
stabilising the port for release.

Thanks,
James

> @@ -1395,6 +1494,80 @@ aarch64_expand_builtin (tree exp,
>   }
>  
>return target;
> +
> +case AARCH64_SIMD_BUILTIN_FCMLA_LANEQ0_V2SF:
> +case AARCH64_SIMD_BUILTIN_FCMLA_LANEQ90_V2SF:
> +case AARCH64_SIMD_BUILTIN_FCMLA_LANEQ180_V2SF:
> +case AARCH64_SIMD_BUILTIN_FCMLA_LANEQ270_V2SF:
> +case AARCH64_SIMD_BUILTIN_FCMLA_LANEQ0_V4HF:
> +case AARCH64_SIMD_BUILTIN_FCMLA_LANEQ90_V4HF:
> +case AARCH64_SIMD_BUILTIN_FCMLA_LANEQ180_V4HF:
> +case AARCH64_SIMD_BUILTIN_FCMLA_LANEQ270_V4HF:

Pull all of this out to a new function please.

> +  int bcode = fcode - AARCH64_SIMD_FCMLA_LANEQ_BUILTIN_BASE - 1;
> +  aarch64_fcmla_laneq_builtin_datum* d
> + = &aarch64_fcmla_lane_builtin_data[bcode];
> +  machine_mode quadmode = GET_MODE_2XWIDER_MODE (d->mode).require ();
> +  op0 = force_reg (d->mode, expand_normal (CALL_EXPR_ARG (exp, 0)));
> +  rtx op1 = force_reg (d->mode, expand_normal (CALL_EXPR_ARG (exp, 1)));
> +  rtx op2 = force_reg (quadmode, expand_normal (CALL_EXPR_ARG (exp, 2)));
> +  tree tmp = CALL_EXPR_ARG (exp, 3);
> +  rtx lane_idx = expand_expr (tmp, NULL_RTX, VOIDmode, 
> +EXPAND_INITIALIZER);
> +
> +  /* Validate that the lane index is a constant.  */
> +  if (!CONST_INT_P (lane_idx))
> + {
> +   error ("%Kargument %d must be a constant immediate", exp, 4);
> +   return const0_rtx;
> + }
> +
> +  /* Validate that the index is within the expected range.  */
> +  int nunits = GET_MODE_NUNITS (quadmode).to_constant ();
> +  aarch64_simd_lane_bounds (lane_idx, 0, nunits / 2, exp);
> +
> +  /* Keep to GCC-vector-extension lane indices in the RTL.  */
> +  lane_idx = aarch64_endian_lane_rtx (quadmode, INTVAL 
> + (lane_idx));
> +
> +  /* Generate the correct register and mode.  */
> +  int lane = INTVAL (lane_idx);
> +
> +  if (lane < nunits / 4)
> + op2 = simplify_gen_subreg (d->mode, op2, quadmode, 0);
> +  else
> + {
> +   /* Select the upper 64 bits, either a V2SF or V4HF, this however
> +  is quite messy, as the operation required even though simple
> +  doesn't have a simple RTL pattern, and seems it's quite hard to
> +  define using a single RTL pattern.  The targe

RE: [PATCH 9/9][GCC][Arm] Add ACLE intrinsics for complex mutliplication and addition

[Tamar Christina]

Hi Kyrill,

Committed with a the addition of a few trivial defines and iterators that were 
missing due to
The patch being split. 

Thanks,
Tamar

-Original Message-
From: Kyrill Tkachov  
Sent: Friday, December 21, 2018 11:40 AM
To: Tamar Christina ; gcc-patches@gcc.gnu.org
Cc: nd ; Ramana Radhakrishnan ; 
Richard Earnshaw ; ni...@redhat.com
Subject: Re: [PATCH 9/9][GCC][Arm] Add ACLE intrinsics for complex 
mutliplication and addition

Hi Tamar,

On 11/12/18 15:46, Tamar Christina wrote:
> Hi All,
>
> This patch adds NEON intrinsics and tests for the Armv8.3-a complex 
> multiplication and add instructions with a rotate along the Argand plane.
>
> The instructions are documented in the ArmARM[1] and the intrinsics 
> specification will be published on the Arm website [2].
>
> The Lane versions of these instructions are special in that they always 
> select a pair.
> using index 0 means selecting lane 0 and 1.  Because of this the range 
> check for the intrinsics require special handling.
>
> On Arm, in order to implement some of the lane intrinsics we're using 
> the structure of the register file.  The lane variant of these 
> instructions always select a D register, but the data itself can be 
> stored in Q registers.  This means that for single precision complex 
> numbers you are only allowed to select D[0] but using the register file 
> layout you can get the range 0-1 for lane indices by selecting between Dn[0] 
> and Dn+1[0].
>
> Same reasoning applies for half float complex numbers, except there 
> your D register indexes can be 0 or 1, so you have a total range of 4 
> elements (for a V8HF).
>
>
> [1] 
> https://developer.arm.com/docs/ddi0487/latest/arm-architecture-referen
> ce-manual-armv8-for-armv8-a-architecture-profile
> [2] https://developer.arm.com/docs/101028/latest
>
> Bootstrapped Regtested on arm-none-gnueabihf and no issues.
>
> Ok for trunk?
>

Ok.
Thanks,
Kyrill

> Thanks,
> Tamar
>
> gcc/ChangeLog:
>
> 2018-12-11  Tamar Christina  
>
> * config/arm/arm-builtins.c
> (enum arm_type_qualifiers): Add qualifier_lane_pair_index.
> (MAC_LANE_PAIR_QUALIFIERS): New.
> (arm_expand_builtin_args): Use it.
> (arm_expand_builtin_1): Likewise.
> * config/arm/arm-protos.h (neon_vcmla_lane_prepare_operands): New.
> * config/arm/arm.c (neon_vcmla_lane_prepare_operands): New.
> * config/arm/arm-c.c (arm_cpu_builtins): Add __ARM_FEATURE_COMPLEX.
> * config/arm/arm_neon.h:
> (vcadd_rot90_f16): New.
> (vcaddq_rot90_f16): New.
> (vcadd_rot270_f16): New.
> (vcaddq_rot270_f16): New.
> (vcmla_f16): New.
> (vcmlaq_f16): New.
> (vcmla_lane_f16): New.
> (vcmla_laneq_f16): New.
> (vcmlaq_lane_f16): New.
> (vcmlaq_laneq_f16): New.
> (vcmla_rot90_f16): New.
> (vcmlaq_rot90_f16): New.
> (vcmla_rot90_lane_f16): New.
> (vcmla_rot90_laneq_f16): New.
> (vcmlaq_rot90_lane_f16): New.
> (vcmlaq_rot90_laneq_f16): New.
> (vcmla_rot180_f16): New.
> (vcmlaq_rot180_f16): New.
> (vcmla_rot180_lane_f16): New.
> (vcmla_rot180_laneq_f16): New.
> (vcmlaq_rot180_lane_f16): New.
> (vcmlaq_rot180_laneq_f16): New.
> (vcmla_rot270_f16): New.
> (vcmlaq_rot270_f16): New.
> (vcmla_rot270_lane_f16): New.
> (vcmla_rot270_laneq_f16): New.
> (vcmlaq_rot270_lane_f16): New.
> (vcmlaq_rot270_laneq_f16): New.
> (vcadd_rot90_f32): New.
> (vcaddq_rot90_f32): New.
> (vcadd_rot270_f32): New.
> (vcaddq_rot270_f32): New.
> (vcmla_f32): New.
> (vcmlaq_f32): New.
> (vcmla_lane_f32): New.
> (vcmla_laneq_f32): New.
> (vcmlaq_lane_f32): New.
> (vcmlaq_laneq_f32): New.
> (vcmla_rot90_f32): New.
> (vcmlaq_rot90_f32): New.
> (vcmla_rot90_lane_f32): New.
> (vcmla_rot90_laneq_f32): New.
> (vcmlaq_rot90_lane_f32): New.
> (vcmlaq_rot90_laneq_f32): New.
> (vcmla_rot180_f32): New.
> (vcmlaq_rot180_f32): New.
> (vcmla_rot180_lane_f32): New.
> (vcmla_rot180_laneq_f32): New.
> (vcmlaq_rot180_lane_f32): New.
> (vcmlaq_rot180_laneq_f32): New.
> (vcmla_rot270_f32): New.
> (vcmlaq_rot270_f32): New.
> (vcmla_rot270_lane_f32): New.
> (vcmla_rot270_laneq_f32): New.
> (vcmlaq_rot270_lane_f32): New.
> (vcmlaq_rot270_laneq_f32): New.
> * config/arm/arm_neon_builtins.def (vcadd90, vcadd270, vcmla0, 
> vcmla90,
> vcmla180, vcmla270, vcmla_lane0, vcmla_lane90, vcmla_lane180, 
> vcmla_lane270,
> vcmla_laneq0, vcmla_laneq90, vcmla_laneq180, vcmla_laneq270,
> vcmlaq_lane0, vcmlaq_lane90, vcmlaq_lane180, vcmlaq_lane270): New.
> * config/arm/neon.md (neon_vcmla_lane,
> neon_vcmla_laneq, neon_vcmlaq_lane): New.
>
> gcc/t

[PATCH] tree-ssa-loop-unswitch.c: port to the dump_* API (PR tree-optimization/88763)

[David Malcolm]

PR tree-optimization/88763 reports difficulties in getting useful
information from the log of tree-ssa-loop-unswitch.c.

As work towards improving this, this patch eliminates all uses of
dump_file from that source file, in favor of the dump API (to
support -fopt-info* and -fsave-optimization-record).

Doing so required adding a way to dump profile_probability instances,
so the patch adds a profile_probability::dump overload for this.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.

OK for next stage 1?

gcc/ChangeLog:
PR tree-optimization/88763
* cfgloop.h (find_loop_location): Move decl to here.
* profile-count.c (profile_probability::dump): Reimplement in
terms of...
(profile_probability::print): ...this new function, moving the
body here, and porting from FILE * to pretty_printer *.
(profile_probability::dump): New function.
* profile-count.h (class dump_metadata_t): New forward decl.
(profile_probability::print): New decl.
(profile_probability::dump): New overloaded decl.
* tree-ssa-loop-unswitch.c (tree_unswitch_single_loop): Port from
fprintf to the dump_* API.
(tree_unswitch_outer_loop): Likewise.
(find_loop_guard): Likewise.
(hoist_guard): Likewise.
* tree-vectorizer.h (find_loop_location): Move from here to
cfgloop.h.
---
 gcc/cfgloop.h|   3 +
 gcc/profile-count.c  |  34 ---
 gcc/profile-count.h  |   7 +++
 gcc/tree-ssa-loop-unswitch.c | 135 ++-
 gcc/tree-vectorizer.h|   1 -
 5 files changed, 120 insertions(+), 60 deletions(-)

diff --git a/gcc/cfgloop.h b/gcc/cfgloop.h
index 2e93af3..c175dcb 100644
--- a/gcc/cfgloop.h
+++ b/gcc/cfgloop.h
@@ -870,4 +870,7 @@ gcov_type_to_wide_int (gcov_type val)
 
   return widest_int::from_array (a, 2);
 }
+
+extern dump_user_location_t find_loop_location (struct loop *);
+
 #endif /* GCC_CFGLOOP_H */
diff --git a/gcc/profile-count.c b/gcc/profile-count.c
index 8c58f86..eaad18d 100644
--- a/gcc/profile-count.c
+++ b/gcc/profile-count.c
@@ -148,27 +148,47 @@ profile_count::stream_out (struct lto_output_stream *ob)
 void
 profile_probability::dump (FILE *f) const
 {
+  pretty_printer pp;
+  print (&pp);
+  fprintf (f, "%s", pp_formatted_text (&pp));
+}
+
+/* Print THIS to the PP.  */
+
+void
+profile_probability::print (pretty_printer *pp) const
+{
   if (!initialized_p ())
-fprintf (f, "uninitialized");
+pp_string (pp, "uninitialized");
   else
 {
   /* Make difference between 0.00 as a roundoff error and actual 0.
 Similarly for 1.  */
   if (m_val == 0)
-fprintf (f, "never");
+pp_string (pp, "never");
   else if (m_val == max_probability)
-fprintf (f, "always");
+pp_string (pp, "always");
   else
-fprintf (f, "%3.1f%%", (double)m_val * 100 / max_probability);
+   pp_scalar (pp, "%3.1f%%", (double)m_val * 100 / max_probability);
   if (m_quality == profile_adjusted)
-   fprintf (f, " (adjusted)");
+   pp_string (pp, " (adjusted)");
   else if (m_quality == profile_afdo)
-   fprintf (f, " (auto FDO)");
+   pp_string (pp, " (auto FDO)");
   else if (m_quality == profile_guessed)
-   fprintf (f, " (guessed)");
+   pp_string (pp, " (guessed)");
 }
 }
 
+/* Dump THIS to the active dump destinations.  */
+
+void
+profile_probability::dump (const dump_metadata_t &metadata) const
+{
+  pretty_printer pp;
+  print (&pp);
+  dump_printf (metadata, "%s", pp_formatted_text (&pp));
+}
+
 /* Dump THIS to stderr.  */
 
 void
diff --git a/gcc/profile-count.h b/gcc/profile-count.h
index 96b7400..a761836 100644
--- a/gcc/profile-count.h
+++ b/gcc/profile-count.h
@@ -23,6 +23,7 @@ along with GCC; see the file COPYING3.  If not see
 
 struct function;
 class profile_count;
+class dump_metadata_t;
 
 /* Quality of the profile count.  Because gengtype does not support enums
inside of classes, this is in global namespace.  */
@@ -561,6 +562,12 @@ public:
   /* Output THIS to F.  */
   void dump (FILE *f) const;
 
+  /* Output THIS to the active dump destinations.  */
+  void dump (const dump_metadata_t &) const;
+
+  /* Write THIS to PP.  */
+  void print (pretty_printer *pp) const;
+
   /* Print THIS to stderr.  */
   void debug () const;
 
diff --git a/gcc/tree-ssa-loop-unswitch.c b/gcc/tree-ssa-loop-unswitch.c
index 30a2a9d..3fdbc57 100644
--- a/gcc/tree-ssa-loop-unswitch.c
+++ b/gcc/tree-ssa-loop-unswitch.c
@@ -281,8 +281,10 @@ tree_unswitch_single_loop (struct loop *loop, int num)
   /* Do not unswitch in cold regions. */
   if (optimize_loop_for_size_p (loop))
{
- if (dump_file && (dump_flags & TDF_DETAILS))
-   fprintf (dump_file, ";; Not unswitching cold loops\n");
+ if (dump_enabled_p ())
+   dump_printf_loc (MSG_MISSED_OPTIMIZATION | TDF_DETAILS,
+

[Committed] PR fortran/88376 -- remove assert()

[Steve Kargl]

I've committed the attached patch as obvious.

2019-01-09  Steven G. Kargl  

 PR fortran/88376
 * resolve.c (is_illegal_recursion): Remove an assert().

2019-01-09  Steven G. Kargl  

 PR fortran/88376
 * gfortran.dg/pr88376.f90: New test.

-- 
Steve
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c	(revision 267779)
+++ gcc/fortran/resolve.c	(working copy)
@@ -1686,8 +1686,6 @@ is_illegal_recursion (gfc_symbol* sym, gfc_namespace* 
   || gfc_fl_struct (sym->attr.flavor))
 return false;
 
-  gcc_assert (sym->attr.flavor == FL_PROCEDURE);
-
   /* If we've got an ENTRY, find real procedure.  */
   if (sym->attr.entry && sym->ns->entries)
 proc_sym = sym->ns->entries->sym;
Index: gcc/testsuite/gfortran.dg/pr88376.f90
===
--- gcc/testsuite/gfortran.dg/pr88376.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr88376.f90	(working copy)
@@ -0,0 +1,8 @@
+! { dg-do compile }
+module m
+   integer :: n
+contains
+   subroutine s
+  character(n(3)) :: c  ! { dg-error "not a function" }
+   end
+end

[PATCH] PR fortran/86322 -- Enforce F2018:C877

[Steve Kargl]

The attached patche fixes the PR.  gfortran was not enforcing
F2018:C877 and would ICE.  Tested on x86_64-*-freebsd.  Ok to
commit?

2019-01-09  Steven G. Kargl  

 PR fortran/86322
 * decl.c (top_var_list): Set locus of expr.
 (gfc_match_data): Detect pointer on non-rightmost part-refs.

2019-01-09  Steven G. Kargl  

 PR fortran/86322
 * gfortran.dg/pr86322_1.f90: New test.
 * gfortran.dg/pr86322_2.f90: Ditto.
 * gfortran.dg/pr86322_3.f90: Ditto.

-- 
Steve
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c	(revision 267779)
+++ gcc/fortran/decl.c	(working copy)
@@ -337,6 +337,8 @@ top_var_list (gfc_data *d)
 
   new_var = gfc_get_data_variable ();
   *new_var = var;
+  if (new_var->expr)
+	new_var->expr->where = gfc_current_locus;
 
   if (tail == NULL)
 	d->var = new_var;
@@ -597,6 +599,7 @@ gfc_match_data (void)
 {
   gfc_data *new_data;
   gfc_expr *e;
+  gfc_ref *ref;
   match m;
 
   /* Before parsing the rest of a DATA statement, check F2008:c1206.  */
@@ -641,7 +644,7 @@ gfc_match_data (void)
 	  bool invalid;
 
 	  invalid = false;
-	  for (gfc_ref *ref = e->ref; ref; ref = ref->next)
+	  for (ref = e->ref; ref; ref = ref->next)
 	if ((ref->type == REF_COMPONENT
 		 && ref->u.c.component->attr.allocatable)
 		|| (ref->type == REF_ARRAY
@@ -655,6 +658,21 @@ gfc_match_data (void)
 			 "near %C in DATA statement");
 	  goto cleanup;
 	}
+
+	  /* F2008:C567 (R536) A data-i-do-object or a variable that appears
+	 as a data-stmt-object shall not be an object designator in which
+	 a pointer appears other than as the entire rightmost part-ref.  */
+	  ref = e->ref;
+	  if (e->symtree->n.sym->ts.type == BT_DERIVED
+	  && e->symtree->n.sym->attr.pointer
+	  && ref->type == REF_COMPONENT)
+	goto partref;
+
+	  for (; ref; ref = ref->next)
+	if (ref->type == REF_COMPONENT
+		&& ref->u.c.component->attr.pointer
+		&& ref->next)
+	  goto partref;
 	}
 
   m = top_val_list (new_data);
@@ -680,6 +698,12 @@ gfc_match_data (void)
   gfc_unset_implicit_pure (gfc_current_ns->proc_name);
 
   return MATCH_YES;
+
+partref:
+
+  gfc_error ("part-ref with pointer attribute near %L is not "
+	 "rightmost part-ref of data-stmt-object",
+	 &e->where);
 
 cleanup:
   set_in_match_data (false);
Index: gcc/testsuite/gfortran.dg/pr86322_1.f90
===
--- gcc/testsuite/gfortran.dg/pr86322_1.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr86322_1.f90	(working copy)
@@ -0,0 +1,12 @@
+! { dg-do compile }
+program foo
+   implicit none
+   type a
+  integer i
+   end type a
+   type(a), target, save :: b
+   type(a), pointer :: c
+   data b%i /42/
+   data c%i /b%i/  ! { dg-error "is not rightmost part-ref" }
+   if (c%i == 42) c%i = 1  ! Unreachable
+end program foo
Index: gcc/testsuite/gfortran.dg/pr86322_2.f90
===
--- gcc/testsuite/gfortran.dg/pr86322_2.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr86322_2.f90	(working copy)
@@ -0,0 +1,13 @@
+! { dg-do compile }
+program bar
+   type a
+ integer :: i
+   end type a
+   type b
+ type(a),pointer :: j
+   end type b
+   integer, target, save :: k = 42
+   type(b) x
+   data x%j%i/k/  ! { dg-error "is not rightmost part-ref" }
+   print *, x%j%i
+end program bar
Index: gcc/testsuite/gfortran.dg/pr86322_3.f90
===
--- gcc/testsuite/gfortran.dg/pr86322_3.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr86322_3.f90	(working copy)
@@ -0,0 +1,13 @@
+! { dg-do run }
+program bar
+   type a
+ integer, pointer :: i
+   end type a
+   type b
+ type(a) :: j
+   end type b
+   integer, target, save :: k = 42
+   type(b) x
+   data x%j%i/k/
+   if (x%j%i /= 42) stop 1
+end program bar

Re: [Patch 4/4][Aarch64] v2: Implement Aarch64 SIMD ABI

[Steve Ellcey]

On Wed, 2019-01-09 at 10:00 +, Richard Sandiford wrote:

Thanks for the quick turnaround on the comments Richard.  Here is a new
version where I tried to address all the issues you raised.  One thing
I noticed is that I think your calls_have_same_clobbers_p function only
works if, when return_call_with_max_clobbers is called with two calls
that clobber the same set of registers, it always returns the first
call.

I don't think my original function had that guarantee but I changed it 
so that it would and documented that requirement in target.def.  I
couldn't see a better way to implement the calls_have_same_clobbers_p
function other than doing that.

Steve Ellcey
sell...@marvell.com


2019-01-09  Steve Ellcey  

* config/aarch64/aarch64.c (aarch64_simd_call_p): New function.
(aarch64_hard_regno_call_part_clobbered): Add insn argument.
(aarch64_return_call_with_max_clobbers): New function.
(TARGET_RETURN_CALL_WITH_MAX_CLOBBERS): New macro.
* config/avr/avr.c (avr_hard_regno_call_part_clobbered): Add insn
argument.
* config/i386/i386.c (ix86_hard_regno_call_part_clobbered): Ditto.
* config/mips/mips.c (mips_hard_regno_call_part_clobbered): Ditto.
* config/rs6000/rs6000.c (rs6000_hard_regno_call_part_clobbered): Ditto.
* config/s390/s390.c (s390_hard_regno_call_part_clobbered): Ditto.
* cselib.c (cselib_process_insn): Add argument to
targetm.hard_regno_call_part_clobbered call.
* ira-conflicts.c (ira_build_conflicts): Ditto.
* ira-costs.c (ira_tune_allocno_costs): Ditto.
* lra-constraints.c (inherit_reload_reg): Ditto.
* lra-int.h (struct lra_reg): Add call_insn field, remove call_p field.
* lra-lives.c (check_pseudos_live_through_calls): Add call_insn
argument.  Call targetm.return_call_with_max_clobbers.
Add argument to targetm.hard_regno_call_part_clobbered call.
(calls_have_same_clobbers_p): New function.
(process_bb_lives): Add call_insn and last_call_insn variables.
Pass call_insn to check_pseudos_live_through_calls.
Modify if stmt to check targetm.return_call_with_max_clobbers.
Update setting of flush variable.
* lra.c (initialize_lra_reg_info_element): Set call_insn to NULL.
* regcprop.c (copyprop_hardreg_forward_1): Add argument to
targetm.hard_regno_call_part_clobbered call.
* reginfo.c (choose_hard_reg_mode): Ditto.
* regrename.c (check_new_reg_p): Ditto.
* reload.c (find_equiv_reg): Ditto.
* reload1.c (emit_reload_insns): Ditto.
* sched-deps.c (deps_analyze_insn): Ditto.
* sel-sched.c (init_regs_for_mode): Ditto.
(mark_unavailable_hard_regs): Ditto.
* targhooks.c (default_dwarf_frame_reg_mode): Ditto.
* target.def (hard_regno_call_part_clobbered): Add insn argument.
(return_call_with_max_clobbers): New target function.
* doc/tm.texi: Regenerate.
* doc/tm.texi.in (TARGET_RETURN_CALL_WITH_MAX_CLOBBERS): New hook.
* hooks.c (hook_bool_uint_mode_false): Change to
hook_bool_insn_uint_mode_false.
* hooks.h (hook_bool_uint_mode_false): Ditto.


diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 1c300af..d88be6c 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -1655,14 +1655,56 @@ aarch64_reg_save_mode (tree fndecl, unsigned regno)
 	   : (aarch64_simd_decl_p (fndecl) ? E_TFmode : E_DFmode);
 }
 
+/* Return true if the instruction is a call to a SIMD function, false
+   if it is not a SIMD function or if we do not know anything about
+   the function.  */
+
+static bool
+aarch64_simd_call_p (rtx_insn *insn)
+{
+  rtx symbol;
+  rtx call;
+  tree fndecl;
+
+  gcc_assert (CALL_P (insn));
+  call = get_call_rtx_from (insn);
+  symbol = XEXP (XEXP (call, 0), 0);
+  if (GET_CODE (symbol) != SYMBOL_REF)
+return false;
+  fndecl = SYMBOL_REF_DECL (symbol);
+  if (!fndecl)
+return false;
+
+  return aarch64_simd_decl_p (fndecl);
+}
+
 /* Implement TARGET_HARD_REGNO_CALL_PART_CLOBBERED.  The callee only saves
the lower 64 bits of a 128-bit register.  Tell the compiler the callee
clobbers the top 64 bits when restoring the bottom 64 bits.  */
 
 static bool
-aarch64_hard_regno_call_part_clobbered (unsigned int regno, machine_mode mode)
+aarch64_hard_regno_call_part_clobbered (rtx_insn *insn, unsigned int regno,
+	machine_mode mode)
 {
-  return FP_REGNUM_P (regno) && maybe_gt (GET_MODE_SIZE (mode), 8);
+  bool simd_p = insn && CALL_P (insn) && aarch64_simd_call_p (insn);
+  return FP_REGNUM_P (regno)
+	 && maybe_gt (GET_MODE_SIZE (mode), simd_p ? 16 : 8);
+}
+
+/* Implement TARGET_RETURN_CALL_WITH_MAX_CLOBBERS.  */
+
+rtx_insn *
+aarch64_return_call_with_max_clobbers (rtx_insn *call_1, rtx_insn *call_2)
+{
+  gcc_assert (CALL_P (call_1) && CALL_P (call_2));
+
+  if (aarch64_simd_call_p (call_1) == aarch6

Re: Go patch committed: Use build_variant_type_copy, not build_distinct_type_copy

[Ian Lance Taylor]

On Thu, Jun 28, 2018 at 10:46 AM Ian Lance Taylor  wrote:
>
> This patch to the Go frontend changes set_placeholder_struct_type to
> use build_variant_type_copy rather than build_distinct_type_copy.
> This is for PR 86343, which noted that the DECL_CONTEXT of the fields
> in the copy were pointing to the wrong type.  Using
> build_variant_type_copy puts the types in right relationship for the
> DECL_CONTEXT setting.  Bootstrapped and ran Go testsuite on
> x86_64-pc-linux-gnu.  Committed to mainline.
>
> Ian
>
> 2018-06-28  Ian Lance Taylor  
>
> PR go/86343
> * go-gcc.cc (Gcc_backend::set_placeholder_struct_type): Call
> build_variant_type_copy rather than build_distinct_type_copy.

It turns out that this old patch broke gccgo's debug info for named
struct types.  Updated as follows, which seems to work better.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian

2019-01-09  Ian Lance Taylor  

PR go/86343
* go-gcc.cc (Gcc_backend::set_placeholder_struct_type): Go back to
build_distinct_type_copy, but copy the fields so that they have
the right DECL_CONTEXT.
Index: go-gcc.cc
===
--- go-gcc.cc   (revision 267788)
+++ go-gcc.cc   (working copy)
@@ -1098,9 +1098,13 @@ Gcc_backend::set_placeholder_struct_type
   if (TYPE_NAME(t) != NULL_TREE)
 {
   // Build the data structure gcc wants to see for a typedef.
-  tree copy = build_variant_type_copy(t);
+  tree copy = build_distinct_type_copy(t);
   TYPE_NAME(copy) = NULL_TREE;
   DECL_ORIGINAL_TYPE(TYPE_NAME(t)) = copy;
+  TYPE_SIZE(copy) = NULL_TREE;
+  Btype* bc = this->make_type(copy);
+  this->fill_in_struct(bc, fields);
+  delete bc;
 }
 
   return r->get_tree() != error_mark_node;

Re: ISO_Fortran_binding patch

[Paul Richard Thomas]

Hi Thomas,

Aaaah! Light bulb moment - I was looking in the $PREFIX/include directory.

For whatever reason, mine does not appear in lib64 but in lib. OK,
that will have to do for now because the patch is blocking my tree for
a number of other things. I'll fix Bernhard's nit and commit on
Saturday.

Thanks everybody.

Paul

On Wed, 9 Jan 2019 at 20:08, Thomas Koenig  wrote:
>
> Hi Paul,
>
> > Incidentally, we need to make sure that it is distributed in the
> > include directory. I have yet to figure out how to do that.
>
> It already does that, that was part of what I sent you :-)
>
> It's the
>
> +gfor_c_HEADERS = $(srcdir)/ISO_Fortran_binding.h
> +gfor_cdir =
> $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/include
> +
>
> part in Makefile.am which puts in the requisite magic into
> Makefile.im.
>
> Header files are then installed into
>
> $PREFIX/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/include/ISO_Fortran_binding.h
> $PREFIX/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/32/include/ISO_Fortran_binding.h
>
> So, OK for trunk.
>
> Thanks a lot for this!  Looking at what we are currently
> finishing, I think we will be quite close to F2008 conformance
> when gcc 9 comes out, modulo a few bugs, of course.
>
> Regards
>
> Thomas
>


-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein

[PATCH, libphobos] Committed remove or update of library deprecations

[Iain Buclaw]

This patch merges the phobos library with upstream b022e552a.

Removes or updates the removal date of all deprecations in phobos.
Many of the marked functions have passed their end dates, and are now
absent in upstream.

Bootstrapped and tested on x86_64-linux-gnu.

Committed to trunk as r267788
-- 
Iain
---
diff --git a/libphobos/src/MERGE b/libphobos/src/MERGE
new file mode 100644
index 000..f32fc597d95
--- /dev/null
+++ b/libphobos/src/MERGE
@@ -0,0 +1,4 @@
+b022e552aaca84810e3dda3a18179440943c7096
+
+The first line of this file holds the git revision number of the last
+merge done from the dlang/phobos repository.
diff --git a/libphobos/src/std/array.d b/libphobos/src/std/array.d
index 13677a30285..b03f5e9d2d0 100644
--- a/libphobos/src/std/array.d
+++ b/libphobos/src/std/array.d
@@ -76,7 +76,6 @@ Source: $(PHOBOSSRC std/_array.d)
 */
 module std.array;
 
-static import std.algorithm.iteration; // FIXME, remove with alias of splitter
 import std.functional;
 import std.meta;
 import std.traits;
@@ -1465,6 +1464,7 @@ if (isSomeString!S)
 {
 import std.ascii : isWhite;
 import std.algorithm.comparison : equal;
+import std.algorithm.iteration : splitter;
 
 string str = "Hello World!";
 assert(str.splitter!(isWhite).equal(["Hello", "World!"]));
@@ -1524,10 +1524,6 @@ if (isSomeString!S)
 assert(a == [[1], [4, 5, 1], [4, 5]]);
 }
 
-// Explicitly undocumented. It will be removed in January 2018. @@@DEPRECATED_2018-01@@@
-deprecated("Please use std.algorithm.iteration.splitter instead.")
-alias splitter = std.algorithm.iteration.splitter;
-
 /++
 Eagerly splits $(D range) into an array, using $(D sep) as the delimiter.
 
diff --git a/libphobos/src/std/conv.d b/libphobos/src/std/conv.d
index 76ac5321382..eaee62f2413 100644
--- a/libphobos/src/std/conv.d
+++ b/libphobos/src/std/conv.d
@@ -3865,20 +3865,10 @@ if (isInputRange!Source && isSomeChar!(ElementType!Source) &&
 string text(T...)(T args)
 if (T.length > 0) { return textImpl!string(args); }
 
-// @@@DEPRECATED_2018-06@@@
-deprecated("Calling `text` with 0 arguments is deprecated")
-string text(T...)(T args)
-if (T.length == 0) { return textImpl!string(args); }
-
 ///ditto
 wstring wtext(T...)(T args)
 if (T.length > 0) { return textImpl!wstring(args); }
 
-// @@@DEPRECATED_2018-06@@@
-deprecated("Calling `wtext` with 0 arguments is deprecated")
-wstring wtext(T...)(T args)
-if (T.length == 0) { return textImpl!wstring(args); }
-
 ///ditto
 dstring dtext(T...)(T args)
 if (T.length > 0) { return textImpl!dstring(args); }
@@ -3891,10 +3881,24 @@ if (T.length > 0) { return textImpl!dstring(args); }
 assert(dtext(42, ' ', 1.5, ": xyz") == "42 1.5: xyz"d);
 }
 
-// @@@DEPRECATED_2018-06@@@
-deprecated("Calling `dtext` with 0 arguments is deprecated")
-dstring dtext(T...)(T args)
-if (T.length == 0) { return textImpl!dstring(args); }
+@safe unittest
+{
+char  c = 'h';
+wchar w = '你';
+dchar d = 'እ';
+
+assert( text(c, "ello", ' ', w, "好 ", d, "ው ሰላም ነው") == "hello 你好 እው ሰላም ነው"c);
+assert(wtext(c, "ello", ' ', w, "好 ", d, "ው ሰላም ነው") == "hello 你好 እው ሰላም ነው"w);
+assert(dtext(c, "ello", ' ', w, "好 ", d, "ው ሰላም ነው") == "hello 你好 እው ሰላም ነው"d);
+
+string  cs = "今日は";
+wstring ws = "여보세요";
+dstring ds = "Здравствуйте";
+
+assert( text(cs, ' ', ws, " ", ds) == "今日は 여보세요 Здравствуйте"c);
+assert(wtext(cs, ' ', ws, " ", ds) == "今日は 여보세요 Здравствуйте"w);
+assert(dtext(cs, ' ', ws, " ", ds) == "今日は 여보세요 Здравствуйте"d);
+}
 
 private S textImpl(S, U...)(U args)
 {
diff --git a/libphobos/src/std/datetime/date.d b/libphobos/src/std/datetime/date.d
index 38a87661b4f..d571f5fdd33 100644
--- a/libphobos/src/std/datetime/date.d
+++ b/libphobos/src/std/datetime/date.d
@@ -2154,32 +2154,6 @@ public:
 assert(idt - duration == DateTime(1999, 7, 6, 12, 30, 21));
 }
 
-// Explicitly undocumented. It will be removed in January 2018. @@@DEPRECATED_2018-01@@@
-deprecated("Use Duration instead of TickDuration.")
-DateTime opBinary(string op)(in TickDuration td) const @safe pure nothrow @nogc
-if (op == "+" || op == "-")
-{
-DateTime retval = this;
-immutable seconds = td.seconds;
-mixin("return retval._addSeconds(" ~ op ~ "seconds);");
-}
-
-deprecated @safe unittest
-{
-// This probably only runs in cases where gettimeofday() is used, but it's
-// hard to do this test correctly with variable ticksPerSec.
-if (TickDuration.ticksPerSec == 1_000_000)
-{
-auto dt = DateTime(Date(1999, 7, 6), TimeOfDay(12, 30, 33));
-
-assert(dt + TickDuration.from!"usecs"(7_000_000) == DateTime(Date(1999, 7, 6), TimeOfDay(12, 30, 40)));
-assert(dt + TickDuration.from!"usecs"(-7_000_000) == DateTime(Date(1999, 7, 6), TimeOfDay(12, 30, 26)));
-
-assert(dt - TickDuration.from!"usecs"(-7_000_000) == DateTime(Date(1999, 7, 6), TimeOfDay(12, 30, 40)));
-assert(dt

[PATCH] Move PR84877 fix elsewhere (PR bootstrap/88450)

[Jakub Jelinek]

Hi!

The r266345 change breaks mingw bootstraps for quite some time.
The problem is that the dynamic realignment is done IMHO way too low.

The biggest problem is that when assign_stack_local_1 decides to do this
dynamic_align_addr, it emits wherever it is currently expanding code about 3
instructions to do something like new_base = (base + (align - 1)) / align * 
align
and returns a MEM with that new_base as the XEXP (mem, 0).  Unfortunately,
one of the common callers of assign_stack_local_1,
assign_stack_temp_from_type, does temporary stack slot management and reuses
already assigned slots if they are suitable somewhere else.  This of course
doesn't work at all if the instructions that set new_base don't dominate one
or more of the other uses.

Another problem is that in way too many cases we decide to choose
BIGGEST_ALIGNMENT for stack slots, even when not strictly needed.  E.g. any
BLKmode stack slot requests that BIGGEST_ALIGNMENT, even if TYPE_ALIGN is
much smaller and assign_stack_local_1 even asserts that for BLKmode the
alignment must be BIGGEST_ALIGNMENT.  E.g. on mingw with -mavx or -mavx512f
BIGGEST_ALIGNMENT is 256 or 512 bits, but MAX_SUPPORTED_STACK_ALIGNMENT is
128 bits.  So the PR84877 change, even if it didn't cause wrong-code, causes
huge amounts of stack slots to be unnecessarily overaligned with dynamic
realignment.

The following patch reverts to the previous behavior and moves this dynamic
stack realignment to the caller that needs it, which doesn't do caching and
where we can do it solely for this overaligned DECL_ALIGN.

If there are other spots that need this, wondering about:
  else
copy = assign_temp (type, 1, 0);
in calls.c, either it can be done by using the variable-sized object
case in the then block, or could be done using assign_stack_local +
this short realignment too.

Bootstrapped/regtested on x86_64-linux, i686-linux, powerpc64le-linux,
bootstrapped on powerpc64-linux (regtest still pending there).

Ok for trunk?

2019-01-09  Jakub Jelinek  

PR middle-end/84877
PR bootstrap/88450
* function.c (assign_stack_local_1): Revert the 2018-11-21 changes.
(assign_parm_setup_block): Do the argument slot realignment here
instead.

--- gcc/function.c.jj   2019-01-09 15:39:26.261153591 +0100
+++ gcc/function.c  2019-01-09 16:17:59.757704567 +0100
@@ -377,7 +377,6 @@ assign_stack_local_1 (machine_mode mode,
   poly_int64 bigend_correction = 0;
   poly_int64 slot_offset = 0, old_frame_offset;
   unsigned int alignment, alignment_in_bits;
-  bool dynamic_align_addr = false;
 
   if (align == 0)
 {
@@ -396,22 +395,14 @@ assign_stack_local_1 (machine_mode mode,
 
   alignment_in_bits = alignment * BITS_PER_UNIT;
 
+  /* Ignore alignment if it exceeds MAX_SUPPORTED_STACK_ALIGNMENT.  */
   if (alignment_in_bits > MAX_SUPPORTED_STACK_ALIGNMENT)
 {
-  /* If the required alignment exceeds MAX_SUPPORTED_STACK_ALIGNMENT and
-it is not OK to reduce it.  Align the slot dynamically.  */
-  if (mode == BLKmode
- && (kind & ASLK_REDUCE_ALIGN) == 0
- && currently_expanding_to_rtl)
-   dynamic_align_addr = true;
-  else
-   {
- alignment_in_bits = MAX_SUPPORTED_STACK_ALIGNMENT;
- alignment = MAX_SUPPORTED_STACK_ALIGNMENT / BITS_PER_UNIT;
-   }
+  alignment_in_bits = MAX_SUPPORTED_STACK_ALIGNMENT;
+  alignment = MAX_SUPPORTED_STACK_ALIGNMENT / BITS_PER_UNIT;
 }
 
-  if (SUPPORTS_STACK_ALIGNMENT && !dynamic_align_addr)
+  if (SUPPORTS_STACK_ALIGNMENT)
 {
   if (crtl->stack_alignment_estimated < alignment_in_bits)
{
@@ -441,42 +432,10 @@ assign_stack_local_1 (machine_mode mode,
}
 }
 
-  /* Handle overalignment here for parameter copy on the stack.
- Reserved enough space for it and dynamically align the address.
- No free frame_space is added here.  */
-  if (dynamic_align_addr)
-{
-  rtx allocsize = gen_int_mode (size, Pmode);
-  get_dynamic_stack_size (&allocsize, 0, alignment_in_bits, NULL);
-
-  /* This is the size of space needed to accommodate required size of data
-with given alignment.  */
-  poly_int64 len = rtx_to_poly_int64 (allocsize);
-  old_frame_offset = frame_offset;
-
-  if (FRAME_GROWS_DOWNWARD)
-   {
- frame_offset -= len;
- try_fit_stack_local (frame_offset, len, len,
-  PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT,
-  &slot_offset);
-   }
-  else
-   {
- frame_offset += len;
- try_fit_stack_local (old_frame_offset, len, len,
-  PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT,
-  &slot_offset);
-   }
-  goto found_space;
-}
-  else
-{
-  if (crtl->stack_alignment_needed < alignment_in_bits)
-   crtl->stack_alignment_needed = alignment_in_bits;
-  if (crtl->max_used_stack_slot_alignmen

Re: [PATCH][AArch64] Use Q-reg loads/stores in movmem expansion

[Wilco Dijkstra]

Hi James,

TImode is an integer mode so we strongly prefer using integer registers
to avoid inefficient allocations using SIMD registers. We might be able to
use TFmode since that prefers Q registers. However we don't support
TFmode LDP/STP unless emitted explicitly like in prolog/epilog. LDP of
TImode isn't supported at all, so both these options are out.

We also can't use 256-bit modes like OImode since that's a special type
for LD2/ST2, so it's not possible to emit LDP/STP that way.

So yes, using V4SImode and allowing LDP/STP being generated as usual
is far better than what we do today. It also allows targets to disable 256-bit
LDPs if required.

Cheers,
Wilco

Re: ISO_Fortran_binding patch

[Damian Rouson]

On Wed, Jan 9, 2019 at 3:08 PM Thomas Koenig  wrote:
>
>
> Thanks a lot for this!  Looking at what we are currently
> finishing, I think we will be quite close to F2008 conformance
> when gcc 9 comes out, modulo a few bugs, of course.

And because ISO_Fortran_binding.h is part of Fortran 2018, this patch moves
gfortran closer to 2018 conformance as well.

Damian

Re: ISO_Fortran_binding patch

[Thomas Koenig]

Hi Paul,


Incidentally, we need to make sure that it is distributed in the
include directory. I have yet to figure out how to do that.


It already does that, that was part of what I sent you :-)

It's the

+gfor_c_HEADERS = $(srcdir)/ISO_Fortran_binding.h
+gfor_cdir = 
$(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/include

+

part in Makefile.am which puts in the requisite magic into
Makefile.im.

Header files are then installed into

$PREFIX/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/include/ISO_Fortran_binding.h
$PREFIX/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/32/include/ISO_Fortran_binding.h

So, OK for trunk.

Thanks a lot for this!  Looking at what we are currently
finishing, I think we will be quite close to F2008 conformance
when gcc 9 comes out, modulo a few bugs, of course.

Regards

Thomas

[PATCH, i386]: Add xorsign support

[Uros Bizjak]

Recent discussions on mailing list reminded me on this long forgotten
patch... I hope it is still OK to commit it, so gcc-9 will support
optimization that benefits SPEC on x86 targets.

2019-01-09  Uroš Bizjak  

* config/i386/i386-protos.h (ix86_expand_xorsign): New prototype.
(ix86_split_xorsign): Ditto.
* config/i386/i386.c (ix86_expand_xorsign): New function.
(ix86_split_xorsign): Ditto.
* config/i386/i386.md (UNSPEC_XORSIGN): New unspec.
(xorsign3): New expander.
(xorsign3_1): New insn_and_split pattern.
* config/i386/sse.md (xorsign3): New expander.

testsuite/ChangeLog:

2019-01-09  Uroš Bizjak  

* lib/target-supports.exp
(check_effective_target_xorsign): Add i?86-*-* and x86_64-*-* targets.
* gcc.target/i386/xorsign.c: New test.

Bootstrapped and regression tested on x86_64. Committed to mainline SVN.

Uros.
Index: config/i386/i386-protos.h
===
--- config/i386/i386-protos.h   (revision 267776)
+++ config/i386/i386-protos.h   (working copy)
@@ -124,6 +124,8 @@ extern void ix86_expand_fp_absneg_operator (enum r
 extern void ix86_expand_copysign (rtx []);
 extern void ix86_split_copysign_const (rtx []);
 extern void ix86_split_copysign_var (rtx []);
+extern void ix86_expand_xorsign (rtx []);
+extern void ix86_split_xorsign (rtx []);
 extern bool ix86_unary_operator_ok (enum rtx_code, machine_mode, rtx[]);
 extern bool ix86_match_ccmode (rtx, machine_mode);
 extern void ix86_expand_branch (enum rtx_code, rtx, rtx, rtx);
Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 267776)
+++ config/i386/i386.c  (working copy)
@@ -21860,6 +21860,63 @@ ix86_split_copysign_var (rtx operands[])
   emit_insn (gen_rtx_SET (dest, x));
 }
 
+/* Expand an xorsign operation.  */
+
+void
+ix86_expand_xorsign (rtx operands[])
+{
+  rtx (*xorsign_insn)(rtx, rtx, rtx, rtx);
+  machine_mode mode, vmode;
+  rtx dest, op0, op1, mask;
+
+  dest = operands[0];
+  op0 = operands[1];
+  op1 = operands[2];
+
+  mode = GET_MODE (dest);
+
+  if (mode == SFmode)
+{
+  xorsign_insn = gen_xorsignsf3_1;
+  vmode = V4SFmode;
+}
+  else if (mode == DFmode)
+{
+  xorsign_insn = gen_xorsigndf3_1;
+  vmode = V2DFmode;
+}
+  else
+gcc_unreachable ();
+
+  mask = ix86_build_signbit_mask (vmode, 0, 0);
+
+  emit_insn (xorsign_insn (dest, op0, op1, mask));
+}
+
+/* Deconstruct an xorsign operation into bit masks.  */
+
+void
+ix86_split_xorsign (rtx operands[])
+{
+  machine_mode mode, vmode;
+  rtx dest, op0, mask, x;
+
+  dest = operands[0];
+  op0 = operands[1];
+  mask = operands[3];
+
+  mode = GET_MODE (dest);
+  vmode = GET_MODE (mask);
+
+  dest = lowpart_subreg (vmode, dest, mode);
+  x = gen_rtx_AND (vmode, dest, mask);
+  emit_insn (gen_rtx_SET (dest, x));
+
+  op0 = lowpart_subreg (vmode, op0, mode);
+  x = gen_rtx_XOR (vmode, dest, op0);
+  emit_insn (gen_rtx_SET (dest, x));
+}
+
 /* Return TRUE or FALSE depending on whether the first SET in INSN
has source and destination with matching CC modes, and that the
CC mode is at least as constrained as REQ_MODE.  */
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 267776)
+++ config/i386/i386.md (working copy)
@@ -124,6 +124,7 @@
 
   ;; Generic math support
   UNSPEC_COPYSIGN
+  UNSPEC_XORSIGN
   UNSPEC_IEEE_MIN  ; not commutative
   UNSPEC_IEEE_MAX  ; not commutative
 
@@ -9784,6 +9785,26 @@
&& reload_completed"
   [(const_int 0)]
   "ix86_split_copysign_var (operands); DONE;")
+
+(define_expand "xorsign3"
+  [(match_operand:MODEF 0 "register_operand")
+   (match_operand:MODEF 1 "register_operand")
+   (match_operand:MODEF 2 "register_operand")]
+  "SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH"
+  "ix86_expand_xorsign (operands); DONE;")
+
+(define_insn_and_split "xorsign3_1"
+  [(set (match_operand:MODEF 0 "register_operand" "=Yv")
+   (unspec:MODEF
+ [(match_operand:MODEF 1 "register_operand" "Yv")
+  (match_operand:MODEF 2 "register_operand" "0")
+  (match_operand: 3 "nonimmediate_operand" "Yvm")]
+ UNSPEC_XORSIGN))]
+  "SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH"
+  "#"
+  "&& reload_completed"
+  [(const_int 0)]
+  "ix86_split_xorsign (operands); DONE;")
 
 ;; One complement instructions
 
Index: config/i386/sse.md
===
--- config/i386/sse.md  (revision 267776)
+++ config/i386/sse.md  (working copy)
@@ -3423,6 +3423,20 @@
   operands[5] = gen_reg_rtx (mode);
 })
 
+(define_expand "xorsign3"
+  [(set (match_dup 4)
+   (and:VF (match_dup 3)
+   (match_operand:VF 2 "vector_operand")))
+   (set (match_operand:VF 0 "register_operand")
+   (xor:VF (match_dup 4)
+   (match_operand:VF 1 "vector_operand")))]
+  "TARGET_SSE"
+{
+  operands[3] = ix86_b

Re: [patch, fortran] Fix PR 68426, simplification of SPREAD

[Steve Kargl]

On Wed, Jan 09, 2019 at 12:11:12AM +0100, Thomas Koenig wrote:
> 
> the attached patch fixes the PR by simpliy having gfc_simplify_spread
> also do its job when there's an EXPR_STRUCTURE.  The code to correctly
> handle that case was already in place, it just was not run for that
> case.
> 
> Regression-tested. OK for trunk?
> 

Yes.

-- 
Steve

Re: Remove overall growth from badness metrics

[Qing Zhao]

>>> 
>>> Those are sizes of libxul, which is the largest library of Firefox.
>>> PGO is profile guided optimization.
>> 
>> Okay.  I see. 
>> 
>> looks like for LTO,  the code size increase with profiling is much smaller 
>> than
>> that without profiling when growth is increased from 20% to 40%.  
> 
> With LTo the growth is about 9%, while for non-LTO is about about 4% and
> with PGO it is about 3%.  This is expected.
> 
> For non-LTO most of translation units do not hit the limit becuase most
> of calls are external. Firefox is bit special here by using the #include
> based unified build that gets it closer to LTO, but not quite.
> 
> With LTO there is only one translation unit that hits the 20% code size
> growth that after optimization translates to that 9%
> 
> With profilef feedback code is partitioned into cold and hot sections
> where only hot section growths by the given percentage. For firefox
> about 15% of the binary is trained and rest is cold.
>> 
>> for Non-LTO, the code size increase is minimal when growth is increased fro 
>> 20% to 40%.
>> 
>> However, not quite understand the last column, could you please explain a 
>> little bit
>> on last column (-finline-functions)?
> 
> It is non-lto build but with additional -finline-functions.
> 
> GCC build machinery uses -O2 by default and -O3 for some files. Adding
> -finline-functions enables agressive inlining everywhere.  But double
> checking the numbers, I must have cut&pasted wrong data here.  For
> growth 20 -finline-functions non-LTO non-PGO I get 107272791 (so table
> is wrong) and increasing growth to 40 gets me 115311719 (which is
> correct in the table)
>> 
> 
> growthLTO+PGOPGO   LTOnone  
> -finline-functions
> 20 (default)   83752215   94390023  93085455  103437191  94351191
> 40 85299111   97220935  101600151 108910311  115311719
> clang  111520431114863807 108437807
> 
> It should be:
> growthLTO+PGOPGO   LTOnone  
> -finline-functions
> 20 (default)   83752215   94390023  93085455  103437191  107272791
> 40 85299111   97220935  101600151 108910311  115311719
> clang  111520431114863807 108437807
> 
> So 7.5% growth.
Okay, I see.

>>> 
>>> Yes, i have also reworked the inline metrics somehwat and spent quite
>>> some time looking into dumps to see that it behaves reasonably.  There
>>> was two ages old bugs I fixed in last two weeks and also added some
>>> extra tricks like penalizing cross-module inlines some time ago. Given
>>> the fact that even with profile feedback I am not able to sort the
>>> priority queue well and neither can Clang do the job, I think it is good
>>> motivation to adjust the parameter which I have set somewhat arbitrarily
>>> at a time I was not able to test it well.
>> 
>> where is the code for your current heuristic to sorting the inlinable 
>> candidates?
> 
> It is in ipa-inline.c:edge-badness
> If you use -fdump-ipa-inline-details you can search for "Considering" in
> the dump file to find record about every inline decision. It dumps the
> badness value and also the individual values used to compute it.

thanks, will take a look on it.

Qing
> 

Re: [patch, rfa] Fix PR other/16615, change "can not" to "cannot" throughout docs and code

[Joseph Myers]

On Tue, 8 Jan 2019, Sandra Loosemore wrote:

> Here are the ChangeLogs for the new patch series.  Parts 1, 2, and 3 are
> mechanically generated via sed (etc).  Part 4 is the hand-edited changes,
> identical to part 2 of the previous series except for excluding a couple
> files.  Part 5 is the regenerated gcc.pot file.  Does this version look OK to
> commit?

OK.  Presumably the Go and D maintainers may wish to apply those changes 
from the previous patch version, following the processes used for those 
directories.

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

[PATCH, d] Committed update copyright years of d/dmd sources

[Iain Buclaw]

Hi,

Happy belated new year, this patch updates copyright years of all
d/dmd sources, which are purposefully skipped by the
contrib/update-copyright.py script.

Committed to trunk as r267778.

-- 
Iain
---
diff --git a/gcc/d/dmd/MERGE b/gcc/d/dmd/MERGE
index bc35d4adc1f..feb65923273 100644
--- a/gcc/d/dmd/MERGE
+++ b/gcc/d/dmd/MERGE
@@ -1,4 +1,4 @@
-237ca3fbe8f9ac4b64e26ce912c20439ee4fc63a
+6d5b853d30908638d49210ebe600917296b8ab9b
 
 The first line of this file holds the git revision number of the last
 merge done from the dlang/dmd repository.
diff --git a/gcc/d/dmd/access.c b/gcc/d/dmd/access.c
index cd60cedc2a5..73951a78bc5 100644
--- a/gcc/d/dmd/access.c
+++ b/gcc/d/dmd/access.c
@@ -1,5 +1,5 @@
 /* Compiler implementation of the D programming language
- * Copyright (C) 1999-2018 by The D Language Foundation, All Rights Reserved
+ * Copyright (C) 1999-2019 by The D Language Foundation, All Rights Reserved
  * written by Walter Bright
  * http://www.digitalmars.com
  * Distributed under the Boost Software License, Version 1.0.
diff --git a/gcc/d/dmd/aggregate.h b/gcc/d/dmd/aggregate.h
index cac0b8efd9f..881be58f2b8 100644
--- a/gcc/d/dmd/aggregate.h
+++ b/gcc/d/dmd/aggregate.h
@@ -1,6 +1,6 @@
 
 /* Compiler implementation of the D programming language
- * Copyright (C) 1999-2018 by The D Language Foundation, All Rights Reserved
+ * Copyright (C) 1999-2019 by The D Language Foundation, All Rights Reserved
  * written by Walter Bright
  * http://www.digitalmars.com
  * Distributed under the Boost Software License, Version 1.0.
diff --git a/gcc/d/dmd/aliasthis.c b/gcc/d/dmd/aliasthis.c
index f4d627ff42d..9653e98027d 100644
--- a/gcc/d/dmd/aliasthis.c
+++ b/gcc/d/dmd/aliasthis.c
@@ -1,6 +1,6 @@
 
 /* Compiler implementation of the D programming language
- * Copyright (C) 2009-2018 by The D Language Foundation, All Rights Reserved
+ * Copyright (C) 2009-2019 by The D Language Foundation, All Rights Reserved
  * written by Walter Bright
  * http://www.digitalmars.com
  * Distributed under the Boost Software License, Version 1.0.
diff --git a/gcc/d/dmd/aliasthis.h b/gcc/d/dmd/aliasthis.h
index 290ccd63088..df176072db9 100644
--- a/gcc/d/dmd/aliasthis.h
+++ b/gcc/d/dmd/aliasthis.h
@@ -1,6 +1,6 @@
 
 /* Compiler implementation of the D programming language
- * Copyright (C) 2009-2018 by The D Language Foundation, All Rights Reserved
+ * Copyright (C) 2009-2019 by The D Language Foundation, All Rights Reserved
  * written by Walter Bright
  * http://www.digitalmars.com
  * Distributed under the Boost Software License, Version 1.0.
diff --git a/gcc/d/dmd/apply.c b/gcc/d/dmd/apply.c
index bec32a892e2..c5e0289b9e0 100644
--- a/gcc/d/dmd/apply.c
+++ b/gcc/d/dmd/apply.c
@@ -1,6 +1,6 @@
 
 /* Compiler implementation of the D programming language
- * Copyright (C) 1999-2018 by The D Language Foundation, All Rights Reserved
+ * Copyright (C) 1999-2019 by The D Language Foundation, All Rights Reserved
  * written by Walter Bright
  * http://www.digitalmars.com
  * Distributed under the Boost Software License, Version 1.0.
diff --git a/gcc/d/dmd/argtypes.c b/gcc/d/dmd/argtypes.c
index c37d48a3691..bed1d4020ab 100644
--- a/gcc/d/dmd/argtypes.c
+++ b/gcc/d/dmd/argtypes.c
@@ -1,6 +1,6 @@
 
 /* Compiler implementation of the D programming language
- * Copyright (C) 2010-2018 by The D Language Foundation, All Rights Reserved
+ * Copyright (C) 2010-2019 by The D Language Foundation, All Rights Reserved
  * written by Walter Bright
  * http://www.digitalmars.com
  * Distributed under the Boost Software License, Version 1.0.
diff --git a/gcc/d/dmd/arrayop.c b/gcc/d/dmd/arrayop.c
index 91c1b76e4ab..859e964b156 100644
--- a/gcc/d/dmd/arrayop.c
+++ b/gcc/d/dmd/arrayop.c
@@ -1,6 +1,6 @@
 
 /* Compiler implementation of the D programming language
- * Copyright (C) 1999-2018 by The D Language Foundation, All Rights Reserved
+ * Copyright (C) 1999-2019 by The D Language Foundation, All Rights Reserved
  * written by Walter Bright
  * http://www.digitalmars.com
  * Distributed under the Boost Software License, Version 1.0.
diff --git a/gcc/d/dmd/arraytypes.h b/gcc/d/dmd/arraytypes.h
index a3d305ed8e3..3ee95c760b1 100644
--- a/gcc/d/dmd/arraytypes.h
+++ b/gcc/d/dmd/arraytypes.h
@@ -1,6 +1,6 @@
 
 /* Compiler implementation of the D programming language
- * Copyright (C) 2006-2018 by The D Language Foundation, All Rights Reserved
+ * Copyright (C) 2006-2019 by The D Language Foundation, All Rights Reserved
  * written by Walter Bright
  * http://www.digitalmars.com
  * Distributed under the Boost Software License, Version 1.0.
diff --git a/gcc/d/dmd/attrib.c b/gcc/d/dmd/attrib.c
index 05728518ff1..e4ad5739e73 100644
--- a/gcc/d/dmd/attrib.c
+++ b/gcc/d/dmd/attrib.c
@@ -1,6 +1,6 @@
 
 /* Compiler implementation of the D programming language
- * Copyright (C) 1999-2018 by The D Language Foundation, All Rights Reserved
+ * Copyright (C) 1999-2019 by The D Language Foundation, All Rights Reserved
  * written by Walter Bright
  * http://www.digit

Re: [PATCH][AArch64] Use Q-reg loads/stores in movmem expansion

[James Greenhalgh]

On Fri, Dec 21, 2018 at 06:30:49AM -0600, Kyrill Tkachov wrote:
> Hi all,
> 
> Our movmem expansion currently emits TImode loads and stores when copying 
> 128-bit chunks.
> This generates X-register LDP/STP sequences as these are the most preferred 
> registers for that mode.
> 
> For the purpose of copying memory, however, we want to prefer Q-registers.
> This uses one fewer register, so helping with register pressure.
> It also allows merging of 256-bit and larger copies into Q-reg LDP/STP, 
> further helping code size.
> 
> The implementation of that is easy: we just use a 128-bit vector mode 
> (V4SImode in this patch)
> rather than a TImode.
> 
> With this patch the testcase:
> #define N 8
> int src[N], dst[N];
> 
> void
> foo (void)
> {
>__builtin_memcpy (dst, src, N * sizeof (int));
> }
> 
> generates:
> foo:
>  adrpx1, src
>  add x1, x1, :lo12:src
>  adrpx0, dst
>  add x0, x0, :lo12:dst
>  ldp q1, q0, [x1]
>  stp q1, q0, [x0]
>  ret
> 
> instead of:
> foo:
>  adrpx1, src
>  add x1, x1, :lo12:src
>  adrpx0, dst
>  add x0, x0, :lo12:dst
>  ldp x2, x3, [x1]
>  stp x2, x3, [x0]
>  ldp x2, x3, [x1, 16]
>  stp x2, x3, [x0, 16]
>  ret
> 
> Bootstrapped and tested on aarch64-none-linux-gnu.
> I hope this is a small enough change for GCC 9.
> One could argue that it is finishing up the work done this cycle to support 
> Q-register LDP/STPs
> 
> I've seen this give about 1.8% on 541.leela_r on Cortex-A57 with other 
> changes in SPEC2017 in the noise
> but there is reduction in code size everywhere (due to more LDP/STP-Q pairs 
> being formed)
> 
> Ok for trunk?

I'm surprised by the logic. If we want to use 256-bit copies, shouldn't we
be explicit about that in the movmem code, rather than using 128-bit copies
that get merged. Why do TImode loads require two X registers? Shouldn't we
just fix TImode loads to use Q registers if that is preferable?

I'm not opposed to the principle of using LDP-Q in our movmem, but is this
the best way to make that happen?

Thanks,
James

> 2018-12-21  Kyrylo Tkachov  
> 
>  * config/aarch64/aarch64.c (aarch64_expand_movmem): Use V4SImode for
>  128-bit moves.
> 
> 2018-12-21  Kyrylo Tkachov  
> 
>  * gcc.target/aarch64/movmem-q-reg_1.c: New test.

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Joseph Myers]

On Wed, 9 Jan 2019, Joseph Myers wrote:

> Also, could you clarify what, in the patch 
>  (if that's 
> still the current version),
> 
> > +  add_sysrooted_hdrs_prefix (&prefixes, argv[2], NULL, 0, 0, false);
> 
> is doing (that is, examples of what sort of prefixes it's adding)?

(I guess this indicates something for the next revision of the patch - if 
each add_sysrooted_hdrs_prefix call has a comment indicating the sort of 
path you expect to be searched, e.g. 
/usr/include/finclude/, that would help both review and 
subsequent readers of the code.)

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

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Joseph Myers]

On Wed, 9 Jan 2019, Martin Liška wrote:

> Hi.
> 
> May I please ping that Joseph. The provided patch should be applicable and
> I would need help with the proper locations.

I'm not clear if there is a specific question here, or a patch needing 
review.  In  I 
noted a specific issue: TOOL_INCLUDE_DIR should be a non-sysrooted prefix.

Also, could you clarify what, in the patch 
 (if that's 
still the current version),

> +  add_sysrooted_hdrs_prefix (&prefixes, argv[2], NULL, 0, 0, false);

is doing (that is, examples of what sort of prefixes it's adding)?

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

Re: [PATCH 2/2] PR libstdc++/86756 Move rest of std::filesystem to libstdc++.so

[Jonathan Wakely]

On 09/01/19 13:53 +0100, Christophe Lyon wrote:

On Wed, 9 Jan 2019 at 11:11, Jonathan Wakely  wrote:


On 09/01/19 10:09 +, Jonathan Wakely wrote:
>On 08/01/19 11:13 +0100, Christophe Lyon wrote:
>>On Mon, 7 Jan 2019 at 15:14, Christophe Lyon  
wrote:
>>>
>>>On Mon, 7 Jan 2019 at 13:39, Jonathan Wakely  wrote:

 On 07/01/19 09:48 +, Jonathan Wakely wrote:
 >On 07/01/19 10:24 +0100, Christophe Lyon wrote:
 >>Hi Jonathan
 >>
 >>On Sun, 6 Jan 2019 at 23:37, Jonathan Wakely  wrote:
 >>>
 >>>Move std::filesystem directory iterators and operations from
 >>>libstdc++fs.a to main libstdc++ library. These components have many
 >>>dependencies on OS support, which is not available on all targets. Some
 >>>additional autoconf checks and conditional compilation is needed to
 >>>ensure the files will build for all targets. Previously this code was
 >>>not compiled without --enable-libstdcxx-filesystem-ts but the C++17
 >>>components should be available for all hosted builds.
 >>>
 >>>The tests for these components no longer need to link to libstdc++fs.a,
 >>>but are not expected to pass on all targets. To avoid numerous failures
 >>>on targets which are not expected to pass the tests (due to missing OS
 >>>functionality) leave the dg-require-filesystem-ts directives in place
 >>>for now. This will ensure the tests only run for builds where the
 >>>filesystem-ts library is built, which presumably means some level of OS
 >>>support is present.
 >>>
 >>>
 >>>Tested x86_64-linux (old/new string ABIs, 32/64 bit), 
x86_64-w64-mingw32.
 >>>
 >>>Committed to trunk.
 >>>
 >>
 >>After this commit (r267616), I've noticed build failures for my
 >>newlib-based toolchains:
 >>aarch64-elf, arm-eabi:
 >>
 >>In file included from
 
>>/tmp/5241593_7.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/src/c++17/fs_ops.cc:57:
 
>>/tmp/5241593_7.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/src/c++17/../filesystem/ops-common.h:142:11:
 >>error: '::truncate' has not been declared
 >> 142 |   using ::truncate;
 >> |   ^~~~
 
>>/tmp/5241593_7.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/src/c++17/fs_ops.cc:
 >>In function 'void std::filesystem::resize_file(const
 >>std::filesystem::__cxx11::path&, uintmax_t, std::error_code&)':
 
>>/tmp/5241593_7.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/src/c++17/fs_ops.cc:1274:19:
 >>error: 'truncate' is not a member of 'posix'
 >>1274 |   else if (posix::truncate(p.c_str(), size))
 >> |   ^~~~
 >>make[5]: *** [fs_ops.lo] Error 1
 >>
 >>I'm not sure if there's an obvious fix? Note that I'm using a rather
 >>old newlib version, if that matters.
 >
 >That's probably the reason, as I didn't see this in my tests with
 >newlib builds.
 >
 >The fix is to add yet another autoconf check and guard the uses of
 >truncate with a _GLIBCXX_USE_TRUNCATE macro. I'll do that now ...


 Should be fixed with this patch, committed to trunk as r267647.

>>>
>>>Yes, it works. Thanks!
>>>
>>
>>Hi Jonathan,
>>
>>So... this was a confirmation that the GCC build succeeded, not that
>>the tests pass :)
>>
>>And there are actually a couple new errors with my newlib-based toolchains:
>>FAIL: 27_io/filesystem/operations/all.cc (test for excess errors)
>>FAIL: 27_io/filesystem/operations/resize_file.cc (test for excess errors)
>>FAIL: 27_io/filesystem/path/generation/normal2.cc (test for excess errors)
>>which are also UNRESOLVED, because of link-time undefined reference to 
`chdir',
>>chmod, mkdir, pathconf and getcwd.
>
>Ah, I was assuming if  is present, then those basic
>functions will be present. More autoconf checks needed, I guess.
>That isn't hard to do, just tedious.
>
>>On aarch64, I'm seeing an addtional:
>>FAIL: 27_io/filesystem/path/compare/strings.cc execution test
>>because:
>>/libstdc++-v3/testsuite/27_io/filesystem/path/compare/strings.cc:39:
>>void test01(): Assertion 'p.compare(p0) == p.compare(s0)' failed.
>
>Odd, I don't know why that would be target-specific. It's probably
>just latent on other targets. I'll try to reproduce it on my aarch64
>system, but it will take a while to build current trunk.
>
>If you have time, could you please apply this patch, re-run that test

*This* patch:

--- a/libstdc++-v3/testsuite/27_io/filesystem/path/compare/strings.cc
+++ b/libstdc++-v3/testsuite/27_io/filesystem/path/compare/strings.cc
@@ -36,6 +36,7 @@ test01()
 path p(s);
 VERIFY( p.compare(s) == 0 );
 VERIFY( p.compare(s.c_str()) == 0 );
+__builtin_printf("Comparing %s as path:%d as string:%d\n", s.c_str(), 
p.compare(p0), p.compare(s0));
 VERIFY( p.compare(p0) == p.compare(s0) );
 VERIFY( p.compare(p0) == p.compare(s0.c_str()) );
   }




>(cd $target/libstdc++-v3 && make check
>RU

Re: [RFC] Update Stage 4 description

[Joseph Myers]

On Wed, 9 Jan 2019, Paul Koning wrote:

> Is there, or should there be, a distinction between primary and 
> non-primary platforms?  While platform bugs typically require fixes in 
> platform-specific code, I would think we would want to stay away from 
> bugfixes in minor platforms during stage 4.  The wording seems to say 
> that I could fix wrong-code bugs in pdp11 during stage 4; I have been 
> assuming I should not do that.  Is this something that should be 
> explicitly stated?

In target-specific code for a minor target you can more or less do as you 
want - but the decision on when to branch won't take account of what 
you're doing for a minor target, so any major work runs the risk of the 
branch happening at an unstable point in the middle of that work.

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

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Martin Liška]

On 11/30/18 2:51 PM, Martin Liška wrote:
> On 11/27/18 2:40 PM, Martin Liška wrote:
>> On 11/26/18 7:44 PM, Joseph Myers wrote:
>>> On Mon, 26 Nov 2018, Martin Liška wrote:
>>>
> I don't see how this version ensures that NATIVE_SYSTEM_HEADER_DIR is 
> properly sysrooted.  Note there's add_sysrooted_prefix separate from 
> add_prefix (but that's *not* the correct thing to use here because it 
> uses 
> target_sysroot_suffix whereas you need target_sysroot_hdrs_suffix).

 I address that in updated version of the patch.
>>>
>>> However, this version seems to make TOOL_INCLUDE_DIR sysrooted as well.  
>>> I don't think that's correct; TOOL_INCLUDE_DIR ($prefix/$target/include, 
>>> roughly) is a non-sysroot location for headers.  Note that it's not 
>>> sysrooted in cppdefault.c, which is a good guide to which directories 
>>> should or should not be sysrooted, and what order they should come in 
>>> (though as discussed, various of the directories there are not relevant 
>>> for the present issue).
>>>
>>> The patch appears to be against some tree other than current trunk.  At 
>>> least, it shows a function find_fortran_preinclude_file in gcc.c as 
>>> already existing in the diff context, but I see no such function in the 
>>> current sources.
>>>
>>
>> I've just installed a prerequisite patch and now you should be able
>> to apply the patch on top of current trunk.
>>
>> Thanks,
>> Martin
>>
> 
> Hi Joseph.
> 
> About this: I'll be away for next 3 weeks and I'm planning to return to
> this once I'm back. If you find a spare cycles and help me with the
> location which should be searched in find_fortran_preinclude_file, I would
> be happy ;)

Hi.

May I please ping that Joseph. The provided patch should be applicable and
I would need help with the proper locations.

Thanks,
Martin

> 
> Thanks,
> Martin
> 

[C++ Patch] Fix three locations

[Paolo Carlini]

Hi,

three additional fixes along the usual lines. In the grokdeclarator 
changes I'm not touching the actual printing of the name, but another 
option would be using %qD and decl here too, thus, for cases like 
parse/crash43.C, where everything lives inside a namespace, we would 
print 'N::i'. instead of simply 'i'. Tested x86_64-linux, plus I checked 
by hand with a cross-compiler the dllimport bit.


Thanks, Paolo.



/cp
2019-01-09  Paolo Carlini  

* decl.c (start_decl): Improve error location.
(grokdeclarator): Likewise, improve two locations.

/testsuite
2019-01-09  Paolo Carlini  

* g++.dg/diagnostic/extern-initialized.C: New.
* g++.dg/ext/dllimport-initialized.C: Likewise.
Index: cp/decl.c
===
--- cp/decl.c   (revision 267756)
+++ cp/decl.c   (working copy)
@@ -5096,7 +5096,8 @@ start_decl (const cp_declarator *declarator,
  a definition.  */
   if (initialized && DECL_DLLIMPORT_P (decl))
 {
-  error ("definition of %q#D is marked %", decl);
+  error_at (DECL_SOURCE_LOCATION (decl),
+   "definition of %q#D is marked %", decl);
   DECL_DLLIMPORT_P (decl) = 0;
 }
 
@@ -12791,11 +12792,13 @@ grokdeclarator (const cp_declarator *declarator,
/* It's common practice (and completely valid) to have a const
   be initialized and declared extern.  */
if (!(type_quals & TYPE_QUAL_CONST))
- warning (0, "%qs initialized and declared %", name);
+ warning_at (DECL_SOURCE_LOCATION (decl), 0,
+ "%qs initialized and declared %", name);
  }
else
  {
-   error ("%qs has both % and initializer", name);
+   error_at (DECL_SOURCE_LOCATION (decl),
+ "%qs has both % and initializer", name);
return error_mark_node;
  }
   }
Index: testsuite/g++.dg/diagnostic/extern-initialized.C
===
--- testsuite/g++.dg/diagnostic/extern-initialized.C(nonexistent)
+++ testsuite/g++.dg/diagnostic/extern-initialized.C(working copy)
@@ -0,0 +1,6 @@
+extern int i __attribute__((unused)) = 0;  // { dg-warning "12:.i. initialized 
and declared .extern." }
+
+void foo()
+{
+  extern int i __attribute__((unused)) = 0;  // { dg-error "14:.i. has both 
.extern. and initializer" }
+}
Index: testsuite/g++.dg/ext/dllimport-initialized.C
===
--- testsuite/g++.dg/ext/dllimport-initialized.C(nonexistent)
+++ testsuite/g++.dg/ext/dllimport-initialized.C(working copy)
@@ -0,0 +1,3 @@
+// { dg-do compile { target i?86-*-cygwin* i?86-*-mingw* x86_64-*-mingw* } }
+
+__attribute__((dllimport)) int i __attribute__((unused)) = 0;  // { dg-error 
"32:definition of .int i. is marked .dllimport." }

Re: [PATCH 6/9][GCC][AArch64] Add Armv8.3-a complex intrinsics

[James Greenhalgh]

On Fri, Dec 21, 2018 at 11:57:55AM -0600, Tamar Christina wrote:
> Hi All,
> 
> This updated patch adds NEON intrinsics and tests for the Armv8.3-a complex
> multiplication and add instructions with a rotate along the Argand plane.
> 
> The instructions are documented in the ArmARM[1] and the intrinsics 
> specification
> will be published on the Arm website [2].
> 
> The Lane versions of these instructions are special in that they always 
> select a pair.
> using index 0 means selecting lane 0 and 1.  Because of this the range check 
> for the
> intrinsics require special handling.
> 
> There're a few complexities with the intrinsics for the laneq variants for 
> AArch64:
> 
> 1) The architecture does not have a version for V2SF. However since the 
> instructions always
>selects a pair of values, the only valid index for V2SF would have been 0. 
> As such the lane
>versions for V2SF are all mapped to the 3SAME variant of the instructions 
> and not the By element
>variant.
> 
> 2) Because of no# 1 above, the laneq versions of the instruction become 
> tricky. The valid indices are 0 and 1.
>For index 0 we treat it the same as the lane version of this instruction 
> and just pass the lower half of the
>register to the 3SAME instruction.  When index is 1 we extract the upper 
> half of the register and pass that to
>the 3SAME version of the instruction.
> 
> 2) The architecture forbits the laneq version of the V4HF instruction from 
> having an index greater than 1.  For index 0-1
>we do no extra work. For index 2-3 we extract the upper parts of the 
> register and pass that to the instruction it would
>have normally used, and re-map the index into a range of 0-1.
> 
> [1] 
> https://developer.arm.com/docs/ddi0487/latest/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile
> [2] https://developer.arm.com/docs/101028/latest
> 
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> Additional runtime checks done but not posted with the patch.
> 
> Ok for trunk?

OK with a refactor.

This isn't a great fit for Stage 4, but it is also completely self-contained.

I hope we can slow down new content in the AArch64 back-end and start
stabilising the port for release.

Thanks,
James

> @@ -1395,6 +1494,80 @@ aarch64_expand_builtin (tree exp,
>   }
>  
>return target;
> +
> +case AARCH64_SIMD_BUILTIN_FCMLA_LANEQ0_V2SF:
> +case AARCH64_SIMD_BUILTIN_FCMLA_LANEQ90_V2SF:
> +case AARCH64_SIMD_BUILTIN_FCMLA_LANEQ180_V2SF:
> +case AARCH64_SIMD_BUILTIN_FCMLA_LANEQ270_V2SF:
> +case AARCH64_SIMD_BUILTIN_FCMLA_LANEQ0_V4HF:
> +case AARCH64_SIMD_BUILTIN_FCMLA_LANEQ90_V4HF:
> +case AARCH64_SIMD_BUILTIN_FCMLA_LANEQ180_V4HF:
> +case AARCH64_SIMD_BUILTIN_FCMLA_LANEQ270_V4HF:

Pull all of this out to a new function please.

> +  int bcode = fcode - AARCH64_SIMD_FCMLA_LANEQ_BUILTIN_BASE - 1;
> +  aarch64_fcmla_laneq_builtin_datum* d
> + = &aarch64_fcmla_lane_builtin_data[bcode];
> +  machine_mode quadmode = GET_MODE_2XWIDER_MODE (d->mode).require ();
> +  op0 = force_reg (d->mode, expand_normal (CALL_EXPR_ARG (exp, 0)));
> +  rtx op1 = force_reg (d->mode, expand_normal (CALL_EXPR_ARG (exp, 1)));
> +  rtx op2 = force_reg (quadmode, expand_normal (CALL_EXPR_ARG (exp, 2)));
> +  tree tmp = CALL_EXPR_ARG (exp, 3);
> +  rtx lane_idx = expand_expr (tmp, NULL_RTX, VOIDmode, 
> EXPAND_INITIALIZER);
> +
> +  /* Validate that the lane index is a constant.  */
> +  if (!CONST_INT_P (lane_idx))
> + {
> +   error ("%Kargument %d must be a constant immediate", exp, 4);
> +   return const0_rtx;
> + }
> +
> +  /* Validate that the index is within the expected range.  */
> +  int nunits = GET_MODE_NUNITS (quadmode).to_constant ();
> +  aarch64_simd_lane_bounds (lane_idx, 0, nunits / 2, exp);
> +
> +  /* Keep to GCC-vector-extension lane indices in the RTL.  */
> +  lane_idx = aarch64_endian_lane_rtx (quadmode, INTVAL (lane_idx));
> +
> +  /* Generate the correct register and mode.  */
> +  int lane = INTVAL (lane_idx);
> +
> +  if (lane < nunits / 4)
> + op2 = simplify_gen_subreg (d->mode, op2, quadmode, 0);
> +  else
> + {
> +   /* Select the upper 64 bits, either a V2SF or V4HF, this however
> +  is quite messy, as the operation required even though simple
> +  doesn't have a simple RTL pattern, and seems it's quite hard to
> +  define using a single RTL pattern.  The target generic version
> +  gen_highpart_mode generates code that isn't optimal.  */
> +   rtx temp1 = gen_reg_rtx (d->mode);
> +   rtx temp2 = gen_reg_rtx (DImode);
> +   temp1 = simplify_gen_subreg (d->mode, op2, quadmode, 0);
> +   temp1 = simplify_gen_subreg (V2DImode, temp1, d->mode, 0);
> +   emit_insn (gen_aarch64_get_lanev2di (temp2, temp1 , const1_rtx));
> +   op2 = simplify_gen_subreg (d->mode, temp2, GE

Integrated Systems Europe 2019 - Visitors List

[sarah.miller]

Hello & Good Day to you!

We wanted to check if you would be interested in acquiring Integrated
Systems Europe 2019 (International Trade Show for Computer, Electronics,
Electrical Engineering, Integrated Systems, Electronic Systems, Audiovisual
and Av Industry) attendees list to increase prospect flow at your booth -
Product launch- Brand awareness - increase Sales - Annual marketing Etc.

Information Provided: - Company name, URL, Contact name, Job title, Phone
number, fax number, physical address, Industry, Company size, Email address.

 

Let me know if you are interested so that we can provide you the number of
Attendees and the cost.

 

Look forward to your reply.

 

Best Regards,

 

Sarah Miller

B2B Marketing & Tradeshow Specialist

 

If you do not wish to receive the attendees list, please reply as 'Opt-out'.

 



---
This email has been checked for viruses by AVG.
https://www.avg.com

[SPARC] Use P mode iterator in more cases

[Eric Botcazou]

On the heels of the TLS patch, this also changes some basic patterns (almost) 
identical in 32-bit and 64-bit modes into patterns using the P mode iterator.

Tested on SPARC/Solaris 11, applied on mainline and 8 branch.


2019-01-09  Eric Botcazou  

* config/sparc/sparc.md (*tablejump_sp32): Merge into...
(*tablejump_sp64): Likewise.
(*tablejump): ...this.
(*call_address_sp32): Merge into...
(*call_address_sp64): Likewise.
(*call_address): ...this.
(*call_symbolic_sp32): Merge into...
(*call_symbolic_sp64): Likewise.
(*call_symbolic): ...this.
(call_value): Remove constraint and add predicate.
(*call_value_address_sp32): Merge into...
(*call_value_address_sp64): Likewise.
(*call_value_address): ...this.
(*call_value_symbolic_sp32): Merge into...
(*call_value_symbolic_sp64): Likewise.
(*call_value_symbolic): ...this.
(*sibcall_symbolic_sp32): Merge into...
(*sibcall_symbolic_sp64): Likewise.
(*sibcall_symbolic): ...this.
(sibcall_value): Remove constraint and add predicate.
(*sibcall_value_symbolic_sp32): Merge into...
(*sibcall_value_symbolic_sp64): Likewise.
(*sibcall_value_symbolic): ...this.
(window_save): Minor tweak.
(*branch_sp32): Merge into...
(*branch_sp64): Likewise.
(*branch): ...this.

-- 
Eric BotcazouIndex: config/sparc/sparc.md
===
--- config/sparc/sparc.md	(revision 267574)
+++ config/sparc/sparc.md	(working copy)
@@ -6842,17 +6842,10 @@ (define_expand "tablejump"
 }
 })
 
-(define_insn "*tablejump_sp32"
-  [(set (pc) (match_operand:SI 0 "address_operand" "p"))
+(define_insn "*tablejump"
+  [(set (pc) (match_operand:P 0 "address_operand" "p"))
(use (label_ref (match_operand 1 "" "")))]
-  "TARGET_ARCH32"
-  "jmp\t%a0%#"
-  [(set_attr "type" "uncond_branch")])
-
-(define_insn "*tablejump_sp64"
-  [(set (pc) (match_operand:DI 0 "address_operand" "p"))
-   (use (label_ref (match_operand 1 "" "")))]
-  "TARGET_ARCH64"
+  ""
   "jmp\t%a0%#"
   [(set_attr "type" "uncond_branch")])
 
@@ -6929,39 +6922,21 @@ (define_expand "call"
 ;; We can't use the same pattern for these two insns, because then registers
 ;; in the address may not be properly reloaded.
 
-(define_insn "*call_address_sp32"
-  [(call (mem:SI (match_operand:SI 0 "address_operand" "p"))
-	 (match_operand 1 "" ""))
-   (clobber (reg:SI O7_REG))]
-  ;;- Do not use operand 1 for most machines.
-  "TARGET_ARCH32"
-  "call\t%a0, %1%#"
-  [(set_attr "type" "call")])
-
-(define_insn "*call_symbolic_sp32"
-  [(call (mem:SI (match_operand:SI 0 "symbolic_operand" "s"))
+(define_insn "*call_address"
+  [(call (mem:P (match_operand:P 0 "address_operand" "p"))
 	 (match_operand 1 "" ""))
-   (clobber (reg:SI O7_REG))]
+   (clobber (reg:P O7_REG))]
   ;;- Do not use operand 1 for most machines.
-  "TARGET_ARCH32"
-  "call\t%a0, %1%#"
-  [(set_attr "type" "call")])
-
-(define_insn "*call_address_sp64"
-  [(call (mem:DI (match_operand:DI 0 "address_operand" "p"))
-	 (match_operand 1 "" ""))
-   (clobber (reg:DI O7_REG))]
-  ;;- Do not use operand 1 for most machines.
-  "TARGET_ARCH64"
+  ""
   "call\t%a0, %1%#"
   [(set_attr "type" "call")])
 
-(define_insn "*call_symbolic_sp64"
-  [(call (mem:DI (match_operand:DI 0 "symbolic_operand" "s"))
+(define_insn "*call_symbolic"
+  [(call (mem:P (match_operand:P 0 "symbolic_operand" "s"))
 	 (match_operand 1 "" ""))
-   (clobber (reg:DI O7_REG))]
+   (clobber (reg:P O7_REG))]
   ;;- Do not use operand 1 for most machines.
-  "TARGET_ARCH64"
+  ""
   "call\t%a0, %1%#"
   [(set_attr "type" "call")])
 
@@ -7026,8 +7001,8 @@ (define_insn "*call_symbolic_untyped_str
 (define_expand "call_value"
   ;; Note that this expression is not used for generating RTL.
   ;; All the RTL is generated explicitly below.
-  [(set (match_operand 0 "register_operand" "=rf")
-	(call (match_operand 1 "" "")
+  [(set (match_operand 0 "register_operand" "")
+	(call (match_operand 1 "call_operand" "")
 	  (match_operand 4 "" "")))]
   ;; operand 2 is stack_size_rtx
   ;; operand 3 is next_arg_register
@@ -7050,43 +7025,23 @@ (define_expand "call_value"
   DONE;
 })
 
-(define_insn "*call_value_address_sp32"
-  [(set (match_operand 0 "" "=rf")
-	(call (mem:SI (match_operand:SI 1 "address_operand" "p"))
-	  (match_operand 2 "" "")))
-   (clobber (reg:SI O7_REG))]
-  ;;- Do not use operand 2 for most machines.
-  "TARGET_ARCH32"
-  "call\t%a1, %2%#"
-  [(set_attr "type" "call")])
-
-(define_insn "*call_value_symbolic_sp32"
-  [(set (match_operand 0 "" "=rf")
-	(call (mem:SI (match_operand:SI 1 "symbolic_operand" "s"))
-	  (match_operand 2 "" "")))
-   (clobber (reg:SI O7_REG))]
-  ;;- Do not use operand 2 for most machines.
-  "TARGET_ARCH32"
-  "call\t%a1, %2%#"
-  [(set_attr "type" "call")])
-
-(define_insn "*call_value_address_sp64"
+(def

[SPARC] Fix PR target/84010

[Eric Botcazou]

This fixes the problematic generation of TLS addresses on 64-bit SPARC, which 
doesn't take into account the TLS relaxation that can be done by the linker.
It can turn positive offsets to the GOT register %l7 into negative offsets to 
the thread register %g7 so the offsets must be computed in DImode for 64-bit 
SPARC, lest they be spilled onto the stack and reloaded as 32-bit values.

James remarked that there is one case where the offsets can safely stay SImode 
but I have changed it too for the sake of consistency and simplicity.

The patch also contains testcases for the patterns combining %tldo_add with 
some integer loads or stores in the local-dynamic model.

Tested on SPARC/Solaris 11, applied on all active branches.


2019-01-09  Eric Botcazou  
James Clarke  

PR target/84010
* config/sparc/sparc.c (sparc_legitimize_tls_address): Only use Pmode
consistently in TLS address generation and adjust code to the renaming
of patterns.  Mark calls to __tls_get_addr as const.
* config/sparc/sparc.md (tgd_hi22): Turn into...
(tgd_hi22): ...this and use Pmode throughout.
(tgd_lo10): Turn into...
(tgd_lo10): ...this and use Pmode throughout.
(tgd_add32): Merge into...
(tgd_add64): Likewise.
(tgd_add): ...this and use Pmode throughout.
(tldm_hi22): Turn into...
(tldm_hi22): ...this and use Pmode throughout.
(tldm_lo10): Turn into...
(tldm_lo10): ...this and use Pmode throughout.
(tldm_add32): Merge into...
(tldm_add64): Likewise.
(tldm_add): ...this and use Pmode throughout.
(tldm_call32): Merge into...
(tldm_call64): Likewise.
(tldm_call): ...this and use Pmode throughout.
(tldo_hix22): Turn into...
(tldo_hix22): ...this and use Pmode throughout.
(tldo_lox10): Turn into...
(tldo_lox10): ...this and use Pmode throughout.
(tldo_add32): Merge into...
(tldo_add64): Likewise.
(tldo_add): ...this and use Pmode throughout.
(tie_hi22): Turn into...
(tie_hi22): ...this and use Pmode throughout.
(tie_lo10): Turn into...
(tie_lo10): ...this and use Pmode throughout.
(tie_ld64): Use DImode throughout.
(tie_add32): Merge into...
(tie_add64): Likewise.
(tie_add): ...this and use Pmode throughout.
(tle_hix22_sp32): Merge into...
(tle_hix22_sp64): Likewise.
(tle_hix22): ...this and use Pmode throughout.
(tle_lox22_sp32): Merge into...
(tle_lox22_sp64): Likewise.
(tle_lox22): ...this and use Pmode throughout.
(*tldo_ldub_sp32): Merge into...
(*tldo_ldub_sp64): Likewise.
(*tldo_ldub): ...this and use Pmode throughout.
(*tldo_ldub1_sp32): Merge into...
(*tldo_ldub1_sp64): Likewise.
(*tldo_ldub1): ...this and use Pmode throughout.
(*tldo_ldub2_sp32): Merge into...
(*tldo_ldub2_sp64): Likewise.
(*tldo_ldub2): ...this and use Pmode throughout.
(*tldo_ldsb1_sp32): Merge into...
(*tldo_ldsb1_sp64): Likewise.
(*tldo_ldsb1): ...this and use Pmode throughout.
(*tldo_ldsb2_sp32): Merge into...
(*tldo_ldsb2_sp64): Likewise.
(*tldo_ldsb2): ...this and use Pmode throughout.
(*tldo_ldub3_sp64): Use DImode throughout.
(*tldo_ldsb3_sp64): Likewise.
(*tldo_lduh_sp32): Merge into...
(*tldo_lduh_sp64): Likewise.
(*tldo_lduh): ...this and use Pmode throughout.
(*tldo_lduh1_sp32): Merge into...
(*tldo_lduh1_sp64): Likewise.
(*tldo_lduh1): ...this and use Pmode throughout.
(*tldo_ldsh1_sp32): Merge into...
(*tldo_ldsh1_sp64): Likewise.
(*tldo_ldsh1): ...this and use Pmode throughout.
(*tldo_lduh2_sp64): Use DImode throughout.
(*tldo_ldsh2_sp64): Likewise.
(*tldo_lduw_sp32): Merge into...
(*tldo_lduw_sp64): Likewise.
(*tldo_lduw): ...this and use Pmode throughout.
(*tldo_lduw1_sp64): Use DImode throughout.
(*tldo_ldsw1_sp64): Likewise.
(*tldo_ldx_sp64): Likewise.
(*tldo_stb_sp32): Merge into...
(*tldo_stb_sp64): Likewise.
(*tldo_stb): ...this and use Pmode throughout.
(*tldo_sth_sp32): Merge into...
(*tldo_sth_sp64): Likewise.
(*tldo_sth): ...this and use Pmode throughout.
(*tldo_stw_sp32): Merge into...
(*tldo_stw_sp64): Likewise.
(*tldo_stw): ...this and use Pmode throughout.
(*tldo_stx_sp64): Use DImode throughout.


2019-01-09  Eric Botcazou  

* gcc.target/sparc/tls-ld-int8.c: New test.
* gcc.target/sparc/tls-ld-int16.c: Likewise.
* gcc.target/sparc/tls-ld-int32.c: Likewise.
* gcc.target/sparc/tls-ld-uint8.c: Likewise.
* gcc.target/sparc/tls-ld-uint16.c: Likewise.
* gcc.target/sparc/tls-ld-uint32.c: Likewise.

-

Re: [PATCH, GCC, AARCH64, 5/6] Enable BTI : Add new pass for BTI.

[Sudakshina Das]

Hi

On 20/12/18 16:40, Sudakshina Das wrote:
> Hi James
> 
> On 19/12/18 3:40 PM, James Greenhalgh wrote:
>> On Fri, Dec 14, 2018 at 10:09:03AM -0600, Sudakshina Das wrote:
>>
>> 
>>
>>> I have updated the patch according to our discussions offline.
>>> The md pattern is now split into 4 patterns and i have added a new
>>> test for the setjmp case along with some comments where missing.
>>
>> This is OK for trunk.
>>
> 
> Thanks for the approvals. With this my series is ready to go in trunk. I 
> will wait for Sam's options patch to go in trunk before I commit mine.
> 

Series is committed with a rebase without Sam Tebbs's 3rd patch for 
B-Key addition as r267765 to r267770.

Thanks
Sudi

> Thanks
> Sudi
> 
>> Thanks,
>> James
>>
>>> *** gcc/ChangeLog ***
>>>
>>> 2018-xx-xx  Sudakshina Das  
>>>     Ramana Radhakrishnan  
>>>
>>> * config.gcc (aarch64*-*-*): Add aarch64-bti-insert.o.
>>> * gcc/config/aarch64/aarch64.h: Update comment for
>>> TRAMPOLINE_SIZE.
>>> * config/aarch64/aarch64.c (aarch64_asm_trampoline_template):
>>> Update if bti is enabled.
>>> * config/aarch64/aarch64-bti-insert.c: New file.
>>> * config/aarch64/aarch64-passes.def (INSERT_PASS_BEFORE): Insert
>>> bti pass.
>>> * config/aarch64/aarch64-protos.h (make_pass_insert_bti):
>>> Declare the new bti pass.
>>> * config/aarch64/aarch64.md (unspecv): Add UNSPECV_BTI_NOARG,
>>> UNSPECV_BTI_C, UNSPECV_BTI_J and UNSPECV_BTI_JC.
>>> (bti_noarg, bti_j, bti_c, bti_jc): New define_insns.
>>> * config/aarch64/t-aarch64: Add rule for aarch64-bti-insert.o.
>>>
>>> *** gcc/testsuite/ChangeLog ***
>>>
>>> 2018-xx-xx  Sudakshina Das  
>>>
>>> * gcc.target/aarch64/bti-1.c: New test.
>>> * gcc.target/aarch64/bti-2.c: New test.
>>> * gcc.target/aarch64/bti-3.c: New test.
>>> * lib/target-supports.exp
>>> (check_effective_target_aarch64_bti_hw): Add new check for
>>> BTI hw.
>>>
>>> Thanks
>>> Sudi

Re: Remove overall growth from badness metrics

[Jan Hubicka]

> Looks like that our current documentation has a bug in the below:
> 
> https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html 
> 
> 
> -finline-functions
> Consider all functions for inlining, even if they are not declared inline. 
> The compiler heuristically decides which functions are worth integrating in 
> this way.
> If all calls to a given function are integrated, and the function is declared 
> static, then the function is normally not output as assembler code in its own 
> right.
> Enabled at levels -O2, -O3, -Os. Also enabled by -fprofile-use and 
> -fauto-profile.
> 
> It clearly mentioned that -finline-functions is enabled at -O2, O3, -Os. 
> 
> And I checked the gcc9 source code, opts.c:
> 
> /* -O3 and -Os optimizations.  */
> /* Inlining of functions reducing size is a good idea with -Os
>regardless of them being declared inline.  */
> { OPT_LEVELS_3_PLUS_AND_SIZE, OPT_finline_functions, NULL, 1 },
> 
> looks like that -finline-functions is ONLY enabled at -O3 and -Os, not for O2.
> (However, I am confused with why -finline-functions should be enabled for 
> -Os?)

yes, it is documentation bug. Seems like Eric beat me on fixing it.
> 
> >> 
> >>> 
> >>> In my test bed this included Firefox with or without LTO becuase they do
> >>> "poor man's" LTO by #including multiple .cpp files into single unified
> >>> source which makes average units large.  Also tramp3d, DLV from our C++
> >>> benhcmark is affected. 
> >>> 
> >>> I have some data on Firefox and I will build remainin ones:
> >> in the following, are the data for code size? are the optimization level 
> >> O3?
> >> what’s PGO mean?  
> > 
> > Those are sizes of libxul, which is the largest library of Firefox.
> > PGO is profile guided optimization.
> 
> Okay.  I see. 
> 
> looks like for LTO,  the code size increase with profiling is much smaller 
> than
> that without profiling when growth is increased from 20% to 40%.  

With LTo the growth is about 9%, while for non-LTO is about about 4% and
with PGO it is about 3%.  This is expected.

For non-LTO most of translation units do not hit the limit becuase most
of calls are external. Firefox is bit special here by using the #include
based unified build that gets it closer to LTO, but not quite.

With LTO there is only one translation unit that hits the 20% code size
growth that after optimization translates to that 9%

With profilef feedback code is partitioned into cold and hot sections
where only hot section growths by the given percentage. For firefox
about 15% of the binary is trained and rest is cold.
> 
> for Non-LTO, the code size increase is minimal when growth is increased fro 
> 20% to 40%.
> 
> However, not quite understand the last column, could you please explain a 
> little bit
> on last column (-finline-functions)?

It is non-lto build but with additional -finline-functions.

GCC build machinery uses -O2 by default and -O3 for some files. Adding
-finline-functions enables agressive inlining everywhere.  But double
checking the numbers, I must have cut&pasted wrong data here.  For
growth 20 -finline-functions non-LTO non-PGO I get 107272791 (so table
is wrong) and increasing growth to 40 gets me 115311719 (which is
correct in the table)
> 
> >>> 
> >>> growthLTO+PGOPGO   LTOnone  
> >>> -finline-functions
> >>> 20 (default)   83752215   94390023  93085455  103437191  94351191
> >>> 40 85299111   97220935  101600151 108910311  115311719
> >>> clang  111520431114863807 108437807

It should be:
growth  LTO+PGOPGO   LTOnone  -finline-functions
20 (default)   83752215   94390023  93085455  103437191  107272791
40 85299111   97220935  101600151 108910311  115311719
clang  111520431114863807 108437807

So 7.5% growth.
> > I was poking about this for a while, but did not really have very good
> > testcases available making it difficult to judge code size/performance
> > tradeoffs here.  With Firefox I can measure things better now and
> > it is clear that 20% growth is just too small. It is small even with
> > profile feedback where compiler knows quite well what calls to inline
> > and more so without.
> 
> Yes, for C++, 20% might be too small, especially for cross-file inlining.
> and C++ applications usually benefit more from inlining. 

Yep, that is my conclussion too.
> 
> >> 
> >> When increasing the value of inline-unit-growth for LTO is one approach to 
> >> resolve this issue, adjusting
> >> the sorting heuristic to sort those important and smaller routines as 
> >> higher priority to be inlined might be
> >> another and better approach? 
> > 
> > Yes, i have also reworked the inline metrics somehwat and spent quite
> > some time looking into dumps to see that it behaves reasonably.  There
> > was two ages old bugs I fixed in last two weeks and also added some
> > extra tr

Re: [RFC] Update Stage 4 description

[Richard Biener]

On Wed, 9 Jan 2019, Paul Koning wrote:

> 
> 
> > On Jan 9, 2019, at 3:42 AM, Tom de Vries  wrote:
> > 
> > [ To revisit https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00385.html ]
> > 
> > The current formulation for the description of Stage 4 here (
> > https://gcc.gnu.org/develop.html ) is:
> > ...
> > During this period, the only (non-documentation) changes that may be
> > made are changes that fix regressions.
> > 
> > Other changes may not be done during this period.
> > 
> > Note that the same constraints apply to release branches.
> > 
> > This period lasts until stage 1 opens for the next release.
> > ...
> > 
> > This updated formulation was proposed by Richi (with a request for
> > review of wording):
> > ...
> > During this period, the only (non-documentation) changes that may
> > be made are changes that fix regressions.
> > 
> > -Other changes may not be done during this period.
> > +Other important bugs like wrong-code, rejects-valid or build issues may
> > +be fixed as well.  All changes during this period should be done with
> > +extra care on not introducing new regressions - fixing bugs at all cost
> > +is not wanted.
> ...
> 
> Is there, or should there be, a distinction between primary and non-primary 
> platforms?  While platform bugs typically require fixes in platform-specific 
> code, I would think we would want to stay away from bugfixes in minor 
> platforms during stage 4.  The wording seems to say that I could fix 
> wrong-code bugs in pdp11 during stage 4; I have been assuming I should not do 
> that.  Is this something that should be explicitly stated?

I think it's somewhere stated that during Stage 3 non-primary/secondary 
targets as well as non-C/C++ languages have no restrictions.  Of course
while technically true breaking builds is still not wanted.

For Stage 4 things are somewhat different I think, not sure if it's 
anywhere spelled out.

Richard.

Re: [RFC] Update Stage 4 description

[Paul Koning]

> On Jan 9, 2019, at 3:42 AM, Tom de Vries  wrote:
> 
> [ To revisit https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00385.html ]
> 
> The current formulation for the description of Stage 4 here (
> https://gcc.gnu.org/develop.html ) is:
> ...
> During this period, the only (non-documentation) changes that may be
> made are changes that fix regressions.
> 
> Other changes may not be done during this period.
> 
> Note that the same constraints apply to release branches.
> 
> This period lasts until stage 1 opens for the next release.
> ...
> 
> This updated formulation was proposed by Richi (with a request for
> review of wording):
> ...
> During this period, the only (non-documentation) changes that may
> be made are changes that fix regressions.
> 
> -Other changes may not be done during this period.
> +Other important bugs like wrong-code, rejects-valid or build issues may
> +be fixed as well.  All changes during this period should be done with
> +extra care on not introducing new regressions - fixing bugs at all cost
> +is not wanted.
...

Is there, or should there be, a distinction between primary and non-primary 
platforms?  While platform bugs typically require fixes in platform-specific 
code, I would think we would want to stay away from bugfixes in minor platforms 
during stage 4.  The wording seems to say that I could fix wrong-code bugs in 
pdp11 during stage 4; I have been assuming I should not do that.  Is this 
something that should be explicitly stated?

paul

Re: [Aarch64][SVE] Add copysign and xorsign support

[Kyrill Tkachov]

Hi all,

On 09/01/19 12:26, Richard Sandiford wrote:

Alejandro Martinez Vicente  writes:
> Hi,
>
> I updated the patch to address Wilco's comment and style issues.

OK, thanks.



I've committed this on Alejandro's behalf with r267764.


As discussed internally, I think for GCC 10 we should instead make
the vectoriser replace copysign with logic ops if the target has
no better implementation.  This would be similar to the existing code
for lowering multiplications by a constant on targets that don't have
general multiplication.



I agree. We should create an enhancement request in bugzilla to track this.

Thanks,
Kyrill


But this optimisation is important for SPEC, and at the moment we have
it for Advanced SIMD and not SVE, which with stretched reasoning you
could call a regression introduced by the SVE port.  So the patch seems
OK for GCC 9 as a functionally-correct contingency until we can do
this "properly".

Sorry that this is stretching stage 4 rules a bit.  I don't think we
have any other similar patches queued up for GCC 9.

Richard

Re: [PATCH 2/2] PR libstdc++/86756 Move rest of std::filesystem to libstdc++.so

[Christophe Lyon]

On Wed, 9 Jan 2019 at 11:11, Jonathan Wakely  wrote:
>
> On 09/01/19 10:09 +, Jonathan Wakely wrote:
> >On 08/01/19 11:13 +0100, Christophe Lyon wrote:
> >>On Mon, 7 Jan 2019 at 15:14, Christophe Lyon  
> >>wrote:
> >>>
> >>>On Mon, 7 Jan 2019 at 13:39, Jonathan Wakely  wrote:
> 
>  On 07/01/19 09:48 +, Jonathan Wakely wrote:
>  >On 07/01/19 10:24 +0100, Christophe Lyon wrote:
>  >>Hi Jonathan
>  >>
>  >>On Sun, 6 Jan 2019 at 23:37, Jonathan Wakely  
>  >>wrote:
>  >>>
>  >>>Move std::filesystem directory iterators and operations from
>  >>>libstdc++fs.a to main libstdc++ library. These components have many
>  >>>dependencies on OS support, which is not available on all targets. 
>  >>>Some
>  >>>additional autoconf checks and conditional compilation is needed to
>  >>>ensure the files will build for all targets. Previously this code was
>  >>>not compiled without --enable-libstdcxx-filesystem-ts but the C++17
>  >>>components should be available for all hosted builds.
>  >>>
>  >>>The tests for these components no longer need to link to 
>  >>>libstdc++fs.a,
>  >>>but are not expected to pass on all targets. To avoid numerous 
>  >>>failures
>  >>>on targets which are not expected to pass the tests (due to missing OS
>  >>>functionality) leave the dg-require-filesystem-ts directives in place
>  >>>for now. This will ensure the tests only run for builds where the
>  >>>filesystem-ts library is built, which presumably means some level of 
>  >>>OS
>  >>>support is present.
>  >>>
>  >>>
>  >>>Tested x86_64-linux (old/new string ABIs, 32/64 bit), 
>  >>>x86_64-w64-mingw32.
>  >>>
>  >>>Committed to trunk.
>  >>>
>  >>
>  >>After this commit (r267616), I've noticed build failures for my
>  >>newlib-based toolchains:
>  >>aarch64-elf, arm-eabi:
>  >>
>  >>In file included from
>  >>/tmp/5241593_7.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/src/c++17/fs_ops.cc:57:
>  >>/tmp/5241593_7.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/src/c++17/../filesystem/ops-common.h:142:11:
>  >>error: '::truncate' has not been declared
>  >> 142 |   using ::truncate;
>  >> |   ^~~~
>  >>/tmp/5241593_7.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/src/c++17/fs_ops.cc:
>  >>In function 'void std::filesystem::resize_file(const
>  >>std::filesystem::__cxx11::path&, uintmax_t, std::error_code&)':
>  >>/tmp/5241593_7.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/src/c++17/fs_ops.cc:1274:19:
>  >>error: 'truncate' is not a member of 'posix'
>  >>1274 |   else if (posix::truncate(p.c_str(), size))
>  >> |   ^~~~
>  >>make[5]: *** [fs_ops.lo] Error 1
>  >>
>  >>I'm not sure if there's an obvious fix? Note that I'm using a rather
>  >>old newlib version, if that matters.
>  >
>  >That's probably the reason, as I didn't see this in my tests with
>  >newlib builds.
>  >
>  >The fix is to add yet another autoconf check and guard the uses of
>  >truncate with a _GLIBCXX_USE_TRUNCATE macro. I'll do that now ...
> 
> 
>  Should be fixed with this patch, committed to trunk as r267647.
> 
> >>>
> >>>Yes, it works. Thanks!
> >>>
> >>
> >>Hi Jonathan,
> >>
> >>So... this was a confirmation that the GCC build succeeded, not that
> >>the tests pass :)
> >>
> >>And there are actually a couple new errors with my newlib-based toolchains:
> >>FAIL: 27_io/filesystem/operations/all.cc (test for excess errors)
> >>FAIL: 27_io/filesystem/operations/resize_file.cc (test for excess errors)
> >>FAIL: 27_io/filesystem/path/generation/normal2.cc (test for excess errors)
> >>which are also UNRESOLVED, because of link-time undefined reference to 
> >>`chdir',
> >>chmod, mkdir, pathconf and getcwd.
> >
> >Ah, I was assuming if  is present, then those basic
> >functions will be present. More autoconf checks needed, I guess.
> >That isn't hard to do, just tedious.
> >
> >>On aarch64, I'm seeing an addtional:
> >>FAIL: 27_io/filesystem/path/compare/strings.cc execution test
> >>because:
> >>/libstdc++-v3/testsuite/27_io/filesystem/path/compare/strings.cc:39:
> >>void test01(): Assertion 'p.compare(p0) == p.compare(s0)' failed.
> >
> >Odd, I don't know why that would be target-specific. It's probably
> >just latent on other targets. I'll try to reproduce it on my aarch64
> >system, but it will take a while to build current trunk.
> >
> >If you have time, could you please apply this patch, re-run that test
>
> *This* patch:
>
> --- a/libstdc++-v3/testsuite/27_io/filesystem/path/compare/strings.cc
> +++ b/libstdc++-v3/testsuite/27_io/filesystem/path/compare/strings.cc
> @@ -36,6 +36,7 @@ test01()
>  path p(s);
>  VERIFY( p.compare(s) == 0 );
>  VERIFY( p.compare(s.c_str()) == 0 );
> +__builtin_printf("Comparing 

[PATCH, og8] Update _OPENACC macro, etc. for OpenACC 2.6

[Julian Brown]

Hi,

This patch updates the _OPENACC macro to 201711, indicating OpenACC 2.6
support, on the openacc-gcc-8-branch. Tested with offloading to NVPTX.

I will apply shortly.

Cheers,

Julian
commit e2ff11ceee7f1294313773d013a9d68f0d4e3c02
Author: Julian Brown 
Date:   Wed Jan 9 03:41:04 2019 -0800

[og8] Update OpenACC version to 2.6

	gcc/c-family/
	* c-cppbuiltin.c (c_cpp_builtins): Update _OPENACC define to 201711.

	gcc/doc/
	* invoke.texi: Update mention of OpenACC version to 2.6.

	gcc/fortran/
	* cpp.c (cpp_define_builtins): Update _OPENACC define to 201711.
	* gfortran.texi: Update mentions of OpenACC version to 2.6.
	* intrinsic.texi: Likewise.

	gcc/testsuite/
	* c-c++-common/cpp/openacc-define-3.c: Update expected value for
	_OPENACC define.
	* gfortran.dg/openacc-define-3.f90: Likewise.

	libgomp/
	* acc_prof.h (_ACC_PROF_INFO_VERSION): Update to 201711.
	* libgomp.texi: Update mentions of OpenACC version to 2.6.  Update
	section numbers to match version 2.6 of the spec.
	* openacc.f90 (openacc_version): Update to 201711.
	* openacc_lib.h (openacc_version): Update to 201711.
	* testsuite/libgomp.oacc-c-c++-common/acc_prof-version-1.c
	(cb_any_event): Update expected profiling info version to 201711.
	* testsuite/libgomp.oacc-fortran/openacc_version-1.f: Update expected
	openacc_version to 201711.
	* testsuite/libgomp.oacc-fortran/openacc_version-2.f90: Likewise.

diff --git a/gcc/c-family/c-cppbuiltin.c b/gcc/c-family/c-cppbuiltin.c
index fe83981..949cc9a 100644
--- a/gcc/c-family/c-cppbuiltin.c
+++ b/gcc/c-family/c-cppbuiltin.c
@@ -1387,7 +1387,7 @@ c_cpp_builtins (cpp_reader *pfile)
 cpp_define (pfile, "__SSP__=1");
 
   if (flag_openacc)
-cpp_define (pfile, "_OPENACC=201510");
+cpp_define (pfile, "_OPENACC=201711");
 
   if (flag_openmp)
 cpp_define (pfile, "_OPENMP=201511");
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index eab399d..085a871 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -2138,7 +2138,7 @@ freestanding and hosted environments.
 Enable handling of OpenACC directives @code{#pragma acc} in C/C++ and
 @code{!$acc} in Fortran.  When @option{-fopenacc} is specified, the
 compiler generates accelerated code according to the OpenACC Application
-Programming Interface v2.5 @w{@uref{https://www.openacc.org}}.  This option
+Programming Interface v2.6 @w{@uref{https://www.openacc.org}}.  This option
 implies @option{-pthread}, and thus is only supported on targets that
 have support for @option{-pthread}.
 
diff --git a/gcc/fortran/cpp.c b/gcc/fortran/cpp.c
index 0d2af2e..11f97ab 100644
--- a/gcc/fortran/cpp.c
+++ b/gcc/fortran/cpp.c
@@ -165,7 +165,7 @@ cpp_define_builtins (cpp_reader *pfile)
   cpp_define (pfile, "_LANGUAGE_FORTRAN=1");
 
   if (flag_openacc)
-cpp_define (pfile, "_OPENACC=201510");
+cpp_define (pfile, "_OPENACC=201711");
 
   if (flag_openmp)
 cpp_define (pfile, "_OPENMP=201511");
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 6dd6682..8cfe716 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -538,7 +538,7 @@ Additionally, the GNU Fortran compilers supports the OpenMP specification
 (version 4.0 and most of the features of the 4.5 version,
 @url{http://openmp.org/@/wp/@/openmp-specifications/}).
 There also is support for the OpenACC specification (targeting
-version 2.5, @uref{http://www.openacc.org/}).  See
+version 2.6, @uref{http://www.openacc.org/}).  See
 @uref{https://gcc.gnu.org/wiki/OpenACC} for more information.
 
 @node Varying Length Character Strings
@@ -2132,7 +2132,7 @@ influence run-time behavior.
 
 GNU Fortran strives to be compatible to the
 @uref{http://www.openacc.org/, OpenACC Application Programming
-Interface v2.5}.
+Interface v2.6}.
 
 To enable the processing of the OpenACC directive @code{!$acc} in
 free-form source code; the @code{c$acc}, @code{*$acc} and @code{!$acc}
diff --git a/gcc/fortran/intrinsic.texi b/gcc/fortran/intrinsic.texi
index 761b575..df94873 100644
--- a/gcc/fortran/intrinsic.texi
+++ b/gcc/fortran/intrinsic.texi
@@ -14862,7 +14862,7 @@ kind @code{omp_proc_bind_kind}:
 @section OpenACC Module @code{OPENACC}
 @table @asis
 @item @emph{Standard}:
-OpenACC Application Programming Interface v2.5
+OpenACC Application Programming Interface v2.6
 @end table
 
 
@@ -14876,9 +14876,9 @@ are listed below.
 
 For details refer to the actual
 @uref{http://www.openacc.org/,
-OpenACC Application Programming Interface v2.5}.
+OpenACC Application Programming Interface v2.6}.
 
 @code{OPENACC} provides the scalar default-integer
 named constant @code{openacc_version} with a value of the form
 @var{mm}, where @code{} is the year and @var{mm} the month
-of the OpenACC version; for OpenACC v2.5 the value is @code{201510}.
+of the OpenACC version; for OpenACC v2.6 the value is @code{201711}.
diff --git a/gcc/testsuite/c-c++-

Re: [Aarch64][SVE] Add copysign and xorsign support

[Richard Sandiford]

Alejandro Martinez Vicente  writes:
> Hi,
>
> I updated the patch to address Wilco's comment and style issues.

OK, thanks.

As discussed internally, I think for GCC 10 we should instead make
the vectoriser replace copysign with logic ops if the target has
no better implementation.  This would be similar to the existing code
for lowering multiplications by a constant on targets that don't have
general multiplication.

But this optimisation is important for SPEC, and at the moment we have
it for Advanced SIMD and not SVE, which with stretched reasoning you
could call a regression introduced by the SVE port.  So the patch seems
OK for GCC 9 as a functionally-correct contingency until we can do
this "properly".

Sorry that this is stretching stage 4 rules a bit.  I don't think we
have any other similar patches queued up for GCC 9.

Richard

RE: [Aarch64][SVE] Add copysign and xorsign support

[Alejandro Martinez Vicente]

Hi,

I updated the patch to address Wilco's comment and style issues.

Alejandro


> -Original Message-
> From: Wilco Dijkstra 
> Sent: 08 January 2019 16:58
> To: GCC Patches ; Alejandro Martinez Vicente
> 
> Cc: nd ; Richard Sandiford 
> Subject: Re: [Aarch64][SVE] Add copysign and xorsign support
> 
> Hi Alejandro,
> 
> +emit_move_insn (mask,
> + aarch64_simd_gen_const_vector_dup
> (mode,
> +HOST_WIDE_INT_M1U
> +<< bits));
> +
> +emit_insn (gen_and3 (sign, arg2, mask));
> 
> Is there a reason to emit separate moves and then requiring the optimizer to
> combine them? The result of aarch64_simd_gen_const_vector_dup can be
> used directly in the gen_and for all supported floating point types.
> 
> Cheers,
> Wilco


copysign_2.patch
Description: copysign_2.patch

Re: [PATCH] PR libstdc++/88204 disable std::complex tests

[Segher Boessenkool]

On Wed, Jan 09, 2019 at 11:14:37AM +0100, Jakub Jelinek wrote:
> Or is double-double considered dead format that will hopefully soon go
> away, not worth spending more time on?

It won't go away soon, but I think we should treat it as legacy format.

Currently, to use ieee128 you need either hardware that has support for it
(i.e. Power9), or a system with VSX for the emulation (i.e. Power7 or later).

If ieee128 was supported on all systems (and then, not just Power), we could
perhaps phase out double-double (take a big performance hit but get a lot of
sanity back for it).  But until then there is really no other option --
plain double as long double is a big step back.

And we'll probably need to support double double on older systems until
those systems go away completely, anyway :-/


Segher

Re: Question on Disable no throw for -flive-patching master option.

[Martin Liška]

Honza: PING^2

On 1/2/19 12:47 PM, Martin Liška wrote:
> Honza: PING
> 
> On 12/6/18 12:16 AM, Qing Zhao wrote:
>> Hi, Honza,
>>
>> I have one question relate to whether to disable nothrow for -flive-patching 
>> as following:
>>
>> actually, there are two passes here:
>>
>> 1. local nothrow pass:  in this pass, nothrow attribute is set locally after 
>> analyzing every stmt of the function
>> body: 
>>
>> unsigned int
>> pass_nothrow::execute (function *)
>> {
>>   struct cgraph_node *node;
>>   basic_block this_block;
>> …
>>
>> }
>>
>> 2. nothrow propagation pass:  (it’s included in the ipa_pure_const pass as 
>> following, propagate the nothrow 
>> attribute along callcgraph)
>>
>> unsigned int
>> pass_ipa_pure_const::
>> execute (function *)
>> {
>>   bool remove_p;
>>
>>   /* Nothrow makes more function to not lead to return and improve
>>      later analysis.  */
>>   propagate_nothrow ();
>>   propagate_malloc ();
>>   remove_p = propagate_pure_const ();
>>
>>   delete funct_state_summaries;
>>   return remove_p ? TODO_remove_functions : 0;
>> }
>>
>> the nothrow propagation pass is included in ipa_pure_const pass, and is 
>> guarded by flag_ipa_pure_const, 
>> this flag_ipa_pure_const is disabled when -flive-patching is ON.
>>
>>
>> So, my question is:
>>
>> shall we disable local nothrow pass as well when -flive-patching is ON?
>>
>> my understanding is: we should. 
>>
>> the reason is:   the local nothrow pass is setting the nothrow attribute for 
>> the current routine based on its
>> body,  and this “nothrow” attribute will be used  when generating EH code 
>> around callsite from the caller
>> of the routine. so the nothrow attribute might impact other routines than 
>> the current routine.  as a result,
>> we should disable this pass?
>>
>> what’s your opinion on this?
>>
>> thanks.
>>
>> Qing
>>
>>> On Nov 28, 2018, at 2:24 PM, Qing Zhao >> > wrote:

 Shall we also disable nothrow or we will worry about C++ only ter?
>>>
>>> This is also mainly for C++ applications, so currently should not be a 
>>> problem.
>>> But I can add a separate simple patch to add another flag to control 
>>> nothrow propagation and disable it when -flive-patching is ON.
>>>

 Patch is OK,
>>>
>>> thanks for the review.
>>>
>>> I will commit the patch very soon.
>>>
>>> Qing
 thanks!
 Honza
>>

Re: [PATCH] Pretty printer test fixes and improvements

[Jonathan Wakely]

On 09/01/19 10:14 +, Jonathan Wakely wrote:

On 09/01/19 11:09 +0100, Christophe Lyon wrote:

On Wed, 9 Jan 2019 at 00:16, Jonathan Wakely  wrote:


Test that StdUniquePtrPrinter correctly prints std::unique_ptr objects
using the old layout, prior to the PR libstdc++/77990 changes.

The printer test for a valueless std::variant started to fail because
the PR libstdc++/87431 fix meant it no longer became valueless. Change
the test to use a type that is not trivially copyable, so that the
exception causes it to become valueless.

   * testsuite/libstdc++-prettyprinters/compat.cc: Test printer support
   for old std::unique_ptr layout.
   * testsuite/libstdc++-prettyprinters/cxx17.cc: Fix std::variant test
   to become valueless. Add filesystem::path tests.

Tested x86_64-linux, committed to trunk.



Hi Jonathan,

After this patch, I've noticed a new failure on aarch64:
FAIL: libstdc++-prettyprinters/cxx17.cc print p2

The log contains:
PASS: libstdc++-prettyprinters/cxx17.cc print p1
$27 = filesystem::path "/dir/." = {[root-directory] = "/", [1] =
"dir", [2] = "."}
got: $27 = filesystem::path "/dir/." = {[root-directory] = "/", [1] =
"dir", [2] = "."}
FAIL: libstdc++-prettyprinters/cxx17.cc print p2


Hmm, that's the expected output. I wonder why it fails.


Oh, it's not the expected output at all. I'm being dumb.

I am seeing that failure too, but didn't notice it along with all the
existing ones caused by PR 88170 (which was also the problem with the
std::variant failure fixed in r267743).

The attached patch fixes it, committed to trunk.



commit 622a802a907585da9a9266a8d4eb3401cc24f9fe
Author: Jonathan Wakely 
Date:   Wed Jan 9 10:45:00 2019 +

Fix failing prettyprinter test

The failure for "p2" went unnoticed due to the pre-existing failures for
variables with similar names, like "p" and "q". This fixes the failure,
and gives the filesystem::path variables better names.

* testsuite/libstdc++-prettyprinters/cxx17.cc: Fix expected output
for filesystem::path. Give variables more distinctive names.

diff --git a/libstdc++-v3/testsuite/libstdc++-prettyprinters/cxx17.cc b/libstdc++-v3/testsuite/libstdc++-prettyprinters/cxx17.cc
index c550cbd61bd..4ed4d47240f 100644
--- a/libstdc++-v3/testsuite/libstdc++-prettyprinters/cxx17.cc
+++ b/libstdc++-v3/testsuite/libstdc++-prettyprinters/cxx17.cc
@@ -124,12 +124,12 @@ main()
 // { dg-final { regexp-test q {std::shared_ptr.int \[2\]. \(use count 2, weak count 1\) = {get\(\) = 0x.*}} } }
 // { dg-final { regexp-test wq {std::weak_ptr.int \[2\]. \(use count 2, weak count 1\) = {get\(\) = 0x.*}} } }
 
-  std::filesystem::path p0;
-// { dg-final { note-test p0 {filesystem::path ""} } }
-  std::filesystem::path p1("filename");
-// { dg-final { note-test p1 {filesystem::path "filename"} } }
-  std::filesystem::path p2("/dir/.");
-// { dg-final { note-test p2 {filesystem::path "/dir/file" = {[root-directory] = "/", [1] = "dir", [2] = "."}} } }
+  std::filesystem::path path0;
+// { dg-final { note-test path0 {filesystem::path ""} } }
+  std::filesystem::path path1("filename");
+// { dg-final { note-test path1 {filesystem::path "filename"} } }
+  std::filesystem::path path2("/dir/.");
+// { dg-final { note-test path2 {filesystem::path "/dir/." = {[root-directory] = "/", [1] = "dir", [2] = "."}} } }
 
   std::cout << "\n";
   return 0;			// Mark SPOT

Re: [PATCH] PR libstdc++/87855 fix optional for types with non-trivial copy/move

[Jonathan Wakely]

On 08/01/19 23:00 +, Jonathan Wakely wrote:

When the contained value is not trivially copy (or move) constructible
the union's copy (or move) constructor will be deleted, and so the
_Optional_payload delegating constructors are invalid. G++ fails to
diagnose this because it incorrectly performs copy elision in the
delegating constructors. Clang does diagnose it (llvm.org/PR40245).

The solution is to avoid performing any copy (or move) when the
contained value's copy (or move) constructor isn't trivial. Instead the
contained value can be constructed by calling _M_construct. This is OK,
because the relevant constructor doesn't need to be constexpr when the
contained value isn't trivially copy (or move) constructible.

Additionally, this patch removes a lot of code duplication in the
_Optional_payload partial specializations and the _Optional_base partial
specialization, by hoisting it into common base classes.


This follow-up patch removes a little more code duplication from those
partial specializations.

Tested x86_64-linux. Ville already ack'd this, so I'm committing it to trunk.


commit ffe7a5a74f406fe82b17eec9a68f8e079b5f43e1
Author: Jonathan Wakely 
Date:   Wed Jan 9 10:37:06 2019 +

Remove some more code duplication in std::optional

Hoist the duplicated code from the _Optional_payload partial
specializations into the _Optional_payload_base base class.

* include/std/optional (_Optional_payload_base::_M_copy_assign): New
member function to perform non-trivial assignment.
(_Optional_payload_base::_M_move_assign): Likewise.
(_Optional_payload::operator=)
(_Optional_payload::operator=)
(_Optional_payload::operator=): Call
_M_copy_assign and/or _M_move_assign to do non-trivial assignments.

diff --git a/libstdc++-v3/include/std/optional b/libstdc++-v3/include/std/optional
index b06e30fbd67..c5e66bdd140 100644
--- a/libstdc++-v3/include/std/optional
+++ b/libstdc++-v3/include/std/optional
@@ -157,6 +157,38 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   _Optional_payload_base&
   operator=(_Optional_payload_base&&) = default;
 
+  // used to perform non-trivial copy assignment.
+  constexpr void
+  _M_copy_assign(const _Optional_payload_base& __other)
+  {
+if (this->_M_engaged && __other._M_engaged)
+  this->_M_get() = __other._M_get();
+else
+	  {
+	if (__other._M_engaged)
+	  this->_M_construct(__other._M_get());
+	else
+	  this->_M_reset();
+	  }
+  }
+
+  // used to perform non-trivial move assignment.
+  constexpr void
+  _M_move_assign(_Optional_payload_base&& __other)
+  noexcept(__and_v,
+		   is_nothrow_move_assignable<_Tp>>)
+  {
+	if (this->_M_engaged && __other._M_engaged)
+	  this->_M_get() = std::move(__other._M_get());
+	else
+	  {
+	if (__other._M_engaged)
+	  this->_M_construct(std::move(__other._M_get()));
+	else
+	  this->_M_reset();
+	  }
+  }
+
   struct _Empty_byte { };
 
   template>
@@ -286,15 +318,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   _Optional_payload&
   operator=(const _Optional_payload& __other)
   {
-if (this->_M_engaged && __other._M_engaged)
-  this->_M_get() = __other._M_get();
-else
-	  {
-	if (__other._M_engaged)
-	  this->_M_construct(__other._M_get());
-	else
-	  this->_M_reset();
-	  }
+	this->_M_copy_assign(__other);
 	return *this;
   }
 };
@@ -319,15 +343,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   noexcept(__and_v,
 		   is_nothrow_move_assignable<_Tp>>)
   {
-	if (this->_M_engaged && __other._M_engaged)
-	  this->_M_get() = std::move(__other._M_get());
-	else
-	  {
-	if (__other._M_engaged)
-	  this->_M_construct(std::move(__other._M_get()));
-	else
-	  this->_M_reset();
-	  }
+	this->_M_move_assign(std::move(__other));
 	return *this;
   }
 };
@@ -344,20 +360,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   _Optional_payload(const _Optional_payload&) = default;
   _Optional_payload(_Optional_payload&&) = default;
 
-  // Non-trivial copy
+  // Non-trivial copy assignment.
   constexpr
   _Optional_payload&
   operator=(const _Optional_payload& __other)
   {
-if (this->_M_engaged && __other._M_engaged)
-  this->_M_get() = __other._M_get();
-else
-	  {
-	if (__other._M_engaged)
-	  this->_M_construct(__other._M_get());
-	else
-	  this->_M_reset();
-	  }
+	this->_M_copy_assign(__other);
 	return *this;
   }
 
@@ -368,15 +376,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   noexcept(__and_v,
 		   is_nothrow_move_assignable<_Tp>>)
   {
-	if (this->_M_engaged && __other._M_engaged)
-	  this->_M_get() = std::move(__other._M_get());
-	else
-	  {
-	if (__other._M_engaged)
-	  this->_M_construct(std::move(__other._M_get()));
-	else
-	  this->_M_reset();
-	  }
+	this

Re: [PATCH] PR libstdc++/88204 disable std::complex tests

[Iain Sandoe]

> On 9 Jan 2019, at 10:14, Jakub Jelinek  wrote:
> 
> On Wed, Jan 09, 2019 at 09:37:40AM +, Jonathan Wakely wrote:
>> The IBM128 long double format isn't foldable in constant expressions, so
>> conditionally skip the std::complex cases when they'll
>> fail.
>> 
>>  PR libstdc++/88204
>>  * testsuite/26_numerics/complex/operators/more_constexpr.cc: Do not
>>  test std::complex if long double format is IBM128.
>>  * testsuite/26_numerics/complex/requirements/more_constexpr.cc:
>>  Likewise.
>> 
>> Tested powerpc64le-linux, committed to trunk.
> 
> Thanks for doing that.  Due to the variable number of bits in the mantissa
> unless we represent the double-double constants in the compiler as a pair of
> doubles there will be always many cases that can't be folded.  That said,
> I've been wondering if we couldn't fold at least the basic arithmetics on
> some constants, essentially by emulating what will happen at runtime.  I.e.
> if we want to constant fold PLUS_EXPR (or MINUS_EXPR, MULT_EXPR, *DIV_EXPR,
> and a few others) of two double-double REAL_CSTs, split them into two
> double values by rounding to a double, subtracting that double and rounding
> the remainder to double, perform whatever we emit inline or the runtime
> library does for the basic operations and in the end check if the result of
> that operation fits in the canonical format we pretend for the double-double
> (i.e. the 106 bits mantissa etc.) and if it does, allow constant folding
> that.  E.g. in Red Hat bugzilla I think we have several spots where people
> complain about this lack of folding, it breaks a couple of real-world apps
> etc.  Or is double-double considered dead format that will hopefully soon go
> away, not worth spending more time on?

It’s also 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19779
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26374

in the latter, Andrew Pinski suggests using MPFR, but there’s no patch.

(there might be others in our BZ)

Iain

Re: [PATCH] PR libstdc++/88204 disable std::complex tests

[Jakub Jelinek]

On Wed, Jan 09, 2019 at 09:37:40AM +, Jonathan Wakely wrote:
> The IBM128 long double format isn't foldable in constant expressions, so
> conditionally skip the std::complex cases when they'll
> fail.
> 
>   PR libstdc++/88204
>   * testsuite/26_numerics/complex/operators/more_constexpr.cc: Do not
>   test std::complex if long double format is IBM128.
>   * testsuite/26_numerics/complex/requirements/more_constexpr.cc:
>   Likewise.
> 
> Tested powerpc64le-linux, committed to trunk.

Thanks for doing that.  Due to the variable number of bits in the mantissa
unless we represent the double-double constants in the compiler as a pair of
doubles there will be always many cases that can't be folded.  That said,
I've been wondering if we couldn't fold at least the basic arithmetics on
some constants, essentially by emulating what will happen at runtime.  I.e.
if we want to constant fold PLUS_EXPR (or MINUS_EXPR, MULT_EXPR, *DIV_EXPR,
and a few others) of two double-double REAL_CSTs, split them into two
double values by rounding to a double, subtracting that double and rounding
the remainder to double, perform whatever we emit inline or the runtime
library does for the basic operations and in the end check if the result of
that operation fits in the canonical format we pretend for the double-double
(i.e. the 106 bits mantissa etc.) and if it does, allow constant folding
that.  E.g. in Red Hat bugzilla I think we have several spots where people
complain about this lack of folding, it breaks a couple of real-world apps
etc.  Or is double-double considered dead format that will hopefully soon go
away, not worth spending more time on?

Jakub

Re: [PATCH] Pretty printer test fixes and improvements

[Jonathan Wakely]

On 09/01/19 11:09 +0100, Christophe Lyon wrote:

On Wed, 9 Jan 2019 at 00:16, Jonathan Wakely  wrote:


Test that StdUniquePtrPrinter correctly prints std::unique_ptr objects
using the old layout, prior to the PR libstdc++/77990 changes.

The printer test for a valueless std::variant started to fail because
the PR libstdc++/87431 fix meant it no longer became valueless. Change
the test to use a type that is not trivially copyable, so that the
exception causes it to become valueless.

* testsuite/libstdc++-prettyprinters/compat.cc: Test printer support
for old std::unique_ptr layout.
* testsuite/libstdc++-prettyprinters/cxx17.cc: Fix std::variant test
to become valueless. Add filesystem::path tests.

Tested x86_64-linux, committed to trunk.



Hi Jonathan,

After this patch, I've noticed a new failure on aarch64:
FAIL: libstdc++-prettyprinters/cxx17.cc print p2

The log contains:
PASS: libstdc++-prettyprinters/cxx17.cc print p1
$27 = filesystem::path "/dir/." = {[root-directory] = "/", [1] =
"dir", [2] = "."}
got: $27 = filesystem::path "/dir/." = {[root-directory] = "/", [1] =
"dir", [2] = "."}
FAIL: libstdc++-prettyprinters/cxx17.cc print p2


Hmm, that's the expected output. I wonder why it fails.

Probably some tcl problem, with { or [ being treated as a special
character.


Note that a number of cxx17.cc tests already failed on aarch64, and still fail:
FAIL: libstdc++-prettyprinters/cxx17.cc print p
FAIL: libstdc++-prettyprinters/cxx17.cc print wp
FAIL: libstdc++-prettyprinters/cxx17.cc print q
FAIL: libstdc++-prettyprinters/cxx17.cc print wq


Yes, this is PR 88170.


I've also noticed that the same test names appear twice, I think this confuses
test_summary etc...


Yes, I don't know why they run twice (or maybe they just get printed
twice).

Re: [PATCH 2/2] PR libstdc++/86756 Move rest of std::filesystem to libstdc++.so

[Jonathan Wakely]

On 09/01/19 10:09 +, Jonathan Wakely wrote:

On 08/01/19 11:13 +0100, Christophe Lyon wrote:

On Mon, 7 Jan 2019 at 15:14, Christophe Lyon  wrote:


On Mon, 7 Jan 2019 at 13:39, Jonathan Wakely  wrote:


On 07/01/19 09:48 +, Jonathan Wakely wrote:
>On 07/01/19 10:24 +0100, Christophe Lyon wrote:
>>Hi Jonathan
>>
>>On Sun, 6 Jan 2019 at 23:37, Jonathan Wakely  wrote:
>>>
>>>Move std::filesystem directory iterators and operations from
>>>libstdc++fs.a to main libstdc++ library. These components have many
>>>dependencies on OS support, which is not available on all targets. Some
>>>additional autoconf checks and conditional compilation is needed to
>>>ensure the files will build for all targets. Previously this code was
>>>not compiled without --enable-libstdcxx-filesystem-ts but the C++17
>>>components should be available for all hosted builds.
>>>
>>>The tests for these components no longer need to link to libstdc++fs.a,
>>>but are not expected to pass on all targets. To avoid numerous failures
>>>on targets which are not expected to pass the tests (due to missing OS
>>>functionality) leave the dg-require-filesystem-ts directives in place
>>>for now. This will ensure the tests only run for builds where the
>>>filesystem-ts library is built, which presumably means some level of OS
>>>support is present.
>>>
>>>
>>>Tested x86_64-linux (old/new string ABIs, 32/64 bit), x86_64-w64-mingw32.
>>>
>>>Committed to trunk.
>>>
>>
>>After this commit (r267616), I've noticed build failures for my
>>newlib-based toolchains:
>>aarch64-elf, arm-eabi:
>>
>>In file included from
>>/tmp/5241593_7.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/src/c++17/fs_ops.cc:57:
>>/tmp/5241593_7.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/src/c++17/../filesystem/ops-common.h:142:11:
>>error: '::truncate' has not been declared
>> 142 |   using ::truncate;
>> |   ^~~~
>>/tmp/5241593_7.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/src/c++17/fs_ops.cc:
>>In function 'void std::filesystem::resize_file(const
>>std::filesystem::__cxx11::path&, uintmax_t, std::error_code&)':
>>/tmp/5241593_7.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/src/c++17/fs_ops.cc:1274:19:
>>error: 'truncate' is not a member of 'posix'
>>1274 |   else if (posix::truncate(p.c_str(), size))
>> |   ^~~~
>>make[5]: *** [fs_ops.lo] Error 1
>>
>>I'm not sure if there's an obvious fix? Note that I'm using a rather
>>old newlib version, if that matters.
>
>That's probably the reason, as I didn't see this in my tests with
>newlib builds.
>
>The fix is to add yet another autoconf check and guard the uses of
>truncate with a _GLIBCXX_USE_TRUNCATE macro. I'll do that now ...


Should be fixed with this patch, committed to trunk as r267647.



Yes, it works. Thanks!



Hi Jonathan,

So... this was a confirmation that the GCC build succeeded, not that
the tests pass :)

And there are actually a couple new errors with my newlib-based toolchains:
FAIL: 27_io/filesystem/operations/all.cc (test for excess errors)
FAIL: 27_io/filesystem/operations/resize_file.cc (test for excess errors)
FAIL: 27_io/filesystem/path/generation/normal2.cc (test for excess errors)
which are also UNRESOLVED, because of link-time undefined reference to `chdir',
chmod, mkdir, pathconf and getcwd.


Ah, I was assuming if  is present, then those basic
functions will be present. More autoconf checks needed, I guess.
That isn't hard to do, just tedious.


On aarch64, I'm seeing an addtional:
FAIL: 27_io/filesystem/path/compare/strings.cc execution test
because:
/libstdc++-v3/testsuite/27_io/filesystem/path/compare/strings.cc:39:
void test01(): Assertion 'p.compare(p0) == p.compare(s0)' failed.


Odd, I don't know why that would be target-specific. It's probably
just latent on other targets. I'll try to reproduce it on my aarch64
system, but it will take a while to build current trunk.

If you have time, could you please apply this patch, re-run that test


*This* patch:

--- a/libstdc++-v3/testsuite/27_io/filesystem/path/compare/strings.cc
+++ b/libstdc++-v3/testsuite/27_io/filesystem/path/compare/strings.cc
@@ -36,6 +36,7 @@ test01()
path p(s);
VERIFY( p.compare(s) == 0 );
VERIFY( p.compare(s.c_str()) == 0 );
+__builtin_printf("Comparing %s as path:%d as string:%d\n", s.c_str(), 
p.compare(p0), p.compare(s0));
VERIFY( p.compare(p0) == p.compare(s0) );
VERIFY( p.compare(p0) == p.compare(s0.c_str()) );
  }





(cd $target/libstdc++-v3 && make check
RUNTESTFLAGS=conformance.exp=*/path/compare/strings/cc) and send me
the output from the $target/libstdc++-v3/testsuite/libstdc++.log file?

On x86_64 I get:

Comparing  as path:-1 as string:-1
Comparing / as path:-1 as string:-1
Comparing // as path:-1 as string:-1
Comparing /. as path:-51 as string:-51
Comparing /./ as path:-51 as string:-51
Comparing /a as path:-2 as string:-2
Comparing /a/ as path:-1 as string:-1
Comparing /a// as path:-1 as string:-1
Comparing 

Re: [PATCH 2/2] PR libstdc++/86756 Move rest of std::filesystem to libstdc++.so

[Jonathan Wakely]

On 08/01/19 11:13 +0100, Christophe Lyon wrote:

On Mon, 7 Jan 2019 at 15:14, Christophe Lyon  wrote:


On Mon, 7 Jan 2019 at 13:39, Jonathan Wakely  wrote:
>
> On 07/01/19 09:48 +, Jonathan Wakely wrote:
> >On 07/01/19 10:24 +0100, Christophe Lyon wrote:
> >>Hi Jonathan
> >>
> >>On Sun, 6 Jan 2019 at 23:37, Jonathan Wakely  wrote:
> >>>
> >>>Move std::filesystem directory iterators and operations from
> >>>libstdc++fs.a to main libstdc++ library. These components have many
> >>>dependencies on OS support, which is not available on all targets. Some
> >>>additional autoconf checks and conditional compilation is needed to
> >>>ensure the files will build for all targets. Previously this code was
> >>>not compiled without --enable-libstdcxx-filesystem-ts but the C++17
> >>>components should be available for all hosted builds.
> >>>
> >>>The tests for these components no longer need to link to libstdc++fs.a,
> >>>but are not expected to pass on all targets. To avoid numerous failures
> >>>on targets which are not expected to pass the tests (due to missing OS
> >>>functionality) leave the dg-require-filesystem-ts directives in place
> >>>for now. This will ensure the tests only run for builds where the
> >>>filesystem-ts library is built, which presumably means some level of OS
> >>>support is present.
> >>>
> >>>
> >>>Tested x86_64-linux (old/new string ABIs, 32/64 bit), x86_64-w64-mingw32.
> >>>
> >>>Committed to trunk.
> >>>
> >>
> >>After this commit (r267616), I've noticed build failures for my
> >>newlib-based toolchains:
> >>aarch64-elf, arm-eabi:
> >>
> >>In file included from
> 
>>/tmp/5241593_7.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/src/c++17/fs_ops.cc:57:
> 
>>/tmp/5241593_7.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/src/c++17/../filesystem/ops-common.h:142:11:
> >>error: '::truncate' has not been declared
> >> 142 |   using ::truncate;
> >> |   ^~~~
> 
>>/tmp/5241593_7.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/src/c++17/fs_ops.cc:
> >>In function 'void std::filesystem::resize_file(const
> >>std::filesystem::__cxx11::path&, uintmax_t, std::error_code&)':
> 
>>/tmp/5241593_7.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/src/c++17/fs_ops.cc:1274:19:
> >>error: 'truncate' is not a member of 'posix'
> >>1274 |   else if (posix::truncate(p.c_str(), size))
> >> |   ^~~~
> >>make[5]: *** [fs_ops.lo] Error 1
> >>
> >>I'm not sure if there's an obvious fix? Note that I'm using a rather
> >>old newlib version, if that matters.
> >
> >That's probably the reason, as I didn't see this in my tests with
> >newlib builds.
> >
> >The fix is to add yet another autoconf check and guard the uses of
> >truncate with a _GLIBCXX_USE_TRUNCATE macro. I'll do that now ...
>
>
> Should be fixed with this patch, committed to trunk as r267647.
>

Yes, it works. Thanks!



Hi Jonathan,

So... this was a confirmation that the GCC build succeeded, not that
the tests pass :)

And there are actually a couple new errors with my newlib-based toolchains:
FAIL: 27_io/filesystem/operations/all.cc (test for excess errors)
FAIL: 27_io/filesystem/operations/resize_file.cc (test for excess errors)
FAIL: 27_io/filesystem/path/generation/normal2.cc (test for excess errors)
which are also UNRESOLVED, because of link-time undefined reference to `chdir',
chmod, mkdir, pathconf and getcwd.


Ah, I was assuming if  is present, then those basic
functions will be present. More autoconf checks needed, I guess.
That isn't hard to do, just tedious.


On aarch64, I'm seeing an addtional:
FAIL: 27_io/filesystem/path/compare/strings.cc execution test
because:
/libstdc++-v3/testsuite/27_io/filesystem/path/compare/strings.cc:39:
void test01(): Assertion 'p.compare(p0) == p.compare(s0)' failed.


Odd, I don't know why that would be target-specific. It's probably
just latent on other targets. I'll try to reproduce it on my aarch64
system, but it will take a while to build current trunk.

If you have time, could you please apply this patch, re-run that test
(cd $target/libstdc++-v3 && make check
RUNTESTFLAGS=conformance.exp=*/path/compare/strings/cc) and send me
the output from the $target/libstdc++-v3/testsuite/libstdc++.log file?

On x86_64 I get:

Comparing  as path:-1 as string:-1
Comparing / as path:-1 as string:-1
Comparing // as path:-1 as string:-1
Comparing /. as path:-51 as string:-51
Comparing /./ as path:-51 as string:-51
Comparing /a as path:-2 as string:-2
Comparing /a/ as path:-1 as string:-1
Comparing /a// as path:-1 as string:-1
Comparing /a/b/c/d as path:1 as string:1
Comparing /a//b as path:1 as string:1
Comparing a as path:-1 as string:-1
Comparing a/b as path:-1 as string:-1
Comparing a/b/ as path:-1 as string:-1
Comparing a/b/c as path:-1 as string:-1
Comparing a/b/c.d as path:-1 as string:-1
Comparing a/b/.. as path:-1 as string:-1
Comparing a/b/c. as path:-1 as string:-1
Comparing a/b/.c as path:-1 as string:-1
PASS: 27_io/filesystem/path/compa

Re: [PATCH] Pretty printer test fixes and improvements

[Christophe Lyon]

On Wed, 9 Jan 2019 at 00:16, Jonathan Wakely  wrote:
>
> Test that StdUniquePtrPrinter correctly prints std::unique_ptr objects
> using the old layout, prior to the PR libstdc++/77990 changes.
>
> The printer test for a valueless std::variant started to fail because
> the PR libstdc++/87431 fix meant it no longer became valueless. Change
> the test to use a type that is not trivially copyable, so that the
> exception causes it to become valueless.
>
> * testsuite/libstdc++-prettyprinters/compat.cc: Test printer support
> for old std::unique_ptr layout.
> * testsuite/libstdc++-prettyprinters/cxx17.cc: Fix std::variant test
> to become valueless. Add filesystem::path tests.
>
> Tested x86_64-linux, committed to trunk.
>

Hi Jonathan,

After this patch, I've noticed a new failure on aarch64:
FAIL: libstdc++-prettyprinters/cxx17.cc print p2

The log contains:
PASS: libstdc++-prettyprinters/cxx17.cc print p1
$27 = filesystem::path "/dir/." = {[root-directory] = "/", [1] =
"dir", [2] = "."}
got: $27 = filesystem::path "/dir/." = {[root-directory] = "/", [1] =
"dir", [2] = "."}
FAIL: libstdc++-prettyprinters/cxx17.cc print p2


Note that a number of cxx17.cc tests already failed on aarch64, and still fail:
FAIL: libstdc++-prettyprinters/cxx17.cc print p
FAIL: libstdc++-prettyprinters/cxx17.cc print wp
FAIL: libstdc++-prettyprinters/cxx17.cc print q
FAIL: libstdc++-prettyprinters/cxx17.cc print wq

I've also noticed that the same test names appear twice, I think this confuses
test_summary etc...

Christophe

Re: [Patch 4/4][Aarch64] v2: Implement Aarch64 SIMD ABI

[Richard Sandiford]

Steve Ellcey  writes:
>  /* Implement TARGET_HARD_REGNO_CALL_PART_CLOBBERED.  The callee only saves
> the lower 64 bits of a 128-bit register.  Tell the compiler the callee
> clobbers the top 64 bits when restoring the bottom 64 bits.  */
>  
>  static bool
> -aarch64_hard_regno_call_part_clobbered (unsigned int regno, machine_mode 
> mode)
> +aarch64_hard_regno_call_part_clobbered (rtx_insn *insn, unsigned int regno,
> + machine_mode mode)
>  {
> -  return FP_REGNUM_P (regno) && maybe_gt (GET_MODE_SIZE (mode), 8);
> +  bool simd_p = insn && CALL_P (insn) && aarch64_simd_call_p (insn);
> +  return FP_REGNUM_P (regno) && maybe_gt (GET_MODE_SIZE (mode), simd_p ? 16: 
> 8);

Should be a space before the ":" (which pushes the line over 80 chars).

> diff --git a/gcc/hooks.h b/gcc/hooks.h
> index 9e4bc29..dc6b2e1 100644
> --- a/gcc/hooks.h
> +++ b/gcc/hooks.h
> @@ -40,7 +40,9 @@ extern bool hook_bool_const_rtx_insn_const_rtx_insn_true 
> (const rtx_insn *,
>  extern bool hook_bool_mode_uhwi_false (machine_mode,
>  unsigned HOST_WIDE_INT);
>  extern bool hook_bool_puint64_puint64_true (poly_uint64, poly_uint64);
> -extern bool hook_bool_uint_mode_false (unsigned int, machine_mode);
> +extern bool hook_bool_insn_uint_mode_false (rtx_insn *,
> + unsigned int,
> + machine_mode);

No need to break the line after "rtx_insn *,".

>  extern bool hook_bool_uint_mode_true (unsigned int, machine_mode);
>  extern bool hook_bool_tree_false (tree);
>  extern bool hook_bool_const_tree_false (const_tree);
> diff --git a/gcc/ira-conflicts.c b/gcc/ira-conflicts.c
> index b57468b..b697e57 100644
> --- a/gcc/ira-conflicts.c
> +++ b/gcc/ira-conflicts.c
> @@ -808,7 +808,8 @@ ira_build_conflicts (void)
>regs must conflict with them.  */
> for (regno = 0; regno < FIRST_PSEUDO_REGISTER; regno++)
>   if (!TEST_HARD_REG_BIT (call_used_reg_set, regno)
> - && targetm.hard_regno_call_part_clobbered (regno,
> + && targetm.hard_regno_call_part_clobbered (NULL,
> +regno,
>  obj_mode))
> {
>   SET_HARD_REG_BIT (OBJECT_CONFLICT_HARD_REGS (obj), regno);

No need to break the line after "NULL,".

> diff --git a/gcc/ira-costs.c b/gcc/ira-costs.c
> index e5d8804..7f60712 100644
> --- a/gcc/ira-costs.c
> +++ b/gcc/ira-costs.c
> @@ -2379,7 +2379,8 @@ ira_tune_allocno_costs (void)
>  *crossed_calls_clobber_regs)
> && (ira_hard_reg_set_intersection_p (regno, mode,
>  call_used_reg_set)
> -   || targetm.hard_regno_call_part_clobbered (regno,
> +   || targetm.hard_regno_call_part_clobbered (NULL,
> +  regno,
>mode)))
>   cost += (ALLOCNO_CALL_FREQ (a)
>* (ira_memory_move_cost[mode][rclass][0]

Same here.

> diff --git a/gcc/lra-int.h b/gcc/lra-int.h
> index 9d9e81d..ccc7b00 100644
> --- a/gcc/lra-int.h
> +++ b/gcc/lra-int.h
> @@ -117,6 +117,8 @@ struct lra_reg
>/* This member is set up in lra-lives.c for subsequent
>   assignments.  */
>lra_copy_t copies;
> +  /* Call instruction that may affect this register.  */
> +  rtx_insn *call_insn;
>  };
>  
>  /* References to the common info about each register.  */

If we do this right, I think the new field should be able to replace call_p.
The pseudo crosses a call iff call_insn is nonnull.

I think the field belongs after:

  poly_int64 offset;

since it comes under:

  /* The following fields are defined only for pseudos.  */

rather than:

  /* These members are set up in lra-lives.c and updated in
 lra-coalesce.c.  */

> diff --git a/gcc/lra-lives.c b/gcc/lra-lives.c
> index 7b60691..0b96891 100644
> --- a/gcc/lra-lives.c
> +++ b/gcc/lra-lives.c
> @@ -579,18 +579,26 @@ lra_setup_reload_pseudo_preferenced_hard_reg (int regno,
> PSEUDOS_LIVE_THROUGH_CALLS and PSEUDOS_LIVE_THROUGH_SETJUMPS.  */
>  static inline void
>  check_pseudos_live_through_calls (int regno,
> -   HARD_REG_SET last_call_used_reg_set)
> +   HARD_REG_SET last_call_used_reg_set,
> +   rtx_insn *call_insn)
>  {
>int hr;
>  
> +  if (call_insn && CALL_P (call_insn) && 
> targetm.return_call_with_max_clobbers)
> +lra_reg_info[regno].call_insn =
> +  targetm.return_call_with_max_clobbers (call_insn,
> +  lra_reg_info[regno].call_insn);
> +

This should happen...

>if (! sparseset_bit_p (pseudos_live_through_

[PATCH] PR libstdc++/88204 disable std::complex tests

[Jonathan Wakely]

The IBM128 long double format isn't foldable in constant expressions, so
conditionally skip the std::complex cases when they'll
fail.

PR libstdc++/88204
* testsuite/26_numerics/complex/operators/more_constexpr.cc: Do not
test std::complex if long double format is IBM128.
* testsuite/26_numerics/complex/requirements/more_constexpr.cc:
Likewise.

Tested powerpc64le-linux, committed to trunk.


commit c65bdd73e81a0867c2384975b9d7d11fd3665e37
Author: Jonathan Wakely 
Date:   Wed Jan 9 09:25:24 2019 +

PR libstdc++/88204 disable std::complex tests

The IBM128 long double format isn't foldable in constant expressions, so
conditionally skip the std::complex cases when they'll
fail.

PR libstdc++/88204
* testsuite/26_numerics/complex/operators/more_constexpr.cc: Do not
test std::complex if long double format is IBM128.
* testsuite/26_numerics/complex/requirements/more_constexpr.cc:
Likewise.

diff --git 
a/libstdc++-v3/testsuite/26_numerics/complex/operators/more_constexpr.cc 
b/libstdc++-v3/testsuite/26_numerics/complex/operators/more_constexpr.cc
index 725e789d334..3def7db2551 100644
--- a/libstdc++-v3/testsuite/26_numerics/complex/operators/more_constexpr.cc
+++ b/libstdc++-v3/testsuite/26_numerics/complex/operators/more_constexpr.cc
@@ -56,7 +56,9 @@ int main()
 {
   __gnu_test::test_operators();
   __gnu_test::test_operators();
+#ifndef __LONG_DOUBLE_IBM128__ // IBM128 format is not constexpr foldable
   __gnu_test::test_operators();
+#endif
 
   return 0;
 }
diff --git 
a/libstdc++-v3/testsuite/26_numerics/complex/requirements/more_constexpr.cc 
b/libstdc++-v3/testsuite/26_numerics/complex/requirements/more_constexpr.cc
index 4b17d421023..670378dc0c3 100644
--- a/libstdc++-v3/testsuite/26_numerics/complex/requirements/more_constexpr.cc
+++ b/libstdc++-v3/testsuite/26_numerics/complex/requirements/more_constexpr.cc
@@ -23,7 +23,6 @@
 
 namespace __gnu_test
 {
-
   // Test constexpr real(val) imag(val).
   template
 inline void
@@ -160,9 +159,11 @@ int main()
   __gnu_test::test_operator_members();
   __gnu_test::test_operator_members();
   __gnu_test::test_operator_members();
+#ifndef __LONG_DOUBLE_IBM128__ // IBM128 format is not constexpr foldable
   __gnu_test::test_operator_members();
   __gnu_test::test_operator_members();
   __gnu_test::test_operator_members();
+#endif
 
 #if defined(_GLIBCXX_USE_FLOAT128)
   // Test primary template.

Re: ISO_Fortran_binding patch

[Paul Richard Thomas]

Hi Thomas,

> Is there any particular reason why you do not want to use
>
> ! { dg-additional-options "-I $srcdir/../../libgfortran" }
>
> in the test cases, and have it only once in the source trees?

I will make it so. Thanks for the reminder.

>
> However, I have no real strong opinion on this matter, if you
> want to keep it as submitted, it is also fine.

Incidentally, we need to make sure that it is distributed in the
include directory. I have yet to figure out how to do that.

>
> Therefore: OK for trunk, and thanks a lot for the patch!
>
> Documentation we can add at a later date, I think.

I can work that up before committing the patch since I will not be in
a position to work on gfortran until Saturday.

In the longer term, I will take the descriptor conversion out of the
library and will write a CFI equivalent of gfc_conv_expr_descriptor.
However, I will await the inevitable bug reports before doing that :-)

Thanks

Paul

>
> Regards
>
> Thomas



-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein

[wwwdocs, committed] Update Stage 4 description

[Tom de Vries]

[ was: Re: [RFC] Update Stage 4 description ]

On 09-01-19 09:47, Richard Biener wrote:
> On Wed, 9 Jan 2019, Tom de Vries wrote:
> 
>> [ To revisit https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00385.html ]
>>
>> The current formulation for the description of Stage 4 here (
>> https://gcc.gnu.org/develop.html ) is:
>> ...
>> During this period, the only (non-documentation) changes that may be
>> made are changes that fix regressions.
>>
>> Other changes may not be done during this period.
>>
>> Note that the same constraints apply to release branches.
>>
>> This period lasts until stage 1 opens for the next release.
>> ...
>>
>> This updated formulation was proposed by Richi (with a request for
>> review of wording):
>> ...
>>  During this period, the only (non-documentation) changes that may
>>  be made are changes that fix regressions.
>>
>> -Other changes may not be done during this period.
>> +Other important bugs like wrong-code, rejects-valid or build issues may
>> +be fixed as well.  All changes during this period should be done with
>> +extra care on not introducing new regressions - fixing bugs at all cost
>> +is not wanted.
>>
>>  Note that the same constraints apply to release branches.
>>
>>  This period lasts until stage 1 opens for the next release.
>> ...
>>
>> If a text can be agreed upon, then I can prepare a patch for wwwdocs.
> 
> The proposed text sounds good, please post a patch and apply!

Attached patch committed.

Thanks,
- Tom
Index: htdocs/develop.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/develop.html,v
retrieving revision 1.190
diff -r1.190 develop.html
135,138c135,140
< be made are changes that fix regressions.  Other changes may not be
< done during this period.  Note that the same constraints apply
< to release branches.  This period lasts until stage 1 opens for
< the next release.
---
> be made are changes that fix regressions.  Other important bugs
> like wrong-code, rejects-valid or build issues may be fixed as well.
> All changes during this period should be done with extra care on
> not introducing new regressions - fixing bugs at all cost is not
> wanted.  Note that the same constraints apply to release branches.
> This period lasts until stage 1 opens for the next release.

Re: [RFC] Update Stage 4 description

[Jonathan Wakely]

On Wed, 9 Jan 2019 at 08:41, Tom de Vries  wrote:
>
> [ To revisit https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00385.html ]
>
> The current formulation for the description of Stage 4 here (
> https://gcc.gnu.org/develop.html ) is:
> ...
> During this period, the only (non-documentation) changes that may be
> made are changes that fix regressions.
>
> Other changes may not be done during this period.
>
> Note that the same constraints apply to release branches.
>
> This period lasts until stage 1 opens for the next release.
> ...
>
> This updated formulation was proposed by Richi (with a request for
> review of wording):
> ...
>  During this period, the only (non-documentation) changes that may
>  be made are changes that fix regressions.
>
> -Other changes may not be done during this period.
> +Other important bugs like wrong-code, rejects-valid or build issues may
> +be fixed as well.  All changes during this period should be done with
> +extra care on not introducing new regressions - fixing bugs at all cost

ISTM that this should be either "at any cost" or "at all costs". The
current wording can't make up its mind if it's singular or plural.

I also stumbled over "on not introducing" ... would that be better as
"to not introduce"?


> +is not wanted.
>
>  Note that the same constraints apply to release branches.
>
>  This period lasts until stage 1 opens for the next release.
> ...
>
> If a text can be agreed upon, then I can prepare a patch for wwwdocs.
>
> Thanks,
> - Tom

Re: [RFC] Update Stage 4 description

[Richard Biener]

On Wed, 9 Jan 2019, Tom de Vries wrote:

> [ To revisit https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00385.html ]
> 
> The current formulation for the description of Stage 4 here (
> https://gcc.gnu.org/develop.html ) is:
> ...
> During this period, the only (non-documentation) changes that may be
> made are changes that fix regressions.
> 
> Other changes may not be done during this period.
> 
> Note that the same constraints apply to release branches.
> 
> This period lasts until stage 1 opens for the next release.
> ...
> 
> This updated formulation was proposed by Richi (with a request for
> review of wording):
> ...
>  During this period, the only (non-documentation) changes that may
>  be made are changes that fix regressions.
> 
> -Other changes may not be done during this period.
> +Other important bugs like wrong-code, rejects-valid or build issues may
> +be fixed as well.  All changes during this period should be done with
> +extra care on not introducing new regressions - fixing bugs at all cost
> +is not wanted.
> 
>  Note that the same constraints apply to release branches.
> 
>  This period lasts until stage 1 opens for the next release.
> ...
> 
> If a text can be agreed upon, then I can prepare a patch for wwwdocs.

The proposed text sounds good, please post a patch and apply!

Thanks,
Richard.

Re: [PATCH] Fix the dynamic_align_addr stuff partially (PR rtl-optimization/88331)

[Richard Biener]

On Tue, 8 Jan 2019, Jakub Jelinek wrote:

> Hi!
> 
> The following patch attempts to fix one of the several issues with
> the r266345 commit.  assign_stack_local isn't called just during expansion,
> but also during RA, at which point we can't just randomly emit insns in the
> middle of nowhere hoping it will be emitted in some insn sequence.
> 
> This patch just reverts the behavior for the over-aligned temporaries to
> what we did before if it isn't during RA.  If needed, for GCC10 we can come
> up with a way to tell the RA that it should realign, but IMHO it isn't
> really needed right now.
> 
> Bootstrapped/regtested on x86_64-linux, i686-linux and powerpc64le-linux, ok
> for trunk?

OK.

Richard.

> 2019-01-08  Jakub Jelinek  
> 
>   PR rtl-optimization/88331
>   * function.c (assign_stack_local_1): Don't set dynamic_align_addr if
>   not currently_expanding_to_rtl.
> 
>   * gcc.target/i386/pr88331.c: New test.
> 
> --- gcc/function.c.jj 2019-01-01 12:37:16.550984910 +0100
> +++ gcc/function.c2019-01-08 16:51:02.868722422 +0100
> @@ -400,7 +400,9 @@ assign_stack_local_1 (machine_mode mode,
>  {
>/* If the required alignment exceeds MAX_SUPPORTED_STACK_ALIGNMENT and
>it is not OK to reduce it.  Align the slot dynamically.  */
> -  if (mode == BLKmode && (kind & ASLK_REDUCE_ALIGN) == 0)
> +  if (mode == BLKmode
> +   && (kind & ASLK_REDUCE_ALIGN) == 0
> +   && currently_expanding_to_rtl)
>   dynamic_align_addr = true;
>else
>   {
> --- gcc/testsuite/gcc.target/i386/pr88331.c.jj2019-01-08 
> 17:31:46.504540870 +0100
> +++ gcc/testsuite/gcc.target/i386/pr88331.c   2019-01-08 17:31:17.547014393 
> +0100
> @@ -0,0 +1,30 @@
> +/* PR rtl-optimization/88331 */
> +/* { dg-do compile } */
> +/* { dg-options "-O3 -march=core-avx2" } */
> +
> +int b, d, e, g, i, j, l, m;
> +int *c, *h, *n, *o;
> +long f, k;
> +
> +void
> +foo (void)
> +{
> +  long p = i;
> +  int *a = o;
> +  while (p)
> +{
> +  n = (int *) (__UINTPTR_TYPE__) a[0];
> +  for (; f; f += 4)
> + for (; m <= d;)
> +   {
> + for (; g <= e; ++g)
> +   l = (int) (__UINTPTR_TYPE__) (n + l);
> + c[m] = (int) (__UINTPTR_TYPE__) n;
> +   }
> +}
> +  int q = 0;
> +  k = 0;
> +  for (; k < j; k++)
> +q += o[k] * h[k];
> +  b = q;
> +}
> 
>   Jakub
> 
> 

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

Re: [PATCH] Fix up initializer_each_zero_or_onep (PR middle-end/88758)

[Richard Biener]

On Tue, 8 Jan 2019, Jakub Jelinek wrote:

> Hi!
> 
> As mentioned in the PR, if a VECTOR_CST is not VECTOR_CST_STEPPED_P,
> it is sufficient to recurse just on all the encoded elt, because if
> the vector has more elts than encoded, all the remaining ones are equal to
> the last one.
> But, if it is stepped, there is the possibility that while the penultimate
> and last encoded elt could be zero or one, the first non-encoded one could
> be two or minus one.
> 
> The patch as committed is doing:
> unsigned HOST_WIDE_INT nelts = vector_cst_encoded_nelts (expr);
> if (VECTOR_CST_STEPPED_P (expr)
> && !TYPE_VECTOR_SUBPARTS (TREE_TYPE (expr)).is_constant (&nelts))
>   return false;
> so if it is stepped, it updates nelts to the subparts count and thus
> attempts to verify all elts rather than just the encoded ones.  But that
> fails because VECTOR_CST_ENCODED_ELT can't really access the non-encoded
> ones.  The following patch fixes it by using vector_cst_elt there instead,
> for the encoded elt it just returns VECTOR_CST_ENCODED_ELT immediately and
> for the next value it will likely fail the predicate.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

Richard.

> 2019-01-08  Jelinek  
> 
>   PR middle-end/88758
>   * tree.c (initializer_each_zero_or_onep) : Use
>   vector_cst_elt instead of VECTOR_CST_ENCODED_ELT.
> 
> --- gcc/tree.c.jj 2019-01-07 17:59:22.883951743 +0100
> +++ gcc/tree.c2019-01-08 18:15:01.956087119 +0100
> @@ -11255,7 +11255,7 @@ initializer_each_zero_or_onep (const_tre
>  
>   for (unsigned int i = 0; i < nelts; ++i)
> {
> - tree elt = VECTOR_CST_ENCODED_ELT (expr, i);
> + tree elt = vector_cst_elt (expr, i);
>   if (!initializer_each_zero_or_onep (elt))
> return false;
> }
> 
>   Jakub
> 
> 

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

[RFC] Update Stage 4 description

[Tom de Vries]

[ To revisit https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00385.html ]

The current formulation for the description of Stage 4 here (
https://gcc.gnu.org/develop.html ) is:
...
During this period, the only (non-documentation) changes that may be
made are changes that fix regressions.

Other changes may not be done during this period.

Note that the same constraints apply to release branches.

This period lasts until stage 1 opens for the next release.
...

This updated formulation was proposed by Richi (with a request for
review of wording):
...
 During this period, the only (non-documentation) changes that may
 be made are changes that fix regressions.

-Other changes may not be done during this period.
+Other important bugs like wrong-code, rejects-valid or build issues may
+be fixed as well.  All changes during this period should be done with
+extra care on not introducing new regressions - fixing bugs at all cost
+is not wanted.

 Note that the same constraints apply to release branches.

 This period lasts until stage 1 opens for the next release.
...

If a text can be agreed upon, then I can prepare a patch for wwwdocs.

Thanks,
- Tom

Fix documentation about -finline-functions

[Eric Botcazou]

The documentation is confused in various ways depending on the active branch, 
although the implementation in opts.c is strictly identical on all of them:

mainline:

 Enabled at levels `-O2', `-O3', `-Os'.  Also enabled by
 `-fprofile-use' and `-fauto-profile'.

8 branch:

 Enabled at levels `-O2', `-O3', `-Os'.

7 branch:

 Enabled at level `-O3'.

None is fully correct, the correct form being:

 Enabled at levels `-O3', `-Os'.  Also enabled by `-fprofile-use'
 and `-fauto-profile'.

Tested with 'make doc', applied on all active branches as obvious.


2019-01-09  Eric Botcazou  

* doc/invoke.texi (-Os): Remove trailing spaces.
(-finline-functions): Remove reference to -O2.


2019-01-09  Eric Botcazou  

* doc/invoke.texi (-Os): Add reference to -finline-functions.
(-finline-functions): Remove reference to -O2, add references
to -fprofile-use and -fauto-profile.


2019-01-09  Eric Botcazou  

* doc/invoke.texi (-Os): Add reference to -finline-functions.
(-finline-small-functions): Add references to -O3 and -Os.
(-findirect-inlining): Likewise.
(-finline-functions): Add references to -Os, -fprofile-use and
-fauto-profile.

-- 
Eric BotcazouIndex: doc/invoke.texi
===
--- doc/invoke.texi	(revision 267608)
+++ doc/invoke.texi	(working copy)
@@ -7136,14 +7136,17 @@ results.  This is the default.
 @item -Os
 @opindex Os
 Optimize for size.  @option{-Os} enables all @option{-O2} optimizations that
-do not typically increase code size.  It also performs further
-optimizations designed to reduce code size.
+do not typically increase code size.
 
 @option{-Os} disables the following optimization flags:
 @gccoptlist{-falign-functions  -falign-jumps  -falign-loops @gol
 -falign-labels  -freorder-blocks  -freorder-blocks-algorithm=stc @gol
 -freorder-blocks-and-partition  -fprefetch-loop-arrays}
 
+It also enables @option{-finline-functions}, causes the compiler to tune for
+code size rather than execution speed, and performs further optimizations
+designed to reduce code size.
+
 @item -Ofast
 @opindex Ofast
 Disregard strict standards compliance.  @option{-Ofast} enables all
@@ -7261,7 +7264,7 @@ heuristically decides which functions ar
 in this way.  This inlining applies to all functions, even those not declared
 inline.
 
-Enabled at level @option{-O2}.
+Enabled at level @option{-O2}, @option{-O3}, @option{-Os}.
 
 @item -findirect-inlining
 @opindex findirect-inlining
@@ -7270,7 +7273,7 @@ time thanks to previous inlining.  This
 when inlining itself is turned on by the @option{-finline-functions}
 or @option{-finline-small-functions} options.
 
-Enabled at level @option{-O2}.
+Enabled at level @option{-O2}, @option{-O3}, @option{-Os}.
 
 @item -finline-functions
 @opindex finline-functions
@@ -7282,7 +7285,8 @@ If all calls to a given function are int
 declared @code{static}, then the function is normally not output as
 assembler code in its own right.
 
-Enabled at level @option{-O3}.
+Enabled at levels @option{-O3}, @option{-Os}.  Also enabled
+by @option{-fprofile-use} and @option{-fauto-profile}.
 
 @item -finline-functions-called-once
 @opindex finline-functions-called-once
Index: doc/invoke.texi
===
--- doc/invoke.texi	(revision 267607)
+++ doc/invoke.texi	(working copy)
@@ -7675,14 +7675,17 @@ results.  This is the default.
 @item -Os
 @opindex Os
 Optimize for size.  @option{-Os} enables all @option{-O2} optimizations that
-do not typically increase code size.  It also performs further
-optimizations designed to reduce code size.
+do not typically increase code size.
 
 @option{-Os} disables the following optimization flags:
 @gccoptlist{-falign-functions  -falign-jumps  -falign-loops @gol
 -falign-labels  -freorder-blocks  -freorder-blocks-algorithm=stc @gol
 -freorder-blocks-and-partition  -fprefetch-loop-arrays}
 
+It also enables @option{-finline-functions}, causes the compiler to tune for
+code size rather than execution speed, and performs further optimizations
+designed to reduce code size.
+
 @item -Ofast
 @opindex Ofast
 Disregard strict standards compliance.  @option{-Ofast} enables all
@@ -7803,7 +7806,8 @@ time thanks to previous inlining.  This
 when inlining itself is turned on by the @option{-finline-functions}
 or @option{-finline-small-functions} options.
 
-Enabled at levels @option{-O2}, @option{-O3}, @option{-Os}.
+Enabled at levels @option{-O3}, @option{-Os}.  Also enabled
+by @option{-fprofile-use} and @option{-fauto-profile}.
 
 @item -finline-functions
 @opindex finline-functions
Index: doc/invoke.texi
===
--- doc/invoke.texi	(revision 267574)
+++ doc/invoke.texi	(working copy)
@@ -8247,7 +8247,7 @@ except those that often increase code si
 
 It also enables @option{-finline-functions}, c