[PATCH] Add myself to MAINTAINERS

[Xiong Hu Luo]

2019-01-16  Xiong Hu Luo 

  * MAINTAINERS (Write After Approval): Add myself.

Committed in r267962.

---

Index: ChangeLog
===
--- ChangeLog   (revision 267961)
+++ ChangeLog   (working copy)
@@ -1,3 +1,7 @@
+ 2019-01-16  Xiong Hu Luo 
+
+ * MAINTAINERS (Write After Approval): Add myself.
+
 2019-01-03  Rainer Orth  

    PR target/88535
Index: MAINTAINERS
===
--- MAINTAINERS (revision 267961)
+++ MAINTAINERS (working copy)
@@ -481,6 +481,7 @@
 Carl Love 
 Martin v. Löwis 
 H.J. Lu 
+Xiong Hu Luo 
 Christophe Lyon 
 Luis Machado 
 Ziga Mahkovec 

Re: [PATCH 8/9] [libbacktrace] Add btest_dwz test-case

[Ian Lance Taylor]

On Tue, Dec 11, 2018 at 2:16 AM Tom de Vries  wrote:
>
> 2018-11-11  Tom de Vries  
>
> * configure.ac (DWZ): Set with AC_CHECK_PROG.
> (HAVE_DWZ): Set with AM_CONDITIONAL.
> * configure: Regenerate.
> * Makefile.am (TESTS): Add btest_dwz.
> * Makefile.in: Regenerate.

> diff --git a/libbacktrace/Makefile.am b/libbacktrace/Makefile.am
> index 1a3680bc98c..497cc2f5c97 100644
> --- a/libbacktrace/Makefile.am
> +++ b/libbacktrace/Makefile.am
> @@ -157,6 +157,18 @@ btest_alloc_LDADD = libbacktrace_alloc.la
>
>  check_PROGRAMS += btest_alloc
>
> +if HAVE_DWZ
> +
> +%_dwz: %
> +   rm -f $@_common.debug
> +   cp $< $@
> +   cp $< $@_2
> +   $(DWZ) -m $@_common.debug $@ $@_2

This doesn't look right.  A Makefile recipe must always create the
target as the very last command.  Otherwise, if the recipe is
interrupted for any reason, such as, in this case, a failure to run
dwz, then when you run make again it will think that the recipe has
already been run.

Ian

Re: [PATCH 6/9] [libbacktrace] Factor out read_referenced_name_1

[Ian Lance Taylor via gcc-patches]

On Tue, Dec 11, 2018 at 2:15 AM Tom de Vries  wrote:
>
> Factor out the common handling of DW_AT_abstract_origin and
> DW_AT_specification from read_function_entry and read_referenced_name.
>
> 2018-12-10  Tom de Vries  
>
> * dwarf.c (read_referenced_name_1): New function.  Factor out of ...
> (read_referenced_name): ... here, and ...
> (read_function_entry): ... here.

> +static const char *read_referenced_name (struct dwarf_data *, struct unit *,
> +uint64_t, backtrace_error_callback,
> +void *);
> +

We don't need this declaration.  Only add a static declaration if
there is a forward reference.


> +/* Read the name of a function from a DIE referenced by ATTR with VAL.  */
> +
> +static const char *
> +read_referenced_name_1 (struct dwarf_data *ddata, struct unit *u,
> +   struct attr *attr, struct attr_val *val,
> +   backtrace_error_callback error_callback, void *data)
> +{

Let's not use a name ending in "_1".  That is a cop-out.  Pick a
meaningful name.  Perhaps read_referenced_name_from_attr.

Ian

Re: [PATCH 5/9] [libbacktrace] Unify function name preference handling

[Ian Lance Taylor via gcc-patches]

On Tue, Dec 11, 2018 at 2:15 AM Tom de Vries  wrote:
>
> Both read_function_entry and read_referenced_name implement a priority scheme
> for names.  The priorities are:
> - 1st: DW_AT_linkage_name
> - 2nd: Name from DW_AT_abstract_origin or DW_AT_specification
> - 3rd: DW_AT_name.
>
> Ensure both functions fully adhere to it.
>
> 2018-11-21  Tom de Vries  
>
> * dwarf.c (read_referenced_name): Don't allow DW_AT_name to override 
> any
> name.
> (read_function_entry): Same.  Don't allow name found via
> DW_AT_abstract_origin or case DW_AT_specification to override linkage
> name.

This is OK.

Thanks.

Ian

Re: [PATCH 4/9] [libbacktrace] Handle DW_FORM_GNU_strp_alt

[Ian Lance Taylor via gcc-patches]

On Tue, Dec 11, 2018 at 2:15 AM Tom de Vries  wrote:
>
> Handle DW_FORM_GNU_strp_alt which references the .debug_str section in the
> .gnu_debugaltlink file.
>
> 2018-11-11  Tom de Vries  
>
> * dwarf.c (read_attribute): Handle DW_FORM_GNU_strp_alt
> using altlink.

This is OK.

Thanks.

Ian

Re: [PATCH 3/9] [libbacktrace] Handle alt FORMS without .gnu_debugaltlink

[Ian Lance Taylor]

On Tue, Dec 11, 2018 at 2:14 AM Tom de Vries  wrote:
>
> Handle DW_FORM_GNU_strp_alt and DW_FORM_GNU_ref_alt references robustly in
> presence of missing .gnu_debugaltlink file.
>
> 2018-11-11  Tom de Vries  
>
> * dwarf.c (enum attr_val_encoding): Add ATTR_VAL_NONE.
> (read_attribute): Add altlink parameter.  Handle missing altlink for
> DW_FORM_GNU_strp_alt and DW_FORM_GNU_ref_alt.
> (find_address_ranges, build_address_map, build_dwarf_data): Add and
> handle altlink parameter.
> (read_referenced_name, read_function_entry): Add argument to
> read_attribute call.



>  read_attribute (enum dwarf_form form, struct dwarf_buf *buf,
> int is_dwarf64, int version, int addrsize,
> const unsigned char *dwarf_str, size_t dwarf_str_size,
> -   struct attr_val *val)
> +   struct attr_val *val, struct dwarf_data *altlink)
>  {

altlink is not a result parameter, so it should be before val.


> @@ -1277,7 +1289,8 @@ find_address_ranges (struct backtrace_state *state, 
> uintptr_t base_address,
>  size_t dwarf_ranges_size,
>  int is_bigendian, backtrace_error_callback 
> error_callback,
>  void *data, struct unit *u,
> -struct unit_addrs_vector *addrs)
> +struct unit_addrs_vector *addrs,
> +struct dwarf_data *altlink)

Same.  altlink should be before the error_callback parameter.


> @@ -1431,7 +1444,8 @@ build_address_map (struct backtrace_state *state, 
> uintptr_t base_address,
>const unsigned char *dwarf_ranges, size_t 
> dwarf_ranges_size,
>const unsigned char *dwarf_str, size_t dwarf_str_size,
>int is_bigendian, backtrace_error_callback error_callback,
> -  void *data, struct unit_addrs_vector *addrs)
> +  void *data, struct unit_addrs_vector *addrs,
> +  struct dwarf_data *altlink)

Same.

Ian

Re: [PATCH 2/9] [libbacktrace] Add altlink field to struct dwarf_data

[Ian Lance Taylor]

On Tue, Dec 11, 2018 at 2:14 AM Tom de Vries  wrote:
>
> Add an altlink field to struct dwarf_data, and initialize it with the pointer
> to the struct dwarf_data for the .gnu_debugaltlink.
>
> 2018-11-11  Tom de Vries  
>
> * dwarf.c (struct dwarf_data): Add altlink field.
> (backtrace_dwarf_add): Add and handle fileline_entry and
> fileline_altlink parameters.
> * elf.c (elf_add): Add and handle fileline_entry parameter.  Add args 
> to
> backtrace_dwarf_add call.
> (phdr_callback, backtrace_initialize): Add arguments to elf_add calls.
> * internal.h (backtrace_dwarf_add): Add fileline_entry and
> fileline_altlink parameters.
> * pecoff.c (coff_add): Add args to backtrace_dwarf_add call.
> * xcoff.c (xcoff_add): Same.


> @@ -2968,7 +2970,7 @@ build_dwarf_data (struct backtrace_state *state,
>   size_t dwarf_str_size,
>   int is_bigendian,
>   backtrace_error_callback error_callback,
> - void *data)
> + void *data, struct dwarf_data *altlink)
>  {

error_callback and data should remain the last two parameters, as they
are for many of the functions in this file.


>   @@ -3031,7 +3034,8 @@ backtrace_dwarf_add (struct backtrace_state *state,
>  size_t dwarf_str_size,
>  int is_bigendian,
>  backtrace_error_callback error_callback,
> -void *data, fileline *fileline_fn)
> +void *data, fileline *fileline_fn, void **fileline_entry,
> +void *fileline_altlink)

The new fileline_altlink parameter should come before error_callback,
as it is not error_callback/data and is not a result parameter.

What is fileline_entry for?  Why is it void**?

Ian

Re: [PATCH 1/9] [libbacktrace] Read .gnu_debugaltlink

[Ian Lance Taylor via gcc-patches]

On Tue, Dec 11, 2018 at 2:14 AM Tom de Vries  wrote:
>
> Read the elf file pointed at by the .gnu_debugaltlink section, and verify that
> the build id matches.
>
> 2018-11-11  Tom de Vries  
>
> * elf.c (elf_add): Add and handle with_buildid_data and
> with_buildid_size parameters.  Handle .gnu_debugaltlink section.
> (phdr_callback, backtrace_initialize): Add arguments to elf_add calls.
> ---



@@ -2899,6 +2918,27 @@ elf_add (struct backtrace_state *state, const
char *filename, int descriptor,
> }
> }
>
> +  if (!debugaltlink_view_valid
> + && strcmp (name, ".gnu_debugaltlink") == 0)
> +   {
> + const char *debugaltlink_data;
> + size_t debugaltlink_name_len;
> +
> + if (!backtrace_get_view (state, descriptor, shdr->sh_offset,
> +  shdr->sh_size, error_callback, data,
> +  &debugaltlink_view))
> +   goto fail;
> +
> + debugaltlink_view_valid = 1;
> + debugaltlink_data = (const char *) debugaltlink_view.data;
> + debugaltlink_name = debugaltlink_data;
> + debugaltlink_name_len = strnlen (debugaltlink_data, shdr->sh_size);
> + debugaltlink_buildid_data = (debugaltlink_data
> +  + debugaltlink_name_len
> +  + 1);
> + debugaltlink_buildid_size = shdr->sh_size - debugaltlink_name_len - 
> 1;
> +   }
> +

This doesn't look quite right.  debugaltlink_buildid_size is unsigned.
If there is some misunderstanding of the format it's possible for
strnlen to return shdr->sh_size.  If it does,
debugaltlink_buildid_size will be set to a very large value.


> +  if (debugaltlink_name != NULL)
> +{
> +  int d;
> +
> +  d = elf_open_debugfile_by_debuglink (state, filename, 
> debugaltlink_name,
> +  0, error_callback, data);
> +  if (d >= 0)
> +   {
> + int ret;
> +
> + ret = elf_add (state, filename, d, base_address, error_callback, 
> data,
> +fileline_fn, found_sym, found_dwarf, 0, 1,
> +debugaltlink_buildid_data, 
> debugaltlink_buildid_size);
> + backtrace_release_view (state, &debugaltlink_view, error_callback,
> + data);
> + debugaltlink_view_valid = 0;
> + if (ret < 0)
> +   {
> + backtrace_close (d, error_callback, data);
> + return ret;
> +   }
> +   }
> +  else
> +   {
> + error_callback (data,
> + "Could not open .gnu_debugaltlink", 0);
> + /* Don't goto fail, but try continue without the info in the
> +.gnu_debugaltlink.  */
> +   }
> +}

The strings passed to error_callback always start with a lowercase
letter (unless they start with something like ELF) because the
callback will most likely print them with some prefix.

More seriously, we don't call error_callback in any cases that
correspond to this.  We just carry on.  Is there any reason to call
error_callback here?

Ian

Re: [PATCH 10/10] libiberty: Correct an invalid assumption

[Ben L]

On 14/01/2019 11:10, Iain Buclaw wrote:

> Thanks, do you have a copyright assignment with the FSF?

No problem, and no I don't think so. I'd assumed these patches were trivial
enough to not need anything like that, but if so then what do I need to do?

> Rather than checking for overflow twice, I think it would be
> sufficient to just do:
> ---
> long digit = mangled[0] - '0';
>
> if (*ret > ((LONG_MAX - digit) / 10))
>return NULL;
>
> (*ret) *= 10;
> (*ret) += digit;
> mangled++;
> ---

I'd agree, that does the trick too. Do I need to resend the patch with that
change, or can that be done by whoever applies it since they'll be squashed
into a single patch anyway?

Thanks,
Ben

[SVE ACLE] Implements svabs, svnot, svneg and svsqrt

[Kugan Vivekanandarajah]

I committed the following patch which implements  svabs, svnot, svneg
and svsqrt to  aarch64/sve-acle-branch. branch

Thanks,
Kugan
From 2af9609a58cf7efbed93f15413224a2552b9696d Mon Sep 17 00:00:00 2001
From: Kugan Vivekanandarajah 
Date: Wed, 16 Jan 2019 07:45:52 +1100
Subject: [PATCH] [SVE ACLE ] svab, svnot, svneg and svsqrt implementation

Change-Id: Iec1e9491e4a84a351702550babedd0f17968617e
---
 gcc/config/aarch64/aarch64-sve-builtins.c  | 126 -
 gcc/config/aarch64/aarch64-sve-builtins.def|   4 +
 gcc/config/aarch64/aarch64-sve.md  |  52 +++--
 gcc/config/aarch64/iterators.md|  16 ++-
 .../gcc.target/aarch64/sve-acle/asm/abs_f16.c  | 122 
 .../gcc.target/aarch64/sve-acle/asm/abs_f32.c  | 122 
 .../gcc.target/aarch64/sve-acle/asm/abs_f64.c  | 122 
 .../gcc.target/aarch64/sve-acle/asm/abs_s16.c  |  83 ++
 .../gcc.target/aarch64/sve-acle/asm/abs_s32.c  |  83 ++
 .../gcc.target/aarch64/sve-acle/asm/abs_s64.c  |  83 ++
 .../gcc.target/aarch64/sve-acle/asm/abs_s8.c   |  83 ++
 .../gcc.target/aarch64/sve-acle/asm/neg_f16.c  | 122 
 .../gcc.target/aarch64/sve-acle/asm/neg_f32.c  | 122 
 .../gcc.target/aarch64/sve-acle/asm/neg_f64.c  | 122 
 .../gcc.target/aarch64/sve-acle/asm/neg_s16.c  |  83 ++
 .../gcc.target/aarch64/sve-acle/asm/neg_s32.c  |  83 ++
 .../gcc.target/aarch64/sve-acle/asm/neg_s64.c  |  83 ++
 .../gcc.target/aarch64/sve-acle/asm/neg_s8.c   |  83 ++
 .../gcc.target/aarch64/sve-acle/asm/not_s16.c  |  83 ++
 .../gcc.target/aarch64/sve-acle/asm/not_s32.c  |  83 ++
 .../gcc.target/aarch64/sve-acle/asm/not_s64.c  |  83 ++
 .../gcc.target/aarch64/sve-acle/asm/not_s8.c   |  83 ++
 .../gcc.target/aarch64/sve-acle/asm/not_u16.c  |  83 ++
 .../gcc.target/aarch64/sve-acle/asm/not_u32.c  |  83 ++
 .../gcc.target/aarch64/sve-acle/asm/not_u64.c  |  83 ++
 .../gcc.target/aarch64/sve-acle/asm/not_u8.c   |  83 ++
 .../gcc.target/aarch64/sve-acle/asm/sqrt_f16.c | 122 
 .../gcc.target/aarch64/sve-acle/asm/sqrt_f32.c | 122 
 .../gcc.target/aarch64/sve-acle/asm/sqrt_f64.c | 122 
 29 files changed, 2610 insertions(+), 14 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/abs_f16.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/abs_f32.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/abs_f64.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/abs_s16.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/abs_s32.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/abs_s64.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/abs_s8.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/neg_f16.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/neg_f32.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/neg_f64.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/neg_s16.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/neg_s32.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/neg_s64.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/neg_s8.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/not_s16.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/not_s32.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/not_s64.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/not_s8.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/not_u16.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/not_u32.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/not_u64.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/not_u8.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/sqrt_f16.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/sqrt_f32.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/sqrt_f64.c

diff --git a/gcc/config/aarch64/aarch64-sve-builtins.c b/gcc/config/aarch64/aarch64-sve-builtins.c
index c300957..d663de4 100644
--- a/gcc/config/aarch64/aarch64-sve-builtins.c
+++ b/gcc/config/aarch64/aarch64-sve-builtins.c
@@ -101,6 +101,9 @@ enum function_shape {
   /* sv_t svfoo[_n]_t0(_t).  */
   SHAPE_unary_n,
 
+  /* sv_t svfoo[_t0](sv_t).  */
+  SHAPE_unary,
+
   /* sv_t svfoo_t0(_t, _t).  */
   SHAPE_binary_scalar,
 
@@ -151,6 +154,7 @@ typedef enum type_suffix type_suffix_pair[

Re: [PATCH] -fdump-go-spec mishandles typedefs that precede the definition of their underlying type

[Ian Lance Taylor]

On Fri, Nov 23, 2018 at 1:18 PM Nikhil Benesch  wrote:
>
> 2018-11-22  Nikhil Benesch  
>
> * gcc/godump.c (go_output_typedef): When outputting a typedef, use
> the refer to the underlying type by its name and not its structure.
> This is necessary when the typedef occurs before the definition of
> an element of the underlying type.
> * gcc.misc-tests/godump-1.c: Add test cases for the new behavior.

Thanks.

Committed to mainline.

Ian

Re: Go patch committed: Pad structs that end with a zero-sized field

[Ian Lance Taylor]

On Fri, Jan 11, 2019 at 3:16 PM Ian Lance Taylor  wrote:
>
> This patch by Cherry Zhang changes the Go frontend to pad structs
> ending with a zero-sized field.  For a struct with zero-sized last
> field, the address of the field falls out of the object boundary,
> which confuses the garbage collector.  Pad an extra byte in this case.
> Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
> to mainline.

This follow-up patch by Cherry Zhang adds the padding to the FFI type
when using using libffi.  This fixes reflect.Call with structs that
end in a zero-sized field.  This fixes test/fixedbugs/issue26335.go in
the main repo.  Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 267950)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-87005025fcd0d7e7908b3aae7062b52cb80eb0f3
+9a79c333e896ea49f6a708d459148074d29a2af6
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/go/runtime/ffi.go
===
--- libgo/go/runtime/ffi.go (revision 267941)
+++ libgo/go/runtime/ffi.go (working copy)
@@ -227,6 +227,7 @@ func structToFFI(typ *structtype) *__ffi
 
fields := make([]*__ffi_type, 0, c+1)
checkPad := false
+   lastzero := false
for i, v := range typ.fields {
// Skip zero-sized fields; they confuse libffi,
// and there is no value to pass in any case.
@@ -235,8 +236,10 @@ func structToFFI(typ *structtype) *__ffi
// next field.
if v.typ.size == 0 {
checkPad = true
+   lastzero = true
continue
}
+   lastzero = false
 
if checkPad {
off := uintptr(0)
@@ -257,6 +260,13 @@ func structToFFI(typ *structtype) *__ffi
fields = append(fields, typeToFFI(v.typ))
}
 
+   if lastzero {
+   // The compiler adds one byte padding to non-empty struct ending
+   // with a zero-sized field (types.cc:get_backend_struct_fields).
+   // Add this padding to the FFI type.
+   fields = append(fields, ffi_type_uint8())
+   }
+
fields = append(fields, nil)
 
return &__ffi_type{

[PATCH, d] Committed refactor building typeof(null) value.

[Iain Buclaw]

Hi,

This patch moves into one function building the typeof(null) values in
the D front-end.

Bootstrapped and regression tested on x86_64-linux-gnu.

Committed to trunk as r267955.

-- 
Iain
---
gcc/d/ChangeLog:

2019-01-16  Iain Buclaw  

* d-codegen.cc (build_typeof_null_value): New function.
* d-tree.h (build_typeof_null_value): Declare.
* d-convert.cc (convert_expr): Use build_typeof_null_value.
* expr.cc (ExprVisitor::visit(NullExp)): Likewise.

---
diff --git a/gcc/d/d-codegen.cc b/gcc/d/d-codegen.cc
index e62d1f9d3b3..7ca0acffcc4 100644
--- a/gcc/d/d-codegen.cc
+++ b/gcc/d/d-codegen.cc
@@ -448,6 +448,42 @@ extract_from_method_call (tree t, tree& callee, tree& object)
   callee = CONSTRUCTOR_ELT (t, 1)->value;
 }
 
+/* Build a typeof(null) constant of type TYPE.  Handles certain special case
+   conversions, where the underlying type is an aggregate with a nullable
+   interior pointer.  */
+
+tree
+build_typeof_null_value (Type *type)
+{
+  Type *tb = type->toBasetype ();
+  tree value;
+
+  /* For dynamic arrays, set length and pointer fields to zero.  */
+  if (tb->ty == Tarray)
+value = d_array_value (build_ctype (type), size_int (0), null_pointer_node);
+
+  /* For associative arrays, set the pointer field to null.  */
+  else if (tb->ty == Taarray)
+{
+  tree ctype = build_ctype (type);
+  gcc_assert (TYPE_ASSOCIATIVE_ARRAY (ctype));
+
+  value = build_constructor_single (ctype, TYPE_FIELDS (ctype),
+	null_pointer_node);
+}
+
+  /* For delegates, set the frame and function pointer fields to null.  */
+  else if (tb->ty == Tdelegate)
+value = build_delegate_cst (null_pointer_node, null_pointer_node, type);
+
+  /* Simple zero constant for all other types.  */
+  else
+value = build_zero_cst (build_ctype (type));
+
+  TREE_CONSTANT (value) = 1;
+  return value;
+}
+
 /* Build a dereference into the virtual table for OBJECT to retrieve
a function pointer of type FNTYPE at position INDEX.  */
 
diff --git a/gcc/d/d-convert.cc b/gcc/d/d-convert.cc
index 0f3cb7ad0c5..e9aa457d852 100644
--- a/gcc/d/d-convert.cc
+++ b/gcc/d/d-convert.cc
@@ -560,18 +560,12 @@ convert_expr (tree exp, Type *etype, Type *totype)
 
 case Tnull:
   /* Casting from typeof(null) is represented as all zeros.  */
-  if (tbtype->ty == Tarray)
-	{
-	  tree ptrtype = build_ctype (tbtype->nextOf ()->pointerTo ());
-	  return d_array_value (build_ctype (totype), size_int (0),
-build_nop (ptrtype, exp));
-	}
-  else if (tbtype->ty == Taarray)
-	return build_constructor (build_ctype (totype), NULL);
-  else if (tbtype->ty == Tdelegate)
-	return build_delegate_cst (exp, null_pointer_node, totype);
+  result = build_typeof_null_value (totype);
 
-  return build_zero_cst (build_ctype (totype));
+  /* Make sure the expression is still evaluated if necessary.  */
+  if (TREE_SIDE_EFFECTS (exp))
+	result = compound_expr (exp, result);
+  break;
 
 case Tvector:
   if (tbtype->ty == Tsarray)
diff --git a/gcc/d/d-tree.h b/gcc/d/d-tree.h
index adab1d1f892..6ffb0f32a1f 100644
--- a/gcc/d/d-tree.h
+++ b/gcc/d/d-tree.h
@@ -511,6 +511,7 @@ extern tree delegate_object (tree);
 extern tree build_delegate_cst (tree, tree, Type *);
 extern tree build_method_call (tree, tree, Type *);
 extern void extract_from_method_call (tree, tree &, tree &);
+extern tree build_typeof_null_value (Type *);
 extern tree build_vindex_ref (tree, tree, size_t);
 extern tree d_save_expr (tree);
 extern tree stabilize_expr (tree *);
diff --git a/gcc/d/expr.cc b/gcc/d/expr.cc
index fecdffde020..15754a1dc2e 100644
--- a/gcc/d/expr.cc
+++ b/gcc/d/expr.cc
@@ -2941,33 +2941,7 @@ public:
 
   void visit (NullExp *e)
   {
-Type *tb = e->type->toBasetype ();
-tree value;
-
-/* Handle certain special case conversions, where the underlying type is an
-   aggregate with a nullable interior pointer.  */
-if (tb->ty == Tarray)
-  {
-	/* For dynamic arrays, set length and pointer fields to zero.  */
-	value = d_array_value (build_ctype (e->type), size_int (0),
-			   null_pointer_node);
-  }
-else if (tb->ty == Taarray)
-  {
-	/* For associative arrays, set the pointer field to null.  */
-	value = build_constructor (build_ctype (e->type), NULL);
-  }
-else if (tb->ty == Tdelegate)
-  {
-	/* For delegates, set the frame and function pointer to null.  */
-	value = build_delegate_cst (null_pointer_node,
-null_pointer_node, e->type);
-  }
-else
-  value = d_convert (build_ctype (e->type), integer_zero_node);
-
-TREE_CONSTANT (value) = 1;
-this->result_ = value;
+this->result_ = build_typeof_null_value (e->type);
   }
 
   /* Build a vector literal.  */

Re: [patch, fortran] Fix PR 43072

[Thomas Koenig]

Hi Steve,


On Tue, Jan 15, 2019 at 10:58:33PM +0100, Thomas Koenig wrote:


the attached patch fixes a missed optimization where a substring equal
in length to the original variable currently leads to an unneeded
temporary.

Regression-tested. OK for trunk?


Yes.  See below.


Thanks.



2019-01-15  Thomas Koenig  

PR fortran/43072
* resolve.c (resolve_array_ref): Add equal_length argument; set it
if the length of the substring equals that of the orignal
variable.
(resolve_ref): Remove the substring if it is equal in length
length to the original variable, unless it is an EXPR_SUBSTRING).


in length length?


Fixed in the commit.

Regards

Thomas

Re: [C++ Patch] Use locations[ds_storage_class] in error messages about ill-formed uses of mutable

[Paolo Carlini]

Hi Martin,

On 15/01/19 21:42, Martin Sebor wrote:

On 1/15/19 9:58 AM, Paolo Carlini wrote:

Hi,

something a little different from my last patches but nevertheless 
pretty straightforward (noticed while I was wondering whether we 
should immediately move the location_t grokdeclarator local even 
further up). Tested x86_64-linux, as usual.


Since you're already making changes to the tests, would be too much
more work to also add quoting around static and const in the error
messages below where mutable is already quoted:

-  error ("static %qs cannot be declared %", name);
+  error_at (sloc, "static %qs cannot be declared %", 
name);

   storage_class = sc_none;
 }
   else if (type_quals & TYPE_QUAL_CONST)
 {
-  error ("const %qs cannot be declared %", name);
+  error_at (sloc, "const %qs cannot be declared %", name);

(I can see it being a hassle if there were many other tests where
the messages expect to find static and const with no quotes.)


No problem, that's not the case. I'm finishing testing the below, then.

Thanks, Paolo.



Index: cp/decl.c
===
--- cp/decl.c   (revision 267932)
+++ cp/decl.c   (working copy)
@@ -11902,36 +11902,43 @@ grokdeclarator (const cp_declarator *declarator,
 
   if (storage_class == sc_mutable)
 {
+  location_t sloc = declspecs->locations[ds_storage_class];
   if (decl_context != FIELD || friendp)
{
- error ("non-member %qs cannot be declared %", name);
+ error_at (sloc, "non-member %qs cannot be declared %",
+   name);
  storage_class = sc_none;
}
   else if (decl_context == TYPENAME || typedef_p)
{
- error ("non-object member %qs cannot be declared %", name);
+ error_at (sloc,
+   "non-object member %qs cannot be declared %",
+   name);
  storage_class = sc_none;
}
   else if (TREE_CODE (type) == FUNCTION_TYPE
   || TREE_CODE (type) == METHOD_TYPE)
{
- error ("function %qs cannot be declared %", name);
+ error_at (sloc, "function %qs cannot be declared %",
+   name);
  storage_class = sc_none;
}
   else if (staticp)
{
- error ("static %qs cannot be declared %", name);
+ error_at (sloc, "% %qs cannot be declared %",
+   name);
  storage_class = sc_none;
}
   else if (type_quals & TYPE_QUAL_CONST)
{
- error ("const %qs cannot be declared %", name);
+ error_at (sloc, "% %qs cannot be declared %",
+   name);
  storage_class = sc_none;
}
   else if (TYPE_REF_P (type))
{
- permerror (input_location, "reference %qs cannot be declared "
-"%", name);
+ permerror (sloc, "reference %qs cannot be declared %",
+name);
  storage_class = sc_none;
}
 }
Index: testsuite/g++.dg/other/pr33558-2.C
===
--- testsuite/g++.dg/other/pr33558-2.C  (revision 267931)
+++ testsuite/g++.dg/other/pr33558-2.C  (working copy)
@@ -2,5 +2,5 @@
 /* { dg-options "-fpermissive" } */
 
 class X {
-  mutable int &q; /* { dg-warning "cannot be declared 'mutable'" } */
+  mutable int &q; /* { dg-warning "3:reference .q. cannot be declared 
.mutable." } */
 };
Index: testsuite/g++.dg/other/pr33558.C
===
--- testsuite/g++.dg/other/pr33558.C(revision 267931)
+++ testsuite/g++.dg/other/pr33558.C(working copy)
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
 
 class X {
-  mutable int &q; /* { dg-error "cannot be declared 'mutable'" } */
+  mutable int &q; /* { dg-error "3:reference .q. cannot be declared .mutable." 
} */
 };
Index: testsuite/g++.dg/parse/crash4.C
===
--- testsuite/g++.dg/parse/crash4.C (revision 267931)
+++ testsuite/g++.dg/parse/crash4.C (working copy)
@@ -7,6 +7,6 @@ struct Bar
  {
  void func(void)
  {
-   mutable Bar::type x; // { dg-error "" }
+   mutable Bar::type x; // { dg-error "8:non-member .x. cannot be declared 
.mutable." }
  }
  };
Index: testsuite/g++.old-deja/g++.brendan/err-msg11.C
===
--- testsuite/g++.old-deja/g++.brendan/err-msg11.C  (revision 267931)
+++ testsuite/g++.old-deja/g++.brendan/err-msg11.C  (working copy)
@@ -1,3 +1,3 @@
 // { dg-do assemble  }
 // GROUPS passed error-messages
-void foo (mutable int x);// { dg-error "" }  non-member `x' cannot be declared 
`mutable'.*
+void foo (mutable int x);// { dg-error "11:non-member .x. cannot be declared 
.mutable." }  non-member `x' cannot be declared `mutable'.*
Index: testsuite/g++.old-deja/g++.mike/p763

Re: [patch, fortran] Fix PR 43072

[Steve Kargl]

On Tue, Jan 15, 2019 at 10:58:33PM +0100, Thomas Koenig wrote:
> 
> the attached patch fixes a missed optimization where a substring equal
> in length to the original variable currently leads to an unneeded
> temporary.
> 
> Regression-tested. OK for trunk?

Yes.  See below.

> 
> 2019-01-15  Thomas Koenig  
> 
>   PR fortran/43072
>   * resolve.c (resolve_array_ref): Add equal_length argument; set it
>   if the length of the substring equals that of the orignal
>   variable.
>   (resolve_ref): Remove the substring if it is equal in length
>   length to the original variable, unless it is an EXPR_SUBSTRING).

in length length?

-- 
Steve

[patch, fortran] Fix PR 43072

[Thomas Koenig]

Hello world,

the attached patch fixes a missed optimization where a substring equal
in length to the original variable currently leads to an unneeded
temporary.

Regression-tested. OK for trunk?

Regards

Thomas

2019-01-15  Thomas Koenig  

PR fortran/43072
* resolve.c (resolve_array_ref): Add equal_length argument; set it
if the length of the substring equals that of the orignal
variable.
(resolve_ref): Remove the substring if it is equal in length
length to the original variable, unless it is an EXPR_SUBSTRING).

2019-01-15  Thomas Koenig  

PR fortran/43072
* gfortran.dg/actual_array_substr_3.f90: New test.
Index: resolve.c
===
--- resolve.c	(Revision 267903)
+++ resolve.c	(Arbeitskopie)
@@ -4873,7 +4873,7 @@ resolve_array_ref (gfc_array_ref *ar)
 
 
 static bool
-resolve_substring (gfc_ref *ref)
+resolve_substring (gfc_ref *ref, bool *equal_length)
 {
   int k = gfc_validate_kind (BT_INTEGER, gfc_charlen_int_kind, false);
 
@@ -4944,6 +4944,13 @@ static bool
 		 &ref->u.ss.end->where);
 	  return false;
 	}
+  /*  If the substring has the same length as the original
+	  variable, the reference itself can be deleted.  */
+
+  if (ref->u.ss.length != NULL
+	  && compare_bound (ref->u.ss.end, ref->u.ss.length->length) == CMP_EQ
+	  && compare_bound_int (ref->u.ss.start, 1) == CMP_EQ)
+	*equal_length = true;
 }
 
   return true;
@@ -5037,7 +5044,8 @@ static bool
 resolve_ref (gfc_expr *expr)
 {
   int current_part_dimension, n_components, seen_part_dimension;
-  gfc_ref *ref;
+  gfc_ref *ref, **prev;
+  bool equal_length;
 
   for (ref = expr->ref; ref; ref = ref->next)
 if (ref->type == REF_ARRAY && ref->u.ar.as == NULL)
@@ -5046,7 +5054,8 @@ resolve_ref (gfc_expr *expr)
 	break;
   }
 
-  for (ref = expr->ref; ref; ref = ref->next)
+  
+  for (ref = expr->ref, prev = &expr->ref; ref; prev = &ref->next, ref = ref->next)
 switch (ref->type)
   {
   case REF_ARRAY:
@@ -5059,8 +5068,19 @@ resolve_ref (gfc_expr *expr)
 	break;
 
   case REF_SUBSTRING:
-	if (!resolve_substring (ref))
+	equal_length = false;
+	if (!resolve_substring (ref, &equal_length))
 	  return false;
+
+	if (expr->expr_type != EXPR_SUBSTRING && equal_length)
+	  {
+	/* Remove the reference and move the charlen, if any.  */
+	*prev = ref->next;
+	ref->next = NULL;
+	expr->ts.u.cl = ref->u.ss.length;
+	ref->u.ss.length = NULL;
+	gfc_free_ref_list (ref);
+	  }
 	break;
   }
 
! { dg-do compile }
! { dg-additional-options "-fdump-tree-original" }
! PR 43072 - no temporary needed because the substring
! is of equal length to the string.
subroutine foo2
  implicit none
  external foo
  character(len=20) :: str(2) = '1234567890'
  call foo(str(:)(1:20))
end
! { dg-final { scan-tree-dump-not "memmove" "original" } }

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

[Steve Ellcey]

Richard,

Here is a new version of the patch but it is not passing the testsuite
right now.  I added the check for the size of the base type being the
same as the size of the return or argument type and modified the error
messages in some cases to make more sense.  This caused some things
to not get cloned which is fine but it also caused a couple of ICE
failures and I am not sure how to deal with those.  I also am having
trouble with a couple of tests that include other tests and how to
set dg-warning on them.

I will try to figure out what is going on but I wanted to send the
latest versions to you to see if you had any ideas on the problems
I am seeing.

Steve Ellcey
sell...@marvell.com



Here are the failures I am getting with this patch:

c-c++-common/gomp/pr63328.c
gcc.dg/gomp/pr87895-2.c

These tests include another test (which passes) and the included tests
have a dg-warning check.  For some reason the dg-warning in the include
is ignored and when I tried adding one in the main file (that includes
the other test), that didn't work either.


gcc.dg/gomp/simd-clones-1.c
g++.dg/gomp/declare-simd-1.C

These two tests are generating an ICE and I am not sure why.

I cut declare-simd-1.C down to:

#pragma omp declare simd simdlen (2) aligned (b : sizeof (long long) * 2)
__extension__ long long
f10 (long long *b)
{
  return *b;
}

And it results in:

% install/usr/bin/g++ -fopenmp-simd -c b1.C
during RTL pass: expand
b1.C: In function ‘long long int f10(long long int*)’:
b1.C:5:15: internal compiler error: in expand_assignment, at expr.c:5101
5 |   return *b;
  |   ^
0xaeee73 expand_assignment(tree_node*, tree_node*, bool)
/home/sellcey/gcc-vect/src/gcc/gcc/expr.c:5101
0x9aeecf expand_gimple_stmt_1
/home/sellcey/gcc-vect/src/gcc/gcc/cfgexpand.c:3746
0x9aeecf expand_gimple_stmt
/home/sellcey/gcc-vect/src/gcc/gcc/cfgexpand.c:3844
0x9b682f expand_gimple_basic_block
/home/sellcey/gcc-vect/src/gcc/gcc/cfgexpand.c:5880
0x9b90a7 execute
/home/sellcey/gcc-vect/src/gcc/gcc/cfgexpand.c:6503
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.



gcc.dg/gomp/simd-clones-1.c is pretty small, when I run that
I get the same trace as above.

Here is the current version of my patch.

2018-01-15  Steve Ellcey  

* config/aarch64/aarch64.c (cgraph.h): New include.
(intl.h): New include.
(supported_simd_type): New function.
(currently_supported_simd_type): Ditto.
(aarch64_simd_clone_compute_vecsize_and_simdlen): Ditto.
(aarch64_simd_clone_adjust): Ditto.
(aarch64_simd_clone_usable): Ditto.
(TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN): New macro.
(TARGET_SIMD_CLONE_ADJUST): Ditto.
(TARGET_SIMD_CLONE_USABLE): Ditto.
* config/i386/i386.c (ix86_simd_clone_adjust): Add definition check.
* omp-simd-clone.c (expand_simd_clones): Add targetm.simd_clone.adjust
call.


2018-01-15  Steve Ellcey  

* c-c++-common/gomp/pr60823-1.c: Add aarch64 specific
warning checks and assembler scans.
* c-c++-common/gomp/pr60823-3.c: Ditto.
* g++.dg/gomp/declare-simd-1.C: Ditto.
* g++.dg/gomp/declare-simd-3.C: Ditto.
* g++.dg/gomp/declare-simd-4.C: Ditto.
* g++.dg/gomp/declare-simd-7.C: Ditto.
* g++.dg/gomp/pr88182.C: Ditto.
* gcc.dg/gomp/declare-simd-1.c: Ditto.
* gcc.dg/gomp/declare-simd-3.c: Ditto.
* gcc.dg/gomp/pr59669-2.c: Ditto.
* gcc.dg/gomp/pr87895-1.c: Ditto.
* gcc.dg/gomp/simd-clones-2.c: Ditto.
* gfortran.dg/gomp/declare-simd-2.f90: Ditto.
* gfortran.dg/gomp/pr79154-1.f90: Ditto.
* gfortran.dg/gomp/pr83977.f90: Ditto.


diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index fd60bdd..5e5248f 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -40,6 +40,7 @@
 #include "regs.h"
 #include "emit-rtl.h"
 #include "recog.h"
+#include "cgraph.h"
 #include "diagnostic.h"
 #include "insn-attr.h"
 #include "alias.h"
@@ -71,6 +72,7 @@
 #include "selftest.h"
 #include "selftest-rtl.h"
 #include "rtx-vector-builder.h"
+#include "intl.h"
 
 /* This file should be included last.  */
 #include "target-def.h"
@@ -18420,6 +18422,151 @@ aarch64_estimated_poly_value (poly_int64 val)
   return val.coeffs[0] + val.coeffs[1] * over_128 / 128;
 }
 
+
+/* Return true for types that could be supported as SIMD return or
+   argument types.  */
+
+static bool supported_simd_type (tree t)
+{
+  if (SCALAR_FLOAT_TYPE_P (t) || INTEGRAL_TYPE_P (t) || POINTER_TYPE_P (t))
+{
+  HOST_WIDE_INT s = tree_to_shwi (TYPE_SIZE_UNIT (t));
+  return s == 1 || s == 2 || s == 4 || s == 8;
+}
+  return false;
+}
+
+/* Return true for types that currently are supported as SIMD return
+   or argum

Re: [C++ Patch] Use locations[ds_storage_class] in error messages about ill-formed uses of mutable

[Martin Sebor]

On 1/15/19 9:58 AM, Paolo Carlini wrote:

Hi,

something a little different from my last patches but nevertheless 
pretty straightforward (noticed while I was wondering whether we should 
immediately move the location_t grokdeclarator local even further up). 
Tested x86_64-linux, as usual.


Since you're already making changes to the tests, would be too much
more work to also add quoting around static and const in the error
messages below where mutable is already quoted:

- error ("static %qs cannot be declared %", name);
+ error_at (sloc, "static %qs cannot be declared %", name);
  storage_class = sc_none;
}
   else if (type_quals & TYPE_QUAL_CONST)
{
- error ("const %qs cannot be declared %", name);
+ error_at (sloc, "const %qs cannot be declared %", name);

(I can see it being a hassle if there were many other tests where
the messages expect to find static and const with no quotes.)

Martin

Go patch committed: panic on uncomparable map key even if map is empty

[Ian Lance Taylor]

This patch to the Go frontend and libgo changes map accesses to panic
on an uncomparable map key, even if the map is empty.  This ports
https://golang.org/cl/155918 from the master repo.  As part of this
change it reorganizes the map type to use a single flag field rather
than different bool fields.  This is a step toward updating libgo to
the Go 1.12beta2 release.  Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 267941)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-0d64279c01a37b2579c0c62ca4f2c3e3f81de07c
+87005025fcd0d7e7908b3aae7062b52cb80eb0f3
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/types.cc
===
--- gcc/go/gofrontend/types.cc  (revision 267941)
+++ gcc/go/gofrontend/types.cc  (working copy)
@@ -5839,6 +5839,25 @@ Struct_type::do_needs_key_update()
   return false;
 }
 
+// Return whether computing the hash value of an instance of this
+// struct type might panic.
+
+bool
+Struct_type::do_hash_might_panic()
+{
+  const Struct_field_list* fields = this->fields_;
+  if (fields == NULL)
+return false;
+  for (Struct_field_list::const_iterator pf = fields->begin();
+   pf != fields->end();
+   ++pf)
+{
+  if (pf->type()->hash_might_panic())
+   return true;
+}
+  return false;
+}
+
 // Return whether this struct type is permitted to be in the heap.
 
 bool
@@ -7979,21 +7998,18 @@ Map_type::make_map_type_descriptor_type(
   Type* ptdt = Type::make_type_descriptor_ptr_type();
   Type* uint8_type = Type::lookup_integer_type("uint8");
   Type* uint16_type = Type::lookup_integer_type("uint16");
-  Type* bool_type = Type::lookup_bool_type();
+  Type* uint32_type = Type::lookup_integer_type("uint32");
 
   Struct_type* sf =
-   Type::make_builtin_struct_type(11,
+   Type::make_builtin_struct_type(8,
   "", tdt,
   "key", ptdt,
   "elem", ptdt,
   "bucket", ptdt,
   "keysize", uint8_type,
-  "indirectkey", bool_type,
   "valuesize", uint8_type,
-  "indirectvalue", bool_type,
   "bucketsize", uint16_type,
-  "reflexivekey", bool_type,
-  "needkeyupdate", bool_type);
+  "flags", uint32_type);
 
   ret = Type::make_builtin_named_type("MapType", sf);
 }
@@ -8011,6 +8027,7 @@ Map_type::do_type_descriptor(Gogo* gogo,
   Type* mtdt = Map_type::make_map_type_descriptor_type();
   Type* uint8_type = Type::lookup_integer_type("uint8");
   Type* uint16_type = Type::lookup_integer_type("uint16");
+  Type* uint32_type = Type::lookup_integer_type("uint32");
 
   int64_t keysize;
   if (!this->key_type_->backend_type_size(gogo, &keysize))
@@ -8078,11 +8095,6 @@ Map_type::do_type_descriptor(Gogo* gogo,
 vals->push_back(Expression::make_integer_int64(keysize, uint8_type, bloc));
 
   ++p;
-  go_assert(p->is_field_name("indirectkey"));
-  vals->push_back(Expression::make_boolean(keysize > Map_type::max_key_size,
-  bloc));
-
-  ++p;
   go_assert(p->is_field_name("valuesize"));
   if (valsize > Map_type::max_val_size)
 vals->push_back(Expression::make_integer_int64(ptrsize, uint8_type, bloc));
@@ -8090,24 +8102,26 @@ Map_type::do_type_descriptor(Gogo* gogo,
 vals->push_back(Expression::make_integer_int64(valsize, uint8_type, bloc));
 
   ++p;
-  go_assert(p->is_field_name("indirectvalue"));
-  vals->push_back(Expression::make_boolean(valsize > Map_type::max_val_size,
-  bloc));
-
-  ++p;
   go_assert(p->is_field_name("bucketsize"));
   vals->push_back(Expression::make_integer_int64(bucketsize, uint16_type,
 bloc));
 
   ++p;
-  go_assert(p->is_field_name("reflexivekey"));
-  vals->push_back(Expression::make_boolean(this->key_type_->is_reflexive(),
-  bloc));
-
-  ++p;
-  go_assert(p->is_field_name("needkeyupdate"));
-  vals->push_back(Expression::make_boolean(this->key_type_->needs_key_update(),
-  bloc));
+  go_assert(p->is_field_name("flags"));
+  // As with the other fields, the flag bits must match the reflect
+  // and runtime packages.
+  unsigned long flags = 0;
+  if (keysize > Map_type::max_key_size)
+flags |= 1;
+  if (valsize > Map_type::max_val_size)
+   

[Committed] PR fortran/81849 -- Host associated vaiables in RESULT spec

[Steve Kargl]

I've committed the following patch as obvious.

2019-01-15  Steven G. Kargl  

PR fortran/81849
* resolve.c (resolve_symbol): Host associated varaibles can appear
in the specification statement of a RESULT array.

2019-01-15  Steven G. Kargl  

PR fortran/81849
* gfortran.dg/pr81849.f90: New test.


Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 267945)
+++ gcc/fortran/resolve.c   (working copy)
@@ -15345,7 +15345,7 @@ resolve_symbol (gfc_symbol *sym)
   /* Set the formal_arg_flag so that check_conflict will not throw
  an error for host associated variables in the specification
  expression for an array_valued function.  */
-  if (sym->attr.function && sym->as)
+  if ((sym->attr.function || sym->attr.result) && sym->as)
 formal_arg_flag = true;
 
   saved_specification_expr = specification_expr;
Index: gcc/testsuite/gfortran.dg/pr81849.f90
===
--- gcc/testsuite/gfortran.dg/pr81849.f90   (nonexistent)
+++ gcc/testsuite/gfortran.dg/pr81849.f90   (working copy)
@@ -0,0 +1,16 @@
+! { dg-do run }
+! PR fortran/81849
+program p
+   implicit none
+   integer  :: n=3
+   if (any(g() /= f())) stop 1
+   contains
+  function g()
+ real g(n)
+ g = 7
+  end function g
+  function f() result(r)
+ real r(n)
+ r = 7
+  end function f
+end program

-- 
Steve

Re: ISO_Fortran_binding patch

[Paul Richard Thomas]

Hi everybody,

I have done the minimum to make the testsuite failures to go
away(thanks, Jakub) and to fix the first (offline) reported bug.
Committed as r267946.

As to the location of ISO_Fortran_binding_2.h, I am open to proposed
fixes. Thomas kindly engineered that part of the original patch since
I have tried to keep my nose out of the configure side of things.

Regards

Paul

2019-01-15  Paul Thomas  

* trans-expr.c (gfc_conv_gfc_desc_to_cfi_desc): Deal with exprs
that are indirect references; ie. dummy arguments.

2019-01-15  Paul Thomas  

* gfortran.dg/ISO_Fortran_binding_2.c : Change reference to
ISO_Fortran_binding_2.h.

On Tue, 15 Jan 2019 at 08:02, Jakub Jelinek  wrote:
>
> On Tue, Jan 15, 2019 at 08:05:59AM +0100, Richard Biener wrote:
> > >It either should
> > >#include "../../../libgfortran/ISO_Fortran_binding.h"
> > >instead or the Fortran *.exp files should arrange for
> > >-I.../libgfortran/
> > >to be added to all gfortran tests.  Because right now it FAILs if you
> > >don't
> > >have ISO_Fortran_binding.h header installed, or succeeds, but includes
> > >header from some other compiler version or even other compiler
> > >altogether.
>
> This still needs to be fixed.
>
> > >Where is that header installed BTW?
> > >Would be best if it got installed in directories like:
> > >$prefix/lib/gcc/$target/$version/include
> > >
> > >See e.g. libssp or libsanitizer, both have something like
> > >target_noncanonical = @target_noncanonical@
> > >libsubincludedir =
> > >$(libdir)/gcc/$(target_noncanonical)/$(gcc_version)/include
> > >nobase_libsubinclude_HEADERS = ssp/ssp.h ssp/string.h ssp/stdio.h
> > >ssp/unistd.h
> > >
> > >You probably want it to go directly in the include dir, so without the
> > >ssp/
> > >or whatever else prefixes.
> >
> > It's there, but also in the multilib locations (which is dubious? Not sure 
> > if we ever search tose include paths)
>
> Yeah, for -m32 it is in
> .../lib/gcc/x86_64-pc-linux-gnu/9.0.0/32/include/
> which isn't that useful; while the finclude/ in there is needed, because
> those are target specific, this header is the same and so it could be
> just in .../9.0.0/include/ always (like e.g. the std*.h headers, intrinsics
> etc.).
>
> Jakub



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

Re: [PATCH] Fix ICE on class-template argument deduction (PR c++/88795)

[Jason Merrill]

On 1/15/19 2:31 PM, David Malcolm wrote:

PR c++/88795 reports an ICE building a function_type for a deduction guide
when the substitution into the function signature fails, due to an
error_mark_node being returned from tsubst_arg_types but not being checked
for.  This error_mark_node gets used as the TYPE_ARG_TYPES, leading to
ICEs in various places that assume this is a TREE_LIST.

This patch checks the result of tsubst_arg_types and propagates the failure
if it returns error_mark_node.  It also adds an assertion to
build_function_type, to fail faster if passed in error_mark_node.

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

OK for trunk?


OK.

Jason

[PATCH] Fix ICE on class-template argument deduction (PR c++/88795)

[David Malcolm]

PR c++/88795 reports an ICE building a function_type for a deduction guide
when the substitution into the function signature fails, due to an
error_mark_node being returned from tsubst_arg_types but not being checked
for.  This error_mark_node gets used as the TYPE_ARG_TYPES, leading to
ICEs in various places that assume this is a TREE_LIST.

This patch checks the result of tsubst_arg_types and propagates the failure
if it returns error_mark_node.  It also adds an assertion to
build_function_type, to fail faster if passed in error_mark_node.

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

OK for trunk?

gcc/cp/ChangeLog:
PR c++/88795
* pt.c (build_deduction_guide): Bail out if tsubst_arg_types
fails.

gcc/testsuite/ChangeLog:
PR c++/88795
* g++.dg/template/pr88795.C: New test.

gcc/ChangeLog:
PR c++/88795
* tree.c (build_function_type): Assert that arg_types is not
error_mark_node.
---
 gcc/cp/pt.c |  2 ++
 gcc/testsuite/g++.dg/template/pr88795.C | 23 +++
 gcc/tree.c  |  2 ++
 3 files changed, 27 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/template/pr88795.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 9473241..ba3b112 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -26909,6 +26909,8 @@ build_deduction_guide (tree ctor, tree outer_args, 
tsubst_flags_t complain)
  targs = template_parms_to_args (tparms);
  fparms = tsubst_arg_types (fparms, tsubst_args, NULL_TREE,
 complain, ctor);
+ if (fparms == error_mark_node)
+   ok = false;
  fargs = tsubst (fargs, tsubst_args, complain, ctor);
  if (ci)
ci = tsubst_constraint_info (ci, tsubst_args, complain, ctor);
diff --git a/gcc/testsuite/g++.dg/template/pr88795.C 
b/gcc/testsuite/g++.dg/template/pr88795.C
new file mode 100644
index 000..918aa6d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/pr88795.C
@@ -0,0 +1,23 @@
+// { dg-do compile { target c++17 } }
+
+template
+struct Array {};
+
+template
+struct Foo {
+  static constexpr int size() {
+  return size_;
+  }
+
+  template
+  Foo(U, Array) {}
+};
+
+template
+Foo(U, Array) -> Foo;
+
+int main() {
+  Array arr{};
+
+  Foo foo{2.0, arr};
+}
diff --git a/gcc/tree.c b/gcc/tree.c
index 2c0a09d..850fc61 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -8455,6 +8455,8 @@ build_function_type (tree value_type, tree arg_types)
   bool any_structural_p, any_noncanonical_p;
   tree canon_argtypes;
 
+  gcc_assert (arg_types != error_mark_node);
+
   if (TREE_CODE (value_type) == FUNCTION_TYPE)
 {
   error ("function return type cannot be function");
-- 
1.8.5.3

Re: C++ PATCH to tweak variadic126.C test (PR c++/88866)

[Jason Merrill]

On 1/15/19 1:27 PM, Marek Polacek wrote:

This test was failing in c++2a because the error messages are different
because we're now trying to parse braced-list in template-argument-list.

Tested on x86_64-linux, ok for trunk?

2019-01-15  Marek Polacek  

PR c++/88866
* g++.dg/cpp0x/variadic126.C: Tweak dg-error.

diff --git gcc/testsuite/g++.dg/cpp0x/variadic126.C 
gcc/testsuite/g++.dg/cpp0x/variadic126.C
index 513c7e54a07..a219309f058 100644
--- gcc/testsuite/g++.dg/cpp0x/variadic126.C
+++ gcc/testsuite/g++.dg/cpp0x/variadic126.C
@@ -3,6 +3,6 @@
  
  template < typename ... > struct A;
  
-struct B : A <			// { dg-error "invalid" }

+struct B : A <  // { dg-error "invalid" "" { target 
c++17_down } }
  {
-};
+}; // { dg-error "mismatch|expected" "" { target c++2a } }


OK.

Jason

Re: [REVISED PATCH 2/9]: C++ P0482R5 char8_t: Core language support

[Jason Merrill]

On 1/15/19 10:50 AM, Tom Honermann wrote:

On 1/15/19 1:51 AM, Christophe Lyon wrote:

On Mon, 14 Jan 2019 at 20:59, Jason Merrill  wrote:

On 12/23/18 9:27 PM, Tom Honermann wrote:
Attached is a revised patch that addresses changes in P0482R6 as 
well as

feedback provided by Jason.  Changes from the prior patch include:
- Updated the value of the __cpp_char8_t feature test macro to 201811
    per P0482R6.
- Enable char8_t support with -std=c++2a per adoption of P0482R6 in
    San Diego.
- Reverted the unnecessary changes to gcc/gcc/c/c-typeck.c as requested
    by Jason.
- Removed unnecessary checks of 'flag_char8_t' within the C++ front
    end as requested by Jason.
- Corrected the regression spotted by Jason regarding initialization of
    signed char and unsigned char arrays with string literals.
- Made minor changes to the error message emitted for ill-formed
    initialization of char arrays with UTF-8 string literals.  These
    changes do not yet implement Jason's suggestion; I'll follow up 
with a

    separate patch for that due to additional test impact.

Tested on x86_64-linux.

I just applied the compiler changes with small modifications, as
follows; thank you very much for the patches.  Jonathan should check in
the library portion before long.

Jason

Hi,

The new testcase g++.dg/ext/utf-cvt-char8_t.C fails at least on arm 
and aarch64:


g++.dg/ext/utf-cvt-char8_t.C  -std=gnu++14  (test for warnings, line 24)
g++.dg/ext/utf-cvt-char8_t.C  -std=gnu++17  (test for warnings, line 24)


Arm and aarch64 have unsigned char by default, so the warning 
("conversion to 'char' from 'char8_t' may change the sign of the 
result") isn't emitted on those platforms.  I presume adding 
'-fsigned-char' to the options for the test would be a sufficient fix? 
If so, a patch is attached.


Applied, thanks.

Jason

C++ PATCH to tweak variadic126.C test (PR c++/88866)

[Marek Polacek]

This test was failing in c++2a because the error messages are different
because we're now trying to parse braced-list in template-argument-list.

Tested on x86_64-linux, ok for trunk?

2019-01-15  Marek Polacek  

PR c++/88866
* g++.dg/cpp0x/variadic126.C: Tweak dg-error.

diff --git gcc/testsuite/g++.dg/cpp0x/variadic126.C 
gcc/testsuite/g++.dg/cpp0x/variadic126.C
index 513c7e54a07..a219309f058 100644
--- gcc/testsuite/g++.dg/cpp0x/variadic126.C
+++ gcc/testsuite/g++.dg/cpp0x/variadic126.C
@@ -3,6 +3,6 @@
 
 template < typename ... > struct A;
 
-struct B : A < // { dg-error "invalid" }
+struct B : A < // { dg-error "invalid" "" { target c++17_down 
} }
 {
-};
+}; // { dg-error "mismatch|expected" "" { target c++2a } }

Re: PATCH: Updated error messages for ill-formed cases of array initialization by string literal

[Joseph Myers]

On Tue, 15 Jan 2019, Jason Merrill wrote:

> I actually incorporated the C++ part of these changes into yesterday's commit,
> using Martin's first suggestion.  Here's the adjusted C patch, which I'd like
> a C maintainer to approve.

The front-end changes are OK.  However, in the testcase changes, some of 
the new expected diagnostics are hardcoding that "unsigned int" is the 
type of char32_t, which isn't correct for all platforms (for example, it's 
definitely not the type when int is 16-bit).  In principle the same 
applies to diagnostics hardcoding the choice of char16_t, although 
variations are at least less likely there.

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

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

[Joseph Myers]

On Mon, 14 Jan 2019, Martin Liška wrote:

> Thanks for review, fixed that in updated version of the patch.
> 
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> 
> Ready to be installed?

This patch is OK.

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

lSJ提//供//税%%栗//

[jcjyify]

gcc-patches@gcc.gnu.org
+
主鼻优 惠 办 理 正 规 税 票，认 证 后 付  款。
  详   电：李 生，136—6075— 4190，
   业   q：157— 533— 2698
---

Re: [PATCH][GCC][AArch64] Fix command line options canonicalization. (PR target/88530)

[Tamar Christina]

Hi Kyrill,

Thanks for the review,

I have respun the patch on top of trunk and
here is the new changelog to account for the
updates of the new extensions.

Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.

Ok for trunk?

Thanks,
Tamar

gcc/ChangeLog:

2019-01-15  Tamar Christina  

PR target/88530
* common/config/aarch64/aarch64-common.c
(struct aarch64_option_extension): Add is_synthetic.
(all_extensions): Use it.
(TARGET_OPTION_INIT_STRUCT): Define hook.
(struct gcc_targetm_common): Moved to end.
(all_extensions_by_on): New.
(opt_ext_cmp, typedef opt_ext): New.
(aarch64_option_init_struct): New.
(aarch64_contains_opt): New.
(aarch64_get_extension_string_for_isa_flags): Output smallest set.
* config/aarch64/aarch64-option-extensions.def
(AARCH64_OPT_EXTENSION): Explicitly include AES and SHA2 in crypto.
(fp, simd, crc, lse, fp16, rcpc, rdma, dotprod, aes, sha2, sha3,
sm4, fp16fml, sve, profile, rng, memtag, sb, ssbs, predres):
Set is_synthetic to false.
(crypto): Set is_synthetic to true.

gcc/testsuite/ChangeLog:

2019-01-15  Tamar Christina  

PR target/88530
* gcc.target/aarch64/options_set_1.c: New test.
* gcc.target/aarch64/options_set_2.c: New test.
* gcc.target/aarch64/options_set_3.c: New test.
* gcc.target/aarch64/options_set_4.c: New test.
* gcc.target/aarch64/options_set_5.c: New test.
* gcc.target/aarch64/options_set_6.c: New test.
* gcc.target/aarch64/options_set_7.c: New test.
* gcc.target/aarch64/options_set_8.c: New test.
* gcc.target/aarch64/options_set_9.c: New test.



The 01/10/2019 17:15, Kyrill Tkachov wrote:
> Hi Tamar,
> 
> On 17/12/18 19:18, Tamar Christina wrote:
> > Hi All,
> >
> > The options don't seem to get canonicalized into the smallest possible set
> > before output to the assembler. This means that overlapping feature sets are
> > emitted with superfluous parts.
> >
> > Normally this isn't an issue, but in the case of crypto we have 
> > retro-actively
> > split it into aes and sha2. We need to emit only +crypto to the assembler
> > so old assemblers continue to work.
> >
> > Because of how -mcpu=native and -march=native work they end up enabling all 
> > feature
> > bits, so we need to get the smallest possible set, which would also fix the
> > problem with older the assemblers and the retro-active split.
> >
> > Admittedly this should be done earlier in options processing, but the 
> > problem
> > with the way AArch64 currently processes options is that where the isa_bits 
> > are
> > determined we don't know which options are part of the default set yet.
> >
> > Which is why we instead do it late in processing when we have all the
> > information.  This however requires us to make a duplicate of the extensions
> > list.
> >
> > The Option handling structures have been extended to have a boolean to 
> > indicate
> > whether the option is synthetic, with that I mean if the option flag itself 
> > has a bit.
> >
> > e.g. +crypto isn't an actual bit, it just enables other bits, but other 
> > features flags
> > like +rdma also enable multiple options but are themselves also a feature.
> >
> > There are two ways to solve this.
> >
> > 1) Either have the options that are feature bits also turn themselves on, 
> > e.g. change
> >rdma to turn on FP, SIMD and RDMA as dependency bits.
> > 2) Make a distinction between these two different type of features and have 
> > the framework
> >handle it correctly.
> >
> > Even though it's more code I went for the second approach, as it's the one 
> > that'll be less
> > fragile and give the least surprises.
> >
> > This is a stop-gap measure that's has the lowest impact and is 
> > back-portable.
> >
> > Effectively this patch changes the following:
> >
> > The values before the => are the old compiler and after the => the new code.
> >
> > -march=armv8.2-a+crypto+sha2 => -march=armv8.2-a+crypto
> > -march=armv8.2-a+sha2+aes => -march=armv8.2-a+crypto
> >
> > The remaining behaviors stay the same.
> >
> >
> > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> >
> > Ok for trunk?
> >
> 
> This will need rebasing over the Armv8.5-A patches as there are new entries 
> in config/aarch64/aarch64-option-extensions.def.
> Since this has to be done anyway, I've also pointed out a few comment typos 
> inline.
> 
> Apart from that, the patch looks good to me (this is a subtle area of GCC).
> 
> Thanks,
> Kyrill
> 
> 
> > Thanks,
> > Tamar
> >
> > gcc/ChangeLog:
> >
> > 2018-12-17  Tamar Christina  
> >
> > PR target/88530
> > * common/config/aarch64/aarch64-common.c
> > (struct aarch64_option_extension): Add is_synthetic.
> > (all_extensions): Use it.
> > (TARGET_OPTION_INIT_STRUCT): Define hook.
> > (struct gcc_targetm_common): Moved to end.
> >   

[PATCH][GCC][Arm] Fix arm big-endian intrinsics regressions.

[Tamar Christina]

Hi All,

We are a bit inconsistent when it comes to lane index endianness on Arm,
we don't seem to always stick to the expected GCC vector extensions index
endianness, for these tests since they are modelled as UNSPEC anyway just
keep the indexes in Arm NEON order.

There are other intrinsics that require an update, but for now these will
fix the new ones.

Bootstrapped Regtested on arm-none-Linux-gnueabihf and no issues.
Cross compiled on armeb-none-eabi and regtested and no issues.
Verified example by hand with execution tests and no issues.

Ok for trunk?

Thanks,
Tamar

gcc/ChangeLog:

2019-01-15  Tamar Christina  

* config/arm/arm-protos.h (neon_vcmla_lane_prepare_operands): Remove 
patternmode.
* config/arm/arm.c (neon_vcmla_lane_prepare_operands): Likewise.
* config/arm/neon.md (neon_vcmla_lane, 
neon_vcmla_laneq,
neon_vcmlaq_lane): Remove endianness conversion.

-- 
diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h
index 2bc43019864ef70ed1bf1e725bad7437cf9b11d8..79ede0db174fcce87abe8b4d18893550d4c7e2f6 100644
--- a/gcc/config/arm/arm-protos.h
+++ b/gcc/config/arm/arm-protos.h
@@ -109,7 +109,7 @@ extern int arm_coproc_mem_operand (rtx, bool);
 extern int neon_vector_mem_operand (rtx, int, bool);
 extern int neon_struct_mem_operand (rtx);
 
-extern rtx *neon_vcmla_lane_prepare_operands (machine_mode, rtx *);
+extern rtx *neon_vcmla_lane_prepare_operands (rtx *);
 
 extern int tls_mentioned_p (rtx);
 extern int symbol_mentioned_p (rtx);
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index cb5e7215e813dc922d606662df3fdc5040fd3524..0b598d20a46ebc6b5c29c782228da045f9a078c1 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -12724,8 +12724,7 @@ neon_struct_mem_operand (rtx op)
 /* Prepares the operands for the VCMLA by lane instruction such that the right
register number is selected.  This instruction is special in that it always
requires a D register, however there is a choice to be made between Dn[0],
-   Dn[1], D(n+1)[0], and D(n+1)[1] depending on the mode of the registers and
-   the PATTERNMODE of the insn.
+   Dn[1], D(n+1)[0], and D(n+1)[1] depending on the mode of the registers.
 
The VCMLA by lane function always selects two values. For instance given D0
and a V2SF, the only valid index is 0 as the values in S0 and S1 will be
@@ -12737,9 +12736,9 @@ neon_struct_mem_operand (rtx op)
updated to contain the right index.  */
 
 rtx *
-neon_vcmla_lane_prepare_operands (machine_mode patternmode, rtx *operands)
+neon_vcmla_lane_prepare_operands (rtx *operands)
 {
-  int lane = NEON_ENDIAN_LANE_N (patternmode, INTVAL (operands[4]));
+  int lane = INTVAL (operands[4]);
   machine_mode constmode = SImode;
   machine_mode mode = GET_MODE (operands[3]);
   int regno = REGNO (operands[3]);
diff --git a/gcc/config/arm/neon.md b/gcc/config/arm/neon.md
index 6f8e7c1cffd2751c1ee7e03ded0410ad3c09c13f..f9d7ba35b137fed383f84eecbe81dd942943d216 100644
--- a/gcc/config/arm/neon.md
+++ b/gcc/config/arm/neon.md
@@ -3494,7 +3494,7 @@
 			 VCMLA)))]
   "TARGET_COMPLEX"
   {
-operands = neon_vcmla_lane_prepare_operands (mode, operands);
+operands = neon_vcmla_lane_prepare_operands (operands);
 return "vcmla.\t%0, %2, d%c3[%c4], #";
   }
   [(set_attr "type" "neon_fcmla")]
@@ -3509,7 +3509,7 @@
 			  VCMLA)))]
   "TARGET_COMPLEX"
   {
-operands = neon_vcmla_lane_prepare_operands (mode, operands);
+operands = neon_vcmla_lane_prepare_operands (operands);
 return "vcmla.\t%0, %2, d%c3[%c4], #";
   }
   [(set_attr "type" "neon_fcmla")]
@@ -3524,7 +3524,7 @@
  VCMLA)))]
   "TARGET_COMPLEX"
   {
-operands = neon_vcmla_lane_prepare_operands (mode, operands);
+operands = neon_vcmla_lane_prepare_operands (operands);
 return "vcmla.\t%0, %2, d%c3[%c4], #";
   }
   [(set_attr "type" "neon_fcmla")]

[C++ Patch] Use locations[ds_storage_class] in error messages about ill-formed uses of mutable

[Paolo Carlini]

Hi,

something a little different from my last patches but nevertheless 
pretty straightforward (noticed while I was wondering whether we should 
immediately move the location_t grokdeclarator local even further up). 
Tested x86_64-linux, as usual.


Thanks, Paolo.

///

/cp
2019-01-15  Paolo Carlini  

* decl.c (grokdeclarator): Use locations[ds_storage_class] in
error messages about ill-formed uses of mutable.

/testsuite
2019-01-15  Paolo Carlini  

* g++.dg/other/pr33558.C: Test location too.
* g++.dg/other/pr33558-2.C: Likewise.
* g++.dg/parse/crash4.C: Likewise.
* g++.old-deja/g++.brendan/err-msg11.C: Likewise.
* g++.old-deja/g++.mike/p7635.C: Likewise.
* g++.old-deja/g++.other/decl6.C: Likewise.
Index: cp/decl.c
===
--- cp/decl.c   (revision 267932)
+++ cp/decl.c   (working copy)
@@ -11902,36 +11902,40 @@ grokdeclarator (const cp_declarator *declarator,
 
   if (storage_class == sc_mutable)
 {
+  location_t sloc = declspecs->locations[ds_storage_class];
   if (decl_context != FIELD || friendp)
{
- error ("non-member %qs cannot be declared %", name);
+ error_at (sloc, "non-member %qs cannot be declared %",
+   name);
  storage_class = sc_none;
}
   else if (decl_context == TYPENAME || typedef_p)
{
- error ("non-object member %qs cannot be declared %", name);
+ error_at (sloc,
+   "non-object member %qs cannot be declared %",
+   name);
  storage_class = sc_none;
}
   else if (TREE_CODE (type) == FUNCTION_TYPE
   || TREE_CODE (type) == METHOD_TYPE)
{
- error ("function %qs cannot be declared %", name);
+ error_at (sloc, "function %qs cannot be declared %", name);
  storage_class = sc_none;
}
   else if (staticp)
{
- error ("static %qs cannot be declared %", name);
+ error_at (sloc, "static %qs cannot be declared %", name);
  storage_class = sc_none;
}
   else if (type_quals & TYPE_QUAL_CONST)
{
- error ("const %qs cannot be declared %", name);
+ error_at (sloc, "const %qs cannot be declared %", name);
  storage_class = sc_none;
}
   else if (TYPE_REF_P (type))
{
- permerror (input_location, "reference %qs cannot be declared "
-"%", name);
+ permerror (sloc, "reference %qs cannot be declared %",
+name);
  storage_class = sc_none;
}
 }
Index: testsuite/g++.dg/other/pr33558-2.C
===
--- testsuite/g++.dg/other/pr33558-2.C  (revision 267931)
+++ testsuite/g++.dg/other/pr33558-2.C  (working copy)
@@ -2,5 +2,5 @@
 /* { dg-options "-fpermissive" } */
 
 class X {
-  mutable int &q; /* { dg-warning "cannot be declared 'mutable'" } */
+  mutable int &q; /* { dg-warning "3:reference .q. cannot be declared 
.mutable." } */
 };
Index: testsuite/g++.dg/other/pr33558.C
===
--- testsuite/g++.dg/other/pr33558.C(revision 267931)
+++ testsuite/g++.dg/other/pr33558.C(working copy)
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
 
 class X {
-  mutable int &q; /* { dg-error "cannot be declared 'mutable'" } */
+  mutable int &q; /* { dg-error "3:reference .q. cannot be declared .mutable." 
} */
 };
Index: testsuite/g++.dg/parse/crash4.C
===
--- testsuite/g++.dg/parse/crash4.C (revision 267931)
+++ testsuite/g++.dg/parse/crash4.C (working copy)
@@ -7,6 +7,6 @@ struct Bar
  {
  void func(void)
  {
-   mutable Bar::type x; // { dg-error "" }
+   mutable Bar::type x; // { dg-error "8:non-member .x. cannot be declared 
.mutable." }
  }
  };
Index: testsuite/g++.old-deja/g++.brendan/err-msg11.C
===
--- testsuite/g++.old-deja/g++.brendan/err-msg11.C  (revision 267931)
+++ testsuite/g++.old-deja/g++.brendan/err-msg11.C  (working copy)
@@ -1,3 +1,3 @@
 // { dg-do assemble  }
 // GROUPS passed error-messages
-void foo (mutable int x);// { dg-error "" }  non-member `x' cannot be declared 
`mutable'.*
+void foo (mutable int x);// { dg-error "11:non-member .x. cannot be declared 
.mutable." }  non-member `x' cannot be declared `mutable'.*
Index: testsuite/g++.old-deja/g++.mike/p7635.C
===
--- testsuite/g++.old-deja/g++.mike/p7635.C (revision 267931)
+++ testsuite/g++.old-deja/g++.mike/p7635.C (working copy)
@@ -3,5 +3,5 @@
 
 class DaycountBasis {
   mutable const int * p;
-  mutable int * const q;   // { dg-error "" } 
+  mutable int * const q;   // { dg-

Re: PING #2 [PATCH] handle expressions in __builtin_has_attribute (PR 88383)

[Martin Sebor]

Ping: https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00337.html

Jeff, do you have any more questions/concerns or is this patch
good to commit?

Martin

On 1/7/19 5:32 PM, Martin Sebor wrote:

Ping: https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00337.html

On 1/3/19 3:22 PM, Martin Sebor wrote:

Ping: https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00337.html

On 12/20/18 7:51 PM, Martin Sebor wrote:

Jeff, did this and the rest of the discussion answer your question
and if so, is the patch okay to commit?

   https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00337.html

Martin

On 12/13/18 12:48 PM, Martin Sebor wrote:

On 12/13/18 12:20 PM, Martin Sebor wrote:

On 12/13/18 11:59 AM, Jeff Law wrote:

On 12/5/18 8:55 PM, Martin Sebor wrote:

The __builtin_has_attribute function fails with an ICE when
its first argument is an expression such as INDIRECT_REF, or
many others.  The code simply assumes it's either a type or
a decl.  The attached patch corrects this oversight.

While testing the fix I also noticed the C++ front end expects
the first operand to be a unary expression, which causes most
other kinds of expressions to be rejected.  The patch fixes
that as well.

Finally, while testing the fix even more I realized that
the built-in considers the underlying array itself in ARRAY_REF
expressions rather than its type, which leads to inconsistent
results for overaligned arrays (it's the array itself that's
overaligned, not its elements).  So I fixed that too and
adjusted the one test designed to verify this.

Tested on x86_64-linux.

Martin

gcc-88383.diff

PR c/88383 - ICE calling __builtin_has_attribute on a reference

gcc/c-family/ChangeLog:

PR c/88383
* c-attribs.c (validate_attribute): Handle expressions.
(has_attribute): Handle types referenced by expressions.
Avoid considering array attributes in ARRAY_REF expressions .

gcc/cp/ChangeLog:

PR c/88383
* parser.c (cp_parser_has_attribute_expression): Handle 
assignment

expressions.

gcc/testsuite/ChangeLog:

PR c/88383
* c-c++-common/builtin-has-attribute-4.c: Adjust expectations.
* c-c++-common/builtin-has-attribute-6.c: New test.
Well, the high level question here is do we want to support this 
builtin
on expressions at all.  Generally attributes apply to types and 
decls,

not expressions.

Clearly we shouldn't fault, but my first inclination is that the
attribute applies to types or decls, not expressions.  In that 
case we

should just be issuing an error.

I could be convinced otherwise, so if you think we should support
passing expressions to this builtin, make your case.


The support is necessary in order to determine the attributes
in expressions such as:

   struct S { __attribute__ ((packed)) int a[32]; };

   extern struct S s;

   _Static_assert (__builtin_has_attribute (s.a, packed));


An example involving types might be a better one:

   typedef __attribute__ ((may_alias)) int* BadInt;

   void f (BadInt *p)
   {
 _Static_assert (__builtin_has_attribute (*p, may_alias));
   }

Martin

Re: PATCH: Add -Waddress-of-packed-member to GCC 9 porting guide

[H.J. Lu]

On Tue, Jan 15, 2019 at 7:05 AM Martin Liška  wrote:
>
> On 1/15/19 3:19 PM, H.J. Lu wrote:
> > On Tue, Jan 15, 2019 at 6:07 AM Martin Liška  wrote:
> >>
> >> On 1/14/19 3:14 PM, H.J. Lu wrote:
> >>> On Mon, Jan 14, 2019 at 5:53 AM Richard Biener
> >>>  wrote:
> 
>  On Mon, Jan 14, 2019 at 2:46 PM H.J. Lu  wrote:
> >
> > This patch adds -Waddress-of-packed-member to GCC 9 porting guide.
> >
> > OK to install?
> 
>  The docs fail to mention what to do when the unaligned pointer is _not_
>  safe to use.  That is, how do I fix
> 
>  struct { char c; int i[4]; } s __attribute__((packed));
>  int foo()
>  {
>    int *p = s.i;
>    return bar (p);
>  }
>  int bar (int *q)
>  {
>    return *q;
>  }
> 
>  for the cases where eliding the pointer isn't easily possible?
> >>>
> >>> You can't have both packed struct and aligned array at the same time.
> >>> The only thing I can say is "don't do it".
> >>>
>  Please also mention the new warning in changes.html
>  (it seems to be enabled by default even?).
> >>>
> >>> I will add a paragraph.
> >>>
> >>> H.J.
>  IIRC the frontends themselves build "bogus" pointer types
>  to aligned data from a simple &s.i[1] because the FIELD_DECLs
>  types are naturally aligned.
> 
>  Richard.
> 
> > Thanks.
> >
> > H.J.
> > ---
> > Index: gcc-9/porting_to.html
> > ===
> > RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/porting_to.html,v
> > retrieving revision 1.1
> > diff -u -r1.1 porting_to.html
> > --- gcc-9/porting_to.html   11 Jan 2019 18:21:45 -  1.1
> > +++ gcc-9/porting_to.html   14 Jan 2019 13:46:07 -
> > @@ -56,13 +56,36 @@
> >}
> >
> >
> > +C/C++ language issues
> > +
> > + > id="Waddress-of-packed-member">-Waddress-of-packed-member
> > +is enabled by default
> > +
> > +
> > +  When address of packed member of struct or union is taken, it may 
> > result
> > +  in an unaligned pointer value.  A new warning
> > +  -Waddress-of-packed-member was added to check alignment 
> > at
> > +  pointer assignment.  It warns both unaligned address and unaligned
> > +  pointer.
> > +
> > +
> > +
> > +  If the pointer value is safe to use, you can suppress
> > +  -Waddress-of-packed-member warnings by using pragmas:
> > +
> > +  
> > +#pragma GCC diagnostic push
> > +#pragma GCC diagnostic ignored "-Waddress-of-packed-member"
> > +/* (code for which the warning is to be disabled)  */
> > +#pragma GCC diagnostic pop
> > +  
> > +
> >  
> >
> >  
> >
> >   >>
> >> It presents the new warning, run-time memory layout dump and also 
> >> sanitizer error.
> >>
> >> Thoughts?
> >
> > This doesn't help port to GCC 9.
> >
> >
>
> But it can still go into changes as example of a code
> for which the warning is triggered.
>
> Thoughts?

How about this?

-- 
H.J.
---
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v
retrieving revision 1.35
diff -u -p -r1.35 changes.html
--- changes.html 15 Jan 2019 13:17:49 - 1.35
+++ changes.html 15 Jan 2019 16:24:18 -
@@ -84,8 +84,29 @@ a work-in-progress.
   
   -Waddress-of-packed-member, enabled by default,
   warns about an unaligned pointer value from the address of a packed
-  member of a struct or union.
-  
+  member of a struct or union:
+  
+$ cat packed.c
+struct packed
+{
+  char c;
+  int i;
+} __attribute__ ((packed));
+
+int *
+foo (struct packed *p)
+{
+  return &p->i;
+}
+$ gcc -O2 -S packed.c
+packed.c: In function ‘foo’:
+packed.c:10:10: warning: taking address of packed member of ‘struct
packed’ may result in an unaligned pointer value
[-Waddress-of-packed-member]
+   10 |   return &p->i;
+  |  ^
+$
+  
+  since the pointer returned from function foo may not be an aligned
+  pointer for int.
   
 

Re: Set inline-unit-growth to 40

[Qing Zhao]

Okay, I see.
thanks.

Qing
> On Jan 15, 2019, at 9:14 AM, Jan Hubicka  wrote:
> 
>> Hi, Honza,
>> 
>> in addition to the code size problems, there are several runtime regression 
>> for the SPEC: (If I read the table correctly, if not, let me know)
>> 
>> SPEC/SPEC2006/INT/483.xalancbmk 
>>  146.131 
>> 4.89%
> 
> This test seems to be just a noise, if you look on the mainline plots
> there is no noticeable regression and you can see differences +- 4% in
> last 10 runs.
>> 
>> SPEC/SPEC2006/FP/436.cactusADM 
>>   
>> 130.967 8.07%   
>> 
>> SPEC/SPEC2017/INT/520.omnetpp_r 
>>  395.582 
>> 4.98%   
> 
> Here you can see in the graph both boxes to be yellow which means that
> binary did not changed nor the size changed. It is just measurement error it 
> seems.
>> 
>> SPEC/SPEC2006/FP/435.gromacs 
>>  
>> 182.555 11.73%  
> 
> I plan to check on gromacs
> This is LTO+PGO which will be rerun only in day or two so I will see if
> the same regression stays on mainline.
>> 
>> SPEC/SPEC2017/INT/541.leela_r 
>>    
>> 452.333 4.17%   
> 
> This was already taken by daily testers and regression does not
> reproduce, so it seems to be noise too.
> 
> Honza
>> 
>> do we have plan to study and fix these run-time regression?
> 
>> 
>> thanks.
>> 
>> Qing
>> 
>>> On Jan 12, 2019, at 12:32 PM, Jan Hubicka  wrote:
>>> 
>>> Hello,
>>> this patch sets inline-unit-growth to 40.  The performance changes are
>>> - Firefox, LTO
>>> https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=f7bd026e1a931b9a284d1c85c2577a72dd592820&newProject=try&newRevision=74889968abcc688b8d161863566ed273c0401ee4&framework=1&filter=opt&showOnlyComparable=1&showOnlyImportant=1
>>> After fixes to inlining priorities this makes difference without
>>> profile feedback only.
>>> 
>>> Code size growth is about 9.15% with LTO and 3.95 with LTO and profile
>>> feedback.
>>> - Firefox noLTO
>>> https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=c902b72340a3dca3114f58578c1c8f3e6a1cd89c&newProject=try&newRevision=4974da6f92c144a9c09765b56a564a640069ddb9&framework=1&showOnlyComparable=1&showOnlyImportant=1
>>> With about 7% code size growth
>>> - SPEC
>>> https://lnt.opensuse.org/db_default/v4/CPP/latest_runs_report?num_runs=10&min_percentage_change=0.02&revisions=46e2bd1143b5c60af814916d7673879b34ceb3f6%2Cc0d79cfe9c4ec30823480f2f9b256600e8e3899f
>>> - C++ benchmarks
>>> https://lnt.opensuse.org/db_default/v4/SPEC/latest_runs_report?num_runs=10&all_changes=on&min_percentage_change=0.02&revisions=46e2bd1143b5c60af814916d7673879b34ceb3f6%2Cc0d79cfe9c4ec30823480f2f9b256600e8e3899f
>>> 
>>> I am not entirely happy about the code-size/performance tradeoffs but it
>>> is concerned only for programs built with -O3 or having too many inline
>>> keywords.  I have looked into inlining decisions for Firefox, HHVM and
>>> Clang and inliner gets out of growt bounds way too early and some of
>>> more performance aware projects already sets the limit up.
>>> 
>>> I will tune other metrics down to handle some of the code size problems.
>>> 
>>> Honza
>>> 
>>> Index: ChangeLog
>>> ===
>>> --- ChangeLog   (revision 267882)
>>> +++ ChangeLog   (working copy)
>>> @@ -1,3 +1,7 @@
>>> +2019-01-05  Jan Hubicka  
>>> +
>>> +   * params.def (inline-unit-growth): Set to 40.
>>> +
>>> 2019-01-12  Jakub Jelinek  
>>> 
>>> * tree-ssa-loop-ivopts.c (find_inv_vars): Fix a comment typo.
>>> Index: params.def
>>> ===
>>> --- params.def  (revision 267882)
>>> +++ params.def  (working copy)
>>> @@ -227,7 +227,7 @@ DEFPARAM(PARAM_LARGE_UNIT_INSNS,
>>> DEFPARAM(PARAM_INLINE_UNIT_GROWTH,
>>>  "inline-unit-growth",
>>>  "How much can given compilation unit grow because of the inlining (in 
>>> percent).",
>>> -20, 0, 0)
>>> +40, 0, 0)
>>> DEFPARAM(PARAM_IPCP_UNIT_GROWTH,
>>>  "ipcp-unit-growth",
>>>  "How much can given compilation unit grow because of the 
>>> interprocedural constant propagation (in percent).",
>> 

Re: PATCH: Updated error messages for ill-formed cases of array initialization by string literal

[Marek Polacek]

On Tue, Jan 15, 2019 at 10:15:22AM -0500, Jason Merrill wrote:
> On 1/14/19 11:09 PM, Tom Honermann wrote:
> > On 1/4/19 7:25 PM, Martin Sebor wrote:
> > > On 12/27/18 1:49 PM, Tom Honermann wrote:
> > > > As requested by Jason in the review of the P0482 (char8_t) core
> > > > language changes, this patch includes updates to the error
> > > > messages emitted for ill-formed cases of array initialization
> > > > with a string literal.  With these changes, error messages that
> > > > previously looked something like these:
> > > > 
> > > > - "char-array initialized from wide string"
> > > > - "wide character array initialized from non-wide string"
> > > > - "wide character array initialized from incompatible wide string"
> > > > 
> > > > now look like:
> > > > 
> > > > - "cannot initialize array of type 'char' from a string literal
> > > > with type array of 'short unsigned int'"
> > > 
> > > The first word "type" doesn't quite work here.  The type of every
> > > array is "array of T" where T is the type of the element, so for
> > > instance, "array of char."  Saying "array of type X" makes it sound
> > > like X is the type of the whole array, which is of course not
> > > the case when X is char.  I think you want to use the same wording
> > > as for the second type:
> > > 
> > >   "cannot initialize array of 'char' from a string literal with
> > >   type array of 'short unsigned int'"
> > > 
> > > or perhaps even better
> > > 
> > >   "cannot initialize array of 'char' from a string literal with
> > >   type 'char16_t[N]'"
> > > 
> > > (i.e., show the actual type of the string, including its bound).
> > 
> > Thank you for the feedback, Martin; sorry for the delayed response. I'll
> > follow up with a revised patch within the next week or two.
> 
> I actually incorporated the C++ part of these changes into yesterday's
> commit, using Martin's first suggestion.  Here's the adjusted C patch, which
> I'd like a C maintainer to approve.

Patch is OK, thanks.

Marek

Re: [REVISED PATCH 2/9]: C++ P0482R5 char8_t: Core language support

[Tom Honermann]

On 1/15/19 1:51 AM, Christophe Lyon wrote:

On Mon, 14 Jan 2019 at 20:59, Jason Merrill  wrote:

On 12/23/18 9:27 PM, Tom Honermann wrote:

Attached is a revised patch that addresses changes in P0482R6 as well as
feedback provided by Jason.  Changes from the prior patch include:
- Updated the value of the __cpp_char8_t feature test macro to 201811
per P0482R6.
- Enable char8_t support with -std=c++2a per adoption of P0482R6 in
San Diego.
- Reverted the unnecessary changes to gcc/gcc/c/c-typeck.c as requested
by Jason.
- Removed unnecessary checks of 'flag_char8_t' within the C++ front
end as requested by Jason.
- Corrected the regression spotted by Jason regarding initialization of
signed char and unsigned char arrays with string literals.
- Made minor changes to the error message emitted for ill-formed
initialization of char arrays with UTF-8 string literals.  These
changes do not yet implement Jason's suggestion; I'll follow up with a
separate patch for that due to additional test impact.

Tested on x86_64-linux.

I just applied the compiler changes with small modifications, as
follows; thank you very much for the patches.  Jonathan should check in
the library portion before long.

Jason

Hi,

The new testcase g++.dg/ext/utf-cvt-char8_t.C fails at least on arm and aarch64:

g++.dg/ext/utf-cvt-char8_t.C  -std=gnu++14  (test for warnings, line 24)
g++.dg/ext/utf-cvt-char8_t.C  -std=gnu++17  (test for warnings, line 24)


Arm and aarch64 have unsigned char by default, so the warning 
("conversion to 'char' from 'char8_t' may change the sign of the 
result") isn't emitted on those platforms.  I presume adding 
'-fsigned-char' to the options for the test would be a sufficient fix?  
If so, a patch is attached.


Tom.



Christophe



Index: gcc/testsuite/g++.dg/ext/utf-cvt-char8_t.C
===
--- gcc/testsuite/g++.dg/ext/utf-cvt-char8_t.C	(revision 267930)
+++ gcc/testsuite/g++.dg/ext/utf-cvt-char8_t.C	(working copy)
@@ -1,7 +1,7 @@
 /* Contributed by Kris Van Hees  */
 /* Test the char8_t promotion rules. */
 /* { dg-do compile { target c++11 } } */
-/* { dg-options "-fchar8_t -Wall -Wconversion -Wsign-conversion -Wsign-promo" } */
+/* { dg-options "-fchar8_t -fsigned-char -Wall -Wconversion -Wsign-conversion -Wsign-promo" } */
 
 extern void f_c (char);
 extern void fsc (signed char);

[PATCH] FIx PR88855

[Richard Biener]

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

Richard.

2019-01-15  Richard Biener  

PR tree-optimization/88855
* tree-if-conv.c (combine_blocks): Collect
SSA_NAME_OCCURS_IN_ABNORMAL_PHI from propagated out virtuals.

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

Index: gcc/tree-if-conv.c
===
--- gcc/tree-if-conv.c  (revision 267930)
+++ gcc/tree-if-conv.c  (working copy)
@@ -2633,6 +2633,8 @@ combine_blocks (struct loop *loop)
  FOR_EACH_IMM_USE_ON_STMT (use_p, iter)
SET_USE (use_p, last_vdef);
}
+ if (SSA_NAME_OCCURS_IN_ABNORMAL_PHI (gimple_phi_result (vphi)))
+   SSA_NAME_OCCURS_IN_ABNORMAL_PHI (last_vdef) = 1;
  gsi = gsi_for_stmt (vphi); 
  remove_phi_node (&gsi, true);
}
@@ -2691,6 +2693,8 @@ combine_blocks (struct loop *loop)
  FOR_EACH_IMM_USE_ON_STMT (use_p, iter)
SET_USE (use_p, last_vdef);
}
+ if (SSA_NAME_OCCURS_IN_ABNORMAL_PHI (gimple_phi_result (vphi)))
+   SSA_NAME_OCCURS_IN_ABNORMAL_PHI (last_vdef) = 1;
  gimple_stmt_iterator gsi = gsi_for_stmt (vphi); 
  remove_phi_node (&gsi, true);
}
Index: gcc/testsuite/gcc.dg/pr88855.c
===
--- gcc/testsuite/gcc.dg/pr88855.c  (nonexistent)
+++ gcc/testsuite/gcc.dg/pr88855.c  (working copy)
@@ -0,0 +1,21 @@
+/* { dg-do compile } */
+/* { dg-options "-O -ftree-loop-if-convert -ftree-vrp -fno-tree-copy-prop 
-fno-tree-dce -fno-tree-dominator-opts" } */
+
+typedef int jmp_buf[1];
+
+extern void exit(int) __attribute__((__noreturn__));
+extern int setjmpx(jmp_buf) __attribute__((__returns_twice__));
+
+jmp_buf jbAnagram;
+int a[6];
+int d;
+int b () { exit (1); }
+int c () { b (); }
+int e ()
+{
+  int f = 0;
+  for (; f < 6; f++)
+a[f] = d;
+  c ();
+  setjmpx (jbAnagram);
+}

Re: [PATCH][AArch64] Initial -mcpu=ares tuning

[Kyrill Tkachov]

Apologies for the duplicate. I've had issues with my mail client
They are both identical submissions.

Kyrill
On 15/01/19 15:29, Kyrill Tkachov wrote:

Hi all,

This patch adds a tuning struct for the Arm Ares CPU and uses it for 
-m{cpu,tune}=ares.
The tunings are an initial attempt and may be improved upon in the future, but 
they serve
as a decent starting point for GCC 9.

With this I see a 1.3% improvement on SPEC2006 int and 0.3% on SPEC2006 fp with 
-mcpu=ares.
On SPEC2017 I see a 0.6% improvement in intrate and changes in the noise for 
fprate.

Bootstrapped and tested on aarch64-none-linux-gnu.

Ok for trunk?
Thanks,
Kyrill

2019-01-15  Kyrylo Tkachov  

 * config/aarch64/aarch64.c (ares_tunings): Define.
 * config/aarch64/aarch64-cores.def (ares): Use the above.

[PATCH][AArch64] Initial -mcpu=ares tuning

[Kyrill Tkachov]

Hi all,

This patch adds a tuning struct for the Arm Ares CPU and uses it for 
-m{cpu,tune}=ares.
The tunings are an initial attempt and may be improved upon in the future, but 
they serve
as a decent starting point for GCC 9.

With this I see a 1.3% improvement on SPEC2006 int and 0.3% on SPEC2006 fp with 
-mcpu=ares.
On SPEC2017 I see a 0.6% improvement in intrate and changes in the noise for 
fprate.

Bootstrapped and tested on aarch64-none-linux-gnu.

Ok for trunk?
Thanks,
Kyrill

2019-01-15  Kyrylo Tkachov  

* config/aarch64/aarch64.c (ares_tunings): Define.
* config/aarch64/aarch64-cores.def (ares): Use the above.
diff --git a/gcc/config/aarch64/aarch64-cores.def b/gcc/config/aarch64/aarch64-cores.def
index 70b076694d9901ccf15bfd26c950b6466d3d1cc2..7c4bd52049e5ae33241acce37414da91abaa989c 100644
--- a/gcc/config/aarch64/aarch64-cores.def
+++ b/gcc/config/aarch64/aarch64-cores.def
@@ -100,7 +100,7 @@ AARCH64_CORE("thunderx2t99",  thunderx2t99,  thunderx2t99, 8_1A,  AARCH64_FL_FOR
 AARCH64_CORE("cortex-a55",  cortexa55, cortexa53, 8_2A,  AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_F16 | AARCH64_FL_RCPC | AARCH64_FL_DOTPROD, cortexa53, 0x41, 0xd05, -1)
 AARCH64_CORE("cortex-a75",  cortexa75, cortexa57, 8_2A,  AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_F16 | AARCH64_FL_RCPC | AARCH64_FL_DOTPROD, cortexa73, 0x41, 0xd0a, -1)
 AARCH64_CORE("cortex-a76",  cortexa76, cortexa57, 8_2A,  AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_F16 | AARCH64_FL_RCPC | AARCH64_FL_DOTPROD, cortexa72, 0x41, 0xd0b, -1)
-AARCH64_CORE("ares",  ares, cortexa57, 8_2A,  AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_F16 | AARCH64_FL_RCPC | AARCH64_FL_DOTPROD | AARCH64_FL_PROFILE, cortexa72, 0x41, 0xd0c, -1)
+AARCH64_CORE("ares",  ares, cortexa57, 8_2A,  AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_F16 | AARCH64_FL_RCPC | AARCH64_FL_DOTPROD | AARCH64_FL_PROFILE, ares, 0x41, 0xd0c, -1)
 
 /* HiSilicon ('H') cores. */
 AARCH64_CORE("tsv110",  tsv110, cortexa57, 8_2A,  AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_CRYPTO | AARCH64_FL_F16 | AARCH64_FL_AES | AARCH64_FL_SHA2, tsv110,   0x48, 0xd01, -1)
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 2fd6bb9821a256eaa2acaee305926b4efebf9c8c..b1e5eacb69728741517e313b110ebbc203d415a4 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -1083,6 +1083,32 @@ static const struct tune_params thunderx2t99_tunings =
   &thunderx2t99_prefetch_tune
 };
 
+static const struct tune_params ares_tunings =
+{
+  &cortexa57_extra_costs,
+  &generic_addrcost_table,
+  &generic_regmove_cost,
+  &cortexa57_vector_cost,
+  &generic_branch_cost,
+  &generic_approx_modes,
+  SVE_NOT_IMPLEMENTED, /* sve_width  */
+  4, /* memmov_cost  */
+  3, /* issue_rate  */
+  AARCH64_FUSE_AES_AESMC, /* fusible_ops  */
+  "32:16",	/* function_align.  */
+  "32:16",	/* jump_align.  */
+  "32:16",	/* loop_align.  */
+  2,	/* int_reassoc_width.  */
+  4,	/* fp_reassoc_width.  */
+  2,	/* vec_reassoc_width.  */
+  2,	/* min_div_recip_mul_sf.  */
+  2,	/* min_div_recip_mul_df.  */
+  0,	/* max_case_values.  */
+  tune_params::AUTOPREFETCHER_WEAK,	/* autoprefetcher_model.  */
+  (AARCH64_EXTRA_TUNE_NONE),	/* tune_flags.  */
+  &generic_prefetch_tune
+};
+
 /* Support for fine-grained override of the tuning structures.  */
 struct aarch64_tuning_override_function
 {

[PATCH][AArch64] Initial -mcpu=ares tuning

[Kyrill Tkachov]

Hi all,

This patch adds a tuning struct for the Arm Ares CPU and uses it for 
-m{cpu,tune}=ares.
The tunings are an initial attempt and may be improved upon in the future, but 
they serve
as a decent starting point for GCC 9.

With this I see a 1.3% improvement on SPEC2006 int and 0.3% on SPEC2006 fp with 
-mcpu=ares.
On SPEC2017 I see a 0.6% improvement in intrate and changes in the noise for 
fprate.

Bootstrapped and tested on aarch64-none-linux-gnu.

Ok for trunk?
Thanks,
Kyrill

2019-01-15  Kyrylo Tkachov  

* config/aarch64/aarch64.c (ares_tunings): Define.
* config/aarch64/aarch64-cores.def (ares): Use the above.
diff --git a/gcc/config/aarch64/aarch64-cores.def b/gcc/config/aarch64/aarch64-cores.def
index 70b076694d9901ccf15bfd26c950b6466d3d1cc2..7c4bd52049e5ae33241acce37414da91abaa989c 100644
--- a/gcc/config/aarch64/aarch64-cores.def
+++ b/gcc/config/aarch64/aarch64-cores.def
@@ -100,7 +100,7 @@ AARCH64_CORE("thunderx2t99",  thunderx2t99,  thunderx2t99, 8_1A,  AARCH64_FL_FOR
 AARCH64_CORE("cortex-a55",  cortexa55, cortexa53, 8_2A,  AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_F16 | AARCH64_FL_RCPC | AARCH64_FL_DOTPROD, cortexa53, 0x41, 0xd05, -1)
 AARCH64_CORE("cortex-a75",  cortexa75, cortexa57, 8_2A,  AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_F16 | AARCH64_FL_RCPC | AARCH64_FL_DOTPROD, cortexa73, 0x41, 0xd0a, -1)
 AARCH64_CORE("cortex-a76",  cortexa76, cortexa57, 8_2A,  AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_F16 | AARCH64_FL_RCPC | AARCH64_FL_DOTPROD, cortexa72, 0x41, 0xd0b, -1)
-AARCH64_CORE("ares",  ares, cortexa57, 8_2A,  AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_F16 | AARCH64_FL_RCPC | AARCH64_FL_DOTPROD | AARCH64_FL_PROFILE, cortexa72, 0x41, 0xd0c, -1)
+AARCH64_CORE("ares",  ares, cortexa57, 8_2A,  AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_F16 | AARCH64_FL_RCPC | AARCH64_FL_DOTPROD | AARCH64_FL_PROFILE, ares, 0x41, 0xd0c, -1)
 
 /* HiSilicon ('H') cores. */
 AARCH64_CORE("tsv110",  tsv110, cortexa57, 8_2A,  AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_CRYPTO | AARCH64_FL_F16 | AARCH64_FL_AES | AARCH64_FL_SHA2, tsv110,   0x48, 0xd01, -1)
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 2fd6bb9821a256eaa2acaee305926b4efebf9c8c..b1e5eacb69728741517e313b110ebbc203d415a4 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -1083,6 +1083,32 @@ static const struct tune_params thunderx2t99_tunings =
   &thunderx2t99_prefetch_tune
 };
 
+static const struct tune_params ares_tunings =
+{
+  &cortexa57_extra_costs,
+  &generic_addrcost_table,
+  &generic_regmove_cost,
+  &cortexa57_vector_cost,
+  &generic_branch_cost,
+  &generic_approx_modes,
+  SVE_NOT_IMPLEMENTED, /* sve_width  */
+  4, /* memmov_cost  */
+  3, /* issue_rate  */
+  AARCH64_FUSE_AES_AESMC, /* fusible_ops  */
+  "32:16",	/* function_align.  */
+  "32:16",	/* jump_align.  */
+  "32:16",	/* loop_align.  */
+  2,	/* int_reassoc_width.  */
+  4,	/* fp_reassoc_width.  */
+  2,	/* vec_reassoc_width.  */
+  2,	/* min_div_recip_mul_sf.  */
+  2,	/* min_div_recip_mul_df.  */
+  0,	/* max_case_values.  */
+  tune_params::AUTOPREFETCHER_WEAK,	/* autoprefetcher_model.  */
+  (AARCH64_EXTRA_TUNE_NONE),	/* tune_flags.  */
+  &generic_prefetch_tune
+};
+
 /* Support for fine-grained override of the tuning structures.  */
 struct aarch64_tuning_override_function
 {

Re: [PATCH] avoid issuing -Warray-bounds during folding (PR 88800)

[Martin Sebor]

On 1/15/19 4:07 AM, Richard Biener wrote:

On Tue, Jan 15, 2019 at 1:08 AM Martin Sebor  wrote:


The gimple_fold_builtin_memory_op() function folds calls to memcpy
and similar to MEM_REF when the size of the copy is a small power
of 2, but it does so without considering whether the copy might
write (or read) past the end of one of the objects.  To detect
these kinds of errors (and help distinguish them from -Westrict)
the folder calls into the wrestrict pass and lets it diagnose them.
Unfortunately, that can lead to false positives for even some fairly
straightforward code that is ultimately found to be unreachable.
PR 88800 is a report of one such problem.

To avoid these false positives the attached patch adjusts
the function to avoid issuing -Warray-bounds for out-of-bounds
calls to memcpy et al.  Instead, the patch disables the folding
of such invalid calls (and only those).  Those that are not
eliminated during DCE or other subsequent passes are eventually
diagnosed by the wrestrict pass.

Since this change required removing the dependency of the detection
on the warning options (originally done as a micro-optimization to
avoid spending compile-time cycles on something that wasn't needed)
the patch also adds tests to verify that code generation is not
affected as a result of warnings being enabled or disabled.  With
the patch as is, the invalid memcpy calls end up emitted (currently
they are folded into equally invalid MEM_REFs).  At some point,
I'd like us to consider whether they should be replaced with traps
(possibly under the control of  as has been proposed a number of
times in the past.  If/when that's done, these tests will need to
be adjusted to look for traps instead.

Tested on x86_64-linux.


I've said in the past that I feel delaying of folding is wrong.

To understand, the PR is about emitting a warning for out-of-bound
accesses in a dead code region?


Yes.  I am keeping in my mind your preference of not delaying
the folding of valid code.



If we think delaying/disablign the folding is the way to go the
patch looks OK.


I do, at least for now.  I'm taking this as your approval to commit
the patch (please let me know if you didn't mean it that way).

Martin

Re: [PATCH] x86: Revert patches to fix PR target/88794

[Jakub Jelinek]

On Tue, Jan 15, 2019 at 04:14:06PM +0100, Uros Bizjak wrote:
> On Tue, Jan 15, 2019 at 3:40 PM Wei Xiao  wrote:
> >
> > Hi,
> >
> > It turns out that the Intel 64 and IA-32 Architectures Software Developer
> > Manuals (SDM) description about the fixupimm intrinsic is incorrect. So we 
> > need
> > to revert 3 patches related to it: r265827, r266026 and r267160.
> > Sorry for the inconvenience.
> >
> > Is it ok?
> 
> Yes, but please test the compiler after the revert. Please also create
> a runtime testcase out of the testcase in the PR.

For r267160, I'd expect you want to revert just the config/i386/ part and
keep the testcases, they should work even with the changes reverted, right?

Jakub

Re: PATCH: Updated error messages for ill-formed cases of array initialization by string literal

[Jason Merrill]

On 1/14/19 11:09 PM, Tom Honermann wrote:

On 1/4/19 7:25 PM, Martin Sebor wrote:

On 12/27/18 1:49 PM, Tom Honermann wrote:
As requested by Jason in the review of the P0482 (char8_t) core 
language changes, this patch includes updates to the error messages 
emitted for ill-formed cases of array initialization with a string 
literal.  With these changes, error messages that previously looked 
something like these:


- "char-array initialized from wide string"
- "wide character array initialized from non-wide string"
- "wide character array initialized from incompatible wide string"

now look like:

- "cannot initialize array of type 'char' from a string literal with 
type array of 'short unsigned int'"


The first word "type" doesn't quite work here.  The type of every
array is "array of T" where T is the type of the element, so for
instance, "array of char."  Saying "array of type X" makes it sound
like X is the type of the whole array, which is of course not
the case when X is char.  I think you want to use the same wording
as for the second type:

  "cannot initialize array of 'char' from a string literal with
  type array of 'short unsigned int'"

or perhaps even better

  "cannot initialize array of 'char' from a string literal with
  type 'char16_t[N]'"

(i.e., show the actual type of the string, including its bound).


Thank you for the feedback, Martin; sorry for the delayed response. I'll 
follow up with a revised patch within the next week or two.


I actually incorporated the C++ part of these changes into yesterday's 
commit, using Martin's first suggestion.  Here's the adjusted C patch, 
which I'd like a C maintainer to approve.


Jason
commit dc77155cc9868b6b5e7c634fd46813b81361e7ee
Author: Jason Merrill 
Date:   Wed Jan 9 15:01:53 2019 -0500

Improve the C error for mismatched array string literal initialization.

* c-typeck.c (digest_init): Revised the error message produced for
ill-formed cases of array initialization with a string literal.

diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index 63d177f7a6f..c7c5c627c2e 100644
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -7722,6 +7722,7 @@ digest_init (location_t init_loc, tree type, tree init, tree origtype,
 	{
 	  struct c_expr expr;
 	  tree typ2 = TYPE_MAIN_VARIANT (TREE_TYPE (TREE_TYPE (inside_init)));
+	  bool incompat_string_cst = false;
 	  expr.value = inside_init;
 	  expr.original_code = (strict_string ? STRING_CST : ERROR_MARK);
 	  expr.original_type = NULL;
@@ -7738,27 +7739,18 @@ digest_init (location_t init_loc, tree type, tree init, tree origtype,
 	  if (char_array)
 	{
 	  if (typ2 != char_type_node)
-		{
-		  error_init (init_loc, "char-array initialized from wide "
-			  "string");
-		  return error_mark_node;
-		}
-	}
-	  else
-	{
-	  if (typ2 == char_type_node)
-		{
-		  error_init (init_loc, "wide character array initialized "
-			  "from non-wide string");
-		  return error_mark_node;
-		}
-	  else if (!comptypes(typ1, typ2))
-		{
-		  error_init (init_loc, "wide character array initialized "
-			  "from incompatible wide string");
-		  return error_mark_node;
-		}
+		incompat_string_cst = true;
 	}
+	  else if (!comptypes (typ1, typ2))
+	incompat_string_cst = true;
+
+  if (incompat_string_cst)
+{
+	  error_init (init_loc, "cannot initialize array of %qT from "
+			  "a string literal with type array of %qT",
+			  typ1, typ2);
+	  return error_mark_node;
+}
 
 	  if (TYPE_DOMAIN (type) != NULL_TREE
 	  && TYPE_SIZE (type) != NULL_TREE
diff --git a/gcc/testsuite/gcc.dg/init-string-2.c b/gcc/testsuite/gcc.dg/init-string-2.c
index 9efd44b3d2f..9b11073c913 100644
--- a/gcc/testsuite/gcc.dg/init-string-2.c
+++ b/gcc/testsuite/gcc.dg/init-string-2.c
@@ -28,8 +28,8 @@ uchar a8[] = "foo"; /* { dg-error "string constant" "a8" } */
 const schar a9[] = "foo"; /* { dg-error "string constant" "a9" } */
 short a10[] = L"foo"; /* { dg-error "string constant" "a10" } */
 const sshrt a11[] = L"foo"; /* { dg-error "string constant" "a11" } */
-char a12[] = L"foo"; /* { dg-error "from wide string" "a12" } */
-wchar_t a13[] = "foo"; /* { dg-error "non-wide string" "a13" } */
+char a12[] = L"foo"; /* { dg-error "from a string literal with type array of .short unsigned int." "a12" } */
+wchar_t a13[] = "foo"; /* { dg-error "from a string literal with type array of .char." "a13" } */
 
 char b0[] = { "foo" };
 const signed char b2[4] = { "foo" };
@@ -43,8 +43,8 @@ uchar b8[] = { "foo" }; /* { dg-error "string constant" "b8" } */
 const schar b9[] = { "foo" }; /* { dg-error "string constant" "b9" } */
 short b10[] = { L"foo" }; /* { dg-error "string constant" "b10" } */
 const sshrt b11[] = { L"foo" }; /* { dg-error "string constant" "b11" } */
-char b12[] = { L"foo" }; /* { dg-error "from wide string" "b12" } */
-wchar_t b13[] = { "foo" }; /* { dg-error "non-wide string" "b13" } */
+char b12[] = { L"foo" }; /* {

Re: Set inline-unit-growth to 40

[Jan Hubicka]

> Hi, Honza,
> 
> in addition to the code size problems, there are several runtime regression 
> for the SPEC: (If I read the table correctly, if not, let me know)
> 
> SPEC/SPEC2006/INT/483.xalancbmk 
>   146.131 
> 4.89%

This test seems to be just a noise, if you look on the mainline plots
there is no noticeable regression and you can see differences +- 4% in
last 10 runs.
> 
> SPEC/SPEC2006/FP/436.cactusADM 
>    
> 130.967 8.07%   
> 
> SPEC/SPEC2017/INT/520.omnetpp_r 
>   395.582 
> 4.98%   

Here you can see in the graph both boxes to be yellow which means that
binary did not changed nor the size changed. It is just measurement error it 
seems.
> 
> SPEC/SPEC2006/FP/435.gromacs 
>   
> 182.555 11.73%  

I plan to check on gromacs
This is LTO+PGO which will be rerun only in day or two so I will see if
the same regression stays on mainline.
> 
> SPEC/SPEC2017/INT/541.leela_r 
> 
> 452.333 4.17%   

This was already taken by daily testers and regression does not
reproduce, so it seems to be noise too.

Honza
> 
> do we have plan to study and fix these run-time regression?

> 
> thanks.
> 
> Qing
> 
> > On Jan 12, 2019, at 12:32 PM, Jan Hubicka  wrote:
> > 
> > Hello,
> > this patch sets inline-unit-growth to 40.  The performance changes are
> > - Firefox, LTO
> >  
> > https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=f7bd026e1a931b9a284d1c85c2577a72dd592820&newProject=try&newRevision=74889968abcc688b8d161863566ed273c0401ee4&framework=1&filter=opt&showOnlyComparable=1&showOnlyImportant=1
> >  After fixes to inlining priorities this makes difference without
> >  profile feedback only.
> > 
> >  Code size growth is about 9.15% with LTO and 3.95 with LTO and profile
> >  feedback.
> > - Firefox noLTO
> >  
> > https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=c902b72340a3dca3114f58578c1c8f3e6a1cd89c&newProject=try&newRevision=4974da6f92c144a9c09765b56a564a640069ddb9&framework=1&showOnlyComparable=1&showOnlyImportant=1
> >  With about 7% code size growth
> > - SPEC
> >  
> > https://lnt.opensuse.org/db_default/v4/CPP/latest_runs_report?num_runs=10&min_percentage_change=0.02&revisions=46e2bd1143b5c60af814916d7673879b34ceb3f6%2Cc0d79cfe9c4ec30823480f2f9b256600e8e3899f
> > - C++ benchmarks
> >  
> > https://lnt.opensuse.org/db_default/v4/SPEC/latest_runs_report?num_runs=10&all_changes=on&min_percentage_change=0.02&revisions=46e2bd1143b5c60af814916d7673879b34ceb3f6%2Cc0d79cfe9c4ec30823480f2f9b256600e8e3899f
> > 
> > I am not entirely happy about the code-size/performance tradeoffs but it
> > is concerned only for programs built with -O3 or having too many inline
> > keywords.  I have looked into inlining decisions for Firefox, HHVM and
> > Clang and inliner gets out of growt bounds way too early and some of
> > more performance aware projects already sets the limit up.
> > 
> > I will tune other metrics down to handle some of the code size problems.
> > 
> > Honza
> > 
> > Index: ChangeLog
> > ===
> > --- ChangeLog   (revision 267882)
> > +++ ChangeLog   (working copy)
> > @@ -1,3 +1,7 @@
> > +2019-01-05  Jan Hubicka  
> > +
> > +   * params.def (inline-unit-growth): Set to 40.
> > +
> > 2019-01-12  Jakub Jelinek  
> > 
> > * tree-ssa-loop-ivopts.c (find_inv_vars): Fix a comment typo.
> > Index: params.def
> > ===
> > --- params.def  (revision 267882)
> > +++ params.def  (working copy)
> > @@ -227,7 +227,7 @@ DEFPARAM(PARAM_LARGE_UNIT_INSNS,
> > DEFPARAM(PARAM_INLINE_UNIT_GROWTH,
> >  "inline-unit-growth",
> >  "How much can given compilation unit grow because of the inlining (in 
> > percent).",
> > -20, 0, 0)
> > +40, 0, 0)
> > DEFPARAM(PARAM_IPCP_UNIT_GROWTH,
> >  "ipcp-unit-growth",
> >  "How much can given compilation unit grow because of the 
> > interprocedural constant propagation (in percent).",
> 

Re: [PATCH] x86: Revert patches to fix PR target/88794

[Uros Bizjak]

On Tue, Jan 15, 2019 at 3:40 PM Wei Xiao  wrote:
>
> Hi,
>
> It turns out that the Intel 64 and IA-32 Architectures Software Developer
> Manuals (SDM) description about the fixupimm intrinsic is incorrect. So we 
> need
> to revert 3 patches related to it: r265827, r266026 and r267160.
> Sorry for the inconvenience.
>
> Is it ok?

Yes, but please test the compiler after the revert. Please also create
a runtime testcase out of the testcase in the PR.

Thanks,
Uros.

> Wei

Re: PATCH: Add -Waddress-of-packed-member to GCC 9 porting guide

[Martin Liška]

On 1/15/19 3:19 PM, H.J. Lu wrote:
> On Tue, Jan 15, 2019 at 6:07 AM Martin Liška  wrote:
>>
>> On 1/14/19 3:14 PM, H.J. Lu wrote:
>>> On Mon, Jan 14, 2019 at 5:53 AM Richard Biener
>>>  wrote:

 On Mon, Jan 14, 2019 at 2:46 PM H.J. Lu  wrote:
>
> This patch adds -Waddress-of-packed-member to GCC 9 porting guide.
>
> OK to install?

 The docs fail to mention what to do when the unaligned pointer is _not_
 safe to use.  That is, how do I fix

 struct { char c; int i[4]; } s __attribute__((packed));
 int foo()
 {
   int *p = s.i;
   return bar (p);
 }
 int bar (int *q)
 {
   return *q;
 }

 for the cases where eliding the pointer isn't easily possible?
>>>
>>> You can't have both packed struct and aligned array at the same time.
>>> The only thing I can say is "don't do it".
>>>
 Please also mention the new warning in changes.html
 (it seems to be enabled by default even?).
>>>
>>> I will add a paragraph.
>>>
>>> H.J.
 IIRC the frontends themselves build "bogus" pointer types
 to aligned data from a simple &s.i[1] because the FIELD_DECLs
 types are naturally aligned.

 Richard.

> Thanks.
>
> H.J.
> ---
> Index: gcc-9/porting_to.html
> ===
> RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/porting_to.html,v
> retrieving revision 1.1
> diff -u -r1.1 porting_to.html
> --- gcc-9/porting_to.html   11 Jan 2019 18:21:45 -  1.1
> +++ gcc-9/porting_to.html   14 Jan 2019 13:46:07 -
> @@ -56,13 +56,36 @@
>}
>
>
> +C/C++ language issues
> +
> + id="Waddress-of-packed-member">-Waddress-of-packed-member
> +is enabled by default
> +
> +
> +  When address of packed member of struct or union is taken, it may 
> result
> +  in an unaligned pointer value.  A new warning
> +  -Waddress-of-packed-member was added to check alignment at
> +  pointer assignment.  It warns both unaligned address and unaligned
> +  pointer.
> +
> +
> +
> +  If the pointer value is safe to use, you can suppress
> +  -Waddress-of-packed-member warnings by using pragmas:
> +
> +  
> +#pragma GCC diagnostic push
> +#pragma GCC diagnostic ignored "-Waddress-of-packed-member"
> +/* (code for which the warning is to be disabled)  */
> +#pragma GCC diagnostic pop
> +  
> +
>  
>
>  
>
>  >
>> It presents the new warning, run-time memory layout dump and also sanitizer 
>> error.
>>
>> Thoughts?
> 
> This doesn't help port to GCC 9.
> 
> 

But it can still go into changes as example of a code
for which the warning is triggered.

Thoughts?

[PATCH] x86: Revert patches to fix PR target/88794

[Wei Xiao]

Hi,

It turns out that the Intel 64 and IA-32 Architectures Software Developer
Manuals (SDM) description about the fixupimm intrinsic is incorrect. So we need
to revert 3 patches related to it: r265827, r266026 and r267160.
Sorry for the inconvenience.

Is it ok?

Wei

[PATCH] Fix PR88046

[Richard Biener]

The following fixes one of the -g0 vs. -g with -flto issues by never
trying to generate inheritance DIEs late (since BINFOs have been
free-lang-data'ed).

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

Richard.

2019-01-15  Richard Biener  

PR debug/88046
* dwarf2out.c (gen_member_die): Do not generate inheritance
DIEs late.

* g++.dg/lto/pr88046_0.C: New testcase.

Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 267930)
+++ gcc/dwarf2out.c (working copy)
@@ -25046,7 +25046,7 @@ gen_member_die (tree type, dw_die_ref co
  the TREE node representing the appropriate (containing) type.  */
 
   /* First output info about the base classes.  */
-  if (binfo)
+  if (binfo && early_dwarf)
 {
   vec *accesses = BINFO_BASE_ACCESSES (binfo);
   int i;
Index: gcc/testsuite/g++.dg/lto/pr88046_0.C
===
--- gcc/testsuite/g++.dg/lto/pr88046_0.C(nonexistent)
+++ gcc/testsuite/g++.dg/lto/pr88046_0.C(working copy)
@@ -0,0 +1,14 @@
+// { dg-lto-do link }
+// { dg-lto-options { { -O2 -fPIC -flto } } }
+// { dg-extra-ld-options "-shared -g" }
+
+class a {};
+class b : virtual a {
+public:
+void operator<<(bool);
+};
+void c() try {
+b d;
+d << "";
+} catch (int) {
+}

Re: PATCH: Add -Waddress-of-packed-member to GCC 9 porting guide

[H.J. Lu]

On Tue, Jan 15, 2019 at 6:07 AM Martin Liška  wrote:
>
> On 1/14/19 3:14 PM, H.J. Lu wrote:
> > On Mon, Jan 14, 2019 at 5:53 AM Richard Biener
> >  wrote:
> >>
> >> On Mon, Jan 14, 2019 at 2:46 PM H.J. Lu  wrote:
> >>>
> >>> This patch adds -Waddress-of-packed-member to GCC 9 porting guide.
> >>>
> >>> OK to install?
> >>
> >> The docs fail to mention what to do when the unaligned pointer is _not_
> >> safe to use.  That is, how do I fix
> >>
> >> struct { char c; int i[4]; } s __attribute__((packed));
> >> int foo()
> >> {
> >>   int *p = s.i;
> >>   return bar (p);
> >> }
> >> int bar (int *q)
> >> {
> >>   return *q;
> >> }
> >>
> >> for the cases where eliding the pointer isn't easily possible?
> >
> > You can't have both packed struct and aligned array at the same time.
> > The only thing I can say is "don't do it".
> >
> >> Please also mention the new warning in changes.html
> >> (it seems to be enabled by default even?).
> >
> > I will add a paragraph.
> >
> > H.J.
> >> IIRC the frontends themselves build "bogus" pointer types
> >> to aligned data from a simple &s.i[1] because the FIELD_DECLs
> >> types are naturally aligned.
> >>
> >> Richard.
> >>
> >>> Thanks.
> >>>
> >>> H.J.
> >>> ---
> >>> Index: gcc-9/porting_to.html
> >>> ===
> >>> RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/porting_to.html,v
> >>> retrieving revision 1.1
> >>> diff -u -r1.1 porting_to.html
> >>> --- gcc-9/porting_to.html   11 Jan 2019 18:21:45 -  1.1
> >>> +++ gcc-9/porting_to.html   14 Jan 2019 13:46:07 -
> >>> @@ -56,13 +56,36 @@
> >>>}
> >>>
> >>>
> >>> +C/C++ language issues
> >>> +
> >>> + >>> id="Waddress-of-packed-member">-Waddress-of-packed-member
> >>> +is enabled by default
> >>> +
> >>> +
> >>> +  When address of packed member of struct or union is taken, it may 
> >>> result
> >>> +  in an unaligned pointer value.  A new warning
> >>> +  -Waddress-of-packed-member was added to check alignment at
> >>> +  pointer assignment.  It warns both unaligned address and unaligned
> >>> +  pointer.
> >>> +
> >>> +
> >>> +
> >>> +  If the pointer value is safe to use, you can suppress
> >>> +  -Waddress-of-packed-member warnings by using pragmas:
> >>> +
> >>> +  
> >>> +#pragma GCC diagnostic push
> >>> +#pragma GCC diagnostic ignored "-Waddress-of-packed-member"
> >>> +/* (code for which the warning is to be disabled)  */
> >>> +#pragma GCC diagnostic pop
> >>> +  
> >>> +
> >>>  
> >>>
> >>>  
> >>>
> >>>  
> It presents the new warning, run-time memory layout dump and also sanitizer 
> error.
>
> Thoughts?

This doesn't help port to GCC 9.


-- 
H.J.

Re: PATCH: Add -Waddress-of-packed-member to GCC 9 porting guide

[Martin Liška]

On 1/14/19 3:14 PM, H.J. Lu wrote:
> On Mon, Jan 14, 2019 at 5:53 AM Richard Biener
>  wrote:
>>
>> On Mon, Jan 14, 2019 at 2:46 PM H.J. Lu  wrote:
>>>
>>> This patch adds -Waddress-of-packed-member to GCC 9 porting guide.
>>>
>>> OK to install?
>>
>> The docs fail to mention what to do when the unaligned pointer is _not_
>> safe to use.  That is, how do I fix
>>
>> struct { char c; int i[4]; } s __attribute__((packed));
>> int foo()
>> {
>>   int *p = s.i;
>>   return bar (p);
>> }
>> int bar (int *q)
>> {
>>   return *q;
>> }
>>
>> for the cases where eliding the pointer isn't easily possible?
> 
> You can't have both packed struct and aligned array at the same time.
> The only thing I can say is "don't do it".
> 
>> Please also mention the new warning in changes.html
>> (it seems to be enabled by default even?).
> 
> I will add a paragraph.
> 
> H.J.
>> IIRC the frontends themselves build "bogus" pointer types
>> to aligned data from a simple &s.i[1] because the FIELD_DECLs
>> types are naturally aligned.
>>
>> Richard.
>>
>>> Thanks.
>>>
>>> H.J.
>>> ---
>>> Index: gcc-9/porting_to.html
>>> ===
>>> RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/porting_to.html,v
>>> retrieving revision 1.1
>>> diff -u -r1.1 porting_to.html
>>> --- gcc-9/porting_to.html   11 Jan 2019 18:21:45 -  1.1
>>> +++ gcc-9/porting_to.html   14 Jan 2019 13:46:07 -
>>> @@ -56,13 +56,36 @@
>>>}
>>>
>>>
>>> +C/C++ language issues
>>> +
>>> +-Waddress-of-packed-member
>>> +is enabled by default
>>> +
>>> +
>>> +  When address of packed member of struct or union is taken, it may result
>>> +  in an unaligned pointer value.  A new warning
>>> +  -Waddress-of-packed-member was added to check alignment at
>>> +  pointer assignment.  It warns both unaligned address and unaligned
>>> +  pointer.
>>> +
>>> +
>>> +
>>> +  If the pointer value is safe to use, you can suppress
>>> +  -Waddress-of-packed-member warnings by using pragmas:
>>> +
>>> +  
>>> +#pragma GCC diagnostic push
>>> +#pragma GCC diagnostic ignored "-Waddress-of-packed-member"
>>> +/* (code for which the warning is to be disabled)  */
>>> +#pragma GCC diagnostic pop
>>> +  
>>> +
>>>  
>>>
>>>  
>>>
>>>  

Re: [PATCH] Fix missing or incorrect feature test macros

[Jonathan Wakely]

On 15/01/19 12:59 +, Jonathan Wakely wrote:

On 15/01/19 12:01 +, Jonathan Wakely wrote:

* doc/xml/manual/status_cxx2017.xml: Document P0032R3 and P0307R2
status.
* include/bits/stl_uninitialized.h (__cpp_lib_raw_memory_algorithms):
Define.
* include/std/any (__cpp_lib_any): Define as 201606L, because P0032R3
changes are supported.
* include/std/optional (__cpp_lib_optional): Likewise.
* include/std/variant (__cpp_lib_variant): Likewise.
* include/std/version [!__STRICT_ANSI__]
(__cpp_lib_uncaught_exceptions): Define as long integer.
[__cplusplus >= 201703L] (__cpp_lib_any)
(__cpp_lib_raw_memory_algorithms, __cpp_lib_uncaught_exceptions)
(__cpp_lib_variant): Define for C++17.
[__cplusplus >= 201703L] (__cpp_lib_optional): Update value and define
as long integer.
* libsupc++/exception (__cpp_lib_uncaught_exceptions): Define as long
integer.


Some more found by Jakub. Everything in  should be consistent
with the rest of the library headers now, for all -std modes.


And one more, where we defined it consistently, but not to the right
value.

Tested powerpc64le-linux, committed to trunk.


commit 172b1fa26185715e39ee7234c86b58e895ecc4b6
Author: Jonathan Wakely 
Date:   Tue Jan 15 13:03:06 2019 +

Update value of __cpp_lib_shared_ptr_arrays macro

* include/bits/shared_ptr_base.h (__cpp_lib_shared_ptr_arrays): Define
as 201611L, because P0497R0 changes are supported.
* include/std/version (__cpp_lib_shared_ptr_arrays): Likewise.

diff --git a/libstdc++-v3/include/bits/shared_ptr_base.h b/libstdc++-v3/include/bits/shared_ptr_base.h
index cacc7d689ea..b45cbf73667 100644
--- a/libstdc++-v3/include/bits/shared_ptr_base.h
+++ b/libstdc++-v3/include/bits/shared_ptr_base.h
@@ -890,7 +890,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 	  _M_pi = nullptr;
 }
 
-#define __cpp_lib_shared_ptr_arrays 201603
+#define __cpp_lib_shared_ptr_arrays 201611L
 
   // Helper traits for shared_ptr of array:
 
diff --git a/libstdc++-v3/include/std/version b/libstdc++-v3/include/std/version
index 36d291dcf93..38277b9ecf2 100644
--- a/libstdc++-v3/include/std/version
+++ b/libstdc++-v3/include/std/version
@@ -52,7 +52,7 @@
 #define __cpp_lib_allocator_traits_is_always_equal 201411
 #define __cpp_lib_is_null_pointer 201309
 #define __cpp_lib_result_of_sfinae 201210
-#define __cpp_lib_shared_ptr_arrays 201603
+#define __cpp_lib_shared_ptr_arrays 201611L
 
 #if !defined(__STRICT_ANSI__)
 // gnu++11

Re: [PATCH] Fix missing or incorrect feature test macros

[Jonathan Wakely]

On 15/01/19 12:01 +, Jonathan Wakely wrote:

* doc/xml/manual/status_cxx2017.xml: Document P0032R3 and P0307R2
status.
* include/bits/stl_uninitialized.h (__cpp_lib_raw_memory_algorithms):
Define.
* include/std/any (__cpp_lib_any): Define as 201606L, because P0032R3
changes are supported.
* include/std/optional (__cpp_lib_optional): Likewise.
* include/std/variant (__cpp_lib_variant): Likewise.
* include/std/version [!__STRICT_ANSI__]
(__cpp_lib_uncaught_exceptions): Define as long integer.
[__cplusplus >= 201703L] (__cpp_lib_any)
(__cpp_lib_raw_memory_algorithms, __cpp_lib_uncaught_exceptions)
(__cpp_lib_variant): Define for C++17.
[__cplusplus >= 201703L] (__cpp_lib_optional): Update value and define
as long integer.
* libsupc++/exception (__cpp_lib_uncaught_exceptions): Define as long
integer.


Some more found by Jakub. Everything in  should be consistent
with the rest of the library headers now, for all -std modes.

Tested powerpc64le-linux, committed to trunk.


commit 40a9d96b4b6ce6d4366a9e3f0cc9f8b8bfb054a5
Author: Jonathan Wakely 
Date:   Tue Jan 15 12:39:18 2019 +

Fix more missing or incorrect feature test macros

* include/bits/erase_if.h [__cplusplus > 201703L]
(__cpp_lib_erase_if): Only define for C++2a.
* include/std/iterator [__cplusplus >= 201402L && !_GLIBCXX_DEBUG]
(__cpp_lib_null_iterators): Define.
* include/std/version [__cplusplus >= 201402L && !_GLIBCXX_DEBUG]
(__cpp_lib_null_iterators): Define.
[__cpp_impl_destroying_delete] (__cpp_lib_destroying_delete): Define.

diff --git a/libstdc++-v3/include/bits/erase_if.h b/libstdc++-v3/include/bits/erase_if.h
index d84f5ffc8ed..4641dbebd85 100644
--- a/libstdc++-v3/include/bits/erase_if.h
+++ b/libstdc++-v3/include/bits/erase_if.h
@@ -38,7 +38,9 @@ namespace std
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
-#define __cpp_lib_erase_if 201900L
+#if __cplusplus > 201703L
+# define __cpp_lib_erase_if 201900L
+#endif
 
   namespace __detail
   {
diff --git a/libstdc++-v3/include/std/iterator b/libstdc++-v3/include/std/iterator
index 5c6903c1cff..9d9e19c4c6b 100644
--- a/libstdc++-v3/include/std/iterator
+++ b/libstdc++-v3/include/std/iterator
@@ -67,4 +67,8 @@
 #include 
 #include 
 
+#if __cplusplus >= 201402L && ! defined _GLIBCXX_DEBUG // PR libstdc++/70303
+# define __cpp_lib_null_iterators 201304L
+#endif
+
 #endif /* _GLIBCXX_ITERATOR */
diff --git a/libstdc++-v3/include/std/version b/libstdc++-v3/include/std/version
index f49a45940f9..36d291dcf93 100644
--- a/libstdc++-v3/include/std/version
+++ b/libstdc++-v3/include/std/version
@@ -42,6 +42,10 @@
 # define __cpp_lib_uncaught_exceptions 201411L
 #endif
 
+#if __cpp_impl_destroying_delete
+# define __cpp_lib_destroying_delete 201806L
+#endif
+
 #if __cplusplus >= 201103L
 // c++11
 #define __cpp_lib_allocator_is_always_equal 201411
@@ -71,6 +75,9 @@
 #define __cpp_lib_is_final 201402L
 #define __cpp_lib_make_reverse_iterator 201402
 #define __cpp_lib_make_unique 201304
+#ifndef _GLIBCXX_DEBUG // PR libstdc++/70303
+# define __cpp_lib_null_iterators 201304L
+#endif
 #define __cpp_lib_quoted_string_io 201304
 #define __cpp_lib_robust_nonmodifying_seq_ops 201304
 #ifdef _GLIBCXX_HAS_GTHREADS

x86_64 with nvptx accelerator libgomp test-report

[Tom de Vries]

Hi,

FYI, I've build (various versions of current) trunk for x86_64 with
nvptx accelerator and ran the libgomp testsuite on the following cards:
- gt 710 (kepler) (using driver version 390.77)
- quadro m1200 (maxwell) (using driver version 390.87)
- gt 1030 (pascal) (using driver version 390.77).

No new issues found.

Thanks,
- Tom

[PATCH] Fix missing or incorrect feature test macros

[Jonathan Wakely]

* doc/xml/manual/status_cxx2017.xml: Document P0032R3 and P0307R2
status.
* include/bits/stl_uninitialized.h (__cpp_lib_raw_memory_algorithms):
Define.
* include/std/any (__cpp_lib_any): Define as 201606L, because P0032R3
changes are supported.
* include/std/optional (__cpp_lib_optional): Likewise.
* include/std/variant (__cpp_lib_variant): Likewise.
* include/std/version [!__STRICT_ANSI__]
(__cpp_lib_uncaught_exceptions): Define as long integer.
[__cplusplus >= 201703L] (__cpp_lib_any)
(__cpp_lib_raw_memory_algorithms, __cpp_lib_uncaught_exceptions)
(__cpp_lib_variant): Define for C++17.
[__cplusplus >= 201703L] (__cpp_lib_optional): Update value and define
as long integer.
* libsupc++/exception (__cpp_lib_uncaught_exceptions): Define as long
integer.

Tested powerpc64le-linux, committed to trunk.


commit 52e40c01e58019174013a4b8e0c32e58704a0cac
Author: Jonathan Wakely 
Date:   Tue Jan 15 11:28:07 2019 +

Fix missing or incorrect feature test macros

* doc/xml/manual/status_cxx2017.xml: Document P0032R3 and P0307R2
status.
* include/bits/stl_uninitialized.h 
(__cpp_lib_raw_memory_algorithms):
Define.
* include/std/any (__cpp_lib_any): Define as 201606L, because 
P0032R3
changes are supported.
* include/std/optional (__cpp_lib_optional): Likewise.
* include/std/variant (__cpp_lib_variant): Likewise.
* include/std/version [!__STRICT_ANSI__]
(__cpp_lib_uncaught_exceptions): Define as long integer.
[__cplusplus >= 201703L] (__cpp_lib_any)
(__cpp_lib_raw_memory_algorithms, __cpp_lib_uncaught_exceptions)
(__cpp_lib_variant): Define for C++17.
[__cplusplus >= 201703L] (__cpp_lib_optional): Update value and 
define
as long integer.
* libsupc++/exception (__cpp_lib_uncaught_exceptions): Define as 
long
integer.

diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2017.xml 
b/libstdc++-v3/doc/xml/manual/status_cxx2017.xml
index 0af8a02b00f..c9913a9e3a7 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx2017.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx2017.xml
@@ -787,6 +787,31 @@ Feature-testing recommendations for C++.
   __cpp_lib_to_chars >= 201611 
 
 
+
+   Homogeneous interface for variant, any and optional 
+  
+   http://www.w3.org/1999/xlink"; 
xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0032r3.pdf";>
+   P0032R3
+   
+  
+   7.1  
+  
+  __cpp_lib_any >= 201606 ,
+  __cpp_lib_optional >= 201606 ,
+  __cpp_lib_variant >= 201606 
+  
+
+
+
+   Making Optional Greater Equal Again 
+  
+   http://www.w3.org/1999/xlink"; 
xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0307r2.pdf";>
+   P0307R2
+   
+  
+   7.1  
+__cpp_lib_optional >= 201606  
+
 
   
 
diff --git a/libstdc++-v3/include/bits/stl_uninitialized.h 
b/libstdc++-v3/include/bits/stl_uninitialized.h
index a0c574dfc44..664e4ad8f00 100644
--- a/libstdc++-v3/include/bits/stl_uninitialized.h
+++ b/libstdc++-v3/include/bits/stl_uninitialized.h
@@ -826,7 +826,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
 #endif
 
-#if __cplusplus > 201402L
+#if __cplusplus >= 201703L
+# define __cpp_lib_raw_memory_algorithms 201606L
+
   template 
 inline void
 uninitialized_default_construct(_ForwardIterator __first,
@@ -877,7 +879,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 __count, __result);
   return {__res.first.base(), __res.second};
 }
-#endif
+#endif // C++17
 
 #if __cplusplus >= 201103L
   template
diff --git a/libstdc++-v3/include/std/any b/libstdc++-v3/include/std/any
index 59d207181cf..385a99ce744 100644
--- a/libstdc++-v3/include/std/any
+++ b/libstdc++-v3/include/std/any
@@ -66,7 +66,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 #endif
   }
 
-#define __cpp_lib_any 201603
+#define __cpp_lib_any 201606L
 
   /**
*  @brief A type-safe container of any type.
diff --git a/libstdc++-v3/include/std/optional 
b/libstdc++-v3/include/std/optional
index c5e66bdd140..d243930fed4 100644
--- a/libstdc++-v3/include/std/optional
+++ b/libstdc++-v3/include/std/optional
@@ -51,7 +51,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
*  @{
*/
 
-#define __cpp_lib_optional 201603
+#define __cpp_lib_optional 201606L
 
   template
 class optional;
diff --git a/libstdc++-v3/include/std/variant b/libstdc++-v3/include/std/variant
index 83cf99e9ae0..89deb143097 100644
--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -68,7 +68,7 @@ namespace __variant
 } // namespace __variant
 } // namespace __detail
 
-#define __cpp_lib_variant 201603
+#define __cpp_lib_variant 201606L
 
   template class tuple;
   templat

Re: [wwwdocs] Add __cpp_* feature macros to C++20 entries + other changes that have those in projects/cxx_status.html

[Jonathan Wakely]

On 12/01/19 14:08 +0100, Jakub Jelinek wrote:

Hi!

On Fri, Jan 11, 2019 at 04:54:11PM +0100, Jakub Jelinek wrote:

I've noticed we don't have any feature test macros in the table for C++20,
even when a couple of the features have them defined.


Here is an updated patch, that in addition to that makes 9 URLs as we now
have #cxx in gcc-9/changes.html and adds missing P0941R2 entry that clang
table has.  For that one I'm not 100% sure what to say, I've copied all the
macros from http://wg21.link/p0941r2 into two source files (attached below),
one for core language features, another one for library and tested those
with -std=c++2a with current trunk.  Compared to what the paper lists, we
have __has_cpp_attribute (carries_dependency) 0, __cpp_guaranteed_copy_elision
and __cpp_nontype_template_parameter_auto not defined.  Is that what we
want?  On the library side, __cpp_lib_any,


This is missing from  and has the wrong value in .


__cpp_lib_execution,


This is unimplemented (it's part of trodgers' PSTL work).


__cpp_lib_hardware_interference_size,


Unimplemented.


__cpp_lib_null_iterators,


This should be defined except in Debug Mode (and Debug Mode should be
fixed to support it).


__cpp_lib_parallel_algorithm,


Unimplemened (PSTL).


__cpp_lib_raw_memory_algorithms,


Missing from both  and 


__cpp_lib_to_chars,


Not fully implemented.


__cpp_lib_uncaught_exceptions,


Only defined in  for !__STRICT_ANSI__.


__cpp_lib_variant


Missing from  and has wrong value in .


macros aren't defined (at least not in ) and
__cpp_lib_optional,


The value is wrong, we implement the P0032 changes that bumped the
macro to 201606.


__cpp_lib_shared_ptr_arrays, __cpp_lib_string_view


I think the value is wrong for these two.


have smaller values than those in the P0941R2.
Is that the desirable state given current C++2A implementation status?


I'll fix the issues above.

Re: [PATCH] avoid issuing -Warray-bounds during folding (PR 88800)

[Richard Biener]

On Tue, Jan 15, 2019 at 1:08 AM Martin Sebor  wrote:
>
> The gimple_fold_builtin_memory_op() function folds calls to memcpy
> and similar to MEM_REF when the size of the copy is a small power
> of 2, but it does so without considering whether the copy might
> write (or read) past the end of one of the objects.  To detect
> these kinds of errors (and help distinguish them from -Westrict)
> the folder calls into the wrestrict pass and lets it diagnose them.
> Unfortunately, that can lead to false positives for even some fairly
> straightforward code that is ultimately found to be unreachable.
> PR 88800 is a report of one such problem.
>
> To avoid these false positives the attached patch adjusts
> the function to avoid issuing -Warray-bounds for out-of-bounds
> calls to memcpy et al.  Instead, the patch disables the folding
> of such invalid calls (and only those).  Those that are not
> eliminated during DCE or other subsequent passes are eventually
> diagnosed by the wrestrict pass.
>
> Since this change required removing the dependency of the detection
> on the warning options (originally done as a micro-optimization to
> avoid spending compile-time cycles on something that wasn't needed)
> the patch also adds tests to verify that code generation is not
> affected as a result of warnings being enabled or disabled.  With
> the patch as is, the invalid memcpy calls end up emitted (currently
> they are folded into equally invalid MEM_REFs).  At some point,
> I'd like us to consider whether they should be replaced with traps
> (possibly under the control of  as has been proposed a number of
> times in the past.  If/when that's done, these tests will need to
> be adjusted to look for traps instead.
>
> Tested on x86_64-linux.

I've said in the past that I feel delaying of folding is wrong.

To understand, the PR is about emitting a warning for out-of-bound
accesses in a dead code region?

If we think delaying/disablign the folding is the way to go the
patch looks OK.

Richard.

>
> Martin

Re: [PATCH]: Mention -Waddress-of-packed-member change in GCC 9

[Richard Biener]

On Mon, Jan 14, 2019 at 3:35 PM H.J. Lu  wrote
>
> OK to install?
>
> H.J.
> ---
> Index: changes.html
> ===
> RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v
> retrieving revision 1.34
> diff -u -p -r1.34 changes.html
> --- changes.html13 Jan 2019 17:40:11 -  1.34
> +++ changes.html14 Jan 2019 14:33:58 -
> @@ -79,6 +79,14 @@ a work-in-progress.
>  __builtin_convertvector built-in for vector conversions
>has been added. 
>
> +
> +  New warnings:
> +  
> +  -Waddress-of-packed-member, enabled by default,
> +  warns unaligned pointer value from adress of packed member of
> +  struct or union.

"warns about an unaligned pointer value from the address of a packed member
of a struct or union."

OK with that change.

Richard.

> +  
> +  
>  
>
>  C++

Re: [PATCH] Fix OpenACC shutdown and PTX image unloading (PR65904)

[Tom de Vries]

[ add gcc-patches@ ]

On 15-01-19 11:38, Tom de Vries wrote:
> Hi
> 
> Copied from here (
> https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00532.html ):
>> This too. Retested for libgomp/NVPTX.
>>
>> OK for trunk now?
>>
> 
> The plugin-nvptx.c part looks ok to me, for stage 1.
> 
> Thanks,
> - Tom
> 
>> Thanks,
>>
>> Julian
>>
>> ChangeLog
>>
>> PR libgomp/65904
>>
>> libgomp/
>> * libgomp.h (gomp_free_memmap): Update prototype.
>> * oacc-init.c (acc_shutdown_1): Pass device descriptor to
>> gomp_free_memmap. Don't lock device around call.
>> * target.c (gomp_map_vars): Initialise tgt->array to NULL before
>> early exit.
>> (GOMP_offload_unregister): Split out and call...
>> (gomp_deoffload_image_from_device): This new function.
>> (gomp_free_memmap): Call gomp_deoffload_image_from_device.
>> * plugin/nvptx.c (struct ptx_image_data): Add ord, fn_descs fields.
>> (nvptx_init): Tweak comment.
>> (nvptx_attach_host_thread_to_device): Add locking with ptx_dev_lock
>> around ptx_devices accesses.
>> (GOMP_OFFLOAD_load_image): Populate new ptx_image_data fields.
>> (GOMP_OFFLOAD_unload_image): Switch to ORD'th device before freeing
>> images, and use fn_descs field from ptx_image_data instead of
>> incorrectly using a pointer derived from target_data.
>> (GOMP_OFFLOAD_openacc_create_thread_data): Add locking around
>> ptx_devices accesses.
> 

Re: [PATCH] Document C++20 library status

[Jonathan Wakely]

On 11/01/19 23:42 +, Jonathan Wakely wrote:

* doc/xml/manual/intro.xml: Include new section.
* doc/xml/manual/status_cxx2017.xml: Document more
implementation-defined properties of the library.
* doc/xml/manual/status_cxx2020.xml: Document C++2a status.
* doc/html/*: Regenerate.


P1123R0 needs no changes, so can be marked complete.

Committed to trunk.


commit bdcb89e8673c5f1d8f799651984a0afc5fcb8a20
Author: Jonathan Wakely 
Date:   Tue Jan 15 10:33:33 2019 +

* doc/xml/manual/status_cxx2020.xml: Update P1123R0 status.

diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2020.xml b/libstdc++-v3/doc/xml/manual/status_cxx2020.xml
index 67353850ce5..05d34284506 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx2020.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx2020.xml
@@ -848,14 +848,13 @@ Feature-testing recommendations for C++.
 
 
 
-  
 Editorial Guidance for merging P0019r8 and P0528r3 
   
 http://www.w3.org/1999/xlink"; xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1123r0.html";>
 	P1123R0
 	
   
-   
+   Note 1 
   
 
 

Re: [WIP] Reimplementation of IPA-SRA

[Martin Liška]

There's one more ICE I see:

$ gcc -O2 libvpx.i -c
libvpx.i: In function ‘m.isra’:
libvpx.i:28:1: error: invalid argument to gimple call
   28 | }
  | ^
ISRA.6
# .MEM_6 = VDEF <.MEM_4(D)>
l_1 = c (d_5(D), ISRA.6);
during IPA pass: materialize-all-clones
libvpx.i:28:1: internal compiler error: verify_gimple failed
0xd72897 verify_gimple_in_cfg(function*, bool)
/home/marxin/Programming/gcc/gcc/tree-cfg.c:5422
0xc4b2cf execute_function_todo
/home/marxin/Programming/gcc/gcc/passes.c:1977
0xc4c1a1 do_per_function
/home/marxin/Programming/gcc/gcc/passes.c:1645
0xc4c1a1 do_per_function
/home/marxin/Programming/gcc/gcc/passes.c:1635
0xc4c1fe execute_todo
/home/marxin/Programming/gcc/gcc/passes.c:2031
typedef int __attribute__((__vector_size__(16))) a;

a dk();
a k();

int b;
a *j;
inline int c(a *d) {
  a e;
  a f;
  a g = *d;
  a h = g;
  a i = h;
  f = i == dk();
  e = f == b;
  k(e);
}

static void m(a *d) {
  int l = c(d);
  if (l)
c(j);
}

void o(void) {
  a n;
  m(&n);
}

[committed][nvptx] Handle assignment to gang-level reduction variable

[Tom de Vries]

Hi,

this fixes an ICE when handling an assignment to a gang-level reduction
variable.

Committed to trunk.

Thanks,
- Tom

[nvptx] Handle assignment to gang-level reduction variable

2019-01-15  Tom de Vries  

PR target/80547
* config/nvptx/nvptx.c (nvptx_goacc_reduction_init): Handle
lhs == NULL_TREE for gang-level reduction.

* testsuite/libgomp.oacc-c-c++-common/gang-reduction-var-assignment.c:
New test.

---
 gcc/config/nvptx/nvptx.c |  3 ++-
 .../gang-reduction-var-assignment.c  | 16 
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index 03c0f82f4a2..23459e1c6f4 100644
--- a/gcc/config/nvptx/nvptx.c
+++ b/gcc/config/nvptx/nvptx.c
@@ -6242,7 +6242,8 @@ nvptx_goacc_reduction_init (gcall *call, offload_attrs 
*oa)
init = var;
}
 
-  gimplify_assign (lhs, init, &seq);
+  if (lhs != NULL_TREE)
+   gimplify_assign (lhs, init, &seq);
 }
 
   pop_gimplify_context (NULL);
diff --git 
a/libgomp/testsuite/libgomp.oacc-c-c++-common/gang-reduction-var-assignment.c 
b/libgomp/testsuite/libgomp.oacc-c-c++-common/gang-reduction-var-assignment.c
new file mode 100644
index 000..05f58a4bddf
--- /dev/null
+++ 
b/libgomp/testsuite/libgomp.oacc-c-c++-common/gang-reduction-var-assignment.c
@@ -0,0 +1,16 @@
+/* { dg-xfail-run-if "PR88852" { openacc_host_selected } } */
+
+int
+main (void)
+{
+  int x = 123;
+
+#pragma acc parallel num_gangs(1) reduction (+: x)
+  {
+x = 23;
+  }
+  if (x != 146)
+__builtin_abort();
+
+  return 0;
+}

Re: PR88788 - Infinite loop in malloc_candidate_p_1

[Prathamesh Kulkarni]

On Tue, 15 Jan 2019 at 14:33, Richard Biener  wrote:
>
> On Tue, 15 Jan 2019, Jakub Jelinek wrote:
>
> > On Tue, Jan 15, 2019 at 12:29:21PM +0530, Prathamesh Kulkarni wrote:
> > > 2019-01-15  Richard Biener  
> > > Prathamesh Kulkarni  
> > >
> > > PR ipa/88378
> >
> > Wrong PR number.
> >
> > > * ipa-pure-const.c (malloc_candidate_p_1): Add parameter visited and
> > > return true if SSA_NAME is already marked in visited bitmap.
> > > * (malloc_candidate_p): Pass visited to malloc_candidate_p_1.
> > >
> > > testsuite/
> > > * g++.dg/ipa/pr88788.C: New test.
> >
> > The testcase looks way too large to me, can't we reduce it?
> >
> > delta/creduce with a hanging compiler isn't fast (one would need to use
> > timeout), but e.g. in #c1 you have a patch to get an ICE instead of hang if
> > it happens.
>
> Or just omit the testcase - even with the bitmap we can end up recursing
> very many times thus the ICE can happen spuriously.
I committed patch in r267933 omitting the test-case.
Thanks Richard and Jakub for help with the bug!

Thanks,
Prathamesh
>
> Richard.

Re: PR88788 - Infinite loop in malloc_candidate_p_1

[Richard Biener]

On Tue, 15 Jan 2019, Jakub Jelinek wrote:

> On Tue, Jan 15, 2019 at 12:29:21PM +0530, Prathamesh Kulkarni wrote:
> > 2019-01-15  Richard Biener  
> > Prathamesh Kulkarni  
> > 
> > PR ipa/88378
> 
> Wrong PR number.
> 
> > * ipa-pure-const.c (malloc_candidate_p_1): Add parameter visited and
> > return true if SSA_NAME is already marked in visited bitmap.
> > * (malloc_candidate_p): Pass visited to malloc_candidate_p_1.
> > 
> > testsuite/
> > * g++.dg/ipa/pr88788.C: New test.
> 
> The testcase looks way too large to me, can't we reduce it?
> 
> delta/creduce with a hanging compiler isn't fast (one would need to use
> timeout), but e.g. in #c1 you have a patch to get an ICE instead of hang if
> it happens.

Or just omit the testcase - even with the bitmap we can end up recursing
very many times thus the ICE can happen spuriously.

Richard.

Re: PR88788 - Infinite loop in malloc_candidate_p_1

[Jakub Jelinek]

On Tue, Jan 15, 2019 at 12:29:21PM +0530, Prathamesh Kulkarni wrote:
> 2019-01-15  Richard Biener  
>   Prathamesh Kulkarni  
> 
>   PR ipa/88378

Wrong PR number.

>   * ipa-pure-const.c (malloc_candidate_p_1): Add parameter visited and
>   return true if SSA_NAME is already marked in visited bitmap.
>   * (malloc_candidate_p): Pass visited to malloc_candidate_p_1.
> 
> testsuite/
>   * g++.dg/ipa/pr88788.C: New test.

The testcase looks way too large to me, can't we reduce it?

delta/creduce with a hanging compiler isn't fast (one would need to use
timeout), but e.g. in #c1 you have a patch to get an ICE instead of hang if
it happens.

Jakub

Re: PR88788 - Infinite loop in malloc_candidate_p_1

[Richard Biener]

On Tue, 15 Jan 2019, Prathamesh Kulkarni wrote:

> Hi Richard,
> I tested your fix and it passes bootstrap+test on
> x86_64-unknown-linux-gnu and cross-tested on following arm and aarch64
> sub-targets:
> http://people.linaro.org/~christophe.lyon/cross-validation/gcc-test-patches/267917-pr88788-3/report-build-info.html
> 
> Is it OK to commit ?

OK

Thanks,
Richard.

> Thanks,
> Prathamesh
> 

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

Re: ISO_Fortran_binding patch

[Jakub Jelinek]

On Tue, Jan 15, 2019 at 08:05:59AM +0100, Richard Biener wrote:
> >It either should
> >#include "../../../libgfortran/ISO_Fortran_binding.h"
> >instead or the Fortran *.exp files should arrange for
> >-I.../libgfortran/
> >to be added to all gfortran tests.  Because right now it FAILs if you
> >don't
> >have ISO_Fortran_binding.h header installed, or succeeds, but includes
> >header from some other compiler version or even other compiler
> >altogether.

This still needs to be fixed.

> >Where is that header installed BTW?
> >Would be best if it got installed in directories like:
> >$prefix/lib/gcc/$target/$version/include
> >
> >See e.g. libssp or libsanitizer, both have something like
> >target_noncanonical = @target_noncanonical@
> >libsubincludedir =
> >$(libdir)/gcc/$(target_noncanonical)/$(gcc_version)/include
> >nobase_libsubinclude_HEADERS = ssp/ssp.h ssp/string.h ssp/stdio.h
> >ssp/unistd.h
> >
> >You probably want it to go directly in the include dir, so without the
> >ssp/
> >or whatever else prefixes.
> 
> It's there, but also in the multilib locations (which is dubious? Not sure if 
> we ever search tose include paths) 

Yeah, for -m32 it is in
.../lib/gcc/x86_64-pc-linux-gnu/9.0.0/32/include/
which isn't that useful; while the finclude/ in there is needed, because
those are target specific, this header is the same and so it could be
just in .../9.0.0/include/ always (like e.g. the std*.h headers, intrinsics
etc.).

Jakub