[PATCH v2] [PR91979] Updated the fix:

[Kamlesh Kumar]

Changlogs
gcc
--
2019-11-02  Kamlesh Kumar  

PR c++/91979 - mangling nullptr expression
* mangle.c (write_template_arg_literal): Handle nullptr
mangling.
* testsuite/g++.dg/cpp0x/nullptr27.C: Modify Test.
* testsuite/g++.dg/cpp0x/pr91979.C: New Test.

libiberty
---
2019-11-02  Kamlesh Kumar  

* cp-demangle.c (d_expr_primary): Handle
nullptr demangling.
* testsuite/demangle-expected: Added test.

gcc/c-family
--
2019-11-02  Kamlesh Kumar  

* c-opts.c (c_common_post_options): Updated
latest_abi_version.
---
 gcc/c-family/c-opts.c  |  2 +-
 gcc/cp/mangle.c|  4 +++-
 gcc/testsuite/g++.dg/cpp0x/nullptr27.C |  2 +-
 gcc/testsuite/g++.dg/cpp0x/pr91979.C   | 15 +++
 libiberty/cp-demangle.c| 11 +++
 libiberty/testsuite/demangle-expected  |  4 
 6 files changed, 35 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/pr91979.C

diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index 0fffe60b140..d4c77be5cd5 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -937,7 +937,7 @@ c_common_post_options (const char **pfilename)
 
   /* Change flag_abi_version to be the actual current ABI level, for the
  benefit of c_cpp_builtins, and to make comparison simpler.  */
-  const int latest_abi_version = 13;
+  const int latest_abi_version = 14;
   /* Generate compatibility aliases for ABI v11 (7.1) by default.  */
   const int abi_compat_default = 11;
 
diff --git a/gcc/cp/mangle.c b/gcc/cp/mangle.c
index a9333b84349..234a975781e 100644
--- a/gcc/cp/mangle.c
+++ b/gcc/cp/mangle.c
@@ -3400,7 +3400,9 @@ write_template_arg_literal (const tree value)
   case INTEGER_CST:
gcc_assert (!same_type_p (TREE_TYPE (value), boolean_type_node)
|| integer_zerop (value) || integer_onep (value));
-   write_integer_cst (value);
+   if (abi_version_at_least(14)
+   && !NULLPTR_TYPE_P (TREE_TYPE (value)))
+ write_integer_cst (value);
break;
 
   case REAL_CST:
diff --git a/gcc/testsuite/g++.dg/cpp0x/nullptr27.C 
b/gcc/testsuite/g++.dg/cpp0x/nullptr27.C
index 2510dc80634..edd11606266 100644
--- a/gcc/testsuite/g++.dg/cpp0x/nullptr27.C
+++ b/gcc/testsuite/g++.dg/cpp0x/nullptr27.C
@@ -1,7 +1,7 @@
 // PR c++/52706
 // { dg-do compile { target c++11 } }
 // { dg-options "-fabi-version=0" }
-// { dg-final { scan-assembler "_Z1fIDnLDn0EEiT_" } }
+// { dg-final { scan-assembler "_Z1fIDnLDnEEiT_" } }
 
 template
 int f(T);
diff --git a/gcc/testsuite/g++.dg/cpp0x/pr91979.C 
b/gcc/testsuite/g++.dg/cpp0x/pr91979.C
new file mode 100644
index 000..7fcd56b27f0
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/pr91979.C
@@ -0,0 +1,15 @@
+// PR c++/91989
+// { dg-do compile { target c++11 } }
+// { dg-final { scan-assembler "_Z3fooILPv0EEvPN9enable_ifIXeqT_LDnEEvE4typeE" 
} }
+
+template 
+struct enable_if {};
+
+template 
+struct enable_if { typedef T type; };
+
+template 
+void foo(typename enable_if::type* = 0) {}
+
+template void foo<(void *)0>(void *);
+
diff --git a/libiberty/cp-demangle.c b/libiberty/cp-demangle.c
index 5b674d7d93c..3fb1c56409e 100644
--- a/libiberty/cp-demangle.c
+++ b/libiberty/cp-demangle.c
@@ -3577,6 +3577,17 @@ d_expr_primary (struct d_info *di)
  && type->u.s_builtin.type->print != D_PRINT_DEFAULT)
di->expansion -= type->u.s_builtin.type->len;
 
+  if (type->type == DEMANGLE_COMPONENT_BUILTIN_TYPE
+ && strncmp (type->u.s_builtin.type->name,
+ cplus_demangle_builtin_types[33].name, 17) == 0)
+   {
+ if (d_peek_char (di) == 'E')
+   {
+ d_advance (di, 1);
+ return type;
+   }
+   }
+
   /* Rather than try to interpret the literal value, we just
 collect it as a string.  Note that it's possible to have a
 floating point literal here.  The ABI specifies that the
diff --git a/libiberty/testsuite/demangle-expected 
b/libiberty/testsuite/demangle-expected
index 61681484d0e..f68a8a71aaf 100644
--- a/libiberty/testsuite/demangle-expected
+++ b/libiberty/testsuite/demangle-expected
@@ -1446,3 +1446,7 @@ Foo()::X::fn
 _ZZZ3FooIiEfvENKUlT_E_clIcEEDaS0_EN1X2fnEv
 Foo()::{lambda(auto:1)#1}::operator()(char) const::X::fn()
 Foo()::{lambda(auto:1)#1}::operator()(char) const::X::fn
+#PR91979 demangling nullptr expression
+
+_Z3fooILPv0EEvPN9enable_ifIXeqT_LDnEEvE4typeE
+void foo<(void*)0>(enable_if<((void*)0)==((decltype(nullptr))), void>::type*)
-- 
2.17.1

Re: [PATCH] V6, #4 of 17: Add prefixed instruction support to stack protect insns

[Segher Boessenkool]

Hi!

On Wed, Oct 16, 2019 at 09:47:41AM -0400, Michael Meissner wrote:
> This patch fixes the stack protection insns to support stacks larger than
> 16-bits on the 'future' system using prefixed loads and stores.

> +;; We can't use the prefixed attribute here because there are two memory
> +;; instructions.  We can't split the insn due to the fact that this operation
> +;; needs to be done in one piece.
>  (define_insn "stack_protect_setdi"
>[(set (match_operand:DI 0 "memory_operand" "=Y")
>   (unspec:DI [(match_operand:DI 1 "memory_operand" "Y")] UNSPEC_SP_SET))
> (set (match_scratch:DI 2 "=") (const_int 0))]
>"TARGET_64BIT"
> -  "ld%U1%X1 %2,%1\;std%U0%X0 %2,%0\;li %2,0"
> +{
> +  if (prefixed_memory (operands[1], DImode))
> +output_asm_insn ("pld %2,%1", operands);
> +  else
> +output_asm_insn ("ld%U1%X1 %2,%1", operands);
> +
> +  if (prefixed_memory (operands[0], DImode))
> +output_asm_insn ("pstd %2,%0", operands);
> +  else
> +output_asm_insn ("std%U0%X0 %2,%0", operands);

We could make %pN mean 'p' for prefixed, for memory as operands[N]?  Are
there more places than this that could use that?  How about inline asm?

> +   (set (attr "length")
> + (cond [(and (match_operand 0 "prefixed_memory")
> + (match_operand 1 "prefixed_memory"))
> +(const_string "24")
> +
> +(ior (match_operand 0 "prefixed_memory")
> + (match_operand 1 "prefixed_memory"))
> +(const_string "20")]
> +
> +   (const_string "12")))])

You can use const_int instead of const_string here, I think?  Please do
that if it works.

Quite a simple expression, phew :-)

> +  if (which_alternative == 0)
> +output_asm_insn ("xor. %3,%3,%4", operands);
> +  else
> +output_asm_insn ("cmpld %0,%3,%4\;li %3,0", operands);

That doesn't work: the backslash is treated like the escape character, in
a C block.  I think doubling it will work?  Check the generated insn-output.c,
it should be translated to \t\n in there.

Okay for trunk with those things taken care of.  Thanks!


Segher

Re: [C++ PATCH] Implement P1073R3: Immediate functions (PR c++/88335, take 3)

[Jason Merrill]

On 11/1/19 5:19 PM, Jakub Jelinek wrote:

On Fri, Nov 01, 2019 at 09:56:44PM +0100, Jakub Jelinek wrote:

Ah, used 8.x to test it.  There have been r265787 and r269775 changes in
between.
Though
   auto d = [] () mutable __attribute__((noreturn)) constexpr {};
   auto e = [] () mutable [[noreturn]] constexpr {};
is still accepted.  I bet incorrectly though, I can try to fix it in a
follow-up patch, but can remove the attribute skipping from the consteval
patch then.


Perhaps like this (untested so far)?


Looks good.


Though, I have to wonder about the other callers of
cp_parser_decl_specifier_seq, whether attributes should be accepted anywhere
in between specifiers or not.


In a normal decl-specifier-seq it's fine to have attributes, just 
lambdas restrict the contents.



2019-11-01  Jakub Jelinek  

PR c++/89640
* parser.c (cp_parser_decl_specifier_seq): Don't parse attributes
if CP_PARSER_FLAGS_ONLY_MUTABLE_OR_CONSTEXPR.

* g++.dg/cpp1z/attr-lambda1.C: New test.
* g++.dg/ext/attr-lambda2.C: New test.

--- gcc/cp/parser.c.jj  2019-10-31 17:33:19.864518279 +0100
+++ gcc/cp/parser.c 2019-11-01 22:05:24.684037804 +0100
@@ -13965,7 +13965,8 @@ cp_parser_decl_specifier_seq (cp_parser*
if (!start_token)
start_token = token;
/* Handle attributes.  */
-  if (cp_next_tokens_can_be_attribute_p (parser))
+  if ((flags & CP_PARSER_FLAGS_ONLY_MUTABLE_OR_CONSTEXPR) == 0
+ && cp_next_tokens_can_be_attribute_p (parser))
{
  /* Parse the attributes.  */
  tree attrs = cp_parser_attributes_opt (parser);
--- gcc/testsuite/g++.dg/cpp1z/attr-lambda1.C.jj2019-11-01 
22:15:57.264378908 +0100
+++ gcc/testsuite/g++.dg/cpp1z/attr-lambda1.C   2019-11-01 22:16:11.143167034 
+0100
@@ -0,0 +1,12 @@
+// PR c++/89640
+// { dg-options "-Wno-attributes" }
+// { dg-do compile { target c++17 } }
+
+void test() {
+[]() mutable [[gnu::cold]] constexpr {}(); // { dg-error 
"expected" }
+[]() constexpr [[gnu::cold]] mutable {}(); // { dg-error 
"expected" }
+[]() [[gnu::cold]] mutable constexpr {}(); // { dg-error 
"expected" }
+[]() [[gnu::cold]] constexpr mutable {}(); // { dg-error 
"expected" }
+[]() mutable constexpr [[gnu::cold]] {}();
+[]() constexpr mutable [[gnu::cold]] {}();
+}
--- gcc/testsuite/g++.dg/ext/attr-lambda2.C.jj  2019-11-01 22:16:25.784943505 
+0100
+++ gcc/testsuite/g++.dg/ext/attr-lambda2.C 2019-11-01 22:16:42.736684714 
+0100
@@ -0,0 +1,12 @@
+// PR c++/89640
+// { dg-options "-Wno-attributes" }
+// { dg-do compile { target c++17 } }
+
+void test() {
+[]() mutable __attribute__((cold)) constexpr {}(); // { dg-error 
"expected" }
+[]() constexpr __attribute__((cold)) mutable {}(); // { dg-error 
"expected" }
+[]() __attribute__((cold)) mutable constexpr {}(); // { dg-error 
"expected" }
+[]() __attribute__((cold)) constexpr mutable {}(); // { dg-error 
"expected" }
+[]() mutable constexpr __attribute__((cold)) {}();
+[]() constexpr mutable __attribute__((cold)) {}();
+}


Jakub

[committed] Simplify omp-device-properties.h creation (PR bootstrap/92314)

[Jakub Jelinek]

Hi!

Apparently my recent change broke quite a lot of setups where people were
configuring --enable-offload-targets= without having the corresponding
offloading compiler already installed.
The following patch simplifies it by removing the need to have it installed
again for compiler building (it is still needed for testing as before),
by adding new tmake_files with the needed rules and building everything
while building the host compiler.

Bootstrapped/regtested on x86_64-linux and i686-linux, tested also with
x86_64-intelmicemul-linux-gnu and nvptx-none offloading, committed to trunk.

2019-11-02  Jakub Jelinek  

PR bootstrap/92314
* configure.ac: Don't look for omp-device-properties files from
installed offloading compilers.  Instead add tmake_file snippets
for configured offloading targets and use files they generate.
* Makefile.in (install): Don't depend on
install-omp-device-properties.
(install-omp-device-properties): Remove goal.
* config/i386/t-omp-device: New file.
* config/i386/t-intelmic (omp-device-properties): Remove goal.
* config/nvptx/t-omp-device: New file.
* config/nvptx/t-nvptx (omp-device-properties): Remove goal.
* configure: Regenerated.

--- gcc/configure.ac.jj 2019-10-31 11:05:50.461137028 +0100
+++ gcc/configure.ac2019-11-01 21:22:58.417920544 +0100
@@ -1026,18 +1026,22 @@ AC_SUBST(real_target_noncanonical)
 AC_SUBST(accel_dir_suffix)
 
 for tgt in `echo $enable_offload_targets | sed 's/,/ /g'`; do
-  tgt_dir=`echo $tgt | sed -n 's/.*=//p'`
   tgt=`echo $tgt | sed 's/=.*//'`
 
   if echo "$tgt" | grep "^hsa" > /dev/null ; then
 enable_hsa=1
   else
 enable_offloading=1
-if test -n "$tgt_dir"; then
-  
omp_device_property="${tgt_dir}/lib/gcc/\$(real_target_noncanonical)/\$(version)/accel/${tgt}/omp-device-properties"
-else
-  omp_device_property="\$(libsubdir)/accel/${tgt}/omp-device-properties"
-fi
+case "$tgt" in
+  *-intelmicemul-*)
+   omp_device_property=omp-device-properties-i386
+   omp_device_property_tmake_file="${omp_device_property_tmake_file} 
\$(srcdir)/config/i386/t-omp-device"
+   ;;
+  nvptx*-*)
+   omp_device_property=omp-device-properties-nvptx
+   omp_device_property_tmake_file="${omp_device_property_tmake_file} 
\$(srcdir)/config/nvptx/t-omp-device"
+   ;;
+esac
 omp_device_properties="${omp_device_properties} 
${tgt}=${omp_device_property}"
 omp_device_property_deps="${omp_device_property_deps} 
${omp_device_property}"
   fi
@@ -2065,7 +2069,7 @@ do
tmake_file_="${tmake_file_} \$(srcdir)/config/$f"
fi
 done
-tmake_file="${tmake_file_}"
+tmake_file="${tmake_file_}${omp_device_property_tmake_file}"
 
 out_object_file=`basename $out_file .c`.o
 common_out_object_file=`basename $common_out_file .c`.o
--- gcc/Makefile.in.jj  2019-10-31 11:05:50.491136565 +0100
+++ gcc/Makefile.in 2019-11-01 21:04:12.720107538 +0100
@@ -3476,10 +3476,6 @@ ifeq ($(enable_plugin),yes)
 install: install-plugin
 endif
 
-ifeq ($(enable_as_accelerator),yes)
-install: install-omp-device-properties
-endif
-
 install-strip: override INSTALL_PROGRAM = $(INSTALL_STRIP_PROGRAM)
 ifneq ($(STRIP),)
 install-strip: STRIPPROG = $(STRIP)
@@ -3665,11 +3661,6 @@ install-driver: installdirs xgcc$(exeext
  fi; \
fi
 
-# Install omp-device-properties file for accelerator compilers.
-install-omp-device-properties: omp-device-properties installdirs
-   $(INSTALL_DATA) omp-device-properties \
- $(DESTDIR)$(libsubdir)/omp-device-properties
-
 # Install the info files.
 # $(INSTALL_DATA) might be a relative pathname, so we can't cd into srcdir
 # to do the install.
--- gcc/config/i386/t-omp-device.jj 2019-11-01 21:02:23.010782525 +0100
+++ gcc/config/i386/t-omp-device2019-11-01 21:02:45.117445012 +0100
@@ -0,0 +1,6 @@
+omp-device-properties-i386: $(srcdir)/config/i386/i386-options.c
+   echo kind: cpu > $@
+   echo arch: x86 x86_64 i386 i486 i586 i686 ia32 >> $@
+   echo isa: sse4 `sed -n '/^static struct ix86_target_opts 
isa2\?_opts\[\] =/,/^};/p' \
+ $(srcdir)/config/i386/i386-options.c | \
+ sed -n 's/",.*$$//;s/\./_/;s/^  { "-m//p'` >> $@
--- gcc/config/i386/t-intelmic.jj   2019-10-31 11:05:50.533135914 +0100
+++ gcc/config/i386/t-intelmic  2019-11-01 21:02:55.715283208 +0100
@@ -8,10 +8,3 @@ ALL_HOST_OBJS += mkoffload.o
 mkoffload$(exeext): mkoffload.o collect-utils.o libcommon-target.a 
$(LIBIBERTY) $(LIBDEPS)
$(LINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \
  mkoffload.o collect-utils.o libcommon-target.a $(LIBIBERTY) $(LIBS)
-
-omp-device-properties: $(srcdir)/config/i386/i386-options.c
-   echo kind: cpu > omp-device-properties
-   echo arch: x86 x86_64 i386 i486 i586 i686 ia32 >> omp-device-properties
-   echo isa: sse4 `sed -n '/^static struct ix86_target_opts 
isa2\?_opts\[\] =/,/^};/p' \
- 

[committed] OpenMP declare variant context strict subset testing

[Jakub Jelinek]

Hi!

The following patch implements one sentence from the OpenMP 5
standard:
"A context selector that is a strict subset of another context selector
has a score of zero."
I have scoring mostly written too, but haven't added testcases yet, so that
will be in a follow-up patch.

Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.

2019-11-02  Jakub Jelinek  

* omp-general.h (omp_context_selector_set_compare): Declare.
* omp-general.c (omp_construct_simd_compare,
omp_context_selector_props_compare, omp_context_selector_set_compare,
omp_context_selector_compare): New functions.
(omp_resolve_declare_variant): Prune variants that are strict subset
of another variant.
c-family/
* c-omp.c (c_omp_mark_declare_variant): Use
omp_context_selector_set_compare.
testsuite/
* c-c++-common/gomp/declare-variant-6.c: Expect construct rather than
constructor in diagnostic messages.
* c-c++-common/gomp/declare-variant-7.c: Likewise.
* c-c++-common/gomp/declare-variant-11.c: New test.

--- gcc/omp-general.h.jj2019-10-25 00:27:43.618318678 +0200
+++ gcc/omp-general.h   2019-11-01 12:37:33.806852041 +0100
@@ -86,6 +86,7 @@ extern poly_uint64 omp_max_vf (void);
 extern int omp_max_simt_vf (void);
 extern int omp_constructor_traits_to_codes (tree, enum tree_code *);
 extern int omp_context_selector_matches (tree);
+extern int omp_context_selector_set_compare (const char *, tree, tree);
 extern tree omp_resolve_declare_variant (tree);
 extern tree oacc_launch_pack (unsigned code, tree device, unsigned op);
 extern tree oacc_replace_fn_attrib_attr (tree attribs, tree dims);
--- gcc/omp-general.c.jj2019-10-31 11:05:50.519136130 +0100
+++ gcc/omp-general.c   2019-11-01 14:53:18.593998097 +0100
@@ -947,6 +947,320 @@ omp_context_selector_matches (tree ctx)
   return ret;
 }
 
+/* Compare construct={simd} CLAUSES1 with CLAUSES2, return 0/-1/1/2 as
+   in omp_context_selector_set_compare.  */
+
+static int
+omp_construct_simd_compare (tree clauses1, tree clauses2)
+{
+  if (clauses1 == NULL_TREE)
+return clauses2 == NULL_TREE ? 0 : -1;
+  if (clauses2 == NULL_TREE)
+return 1;
+
+  int r = 0;
+  struct declare_variant_simd_data {
+bool inbranch, notinbranch;
+tree simdlen;
+auto_vec data_sharing;
+auto_vec aligned;
+declare_variant_simd_data ()
+  : inbranch(false), notinbranch(false), simdlen(NULL_TREE) {}
+  } data[2];
+  unsigned int i;
+  for (i = 0; i < 2; i++)
+for (tree c = i ? clauses2 : clauses1; c; c = OMP_CLAUSE_CHAIN (c))
+  {
+   vec *v;
+   switch (OMP_CLAUSE_CODE (c))
+ {
+ case OMP_CLAUSE_INBRANCH:
+   data[i].inbranch = true;
+   continue;
+ case OMP_CLAUSE_NOTINBRANCH:
+   data[i].notinbranch = true;
+   continue;
+ case OMP_CLAUSE_SIMDLEN:
+   data[i].simdlen = OMP_CLAUSE_SIMDLEN_EXPR (c);
+   continue;
+ case OMP_CLAUSE_UNIFORM:
+ case OMP_CLAUSE_LINEAR:
+   v = [i].data_sharing;
+   break;
+ case OMP_CLAUSE_ALIGNED:
+   v = [i].aligned;
+   break;
+ default:
+   gcc_unreachable ();
+ }
+   unsigned HOST_WIDE_INT argno = tree_to_uhwi (OMP_CLAUSE_DECL (c));
+   if (argno >= v->length ())
+ v->safe_grow_cleared (argno + 1);
+   (*v)[argno] = c;
+  }
+  /* Here, r is used as a bitmask, 2 is set if CLAUSES1 has something
+ CLAUSES2 doesn't, 1 is set if CLAUSES2 has something CLAUSES1
+ doesn't.  Thus, r == 3 implies return value 2, r == 1 implies
+ -1, r == 2 implies 1 and r == 0 implies 0.  */
+  if (data[0].inbranch != data[1].inbranch)
+r |= data[0].inbranch ? 2 : 1;
+  if (data[0].notinbranch != data[1].notinbranch)
+r |= data[0].notinbranch ? 2 : 1;
+  if (!simple_cst_equal (data[0].simdlen, data[1].simdlen))
+{
+  if (data[0].simdlen && data[1].simdlen)
+   return 2;
+  r |= data[0].simdlen ? 2 : 1;
+}
+  if (data[0].data_sharing.length () < data[1].data_sharing.length ()
+  || data[0].aligned.length () < data[1].aligned.length ())
+r |= 1;
+  tree c1, c2;
+  FOR_EACH_VEC_ELT (data[0].data_sharing, i, c1)
+{
+  c2 = (i < data[1].data_sharing.length ()
+   ? data[1].data_sharing[i] : NULL_TREE);
+  if ((c1 == NULL_TREE) != (c2 == NULL_TREE))
+   {
+ r |= c1 != NULL_TREE ? 2 : 1;
+ continue;
+   }
+  if (c1 == NULL_TREE)
+   continue;
+  if (OMP_CLAUSE_CODE (c1) != OMP_CLAUSE_CODE (c2))
+   return 2;
+  if (OMP_CLAUSE_CODE (c1) != OMP_CLAUSE_LINEAR)
+   continue;
+  if (OMP_CLAUSE_LINEAR_VARIABLE_STRIDE (c1)
+ != OMP_CLAUSE_LINEAR_VARIABLE_STRIDE (c2))
+   return 2;
+  if (OMP_CLAUSE_LINEAR_KIND (c1) != OMP_CLAUSE_LINEAR_KIND (c2))
+   return 2;
+  if (!simple_cst_equal (OMP_CLAUSE_LINEAR_STEP (c1),
+  

Re: [PATCH] bring -Warray-bounds closer to -Wstringop-overflow (PR91647, 91463, 91679)

[Jakub Jelinek]

On Fri, Nov 01, 2019 at 03:09:39PM -0600, Martin Sebor wrote:
>   * gcc.dg/pr36902.c: Remove xfail.

> --- a/gcc/testsuite/gcc.dg/pr36902.c
> +++ b/gcc/testsuite/gcc.dg/pr36902.c
> @@ -44,7 +44,7 @@ foo2(unsigned char * to, const unsigned char * from, int n)
>*to = *from;
>break;
>  case 5:
> -  to[4] = from [4]; /* { dg-warning "array subscript is above array 
> bounds" "" { xfail *-*-* } } */
> +  to[4] = from [4]; /* { dg-warning "\\\[-Warray-bounds } */
>break;
>  }
>return to;

This FAILs:
+ERROR: gcc.dg/pr36902.c: missing " for " dg-warning 47 "\\[-Warray-bounds "
+ERROR: gcc.dg/pr36902.c: missing " for " dg-warning 47 "\\[-Warray-bounds "
Fixed thusly, regtested on x86_64-linux and i686-linux, committed to trunk
as obvious:

2019-11-02  Jakub Jelinek  

* gcc.dg/pr36902.c: Terminate dg-warning regexp string.

--- gcc/testsuite/gcc.dg/pr36902.c.jj   2019-11-01 22:19:48.757844885 +0100
+++ gcc/testsuite/gcc.dg/pr36902.c  2019-11-02 00:21:00.556117852 +0100
@@ -44,7 +44,7 @@ foo2(unsigned char * to, const unsigned
   *to = *from;
   break;
 case 5:
-  to[4] = from [4]; /* { dg-warning "\\\[-Warray-bounds } */
+  to[4] = from [4]; /* { dg-warning "\\\[-Warray-bounds" } */
   break;
 }
   return to;


Jakub

Re: [PATCH][Aarch64] Fix vec_perm cost for thunderx2t99

[Andrew Pinski]

On Fri, Nov 1, 2019 at 7:03 AM Anton Youdkevitch
 wrote:
>
> Hello,
>
> Here is the one-liner that fixes the incorrect
> vec_perm cost for thunderx2t99 chip.
> With the patch applied 526.blender of CPU2017
> gets ~5% improvement with no measurable changes
> for other benchmarks.
>
> Bootstrapped OK on aarch64-linux-gnu.
>
> OK for trunk?

Maybe the big question is vec_perm used for both 1 input and 2 input
cases?  If so maybe splitting the two cases would be important too.
Otherwise this is ok from my point of view but I can't approve it.


Thanks,
Andrew Pinski

>
> 2019-11-01 Anton Youdkevitch 
>
> * gcc/config/aarch64/aarch64.c (thunderx2t99_vector_cost):
> change vec_perm field
>
> --
>   Thanks,
>   Anton

Re: [PATCH rs6000]Fix PR92132

[Segher Boessenkool]

On Tue, Oct 29, 2019 at 01:16:53PM +0800, Kewen.Lin wrote:
>   (vcond_mask_): New expand.

Say for which mode please?  Like
(vcond_mask_ for VEC_I and VEC_I): New expand.

>   (vcond_mask_): Likewise.

"for VEC_I and VEC_F", here, but the actual names in the pattern are for
vector modes of same-size integer elements.  Maybe it is clear enough like
this, dunno.

>   (vector_{ungt,unge,unlt,unle}): Likewise.

Never use wildcards (or shell expansions) in the "what changed" part of a
changelog, because people try to search for that.

>  ;; 128-bit one's complement
> -(define_insn_and_split "*one_cmpl3_internal"
> +(define_insn_and_split "one_cmpl3_internal"

Instead, rename it to "one_cmpl3" and delete the define_expand that
serves no function?

> +(define_code_iterator fpcmpun [ungt unge unlt unle])

Why these four?  Should there be more?  Should this be added to some
existing iterator?

It's not all comparisons including unordered, there are uneq, unordered
itself, and ne as well.

> +;; Same mode for condition true/false values and predicate operand.
> +(define_expand "vcond_mask_"
> +  [(match_operand:VEC_I 0 "vint_operand")
> +   (match_operand:VEC_I 1 "vint_operand")
> +   (match_operand:VEC_I 2 "vint_operand")
> +   (match_operand:VEC_I 3 "vint_operand")]
> +  "VECTOR_UNIT_ALTIVEC_OR_VSX_P (mode)"
> +{
> +  emit_insn (gen_vector_select_ (operands[0], operands[2], operands[1],
> +   operands[3]));
> +  DONE;
> +})

So is this exactly the same as vsel/xxsel?

> +;; For signed integer vectors comparison.
> +(define_expand "vec_cmp"

> +case GEU:
> +  emit_insn (
> + gen_vector_nltu (operands[0], operands[2], operands[3], tmp));
> +  break;
> +case GTU:
> +  emit_insn (gen_vector_gtu (operands[0], operands[2], 
> operands[3]));
> +  break;
> +case LEU:
> +  emit_insn (
> + gen_vector_ngtu (operands[0], operands[2], operands[3], tmp));
> +  break;
> +case LTU:
> +  emit_insn (gen_vector_gtu (operands[0], operands[3], 
> operands[2]));
> +  break;

You shouldn't allow those for signed comparisons, that will only hide
problems.

You can do all the rest with some iterator / code attribute?  Or two cases,
one for the codes that need ops 2 and 3 swapped, one for the rest?

> +;; For unsigned integer vectors comparison.
> +(define_expand "vec_cmpu"
> +  [(set (match_operand:VEC_I 0 "vint_operand")
> + (match_operator 1 "comparison_operator"
> +   [(match_operand:VEC_I 2 "vint_operand")
> +(match_operand:VEC_I 3 "vint_operand")]))]
> +  "VECTOR_UNIT_ALTIVEC_OR_VSX_P (mode)"
> +{
> +  emit_insn (gen_vec_cmp (operands[0], operands[1],
> +   operands[2], operands[3]));
> +  DONE;
> +})

unsigned_comparison_operator?

Why *are* there separate vec_cmp and vec_cmpu patterns, in the first place?


Segher

[Patch, Fortran] PR90374 Support d0.d, e0.d, es0.d, en0.d, g0.d

[Jerry DeLisle]

Hi all,

The attached patch provides frontend and runtime modifications to allow the 
subject format specifiers. These are allowed as default behavior and under 
-std=f2018.


It does not implement the ew.de0 specifier. I decided to do that part 
separarately since it involves different places in the code.


I will to a Changlog for the testsuite changes. In summary:

modified: fmt_error_10.f to allow it to pass.
modified: fmt_error_7.f likewise.
modified: fmt_error_9.f likewise.
new file: fmt_zero_width.f90 to test the new features.

Regression tested on x86_64-pc-linux-gnu.

OK for trunk?

Jerry

2019-11-01  Jerry DeLisle  

PR fortran/90374
* io.c (check_format): Allow zero width for D, E, EN, and ES
specifiers as default and when -std=F2018 is given. Retain
existing errors when using the -fdec family of flags.


2019-11-01  Jerry DeLisle  

PR fortran/90374
io/format.c (parse_format_list): Relax format checking for
zero width as default and when -std=f2018.
io/format.h (format_token): Move definition to io.h.
io/io.h (format_token): Add definition here to allow access to
this definition at higher levels. Rename the declaration of
write_real_g0 to write_real_w0 and add a new format_token
argumanet so that higher level functions can pass to it the
token so that handling of g0 vs the other zero width specifiers
can be differentiated.
io/transfer.c (formatted_transfer_scalar_write): Add checks for
zero width and call write_real_w0 to handle it.
io/write.c (write_real_g0): Remove.
(write_real_w0): Add new, same as previous write_real_g0 except
check format token to handle the g0 case.

diff --git a/gcc/fortran/io.c b/gcc/fortran/io.c
index b969a1a4738..57a3fdd5152 100644
--- a/gcc/fortran/io.c
+++ b/gcc/fortran/io.c
@@ -922,19 +922,38 @@ data_desc:
 
   if (u != FMT_POSINT)
 	{
+	  if (flag_dec)
+	{
+	  if (flag_dec_format_defaults)
+		{
+		  /* Assume a default width based on the variable size.  */
+		  saved_token = u;
+		  break;
+		}
+	  else
+		{
+		  gfc_error ("Positive width required in format "
+			 "specifier %s at %L", token_to_string (t),
+			 _locus);
+		  saved_token = u;
+		  goto fail;
+		}
+	}
+
+	  format_locus.nextc += format_string_pos;
+	  if (!gfc_notify_std (GFC_STD_F2018,
+			   "positive width required at %L",
+			   _locus))
+	{
+	  saved_token = u;
+	  goto fail;
+	}
 	  if (flag_dec_format_defaults)
 	{
 	  /* Assume a default width based on the variable size.  */
 	  saved_token = u;
 	  break;
 	}
-
-	  format_locus.nextc += format_string_pos;
-	  gfc_error ("Positive width required in format "
-			 "specifier %s at %L", token_to_string (t),
-			 _locus);
-	  saved_token = u;
-	  goto fail;
 	}
 
   u = format_lex ();
diff --git a/gcc/testsuite/gfortran.dg/fmt_error_10.f b/gcc/testsuite/gfortran.dg/fmt_error_10.f
index 7ea6aec1220..6e1a5f60bea 100644
--- a/gcc/testsuite/gfortran.dg/fmt_error_10.f
+++ b/gcc/testsuite/gfortran.dg/fmt_error_10.f
@@ -18,9 +18,9 @@
 
   str = '(1pd0.15)'
   write (line,str,iostat=istat, iomsg=msg) 1.0d0
-  if (istat.ne.5006 .or. msg(1:15).ne."Positive width ") STOP 5
+  if (line.ne."1.000") STOP 5
   read (*,str,iostat=istat, iomsg=msg) x
-  if (istat.ne.5006 .or. msg(1:15).ne."Positive width ") STOP 6
+  if (istat.ne.5006 .or. msg(1:10).ne."Zero width") STOP 6
   if (x.ne.555.25) STOP 7
   
   write (line,'(1pd24.15e11.3)') 1.0d0, 1.234
diff --git a/gcc/testsuite/gfortran.dg/fmt_error_7.f b/gcc/testsuite/gfortran.dg/fmt_error_7.f
index 9b5fba97e25..3937c8fe750 100644
--- a/gcc/testsuite/gfortran.dg/fmt_error_7.f
+++ b/gcc/testsuite/gfortran.dg/fmt_error_7.f
@@ -1,7 +1,9 @@
 ! { dg-do compile }
+! { dg-options "-std=f95" }
+
 ! PR37446 Diagnostic of edit descriptors, esp. EN
   character(40) :: fmt_string
   write(*, '(1P,2E12.4)') 1.0
-  write(*,'(EN)') 5.0 ! { dg-error "Positive width required" }
+  write(*,'(EN)') 5.0 ! { dg-error "positive width required" }
   write(*,'("abcdefg",EN6,"hjjklmnop")') 5.0 ! { dg-error "Period required" }
   end
diff --git a/gcc/testsuite/gfortran.dg/fmt_error_9.f b/gcc/testsuite/gfortran.dg/fmt_error_9.f
index 1d677509e37..40c73599ac8 100644
--- a/gcc/testsuite/gfortran.dg/fmt_error_9.f
+++ b/gcc/testsuite/gfortran.dg/fmt_error_9.f
@@ -16,7 +16,7 @@
   write (line,str,iostat=istat, iomsg=msg) 1.0d0
   if (istat.ne.0) STOP 3
   read (*,str,iostat=istat, iomsg=msg) x
-  if (istat.ne.5006 .or. msg(1:15).ne."Positive width ") STOP 4
+  if (istat.ne.5006 .or. msg(1:10).ne."Zero width") STOP 4
   if (x.ne.555.25) STOP 5
   
   write (line,'(1pd24.15e11.3)') 1.0d0, 1.234
diff --git a/gcc/testsuite/gfortran.dg/fmt_zero_width.f90 b/gcc/testsuite/gfortran.dg/fmt_zero_width.f90
new file mode 

Re: [Patch, GCC]Backporting r269039 to gcc8

[Jeff Law]

On 10/25/19 11:02 AM, Delia Burduv wrote:
> Hello Jeff,
> 
> Yes, it is a backport to gcc-8. No, I don't have commit access. Could
> you please commit it for me?
Done.

Thanks for your patience.
jeff

Re: [PATCH][MSP430] Add -mtiny-printf option to support reduced code size printf and puts

[Jeff Law]

On 10/24/19 2:56 PM, Jozef Lawrynowicz wrote:
> I added support for reduced code size printf and puts functions to Newlib for
> MSP430 a while ago [1]. By removing support for reentrancy, streams and
> buffering we can greatly reduce code size, which is always often a limitation
> when using printf on microcontrollers.
> 
> This patch adds an interface to enable these reduced code size implementations
> from GCC by using the -mtiny-printf option. The tiny printf and puts
> implementations require GCC to be configured with
> --enable-newlib-nano-formatted-io, so there are some modifications to 
> configure
> scripts to support the checking of that.
> 
> -mtiny-printf is merely an alias for passing "--wrap printf --wrap puts" to 
> the
> linker.
> This will replace references to "printf" and "puts" in user
> code with "__wrap_printf" and "__wrap_puts" respectively.
> If there is no implementation of these __wrap* functions in user code,
> these "tiny" printf and puts implementations will be linked into the
> final executable.
> 
> The wrapping mechanism is supposed to be invisible to the user since even if
> they are unaware of the "tiny" implementation, and implement their own 
> __wrap_printf and __wrap_puts, their own implementation will be automatically
> chosen over the "tiny" printf and puts from the library.
> 
> Successfully regtested on trunk by comparing results with -mtiny-printf with a
> set of testresults without the option.
> The new test "gcc.target/msp430/tiny-printf.c" verifies the option behaves as
> expected when GCC is configured with and without
> --enable-newlib-nano-formatted-io.
> 
> Ok to apply?
> 
> [1]
> https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;h=1e6c561d48f
> 
> 
> 0001-MSP430-Add-mtiny-printf-option.patch
> 
> From 4d4e2b6bb92317b2b4db1d99c3f43a167a1e3288 Mon Sep 17 00:00:00 2001
> From: Jozef Lawrynowicz 
> Date: Thu, 24 Oct 2019 13:30:21 +0100
> Subject: [PATCH] MSP430: Add -mtiny-printf option
> 
> gcc/ChangeLog:
> 
> 2019-10-24  Jozef Lawrynowicz  
> 
>   * config.in: Regenerate.
>   * config/msp430/msp430.c (msp430_option_override): Emit an error if
>   -mtiny-printf is used without GCC being configured with
>   --enable-newlib-nano-formatted-io.
>   * config/msp430/msp430.h (LINK_SPEC): Pass 
>   "--wrap puts --wrap printf" when -mtiny-printf is used.
>   * config/msp430/msp430.opt: Document -mtiny-printf.
>   * configure: Regenerate.
>   * configure.ac: Enable --enable-newlib-nano-formatted-io flag.
>   Define HAVE_NEWLIB_NANO_FORMATTED_IO if
>   --enable-newlib-nano-formatted-io is passed.
>   * doc/invoke.texi: Document -mtiny-printf.
OK
jeff

Re: [PATCH] Come up with ggc_delete.

[Jeff Law]

On 10/30/19 9:01 AM, Martin Liška wrote:
> Hi.
> 
> There's a small code refactoring.
> 
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> 
> Ready to be installed?
> Thanks,
> Martin
> 
> 
> 0001-Come-up-with-ggc_delete.patch
> 
> From dc92c8c3e31887b23ef419bc60e3c1607d0e9e53 Mon Sep 17 00:00:00 2001
> From: Martin Liska 
> Date: Wed, 30 Oct 2019 12:50:51 +0100
> Subject: [PATCH] Come up with ggc_delete.
> 
> gcc/ChangeLog:
> 
> 2019-10-30  Martin Liska  
> 
>   * ggc.h (ggc_delete): New function.
>   * ipa-fnsummary.c (ipa_free_fn_summary): Use it.
>   * ipa-prop.c (ipa_free_all_edge_args): Likewise.
>   (ipa_free_all_node_params): Likewise.
>   * ipa-sra.c (ipa_sra_analysis): Likewise.

OK
jeff

Re: [PATCH][MSP430] Read MCU data from external file specified with environment variable or installed into toolchain subdirectory

[Jeff Law]

On 11/1/19 4:53 AM, Jozef Lawrynowicz wrote:
> Each different MSP430 MCU has two properties that affect code generation, 
> which
> are the the CPU ISA and the hardware multiply support. These can be manually
> specified with the -mcpu= and -mhwmult= options, respectively.
> The existing -mmcu= option takes an MCU name as an argument and uses the CPU
> ISA and hardware multiply known to be supported for that MCU, so the user does
> not have to provide the -mcpu and -mhwmult options.
> 
> Currently, the MCU data can be provided in an external "devices.csv" file, and
> this file is already searched for on the paths specified with -I and -L.
> 
> This patch extends the searching behaviour so the path to the directory
> containing devices.csv can either be specified with the 
> "MSP430_GCC_INCLUDE_DIR"
> environment variable, or installed into the msp430-elf/include/devices
> subdirectory of the toolchain.
> The msp430.exp toolchain driver has been extended to ensure these new methods
> can be tested properly.
> 
> Successfully regtested on trunk.
> 
> Ok to apply?
> 
> 
> 0001-MSP430-Read-MCU-data-from-external-file-specified-wi.patch
> 
> From f781013148c2fd242af8526dbcfa2079fe30db07 Mon Sep 17 00:00:00 2001
> From: Jozef Lawrynowicz 
> Date: Wed, 30 Oct 2019 21:10:38 +
> Subject: [PATCH] MSP430: Read MCU data from external file specified with
>  environment variable or installed into toolchain subdirectory
> 
> gcc/ChangeLog:
> 
> 2019-10-31  Jozef Lawrynowicz  
> 
>   * config/msp430/driver-msp430.c 
> (msp430_get_linker_devices_include_path):
>   New spec function.
>   * config/msp430/msp430-devices.c (msp430_dirname): New function.
>   (extract_devices_dir_from_exec_prefix): New function.
>   (extract_devices_dir_from_collect_gcc): New function.
>   (msp430_check_env_var_for_devices): New function.
>   (msp430_check_path_for_devices): Use xstrdup instead of ASTRDUP.
>   (parse_devices_csv): Call msp430_check_env_var_for_devices if
>   devices.csv was not found using other methods.
>   * config/msp430/msp430-devices.h (msp430_check_env_var_for_devices):
>   New prototype.
>   (msp430_dirname): Likewise.
>   * config/msp430/msp430.c (msp430_register_pre_includes): New function.
>   * config/msp430/msp430.h (EXTRA_SPEC_FUNCTIONS): Add
>   msp430_get_linker_devices_include_path.
>   (TARGET_EXTRA_PRE_INCLUDES): Define.
>   * doc/invoke.texi: Document new ways of searching for support files.
> 
> gcc/testsuite/ChangeLog:
> 
> 2019-10-31  Jozef Lawrynowicz  
> 
>   * gcc.target/msp430/devices/csv-using-env-var.c: New test.
>   * gcc.target/msp430/devices/csv-using-installed.c: New test.
>   * gcc.target/msp430/devices/csv-using-option.c: New test.
>   * gcc.target/msp430/devices/devices-main.c: New test source file.
>   * gcc.target/msp430/devices/msp430-devices.h: New test.
>   * gcc.target/msp430/msp430.exp (msp430_device_permutations_runtest):
>   Add special cases for csv-using* tests.
>   Define TESTING_HARD_DATA when running tests that use hard-coded device
>   data.
>   (get_installed_device_data_path): New.
>   (msp430_hide_installed_devices_data): New.
>   (msp430_restore_installed_devices_data): New.
>   (msp430_test_installed_device_data): New.
>   (msp430_install_device_data): New.
OK
jeff

Re: [PATCH] Fix hash_operand for fields of a CONSTRUCTOR.

[Jeff Law]

On 10/31/19 10:01 AM, Martin Liška wrote:
> Hi.
> 
> operand_equal_p can properly handle situation where we have a CONSTRUCTOR
> where indices are NULL:
> 
> if (!operand_equal_p (c0->value, c1->value, flags)
> /* In GIMPLE the indexes can be either NULL or matching i.
>Double check this so we won't get false
>positives for GENERIC.  */
> || (c0->index
> && (TREE_CODE (c0->index) != INTEGER_CST 
> || compare_tree_int (c0->index, i)))
> || (c1->index
> && (TREE_CODE (c1->index) != INTEGER_CST 
> || compare_tree_int (c1->index, i
>   return false;
> 
> but the corresponding hash function always hashes field (which
> can be NULL_TREE or equal to ctor index).
> 
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> 
> Ready to be installed?
> Thanks,
> Martin
> 
> gcc/ChangeLog:
> 
> 2019-10-31  Martin Liska  
> 
>   PR ipa/92304
>   * fold-const.c (operand_compare::hash_operand): Fix field
>   hashing of CONSTRUCTOR.
OK.  One question though, do these routines need to handle
CONSTRUCTOR_NO_CLEARING?

jeff

Re: [C++ PATCH] Implement P1073R3: Immediate functions (PR c++/88335, take 3)

[Jakub Jelinek]

On Fri, Nov 01, 2019 at 09:56:44PM +0100, Jakub Jelinek wrote:
> Ah, used 8.x to test it.  There have been r265787 and r269775 changes in
> between.
> Though
>   auto d = [] () mutable __attribute__((noreturn)) constexpr {};
>   auto e = [] () mutable [[noreturn]] constexpr {};
> is still accepted.  I bet incorrectly though, I can try to fix it in a
> follow-up patch, but can remove the attribute skipping from the consteval
> patch then.

Perhaps like this (untested so far)?
Though, I have to wonder about the other callers of
cp_parser_decl_specifier_seq, whether attributes should be accepted anywhere
in between specifiers or not.

2019-11-01  Jakub Jelinek  

PR c++/89640
* parser.c (cp_parser_decl_specifier_seq): Don't parse attributes
if CP_PARSER_FLAGS_ONLY_MUTABLE_OR_CONSTEXPR.

* g++.dg/cpp1z/attr-lambda1.C: New test.
* g++.dg/ext/attr-lambda2.C: New test.

--- gcc/cp/parser.c.jj  2019-10-31 17:33:19.864518279 +0100
+++ gcc/cp/parser.c 2019-11-01 22:05:24.684037804 +0100
@@ -13965,7 +13965,8 @@ cp_parser_decl_specifier_seq (cp_parser*
   if (!start_token)
start_token = token;
   /* Handle attributes.  */
-  if (cp_next_tokens_can_be_attribute_p (parser))
+  if ((flags & CP_PARSER_FLAGS_ONLY_MUTABLE_OR_CONSTEXPR) == 0
+ && cp_next_tokens_can_be_attribute_p (parser))
{
  /* Parse the attributes.  */
  tree attrs = cp_parser_attributes_opt (parser);
--- gcc/testsuite/g++.dg/cpp1z/attr-lambda1.C.jj2019-11-01 
22:15:57.264378908 +0100
+++ gcc/testsuite/g++.dg/cpp1z/attr-lambda1.C   2019-11-01 22:16:11.143167034 
+0100
@@ -0,0 +1,12 @@
+// PR c++/89640
+// { dg-options "-Wno-attributes" }
+// { dg-do compile { target c++17 } }
+
+void test() {
+[]() mutable [[gnu::cold]] constexpr {}(); // { dg-error 
"expected" }
+[]() constexpr [[gnu::cold]] mutable {}(); // { dg-error 
"expected" }
+[]() [[gnu::cold]] mutable constexpr {}(); // { dg-error 
"expected" }
+[]() [[gnu::cold]] constexpr mutable {}(); // { dg-error 
"expected" }
+[]() mutable constexpr [[gnu::cold]] {}();
+[]() constexpr mutable [[gnu::cold]] {}();
+}
--- gcc/testsuite/g++.dg/ext/attr-lambda2.C.jj  2019-11-01 22:16:25.784943505 
+0100
+++ gcc/testsuite/g++.dg/ext/attr-lambda2.C 2019-11-01 22:16:42.736684714 
+0100
@@ -0,0 +1,12 @@
+// PR c++/89640
+// { dg-options "-Wno-attributes" }
+// { dg-do compile { target c++17 } }
+
+void test() {
+[]() mutable __attribute__((cold)) constexpr {}(); // { dg-error 
"expected" }
+[]() constexpr __attribute__((cold)) mutable {}(); // { dg-error 
"expected" }
+[]() __attribute__((cold)) mutable constexpr {}(); // { dg-error 
"expected" }
+[]() __attribute__((cold)) constexpr mutable {}(); // { dg-error 
"expected" }
+[]() mutable constexpr __attribute__((cold)) {}();
+[]() constexpr mutable __attribute__((cold)) {}();
+}


Jakub

Re: [[PATCH][PR91979] handle mangling of nullptr expression ] updated the fix

[Jason Merrill]

On 10/31/19 2:06 PM, kamlesh kumar wrote:

Jason,
Can you please review this,
let me know how can we handle -fabi-version?


We should bump latest_abi_version in c-opts.c and use 
abi_version_at_least to control this change.



On Wed, Oct 23, 2019 at 7:55 AM Kamlesh Kumar  wrote:


---
  gcc/cp/mangle.c|  3 ++-
  gcc/testsuite/g++.dg/cpp0x/nullptr27.C |  2 +-
  gcc/testsuite/g++.dg/cpp0x/pr91979.C   | 15 +++
  libiberty/cp-demangle.c| 10 ++
  libiberty/testsuite/demangle-expected  |  4 
  5 files changed, 32 insertions(+), 2 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/pr91979.C

diff --git a/gcc/cp/mangle.c b/gcc/cp/mangle.c
index a9333b8..334610c 100644
--- a/gcc/cp/mangle.c
+++ b/gcc/cp/mangle.c
@@ -3400,7 +3400,8 @@ write_template_arg_literal (const tree value)
case INTEGER_CST:
 gcc_assert (!same_type_p (TREE_TYPE (value), boolean_type_node)
 || integer_zerop (value) || integer_onep (value));
-   write_integer_cst (value);
+   if (!NULLPTR_TYPE_P (TREE_TYPE (value)))
+ write_integer_cst (value);
 break;

case REAL_CST:
diff --git a/gcc/testsuite/g++.dg/cpp0x/nullptr27.C 
b/gcc/testsuite/g++.dg/cpp0x/nullptr27.C
index 2510dc8..edd1160 100644
--- a/gcc/testsuite/g++.dg/cpp0x/nullptr27.C
+++ b/gcc/testsuite/g++.dg/cpp0x/nullptr27.C
@@ -1,7 +1,7 @@
  // PR c++/52706
  // { dg-do compile { target c++11 } }
  // { dg-options "-fabi-version=0" }
-// { dg-final { scan-assembler "_Z1fIDnLDn0EEiT_" } }
+// { dg-final { scan-assembler "_Z1fIDnLDnEEiT_" } }

  template
  int f(T);
diff --git a/gcc/testsuite/g++.dg/cpp0x/pr91979.C 
b/gcc/testsuite/g++.dg/cpp0x/pr91979.C
new file mode 100644
index 000..7fcd56b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/pr91979.C
@@ -0,0 +1,15 @@
+// PR c++/91989
+// { dg-do compile { target c++11 } }
+// { dg-final { scan-assembler "_Z3fooILPv0EEvPN9enable_ifIXeqT_LDnEEvE4typeE" 
} }
+
+template 
+struct enable_if {};
+
+template 
+struct enable_if { typedef T type; };
+
+template 
+void foo(typename enable_if::type* = 0) {}
+
+template void foo<(void *)0>(void *);
+
diff --git a/libiberty/cp-demangle.c b/libiberty/cp-demangle.c
index aa78c86..3c32b26 100644
--- a/libiberty/cp-demangle.c
+++ b/libiberty/cp-demangle.c
@@ -3577,6 +3577,16 @@ d_expr_primary (struct d_info *di)
   && type->u.s_builtin.type->print != D_PRINT_DEFAULT)
 di->expansion -= type->u.s_builtin.type->len;

+  if (type->type == DEMANGLE_COMPONENT_BUILTIN_TYPE
+  && 
strncmp(type->u.s_builtin.type->name,cplus_demangle_builtin_types[33].name,17) == 0)


This line is too long and needs more spaces: before the ( and after commas.


+{
+  if (d_peek_char (di) == 'E')
+{
+  d_advance (di, 1);
+  return type;
+}
+}
+
/* Rather than try to interpret the literal value, we just
  collect it as a string.  Note that it's possible to have a
  floating point literal here.  The ABI specifies that the
diff --git a/libiberty/testsuite/demangle-expected 
b/libiberty/testsuite/demangle-expected
index f21ed00..b23a7c2 100644
--- a/libiberty/testsuite/demangle-expected
+++ b/libiberty/testsuite/demangle-expected
@@ -1446,3 +1446,7 @@ Foo()::X::fn
  _ZZZ3FooIiEfvENKUlT_E_clIcEEDaS0_EN1X2fnEv
  Foo()::{lambda(auto:1)#1}::operator()(char) const::X::fn()
  Foo()::{lambda(auto:1)#1}::operator()(char) const::X::fn
+#PR91979 demangling nullptr expression
+
+_Z3fooILPv0EEvPN9enable_ifIXeqT_LDnEEvE4typeE
+void foo<(void*)0>(enable_if<((void*)0)==((decltype(nullptr))), void>::type*)
--
1.8.5.6

Re: [PATCH] bring -Warray-bounds closer to -Wstringop-overflow (PR91647, 91463, 91679)

[Martin Sebor]

On 10/31/19 12:54 PM, Jeff Law wrote:

On 10/11/19 10:34 AM, Martin Sebor wrote:

I've fixed the bug in the attached patch.  The rest can be suppressed
by replacing the zero-length arrays with flexible array members but
that's just trading one misuse for another.  If the code can't be
changed to avoid this (likely not an option since the arrays are in
visible in the public API) I think the best way to deal with them is
to suppress them by #pragma GCC diagnostic ignored.  I opened BZ 25097
in Glibc Bugzilla to track this.

While it's trading one misuse for another, one could argue that a
flexible array is less of a misuse :-)



The patch triggers 94 instances of -Warray-bounds (60 of which
are for distinct code) in 21 .c files.  I haven't looked at all
of them but some of the patterns I noticed are:

1) Intentionally using an interior zero-length array to access
    (e.g., memset) one or more subsequent members. E.g.,
    _dbgp_external_startup in drivers/usb/early/ehci-dbgp.c and
    quite a few others.  This is pretty pervasive but seems easily
    avoidable.

Yea, I saw something like this as well.  I can't recall if it was in the
kernel or a package that was reading structured data of some sort.
THey'd use the zero length array to access the entire blob-o-data and
subsequent fields when they wanted to access particular chunks of data
that were at well known offsets from the start.




2) Overwriting a member array with more data (e.g., function
    cxio_rdev_open in
    drivers/infiniband/hw/cxgb3/cxio_hal.c or in function
    pk_probe in drivers/hid/hid-prodikeys.c).  At first glance
    some of these look like bugs but with stuff obscured by macros
    and no comments it's hard to tell.

ACK.



3) Uses of the container_of() macro to access one member given
    the address of another.  This is undefined (and again breaks
    the aliasing rules) but the macro is used all over the place
    in the kernel.  I count over 15,000 references to it.

Ugh.



4) Uses of one-element arrays as members of other one-element
    arrays (in include/scsi/fc/fc_ms.h).  Was this ever meant
    to be supported by GCC?  (It isn't by _FORTIFY_SOURCE=2.)

5) Possible false positives due to the recent loop unrolling
    change.

I think I've worked around some #5 issues as well.  It's got an
aassociated BZ and hopefully will be addressed during stage3/stage4.



It will be a quite a bit of work to clean this up.  To make it
easier we would introduce a new option to control the warning
for some of the most common idioms, such as
-Wzero-length-array-bounds.  I'm not too wild about this because
it would just paper over the problem.  A better solution would
also involve avoiding the aliasing assumptions for overlapping
zero-length member arrays.

Anyway, attached is the updated patch with just the one fix
I mentioned above, retested on x86_64-linux.

I think the agreement in our meeting yesterday was to give some kind of
knob, particularly for the kernel folks.




Martin

gcc-91647.diff

PR middle-end/91679 - missing -Warray-bounds accessing a member array in a 
local buffer
PR middle-end/91647 - new FAILs for Warray-bounds-8 and Wstringop-overflow-3.C
PR middle-end/91463 - missing -Warray-bounds accessing past the end of a 
statically initialized flexible array member

gcc/ChangeLog:

PR middle-end/91679
PR middle-end/91647
PR middle-end/91463
* tree-vrp.c (vrp_prop::check_array_ref): Handle trailing arrays with
initializers.
(vrp_prop::check_mem_ref): Handle declared struct objects.
* tree.c (last_field): New function.
(array_at_struct_end_p): Handle MEM_REF.
(get_initializer_for): New helper.
(component_ref_size): Rename locals.  Call get_initializer_for instead
of fold_ctor_reference.  Correct handling of flexible array members.
* wide-int.h (generic_wide_int ::sign_mask): Assert invariant.

gcc/testsuite/ChangeLog:

PR middle-end/91679
PR middle-end/91647
PR middle-end/91463
* c-c++-common/Warray-bounds-2.c: Disable VRP.  Adjust expected 
messages.
* gcc.dg/Warray-bounds-48.c: New test.
* gcc.dg/Warray-bounds-49.c: New test.
* gcc.dg/Wstringop-overflow-16.c: Adjust text of expected messages.
* gcc.dg/pr36902.c: Remove xfail.
* gcc.dg/strlenopt-57.c: Add an expected warning.

So per our meeting yesterday, add a knob for the kernel folks to be able
to control this and it's OK.


I've added a new option, -Wzero-length-bounds to control this.
It complicates the get_component_size function a bit but the rest
of the changes weren't intrusive.

To make a clear distinction between zero-length arrays and flexible
array members in dianostics I tweaked how the former are shown and
added the zero.  With that, a zero-length array is now rendered as
char[0] and not as char[] as it was before, and as flexible arrays
still are.

I also had to work around by using memcpy 

Re: C++ PATCH for c++/91363 - P0960R3: Parenthesized initialization of aggregates

[Jason Merrill]

On 11/1/19 4:42 PM, Marek Polacek wrote:

On Fri, Nov 01, 2019 at 04:37:15PM -0400, Jason Merrill wrote:

On 10/22/19 10:53 AM, Marek Polacek wrote:

This patch implements C++20 P0960R3: Parenthesized initialization of aggregates
(; see R0 for more background info).  Essentially, if you have
an aggregate, you can now initialize it by (x, y), similarly to {x, y}.  E.g.

struct A {
  int x, y;
  // no A(int, int) ctor (see paren-init14.C for = delete; case)
};
A a(1, 2);

The difference between ()-init and {}-init is that narrowing conversions are
permitted, designators are not permitted, a temporary object bound to
a reference does not have its lifetime extended, and there is no brace elision.
Further, things like

int a[](1, 2, 3); // will deduce the array size
const A& r(1, 2.3, 3); // narrowing is OK
int (&)[](1, 2, 3);
int b[3](1, 2); // b[2] will be value-initialized

now work as expected.  Note that

char f[]("fluff");

has always worked and this patch keeps it that way.  Also note that A a((1, 2))
is not the same as A a{{1,2}}; the inner (1, 2) remains a COMPOUND_EXPR.

The approach I took was to handle (1, 2) similarly to {1, 2} -- conjure up
a CONSTRUCTOR, and introduce LOOKUP_AGGREGATE_PAREN_INIT to distinguish
between the two.  This kind of initialization is only supported in C++20;
I've made no attempt to support it in earlier standards, like we don't
support CTAD pre-C++17, for instance.


Could we use a flag on the CONSTRUCTOR to distinguish between them instead,
rather than a LOOKUP flag and a flag in the conversion?


I think I tried and it didn't play well with digest_init and narrowing.
If we have { 2.0 } then when recursing on the CONSTRUCTOR element we
don't know it came from a paren-init, so a LOOKUP flag was necessary.


Ah, good point.  Perhaps process_init_constructor could add that flag 
based on the CONSTRUCTOR flag rather than use rvaluedness_matches_p? 
That ought to avoid a few of the changes.  And extend_ref_init_temps 
could check it rather than change store_init_value.


It also looks like you're using the LOOKUP flag to mean two different 
things:


1) try to treat parenthesized args as an aggregate initializer 
(build_new_method_call_1)
2) treat this CONSTRUCTOR as coming from parenthesized args 
(store_init_value/digest_init)


Why is the flag needed for #1?  When do we not want to try to treat the 
args as an aggregate initializer?


Jason

Re: [C++ PATCH] Implement P1073R3: Immediate functions (PR c++/88335, take 3)

[Jakub Jelinek]

On Fri, Nov 01, 2019 at 04:42:45PM -0400, Jason Merrill wrote:
> It isn't accepted for me:
> 
> wa3.C: In function 'void foo()':
> wa3.C:4:29: warning: attribute ignored [-Wattributes]
> 4 |   auto a = [] () [[noreturn]] constexpr {};
>   | ^
> wa3.C:4:29: note: an attribute that appertains to a type-specifier is
> ignored
> wa3.C: In lambda function:
> wa3.C:4:31: error: expected '{' before 'constexpr'
> 4 |   auto a = [] () [[noreturn]] constexpr {};
>   |   ^
> wa3.C: In function 'void foo()':
> wa3.C:4:31: error: expected ',' or ';' before 'constexpr'
> wa3.C: In lambda function:
> wa3.C:5:44: error: expected '{' before 'constexpr'
> 5 |   auto b = [] () __attribute__((noreturn)) constexpr {};
>   |^
> wa3.C: In function 'void foo()':
> wa3.C:5:44: error: expected ',' or ';' before 'constexpr'
> 
> Moving constexpr before the attributes makes it compile.

Ah, used 8.x to test it.  There have been r265787 and r269775 changes in
between.
Though
  auto d = [] () mutable __attribute__((noreturn)) constexpr {};
  auto e = [] () mutable [[noreturn]] constexpr {};
is still accepted.  I bet incorrectly though, I can try to fix it in a
follow-up patch, but can remove the attribute skipping from the consteval
patch then.

> > The code should handle mutable consteval, as mutable is a keyword and it
> > will just keep looking after that keyword.
> 
> Ah, right.

Jakub

Re: [C++ PATCH] Implement P1073R3: Immediate functions (PR c++/88335, take 3)

[Jason Merrill]

On 11/1/19 3:57 PM, Jakub Jelinek wrote:

On Fri, Nov 01, 2019 at 03:42:58PM -0400, Jason Merrill wrote:

+ for (size_t n = cp_parser_skip_balanced_tokens (parser, 1); ; n++)
+   {
+ size_t after = cp_parser_skip_attributes_opt (parser, n);
+ if (after > n)
+   {
+ n = after - 1;
+ continue;
+   }


You don't need to skip attributes, the decl-specifiers come immediately
after the ).


void
foo ()
{
   auto a = [] () [[noreturn]] constexpr {};
   auto b = [] () __attribute__((noreturn)) constexpr {};
   auto c = [] () mutable constexpr {};
}

(using constexpr instead of consteval to be able to test it without my
patch) is certainly accepted, not sure if that is conforming or not.


It isn't accepted for me:

wa3.C: In function 'void foo()':
wa3.C:4:29: warning: attribute ignored [-Wattributes]
4 |   auto a = [] () [[noreturn]] constexpr {};
  | ^
wa3.C:4:29: note: an attribute that appertains to a type-specifier is 
ignored

wa3.C: In lambda function:
wa3.C:4:31: error: expected '{' before 'constexpr'
4 |   auto a = [] () [[noreturn]] constexpr {};
  |   ^
wa3.C: In function 'void foo()':
wa3.C:4:31: error: expected ',' or ';' before 'constexpr'
wa3.C: In lambda function:
wa3.C:5:44: error: expected '{' before 'constexpr'
5 |   auto b = [] () __attribute__((noreturn)) constexpr {};
  |^
wa3.C: In function 'void foo()':
wa3.C:5:44: error: expected ',' or ';' before 'constexpr'

Moving constexpr before the attributes makes it compile.


The code should handle mutable consteval, as mutable is a keyword and it
will just keep looking after that keyword.


Ah, right.

Jason

Re: C++ PATCH for c++/91363 - P0960R3: Parenthesized initialization of aggregates

[Marek Polacek]

On Fri, Nov 01, 2019 at 04:37:15PM -0400, Jason Merrill wrote:
> On 10/22/19 10:53 AM, Marek Polacek wrote:
> > This patch implements C++20 P0960R3: Parenthesized initialization of 
> > aggregates
> > (; see R0 for more background info).  Essentially, if you 
> > have
> > an aggregate, you can now initialize it by (x, y), similarly to {x, y}.  
> > E.g.
> > 
> >struct A {
> >  int x, y;
> >  // no A(int, int) ctor (see paren-init14.C for = delete; case)
> >};
> >A a(1, 2);
> > 
> > The difference between ()-init and {}-init is that narrowing conversions are
> > permitted, designators are not permitted, a temporary object bound to
> > a reference does not have its lifetime extended, and there is no brace 
> > elision.
> > Further, things like
> > 
> >int a[](1, 2, 3); // will deduce the array size
> >const A& r(1, 2.3, 3); // narrowing is OK
> >int (&)[](1, 2, 3);
> >int b[3](1, 2); // b[2] will be value-initialized
> > 
> > now work as expected.  Note that
> > 
> >char f[]("fluff");
> > 
> > has always worked and this patch keeps it that way.  Also note that A a((1, 
> > 2))
> > is not the same as A a{{1,2}}; the inner (1, 2) remains a COMPOUND_EXPR.
> > 
> > The approach I took was to handle (1, 2) similarly to {1, 2} -- conjure up
> > a CONSTRUCTOR, and introduce LOOKUP_AGGREGATE_PAREN_INIT to distinguish
> > between the two.  This kind of initialization is only supported in C++20;
> > I've made no attempt to support it in earlier standards, like we don't
> > support CTAD pre-C++17, for instance.
> 
> Could we use a flag on the CONSTRUCTOR to distinguish between them instead,
> rather than a LOOKUP flag and a flag in the conversion?

I think I tried and it didn't play well with digest_init and narrowing.
If we have { 2.0 } then when recursing on the CONSTRUCTOR element we
don't know it came from a paren-init, so a LOOKUP flag was necessary.

Marek

Re: C++ PATCH for c++/91363 - P0960R3: Parenthesized initialization of aggregates

[Jason Merrill]

On 10/22/19 10:53 AM, Marek Polacek wrote:

This patch implements C++20 P0960R3: Parenthesized initialization of aggregates
(; see R0 for more background info).  Essentially, if you have
an aggregate, you can now initialize it by (x, y), similarly to {x, y}.  E.g.

   struct A {
 int x, y;
 // no A(int, int) ctor (see paren-init14.C for = delete; case)
   };
   A a(1, 2);

The difference between ()-init and {}-init is that narrowing conversions are
permitted, designators are not permitted, a temporary object bound to
a reference does not have its lifetime extended, and there is no brace elision.
Further, things like

   int a[](1, 2, 3); // will deduce the array size
   const A& r(1, 2.3, 3); // narrowing is OK
   int (&)[](1, 2, 3);
   int b[3](1, 2); // b[2] will be value-initialized

now work as expected.  Note that

   char f[]("fluff");

has always worked and this patch keeps it that way.  Also note that A a((1, 2))
is not the same as A a{{1,2}}; the inner (1, 2) remains a COMPOUND_EXPR.

The approach I took was to handle (1, 2) similarly to {1, 2} -- conjure up
a CONSTRUCTOR, and introduce LOOKUP_AGGREGATE_PAREN_INIT to distinguish
between the two.  This kind of initialization is only supported in C++20;
I've made no attempt to support it in earlier standards, like we don't
support CTAD pre-C++17, for instance.


Could we use a flag on the CONSTRUCTOR to distinguish between them 
instead, rather than a LOOKUP flag and a flag in the conversion?


Jason

[PATCH] RISC-V: Build soft-float divide routines for -mno-fdiv.

[Jim Wilson]

Using -mno-fdiv gives linker errors unless we build the missing divide
routines in libgcc always.  There is at least one university project
designing RISC-V parts without FP divide that wants to use the option.

Tested by hand with single-float and double-float builds to verify that
the -mno-fdiv option works with the patch.  Also tested with rv32-newlib
and rv64-linux cross builds and make check, with no regressions.

Committed.

Jim

libgcc/
* config/riscv/t-softfp32 (softfp_extra): Add FP divide routines
---
 libgcc/config/riscv/t-softfp32 | 17 +
 1 file changed, 17 insertions(+)

diff --git a/libgcc/config/riscv/t-softfp32 b/libgcc/config/riscv/t-softfp32
index 1bd51e803d1..59be1df827e 100644
--- a/libgcc/config/riscv/t-softfp32
+++ b/libgcc/config/riscv/t-softfp32
@@ -12,7 +12,11 @@ softfp_float_modes := tf
 softfp_extensions := sftf dftf
 softfp_truncations := tfsf tfdf
 
+# Enable divide routines to make -mno-fdiv work.
+softfp_extras := divsf3 divdf3
+
 else
+# !ABI_DOUBLE
 
 softfp_float_modes := df tf
 softfp_extensions := sfdf sftf dftf
@@ -20,7 +24,20 @@ softfp_truncations := dfsf tfsf tfdf
 
 ifndef ABI_SINGLE
 softfp_float_modes += sf
+else
+# ABI_SINGLE
+
+# Enable divide routines to make -mno-fdiv work.
+softfp_extras := divsf3
+
 endif
 
 endif
+
+else
+# ABI_QUAD
+
+# Enable divide routines to make -mno-fdiv work.
+softfp_extras := divsf3 divdf3 divtf3
+
 endif
-- 
2.17.1

Re: [ C++ ] [ PATCH ] [ RFC ] p1301 - [[nodiscard("should have a reason")]]

[Jason Merrill]

On Sat, Oct 19, 2019 at 6:35 PM Jakub Jelinek  wrote:
>
> Hi!
>
> On Sat, Oct 19, 2019 at 12:46:56AM -0400, Jason Merrill wrote:
> > gcc/testsuite/g++.dg/cpp2a
> > * nodiscard-construct.C: New test.
> > * nodiscard-once.C: New test.
> > * nodiscard-reason-nonstring.C: New test.
> > * nodiscard-reason-only-one.C: New test.
> > * nodiscard-reason.C: New test.
>
> Unfortunately, the tests break testing with check-c++-all,
> ERROR: tcl error sourcing /home/jakub/src/gcc/gcc/testsuite/g++.dg/dg.exp.
> ERROR: couldn't compile regular expression pattern: quantifier operand invalid
> while executing
> "regsub -all "(^|\n)(\[^\n\]+$line\[^\n\]*($pattern)\[^\n\]*\n?)+" 
> $comp_output "\n" comp_output"
> (procedure "saved-dg-test" line 125)
> invoked from within
> "saved-dg-test 
> /home/jakub/src/gcc/gcc/testsuite/g++.dg/cpp2a/nodiscard-reason-only-one.C { 
> -std=gnu++2a} { -pedantic-errors -Wno-long-long}"
> ("eval" body line 1)
> invoked from within
> "eval saved-dg-test $args "
> (procedure "dg-test" line 4)
> invoked from within
> "dg-test $test "$flags $flags_t" ${default-extra-flags}"
> (procedure "g++-dg-runtest" line 40)
> invoked from within
> "g++-dg-runtest $tests "" $DEFAULT_CXXFLAGS"
> (file "/home/jakub/src/gcc/gcc/testsuite/g++.dg/dg.exp" line 46)
> invoked from within
> "source /home/jakub/src/gcc/gcc/testsuite/g++.dg/dg.exp"
> ("uplevel" body line 1)
> invoked from within
> "uplevel #0 source /home/jakub/src/gcc/gcc/testsuite/g++.dg/dg.exp"
> invoked from within
> "catch "uplevel #0 source $test_file_name""
> testcase /home/jakub/src/gcc/gcc/testsuite/g++.dg/dg.exp completed in 291 
> seconds
>
> The problem is that tcl allows (?n) only at the start of the regex string,
> but for e.g. dg-warning or dg-error, gcc_error_prefix etc. is added to the
> start of the regex, e.g. (fatal )?error:
> so
> { dg-error "(?n)wrong number of arguments..*nodiscard" }
> will result in regex
> "(fatal )?error:(?n)wrong number of arguments..*nodiscard"
> and tcl will complain.
>
> I've just committed as obvious a mechanical change to unbreak this.
>
> Even with this change there are some FAILs, but not tcl errors already:
> FAIL: g++.dg/cpp2a/nodiscard-once.C  -std=gnu++2a (test for excess errors)
> FAIL: g++.dg/cpp2a/nodiscard-reason.C  -std=gnu++2a  (test for warnings, line 
> 16)
> FAIL: g++.dg/cpp2a/nodiscard-reason.C  -std=gnu++2a  (test for warnings, line 
> 17)
> FAIL: g++.dg/cpp2a/nodiscard-reason.C  -std=gnu++2a  (test for warnings, line 
> 176)
> FAIL: g++.dg/cpp2a/nodiscard-reason.C  -std=gnu++2a  (test for warnings, line 
> 178)
> FAIL: g++.dg/cpp2a/nodiscard-reason.C  -std=gnu++2a  (test for warnings, line 
> 183)
> FAIL: g++.dg/cpp2a/nodiscard-reason.C  -std=gnu++2a  (test for warnings, line 
> 185)
> FAIL: g++.dg/cpp2a/nodiscard-reason.C  -std=gnu++2a  (test for warnings, line 
> 190)
> FAIL: g++.dg/cpp2a/nodiscard-reason.C  -std=gnu++2a  (test for warnings, line 
> 192)
> FAIL: g++.dg/cpp2a/nodiscard-reason.C  -std=gnu++2a (test for excess errors)
>
> I'll defer to the patch author to resolve those, nodiscard-once is missing
> one dg-warning line, but in the other tests there are quite a few warning
> differences and the question is if it is desirable to change the testcase to
> match what the compiler is doing, or change what the compiler is doing.

What the compiler is doing seems reasonable to me, so I'm going to
adjust the tests.
commit ce706422720f55841b1a5d37c4ef5fbff2182464
Author: Jason Merrill 
Date:   Fri Nov 1 11:16:34 2019 -0400

Fix nodiscard test failures.

* g++.dg/cpp2a/nodiscard-once.C: Expect nodiscard warning.
* g++.dg/cpp2a/nodiscard-reason.C: Adjust expected warnings.

diff --git a/gcc/testsuite/g++.dg/cpp2a/nodiscard-once.C b/gcc/testsuite/g++.dg/cpp2a/nodiscard-once.C
index b9dde5cfb57..78349715aae 100644
--- a/gcc/testsuite/g++.dg/cpp2a/nodiscard-once.C
+++ b/gcc/testsuite/g++.dg/cpp2a/nodiscard-once.C
@@ -7,6 +7,6 @@
 void
 test (void)
 {
-  check1 ();
+  check1 ();			// { dg-warning "nodiscard" }
   (void) check1 ();
 }
diff --git a/gcc/testsuite/g++.dg/cpp2a/nodiscard-reason.C b/gcc/testsuite/g++.dg/cpp2a/nodiscard-reason.C
index e0230b1d519..5fda058c9ee 100644
--- a/gcc/testsuite/g++.dg/cpp2a/nodiscard-reason.C
+++ b/gcc/testsuite/g++.dg/cpp2a/nodiscard-reason.C
@@ -13,8 +13,8 @@ typedef struct { char big[1024]; fnt fn; } C;
 struct [[nodiscard("exact_D_message")]] D { int i; D(); ~D(); };
 
 NODIS E check1 (void);
-NODIS void check2 (void); /* { dg-warning "10:.nodiscard\[^\n\r]*exact_message" } */
-NODIS int foo; /* { dg-warning "9:.nodiscard\[^\n\r]*exact_message" } */
+NODIS void check2 (void); /* { dg-warning "12:.nodiscard\[^\n\r]*void" } */
+NODIS int foo; /* { dg-warning "11:.nodiscard\[^\n\r]*class" } */
 int bar (void);
 NODISAI E check3 (void) { return (E)bar (); }
 NODIS A check4 (void);
@@ 

Re: [C++ PATCH] Implement P1073R3: Immediate functions (PR c++/88335, take 3)

[Jakub Jelinek]

On Fri, Nov 01, 2019 at 03:42:58PM -0400, Jason Merrill wrote:
> > + for (size_t n = cp_parser_skip_balanced_tokens (parser, 1); ; n++)
> > +   {
> > + size_t after = cp_parser_skip_attributes_opt (parser, n);
> > + if (after > n)
> > +   {
> > + n = after - 1;
> > + continue;
> > +   }
> 
> You don't need to skip attributes, the decl-specifiers come immediately
> after the ).

void
foo ()
{
  auto a = [] () [[noreturn]] constexpr {};
  auto b = [] () __attribute__((noreturn)) constexpr {};
  auto c = [] () mutable constexpr {};
}

(using constexpr instead of consteval to be able to test it without my
patch) is certainly accepted, not sure if that is conforming or not.

The grammar has
decl-specifier-seq[opt] after the ) in lambda-declarator and
decl-specifier-seq:
  decl-specifier attribute-specifier-seq[opt]
  decl-specifier decl-specifier-seq
so I'd say attribute-specifier-seq is only allowed at the very end of the
decl-specifier-seq, so maybe we have an accepts-invalid bug, but the
grammar doesn't cover the GNU attributes anyway.

> 
> OK with that change.
> 
> > + if (!cp_lexer_nth_token_is (parser->lexer, n, CPP_KEYWORD))
> > +   break;
> > + if (cp_lexer_peek_nth_token (parser->lexer, n)->keyword
> > + == RID_CONSTEVAL)
> 
> I suppose it's reasonable to not consider "mutable consteval" here.  :)
> 
> > +   {
> > + is_consteval = true;
> > + break;
> > +   }

The code should handle mutable consteval, as mutable is a keyword and it
will just keep looking after that keyword.

Jakub

Re: [C++ Patch] Add location parameter to composite_pointer_type and use it

[Jason Merrill]

On 11/1/19 10:06 AM, Paolo Carlini wrote:

Hi again,

On 31/10/19 16:56, Paolo Carlini wrote:

Hi,

yesterday I noticed that we want to forward the location parameter of 
cp_build_binary_op to composite_pointer_type and then 
composite_pointer_error. Note, for the time being at least, this is 
always for CPO_COMPARISON, the other two composite_pointer_operation 
cases aren't involved - and the various functions (eg, 
common_pointer_type) forward input_location - but I'm consistently 
changing all the pedwarn, emit_diagnostic, and error_at anyway to use 
the location.


In fact, build_conditional_expr_1, which passes CPO_CONDITIONAL_EXPR, 
has available a suitable location, thus we can extend my previous patch 
and forward that too instead of input_location. Tested as usual 
x86_64-linux.


Thanks, Paolo.

/


OK.

Re: [C++ PATCH] Implement P1073R3: Immediate functions (PR c++/88335, take 3)

[Jason Merrill]

On 10/31/19 1:21 PM, Jakub Jelinek wrote:

On Wed, Oct 30, 2019 at 05:06:00PM -0400, Jason Merrill wrote:

build_cplus_new does the magic of replacing a dummy argument, e.g.


   if (obj_arg && is_dummy_object (obj_arg))
 {
   call = build_cplus_new (DECL_CONTEXT (fndecl), call, complain);
   obj_arg = NULL_TREE;
 }


And then if the return value from build_special_member_call is
TREE_CONSTANT, we can return that directly from build_value_init rather than
look for an AGGR_INIT_EXPR.


Ok, that works.


Hmm, it shouldn't be hard to scan ahead to see if there's a consteval after
the parameter list.


Done it that way, we already have all the needed skip routines so nothing
really needs to be parsed, just skipped.

I've added some further tests and run into another issue, that for const
or constexpr vars with consteval ctor constexpr evaluation complained that
the ctor can't modify non-static data members in the object.  The problem
was that obj_arg passed in that case was *(S *) where var had const S
type, so had to add code to pass var in that case.

Bootstrapped/regtested on x86_64-linux and i686-linux, all tests pass now,
ok for trunk?

2019-10-31  Jakub Jelinek  

PR c++/88335 - Implement P1073R3: Immediate functions
c-family/
* c-common.h (enum rid): Add RID_CONSTEVAL.
* c-common.c (c_common_reswords): Add consteval.
cp/
* cp-tree.h (struct lang_decl_fn): Add immediate_fn_p bit.
(DECL_IMMEDIATE_FUNCTION_P, SET_DECL_IMMEDIATE_FUNCTION_P): Define.
(enum cp_decl_spec): Add ds_consteval.
(fold_non_dependent_expr): Add another tree argument defaulted to
NULL_TREE.
* name-lookup.h (struct cp_binding_level): Add immediate_fn_ctx_p
member.
* parser.c (cp_keyword_starts_decl_specifier_p): Adjust comments
for C++11 and C++20 specifiers.  Handle RID_CONSTEVAL.
(CP_PARSER_FLAGS_ONLY_MUTABLE_OR_CONSTEXPR): Adjust comment.
(CP_PARSER_FLAGS_CONSTEVAL): New.
(cp_parser_skip_balanced_tokens): New forward declaration.
(cp_parser_lambda_declarator_opt): Handle ds_consteval.  Set
current_binding_level->immediate_fn_ctx_p before parsing parameter
list if decl-specifier-seq contains consteval specifier.
(cp_parser_decl_specifier_seq): Handle RID_CONSTEVAL.
(cp_parser_explicit_instantiation): Diagnose explicit instantiation
with consteval specifier.
(cp_parser_init_declarator): For consteval or into flags
CP_PARSER_FLAGS_CONSTEVAL.
(cp_parser_direct_declarator): If CP_PARSER_FLAGS_CONSTEVAL, set
current_binding_level->immediate_fn_ctx_p in the sk_function_parms
scope.
(set_and_check_decl_spec_loc): Add consteval entry, formatting fix.
* call.c (build_addr_func): For direct calls to immediate functions
use build_address rather than decay_conversion.
(build_over_call): Evaluate immediate function invocations.
* error.c (dump_function_decl): Handle DECL_IMMEDIATE_FUNCTION_P.
* semantics.c (expand_or_defer_fn_1): Use tentative linkage and don't
call mark_needed for immediate functions.
* typeck.c (cxx_sizeof_or_alignof_expr): Likewise.  Formatting fix.
(cp_build_addr_expr_1): Reject taking address of immediate function
outside of immediate function.
* decl.c (validate_constexpr_redeclaration): Diagnose consteval
vs. non-consteval or vice versa redeclaration.  Use
SET_DECL_IMMEDIATE_FUNCTION_P if new_decl is immediate function.
(check_tag_decl): Use %qs with keyword string to simplify translation.
Handle ds_consteval.
(start_decl): Adjust diagnostics for static or thread_local variables
in immediate functions.
(grokfndecl): Call sorry_at on virtual consteval.  Use %qs with keyword
to string to simplify translation.  Diagnose consteval main.  Use
SET_DECL_IMMEDIATE_FUNCTION_P for consteval.
(grokdeclarator): Handle consteval.  Use %qs with keyword strings to
simplify translation.  Use separate ifs instead of chained else if
for invalid specifiers.  For constinit clear constinit_p rather than
constexpr_p.
* constexpr.c (find_immediate_fndecl): New function.
(cxx_eval_outermost_constant_expr): Allow consteval calls returning
void.  Diagnose returning address of immediate function from consteval
evaluation.
(fold_non_dependent_expr_template): Add OBJECT argument, pass it
through to cxx_eval_outermost_constant_expr.
(fold_non_dependent_expr): Add OBJECT argument, pass it through to
fold_non_dependent_expr_template.
(fold_non_dependent_init): Adjust fold_non_dependent_expr_template
caller.
* method.c (defaulted_late_check): Adjust diagnostics for consteval.
* lambda.c 

Re: [C++ PATCH] P0784R7 constexpr new further fix (PR c++/91369)

[Jason Merrill]

On 10/31/19 1:10 PM, Jakub Jelinek wrote:

On Wed, Oct 30, 2019 at 11:05:29PM +0100, Jakub Jelinek wrote:

Looks like there used to be a TREE_CALLS_NEW flag in TREE_LANG_FLAG_1, but
that flag is now free for CALL_EXPR.


I'll try a CALL_EXPR flag first.


TREE_LANG_FLAG_1 is also STMT_IS_FULL_EXPR_P, and while it is mostly guarded
with STATEMENT_CODE_P checks, in add_stmt it is not.  Are we sure that we
never add_stmt a CALL_EXPR?


I wouldn't think so, but we might add the check there too.


I've picked up TREE_LANG_FLAG_2 instead which looked unused on CALL_EXPR.


OK.


Below is the patch that rejects ::operator new and ::operator delete
calls used directly by users (with the STL exteption), but doesn't try to
diagnose what is discussed below.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?


OK.


Another thing is that even with that change,
std::allocator a;
auto p = a.allocate (1);
*p = 1;
a.deallocate (p, 1);
would be accepted during constexpr evaluation, because allocate already
has the cast which turns "heap uninit" variable into "heap " and assigns
it a type, so there is nothing that will prevent the store from succeeding.


What's wrong with the store?


If it is fine, the better.  I'd still think that
   struct S { constexpr S () : s (0) {}; int s; };
   std::allocator a;
   auto p = a.allocate (1);
   p->s = 1;
   a.deallocate (p, 1);
would still be invalid though, because that type needs constructing and
the construction didn't happen in that case.  Or:
   struct S { constexpr S () : s (0) {}; int s; };
   std::allocator a;
   auto p = a.allocate (1);
   std::construct_at (p);
   p->s++; // ok
   std::destruct_at (p);
   p->s = 1; // shouldn't this be an error?
   a.deallocate (p, 1);
but I admit I haven't tried to back that up by some standard wording, just a
general principle that objects with TYPE_ADDRESSABLE types need to be
constructed first and destructed last and accesses to it are only valid in
between those in normal code and constexpr should flag any UB as errors.


So, are objects in the heap with vacuous initialization ok and objects with
non-trivial constructors not ok without std::construct_at to begin the
lifetime?


Correct.


What about objects with trivial constructor but non-trivial constexpr 
destructor, is
it ok to set them after std::destruct_at or direct p->~S (); invocation
without an intervening std::construct_at?


That would seem to follow.


Also, shouldn't it be invalid if objects with non-trivial destructor are
constructed using std::construct_at but not destructed before deallocate?


It doesn't seem so: "For an object of a class type, the program is not 
required to call the destructor explicitly before the storage which the 
object occupies is reused or released; however, if there is no explicit 
call to the destructor or if a delete-expression is not used to release 
the storage, the destructor is not implicitly called and any program 
that depends on the side effects produced by the destructor has 
undefined behavior."



2019-10-31  Jakub Jelinek  

PR c++/91369 - Implement P0784R7: constexpr new
* cp-tree.h (CALL_FROM_NEW_OR_DELETE_P): Define.
* init.c (build_new_1, build_vec_delete_1, build_delete): Set
CALL_FROM_NEW_OR_DELETE_P on the CALL_EXPR to allocator functions.
* constexpr.c (is_std_allocator_allocate): Only allow
global replaceable allocator functions if CALL_FROM_NEW_OR_DELETE_P
or in std::allocate::{,de}allocate.
(potential_constant_expression_1): Likewise.

* g++.dg/cpp2a/constexpr-new6.C: New test.
* g++.dg/cpp2a/constexpr-new7.C: New test.

--- gcc/cp/cp-tree.h.jj 2019-10-31 08:10:14.515368058 +0100
+++ gcc/cp/cp-tree.h2019-10-31 09:00:45.798418129 +0100
@@ -448,6 +448,7 @@ extern GTY(()) tree cp_global_trees[CPTI
LAMBDA_EXPR_CAPTURE_OPTIMIZED (in LAMBDA_EXPR)
IMPLICIT_CONV_EXPR_BRACED_INIT (in IMPLICIT_CONV_EXPR)
TINFO_VAR_DECLARED_CONSTINIT (in TEMPLATE_INFO)
+  CALL_FROM_NEW_OR_DELETE_P (in CALL_EXPR)
 3: (TREE_REFERENCE_EXPR) (in NON_LVALUE_EXPR) (commented-out).
ICS_BAD_FLAG (in _CONV)
FN_TRY_BLOCK_P (in TRY_BLOCK)
@@ -3791,6 +3792,11 @@ struct GTY(()) lang_decl {
 should be performed at instantiation time.  */
  #define KOENIG_LOOKUP_P(NODE) TREE_LANG_FLAG_0 (CALL_EXPR_CHECK (NODE))
  
+/* In a CALL_EXPR, true for allocator calls from new or delete

+   expressions.  */
+#define CALL_FROM_NEW_OR_DELETE_P(NODE) \
+  TREE_LANG_FLAG_2 (CALL_EXPR_CHECK (NODE))
+
  /* True if the arguments to NODE should be evaluated in left-to-right
 order regardless of PUSH_ARGS_REVERSED.  */
  #define CALL_EXPR_ORDERED_ARGS(NODE) \
--- gcc/cp/init.c.jj2019-10-05 09:36:39.249674512 +0200
+++ gcc/cp/init.c   2019-10-31 09:25:11.870698471 +0100
@@ -3404,6 +3404,10 @@ build_new_1 (vec **placemen
}
  }
  
+  tree alloc_call_expr = extract_call_expr (alloc_call);

Re: [RFC PATCH] targetm.omp.device_kind_arch_isa and OpenMP declare variant kind/arch/isa handling

[Martin Jambor]

Hi,

On Tue, Oct 29 2019, Jakub Jelinek wrote:
> Does this approach look reasonable and is it ok with the backend maintainers
> listed in To:?  Martin listed for HSA, I'm afraid right now not really sure
> at which point it would be possible to distinguish hsa guarded targeted code
> from host targeted one.

Right, since the general approach is to heavily rely on falling back on
the host, I don't think you can do much better than what the patch does.

Thanks,

Martin


> CCed some backend maintainers for thoughts on what
> would be reasonable values for the target hook on their backends.
>
> 2019-10-29  Jakub Jelinek  
>
>   * configure.ac: Compute and substitute omp_device_properties and
>   omp_device_property_deps.
>   * Makefile.in (generated_files): Add omp-device-properties.h.
>   (omp-general.o): Depend on omp-device-properties.h.
>   (omp_device_properties): New make variable.
>   (omp-device-properties.h, s-omp-device-properties-h,
>   install-omp-device-properties): New goals.
>   (install): Depend on install-omp-device-properties for accelerators.
>   * target.def (TARGET_OMP_DEVICE_KIND_ARCH_ISA): New target hook.
>   * target.h (enum omp_device_kind_arch_isa): New enum.
>   * doc/tm.texi.in: Add placeholder for TARGET_OMP_DEVICE_KIND_ARCH_ISA
>   documentation.
>   * omp-general.c: Include omp-device-properties.h.
>   (omp_max_simt_vf): Expect OFFLOAD_TARGET_NAMES to be separated by
>   colon instead of comma.
>   (omp_offload_device_kind_arch_isa, omp_maybe_offloaded): New
>   functions.
>   (omp_context_selector_matches): Implement device set arch/isa
>   selectors, improve device set kind selector handling.
>   * config/i386/i386-options.h (ix86_omp_device_kind_arch_isa): Declare.
>   * config/i386/i386.c (TARGET_SIMD_CLONE_ADJUST,
>   TARGET_SIMD_CLONE_USABLE): Formatting fix.
>   (TARGET_OMP_DEVICE_KIND_ARCH_ISA): Redefine to
>   ix86_omp_device_kind_arch_isa.
>   * config/i386/i386-options.c (struct ix86_target_opts): Move type
>   definition from ix86_target_string to file scope.
>   (isa2_opts, isa_opts): Moved arrays from ix86_target_string function
>   to file scope.
>   (ix86_omp_device_kind_arch_isa): New function.
>   (ix86_target_string): Moved struct ix86_target_opts, isa2_opts and
>   isa_opts definitions to file scope.
>   * config/i386/t-intelmic (omp-device-properties): New goal.
>   * config/nvptx/t-nvptx (omp-device-properties): Likewise.
>   * config/nvptx/nvptx.c (nvptx_omp_device_kind_arch_isa): New function.
>   (TARGET_OMP_DEVICE_KIND_ARCH_ISA): Redefine to
>   nvptx_omp_device_kind_arch_isa.
>   * configure: Regenerate.
>   * doc/tm.texi: Regenerate.
> testsuite/
>   * c-c++-common/gomp/declare-variant-9.c: New test.
>   * c-c++-common/gomp/declare-variant-10.c: New test.
>

Re: [PATCH] Add explicit description for -finline

[Joseph Myers]

On Thu, 31 Oct 2019, Xiong Hu Luo wrote:

> +@code{-finline} enables inlining of function declared \"inline\".
> +@code{-finline} is enabled at levels -O1, -O2, -O3 and -Os, but not -Og.

Use @option{} to mark up option names (both -finline and all the -O 
options in this paragraph).  Use @code{} to mark up keyword names, not 
\"\".

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

Re: [PATCH] Fix the fix for PR fortran/90988

[Steve Kargl]

On Fri, Nov 01, 2019 at 08:49:58AM +0100, Tobias Burnus wrote:
> On 10/31/19 11:16 PM, Steve Kargl wrote:
> 
> > Jeff Law sent me an email … caused a regression for fixed-form
> > source code.
> 
> Interesting, what kind of code is used in the real world!
> 

Jeff sent me the file from dl_poly that ran into thre regression.
The dl_ploy developers use modern Fortran, but at least one file
restrict themselves to fixed-form source code.  This seems to be
an odd choice to me, but it is legal Fortran.

> > OK to commit?
> 
> OK. Thanks for the patch!
> 

Thanks.  And, sorry about the regression.

-- 
Steve

Re: [PR47785] COLLECT_AS_OPTIONS

[H.J. Lu]

On Thu, Oct 31, 2019 at 6:33 PM Kugan Vivekanandarajah
 wrote:
>
> On Wed, 30 Oct 2019 at 03:11, H.J. Lu  wrote:
> >
> > On Sun, Oct 27, 2019 at 6:33 PM Kugan Vivekanandarajah
> >  wrote:
> > >
> > > Hi Richard,
> > >
> > > Thanks for the review.
> > >
> > > On Wed, 23 Oct 2019 at 23:07, Richard Biener  
> > > wrote:
> > > >
> > > > On Mon, Oct 21, 2019 at 10:04 AM Kugan Vivekanandarajah
> > > >  wrote:
> > > > >
> > > > > Hi Richard,
> > > > >
> > > > > Thanks for the pointers.
> > > > >
> > > > >
> > > > >
> > > > > On Fri, 11 Oct 2019 at 22:33, Richard Biener 
> > > > >  wrote:
> > > > > >
> > > > > > On Fri, Oct 11, 2019 at 6:15 AM Kugan Vivekanandarajah
> > > > > >  wrote:
> > > > > > >
> > > > > > > Hi Richard,
> > > > > > > Thanks for the review.
> > > > > > >
> > > > > > > On Wed, 2 Oct 2019 at 20:41, Richard Biener 
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > On Wed, Oct 2, 2019 at 10:39 AM Kugan Vivekanandarajah
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > As mentioned in the PR, attached patch adds 
> > > > > > > > > COLLECT_AS_OPTIONS for
> > > > > > > > > passing assembler options specified with -Wa, to the 
> > > > > > > > > link-time driver.
> > > > > > > > >
> > > > > > > > > The proposed solution only works for uniform -Wa options 
> > > > > > > > > across all
> > > > > > > > > TUs. As mentioned by Richard Biener, supporting non-uniform 
> > > > > > > > > -Wa flags
> > > > > > > > > would require either adjusting partitioning according to 
> > > > > > > > > flags or
> > > > > > > > > emitting multiple object files  from a single LTRANS CU. We 
> > > > > > > > > could
> > > > > > > > > consider this as a follow up.
> > > > > > > > >
> > > > > > > > > Bootstrapped and regression tests on  arm-linux-gcc. Is this 
> > > > > > > > > OK for trunk?
> > > > > > > >
> > > > > > > > While it works for your simple cases it is unlikely to work in 
> > > > > > > > practice since
> > > > > > > > your implementation needs the assembler options be present at 
> > > > > > > > the link
> > > > > > > > command line.  I agree that this might be the way for people to 
> > > > > > > > go when
> > > > > > > > they face the issue but then it needs to be documented somewhere
> > > > > > > > in the manual.
> > > > > > > >
> > > > > > > > That is, with COLLECT_AS_OPTION (why singular?  I'd expected
> > > > > > > > COLLECT_AS_OPTIONS) available to cc1 we could stream this string
> > > > > > > > to lto_options and re-materialize it at link time (and diagnose 
> > > > > > > > mismatches
> > > > > > > > even if we like).
> > > > > > > OK. I will try to implement this. So the idea is if we provide
> > > > > > > -Wa,options as part of the lto compile, this should be available
> > > > > > > during link time. Like in:
> > > > > > >
> > > > > > > arm-linux-gnueabihf-gcc -march=armv7-a -mthumb -O2 -flto
> > > > > > > -Wa,-mimplicit-it=always,-mthumb -c test.c
> > > > > > > arm-linux-gnueabihf-gcc  -flto  test.o
> > > > > > >
> > > > > > > I am not sure where should we stream this. Currently, 
> > > > > > > cl_optimization
> > > > > > > has all the optimization flag provided for compiler and it is
> > > > > > > autogenerated and all the flags are integer values. Do you have 
> > > > > > > any
> > > > > > > preference or example where this should be done.
> > > > > >
> > > > > > In lto_write_options, I'd simply append the contents of 
> > > > > > COLLECT_AS_OPTIONS
> > > > > > (with -Wa, prepended to each of them), then recover them in 
> > > > > > lto-wrapper
> > > > > > for each TU and pass them down to the LTRANS compiles (if they agree
> > > > > > for all TUs, otherwise I'd warn and drop them).
> > > > >
> > > > > Attached patch streams it and also make sure that the options are the
> > > > > same for all the TUs. Maybe it is a bit restrictive.
> > > > >
> > > > > What is the best place to document COLLECT_AS_OPTIONS. We don't seem
> > > > > to document COLLECT_GCC_OPTIONS anywhere ?
> > > >
> > > > Nowhere, it's an implementation detail then.
> > > >
> > > > > Attached patch passes regression and also fixes the original ARM
> > > > > kernel build issue with tumb2.
> > > >
> > > > Did you try this with multiple assembler options?  I see you stream
> > > > them as -Wa,-mfpu=xyz,-mthumb but then compare the whole
> > > > option strings so a mismatch with -Wa,-mthumb,-mfpu=xyz would be
> > > > diagnosed.  If there's a spec induced -Wa option do we get to see
> > > > that as well?  I can imagine -march=xyz enabling a -Wa option
> > > > for example.
> > > >
> > > > + *collect_as = XNEWVEC (char, strlen (args_text) + 1);
> > > > + strcpy (*collect_as, args_text);
> > > >
> > > > there's strdup.  Btw, I'm not sure why you don't simply leave
> > > > the -Wa option in the merged options [individually] and match
> > > > them up but go the route of comparing strings and carrying that
> > > > along separately.  I think that would be much better.
> 

Re: GCC 10.0 Status Report (2019-10-22), Stage 1 to end Nov 16th

[Marek Polacek]

On Fri, Nov 01, 2019 at 09:31:07AM -0600, Jeff Law wrote:
> On 11/1/19 9:08 AM, Marek Polacek wrote:
> > On Fri, Nov 01, 2019 at 04:01:12PM +0100, Romain Geissler wrote:
> >> Le mar. 22 oct. 2019 à 14:53, Richard Biener  a écrit :
> >>>
> >>> Please make sure to get features intended for GCC 10 finished
> >>> and reviewed before the end of stage 1.
> >>>
> >>
> >> Hi,
> >>
> >> I understand my question comes very (most likely too) late, but are
> >> there any plans to switch the default C++ dialect to -std=gnu++17 when
> >> invoking g++ ? C++17 support in gcc is now quite complete, has been
> >> out tested by some users since gcc 8, so shall it be switched on by
> >> default in gcc 10 ? Or gcc 11 ? However I fear doing that may break
> >> some tests in the testsuite, I hope not too many.
> > 
> > I plan to propose a switch to -std=gnu++17 in GCC 11.  I think it's way
> > too late for GCC 10.
> > 
> > Dealing with the testsuite fallout, and rebuilding Fedora packages is
> > of course part of that switch.
> FWIW, we *could* do the rebuild test, we've got time for that.  What's
> far more interesting would be dealing with the fallout ;-)

I most definitely had your tester in mind ;).

> I'd tend to agree though, flip the default as soon as gcc-11 stage1
> opens.  That gives us plenty of time to deal with any fallout.

Sounds like we have a plan.

--
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA

Re: GCC 10.0 Status Report (2019-10-22), Stage 1 to end Nov 16th

[Jeff Law]

On 11/1/19 9:08 AM, Marek Polacek wrote:
> On Fri, Nov 01, 2019 at 04:01:12PM +0100, Romain Geissler wrote:
>> Le mar. 22 oct. 2019 à 14:53, Richard Biener  a écrit :
>>>
>>> Please make sure to get features intended for GCC 10 finished
>>> and reviewed before the end of stage 1.
>>>
>>
>> Hi,
>>
>> I understand my question comes very (most likely too) late, but are
>> there any plans to switch the default C++ dialect to -std=gnu++17 when
>> invoking g++ ? C++17 support in gcc is now quite complete, has been
>> out tested by some users since gcc 8, so shall it be switched on by
>> default in gcc 10 ? Or gcc 11 ? However I fear doing that may break
>> some tests in the testsuite, I hope not too many.
> 
> I plan to propose a switch to -std=gnu++17 in GCC 11.  I think it's way
> too late for GCC 10.
> 
> Dealing with the testsuite fallout, and rebuilding Fedora packages is
> of course part of that switch.
FWIW, we *could* do the rebuild test, we've got time for that.  What's
far more interesting would be dealing with the fallout ;-)

I'd tend to agree though, flip the default as soon as gcc-11 stage1
opens.  That gives us plenty of time to deal with any fallout.

jeff

Re: GCC 10.0 Status Report (2019-10-22), Stage 1 to end Nov 16th

[Marek Polacek]

On Fri, Nov 01, 2019 at 04:01:12PM +0100, Romain Geissler wrote:
> Le mar. 22 oct. 2019 à 14:53, Richard Biener  a écrit :
> >
> > Please make sure to get features intended for GCC 10 finished
> > and reviewed before the end of stage 1.
> >
> 
> Hi,
> 
> I understand my question comes very (most likely too) late, but are
> there any plans to switch the default C++ dialect to -std=gnu++17 when
> invoking g++ ? C++17 support in gcc is now quite complete, has been
> out tested by some users since gcc 8, so shall it be switched on by
> default in gcc 10 ? Or gcc 11 ? However I fear doing that may break
> some tests in the testsuite, I hope not too many.

I plan to propose a switch to -std=gnu++17 in GCC 11.  I think it's way
too late for GCC 10.

Dealing with the testsuite fallout, and rebuilding Fedora packages is
of course part of that switch.

--
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA

[PR 70929] Remove gimple_call_types_likely_match_p... almost

[Martin Jambor]

Hi,

I have spent some more time looking into PR 70929, how
gimple_check_call_matching_types behaves when LTO-building Firefox to
see what could replace it or if we perhaps could remove it.

TL;DR:
I believe it can and should be removed, possibly except the use in
value-prof.c where I replaced it with a clearly imprecise predicate to
catch cases where the profile info is corrupted and since I had it, I
also ended up using it for speculative devirtualization, in case it got
its guess somehow wrong (but I have not seen either of the two cases
happening).  See the patch below.


More details:
With LTO the predicate can always be fooled and so we cannot rely on it
as means to prevent ICEs, if the user calls incompatible functions, the
compiler should try to fix it with folding, VCEing or just using zero
constructors in the most bogus of cases.

And trying to make the predicate more clever can be difficult.  When
LTO-building Firefox (without PGO), gimple_check_call_matching_types
returns false 8133 times and those cases can be divided into:

  - 2507x the callee was __builtin_constant_p
  -   17x the callee was __builtin_signbit
  - 1388x the callee was __builtin_unreachable

  - 4215x would pass the suggested test in comment 5 of the bug.  I
examined quite a few and all were exactly the problem discussed in
this PR - they were all deemed incompatible because one parameter
was a reference to a TREE_ADDRESSABLE class.

  - 6x both predicates returned false for a target found by speculative
devirtualization.  I tend to think they were both wrong because...

...the predicate from comment #5 of the bug is not a good substitute
because it returns false for perfectly fine virtual calls when the type
of the call is a method belonging to an ancestor of the class to which
the actual callee belongs.  Thousands of calls to AddRef did not pass
the test.

Without finding any real case for having the predicate, I decided to
remove its use from everywhere except for check_ic_target because its
comment says:

/* Perform sanity check on the indirect call target. Due to race conditions,
   false function target may be attributed to an indirect call site. If the
   call expression type mismatches with the target function's type, expand_call
   may ICE. Here we only do very minimal sanity check just to make compiler 
happy.
   Returns true if TARGET is considered ok for call CALL_STMT.  */

and if some such race conditions really happen and can be detected if
e.g. the number of parameters is clearly off, the compiler should
probably discard the target.  But I did not want to keep the original
clumsy predicate and therefore decided to extract the non-problematic
bits of useless_type_conversion_p into:

/* Check the type of FNDECL and return true if it is likely compatible with the
   callee type in CALL.  The check is imprecise, the intended use of this
   function is that when optimizations like value profiling and speculative
   devirtualization somehow guess a clearly wrong target of an indirect call,
   they can discard it.  */

bool
gimple_call_types_likely_match_p (gcall *call, tree fndecl)
{
  tree call_type = gimple_call_fntype (call);
  tree decl_type = TREE_TYPE (fndecl);

  /* If one is a function and the other a method, that's a mismatch.  */
  if (TREE_CODE (call_type) != TREE_CODE (decl_type))
return false;
  /* If the return types are not compatible, bail out.  */
  if (!useless_type_conversion_p (TREE_TYPE (call_type),
  TREE_TYPE (decl_type)))
return false;
  /* If the call was to an unprototyped function, all bets are off.  */
  if (!prototype_p (call_type))
return true;

  /* If the unqualified argument types are compatible, the types match.  */
  if (TYPE_ARG_TYPES (call_type) == TYPE_ARG_TYPES (decl_type))
return true;

  tree call_parm, decl_parm;
  for (call_parm = TYPE_ARG_TYPES (call_type),
 decl_parm = TYPE_ARG_TYPES (decl_type);
   call_parm && decl_parm;
   call_parm = TREE_CHAIN (call_parm),
 decl_parm = TREE_CHAIN (decl_parm))
if (!useless_type_conversion_p
(TYPE_MAIN_VARIANT (TREE_VALUE (call_parm)),
 TYPE_MAIN_VARIANT (TREE_VALUE (decl_parm
  return false;

  /* If there is a mismatch in the number of arguments the functions
 are not compatible.  */
  if (call_parm || decl_parm)
return false;

  return true;
}

Crucially, the function is missing the part that does:

  /* Method types should belong to a compatible base class.  */
  if (TREE_CODE (inner_type) == METHOD_TYPE
  && !useless_type_conversion_p (TYPE_METHOD_BASETYPE (outer_type),
 TYPE_METHOD_BASETYPE (inner_type)))
return false;

Of course, it would be nice if useless_type_conversion_p could detect
ancestors but that does not seem to be easy and doing it IMHO should not
hold us back from fixing this PR now.

I have also naturally tried to use this 

Re: GCC 10.0 Status Report (2019-10-22), Stage 1 to end Nov 16th

[Romain Geissler]

Le mar. 22 oct. 2019 à 14:53, Richard Biener  a écrit :
>
> Please make sure to get features intended for GCC 10 finished
> and reviewed before the end of stage 1.
>

Hi,

I understand my question comes very (most likely too) late, but are
there any plans to switch the default C++ dialect to -std=gnu++17 when
invoking g++ ? C++17 support in gcc is now quite complete, has been
out tested by some users since gcc 8, so shall it be switched on by
default in gcc 10 ? Or gcc 11 ? However I fear doing that may break
some tests in the testsuite, I hope not too many.

Cheers,
Romain

Re: [C++ Patch] Add location parameter to composite_pointer_type and use it

[Paolo Carlini]

Hi again,

On 31/10/19 16:56, Paolo Carlini wrote:

Hi,

yesterday I noticed that we want to forward the location parameter of 
cp_build_binary_op to composite_pointer_type and then 
composite_pointer_error. Note, for the time being at least, this is 
always for CPO_COMPARISON, the other two composite_pointer_operation 
cases aren't involved - and the various functions (eg, 
common_pointer_type) forward input_location - but I'm consistently 
changing all the pedwarn, emit_diagnostic, and error_at anyway to use 
the location.


In fact, build_conditional_expr_1, which passes CPO_CONDITIONAL_EXPR, 
has available a suitable location, thus we can extend my previous patch 
and forward that too instead of input_location. Tested as usual 
x86_64-linux.


Thanks, Paolo.

/

/cp
2019-11-01  Paolo Carlini  

* typeck.c (composite_pointer_type): Add a const op_location_t&
parameter and use it in diagnostics.
(composite_pointer_error): Likewise.
(composite_pointer_type_r): Add a const op_location_t&
parameter and forward it.
(cp_build_binary_op): Adjust calls.
(common_pointer_type): Likewise.
* call.c (add_builtin_candidate): Likewise.
(build_conditional_expr_1): Likewise.
* cp-tree.h (composite_pointer_type): Update declaration.

* typeck.c (cxx_sizeof_expr): Use cp_expr_loc_or_input_loc
in permerror.
(cxx_alignof_expr): Likewise.
(lvalue_or_else): Likewise.

/testsuite
2019-11-01  Paolo Carlini  

* g++.dg/conversion/ptrmem9.C: Check location.
* g++.dg/expr/cond2.C: Likewise.
* g++.dg/warn/Waddress-1.C: Check locations.
* g++.old-deja/g++.bugs/900324_02.C: Check location.
* g++.old-deja/g++.jason/rfg20.C: Likewise.
* g++.old-deja/g++.law/typeck1.C: Likewise.
* g++.old-deja/g++.rfg/00321_01-.C: Likewise.
* g++.old-deja/g++.rfg/00324_02-.C: Likewise.

* g++.dg/diagnostic/alignof1.C: New.
* g++.dg/expr/sizeof1.C: Check location.
* g++.dg/cpp0x/rv-lvalue-req.C: Check locations.
Index: cp/call.c
===
--- cp/call.c   (revision 277705)
+++ cp/call.c   (working copy)
@@ -3029,7 +3029,8 @@ add_builtin_candidate (struct z_candidate **candid
 {
   if (TYPE_PTR_OR_PTRMEM_P (type1))
{
- tree cptype = composite_pointer_type (type1, type2,
+ tree cptype = composite_pointer_type (input_location,
+   type1, type2,
error_mark_node,
error_mark_node,
CPO_CONVERSION,
@@ -5553,7 +5554,8 @@ build_conditional_expr_1 (const op_location_t 
   || (TYPE_PTRDATAMEM_P (arg2_type) && TYPE_PTRDATAMEM_P (arg3_type))
   || (TYPE_PTRMEMFUNC_P (arg2_type) && TYPE_PTRMEMFUNC_P (arg3_type)))
 {
-  result_type = composite_pointer_type (arg2_type, arg3_type, arg2,
+  result_type = composite_pointer_type (loc,
+   arg2_type, arg3_type, arg2,
arg3, CPO_CONDITIONAL_EXPR,
complain);
   if (result_type == error_mark_node)
Index: cp/cp-tree.h
===
--- cp/cp-tree.h(revision 277705)
+++ cp/cp-tree.h(working copy)
@@ -7509,7 +7509,8 @@ extern tree build_ptrmemfunc1 (tree, 
tree, tree)
 extern void expand_ptrmemfunc_cst  (tree, tree *, tree *);
 extern tree type_after_usual_arithmetic_conversions (tree, tree);
 extern tree common_pointer_type (tree, tree);
-extern tree composite_pointer_type (tree, tree, tree, tree,
+extern tree composite_pointer_type (const op_location_t &,
+tree, tree, tree, tree,
 composite_pointer_operation,
 tsubst_flags_t);
 extern tree merge_types(tree, tree);
Index: cp/typeck.c
===
--- cp/typeck.c (revision 277705)
+++ cp/typeck.c (working copy)
@@ -450,25 +450,26 @@ type_after_usual_arithmetic_conversions (tree t1,
 }
 
 static void
-composite_pointer_error (diagnostic_t kind, tree t1, tree t2,
+composite_pointer_error (const op_location_t ,
+diagnostic_t kind, tree t1, tree t2,
 composite_pointer_operation operation)
 {
   switch (operation)
 {
 case CPO_COMPARISON:
-  emit_diagnostic (kind, input_location, 0,
+  emit_diagnostic (kind, location, 0,
   "comparison between "
   "distinct pointer types 

[PATCH][Aarch64] Fix vec_perm cost for thunderx2t99

[Anton Youdkevitch]

Hello,

Here is the one-liner that fixes the incorrect
vec_perm cost for thunderx2t99 chip.
With the patch applied 526.blender of CPU2017
gets ~5% improvement with no measurable changes
for other benchmarks.

Bootstrapped OK on aarch64-linux-gnu.

OK for trunk?

2019-11-01 Anton Youdkevitch 

* gcc/config/aarch64/aarch64.c (thunderx2t99_vector_cost):
change vec_perm field

-- 
  Thanks,
  Anton
>From 42eab5c85a39a5c5ed7be00245f13f73c3f6b946 Mon Sep 17 00:00:00 2001
From: Anton Youdkevitch 
Date: Wed, 30 Oct 2019 14:42:41 +
Subject: [PATCH] [Aarch64] Fix vec_perm cost for thunderx2t99

The vec_perm cost for thunderx2t99 was set to 3
which was too low and resulted in non-beneficial
permutations neing generated.
Changed it to 10 (2-register form tbl cost) to more
accurately represent the timings wrt the actual
TX2 hardware.
---
 gcc/config/aarch64/aarch64.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 599d07a..f28fe80 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -585,7 +585,7 @@ static const struct cpu_vector_cost thunderx2t99_vector_cost =
   1, /* scalar_store_cost  */
   5, /* vec_int_stmt_cost  */
   6, /* vec_fp_stmt_cost  */
-  3, /* vec_permute_cost  */
+  10, /* vec_permute_cost  */
   6, /* vec_to_scalar_cost  */
   5, /* scalar_to_vec_cost  */
   8, /* vec_align_load_cost  */
-- 
2.7.4

[C++ PATCH] cleanup check_field_decls

[Nathan Sidwell]

In implementing C++20 using enum changes, I wandered into 
check_field_decls, and was confused.


This patch makes it better than it was.
*) the main loop showed signs that we used to remove bad fields.  but we 
don't any more.
*) ... so we can call the field 'field', not 'x'.  (still not perfect, 
but hey, it comes from TYPE_FIELDS.)
*) The 'clever' use of 'continue' to get to the next iteration is now in 
only one place.  Less churn than indenting the entirety of the 
FIELD_DECL case
*) We now note the first default-init and pointer-type field, when 
issuing diagnostics -- better than 'hey, somewhere in here is a field 
with these bad properties'.
*) While grokdeclarator doesn't appear to emit FIELD_DECLS of function 
or method type, we can still get there via template instantiation. 
Added a test case for that, but didn't move the check into pt.c, which 
may be a better place.


committing to trunk.

nathan
--
Nathan Sidwell
2019-11-01  Nathan Sidwell  

	cp/
	* class.c (check_field_decls): Refactor.

	testsuite/
	* g++.dg/template/fn.C: New.

Index: gcc/cp/class.c
===
--- gcc/cp/class.c	(revision 277705)
+++ gcc/cp/class.c	(working copy)
@@ -3449,8 +3449,5 @@ check_field_decl (tree field,
 
All of these flags should be initialized before calling this
-   function.
-
-   Returns a pointer to the end of the TYPE_FIELDs chain; additional
-   fields can be added by adding to this chain.  */
+   function.   */
 
 static void
@@ -3459,102 +3456,99 @@ check_field_decls (tree t, tree *access_
 		   int *no_const_asn_ref_p)
 {
-  tree *field;
-  tree *next;
   int cant_pack = 0;
-  int field_access = -1;
 
   /* Assume there are no access declarations.  */
   *access_decls = NULL_TREE;
-  /* Assume this class has no pointer members.  */
-  bool has_pointers = false;
-  /* Assume none of the members of this class have default
- initializations.  */
-  bool any_default_members = false;
-  /* Assume none of the non-static data members are of non-volatile literal
- type.  */
+  /* Effective C has things to say about classes with pointer members.  */
+  tree pointer_member = NULL_TREE;
+  /* Default initialized members affect the whole class.  */
+  tree default_init_member = NULL_TREE;
+  /* Lack of any non-static data member of non-volatile literal
+ type affects a union.  */
   bool found_nv_literal_p = false;
+  /* Standard layout requires all FIELDS have same access.  */
+  int field_access = -1;
 
-  for (field = _FIELDS (t); *field; field = next)
+  for (tree field = TYPE_FIELDS (t); field; field = DECL_CHAIN (field))
 {
-  tree x = *field;
-  tree type = TREE_TYPE (x);
-  int this_field_access;
+  tree type = TREE_TYPE (field);
 
-  next = _CHAIN (x);
-
-  if (TREE_CODE (x) == USING_DECL)
+  switch (TREE_CODE (field))
 	{
-	  /* Save the access declarations for our caller.  */
-	  *access_decls = tree_cons (NULL_TREE, x, *access_decls);
-	  continue;
-	}
-
-  if (TREE_CODE (x) == TYPE_DECL
-	  || TREE_CODE (x) == TEMPLATE_DECL)
-	continue;
-
-  if (TREE_CODE (x) == FUNCTION_DECL)
-	/* FIXME: We should fold in the checking from check_methods.  */
-	continue;
+	default:
+	  gcc_unreachable ();
 
-  /* If we've gotten this far, it's a data member, possibly static,
-	 or an enumerator.  */
-  if (TREE_CODE (x) != CONST_DECL)
-	DECL_CONTEXT (x) = t;
+	case USING_DECL:
+	  /* Save the access declarations for our caller.  */
+	  *access_decls = tree_cons (NULL_TREE, field, *access_decls);
+	  break;
 
-  /* When this goes into scope, it will be a non-local reference.  */
-  DECL_NONLOCAL (x) = 1;
+	case TYPE_DECL:
+	case TEMPLATE_DECL:
+	  break;
+
+	case FUNCTION_DECL:
+	  /* FIXME: We should fold in the checking from check_methods.  */
+	  break;
+
+	case CONST_DECL:
+	  DECL_NONLOCAL (field) = 1;
+	  break;
+	  
+	case VAR_DECL:
+	  if (TREE_CODE (t) == UNION_TYPE
+	  && cxx_dialect < cxx11)
+	{
+	  /* [class.union]
 
-  if (TREE_CODE (t) == UNION_TYPE)
-	{
-	  /* [class.union] (C++98)
+		 (C++98) If a union contains a static data member,
+		 ... the program is ill-formed.  */
+	  if (cxx_dialect < cxx11)
+		error ("in C++98 %q+D may not be static because it is "
+		   "a member of a union", field);
+	}
+	  goto data_member;
+	  
+	case FIELD_DECL:
+	  if (TREE_CODE (t) == UNION_TYPE)
+	{
+	  /* [class.union]
 
-	 If a union contains a static data member, or a member of
-	 reference type, the program is ill-formed.
+		 If a union contains ... or a [non-static data] member
+		 of reference type, the program is ill-formed.  */
+	  if (TYPE_REF_P (type))
+		error ("non-static data member %q+D in a union may not "
+		   "have reference type %qT", field, type);
+	}
 
-	 In C++11 [class.union] says:
-	 If a union contains a non-static data member of reference type
-	 the program is ill-formed.  */
-	  if (VAR_P (x) 

Re: [PATCH] Fix the fix for PR fortran/90988

[Jeff Law]

On 11/1/19 1:49 AM, Tobias Burnus wrote:
> On 10/31/19 11:16 PM, Steve Kargl wrote:
> 
>> Jeff Law sent me an email … caused a regression for fixed-form
>> source code.
> 
> Interesting, what kind of code is used in the real world!
It's from the dl_poly package in Fedora IIRC.  It was the only instance
of this problem across the Fedora builds.
jeff

Re: [committed][AArch64] Add support for the SVE PCS

[Andreas Schwab]

On Okt 31 2019, Richard Sandiford wrote:

> The SVE PCS support broke go, D and Ada because those languages don't
> call TARGET_INIT_BUILTINS.  We therefore ended up trying to get the
> TYPE_MAIN_VARIANT of a null __SVBool_t.
>
> We shouldn't really need to apply TYPE_MAIN_VARIANT there anyway,
> since the ABI-defined types are (and need to be) their own main
> variants.  This patch asserts for that instead.

That doesn't fix the D frontend.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

[PATCH][MSP430] Read MCU data from external file specified with environment variable or installed into toolchain subdirectory

[Jozef Lawrynowicz]

Each different MSP430 MCU has two properties that affect code generation, which
are the the CPU ISA and the hardware multiply support. These can be manually
specified with the -mcpu= and -mhwmult= options, respectively.
The existing -mmcu= option takes an MCU name as an argument and uses the CPU
ISA and hardware multiply known to be supported for that MCU, so the user does
not have to provide the -mcpu and -mhwmult options.

Currently, the MCU data can be provided in an external "devices.csv" file, and
this file is already searched for on the paths specified with -I and -L.

This patch extends the searching behaviour so the path to the directory
containing devices.csv can either be specified with the "MSP430_GCC_INCLUDE_DIR"
environment variable, or installed into the msp430-elf/include/devices
subdirectory of the toolchain.
The msp430.exp toolchain driver has been extended to ensure these new methods
can be tested properly.

Successfully regtested on trunk.

Ok to apply?
>From f781013148c2fd242af8526dbcfa2079fe30db07 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz 
Date: Wed, 30 Oct 2019 21:10:38 +
Subject: [PATCH] MSP430: Read MCU data from external file specified with
 environment variable or installed into toolchain subdirectory

gcc/ChangeLog:

2019-10-31  Jozef Lawrynowicz  

	* config/msp430/driver-msp430.c (msp430_get_linker_devices_include_path):
	New spec function.
	* config/msp430/msp430-devices.c (msp430_dirname): New function.
	(extract_devices_dir_from_exec_prefix): New function.
	(extract_devices_dir_from_collect_gcc): New function.
	(msp430_check_env_var_for_devices): New function.
	(msp430_check_path_for_devices): Use xstrdup instead of ASTRDUP.
	(parse_devices_csv): Call msp430_check_env_var_for_devices if
	devices.csv was not found using other methods.
	* config/msp430/msp430-devices.h (msp430_check_env_var_for_devices):
	New prototype.
	(msp430_dirname): Likewise.
	* config/msp430/msp430.c (msp430_register_pre_includes): New function.
	* config/msp430/msp430.h (EXTRA_SPEC_FUNCTIONS): Add
	msp430_get_linker_devices_include_path.
	(TARGET_EXTRA_PRE_INCLUDES): Define.
	* doc/invoke.texi: Document new ways of searching for support files.

gcc/testsuite/ChangeLog:

2019-10-31  Jozef Lawrynowicz  

	* gcc.target/msp430/devices/csv-using-env-var.c: New test.
	* gcc.target/msp430/devices/csv-using-installed.c: New test.
	* gcc.target/msp430/devices/csv-using-option.c: New test.
	* gcc.target/msp430/devices/devices-main.c: New test source file.
	* gcc.target/msp430/devices/msp430-devices.h: New test.
	* gcc.target/msp430/msp430.exp (msp430_device_permutations_runtest):
	Add special cases for csv-using* tests.
	Define TESTING_HARD_DATA when running tests that use hard-coded device
	data.
	(get_installed_device_data_path): New.
	(msp430_hide_installed_devices_data): New.
	(msp430_restore_installed_devices_data): New.
	(msp430_test_installed_device_data): New.
	(msp430_install_device_data): New.
---
 gcc/config/msp430/driver-msp430.c |  13 ++
 gcc/config/msp430/msp430-devices.c| 133 +-
 gcc/config/msp430/msp430-devices.h|   2 +
 gcc/config/msp430/msp430.c|  23 +++
 gcc/config/msp430/msp430.h|  12 +-
 gcc/doc/invoke.texi   |  29 +++-
 .../msp430/devices/csv-using-env-var.c|  10 ++
 .../msp430/devices/csv-using-installed.c  |   9 ++
 .../msp430/devices/csv-using-option.c |   9 ++
 .../gcc.target/msp430/devices/devices-main.c  |   4 +
 .../msp430/devices/msp430-devices.h   |   3 +
 gcc/testsuite/gcc.target/msp430/msp430.exp|  94 -
 12 files changed, 332 insertions(+), 9 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/csv-using-env-var.c
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/csv-using-installed.c
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/csv-using-option.c
 create mode 100644 gcc/testsuite/gcc.target/msp430/devices/msp430-devices.h

diff --git a/gcc/config/msp430/driver-msp430.c b/gcc/config/msp430/driver-msp430.c
index c37b169ff8b..fbe7c44ea37 100644
--- a/gcc/config/msp430/driver-msp430.c
+++ b/gcc/config/msp430/driver-msp430.c
@@ -150,6 +150,19 @@ msp430_select_hwmult_lib (int argc ATTRIBUTE_UNUSED,
   return "-lmul_none";
 }
 
+/* Spec function.  Used to place the path to the MSP430-GCC support files
+   on the command line, prefixed with "-L", so the linker finds the linker
+   scripts in that directory.  */
+const char *
+msp430_get_linker_devices_include_path (int argc ATTRIBUTE_UNUSED,
+	const char **argv ATTRIBUTE_UNUSED)
+{
+  char *devices_csv_path;
+  if (msp430_check_env_var_for_devices (_csv_path))
+return NULL;
+  return concat ("-L", msp430_dirname (devices_csv_path), NULL);
+}
+
 /* Spec function.  Propagate -m{code,data}-region= to the linker, unless the
lower region has been specified without -muse-lower-region-prefix also being
used.  */

Re: [PATCH 2/2][MIPS][RFC] Emit .note.GNU-stack for hard-float linux targets.

[Dragan Mladjenovic]

On 10.08.2019. 00:15, Joseph Myers wrote:
> On Fri, 9 Aug 2019, Jeff Law wrote:
>
>>> 2019-08-05  Dragan Mladjenovic  
>>>
>>> * config.in: Regenerated.
>>> * config/mips/linux.h (NEED_INDICATE_EXEC_STACK): Define to 1
>>> for TARGET_LIBC_GNUSTACK.
>>> * configure: Regenerated.
>>> * configure.ac: Define TARGET_LIBC_GNUSTACK if glibc version is
>>> found 2.31 or greater.
>> My only concern here is the configure bits.  So for example, will it do
>> the right thing if you're cross-compiling to a MIPS linux target?  If
>> so, how?  If not, do we need to make it a first class configure option
>> so that it can be specified when building cross MIPS linux toolchains?
>
> The key point of using GCC_GLIBC_VERSION_GTE_IFELSE is that (a) it checks
> the target glibc headers if available when GCC is built and (b) if not
> available, you can still use --with-glibc-version when configuring GCC, to
> get the right configuration in a bootstrap compiler built before glibc is
> built (the latter is necessary on some architectures to get the right
> stack-protector configuration for bootstrapping glibc, but may be useful
> in other cases as well).
>
> My main concern about this patch is the one I gave in
>  about what
> the configuration mechanism should be, on a whole-toolchain level, to say
> whether you are OK with a requirement for a 4.8 or later kernel.
>

Sorry for the late reply.

I was waiting to backport [1] to most of the glibc release branches in 
use, but I got sidetracked along the way.

After this patch lands the preferred way to configure gcc would be using 
--with-glibc-version=2.31 and to use said glibc.
If the user/distribution can live with minimal kernel requirement of 4.8
the glibc used should be configured with --enable-kernel=4.8.
I also plan to backport the [1] to limit the opportunity for building 
the possibly broken glibc with the gcc w/ enabled .note.GNU-stack.

This is all tedious and user has to be aware of all of it to make it 
work, but hopefully over time the distributions will default to 
--with-glibc-version=2.31 and --enable-kernel=4.8. I guess providing the 
detailed NEWS entry for this change would help a bit.

Is there any objections to getting this on the trunk before the end of
stage1?

[1] https://sourceware.org/ml/libc-alpha/2019-08/msg00639.html

Best regards,
Dragan

Re: [Patch,committed] Ensure that gfortran.dg/achar_2.f90 can fail

[Janne Blomqvist]

On Thu, Oct 31, 2019 at 10:04 PM Steve Kargl
 wrote:
>
> On Thu, Oct 31, 2019 at 09:30:26PM +0200, Janne Blomqvist wrote:
> >
> > I'd personally prefer the current behavior. I.e. just let the
> > underlying OS/libc handle it as it sees fit. No need to invent our own
> > semantics here. Tobias quoted the relevant part of the standard, which
> > the current implementation fulfills just fine.
> >
>
> I'm fine with that.  I suppose someone should
> document how gfortran communicates an exit
> status to an invoking shell handle; especially
> when the stop codes exceeds 255.

In principle yes, but how to do it without bogging down into minutiae
of how different targets allow retrieving the process exit status?

For POSIX, we can say that the 8 lowest order bits are used.  Except
if using the POSIX 2008 waitid() function which allows the parent
process to retrieve the full 32 bits. And Windows apparently use
32-bit unsigned integers. And then all the weird targets that a
handful of people around the world for some reason care about, etc.

More info at wikipedia: https://en.wikipedia.org/wiki/Exit_status

Perhaps some note that positive integers in the range [0,255] are
somewhat portable?

-- 
Janne Blomqvist

Re: [PATCH][vect] Clean up orig_loop_vinfo from vect_analyze_loop

[Richard Sandiford]

"Andre Vieira (lists)"  writes:
> Hi,
>
> After my patch I believe the only way orig_loop_vinfo is not null when 
> calling vect_analyze_loop is when it is called for an epilogue and in 
> that case we no longer use that variable, since 
> LOOP_VINFO_ORIG_LOOP_INFO is already set for the epilogue's 
> loop_vec_info.  This patch removes that parameter.
>
> Bootstrapped on x86_64 and aarch64.
>
> Is this OK for trunk?
>
> Cheers,
> Andre
>
> gcc/ChangeLog:
> 2019-10-31  Andre Vieira  
>
>  * tree-vect-loop.c (vect_analyze_loop): Remove orig_loop_vinfo
>  parameter.
>  * tree-vectorizer.h (vect_analyze_loop): Update declaration.
>  * tree-vectorizer.c (try_vectorize_loop_1): Update calls to 
> vect_analyze_loop.

OK with...

> diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
> index 
> 9b7d2485b7cae81578c6a7d33304dc48134cc850..f3deada90cb30c3d5a69a8ca243b0b7687d356cc
>  100644
> --- a/gcc/tree-vect-loop.c
> +++ b/gcc/tree-vect-loop.c
> @@ -2352,8 +2352,7 @@ again:
> loop_vec_info struct.  If ORIG_LOOP_VINFO is not NULL epilogue must
> be vectorized.  */
>  opt_loop_vec_info
> -vect_analyze_loop (class loop *loop, loop_vec_info orig_loop_vinfo,
> -vec_info_shared *shared)
> +vect_analyze_loop (class loop *loop, vec_info_shared *shared)
>  {
>auto_vector_sizes vector_sizes;

...removing the "If ORIG_LOOP_VINFO is not NULL ..." comment too.

Thanks,
Richard

Re: [SLP] SLP vectorization: vectorize vector constructors

[Joel Hutton]

On 30/10/2019 13:49, Richard Biener wrote:
 >>
 >>  * expr.c (store_constructor): Add case for constructor of 
vectors.
 > Why do you need this?  The vectorizer already creates such CTORs.  Any
 > testcase that you can show?
 >
 > typedef long v2di __attribute__((vector_size(16)));
 > v2di v;
 > void
 > foo()
 > {
 >    v = (v2di){v[1], v[0]};
 > }
There is a special case for single element vectors, where the vector 
mode and
the element mode are the same.
I've changed this slightly, as your solution of using VECTOR_MODE_P didn't
work for my case where:
   emode = E_DImode
   eltmode = E_DImode
On aarch64. As E_DImode is not a vector mode.
Based on some checks I found in verify_gimple, I set the type of the 
replacement
constructor to the same as the original constructor, as verify_gimple 
seems to
expect flattened types. i.e. a vector of vectors of ints should have 
type vector
of ints.


 > What could be done is "compact" the
 > operands to vectorize to only contain SSA names, try to SLP
 > match and vectorize them and then combine the vectorized result
 > with the constant elements.
 >
 > Not worth doing I guess unless it's sth regular like
 >
 >  { a, b, c, d, 0, 0, 0, 0 }
 >
 > or so.  But this can be handled as followup if necessary.
 >
I agree, it should be possible to support this in future patches.


 > + SLP_INSTANCE_ROOT_STMT (new_instance) = constructor ?
 > stmt_info->stmt\
 > + : NULL;
 >
 > SLP_INSTANCE_ROOT_STMT should be a stmt_vec_info I guess...
 >
 > @@ -2801,6 +2830,10 @@ vect_bb_slp_scalar_cost (basic_block bb,
 > stmt_vec_info use_stmt_info = vinfo->lookup_stmt
 > (use_stmt);
 > if (!use_stmt_info || !PURE_SLP_STMT (use_stmt_info))
 >   {
 > +   /* Check this is not a constructor that will be
 > vectorized
 > +  away.  */
 > +   if (BB_VINFO_GROUPED_STORES (vinfo).contains
 > (use_stmt_info))
 > +   continue;
 > (*life)[i] = true;
 >
 > ... which you then simply mark as PURE_SLP_STMT where we call
 > vect_mark_slp_stmts in vect_slp_analyze_bb_1.
Done.


 > I see you have the TYPE_VECTOR_SUBPARTS check still at transform
 > stage in vectorize_slp_instance_root_stmt, please simply move
 > it to vect_slp_check_for_constructors or to vect_analyze_slp_instance
 > where you have the other rejects (non-SSA names in the ctor).
 >
Done.


 >
 > +bool
 > +vectorize_slp_instance_root_stmt (slp_tree node, slp_instance instance)
 > +{
 > +
 >
 > extra newline
Fixed.


 > +  /* For vector constructors, the constructor stmt that the SLP tree is
 > built
 > + from, NULL otherwise.  */
 > +  gimple *root_stmt;
 >
 > as said, make this a stmt_vec_info
Done.


 > +  if (SLP_TREE_NUMBER_OF_VEC_STMTS (node) == 1)
 >
 > the stmt replacing can be commonized between == 1 and > 1 cases.
Done.


 > +
 > +  /* Vectorize the instance root.  */
 > +  if (instance->root == node && SLP_INSTANCE_ROOT_STMT (instance)
 > + && SLP_TREE_VEC_STMTS (node).exists ())
 > +   if (!vectorize_slp_instance_root_stmt (node, instance))
 > + {
 >
 > instance->root == node is always true.  Likewise
 > SLP_TREE_VEC_STMTS (node).exists ().
Done.


 > @@ -4061,15 +4201,42 @@ vect_schedule_slp (vec_info *vinfo)
 >    if (is_a  (vinfo))
 >
 > the ChangeLog doesn't mention this.  I guess this isn't necessary
 > unless you fail vectorizing late which you shouldn't.
 >
It's necessary to avoid:

     removing stmts twice for constructors of the form {_1,_1,_1,_1}
     removing stmts that define ssa names used elsewhere (which 
previously wasn't a consideration because the scalar_stmts were stores 
to memory, not assignments to ssa names)

Updated changelog (and patch)

2019-10-31  Joel Hutton  

     * expr.c (store_constructor): Modify to handle single element 
vectors.
     * tree-vect-slp.c (vect_analyze_slp_instance): Add case for 
vector constructors.
     (vect_slp_check_for_constructors): New function.
     (vect_slp_analyze_bb_1): Call new function to check for vector 
constructors.
     (vectorize_slp_instance_root_stmt): New function.
     (vect_schedule_slp): Call new function to vectorize root stmt 
of vector constructors.
     * tree-vectorizer.h (SLP_INSTANCE_ROOT_STMT): New field.

gcc/testsuite/ChangeLog:

2019-10-31  Joel Hutton  

     * gcc.dg/vect/bb-slp-40.c: New test.
     * gcc.dg/vect/bb-slp-41.c: New test.

From 35942aebea1e93497280e11a17af0ca393539e2f Mon Sep 17 00:00:00 2001
From: Joel Hutton 
Date: Tue, 22 Oct 2019 10:05:19 +0100
Subject: [PATCH] SLP Vectorization: Vectorize vector constructors

---
 gcc/expr.c|   5 +-
 gcc/testsuite/gcc.dg/vect/bb-slp-40.c |  34 ++
 gcc/testsuite/gcc.dg/vect/bb-slp-41.c |  61 +++
 gcc/tree-vect-slp.c   | 151 +-
 

Re: [PATCH] Fix the fix for PR fortran/90988

[Tobias Burnus]

On 10/31/19 11:16 PM, Steve Kargl wrote:


Jeff Law sent me an email … caused a regression for fixed-form
source code.


Interesting, what kind of code is used in the real world!


OK to commit?


OK. Thanks for the patch!

Tobias


2019-10-31  Steven G. Kargl  

PR fortran/90988
* decl.c (gfc_match_private, gfc_match_public): Fixed-form source code
does not require whitespace between PRIVATE (or PUBLIC) and an entity.

2019-10-31  Steven G. Kargl  

PR fortran/90988
* gfortran.dg/pr90988_4.f: New test.