Re: [PATCH] x86: Don't allocate stack frame nor align stack if not needed

[Uros Bizjak]

On Tue, May 21, 2019 at 5:01 PM H.J. Lu  wrote:
>
> get_frame_size () returns used stack slots during compilation, which
> may be optimized out later.  This patch does the followings:
>
> 1. Add no_stack_frame to machine_function to indicate that the function
> doesn't need a stack frame.

Can you please add "stack_frame_required" to machine_function with
inverted meaning instead? Every single usage of no_stack_frame is
inverted, and it is hard to follow this negative logic through the
code.

> 2. Change ix86_find_max_used_stack_alignment to set no_stack_frame.
> 3. Always call ix86_find_max_used_stack_alignment to check if stack
> frame is needed.
>
> Tested on i686 and x86-64 with
>
> --with-arch=native --with-cpu=native
>
> Tested on AVX512 machine configured with
>
> --with-arch=native --with-cpu=native
>
> gcc/
>
> PR target/88483
> * config/i386/i386.c (ix86_get_frame_size): New function.
> (ix86_frame_pointer_required): Replace get_frame_size with
> ix86_get_frame_size.
> (ix86_compute_frame_layout): Likewise.
> (ix86_find_max_used_stack_alignment): Changed to void.  Set
> no_stack_frame.
> (ix86_finalize_stack_frame_flags): Always call
> ix86_find_max_used_stack_alignment.  Replace get_frame_size with
> ix86_get_frame_size.
> * config/i386/i386.h (machine_function): Add no_stack_frame.
>
> gcc/testsuite/
>
> PR target/88483
> * gcc.target/i386/stackalign/pr88483-1.c: New test.
> * gcc.target/i386/stackalign/pr88483-2.c: Likewise.
> ---
>  gcc/config/i386/i386.c| 53 ---
>  gcc/config/i386/i386.h|  3 ++
>  .../gcc.target/i386/stackalign/pr88483-1.c| 18 +++
>  .../gcc.target/i386/stackalign/pr88483-2.c| 18 +++
>  4 files changed, 74 insertions(+), 18 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/i386/stackalign/pr88483-1.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/stackalign/pr88483-2.c
>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 54607748b0b..d0b2a4f8b70 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -5012,6 +5012,19 @@ ix86_can_use_return_insn_p (void)
>   && (frame.nregs + frame.nsseregs) == 0);
>  }
>
> +/* Return stack frame size.  get_frame_size () returns used stack slots
> +   during compilation, which may be optimized out later.  no_stack_frame
> +   is set to true if stack frame isn't needed.  */
> +
> +static HOST_WIDE_INT
> +ix86_get_frame_size (void)
> +{
> +  if (cfun->machine->no_stack_frame)
> +return 0;
> +  else
> +return get_frame_size ();
> +}
> +
>  /* Value should be nonzero if functions must have frame pointers.
> Zero means the frame pointer need not be set up (and parms may
> be accessed via the stack pointer) in functions that seem suitable.  */
> @@ -5035,7 +5048,7 @@ ix86_frame_pointer_required (void)
>
>/* Win64 SEH, very large frames need a frame-pointer as maximum stack
>   allocation is 4GB.  */
> -  if (TARGET_64BIT_MS_ABI && get_frame_size () > SEH_MAX_FRAME_SIZE)
> +  if (TARGET_64BIT_MS_ABI && ix86_get_frame_size () > SEH_MAX_FRAME_SIZE)
>  return true;
>
>/* SSE saves require frame-pointer when stack is misaligned.  */
> @@ -5842,7 +5855,7 @@ ix86_compute_frame_layout (void)
>unsigned HOST_WIDE_INT stack_alignment_needed;
>HOST_WIDE_INT offset;
>unsigned HOST_WIDE_INT preferred_alignment;
> -  HOST_WIDE_INT size = get_frame_size ();
> +  HOST_WIDE_INT size = ix86_get_frame_size ();
>HOST_WIDE_INT to_allocate;
>
>/* m->call_ms2sysv is initially enabled in ix86_expand_call for all 64-bit
> @@ -7436,11 +7449,11 @@ output_probe_stack_range (rtx reg, rtx end)
>return "";
>  }
>
> -/* Return true if stack frame is required.  Update STACK_ALIGNMENT
> -   to the largest alignment, in bits, of stack slot used if stack
> -   frame is required and CHECK_STACK_SLOT is true.  */
> +/* Set no_stack_frame to true if stack frame isn't required.  Update
> +   STACK_ALIGNMENT to the largest alignment, in bits, of stack slot
> +   used if stack frame is required and CHECK_STACK_SLOT is true.  */

>From the above comment, you can see the confusion caused by using
negative logic for no_stack_frame.

> -static bool
> +static void
>  ix86_find_max_used_stack_alignment (unsigned int &stack_alignment,
> bool check_stack_slot)
>  {
> @@ -7489,7 +7502,7 @@ ix86_find_max_used_stack_alignment (unsigned int 
> &stack_alignment,
>   }
>  }
>
> -  return require_stack_frame;
> +  cfun->machine->no_stack_frame = !require_stack_frame;
>  }
>
>  /* Finalize stack_realign_needed and frame_pointer_needed flags, which
> @@ -7519,6 +7532,14 @@ ix86_finalize_stack_frame_flags (void)
>return;
>  }
>
> +  /* It is always safe to compute max_used_stack_alignment.  We
> + compute it only if 128-bit aligned load/store

[PATCH] optc-save-gen.awk: use uintrptr_t for casting of a pointer (PR bootstrap/90543).

[Martin Liška]

Hi.

The patch is about using of uintptr_t instead unsigned long that's
being used for printing value of a pointer.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin

gcc/ChangeLog:

2019-05-22  Martin Liska  

PR bootstrap/90543
* optc-save-gen.awk: Use uintptr_t instead of
unsigned long.
---
 gcc/optc-save-gen.awk | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)


diff --git a/gcc/optc-save-gen.awk b/gcc/optc-save-gen.awk
index 7ecd1eb9cc7..1e0a5f53a1e 100644
--- a/gcc/optc-save-gen.awk
+++ b/gcc/optc-save-gen.awk
@@ -213,7 +213,7 @@ for (i = 0; i < n_opt_other; i++) {
 	print "fprintf (file, \"%*s%s (%#lx)\\n\",";
 	print " indent_to, \"\",";
 	print " \"" var_opt_other[i] "\",";
-	print " (unsigned long)ptr->x_" var_opt_other[i] ");";
+	print " (uintptr_t)ptr->x_" var_opt_other[i] ");";
 	print "";
 }
 
@@ -278,8 +278,8 @@ for (i = 0; i < n_opt_other; i++) {
 	print "fprintf (file, \"%*s%s (%#lx/%#lx)\\n\",";
 	print " indent_to, \"\",";
 	print " \"" var_opt_other[i] "\",";
-	print " (unsigned long)ptr1->x_" var_opt_other[i] ",";
-	print " (unsigned long)ptr2->x_" var_opt_other[i] ");";
+	print " (uintptr_t)ptr1->x_" var_opt_other[i] ",";
+	print " (uintptr_t)ptr2->x_" var_opt_other[i] ");";
 	print "";
 }
 
@@ -490,7 +490,7 @@ for (i = 0; i < n_target_other; i++) {
 	if (hwi == "yes")
 		print " ptr->x_" var_target_other[i] ");";
 	else
-		print " (unsigned long)ptr->x_" var_target_other[i] ");";
+		print " (uintptr_t)ptr->x_" var_target_other[i] ");";
 	print "";
 }
 
@@ -559,8 +559,8 @@ for (i = 0; i < n_target_other; i++) {
 		print " ptr2->x_" var_target_other[i] ");";
 	}
 	else {
-		print " (unsigned long)ptr1->x_" var_target_other[i] ",";
-		print " (unsigned long)ptr2->x_" var_target_other[i] ");";
+		print " (uintptr_t)ptr1->x_" var_target_other[i] ",";
+		print " (uintptr_t)ptr2->x_" var_target_other[i] ");";
 	}
 	print "";
 }

Backport fix for PR c++/85400

[Eric Botcazou]

Jakub asked me to backport the fix for PR c++/85400 initially intended for 
SPARC/Solaris but which also helps on x86-64/Linux apparently.

Tested on the latter platform, applied on the 8 branch.


2019-05-22  Eric Botcazou  

c-family/
Backport from mainline
2018-05-10  Eric Botcazou  

PR c++/85400
* c-attribs.c (handle_visibility_attribute): Do not set no_add_attrs.


2019-05-22  Eric Botcazou  

cp/
Backport from mainline
2018-05-10  Eric Botcazou  

PR c++/85400
* decl2.c (adjust_var_decl_tls_model): New static function.
(comdat_linkage): Call it on a variable.
(maybe_make_one_only): Likewise.


2019-05-22  Eric Botcazou  

* g++.dg/tls/pr85400.C: New test.

-- 
Eric BotcazouIndex: c-family/c-attribs.c
===
--- c-family/c-attribs.c	(revision 270883)
+++ c-family/c-attribs.c	(working copy)
@@ -2310,14 +2310,13 @@ handle_visibility_attribute (tree *node,
 
 static tree
 handle_tls_model_attribute (tree *node, tree name, tree args,
-			int ARG_UNUSED (flags), bool *no_add_attrs)
+			int ARG_UNUSED (flags),
+			bool *ARG_UNUSED (no_add_attrs))
 {
   tree id;
   tree decl = *node;
   enum tls_model kind;
 
-  *no_add_attrs = true;
-
   if (!VAR_P (decl) || !DECL_THREAD_LOCAL_P (decl))
 {
   warning (OPT_Wattributes, "%qE attribute ignored", name);
Index: cp/decl2.c
===
--- cp/decl2.c	(revision 270883)
+++ cp/decl2.c	(working copy)
@@ -1838,6 +1838,17 @@ mark_vtable_entries (tree decl)
 }
 }
 
+/* Adjust the TLS model on variable DECL if need be, typically after
+   the linkage of DECL has been modified.  */
+
+static void
+adjust_var_decl_tls_model (tree decl)
+{
+  if (CP_DECL_THREAD_LOCAL_P (decl)
+  && !lookup_attribute ("tls_model", DECL_ATTRIBUTES (decl)))
+set_decl_tls_model (decl, decl_default_tls_model (decl));
+}
+
 /* Set DECL up to have the closest approximation of "initialized common"
linkage available.  */
 
@@ -1888,6 +1899,9 @@ comdat_linkage (tree decl)
 
   if (TREE_PUBLIC (decl))
 DECL_COMDAT (decl) = 1;
+
+  if (VAR_P (decl))
+adjust_var_decl_tls_model (decl);
 }
 
 /* For win32 we also want to put explicit instantiations in
@@ -1926,6 +1940,8 @@ maybe_make_one_only (tree decl)
 	  /* Mark it needed so we don't forget to emit it.  */
   node->forced_by_abi = true;
 	  TREE_USED (decl) = 1;
+
+	  adjust_var_decl_tls_model (decl);
 	}
 }
 }

[PATCH] Fix PR90450

[Richard Biener]

The hash-table checker discovered a bug in LIMs new fancy hash/compare
logic, fixed as follows.

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

Richard.

2019-05-22  Richard Biener  

PR tree-optimization/90450
* tree-ssa-loop-im.c (struct im_mem_ref): Add ref_decomposed.
(mem_ref_hasher::equal): Check it.
(mem_ref_alloc): Initialize it.
(gather_mem_refs_stmt): Set it.

Index: gcc/tree-ssa-loop-im.c
===
--- gcc/tree-ssa-loop-im.c  (revision 271415)
+++ gcc/tree-ssa-loop-im.c  (working copy)
@@ -115,9 +115,10 @@ struct mem_ref_loc
 
 struct im_mem_ref
 {
-  unsigned id : 31;/* ID assigned to the memory reference
+  unsigned id : 30;/* ID assigned to the memory reference
   (its index in memory_accesses.refs_list)  */
   unsigned ref_canonical : 1;   /* Whether mem.ref was canonicalized.  */
+  unsigned ref_decomposed : 1;  /* Whether the ref was hashed from mem.  */
   hashval_t hash;  /* Its hash value.  */
 
   /* The memory access itself and associated caching of alias-oracle
@@ -173,7 +174,8 @@ inline bool
 mem_ref_hasher::equal (const im_mem_ref *mem1, const ao_ref *obj2)
 {
   if (obj2->max_size_known_p ())
-return (operand_equal_p (mem1->mem.base, obj2->base, 0)
+return (mem1->ref_decomposed
+   && operand_equal_p (mem1->mem.base, obj2->base, 0)
&& known_eq (mem1->mem.offset, obj2->offset)
&& known_eq (mem1->mem.size, obj2->size)
&& known_eq (mem1->mem.max_size, obj2->max_size)
@@ -1389,6 +1391,7 @@ mem_ref_alloc (ao_ref *mem, unsigned has
 ao_ref_init (&ref->mem, error_mark_node);
   ref->id = id;
   ref->ref_canonical = false;
+  ref->ref_decomposed = false;
   ref->hash = hash;
   ref->stored = NULL;
   bitmap_initialize (&ref->indep_loop, &lim_bitmap_obstack);
@@ -1476,6 +1479,7 @@ gather_mem_refs_stmt (struct loop *loop,
   HOST_WIDE_INT offset, size, max_size;
   poly_int64 saved_maxsize = aor.max_size, mem_off;
   tree mem_base;
+  bool ref_decomposed;
   if (aor.max_size_known_p ()
  && aor.offset.is_constant (&offset)
  && aor.size.is_constant (&size)
@@ -1489,12 +1493,14 @@ gather_mem_refs_stmt (struct loop *loop,
   aor.size)
  && (mem_base = get_addr_base_and_unit_offset (aor.ref, &mem_off)))
{
+ ref_decomposed = true;
  hash = iterative_hash_expr (ao_ref_base (&aor), 0);
  hash = iterative_hash_host_wide_int (offset, hash);
  hash = iterative_hash_host_wide_int (size, hash);
}
   else
{
+ ref_decomposed = false;
  hash = iterative_hash_expr (aor.ref, 0);
  aor.max_size = -1;
}
@@ -1543,6 +1549,7 @@ gather_mem_refs_stmt (struct loop *loop,
{
  id = memory_accesses.refs_list.length ();
  ref = mem_ref_alloc (&aor, hash, id);
+ ref->ref_decomposed = ref_decomposed;
  memory_accesses.refs_list.safe_push (ref);
  *slot = ref;
 

Re: [PATCH] optc-save-gen.awk: use uintrptr_t for casting of a pointer (PR bootstrap/90543).

[Jakub Jelinek]

On Wed, May 22, 2019 at 09:39:52AM +0200, Martin Liška wrote:
> The patch is about using of uintptr_t instead unsigned long that's
> being used for printing value of a pointer.
> 
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> 
> Ready to be installed?

No.  You haven't adjusted the fprintf format strings for this change,
so it will break build on any target where uintptr_t is not unsigned long.

I don't see any gcc/ code using the PRIxPTR and similar macros, so no idea
about the portability of that, but I'd think we just should keep that as is.

Jakub

[PATCH, Darwin, testsuite] Fix PR27221.

[Iain Sandoe]

An old one…

This test can never pass on 32b Darwin (or AIX) because the ABI demands a
different result to that being tested.  So XFAIL it.

Tested on powerpc-darwin9, powerpc-ibm-aix
Applied to mainline
Iain

gcc/testsuite/

2019-05-22  Iain Sandoe  

   PR testsuite/27221
   * g++.dg/ext/alignof2.C: XFAIL for 32bit Darwin.


diff --git a/gcc/testsuite/g++.dg/ext/alignof2.C 
b/gcc/testsuite/g++.dg/ext/alignof2.C
index 2217590..bd56cf6 100644
--- a/gcc/testsuite/g++.dg/ext/alignof2.C
+++ b/gcc/testsuite/g++.dg/ext/alignof2.C
@@ -3,7 +3,7 @@
 // wrong for some fields.
 
 // { dg-do run }
-// { dg-xfail-run-if "AIX ABI increases struct alignment for first member 
double" { powerpc-ibm-aix* } }
+// { dg-xfail-run-if "AIX/Darwin ABI increases struct alignment for first 
member double" { powerpc-ibm-aix* || { ilp32 && powerpc-*-darwin* } } }
 
 extern "C" void abort();
 

*ping* Re: [PATCH] PR fortran/89100 Default widths for i, f and g format specifiers in format strings

[Mark Eggleston]

On 13/05/2019 10:45, Mark Eggleston wrote:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89100 see comment 4

Please can someone commit the attached patch as I do not have commit 
rights.


Change logs:

For gcc/fortran

    Jeff Law  
    Mark Eggleston  

    PR fortran/89100
    * gfortran.texi: Add Default widths for F, G and I format descriptors
    to Extensions section.
    * invoke.texi: Add -fdec-format-defaults
    * io.c (check_format): Use default widths for i, f and g when
    flag_dec_format_defaults is enabled.
    * lang.opt: Add new option.
    * options.c (set_dec_flags): Add SET_BITFLAG for
    flag_dec_format_defaults.

For gcc/testsuite

    Mark Eggleston 

    PR fortran/89100
    * gfortran.dg/fmt_f_default_field_width_1.f90: New test.
    * gfortran.dg/fmt_f_default_field_width_2.f90: New test.
    * gfortran.dg/fmt_f_default_field_width_3.f90: New test.
    * gfortran.dg/fmt_g_default_field_width_1.f90: New test.
    * gfortran.dg/fmt_g_default_field_width_2.f90: New test.
    * gfortran.dg/fmt_g_default_field_width_3.f90: New test.
    * gfortran.dg/fmt_i_default_field_width_1.f90: New test.
    * gfortran.dg/fmt_i_default_field_width_2.f90: New test.
    * gfortran.dg/fmt_i_default_field_width_3.f90: New test.

For libgfortran

    Jeff Law  

    PR fortran/89100
    * io/format.c (parse_format_list): set default width when the
    IOPARM_DT_DEC_EXT flag is set for i, f and g.
    * io/io.h: add default_width_for_integer, default_width_for_float
    and default_precision_for_float.
    * io/write.c (write_boz): extra parameter giving length of data
    corresponding to the type's kind.
    (write_b): pass data length as extra parameter in calls to write_boz.
    (write_o): pass data length as extra parameter in calls to write_boz.
    (write_z): pass data length as extra parameter in calls to write_boz.
    (size_from_kind): also set size is default width is set.
    * io/write_float.def (build_float_string): new paramter inserted 
before

    result parameter. If default width use values passed instead of the
    values in fnode.
    (FORMAT_FLOAT): macro modified to check for default width and 
calls to

    build_float_string to pass in default width.
    (get_float_string): set width and precision to defaults when needed.



ping?

--
https://www.codethink.co.uk/privacy.html

>From f952b060a6d5de506022026eef13c86692c23c12 Mon Sep 17 00:00:00 2001
From: law 
Date: Thu, 10 May 2018 11:48:34 +0100
Subject: [PATCH 1/6] Default widths for i, f and g format specifiers in format
 strings.

Enabled using -fdec.

The behaviour is modelled on the Oracle Fortran compiler. At the time
of writing, the details were available at this URL:

  https://docs.oracle.com/cd/E19957-01/805-4939/6j4m0vnc3/index.html#z4000743746d

Addition by Mark Eggleston :

Use -fdec-format-defaults to enable this feature. Also enabled using -fdec.
---
 gcc/fortran/gfortran.texi  | 17 
 gcc/fortran/invoke.texi| 25 ++-
 gcc/fortran/io.c   | 31 --
 gcc/fortran/lang.opt   |  4 ++
 gcc/fortran/options.c  |  1 +
 .../gfortran.dg/fmt_f_default_field_width_1.f90| 40 +
 .../gfortran.dg/fmt_f_default_field_width_2.f90| 43 +++
 .../gfortran.dg/fmt_f_default_field_width_3.f90| 30 +
 .../gfortran.dg/fmt_g_default_field_width_1.f90| 45 +++
 .../gfortran.dg/fmt_g_default_field_width_2.f90| 48 +
 .../gfortran.dg/fmt_g_default_field_width_3.f90| 33 ++
 .../gfortran.dg/fmt_i_default_field_width_1.f90| 40 +
 .../gfortran.dg/fmt_i_default_field_width_2.f90| 44 +++
 .../gfortran.dg/fmt_i_default_field_width_3.f90| 37 
 libgfortran/io/format.c| 35 +++
 libgfortran/io/io.h| 50 ++
 libgfortran/io/read.c  |  6 +++
 libgfortran/io/write.c | 22 ++
 libgfortran/io/write_float.def | 37 +---
 19 files changed, 560 insertions(+), 28 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/fmt_f_default_field_width_1.f90
 create mode 100644 gcc/testsuite/gfortran.dg/fmt_f_default_field_width_2.f90
 create mode 100644 gcc/testsuite/gfortran.dg/fmt_f_default_field_width_3.f90
 create mode 100644 gcc/testsuite/gfortran.dg/fmt_g_default_field_width_1.f90
 create mode 100644 gcc/testsuite/gfortran.dg/fmt_g_default_field_width_2.f90
 create mode 100644 gcc/testsuite/gfortran.dg/fmt_g_default_field_width_3.f90
 create mode 100644 gcc/testsuite/gfortran.dg/fmt_i_default_field_width_1.f90
 create mode 100644 gcc/testsuite/gfortran.dg/fmt_i_default_field_width_2.f90
 create mode 100644 gcc/testsuite/gfortran.dg/fmt_i_default_fi

Re: [PATCH] optc-save-gen.awk: use uintrptr_t for casting of a pointer (PR bootstrap/90543).

[Martin Liška]

On 5/22/19 9:50 AM, Jakub Jelinek wrote:
> On Wed, May 22, 2019 at 09:39:52AM +0200, Martin Liška wrote:
>> The patch is about using of uintptr_t instead unsigned long that's
>> being used for printing value of a pointer.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>
>> Ready to be installed?
> 
> No.  You haven't adjusted the fprintf format strings for this change,
> so it will break build on any target where uintptr_t is not unsigned long.
> 
> I don't see any gcc/ code using the PRIxPTR and similar macros, so no idea
> about the portability of that, but I'd think we just should keep that as is.

Ok.

Martin

> 
>   Jakub
> 

Re: [PATCH] [aarch64] Introduce flags for SVE2.

[Richard Sandiford]

[Gah, wrote this a few days ago but just realised I never sent it.
 Was wondering why hadn't been applied. :-)]

Matthew Malcomson  writes:
> @@ -16008,6 +16008,17 @@ generation.  This option is enabled by default for 
> @option{-march=armv8.5-a}.
> +@item bitperm
> +Enable SVE2 bitperm Extension.  This also enables SVE2 instructions.
> +@item sve2-sm4
> +Enable SVE2 sm4 Extension.  This also enables SVE2 instructions.
> +@item sve2-aes
> +Enable SVE2 aes Extension.  This also enables SVE2 instructions.
> +@item sve2-sha3
> +Enable SVE2 sha3 Extension.  This also enables SVE2 instructions.
>  @option{-march=armv8.5-a}.

Realise things aren't very consistent, but s/Extension/instructions/
reads better to me for these.

OK with that change, thanks.

Richard

Re: [PATCH] tree-ssa-uninit: suppress more spurious warnings

[Christophe Lyon]

On Fri, 17 May 2019 at 10:12, Vladislav Ivanishin  wrote:
>
> Hi!
>
> Without the patch, two of the newly added tests fail with bogus warnings:
>
> - gcc.dg/uninit-28-gimple.c (Definition guarded with NE_EXPR, use with
>   BIT_AND_EXPR.  This is an FP my previous patch [1] knowingly
>   overlooks.)
> - gcc.dg/uninit-30-gimple.c (EQ_EXPR in the predicate guarding use.
>   This is what I spotted while refactoring.  It never worked, and is
>   easy to handle).
>
> Bootstraped with `BOOT_CFLAGS="-O -Wno-error=maybe-uninitialized
> -Wuninitialized"` and regtested on x86_64-pc-linux-gnu.  OK for trunk?
>

Hi,

As you have probably noticed already, the new test uninit-28.c fails:
/gcc/testsuite/gcc.dg/uninit-28-gimple.c:9:16: warning: 'undef' may be
used uninitialized in this function [-Wmaybe-uninitialized]
FAIL: gcc.dg/uninit-28-gimple.c  (test for bogus messages, line 9)
at least on arm & aarch64

Christophe

> Also, Richard, would you mind being a sponsor for my svn account?
>
> [1]: https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00896.html
>
>
> --
> Vlad

[PATCH][OBVIOUS] Fix wrong escaping of brackets (PR testsuite/90564).

[Martin Liška]

Hi.

The patch fixes couple of tests that I've just tested on ppc64le-linux-gnu.

I'm going to install the patch.
Thanks,
Martin

gcc/testsuite/ChangeLog:

2019-05-22  Martin Liska  

PR testsuite/90564
* gcc.target/powerpc/pr80315-1.c: Add one extra \ to escape
brackets.
* gcc.target/powerpc/pr80315-2.c: Likewise.
* gcc.target/powerpc/pr80315-3.c: Likewise.
* gcc.target/powerpc/pr80315-4.c: Likewise.
---
 gcc/testsuite/gcc.target/powerpc/pr80315-1.c | 2 +-
 gcc/testsuite/gcc.target/powerpc/pr80315-2.c | 2 +-
 gcc/testsuite/gcc.target/powerpc/pr80315-3.c | 2 +-
 gcc/testsuite/gcc.target/powerpc/pr80315-4.c | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)


diff --git a/gcc/testsuite/gcc.target/powerpc/pr80315-1.c b/gcc/testsuite/gcc.target/powerpc/pr80315-1.c
index 2f670a0c6c7..87b69a6a5d5 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr80315-1.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr80315-1.c
@@ -10,6 +10,6 @@ main()
   int mask;
 
   /* Argument 2 must be 0 or 1.  Argument 3 must be in range 0..15.  */
-  res = __builtin_crypto_vshasigmaw (test, 1, 0xff); /* { dg-error "argument 3 must be in the range \\[0, 15\\]" } */
+  res = __builtin_crypto_vshasigmaw (test, 1, 0xff); /* { dg-error "argument 3 must be in the range \\\[0, 15\\\]" } */
   return 0;
 }
diff --git a/gcc/testsuite/gcc.target/powerpc/pr80315-2.c b/gcc/testsuite/gcc.target/powerpc/pr80315-2.c
index e95187e2179..d2de5fd5a47 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr80315-2.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr80315-2.c
@@ -10,6 +10,6 @@ main ()
   int mask;
 
   /* Argument 2 must be 0 or 1.  Argument 3 must be in range 0..15.  */
-  res = __builtin_crypto_vshasigmad (test, 1, 0xff); /* { dg-error "argument 3 must be in the range \\[0, 15\\]" } */
+  res = __builtin_crypto_vshasigmad (test, 1, 0xff); /* { dg-error "argument 3 must be in the range \\\[0, 15\\\]" } */
   return 0;
 }
diff --git a/gcc/testsuite/gcc.target/powerpc/pr80315-3.c b/gcc/testsuite/gcc.target/powerpc/pr80315-3.c
index f1a782663a1..025fdbdf767 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr80315-3.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr80315-3.c
@@ -12,6 +12,6 @@ main ()
   int mask;
 
   /* Argument 2 must be 0 or 1.  Argument 3 must be in range 0..15.  */
-  res = vec_shasigma_be (test, 1, 0xff); /* { dg-error "argument 3 must be in the range \\[0, 15\\]" } */
+  res = vec_shasigma_be (test, 1, 0xff); /* { dg-error "argument 3 must be in the range \\\[0, 15\\\]" } */
   return res;
 }
diff --git a/gcc/testsuite/gcc.target/powerpc/pr80315-4.c b/gcc/testsuite/gcc.target/powerpc/pr80315-4.c
index 66a3efce9c5..d9f7b8dc202 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr80315-4.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr80315-4.c
@@ -12,6 +12,6 @@ main ()
   int mask;
 
   /* Argument 2 must be 0 or 1.  Argument 3 must be in range 0..15.  */
-  res = vec_shasigma_be (test, 1, 0xff); /* { dg-error "argument 3 must be in the range \\[0, 15\\]" } */
+  res = vec_shasigma_be (test, 1, 0xff); /* { dg-error "argument 3 must be in the range \\\[0, 15\\\]" } */
   return res;
 }

Re: [C++ Patch] Two literal operator template location fixes

[Christophe Lyon]

On Tue, 21 May 2019 at 13:03, Paolo Carlini  wrote:
>
> Hi,
>
> also in my back queue a few more location fixes (of course ;) Tested
> x86_64-linux.
>
> Thanks, Paolo.
>
> 
>

Hi,

I think you incorrectly committed an additional chunk:
diff --git a/gcc/testsuite/g++.dg/cpp0x/decltype-pr66548.C
b/gcc/testsuite/g++.dg/cpp0x/decltype-pr66548.C
index f4b7caa..3f20d15 100644
--- a/gcc/testsuite/g++.dg/cpp0x/decltype-pr66548.C
+++ b/gcc/testsuite/g++.dg/cpp0x/decltype-pr66548.C
@@ -11,7 +11,7 @@ struct Meow {};

 void f ()
 {
-  decltype (Meow.purr ()) d;   // { dg-error "expected
primary-expression" "pr89875" { xfail c++98_only } }
+  decltype (Meow.purr ()) d;   // { dg-error "expected primary-expression" }
   (void)&d;
 }


As a result, the test now fails
/gcc/testsuite/g++.dg/cpp0x/decltype-pr66548.C:20:3: error: expected
primary-expression before '__typeof__'
compiler exited with status 1
FAIL: g++.dg/cpp0x/decltype-pr66548.C  -std=gnu++98  (test for errors, line 14)

Christophe

Re: [ARM/FDPIC v5 03/21] [ARM] FDPIC: Force FDPIC related options unless -mno-fdpic is provided

[Szabolcs Nagy]

On 21/05/2019 16:28, Christophe Lyon wrote:
> --- a/gcc/config/arm/linux-eabi.h
> +++ b/gcc/config/arm/linux-eabi.h
> @@ -89,7 +89,7 @@
>  #define MUSL_DYNAMIC_LINKER_E "%{mbig-endian:eb}"
>  #endif
>  #define MUSL_DYNAMIC_LINKER \
> -  "/lib/ld-musl-arm" MUSL_DYNAMIC_LINKER_E "%{mfloat-abi=hard:hf}.so.1"
> +  "/lib/ld-musl-arm" MUSL_DYNAMIC_LINKER_E
> "%{mfloat-abi=hard:hf}%{mfdpic:-fdpic}.so.1"

the line break seems wrong (either needs \ or no newline)

> --- a/libsanitizer/configure.tgt
> +++ b/libsanitizer/configure.tgt
> @@ -45,7 +45,7 @@ case "${target}" in
> ;;
>sparc*-*-solaris2.11*)
> ;;
> -  arm*-*-uclinuxfdpiceabi)
> +  arm*-*-fdpiceabi)

should be *fdpiceabi instead of *-fdpiceabi i think.

Re: [ARM/FDPIC v5 03/21] [ARM] FDPIC: Force FDPIC related options unless -mno-fdpic is provided

[Christophe Lyon]

On Wed, 22 May 2019 at 10:39, Szabolcs Nagy  wrote:
>
> On 21/05/2019 16:28, Christophe Lyon wrote:
> > --- a/gcc/config/arm/linux-eabi.h
> > +++ b/gcc/config/arm/linux-eabi.h
> > @@ -89,7 +89,7 @@
> >  #define MUSL_DYNAMIC_LINKER_E "%{mbig-endian:eb}"
> >  #endif
> >  #define MUSL_DYNAMIC_LINKER \
> > -  "/lib/ld-musl-arm" MUSL_DYNAMIC_LINKER_E "%{mfloat-abi=hard:hf}.so.1"
> > +  "/lib/ld-musl-arm" MUSL_DYNAMIC_LINKER_E
> > "%{mfloat-abi=hard:hf}%{mfdpic:-fdpic}.so.1"
>
> the line break seems wrong (either needs \ or no newline)
>
Sorry, that's a mailer artifact.

> > --- a/libsanitizer/configure.tgt
> > +++ b/libsanitizer/configure.tgt
> > @@ -45,7 +45,7 @@ case "${target}" in
> > ;;
> >sparc*-*-solaris2.11*)
> > ;;
> > -  arm*-*-uclinuxfdpiceabi)
> > +  arm*-*-fdpiceabi)
>
> should be *fdpiceabi instead of *-fdpiceabi i think.

Indeed, thanks

Re: [C++ Patch] Two literal operator template location fixes

[Paolo Carlini]

On 22/05/19 10:28, Christophe Lyon wrote:

On Tue, 21 May 2019 at 13:03, Paolo Carlini  wrote:

Hi,

also in my back queue a few more location fixes (of course ;) Tested
x86_64-linux.

Thanks, Paolo.




Hi,

I think you incorrectly committed an additional chunk:


I fixed that earlier today, sorry.

Paolo.

Re: [PATCH] tree-ssa-uninit: suppress more spurious warnings

[Rainer Orth]

Hi Christophe,

> On Fri, 17 May 2019 at 10:12, Vladislav Ivanishin  wrote:
>>
>> Hi!
>>
>> Without the patch, two of the newly added tests fail with bogus warnings:
>>
>> - gcc.dg/uninit-28-gimple.c (Definition guarded with NE_EXPR, use with
>>   BIT_AND_EXPR.  This is an FP my previous patch [1] knowingly
>>   overlooks.)
>> - gcc.dg/uninit-30-gimple.c (EQ_EXPR in the predicate guarding use.
>>   This is what I spotted while refactoring.  It never worked, and is
>>   easy to handle).
>>
>> Bootstraped with `BOOT_CFLAGS="-O -Wno-error=maybe-uninitialized
>> -Wuninitialized"` and regtested on x86_64-pc-linux-gnu.  OK for trunk?
>>
>
> Hi,
>
> As you have probably noticed already, the new test uninit-28.c fails:
> /gcc/testsuite/gcc.dg/uninit-28-gimple.c:9:16: warning: 'undef' may be
> used uninitialized in this function [-Wmaybe-uninitialized]
> FAIL: gcc.dg/uninit-28-gimple.c  (test for bogus messages, line 9)
> at least on arm & aarch64

I'm seeing it on sparc-sun-solaris2.11, and there are gcc-testresults
reports for i?86, mips64el, powerpc*, s390x, and x86_64.

Rainer

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

Re: [PATCH, i386]: Introduce signbit2 expander

[Rainer Orth]

Hi Uros,

> Based on the recent work that enabled vectorization of
> __builtin_signbit on aarch64.
>
> 2019-05-21  Uroš Bizjak  
>
> * config/i386/sse.md (VF1_AVX2): New mode iterator.
> (signbit2): New expander
>
> testsuite/ChangeLog:
>
> 2019-05-21  Uroš Bizjak  
>
> * gcc.target/i386/vect-signbitf.c: New test.
>
> Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

the new testcase FAILs on i386-pc-solaris2.11 (both with the default
-m32 and -m64), but also on i586-unknown-freebsd11.2, i686-pc-linux-gnu:

+FAIL: gcc.target/i386/vect-signbitf.c scan-assembler-not -2147483648

Rainer

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

Re: [PATCH,RFC 0/3] Support for CTF in GCC

[Richard Biener]

On Wed, May 22, 2019 at 12:34 AM Indu Bhagat  wrote:
>
> Thanks for your feedback. Comments inline.
>
>
> On 05/21/2019 03:28 AM, Richard Biener wrote:
>
> GCC RFC patch set :
> Patch 1 is a simple addition of a new function lang_GNU_GIMPLE to check for
> GIMPLE frontend.
>
> I don't think you should need this - the GIMPLE "frontend" is intended for
> unit testing only, I wouldn't like it to be exposed more.
>
> When using -gt with -flto, I would still like the CTF hooks to be initialized
> so that CTF can be generated when -flto is used. So the check in toplev.c is
> done to allow only C and GNU GIMPLE.  I am fine with doing a string compare
> with the language.hooks string if you suggest to go that way.

I see.  Note that starting with GCC 8 type and declaration debug information
(the only you are interested in it seems) for LTO is generated at compile-time
while LTO ("GNU GIMPLE") only amends it with location information.  So
I believe you do not want to emit CTF from LTO but from the compilation-stage
driven by the appropriate language frontend which is where debug information
for types and decls is emitted.

>
> One of the main high-level design requirements that is relevant in the context
> of the current GCC patch set is that - CTF and DWARF must be able to co-exist.
> A user may want CTF debug information in isolation or with other debug 
> formats.
> A .ctf section is small and unlike other debug sections, ideally should not
> need to be stripped out of the binary/executable.
>
> High-level proposed plan (phase 1) :
> In the next few patches, the functionality to generate contents of the CTF
> section (.ctf) for a single compilation unit will be added.
> Once CTF generation for a single compilation unit stabilizes, LTO and CTF
> generation will be looked at.
>
> Feedback and suggestions welcome.
>
> You probably got asked this question multiple times already, but,
> can CTF information be generated from DWARF instead?
>
> Yes and No :) And that is indeed one of the motivation of the project - to
> allow CTF generation where it's most suited aka the toolchain.
>
> There do exist utilties for generation of CTF from DWARF. For example, one of
> them is the dwarf2ctf in the DTrace Linux distribution. dwarf2ctf works 
> offline
> to transform DWARF generated by the compiler into CTF.
>
> A dependency of an external conversion utility for "post-processing" DWARF
> offline poses several problems:
>
> 1. Deployment problems: the converter should be distributed and integrated in
>the build system of the program.  This, on occasions, can be intrusive.  
> For
>example, in terms of dependencies: the dwarf2ctf converter depends on
>libdwarf from elfutils suite, glib2 (used for the GHashTable), zlib (used 
> to
>compress the CTF information) and libctf (which both reads and writes the
>CTF data).
>
> 2. Performance problems: the conversion from DWARF to CTF can take a long 
> time,
>especially in big programs such as the Linux kernel.
>
> 3. Maintainability problems: the converter should be maintained in order to
>reflect potential changes in the DWARF generated by the compiler.
>
> 4. Adoption problem: it is difficult for applications to adopt the usage of
>CTF, even if it happens to provide what they need, since it would require 
> to
>write a conversion utility or integrate DTrace's.
>
>
>
> The meaning of the CTF acronym suggests that there's nothing
> like locations, registers, etc. but just a representation of the
> types?
>
> Yes. CTF is simply put Type information; no locations, registers etc.
>
>
> Generally we are trying to walk away from supporting multiple
> debug info formats because that gets in the way of being
> more precise from the frontend side.  Since DWARF is the
>
>
> With regard to whether the support for CTF imposes infeasible or distinct
> requirements on the frontend - it does not appear to be the case (I have
> been working on CTF generation in GCC for a SINGLE compilation unit; More see
> below). I agree that CTF debug information generation should ideally not 
> impose
> additional requirements on the frontend.
>
> defacto standard, extensible and with a rich feature set the
> line of thinking is that other formats (like STABS) can be
> generated by "post-processing" DWARF.  Such
> post-processing could happen on the object files or
> on the GCC internal DWARF data structures by
> providing alternate output routines.  That is, the mid-term
> design goal is to make DWARF generation the "API"
> for GCC frontends to use when creating high-level
> debug information rather than trying to abstract from
> the debuginfo format via the current debug-hooks or
> the other way around via language-hooks.
>
> I am not sure if I understood the last part very well, so I will state how CTF
> generation is intended to work. Does the following fit the design goal you
> state ?
>
> ( Caveat : I have been working on the functionality to generate CTF for a 
> SINGLE
>

Re: [PATCH] tree-ssa-uninit: suppress more spurious warnings

[Rainer Orth]

Rainer Orth  writes:

>> On Fri, 17 May 2019 at 10:12, Vladislav Ivanishin  wrote:
>>>
>>> Hi!
>>>
>>> Without the patch, two of the newly added tests fail with bogus warnings:
>>>
>>> - gcc.dg/uninit-28-gimple.c (Definition guarded with NE_EXPR, use with
>>>   BIT_AND_EXPR.  This is an FP my previous patch [1] knowingly
>>>   overlooks.)
>>> - gcc.dg/uninit-30-gimple.c (EQ_EXPR in the predicate guarding use.
>>>   This is what I spotted while refactoring.  It never worked, and is
>>>   easy to handle).
>>>
>>> Bootstraped with `BOOT_CFLAGS="-O -Wno-error=maybe-uninitialized
>>> -Wuninitialized"` and regtested on x86_64-pc-linux-gnu.  OK for trunk?
>>>
>>
>> Hi,
>>
>> As you have probably noticed already, the new test uninit-28.c fails:
>> /gcc/testsuite/gcc.dg/uninit-28-gimple.c:9:16: warning: 'undef' may be
>> used uninitialized in this function [-Wmaybe-uninitialized]
>> FAIL: gcc.dg/uninit-28-gimple.c  (test for bogus messages, line 9)
>> at least on arm & aarch64
>
> I'm seeing it on sparc-sun-solaris2.11, and there are gcc-testresults
> reports for i?86, mips64el, powerpc*, s390x, and x86_64.

There are a couple more testsuite regressions that are likely fallout
from this patch:

+FAIL: gcc.dg/pr67512.c (test for excess errors)

  32 and 64-bit i386-pc-solaris2.11, also on aarch64-unknown-linux-gnu

+FAIL: gcc.dg/uninit-18.c  (test for bogus messages, line 13)

  32 and 64-bit i386-pc-solaris2.11, also on aarch64-unknown-linux-gnu,
  powerpc64le-unknown-linux-gnu

+FAIL: gcc.dg/uninit-pr90394-1-gimple.c  (test for warnings, line 9)

  32 and 64-bit i386-pc-solaris2.11, also on aarch64-unknown-linux-gnu,
  powerpc64le-unknown-linux-gnu, s390x-ibm-linux-gnu

Rainer

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

Re: Backport fix for PR c++/85400

[Richard Biener]

On Wed, May 22, 2019 at 9:43 AM Eric Botcazou  wrote:
>
> Jakub asked me to backport the fix for PR c++/85400 initially intended for
> SPARC/Solaris but which also helps on x86-64/Linux apparently.
>
> Tested on the latter platform, applied on the 8 branch.

Probably also required for GCC 7 then?

Richard.

>
> 2019-05-22  Eric Botcazou  
>
> c-family/
> Backport from mainline
> 2018-05-10  Eric Botcazou  
>
> PR c++/85400
> * c-attribs.c (handle_visibility_attribute): Do not set no_add_attrs.
>
>
> 2019-05-22  Eric Botcazou  
>
> cp/
> Backport from mainline
> 2018-05-10  Eric Botcazou  
>
> PR c++/85400
> * decl2.c (adjust_var_decl_tls_model): New static function.
> (comdat_linkage): Call it on a variable.
> (maybe_make_one_only): Likewise.
>
>
> 2019-05-22  Eric Botcazou  
>
> * g++.dg/tls/pr85400.C: New test.
>
> --
> Eric Botcazou

Re: [PATCH][OBVIOUS] Fix wrong escaping of brackets (PR testsuite/90564).

[Segher Boessenkool]

Hi,

On Wed, May 22, 2019 at 10:24:32AM +0200, Martin Liška wrote:
> The patch fixes couple of tests that I've just tested on ppc64le-linux-gnu.
> 
> I'm going to install the patch.

Could you please not use double quotes, instead?  E.g.

> -  res = __builtin_crypto_vshasigmaw (test, 1, 0xff); /* { dg-error "argument 
> 3 must be in the range \\[0, 15\\]" } */
> +  res = __builtin_crypto_vshasigmaw (test, 1, 0xff); /* { dg-error "argument 
> 3 must be in the range \\\[0, 15\\\]" } */

  res = __builtin_crypto_vshasigmaw (test, 1, 0xff); /* { dg-error {argument 3 
must be in the range \[0, 15\]} } */


Segher

Re: [PATCH, i386]: Introduce signbit2 expander

[Uros Bizjak]

On Wed, May 22, 2019 at 11:04 AM Rainer Orth
 wrote:
>
> Hi Uros,
>
> > Based on the recent work that enabled vectorization of
> > __builtin_signbit on aarch64.
> >
> > 2019-05-21  Uroš Bizjak  
> >
> > * config/i386/sse.md (VF1_AVX2): New mode iterator.
> > (signbit2): New expander
> >
> > testsuite/ChangeLog:
> >
> > 2019-05-21  Uroš Bizjak  
> >
> > * gcc.target/i386/vect-signbitf.c: New test.
> >
> > Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
>
> the new testcase FAILs on i386-pc-solaris2.11 (both with the default
> -m32 and -m64), but also on i586-unknown-freebsd11.2, i686-pc-linux-gnu:
>
> +FAIL: gcc.target/i386/vect-signbitf.c scan-assembler-not -2147483648

It works for me on x86_64-linux-gnu with -32, so I'm at loss on what
might be wrong.

Uros.

Re: [PATCH][RFC] Sanitize equals and hash functions in hash-tables.

[Martin Liška]

On 5/21/19 1:51 PM, Richard Biener wrote:
> On Tue, May 21, 2019 at 1:02 PM Martin Liška  wrote:
>>
>> On 5/21/19 11:38 AM, Richard Biener wrote:
>>> On Tue, May 21, 2019 at 12:07 AM Jeff Law  wrote:

 On 5/13/19 1:41 AM, Martin Liška wrote:
> On 11/8/18 9:56 AM, Martin Liška wrote:
>> On 11/7/18 11:23 PM, Jeff Law wrote:
>>> On 10/30/18 6:28 AM, Martin Liška wrote:
 On 10/30/18 11:03 AM, Jakub Jelinek wrote:
> On Mon, Oct 29, 2018 at 04:14:21PM +0100, Martin Liška wrote:
>> +hashtab_chk_error ()
>> +{
>> +  fprintf (stderr, "hash table checking failed: "
>> +   "equal operator returns true for a pair "
>> +   "of values with a different hash value");
> BTW, either use internal_error here, or at least if using fprintf
> terminate with \n, in your recent mail I saw:
> ...different hash valueduring RTL pass: vartrack
> ^^
 Sure, fixed in attached patch.

 Martin

>> +  gcc_unreachable ();
>> +}
>   Jakub
>
 0001-Sanitize-equals-and-hash-functions-in-hash-tables.patch

 From 0d9c979c845580a98767b83c099053d36eb49bb9 Mon Sep 17 00:00:00 2001
 From: marxin 
 Date: Mon, 29 Oct 2018 09:38:21 +0100
 Subject: [PATCH] Sanitize equals and hash functions in hash-tables.

 ---
  gcc/hash-table.h | 40 +++-
  1 file changed, 39 insertions(+), 1 deletion(-)

 diff --git a/gcc/hash-table.h b/gcc/hash-table.h
 index bd83345c7b8..694eedfc4be 100644
 --- a/gcc/hash-table.h
 +++ b/gcc/hash-table.h
 @@ -503,6 +503,7 @@ private:

value_type *alloc_entries (size_t n CXX_MEM_STAT_INFO) const;
value_type *find_empty_slot_for_expand (hashval_t);
 +  void verify (const compare_type &comparable, hashval_t hash);
bool too_empty_p (unsigned int);
void expand ();
static bool is_deleted (value_type &v)
 @@ -882,8 +883,12 @@ hash_table
if (insert == INSERT && m_size * 3 <= m_n_elements * 4)
  expand ();

 -  m_searches++;
 +#if ENABLE_EXTRA_CHECKING
 +if (insert == INSERT)
 +  verify (comparable, hash);
 +#endif

 +  m_searches++;
value_type *first_deleted_slot = NULL;
hashval_t index = hash_table_mod1 (hash, m_size_prime_index);
hashval_t hash2 = hash_table_mod2 (hash, m_size_prime_index);
 @@ -930,6 +935,39 @@ hash_table
return &m_entries[index];
  }

 +#if ENABLE_EXTRA_CHECKING
 +
 +/* Report a hash table checking error.  */
 +
 +ATTRIBUTE_NORETURN ATTRIBUTE_COLD
 +static void
 +hashtab_chk_error ()
 +{
 +  fprintf (stderr, "hash table checking failed: "
 + "equal operator returns true for a pair "
 + "of values with a different hash value\n");
 +  gcc_unreachable ();
 +}
>>> I think an internal_error here is probably still better than a simple
>>> fprintf, even if the fprintf is terminated with a \n :-)
>> Fully agree with that, but I see a lot of build errors when using 
>> internal_error.
>>
>>> The question then becomes can we bootstrap with this stuff enabled and
>>> if not, are we likely to soon?  It'd be a shame to put it into
>>> EXTRA_CHECKING, but then not be able to really use EXTRA_CHECKING
>>> because we've got too many bugs to fix.
>> Unfortunately it's blocked with these 2 PRs:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87845
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87847
> Hi.
>
> I've just added one more PR:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90450
>
> I'm sending updated version of the patch that provides a disablement for 
> the 3 PRs
> with a new function disable_sanitize_eq_and_hash.
>
> With that I can bootstrap and finish tests. However, I've done that with 
> a patch
> limits maximal number of checks:
 So rather than call the disable_sanitize_eq_and_hash, can you have its
 state set up when you instantiate the object?  It's not a huge deal,
 just thinking about loud.



 So how do we want to go forward, particularly the EXTRA_EXTRA checking
 issue :-)
>>>
>>> There is at least one PR where we have a table where elements _in_ the
>>> table are never compared against each other but always against another
>>> object (I guess that's usual even), but the setup is in a way that the
>>> comparison function only works with those.  With the patch we verify
>>> hashing/comparison for something that is never used.
>>>
>>> So - wouldn't it be more "co

Re: [PATCH][OBVIOUS] Fix wrong escaping of brackets (PR testsuite/90564).

[Martin Liška]

On 5/22/19 11:13 AM, Segher Boessenkool wrote:
> Hi,
> 
> On Wed, May 22, 2019 at 10:24:32AM +0200, Martin Liška wrote:
>> The patch fixes couple of tests that I've just tested on ppc64le-linux-gnu.
>>
>> I'm going to install the patch.
> 
> Could you please not use double quotes, instead?  E.g.
> 
>> -  res = __builtin_crypto_vshasigmaw (test, 1, 0xff); /* { dg-error 
>> "argument 3 must be in the range \\[0, 15\\]" } */
>> +  res = __builtin_crypto_vshasigmaw (test, 1, 0xff); /* { dg-error 
>> "argument 3 must be in the range \\\[0, 15\\\]" } */
> 
>   res = __builtin_crypto_vshasigmaw (test, 1, 0xff); /* { dg-error {argument 
> 3 must be in the range \[0, 15\]} } */
> 
> 
> Segher
> 

Sure, done in the following patch that I've just tested.

Martin
>From 5426287ba0e181b7ba3e04de2472a84c14d389be Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Wed, 22 May 2019 11:17:20 +0200
Subject: [PATCH] Do not use quotes in tests (PR testsuite/90564).

gcc/testsuite/ChangeLog:

2019-05-22  Martin Liska  

	PR testsuite/90564
	* gcc.target/powerpc/pr80315-1.c: Remove usage of quotes.
	* gcc.target/powerpc/pr80315-2.c: Likewise.
	* gcc.target/powerpc/pr80315-3.c: Likewise.
	* gcc.target/powerpc/pr80315-4.c: Likewise.
---
 gcc/testsuite/gcc.target/powerpc/pr80315-1.c | 2 +-
 gcc/testsuite/gcc.target/powerpc/pr80315-2.c | 2 +-
 gcc/testsuite/gcc.target/powerpc/pr80315-3.c | 2 +-
 gcc/testsuite/gcc.target/powerpc/pr80315-4.c | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/pr80315-1.c b/gcc/testsuite/gcc.target/powerpc/pr80315-1.c
index 87b69a6a5d5..e2db0ff4b5f 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr80315-1.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr80315-1.c
@@ -10,6 +10,6 @@ main()
   int mask;
 
   /* Argument 2 must be 0 or 1.  Argument 3 must be in range 0..15.  */
-  res = __builtin_crypto_vshasigmaw (test, 1, 0xff); /* { dg-error "argument 3 must be in the range \\\[0, 15\\\]" } */
+  res = __builtin_crypto_vshasigmaw (test, 1, 0xff); /* { dg-error {argument 3 must be in the range \[0, 15\]} } */
   return 0;
 }
diff --git a/gcc/testsuite/gcc.target/powerpc/pr80315-2.c b/gcc/testsuite/gcc.target/powerpc/pr80315-2.c
index d2de5fd5a47..144b705c012 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr80315-2.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr80315-2.c
@@ -10,6 +10,6 @@ main ()
   int mask;
 
   /* Argument 2 must be 0 or 1.  Argument 3 must be in range 0..15.  */
-  res = __builtin_crypto_vshasigmad (test, 1, 0xff); /* { dg-error "argument 3 must be in the range \\\[0, 15\\\]" } */
+  res = __builtin_crypto_vshasigmad (test, 1, 0xff); /* { dg-error {argument 3 must be in the range \[0, 15\]} } */
   return 0;
 }
diff --git a/gcc/testsuite/gcc.target/powerpc/pr80315-3.c b/gcc/testsuite/gcc.target/powerpc/pr80315-3.c
index 025fdbdf767..99a3e24eadd 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr80315-3.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr80315-3.c
@@ -12,6 +12,6 @@ main ()
   int mask;
 
   /* Argument 2 must be 0 or 1.  Argument 3 must be in range 0..15.  */
-  res = vec_shasigma_be (test, 1, 0xff); /* { dg-error "argument 3 must be in the range \\\[0, 15\\\]" } */
+  res = vec_shasigma_be (test, 1, 0xff); /* { dg-error {argument 3 must be in the range \[0, 15\]} } */
   return res;
 }
diff --git a/gcc/testsuite/gcc.target/powerpc/pr80315-4.c b/gcc/testsuite/gcc.target/powerpc/pr80315-4.c
index d9f7b8dc202..7f5f6f75029 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr80315-4.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr80315-4.c
@@ -12,6 +12,6 @@ main ()
   int mask;
 
   /* Argument 2 must be 0 or 1.  Argument 3 must be in range 0..15.  */
-  res = vec_shasigma_be (test, 1, 0xff); /* { dg-error "argument 3 must be in the range \\\[0, 15\\\]" } */
+  res = vec_shasigma_be (test, 1, 0xff); /* { dg-error {argument 3 must be in the range \[0, 15\]} } */
   return res;
 }
-- 
2.21.0

[PATCH] Fix PR88440, enable mem* detection at -O[2s]

[Richard Biener]

This enables -ftree-loop-distribute-patterns at -O[2s] and also
arranges cold loops to be still processed but for pattern
recognition to save code-size.

Bootstrap and regtest running on x86_64-unknown-linux-gnu.

Martin has done extensive compile-time testing on SPEC
identifying only a single regression I'll have a look into.

Richard.

2019-05-22  Richard Biener  

PR tree-optimization/88440
* opts.c (default_options_table): Enable -ftree-loop-distribute-patterns
at -O[2s]+.
* tree-loop-distribution.c (generate_memset_builtin): Fold the
generated call.
(generate_memcpy_builtin): Likewise.
(distribute_loop): Pass in whether to only distribute patterns.
(prepare_perfect_loop_nest): Also allow size optimization.
(pass_loop_distribution::execute): When optimizing a loop
nest for size allow pattern replacement.

* gcc.dg/tree-ssa/ldist-37.c: New testcase.
* gcc.dg/tree-ssa/ldist-38.c: Likewise.

Index: gcc/opts.c
===
--- gcc/opts.c  (revision 271463)
+++ gcc/opts.c  (working copy)
@@ -550,7 +550,7 @@ static const struct default_options defa
 { OPT_LEVELS_3_PLUS, OPT_fpredictive_commoning, NULL, 1 },
 { OPT_LEVELS_3_PLUS, OPT_fsplit_loops, NULL, 1 },
 { OPT_LEVELS_3_PLUS, OPT_fsplit_paths, NULL, 1 },
-{ OPT_LEVELS_3_PLUS, OPT_ftree_loop_distribute_patterns, NULL, 1 },
+{ OPT_LEVELS_2_PLUS, OPT_ftree_loop_distribute_patterns, NULL, 1 },
 { OPT_LEVELS_3_PLUS, OPT_ftree_loop_distribution, NULL, 1 },
 { OPT_LEVELS_3_PLUS, OPT_ftree_loop_vectorize, NULL, 1 },
 { OPT_LEVELS_3_PLUS, OPT_ftree_partial_pre, NULL, 1 },
Index: gcc/tree-loop-distribution.c
===
--- gcc/tree-loop-distribution.c(revision 271463)
+++ gcc/tree-loop-distribution.c(working copy)
@@ -115,6 +115,7 @@ along with GCC; see the file COPYING3.
 #include "params.h"
 #include "tree-vectorizer.h"
 #include "tree-eh.h"
+#include "gimple-fold.h"
 
 
 #define MAX_DATAREFS_NUM \
@@ -1028,6 +1029,7 @@ generate_memset_builtin (struct loop *lo
   fn = build_fold_addr_expr (builtin_decl_implicit (BUILT_IN_MEMSET));
   fn_call = gimple_build_call (fn, 3, mem, val, nb_bytes);
   gsi_insert_after (&gsi, fn_call, GSI_CONTINUE_LINKING);
+  fold_stmt (&gsi);
 
   if (dump_file && (dump_flags & TDF_DETAILS))
 {
@@ -1071,6 +1073,7 @@ generate_memcpy_builtin (struct loop *lo
   fn = build_fold_addr_expr (builtin_decl_implicit (kind));
   fn_call = gimple_build_call (fn, 3, dest, src, nb_bytes);
   gsi_insert_after (&gsi, fn_call, GSI_CONTINUE_LINKING);
+  fold_stmt (&gsi);
 
   if (dump_file && (dump_flags & TDF_DETAILS))
 {
@@ -2769,7 +2772,8 @@ finalize_partitions (struct loop *loop,
 
 static int
 distribute_loop (struct loop *loop, vec stmts,
-control_dependences *cd, int *nb_calls, bool *destroy_p)
+control_dependences *cd, int *nb_calls, bool *destroy_p,
+bool only_patterns_p)
 {
   ddrs_table = new hash_table (389);
   struct graph *rdg;
@@ -2843,7 +2847,7 @@ distribute_loop (struct loop *loop, vec<
 
   /* If we are only distributing patterns but did not detect any,
  simply bail out.  */
-  if (!flag_tree_loop_distribution
+  if (only_patterns_p
   && !any_builtin)
 {
   nbp = 0;
@@ -2855,7 +2859,7 @@ distribute_loop (struct loop *loop, vec<
  a loop into pieces, separated by builtin calls.  That is, we
  only want no or a single loop body remaining.  */
   struct partition *into;
-  if (!flag_tree_loop_distribution)
+  if (only_patterns_p)
 {
   for (i = 0; partitions.iterate (i, &into); ++i)
if (!partition_builtin_p (into))
@@ -3085,7 +3089,6 @@ prepare_perfect_loop_nest (struct loop *
 && loop_outer (outer)
 && outer->inner == loop && loop->next == NULL
 && single_exit (outer)
-&& optimize_loop_for_speed_p (outer)
 && !chrec_contains_symbols_defined_in_loop (niters, outer->num)
 && (niters = number_of_latch_executions (outer)) != NULL_TREE
 && niters != chrec_dont_know)
@@ -3139,9 +3142,11 @@ pass_loop_distribution::execute (functio
  walking to innermost loops.  */
   FOR_EACH_LOOP (loop, LI_ONLY_INNERMOST)
 {
-  /* Don't distribute multiple exit edges loop, or cold loop.  */
+  /* Don't distribute multiple exit edges loop, or cold loop when
+ not doing pattern detection.  */
   if (!single_exit (loop)
- || !optimize_loop_for_speed_p (loop))
+ || (!flag_tree_loop_distribute_patterns
+ && !optimize_loop_for_speed_p (loop)))
continue;
 
   /* Don't distribute loop if niters is unknown.  */
@@ -3169,9 +3174,10 @@ pass_loop_distribution::execute (functio
 
  bool destroy_p;
  int nb_generated_loops, nb_generated_calls;
- nb_generated_loops = distribute_lo

Re: [PATCH] optc-save-gen.awk: use uintrptr_t for casting of a pointer (PR bootstrap/90543).

[Jakub Jelinek]

On Wed, May 22, 2019 at 10:07:33AM +0200, Martin Liška wrote:
> On 5/22/19 9:50 AM, Jakub Jelinek wrote:
> > On Wed, May 22, 2019 at 09:39:52AM +0200, Martin Liška wrote:
> >> The patch is about using of uintptr_t instead unsigned long that's
> >> being used for printing value of a pointer.
> >>
> >> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> >>
> >> Ready to be installed?
> > 
> > No.  You haven't adjusted the fprintf format strings for this change,
> > so it will break build on any target where uintptr_t is not unsigned long.
> > 
> > I don't see any gcc/ code using the PRIxPTR and similar macros, so no idea
> > about the portability of that, but I'd think we just should keep that as is.
> 
> Ok.

If the problem is just warnings, perhaps you could do
(unsigned long) (uintptr_t) casts instead of directly to (unsigned long),
ideally only for the options with pointer types.
Seems we have:
else if (otype ~ "^const char \\**$")
var_opt_string[n_opt_string++] = name;
else
var_opt_other[n_opt_other++] = name;
and so the
print "  fputs (\"\\n\", file);";
for (i = 0; i < n_opt_other; i++) {
print "  if (ptr1->x_" var_opt_other[i] " != ptr2->x_" var_opt_other[i] 
")";
print "fprintf (file, \"%*s%s (%#lx/%#lx)\\n\",";
print " indent_to, \"\",";
print " \"" var_opt_other[i] "\",";
print " (unsigned long)ptr1->x_" var_opt_other[i] ",";
print " (unsigned long)ptr2->x_" var_opt_other[i] ");";
print "";
}
printing isn't done for strings, we use in that case
for (i = 0; i < n_opt_string; i++) {
name = var_opt_string[i]
print "  if (ptr1->x_" name " != ptr2->x_" name "";
print "  || (!ptr1->x_" name" || !ptr2->x_" name
print "  || strcmp (ptr1->x_" name", ptr2->x_" name ")))";
print "fprintf (file, \"%*s%s (%s/%s)\\n\",";
print " indent_to, \"\",";
print " \"" name "\",";
print " ptr1->x_" name ",";
print " ptr2->x_" name ");";
print "";
}
instead.  So, the only problem is in:
print "  fputs (\"\\n\", file);";
for (i = 0; i < n_target_other; i++) {
print "  if (ptr->x_" var_target_other[i] ")";
hwi = host_wide_int[var_target_other[i]]
if (hwi == "yes")
print "fprintf (file, \"%*s%s (%#\" HOST_WIDE_INT_PRINT 
\"x)\\n\",";
else
print "fprintf (file, \"%*s%s (%#lx)\\n\",";
print " indent, \"\",";
print " \"" var_target_other[i] "\",";
if (hwi == "yes")
print " ptr->x_" var_target_other[i] ");";
else
print " (unsigned long)ptr->x_" var_target_other[i] 
");";
print "";
}
and another similar block with ptr1/ptr2 later.  So, I wonder if you just
shouldn't follow what is done for var_opt_string vs. var_opt_other even in
the var_target_other case, do:
+   else if (otype ~ "^const char \\**$")
+   var_target_string[n_target_string++] = name;
else
var_target_other[n_target_other++] = name;
+ initialization etc. and handle var_target_string differently from
var_target_other for the printing (print it actually with %s instead of
%#lx).

Jakub

[patch] Fix Fortran size_t parameter passing

[Andrew Stubbs]

This patch fixes a bug observed on amdgcn in which the Fortran frontend 
creates function calls using the 32-bit parameters where they ought to 
be 64-bit, resulting in UB.


The issue is caused by the use of "integer_zero_node" where the 
definition of the function calls for "size_zero_node". I presume this 
works on other architectures because the types are the same size, or 
else because parameters are always 64-bit wide.


OK to commit?

Andrew
Fix fortran size_t parameter passing.

2019-05-22  Andrew Stubbs  

	gcc/fortran/
	* trans-stmt.c (gfc_trans_critical): Use size_zero_node for
	gfor_fndecl_caf_lock and gfor_fndecl_caf_unlock calls.
	(gfc_trans_allocate): Use size_zero_node for gfor_fndecl_caf_sync_all
	call.

diff --git a/gcc/fortran/trans-stmt.c b/gcc/fortran/trans-stmt.c
index 5fa182bf05a..4314a1edb90 100644
--- a/gcc/fortran/trans-stmt.c
+++ b/gcc/fortran/trans-stmt.c
@@ -1579,9 +1579,9 @@ gfc_trans_critical (gfc_code *code)
   token = gfc_get_symbol_decl (code->resolved_sym);
   token = GFC_TYPE_ARRAY_CAF_TOKEN (TREE_TYPE (token));
   tmp = build_call_expr_loc (input_location, gfor_fndecl_caf_lock, 7,
- token, integer_zero_node, integer_one_node,
+ token, size_zero_node, integer_one_node,
  null_pointer_node, null_pointer_node,
- null_pointer_node, integer_zero_node);
+ null_pointer_node, size_zero_node);
   gfc_add_expr_to_block (&block, tmp);
 
   /* It guarantees memory consistency within the same segment */
@@ -1602,9 +1602,9 @@ gfc_trans_critical (gfc_code *code)
   if (flag_coarray == GFC_FCOARRAY_LIB)
 {
   tmp = build_call_expr_loc (input_location, gfor_fndecl_caf_unlock, 6,
- token, integer_zero_node, integer_one_node,
+ token, size_zero_node, integer_one_node,
  null_pointer_node, null_pointer_node,
- integer_zero_node);
+ size_zero_node);
   gfc_add_expr_to_block (&block, tmp);
 
   /* It guarantees memory consistency within the same segment */
@@ -6774,7 +6774,7 @@ gfc_trans_allocate (gfc_code * code)
   /* Add a sync all after the allocation has been executed.  */
   tmp = build_call_expr_loc (input_location, gfor_fndecl_caf_sync_all,
  3, null_pointer_node, null_pointer_node,
- integer_zero_node);
+ size_zero_node);
   gfc_add_expr_to_block (&post, tmp);
 }
 

[patch] Fix coarray_lock_7.f90 test failure

[Andrew Stubbs]

The coarray_lock_7.f90 test has fixed-width patterns for matching the 
variable numbers in the dumps. This has caused recent test failures for 
at least amdgcn because changes elsewhere have happened to increase 
those numbers too far.


This patch adds a "\\d+" match to allow variable-width matches.

OK to commit?

Andrew
Fix new coarray failures.

2019-05-22  Andrew Stubbs  

	gcc/testsuite/
	* gfortran.dg/coarray_lock_7.f90: Fix output patterns.

diff --git a/gcc/testsuite/gfortran.dg/coarray_lock_7.f90 b/gcc/testsuite/gfortran.dg/coarray_lock_7.f90
index aedb2267413..4f4bdde856d 100644
--- a/gcc/testsuite/gfortran.dg/coarray_lock_7.f90
+++ b/gcc/testsuite/gfortran.dg/coarray_lock_7.f90
@@ -35,8 +35,8 @@ end
 ! { dg-final { scan-tree-dump-times "_gfortran_caf_lock \\(caf_token.., 0, 0, 0B, 0B, 0B, 0\\);" 1 "original" } }
 ! { dg-final { scan-tree-dump-times "_gfortran_caf_unlock \\(caf_token.., 0, 0, 0B, 0B, 0\\);" 1 "original" } }
 
-! { dg-final { scan-tree-dump-times "_gfortran_caf_lock \\(caf_token.., .*\\(\\(3 - parmdim\\\[0\\\].lbound\\) \\+ \\(MAX_EXPR  \\+ 1\\) \\* \\(3 - parmdim\\\[1\\\].lbound\\)\\), 0, 0B, &ii, 0B, 0\\);|_gfortran_caf_lock \\(caf_token.1, \\(3 - parmdim\\\[0\\\].lbound\\) \\+ \\(MAX_EXPR  \\+ 1\\) \\* \\(3 - parmdim\\\[1\\\].lbound\\), 0, 0B, &ii, 0B, 0\\);" 1 "original" } }
-! { dg-final { scan-tree-dump-times "_gfortran_caf_unlock \\(caf_token.., .*\\(\\(2 - parmdim\\\[0\\\].lbound\\) \\+ \\(MAX_EXPR  \\+ 1\\) \\* \\(3 - parmdim\\\[1\\\].lbound\\)\\), 0, &ii, 0B, 0\\);|_gfortran_caf_unlock \\(caf_token.., \\(2 - parmdim\\\[0\\\].lbound\\) \\+ \\(MAX_EXPR  \\+ 1\\) \\* \\(3 - parmdim\\\[1\\\].lbound\\), 0, &ii, 0B, 0\\);" 1 "original" } }
+! { dg-final { scan-tree-dump-times "_gfortran_caf_lock \\(caf_token.., .*\\(\\(3 - parm.\\d+.dim\\\[0\\\].lbound\\) \\+ \\(MAX_EXPR  \\+ 1\\) \\* \\(3 - parm.\\d+.dim\\\[1\\\].lbound\\)\\), 0, 0B, &ii, 0B, 0\\);|_gfortran_caf_lock \\(caf_token.1, \\(3 - parm.\\d+.dim\\\[0\\\].lbound\\) \\+ \\(MAX_EXPR  \\+ 1\\) \\* \\(3 - parm.\\d+.dim\\\[1\\\].lbound\\), 0, 0B, &ii, 0B, 0\\);" 1 "original" } }
+! { dg-final { scan-tree-dump-times "_gfortran_caf_unlock \\(caf_token.., .*\\(\\(2 - parm.\\d+.dim\\\[0\\\].lbound\\) \\+ \\(MAX_EXPR  \\+ 1\\) \\* \\(3 - parm.\\d+.dim\\\[1\\\].lbound\\)\\), 0, &ii, 0B, 0\\);|_gfortran_caf_unlock \\(caf_token.., \\(2 - parm.\\d+.dim\\\[0\\\].lbound\\) \\+ \\(MAX_EXPR  \\+ 1\\) \\* \\(3 - parm.\\d+.dim\\\[1\\\].lbound\\), 0, &ii, 0B, 0\\);" 1 "original" } }
 
 ! { dg-final { scan-tree-dump-times "_gfortran_caf_lock \\(three.token, 0, \\(integer\\(kind=4\\)\\) \\(5 - three.dim\\\[0\\\].lbound\\), &acquired.\[0-9\]+, 0B, 0B, 0\\);|_gfortran_caf_lock \\(three.token, 0, 5 - three.dim\\\[0\\\].lbound, &acquired.\[0-9\]+, 0B, 0B, 0\\);" 1 "original" } }
 ! { dg-final { scan-tree-dump-times "_gfortran_caf_unlock \\(three.token, 0, \\(integer\\(kind=4\\)\\) \\(8 - three.dim\\\[0\\\].lbound\\), &ii, 0B, 0\\);|_gfortran_caf_unlock \\(three.token, 0, 8 - three.dim\\\[0\\\].lbound, &ii, 0B, 0\\);" 1 "original" } }

Re: [PATCH] optc-save-gen.awk: use uintrptr_t for casting of a pointer (PR bootstrap/90543).

[Martin Liška]

On 5/22/19 11:40 AM, Jakub Jelinek wrote:
> On Wed, May 22, 2019 at 10:07:33AM +0200, Martin Liška wrote:
>> On 5/22/19 9:50 AM, Jakub Jelinek wrote:
>>> On Wed, May 22, 2019 at 09:39:52AM +0200, Martin Liška wrote:
 The patch is about using of uintptr_t instead unsigned long that's
 being used for printing value of a pointer.

 Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

 Ready to be installed?
>>>
>>> No.  You haven't adjusted the fprintf format strings for this change,
>>> so it will break build on any target where uintptr_t is not unsigned long.
>>>
>>> I don't see any gcc/ code using the PRIxPTR and similar macros, so no idea
>>> about the portability of that, but I'd think we just should keep that as is.
>>
>> Ok.
> 
> If the problem is just warnings, perhaps you could do
> (unsigned long) (uintptr_t) casts instead of directly to (unsigned long),
> ideally only for the options with pointer types.

I'm sending patch for it.

> Seems we have:
> else if (otype ~ "^const char \\**$")
> var_opt_string[n_opt_string++] = name;
> else
> var_opt_other[n_opt_other++] = name;
> and so the
> print "  fputs (\"\\n\", file);";
> for (i = 0; i < n_opt_other; i++) {
> print "  if (ptr1->x_" var_opt_other[i] " != ptr2->x_" 
> var_opt_other[i] ")";
> print "fprintf (file, \"%*s%s (%#lx/%#lx)\\n\",";
> print " indent_to, \"\",";
> print " \"" var_opt_other[i] "\",";
> print " (unsigned long)ptr1->x_" var_opt_other[i] ",";
> print " (unsigned long)ptr2->x_" var_opt_other[i] ");";
> print "";
> }
> printing isn't done for strings, we use in that case
> for (i = 0; i < n_opt_string; i++) {
> name = var_opt_string[i]
> print "  if (ptr1->x_" name " != ptr2->x_" name "";
> print "  || (!ptr1->x_" name" || !ptr2->x_" name
> print "  || strcmp (ptr1->x_" name", ptr2->x_" name ")))";
> print "fprintf (file, \"%*s%s (%s/%s)\\n\",";
> print " indent_to, \"\",";
> print " \"" name "\",";
> print " ptr1->x_" name ",";
> print " ptr2->x_" name ");";
> print "";
> }
> instead.  So, the only problem is in:
> print "  fputs (\"\\n\", file);";
> for (i = 0; i < n_target_other; i++) {
> print "  if (ptr->x_" var_target_other[i] ")";
> hwi = host_wide_int[var_target_other[i]]
> if (hwi == "yes")
> print "fprintf (file, \"%*s%s (%#\" HOST_WIDE_INT_PRINT 
> \"x)\\n\",";
> else
> print "fprintf (file, \"%*s%s (%#lx)\\n\",";
> print " indent, \"\",";
> print " \"" var_target_other[i] "\",";
> if (hwi == "yes")
> print " ptr->x_" var_target_other[i] ");";
> else
> print " (unsigned long)ptr->x_" 
> var_target_other[i] ");";
> print "";
> }
> and another similar block with ptr1/ptr2 later.  So, I wonder if you just
> shouldn't follow what is done for var_opt_string vs. var_opt_other even in
> the var_target_other case, do:
> + else if (otype ~ "^const char \\**$")
> + var_target_string[n_target_string++] = name;
>   else
>   var_target_other[n_target_other++] = name;
> + initialization etc. and handle var_target_string differently from
> var_target_other for the printing (print it actually with %s instead of
> %#lx).

No, you want to print a value, which can be an integer type, or a pointer
to an array. So you don't want to use %s.

Martin

> 
>   Jakub
> 

>From a8e5bd9cd741cba2841c13e5120ded3669e396a4 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Wed, 22 May 2019 13:17:03 +0200
Subject: [PATCH] Patch candidate.

---
 gcc/optc-save-gen.awk | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/gcc/optc-save-gen.awk b/gcc/optc-save-gen.awk
index 7ecd1eb9cc7..de590c682a8 100644
--- a/gcc/optc-save-gen.awk
+++ b/gcc/optc-save-gen.awk
@@ -213,7 +213,7 @@ for (i = 0; i < n_opt_other; i++) {
 	print "fprintf (file, \"%*s%s (%#lx)\\n\",";
 	print " indent_to, \"\",";
 	print " \"" var_opt_other[i] "\",";
-	print " (unsigned long)ptr->x_" var_opt_other[i] ");";
+	print " (unsigned long)(intptr_t)ptr->x_" var_opt_other[i] ");";
 	print "";
 }
 
@@ -278,8 +278,8 @@ for (i = 0; i < n_opt_other; i++) {
 	print "fprintf (file, \"%*s%s (%#lx/%#lx)\\n\",";
 	print " indent_to, \"\",";
 	print " \"" var_opt_other[i] "\",";
-	print " (unsigned long)ptr1->x_" var_opt_other[i] ",";
-	print " (unsigned long)ptr2->x_" var_opt_other[i] ");";
+	print " (unsi

Re: [PATCH] optc-save-gen.awk: use uintrptr_t for casting of a pointer (PR bootstrap/90543).

[Jakub Jelinek]

On Wed, May 22, 2019 at 01:19:37PM +0200, Martin Liška wrote:
> > and another similar block with ptr1/ptr2 later.  So, I wonder if you just
> > shouldn't follow what is done for var_opt_string vs. var_opt_other even in
> > the var_target_other case, do:
> > +   else if (otype ~ "^const char \\**$")
> > +   var_target_string[n_target_string++] = name;
> > else
> > var_target_other[n_target_other++] = name;
> > + initialization etc. and handle var_target_string differently from
> > var_target_other for the printing (print it actually with %s instead of
> > %#lx).
> 
> No, you want to print a value, which can be an integer type, or a pointer
> to an array. So you don't want to use %s.

No, IMHO you do want to use %s, patch below.  I've found a couple of other
bugs in optc-save-gen.awk.  Attached is a diff between aarch64 target
options-save.c before and after this patch.

The other bugs were that cl_optimization_print had a typo in the condition
and so guarded the printing on the value of an unrelated option, and that
not all C libraries print (null) instead of crashing when passing NULL to
%s.

Tested on x86_64-linux and aarch64-linux (cross), ok for trunk?

2019-05-22  Jakub Jelinek  

PR bootstrap/90543
* optc-save-gen.awk: In cl_optimization_print, use correct condition
for var_opt_string printing.  In cl_optimization_print_diff, print
(null) instead of invoking undefined behavior if one of the
var_opt_string pointers is NULL.  For var_target_other options, handle
const char * target variables similarly to const char * optimize node
variables.

--- gcc/optc-save-gen.awk.jj2019-02-15 08:16:22.838993512 +0100
+++ gcc/optc-save-gen.awk   2019-05-22 13:16:26.596524297 +0200
@@ -253,7 +253,7 @@ for (i = 0; i < n_opt_char; i++) {
 }
 
 for (i = 0; i < n_opt_string; i++) {
-   print "  if (ptr->x_" var_opt_char[i] ")";
+   print "  if (ptr->x_" var_opt_string[i] ")";
print "fprintf (file, \"%*s%s (%s)\\n\",";
print " indent_to, \"\",";
print " \"" var_opt_string[i] "\",";
@@ -331,8 +331,8 @@ for (i = 0; i < n_opt_string; i++) {
print "fprintf (file, \"%*s%s (%s/%s)\\n\",";
print " indent_to, \"\",";
print " \"" name "\",";
-   print " ptr1->x_" name ",";
-   print " ptr2->x_" name ");";
+   print " ptr1->x_" name " ? : ptr1->x_" name " : 
\"(null)\",";
+   print " ptr2->x_" name " ? : ptr1->x_" name " : 
\"(null)\");";
print "";
 }
 
@@ -349,6 +349,7 @@ n_target_char = 0;
 n_target_short = 0;
 n_target_int = 0;
 n_target_enum = 0;
+n_target_string = 0;
 n_target_other = 0;
 
 if (have_save) {
@@ -381,6 +382,8 @@ if (have_save) {
if (otype == var_type(flags[i]))
var_target_range[name] = ""
}
+   else if (otype ~ "^const char \\**$")
+   var_target_string[n_target_string++] = name;
else
var_target_other[n_target_other++] = name;
}
@@ -429,6 +432,10 @@ for (i = 0; i < n_target_char; i++) {
print "  ptr->x_" var_target_char[i] " = opts->x_" var_target_char[i] 
";";
 }
 
+for (i = 0; i < n_target_string; i++) {
+   print "  ptr->x_" var_target_string[i] " = opts->x_" 
var_target_string[i] ";";
+}
+
 print "}";
 
 print "";
@@ -461,6 +468,10 @@ for (i = 0; i < n_target_char; i++) {
print "  opts->x_" var_target_char[i] " = ptr->x_" var_target_char[i] 
";";
 }
 
+for (i = 0; i < n_target_string; i++) {
+   print "  opts->x_" var_target_string[i] " = ptr->x_" 
var_target_string[i] ";";
+}
+
 # This must occur after the normal variables in case the code depends on those
 # variables.
 print "";
@@ -530,6 +541,15 @@ for (i = 0; i < n_target_char; i++) {
print "";
 }
 
+for (i = 0; i < n_target_string; i++) {
+   print "  if (ptr->x_" var_target_string[i] ")";
+   print "fprintf (file, \"%*s%s (%s)\\n\",";
+   print " indent, \"\",";
+   print " \"" var_target_string[i] "\",";
+   print " ptr->x_" var_target_string[i] ");";
+   print "";
+}
+
 print "";
 print "  if (targetm.target_option.print)";
 print "targetm.target_option.print (file, indent, ptr);";
@@ -605,6 +625,19 @@ for (i = 0; i < n_target_char; i++) {
print "";
 }
 
+for (i = 0; i < n_target_string; i++) {
+   name = var_target_string[i]
+   print "  if (ptr1->x_" name " != ptr2->x_" name "";
+   print "  || (!ptr1->x_" name" || !ptr2->x_" name
+   print "  || strcmp (ptr1->x_" name", ptr2->x_" name ")))";
+   print "fprintf (file, \"%*s%s (%s/%s)\\n\",";
+   print "

Re: [patch] Fix Fortran size_t parameter passing

[Janne Blomqvist]

On Wed, May 22, 2019 at 1:54 PM Andrew Stubbs  wrote:
>
> This patch fixes a bug observed on amdgcn in which the Fortran frontend
> creates function calls using the 32-bit parameters where they ought to
> be 64-bit, resulting in UB.
>
> The issue is caused by the use of "integer_zero_node" where the
> definition of the function calls for "size_zero_node". I presume this
> works on other architectures because the types are the same size, or
> else because parameters are always 64-bit wide.
>
> OK to commit?
>
> Andrew

Thanks for the catch. Though for size_t you should use build_zero_cst
(size_type_node). size_zero_node is a zero constant of type sizetype,
which is not the same as size_type_node (size_t in C). Ok with that
change.


-- 
Janne Blomqvist

Re: [patch] Fix coarray_lock_7.f90 test failure

[Janne Blomqvist]

On Wed, May 22, 2019 at 1:59 PM Andrew Stubbs  wrote:
>
> The coarray_lock_7.f90 test has fixed-width patterns for matching the
> variable numbers in the dumps. This has caused recent test failures for
> at least amdgcn because changes elsewhere have happened to increase
> those numbers too far.
>
> This patch adds a "\\d+" match to allow variable-width matches.
>
> OK to commit?

Ok.


-- 
Janne Blomqvist

Re: [PATCH] optc-save-gen.awk: use uintrptr_t for casting of a pointer (PR bootstrap/90543).

[Martin Liška]

On 5/22/19 1:27 PM, Jakub Jelinek wrote:
> On Wed, May 22, 2019 at 01:19:37PM +0200, Martin Liška wrote:
>>> and another similar block with ptr1/ptr2 later.  So, I wonder if you just
>>> shouldn't follow what is done for var_opt_string vs. var_opt_other even in
>>> the var_target_other case, do:
>>> +   else if (otype ~ "^const char \\**$")
>>> +   var_target_string[n_target_string++] = name;
>>> else
>>> var_target_other[n_target_other++] = name;
>>> + initialization etc. and handle var_target_string differently from
>>> var_target_other for the printing (print it actually with %s instead of
>>> %#lx).
>>
>> No, you want to print a value, which can be an integer type, or a pointer
>> to an array. So you don't want to use %s.
> 
> No, IMHO you do want to use %s, patch below.  I've found a couple of other
> bugs in optc-save-gen.awk.  Attached is a diff between aarch64 target
> options-save.c before and after this patch.
> 
> The other bugs were that cl_optimization_print had a typo in the condition
> and so guarded the printing on the value of an unrelated option, and that
> not all C libraries print (null) instead of crashing when passing NULL to
> %s.
> 
> Tested on x86_64-linux and aarch64-linux (cross), ok for trunk?
> 
> 2019-05-22  Jakub Jelinek  
> 
>   PR bootstrap/90543
>   * optc-save-gen.awk: In cl_optimization_print, use correct condition
>   for var_opt_string printing.  In cl_optimization_print_diff, print
>   (null) instead of invoking undefined behavior if one of the
>   var_opt_string pointers is NULL.  For var_target_other options, handle
>   const char * target variables similarly to const char * optimize node
>   variables.
> 
> --- gcc/optc-save-gen.awk.jj  2019-02-15 08:16:22.838993512 +0100
> +++ gcc/optc-save-gen.awk 2019-05-22 13:16:26.596524297 +0200
> @@ -253,7 +253,7 @@ for (i = 0; i < n_opt_char; i++) {
>  }
>  
>  for (i = 0; i < n_opt_string; i++) {
> - print "  if (ptr->x_" var_opt_char[i] ")";
> + print "  if (ptr->x_" var_opt_string[i] ")";
>   print "fprintf (file, \"%*s%s (%s)\\n\",";
>   print " indent_to, \"\",";
>   print " \"" var_opt_string[i] "\",";
> @@ -331,8 +331,8 @@ for (i = 0; i < n_opt_string; i++) {
>   print "fprintf (file, \"%*s%s (%s/%s)\\n\",";
>   print " indent_to, \"\",";
>   print " \"" name "\",";
> - print " ptr1->x_" name ",";
> - print " ptr2->x_" name ");";
> + print " ptr1->x_" name " ? : ptr1->x_" name " : 
> \"(null)\",";
> + print " ptr2->x_" name " ? : ptr1->x_" name " : 
> \"(null)\");";

There are typos: "? :"

options-save.c:3786:67: error: expected ‘)’ before ‘:’ token
  ptr2->x_str_align_labels ? : ptr1->x_str_align_labels : "(null)");
   ^~
>   print "";
>  }
>  
> @@ -349,6 +349,7 @@ n_target_char = 0;
>  n_target_short = 0;
>  n_target_int = 0;
>  n_target_enum = 0;
> +n_target_string = 0;
>  n_target_other = 0;
>  
>  if (have_save) {
> @@ -381,6 +382,8 @@ if (have_save) {
>   if (otype == var_type(flags[i]))
>   var_target_range[name] = ""
>   }
> + else if (otype ~ "^const char \\**$")
> + var_target_string[n_target_string++] = name;
>   else
>   var_target_other[n_target_other++] = name;
>   }
> @@ -429,6 +432,10 @@ for (i = 0; i < n_target_char; i++) {
>   print "  ptr->x_" var_target_char[i] " = opts->x_" var_target_char[i] 
> ";";
>  }
>  
> +for (i = 0; i < n_target_string; i++) {
> + print "  ptr->x_" var_target_string[i] " = opts->x_" 
> var_target_string[i] ";";
> +}
> +
>  print "}";
>  
>  print "";
> @@ -461,6 +468,10 @@ for (i = 0; i < n_target_char; i++) {
>   print "  opts->x_" var_target_char[i] " = ptr->x_" var_target_char[i] 
> ";";
>  }
>  
> +for (i = 0; i < n_target_string; i++) {
> + print "  opts->x_" var_target_string[i] " = ptr->x_" 
> var_target_string[i] ";";
> +}
> +
>  # This must occur after the normal variables in case the code depends on 
> those
>  # variables.
>  print "";
> @@ -530,6 +541,15 @@ for (i = 0; i < n_target_char; i++) {
>   print "";
>  }
>  
> +for (i = 0; i < n_target_string; i++) {
> + print "  if (ptr->x_" var_target_string[i] ")";
> + print "fprintf (file, \"%*s%s (%s)\\n\",";
> + print " indent, \"\",";
> + print " \"" var_target_string[i] "\",";
> + print " ptr->x_" var_target_string[i] ");";
> + print "";
> +}
> +
>  print "";
>  print "  if (targetm.target_option.print)";
>  print "targetm.target_option.print (file, indent, ptr);";
> @@ -605,6 +625,19 @@ 

[PATCH] Assorted optc-save-gen.awk fixes (PR bootstrap/90543)

[Jakub Jelinek]

On Wed, May 22, 2019 at 01:27:04PM +0200, Jakub Jelinek wrote:
> No, IMHO you do want to use %s, patch below.  I've found a couple of other
> bugs in optc-save-gen.awk.  Attached is a diff between aarch64 target
> options-save.c before and after this patch.
> 
> The other bugs were that cl_optimization_print had a typo in the condition
> and so guarded the printing on the value of an unrelated option, and that
> not all C libraries print (null) instead of crashing when passing NULL to
> %s.
> 
> Tested on x86_64-linux and aarch64-linux (cross), ok for trunk?

I ended up sending a non-final version which actually didn't compile (extra
: after ?), but also found another issue since then, conditions like:
  if (ptr1->x_str_align_functions != ptr2->x_str_align_functions
  || (!ptr1->x_str_align_functions || !ptr2->x_str_align_functions
  || strcmp (ptr1->x_str_align_functions, ptr2->x_str_align_functions)))
fprintf (file, "%*s%s (%s/%s)\n",
 indent_to, "",
 "str_align_functions",
 ptr1->x_str_align_functions,
 ptr2->x_str_align_functions);
don't really make any sense, if ptr1->x_str_align_functions != 
ptr2->x_str_align_functions
is false, then either both are NULL (but then we do not want to print
anything), or strcmp will be necessarily 0 (for both pointers).  What we
actually want is
  if (ptr1->x_str_align_functions != ptr2->x_str_align_functions
  && (!ptr1->x_str_align_functions || !ptr2->x_str_align_functions
  || strcmp (ptr1->x_str_align_functions, ptr2->x_str_align_functions)))
note the && instead of ||.

So, here is a new patch and a new aarch64 options-save.c diff.

Ok for trunk if it passes full bootstrap/regtest on x86_64-linux (passed
already normal build on aarch64-linux cross)?

2019-05-22  Jakub Jelinek  

PR bootstrap/90543
* optc-save-gen.awk: In cl_optimization_print, use correct condition
for var_opt_string printing.  In cl_optimization_print_diff, print
(null) instead of invoking undefined behavior if one of the
var_opt_string pointers is NULL and use && instead of first || in the
guarding condition.  For var_target_other options, handle const char *
target variables similarly to const char * optimize node variables.

--- gcc/optc-save-gen.awk.jj2019-02-15 08:16:22.838993512 +0100
+++ gcc/optc-save-gen.awk   2019-05-22 13:33:11.128183956 +0200
@@ -253,7 +253,7 @@ for (i = 0; i < n_opt_char; i++) {
 }
 
 for (i = 0; i < n_opt_string; i++) {
-   print "  if (ptr->x_" var_opt_char[i] ")";
+   print "  if (ptr->x_" var_opt_string[i] ")";
print "fprintf (file, \"%*s%s (%s)\\n\",";
print " indent_to, \"\",";
print " \"" var_opt_string[i] "\",";
@@ -326,13 +326,13 @@ for (i = 0; i < n_opt_char; i++) {
 for (i = 0; i < n_opt_string; i++) {
name = var_opt_string[i]
print "  if (ptr1->x_" name " != ptr2->x_" name "";
-   print "  || (!ptr1->x_" name" || !ptr2->x_" name
+   print "  && (!ptr1->x_" name" || !ptr2->x_" name
print "  || strcmp (ptr1->x_" name", ptr2->x_" name ")))";
print "fprintf (file, \"%*s%s (%s/%s)\\n\",";
print " indent_to, \"\",";
print " \"" name "\",";
-   print " ptr1->x_" name ",";
-   print " ptr2->x_" name ");";
+   print " ptr1->x_" name " ? ptr1->x_" name " : \"(null)\",";
+   print " ptr2->x_" name " ? ptr1->x_" name " : \"(null)\");";
print "";
 }
 
@@ -349,6 +349,7 @@ n_target_char = 0;
 n_target_short = 0;
 n_target_int = 0;
 n_target_enum = 0;
+n_target_string = 0;
 n_target_other = 0;
 
 if (have_save) {
@@ -381,6 +382,8 @@ if (have_save) {
if (otype == var_type(flags[i]))
var_target_range[name] = ""
}
+   else if (otype ~ "^const char \\**$")
+   var_target_string[n_target_string++] = name;
else
var_target_other[n_target_other++] = name;
}
@@ -429,6 +432,10 @@ for (i = 0; i < n_target_char; i++) {
print "  ptr->x_" var_target_char[i] " = opts->x_" var_target_char[i] 
";";
 }
 
+for (i = 0; i < n_target_string; i++) {
+   print "  ptr->x_" var_target_string[i] " = opts->x_" 
var_target_string[i] ";";
+}
+
 print "}";
 
 print "";
@@ -461,6 +468,10 @@ for (i = 0; i < n_target_char; i++) {
print "  opts->x_" var_target_char[i] " = ptr->x_" var_target_char[i] 
";";
 }
 
+for (i = 0; i < n_target_string; i++) {
+   print "  opts->x_" var_target_string[i] " = ptr->x_" 
var_target_string[i] ";";
+}
+
 # This must occur after the normal variables in case the code depends on those
 # variables.
 print "";
@@ -530,6 +541,15 @@ for (i = 0; i < n_target_char; i++) {

cse.c typo fix

[Prathamesh Kulkarni]

Hi,
The attached patch fixes a typo in cse_dump_path, which I came across
while debugging another issue. OK to commit ?

Thanks,
Prathamesh
2019-05-22  Prathamesh Kulkarni  

* cse.c (cse_dump_path): s/dump_file/f.

diff --git a/gcc/cse.c b/gcc/cse.c
index 6c9cda16a98..35840a6d5ca 100644
--- a/gcc/cse.c
+++ b/gcc/cse.c
@@ -6512,7 +6512,7 @@ cse_dump_path (struct cse_basic_block_data *data, int 
nsets, FILE *f)
   fprintf (f, ";; Following path with %d sets: ", nsets);
   for (path_entry = 0; path_entry < data->path_size; path_entry++)
 fprintf (f, "%d ", (data->path[path_entry].bb)->index);
-  fputc ('\n', dump_file);
+  fputc ('\n', f);
   fflush (f);
 }
 

Re: Fix MEM_REF creation for shared stack slots

[Richard Biener]

On Tue, 21 May 2019, Richard Biener wrote:

> And that should be done at RTL creation time instead of
> repeatedly over and over.  Like with the following.
> 
> Bootstrap / regtest on x86_64-unknown-linux-gnu in progress.

But we can't get away w/o unsharing the expr we change so committed
as follows after Bootstrap / regtest on x86_64-unknown-linux-gnu.

Richard.

2019-05-22  Richard Biener  

* alias.c (ao_ref_from_mem): Move stack-slot sharing
rewrite ...
* emit-rtl.c (set_mem_attributes_minus_bitpos): ... here.

Index: gcc/alias.c
===
--- gcc/alias.c (revision 271500)
+++ gcc/alias.c (working copy)
@@ -307,18 +307,6 @@ ao_ref_from_mem (ao_ref *ref, const_rtx
&& TREE_CODE (TMR_BASE (base)) == SSA_NAME)))
 return false;
 
-  /* If this is a reference based on a partitioned decl replace the
- base with a MEM_REF of the pointer representative we
- created during stack slot partitioning.  */
-  if (VAR_P (base)
-  && ! is_global_var (base)
-  && cfun->gimple_df->decls_to_pointers != NULL)
-{
-  tree *namep = cfun->gimple_df->decls_to_pointers->get (base);
-  if (namep)
-   ref->base = build_simple_mem_ref (*namep);
-}
-
   ref->ref_alias_set = MEM_ALIAS_SET (mem);
 
   /* If MEM_OFFSET or MEM_SIZE are unknown what we got from MEM_EXPR
Index: gcc/emit-rtl.c
===
--- gcc/emit-rtl.c  (revision 271500)
+++ gcc/emit-rtl.c  (working copy)
@@ -61,6 +61,9 @@ along with GCC; see the file COPYING3.
 #include "opts.h"
 #include "predict.h"
 #include "rtx-vector-builder.h"
+#include "gimple.h"
+#include "gimple-ssa.h"
+#include "gimplify.h"
 
 struct target_rtl default_target_rtl;
 #if SWITCHABLE_TARGET
@@ -2128,6 +2131,27 @@ set_mem_attributes_minus_bitpos (rtx ref
  apply_bitpos = bitpos;
}
 
+  /* If this is a reference based on a partitioned decl replace the
+base with a MEM_REF of the pointer representative we created
+during stack slot partitioning.  */
+  if (attrs.expr
+ && VAR_P (base)
+ && ! is_global_var (base)
+ && cfun->gimple_df->decls_to_pointers != NULL)
+   {
+ tree *namep = cfun->gimple_df->decls_to_pointers->get (base);
+ if (namep)
+   {
+ attrs.expr = unshare_expr (attrs.expr);
+ tree *orig_base = &attrs.expr;
+ while (handled_component_p (*orig_base))
+   orig_base = &TREE_OPERAND (*orig_base, 0);
+ tree aptrt = reference_alias_ptr_type (*orig_base);
+ *orig_base = build2 (MEM_REF, TREE_TYPE (*orig_base), *namep,
+  build_int_cst (aptrt, 0));
+   }
+   }
+
   /* Compute the alignment.  */
   unsigned int obj_align;
   unsigned HOST_WIDE_INT obj_bitpos;

Re: cse.c typo fix

[Jeff Law]

On 5/22/19 5:46 AM, Prathamesh Kulkarni wrote:
> Hi,
> The attached patch fixes a typo in cse_dump_path, which I came across
> while debugging another issue. OK to commit ?
OK
jeff

Re: *ping* Re: [PATCH] PR fortran/89100 Default widths for i, f and g format specifiers in format strings

[Janne Blomqvist]

On Wed, May 22, 2019 at 10:58 AM Mark Eggleston
 wrote:
>
> On 13/05/2019 10:45, Mark Eggleston wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89100 see comment 4
> >
> > Please can someone commit the attached patch as I do not have commit
> > rights.
> >
> > Change logs:
> >
> > For gcc/fortran
> >
> > Jeff Law  
> > Mark Eggleston  
> >
> > PR fortran/89100
> > * gfortran.texi: Add Default widths for F, G and I format descriptors
> > to Extensions section.
> > * invoke.texi: Add -fdec-format-defaults
> > * io.c (check_format): Use default widths for i, f and g when
> > flag_dec_format_defaults is enabled.
> > * lang.opt: Add new option.
> > * options.c (set_dec_flags): Add SET_BITFLAG for
> > flag_dec_format_defaults.
> >
> > For gcc/testsuite
> >
> > Mark Eggleston 
> >
> > PR fortran/89100
> > * gfortran.dg/fmt_f_default_field_width_1.f90: New test.
> > * gfortran.dg/fmt_f_default_field_width_2.f90: New test.
> > * gfortran.dg/fmt_f_default_field_width_3.f90: New test.
> > * gfortran.dg/fmt_g_default_field_width_1.f90: New test.
> > * gfortran.dg/fmt_g_default_field_width_2.f90: New test.
> > * gfortran.dg/fmt_g_default_field_width_3.f90: New test.
> > * gfortran.dg/fmt_i_default_field_width_1.f90: New test.
> > * gfortran.dg/fmt_i_default_field_width_2.f90: New test.
> > * gfortran.dg/fmt_i_default_field_width_3.f90: New test.
> >
> > For libgfortran
> >
> > Jeff Law  
> >
> > PR fortran/89100
> > * io/format.c (parse_format_list): set default width when the
> > IOPARM_DT_DEC_EXT flag is set for i, f and g.
> > * io/io.h: add default_width_for_integer, default_width_for_float
> > and default_precision_for_float.
> > * io/write.c (write_boz): extra parameter giving length of data
> > corresponding to the type's kind.
> > (write_b): pass data length as extra parameter in calls to write_boz.
> > (write_o): pass data length as extra parameter in calls to write_boz.
> > (write_z): pass data length as extra parameter in calls to write_boz.
> > (size_from_kind): also set size is default width is set.
> > * io/write_float.def (build_float_string): new paramter inserted
> > before
> > result parameter. If default width use values passed instead of the
> > values in fnode.
> > (FORMAT_FLOAT): macro modified to check for default width and
> > calls to
> > build_float_string to pass in default width.
> > (get_float_string): set width and precision to defaults when needed.
> >
> >
> ping?


Committed as r271511.

-- 
Janne Blomqvist

Re: [patch] Fix Fortran size_t parameter passing

[Andrew Stubbs]

On 22/05/2019 12:35, Janne Blomqvist wrote:

Thanks for the catch. Though for size_t you should use build_zero_cst
(size_type_node). size_zero_node is a zero constant of type sizetype,
which is not the same as size_type_node (size_t in C). Ok with that
change.


So, integer_zero_node is compatible with integer_type_node, but 
size_zero_node is not (necessarily) compatible with size_type_node? 
Well, that's just asking for trouble. :-(


Just to confirm, is the attached what you mean?

Thanks

Andrew

Fix fortran size_type_node parameter passing.

2019-05-22  Andrew Stubbs  

	gcc/fortran/
	* trans-stmt.c (gfc_trans_critical): Use size_type_node for
	gfor_fndecl_caf_lock and gfor_fndecl_caf_unlock calls.
	(gfc_trans_allocate): Use size_type_node for gfor_fndecl_caf_sync_all
	call.

diff --git a/gcc/fortran/trans-stmt.c b/gcc/fortran/trans-stmt.c
index 5fa182bf05a..7c365634085 100644
--- a/gcc/fortran/trans-stmt.c
+++ b/gcc/fortran/trans-stmt.c
@@ -1576,12 +1576,13 @@ gfc_trans_critical (gfc_code *code)
 
   if (flag_coarray == GFC_FCOARRAY_LIB)
 {
+  tree zero_size = build_zero_cst (size_type_node);
   token = gfc_get_symbol_decl (code->resolved_sym);
   token = GFC_TYPE_ARRAY_CAF_TOKEN (TREE_TYPE (token));
   tmp = build_call_expr_loc (input_location, gfor_fndecl_caf_lock, 7,
- token, integer_zero_node, integer_one_node,
+ token, zero_size, integer_one_node,
  null_pointer_node, null_pointer_node,
- null_pointer_node, integer_zero_node);
+ null_pointer_node, zero_size);
   gfc_add_expr_to_block (&block, tmp);
 
   /* It guarantees memory consistency within the same segment */
@@ -1601,10 +1602,11 @@ gfc_trans_critical (gfc_code *code)
 
   if (flag_coarray == GFC_FCOARRAY_LIB)
 {
+  tree zero_size = build_zero_cst (size_type_node);
   tmp = build_call_expr_loc (input_location, gfor_fndecl_caf_unlock, 6,
- token, integer_zero_node, integer_one_node,
+ token, zero_size, integer_one_node,
  null_pointer_node, null_pointer_node,
- integer_zero_node);
+ zero_size);
   gfc_add_expr_to_block (&block, tmp);
 
   /* It guarantees memory consistency within the same segment */
@@ -6772,9 +6774,10 @@ gfc_trans_allocate (gfc_code * code)
   if (needs_caf_sync)
 {
   /* Add a sync all after the allocation has been executed.  */
+  tree zero_size = build_zero_cst (size_type_node);
   tmp = build_call_expr_loc (input_location, gfor_fndecl_caf_sync_all,
  3, null_pointer_node, null_pointer_node,
- integer_zero_node);
+ zero_size);
   gfc_add_expr_to_block (&post, tmp);
 }
 

Re: [patch] Fix Fortran size_t parameter passing

[Janne Blomqvist]

On Wed, May 22, 2019 at 3:20 PM Andrew Stubbs  wrote:
>
> On 22/05/2019 12:35, Janne Blomqvist wrote:
> > Thanks for the catch. Though for size_t you should use build_zero_cst
> > (size_type_node). size_zero_node is a zero constant of type sizetype,
> > which is not the same as size_type_node (size_t in C). Ok with that
> > change.
>
> So, integer_zero_node is compatible with integer_type_node, but
> size_zero_node is not (necessarily) compatible with size_type_node?
> Well, that's just asking for trouble. :-(

Indeed it is. IIRC the main difference is that while both are unsigned
types, sizetype has undefined behavior on overflow whereas
size_type_node wraps around. And sizetype is an internal
implementation detail, so should not be used in ABI-visible places.

> Just to confirm, is the attached what you mean?

Yes, looks good.

-- 
Janne Blomqvist

Re: [PATCH] A jump threading opportunity for condition branch

[Richard Biener]

On Tue, 21 May 2019, Jiufu Guo wrote:

> Hi,
> 
> This patch implements a new opportunity of jump threading for PR77820.
> In this optimization, conditional jumps are merged with unconditional jump.
> And then moving CMP result to GPR is eliminated.
> 
> It looks like below:
> 
>   
>   p0 = a CMP b
>   goto ;
> 
>   
>   p1 = c CMP d
>   goto ;
> 
>   
>   # phi = PHI 
>   if (phi != 0) goto ; else goto ;
> 
> Could be transformed to:
> 
>   
>   p0 = a CMP b
>   if (p0 != 0) goto ; else goto ;
> 
>   
>   p1 = c CMP d
>   if (p1 != 0) goto ; else goto ;
> 
> 
> This optimization eliminates:
> 1. saving CMP result: p0 = a CMP b.
> 2. additional CMP on branch: if (phi != 0).
> 3. converting CMP result if there is phi = (INT_CONV) p0 if there is.
> 
> Bootstrapped and tested on powerpc64le with no regressions(one case is 
> improved)
> and new testcases are added. Is this ok for trunk?
> 
> Thanks!
> Jiufu Guo
> 
> 
> [gcc]
> 2019-05-21  Jiufu Guo  
>   Lijia He  
> 
>   PR tree-optimization/77820
>   * tree-ssa-threadedge.c (cmp_from_unconditional_block): New function.
>   * tree-ssa-threadedge.c (is_trivial_join_block): New function.
>   * tree-ssa-threadedge.c (thread_across_edge): Call 
> is_trivial_join_block.
> 
> [gcc/testsuite]
> 2019-05-21  Jiufu Guo  
>   Lijia He  
> 
>   PR tree-optimization/77820
>   * gcc.dg/tree-ssa/phi_on_compare-1.c: New testcase.
>   * gcc.dg/tree-ssa/phi_on_compare-2.c: New testcase.
>   * gcc.dg/tree-ssa/phi_on_compare-3.c: New testcase.
>   * gcc.dg/tree-ssa/phi_on_compare-4.c: New testcase.
>   * gcc.dg/tree-ssa/split-path-6.c: Update testcase.
> 
> ---
>  gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-1.c | 32 +
>  gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-2.c | 27 +++
>  gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-3.c | 31 
>  gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-4.c | 40 +++
>  gcc/testsuite/gcc.dg/tree-ssa/split-path-6.c |  2 +-
>  gcc/tree-ssa-threadedge.c| 91 
> +++-
>  6 files changed, 219 insertions(+), 4 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-1.c
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-2.c
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-3.c
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-4.c
> 
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-1.c 
> b/gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-1.c
> new file mode 100644
> index 000..ad4890a
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-1.c
> @@ -0,0 +1,32 @@
> +/* { dg-do compile } */
> +/* { dg-options "-Ofast -fdump-tree-vrp1" } */
> +
> +void g (int);
> +void g1 (int);
> +
> +void
> +f (long a, long b, long c, long d, long x)
> +{
> +  _Bool t;
> +  if (x)
> +{
> +  g (a + 1);
> +  t = a < b;
> +  c = d + x;
> +}
> +  else
> +{
> +  g (b + 1);
> +  a = c + d;
> +  t = c > d;
> +}
> +
> +  if (t)
> +{
> +  g1 (c);
> +}
> +
> +  g (a);
> +}
> +
> +/* { dg-final { scan-tree-dump-times "Removing basic block" 1 "vrp1" } } */
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-2.c 
> b/gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-2.c
> new file mode 100644
> index 000..ca67d65
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-2.c
> @@ -0,0 +1,27 @@
> +/* { dg-do compile } */
> +/* { dg-options "-Ofast -fdump-tree-vrp1" } */
> +
> +void g (void);
> +void g1 (void);
> +
> +void
> +f (long a, long b, long c, long d, int x)
> +{
> +  _Bool t;
> +  if (x)
> +{
> +  t = c < d;
> +}
> +  else
> +{
> +  t = a < b;
> +}
> +
> +  if (t)
> +{
> +  g1 ();
> +  g ();
> +}
> +}
> +
> +/* { dg-final { scan-tree-dump-times "Removing basic block" 1 "vrp1" } } */
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-3.c 
> b/gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-3.c
> new file mode 100644
> index 000..a126e97
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-3.c
> @@ -0,0 +1,31 @@
> +/* { dg-do compile } */
> +/* { dg-options "-Ofast -fdump-tree-vrp1" } */
> +
> +void g (void);
> +void g1 (void);
> +
> +void
> +f (long a, long b, long c, long d, int x)
> +{
> +  int t;
> +  if (x)
> +{
> +  t = a < b;
> +}
> +  else if (d == x)
> +{
> +  t = c < b;
> +}
> +  else
> +{
> +  t = d > c;
> +}
> +
> +  if (t)
> +{
> +  g1 ();
> +  g ();
> +}
> +}
> +
> +/* { dg-final { scan-tree-dump-times "Removing basic block" 1 "vrp1" } } */
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-4.c 
> b/gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-4.c
> new file mode 100644
> index 000..5a50c2d
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-4.c
> @@ -0,0 +1,40 @@
> +/* { dg-do compile } */
> +/* { dg-options "-Ofast -fdump-tree-

Re: [PATCH][RFC] Fix PR90510, VEC_PERM -> BIT_INSERT folding

[Thomas Schwinge]

Hi!

On Tue, 21 May 2019 13:11:54 +0200 (CEST), Richard Biener  
wrote:
> On Mon, 20 May 2019, Richard Biener wrote:
> > On Sun, 19 May 2019, Richard Sandiford wrote:
> > > Richard Biener  writes:
> > > > This adds, incrementally ontop of moving VEC_PERM_EXPR folding
> > > > to match.pd (but not incremental patch - sorry...), folding
> > > > of single-element insert permutations to BIT_INSERT_EXPR.

> And the following is what I applied after fixing all sign-compare
> issues.
> 
> Bootstraped and tested on x86_64-unknown-linux-gnu.

I'm seeing one regression, in 'gcc/testsuite/brig/brig.sum':

@@ -126,7 +126,7 @@ PASS: packed.hsail.brig scan-tree-dump original "\\+ { 
15, 14, 13, 12, 11, 10, 9
PASS: packed.hsail.brig scan-tree-dump gimple "= { 15, 15, 15, 15, 15, 15, 
15, 15, 15, 15, 15, 15, 15, 15, 15, 15 };[\n ]+[a-z0-9_]+ = [a-z0-9_]+ \\+ 
[a-z0-9_]+;"
PASS: packed.hsail.brig scan-tree-dump gimple "VEC_PERM_EXPR <[a-z0-9_]+, 
[a-z0-9_]+, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }>;"
PASS: packed.hsail.brig scan-tree-dump gimple "_[0-9]+ = q2 \\+ q3;"
[-PASS:-]{+FAIL:+} packed.hsail.brig scan-tree-dump gimple "= VEC_PERM_EXPR 
<[a-z0-9_]+, new_output.[0-9]+_[0-9]+, { 16, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 
12, 13, 14, 15 }>;"
PASS: packed.hsail.brig scan-tree-dump gimple "q4 = 
(VIEW_CONVERT_EXPR\\()?s_output.[0-9]+(_[0-9]+)*\\)?;"
PASS: packed.hsail.brig scan-tree-dump-times gimple "= 
__builtin___hsail_sat_add_u8" 64
PASS: packed.hsail.brig scan-tree-dump gimple "= 
VIEW_CONVERT_EXPR\\((s_output.[0-9]+_[0-9]+|q8)\\);[\n ]+q9 = -_[0-9]+;[\n ]+"

The before vs. after tree dump changed as follows:

--- packed.hsail.brig.005t.gimple   2019-05-22 14:29:48.810860260 +0200
+++ packed.hsail.brig.005t.gimple   2019-05-22 14:31:32.936670016 +0200
@@ -112,7 +112,7 @@
   _26 = q2 + q3;
   new_output.11 = _26;
   new_output.21_27 = new_output.11;
-  _28 = VEC_PERM_EXPR ;
+  _28 = VEC_PERM_EXPR ;
   s_output.12 = _28;
   q4 = s_output.12;
   _29 = { 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0 };
@@ -369,7 +369,7 @@
   vec_out.22_273 = vec_out.16;
   new_output.17 = vec_out.22_273;
   new_output.23_274 = new_output.17;
-  _275 = VEC_PERM_EXPR ;
+  _275 = VEC_PERM_EXPR ;
   s_output.18 = _275;
   q8 = s_output.18;
   _276 = VIEW_CONVERT_EXPR(q8);

Will it be OK to just commit the obvious patch to adjust the tree dump
scanning, or is something actually wrong?  (As you can tell, so far I
didn't look up what that actually means -- hoping you can tell from the
little bit of context?)


Grüße
 Thomas


> 2019-05-21  Richard Biener  
> 
>   PR middle-end/90510
>   * fold-const.c (fold_read_from_vector): New function.
>   * fold-const.h (fold_read_from_vector): Declare.
>   * match.pd (VEC_PERM_EXPR): Build BIT_INSERT_EXPRs for
>   single-element insert permutations.  Canonicalize selector
>   further and fix issue with last commit.
> 
>   * gcc.target/i386/pr90510.c: New testcase.
> 
> Index: gcc/fold-const.c
> ===
> --- gcc/fold-const.c  (revision 271412)
> +++ gcc/fold-const.c  (working copy)
> @@ -13793,6 +13793,28 @@ fold_read_from_constant_string (tree exp
>return NULL;
>  }
>  
> +/* Folds a read from vector element at IDX of vector ARG.  */
> +
> +tree
> +fold_read_from_vector (tree arg, poly_uint64 idx)
> +{
> +  unsigned HOST_WIDE_INT i;
> +  if (known_lt (idx, TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg)))
> +  && known_ge (idx, 0u)
> +  && idx.is_constant (&i))
> +{
> +  if (TREE_CODE (arg) == VECTOR_CST)
> + return VECTOR_CST_ELT (arg, i);
> +  else if (TREE_CODE (arg) == CONSTRUCTOR)
> + {
> +   if (i >= CONSTRUCTOR_NELTS (arg))
> + return build_zero_cst (TREE_TYPE (TREE_TYPE (arg)));
> +   return CONSTRUCTOR_ELT (arg, i)->value;
> + }
> +}
> +  return NULL_TREE;
> +}
> +
>  /* Return the tree for neg (ARG0) when ARG0 is known to be either
> an integer constant, real, or fixed-point constant.
>  
> Index: gcc/fold-const.h
> ===
> --- gcc/fold-const.h  (revision 271412)
> +++ gcc/fold-const.h  (working copy)
> @@ -100,6 +100,7 @@ extern tree fold_bit_and_mask (tree, tre
>  tree, enum tree_code, tree, tree,
>  tree, enum tree_code, tree, tree, tree *);
>  extern tree fold_read_from_constant_string (tree);
> +extern tree fold_read_from_vector (tree, poly_uint64);
>  #if GCC_VEC_PERN_INDICES_H
>  extern tree fold_vec_perm (tree, tree, tree, const vec_perm_indices &);
>  #endif
> Index: gcc/match.pd
> ===
> --- gcc/match.pd  (revision 271412)
> +++ gcc/match.pd  (working copy)
> @@ -5406,6 +5406,11 @@ (define_operator_list COND_TERNARY
>  op0 = op

Re: [patch] Fix Fortran size_t parameter passing

[Andrew Stubbs]

On 22/05/2019 13:28, Janne Blomqvist wrote:

Just to confirm, is the attached what you mean?


Yes, looks good.


Thanks, now committed.

Andrew

Re: [patch] Fix coarray_lock_7.f90 test failure

[Andrew Stubbs]

On 22/05/2019 12:38, Janne Blomqvist wrote:

Ok.


Thanks, committed.

Andrew

Re: [PATCH, i386]: Introduce signbit2 expander

[Rainer Orth]

Hi Uros,

>> the new testcase FAILs on i386-pc-solaris2.11 (both with the default
>> -m32 and -m64), but also on i586-unknown-freebsd11.2, i686-pc-linux-gnu:
>>
>> +FAIL: gcc.target/i386/vect-signbitf.c scan-assembler-not -2147483648
>
> It works for me on x86_64-linux-gnu with -32, so I'm at loss on what
> might be wrong.

I just tried x86_64-pc-linux-gnu and i686-pc-linux-gnu bootstraps: no
failures (with or without -m32) in the former, fails for both -m32 and
-m64 in the latter, just as on i386-pc-solaris2.11.

Rainer

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

Re: [PATCH][RFC] Fix PR90510, VEC_PERM -> BIT_INSERT folding

[Richard Biener]

On Wed, 22 May 2019, Thomas Schwinge wrote:

> Hi!
> 
> On Tue, 21 May 2019 13:11:54 +0200 (CEST), Richard Biener  
> wrote:
> > On Mon, 20 May 2019, Richard Biener wrote:
> > > On Sun, 19 May 2019, Richard Sandiford wrote:
> > > > Richard Biener  writes:
> > > > > This adds, incrementally ontop of moving VEC_PERM_EXPR folding
> > > > > to match.pd (but not incremental patch - sorry...), folding
> > > > > of single-element insert permutations to BIT_INSERT_EXPR.
> 
> > And the following is what I applied after fixing all sign-compare
> > issues.
> > 
> > Bootstraped and tested on x86_64-unknown-linux-gnu.
> 
> I'm seeing one regression, in 'gcc/testsuite/brig/brig.sum':
> 
> @@ -126,7 +126,7 @@ PASS: packed.hsail.brig scan-tree-dump original "\\+ 
> { 15, 14, 13, 12, 11, 10, 9
> PASS: packed.hsail.brig scan-tree-dump gimple "= { 15, 15, 15, 15, 15, 
> 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15 };[\n ]+[a-z0-9_]+ = [a-z0-9_]+ 
> \\+ [a-z0-9_]+;"
> PASS: packed.hsail.brig scan-tree-dump gimple "VEC_PERM_EXPR <[a-z0-9_]+, 
> [a-z0-9_]+, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }>;"
> PASS: packed.hsail.brig scan-tree-dump gimple "_[0-9]+ = q2 \\+ q3;"
> [-PASS:-]{+FAIL:+} packed.hsail.brig scan-tree-dump gimple "= 
> VEC_PERM_EXPR <[a-z0-9_]+, new_output.[0-9]+_[0-9]+, { 16, 1, 2, 3, 4, 5, 6, 
> 7, 8, 9, 10, 11, 12, 13, 14, 15 }>;"
> PASS: packed.hsail.brig scan-tree-dump gimple "q4 = 
> (VIEW_CONVERT_EXPR\\()?s_output.[0-9]+(_[0-9]+)*\\)?;"
> PASS: packed.hsail.brig scan-tree-dump-times gimple "= 
> __builtin___hsail_sat_add_u8" 64
> PASS: packed.hsail.brig scan-tree-dump gimple "= 
> VIEW_CONVERT_EXPR short>\\((s_output.[0-9]+_[0-9]+|q8)\\);[\n ]+q9 = -_[0-9]+;[\n ]+"
> 
> The before vs. after tree dump changed as follows:
> 
> --- packed.hsail.brig.005t.gimple 2019-05-22 14:29:48.810860260 +0200
> +++ packed.hsail.brig.005t.gimple 2019-05-22 14:31:32.936670016 +0200
> @@ -112,7 +112,7 @@
>_26 = q2 + q3;
>new_output.11 = _26;
>new_output.21_27 = new_output.11;
> -  _28 = VEC_PERM_EXPR  8, 9, 10, 11, 12, 13, 14, 15 }>;
> +  _28 = VEC_PERM_EXPR  22, 23, 24, 25, 26, 27, 28, 29, 30, 31 }>;
>s_output.12 = _28;
>q4 = s_output.12;
>_29 = { 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0 };
> @@ -369,7 +369,7 @@
>vec_out.22_273 = vec_out.16;
>new_output.17 = vec_out.22_273;
>new_output.23_274 = new_output.17;
> -  _275 = VEC_PERM_EXPR  7, 8, 9, 10, 11, 12, 13, 14, 15 }>;
> +  _275 = VEC_PERM_EXPR  22, 23, 24, 25, 26, 27, 28, 29, 30, 31 }>;
>s_output.18 = _275;
>q8 = s_output.18;
>_276 = VIEW_CONVERT_EXPR(q8);
> 
> Will it be OK to just commit the obvious patch to adjust the tree dump
> scanning, or is something actually wrong?  (As you can tell, so far I
> didn't look up what that actually means -- hoping you can tell from the
> little bit of context?)

Yeah, this is because of a new canonicalization suggested by Richard
to have the first element in the permutation come from the first vector.

Richard.

> 
> Grüße
>  Thomas
> 
> 
> > 2019-05-21  Richard Biener  
> > 
> > PR middle-end/90510
> > * fold-const.c (fold_read_from_vector): New function.
> > * fold-const.h (fold_read_from_vector): Declare.
> > * match.pd (VEC_PERM_EXPR): Build BIT_INSERT_EXPRs for
> > single-element insert permutations.  Canonicalize selector
> > further and fix issue with last commit.
> > 
> > * gcc.target/i386/pr90510.c: New testcase.
> > 
> > Index: gcc/fold-const.c
> > ===
> > --- gcc/fold-const.c(revision 271412)
> > +++ gcc/fold-const.c(working copy)
> > @@ -13793,6 +13793,28 @@ fold_read_from_constant_string (tree exp
> >return NULL;
> >  }
> >  
> > +/* Folds a read from vector element at IDX of vector ARG.  */
> > +
> > +tree
> > +fold_read_from_vector (tree arg, poly_uint64 idx)
> > +{
> > +  unsigned HOST_WIDE_INT i;
> > +  if (known_lt (idx, TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg)))
> > +  && known_ge (idx, 0u)
> > +  && idx.is_constant (&i))
> > +{
> > +  if (TREE_CODE (arg) == VECTOR_CST)
> > +   return VECTOR_CST_ELT (arg, i);
> > +  else if (TREE_CODE (arg) == CONSTRUCTOR)
> > +   {
> > + if (i >= CONSTRUCTOR_NELTS (arg))
> > +   return build_zero_cst (TREE_TYPE (TREE_TYPE (arg)));
> > + return CONSTRUCTOR_ELT (arg, i)->value;
> > +   }
> > +}
> > +  return NULL_TREE;
> > +}
> > +
> >  /* Return the tree for neg (ARG0) when ARG0 is known to be either
> > an integer constant, real, or fixed-point constant.
> >  
> > Index: gcc/fold-const.h
> > ===
> > --- gcc/fold-const.h(revision 271412)
> > +++ gcc/fold-const.h(working copy)
> > @@ -100,6 +100,7 @@ extern tree fold_bit_and_mask (tree, tre
> >tree, e

Re: [PATCH] Remove empty loop with assumed finiteness (PR tree-optimization/89713)

[Michael Matz]

Hi,

On Tue, 21 May 2019, Richard Biener wrote:

> > Index: gcc/tree-ssa-dce.c
> > ===
> > --- gcc/tree-ssa-dce.c  (revision 271415)
> > +++ gcc/tree-ssa-dce.c  (working copy)
> > @@ -417,7 +417,7 @@ find_obviously_necessary_stmts (bool agg
> >   }
> >
> >FOR_EACH_LOOP (loop, 0)
> > -   if (!finite_loop_p (loop))
> > +   if (!loop_has_exit_edges (loop))
> >   {
> > if (dump_file)
> >   fprintf (dump_file, "cannot prove finiteness of loop
> > %i\n", loop->num);
> 
> Bootstrapped / tested on x86_64-unknown-linux-gnu.  Fallout:
> 
> FAIL: gcc.dg/loop-unswitch-1.c scan-tree-dump unswitch ";; Unswitching loop"
> FAIL: gcc.dg/predict-9.c scan-tree-dump-times profile_estimate "first
> match heuristics: 2.20%" 3
> FAIL: gcc.dg/predict-9.c scan-tree-dump-times profile_estimate "first
> match heuristics: 5.50%" 1

These contain infinite loops without other sideeffects.

> FAIL: gcc.dg/graphite/scop-19.c scan-tree-dump-times graphite "number
> of SCoPs: 0" 2

Loop without sideeffects.

> ...
> UNRESOLVED: gcc.dg/tree-ssa/20040211-1.c scan-tree-dump cddce2 "if "

why unresolved?  Anyway, conditionally infinite loop, but without side 
effects.

> FAIL: gcc.dg/tree-ssa/loop-10.c scan-tree-dump-times optimized "if " 3

Probably removes one more loop, which is conditionally infinite, but no 
side-effects.

> FAIL: gcc.dg/tree-ssa/pr84648.c scan-tree-dump-times cddce1 "Found
> loop 1 to be finite: upper bound found" 1

finite, no side-effect.

> FAIL: gcc.dg/tree-ssa/split-path-6.c scan-tree-dump-times split-paths
> "Duplicating join block" 3

AFAICS all loops therein contain side-effects, though the one in 
lookharder() only an invalid one, which might be optimized away, so that 
might be it.  But this would need to be looked at.

> FAIL: gcc.dg/tree-ssa/ssa-thread-12.c scan-tree-dump thread2 "FSM"
> FAIL: gcc.dg/tree-ssa/ssa-thread-12.c scan-tree-dump thread3 "FSM"

If everything is properly inlined, this contains two nested 
side-effect-free loops.

> FAIL: gcc.dg/uninit-28-gimple.c  (test for bogus messages, line 9)

But this one doesn't contain a loop at all!?

> I didn't look if the testcases are sensible for loop removal (or what
> actually happens).

IMHO most testcases above (perhaps except gcc.dg/uninit-28-gimple.c and 
tree-ssa/split-path-6.c) are sensible for loop removal if mere memory 
accesses and possible infiniteness don't count as side-effects.


Ciao,
Michael.

Re: [PATCH] Support again multiple --help options (PR other/90315).

[Hans-Peter Nilsson]

Ping, on behalf of Martin, CC:ing diagnostics maintainers.

On Fri, 3 May 2019, Martin Li?ka wrote:

> Hi.
>
> The patch prints all values requested in multiple --help options.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> 2019-05-03  Martin Liska  
>
>   PR other/90315
>   * opts-global.c (decode_options): Print help for all
>   help_option_arguments.
>   * opts.c (print_help): Add new argument.
>   (common_handle_option): Remember all values into
>   help_option_arguments.
>   * opts.h (print_help): Add new argument.
> ---
>  gcc/opts-global.c | 4 ++--
>  gcc/opts.c| 7 ---
>  gcc/opts.h| 5 +++--
>  3 files changed, 9 insertions(+), 7 deletions(-)
>
>
>

Re: [PATCH] tree-ssa-uninit: suppress more spurious warnings

[Vladislav Ivanishin]

Christophe, Rainer,

Rainer Orth  writes:

> Hi Christophe,
>
>> On Fri, 17 May 2019 at 10:12, Vladislav Ivanishin  wrote:
>>>
>> As you have probably noticed already, the new test uninit-28.c fails:
>> /gcc/testsuite/gcc.dg/uninit-28-gimple.c:9:16: warning: 'undef' may be
>> used uninitialized in this function [-Wmaybe-uninitialized]
>> FAIL: gcc.dg/uninit-28-gimple.c  (test for bogus messages, line 9)
>> at least on arm & aarch64

Thanks for spotting.  I managed to reproduce the failure on x86_64 (I
started from revision and configure options in one of H.J.'s test
results [1]) and it seems, another check-in is to blame.  The stage1
compiler is always fine w.r.t. the result on uninit-28-gimple.c.  The
stage2 compiler seems to be miscompiled.

r271460 is already bad, yes, but the problem starts earlier (better to
pick another test as an indicator, or bisect just the stage1 compiler,
compiling pseudo-stage2 with it from newer sources).

I'm going to bisect the regression and report to the appropriate thread
unless someone beats me to it.

[1]: https://gcc.gnu.org/ml/gcc-testresults/2019-05/msg02436.html

> I'm seeing it on sparc-sun-solaris2.11, and there are gcc-testresults
> reports for i?86, mips64el, powerpc*, s390x, and x86_64.
>
>   Rainer

-- 
Vlad

Re: [PATCH] x86: Don't allocate stack frame nor align stack if not needed

[H.J. Lu]

On Wed, May 22, 2019 at 12:31 AM Uros Bizjak  wrote:
>
> On Tue, May 21, 2019 at 5:01 PM H.J. Lu  wrote:
> >
> > get_frame_size () returns used stack slots during compilation, which
> > may be optimized out later.  This patch does the followings:
> >
> > 1. Add no_stack_frame to machine_function to indicate that the function
> > doesn't need a stack frame.
>
> Can you please add "stack_frame_required" to machine_function with
> inverted meaning instead? Every single usage of no_stack_frame is
> inverted, and it is hard to follow this negative logic through the
> code.

Fixed.

> > 2. Change ix86_find_max_used_stack_alignment to set no_stack_frame.
> > 3. Always call ix86_find_max_used_stack_alignment to check if stack
> > frame is needed.
> >
> > Tested on i686 and x86-64 with
> >
> > --with-arch=native --with-cpu=native
> >
> > Tested on AVX512 machine configured with
> >
> > --with-arch=native --with-cpu=native
> >
> > gcc/
> >
> > PR target/88483
> > * config/i386/i386.c (ix86_get_frame_size): New function.
> > (ix86_frame_pointer_required): Replace get_frame_size with
> > ix86_get_frame_size.
> > (ix86_compute_frame_layout): Likewise.
> > (ix86_find_max_used_stack_alignment): Changed to void.  Set
> > no_stack_frame.
> > (ix86_finalize_stack_frame_flags): Always call
> > ix86_find_max_used_stack_alignment.  Replace get_frame_size with
> > ix86_get_frame_size.
> > * config/i386/i386.h (machine_function): Add no_stack_frame.
> >
> > gcc/testsuite/
> >
> > PR target/88483
> > * gcc.target/i386/stackalign/pr88483-1.c: New test.
> > * gcc.target/i386/stackalign/pr88483-2.c: Likewise.
> > ---
> >  gcc/config/i386/i386.c| 53 ---
> >  gcc/config/i386/i386.h|  3 ++
> >  .../gcc.target/i386/stackalign/pr88483-1.c| 18 +++
> >  .../gcc.target/i386/stackalign/pr88483-2.c| 18 +++
> >  4 files changed, 74 insertions(+), 18 deletions(-)
> >  create mode 100644 gcc/testsuite/gcc.target/i386/stackalign/pr88483-1.c
> >  create mode 100644 gcc/testsuite/gcc.target/i386/stackalign/pr88483-2.c
> >
> > diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> > index 54607748b0b..d0b2a4f8b70 100644
> > --- a/gcc/config/i386/i386.c
> > +++ b/gcc/config/i386/i386.c
> > @@ -5012,6 +5012,19 @@ ix86_can_use_return_insn_p (void)
> >   && (frame.nregs + frame.nsseregs) == 0);
> >  }
> >
> > +/* Return stack frame size.  get_frame_size () returns used stack slots
> > +   during compilation, which may be optimized out later.  no_stack_frame
> > +   is set to true if stack frame isn't needed.  */
> > +
> > +static HOST_WIDE_INT
> > +ix86_get_frame_size (void)
> > +{
> > +  if (cfun->machine->no_stack_frame)
> > +return 0;
> > +  else
> > +return get_frame_size ();
> > +}
> > +
> >  /* Value should be nonzero if functions must have frame pointers.
> > Zero means the frame pointer need not be set up (and parms may
> > be accessed via the stack pointer) in functions that seem suitable.  */
> > @@ -5035,7 +5048,7 @@ ix86_frame_pointer_required (void)
> >
> >/* Win64 SEH, very large frames need a frame-pointer as maximum stack
> >   allocation is 4GB.  */
> > -  if (TARGET_64BIT_MS_ABI && get_frame_size () > SEH_MAX_FRAME_SIZE)
> > +  if (TARGET_64BIT_MS_ABI && ix86_get_frame_size () > SEH_MAX_FRAME_SIZE)
> >  return true;
> >
> >/* SSE saves require frame-pointer when stack is misaligned.  */
> > @@ -5842,7 +5855,7 @@ ix86_compute_frame_layout (void)
> >unsigned HOST_WIDE_INT stack_alignment_needed;
> >HOST_WIDE_INT offset;
> >unsigned HOST_WIDE_INT preferred_alignment;
> > -  HOST_WIDE_INT size = get_frame_size ();
> > +  HOST_WIDE_INT size = ix86_get_frame_size ();
> >HOST_WIDE_INT to_allocate;
> >
> >/* m->call_ms2sysv is initially enabled in ix86_expand_call for all 
> > 64-bit
> > @@ -7436,11 +7449,11 @@ output_probe_stack_range (rtx reg, rtx end)
> >return "";
> >  }
> >
> > -/* Return true if stack frame is required.  Update STACK_ALIGNMENT
> > -   to the largest alignment, in bits, of stack slot used if stack
> > -   frame is required and CHECK_STACK_SLOT is true.  */
> > +/* Set no_stack_frame to true if stack frame isn't required.  Update
> > +   STACK_ALIGNMENT to the largest alignment, in bits, of stack slot
> > +   used if stack frame is required and CHECK_STACK_SLOT is true.  */
>
> From the above comment, you can see the confusion caused by using
> negative logic for no_stack_frame.
>
> > -static bool
> > +static void
> >  ix86_find_max_used_stack_alignment (unsigned int &stack_alignment,
> > bool check_stack_slot)
> >  {
> > @@ -7489,7 +7502,7 @@ ix86_find_max_used_stack_alignment (unsigned int 
> > &stack_alignment,
> >   }
> >  }
> >
> > -  return require_stack_frame;
> > +  cfun->machine->no_stack_frame = !require_st

Re: [PATCH] tree-ssa-uninit: suppress more spurious warnings

[Jeff Law]

On 5/22/19 8:44 AM, Vladislav Ivanishin wrote:
> Christophe, Rainer,
> 
> Rainer Orth  writes:
> 
>> Hi Christophe,
>>
>>> On Fri, 17 May 2019 at 10:12, Vladislav Ivanishin  wrote:

>>> As you have probably noticed already, the new test uninit-28.c fails:
>>> /gcc/testsuite/gcc.dg/uninit-28-gimple.c:9:16: warning: 'undef' may be
>>> used uninitialized in this function [-Wmaybe-uninitialized]
>>> FAIL: gcc.dg/uninit-28-gimple.c  (test for bogus messages, line 9)
>>> at least on arm & aarch64
> 
> Thanks for spotting.  I managed to reproduce the failure on x86_64 (I
> started from revision and configure options in one of H.J.'s test
> results [1]) and it seems, another check-in is to blame.  The stage1
> compiler is always fine w.r.t. the result on uninit-28-gimple.c.  The
> stage2 compiler seems to be miscompiled.
> 
> r271460 is already bad, yes, but the problem starts earlier (better to
> pick another test as an indicator, or bisect just the stage1 compiler,
> compiling pseudo-stage2 with it from newer sources).
> 
> I'm going to bisect the regression and report to the appropriate thread
> unless someone beats me to it.
> 
> [1]: https://gcc.gnu.org/ml/gcc-testresults/2019-05/msg02436.html
> 
>> I'm seeing it on sparc-sun-solaris2.11, and there are gcc-testresults
>> reports for i?86, mips64el, powerpc*, s390x, and x86_64.
FWIW I'm also seeing uninit-18 failing on the ppc targets.

And I'll reiterate my concern that these are likely masking issues
earlier in the optimizer pipeline.  For example uninit-18 really should
be fixed by threading in either DOM or VRP.

Jeff

Re: [PATCH] tree-ssa-uninit: suppress more spurious warnings

[Iain Sandoe]

> On 22 May 2019, at 16:19, Jeff Law  wrote:
> 
> On 5/22/19 8:44 AM, Vladislav Ivanishin wrote:
>> Christophe, Rainer,
>> 
>> Rainer Orth  writes:
>> 
>>> Hi Christophe,
>>> 
 On Fri, 17 May 2019 at 10:12, Vladislav Ivanishin  wrote:
> 
 As you have probably noticed already, the new test uninit-28.c fails:
 /gcc/testsuite/gcc.dg/uninit-28-gimple.c:9:16: warning: 'undef' may be
 used uninitialized in this function [-Wmaybe-uninitialized]
 FAIL: gcc.dg/uninit-28-gimple.c  (test for bogus messages, line 9)
 at least on arm & aarch64
>> 
>> Thanks for spotting.  I managed to reproduce the failure on x86_64 (I
>> started from revision and configure options in one of H.J.'s test
>> results [1]) and it seems, another check-in is to blame.  The stage1
>> compiler is always fine w.r.t. the result on uninit-28-gimple.c.  The
>> stage2 compiler seems to be miscompiled.
>> 
>> r271460 is already bad, yes, but the problem starts earlier (better to
>> pick another test as an indicator, or bisect just the stage1 compiler,
>> compiling pseudo-stage2 with it from newer sources).
>> 
>> I'm going to bisect the regression and report to the appropriate thread
>> unless someone beats me to it.
>> 
>> [1]: https://gcc.gnu.org/ml/gcc-testresults/2019-05/msg02436.html
>> 
>>> I'm seeing it on sparc-sun-solaris2.11, and there are gcc-testresults
>>> reports for i?86, mips64el, powerpc*, s390x, and x86_64.
> FWIW I'm also seeing uninit-18 failing on the ppc targets.

uninit-18, 19 are failing on x86_64-darwin16 (m32 and m64) at least, too
(although uninit-28 is passing there).

Iain

> 
> And I'll reiterate my concern that these are likely masking issues
> earlier in the optimizer pipeline.  For example uninit-18 really should
> be fixed by threading in either DOM or VRP.
> 
> Jeff

Re: [PATCH, i386]: Introduce signbit2 expander

[H.J. Lu]

On Wed, May 22, 2019 at 6:36 AM Rainer Orth  
wrote:
>
> Hi Uros,
>
> >> the new testcase FAILs on i386-pc-solaris2.11 (both with the default
> >> -m32 and -m64), but also on i586-unknown-freebsd11.2, i686-pc-linux-gnu:
> >>
> >> +FAIL: gcc.target/i386/vect-signbitf.c scan-assembler-not -2147483648
> >
> > It works for me on x86_64-linux-gnu with -32, so I'm at loss on what
> > might be wrong.
>
> I just tried x86_64-pc-linux-gnu and i686-pc-linux-gnu bootstraps: no
> failures (with or without -m32) in the former, fails for both -m32 and
> -m64 in the latter, just as on i386-pc-solaris2.11.
>

i686 GCC generates slightly different assembly codes from x86-64 GCC
with -m32:


@@ -88,16 +88,16 @@ main.cold:
  .size a, 4096
 a:
  .long 0
- .long 2147483648
+ .long -2147483648   This matches /* { dg-final {
scan-assembler-not "-2147483648" } } */
  .long 1065353216
- .long 3212836864
- .long 3221225472
+ .long -1082130432
+ .long -1073741824
  .long 1077936128
- .long 3231711232
- .long 3238002688
+ .long -1063256064
+ .long -1056964608
  .long 1095761920
  .long 1101529088
- .long 3251109888
+ .long -1043857408
  .long 1107558400
  .zero 4048

These numbers are equivalent.  Should we check

andl $-2147483648, %edx

instead?

BTW, we also need -mfpmath=sse since it may not be the default for -m32.

-- 
H.J.

[PATCH] fix more -Wformat-diag issues

[Martin Sebor]

Incorporating the feedback I got on the -Wformat-diag checker
provided an opportunity to tighten up existing and implement
a small number of few additional rules based on GCC Coding
Conventions (https://gcc.gnu.org/codingconventions.html).
The checker now also warns for incorrect uses of the following:

 *  bitfield (rather than bit-field)
 *  builtin (rather than built-in)
 *  command line (rather than command-line)
 *  enumeral (rather than enumerated)
 *  floating point (rather than floating-point)
 *  non-zero (rather than nonzero)

In addition, it has become better at finding unquoted qualifiers
(like const in const-qualified or "const %qT" rather than %"), and detects some additional abbreviations (e.g., "stmt"
instead of "statement").

These improvements exposed a number of additional issues in our
sources that the attached patch corrects.

As before, I have tested the patch on x86_64-linux and adjusted
the fallout in the test suite.  More cleanup will likely be needed
on other targets but based on the prior changes I don't expect it
to be extensive.

I will post the patch with the checker implementation separately.

Martin

PS As discussed in the thread below, some of the instances of
added hyphenation in "floating-point" aren't strictly necessary
and the  wording might need to be tweaked a bit to make it so:
  https://gcc.gnu.org/ml/gcc/2019-05/msg00168.html
I'll handle it in a subsequent commit if it's viewed important.
gcc/c/ChangeLog:

	* c-decl.c (start_decl): Adjust quoting and hyphenation
	in diagnostics.
	(finish_decl): Same.
	(finish_enum): Same.
	(start_function): Same.
	(declspecs_add_type): Same.
	* c-parser.c (warn_for_abs): Same.
	* c-typeck.c (build_binary_op): Same.

gcc/c-family/ChangeLog:

	* c-attribs.c (handle_mode_attribute): Adjust quoting and hyphenation.
	(handle_alias_ifunc_attribute): Same.
	(handle_copy_attribute): Same.
	(handle_weakref_attribute): Same.
	(handle_nonnull_attribute): Same.
	* c-warn.c (warn_for_sign_compare): Same.
	(warn_for_restrict): Same.
	* c.opt: Same.

	* c-common.h (GCC_DIAG_STYLE): Adjust.
	 (GCC_DIAG_RAW_STYLE): New macro.

gcc/cp/ChangeLog:

	* call.c (build_conditional_expr_1): Adjust quoting and hyphenation.
	(convert_like_real): Same.
	(convert_arg_to_ellipsis): Same.
	* constexpr.c (diag_array_subscript): Same.
	* constraint.cc (diagnose_trait_expression): Same.
	* cvt.c (ocp_convert): Same.
	* decl.c (start_decl): Same.
	(check_for_uninitialized_const_var): Same.
	(grokfndecl): Same.
	(check_special_function_return_type): Same.
	(finish_enum_value_list): Same.
	(start_preparsed_function): Same.
	* parser.c (cp_parser_decl_specifier_seq): Same.
	* typeck.c (cp_build_binary_op): Same.
	(build_static_cast_1): Same.

	* cp-tree.h (GCC_DIAG_STYLE): Adjust.
	 (GCC_DIAG_RAW_STYLE): New macro.

gcc/lto/ChangeLog:

	* lto-common.c (lto_file_finalize): Adjust quoting and hyphenation.

gcc/objc/ChangeLog:

	* objc-act.c (objc_build_setter_call): Adjust quoting and hyphenation.
	* objc-encoding.c (encode_gnu_bitfield): Same.

gcc/ChangeLog:

	* config/i386/i386-features.c (ix86_get_function_versions_dispatcher):
	Adjust quoting and hyphenation.
	* convert.c (convert_to_real_1): Same.
	* gcc.c (driver_wrong_lang_callback): Same.
	(driver::handle_unrecognized_options): Same.
	* gimple-ssa-nonnull-compare.c (do_warn_nonnull_compare): Same.
	* opts-common.c (cmdline_handle_error): Same.
	(read_cmdline_option): Same.
	* opts-global.c (complain_wrong_lang): Same.
	(print_ignored_options): Same.
	(handle_common_deferred_options): Same.
	* pretty-print.h: Same.
	* print-rtl.c (debug_bb_n_slim): Same.
	* sched-rgn.c (make_pass_sched_fusion): Same.
	* tree-cfg.c (verify_gimple_assign_unary): Same.
	(verify_gimple_label): Same.
	* tree-ssa-operands.c (verify_ssa_operands): Same.
	* varasm.c (do_assemble_alias): Same.
	(assemble_alias): Same.

	* diagnostic-core.h (GCC_DIAG_STYLE): Adjust.
	 (GCC_DIAG_RAW_STYLE): New macro.

	* cfghooks.c: Disable -Wformat-diags.
	* cfgloop.c: Same.
	* cfgrtl.c: Same.
	* cgraph.c: Same.
	* diagnostic-show-locus.c: Same.
	* diagnostic.c: Same.
	* gimple-pretty-print.c: Same.
	* graph.c: Same.
	* symtab.c: Same.
	* tree-eh.c Same.
	* tree-pretty-print.c: Same.
	* tree-ssa.c: Same.

	* configure: Regenerate.
	* configure.ac (ACX_PROG_CXX_WARNING_OPTS): Add -Wno-error=format-diag.
	 (ACX_PROG_CC_WARNING_OPTS): Same.

diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
index 03203470955..748653fd7f5 100644
--- a/gcc/c-family/c-attribs.c
+++ b/gcc/c-family/c-attribs.c
@@ -1821,7 +1821,7 @@ handle_mode_attribute (tree *node, tree name, tree args,
 	 this mode for this type.  */
 	  if (TREE_CODE (typefm) != INTEGER_TYPE)
 	{
-	  error ("cannot use mode %qs for enumeral types", p);
+	  error ("cannot use mode %qs for enumerated types", p);
 	  return NULL_TREE;
 	}
 
@@ -2326,12 +2326,8 @@ handle_alias_ifunc_attribute (bool is_alias, tree *node, tree name, tree args,
 {
   struct symtab_node 

[PATCH] implement -Wformat-diag, v2

[Martin Sebor]

Attached is a revised implementation of the -Wformat-diag checker
incorporating the feedback I got on the first revision.

Martin
gcc/c-family/ChangeLog:

	* c-format.c (function_format_info::format_type): Adjust type.
	(function_format_info::is_raw): New member.
	(decode_format_type): Adjust signature.  Handle "raw" diag attributes.
	(decode_format_attr): Adjust call to decode_format_type.
	Avoid a redundant call to convert_format_name_to_system_name.
	Avoid abbreviating the word "arguments" in a diagnostic.
	(format_warning_substr): New function.
	(avoid_dollar_number): Quote dollar sign in a diagnostic.
	(finish_dollar_format_checking): Same.
	(check_format_info): Same.
	(struct baltoks_t): New.
	(c_opers, c_keywords, cxx_keywords, badwords, contrs): New arrays.
	(maybe_diag_unbalanced_tokens, check_tokens, check_plain): New
	functions.
	(check_format_info_main): Call check_plain.  Use baltoks_t.  Call
	maybe_diag_unbalanced_tokens.
	(handle_format_attribute): Spell out the word "arguments" in
	a diagnostic.

gcc/testsuite/ChangeLog:
	* gcc.dg/format/gcc_diag-11.c: New test.

diff --git a/gcc/c-family/c-format.c b/gcc/c-family/c-format.c
index a7f76c1c01d..713fce442c9 100644
--- a/gcc/c-family/c-format.c
+++ b/gcc/c-family/c-format.c
@@ -52,7 +52,13 @@ enum format_type { printf_format_type, asm_fprintf_format_type,
 
 struct function_format_info
 {
-  int format_type;			/* type of format (printf, scanf, etc.) */
+  enum format_type format_type;		/* type of format (printf, scanf, etc.) */
+  /* IS_RAW is relevant only for GCC diagnostic format functions.
+ It is set for "raw" formatting functions like pp_printf that
+ are not intended to produce complete diagnostics according to
+ GCC guidelines, and clear for others like error and warning
+ whose format string is checked for proper quoting and spelling.  */
+  bool is_raw;
   unsigned HOST_WIDE_INT format_num;	/* number of format argument */
   unsigned HOST_WIDE_INT first_arg_num;	/* number of first arg (zero for varargs) */
 };
@@ -65,7 +71,7 @@ static GTY(()) tree locus;
 
 static bool decode_format_attr (const_tree, tree, tree, function_format_info *,
 bool);
-static int decode_format_type (const char *);
+static format_type decode_format_type (const char *, bool * = NULL);
 
 static bool check_format_string (const_tree argument,
  unsigned HOST_WIDE_INT format_num,
@@ -111,6 +117,32 @@ format_warning_at_char (location_t fmt_string_loc, tree format_string_cst,
   return warned;
 }
 
+
+/* Emit a warning as per format_warning_va, but construct the substring_loc
+   for the substring at offset (POS1, POS2 - 1) within a string constant
+   FORMAT_STRING_CST at FMT_STRING_LOC.  */
+
+ATTRIBUTE_GCC_DIAG (6,7)
+static bool
+format_warning_substr (location_t fmt_string_loc, tree format_string_cst,
+		   int pos1, int pos2, int opt, const char *gmsgid, ...)
+{
+  va_list ap;
+  va_start (ap, gmsgid);
+  tree string_type = TREE_TYPE (format_string_cst);
+
+  pos2 -= 1;
+
+  substring_loc fmt_loc (fmt_string_loc, string_type, pos1, pos1, pos2);
+  format_string_diagnostic_t diag (fmt_loc, NULL, UNKNOWN_LOCATION, NULL,
+   NULL);
+  bool warned = diag.emit_warning_va (opt, gmsgid, &ap);
+  va_end (ap);
+
+  return warned;
+}
+
+
 /* Check that we have a pointer to a string suitable for use as a format.
The default is to check for a char type.
For objective-c dialects, this is extended to include references to string
@@ -320,10 +352,8 @@ decode_format_attr (const_tree fntype, tree atname, tree args,
 {
   const char *p = IDENTIFIER_POINTER (format_type_id);
 
-  p = convert_format_name_to_system_name (p);
+  info->format_type = decode_format_type (p, &info->is_raw);
 
-  info->format_type = decode_format_type (p);
-  
   if (!c_dialect_objc ()
 	   && info->format_type == gcc_objc_string_format_type)
 	{
@@ -359,7 +389,7 @@ decode_format_attr (const_tree fntype, tree atname, tree args,
   if (info->first_arg_num != 0 && info->first_arg_num <= info->format_num)
 {
   gcc_assert (!validated_p);
-  error ("format string argument follows the args to be formatted");
+  error ("format string argument follows the arguments to be formatted");
   return false;
 }
 
@@ -1067,27 +1097,55 @@ static void format_type_warning (const substring_loc &fmt_loc,
  char conversion_char);
 
 /* Decode a format type from a string, returning the type, or
-   format_type_error if not valid, in which case the caller should print an
-   error message.  */
-static int
-decode_format_type (const char *s)
+   format_type_error if not valid, in which case the caller should
+   print an error message.  On success, when IS_RAW is non-null, set
+   *IS_RAW when the format type corresponds to a GCC "raw" diagnostic
+   formatting function and clear it otherwise.  */
+static format_type
+decode_format_type (const char *s, bool *is_raw /* = NULL */)
 {
-  int i;
-  int slen;
+  bool is_raw_buf;
+
+  if 

[PATCH] rs6000: Infrastructure for future arch

[Bill Schmidt]

Hi,

This patch introduces the infrastructure to support -mcpu=future, used for 
features
in a future architecture, as yet unnamed.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no regressions.  
Is
this okay for trunk?

Thanks,
Bill


Add infrastructure to support -mcpu=future to represent a future
architecture level, as yet unnamed.

[gcc]

2019-05-22  Bill Schmidt  
Michael Meissner  
Segher Boessenkool  

* config.gcc: Add future cpu.
* config.in (HAVE_AS_FUTURE): New #define.
* config/rs6000/driver-rs6000.c (asm_names): Add future cpu.
* config/rs6000/rs6000-cpus.def (ISA_FUTURE_MASKS_SERVER): New
#define.
(OTHER_P9_VECTOR_MASKS): Add OPTION_MASK_FUTURE.
(POWERPC_MASKS): Add OPTION_MASK_FUTURE.
(RS6000_CPU): New instantiation for future cpu.
* config/rs6000/rs6000-opts.h (enum processor_type): Add
PROCESSOR_FUTURE.
* config/rs6000/rs6000-string.c (expand_compare_loop): Treat
PROCESSOR_FUTURE like PROCESSOR_POWER9 for now.
* config/rs6000/rs6000-tables.opt: Regenerate.
* config/rs6000/rs6000.c (rs6000_option_override_internal): Treat
PROCESSOR_FUTURE similarly to PROCESSOR_POWER9 for now.
(rs6000_machine_from_flags): Handle future cpu.
(rs6000_reassociation_width): Treat PROCESSOR_FUTURE like
PROCESSOR_POWER9 for now.
(rs6000_adjust_cost): Likewise.
(rs6000_issue_rate): Likewise.
(rs6000_opt_mask): Add entry for future.
* config/rs6000/rs6000.h (ASM_CPU_SPEC): Add future cpu.
(MASK_FUTURE): New #define.
* config/rs6000/rs6000.md (define_attr "cpu"): Add future cpu.
* config/rs6000/rs6000.opt (mfuture): New target option.
* doc/invoke.texi (mcpu): Add future cpu.

[gcc/testsuite]

2019-05-22  Bill Schmidt  

* gcc.target/powerpc/cpu-future.c: New test.


diff --git a/gcc/config.gcc b/gcc/config.gcc
index 76bb316942d..af5cd77f84c 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -506,7 +506,7 @@ powerpc*-*-*)
extra_headers="${extra_headers} ppu_intrinsics.h spu2vmx.h vec_types.h 
si2vmx.h"
extra_headers="${extra_headers} amo.h"
case x$with_cpu in
-   
xpowerpc64|xdefault64|x6[23]0|x970|xG5|xpower[3456789]|xpower6x|xrs64a|xcell|xa2|xe500mc64|xe5500|xe6500)
+   
xpowerpc64|xdefault64|x6[23]0|x970|xG5|xpower[3456789]|xpower6x|xrs64a|xcell|xa2|xe500mc64|xe5500|xe6500|xfuture)
cpu_is_64bit=yes
;;
esac
diff --git a/gcc/config.in b/gcc/config.in
index a718ceaf3da..c2f056710ba 100644
--- a/gcc/config.in
+++ b/gcc/config.in
@@ -358,6 +358,12 @@
 #endif
 
 
+/* Define if your assembler supports FUTURE instructions.  */
+#ifndef USED_FOR_TARGET
+#undef HAVE_AS_FUTURE
+#endif
+
+
 /* Define if your assembler supports explicit relocations. */
 #ifndef USED_FOR_TARGET
 #undef HAVE_AS_EXPLICIT_RELOCS
diff --git a/gcc/config/rs6000/driver-rs6000.c 
b/gcc/config/rs6000/driver-rs6000.c
index fde2a127ef1..cd6c889e368 100644
--- a/gcc/config/rs6000/driver-rs6000.c
+++ b/gcc/config/rs6000/driver-rs6000.c
@@ -457,6 +457,7 @@ static const struct asm_name asm_names[] = {
   { "630", "-m620" },
   { "970", "-m970" },
   { "G5",  "-m970" },
+  { "future",  "-mfuture" },
   { NULL,  "\
   %{mvsx: -mpwr6; \
 maltivec: -m970; \
@@ -520,6 +521,7 @@ static const struct asm_name asm_names[] = {
   { "e5500",   "-me5500" },
   { "e6500",   "-me6500" },
   { "titan",   "-mtitan" },
+  { "future",  "-mfuture" },
   { NULL,  "\
 %{mpower9-vector: -mpower9; \
   mpower8-vector|mcrypto|mdirect-move|mhtm: -mpower8; \
diff --git a/gcc/config/rs6000/rs6000-cpus.def 
b/gcc/config/rs6000/rs6000-cpus.def
index d0d69beafd4..f32da25930d 100644
--- a/gcc/config/rs6000/rs6000-cpus.def
+++ b/gcc/config/rs6000/rs6000-cpus.def
@@ -72,8 +72,13 @@
 | OPTION_MASK_P9_VECTOR\
 | OPTION_MASK_DIRECT_MOVE)
 
+/* Support for a future processor's features.  */
+#define ISA_FUTURE_MASKS_SERVER(ISA_3_0_MASKS_SERVER   
\
+| OPTION_MASK_FUTURE)
+
 /* Flags that need to be turned off if -mno-power9-vector.  */
 #define OTHER_P9_VECTOR_MASKS  (OPTION_MASK_FLOAT128_HW\
+| OPTION_MASK_FUTURE   \
 | OPTION_MASK_P9_MINMAX)
 
 /* Flags that need to be turned off if -mno-power8-vector.  */
@@ -134,7 +139,8 @@
 | OPTION_MASK_RECIP_PRECISION  \
 | OPTION_MASK_SOFT_FLOAT   \
 | OPTION_MASK_STRICT_ALIGN_OPTIONAL\
-| OPTION_MASK_VSX)
+| OPTION_MASK_VSX  \
+| OPTION_

Re: [PATCH] x86: Don't allocate stack frame nor align stack if not needed

[Uros Bizjak]

On Wed, May 22, 2019 at 5:10 PM H.J. Lu  wrote:
>
> On Wed, May 22, 2019 at 12:31 AM Uros Bizjak  wrote:
> >
> > On Tue, May 21, 2019 at 5:01 PM H.J. Lu  wrote:
> > >
> > > get_frame_size () returns used stack slots during compilation, which
> > > may be optimized out later.  This patch does the followings:
> > >
> > > 1. Add no_stack_frame to machine_function to indicate that the function
> > > doesn't need a stack frame.
> >
> > Can you please add "stack_frame_required" to machine_function with
> > inverted meaning instead? Every single usage of no_stack_frame is
> > inverted, and it is hard to follow this negative logic through the
> > code.
>
> Fixed.
>
> > > 2. Change ix86_find_max_used_stack_alignment to set no_stack_frame.
> > > 3. Always call ix86_find_max_used_stack_alignment to check if stack
> > > frame is needed.
> > >
> > > Tested on i686 and x86-64 with
> > >
> > > --with-arch=native --with-cpu=native
> > >
> > > Tested on AVX512 machine configured with
> > >
> > > --with-arch=native --with-cpu=native
> > >
> > > gcc/
> > >
> > > PR target/88483
> > > * config/i386/i386.c (ix86_get_frame_size): New function.
> > > (ix86_frame_pointer_required): Replace get_frame_size with
> > > ix86_get_frame_size.
> > > (ix86_compute_frame_layout): Likewise.
> > > (ix86_find_max_used_stack_alignment): Changed to void.  Set
> > > no_stack_frame.
> > > (ix86_finalize_stack_frame_flags): Always call
> > > ix86_find_max_used_stack_alignment.  Replace get_frame_size with
> > > ix86_get_frame_size.
> > > * config/i386/i386.h (machine_function): Add no_stack_frame.
> > >
> > > gcc/testsuite/
> > >
> > > PR target/88483
> > > * gcc.target/i386/stackalign/pr88483-1.c: New test.
> > > * gcc.target/i386/stackalign/pr88483-2.c: Likewise.
> > > ---
> > >  gcc/config/i386/i386.c| 53 ---
> > >  gcc/config/i386/i386.h|  3 ++
> > >  .../gcc.target/i386/stackalign/pr88483-1.c| 18 +++
> > >  .../gcc.target/i386/stackalign/pr88483-2.c| 18 +++
> > >  4 files changed, 74 insertions(+), 18 deletions(-)
> > >  create mode 100644 gcc/testsuite/gcc.target/i386/stackalign/pr88483-1.c
> > >  create mode 100644 gcc/testsuite/gcc.target/i386/stackalign/pr88483-2.c
> > >
> > > diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> > > index 54607748b0b..d0b2a4f8b70 100644
> > > --- a/gcc/config/i386/i386.c
> > > +++ b/gcc/config/i386/i386.c
> > > @@ -5012,6 +5012,19 @@ ix86_can_use_return_insn_p (void)
> > >   && (frame.nregs + frame.nsseregs) == 0);
> > >  }
> > >
> > > +/* Return stack frame size.  get_frame_size () returns used stack slots
> > > +   during compilation, which may be optimized out later.  no_stack_frame
> > > +   is set to true if stack frame isn't needed.  */
> > > +
> > > +static HOST_WIDE_INT
> > > +ix86_get_frame_size (void)
> > > +{
> > > +  if (cfun->machine->no_stack_frame)
> > > +return 0;
> > > +  else
> > > +return get_frame_size ();
> > > +}
> > > +
> > >  /* Value should be nonzero if functions must have frame pointers.
> > > Zero means the frame pointer need not be set up (and parms may
> > > be accessed via the stack pointer) in functions that seem suitable.  
> > > */
> > > @@ -5035,7 +5048,7 @@ ix86_frame_pointer_required (void)
> > >
> > >/* Win64 SEH, very large frames need a frame-pointer as maximum stack
> > >   allocation is 4GB.  */
> > > -  if (TARGET_64BIT_MS_ABI && get_frame_size () > SEH_MAX_FRAME_SIZE)
> > > +  if (TARGET_64BIT_MS_ABI && ix86_get_frame_size () > SEH_MAX_FRAME_SIZE)
> > >  return true;
> > >
> > >/* SSE saves require frame-pointer when stack is misaligned.  */
> > > @@ -5842,7 +5855,7 @@ ix86_compute_frame_layout (void)
> > >unsigned HOST_WIDE_INT stack_alignment_needed;
> > >HOST_WIDE_INT offset;
> > >unsigned HOST_WIDE_INT preferred_alignment;
> > > -  HOST_WIDE_INT size = get_frame_size ();
> > > +  HOST_WIDE_INT size = ix86_get_frame_size ();
> > >HOST_WIDE_INT to_allocate;
> > >
> > >/* m->call_ms2sysv is initially enabled in ix86_expand_call for all 
> > > 64-bit
> > > @@ -7436,11 +7449,11 @@ output_probe_stack_range (rtx reg, rtx end)
> > >return "";
> > >  }
> > >
> > > -/* Return true if stack frame is required.  Update STACK_ALIGNMENT
> > > -   to the largest alignment, in bits, of stack slot used if stack
> > > -   frame is required and CHECK_STACK_SLOT is true.  */
> > > +/* Set no_stack_frame to true if stack frame isn't required.  Update
> > > +   STACK_ALIGNMENT to the largest alignment, in bits, of stack slot
> > > +   used if stack frame is required and CHECK_STACK_SLOT is true.  */
> >
> > From the above comment, you can see the confusion caused by using
> > negative logic for no_stack_frame.
> >
> > > -static bool
> > > +static void
> > >  ix86_find_max_used_stack_alignment (unsigned int &stack_alignm

[PATCH, X86] Revise fuse-caller-save-* to avoid XPASSes on PIC targets.

[Iain Sandoe]

As Dominque noted in PR 64895, somewhere between revisions
 r244915 and r244957 we see the fuse-caller-save* tests started to
XPASS on Darwin, which is a PIC target by default.

The XFAILed parts of the tests never seem to be exercised on 
Linux, and therefore the change would be unnoticed there.

I have attached an analysis to the PR of the latest codegen from Linux
(which is identical to Darwin modulo the syntactic differences of PIC
accesses on the m32 platforms).

AFAICT, from the thread in the PR, codegen now seems to be correct.
Even if the codegen is still not right, the test conditions need amendment
to reflect the current status quo (and the XFAILs are no longers needed).

One test requires amendment for the PIC case on Linux, the remainer
of the changes are removals of the XFAILs.

With the attached patch both Linux and Darwin show 17 / 18 passes m32 / m64.

OK for trunk?
Relevant branch(es)?

Iain

gcc/testsuite/

PR rtl-optimisation/64895
* gcc.target/i386/fuse-caller-save-rec.c: Remove XFAILs.
* gcc.target/i386/fuse-caller-save.c: Likewise.
* gcc.target/i386/fuse-caller-save-xmm.c: Adjust tests for
PIC cases, remove XFAILs.

diff --git a/gcc/testsuite/gcc.target/i386/fuse-caller-save-rec.c 
b/gcc/testsuite/gcc.target/i386/fuse-caller-save-rec.c
index 7abcf91..e8d4efb 100644
--- a/gcc/testsuite/gcc.target/i386/fuse-caller-save-rec.c
+++ b/gcc/testsuite/gcc.target/i386/fuse-caller-save-rec.c
@@ -18,14 +18,12 @@ foo (int y)
   return y + bar (y);
 }
 
-/* For !nonpic && ia32 xfails, see PR64895.  */
-
 /* Check that no registers are saved/restored. */
-/* { dg-final { scan-assembler-not "push" { xfail { { ! nonpic } && ia32 } } } 
} */
-/* { dg-final { scan-assembler-not "pop" { xfail { { ! nonpic } && ia32 } } } 
} */
+/* { dg-final { scan-assembler-not "push" } } */
+/* { dg-final { scan-assembler-not "pop" } } */
 
 /* Check that addition uses dx. */
-/* { dg-final { scan-assembler-times "addl\t%\[re\]?dx, %\[re\]?ax" 1 { xfail 
{ { ! nonpic } && ia32 } } } } */
+/* { dg-final { scan-assembler-times "addl\t%\[re\]?dx, %\[re\]?ax" 1 } } */
 
 /* Verify that bar is self-recursive.  */
 /* { dg-final { scan-assembler-times "call\t_?bar" 2 } } */
diff --git a/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c 
b/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c
index c2d0544..02a5f5b 100644
--- a/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c
+++ b/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c
@@ -15,13 +15,18 @@ foo (v2df y)
   return y + bar (y);
 }
 
-/* For !nonpic && ia32 xfails, see PR64895.  */
-
 /* Check presence of all insns on xmm registers.  These checks are expected to
pass with both -fipa-ra and -fno-ipa-ra.  */
-/* { dg-final { scan-assembler-times "addpd\t\\.?LC0.*, %xmm0" 1 } } */
-/* { dg-final { scan-assembler-times "addpd\t%xmm1, %xmm0" 1 { xfail { { ! 
nonpic } && ia32 } } } } */
-/* { dg-final { scan-assembler-times "movapd\t%xmm0, %xmm1" 1 { xfail { { ! 
nonpic } && ia32 } } } } */
+
+/* { dg-final { scan-assembler-times {addpd\t\.?[Ll]C0.*, %xmm0} 1 { target { 
{ ! ia32 } || nonpic } } } } */
+/* { dg-final { scan-assembler-times {movapd\t\.?[Ll]C0.*, %xmm1} 1 { target { 
ia32 && { ! nonpic } } } } } */
+
+/* We happen to get this for both cases, but in different positions.  */
+/* { dg-final { scan-assembler-times "addpd\t%xmm1, %xmm0" 1 } } */
+
+/* { dg-final { scan-assembler-times "movapd\t%xmm0, %xmm1" 1 { target { { ! 
ia32 } || nonpic } } } } */
+/* { dg-final { scan-assembler-times "movapd\t%xmm0, %xmm2" 1 { target { ia32 
&& { ! nonpic } } } } } */
+/* { dg-final { scan-assembler-times "addpd\t%xmm2, %xmm0" 1 { target { ia32 
&& { ! nonpic } } } } } */
 
 /* Check absence of save/restore of xmm1 register.  */
 /* { dg-final { scan-assembler-not "movaps\t%xmm1, \\(%\[re\]?sp\\)" } } */
diff --git a/gcc/testsuite/gcc.target/i386/fuse-caller-save.c 
b/gcc/testsuite/gcc.target/i386/fuse-caller-save.c
index 4b8e68d..c0e8bf4 100644
--- a/gcc/testsuite/gcc.target/i386/fuse-caller-save.c
+++ b/gcc/testsuite/gcc.target/i386/fuse-caller-save.c
@@ -16,11 +16,9 @@ foo (int y)
   return y + bar (y);
 }
 
-/* For !nonpic && ia32 xfails, see PR64895.  */
-
 /* Check that no registers are saved/restored. */
-/* { dg-final { scan-assembler-not "push" { xfail { { ! nonpic } && ia32 } } } 
} */
-/* { dg-final { scan-assembler-not "pop" { xfail { { ! nonpic } && ia32 } } } 
} */
+/* { dg-final { scan-assembler-not "push" } } */
+/* { dg-final { scan-assembler-not "pop" } } */
 
 /* PR61605.  If the first argument register and the return register differ, 
then
bar leaves the first argument register intact.  That means in foo that the
@@ -31,4 +29,4 @@ foo (int y)
 /* { dg-final { scan-assembler-not "movl" { target { ! ia32 } } } } */
 
 /* Check that addition uses di (in case of no copy) or dx (in case of copy). */
-/* { dg-final { scan-assembler-times "addl\t%\[re\]?d\[ix\], %\[re\]?ax" 1 { 
xfail { { ! nonpic } && ia32

[PATCH, i386]: Fix up sse_cvtpi2ps insn condition

[Uros Bizjak]

This pattern needs TARGET_MMX as it uses mmx registers.

2019-05-22  Uroš Bizjak  

* config/i386/sse.md (sse_cvtpi2ps): Use TARGET_MMX in insn condition.

(+ some trivial code reorg parts).

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Committed to mainline SVN.

Uros.
diff --git a/gcc/config/i386/mmx.md b/gcc/config/i386/mmx.md
index adad950fa04d..dc8dabfafc85 100644
--- a/gcc/config/i386/mmx.md
+++ b/gcc/config/i386/mmx.md
@@ -1521,8 +1521,7 @@
 
   op = gen_rtx_VEC_SELECT (V8HImode, operands[1], mask);
 }
-  rtx insn = gen_rtx_SET (operands[0], op);
-  emit_insn (insn);
+  emit_insn (gen_rtx_SET (operands[0], op));
   DONE;
 }
   [(set_attr "mmx_isa" "native,x64,x64_avx")
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 7e7b3417cfc8..7d48402ee9d9 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -5012,7 +5012,7 @@
  (match_operand:V4SF 1 "register_operand" "0,0,Yv")
  (const_int 3)))
(clobber (match_scratch:V4SF 3 "=X,x,Yv"))]
-  "TARGET_SSE || TARGET_MMX_WITH_SSE"
+  "(TARGET_MMX || TARGET_MMX_WITH_SSE) && TARGET_SSE"
   "@
cvtpi2ps\t{%2, %0|%0, %2}
#
@@ -5023,8 +5023,7 @@
   rtx op2 = lowpart_subreg (V4SImode, operands[2],
GET_MODE (operands[2]));
   /* Generate SSE2 cvtdq2ps.  */
-  rtx insn = gen_floatv4siv4sf2 (operands[3], op2);
-  emit_insn (insn);
+  emit_insn (gen_floatv4siv4sf2 (operands[3], op2));
 
   /* Merge operands[3] with operands[0].  */
   rtx mask, op1;
@@ -5035,7 +5034,7 @@
  GEN_INT (6), GEN_INT (7)));
   op1 = gen_rtx_VEC_CONCAT (V8SFmode, operands[3], operands[1]);
   op2 = gen_rtx_VEC_SELECT (V4SFmode, op1, mask);
-  insn = gen_rtx_SET (operands[0], op2);
+  emit_insn (gen_rtx_SET (operands[0], op2));
 }
   else
 {
@@ -5045,8 +5044,7 @@
  GEN_INT (4), GEN_INT (5)));
   op1 = gen_rtx_VEC_CONCAT (V8SFmode, operands[0], operands[3]);
   op2 = gen_rtx_VEC_SELECT (V4SFmode, op1, mask);
-  insn = gen_rtx_SET (operands[0], op2);
-  emit_insn (insn);
+  emit_insn (gen_rtx_SET (operands[0], op2));
 
   /* Swap bits 0:63 with bits 64:127.  */
   mask = gen_rtx_PARALLEL (VOIDmode,
@@ -5055,9 +5053,8 @@
   rtx dest = lowpart_subreg (V4SImode, operands[0],
 GET_MODE (operands[0]));
   op1 = gen_rtx_VEC_SELECT (V4SImode, dest, mask);
-  insn = gen_rtx_SET (dest, op1);
+  emit_insn (gen_rtx_SET (dest, op1));
 }
-  emit_insn (insn);
   DONE;
 }
   [(set_attr "mmx_isa" "native,x64_noavx,x64_avx")
@@ -16356,14 +16353,12 @@
   /* Emulate MMX palignrdi with SSE psrldq.  */
   rtx op0 = lowpart_subreg (V2DImode, operands[0],
GET_MODE (operands[0]));
-  rtx insn;
   if (TARGET_AVX)
-insn = gen_vec_concatv2di (op0, operands[2], operands[1]);
+emit_insn (gen_vec_concatv2di (op0, operands[2], operands[1]));
   else
 {
   /* NB: SSE can only concatenate OP0 and OP1 to OP0.  */
-  insn = gen_vec_concatv2di (op0, operands[1], operands[2]);
-  emit_insn (insn);
+  emit_insn (gen_vec_concatv2di (op0, operands[1], operands[2]));
   /* Swap bits 0:63 with bits 64:127.  */
   rtx mask = gen_rtx_PARALLEL (VOIDmode,
   gen_rtvec (4, GEN_INT (2),
@@ -16372,9 +16367,8 @@
  GEN_INT (1)));
   rtx op1 = lowpart_subreg (V4SImode, op0, GET_MODE (op0));
   rtx op2 = gen_rtx_VEC_SELECT (V4SImode, op1, mask);
-  insn = gen_rtx_SET (op1, op2);
+  emit_insn (gen_rtx_SET (op1, op2));
 }
-  emit_insn (insn);
   operands[0] = lowpart_subreg (V1TImode, op0, GET_MODE (op0));
 }
   [(set_attr "mmx_isa" "native,x64_noavx,x64_avx")

Re: [PATCH, i386]: Introduce signbit2 expander

[Uros Bizjak]

On Wed, May 22, 2019 at 5:52 PM H.J. Lu  wrote:
>
> On Wed, May 22, 2019 at 6:36 AM Rainer Orth  
> wrote:
> >
> > Hi Uros,
> >
> > >> the new testcase FAILs on i386-pc-solaris2.11 (both with the default
> > >> -m32 and -m64), but also on i586-unknown-freebsd11.2, i686-pc-linux-gnu:
> > >>
> > >> +FAIL: gcc.target/i386/vect-signbitf.c scan-assembler-not -2147483648
> > >
> > > It works for me on x86_64-linux-gnu with -32, so I'm at loss on what
> > > might be wrong.
> >
> > I just tried x86_64-pc-linux-gnu and i686-pc-linux-gnu bootstraps: no
> > failures (with or without -m32) in the former, fails for both -m32 and
> > -m64 in the latter, just as on i386-pc-solaris2.11.
> >
>
> i686 GCC generates slightly different assembly codes from x86-64 GCC
> with -m32:
>
>
> @@ -88,16 +88,16 @@ main.cold:
>   .size a, 4096
>  a:
>   .long 0
> - .long 2147483648
> + .long -2147483648   This matches /* { dg-final {
> scan-assembler-not "-2147483648" } } */
>   .long 1065353216
> - .long 3212836864
> - .long 3221225472
> + .long -1082130432
> + .long -1073741824
>   .long 1077936128
> - .long 3231711232
> - .long 3238002688
> + .long -1063256064
> + .long -1056964608
>   .long 1095761920
>   .long 1101529088
> - .long 3251109888
> + .long -1043857408
>   .long 1107558400
>   .zero 4048
>
> These numbers are equivalent.  Should we check
>
> andl $-2147483648, %edx

I think we can go with:

-/* { dg-final { scan-assembler-not "-2147483648" } } */
+/* { dg-final { scan-assembler-not "\\$-2147483648" } } */

> BTW, we also need -mfpmath=sse since it may not be the default for -m32.

No need for this, vectorization does not care for target math.

Uros.

Re: [C++ PATCH] PR c++/86485 - -Wmaybe-unused with empty class ?:

[Jason Merrill]

On Tue, May 7, 2019 at 4:43 PM Jason Merrill  wrote:
>
> * typeck.c (build_static_cast_1): Use cp_build_addr_expr.
>
> For GCC 9 I fixed this bug with a patch to gimplify_cond_expr, but this
> function was also doing the wrong thing.
>
> Using build_address does not push the ADDR_EXPR down into the arms of a
> COND_EXPR, which we need for proper handling of conversion of an lvalue ?:
> to another reference type.

Yet another tweak that would have fixed this bug: we should treat INIT_EXPR
and MODIFY_EXPR differently for determining whether this is a simple empty
class copy, since a TARGET_EXPR on the RHS is direct initialization if
INIT_EXPR but copy if MODIFY_EXPR.

* cp-gimplify.c (simple_empty_class_p): Also true for MODIFY_EXPR.
commit 4ee9e054cba31bd532061bd357477e757b5b284a
Author: Jason Merrill 
Date:   Sat Mar 2 01:07:41 2019 -0500

PR c++/86485 - simple_empty_class_p

Yet another tweak that would have fixed this bug: we should treat INIT_EXPR
and MODIFY_EXPR differently for determining whether this is a simple empty
class copy, since a TARGET_EXPR on the RHS is direct initialization if
INIT_EXPR but copy if MODIFY_EXPR.

* cp-gimplify.c (simple_empty_class_p): Also true for MODIFY_EXPR.

diff --git a/gcc/cp/cp-gimplify.c b/gcc/cp/cp-gimplify.c
index e8c22c071c2..30937b1a1a3 100644
--- a/gcc/cp/cp-gimplify.c
+++ b/gcc/cp/cp-gimplify.c
@@ -594,19 +594,20 @@ gimplify_must_not_throw_expr (tree *expr_p, gimple_seq 
*pre_p)
return slot optimization alone because it isn't a copy.  */
 
 static bool
-simple_empty_class_p (tree type, tree op)
+simple_empty_class_p (tree type, tree op, tree_code code)
 {
+  if (TREE_CODE (op) == COMPOUND_EXPR)
+return simple_empty_class_p (type, TREE_OPERAND (op, 1), code);
   return
-((TREE_CODE (op) == COMPOUND_EXPR
-  && simple_empty_class_p (type, TREE_OPERAND (op, 1)))
- || TREE_CODE (op) == EMPTY_CLASS_EXPR
+(TREE_CODE (op) == EMPTY_CLASS_EXPR
+ || code == MODIFY_EXPR
  || is_gimple_lvalue (op)
  || INDIRECT_REF_P (op)
  || (TREE_CODE (op) == CONSTRUCTOR
-&& CONSTRUCTOR_NELTS (op) == 0
-&& !TREE_CLOBBER_P (op))
+&& CONSTRUCTOR_NELTS (op) == 0)
  || (TREE_CODE (op) == CALL_EXPR
 && !CALL_EXPR_RETURN_SLOT_OPT (op)))
+&& !TREE_CLOBBER_P (op)
 && is_really_empty_class (type, /*ignore_vptr*/true);
 }
 
@@ -715,7 +716,7 @@ cp_gimplify_expr (tree *expr_p, gimple_seq *pre_p, 
gimple_seq *post_p)
  TREE_OPERAND (*expr_p, 1) = build1 (VIEW_CONVERT_EXPR,
  TREE_TYPE (op0), op1);
 
-   else if (simple_empty_class_p (TREE_TYPE (op0), op1))
+   else if (simple_empty_class_p (TREE_TYPE (op0), op1, code))
  {
/* Remove any copies of empty classes.  Also drop volatile
   variables on the RHS to avoid infinite recursion from

[C++ PATCH] PR c++/20408 - unnecessary code for empty struct.

[Jason Merrill]

Here initializing the argument from a TARGET_EXPR isn't an empty class
copy even though the type is !TREE_ADDRESSABLE, so we should check
simple_empty_class_p.

Tested x86_64-pc-linux-gnu, applying to trunk.

* call.c (build_call_a): Use simple_empty_class_p.
---
 gcc/cp/cp-tree.h|  1 +
 gcc/cp/call.c   |  2 +-
 gcc/cp/cp-gimplify.c|  2 +-
 gcc/testsuite/g++.dg/tree-ssa/empty-3.C | 16 
 gcc/cp/ChangeLog|  3 +++
 5 files changed, 22 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/tree-ssa/empty-3.C

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 45a6a7010f6..7ad3c6b436d 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -7581,6 +7581,7 @@ extern tree cp_fully_fold_init(tree);
 extern void clear_fold_cache   (void);
 extern tree lookup_hotness_attribute   (tree);
 extern tree process_stmt_hotness_attribute (tree, location_t);
+extern bool simple_empty_class_p   (tree, tree, tree_code);
 
 /* in name-lookup.c */
 extern tree strip_using_decl(tree);
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 1e167851872..4d9331f98c2 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -393,7 +393,7 @@ build_call_a (tree function, int n, tree *argarray)
   {
tree arg = CALL_EXPR_ARG (function, i);
if (is_empty_class (TREE_TYPE (arg))
-   && ! TREE_ADDRESSABLE (TREE_TYPE (arg)))
+   && simple_empty_class_p (TREE_TYPE (arg), arg, INIT_EXPR))
  {
tree t = build0 (EMPTY_CLASS_EXPR, TREE_TYPE (arg));
arg = build2 (COMPOUND_EXPR, TREE_TYPE (t), arg, t);
diff --git a/gcc/cp/cp-gimplify.c b/gcc/cp/cp-gimplify.c
index 30937b1a1a3..7b9607dde17 100644
--- a/gcc/cp/cp-gimplify.c
+++ b/gcc/cp/cp-gimplify.c
@@ -593,7 +593,7 @@ gimplify_must_not_throw_expr (tree *expr_p, gimple_seq 
*pre_p)
non-empty CONSTRUCTORs get reduced properly, and we leave the
return slot optimization alone because it isn't a copy.  */
 
-static bool
+bool
 simple_empty_class_p (tree type, tree op, tree_code code)
 {
   if (TREE_CODE (op) == COMPOUND_EXPR)
diff --git a/gcc/testsuite/g++.dg/tree-ssa/empty-3.C 
b/gcc/testsuite/g++.dg/tree-ssa/empty-3.C
new file mode 100644
index 000..f340bd4070b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/tree-ssa/empty-3.C
@@ -0,0 +1,16 @@
+// PR c++/20408
+// { dg-additional-options -fdump-tree-gimple }
+// { dg-final { scan-tree-dump-times "struct Foo" 2 "gimple" } }
+
+struct Foo {};
+void foo(const Foo&);
+void bar(Foo);
+
+void fooc(void)
+{
+foo(Foo());
+}
+void barc(void)
+{
+bar(Foo());
+}
diff --git a/gcc/cp/ChangeLog b/gcc/cp/ChangeLog
index 6c9869679e0..88baf8647b6 100644
--- a/gcc/cp/ChangeLog
+++ b/gcc/cp/ChangeLog
@@ -1,5 +1,8 @@
 2019-05-22  Jason Merrill  
 
+   PR c++/20408 - unnecessary code for empty struct.
+   * call.c (build_call_a): Use simple_empty_class_p.
+
PR c++/86485 - -Wmaybe-unused with empty class ?:
* cp-gimplify.c (simple_empty_class_p): Also true for MODIFY_EXPR.
 

base-commit: cfb71062a9209810da06cd9b8dd559b62f0d61c7
prerequisite-patch-id: 18c3c5f0daf7a94fa325f89d1c67b15e426d84d1
-- 
2.20.1

Re: [RS6000] Don't pass -many to the assembler

[Segher Boessenkool]

On Wed, May 22, 2019 at 12:56:15PM +0930, Alan Modra wrote:
> On Tue, May 21, 2019 at 09:48:10AM -0500, Segher Boessenkool wrote:
> > (Is Power5 2.4?  Not 2.2?)
> 
> Yes, I think power5 was 2.02, but I haven't looked at cpu and arch
> books to verify exactly what power5 and power5+ was.

My notes say p5 is 2.02 and p5+ is 2.04.

> Note that gas
> lumps power5 and power5+ in one category so "power5" from
> rs6000_machine_from_flags means power5+ too.

Gotcha, good to know.

GCC can unfortunately not lump the two together, or code compiled for
Power5 will not necessarily work on a Power5 anymore.  For the few
people who care, but hey.

> This change was based on the fact that "friz" and other similar
> instructions enabled by gcc with TARGET_FPRND are enabled in gas by
> "-mpower5", "-mpwr5", or "-mpwr5x".  ("-mpower5+" isn't a valid gas
> option.)  rs6000-cpus.def puts OPTION_MASK_FPRND in ISA_2_4_MASKS, so
> ISA_2_4_MASKS is the one to use in deciding to pass "-mpower5" to
> gas.

FPRND is power5+, 2.04.

> > -mdejagnu-cpu=power7 should make the -mno-* things unnecessary I think?
> 
> No, it doesn't.  The -mno- options are to counter options added by
> check_vect_support_and_set_flags based on hardware detection.

Yeah, I realised that later...  Some later email I think.

It seems that check_vect_support_and_set_flags will need some work (or
the tests using it).


Segher

[PATCH] rs6000: Add basic infrastructure for PC-relative addressing

[Bill Schmidt]

Hi,

This patch adds basic infrastructure support to enable PC-relative addressing.
It adds the -mpcrel / -mno-pcrel option (defaulted on for -mcpu=future, 
otherwise
off), and provides a couple of interfaces to determine whether PC-relative
addressing should be used when generating a single function.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no regressions.
Is this okay for trunk?

Thanks,
Bill


2019-05-22  Bill Schmidt  
Michael Meissner  
Segher Boessenkool  

* config/rs6000/rs6000-cpus.def (ISA_FUTURE_MASKS_SERVER): Add
OPTION_MASK_PCREL.
(OTHER_FUTURE_MASKS): New #define.
(OTHER_P9_VECTOR_MASKS): Add OTHER_FUTURE_MASKS.
(POWERPC_MASKS): Add OPTION_MASK_PCREL.
* config/rs6000/rs6000-protos.h (rs6000_pcrel_p): New prototype.
(rs6000_fndecl_pcrel_p): Likewise.
* config/rs6000/rs6000.c (rs6000_option_override_internal): Report
error if -mpcrel is requested without -mcpu=future.
(rs6000_fndecl_pcrel_p): New function.
(rs6000_pcrel_p): Likewise.
* config/rs6000/rs6000.opt (mpcrel): New option.
* doc/invoke.texi: Document -mpcrel and -mno-pcrel.


diff --git a/gcc/config/rs6000/rs6000-cpus.def 
b/gcc/config/rs6000/rs6000-cpus.def
index f32da25930d..a4e1d1a01d8 100644
--- a/gcc/config/rs6000/rs6000-cpus.def
+++ b/gcc/config/rs6000/rs6000-cpus.def
@@ -74,10 +74,15 @@
 
 /* Support for a future processor's features.  */
 #define ISA_FUTURE_MASKS_SERVER(ISA_3_0_MASKS_SERVER   
\
-| OPTION_MASK_FUTURE)
+| OPTION_MASK_FUTURE   \
+| OPTION_MASK_PCREL)
+
+/* Flags that need to be turned off if -mno-future.  */
+#define OTHER_FUTURE_MASKS (OPTION_MASK_PCREL)
 
 /* Flags that need to be turned off if -mno-power9-vector.  */
-#define OTHER_P9_VECTOR_MASKS  (OPTION_MASK_FLOAT128_HW\
+#define OTHER_P9_VECTOR_MASKS  (OTHER_FUTURE_MASKS \
+| OPTION_MASK_FLOAT128_HW  \
 | OPTION_MASK_FUTURE   \
 | OPTION_MASK_P9_MINMAX)
 
@@ -129,6 +134,7 @@
 | OPTION_MASK_P9_MINMAX\
 | OPTION_MASK_P9_MISC  \
 | OPTION_MASK_P9_VECTOR\
+| OPTION_MASK_PCREL\
 | OPTION_MASK_POPCNTB  \
 | OPTION_MASK_POPCNTD  \
 | OPTION_MASK_POWERPC64\
diff --git a/gcc/config/rs6000/rs6000-protos.h 
b/gcc/config/rs6000/rs6000-protos.h
index 9718adaa2b9..18ece005a96 100644
--- a/gcc/config/rs6000/rs6000-protos.h
+++ b/gcc/config/rs6000/rs6000-protos.h
@@ -152,6 +152,8 @@ extern rtx rs6000_machopic_legitimize_pic_address (rtx, 
machine_mode,
 extern rtx rs6000_allocate_stack_temp (machine_mode, bool, bool);
 extern align_flags rs6000_loop_align (rtx);
 extern void rs6000_split_logical (rtx [], enum rtx_code, bool, bool, bool);
+extern bool rs6000_pcrel_p (struct function *);
+extern bool rs6000_fndecl_pcrel_p (const_tree);
 #endif /* RTX_CODE */
 
 #ifdef TREE_CODE
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 57c9eae8208..68abc81c354 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -4296,6 +4296,15 @@ rs6000_option_override_internal (bool global_init_p)
   rs6000_isa_flags &= ~OPTION_MASK_FLOAT128_HW;
 }
 
+  /* -mpcrel requires the prefixed load/store support on FUTURE systems.  */
+  if (!TARGET_FUTURE && TARGET_PCREL)
+{
+  if ((rs6000_isa_flags_explicit & OPTION_MASK_PCREL) != 0)
+   error ("%qs requires %qs", "-mpcrel", "-mcpu=future");
+
+  rs6000_isa_flags &= ~OPTION_MASK_PCREL;
+}
+
   /* Print the options after updating the defaults.  */
   if (TARGET_DEBUG_REG || TARGET_DEBUG_TARGET)
 rs6000_print_isa_options (stderr, 0, "after defaults", rs6000_isa_flags);
@@ -38112,6 +38121,34 @@ rs6000_save_toc_in_prologue_p (void)
   return (cfun && cfun->machine && cfun->machine->save_toc_in_prologue);
 }
 
+/* Return whether we should generate PC-relative code for FNDECL.  */
+bool
+rs6000_fndecl_pcrel_p (const_tree fndecl)
+{
+  if (DEFAULT_ABI != ABI_ELFv2)
+return false;
+
+  struct cl_target_option *opts = target_opts_for_fn (fndecl);
+
+  return ((opts->x_rs6000_isa_flags & OPTION_MASK_PCREL) != 0
+ && TARGET_CMODEL == CMODEL_MEDIUM);
+}
+
+/* Return whether we should generate PC-relative code for *FN.  */
+bool
+rs6000_pcrel_p (struct function *fn)
+{
+  if (DEFAULT_ABI != ABI_ELFv2)
+return false;
+
+  /* Optimize usual case.  */
+  if (fn == cfun)
+return ((rs6000_isa_flag

[PATCH] PR libstdc++/77691 fix resource_adaptor failures due to max_align_t bugs

[Jonathan Wakely]

Remove the hardcoded whitelist of allocators expected to return memory
aligned to alignof(max_align_t), because that doesn't work when the
platform's malloc() and GCC's max_align_t do not agree what the largest
fundamental alignment is. It's also sub-optimal for user-defined
allocators that return memory suitable for any fundamental alignment.

Instead use a hardcoded list of alignments that are definitely supported
by the platform malloc, and use a copy of the allocator rebound to a POD
type with the requested alignment. Only allocate an oversized
buffer to use with std::align for alignments larger than any of the
hardcoded values.

For 32-bit Solaris x86 do not include alignof(max_align_t) in the
hardcoded values.

PR libstdc++/77691
* include/experimental/memory_resource: Add system header pragma.
(__resource_adaptor_common::__guaranteed_alignment): Remove.
(__resource_adaptor_common::_Types)
(__resource_adaptor_common::__new_list)
(__resource_adaptor_common::_New_list)
(__resource_adaptor_common::_Alignments)
(__resource_adaptor_common::_Fund_align_types): New utilities for
creating a list of types with fundamental alignments.
(__resource_adaptor_imp::do_allocate): Call new _M_allocate function.
(__resource_adaptor_imp::do_deallocate): Call new _M_deallocate
function.
(__resource_adaptor_imp::_M_allocate): New function that first tries
to use an allocator rebound to a type with a fundamental alignment.
(__resource_adaptor_imp::_M_deallocate): Likewise for deallocation.
* testsuite/experimental/memory_resource/new_delete_resource.cc:
Adjust expected allocation sizes.
* testsuite/experimental/memory_resource/resource_adaptor.cc: Remove
xfail.

Tested x86_64-linux, committed to trunk.


commit 5a14390cba4480685ef98c97a88a1ea965679c6a
Author: Jonathan Wakely 
Date:   Wed May 22 21:06:25 2019 +0100

PR libstdc++/77691 fix resource_adaptor failures due to max_align_t bugs

Remove the hardcoded whitelist of allocators expected to return memory
aligned to alignof(max_align_t), because that doesn't work when the
platform's malloc() and GCC's max_align_t do not agree what the largest
fundamental alignment is. It's also sub-optimal for user-defined
allocators that return memory suitable for any fundamental alignment.

Instead use a hardcoded list of alignments that are definitely supported
by the platform malloc, and use a copy of the allocator rebound to a POD
type with the requested alignment. Only allocate an oversized
buffer to use with std::align for alignments larger than any of the
hardcoded values.

For 32-bit Solaris x86 do not include alignof(max_align_t) in the
hardcoded values.

PR libstdc++/77691
* include/experimental/memory_resource: Add system header pragma.
(__resource_adaptor_common::__guaranteed_alignment): Remove.
(__resource_adaptor_common::_Types)
(__resource_adaptor_common::__new_list)
(__resource_adaptor_common::_New_list)
(__resource_adaptor_common::_Alignments)
(__resource_adaptor_common::_Fund_align_types): New utilities for
creating a list of types with fundamental alignments.
(__resource_adaptor_imp::do_allocate): Call new _M_allocate 
function.
(__resource_adaptor_imp::do_deallocate): Call new _M_deallocate
function.
(__resource_adaptor_imp::_M_allocate): New function that first tries
to use an allocator rebound to a type with a fundamental alignment.
(__resource_adaptor_imp::_M_deallocate): Likewise for deallocation.
* testsuite/experimental/memory_resource/new_delete_resource.cc:
Adjust expected allocation sizes.
* testsuite/experimental/memory_resource/resource_adaptor.cc: Remove
xfail.

diff --git a/libstdc++-v3/include/experimental/memory_resource 
b/libstdc++-v3/include/experimental/memory_resource
index a0b30632154..dde3753fab7 100644
--- a/libstdc++-v3/include/experimental/memory_resource
+++ b/libstdc++-v3/include/experimental/memory_resource
@@ -30,6 +30,10 @@
 #ifndef _GLIBCXX_EXPERIMENTAL_MEMORY_RESOURCE
 #define _GLIBCXX_EXPERIMENTAL_MEMORY_RESOURCE 1
 
+#pragma GCC system_header
+
+#if __cplusplus >= 201402L
+
 #include   // align, uses_allocator, __uses_alloc
 #include // pair, 
experimental::erased_type
 #include   // atomic
@@ -358,23 +362,6 @@ namespace pmr {
  return __val;
}
 };
-
-template
-  struct __guaranteed_alignment : std::integral_constant { };
-
-template
-  struct __guaranteed_alignment<__gnu_cxx::new_allocator<_Tp>>
-  : std::alignment_of::type { };
-
-template
-  struct __guaranteed_alignment<__gnu_cxx::malloc

[PATCH] [Patch] Rename PSTL macro's consistent with libstdc++ standards.

[Thomas Rodgers]

0001-Patch-Rename-PSTL-macro-s-consistent-with-libstdc-st.patch.bz2
Description: Compressed patch

* include/bits/c++config: Rename all macros of the form __PSTL* to 
_PSTL*.
* include/std/algorithm: Likewise.
* include/std/execution: Likewise.
* include/std/numeric: Likewise.
* include/std/memory: Likewise.
* include/pstl/glue_memory_impl.h: Likewise.
* include/pstl/numeric_impl.h: Likewise.
* include/pstl/glue_memory_defs.h: Likewise.
* include/pstl/execution_defs.h: Likewise.
* include/pstl/utils.h: Likewise.
* include/pstl/algorithm_fwd.h: Likewise.
* include/pstl/unseq_backend_simd.h: Likewise.
* include/pstl/glue_execution_defs.h: Likewise.
* include/pstl/algorithm_impl.h: Likewise.
* include/pstl/parallel_impl.h: Likewise.
* include/pstl/memory_impl.h: Likewise.
* include/pstl/glue_numeric_defs.h: Likewise.
* include/pstl/parallel_backend_utils.h: Likewise.
* include/pstl/glue_algorithm_defs.h: Likewise.
* include/pstl/parallel_backend.h: Likewise.
* include/pstl/glue_numeric_impl.h: Likewise.
* include/pstl/parallel_backend_tbb.h: Likewise.
* include/pstl/numeric_fwd.h: Likewise.
* include/pstl/glue_algorithm_impl.h: Likewise.
* include/pstl/execution_impl.h: Likewise.
* include/pstl/pstl_config.h: Likewise.
* testsuite/util/pstl/pstl_test_config.h: Likewise.
* testsuite/util/pstl/test_utils.h: Likewise.
* 
testsuite/20_util/specialized_algorithms/pstl/uninitialized_construct.cc: 
Likewise.
* 
testsuite/20_util/specialized_algorithms/pstl/uninitialized_copy_move.cc: 
Likewise.
* testsuite/26_numerics/pstl/numeric_ops/adjacent_difference.cc: 
Likewise.
* testsuite/26_numerics/pstl/numeric_ops/scan.cc: Likewise.
* testsuite/26_numerics/pstl/numeric_ops/transform_scan.cc: Likewise.
* testsuite/26_numerics/pstl/numeric_ops/reduce.cc: Likewise.
* testsuite/25_algorithms/pstl/alg_nonmodifying/reverse.cc: Likewise.
* testsuite/25_algorithms/pstl/alg_nonmodifying/nth_element.cc: 
Likewise.
* testsuite/25_algorithms/pstl/alg_nonmodifying/find_end.cc: Likewise.
* testsuite/25_algorithms/pstl/alg_nonmodifying/find_if.cc: Likewise.
* testsuite/25_algorithms/pstl/alg_nonmodifying/none_of.cc: Likewise.
* testsuite/25_algorithms/pstl/alg_nonmodifying/count.cc: Likewise.
* testsuite/25_algorithms/pstl/alg_nonmodifying/reverse_copy.cc: 
Likewise.
* testsuite/25_algorithms/pstl/alg_nonmodifying/equal.cc: Likewise.
* testsuite/25_algorithms/pstl/alg_nonmodifying/search_n.cc: Likewise.
* testsuite/25_algorithms/pstl/alg_nonmodifying/find.cc: Likewise.
* testsuite/25_algorithms/pstl/alg_nonmodifying/all_of.cc: Likewise.
* testsuite/25_algorithms/pstl/alg_nonmodifying/find_first_of.cc: 
Likewise.
* testsuite/25_algorithms/pstl/alg_sorting/is_heap.cc: Likewise.
* testsuite/25_algorithms/pstl/alg_sorting/partial_sort.cc: Likewise.
* testsuite/25_algorithms/pstl/alg_sorting/partial_sort_copy.cc: 
Likewise.
* testsuite/25_algorithms/pstl/alg_sorting/lexicographical_compare.cc: 
Likewise.
* testsuite/25_algorithms/pstl/alg_merge/inplace_merge.cc: Likewise.
* testsuite/25_algorithms/pstl/alg_merge/merge.cc: Likewise.
* 
testsuite/25_algorithms/pstl/alg_modifying_operations/unique_copy_equal.cc: 
Likewise.
* 
testsuite/25_algorithms/pstl/alg_modifying_operations/replace_copy.cc: Likewise.
* 
testsuite/25_algorithms/pstl/alg_modifying_operations/is_partitioned.cc: 
Likewise.
* testsuite/25_algorithms/pstl/alg_modifying_operations/rotate_copy.cc: 
Likewise.
* testsuite/25_algorithms/pstl/alg_modifying_operations/remove.cc: 
Likewise.
* testsuite/25_algorithms/pstl/alg_modifying_operations/copy_if.cc: 
Likewise.
* 
testsuite/25_algorithms/pstl/alg_modifying_operations/partition_copy.cc: 
Likewise.
* testsuite/25_algorithms/pstl/alg_modifying_operations/partition.cc: 
Likewise.
* testsuite/25_algorithms/pstl/alg_modifying_operations/copy_move.cc: 
Likewise.
* testsuite/25_algorithms/pstl/alg_modifying_operations/unique.cc: 
Likewise.
* testsuite/25_algorithms/pstl/alg_modifying_operations/rotate.cc: 
Likewise.
* testsuite/25_algorithms/pstl/alg_nonmodifying/any_of.cc: Likewise.

[PATCH] warn on returning alloca and VLA (PR 71924, 90549)

[Martin Sebor]

-Wreturn-local-addr detects a subset of instances of returning
the address of a local object from a function but the warning
doesn't try to handle alloca or VLAs, or some non-trivial cases
of ordinary automatic variables[1].

The attached patch extends the implementation of the warning to
detect those.  It still doesn't detect instances where the address
is the result of a built-in such strcpy[2].

Tested on x86_64-linux.

Martin

[1] For example, this is only diagnosed with the patch:

  void* f (int i)
  {
struct S { int a[2]; } s[2];
return &s->a[i];
  }

[2] The following is not diagnosed even with the patch:

  void sink (void*);

  void* f (int i)
  {
char a[6];
char *p = __builtin_strcpy (a, "123");
sink (p);
return p;
  }

I would expect detecting to be possible and useful.  Maybe as
a follow-up.
PR middle-end/71924 - missing -Wreturn-local-addr returning alloca result
PR middle-end/90549 - missing -Wreturn-local-addr maybe returning an address of a local array plus offset

gcc/ChangeLog:

	PR c/71924
	* gimple-ssa-isolate-paths.c (is_addr_local): New function.
	(warn_return_addr_local_phi_arg, warn_return_addr_local): Same.
	(find_implicit_erroneous_behavior): Call warn_return_addr_local_phi_arg.
	(find_explicit_erroneous_behavior): Call warn_return_addr_local.

gcc/testsuite/ChangeLog:

	PR c/71924
	* gcc.dg/Wreturn-local-addr-2.c: New test.
	* gcc.dg/Walloca-4.c: Prune expected warnings.
	* gcc.dg/pr41551.c: Same.
	* gcc.dg/pr59523.c: Same.
	* gcc.dg/tree-ssa/pr88775-2.c: Same.
	* gcc.dg/winline-7.c: Same.

diff --git a/gcc/gimple-ssa-isolate-paths.c b/gcc/gimple-ssa-isolate-paths.c
index 33fe352bb23..2933ecf502e 100644
--- a/gcc/gimple-ssa-isolate-paths.c
+++ b/gcc/gimple-ssa-isolate-paths.c
@@ -341,6 +341,135 @@ stmt_uses_0_or_null_in_undefined_way (gimple *stmt)
   return false;
 }
 
+/* Return true if EXPR is a expression of pointer type that refers
+   to the address of a variable with automatic storage duration.
+   If so, set *PLOC to the location of the object or the call that
+   allocated it (for alloca and VLAs).  When PMAYBE is non-null,
+   also consider PHI statements and set *PMAYBE when some but not
+   all arguments of such statements refer to local variables, and
+   to clear it otherwise.  */
+
+static bool
+is_addr_local (tree exp, location_t *ploc, bool *pmaybe = NULL,
+	   hash_set *visited = NULL)
+{
+  if (TREE_CODE (exp) == ADDR_EXPR)
+{
+  tree baseaddr = get_base_address (TREE_OPERAND (exp, 0));
+  if (TREE_CODE (baseaddr) == MEM_REF)
+	return is_addr_local (TREE_OPERAND (baseaddr, 0), ploc, pmaybe, visited);
+
+  if ((!VAR_P (baseaddr)
+	   || is_global_var (baseaddr))
+	  && TREE_CODE (baseaddr) != PARM_DECL)
+	return false;
+
+  *ploc = DECL_SOURCE_LOCATION (baseaddr);
+  return true;
+}
+
+  if (TREE_CODE (exp) == SSA_NAME)
+{
+  gimple *def_stmt = SSA_NAME_DEF_STMT (exp);
+  enum gimple_code code = gimple_code (def_stmt);
+
+  if (is_gimple_assign (def_stmt))
+	{
+	  tree type = TREE_TYPE (gimple_assign_lhs (def_stmt));
+	  if (POINTER_TYPE_P (type))
+	{
+	  tree ptr = gimple_assign_rhs1 (def_stmt);
+	  return is_addr_local (ptr, ploc, pmaybe, visited);
+	}
+	  return false;
+	}
+
+  if (code == GIMPLE_CALL
+	  && gimple_call_builtin_p (def_stmt))
+	{
+	  tree fn = gimple_call_fndecl (def_stmt);
+	  int code = DECL_FUNCTION_CODE (fn);
+	  if (code != BUILT_IN_ALLOCA
+	  && code != BUILT_IN_ALLOCA_WITH_ALIGN)
+	return false;
+
+	  *ploc = gimple_location (def_stmt);
+	  return true;
+	}
+
+  if (code == GIMPLE_PHI && pmaybe)
+	{
+	  unsigned count = 0;
+	  gphi *phi_stmt = as_a  (def_stmt);
+
+	  unsigned nargs = gimple_phi_num_args (phi_stmt);
+	  for (unsigned i = 0; i < nargs; ++i)
+	{
+	  if (!visited->add (phi_stmt))
+		{
+		  tree arg = gimple_phi_arg_def (phi_stmt, i);
+		  if (is_addr_local (arg, ploc, pmaybe, visited))
+		++count;
+		}
+	}
+
+	  *pmaybe = count && count < nargs;
+	  return count != 0;
+	}
+}
+
+  return false;
+}
+
+/* Detect and diagnose returning the address of a local variable in
+   a PHI result LHS and argument OP and PHI edge E in basic block BB.  */
+
+static basic_block
+warn_return_addr_local_phi_arg (basic_block bb, basic_block duplicate,
+tree lhs, tree op, edge e)
+{
+  location_t origin;
+  if (!is_addr_local (op, &origin))
+return NULL;
+
+  gimple *use_stmt;
+  imm_use_iterator iter;
+
+  FOR_EACH_IMM_USE_STMT (use_stmt, iter, lhs)
+{
+  greturn *return_stmt = dyn_cast  (use_stmt);
+  if (!return_stmt)
+	continue;
+
+  if (gimple_return_retval (return_stmt) != lhs)
+	continue;
+
+  {
+	auto_diagnostic_group d;
+	if (warning_at (gimple_location (use_stmt),
+			OPT_Wreturn_local_addr,
+			"function may return address "
+			"of local variable")
+	&& origin != UNKNOWN_LOCATION)
+	  inform (origin, "declared here");
+  }
+
+  if ((flag_isolate_erroneous_paths_derefere

[C++ PATCH] Fix udlit-char-template-neg.C test

[Marek Polacek]

I noticed this test fails since r271492.  Probably obvious, but...

Tested on x86_64-linux, ok for trunk?

2019-05-22  Marek Polacek  

* g++.dg/cpp1y/udlit-char-template-neg.C: Expect the error on a
different line.  Check the column number too.

diff --git gcc/testsuite/g++.dg/cpp1y/udlit-char-template-neg.C 
gcc/testsuite/g++.dg/cpp1y/udlit-char-template-neg.C
index e77ea45890d..6295256b53d 100644
--- gcc/testsuite/g++.dg/cpp1y/udlit-char-template-neg.C
+++ gcc/testsuite/g++.dg/cpp1y/udlit-char-template-neg.C
@@ -2,7 +2,7 @@
 
 template
   int
-  operator"" _script()
-  { return 42; } // { dg-error "literal operator template|has invalid 
parameter list" }
+  operator"" _script() // { dg-error "3:literal operator template|has invalid 
parameter list" }
+  { return 42; }
 
 int i = "hi!"_script;

Re: C++ PATCH for c++/90548 - ICE with generic lambda and empty pack

[Marek Polacek]

On Wed, May 22, 2019 at 12:17:04AM -0400, Jason Merrill wrote:
> On 5/20/19 6:08 PM, Marek Polacek wrote:
> > We ICE here because we are accessing call_args even though it's empty:
> > 
> > (gdb) p (*call_args).is_empty()
> > $5 = true
> > 
> > It's empty because the pack processed by tsubst_pack_expansion expanded 
> > into an
> > empty vector, so nothing got pushed onto call_args.  So handle that, and 
> > also
> > handle pushing 'this' properly when call_args is empty.
> 
> Ah, the problem is that nargs is just wrong in the presence of pack
> expansions; in this case it's too large, but it could also end up too small.
> What we want is the length of call_args, not the number of args before doing
> the expansions.

Oh, right.  I've expanded the test to also detect the case when the number of
arguments grows after any packs have been expanded.  We still need the special
handling when adding 'this', though.

Thanks for catching the other problem!

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

2019-05-22  Marek Polacek  

PR c++/90548 - ICE with generic lambda and empty pack.
* pt.c (tsubst_copy_and_build): Handle pack expansion properly.

* g++.dg/cpp1y/lambda-generic-90548.C: New test.

diff --git gcc/cp/pt.c gcc/cp/pt.c
index 592adfcf5c1..0a31ba4f3fe 100644
--- gcc/cp/pt.c
+++ gcc/cp/pt.c
@@ -18861,6 +18861,9 @@ tsubst_copy_and_build (tree t,
   the thunk template for a generic lambda.  */
if (CALL_FROM_THUNK_P (t))
  {
+   /* Now that we've expanded any packs, the number of call args
+  might be different.  */
+   unsigned int cargs = call_args->length ();
tree thisarg = NULL_TREE;
if (TREE_CODE (function) == COMPONENT_REF)
  {
@@ -18874,7 +18877,7 @@ tsubst_copy_and_build (tree t,
/* We aren't going to do normal overload resolution, so force the
   template-id to resolve.  */
function = resolve_nondeduced_context (function, complain);
-   for (unsigned i = 0; i < nargs; ++i)
+   for (unsigned i = 0; i < cargs; ++i)
  {
/* In a thunk, pass through args directly, without any
   conversions.  */
@@ -18885,12 +1,18 @@ tsubst_copy_and_build (tree t,
  }
if (thisarg)
  {
-   /* Shift the other args over to make room.  */
-   tree last = (*call_args)[nargs - 1];
-   vec_safe_push (call_args, last);
-   for (int i = nargs-1; i > 0; --i)
- (*call_args)[i] = (*call_args)[i-1];
-   (*call_args)[0] = thisarg;
+   /* If there are no other args, just push 'this'.  */
+   if (cargs == 0)
+ vec_safe_push (call_args, thisarg);
+   else
+ {
+   /* Otherwise, shift the other args over to make room.  */
+   tree last = (*call_args)[cargs - 1];
+   vec_safe_push (call_args, last);
+   for (int i = cargs - 1; i > 0; --i)
+ (*call_args)[i] = (*call_args)[i - 1];
+   (*call_args)[0] = thisarg;
+ }
  }
ret = build_call_a (function, call_args->length (),
call_args->address ());
diff --git gcc/testsuite/g++.dg/cpp1y/lambda-generic-90548.C 
gcc/testsuite/g++.dg/cpp1y/lambda-generic-90548.C
new file mode 100644
index 000..b845dd85c41
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp1y/lambda-generic-90548.C
@@ -0,0 +1,22 @@
+// PR c++/90548
+// { dg-do compile { target c++14 } }
+
+struct S { S (void ()); };
+S foo([] (auto...) { });
+S foo2{[] (auto...) {}};
+S foo3 = {[] (auto...) {}};
+
+struct W { W(void (int)); };
+W bar([](auto...) { });
+W bar2{[](auto...) { }};
+W bar3 = {[](auto...) { }};
+
+struct T { T(void (int, int)); };
+T qux([](auto...) { });
+T qux2{[](auto...) { }};
+T qux3 = {[](auto...) { }};
+
+struct R { R(void (int, int, int, int, int, int, int, int, int, int)); };
+R baz([](auto...) { });
+R baz2{[](auto...) { }};
+R baz3 = {[](auto...) { }};

Re: [PATCH] [Patch] Rename PSTL macro's consistent with libstdc++ standards.

[Jonathan Wakely]

On 22/05/19 14:02 -0700, Thomas Rodgers wrote:

* include/bits/c++config: Rename all macros of the form __PSTL* to 
_PSTL*.


Please keep the ChangeLog lines to 80 columns, so break before
"_PSTL*" here.


* include/std/algorithm: Likewise.
* include/std/execution: Likewise.
* include/std/numeric: Likewise.
* include/std/memory: Likewise.
* include/pstl/glue_memory_impl.h: Likewise.
* include/pstl/numeric_impl.h: Likewise.
* include/pstl/glue_memory_defs.h: Likewise.
* include/pstl/execution_defs.h: Likewise.
* include/pstl/utils.h: Likewise.
* include/pstl/algorithm_fwd.h: Likewise.
* include/pstl/unseq_backend_simd.h: Likewise.
* include/pstl/glue_execution_defs.h: Likewise.
* include/pstl/algorithm_impl.h: Likewise.
* include/pstl/parallel_impl.h: Likewise.
* include/pstl/memory_impl.h: Likewise.
* include/pstl/glue_numeric_defs.h: Likewise.
* include/pstl/parallel_backend_utils.h: Likewise.
* include/pstl/glue_algorithm_defs.h: Likewise.
* include/pstl/parallel_backend.h: Likewise.
* include/pstl/glue_numeric_impl.h: Likewise.
* include/pstl/parallel_backend_tbb.h: Likewise.
* include/pstl/numeric_fwd.h: Likewise.
* include/pstl/glue_algorithm_impl.h: Likewise.
* include/pstl/execution_impl.h: Likewise.
* include/pstl/pstl_config.h: Likewise.
* testsuite/util/pstl/pstl_test_config.h: Likewise.
* testsuite/util/pstl/test_utils.h: Likewise.
* 
testsuite/20_util/specialized_algorithms/pstl/uninitialized_construct.cc: 
Likewise.


And break before "Likewise" here, and in the other lines that are
longer than 80 columns.

The actual patch is fine, so OK for trunk with that change. Thanks.

Re: [C++ PATCH] PR c++/86485 - -Wmaybe-unused with empty class ?:

[Jason Merrill]

On Tue, May 7, 2019 at 4:43 PM Jason Merrill  wrote:
>
> * typeck.c (build_static_cast_1): Use cp_build_addr_expr.
>
> For GCC 9 I fixed this bug with a patch to gimplify_cond_expr, but this
> function was also doing the wrong thing.
>
> Using build_address does not push the ADDR_EXPR down into the arms of a
> COND_EXPR, which we need for proper handling of conversion of an lvalue ?:
> to another reference type.

And that allows the gimplifier to assert that we should never see a
COND_EXPR of addressable type.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit c4f1e37204aaea7efb2aa7dc234d5c8ebeba1089
Author: Jason Merrill 
Date:   Mon Mar 4 14:09:57 2019 -0500

* gimplify.c (gimplify_cond_expr): Don't check TREE_ADDRESSABLE.

The front end shouldn't produce a GENERIC COND_EXPR of TREE_ADDRESSABLE
type.

diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 5bacb255ba7..6905165ad33 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -3990,10 +3990,12 @@ gimplify_cond_expr (tree *expr_p, gimple_seq *pre_p, 
fallback_t fallback)
   tree result;
 
   /* If either an rvalue is ok or we do not require an lvalue, create the
-temporary.  But we cannot do that if the type is addressable.  */
+temporary.  We cannot do that if the type is addressable, but
+that should have been avoided before we got here.  */
   if (((fallback & fb_rvalue) || !(fallback & fb_lvalue))
- && !TREE_ADDRESSABLE (type))
+ && (flag_checking || !TREE_ADDRESSABLE (type)))
{
+ gcc_assert (!TREE_ADDRESSABLE (type));
  if (gimplify_ctxp->allow_rhs_cond_expr
  /* If either branch has side effects or could trap, it can't be
 evaluated unconditionally.  */

Re: [C++ PATCH] Fix udlit-char-template-neg.C test

[Paolo Carlini]

Hi,

On 22/05/19 23:45, Marek Polacek wrote:

I noticed this test fails since r271492.  Probably obvious, but...

Tested on x86_64-linux, ok for trunk?


I was wondering why I didn't notice it... It's because it only fails 
with check-c++-all not with check-c++. Anyway, it seems obvious to me 
too and the right line is the current one, good ;)


Paolo.

Re: [C++ PATCH] Fix udlit-char-template-neg.C test

[Marek Polacek]

On Thu, May 23, 2019 at 12:00:22AM +0200, Paolo Carlini wrote:
> Hi,
> 
> On 22/05/19 23:45, Marek Polacek wrote:
> > I noticed this test fails since r271492.  Probably obvious, but...
> > 
> > Tested on x86_64-linux, ok for trunk?
> 
> I was wondering why I didn't notice it... It's because it only fails with
> check-c++-all not with check-c++. Anyway, it seems obvious to me too and the
> right line is the current one, good ;)

I'll go ahead and check it in, thanks for confirming!

Marek

Re: [C++ PATCH] Fix udlit-char-template-neg.C test

[Paolo Carlini]

Hi,

On 23/05/19 00:04, Marek Polacek wrote:

On Thu, May 23, 2019 at 12:00:22AM +0200, Paolo Carlini wrote:

Hi,

On 22/05/19 23:45, Marek Polacek wrote:

I noticed this test fails since r271492.  Probably obvious, but...

Tested on x86_64-linux, ok for trunk?

I was wondering why I didn't notice it... It's because it only fails with
check-c++-all not with check-c++. Anyway, it seems obvious to me too and the
right line is the current one, good ;)

I'll go ahead and check it in, thanks for confirming!


Actually, Marek, there is a vey weird issue with our DejaGNU 
infrastructure which I noticed already in the past: dg-error "3:literal 
operator template|has invalid parameter list" is unexpectedly very weak: 
the column information, the 3, due to the | is mysteriously ignored. I 
think you want to shorten the string literal to simply "3:literal 
operator template", or alternately specify everything up to the "has 
invalid parameter list" (ie, see what I did for that patch and many other).


Paolo.

[PATCH] PR libstdc++/90557 fix path assignment that alters source

[Jonathan Wakely]

PR libstdc++/90557
* src/c++17/fs_path.cc (path::_List::operator=(const _List&)): Fix
reversed arguments to uninitialized_copy_n.
* testsuite/27_io/filesystem/path/assign/copy.cc: Check that source
is unchanged by copy assignment.
* testsuite/util/testsuite_fs.h (compare_paths): Use std::equal to
compare path components.

Tested x86_64-linux, committed to trunk. I'll backport it to
gcc-9-branch too.


commit edcb23ee78d194cbb518a151c7edfbb2895c48d3
Author: Jonathan Wakely 
Date:   Wed May 22 22:07:50 2019 +0100

PR libstdc++/90557 fix path assignment that alters source

PR libstdc++/90557
* src/c++17/fs_path.cc (path::_List::operator=(const _List&)): Fix
reversed arguments to uninitialized_copy_n.
* testsuite/27_io/filesystem/path/assign/copy.cc: Check that source
is unchanged by copy assignment.
* testsuite/util/testsuite_fs.h (compare_paths): Use std::equal to
compare path components.

diff --git a/libstdc++-v3/src/c++17/fs_path.cc 
b/libstdc++-v3/src/c++17/fs_path.cc
index 605f62cbf81..8e01bf510d3 100644
--- a/libstdc++-v3/src/c++17/fs_path.cc
+++ b/libstdc++-v3/src/c++17/fs_path.cc
@@ -278,8 +278,8 @@ path::_List::operator=(const _List& other)
to[i]._M_pathname.reserve(from[i]._M_pathname.length());
  if (newsize > oldsize)
{
- std::uninitialized_copy_n(to + oldsize, newsize - oldsize,
-   from + oldsize);
+ std::uninitialized_copy_n(from + oldsize, newsize - oldsize,
+   to + oldsize);
  impl->_M_size = newsize;
}
  else if (newsize < oldsize)
diff --git a/libstdc++-v3/testsuite/27_io/filesystem/path/assign/copy.cc 
b/libstdc++-v3/testsuite/27_io/filesystem/path/assign/copy.cc
index 775dbffad36..6aa25ae12ef 100644
--- a/libstdc++-v3/testsuite/27_io/filesystem/path/assign/copy.cc
+++ b/libstdc++-v3/testsuite/27_io/filesystem/path/assign/copy.cc
@@ -64,10 +64,25 @@ test03()
   VERIFY( ptr2 == p.begin()->c_str() );
 }
 
+void
+test04()
+{
+  // PR libstdc++/90557
+  path p1 = "a/b/c";
+  const path p2 = "d/e";
+  const path p3 = p2;
+  p1.clear();
+  p1 = p2;
+  __gnu_test::compare_paths(p1, p2);
+  __gnu_test::compare_paths(p1, p3);
+  __gnu_test::compare_paths(p2, p3);
+}
+
 int
 main()
 {
   test01();
   test02();
   test03();
+  test04();
 }
diff --git a/libstdc++-v3/testsuite/util/testsuite_fs.h 
b/libstdc++-v3/testsuite/util/testsuite_fs.h
index baba90eaa0c..b2a5ee6e655 100644
--- a/libstdc++-v3/testsuite/util/testsuite_fs.h
+++ b/libstdc++-v3/testsuite/util/testsuite_fs.h
@@ -30,6 +30,7 @@ namespace test_fs = std::filesystem;
 #include 
 namespace test_fs = std::experimental::filesystem;
 #endif
+#include 
 #include 
 #include 
 #include 
@@ -62,10 +63,15 @@ namespace __gnu_test
 PATH_CHK( p1, p2, is_relative );
 auto d1 = std::distance(p1.begin(), p1.end());
 auto d2 = std::distance(p2.begin(), p2.end());
-if( d1 != d2 )
+if (d1 != d2)
   throw test_fs::filesystem_error(
- "distance(begin, end)", p1, p2,
+ "distance(begin1, end1) != distance(begin2, end2)", p1, p2,
  std::make_error_code(std::errc::invalid_argument) );
+if (!std::equal(p1.begin(), p1.end(), p2.begin(), p2.end()))
+  throw test_fs::filesystem_error(
+ "!equal(begin1, end1, begin2, end2)", p1, p2,
+ std::make_error_code(std::errc::invalid_argument) );
+
   }
 
   const std::string test_paths[] = {

[PATCH] rs6000: One more bit of PC-relative enablement

[Bill Schmidt]

Hi,

My last patch was a result of refactoring, and I missed one important line.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu; okay for turnk
with the other patch?

Thanks,
Bill


2019-05-22  Bill Schmidt  
Michael Meissner  

* config/rs6000/rs6000.c (rs6000_opt_mask): Add entry for pcrel.


diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 68abc81c354..959e222c9cb 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -36282,6 +36282,7 @@ static struct rs6000_opt_mask const rs6000_opt_masks[] =
   { "modulo",  OPTION_MASK_MODULO, false, true  },
   { "mulhw",   OPTION_MASK_MULHW,  false, true  },
   { "multiple",OPTION_MASK_MULTIPLE,   false, 
true  },
+  { "pcrel",   OPTION_MASK_PCREL,  false, true  },
   { "popcntb", OPTION_MASK_POPCNTB,false, true  },
   { "popcntd", OPTION_MASK_POPCNTD,false, true  },
   { "power8-fusion",   OPTION_MASK_P8_FUSION,  false, true  },

Re: [PATCH] PR libstdc++/77691 fix resource_adaptor failures due to max_align_t bugs

[Jonathan Wakely]

On 22/05/19 21:40 +0100, Jonathan Wakely wrote:

Remove the hardcoded whitelist of allocators expected to return memory
aligned to alignof(max_align_t), because that doesn't work when the
platform's malloc() and GCC's max_align_t do not agree what the largest
fundamental alignment is. It's also sub-optimal for user-defined
allocators that return memory suitable for any fundamental alignment.

Instead use a hardcoded list of alignments that are definitely supported
by the platform malloc, and use a copy of the allocator rebound to a POD
type with the requested alignment. Only allocate an oversized
buffer to use with std::align for alignments larger than any of the
hardcoded values.

For 32-bit Solaris x86 do not include alignof(max_align_t) in the
hardcoded values.

PR libstdc++/77691
* include/experimental/memory_resource: Add system header pragma.
(__resource_adaptor_common::__guaranteed_alignment): Remove.
(__resource_adaptor_common::_Types)
(__resource_adaptor_common::__new_list)
(__resource_adaptor_common::_New_list)
(__resource_adaptor_common::_Alignments)
(__resource_adaptor_common::_Fund_align_types): New utilities for
creating a list of types with fundamental alignments.
(__resource_adaptor_imp::do_allocate): Call new _M_allocate function.
(__resource_adaptor_imp::do_deallocate): Call new _M_deallocate
function.
(__resource_adaptor_imp::_M_allocate): New function that first tries
to use an allocator rebound to a type with a fundamental alignment.
(__resource_adaptor_imp::_M_deallocate): Likewise for deallocation.
* testsuite/experimental/memory_resource/new_delete_resource.cc:
Adjust expected allocation sizes.
* testsuite/experimental/memory_resource/resource_adaptor.cc: Remove
xfail.


Gah, that's the wrong ChangeLog, from an earlier version of the patch.
The right one is in the ChangeLog file, but the svn commit has the
wrong info, sorry.

The correct one is:

   PR libstdc++/77691
   * include/experimental/memory_resource: Add system header pragma and
   do not define anything unless compiled as C++14 or later.
   (__resource_adaptor_common::__guaranteed_alignment): Remove.
   (__resource_adaptor_imp::do_allocate): If the requested alignment
   is a fundamental alignment then either allocate directly from _M_alloc
   or call the new _M_allocate function.
   (__resource_adaptor_imp::do_deallocate): Likewise for deallocation.
   (__resource_adaptor_imp::_M_allocate): New function that uses a copy
   of the allocator rebound to a POD type with the specified alignment.
   (__resource_adaptor_imp::_M_deallocate): Likewise for deallocation.
   * testsuite/experimental/memory_resource/new_delete_resource.cc:
   Adjust expected allocation sizes.
   * testsuite/experimental/memory_resource/resource_adaptor.cc: Remove
   xfail for Solaris x86.

[committed, amdgcn] Disable trampolines on GCN5

[Andrew Stubbs]

Trampolines work just fine on GCN3 devices, but GCN5 devices have 
execute permission hardware, and the driver sets permission off for the 
private segment allocation in which the stacks are located.


It may be possible to implement indirect calls to nested functions 
another way, but for now this will prevent unexplained crashes or hangs 
on unsupported devices.


--
Andrew Stubbs
Mentor Graphics / CodeSourcery
Fix trampoline execution failures on GCN5.

2019-05-22  Andrew Stubbs  

	gcc/
	* config/gcn/gcn.c (gcn_trampoline_init): Call "sorry" on GCN5.

diff --git a/gcc/config/gcn/gcn.c b/gcc/config/gcn/gcn.c
index 1dd2ff2d4f0..6820837c763 100644
--- a/gcc/config/gcn/gcn.c
+++ b/gcc/config/gcn/gcn.c
@@ -3062,6 +3062,10 @@ gcn_asm_trampoline_template (FILE *f)
 static void
 gcn_trampoline_init (rtx m_tramp, tree fndecl, rtx chain_value)
 {
+  if (TARGET_GCN5_PLUS)
+sorry ("nested function trampolines not supported on GCN5 due to"
+   " non-executable stacks");
+
   emit_block_move (m_tramp, assemble_trampoline_template (),
 		   GEN_INT (TRAMPOLINE_SIZE), BLOCK_OP_NORMAL);
 

Re: [PATCH] PR libstdc++/77691 fix resource_adaptor failures due to max_align_t bugs

[Jonathan Wakely]

On 22/05/19 23:17 +0100, Jonathan Wakely wrote:

On 22/05/19 21:40 +0100, Jonathan Wakely wrote:

Remove the hardcoded whitelist of allocators expected to return memory
aligned to alignof(max_align_t), because that doesn't work when the
platform's malloc() and GCC's max_align_t do not agree what the largest
fundamental alignment is. It's also sub-optimal for user-defined
allocators that return memory suitable for any fundamental alignment.

Instead use a hardcoded list of alignments that are definitely supported
by the platform malloc, and use a copy of the allocator rebound to a POD
type with the requested alignment. Only allocate an oversized
buffer to use with std::align for alignments larger than any of the
hardcoded values.

For 32-bit Solaris x86 do not include alignof(max_align_t) in the
hardcoded values.

PR libstdc++/77691
* include/experimental/memory_resource: Add system header pragma.
(__resource_adaptor_common::__guaranteed_alignment): Remove.
(__resource_adaptor_common::_Types)
(__resource_adaptor_common::__new_list)
(__resource_adaptor_common::_New_list)
(__resource_adaptor_common::_Alignments)
(__resource_adaptor_common::_Fund_align_types): New utilities for
creating a list of types with fundamental alignments.
(__resource_adaptor_imp::do_allocate): Call new _M_allocate function.
(__resource_adaptor_imp::do_deallocate): Call new _M_deallocate
function.
(__resource_adaptor_imp::_M_allocate): New function that first tries
to use an allocator rebound to a type with a fundamental alignment.
(__resource_adaptor_imp::_M_deallocate): Likewise for deallocation.
* testsuite/experimental/memory_resource/new_delete_resource.cc:
Adjust expected allocation sizes.
* testsuite/experimental/memory_resource/resource_adaptor.cc: Remove
xfail.


Gah, that's the wrong ChangeLog, from an earlier version of the patch.
The right one is in the ChangeLog file, but the svn commit has the
wrong info, sorry.

The correct one is:

  PR libstdc++/77691
  * include/experimental/memory_resource: Add system header pragma and
  do not define anything unless compiled as C++14 or later.
  (__resource_adaptor_common::__guaranteed_alignment): Remove.
  (__resource_adaptor_imp::do_allocate): If the requested alignment
  is a fundamental alignment then either allocate directly from _M_alloc
  or call the new _M_allocate function.
  (__resource_adaptor_imp::do_deallocate): Likewise for deallocation.
  (__resource_adaptor_imp::_M_allocate): New function that uses a copy
  of the allocator rebound to a POD type with the specified alignment.
  (__resource_adaptor_imp::_M_deallocate): Likewise for deallocation.
  * testsuite/experimental/memory_resource/new_delete_resource.cc:
  Adjust expected allocation sizes.
  * testsuite/experimental/memory_resource/resource_adaptor.cc: Remove
  xfail for Solaris x86.


Double-gah, the tests are failing for 32-bit x86-linux, but not on my
machine. Presumably because glibc malloc only used to guarantee 8-byte
alignment until fairly recently.

[committed, amdgcn] Add support for constructors and destructors

[Andrew Stubbs]

This patch adds support for constructors that run before "main", and 
destructors that run afterwards. This is prerequisite for supporting 
more of libgfortran (and other libraries, including libstdc++).


The init_array and fini_array sections are created, and gcn-run is 
modified to launch the initialization and finalization kernels, in 
addition to the main entry point.


--
Andrew Stubbs
Mentor Graphics / CodeSourcery
Add support for constructors and destuctors on GCN

2019-05-22  Kwok Cheung Yeung  
Andrew Stubbs  

	AMDGPU-230

	gcc/
	* config.gcc (gcc_cv_initfini_array): Set for AMD GCN.
	* config/gcn/gcn-run.c (init_array_kernel, fini_array_kernel): New.
	(kernel): Rename to...
	(main_kernel): ... this.
	(load_image): Load _init_array and _fini_array kernels.
	(run): Add argument for kernel to run.
	(main): Run init_array_kernel before main_kernel, and
	fini_array_kernel after.
	* config/gcn/gcn.c (gcn_handle_amdgpu_hsa_kernel_attribute): Allow
	amdgpu_hsa_kernel attribute on functions.
	(gcn_disable_constructors): Delete.
	(TARGET_ASM_CONSTRUCTOR, TARGET_ASM_DESTRUCTOR): Delete.
	* config/gcn/crt0.c (size_t): Define.
	(_init_array, _fini_array): New.
	(__preinit_array_start, __preinit_array_end,
	__init_array_start, __init_array_end,
	__fini_array_start, __fini_array_end): Declare weak references.

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 76bb316942d..7122c8ed1c8 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1424,6 +1424,8 @@ amdgcn-*-amdhsa)
 		extra_programs="${extra_programs} mkoffload\$(exeext)"
 		tm_file="${tm_file} gcn/offload.h"
 	fi
+	# Force .init_array support.
+	gcc_cv_initfini_array=yes
 	;;
 moxie-*-elf)
 	gas=yes
diff --git a/gcc/config/gcn/gcn-run.c b/gcc/config/gcn/gcn-run.c
index 00a71014c20..84718f42846 100644
--- a/gcc/config/gcn/gcn-run.c
+++ b/gcc/config/gcn/gcn-run.c
@@ -66,7 +66,9 @@ bool debug = false;
 
 hsa_agent_t device = { 0 };
 hsa_queue_t *queue = NULL;
-uint64_t kernel = 0;
+uint64_t init_array_kernel = 0;
+uint64_t fini_array_kernel = 0;
+uint64_t main_kernel = 0;
 hsa_executable_t executable = { 0 };
 
 hsa_region_t kernargs_region = { 0 };
@@ -427,14 +429,30 @@ load_image (const char *filename)
   XHSA (hsa_fns.hsa_executable_freeze_fn (executable, ""),
 	"Freeze GCN executable");
 
-  /* Locate the "main" function, and read the kernel's properties.  */
+  /* Locate the "_init_array" function, and read the kernel's properties.  */
   hsa_executable_symbol_t symbol;
+  XHSA (hsa_fns.hsa_executable_get_symbol_fn (executable, NULL, "_init_array",
+	  device, 0, &symbol),
+	"Find '_init_array' function");
+  XHSA (hsa_fns.hsa_executable_symbol_get_info_fn
+	(symbol, HSA_EXECUTABLE_SYMBOL_INFO_KERNEL_OBJECT, &init_array_kernel),
+	"Extract '_init_array' kernel object kernel object");
+
+  /* Locate the "_fini_array" function, and read the kernel's properties.  */
+  XHSA (hsa_fns.hsa_executable_get_symbol_fn (executable, NULL, "_fini_array",
+	  device, 0, &symbol),
+	"Find '_fini_array' function");
+  XHSA (hsa_fns.hsa_executable_symbol_get_info_fn
+	(symbol, HSA_EXECUTABLE_SYMBOL_INFO_KERNEL_OBJECT, &fini_array_kernel),
+	"Extract '_fini_array' kernel object kernel object");
+
+  /* Locate the "main" function, and read the kernel's properties.  */
   XHSA (hsa_fns.hsa_executable_get_symbol_fn (executable, NULL, "main",
 	  device, 0, &symbol),
 	"Find 'main' function");
   XHSA (hsa_fns.hsa_executable_symbol_get_info_fn
-	(symbol, HSA_EXECUTABLE_SYMBOL_INFO_KERNEL_OBJECT, &kernel),
-	"Extract kernel object");
+	(symbol, HSA_EXECUTABLE_SYMBOL_INFO_KERNEL_OBJECT, &main_kernel),
+	"Extract 'main' kernel object");
   XHSA (hsa_fns.hsa_executable_symbol_get_info_fn
 	(symbol, HSA_EXECUTABLE_SYMBOL_INFO_KERNEL_KERNARG_SEGMENT_SIZE,
 	 &kernarg_segment_size),
@@ -684,7 +702,7 @@ gomp_print_output (struct kernargs *kernargs, bool final)
 /* Execute an already-loaded kernel on the device.  */
 
 static void
-run (void *kernargs)
+run (uint64_t kernel, void *kernargs)
 {
   /* A "signal" is used to launch and monitor the kernel.  */
   hsa_signal_t signal;
@@ -822,11 +840,17 @@ main (int argc, char *argv[])
   kernargs->heap_ptr = (int64_t) &kernargs->heap;
   kernargs->heap.size = heap_size;
 
+  /* Run constructors on the GPU.  */
+  run (init_array_kernel, kernargs);
+
   /* Run the kernel on the GPU.  */
-  run (kernargs);
+  run (main_kernel, kernargs);
   unsigned int return_value =
 (unsigned int) kernargs->output_data.return_value;
 
+  /* Run destructors on the GPU.  */
+  run (fini_array_kernel, kernargs);
+
   unsigned int upper = (return_value & ~0x) >> 16;
   if (upper == 0xcafe)
 printf ("Kernel exit value was never set\n");
diff --git a/gcc/config/gcn/gcn.c b/gcc/config/gcn/gcn.c
index 6820837c763..47630c6edb4 100644
--- a/gcc/config/gcn/gcn.c
+++ b/gcc/config/gcn/gcn.c
@@ -305,9 +305,7 @@ static tree
 gcn_handle_amdgpu_hsa_kernel_attribute (tree *node, tree name,
 	tr

Re: Backport fix for PR c++/85400

[Eric Botcazou]

> Probably also required for GCC 7 then?

The problem is (probably) present there too, but that's not my call.

-- 
Eric Botcazou

Re: [PATCH] Assorted optc-save-gen.awk fixes (PR bootstrap/90543)

[Jakub Jelinek]

On Wed, May 22, 2019 at 01:41:56PM +0200, Jakub Jelinek wrote:
> Ok for trunk if it passes full bootstrap/regtest on x86_64-linux (passed
> already normal build on aarch64-linux cross)?

Successfully bootstrapped/regtested on x86_64-linux and i686-linux.

> 2019-05-22  Jakub Jelinek  
> 
>   PR bootstrap/90543
>   * optc-save-gen.awk: In cl_optimization_print, use correct condition
>   for var_opt_string printing.  In cl_optimization_print_diff, print
>   (null) instead of invoking undefined behavior if one of the
>   var_opt_string pointers is NULL and use && instead of first || in the
>   guarding condition.  For var_target_other options, handle const char *
>   target variables similarly to const char * optimize node variables.

Jakub

[PATCH] Improve stack_protect_test_ on x86 (PR target/90568)

[Jakub Jelinek]

Hi!

For stack_protect_test_[sd]i we don't use comparison, so that we clear the
content of the register and don't keep the stack canary in any register for
security reasons, but as mentioned in the PR, using sub instead of xor
achieves the same effect in the likely case (no failure), in the failure
case neither xor nor sub wipes it completely but in that case the program
terminates anyway through __stack_chk_fail, and, on some CPUs sub can be
fused with the conditional branch, while xor can't.

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

Incrementally, we should consider handling e.g. *subsi_2{,_zext} and similar
patterns and also this stack_protect_test_[sd]i in ix86_macro_fusion_pair_p,
not sure if unconditionally, or only when tuning for skylake+ / generic.

2019-05-22  Jakub Jelinek  

PR target/90568
* config/i386/i386.md (stack_protect_test_): Use sub instead
of xor.

--- gcc/config/i386/i386.md.jj  2019-05-15 23:36:47.829062261 +0200
+++ gcc/config/i386/i386.md 2019-05-22 18:40:04.360359867 +0200
@@ -19513,7 +19513,7 @@ (define_insn "stack_protect_test_"
UNSPEC_SP_TEST))
(clobber (match_scratch:PTR 3 "=&r"))]
   ""
-  "mov{}\t{%1, %3|%3, %1}\;xor{}\t{%2, %3|%3, %2}"
+  "mov{}\t{%1, %3|%3, %1}\;sub{}\t{%2, %3|%3, %2}"
   [(set_attr "type" "multi")])
 
 (define_insn "sse4_2_crc32"

Jakub

Re: [C++ PATCH] Fix udlit-char-template-neg.C test

[Marek Polacek]

On Thu, May 23, 2019 at 12:11:24AM +0200, Paolo Carlini wrote:
> Hi,
> 
> On 23/05/19 00:04, Marek Polacek wrote:
> > On Thu, May 23, 2019 at 12:00:22AM +0200, Paolo Carlini wrote:
> > > Hi,
> > > 
> > > On 22/05/19 23:45, Marek Polacek wrote:
> > > > I noticed this test fails since r271492.  Probably obvious, but...
> > > > 
> > > > Tested on x86_64-linux, ok for trunk?
> > > I was wondering why I didn't notice it... It's because it only fails with
> > > check-c++-all not with check-c++. Anyway, it seems obvious to me too and 
> > > the
> > > right line is the current one, good ;)
> > I'll go ahead and check it in, thanks for confirming!
> 
> Actually, Marek, there is a vey weird issue with our DejaGNU infrastructure
> which I noticed already in the past: dg-error "3:literal operator
> template|has invalid parameter list" is unexpectedly very weak: the column
> information, the 3, due to the | is mysteriously ignored. I think you want
> to shorten the string literal to simply "3:literal operator template", or
> alternately specify everything up to the "has invalid parameter list" (ie,
> see what I did for that patch and many other).

I see, thanks.  I'm checking in this, then: 

2019-05-22  Marek Polacek  

* g++.dg/cpp1y/udlit-char-template-neg.C: Expect the error on a
different line.  Check the column number too.

diff --git gcc/testsuite/g++.dg/cpp1y/udlit-char-template-neg.C 
gcc/testsuite/g++.dg/cpp1y/udlit-char-template-neg.C
index e77ea45890d..6295256b53d 100644
--- gcc/testsuite/g++.dg/cpp1y/udlit-char-template-neg.C
+++ gcc/testsuite/g++.dg/cpp1y/udlit-char-template-neg.C
@@ -2,7 +2,7 @@
 
 template
   int
-  operator"" _script()
-  { return 42; } // { dg-error "literal operator template|has invalid 
parameter list" }
+  operator"" _script() // { dg-error "3:literal operator template" }
+  { return 42; }
 
 int i = "hi!"_script;

Re: [PATCH] rs6000: Infrastructure for future arch

[Segher Boessenkool]

Hi Bill,

On Wed, May 22, 2019 at 12:51:50PM -0500, Bill Schmidt wrote:
> +/* Define if your assembler supports FUTURE instructions.  */
> +#ifndef USED_FOR_TARGET
> +#undef HAVE_AS_FUTURE
> +#endif

Let's not use that?  I removed HAVE_AS_* (for ISA version support) in
r264675:

"""
rs6000: Delete many HAVE_AS_* (PR87149)

This deletes most HAVE_AS_* that determine if the assembler supports
some ISA level (and also HAVE_AS_MFPGPR and HAVE_AS_DFP).

These are not useful: we will only generate an instruction that requires
some newer ISA if the user specifically asked for it (with -mcpu=, say).
If the assembler cannot handle that, it is fine if it gives an error.

They also hurt: it increases the number of possible situations that all
need handling and all need testing.  We do not handle all cases, and
obviously do not test all either.
"""

So, just generate FUTURE insns when the user asked for that, don't worry
about checking if the assembler can handle that -- the user will find out
soon enough if not, and on any normal install everything will work fine.

>  /* Flags that need to be turned off if -mno-power9-vector.  */
>  #define OTHER_P9_VECTOR_MASKS(OPTION_MASK_FLOAT128_HW
> \
> +  | OPTION_MASK_FUTURE   \
>| OPTION_MASK_P9_MINMAX)

Why this?

> @@ -134,7 +139,8 @@
>| OPTION_MASK_RECIP_PRECISION  \
>| OPTION_MASK_SOFT_FLOAT   \
>| OPTION_MASK_STRICT_ALIGN_OPTIONAL\
> -  | OPTION_MASK_VSX)
> +  | OPTION_MASK_VSX  \
> +  | OPTION_MASK_FUTURE)

This list is alphabetic.  Well, was alphabetic :-)

> -RS6000_CPU ("powerpc64le", PROCESSOR_POWER8, MASK_POWERPC64 | 
> ISA_2_7_MASKS_SERVER)
> +RS6000_CPU ("powerpc64le", PROCESSOR_POWER8, MASK_POWERPC64
> + | ISA_2_7_MASKS_SERVER)

Please don't reformat mixed with other (non-random) changes.

> -@samp{power9}, @samp{powerpc}, @samp{powerpc64}, @samp{powerpc64le},
> -@samp{rs64}, and @samp{native}.
> +@samp{power9}, @samp{future}, @samp{powerpc}, @samp{powerpc64},
> +@samp{powerpc64le}, @samp{rs64}, and @samp{native}.

Maybe *not* documenting this would be less confusing?

> diff --git a/gcc/testsuite/gcc.target/powerpc/cpu-future.c 
> b/gcc/testsuite/gcc.target/powerpc/cpu-future.c
> new file mode 100644
> index 000..b62d40341d1
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/cpu-future.c
> @@ -0,0 +1,7 @@
> +/* { dg-do compile } */
> +/* { dg-options "-mcpu=future -O2" } */
> +/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
> "-mcpu=future" } } */

Drop this last line, use -mdejagnu-cpu=future instead?


Segher

[PATCH, X86] Disable mfentry for Darwin and amend testing.

[Iain Sandoe]

Although this is a Darwin-specific change, I need to touch
target-supports.exp and several tests in i386.exp.

tested on x86_64-darwin and x86_64-linux-gnu
doc change tested with “make pdf”,

OK for trunk?
backports? (where the tests fail).

gcc/

* config/i386/darwin.h: Reject -mfentry*.
* doc/sourcebuild.texi: Document mfentry target support.

gcc/testsuite/

* lib/target-supports.exp (check_effective_target_mfentry): New.
* gcc.target/i386/fentry-override.c: Require effective target mfentry,
* gcc/testsuite/gcc.target/i386/fentry.c: Likewise
* gcc.target/i386/fentryname1.c: Likewise
* gcc.target/i386/fentryname2.c: Likewise
* gcc.target/i386/fentryname3.c: Likewise
* gcc.target/i386/nop-mcount.c: Likewise
* gcc.target/i386/pr82699-2.c: Likewise
* gcc.target/i386/pr82699-4.c: Likewise
* gcc.target/i386/pr82699-5.c: Likewise
* gcc.target/i386/pr82699-6.c: Likewise
* gcc.target/i386/returninst1.c: Likewise
* gcc.target/i386/returninst2.c: Likewise
* gcc.target/i386/returninst3.c : Likewise

diff --git a/gcc/config/i386/darwin.h b/gcc/config/i386/darwin.h
index fe11ec9..1128428 100644
--- a/gcc/config/i386/darwin.h
+++ b/gcc/config/i386/darwin.h
@@ -132,7 +132,8 @@ extern int darwin_emit_branch_islands;
 #define CC1_SPEC "%(cc1_cpu) \
   %{!mkernel:%{!static:%{!mdynamic-no-pic:-fPIC}}} \
   %{g: %{!fno-eliminate-unused-debug-symbols: -feliminate-unused-debug-symbols 
}} \
-  %{mx32:%eDarwin is not an mx32 platform}" \
+  %{mx32:%eDarwin is not an mx32 platform} \
+  %{mfentry*:%eDarwin does not support -mfentry or associated options}" \
   DARWIN_CC1_SPEC
 
 #undef ASM_SPEC
diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index cf12d74..546af7f 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -2382,6 +2382,10 @@ Target supports compiling @code{aes} instructions.
 @item fma4
 Target supports compiling @code{fma4} instructions.
 
+@item mfentry
+Target supports the @code{-mfentry} option that alters the
+position of profiling calls such that they precede the prologue.
+
 @item ms_hook_prologue
 Target supports attribute @code{ms_hook_prologue}.
 
diff --git a/gcc/testsuite/gcc.target/i386/fentry-override.c 
b/gcc/testsuite/gcc.target/i386/fentry-override.c
index 7bc5fc4..efba1bf 100644
--- a/gcc/testsuite/gcc.target/i386/fentry-override.c
+++ b/gcc/testsuite/gcc.target/i386/fentry-override.c
@@ -1,5 +1,6 @@
 /* Test -mfentry override */
 /* { dg-do compile { target { *-*-linux* && { ! ia32 } } } } */
+/* { dg-require-effective-target mfentry } */
 /* { dg-options "-mfentry" } */
 /* { dg-final { scan-assembler-not "__fentry__" } } */
 /* Origin: Andi Kleen */
diff --git a/gcc/testsuite/gcc.target/i386/fentry.c 
b/gcc/testsuite/gcc.target/i386/fentry.c
index 2449e75..28edd10 100644
--- a/gcc/testsuite/gcc.target/i386/fentry.c
+++ b/gcc/testsuite/gcc.target/i386/fentry.c
@@ -1,5 +1,6 @@
 /* Test -mfentry */
 /* { dg-do compile { target { *-*-linux* && { ! ia32 } } } } */
+/* { dg-require-effective-target mfentry } */
 /* { dg-options "-fprofile -mfentry" } */
 /* { dg-final { scan-assembler "__fentry__" } } */
 /* Origin: Andi Kleen */
diff --git a/gcc/testsuite/gcc.target/i386/fentryname1.c 
b/gcc/testsuite/gcc.target/i386/fentryname1.c
index 6d2e76d..1265342 100644
--- a/gcc/testsuite/gcc.target/i386/fentryname1.c
+++ b/gcc/testsuite/gcc.target/i386/fentryname1.c
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-require-effective-target mfentry } */
 /* { dg-options "-pg -mfentry -mfentry-name=foo" } */
 /* { dg-final { scan-assembler "call.*foo" } } */
 /* { dg-final { scan-assembler "call.*bar" } } */
diff --git a/gcc/testsuite/gcc.target/i386/fentryname2.c 
b/gcc/testsuite/gcc.target/i386/fentryname2.c
index 7d102bf..c51c5d1 100644
--- a/gcc/testsuite/gcc.target/i386/fentryname2.c
+++ b/gcc/testsuite/gcc.target/i386/fentryname2.c
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-require-effective-target mfentry } */
 /* { dg-options "-pg -mfentry -mrecord-mcount -mfentry-section=foo" } */
 /* { dg-final { scan-assembler "section.*foo" } } */
 /* { dg-final { scan-assembler "section.*bar" } } */
diff --git a/gcc/testsuite/gcc.target/i386/fentryname3.c 
b/gcc/testsuite/gcc.target/i386/fentryname3.c
index 777f4e4..5688109 100644
--- a/gcc/testsuite/gcc.target/i386/fentryname3.c
+++ b/gcc/testsuite/gcc.target/i386/fentryname3.c
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-require-effective-target mfentry } */
 /* { dg-options "-pg -mfentry"  } */
 /* { dg-final { scan-assembler "section.*__entry_loc" } } */
 /* { dg-final { scan-assembler "0x0f, 0x1f, 0x44, 0x00, 0x00" } } */
diff --git a/gcc/testsuite/gcc.target/i386/nop-mcount.c 
b/gcc/testsuite/gcc.target/i386/nop-mcount.c
index a8e14bc..a5f8d27 100644
--- a/gcc/testsuite/gcc.target/i386/nop-mcount.c
+++ b/gcc/testsuite/gcc.target/i386/nop-mcount.c
@@ -1,5 +1,6 @@
 /* Test -mnop-mcount */

[PATCH] rs6000: Entry point generation for functions using PC-relative addressing

[Bill Schmidt]

Hi,

Functions using PC-relative addressing do not use a TOC, so there is no need for
a global entry point for TOC setup.  Ensure we never generate a global entry
point, and use a .localentry directive that sets the upper st_other bits to 1.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no regressions.
Is this okay for trunk?

Thanks,
Bill


[gcc]

2019-05-22  Bill Schmidt  

* config/rs6000/rs6000.c (rs6000_global_entry_point_needed_p):
Return false for PC-relative functions.
(rs6000_output_function_prologue): Emit ".localentry name,1" for
PC-relative functions.

[gcc/testsuite]

2019-05-22  Bill Schmidt  

* gcc.target/powerpc/localentry-1.c: New file.


diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 959e222c9cb..23c6d37ab55 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -26191,6 +26191,10 @@ rs6000_global_entry_point_needed_p (void)
   if (TARGET_SINGLE_PIC_BASE)
 return false;
 
+  /* PC-relative functions never generate a global entry point prologue.  */
+  if (rs6000_pcrel_p (cfun))
+return false;
+
   /* Ensure we have a global entry point for thunks.   ??? We could
  avoid that if the target routine doesn't need a global entry point,
  but we do not know whether this is the case at this point.  */
@@ -27545,12 +27549,12 @@ rs6000_output_function_prologue (FILE *file)
 #endif
 }
 
+  const char *name = XSTR (XEXP (DECL_RTL (current_function_decl), 0), 0);
+
   /* ELFv2 ABI r2 setup code and local entry point.  This must follow
  immediately after the global entry point label.  */
   if (rs6000_global_entry_point_needed_p ())
 {
-  const char *name = XSTR (XEXP (DECL_RTL (current_function_decl), 0), 0);
-
   (*targetm.asm_out.internal_label) (file, "LCF", rs6000_pic_labelno);
 
   if (TARGET_CMODEL != CMODEL_LARGE)
@@ -27601,6 +27605,18 @@ rs6000_output_function_prologue (FILE *file)
   fputs ("\n", file);
 }
 
+  else if (rs6000_pcrel_p (cfun))
+{
+  /* All functions compiled to use PC-relative addressing will
+have a .localentry value of 0 or 1.  For now we set it to
+1 all the time, indicating that the function may clobber
+the TOC register r2.  Later we may optimize this by setting
+it to 0 if the function is a leaf and does not clobber r2.  */
+  fputs ("\t.localentry\t", file);
+  assemble_name (file, name);
+  fputs (",1\n", file);
+}
+
   /* Output -mprofile-kernel code.  This needs to be done here instead of
  in output_function_profile since it must go after the ELFv2 ABI
  local entry point.  */
diff --git a/gcc/testsuite/gcc.target/powerpc/localentry-1.c 
b/gcc/testsuite/gcc.target/powerpc/localentry-1.c
new file mode 100644
index 000..15e00d9917e
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/localentry-1.c
@@ -0,0 +1,19 @@
+/* { dg-do compile } */
+/* { dg-options "-mcpu=future -O2" } */
+/* { dg-require-effective-target powerpc_elfv2 } */
+/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=future" } } */
+
+/* Ensure we generate ".localentry fn,1" for both leaf and non-leaf
+   functions.  */
+
+extern int y (int);
+
+int x (void)
+{
+  return y (5);
+}
+
+void z (void) { };
+
+/* { dg-final { scan-assembler {\.localentry\t\mx,1\M} } } */
+/* { dg-final { scan-assembler {\.localentry\t\mz,1\M} } } */

Re: [PATCH] rs6000: Infrastructure for future arch

[Bill Schmidt]

On 5/22/19 6:05 PM, Segher Boessenkool wrote:
> Hi Bill,
>
> On Wed, May 22, 2019 at 12:51:50PM -0500, Bill Schmidt wrote:
>> +/* Define if your assembler supports FUTURE instructions.  */
>> +#ifndef USED_FOR_TARGET
>> +#undef HAVE_AS_FUTURE
>> +#endif
> Let's not use that?  I removed HAVE_AS_* (for ISA version support) in
> r264675:
Yep, agreed.  This was refactored from old patches prior to that.
>
> """
> rs6000: Delete many HAVE_AS_* (PR87149)
>
> This deletes most HAVE_AS_* that determine if the assembler supports
> some ISA level (and also HAVE_AS_MFPGPR and HAVE_AS_DFP).
>
> These are not useful: we will only generate an instruction that requires
> some newer ISA if the user specifically asked for it (with -mcpu=, say).
> If the assembler cannot handle that, it is fine if it gives an error.
>
> They also hurt: it increases the number of possible situations that all
> need handling and all need testing.  We do not handle all cases, and
> obviously do not test all either.
> """
>
> So, just generate FUTURE insns when the user asked for that, don't worry
> about checking if the assembler can handle that -- the user will find out
> soon enough if not, and on any normal install everything will work fine.
>
>>  /* Flags that need to be turned off if -mno-power9-vector.  */
>>  #define OTHER_P9_VECTOR_MASKS   (OPTION_MASK_FLOAT128_HW
>> \
>> + | OPTION_MASK_FUTURE   \
>>   | OPTION_MASK_P9_MINMAX)
> Why this?
I agree that this seems wrong.  Will remove.
>
>> @@ -134,7 +139,8 @@
>>   | OPTION_MASK_RECIP_PRECISION  \
>>   | OPTION_MASK_SOFT_FLOAT   \
>>   | OPTION_MASK_STRICT_ALIGN_OPTIONAL\
>> - | OPTION_MASK_VSX)
>> + | OPTION_MASK_VSX  \
>> + | OPTION_MASK_FUTURE)
> This list is alphabetic.  Well, was alphabetic :-)
OK.
>
>> -RS6000_CPU ("powerpc64le", PROCESSOR_POWER8, MASK_POWERPC64 | 
>> ISA_2_7_MASKS_SERVER)
>> +RS6000_CPU ("powerpc64le", PROCESSOR_POWER8, MASK_POWERPC64
>> +| ISA_2_7_MASKS_SERVER)
> Please don't reformat mixed with other (non-random) changes.
OK.
>
>> -@samp{power9}, @samp{powerpc}, @samp{powerpc64}, @samp{powerpc64le},
>> -@samp{rs64}, and @samp{native}.
>> +@samp{power9}, @samp{future}, @samp{powerpc}, @samp{powerpc64},
>> +@samp{powerpc64le}, @samp{rs64}, and @samp{native}.
> Maybe *not* documenting this would be less confusing?
Well, this was refactored from your patch. ;-)

I disagree, simply because at some point this will be renamed, and
having the place-holder will ensure we don't forget to add the new
name.  So I'd like to keep this.
>
>> diff --git a/gcc/testsuite/gcc.target/powerpc/cpu-future.c 
>> b/gcc/testsuite/gcc.target/powerpc/cpu-future.c
>> new file mode 100644
>> index 000..b62d40341d1
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/powerpc/cpu-future.c
>> @@ -0,0 +1,7 @@
>> +/* { dg-do compile } */
>> +/* { dg-options "-mcpu=future -O2" } */
>> +/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
>> "-mcpu=future" } } */
> Drop this last line, use -mdejagnu-cpu=future instead?
OK.

Thanks for the quick review!
Bill
>
>
> Segher
>

[committed] Bulletproof -fdiagnostics-format=json against bad locations (PR c++/90462)

[David Malcolm]

PR c++/90462 reports an ICE with -fdiagnostics-format=json when
attempting to serialize a malformed location to JSON.

The compound location_t in question has meaningful "caret" and "start"
locations, but has UNKNOWN_LOCATION for its "finish" location,
leading to a NULL pointer dereference when attempting to build a JSON
string for the filename.

This patch bulletproofs the JSON output so that attempts to write
a JSON object for a location with a NULL file will lead to an object
with no "file" key, and attempts to write a compound location with
UNKNOWN_LOCATION for its start or finish will lead to the corresponding
JSON child object being omitted.

This patch also adds a json::object::get member function, for self-testing
the above.

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

Committed to trunk as r271535.

gcc/ChangeLog:
PR c++/90462
* diagnostic-format-json.cc: Include "selftest.h".
(json_from_expanded_location): Only add "file" key for non-NULL
file strings.
(json_from_location_range): Don't add "start" and "finish"
children if they are UNKNOWN_LOCATION.
(selftest::test_unknown_location): New selftest.
(selftest::test_bad_endpoints): New selftest.
(selftest::diagnostic_format_json_cc_tests): New function.
* json.cc (json::object::get): New function.
(selftest::test_object_get): New selftest.
(selftest::json_cc_tests): Call it.
* json.h (json::object::get): New decl.
* selftest-run-tests.c (selftest::run_tests): Call
selftest::diagnostic_format_json_cc_tests.
* selftest.h (selftest::diagnostic_format_json_cc_tests): New
decl.

gcc/testsuite/ChangeLog:
PR c++/90462
* g++.dg/pr90462.C: New test.
---
 gcc/diagnostic-format-json.cc  | 60 +++---
 gcc/json.cc| 29 
 gcc/json.h |  1 +
 gcc/selftest-run-tests.c   |  1 +
 gcc/selftest.h |  1 +
 gcc/testsuite/g++.dg/pr90462.C | 49 ++
 6 files changed, 138 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/pr90462.C

diff --git a/gcc/diagnostic-format-json.cc b/gcc/diagnostic-format-json.cc
index 0355210..53c3b63 100644
--- a/gcc/diagnostic-format-json.cc
+++ b/gcc/diagnostic-format-json.cc
@@ -24,6 +24,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "coretypes.h"
 #include "diagnostic.h"
 #include "json.h"
+#include "selftest.h"
 
 /* The top-level JSON array of pending diagnostics.  */
 
@@ -45,7 +46,8 @@ json_from_expanded_location (location_t loc)
 {
   expanded_location exploc = expand_location (loc);
   json::object *result = new json::object ();
-  result->set ("file", new json::string (exploc.file));
+  if (exploc.file)
+result->set ("file", new json::string (exploc.file));
   result->set ("line", new json::number (exploc.line));
   result->set ("column", new json::number (exploc.column));
   return result;
@@ -66,9 +68,11 @@ json_from_location_range (const location_range *loc_range, 
unsigned range_idx)
 
   json::object *result = new json::object ();
   result->set ("caret", json_from_expanded_location (caret_loc));
-  if (start_loc != caret_loc)
+  if (start_loc != caret_loc
+  && start_loc != UNKNOWN_LOCATION)
 result->set ("start", json_from_expanded_location (start_loc));
-  if (finish_loc != caret_loc)
+  if (finish_loc != caret_loc
+  && finish_loc != UNKNOWN_LOCATION)
 result->set ("finish", json_from_expanded_location (finish_loc));
 
   if (loc_range->m_label)
@@ -262,3 +266,53 @@ diagnostic_output_format_init (diagnostic_context *context,
   break;
 }
 }
+
+#if CHECKING_P
+
+namespace selftest {
+
+/* We shouldn't call json_from_expanded_location on UNKNOWN_LOCATION,
+   but verify that we handle this gracefully.  */
+
+static void
+test_unknown_location ()
+{
+  delete json_from_expanded_location (UNKNOWN_LOCATION);
+}
+
+/* Verify that we gracefully handle attempts to serialize bad
+   compound locations.  */
+
+static void
+test_bad_endpoints ()
+{
+  location_t bad_endpoints
+= make_location (BUILTINS_LOCATION,
+UNKNOWN_LOCATION, UNKNOWN_LOCATION);
+
+  location_range loc_range;
+  loc_range.m_loc = bad_endpoints;
+  loc_range.m_range_display_kind = SHOW_RANGE_WITH_CARET;
+  loc_range.m_label = NULL;
+
+  json::object *obj = json_from_location_range (&loc_range, 0);
+  /* We should have a "caret" value, but no "start" or "finish" values.  */
+  ASSERT_TRUE (obj != NULL);
+  ASSERT_TRUE (obj->get ("caret") != NULL);
+  ASSERT_TRUE (obj->get ("start") == NULL);
+  ASSERT_TRUE (obj->get ("finish") == NULL);
+  delete obj;
+}
+
+/* Run all of the selftests within this file.  */
+
+void
+diagnostic_format_json_cc_tests ()
+{
+  test_unknown_location ();
+  test_bad_endpoints ();
+}
+
+} // namespace selftest
+
+#endif /* #if CHECKING_P */
diff 

Re: [gofrontend-dev] Re: Go patch committed: Intrinsify runtime/internal/atomic functions

[Cherry Zhang via gcc-patches]

Jim, thank you for the fix! The patch looks good to me. Maybe we should
also apply this to __atomic_add_fetch_4 and __atomic_add_fetch_8?

Thanks,
Cherry



On Tue, May 21, 2019 at 11:25 PM Jim Wilson  wrote:

> On Sun, May 19, 2019 at 5:22 AM Andreas Schwab 
> wrote:
> > ../../../libgo/go/runtime/mbitmap.go: In function
> ‘runtime.setMarked.runtime.markBits’:
> > ../../../libgo/go/runtime/mbitmap.go:291:9: internal compiler error:
> Segmentation fault
> >   291 |  atomic.Or8(m.bytep, m.mask)
> >   | ^
>
> This is failing for RISC-V because __atomic_or_fetch_1 isn't a
> built-in function that can be expanded inline.  You have to call the
> library function in libatomic.  The C front-end is registering all of
> the built-in functions, but it looks like the go front-end is only
> registering functions it thinks it needs and this list is incomplete.
> In expand_builtin, case BUILT_IN_ATOMIC_OR_FETCH_1, the external
> library call for this gets set to BUILT_IN_ATOMIC_FETCH_OR_1.  Then in
> expand_builtin_atomic_fetch_op when we call builtin_decl_explicit
> (ext_call) it returns NULL.  This is because the go front end
> registered BUILT_IN_ATOMIC_OR_FETCH_1 as a built-in, but did not
> register BUILT_IN_ATOMIC_FETCH_OR_1 as a built-in.  The NULL return
> from builtin_decl_explicit gives us an ADDR_EXPR with a NULL operand
> which eventually causes the internal compiler error.  It looks like
> the same thing is done with all of the op_fetch built-ins, so use of
> any of them means that the fetch_op built-in also has to be
> registered.  I verified with a quick hack that I need both
> BUILT_IN_ATOMIC_FETCH_OR_1 and BUILT_IN_ATOMIC_FETCH_AND_1 defined as
> built-ins to make a RISC-V go build work.  I haven't done any testing
> yet.
>
> Jim
>
> --
> You received this message because you are subscribed to the Google Groups
> "gofrontend-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to gofrontend-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/gofrontend-dev/CAFyWVaY8aMmhmnWpoGdywaeEhiXmSUe8qqha%2BHhvbxYHhUnisQ%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

Re: [gofrontend-dev] Re: Go patch committed: Intrinsify runtime/internal/atomic functions

[Ian Lance Taylor]

On Wed, May 22, 2019 at 9:36 PM Cherry Zhang  wrote:
>
> Jim, thank you for the fix! The patch looks good to me. Maybe we should also 
> apply this to __atomic_add_fetch_4 and __atomic_add_fetch_8?
>
> Thanks,
> Cherry
>
>
>
> On Tue, May 21, 2019 at 11:25 PM Jim Wilson  wrote:
>>
>> On Sun, May 19, 2019 at 5:22 AM Andreas Schwab  wrote:
>> > ../../../libgo/go/runtime/mbitmap.go: In function 
>> > ‘runtime.setMarked.runtime.markBits’:
>> > ../../../libgo/go/runtime/mbitmap.go:291:9: internal compiler error: 
>> > Segmentation fault
>> >   291 |  atomic.Or8(m.bytep, m.mask)
>> >   | ^
>>
>> This is failing for RISC-V because __atomic_or_fetch_1 isn't a
>> built-in function that can be expanded inline.  You have to call the
>> library function in libatomic.  The C front-end is registering all of
>> the built-in functions, but it looks like the go front-end is only
>> registering functions it thinks it needs and this list is incomplete.
>> In expand_builtin, case BUILT_IN_ATOMIC_OR_FETCH_1, the external
>> library call for this gets set to BUILT_IN_ATOMIC_FETCH_OR_1.  Then in
>> expand_builtin_atomic_fetch_op when we call builtin_decl_explicit
>> (ext_call) it returns NULL.  This is because the go front end
>> registered BUILT_IN_ATOMIC_OR_FETCH_1 as a built-in, but did not
>> register BUILT_IN_ATOMIC_FETCH_OR_1 as a built-in.  The NULL return
>> from builtin_decl_explicit gives us an ADDR_EXPR with a NULL operand
>> which eventually causes the internal compiler error.  It looks like
>> the same thing is done with all of the op_fetch built-ins, so use of
>> any of them means that the fetch_op built-in also has to be
>> registered.  I verified with a quick hack that I need both
>> BUILT_IN_ATOMIC_FETCH_OR_1 and BUILT_IN_ATOMIC_FETCH_AND_1 defined as
>> built-ins to make a RISC-V go build work.  I haven't done any testing
>> yet.

Jim, you can go ahead and commit that patch with a ChangeLog entry.
(The files in go/gcc but not in go/gcc/gofrontend) are under normal
GCC rules.)  Thanks.

Ian

Re: [PATCH] rs6000: Infrastructure for future arch

[Alan Modra]

On Wed, May 22, 2019 at 12:51:50PM -0500, Bill Schmidt wrote:
>   * config/rs6000/rs6000.c (rs6000_option_override_internal): Treat
>   PROCESSOR_FUTURE similarly to PROCESSOR_POWER9 for now.
>   (rs6000_machine_from_flags): Handle future cpu.
>   (rs6000_reassociation_width): Treat PROCESSOR_FUTURE like
>   PROCESSOR_POWER9 for now.
>   (rs6000_adjust_cost): Likewise.
>   (rs6000_issue_rate): Likewise.

rs6000_register_move_cost needs similar tweaks.

-- 
Alan Modra
Australia Development Lab, IBM

Fixed: "required ftruncate or chsize support not present" in gfortran testsuite

[Hans-Peter Nilsson]

There was a regression for gfortran.dg/fmt_en.f90 for cris-elf
that on inspection was due to it having acquired a truncation
call through the runtime.  I updated that and the new tests that
had "Fortran runtime error: required ftruncate or chsize support
not present" messages in gfortran.log, ran past cris-elf and
committed as obvious.  See also
 from
which I copy-pasted most of this message.  (Yep, 11 years ago.)

gcc/testsuite:
* gfortran.dg/dec_io_1.f90, gfortran.dg/dtio_1.f90,
gfortran.dg/dtio_12.f90, gfortran.dg/fmt_en.f90,
gfortran.dg/namelist_89.f90: Gate test on effective_target
fd_truncate.

diff --git gcc/testsuite/gfortran.dg/dec_io_1.f90 
gcc/testsuite/gfortran.dg/dec_io_1.f90
index 2edc427..58daf30 100644
--- gcc/testsuite/gfortran.dg/dec_io_1.f90
+++ gcc/testsuite/gfortran.dg/dec_io_1.f90
@@ -1,4 +1,4 @@
-! { dg-do run }
+! { dg-do run { target fd_truncate } }
 ! { dg-options "-fdec" }
 !
 ! Run-time tests for values of DEC I/O parameters (doesn't test functionality).
diff --git gcc/testsuite/gfortran.dg/dtio_1.f90 
gcc/testsuite/gfortran.dg/dtio_1.f90
index c6f17d9..b168d30 100644
--- gcc/testsuite/gfortran.dg/dtio_1.f90
+++ gcc/testsuite/gfortran.dg/dtio_1.f90
@@ -1,4 +1,4 @@
-! { dg-do run  }
+! { dg-do run { target fd_truncate } }
 !
 ! Functional test of User Defined Derived Type IO, Formatted WRITE/READ
 !
diff --git gcc/testsuite/gfortran.dg/dtio_12.f90 
gcc/testsuite/gfortran.dg/dtio_12.f90
index 54b10cb..ac6d9e7 100644
--- gcc/testsuite/gfortran.dg/dtio_12.f90
+++ gcc/testsuite/gfortran.dg/dtio_12.f90
@@ -1,4 +1,4 @@
-! { dg-do run }
+! { dg-do run { target fd_truncate } }
 !
 ! Test the fix for PR77657 in which the DTIO subroutine was not found,
 ! which led to an error in attempting to link to the abstract interface.
diff --git gcc/testsuite/gfortran.dg/fmt_en.f90 
gcc/testsuite/gfortran.dg/fmt_en.f90
index b3597e4..89011b3 100644
--- gcc/testsuite/gfortran.dg/fmt_en.f90
+++ gcc/testsuite/gfortran.dg/fmt_en.f90
@@ -1,4 +1,4 @@
-! { dg-do run }
+! { dg-do run { target fd_truncate } }
 ! PR60128 Invalid outputs with EN descriptors
 ! Test case provided by Walt Brainerd.
 program pr60128
diff --git gcc/testsuite/gfortran.dg/namelist_89.f90 
gcc/testsuite/gfortran.dg/namelist_89.f90
index fbb7143..91f64fe 100644
--- gcc/testsuite/gfortran.dg/namelist_89.f90
+++ gcc/testsuite/gfortran.dg/namelist_89.f90
@@ -1,4 +1,4 @@
-! { dg-do run }
+! { dg-do run { target fd_truncate } }
 ! PR69456 Namelist value with trailing sign is ignored without error
 implicit none
 integer :: ios

brgds, H-P

Re: [PATCH] rs6000: Infrastructure for future arch

[Bill Schmidt]

On 5/22/19 8:54 PM, Alan Modra wrote:
> On Wed, May 22, 2019 at 12:51:50PM -0500, Bill Schmidt wrote:
>>  * config/rs6000/rs6000.c (rs6000_option_override_internal): Treat
>>  PROCESSOR_FUTURE similarly to PROCESSOR_POWER9 for now.
>>  (rs6000_machine_from_flags): Handle future cpu.
>>  (rs6000_reassociation_width): Treat PROCESSOR_FUTURE like
>>  PROCESSOR_POWER9 for now.
>>  (rs6000_adjust_cost): Likewise.
>>  (rs6000_issue_rate): Likewise.
> rs6000_register_move_cost needs similar tweaks.
>
Does it?  I don't believe the slow LR/CTR move applies.  However, the cost
for direct moves probably should be treated the same as POWER9, I think...
I will plan to make that change.

Thanks!
Bill

[PATCH] AARCH64: ILP32: Fix aarch64_asan_shadow_offset

[Andrew Pinski]

aarch64_asan_shadow_offset is using the wrong
offset for ILP32.  Change it to be a decent one.

OK?  Bootstrapped and tested on aarch64-linux-gnu
with no regressions,

Thanks,
Andrew Pinski

ChangeLog:
* config/aarch64/aarch64.c (aarch64_asan_shadow_offset):
Fix ILP32 value.
---
 gcc/config/aarch64/aarch64.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 3d872438..e5fefe93 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -17258,7 +17258,10 @@ aarch64_expand_subvti (rtx op0, rtx low_dest, rtx 
low_in1,
 static unsigned HOST_WIDE_INT
 aarch64_asan_shadow_offset (void)
 {
-  return (HOST_WIDE_INT_1 << 36);
+  if (TARGET_ILP32)
+return (HOST_WIDE_INT_1 << 29);
+  else
+return (HOST_WIDE_INT_1 << 36);
 }
 
 static rtx
-- 
1.8.3.1

Re: libbacktrace integration for _GLIBCXX_DEBUG mode

[François Dumont]

Hi

    So here what I come up with.

    _GLIBCXX_DEBUG_BACKTRACE controls the feature. If the user define 
it and there is a detectable issue with libbacktrace then I generate a 
compilation error. I want to avoid users defining it but having no 
backtrace in the end in the debug assertion.


    With this new setup I manage to run testsuite with it like that:

export LD_LIBRARY_PATH=/home/fdt/dev/gcc/install/lib/
make CXXFLAGS='-D_GLIBCXX_DEBUG_BACKTRACE 
-I/home/fdt/dev/gcc/install/include -lbacktrace' check-debug


    An example of result:

/home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/vector:606:
In function:
    std::__debug::vector<_Tp, _Allocator>::iterator
    std::__debug::vector<_Tp, 
_Allocator>::insert(std::__debug::vector<_Tp,

    _Allocator>::const_iterator, _InputIterator, _InputIterator) [with
    _InputIterator = int*;  = void; _Tp = int;
    _Allocator = std::allocator; std::__debug::vector<_Tp,
    _Allocator>::iterator =
__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator >, std::__debug::vector,
    std::random_access_iterator_tag>; typename 
std::iterator_traits
    std::vector<_Tp, _Alloc>::iterator>::iterator_category =
    std::random_access_iterator_tag; typename std::vector<_Tp,
    _Alloc>::iterator = __gnu_cxx::__normal_iteratorstd::vector

    >; std::__debug::vector<_Tp, _Allocator>::const_iterator =
__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator >, std::__debug::vector,
    std::random_access_iterator_tag>; typename 
std::iterator_traits
    std::vector<_Tp, _Alloc>::const_iterator>::iterator_category =
    std::random_access_iterator_tag; typename std::vector<_Tp,
    _Alloc>::const_iterator = __gnu_cxx::__normal_iteratorstd::

    vector >]

Backtrace:
    0x402718 
__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iteratorstd::vector >> std::__debug::vector::insertvoid>(__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iteratorconst*, std::vector >>, int*, int*)

/home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/vector:606
    0x402718 test01()
/home/fdt/dev/gcc/git/libstdc++-v3/testsuite/23_containers/vector/debug/57779_neg.cc:29
    0x401428 main
/home/fdt/dev/gcc/git/libstdc++-v3/testsuite/23_containers/vector/debug/57779_neg.cc:34

Error: attempt to insert with an iterator range [__first, __last) from this
container.

Objects involved in the operation:
    iterator "__first" @ 0x0x7fff730b96b0 {
  type = int* (mutable iterator);
    }
    iterator "__last" @ 0x0x7fff730b96b8 {
  type = int* (mutable iterator);
    }
    sequence "this" @ 0x0x7fff730b9720 {
  type = std::__debug::vector;
    }
XFAIL: 23_containers/vector/debug/57779_neg.cc execution test


    * include/debug/formatter.h [_GLIBCXX_DEBUG_BACKTRACE]: Include
     and .
    [!_GLIBCXX_DEBUG_BACKTRACE]: Include .
    [!_GLIBCXX_DEBUG_BACKTRACE](backtrace_error_callback): New.
    [!_GLIBCXX_DEBUG_BACKTRACE](backtrace_full_callback): New.
    [!_GLIBCXX_DEBUG_BACKTRACE](struct backtrace_state): New declaration.
    (_Error_formatter::_Bt_full_t): New function pointer type.
    (_Error_formatter::_M_print_backtrace): New.
    (_Error_formatter::_M_backtrace_state): New.
    (_Error_formatter::_M_backtrace_full_func): New.
    * src/c++11/debug.cc: Include  and .
    (PrintContext::_M_demangle_name): New.
    (_Print_func_t): New.
    (print_word(PrintContext&, const char*)): New.
    (print_raw(PrintContext&, const char*)): New.
    (print_function(PrintContext&, const char*, _Print_func_t)): New.
    (print_type): Use latter.
    (print_string(PrintContext&, const char*)): New.
    (print_backtrace(void*, uintptr_t, const char*, int, const char*)):
    New.
    (_Error_formatter::_M_error()): Adapt.
    * doc/xml/manual/debug_mode.xml: Document _GLIBCXX_DEBUG_BACKTRACE.

Tested under Linux x86_64.

Ok to commit ?

François


On 12/21/18 10:03 PM, Jonathan Wakely wrote:

On 21/12/18 22:47 +0200, Ville Voutilainen wrote:
On Fri, 21 Dec 2018 at 22:35, Jonathan Wakely  
wrote:

>    I also explcitely define BACKTRACE_SUPPORTED to 0 to make sure
>libstdc++ has no libbacktrace dependency after usual build.



I'm concerned about the requirement to link to libbacktrace
explicitly (which will break existing makefiles and build systems that
currently use debug mode in testing).


But see what Francois wrote, "I also explcitely define
BACKTRACE_SUPPORTED to 0 to make sure
libstdc++ has no libbacktrace dependency after usual build."


Yes, but if you happen to install libbacktrace headers, the behaviour
for users building their own code changes. I agree that if you install
those headers, it's probably for a reason, but it might be a different
reason to "so that libstdc++ prints better backtraces".


Also, some of the glibc team pointed out to me that running *any*
extra code after undefined behaviour has been detected is a potential
risk. The less that you do between detecting UB and calling abort(),
the better. Giving the users more information

PING*2: Re: abstract out EH propagation cleanups

[Aldy Hernandez]

PING*2

On 5/15/19 12:36 PM, Aldy Hernandez wrote:

Sorry, I meant to PING this one.

Aldy

On Wed, May 8, 2019 at 5:08 PM Aldy Hernandez  wrote:


On 5/8/19 2:30 AM, Richard Biener wrote:

On Tue, May 7, 2019 at 11:55 PM Jeff Law  wrote:


On 5/7/19 3:45 AM, Richard Biener wrote:

On Tue, May 7, 2019 at 11:13 AM Aldy Hernandez  wrote:


Hi.

We seem to have numerous copies of the same EH propagation cleanups
scattered throughout the compiler.  The attached patch moves all the
logic into one class that allows for easy marking of statements and
automatic cleanup once it goes out of scope.

Tested on x86-64 Linux.

OK for trunk? (*)


Ugh :/

First of all I don't like the fact that the actual cleanup is done
upon constructor execution.  Please make it explicit
and in the constructor assert that nothing is to be done.

I'm of a mixed mind here.  I have railed against implicit code being run
behind my back for decades.

However as I've had to debug locking issues and the like in other C++
codebases I've become more and more of a fan of RAII and its basic
concepts.  This has made me more open to code running behind my back
like this implicitly when the object gets destroyed.

There's something to be said for embedding this little class into other
objects like Aldy has done and just letting things clean up
automatically as the object goes out of scope.  No more missing calls to
run the cleanup bits, it "just works".

But I won't object if you want it to be more explicit.  I've been there
and understand why one might want the cleanup step to be explicit.





Then I'm not sure this is a 1:1 transform since for example

@@ -1061,8 +1173,6 @@
substitute_and_fold_dom_walker::before_dom_children (basic_block bb)
  }

 gimple *old_stmt = stmt;
-  bool was_noreturn = (is_gimple_call (stmt)
-  && gimple_call_noreturn_p (stmt));

 /* Replace real uses in the statement.  */
 did_replace |= substitute_and_fold_engine->replace_uses_in (stmt);
@@ -1110,25 +1220,7 @@
substitute_and_fold_dom_walker::before_dom_children (basic_block bb)
 /* Now cleanup.  */
 if (did_replace)
  {
...
+ fixups.record_change (old_stmt, stmt);

here we no longer can reliably determine whether old_stmt was noreturn since
we substitute into stmt itself.  It's no longer a correctness issue if
we do _not_
fixup_noreturn since we now have GF_CALL_CTRL_ALTERING, it's merely
an optimization issue.  So there may be no testcase for this (previously such
cases ICEd).

But AFAICT we don't care in the case Aldy is changing.  If we really
want to know if the old statement was a noreturn we can test prior to
queing it.


The code isn't doing what it did before after the change.  That's a bug.


If this is indeed a problem in the cases that I changed, it's easily
fixed by marking the statement ahead of time and keeping track of the
noreturn bit (as I have done in the attached patch).



To be more explicit here - adding this kind of new and fancy C++ stuff
just for the sake of it, thereby adding yet _another_ way of handling these
things instead of forcing it a new way (remove the other APIs this
encapsulates) is very bad(TM) IMHO, both for maintainance and for
new people coming around trying to understand GCC.


I'm not adding them for the sake of it.  I'm adding them because we have
5 copies of the virtually the same code, and if I add any (additional)
propagation smarts to the compiler, I'm going to have to add a 6th copy.
   My patch abstracts away 4 out of the 5 versions, and I am volunteering
to fix the last one (forwprop) as an incremental patch.

I don't agree that this is worse.  On the contrary, I am transforming
multiple copies of this:

-  bool was_noreturn = (is_gimple_call (stmt)
-  && gimple_call_noreturn_p (stmt));
...
...
- /* If we cleaned up EH information from the statement,
-remove EH edges.  */
- if (maybe_clean_or_replace_eh_stmt (old_stmt, stmt))
-   bitmap_set_bit (need_eh_cleanup, bb->index);
-
- /* If we turned a not noreturn call into a noreturn one
-schedule it for fixup.  */
- if (!was_noreturn
- && is_gimple_call (stmt)
- && gimple_call_noreturn_p (stmt))
-   stmts_to_fixup.safe_push (stmt);
-
- if (gimple_assign_single_p (stmt))
-   {
- tree rhs = gimple_assign_rhs1 (stmt);
- if (TREE_CODE (rhs) == ADDR_EXPR)
-   recompute_tree_invariant_for_addr_expr (rhs);
-   }
-   }

by this:

+  fixups.mark_stmt (old_stmt);
...
...
+   fixups.record_change (stmt);

And we no longer have to clean things up manually at scope end:

-  if (!bitmap_empty_p (need_eh_cleanup))
-gimple_purge_all_dead_eh_edges (need_eh_cleanup);
-
-  /* Fixup stmts that became noreturn calls.  This may require splitting
- blocks and thus isn't possible during the dominator walk

Re: [PATCH, X86] Revise fuse-caller-save-* to avoid XPASSes on PIC targets.

[Uros Bizjak]

On Wed, May 22, 2019 at 8:41 PM Iain Sandoe  wrote:
>
> As Dominque noted in PR 64895, somewhere between revisions
>  r244915 and r244957 we see the fuse-caller-save* tests started to
> XPASS on Darwin, which is a PIC target by default.
>
> The XFAILed parts of the tests never seem to be exercised on
> Linux, and therefore the change would be unnoticed there.
>
> I have attached an analysis to the PR of the latest codegen from Linux
> (which is identical to Darwin modulo the syntactic differences of PIC
> accesses on the m32 platforms).
>
> AFAICT, from the thread in the PR, codegen now seems to be correct.
> Even if the codegen is still not right, the test conditions need amendment
> to reflect the current status quo (and the XFAILs are no longers needed).
>
> One test requires amendment for the PIC case on Linux, the remainer
> of the changes are removals of the XFAILs.
>
> With the attached patch both Linux and Darwin show 17 / 18 passes m32 / m64.
>
> OK for trunk?

These changes are OK as long as they don't regress HJ's x86_64 and
i686 autotesters. Double points if they also fix -fpic failures. ;)

> Relevant branch(es)?

After a couple of days in mainline, if there are no autotester
regressions. Otherwise your call.

Thanks,
Uros.

>
> Iain
>
> gcc/testsuite/
>
> PR rtl-optimisation/64895
> * gcc.target/i386/fuse-caller-save-rec.c: Remove XFAILs.
> * gcc.target/i386/fuse-caller-save.c: Likewise.
> * gcc.target/i386/fuse-caller-save-xmm.c: Adjust tests for
> PIC cases, remove XFAILs.
>
> diff --git a/gcc/testsuite/gcc.target/i386/fuse-caller-save-rec.c 
> b/gcc/testsuite/gcc.target/i386/fuse-caller-save-rec.c
> index 7abcf91..e8d4efb 100644
> --- a/gcc/testsuite/gcc.target/i386/fuse-caller-save-rec.c
> +++ b/gcc/testsuite/gcc.target/i386/fuse-caller-save-rec.c
> @@ -18,14 +18,12 @@ foo (int y)
>return y + bar (y);
>  }
>
> -/* For !nonpic && ia32 xfails, see PR64895.  */
> -
>  /* Check that no registers are saved/restored. */
> -/* { dg-final { scan-assembler-not "push" { xfail { { ! nonpic } && ia32 } } 
> } } */
> -/* { dg-final { scan-assembler-not "pop" { xfail { { ! nonpic } && ia32 } } 
> } } */
> +/* { dg-final { scan-assembler-not "push" } } */
> +/* { dg-final { scan-assembler-not "pop" } } */
>
>  /* Check that addition uses dx. */
> -/* { dg-final { scan-assembler-times "addl\t%\[re\]?dx, %\[re\]?ax" 1 { 
> xfail { { ! nonpic } && ia32 } } } } */
> +/* { dg-final { scan-assembler-times "addl\t%\[re\]?dx, %\[re\]?ax" 1 } } */
>
>  /* Verify that bar is self-recursive.  */
>  /* { dg-final { scan-assembler-times "call\t_?bar" 2 } } */
> diff --git a/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c 
> b/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c
> index c2d0544..02a5f5b 100644
> --- a/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c
> +++ b/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c
> @@ -15,13 +15,18 @@ foo (v2df y)
>return y + bar (y);
>  }
>
> -/* For !nonpic && ia32 xfails, see PR64895.  */
> -
>  /* Check presence of all insns on xmm registers.  These checks are expected 
> to
> pass with both -fipa-ra and -fno-ipa-ra.  */
> -/* { dg-final { scan-assembler-times "addpd\t\\.?LC0.*, %xmm0" 1 } } */
> -/* { dg-final { scan-assembler-times "addpd\t%xmm1, %xmm0" 1 { xfail { { ! 
> nonpic } && ia32 } } } } */
> -/* { dg-final { scan-assembler-times "movapd\t%xmm0, %xmm1" 1 { xfail { { ! 
> nonpic } && ia32 } } } } */
> +
> +/* { dg-final { scan-assembler-times {addpd\t\.?[Ll]C0.*, %xmm0} 1 { target 
> { { ! ia32 } || nonpic } } } } */
> +/* { dg-final { scan-assembler-times {movapd\t\.?[Ll]C0.*, %xmm1} 1 { target 
> { ia32 && { ! nonpic } } } } } */
> +
> +/* We happen to get this for both cases, but in different positions.  */
> +/* { dg-final { scan-assembler-times "addpd\t%xmm1, %xmm0" 1 } } */
> +
> +/* { dg-final { scan-assembler-times "movapd\t%xmm0, %xmm1" 1 { target { { ! 
> ia32 } || nonpic } } } } */
> +/* { dg-final { scan-assembler-times "movapd\t%xmm0, %xmm2" 1 { target { 
> ia32 && { ! nonpic } } } } } */
> +/* { dg-final { scan-assembler-times "addpd\t%xmm2, %xmm0" 1 { target { ia32 
> && { ! nonpic } } } } } */
>
>  /* Check absence of save/restore of xmm1 register.  */
>  /* { dg-final { scan-assembler-not "movaps\t%xmm1, \\(%\[re\]?sp\\)" } } */
> diff --git a/gcc/testsuite/gcc.target/i386/fuse-caller-save.c 
> b/gcc/testsuite/gcc.target/i386/fuse-caller-save.c
> index 4b8e68d..c0e8bf4 100644
> --- a/gcc/testsuite/gcc.target/i386/fuse-caller-save.c
> +++ b/gcc/testsuite/gcc.target/i386/fuse-caller-save.c
> @@ -16,11 +16,9 @@ foo (int y)
>return y + bar (y);
>  }
>
> -/* For !nonpic && ia32 xfails, see PR64895.  */
> -
>  /* Check that no registers are saved/restored. */
> -/* { dg-final { scan-assembler-not "push" { xfail { { ! nonpic } && ia32 } } 
> } } */
> -/* { dg-final { scan-assembler-not "pop" { xfail { { ! nonpic } && ia32 } } 
> } } */
> +/* { dg-final { scan-assembler-not "push" } }

Re: [PATCH, X86] Disable mfentry for Darwin and amend testing.

[Uros Bizjak]

On Thu, May 23, 2019 at 1:09 AM Iain Sandoe  wrote:
>
> Although this is a Darwin-specific change, I need to touch
> target-supports.exp and several tests in i386.exp.
>
> tested on x86_64-darwin and x86_64-linux-gnu
> doc change tested with “make pdf”,
>
> OK for trunk?
> backports? (where the tests fail).
>
> gcc/
>
> * config/i386/darwin.h: Reject -mfentry*.
> * doc/sourcebuild.texi: Document mfentry target support.
>
> gcc/testsuite/
>
> * lib/target-supports.exp (check_effective_target_mfentry): New.

This procedure is written in a wrong way. You should either fix it as
suggested below, or write it in a way, similar to e.g.
check_effective_target_cet.

Uros.

> * gcc.target/i386/fentry-override.c: Require effective target mfentry,
> * gcc/testsuite/gcc.target/i386/fentry.c: Likewise
> * gcc.target/i386/fentryname1.c: Likewise
> * gcc.target/i386/fentryname2.c: Likewise
> * gcc.target/i386/fentryname3.c: Likewise
> * gcc.target/i386/nop-mcount.c: Likewise
> * gcc.target/i386/pr82699-2.c: Likewise
> * gcc.target/i386/pr82699-4.c: Likewise
> * gcc.target/i386/pr82699-5.c: Likewise
> * gcc.target/i386/pr82699-6.c: Likewise
> * gcc.target/i386/returninst1.c: Likewise
> * gcc.target/i386/returninst2.c: Likewise
> * gcc.target/i386/returninst3.c : Likewise
>
> diff --git a/gcc/config/i386/darwin.h b/gcc/config/i386/darwin.h
> index fe11ec9..1128428 100644
> --- a/gcc/config/i386/darwin.h
> +++ b/gcc/config/i386/darwin.h
> @@ -132,7 +132,8 @@ extern int darwin_emit_branch_islands;
>  #define CC1_SPEC "%(cc1_cpu) \
>%{!mkernel:%{!static:%{!mdynamic-no-pic:-fPIC}}} \
>%{g: %{!fno-eliminate-unused-debug-symbols: 
> -feliminate-unused-debug-symbols }} \
> -  %{mx32:%eDarwin is not an mx32 platform}" \
> +  %{mx32:%eDarwin is not an mx32 platform} \
> +  %{mfentry*:%eDarwin does not support -mfentry or associated options}" \
>DARWIN_CC1_SPEC
>
>  #undef ASM_SPEC
> diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
> index cf12d74..546af7f 100644
> --- a/gcc/doc/sourcebuild.texi
> +++ b/gcc/doc/sourcebuild.texi
> @@ -2382,6 +2382,10 @@ Target supports compiling @code{aes} instructions.
>  @item fma4
>  Target supports compiling @code{fma4} instructions.
>
> +@item mfentry
> +Target supports the @code{-mfentry} option that alters the
> +position of profiling calls such that they precede the prologue.
> +
>  @item ms_hook_prologue
>  Target supports attribute @code{ms_hook_prologue}.
>
> diff --git a/gcc/testsuite/gcc.target/i386/fentry-override.c 
> b/gcc/testsuite/gcc.target/i386/fentry-override.c
> index 7bc5fc4..efba1bf 100644
> --- a/gcc/testsuite/gcc.target/i386/fentry-override.c
> +++ b/gcc/testsuite/gcc.target/i386/fentry-override.c
> @@ -1,5 +1,6 @@
>  /* Test -mfentry override */
>  /* { dg-do compile { target { *-*-linux* && { ! ia32 } } } } */
> +/* { dg-require-effective-target mfentry } */
>  /* { dg-options "-mfentry" } */
>  /* { dg-final { scan-assembler-not "__fentry__" } } */
>  /* Origin: Andi Kleen */
> diff --git a/gcc/testsuite/gcc.target/i386/fentry.c 
> b/gcc/testsuite/gcc.target/i386/fentry.c
> index 2449e75..28edd10 100644
> --- a/gcc/testsuite/gcc.target/i386/fentry.c
> +++ b/gcc/testsuite/gcc.target/i386/fentry.c
> @@ -1,5 +1,6 @@
>  /* Test -mfentry */
>  /* { dg-do compile { target { *-*-linux* && { ! ia32 } } } } */
> +/* { dg-require-effective-target mfentry } */
>  /* { dg-options "-fprofile -mfentry" } */
>  /* { dg-final { scan-assembler "__fentry__" } } */
>  /* Origin: Andi Kleen */
> diff --git a/gcc/testsuite/gcc.target/i386/fentryname1.c 
> b/gcc/testsuite/gcc.target/i386/fentryname1.c
> index 6d2e76d..1265342 100644
> --- a/gcc/testsuite/gcc.target/i386/fentryname1.c
> +++ b/gcc/testsuite/gcc.target/i386/fentryname1.c
> @@ -1,4 +1,5 @@
>  /* { dg-do compile } */
> +/* { dg-require-effective-target mfentry } */
>  /* { dg-options "-pg -mfentry -mfentry-name=foo" } */
>  /* { dg-final { scan-assembler "call.*foo" } } */
>  /* { dg-final { scan-assembler "call.*bar" } } */
> diff --git a/gcc/testsuite/gcc.target/i386/fentryname2.c 
> b/gcc/testsuite/gcc.target/i386/fentryname2.c
> index 7d102bf..c51c5d1 100644
> --- a/gcc/testsuite/gcc.target/i386/fentryname2.c
> +++ b/gcc/testsuite/gcc.target/i386/fentryname2.c
> @@ -1,4 +1,5 @@
>  /* { dg-do compile } */
> +/* { dg-require-effective-target mfentry } */
>  /* { dg-options "-pg -mfentry -mrecord-mcount -mfentry-section=foo" } */
>  /* { dg-final { scan-assembler "section.*foo" } } */
>  /* { dg-final { scan-assembler "section.*bar" } } */
> diff --git a/gcc/testsuite/gcc.target/i386/fentryname3.c 
> b/gcc/testsuite/gcc.target/i386/fentryname3.c
> index 777f4e4..5688109 100644
> --- a/gcc/testsuite/gcc.target/i386/fentryname3.c
> +++ b/gcc/testsuite/gcc.target/i386/fentryname3.c
> @@ -1,4 +1,5 @@
>  /* { dg-do compile } */
> +/* { dg-require-effective-target mfentry } */
>  /* {

Re: Strenghten aliasing_component_refs_p

[Bernhard Reutner-Fischer]

On 20 May 2019 11:40:17 CEST, Richard Biener  wrote:
>On Sun, 19 May 2019, Jan Hubicka wrote:
>
>> > On Fri, 17 May 2019, Jan Hubicka wrote:
>> > 
>> > > Hi,
>> > > this patch cuts walks in aliasing_component_refs_p if the type we
>look for
>> > > can not fit into a given type by comparing their sizes. Similar
>logic
>> > > already exists in indirect_ref_may_alias_decl_p.
>> > > 
>> > > When we walk reference a.b.c.d.e looking for type x we only need
>to do
>> > > it if sizeof(a)>=sizeof(x) and continue woking from e until
>> > > sizeof(e)<=sizeof(x). We do not need to compare types where sizes
>are
>> > > known to be different.
>> > > 
>> > > This saves some work (by not walking refs and not comparing their
>types
>> > > if they can not match) but also increases number of
>disambiguations
>> > > quite noticably. This is because same_type_for_tbaa often returns
>-1 and
>> > > makes aliasing_compinent_refs_p to give up.  Using the simple
>size check
>> > > prevents hitting such problematic type pairs in many common
>cases.
>> > > 
>> > > Stats on tramp3d lto build change From:
>> > > 
>> > > Alias oracle query stats:
>> > >   refs_may_alias_p: 0 disambiguations, 0 queries
>> > >   ref_maybe_used_by_call_p: 6451 disambiguations, 25578 queries
>> > >   call_may_clobber_ref_p: 817 disambiguations, 817 queries
>> > >   aliasing_component_ref_p: 14 disambiguations, 12528 queries
>> > >   TBAA oracle: 1468347 disambiguations 3010562 queries
>> > >550690 are in alias set 0
>> > >614235 queries asked about the same object
>> > >0 queries asked about the same alias set
>> > >0 access volatile
>> > >260937 are dependent in the DAG
>> > >116353 are aritificially in conflict with void *
>> > > 
>> > > to:
>> > > 
>> > > Alias oracle query stats:
>> > >   refs_may_alias_p: 0 disambiguations, 0 queries
>> > >   ref_maybe_used_by_call_p: 6451 disambiguations, 25580 queries
>> > >   call_may_clobber_ref_p: 817 disambiguations, 817 queries
>> > >   aliasing_component_ref_p: 118 disambiguations, 12552 queries
>> > >   TBAA oracle: 1468413 disambiguations 3010714 queries
>> > >550719 are in alias set 0
>> > >614247 queries asked about the same object
>> > >0 queries asked about the same alias set
>> > >0 access volatile
>> > >260970 are dependent in the DAG
>> > >116365 are aritificially in conflict with void *
>> > > 
>> > > So disambiguations are up from 14 to 118 which is still quite
>low.
>> > > 
>> > > A followup patch making types_same_for_tbaa to not give up for
>> > > TYPE_STRUCTURAL_EQUALITY pointers and arrays improves hitrate to
>2723.
>> > > 
>> > > Bootstrapped/regtested x86_64-linux, OK?
>> > > 
>> > >  * tree-ssa-alias.c (type_big_enough_for_type_p): New function.
>> > >  (aliasing_component_refs_p): Use it.
>> > > Index: tree-ssa-alias.c
>> > >
>===
>> > > --- tree-ssa-alias.c (revision 271292)
>> > > +++ tree-ssa-alias.c (working copy)
>> > > @@ -735,6 +735,27 @@ ao_ref_init_from_ptr_and_size (ao_ref *r
>> > >ref->volatile_p = false;
>> > >  }
>> > >  
>> > > +/* Return true if TYPE1 may contain TYPE2 by its size.  */
>> > > +
>> > > +static bool
>> > > +type_big_enough_for_type_p (tree type1, tree type2)
>> > > +{
>> > > +  if (!TYPE_SIZE (type1) || !TYPE_SIZE (type2))
>> > > +return true;
>> > > +  /* Be conservative for arrays and vectors.  We want to support
>partial
>> > > + overlap on int[3] and int[3] as tested in
>gcc.dg/torture/alias-2.c.  */
>> > > +  while (TREE_CODE (type2) == ARRAY_TYPE
>> > > + || TREE_CODE (type2) == VECTOR_TYPE)
>> > > +type2 = TREE_TYPE (type2);
>> > 
>> > Eww ;)  I guess this means same-type can never return true for
>> > array or vectors?
>> > 
>> > > +  if (!poly_int_tree_p (TYPE_SIZE (type1))
>> > > +  || !poly_int_tree_p (TYPE_SIZE (type2)))
>> > > +return true;
>> > 
>> > Use
>> > 
>> > poly_uint64 size1;
>> > if (!poly_int_tree_p (TYPE_SIZE (type1), &size1)
>> >  ...
>> > 
>> > > +  if (known_lt (wi::to_poly_widest (TYPE_SIZE (type1)),
>> > > +wi::to_poly_widest (TYPE_SIZE (type2
>> > 
>> > and
>> > 
>> >  if (known_lt (size1, size2))
>> > 
>> > I wonder if you can compute whether type1 fits in type2 and
>> > the other way around at the same time, saving seemingly
>> > redundant work since you test both ways most of the time below.
>> > So sth like type_size_compare_for_fitting () returning
>> > -1, 0, 1 and use zero for "don't know"?
>> 
>> Hi,
>> this patch implements the three way compare and also merges the code
>> with same logic in indirect_ref_may_alias_decl_p.
>> We end up doing more known_lt calls than necessary because sometimes
>we
>> do not care about the three way outcome, but I asusme that this
>should
>> be relatively cheap once we