[Bug tree-optimization/91909] [10 regression] gcc.dg/vect/vect-cond-4.c fails on armeb after r275898

[clyon at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91909

--- Comment #5 from Christophe Lyon  ---
I confirm that the proposed patch fixed the problem for me.

[Bug libquadmath/91924] New: tgammal(- odd.5 ) has wrong sign

[tydeman at tybor dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91924

Bug ID: 91924
   Summary: tgammal(- odd.5 ) has wrong sign
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libquadmath
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tydeman at tybor dot com
  Target Milestone: ---

tgammal() of negative odd non-integers, e.g., -33.5, -37.5, -67.5, -69.5, ...
has the wrong sign.  It should be positive.

[Bug c++/91923] [9/10 Regression] Failure-to-SFINAE with class type NTTP in C++17

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91923

--- Comment #2 from Marek Polacek  ---
This patch implements that suggestion:

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index e5d64989b32..bd8b2400b86 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -25233,7 +25233,7 @@ invalid_nontype_parm_type_p (tree type, tsubst_flags_t
complain)
 return false;
   else if (CLASS_TYPE_P (type))
 {
-  if (cxx_dialect < cxx2a)
+  if (cxx_dialect < cxx2a && (complain & tf_error))
{
  error ("non-type template parameters of class type only available "
 "with %<-std=c++2a%> or %<-std=gnu++2a%>");

[Bug c++/91923] [9/10 Regression] Failure-to-SFINAE with class type NTTP in C++17

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91923

Marek Polacek  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-27
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with r265789.

[PATCH, rs6000] Support float from/to long conversion vectorization

[Kewen.Lin]

Hi,

This patch is to add the support for float from/to long conversion
vectorization.  ISA 2.06 supports the vector version instructions
for conversion between float and long long (both signed and unsigned),
but vectorizer can't exploit them since the optab check fails.
So this patch is mainly to add related optab supports.

I've verified the functionality on both LE and BE.  Bootstrapped and
regress tested on powerpc64le-linux-gnu.


Thanks,
Kewen

--- 
gcc/ChangeLog

2019-09-27  Kewen Lin  

* config/rs6000/vsx.md (vec_pack[su]_float_v2di): New define_expand.
(vec_unpack_[su]fix_trunc_hi_v4sf): Likewise.
(vec_unpack_[su]fix_trunc_lo_v4sf): Likewise.

gcc/testsuite/ChangeLog

2019-09-27  Kewen Lin  

* gcc.target/powerpc/conv-vectorize-1.c: New test.
* gcc.target/powerpc/conv-vectorize-2.c: New test.
diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
index 7633171..ef32971 100644
--- a/gcc/config/rs6000/vsx.md
+++ b/gcc/config/rs6000/vsx.md
@@ -5538,3 +5538,42 @@
   operands[SFBOOL_TMP_VSX_DI] = gen_rtx_REG (DImode, regno_tmp_vsx);
   operands[SFBOOL_MTVSR_D_V4SF] = gen_rtx_REG (V4SFmode, regno_mtvsr_d);
 })
+
+;; Support signed/unsigned long long to float conversion vectorization.
+(define_expand "vec_pack_float_v2di"
+  [(match_operand:V4SF 0 "vfloat_operand")
+   (any_float:V4SF (parallel [(match_operand:V2DI 1 "vint_operand")
+ (match_operand:V2DI 2 "vint_operand")]))]
+  "TARGET_VSX"
+{
+  rtx r1 = gen_reg_rtx (V4SFmode);
+  rtx r2 = gen_reg_rtx (V4SFmode);
+  emit_insn (gen_vsx_xvcvxdsp (r1, operands[1]));
+  emit_insn (gen_vsx_xvcvxdsp (r2, operands[2]));
+  rs6000_expand_extract_even (operands[0], r1, r2);
+  DONE;
+})
+
+;; Support float to signed/unsigned long long conversion vectorization.
+(define_expand "vec_unpack_fix_trunc_hi_v4sf"
+  [(match_operand:V2DI 0 "vint_operand")
+   (any_fix:V2DI (match_operand:V4SF 1 "vfloat_operand"))]
+  "TARGET_VSX"
+{
+  rtx reg = gen_reg_rtx (V4SFmode);
+  rs6000_expand_interleave (reg, operands[1], operands[1], BYTES_BIG_ENDIAN);
+  emit_insn (gen_vsx_xvcvspxds (operands[0], reg));
+  DONE;
+})
+
+(define_expand "vec_unpack_fix_trunc_lo_v4sf"
+  [(match_operand:V2DI 0 "vint_operand")
+   (any_fix:V2DI (match_operand:V4SF 1 "vfloat_operand"))]
+  "TARGET_VSX"
+{
+  rtx reg = gen_reg_rtx (V4SFmode);
+  rs6000_expand_interleave (reg, operands[1], operands[1], !BYTES_BIG_ENDIAN);
+  emit_insn (gen_vsx_xvcvspxds (operands[0], reg));
+  DONE;
+})
+
diff --git a/gcc/testsuite/gcc.target/powerpc/conv-vectorize-1.c 
b/gcc/testsuite/gcc.target/powerpc/conv-vectorize-1.c
new file mode 100644
index 000..d96db14
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/conv-vectorize-1.c
@@ -0,0 +1,37 @@
+/* { dg-require-effective-target powerpc_vsx_ok } */
+/* { dg-options "-O2 -ftree-vectorize -mvsx" } */
+
+/* Test vectorizer can exploit vector conversion instructions to convert
+   unsigned/signed long long to float.  */
+
+#include 
+
+#define SIZE 32
+#define ALIGN 16
+
+float sflt_array[SIZE] __attribute__ ((__aligned__ (ALIGN)));
+float uflt_array[SIZE] __attribute__ ((__aligned__ (ALIGN)));
+
+unsigned long long ulong_array[SIZE] __attribute__ ((__aligned__ (ALIGN)));
+signed long long slong_array[SIZE] __attribute__ ((__aligned__ (ALIGN)));
+
+void
+convert_slong_to_float (void)
+{
+  size_t i;
+
+  for (i = 0; i < SIZE; i++)
+sflt_array[i] = (float) slong_array[i];
+}
+
+void
+convert_ulong_to_float (void)
+{
+  size_t i;
+
+  for (i = 0; i < SIZE; i++)
+uflt_array[i] = (float) ulong_array[i];
+}
+
+/* { dg-final { scan-assembler {\mxvcvsxdsp\M} } } */
+/* { dg-final { scan-assembler {\mxvcvuxdsp\M} } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/conv-vectorize-2.c 
b/gcc/testsuite/gcc.target/powerpc/conv-vectorize-2.c
new file mode 100644
index 000..5dd5dea
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/conv-vectorize-2.c
@@ -0,0 +1,37 @@
+/* { dg-require-effective-target powerpc_vsx_ok } */
+/* { dg-options "-O2 -ftree-vectorize -mvsx" } */
+
+/* Test vectorizer can exploit vector conversion instructions to convert
+   float to unsigned/signed long long.  */
+
+#include 
+
+#define SIZE 32
+#define ALIGN 16
+
+float sflt_array[SIZE] __attribute__ ((__aligned__ (ALIGN)));
+float uflt_array[SIZE] __attribute__ ((__aligned__ (ALIGN)));
+
+unsigned long long ulong_array[SIZE] __attribute__ ((__aligned__ (ALIGN)));
+signed long long slong_array[SIZE] __attribute__ ((__aligned__ (ALIGN)));
+
+void
+convert_float_to_slong (void)
+{
+  size_t i;
+
+  for (i = 0; i < SIZE; i++)
+slong_array[i] = (signed long long) sflt_array[i];
+}
+
+void
+convert_float_to_ulong (void)
+{
+  size_t i;
+
+  for (i = 0; i < SIZE; i++)
+ulong_array[i] = (unsigned long long) uflt_array[i];
+}
+
+/* { dg-final { scan-assembler {\mxvcvspsxds\M} } } */
+/* { dg-final { scan-assembler {\mxvcvspuxds\M} } } */

[Bug c++/91923] New: [9/10 Regression] Failure-to-SFINAE with class type NTTP in C++17

[Casey at Carter dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91923

Bug ID: 91923
   Summary: [9/10 Regression] Failure-to-SFINAE with class type
NTTP in C++17
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Casey at Carter dot net
  Target Milestone: ---

Compiling this well-formed TU (https://godbolt.org/z/8HYWSC):

template
constexpr bool is_integral_(...) {
return false;
}
template
constexpr bool is_integral_(long) {
return true;
}

static_assert(is_integral_(42));
static_assert(!is_integral_(42));

struct S {};
static_assert(!is_integral_(42));

with -std=c++17 diagnoses:

: In substitution of 'template > constexpr
bool is_integral_(long int) [with T = S; T  = ]':
:14:34:   required from here
:5:26: error: non-type template parameters of class type only
available with '-std=c++2a' or '-std=gnu++2a'
5 | template
  |  ^
Compiler returned: 1

whereas earlier compiler versions (at least 6 though 8) accept the TU without
diagnostic.

This seems to simply be a case of adding the helpful new diagnostic but
forgetting to silence it in SFINAE context.

C++ PATCH for c++/91889 - follow-up fix for DR 2352

[Marek Polacek]

It turned out that DR 2352 needs some fixing: as of now, it means that in

  void f(int*); // #1
  void f(const int* const &); // #2
  void g(int* p) { f(p); }

the call to f is ambiguous.  This broke e.g. Boost.  I raised this on the CWG
reflector and Jason suggested wording that would break this up; this patch is
an attempt to implement that suggestion.

Jason, you remarked that adding a ck_qual under the ck_ref_bind might be
too much trouble, but it seems it's actually fairly simple.  The comments
hopefully explain my thinking.  Is this what you had in mind?

ref-bind6.C is something reduced from libstdc++ I came across when testing
this patch.

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

2019-09-26  Marek Polacek  

PR c++/91889 - follow-up fix for DR 2352.
* call.c (involves_qualification_conversion_p): New function.
(direct_reference_binding): Build a ck_qual if the conversion
would involve a qualification conversion.
(convert_like_real): Strip the conversion created by the ck_qual
in direct_reference_binding.

* g++.dg/cpp0x/ref-bind3.C: Add dg-error.
* g++.dg/cpp0x/ref-bind4.C: New test.
* g++.dg/cpp0x/ref-bind5.C: New test.
* g++.dg/cpp0x/ref-bind6.C: New test.
* g++.old-deja/g++.pt/spec35.C: Revert earlier change.

diff --git gcc/cp/call.c gcc/cp/call.c
index 45b984ecb11..09976369aed 100644
--- gcc/cp/call.c
+++ gcc/cp/call.c
@@ -1555,6 +1555,27 @@ reference_compatible_p (tree t1, tree t2)
   return true;
 }
 
+/* Return true if converting FROM to TO would involve a qualification
+   conversion.  */
+
+static bool
+involves_qualification_conversion_p (tree to, tree from)
+{
+  /* If we're not convering a pointer to another one, we won't get
+ a qualification conversion.  */
+  if (!((TYPE_PTR_P (to) && TYPE_PTR_P (from))
+   || (TYPE_PTRDATAMEM_P (to) && TYPE_PTRDATAMEM_P (from
+return false;
+
+  conversion *conv = standard_conversion (to, from, NULL_TREE,
+ /*c_cast_p=*/false, 0, tf_none);
+  for (conversion *t = conv; t; t = next_conversion (t))
+if (t->kind == ck_qual)
+  return true;
+
+  return false;
+}
+
 /* A reference of the indicated TYPE is being bound directly to the
expression represented by the implicit conversion sequence CONV.
Return a conversion sequence for this binding.  */
@@ -1598,6 +1619,19 @@ direct_reference_binding (tree type, conversion *conv)
 That way, convert_like knows not to generate a temporary.  */
   conv->need_temporary_p = false;
 }
+  else if (involves_qualification_conversion_p (t, conv->type))
+/* Represent the qualification conversion.  After DR 2352
+   #1 and #2 were indistinguishable conversion sequences:
+
+void f(int*); // #1
+void f(const int* const &); // #2
+void g(int* p) { f(p); }
+
+   because the types "int *" and "const int *const" are
+   reference-related and we were binding both directly and they
+   had the same rank.  To break it up, we add a ck_qual under the
+   ck_ref_bind so that conversion sequence ranking chooses #1.  */
+conv = build_conv (ck_qual, t, conv);
 
   return build_conv (ck_ref_bind, type, conv);
 }
@@ -7342,6 +7376,16 @@ convert_like_real (conversion *convs, tree expr, tree 
fn, int argnum,
   {
tree ref_type = totype;
 
+   /* direct_reference_binding might have inserted a ck_qual under
+  this ck_ref_bind for the benefit of conversion sequence ranking.
+  Ignore the conversion; we'll create our own below.  */
+   if (next_conversion (convs)->kind == ck_qual)
+ {
+   gcc_assert (same_type_p (TREE_TYPE (expr),
+next_conversion (convs)->type));
+   STRIP_NOPS (expr);
+ }
+
if (convs->bad_p && !next_conversion (convs)->bad_p)
  {
tree extype = TREE_TYPE (expr);
diff --git gcc/testsuite/g++.dg/cpp0x/ref-bind3.C 
gcc/testsuite/g++.dg/cpp0x/ref-bind3.C
index 16e1bfe6ccc..b2c85ec684a 100644
--- gcc/testsuite/g++.dg/cpp0x/ref-bind3.C
+++ gcc/testsuite/g++.dg/cpp0x/ref-bind3.C
@@ -1,22 +1,18 @@
 // PR c++/91844 - Implement CWG 2352, Similar types and reference binding.
 // { dg-do compile { target c++11 } }
 
-template int f (const T *const &); // (1)
-template int f (T *const &); // (2)
-template int f (T *); // (3)
-
-/* Before CWG 2352, (2) was a better match than (1), but (2) and (3) were
-   equally good, so there was an ambiguity.  (2) was better than (1) because
-   (1) required a qualification conversion whereas (2) didn't.  But with this
-   CWG, (1) no longer requires a qualification conversion, because the types
-   "const int* const" and "int *" are now considered reference-related and we
-   bind directly, and (1) is more specialized than (2).  And (1) is also a
-   better match than (3).  */
+template int f (const T *const &); // 1
+template int f 

C++ PATCH for c++/91921 - stray warning with -Woverloaded-virtual

[Marek Polacek]

Here we were emitting a stray "by" message if base_fndecl was in
a system header but fns was not.  As usually, we need to guard such
a use.  Further, use inform instead of warning_at.

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

2019-09-26  Marek Polacek  

PR c++/91921 - stray warning with -Woverloaded-virtual.
* class.c (warn_hidden): Only emit the second part of
-Woverloaded-virtual if the first part was issued.  Use inform instead
warning_at.

* g++.dg/warn/Woverloaded-2.C: New.
* g++.dg/warn/Woverloaded-2.h: New.
* g++.dg/warn/pr61945.C: Turn dg-warning into dg-message.
* g++.old-deja/g++.mike/warn6.C: Likewise.
* g++.old-deja/g++.warn/virt1.C: Likewise.

diff --git gcc/cp/class.c gcc/cp/class.c
index 59a3d1a0496..0fd5e8e188d 100644
--- gcc/cp/class.c
+++ gcc/cp/class.c
@@ -2915,11 +2915,10 @@ warn_hidden (tree t)
  if (base_fndecl)
{
  /* Here we know it is a hider, and no overrider exists.  */
- warning_at (location_of (base_fndecl),
- OPT_Woverloaded_virtual,
- "%qD was hidden", base_fndecl);
- warning_at (location_of (fns),
- OPT_Woverloaded_virtual, "  by %qD", fns);
+ if (warning_at (location_of (base_fndecl),
+ OPT_Woverloaded_virtual,
+ "%qD was hidden", base_fndecl))
+   inform (location_of (fns), "  by %qD", fns);
}
   }
 }
diff --git gcc/testsuite/g++.dg/warn/Woverloaded-2.C 
gcc/testsuite/g++.dg/warn/Woverloaded-2.C
new file mode 100644
index 000..84d65de05ce
--- /dev/null
+++ gcc/testsuite/g++.dg/warn/Woverloaded-2.C
@@ -0,0 +1,9 @@
+// PR c++/91921 - stray warning with -Woverloaded-virtual.
+// { dg-options "-Woverloaded-virtual" }
+
+#include "Woverloaded-2.h"
+
+struct B : A
+{
+  void f(int);
+};
diff --git gcc/testsuite/g++.dg/warn/Woverloaded-2.h 
gcc/testsuite/g++.dg/warn/Woverloaded-2.h
new file mode 100644
index 000..b9e15b0c331
--- /dev/null
+++ gcc/testsuite/g++.dg/warn/Woverloaded-2.h
@@ -0,0 +1,6 @@
+#pragma GCC system_header
+
+struct A
+{
+  virtual void f();
+};
diff --git gcc/testsuite/g++.dg/warn/pr61945.C 
gcc/testsuite/g++.dg/warn/pr61945.C
index 5584d841692..3d40581e5e3 100644
--- gcc/testsuite/g++.dg/warn/pr61945.C
+++ gcc/testsuite/g++.dg/warn/pr61945.C
@@ -7,5 +7,5 @@ class A {
 };
 class B : A {
   template 
-  void foo (); // { dg-warning "by .B::foo\\(\\)." }
+  void foo (); // { dg-message "by .B::foo\\(\\)." }
 };
diff --git gcc/testsuite/g++.old-deja/g++.mike/warn6.C 
gcc/testsuite/g++.old-deja/g++.mike/warn6.C
index 9c694d62559..26759cfb527 100644
--- gcc/testsuite/g++.old-deja/g++.mike/warn6.C
+++ gcc/testsuite/g++.old-deja/g++.mike/warn6.C
@@ -30,13 +30,13 @@ struct D : public B, public B2, public B3 {
 
   virtual void bothsame(int);
 
-  virtual void bothdiff(int);  // { dg-warning "" } 
+  virtual void bothdiff(int);  // { dg-message "" } 
 
   virtual void both2same(int);
   virtual void both2same(float);
 
-  virtual void both12diff(int);// { dg-warning "" } 
+  virtual void both12diff(int);// { dg-message "" } 
 
-  virtual void bothfardiff(int);   // { dg-warning "" } 
+  virtual void bothfardiff(int);   // { dg-message "" } 
 };
 
diff --git gcc/testsuite/g++.old-deja/g++.warn/virt1.C 
gcc/testsuite/g++.old-deja/g++.warn/virt1.C
index 4550dd5e054..c68de8a7e7c 100644
--- gcc/testsuite/g++.old-deja/g++.warn/virt1.C
+++ gcc/testsuite/g++.old-deja/g++.warn/virt1.C
@@ -6,5 +6,5 @@ struct A {
 };
 
 struct B: public A {
-  void f(int); // { dg-warning "" } by this
+  void f(int); // { dg-message "" } by this
 };

[Bug ipa/89924] [missed-optimization] Function not de-virtualized within the same TU

[kamleshbhalui at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89924

--- Comment #6 from Kamlesh Kumar  ---
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01527.html

[FYI] [Ada] set DECL_SIZE_UNIT for zero-sized fields

[Alexandre Oliva]

Zero-sized fields do not get processed by finish_record_type: they're
removed from the field list before and reinserted after, so their
DECL_SIZE_UNIT remains unset, causing the translation of assignment
statements with use_memset_p, in quite unusual circumstances, to use a
NULL_TREE as the memset length.  This patch sets DECL_SIZE_UNIT for
the zero-sized fields, that don't go through language-independent
layout, in language-specific layout.

Regstrapped on x86_64-linux-gnu.  I'm checking this in.


for  gcc/ada/ChangeLog

* gcc-interface/decl.c (components_to_record): Set
DECL_SIZE_UNIT for zero-sized fields.
---
 gcc/ada/gcc-interface/decl.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/ada/gcc-interface/decl.c b/gcc/ada/gcc-interface/decl.c
index 67b938ee7eef0..77c6c9f12e76c 100644
--- a/gcc/ada/gcc-interface/decl.c
+++ b/gcc/ada/gcc-interface/decl.c
@@ -7928,6 +7928,7 @@ components_to_record (Node_Id gnat_component_list, 
Entity_Id gnat_record_type,
 
   if (DECL_SIZE (gnu_field) && integer_zerop (DECL_SIZE (gnu_field)))
{
+ DECL_SIZE_UNIT (gnu_field) = size_zero_node;
  DECL_FIELD_OFFSET (gnu_field) = size_zero_node;
  SET_DECL_OFFSET_ALIGN (gnu_field, BIGGEST_ALIGNMENT);
  DECL_FIELD_BIT_OFFSET (gnu_field) = bitsize_zero_node;

-- 
Alexandre Oliva, freedom fighter  he/him   https://FSFLA.org/blogs/lxo
Be the change, be Free!FSF VP & FSF Latin America board member
GNU Toolchain EngineerFree Software Evangelist
Hay que enGNUrecerse, pero sin perder la terGNUra jamás - Che GNUevara

Re: [PATCH 2/2] libada: Respect `--enable-version-specific-runtime-libs'

[Maciej W. Rozycki]

On Thu, 26 Sep 2019, Arnaud Charlet wrote:

> > Notice that ADA_RTL_OBJ_DIR never changes with/without the use of this 
> > configuration option (as expected).
> > 
> >  Does it answer your question?
> 
> Yes, that's now very clear, thanks!

 Sorry not to make the original change description clear enough.

> The change is OK for me, thanks.

 Thanks for your review.

 Shall I amend the change description anyhow then?  I know it has not (as 
yet, as discussed at the GNU Tools Cauldron recently) been enforced for 
the GCC project (unlike with e.g. glibc), however I mean to use it whole 
as the commit message, which is what I have been doing for quite a while 
now, because I recognise the value of change descriptions for future 
repository examination.

  Maciej

Re: [PATCH 1/2] libada: Remove racy duplicate gnatlib installation

[Maciej W. Rozycki]

On Thu, 26 Sep 2019, Arnaud Charlet wrote:

> Unfortunately the Make-lang.in part is still needed when using the
> --disable-libada configure switch so a more elaborate change is needed.

 Hmm, I've experimented a bit and AFAICT if `--disable-libada' is given 
without my proposed change applied, then the gnatlib stuff doesn't get 
built in the first place let alone installed anyway.

 Actually the `install-gnatlib' target invocation in `ada.install-common' 
I have proposed to get removed does go ahead in that case, and then fails, 
again non-fatally (thanks to the `-' recipe line prefix in action here 
too):

make[4]: Entering directory '.../gcc/ada'
You must first build the GNAT library: make gnatlib
make[4]: *** [gcc-interface/Makefile:497: ../stamp-gnatlib-rts] Error 1
make[4]: Leaving directory '.../gcc/ada'
make[3]: *** [.../gcc/ada/gcc-interface/Make-lang.in:852: install-gnatlib] 
Error 2
make[2]: [.../gcc/ada/gcc-interface/Make-lang.in:828: ada.install-common] Error 
2 (ignored)

so all my change effectively does in that case is to remove these 
messages.

 I went as far as to compare the installed trees with `--disable-libada' 
specified and then without and with my patch applied respectively and they 
were exactly the same.

 NB no gnattools stuff is built either when `--disable-libada' is in 
effect, due to this clause in Makefile.def:

dependencies = { module=all-gnattools; on=all-target-libada; };

leaving the resulting installation with a bare Ada compiler driver and 
backend only, e.g. with my native `x86_64-linux-gnu' setup:

$(prefix)/bin/gnatbind
$(prefix)/libexec/gcc/x86_64-linux-gnu/10.0.0/gnat1

(which is then of course incapable of building a `riscv-linux-gnu' 
cross-compiler, so that's it as far as Ada support goes).

 Therefore I maintain my change is correct and safe to apply.

 OK to go ahead with it then?  Or have I missed anything and you meant 
something else (I find "still needed" a bit vague)?

  Maciej

Re: [PATCH v2, rs6000] Replace X-form addressing with D-form addressing in new pass for Power 9

[Segher Boessenkool]

Hi Kelvin,

Sorry for the slow review.

On Tue, Sep 03, 2019 at 03:10:09PM -0500, Kelvin Nilsen wrote:
> This new pass scans existing rtl expressions and replaces them with rtl 
> expressions that favor selection of the D-form instructions in contexts for 
> which the D-form instructions are preferred.  The new pass runs after the RTL 
> loop optimizations since loop unrolling often introduces opportunities for 
> beneficial replacements of X-form addressing instructions.

And that is before the "big" RTL passes (cprop, CSE, combine, and related).
Okay.

> --- gcc/config/rs6000/rs6000-p9dform.c(nonexistent)
> +++ gcc/config/rs6000/rs6000-p9dform.c(working copy)
> @@ -0,0 +1,1487 @@
> +/* Subroutines used to transform array subscripting expressions into
> +   forms that are more amenable to d-form instruction selection for p9
> +   little-endian VSX code.
> +   Copyright (C) 1991-2018 Free Software Foundation, Inc.

(Year needs updating here).

> +   This pass runs immediately after pass_loops2.  Loops have already

(typo, pass_loop2)

> +/* This is based on the union-find logic in web.c.  web_entry_base is
> +   defined in df.h.  */
> +class indexing_web_entry : public web_entry_base
> +{
> + public:

Most places have no extra leading space here.  Not sure what the coding
standards say?

> +static int count_links (struct df_link *def_link)
> +{
> +  int result;
> +  for (result = 0; def_link != NULL; result++)
> +def_link = def_link->next;
> +  return result;
> +}

Maybe this belongs in more generic code?  Or as inline in df.h even?

> +
> +  int result = 0;
> +  for (i = 0; i < count; i++)
> +{
> +  result = (result << 6) | ((result & 0xf00) >> 28);

Do you want an extra zero in the constant there?  The expression  is 0
as written.

Shifting a signed (possibly negative!) number to the right isn't a great
idea in any case.

Maybe you want to use some standard hash, instead?

> +   /* if there is no def, or the def is artificial,
> +  or there are multiple defs, this is an originating
> +  use.  */

(Sentence should start with a capital).

> +   unsigned int uid2 =
> + insn_entry[uid].original_base_use;

The = goes on the second line, instead.

> +  rtx mem = NULL;
> +  if (GET_CODE (body) == SET)
> +{
> +  if (MEM_P (SET_SRC (body)))
> + mem = XEXP (SET_SRC (body), 0);
> +  else if (MEM_P (SET_DEST (body)))
> + mem = XEXP (SET_DEST (body), 0);
> +}
> +  /* Otherwise, this is neither load or store, so leave mem as NULL.  */
> +
> +  if (mem != NULL)
> +{

You could instead say

  if (!mem)
return;

and then you don't need the comment or the "if" after it.  Or even:

  if (GET_CODE (body) != SET)
return;

  rtx mem;
  if (MEM_P (SET_SRC (body)))
mem = XEXP (SET_SRC (body), 0);
  else if (MEM_P (SET_DEST (body)))
mem = XEXP (SET_DEST (body), 0);
  else
return;

> +{
> +  rtx def_insn = DF_REF_INSN (def_link->ref);
> +  /* unsigned uid = INSN_UID (def_insn); not needed? */

Delete this line?  Or is it useful still :-)

> +  if (GET_CODE (body) == CONST_INT)
> + return true;

if (CONST_INT_P (body)) ...

> +static bool
> +in_use_list (struct df_link *list, struct df_link *element)
> +{
> +  while (list != NULL)
> +{
> +  if (element->ref == list->ref)
> + return true;
> +  list = list->next;
> +}
> +  /* Got to end of list without finding element.  */
> +  return false;
> +}

This kind of function makes me scared of quadratic complexity somewhere.
I didn't check, but it seems likely :-/

> +  if ((insn_entry[uid_1].base_equivalence_hash !=
> +   insn_entry[uid_2].base_equivalence_hash) ||
> +  (insn_entry[uid_1].index_equivalence_hash !=
> +   insn_entry[uid_2].index_equivalence_hash))
> +return false;
> +  else   /* Hash codes match.  Check details.  */

After a return you don't need an else.  Reduce indentation, instead :-)

> +/* Return true iff instruction I2 dominates instruction I1.  */
> +static bool
> +insn_dominated_by_p (rtx_insn *i1, rtx_insn *i2)
> +{
> +  basic_block bb1 = BLOCK_FOR_INSN (i1);
> +  basic_block bb2 = BLOCK_FOR_INSN (i2);
> +
> +  if (bb1 == bb2)
> +{
> +  for (rtx_insn *i = i2;
> +(i != NULL) && (BLOCK_FOR_INSN (i) == bb1); i = NEXT_INSN (i))

How can it ever be NULL?

> + if (i == i1)
> +   return true;
> +  return false;
> +}
> +  else
> +return dominated_by_p (CDI_DOMINATORS, bb1, bb2);
> +}

IRA already has an insn_dominated_by_p function, which is constant time
(it does require some extra init for uid_luid[]).

> +   int hash = ((insn_entry [uid].base_equivalence_hash +

No + at the end of line, either.  The check_GNU_style script should
check for this (not sure if it actually does, YMMV).

> +  /* Since this pass creates new instructions, get_max_uid () may
> + return different values at different times during this pass.  The
> +

Re: Moving to C++11

[Eric Gallager]

On 9/26/19, Nicholas Krause  wrote:
> Greetings,
>
> I asked about moving to C/C++ 11 as it would make it easier to
>
> allow multithreading support due to having a memory model
>
> alongside other features. Jason Merill mentioned due to it
>
> being so common it may be a good  time to.
>
> Moving to git seems to be universally agree on so I'm opening the
> discussion
>
> for the same as related to C/C++11 migration and if possible opening
>
> a TODO similar to git if decided on.
>
> Please post your comments or ideas about the migration in response to this
>
> email,
>
> Nick
>
>

A good first step would be to flip the switch from -Wno-narrowing to
-Wnarrowing in the warning flags GCC uses when building, as C++11 has
stricter rules about narrowing conversions. This would be useful even
if we don't end up going to C++11 yet, as such narrowing conversions
are bad even in versions of the standard where they're allowed.

Re: Moving to C++11

[Pedro Alves]

On 9/26/19 9:08 AM, Richard Biener wrote:

> Note the main issue is host compiler support.  I'm not sure if C++11 would
> be the step we'd gain most - for some hashtable issues I'd have needed
> std::move support for example.  There's always the possibility to
> require an intermediate step (first build GCC 5, with that you can build
> trunk, etc.), a install.texi clarification could be useful here (or even
> some automation via a contrib/ script).
> 
> I'm not too worried about requiring even a C++14 compiler, for the
> set of products we still release latest compilers we have newer
> GCCs available we can use for building them (even if those are
> not our primary supported compilers which would limit us to
> GCC 4.8).

FWIW, GDB requires C++11 nowadays, and the baseline required
GCC version is GCC 4.8.1.  The current policy is here:

https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards#When_is_GDB_going_to_start_requiring_C.2B-.2B-NN_.3F

Pasted for convenience:

 
 When is GDB going to start requiring C++NN ?

 Our general policy is to wait until the oldest compiler that 
 supports C++NN is at least 3 years old.

 Rationale: We want to ensure reasonably widespread compiler 
 availability, to lower barrier of entry to GDB contributions, 
 and to make it easy for users to easily build new GDB on currently
 supported stable distributions themselves. 3 years should be sufficient
 for latest stable releases of distributions to include a compiler
 for the standard, and/or for new compilers to appear as easily
 installable optional packages. Requiring everyone to build a compiler
 first before building GDB, which would happen if we required a
 too-new compiler, would cause too much inconvenience. 
 

That was decided 3 years ago, so I guess we'd be good for a
reevaluation, though I don't particularly miss C++14 features
all that much, so I wouldn't mind staying with C++11 for a while
longer in GDB.  But if GCC jumps to C++14, I think GDB would
follow along.  Just FYI.

C++03 -> C++11 makes a great difference.  Particularly
std::move and rvalue references are a game changer.

Thanks,
Pedro Alves

gcc-7-20190926 is now available

[gccadmin]

Snapshot gcc-7-20190926 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/7-20190926/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch 
revision 276168

You'll find:

 gcc-7-20190926.tar.xzComplete GCC

  SHA256=e1b55fa288f7bd0f60e1207c4fda0b7ae00dec6e8ba1c36a6451f9dbb3e6e1ff
  SHA1=5a42d00b8ff1b67b0f94a3a5a14020bdb45a0b20

Diffs from 7-20190919 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-7
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: Problem exposed by recent ARM multiply changes

[Segher Boessenkool]

On Fri, Sep 27, 2019 at 12:30:50AM +0200, Jakub Jelinek wrote:
> On Thu, Sep 26, 2019 at 05:17:40PM -0500, Segher Boessenkool wrote:
> > On Wed, Sep 25, 2019 at 10:06:13PM -0600, Jeff Law wrote:
> > > (insn 14 13 16 2 (parallel [
> > > (set (reg:SI 132)
> > > (plus:SI (mult:SI (zero_extend:DI (reg/v:SI 115 [ sec ]))
> > > (zero_extend:DI (reg:SI 124)))
> > > (reg:SI 130)))
> > > (set (reg:SI 133 [+4 ])
> > > (plus:SI (truncate:SI (lshiftrt:DI (plus:DI (mult:DI 
> > > (zero_extend:DI (reg/v:SI 115 [ sec ]))
> > > (zero_extend:DI (reg:SI 124)))
> > > (zero_extend:DI (reg:SI 130)))
> > > (const_int 32 [0x20])))
> > > (reg:SI 131 [+4 ])))
> > > ]) "j.c":10:54 60 {umlal}
> > >  (expr_list:REG_DEAD (reg:SI 131 [+4 ])
> > > (expr_list:REG_DEAD (reg:SI 130)
> > > (expr_list:REG_DEAD (reg:SI 124)
> > > (expr_list:REG_DEAD (reg/v:SI 115 [ sec ])
> > > (nil))
> > 
> > This is not a correct pattern for umlal (it should have a carry from the
> > low half of the addition to the high half).
> 
> Are you sure?
> "The UMLAL instruction interprets the values from Rn and Rm as unsigned
> integers.  It multiplies these integers, and adds the 64-bit result to the
> 64-bit unsigned integer contained in RdHi and RdLo."

Yes.  It adds two 64-bit numbers.  That is not the same as adding the
top and bottom 32-bit halfs of that separately.

> Appart from the bug I've provided untested fix in the PR, the above pattern
> seems to do what the documentation says, the low 32 bits are
> (unsigned int) (Rn*Rm+RdLo), and the whole result for unsigned int
> Rn, Rm, RdHi and RdLo is
> (unsigned long long)Rn*Rm+((unsigned long long)RdHi<<32)+RdLo
> and the upper 32 bits of that are IMHO equivalent to
> (unsigned) (((unsigned long long)Rn*Rm+RdLo)>>32)+RdHi

The upper half of the result should be one bigger if the addition of the
low half carries.


Segher

Re: Problem exposed by recent ARM multiply changes

[Jakub Jelinek]

On Thu, Sep 26, 2019 at 05:17:40PM -0500, Segher Boessenkool wrote:
> On Wed, Sep 25, 2019 at 10:06:13PM -0600, Jeff Law wrote:
> > (insn 14 13 16 2 (parallel [
> > (set (reg:SI 132)
> > (plus:SI (mult:SI (zero_extend:DI (reg/v:SI 115 [ sec ]))
> > (zero_extend:DI (reg:SI 124)))
> > (reg:SI 130)))
> > (set (reg:SI 133 [+4 ])
> > (plus:SI (truncate:SI (lshiftrt:DI (plus:DI (mult:DI 
> > (zero_extend:DI (reg/v:SI 115 [ sec ]))
> > (zero_extend:DI (reg:SI 124)))
> > (zero_extend:DI (reg:SI 130)))
> > (const_int 32 [0x20])))
> > (reg:SI 131 [+4 ])))
> > ]) "j.c":10:54 60 {umlal}
> >  (expr_list:REG_DEAD (reg:SI 131 [+4 ])
> > (expr_list:REG_DEAD (reg:SI 130)
> > (expr_list:REG_DEAD (reg:SI 124)
> > (expr_list:REG_DEAD (reg/v:SI 115 [ sec ])
> > (nil))
> 
> This is not a correct pattern for umlal (it should have a carry from the
> low half of the addition to the high half).

Are you sure?
"The UMLAL instruction interprets the values from Rn and Rm as unsigned
integers.  It multiplies these integers, and adds the 64-bit result to the
64-bit unsigned integer contained in RdHi and RdLo."

Appart from the bug I've provided untested fix in the PR, the above pattern
seems to do what the documentation says, the low 32 bits are
(unsigned int) (Rn*Rm+RdLo), and the whole result for unsigned int
Rn, Rm, RdHi and RdLo is
(unsigned long long)Rn*Rm+((unsigned long long)RdHi<<32)+RdLo
and the upper 32 bits of that are IMHO equivalent to
(unsigned) (((unsigned long long)Rn*Rm+RdLo)>>32)+RdHi

Jakub

[Bug libbacktrace/91908] New libbacktrace tests fail to build

[dave.anglin at bell dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91908

--- Comment #3 from dave.anglin at bell dot net ---
On 2019-09-26 6:26 p.m., ian at airs dot com wrote:
> Should be fixed on trunk.
Thanks Ian.

[Bug libstdc++/91871] iterator_to_const_iterator() in testsuite_hooks.h causes valid -Wreturn-stack-address warnings with LLVM

[brooks at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91871

--- Comment #7 from Brooks Moses  ---
Thanks, Jonathan!  I've confirmed that this does indeed fix the warning with
Clang trunk, and the test passes again.

[Bug libbacktrace/91908] New libbacktrace tests fail to build

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91908

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ian at airs dot com
 Resolution|--- |FIXED

--- Comment #2 from Ian Lance Taylor  ---
Should be fixed on trunk.

[Bug rtl-optimization/91860] [10 Regression] ICE: in decompose, at rtl.h:2279 with -Og -fipa-cp -g --param=max-combine-insns=3

[wilson at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91860

--- Comment #5 from Jim Wilson  ---
The new testcase is essentially the same problem, but it is i1src this time not
i2src, so just copying i2src earlier doesn't solve the problem, we also need a
fix for i1src, or a fix elsewhere.

[Bug libbacktrace/91908] New libbacktrace tests fail to build

[ian at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91908

--- Comment #1 from ian at gcc dot gnu.org  ---
Author: ian
Date: Thu Sep 26 22:19:47 2019
New Revision: 276168

URL: https://gcc.gnu.org/viewcvs?rev=276168=gcc=rev
Log:
PR libbacktrace/91908
* pecoff.c (backtrace_initialize): Explicitly cast unchecked
__sync_bool_compare_and_swap to void.
* xcoff.c (backtrace_initialize): Likewise.

Modified:
trunk/libbacktrace/ChangeLog
trunk/libbacktrace/pecoff.c
trunk/libbacktrace/xcoff.c

Avoid libbacktrace warnings with old compilers

[Ian Lance Taylor]

This patch to libbacktrace avoids a compilation warning when building
libbacktrace with an old compiler.  This fixes PR 91908.  Bootstrapped
and ran libbacktrace tests.  Committed to mainline.

Ian

2019-09-26  Ian Lance Taylor  

PR libbacktrace/91908
* pecoff.c (backtrace_initialize): Explicitly cast unchecked
__sync_bool_compare_and_swap to void.
* xcoff.c (backtrace_initialize): Likewise.
Index: pecoff.c
===
--- pecoff.c(revision 275698)
+++ pecoff.c(working copy)
@@ -922,7 +922,8 @@ backtrace_initialize (struct backtrace_s
   if (found_sym)
backtrace_atomic_store_pointer (>syminfo_fn, coff_syminfo);
   else
-   __sync_bool_compare_and_swap (>syminfo_fn, NULL, coff_nosyms);
+   (void) __sync_bool_compare_and_swap (>syminfo_fn, NULL,
+coff_nosyms);
 }
 
   if (!state->threaded)
Index: xcoff.c
===
--- xcoff.c (revision 275698)
+++ xcoff.c (working copy)
@@ -1592,7 +1592,8 @@ backtrace_initialize (struct backtrace_s
   if (found_sym)
backtrace_atomic_store_pointer (>syminfo_fn, xcoff_syminfo);
   else
-   __sync_bool_compare_and_swap (>syminfo_fn, NULL, xcoff_nosyms);
+   (void) __sync_bool_compare_and_swap (>syminfo_fn, NULL,
+xcoff_nosyms);
 }
 
   if (!state->threaded)

Re: Problem exposed by recent ARM multiply changes

[Segher Boessenkool]

On Wed, Sep 25, 2019 at 10:06:13PM -0600, Jeff Law wrote:
> (insn 14 13 16 2 (parallel [
> (set (reg:SI 132)
> (plus:SI (mult:SI (zero_extend:DI (reg/v:SI 115 [ sec ]))
> (zero_extend:DI (reg:SI 124)))
> (reg:SI 130)))
> (set (reg:SI 133 [+4 ])
> (plus:SI (truncate:SI (lshiftrt:DI (plus:DI (mult:DI
> (zero_extend:DI (reg/v:SI 115 [ sec ]))
> (zero_extend:DI (reg:SI 124)))
> (zero_extend:DI (reg:SI 130)))
> (const_int 32 [0x20])))
> (reg:SI 131 [+4 ])))
> ]) "j.c":10:54 60 {umlal}
>  (expr_list:REG_DEAD (reg:SI 131 [+4 ])
> (expr_list:REG_DEAD (reg:SI 130)
> (expr_list:REG_DEAD (reg:SI 124)
> (expr_list:REG_DEAD (reg/v:SI 115 [ sec ])
> (nil))

This is not a correct pattern for umlal (it should have a carry from the
low half of the addition to the high half).


Segher

Re: Problem exposed by recent ARM multiply changes

[Jakub Jelinek]

On Thu, Sep 26, 2019 at 03:27:50PM -0600, Jeff Law wrote:
> > Some machines support a multiplication that generates a product wider
> > than the operands.  Write the pattern for this as
> > 
> > @smallexample
> > (mult:@var{m} (sign_extend:@var{m} @var{x}) (sign_extend:@var{m} @var{y}))
> > @end smallexample
> > 
> > where @var{m} is wider than the modes of @var{x} and @var{y}, which need
> > not be the same.
> ^^^ this clause.  I read this as x & y being able to vary relative to
> each other.  But I think you're reading it as x & y are the same, but
> they can vary relative to m

This talks about the mult with sign_extend operands, and in that case
sure, x can have different mode from y, the only restriction is that
the modes are scalar integral (otherwise sign_extend isn't valid) and that
they are narrower than m.  But, the mult still has both operands as well as
result with the same mode m, x and y aren't operands of mult in that case,
but of the sign_extends.

Jakub

Re: Problem exposed by recent ARM multiply changes

[Jeff Law]

On 9/26/19 10:05 AM, Jakub Jelinek wrote:
> On Thu, Sep 26, 2019 at 10:01:56AM -0600, Jeff Law wrote:
>> On 9/26/19 9:47 AM, Jakub Jelinek wrote:
>>> On Thu, Sep 26, 2019 at 09:39:31AM -0600, Jeff Law wrote:
 Right.  My point is that the multiplication patterns are an exception as
 well.
>>>
>>> Do you have some evidence for that? 
>> It's in the manual.  And yes it potentially makes a huge mess due to the
>> interactions with modeless CONST_INTs.
> 
> Where?
> Unless otherwise specified, all the operands of arithmetic expressions
> must be valid for mode @var{m}.  An operand is valid for mode @var{m}
> if it has mode @var{m}, or if it is a @code{const_int} or
> @code{const_double} and @var{m} is a mode of class @code{MODE_INT}.
> 
> and for MULT:
> Represents the signed product of the values represented by @var{x} and
> @var{y} carried out in machine mode @var{m}.
> @code{ss_mult} and @code{us_mult} ensure that an out-of-bounds result
> saturates to the maximum or minimum signed or unsigned value.
> 
> Some machines support a multiplication that generates a product wider
> than the operands.  Write the pattern for this as
> 
> @smallexample
> (mult:@var{m} (sign_extend:@var{m} @var{x}) (sign_extend:@var{m} @var{y}))
> @end smallexample
> 
> where @var{m} is wider than the modes of @var{x} and @var{y}, which need
> not be the same.
^^^ this clause.  I read this as x & y being able to vary relative to
each other.  But I think you're reading it as x & y are the same, but
they can vary relative to m

Jeff

[Bug tree-optimization/91885] [9 Regression] ICE when compiling SPEC 2017 blender benchmark with -O3 -fprofile-generate

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91885

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #6 from Rainer Orth  ---
(In reply to Christophe Lyon from comment #5)

> because the *int64_t types are not defined correctly for 32 bits targets.

Indeed:

typedef signed long int __int64_t;
typedef unsigned long int __uint64_t;

They should use long long/unsigned long long or (better yet)
__INT64_TYPE__/__UINT64_TYPE__

[Bug tree-optimization/91885] [9 Regression] ICE when compiling SPEC 2017 blender benchmark with -O3 -fprofile-generate

[clyon at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91885

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #5 from Christophe Lyon  ---
(In reply to Martin Liška from comment #4)
> Fixed on trunk so far.

So new testcase fails on arm:
FAIL: gcc.dg/pr91885.c (test for excess errors)
Excess errors:
pr91885.c:13:17: warning: right shift count >= width of type
[-Wshift-count-overflow]
pr91885.c:13:34: warning: left shift count >= width of type
[-Wshift-count-overflow]
pr91885.c:18:12: warning: right shift count >= width of type
[-Wshift-count-overflow]
pr91885.c:18:52: warning: left shift count >= width of type
[-Wshift-count-overflow]

because the *int64_t types are not defined correctly for 32 bits targets.

[Bug target/91880] ICE: segfault in hwloop_optimize

[jcmvbkbc at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91880

jcmvbkbc at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from jcmvbkbc at gcc dot gnu.org ---
This is now fixed and a new regression test is added.

[Bug c/91922] New: #pragma pack(push,4) does not align element on 32 bit boundary properly

[slightbody at ledroadwaylighting dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91922

Bug ID: 91922
   Summary: #pragma pack(push,4) does not align element on 32 bit
boundary properly
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slightbody at ledroadwaylighting dot com
  Target Milestone: ---

Created attachment 46958
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46958=edit
c source

The attached small main.c results in a Hard Fault on the line *p=x; when
compiled for the Cortex M0+ processor. The u32thing element of the structure
should be aligned on a 32bit boundary in memory due to the #pragma pack(push,4)
statement, but it is not.

It appears the compiler may be being confused by the pack(1) directive later in
the structure.

Compile line:
"D:\Atmel\Studio\7.0\toolchain\arm\arm-gnu-toolchain\bin\arm-none-eabi-gcc.exe"
 -x c -mthumb -D__SAMD21G18A__ -DNDEBUG 
-I"D:\Atmel\Studio\7.0\Packs\arm\cmsis\5.0.1\CMSIS\Include"
-I"D:\Atmel\Studio\7.0\Packs\atmel\SAMD21_DFP\1.3.304\samd21a\include"  -Os
-ffunction-sections -mlong-calls -Wall -mcpu=cortex-m0plus -c -std=gnu99 -MD
-MP -MF "main.d" -MT"main.d" -MT"main.o"   -o "main.o" ".././main.c" 

Snip of .map file (one_v) should be on a 32 bit aligned address:
 *(COMMON)
 COMMON 0x24500xa main.o
0x2450two
0x2454abc
0x2455one_v

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

[Max Filippov]

On Thu, Sep 26, 2019 at 1:42 PM augustine.sterl...@gmail.com
 wrote:
>
> On Tue, Sep 24, 2019 at 5:41 PM Max Filippov  wrote:
> >
> > Xtensa hwloop_optimize segfaults when zero overhead loop is about to be
> > inserted as the first instruction of the function.
> > Insert zero overhead loop instruction into new basic block before the
> > loop when basic block that precedes the loop is empty.
> >
> > 2019-09-24  Max Filippov  
> > gcc/
> > * config/xtensa/xtensa.c (hwloop_optimize): Insert zero overhead
> > loop instruction into new basic block before the loop when basic
> > block that precedes the loop is empty.
> >
> > gcc/testsuite/
> > * gcc.target/xtensa/pr91880.c: New test case.
> > * gcc.target/xtensa/xtensa.exp: New test suite.
> > ---
> >  gcc/config/xtensa/xtensa.c |  5 ++--
> >  gcc/testsuite/gcc.target/xtensa/pr91880.c  | 10 
> >  gcc/testsuite/gcc.target/xtensa/xtensa.exp | 41 
> > ++
> >  3 files changed, 54 insertions(+), 2 deletions(-)
> >  create mode 100644 gcc/testsuite/gcc.target/xtensa/pr91880.c
> >  create mode 100644 gcc/testsuite/gcc.target/xtensa/xtensa.exp
>
> Approved. Thanks.

Thanks. Applied to trunk.
I'll backport it later to gcc-7..9 branches.

-- Max

[Bug target/91880] ICE: segfault in hwloop_optimize

[jcmvbkbc at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91880

--- Comment #4 from jcmvbkbc at gcc dot gnu.org ---
Author: jcmvbkbc
Date: Thu Sep 26 20:51:27 2019
New Revision: 276166

URL: https://gcc.gnu.org/viewcvs?rev=276166=gcc=rev
Log:
xtensa: fix PR target/91880

Xtensa hwloop_optimize segfaults when zero overhead loop is about to be
inserted as the first instruction of the function.
Insert zero overhead loop instruction into new basic block before the
loop when basic block that precedes the loop is empty.

2019-09-26  Max Filippov  
gcc/
* config/xtensa/xtensa.c (hwloop_optimize): Insert zero overhead
loop instruction into new basic block before the loop when basic
block that precedes the loop is empty.

gcc/testsuite/
* gcc.target/xtensa/pr91880.c: New test case.
* gcc.target/xtensa/xtensa.exp: New test suite.


Added:
trunk/gcc/testsuite/gcc.target/xtensa/
trunk/gcc/testsuite/gcc.target/xtensa/pr91880.c
trunk/gcc/testsuite/gcc.target/xtensa/xtensa.exp
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/xtensa/xtensa.c
trunk/gcc/testsuite/ChangeLog

Re: [PATCH] Multibyte awareness for diagnostics (PR 49973)

[Lewis Hyatt]

On Thu, Sep 26, 2019 at 4:47 PM Joseph Myers  wrote:
>
> On Thu, 26 Sep 2019, Lewis Hyatt wrote:
>
> > A couple notes:
> > - In order to avoid any portability problems with wchar_t, the
> > equivalent of wcwidth() from libc is implemented in-house.
>
> I'm uneasy about contrib/gen_wcwidth.cpp doing the generation using host
> libc's wcwidth.  The effect is that libcpp/generated_cpp_wcwidth.h is
> *not* reproducible unless you know exactly what host (libc version, locale
> used when running the program, distribution patches to libc and locale
> data) was used to run the program.  I think we need a generator that works
> from Unicode data in some way so we can explicitly say what version of the
> (unmodified) Unicode data was used.
>

Got it, no problem, will find something that accomplishes this.

-Lewis

Re: [PATCH] Multibyte awareness for diagnostics (PR 49973)

[Joseph Myers]

On Thu, 26 Sep 2019, Lewis Hyatt wrote:

> A couple notes: 
> - In order to avoid any portability problems with wchar_t, the
> equivalent of wcwidth() from libc is implemented in-house.

I'm uneasy about contrib/gen_wcwidth.cpp doing the generation using host 
libc's wcwidth.  The effect is that libcpp/generated_cpp_wcwidth.h is 
*not* reproducible unless you know exactly what host (libc version, locale 
used when running the program, distribution patches to libc and locale 
data) was used to run the program.  I think we need a generator that works 
from Unicode data in some way so we can explicitly say what version of the 
(unmodified) Unicode data was used.

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

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

[augustine.sterl...@gmail.com]

On Tue, Sep 24, 2019 at 5:41 PM Max Filippov  wrote:
>
> Xtensa hwloop_optimize segfaults when zero overhead loop is about to be
> inserted as the first instruction of the function.
> Insert zero overhead loop instruction into new basic block before the
> loop when basic block that precedes the loop is empty.
>
> 2019-09-24  Max Filippov  
> gcc/
> * config/xtensa/xtensa.c (hwloop_optimize): Insert zero overhead
> loop instruction into new basic block before the loop when basic
> block that precedes the loop is empty.
>
> gcc/testsuite/
> * gcc.target/xtensa/pr91880.c: New test case.
> * gcc.target/xtensa/xtensa.exp: New test suite.
> ---
>  gcc/config/xtensa/xtensa.c |  5 ++--
>  gcc/testsuite/gcc.target/xtensa/pr91880.c  | 10 
>  gcc/testsuite/gcc.target/xtensa/xtensa.exp | 41 
> ++
>  3 files changed, 54 insertions(+), 2 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/xtensa/pr91880.c
>  create mode 100644 gcc/testsuite/gcc.target/xtensa/xtensa.exp

Approved. Thanks.

[Bug preprocessor/49973] Column numbers count multibyte characters as multiple columns

[lhyatt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49973

--- Comment #18 from Lewis Hyatt  ---
(In reply to jos...@codesourcery.com from comment #17)
> On Tue, 17 Sep 2019, lhyatt at gmail dot com wrote:
> 
> > In any case, the underlying source of wcwidth() could easily be changed as a
> > drop-in replacement so I guess it can also be decided later. The use of
> > mbrtowc() is the bigger problem, since this converts from the user's locale 
> > and
> > it needs to convert from what -finput-charset asked for (or else UTF-8)
> > instead.
> 
> If __STDC_ISO_10646__ is defined, wchar_t is Unicode and so local code 
> converting from UTF-8 to wchar_t can be used (together with wcwidth from 
> libc if available).
> 
> If __STDC_ISO_10646__ is not defined, the encoding of wchar_t is unknown.  
> Maybe in that case it's best to avoid libc's wcwidth (if any) and just use 
> a local implementation of wcwidth on the results of converting UTF-8 to 
> Unicode code points.

It seems to erase a lot of complexity just to always use an internal wcwidth(),
so that's what I ended up doing. Patch was posted to
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01558.html for your
consideration. This one just addresses diagnostics, not the input-charset or
user locale conversion stuff. I will submit those separately after this one is
reviewed. Thanks!

[PATCH] Multibyte awareness for diagnostics (PR 49973)

[Lewis Hyatt]

Hello-

PR preprocessor/49973 addresses the fact that the column number in diagnostics
is not correct if the source lines contain multibyte characters. The attached
patch corrects this. The outlines of it were discussed starting here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49973#c13. If it looks OK, could
you please apply it? The patch is a bit large unfortunately, because the column
number was just the tip of the iceberg. There is a lot of machinery in
diagnostic-show-locus.c that also requires multibyte awareness, which I have
done in this patch as well.

A couple notes: 
- In order to avoid any portability problems with wchar_t, the
equivalent of wcwidth() from libc is implemented in-house.

- The diagnostic-show-locus stuff needs to know both the bytes column and
the display column. All location infrastructure (e.g. line-map.h) tracks byte
offsets, so I left that all alone. Rather, diagnostic-show-locus.c just
computes display columns on demand when it needs them.

- In the above-linked PR, Joseph and I also discussed a couple related
fixes that need to be made, namely, when -finput-charset is in use, the
translation needs to be applied when reading source lines for the purpose of
diagnostics printing, which currently it is not, and also, when outputting
diagnostics, the current locale should be inspected to avoid outputting bytes
that the user's terminal cannot display. I have separate patches for these two
as well, but since they are more or less orthogonal to this one, I will submit
them later.

Thank you for your time taking a look at this. It will be nice to clean these
up as part of the support for extended characters in identifiers. I have a
related issue for extended characters also in PR 91843
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91843#c1). I can also submit that
couple-line patch here if it looks OK.

-Lewis
/ChangeLog
2019-09-26  Lewis Hyatt  

PR preprocessor/49973
* contrib/gen_wcwidth.cpp: New standalone utility to generate
libcpp/generated_cpp_wcwidth.h.

libcpp/ChangeLog
2019-09-26  Lewis Hyatt  

PR preprocessor/49973
* generated_cpp_wcwidth.h: New file generated by
contrib/gen_wcwidth.cpp, supports new cpp_wcwidth function.
* charset.c (compute_next_display_width): New function to help
implement display columns.
(cpp_byte_column_to_display_column): Likewise.
(cpp_display_column_to_byte_column): Likewise.
(cpp_wcwidth): Likewise.
* include/cpplib.h (cpp_byte_column_to_display_column): Declare.
(cpp_display_column_to_byte_column): Declare.
(cpp_wcwidth): Declare.
(cpp_display_width): New function.

gcc/ChangeLog
2019-09-26  Lewis Hyatt  

PR preprocessor/49973
* input.c (location_compute_display_column): New function to help with
multibyte awareness in diagnostics.
(test_cpp_utf8): New self-test.
(input_c_tests): Call the new test.
* input.h (location_compute_display_column): Declare.
* diagnostic.c (diagnostic_get_location_text): Use it to output the
correct column number on diagnostics for source lines containing
multibyte characters.
* diagnostic-show-locus.c: Pervasive changes to add multibyte awareness
to all classes and functions.
(class exploc_with_display_col): New class.
(class layout_point): Add m_display_col member.
(layout_point::get_col): New function.
(layout_range::contains_point): Add use_display argument.
(test_layout_range_for_single_point): Pass new argument.
(test_layout_range_for_single_line): Likewise.
(test_layout_range_for_multiple_lines): Likewise.
(line_bounds::convert_to_display_cols): New function.
(layout::get_state_at_point): Add use_display argument.
(class layout): m_exploc changed to exploc_with_display_col from
expanded_location.
(layout::layout): Add multibyte awareness.
(layout::print_source_line): Likewise.
(layout::print_annotation_line): Likewise.
(line_label::line_label): Likewise.
(layout::print_any_labels): Likewise.
(layout::annotation_line_showed_range_p): Likewise.
(get_printed_columns): Likewise.
(get_affected_columns): Rename to...
(get_affected_range): ...this; add use_display argument and multibyte
awareness.
(class correction): Add m_affected_bytes and m_display_cols
members.  Rename m_len to m_bytes for clarity.  Add multibyte awareness.
(correction::insertion_p): Add multibyte awareness.
(correction::compute_display_cols): New function.
(correction::ensure_terminated): m_len renamed to m_bytes.
(line_corrections::add_hint): Add multibyte awareness.
(layout::print_trailing_fixits): Likewise.
(layout::get_x_bound_for_row): Likewise.
(test_one_liner_simple_caret_utf8): 

Re: Reposurgeon status

[Eric S. Raymond]

Joseph Myers :
> On Thu, 26 Sep 2019, Eric S. Raymond wrote:
> 
> > > You might want to update the state of reposurgeon on that page.
> > 
> > I will do so.
> 
> Note that once you've created an account, someone will need to add it to 
> the EditorGroup page before you can edit.

I'm having trouble with basic account creation, actually.  It's to
all appearances not accepting the password I set up. I have sent a 
reset request.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

[Bug target/91903] vec_ctf altivec intrinsic can cause ICE on powerpc

[murphyp at linux dot vnet.ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91903

--- Comment #2 from Paul E. Murphy  ---
I tried this out on IBM's new AT13 compiler (GCC 9.2.1):

/opt/at13.0/bin/powerpc64le-linux-gnu-gcc -c test.c 
during RTL pass: expand
test.c: In function ‘test’:
test.c:5:5: internal compiler error: in copy_to_mode_reg, at explow.c:629
5 | ret = vec_ctf(a,b);
  | ^~
0x735d8b copy_to_mode_reg(machine_mode, rtx_def*)
   
/build/at13.0_RHEL8_x86_64-ppc64le/11/at13.0-0.redhat-8_x86_64_ppc64le/sources/gcc/gcc/explow.c:629
0xca0c21 rs6000_expand_binop_builtin
   
/build/at13.0_RHEL8_x86_64-ppc64le/11/at13.0-0.redhat-8_x86_64_ppc64le/sources/gcc/gcc/config/rs6000/rs6000.c:13787
0xcd0732 rs6000_expand_builtin
   
/build/at13.0_RHEL8_x86_64-ppc64le/11/at13.0-0.redhat-8_x86_64_ppc64le/sources/gcc/gcc/config/rs6000/rs6000.c:16619
0x64158c expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
   
/build/at13.0_RHEL8_x86_64-ppc64le/11/at13.0-0.redhat-8_x86_64_ppc64le/sources/gcc/gcc/builtins.c:7236
0x74c180 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
   
/build/at13.0_RHEL8_x86_64-ppc64le/11/at13.0-0.redhat-8_x86_64_ppc64le/sources/gcc/gcc/expr.c:11030
0x755bca store_expr(tree_node*, rtx_def*, int, bool, bool)
   
/build/at13.0_RHEL8_x86_64-ppc64le/11/at13.0-0.redhat-8_x86_64_ppc64le/sources/gcc/gcc/expr.c:5674
0x756bd0 expand_assignment(tree_node*, tree_node*, bool)
   
/build/at13.0_RHEL8_x86_64-ppc64le/11/at13.0-0.redhat-8_x86_64_ppc64le/sources/gcc/gcc/expr.c:5436
0x660440 expand_call_stmt
   
/build/at13.0_RHEL8_x86_64-ppc64le/11/at13.0-0.redhat-8_x86_64_ppc64le/sources/gcc/gcc/cfgexpand.c:2722
0x660440 expand_gimple_stmt_1
   
/build/at13.0_RHEL8_x86_64-ppc64le/11/at13.0-0.redhat-8_x86_64_ppc64le/sources/gcc/gcc/cfgexpand.c:3691
0x660440 expand_gimple_stmt
   
/build/at13.0_RHEL8_x86_64-ppc64le/11/at13.0-0.redhat-8_x86_64_ppc64le/sources/gcc/gcc/cfgexpand.c:3850
0x6650bf expand_gimple_basic_block
   
/build/at13.0_RHEL8_x86_64-ppc64le/11/at13.0-0.redhat-8_x86_64_ppc64le/sources/gcc/gcc/cfgexpand.c:5890
0x6676d6 execute
   
/build/at13.0_RHEL8_x86_64-ppc64le/11/at13.0-0.redhat-8_x86_64_ppc64le/sources/gcc/gcc/cfgexpand.c:6513
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Re: [Patch, Fortran] CO_BROADCAST for derived types with allocatable components

[Alessandro Fanfarillo]

Hi Paul,
that message was a copy/paste leftover. It doesn't make any sense in
that part of the code, it's now removed.

Committed as revision 276164.

Thanks!


Il giorno dom 15 set 2019 alle ore 12:19 Paul Richard Thomas
 ha scritto:
>
> Hi Sandro,
>
> This patch looks fine to me. I have a question about the comment:
> "This code is obviously added because the finalizer is not trusted to
> free all memory."
> 'obviously'? Not to me :-( Maybe you can expand on this?
>
> As to the stat and errmsg: Leave them for the time being. However, an
> attempt will have to be made to implement F2018 "16.6 Collective
> subroutines". I don't know enough about the coarrays implementation to
> be able to help you about detecting these conditions. Maybe Tobias
> Burnus can help?
>
> OK to commit.
>
> Paul
>
> PS Sometime before very long, something will have to be done about the
> exponential code bloat that structure_alloc_comps. The more users that
> there are for it the tougher it is going to get!
>
> On Thu, 22 Aug 2019 at 18:41, Alessandro Fanfarillo
>  wrote:
> >
> > Dear all,
> > please find in attachment a preliminary patch that adds support to
> > co_broadcast for allocatable components of derived types.
> > The patch is currently ignoring the stat and errmsg arguments, mostly
> > because I am not sure how to handle them properly. I have created a
> > new data structure called used to pass those argument to the
> > preexisting structure_alloc_comps.
> > Suggestions on how to handle them are more than welcome :-)
> >
> > The patch builds correctly on x86_64 and it has been tested with
> > OpenCoarrays and the following test cases:
> >
> > https://github.com/sourceryinstitute/OpenCoarrays/blob/co_broadcast-derived-type/src/tests/unit/collectives/co_broadcast_allocatable_components.f90
> >
> > https://github.com/sourceryinstitute/OpenCoarrays/blob/co_broadcast-derived-type/src/tests/unit/collectives/co_broadcast_allocatable_components_array.f90
> >
> > Regards,
>
>
>
> --
> "If you can't explain it simply, you don't understand it well enough"
> - Albert Einstein

[Bug target/91919] [10 Regression] arm-linux-eabi ICE with building kernel

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91919

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-26
 CC||ktkachov at gcc dot gnu.org,
   ||wilco at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug target/91919] [10 Regression] arm-linux-eabi ICE with building kernel

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91919

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Created attachment 46957
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46957=edit
gcc10-pr91919.patch

I can provide this untested patch that fixes the testcase in a cross-compiler,
but can't easily test it on the trunk.

[Bug target/91829] compatibility.cc: syntax error lea (%pc, _GLOBAL_OFFSET_TABLE@GOTPC), a4 ignored

[forkenmasterforce at keemail dot me]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91829

--- Comment #2 from Jon Daniel  ---
Enabling only the COLDFIRE section in load_got seems to fix the compilation
problem even without a coldfire cpu target.
I'll try to figure out which lea move.l combo to use for a specific motorola
target cpu.

Re: Reposurgeon status

[Joseph Myers]

On Thu, 26 Sep 2019, Eric S. Raymond wrote:

> > You might want to update the state of reposurgeon on that page.
> 
> I will do so.

Note that once you've created an account, someone will need to add it to 
the EditorGroup page before you can edit.

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

[C++ Patch] Improve grokdeclarator error

[Paolo Carlini]

Hi,

over the last weeks, while working on various batches of location 
improvements (a new one is forthcoming, in case you are wondering ;) I 
noticed this grokdeclarator diagnostic, one of those not exercised by 
our testsuite. While constructing a testcase I realized that probably 
it's better to immediately return error_mark_node, and avoid an 
additional redundant error about variable or field declared void or even 
about "fancy" variable templates, depending on the return type of the 
function template. Tested x86_64-linux.


Thanks, Paolo.

//

/cp
2019-09-26  Paolo Carlini  

* decl.c (grokdeclarator): Immediately return error_mark_node
upon error about template-id used as a declarator.

/testsuite
2019-09-26  Paolo Carlini  

* g++.dg/diagnostic/template-id-as-declarator-1.C: New.
Index: testsuite/g++.dg/diagnostic/template-id-as-declarator-1.C
===
--- testsuite/g++.dg/diagnostic/template-id-as-declarator-1.C   (nonexistent)
+++ testsuite/g++.dg/diagnostic/template-id-as-declarator-1.C   (working copy)
@@ -0,0 +1,5 @@
+template
+void foo() {}
+
+template void foo(  // { dg-error "15:template-id .foo. used as a 
declarator" }
+// { dg-error "expected" "" { target *-*-* } .-1 }
Index: cp/decl.c
===
--- cp/decl.c   (revision 276151)
+++ cp/decl.c   (working copy)
@@ -12078,9 +12078,9 @@ grokdeclarator (const cp_declarator *declarator,
   && !FUNC_OR_METHOD_TYPE_P (type)
   && !variable_template_p (TREE_OPERAND (unqualified_id, 0)))
 {
-  error ("template-id %qD used as a declarator",
-unqualified_id);
-  unqualified_id = dname;
+  error_at (id_loc, "template-id %qD used as a declarator",
+   unqualified_id);
+  return error_mark_node;
 }
 
   /* If TYPE is a FUNCTION_TYPE, but the function name was explicitly

[Bug c++/91369] Implement P0784R7: constexpr new

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91369

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #46946|0   |1
is obsolete||

--- Comment #8 from Jakub Jelinek  ---
Created attachment 46956
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46956=edit
gcc10-pr91369.patch

Updated patch.
This patch implements the state if C++ drops the note that trivial destructors
are constexpr destructors.  If on the core reflector you agree on something
else, please let me know and I'll change it.
Other than that, I need to finish up the cookie_size support for array new
(trying to represent that heap object as record with two fields, sizetype array
covering cookie and class_type array covering the rest, but seems indirect ref
folding isn't still happy about that, otherwise I'm out of ideas what else to
test.

Re: [00/32] Support multiple ABIs in the same translation unit

[Dimitar Dimitrov]

On Wed, 11 Sep 2019, 22:02:26 EEST Richard Sandiford wrote:
> The reason for the PRU differences is that the port defines
> targetm.hard_regno_call_part_clobbered, but uses it to test whether
> a multi-register value contains a mixture of fully-clobbered and
> fully-preserved registers.  AFAICT the port doesn't actually have
> individual registers that are partly clobbered, so it doesn't need
> to define the hook.  (I can see how the documentation gave a misleading
> impression though.  I've tried to improve it in one of the patches.)
> The series moves away from testing hard_regno_call_part_clobbered
> directly to testing cached information instead, and the way that the
> cached information is calculated means that defining the hook the way
> the PRU port does has no effect.  In other words, after the series we
> treat it (rightly IMO) as having a "normal" ABI whereas before we didn't.
You are correct. Port does not have partially clobbered HW registers. And 
indeed I was worried about multi-register values.

PRU testsuite showed no regression from trunk with your patch set.

With your patch set, I tried to compare PRU assembly with and without defining 
the targetm.hard_regno_call_part_clobbered hook. There was much noise in 
compare-all-tests due to lto compiler ID strings, but after some filtering I 
think the output assembly was the same.

Thanks,
Dimitar

A bug with -fprofile-dir? Profile directory concatenated with object file path

[Qing Zhao]

Hi,

we noticed that the profile directory will be concatenated with object file 
path.

the following small example explain this behavior:

[qinzhao@localhost small]$ cat t
#! /bin/bash
CC=/home/qinzhao/Install/latest/bin/gcc
opt="-O3 -fprofile-generate"
opt="$opt -fprofile-dir=/home/qinzhao/prof_dir" 
opt="$opt -c -o /home/qinzhao/obj_dir/t.o"
tf="t.c"

echo $CC $opt $tf
$CC $opt $tf
strings /home/qinzhao/obj_dir/t.o | grep prof_dir
[qinzhao@localhost small]$ sh t
/home/qinzhao/Install/latest/bin/gcc -O3 -fprofile-generate 
-fprofile-dir=/home/qinzhao/prof_dir -c -o /home/qinzhao/obj_dir/t.o t.c
/home/qinzhao/prof_dir//home/qinzhao/obj_dir/t.gcda
[qinzhao@localhost small]$ 


From the above, we can see:

when specifying the profiling directory with -fprofile-dir as 
“/home/qinzhao/prof_dir”,  the user expects that the profiling data will 
be stored in this specific directory.  However, GCC concatenates  the profiling 
directory “/home/qinzhao/prof_dir” with the path for the 
object file “/home/qinzhao/obj_dir” together. As a result, the profiling data 
will be stored to:

/home/qinzhao/prof_dir/home/qinzhao/obj_dir/

instead of 

/home/qinzhao/prof_dir

This looks like a bug to me.

any comment for this?

thank you!

Qing

[Bug target/91829] compatibility.cc: syntax error lea (%pc, _GLOBAL_OFFSET_TABLE@GOTPC), a4 ignored

[forkenmasterforce at keemail dot me]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91829

Jon Daniel  changed:

   What|Removed |Added

URL||https://cygwin.com/ml/cross
   ||gcc/2001-10/msg00050.html

--- Comment #1 from Jon Daniel  ---
https://cygwin.com/ml/crossgcc/2001-10/msg00050.html

[Darwin, PPC, Mode Iterators 2/n] Eliminate picbase expanders.

[Iain Sandoe]

Hi Segher,

thanks for the pointers to how to simplify this!

> On 25 Sep 2019, at 00:23, Segher Boessenkool  
> wrote:

> On Tue, Sep 24, 2019 at 08:31:16PM +0100, Iain Sandoe wrote:
>> This switches the picbase load and reload patterns to use the 'P' mode
>> iterator instead of writing an SI and DI pattern for each (and deletes the
>> old patterns).  No functional change intended.
> 
>> (define_expand "load_macho_picbase"
>> -  [(set (reg:SI LR_REGNO)
>> +  [(set (reg LR_REGNO)
> 
> This changes it to VOIDmode instead?  It should have been reg:P LR_REGNO?
> 
>> (define_expand "reload_macho_picbase"
>> -  [(set (reg:SI LR_REGNO)
>> +  [(set (reg LR_REGNO)
> 
> Same here.

As we discussed this is symptomatic of the fact that the expanders only exist 
in this
to pass the mode through.

We can eliminate them completely by using an “@pattern” in the actual
patterns (and updating callers to pass the mode as the first argument).

tested on powerpc-darwin9, powerpc64-linux-gnu (m32, m64)
applied to mainline,
thanks
Iain

gcc/ChangeLog:

2019-09-26  Iain Sandoe  

* config/rs6000/darwin.md: Replace the expanders for
load_macho_picbase and reload_macho_picbase with use of '@'
in their respective define_insns.
(nonlocal_goto_receiver): Pass Pmode to gen_reload_macho_picbase.
* config/rs6000/rs6000-logue.c (rs6000_emit_prologue): Pass
Pmode to gen_load_macho_picbase.
* config/rs6000/rs6000.md: Likewise.

diff --git a/gcc/config/rs6000/darwin.md b/gcc/config/rs6000/darwin.md
index 4a284211af..a5c5a3af39 100644
--- a/gcc/config/rs6000/darwin.md
+++ b/gcc/config/rs6000/darwin.md
@@ -216,21 +216,7 @@ You should have received a copy of the GNU General Public 
License
(match_dup 2))]
   "")
 
-(define_expand "load_macho_picbase"
-  [(set (reg LR_REGNO)
-(unspec [(match_operand 0 "")]
-   UNSPEC_LD_MPIC))]
-  "(DEFAULT_ABI == ABI_DARWIN) && flag_pic"
-{
-  if (TARGET_32BIT)
-emit_insn (gen_load_macho_picbase_si (operands[0]));
-  else
-emit_insn (gen_load_macho_picbase_di (operands[0]));
-
-  DONE;
-})
-
-(define_insn "load_macho_picbase_"
+(define_insn "@load_macho_picbase_"
   [(set (reg:P LR_REGNO)
(unspec:P [(match_operand:P 0 "immediate_operand" "s")
(pc)] UNSPEC_LD_MPIC))]
@@ -284,21 +270,7 @@ You should have received a copy of the GNU General Public 
License
   "addis %0,%1,ha16(%2-%3)\n\taddi %0,%0,lo16(%2-%3)"
   [(set_attr "length" "8")])
 
-(define_expand "reload_macho_picbase"
-  [(set (reg LR_REGNO)
-(unspec [(match_operand 0 "")]
-   UNSPEC_RELD_MPIC))]
-  "(DEFAULT_ABI == ABI_DARWIN) && flag_pic"
-{
-  if (TARGET_32BIT)
-emit_insn (gen_reload_macho_picbase_si (operands[0]));
-  else
-emit_insn (gen_reload_macho_picbase_di (operands[0]));
-
-  DONE;
-})
-
-(define_insn "reload_macho_picbase_"
+(define_insn "@reload_macho_picbase_"
   [(set (reg:P LR_REGNO)
 (unspec:P [(match_operand:P 0 "immediate_operand" "s")
(pc)] UNSPEC_RELD_MPIC))]
@@ -342,7 +314,7 @@ You should have received a copy of the GNU General Public 
License
   ASM_GENERATE_INTERNAL_LABEL(tmplab, "Lnlgr", ++n);
   tmplrtx = gen_rtx_SYMBOL_REF (Pmode, ggc_strdup (tmplab));
 
-  emit_insn (gen_reload_macho_picbase (tmplrtx));
+  emit_insn (gen_reload_macho_picbase (Pmode, tmplrtx));
   emit_move_insn (picreg, gen_rtx_REG (Pmode, LR_REGNO));
   emit_insn (gen_macho_correct_pic (picreg, picreg, picrtx, tmplrtx));
 }
diff --git a/gcc/config/rs6000/rs6000-logue.c b/gcc/config/rs6000/rs6000-logue.c
index 633a253e43..e98893a440 100644
--- a/gcc/config/rs6000/rs6000-logue.c
+++ b/gcc/config/rs6000/rs6000-logue.c
@@ -3809,7 +3809,7 @@ rs6000_emit_prologue (void)
   if (!info->lr_save_p)
emit_move_insn (gen_rtx_REG (Pmode, 0), lr);
 
-  emit_insn (gen_load_macho_picbase (src));
+  emit_insn (gen_load_macho_picbase (Pmode, src));
 
   emit_move_insn (gen_rtx_REG (Pmode,
   RS6000_PIC_OFFSET_TABLE_REGNUM),
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 4dbf85bbc9..c5443bab9e 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -10053,7 +10053,7 @@
  CODE_LABEL_NUMBER (operands[0]));
   tmplabrtx = gen_rtx_SYMBOL_REF (Pmode, ggc_strdup (tmplab));
 
-  emit_insn (gen_load_macho_picbase (tmplabrtx));
+  emit_insn (gen_load_macho_picbase (Pmode, tmplabrtx));
   emit_move_insn (picreg, gen_rtx_REG (Pmode, LR_REGNO));
   emit_insn (gen_macho_correct_pic (picreg, picreg, picrtx, tmplabrtx));
 }

Re: Moving to C++11

[Richard Sandiford]

Tom Tromey  writes:
>> "Jason" == Jason Merrill  writes:
>
> Jason> Note that std::move is from C++11.
>
>>> I'm not too worried about requiring even a C++14 compiler, for the
>>> set of products we still release latest compilers we have newer
>>> GCCs available we can use for building them (even if those are
>>> not our primary supported compilers which would limit us to
>>> GCC 4.8).
>
> Jason> I wouldn't object to C++14, but there's nothing in there I
> Jason> particularly want to use, so it seems unnecessary.
>
>>> Note I'd still not like to see more C++ feature creep into general
>>> non-container/infrastructure code, C++ is complex enough as-is.
>
> Jason> I agree for rvalue references.  I want to start using C++11 'auto' in
> Jason> local variable declarations.
>
> FWIW in gdb we went with C++11, because it was the version that offered
> the most useful upgrades -- for me those was mainly move and foreach,
> but 'auto' is sometimes nice as well.

FWIW, on top of what's already been mentioned:

- "= default" would be very useful for some of the core types

- explicit conversion operators would avoid dangerous implicit conversions
  to things like bool.  E.g. it should be safe to provide an explicit
  operator bool() for poly_int and avoid those pesky known_eq (..., 0)/
  maybe_ne (..., 0) conditions

- templated type aliases would simplify wide_int

Richard

Re: Reposurgeon status

[Eric S. Raymond]

Jeff Law :
> Probably the most important thing to know is the project will make a
> decision on Dec 16 to choose the conversion tool.  The evaluation is
> based on the state of tool's conversion on that date.  More details:
> 
> > https://gcc.gnu.org/wiki/GitConversion
> 
> You should consider the dates in there as firm.

I think it is extremely likely that I will have a final conversion ready by 
then.

The only known problem that is in any way serious is the x-bit
propagation bug, and I may already have fixed that. I'd think I'd have
to get blindsided by something much larger to miss that deadline.

> You might want to update the state of reposurgeon on that page.

I will do so.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

Re: Moving to C++11

[Tom Tromey]

> "Jason" == Jason Merrill  writes:

Jason> Note that std::move is from C++11.

>> I'm not too worried about requiring even a C++14 compiler, for the
>> set of products we still release latest compilers we have newer
>> GCCs available we can use for building them (even if those are
>> not our primary supported compilers which would limit us to
>> GCC 4.8).

Jason> I wouldn't object to C++14, but there's nothing in there I
Jason> particularly want to use, so it seems unnecessary.

>> Note I'd still not like to see more C++ feature creep into general
>> non-container/infrastructure code, C++ is complex enough as-is.

Jason> I agree for rvalue references.  I want to start using C++11 'auto' in
Jason> local variable declarations.

FWIW in gdb we went with C++11, because it was the version that offered
the most useful upgrades -- for me those was mainly move and foreach,
but 'auto' is sometimes nice as well.

Tom

Re: Problem exposed by recent ARM multiply changes

[Paul Koning]

> On Sep 26, 2019, at 12:01 PM, Jeff Law  wrote:
> 
> On 9/26/19 9:47 AM, Jakub Jelinek wrote:
>> On Thu, Sep 26, 2019 at 09:39:31AM -0600, Jeff Law wrote:
>>> Right.  My point is that the multiplication patterns are an exception as
>>> well.
>> 
>> Do you have some evidence for that? 
> It's in the manual.  And yes it potentially makes a huge mess due to the
> interactions with modeless CONST_INTs.

Do you mean things like "mulhisi3"?

That's a pattern for a multiplication whose output is longer than its inputs.  
But the RTL it builds has a regular mult insn with equal length operands (all 
SImode in this example), with sign_extend insns in the mult source operands.  
So I don't believe that contradicts what Jakub said.

paul

[Bug c++/91921] Incomplete -Woverloaded-virtual warning when base class is in system header

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91921

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

--- Comment #2 from Marek Polacek  ---
Looks trivial.

[Bug c++/91921] Incomplete -Woverloaded-virtual warning when base class is in system header

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91921

Marek Polacek  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-26
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c++/91921] New: Incomplete -Woverloaded-virtual warning when base class is in system header

[andrey.vihrov at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91921

Bug ID: 91921
   Summary: Incomplete -Woverloaded-virtual warning when base
class is in system header
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrey.vihrov at gmail dot com
  Target Milestone: ---

Compiling the following preprocessed source:

  # 1 "foo.h" 3
  struct A
  {
virtual void f();
  };

  # 1 "bar.h"
  struct B : A
  {
void f(int);
  };

with "g++ -c test.ii -Woverloaded-virtual" gives

  bar.h:3:8: warning:   by 'void B::f(int)' [-Woverloaded-virtual]

The first part of the warning is missing.

Re: Moving to C++11

[Jason Merrill]

On Thu, Sep 26, 2019 at 4:08 AM Richard Biener
 wrote:
> On Thu, Sep 26, 2019 at 9:23 AM Jonathan Wakely  wrote:
> > On Thu, 26 Sep 2019, 05:10 Nicholas Krause,  wrote:
> > >
> > > Greetings,
> > >
> > > I asked about moving to C/C++ 11 as it would make it easier to
> > >
> > > allow multithreading support due to having a memory model
> > >
> > > alongside other features. Jason Merill mentioned due to it
> > >
> > > being so common it may be a good  time to.
> > >
> > > Moving to git seems to be universally agree on so I'm opening the 
> > > discussion
> > >
> > > for the same as related to C/C++11 migration and if possible opening
> > >
> > > a TODO similar to git if decided on.
> > >
> > > Please post your comments or ideas about the migration in response to this
> > >
> > > email,
> >
> >
> >
> > For a start, it doesn't make sense to talk about C/C++11.
> >
> > C and C++ are separate languages, and so are C11 and C++11. There is
> > no reason why using C++11 should imply using C11, let's not confuse
> > things.
> >
> > GCC is written in C++ so the topic should be C++11.
>
> Note the main issue is host compiler support.  I'm not sure if C++11 would
> be the step we'd gain most - for some hashtable issues I'd have needed
> std::move support for example.  There's always the possibility to
> require an intermediate step (first build GCC 5, with that you can build
> trunk, etc.), a install.texi clarification could be useful here (or even
> some automation via a contrib/ script).

Note that std::move is from C++11.

> I'm not too worried about requiring even a C++14 compiler, for the
> set of products we still release latest compilers we have newer
> GCCs available we can use for building them (even if those are
> not our primary supported compilers which would limit us to
> GCC 4.8).

I wouldn't object to C++14, but there's nothing in there I
particularly want to use, so it seems unnecessary.

> Note I'd still not like to see more C++ feature creep into general
> non-container/infrastructure code, C++ is complex enough as-is.

I agree for rvalue references.  I want to start using C++11 'auto' in
local variable declarations.

Jason

[Bug target/87243] FSF GCC needs to do something special (like using xcrun) on darwin18 to find system headers in SDK

[ken.cunningham.webuse at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87243

Ken Cunningham  changed:

   What|Removed |Added

 CC||ken.cunningham.webuse@gmail
   ||.com

--- Comment #6 from Ken Cunningham  ---
I would suggest that, if not using xcrun (which I understand completely), then
some replication of the logic it uses in darwin's driver would make sense.

An knowledgeable person explained this to me regarding how xcrun finds the SDK:

If -isysroot is on the command line, it is used. Otherwise ...
If system headers are installed, they are used (no sysroot is set). Otherwise
...
If xcrun finds a major-version matching SDK in the selected in
/Library/Developer/SDKs, it will use it. Otherwise ...
If xcrun finds a macosx SDK in the selected Xcode.app or in
/Library/Developer/SDKs, it will use it.
xcrun does not explicitly set the command line arguments. It sets the SDKROOT
envvar, which CFE honors as the default isysroot if set.


This was later updated to change the SDK search path to
/Library/Developer/CommandLineTools/SDKs, which is the one that is working now
on 10.14.

The only thing I would add to that would be that it would probably be quite
desirable to have ${SDKROOT} respected if it has been set by the user, so a
specific SDK can be forced globally.

The way the CFE then uses the ${SDKROOT} internally is here:

https://clang.llvm.org/doxygen/Darwin_8cpp_source.html

Re: [PATCH, rs6000] Update powerpc vector load builtins with PURE attribute

[Segher Boessenkool]

On Thu, Sep 26, 2019 at 12:06:03PM -0500, Bill Schmidt wrote:
> On 9/26/19 12:00 PM, Segher Boessenkool wrote:
> >On Thu, Sep 26, 2019 at 10:40:29AM -0500, will schmidt wrote:
> >>Update our (rs6000) vector load built-ins with the PURE attribute.  These
> >>were previously given the MEM attribute, which meant that redundant loads
> >>surrounding the built-in calls could not be eliminated in earlier passes
> >>since they were defined as having the potential to touch memory.
> >>2019-09-26  Will Schmidt 
> >>* config/rs6000/rs6000-builtin.def: ( LVSL LVSR LVEBX LVEHX
> >  ^--- stray space
> >
> >Please put commas between the items, too?
> >
> >The patch is okay for trunk.  Thank you!
> >
> I wonder whether we should also consider a backport to 9, when we 
> started expanding these earlier.  Thoughts?

Good idea, yeah.  After waiting for a week or so to see if problems turn
up on trunk, as usual.


Segher

Re: [PATCH, rs6000] Update powerpc vector load builtins with PURE attribute

[Bill Schmidt]

On 9/26/19 12:00 PM, Segher Boessenkool wrote:

Hi Will,

On Thu, Sep 26, 2019 at 10:40:29AM -0500, will schmidt wrote:

Update our (rs6000) vector load built-ins with the PURE attribute.  These
were previously given the MEM attribute, which meant that redundant loads
surrounding the built-in calls could not be eliminated in earlier passes
since they were defined as having the potential to touch memory.
2019-09-26  Will Schmidt 
* config/rs6000/rs6000-builtin.def: ( LVSL LVSR LVEBX LVEHX

  ^--- stray space

Please put commas between the items, too?

The patch is okay for trunk.  Thank you!

I wonder whether we should also consider a backport to 9, when we 
started expanding these earlier.  Thoughts?


Bill


Segher

Re: [PATCH, rs6000] Update powerpc vector load builtins with PURE attribute

[Segher Boessenkool]

Hi Will,

On Thu, Sep 26, 2019 at 10:40:29AM -0500, will schmidt wrote:
> Update our (rs6000) vector load built-ins with the PURE attribute.  These
> were previously given the MEM attribute, which meant that redundant loads
> surrounding the built-in calls could not be eliminated in earlier passes
> since they were defined as having the potential to touch memory.

> 2019-09-26  Will Schmidt 
>   * config/rs6000/rs6000-builtin.def: ( LVSL LVSR LVEBX LVEHX
 ^--- stray space

Please put commas between the items, too?

The patch is okay for trunk.  Thank you!


Segher

[Bug target/91897] Very poor optimization on large attribute vector_size

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91897

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||10.0
 Resolution|--- |FIXED

--- Comment #5 from Richard Biener  ---
Fixed on trunk.

[Bug tree-optimization/91896] [10 Regression] ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1687

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91896

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Thu Sep 26 16:54:51 2019
New Revision: 276158

URL: https://gcc.gnu.org/viewcvs?rev=276158=gcc=rev
Log:
2019-09-25  Richard Biener  

PR tree-optimization/91896
* tree-vect-loop.c (vectorizable_reduction): The single
def-use cycle optimization cannot apply when there's more
than one pattern stmt involved.

* gcc.dg/torture/pr91896.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr91897.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/testsuite/ChangeLog

[PATCH] Split out nested cycle loop-closed PHI vectorization

[Richard Biener]

Bootstrapped / tested on x86_64-unknown-linux-gnu, applied.

Richard.

2019-09-26  Richard Biener  

* tree-vect-loop.c (vect_analyze_loop_operations): Analyze
loop-closed PHIs that are vect_internal_def.
(vect_create_epilog_for_reduction): Exit early for nested cycles.
Simplify.
(vectorizable_lc_phi): New.
* tree-vect-stmts.c (vect_analyze_stmt): Call vectorize_lc_phi.
(vect_transform_stmt): Likewise.
* tree-vectorizer.h (stmt_vec_info_type): Add lc_phi_info_type.
(vectorizable_lc_phi): Declare.

Index: gcc/tree-vect-loop.c
===
--- gcc/tree-vect-loop.c(revision 276156)
+++ gcc/tree-vect-loop.c(working copy)
@@ -1519,12 +1519,16 @@ vect_analyze_loop_operations (loop_vec_i
   phi_op = PHI_ARG_DEF (phi, 0);
  stmt_vec_info op_def_info = loop_vinfo->lookup_def (phi_op);
  if (!op_def_info)
-   return opt_result::failure_at (phi, "unsupported phi");
+   return opt_result::failure_at (phi, "unsupported phi\n");
 
  if (STMT_VINFO_RELEVANT (op_def_info) != vect_used_in_outer
  && (STMT_VINFO_RELEVANT (op_def_info)
  != vect_used_in_outer_by_reduction))
-   return opt_result::failure_at (phi, "unsupported phi");
+   return opt_result::failure_at (phi, "unsupported phi\n");
+
+ if (STMT_VINFO_DEF_TYPE (stmt_info) == vect_internal_def
+ && !vectorizable_lc_phi (stmt_info, NULL, NULL))
+   return opt_result::failure_at (phi, "unsupported phi\n");
 }
 
   continue;
@@ -4396,6 +4400,10 @@ vect_create_epilog_for_reduction (vec
  # b1 = phi 
@@ -5313,7 +5311,6 @@ vect_create_epilog_for_reduction (vecinner;
@@ -5473,7 +5470,7 @@ vect_create_epilog_for_reduction (vec (stmt_info->stmt)
+  || gimple_phi_num_args (stmt_info->stmt) != 1)
+return false;
+
+  /* To handle the nested_cycle_def for double-reductions we have to
+ refactor epilogue generation more.  */
+  if (STMT_VINFO_DEF_TYPE (stmt_info) != vect_internal_def
+  /* && STMT_VINFO_DEF_TYPE (stmt_info) != vect_double_reduction_def */)
+return false;
+
+  if (!vec_stmt) /* transformation not required.  */
+{
+  STMT_VINFO_TYPE (stmt_info) = lc_phi_info_type;
+  return true;
+}
+
+  tree vectype = STMT_VINFO_VECTYPE (stmt_info);
+  tree scalar_dest = gimple_phi_result (stmt_info->stmt);
+  basic_block bb = gimple_bb (stmt_info->stmt);
+  edge e = single_pred_edge (bb);
+  tree vec_dest = vect_create_destination_var (scalar_dest, vectype);
+  vec vec_oprnds = vNULL;
+  vect_get_vec_defs (gimple_phi_arg_def (stmt_info->stmt, 0), NULL_TREE,
+stmt_info, _oprnds, NULL, slp_node);
+  if (slp_node)
+{
+  unsigned vec_num = SLP_TREE_NUMBER_OF_VEC_STMTS (slp_node);
+  gcc_assert (vec_oprnds.length () == vec_num);
+  for (unsigned i = 0; i < vec_num; i++)
+   {
+ /* Create the vectorized LC PHI node.  */
+ gphi *new_phi = create_phi_node (vec_dest, bb);
+ add_phi_arg (new_phi, vec_oprnds[i], e, UNKNOWN_LOCATION);
+ stmt_vec_info new_phi_info = loop_vinfo->add_stmt (new_phi);
+ SLP_TREE_VEC_STMTS (slp_node).quick_push (new_phi_info);
+   }
+}
+  else
+{
+  unsigned ncopies = vect_get_num_copies (loop_vinfo, vectype);
+  stmt_vec_info prev_phi_info = NULL;
+  for (unsigned i = 0; i < ncopies; i++)
+   {
+ if (i != 0)
+   vect_get_vec_defs_for_stmt_copy (loop_vinfo, _oprnds, NULL);
+ /* Create the vectorized LC PHI node.  */
+ gphi *new_phi = create_phi_node (vec_dest, bb);
+ add_phi_arg (new_phi, vec_oprnds[0], e, UNKNOWN_LOCATION);
+ stmt_vec_info new_phi_info = loop_vinfo->add_stmt (new_phi);
+ if (i == 0)
+   STMT_VINFO_VEC_STMT (stmt_info) = *vec_stmt = new_phi_info;
+ else
+   STMT_VINFO_RELATED_STMT (prev_phi_info) = new_phi_info;
+ prev_phi_info = new_phi_info;
+   }
+}
+  vec_oprnds.release ();
+
+  return true;
+}
+
+
 /* Function vect_min_worthwhile_factor.
 
For a loop where we could vectorize the operation indicated by CODE,
@@ -8399,7 +8466,8 @@ vect_transform_loop (loop_vec_info loop_
  if ((STMT_VINFO_DEF_TYPE (stmt_info) == vect_induction_def
   || STMT_VINFO_DEF_TYPE (stmt_info) == vect_reduction_def
   || STMT_VINFO_DEF_TYPE (stmt_info) == vect_double_reduction_def
-  || STMT_VINFO_DEF_TYPE (stmt_info) == vect_nested_cycle)
+  || STMT_VINFO_DEF_TYPE (stmt_info) == vect_nested_cycle
+  || STMT_VINFO_DEF_TYPE (stmt_info) == vect_internal_def)
  && ! PURE_SLP_STMT (stmt_info))
{
  if (dump_enabled_p ())
Index: 

Re: Moving to C++11

[Nicholas Krause]

On 9/26/19 4:08 AM, Richard Biener wrote:

On Thu, Sep 26, 2019 at 9:23 AM Jonathan Wakely  wrote:

On Thu, 26 Sep 2019, 05:10 Nicholas Krause,  wrote:

Greetings,

I asked about moving to C/C++ 11 as it would make it easier to

allow multithreading support due to having a memory model

alongside other features. Jason Merill mentioned due to it

being so common it may be a good  time to.

Moving to git seems to be universally agree on so I'm opening the discussion

for the same as related to C/C++11 migration and if possible opening

a TODO similar to git if decided on.

Please post your comments or ideas about the migration in response to this

email,



For a start, it doesn't make sense to talk about C/C++11.

C and C++ are separate languages, and so are C11 and C++11. There is
no reason why using C++11 should imply using C11, let's not confuse
things.

GCC is written in C++ so the topic should be C++11.

Note the main issue is host compiler support.  I'm not sure if C++11 would
be the step we'd gain most - for some hashtable issues I'd have needed
std::move support for example.  There's always the possibility to
require an intermediate step (first build GCC 5, with that you can build
trunk, etc.), a install.texi clarification could be useful here (or even
some automation via a contrib/ script).

I agree.


I'm not too worried about requiring even a C++14 compiler, for the
set of products we still release latest compilers we have newer
GCCs available we can use for building them (even if those are
not our primary supported compilers which would limit us to
GCC 4.8).
Note I'd still not like to see more C++ feature creep into general
non-container/infrastructure code, C++ is complex enough as-is.


While the features that  seem to be the most useful to use I will

list below:

1. C++ memory model and atomics classes

2. Move and R values

3. Auto?

4. For each loops may be nice i.e. x: array loops through all of the array

To your point it seems that the above are the most useful and we can

just avoid the others as these don't really affect core code and even

if they do its an extension rather of older features. Auto is just

templates for variables really.

Nick




Richard.

[Bug c/91920] ggc 9.2.0 failing openmp compile on ppc64le

[gcc at octaforge dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91920

Daniel Kolesa  changed:

   What|Removed |Added

 CC||gcc at octaforge dot org

--- Comment #2 from Daniel Kolesa  ---
confirmed, same here

[Bug c/91920] ggc 9.2.0 failing openmp compile on ppc64le

[robert at robbieab dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91920

--- Comment #1 from robert at robbieab dot com ---
Created attachment 46955
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46955=edit
Preprocessed copy of test-openmp.c

[Bug c/91920] New: ggc 9.2.0 failing openmp compile on ppc64le

[robert at robbieab dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91920

Bug ID: 91920
   Summary: ggc 9.2.0 failing openmp compile on ppc64le
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: robert at robbieab dot com
  Target Milestone: ---

Created attachment 46954
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46954=edit
The minimal test-case C file i used.

Compiling the attached program with "gcc -fopenmp" failes with the following
error on my ppc64le platform:
---
$ gcc -fopenmp test-openmp.c 
test-openmp.c: In function ‘testfunc’:
test-openmp.c:10:15: error: ‘*.LC0’ not specified in enclosing ‘parallel’
   10 | float k[3] = { 0.1f, 0.1f, 0.1f } ;
  |   ^
test-openmp.c:7:9: error: enclosing ‘parallel’
7 | #pragma omp parallel for default(none) shared(f)
  | ^~~
---

This errors does not appear if the 0.1f values are replaced with 0.0f in the
k[3] array.

gcc details:
---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/powerpc64le-unknown-linux-gnu/9.2.0/lto-wrapper
Target: powerpc64le-unknown-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-9.2.0-r1/work/gcc-9.2.0/configure
--host=powerpc64le-unknown-linux-gnu --build=powerpc64le-unknown-linux-gnu
--prefix=/usr --bindir=/usr/powerpc64le-unknown-linux-gnu/gcc-bin/9.2.0
--includedir=/usr/lib/gcc/powerpc64le-unknown-linux-gnu/9.2.0/include
--datadir=/usr/share/gcc-data/powerpc64le-unknown-linux-gnu/9.2.0
--mandir=/usr/share/gcc-data/powerpc64le-unknown-linux-gnu/9.2.0/man
--infodir=/usr/share/gcc-data/powerpc64le-unknown-linux-gnu/9.2.0/info
--with-gxx-include-dir=/usr/lib/gcc/powerpc64le-unknown-linux-gnu/9.2.0/include/g++-v9
--with-python-dir=/share/gcc-data/powerpc64le-unknown-linux-gnu/9.2.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 9.2.0-r1 p2' --disable-esp --enable-libstdcxx-time
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --disable-multilib --enable-altivec --disable-fixed-point
--enable-targets=all --enable-libgomp --disable-libmudflap --disable-libssp
--disable-systemtap --disable-vtable-verify --disable-libvtv --enable-lto
--with-isl --disable-isl-version-check --enable-default-pie
--enable-default-ssp
Thread model: posix
gcc version 9.2.0 (Gentoo 9.2.0-r1 p2) 
---

This problem does not appear to happen on my x86_64 system.

[Bug libgomp/91917] OpenACC 'acc_set_cuda_stream' return type

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91917

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-26
 Ever confirmed|0   |1

--- Comment #1 from Thomas Schwinge  ---
Jakub confirmed:

| I'm not aware of any target that supports OpenMP/OpenACC that would
| have different calling conventions between something that returns int and
| void if the return value is ignored.
| So, if OpenACC standard changes it, no concern.

Re: [PATCH] PR libstdc++/91910 fix data race in Debug Mode destructors

[Jonathan Wakely]

On 26/09/19 14:20 +0100, Jonathan Wakely wrote:

Fix data race when _Safe_iterator_base::_M_detach() runs concurrently with
the _Safe_container_base destructor.

PR libstdc++/91910
* src/c++11/debug.cc (_Safe_iterator_base::_M_detach()): Load pointer
atomically and lock the mutex before accessing the sequence.
(_Safe_iterator_base::_M_reset()): Clear _M_sequence atomically.

Tested x86_64-linux. I plan to commit this to trunk unless somebody
sees a problem with it.


We need the same change in the _Safe_local_iterator_base::_M_detach()
function, as in this new patch.


commit 3ec426b2f46e65eb6e4ce7ec05863a6f9c05dffc
Author: Jonathan Wakely 
Date:   Thu Sep 26 13:08:48 2019 +0100

PR libstdc++/91910 fix data race in Debug Mode destructors

Fix data race when _Safe_iterator_base::_M_detach() runs concurrently with
the _Safe_container_base destructor.

PR libstdc++/91910
* src/c++11/debug.cc (_Safe_iterator_base::_M_detach()): Load pointer
atomically and lock the mutex before accessing the sequence.
(_Safe_local_iterator_base::_M_detach()): Likewise.
(_Safe_iterator_base::_M_reset()): Clear _M_sequence atomically.

diff --git a/libstdc++-v3/src/c++11/debug.cc b/libstdc++-v3/src/c++11/debug.cc
index f5a49992efa..efd1a9e0254 100644
--- a/libstdc++-v3/src/c++11/debug.cc
+++ b/libstdc++-v3/src/c++11/debug.cc
@@ -381,10 +381,17 @@ namespace __gnu_debug
   _Safe_iterator_base::
   _M_detach()
   {
-if (_M_sequence)
+// This function can run concurrently with the sequence destructor,
+// so there is a TOCTTOU race here: the sequence could be destroyed
+// after we check that _M_sequence is not null. Use the pointer value
+// to acquire the mutex (rather than via _M_sequence->_M_get_mutex()).
+// If the sequence destructor runs between loading the pointer and
+// locking the mutex, it will detach this iterator and set _M_sequence
+// to null, and then _M_detach_single() will do nothing.
+if (auto seq = __atomic_load_n(&_M_sequence, __ATOMIC_ACQUIRE))
   {
-	_M_sequence->_M_detach(this);
-	_M_reset();
+	__gnu_cxx::__scoped_lock sentry(get_safe_base_mutex(seq));
+	_M_detach_single();
   }
   }
 
@@ -403,7 +410,7 @@ namespace __gnu_debug
   _Safe_iterator_base::
   _M_reset() throw ()
   {
-_M_sequence = 0;
+__atomic_store_n(&_M_sequence, (_Safe_sequence_base*)0, __ATOMIC_RELEASE);
 _M_version = 0;
 _M_prior = 0;
 _M_next = 0;
@@ -466,10 +473,10 @@ namespace __gnu_debug
   _Safe_local_iterator_base::
   _M_detach()
   {
-if (_M_sequence)
+if (auto seq = __atomic_load_n(&_M_sequence, __ATOMIC_ACQUIRE))
   {
-	_M_get_container()->_M_detach_local(this);
-	_M_reset();
+	__gnu_cxx::__scoped_lock sentry(get_safe_base_mutex(seq));
+	_M_detach_single();
   }
   }
 

[Bug tree-optimization/91914] [9 Regression] Invalid strlen optimization

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91914

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Thu Sep 26 16:17:22 2019
New Revision: 276156

URL: https://gcc.gnu.org/viewcvs?rev=276156=gcc=rev
Log:
PR tree-optimization/91914 - Invalid strlen folding for offset into struct

gcc/testsuite/CHangeLog:
* gcc.dg/strlenopt-79.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/strlenopt-79.c
Modified:
trunk/gcc/testsuite/ChangeLog

[PATCH] Define std::to_array for Debug Mode

[Jonathan Wakely]

* include/debug/array (to_array): Define for debug mode.

Tested x86_64-linux, committed to trunk.

commit 6404cc56a2e300ffcf5f680f0728e695539a137a
Author: Jonathan Wakely 
Date:   Thu Sep 26 15:50:30 2019 +0100

Define std::to_array for Debug Mode

* include/debug/array (to_array): Define for debug mode.

diff --git a/libstdc++-v3/include/debug/array b/libstdc++-v3/include/debug/array
index 9e94e656c04..2f8eb842eb8 100644
--- a/libstdc++-v3/include/debug/array
+++ b/libstdc++-v3/include/debug/array
@@ -314,6 +314,45 @@ namespace __debug
   static_assert(_Int < _Nm, "index is out of bounds");
   return std::move(__debug::get<_Int>(__arr));
 }
+
+#if __cplusplus > 201703L
+#define __cpp_lib_to_array 201907L
+
+  template
+constexpr array, sizeof...(_Idx)>
+__to_array(_Tp (&__a)[sizeof...(_Idx)], index_sequence<_Idx...>)
+{
+  if constexpr (_Move)
+   return {{std::move(__a[_Idx])...}};
+  else
+   return {{__a[_Idx]...}};
+}
+
+  template
+constexpr array, _Nm>
+to_array(_Tp (&__a)[_Nm])
+noexcept(is_nothrow_constructible_v<_Tp, _Tp&>)
+{
+  static_assert(!is_array_v<_Tp>);
+  static_assert(is_constructible_v<_Tp, _Tp&>);
+  if constexpr (is_constructible_v<_Tp, _Tp&>)
+   return __debug::__to_array(__a, make_index_sequence<_Nm>{});
+  __builtin_unreachable(); // FIXME: see PR c++/91388
+}
+
+  template
+constexpr array, _Nm>
+to_array(_Tp (&&__a)[_Nm])
+noexcept(is_nothrow_move_constructible_v<_Tp>)
+{
+  static_assert(!is_array_v<_Tp>);
+  static_assert(is_move_constructible_v<_Tp>);
+  if constexpr (is_move_constructible_v<_Tp>)
+   return __debug::__to_array<1>(__a, make_index_sequence<_Nm>{});
+  __builtin_unreachable(); // FIXME: see PR c++/91388
+}
+#endif // C++20
+
 } // namespace __debug
 
 _GLIBCXX_BEGIN_NAMESPACE_VERSION

[PATCH] Implement C++20 constexpr changes to std::pair (P1032R1)

[Jonathan Wakely]

* include/bits/stl_pair.h (pair): Add _GLIBCXX20_CONSTEXPR to
piecewise construction constructor, assignment operators, and swap.
* include/std/tuple (pair::pair(piecewise_construct_t, tuple, tuple)):
Add _GLIBCXX20_CONSTEXPR.
(pair::pair(tuple, tuple, _Index_tuple, _Index_tuple)): Likewise.
* testsuite/20_util/pair/constexpr_assign.cc: New test.
* testsuite/20_util/pair/constexpr_swap.cc: New test.

There are still more pieces of P1032R1 that need to be implemented,
including (at least) the std::tuple bits.

Tested x86_64-linux, committed to trunk.
commit 30fc6a7e208ba88bd874145fc9a1570862964a5f
Author: Jonathan Wakely 
Date:   Thu Sep 26 15:42:10 2019 +0100

Implement C++20 constexpr changes to std::pair (P1032R1)

* include/bits/stl_pair.h (pair): Add _GLIBCXX20_CONSTEXPR to
piecewise construction constructor, assignment operators, and swap.
* include/std/tuple (pair::pair(piecewise_construct_t, tuple, 
tuple)):
Add _GLIBCXX20_CONSTEXPR.
(pair::pair(tuple, tuple, _Index_tuple, _Index_tuple)): Likewise.
* testsuite/20_util/pair/constexpr_assign.cc: New test.
* testsuite/20_util/pair/constexpr_swap.cc: New test.

diff --git a/libstdc++-v3/include/bits/stl_pair.h 
b/libstdc++-v3/include/bits/stl_pair.h
index c04f169bb6c..f7ad1696545 100644
--- a/libstdc++-v3/include/bits/stl_pair.h
+++ b/libstdc++-v3/include/bits/stl_pair.h
@@ -380,9 +380,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  second(std::forward<_U2>(__p.second)) { }
 
   template
+   _GLIBCXX20_CONSTEXPR
 pair(piecewise_construct_t, tuple<_Args1...>, tuple<_Args2...>);
 
-  pair&
+  _GLIBCXX20_CONSTEXPR pair&
   operator=(typename conditional<
__and_,
   is_copy_assignable<_T2>>::value,
@@ -393,7 +394,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
return *this;
   }
 
-  pair&
+  _GLIBCXX20_CONSTEXPR pair&
   operator=(typename conditional<
__and_,
   is_move_assignable<_T2>>::value,
@@ -407,9 +408,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   }
 
   template
-  typename enable_if<__and_,
-   is_assignable<_T2&, const _U2&>>::value,
-pair&>::type
+   _GLIBCXX20_CONSTEXPR
+   typename enable_if<__and_,
+ is_assignable<_T2&, const _U2&>>::value,
+  pair&>::type
operator=(const pair<_U1, _U2>& __p)
{
  first = __p.first;
@@ -418,9 +420,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
 
   template
-  typename enable_if<__and_,
-   is_assignable<_T2&, _U2&&>>::value,
-pair&>::type
+   _GLIBCXX20_CONSTEXPR
+   typename enable_if<__and_,
+ is_assignable<_T2&, _U2&&>>::value,
+  pair&>::type
operator=(pair<_U1, _U2>&& __p)
{
  first = std::forward<_U1>(__p.first);
@@ -429,7 +432,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
 
   /// Swap the first members and then the second members.
-  void
+  _GLIBCXX20_CONSTEXPR void
   swap(pair& __p)
   noexcept(__and_<__is_nothrow_swappable<_T1>,
   __is_nothrow_swappable<_T2>>::value)
@@ -442,6 +445,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 private:
   template
+   _GLIBCXX20_CONSTEXPR
 pair(tuple<_Args1...>&, tuple<_Args2...>&,
  _Index_tuple<_Indexes1...>, _Index_tuple<_Indexes2...>);
 #endif
@@ -503,7 +507,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
* which has performance implications, e.g. see https://gcc.gnu.org/PR38466
   */
   template
-inline
+_GLIBCXX20_CONSTEXPR inline
 #if __cplusplus > 201402L || !defined(__STRICT_ANSI__) // c++1z or gnu++11
 // Constrained free swap overload, see p0185r1
 typename enable_if<__and_<__is_swappable<_T1>,
diff --git a/libstdc++-v3/include/std/tuple b/libstdc++-v3/include/std/tuple
index dd966b3a0bc..ae1a3d0d18b 100644
--- a/libstdc++-v3/include/std/tuple
+++ b/libstdc++-v3/include/std/tuple
@@ -1570,7 +1570,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   */
   template
 template
-  inline
+  _GLIBCXX20_CONSTEXPR inline
   pair<_T1, _T2>::
   pair(piecewise_construct_t,
   tuple<_Args1...> __first, tuple<_Args2...> __second)
@@ -1582,7 +1582,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template
 template
-  inline
+  _GLIBCXX20_CONSTEXPR inline
   pair<_T1, _T2>::
   pair(tuple<_Args1...>& __tuple1, tuple<_Args2...>& __tuple2,
   _Index_tuple<_Indexes1...>, _Index_tuple<_Indexes2...>)
diff --git a/libstdc++-v3/testsuite/20_util/pair/constexpr_assign.cc 
b/libstdc++-v3/testsuite/20_util/pair/constexpr_assign.cc
new file mode 100644
index 000..7abf2370658
--- /dev/null
+++ 

[PATCH] Fix array index error in address_v6 comparisons

[Jonathan Wakely]

* include/experimental/internet (operator==, operator<): Fix loop
condition to avoid reading past the end of the array.

Tested x86_64-linux, committed to trunk.


commit f5886e6a2c744196c089b16853d73d64e248a735
Author: Jonathan Wakely 
Date:   Thu Sep 26 14:57:56 2019 +0100

Fix array index error in address_v6 comparisons

* include/experimental/internet (operator==, operator<): Fix loop
condition to avoid reading past the end of the array.

diff --git a/libstdc++-v3/include/experimental/internet 
b/libstdc++-v3/include/experimental/internet
index 44d757c3a97..929a747a250 100644
--- a/libstdc++-v3/include/experimental/internet
+++ b/libstdc++-v3/include/experimental/internet
@@ -539,7 +539,7 @@ namespace ip
 const auto& __aa = __a._M_bytes;
 const auto& __bb = __b._M_bytes;
 int __i = 0;
-for (; __aa[__i] == __bb[__i] && __i < 16; ++__i)
+for (; __i < 16 && __aa[__i] == __bb[__i]; ++__i)
   ;
 return __i == 16 ? __a.scope_id() == __b.scope_id() : false;
   }
@@ -554,7 +554,7 @@ namespace ip
 const auto& __aa = __a._M_bytes;
 const auto& __bb = __b._M_bytes;
 int __i = 0;
-for (; __aa[__i] == __bb[__i] && __i < 16; ++__i)
+for (; __i < 16 && __aa[__i] == __bb[__i]; ++__i)
   ;
 return __i == 16 ? __a.scope_id() < __b.scope_id() : __aa[__i] < __bb[__i];
   }

[PATCH] Remove include directives for deleted Profile Mode headers

[Jonathan Wakely]

* include/std/array: Remove references to profile mode.
* include/std/bitset: Likewise.
* include/std/deque: Likewise.
* include/std/forward_list: Likewise.
* include/std/list: Likewise.
* include/std/map: Likewise.
* include/std/set: Likewise.
* include/std/unordered_map: Likewise.
* include/std/unordered_set: Likewise.
* include/std/vector: Likewise.
* testsuite/17_intro/headers/c++1998/profile_mode.cc: New test.
* testsuite/17_intro/headers/c++2011/profile_mode.cc: New test.

Tested x86_64-linux, committed to trunk.

commit ebfcc6644881b96fff60db313b37b5fb4843fbc1
Author: Jonathan Wakely 
Date:   Thu Sep 26 14:31:51 2019 +0100

Remove include directives for deleted Profile Mode headers

* include/std/array: Remove references to profile mode.
* include/std/bitset: Likewise.
* include/std/deque: Likewise.
* include/std/forward_list: Likewise.
* include/std/list: Likewise.
* include/std/map: Likewise.
* include/std/set: Likewise.
* include/std/unordered_map: Likewise.
* include/std/unordered_set: Likewise.
* include/std/vector: Likewise.
* testsuite/17_intro/headers/c++1998/profile_mode.cc: New test.
* testsuite/17_intro/headers/c++2011/profile_mode.cc: New test.

diff --git a/libstdc++-v3/include/std/array b/libstdc++-v3/include/std/array
index a380f523d44..b1dc8887787 100644
--- a/libstdc++-v3/include/std/array
+++ b/libstdc++-v3/include/std/array
@@ -422,10 +422,6 @@ _GLIBCXX_END_NAMESPACE_VERSION
 # include 
 #endif
 
-#ifdef _GLIBCXX_PROFILE
-# include 
-#endif
-
 #endif // C++11
 
 #endif // _GLIBCXX_ARRAY
diff --git a/libstdc++-v3/include/std/bitset b/libstdc++-v3/include/std/bitset
index d6958301e8a..ef4a91a0c15 100644
--- a/libstdc++-v3/include/std/bitset
+++ b/libstdc++-v3/include/std/bitset
@@ -1593,8 +1593,4 @@ _GLIBCXX_END_NAMESPACE_VERSION
 # include 
 #endif
 
-#ifdef _GLIBCXX_PROFILE
-# include 
-#endif
-
 #endif /* _GLIBCXX_BITSET */
diff --git a/libstdc++-v3/include/std/deque b/libstdc++-v3/include/std/deque
index ed4927e13b7..3f8e9abe032 100644
--- a/libstdc++-v3/include/std/deque
+++ b/libstdc++-v3/include/std/deque
@@ -72,10 +72,6 @@
 # include 
 #endif
 
-#ifdef _GLIBCXX_PROFILE
-# include 
-#endif
-
 #if __cplusplus >= 201703L
 namespace std _GLIBCXX_VISIBILITY(default)
 {
diff --git a/libstdc++-v3/include/std/forward_list 
b/libstdc++-v3/include/std/forward_list
index 9d6cc40593b..39c3f4438de 100644
--- a/libstdc++-v3/include/std/forward_list
+++ b/libstdc++-v3/include/std/forward_list
@@ -43,10 +43,6 @@
 # include 
 #endif
 
-#ifdef _GLIBCXX_PROFILE
-# include 
-#endif
-
 #if __cplusplus >= 201703L
 namespace std _GLIBCXX_VISIBILITY(default)
 {
diff --git a/libstdc++-v3/include/std/list b/libstdc++-v3/include/std/list
index 8d6ac198c9a..35c9d44a39e 100644
--- a/libstdc++-v3/include/std/list
+++ b/libstdc++-v3/include/std/list
@@ -67,10 +67,6 @@
 # include 
 #endif
 
-#ifdef _GLIBCXX_PROFILE
-# include 
-#endif
-
 #if __cplusplus >= 201703L
 namespace std _GLIBCXX_VISIBILITY(default)
 {
diff --git a/libstdc++-v3/include/std/map b/libstdc++-v3/include/std/map
index 0da7c895aac..0eb4f80f93f 100644
--- a/libstdc++-v3/include/std/map
+++ b/libstdc++-v3/include/std/map
@@ -67,10 +67,6 @@
 # include 
 #endif
 
-#ifdef _GLIBCXX_PROFILE
-# include 
-#endif
-
 #if __cplusplus >= 201703L
 namespace std _GLIBCXX_VISIBILITY(default)
 {
diff --git a/libstdc++-v3/include/std/set b/libstdc++-v3/include/std/set
index a9ce58c4574..4213a4a01b8 100644
--- a/libstdc++-v3/include/std/set
+++ b/libstdc++-v3/include/std/set
@@ -67,10 +67,6 @@
 # include 
 #endif
 
-#ifdef _GLIBCXX_PROFILE
-# include 
-#endif
-
 #if __cplusplus >= 201703L
 namespace std _GLIBCXX_VISIBILITY(default)
 {
diff --git a/libstdc++-v3/include/std/unordered_map 
b/libstdc++-v3/include/std/unordered_map
index 60f9bd7a6a6..eb69240a94f 100644
--- a/libstdc++-v3/include/std/unordered_map
+++ b/libstdc++-v3/include/std/unordered_map
@@ -52,10 +52,6 @@
 # include 
 #endif
 
-#ifdef _GLIBCXX_PROFILE
-# include 
-#endif
-
 #if __cplusplus >= 201703L
 namespace std _GLIBCXX_VISIBILITY(default)
 {
diff --git a/libstdc++-v3/include/std/unordered_set 
b/libstdc++-v3/include/std/unordered_set
index 90438738614..a28b840c136 100644
--- a/libstdc++-v3/include/std/unordered_set
+++ b/libstdc++-v3/include/std/unordered_set
@@ -52,10 +52,6 @@
 # include 
 #endif
 
-#ifdef _GLIBCXX_PROFILE
-# include 
-#endif
-
 #if __cplusplus >= 201703L
 namespace std _GLIBCXX_VISIBILITY(default)
 {
diff --git a/libstdc++-v3/include/std/vector b/libstdc++-v3/include/std/vector
index e5e13ab3ef7..c15faf1da9a 100644
--- a/libstdc++-v3/include/std/vector
+++ b/libstdc++-v3/include/std/vector
@@ -76,10 +76,6 @@
 # include 
 #endif
 
-#ifdef _GLIBCXX_PROFILE
-# include 
-#endif
-
 #if __cplusplus >= 201703L
 namespace std 

Re: Problem exposed by recent ARM multiply changes

[Jakub Jelinek]

On Thu, Sep 26, 2019 at 10:01:56AM -0600, Jeff Law wrote:
> On 9/26/19 9:47 AM, Jakub Jelinek wrote:
> > On Thu, Sep 26, 2019 at 09:39:31AM -0600, Jeff Law wrote:
> >> Right.  My point is that the multiplication patterns are an exception as
> >> well.
> > 
> > Do you have some evidence for that? 
> It's in the manual.  And yes it potentially makes a huge mess due to the
> interactions with modeless CONST_INTs.

Where?
Unless otherwise specified, all the operands of arithmetic expressions
must be valid for mode @var{m}.  An operand is valid for mode @var{m}
if it has mode @var{m}, or if it is a @code{const_int} or
@code{const_double} and @var{m} is a mode of class @code{MODE_INT}.

and for MULT:
Represents the signed product of the values represented by @var{x} and
@var{y} carried out in machine mode @var{m}.
@code{ss_mult} and @code{us_mult} ensure that an out-of-bounds result
saturates to the maximum or minimum signed or unsigned value.

Some machines support a multiplication that generates a product wider
than the operands.  Write the pattern for this as

@smallexample
(mult:@var{m} (sign_extend:@var{m} @var{x}) (sign_extend:@var{m} @var{y}))
@end smallexample

where @var{m} is wider than the modes of @var{x} and @var{y}, which need
not be the same.

For unsigned widening multiplication, use the same idiom, but with
@code{zero_extend} instead of @code{sign_extend}.

I don't read that as an exception to violate that, it simply says that in
that case one should use sign/zero_extend.

Jakub

Re: Problem exposed by recent ARM multiply changes

[Jeff Law]

On 9/26/19 9:47 AM, Jakub Jelinek wrote:
> On Thu, Sep 26, 2019 at 09:39:31AM -0600, Jeff Law wrote:
>> Right.  My point is that the multiplication patterns are an exception as
>> well.
> 
> Do you have some evidence for that? 
It's in the manual.  And yes it potentially makes a huge mess due to the
interactions with modeless CONST_INTs.

jeff

Re: [libcpp] Issue a pedantic warning for UCNs outside UCS codespace

[Joseph Myers]

On Thu, 26 Sep 2019, Eric Botcazou wrote:

> > For C, I think such UCNs violate the Semantics but not the Constraints on
> > UCNs, so no diagnostic is actually required in C, although it is permitted
> > as a pedwarn / error.
> > 
> > However, while C++ doesn't have that Semantics / Constraints division,
> > it's also the case that before C++2a, C++ only has a dated normative
> > reference to ISO/IEC 10646-1:1993 (C++2a adds an undated reference and
> > says the dated one is only for deprecated features, as well as explicitly
> > making such UCNs outside the ISO 10646 code point range ill-formed).  So I
> > think that for C++, this is only correct as an error / pedwarn in the
> > C++2a case.
> 
> OK, thanks for the exegesis. ;-)  Revision version attached.

Checking "CPP_OPTION (pfile, lang) == CLK_CXX2A" is problematic because 
future versions later than C++2a should be handled the same as C++2a.

The only place I see doing something similar (outside of init.c, most 
version conditionals are handled via language flags set there) does 
"CPP_OPTION (pfile, lang) > CLK_CXX11" (for "In C++14 and up these 
suffixes are in the standard library, so treat them as user-defined 
literals.", two places doing the same comparison).  So I think that 
"CPP_OPTION (pfile, lang) > CLK_CXX17" is the right thing to replace the 
comparisons against CLK_CXX2A and CLK_GNUCXX2A.

The patch is OK with that change.

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

Re: Problem exposed by recent ARM multiply changes

[Jakub Jelinek]

On Thu, Sep 26, 2019 at 09:39:31AM -0600, Jeff Law wrote:
> Right.  My point is that the multiplication patterns are an exception as
> well.

Do you have some evidence for that?  I mean, e.g. simplify-rtx.c will in
that case almost certainly misbehave, if some expression can have CONST_INT
operand(s), then it really needs to have the mode for them determined by
the result mode or mode of another operand, or during simplification can be
handled by passing that mode around (that is why e.g.
simplify_unary_operation has both mode and op_mode arguments,
simplify_relational_operation has both mode and cmp_mode arguments etc.),
though in such a case they must simplify into something that doesn't include
the operation anymore, or CONST_INT can't be propagated into it.

Jakub

Re: [PATCH] Retain TYPE_MODE more often for BIT_FIELD_REFs in get_inner_referece

[Eric Botcazou]

> 2019-09-26  Richard Biener  
> 
>   PR middle-end/91897
>   * expr.c (get_inner_reference): For BIT_FIELD_REF with
>   vector type retain the original mode.
> 
>   * gcc.target/i386/pr91897.c: New testcase.

This looks good to me, thanks.

-- 
Eric Botcazou

[Bug c/91918] Const pointer argument to atomic_compare_exchange doesn't cause an error.

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91918

--- Comment #5 from joseph at codesourcery dot com  ---
In general this sort of thing is undefined behavior under 7.1.4.  It's 
valid to give an error in this case (as the types are wrong), but it's 
liable to be hard to do so in all cases for generic functions implemented 
using macros.  In this case an error could probably be achieved reliably 
by implementing stricter checks for the arguments to the 
__atomic_compare_exchange built-in function.

[PATCH, rs6000] Update powerpc vector load builtins with PURE attribute

[will schmidt]

Hi,

Update our (rs6000) vector load built-ins with the PURE attribute.  These
were previously given the MEM attribute, which meant that redundant loads
surrounding the built-in calls could not be eliminated in earlier passes
since they were defined as having the potential to touch memory.

This change has been tested across assorted powerpc
systems (p7, p8le, p8be, p9) with no regressions noted.

OK for trunk?

Thanks,
-Will

[gcc]

2019-09-26  Will Schmidt 
* config/rs6000/rs6000-builtin.def: ( LVSL LVSR LVEBX LVEHX
LVEWX LVXL LVXL_V2DF LVXL_V2DI LVXL_V4SF LVXL_V4SI LVXL_V8HI
LVXL_V16QI LVX LVX_V1TI LVX_V2DF LVX_V2DI LVX_V4SF LVX_V4SI
LVX_V8HI LVX_V16QI LVLX LVLXL LVRX LVRXL LXSDX LXVD2X_V1TI
LXVD2X_V2DF LXVD2X_V2DI LXVDSX LXVW4X_V4SF LXVW4X_V4SI
LXVW4X_V8HI LXVW4X_V16QI LD_ELEMREV_V1TI LD_ELEMREV_V2DF
LD_ELEMREV_V2DI LD_ELEMREV_V4SF LD_ELEMREV_V4SI LD_ELEMREV_V8HI
LD_ELEMREV_V16QI): Use the PURE attribute.

[testsuite]

2019-09-26  Will Schmidt 
* gcc.target/powerpc/pure-builtin-redundant-load.c:  New.

diff --git a/gcc/config/rs6000/rs6000-builtin.def 
b/gcc/config/rs6000/rs6000-builtin.def
index 0a2bdb7..4d4f3b3 100644
--- a/gcc/config/rs6000/rs6000-builtin.def
+++ b/gcc/config/rs6000/rs6000-builtin.def
@@ -1175,41 +1175,41 @@ BU_ALTIVEC_P (VCMPGTUB_P, "vcmpgtub_p", CONST,  
vector_gtu_v16qi_p)
 /* AltiVec builtins that are handled as special cases.  */
 BU_ALTIVEC_X (MTVSCR,  "mtvscr",   MISC)
 BU_ALTIVEC_X (MFVSCR,  "mfvscr",   MISC)
 BU_ALTIVEC_X (DSSALL,  "dssall",   MISC)
 BU_ALTIVEC_X (DSS, "dss",  MISC)
-BU_ALTIVEC_X (LVSL,"lvsl", MEM)
-BU_ALTIVEC_X (LVSR,"lvsr", MEM)
-BU_ALTIVEC_X (LVEBX,   "lvebx",MEM)
-BU_ALTIVEC_X (LVEHX,   "lvehx",MEM)
-BU_ALTIVEC_X (LVEWX,   "lvewx",MEM)
-BU_ALTIVEC_X (LVXL,"lvxl", MEM)
-BU_ALTIVEC_X (LVXL_V2DF,   "lvxl_v2df",MEM)
-BU_ALTIVEC_X (LVXL_V2DI,   "lvxl_v2di",MEM)
-BU_ALTIVEC_X (LVXL_V4SF,   "lvxl_v4sf",MEM)
-BU_ALTIVEC_X (LVXL_V4SI,   "lvxl_v4si",MEM)
-BU_ALTIVEC_X (LVXL_V8HI,   "lvxl_v8hi",MEM)
-BU_ALTIVEC_X (LVXL_V16QI,  "lvxl_v16qi",   MEM)
-BU_ALTIVEC_X (LVX, "lvx",  MEM)
-BU_ALTIVEC_X (LVX_V1TI,"lvx_v1ti", MEM)
-BU_ALTIVEC_X (LVX_V2DF,"lvx_v2df", MEM)
-BU_ALTIVEC_X (LVX_V2DI,"lvx_v2di", MEM)
-BU_ALTIVEC_X (LVX_V4SF,"lvx_v4sf", MEM)
-BU_ALTIVEC_X (LVX_V4SI,"lvx_v4si", MEM)
-BU_ALTIVEC_X (LVX_V8HI,"lvx_v8hi", MEM)
-BU_ALTIVEC_X (LVX_V16QI,   "lvx_v16qi",MEM)
+BU_ALTIVEC_X (LVSL,"lvsl", PURE)
+BU_ALTIVEC_X (LVSR,"lvsr", PURE)
+BU_ALTIVEC_X (LVEBX,   "lvebx",PURE)
+BU_ALTIVEC_X (LVEHX,   "lvehx",PURE)
+BU_ALTIVEC_X (LVEWX,   "lvewx",PURE)
+BU_ALTIVEC_X (LVXL,"lvxl", PURE)
+BU_ALTIVEC_X (LVXL_V2DF,   "lvxl_v2df",PURE)
+BU_ALTIVEC_X (LVXL_V2DI,   "lvxl_v2di",PURE)
+BU_ALTIVEC_X (LVXL_V4SF,   "lvxl_v4sf",PURE)
+BU_ALTIVEC_X (LVXL_V4SI,   "lvxl_v4si",PURE)
+BU_ALTIVEC_X (LVXL_V8HI,   "lvxl_v8hi",PURE)
+BU_ALTIVEC_X (LVXL_V16QI,  "lvxl_v16qi",   PURE)
+BU_ALTIVEC_X (LVX, "lvx",  PURE)
+BU_ALTIVEC_X (LVX_V1TI,"lvx_v1ti", PURE)
+BU_ALTIVEC_X (LVX_V2DF,"lvx_v2df", PURE)
+BU_ALTIVEC_X (LVX_V2DI,"lvx_v2di", PURE)
+BU_ALTIVEC_X (LVX_V4SF,"lvx_v4sf", PURE)
+BU_ALTIVEC_X (LVX_V4SI,"lvx_v4si", PURE)
+BU_ALTIVEC_X (LVX_V8HI,"lvx_v8hi", PURE)
+BU_ALTIVEC_X (LVX_V16QI,   "lvx_v16qi",PURE)
 BU_ALTIVEC_X (STVX,"stvx", MEM)
 BU_ALTIVEC_X (STVX_V2DF,   "stvx_v2df",MEM)
 BU_ALTIVEC_X (STVX_V2DI,   "stvx_v2di",MEM)
 BU_ALTIVEC_X (STVX_V4SF,   "stvx_v4sf",MEM)
 BU_ALTIVEC_X (STVX_V4SI,   "stvx_v4si",MEM)
 BU_ALTIVEC_X (STVX_V8HI,   "stvx_v8hi",MEM)
 BU_ALTIVEC_X (STVX_V16QI,  "stvx_v16qi",   MEM)
-BU_ALTIVEC_C (LVLX,"lvlx", MEM)
-BU_ALTIVEC_C (LVLXL,   "lvlxl",MEM)
-BU_ALTIVEC_C (LVRX,"lvrx", MEM)
-BU_ALTIVEC_C (LVRXL,   "lvrxl",MEM)
+BU_ALTIVEC_C (LVLX,"lvlx", PURE)
+BU_ALTIVEC_C (LVLXL,   "lvlxl",PURE)
+BU_ALTIVEC_C (LVRX,"lvrx", PURE)
+BU_ALTIVEC_C (LVRXL,   "lvrxl",PURE)
 BU_ALTIVEC_X 

[Bug c/91915] New warning for duplicate if condition in if-elseif-elseif chain

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91915

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
(In reply to Marek Polacek from comment #2)
> I already implemented such a warning in r228388:
> 
> w.c: In function ‘foo’:
> w.c:11:17: warning: duplicated ‘if’ condition [-Wduplicated-cond]
>11 |   else if (argc == 1)
>   |~^~~~
> w.c:6:12: note: previously used here
> 6 |   if (argc == 1)
>   |   ~^~~~

so in that case this would be bug 87656

Re: Problem exposed by recent ARM multiply changes

[Jeff Law]

On 9/26/19 9:22 AM, Jakub Jelinek wrote:
> On Thu, Sep 26, 2019 at 09:12:34AM -0600, Jeff Law wrote:
>> On 9/26/19 12:49 AM, Jakub Jelinek wrote:
>>> On Wed, Sep 25, 2019 at 10:06:13PM -0600, Jeff Law wrote:
 (insn 13 12 14 2 (set (reg:SI 124)
 (const_int -939524096 [0xc800])) "j.c":10:54 161
 {*arm_movsi_insn}
  (nil))

 (insn 14 13 16 2 (parallel [
 (set (reg:SI 132)
 (plus:SI (mult:SI (zero_extend:DI (reg/v:SI 115 [ sec ]))
 (zero_extend:DI (reg:SI 124)))
 (reg:SI 130)))
>>>
>>> IMNSHO the bug is just in the backend, the above is not valid RTL.
>>> SImode MULT has to have SImode operands, not DImode operands.
>> Hmm, yea, I think you're right.  I totally missed that last night.
>>
>> FWIW, we do allow the modes of the input operands to differ.  But I
>> don't think either is allowed to be wider than the result mode of the
>> multiplication.
> 
> Sure, there are some rtl codes that can have different operands, but most of
> them don't.  The exceptions are shifts/rotates (the second operand can have
> different mode, but result/first operand needs to be the same), comparisons
> (result mode can be different from operand modes, but operand mode needs to
> be the same), zero_extract/sign_extract, some vec_* etc.
> Most binary arithmetic rtxes need to have the same mode for the result and
> both arguments though.
Right.  My point is that the multiplication patterns are an exception as
well.

I don't like the exceptions for the multiplication patterns as I think
the same effect could have been achieved with more zero/sign extractions.


Jeff

[Bug tree-optimization/91914] [9 Regression] Invalid strlen optimization

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91914

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #2 from Martin Sebor  ---
I was reluctant to backport the fix for pr91490 to GCC 9 because although it
eliminates some false positives it introduces new true ones that didn't exist
before.  Maybe that's okay.  If not, the simple change below appears to both
avoid the false positive and the unintended folding:

Index: gcc/expr.c
===
--- gcc/expr.c  (revision 276151)
+++ gcc/expr.c  (working copy)
@@ -11556,7 +11556,7 @@ string_constant (tree arg, tree *ptr_offset, tree

   base_off = wioff.to_uhwi ();
   unsigned HOST_WIDE_INT fieldoff = 0;
-  init = fold_ctor_reference (NULL_TREE, init, base_off, 0, array,
+  init = fold_ctor_reference (TREE_TYPE (arg), init, base_off, 0, array,
  );
   HOST_WIDE_INT cstoff;
   if (!base_off.is_constant ())

Re: Problem exposed by recent ARM multiply changes

[Kyrill Tkachov]

On 9/26/19 4:32 PM, Jeff Law wrote:

On 9/26/19 9:14 AM, Kyrill Tkachov wrote:

On 9/26/19 4:12 PM, Jeff Law wrote:

On 9/26/19 12:49 AM, Jakub Jelinek wrote:

On Wed, Sep 25, 2019 at 10:06:13PM -0600, Jeff Law wrote:

(insn 13 12 14 2 (set (reg:SI 124)
  (const_int -939524096 [0xc800])) "j.c":10:54 161
{*arm_movsi_insn}
   (nil))

(insn 14 13 16 2 (parallel [
  (set (reg:SI 132)
  (plus:SI (mult:SI (zero_extend:DI (reg/v:SI 115 [

sec ]))

  (zero_extend:DI (reg:SI 124)))
  (reg:SI 130)))

IMNSHO the bug is just in the backend, the above is not valid RTL.
SImode MULT has to have SImode operands, not DImode operands.

Hmm, yea, I think you're right.  I totally missed that last night.

FWIW, we do allow the modes of the input operands to differ.  But I
don't think either is allowed to be wider than the result mode of the
multiplication.


I think that means we punt this back to Wilco to fix since it's an ARM
specific issue.

Can you please file a PR for it so we don't lose track of it?

91919


Nice.

Kyrill





jeff

Re: Problem exposed by recent ARM multiply changes

[Jeff Law]

On 9/26/19 9:14 AM, Kyrill Tkachov wrote:
> 
> On 9/26/19 4:12 PM, Jeff Law wrote:
>> On 9/26/19 12:49 AM, Jakub Jelinek wrote:
>> > On Wed, Sep 25, 2019 at 10:06:13PM -0600, Jeff Law wrote:
>> >> (insn 13 12 14 2 (set (reg:SI 124)
>> >> (const_int -939524096 [0xc800])) "j.c":10:54 161
>> >> {*arm_movsi_insn}
>> >>  (nil))
>> >>
>> >> (insn 14 13 16 2 (parallel [
>> >> (set (reg:SI 132)
>> >> (plus:SI (mult:SI (zero_extend:DI (reg/v:SI 115 [
>> sec ]))
>> >> (zero_extend:DI (reg:SI 124)))
>> >> (reg:SI 130)))
>> >
>> > IMNSHO the bug is just in the backend, the above is not valid RTL.
>> > SImode MULT has to have SImode operands, not DImode operands.
>> Hmm, yea, I think you're right.  I totally missed that last night.
>>
>> FWIW, we do allow the modes of the input operands to differ.  But I
>> don't think either is allowed to be wider than the result mode of the
>> multiplication.
>>
>>
>> I think that means we punt this back to Wilco to fix since it's an ARM
>> specific issue.
> 
> Can you please file a PR for it so we don't lose track of it?
91919

jeff

Re: Reposurgeon status

[Jeff Law]

On 9/25/19 2:32 PM, Eric S. Raymond wrote:
> Since the subject of repository conversions has come up, a situation report...
> 
> I am in the very last stages of qualifying the Go port of reposurgeon.
> Most importantly to your project, the Go code passed all of the
> existing regression tests for reading Subversion stream dumps two days
> ago. That is a big deal, as the stream dump reader was by *far* the
> trickiest and most bug-prone part to translate.
[ ... ]

> 
> I think I'm looking at somewhere between 7 and 14 days until I can start 
> work on the GCC move again. Getting to this point has taken a year.

[ ... ]
Good to hear there's been major progress.

Probably the most important thing to know is the project will make a
decision on Dec 16 to choose the conversion tool.  The evaluation is
based on the state of tool's conversion on that date.  More details:

> https://gcc.gnu.org/wiki/GitConversion

You should consider the dates in there as firm.


You might want to update the state of reposurgeon on that page.


Jeff

Re: Problem exposed by recent ARM multiply changes

[Jakub Jelinek]

On Thu, Sep 26, 2019 at 09:12:34AM -0600, Jeff Law wrote:
> On 9/26/19 12:49 AM, Jakub Jelinek wrote:
> > On Wed, Sep 25, 2019 at 10:06:13PM -0600, Jeff Law wrote:
> >> (insn 13 12 14 2 (set (reg:SI 124)
> >> (const_int -939524096 [0xc800])) "j.c":10:54 161
> >> {*arm_movsi_insn}
> >>  (nil))
> >>
> >> (insn 14 13 16 2 (parallel [
> >> (set (reg:SI 132)
> >> (plus:SI (mult:SI (zero_extend:DI (reg/v:SI 115 [ sec ]))
> >> (zero_extend:DI (reg:SI 124)))
> >> (reg:SI 130)))
> > 
> > IMNSHO the bug is just in the backend, the above is not valid RTL.
> > SImode MULT has to have SImode operands, not DImode operands.
> Hmm, yea, I think you're right.  I totally missed that last night.
> 
> FWIW, we do allow the modes of the input operands to differ.  But I
> don't think either is allowed to be wider than the result mode of the
> multiplication.

Sure, there are some rtl codes that can have different operands, but most of
them don't.  The exceptions are shifts/rotates (the second operand can have
different mode, but result/first operand needs to be the same), comparisons
(result mode can be different from operand modes, but operand mode needs to
be the same), zero_extract/sign_extract, some vec_* etc.
Most binary arithmetic rtxes need to have the same mode for the result and
both arguments though.

> I think that means we punt this back to Wilco to fix since it's an ARM
> specific issue.

Sure.

Jakub

[Bug target/91919] New: [10 Regression] arm-linux-eabi ICE with building kernel

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91919

Bug ID: 91919
   Summary: [10 Regression] arm-linux-eabi ICE with building
kernel
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: law at redhat dot com
  Target Milestone: ---

> commit fa761b10d40aaa71e62fbc0c9f2ab8fc07a98b49 (HEAD, refs/bisect/bad)
> Author: wilco 
> Date:   Wed Sep 18 18:33:30 2019 +
>
> [ARM] Cleanup 64-bit multiplies
> 
> Cleanup 64-bit multiplies.  Combine the expanders using iterators.
> Merge the signed/unsigned multiplies as well as the pre-Armv6 and Armv6
> variants.  Split DImode operands early into parallel sets inside the
> MULL/MLAL instructions - this improves register allocation and avoids
> subreg issues due to other DImode operations splitting early.
> 
> gcc/
> * config/arm/arm.md (maddsidi4): Remove expander.
> (mulsidi3adddi): Remove pattern.
> (mulsidi3adddi_v6): Likewise.
> (mulsidi3_nov6): Likewise.
> (mulsidi3_v6): Likewise.
> (umulsidi3): Remove expander.
> (umulsidi3_nov6): Remove pattern.
> (umulsidi3_v6): Likewise.
> (umulsidi3adddi): Likewise.
> (umulsidi3adddi_v6): Likewise.
> (mulsidi3): Add combined expander.
> (maddsidi4): Likewise.
> (mull): Add combined umull and smull pattern.
> (mlal): Likewise.
> * config/arm/iterators.md (Us): Add new iterator.

Is causing the linux kernel to fail to build for arm-linux-gnueabi.

-O2 with this testcase:

__extension__ typedef unsigned long long __u64;
typedef __u64 u64;
static inline unsigned long
__timespec64_to_jiffies (u64 sec, long nsec)
{
  return ((sec *
   ((unsigned
 long) u64) 10L << (32 - 7)) +
 ((10L + 100 / 2) / 100) -
 1) / (u64) ((10L + 100 / 2) / 100 +
  (((u64) nsec *
((unsigned
  long) u64) 1 << ((32 - 7) + 29)) +
  ((10L + 100 / 2) / 100) -
  1) / (u64) ((10L + 100 / 2) / 100 >>
(((32 -

 7) +

29) -

(32 -

7
>> (32 - 7);
}

unsigned long
__timespec_to_jiffies (unsigned long sec, long nsec)
{
  return __timespec64_to_jiffies ((u64) sec, nsec);
}


(insn 14 13 16 2 (parallel [
(set (reg:SI 132)
(plus:SI (mult:SI (zero_extend:DI (reg/v:SI 115 [ sec ]))
(zero_extend:DI (reg:SI 124)))
(reg:SI 130)))
   ...)

Jakub noted the mode of the mult is SImode, while the operands are DImode. 
That's not valid RTL.

Re: Problem exposed by recent ARM multiply changes

[Kyrill Tkachov]

On 9/26/19 4:12 PM, Jeff Law wrote:

On 9/26/19 12:49 AM, Jakub Jelinek wrote:
> On Wed, Sep 25, 2019 at 10:06:13PM -0600, Jeff Law wrote:
>> (insn 13 12 14 2 (set (reg:SI 124)
>> (const_int -939524096 [0xc800])) "j.c":10:54 161
>> {*arm_movsi_insn}
>>  (nil))
>>
>> (insn 14 13 16 2 (parallel [
>> (set (reg:SI 132)
>> (plus:SI (mult:SI (zero_extend:DI (reg/v:SI 115 [ 
sec ]))

>> (zero_extend:DI (reg:SI 124)))
>> (reg:SI 130)))
>
> IMNSHO the bug is just in the backend, the above is not valid RTL.
> SImode MULT has to have SImode operands, not DImode operands.
Hmm, yea, I think you're right.  I totally missed that last night.

FWIW, we do allow the modes of the input operands to differ.  But I
don't think either is allowed to be wider than the result mode of the
multiplication.


I think that means we punt this back to Wilco to fix since it's an ARM
specific issue.


Can you please file a PR for it so we don't lose track of it?

Thanks,

Kyrill




jeff

Re: Problem exposed by recent ARM multiply changes

[Jeff Law]

On 9/26/19 12:49 AM, Jakub Jelinek wrote:
> On Wed, Sep 25, 2019 at 10:06:13PM -0600, Jeff Law wrote:
>> (insn 13 12 14 2 (set (reg:SI 124)
>> (const_int -939524096 [0xc800])) "j.c":10:54 161
>> {*arm_movsi_insn}
>>  (nil))
>>
>> (insn 14 13 16 2 (parallel [
>> (set (reg:SI 132)
>> (plus:SI (mult:SI (zero_extend:DI (reg/v:SI 115 [ sec ]))
>> (zero_extend:DI (reg:SI 124)))
>> (reg:SI 130)))
> 
> IMNSHO the bug is just in the backend, the above is not valid RTL.
> SImode MULT has to have SImode operands, not DImode operands.
Hmm, yea, I think you're right.  I totally missed that last night.

FWIW, we do allow the modes of the input operands to differ.  But I
don't think either is allowed to be wider than the result mode of the
multiplication.


I think that means we punt this back to Wilco to fix since it's an ARM
specific issue.

jeff

[Bug c++/91889] [10 Regression] error: call of overloaded ‘to_value_ptr(B*&)’ is ambiguous

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91889

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |10.0

--- Comment #12 from Marek Polacek  ---
ACK, will work on that.

[AArch64][SVE2] Shift-Right Accumulate combine patterns

[Yuliang Wang]

Hi,

This patch adds combining support for SVE2's shift-right accumulate 
instructions.

Example snippet:

#define IMM ...

void foo (TYPE a, TYPE b, int n)
{
  for (int i = 0; i < n; i++)
a[i] += b[i] >> IMM;
}

Signed:

  beforeasr z0.s, z0.s, #{IMM}
add z0.s, z0.s, z1.s
  ...
  after ssraz0.s, z1.s, #{IMM}

Unsigned:

  beforelsr z0.s, z0.s, #{IMM}
add z0.s, z0.s, z1.s
  ...
  after usraz0.s, z1.s, #{IMM}

Built and regression tested on aarch64-none-elf.

Best Regards,
Yuliang Wang


gcc/ChangeLog:

2019-09-26 Yuliang Wang  

* config/aarch64/aarch64-sve2.md (aarch64_sve2_sra):
New combine pattern.

gcc/testsuite/ChangeLog:

2019-09-26 Yuliang Wang  

* gcc.target/aarch64/sve2/shracc_1.c: New test.



rb11872.patch
Description: rb11872.patch

[Bug c++/91889] [10 Regression] error: call of overloaded ‘to_value_ptr(B*&)’ is ambiguous

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91889

Jason Merrill  changed:

   What|Removed |Added

 Status|SUSPENDED   |NEW

--- Comment #11 from Jason Merrill  ---
(In reply to Marek Polacek from comment #7)
> Maybe the ranking needs additional wording, thus input from CWG.

Indeed, that's what I was thinking about at in my comment on your patch for PR
91877.  I think until we have a way to rank these conversions the DR is broken.
 I also think the obvious fix is to treat the reference binding as having an
implicit qualification conversion for purposes of comparison.

I'd also leave this PR open, not suspended; this is in fact a GCC 10
regression.

[Bug c++/91369] Implement P0784R7: constexpr new

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91369

--- Comment #7 from Jason Merrill  ---
(In reply to Jakub Jelinek from comment #6)
> So, is the [class.dtor]/9 note just incorrect and should be removed, or
> clarified somehow?  I believe it shouldn't affect what actually is a literal
> type or not, because the constructor of a class without virtual bases which
> has a non-static data member that has virtual bases can't be constexpr either.

I think a virtual base just shouldn't make the destructor non-constexpr, which
would make the note correct.  I've emailed CWG to that effect.

[Bug c++/91889] [10 Regression] error: call of overloaded ‘to_value_ptr(B*&)’ is ambiguous

[sje at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91889

--- Comment #10 from Steve Ellcey  ---
(In reply to Marek Polacek from comment #9)
> I'll raise it with CWG; suspending until then.

Not sure if it matters but there seem to be 8 instances of this problem in
Boost (get_color, get_left, get_next, get_parent, get_previous, get_right,
to_hook_ptr, and to_value_ptr).  The actual number of errors you get during a
boost build is much higher due to hitting these overload issues numerous times
during the build.

[Bug c/91918] Const pointer argument to atomic_compare_exchange doesn't cause an error.

[mq at ucw dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91918

--- Comment #4 from Maria Matejka  ---
This bug applies also on v9.2.0.