libgo patch commit: fix NetBSD build

[Ian Lance Taylor via Gcc-patches]

This patch to the libgo by Benny Siegert fixes compiling the runtime
package on NetBSD.  On NetBSD si_code in siginfo_t is a macro on
NetBSD, not a member of the struct itself, so add a C trampoline for
receiving its value.  Also replace references to mos.waitsemacount
with the replacement and add some helpers from os_netbsd.go in the GC
repository.  This is for https://golang.org/issue/38538.  Bootstrapped
and ran Go testsuite on x86_64-pc-linux-gnu.  Committed to mainline.

Ian
4f7e3ea2006a4e23998806ee7cf8111441d631fc
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 7b382cf47b8..e48abcf71d6 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-0fe7a277c5d22265a73a4d216bd5d81799634453
+b76c83f34c006938fe6c3311d949496990bc5db9
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/libgo/go/runtime/os_netbsd.go b/libgo/go/runtime/os_netbsd.go
index 7c3d41fb9d1..69d2c710449 100644
--- a/libgo/go/runtime/os_netbsd.go
+++ b/libgo/go/runtime/os_netbsd.go
@@ -68,9 +68,9 @@ func semasleep(ns int64) int32 {
}
 
for {
-   v := atomic.Load(&_g_.m.mos.waitsemacount)
+   v := atomic.Load(&_g_.m.waitsemacount)
if v > 0 {
-   if atomic.Cas(&_g_.m.mos.waitsemacount, v, v-1) {
+   if atomic.Cas(&_g_.m.waitsemacount, v, v-1) {
return 0 // semaphore acquired
}
continue
@@ -96,15 +96,15 @@ func semasleep(ns int64) int32 {
 
 //go:nosplit
 func semawakeup(mp *m) {
-   atomic.Xadd(, 1)
+   atomic.Xadd(, 1)
// From NetBSD's _lwp_unpark(2) manual:
// "If the target LWP is not currently waiting, it will return
// immediately upon the next call to _lwp_park()."
-   ret := lwp_unpark(int32(mp.procid), 
unsafe.Pointer())
+   ret := lwp_unpark(int32(mp.procid), unsafe.Pointer())
if ret != 0 && ret != _ESRCH {
// semawakeup can be called on signal stack.
systemstack(func() {
-   print("thrwakeup addr=", , " 
sem=", mp.mos.waitsemacount, " ret=", ret, "\n")
+   print("thrwakeup addr=", , " sem=", 
mp.waitsemacount, " ret=", ret, "\n")
})
}
 }
@@ -115,3 +115,34 @@ func osinit() {
physPageSize = getPageSize()
}
 }
+
+func sysargs(argc int32, argv **byte) {
+   n := argc + 1
+
+   // skip over argv, envp to get to auxv
+   for argv_index(argv, n) != nil {
+   n++
+   }
+
+   // skip NULL separator
+   n++
+
+   // now argv+n is auxv
+   auxv := (*[1 << 28]uintptr)(add(unsafe.Pointer(argv), 
uintptr(n)*sys.PtrSize))
+   sysauxv(auxv[:])
+}
+
+const (
+   _AT_NULL   = 0 // Terminates the vector
+   _AT_PAGESZ = 6 // Page size in bytes
+)
+
+func sysauxv(auxv []uintptr) {
+   for i := 0; auxv[i] != _AT_NULL; i += 2 {
+   tag, val := auxv[i], auxv[i+1]
+   switch tag {
+   case _AT_PAGESZ:
+   physPageSize = val
+   }
+   }
+}
diff --git a/libgo/go/runtime/signal_gccgo.go b/libgo/go/runtime/signal_gccgo.go
index 6f362fc05be..c555712a03c 100644
--- a/libgo/go/runtime/signal_gccgo.go
+++ b/libgo/go/runtime/signal_gccgo.go
@@ -60,7 +60,7 @@ type sigctxt struct {
 }
 
 func (c *sigctxt) sigcode() uint64 {
-   return uint64(c.info.si_code)
+   return uint64(getSiginfoCode(c.info))
 }
 
 //go:nosplit
diff --git a/libgo/go/runtime/stubs.go b/libgo/go/runtime/stubs.go
index 4a06da51fe5..25b1836daf0 100644
--- a/libgo/go/runtime/stubs.go
+++ b/libgo/go/runtime/stubs.go
@@ -297,6 +297,10 @@ func getSigactionHandler(*_sigaction) uintptr
 //go:noescape
 func setSigactionHandler(*_sigaction, uintptr)
 
+// Get signal code, written in C.
+//go:noescape
+func getSiginfoCode(*_siginfo_t) uintptr
+
 // Retrieve fields from the siginfo_t and ucontext_t pointers passed
 // to a signal handler using C, as they are often hidden in a union.
 // Returns  and, if available, PC where signal occurred.
diff --git a/libgo/runtime/go-signal.c b/libgo/runtime/go-signal.c
index a07fdeafeb4..b429fdb2403 100644
--- a/libgo/runtime/go-signal.c
+++ b/libgo/runtime/go-signal.c
@@ -179,6 +179,18 @@ setSigactionHandler(struct sigaction* sa, uintptr handler)
 // C code to fetch values from the siginfo_t and ucontext_t pointers
 // passed to a signal handler.
 
+uintptr getSiginfoCode(siginfo_t *)
+   __attribute__ ((no_split_stack));
+
+uintptr getSiginfoCode(siginfo_t *)
+   __asm__ (GOSYM_PREFIX "runtime.getSiginfoCode");
+
+uintptr
+getSiginfoCode(siginfo_t *info)
+{
+   return (uintptr)(info->si_code);
+}
+
 struct getSiginfoRet {
uintptr sigaddr;
uintptr sigpc;

Re: [PATCH][v2], rs6000, PR/target 94622, Be more careful with plq for atomic_load

[Aaron Sawdey via Gcc-patches]

For future architecture with prefix instructions, always use plq
rather than lq for atomic load of quadword. Then we never have to
do the doubleword swap on little endian. Before this fix, -mno-pcrel
would generate lq with the doubleword swap (which was ok) and -mpcrel
would generate plq, also with the doubleword swap, which was wrong.

So, of course you can't use set_attr with an if_then_else. The below
code actually builds and passes regstrap on ppc64le power9.

OK for trunk?

Thanks,
Aaron


2020-04-20  Aaron Sawdey  

PR target/94622
* config/rs6000/sync.md (load_quadpti): Add attr "prefixed"
if TARGET_PREFIXED.
(atomic_load): Do not swap doublewords if TARGET_PREFIXED as
plq will be used and doesn't need it.
---
 gcc/config/rs6000/sync.md | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/gcc/config/rs6000/sync.md b/gcc/config/rs6000/sync.md
index f27edc77b6a..96cef082dd5 100644
--- a/gcc/config/rs6000/sync.md
+++ b/gcc/config/rs6000/sync.md
@@ -129,7 +129,10 @@ (define_insn "load_quadpti"
   "TARGET_SYNC_TI
&& !reg_mentioned_p (operands[0], operands[1])"
   "lq %0,%1"
-  [(set_attr "type" "load")])
+  [(set_attr "type" "load")
+   (set (attr "prefixed") (if_then_else (match_test "TARGET_PREFIXED")
+(const_string "yes")
+(const_string "no")))])
 
 (define_expand "atomic_load"
   [(set (match_operand:AINT 0 "register_operand")  ;; output
@@ -162,7 +165,7 @@ (define_expand "atomic_load"
 
   emit_insn (gen_load_quadpti (pti_reg, op1));
 
-  if (WORDS_BIG_ENDIAN)
+  if (WORDS_BIG_ENDIAN || TARGET_PREFIXED)
emit_move_insn (op0, gen_lowpart (TImode, pti_reg));
   else
{
-- 
2.17.1

Re: [PATCH v2] c++: Fix ICE with { } as template argument [PR94592]

[Marek Polacek via Gcc-patches]

On Mon, Apr 20, 2020 at 06:37:08PM -0400, Jason Merrill wrote:
> On 4/20/20 4:44 PM, Marek Polacek wrote:
> > On Mon, Apr 20, 2020 at 11:51:59AM -0400, Jason Merrill wrote:
> > > On 4/17/20 4:28 PM, Marek Polacek wrote:
> > > > As an extension (there should be a CWG about this though), we support
> > > > braced-init-list as a template argument, but convert_nontype_argument
> > > > had trouble digesting them.  We ICEd because of the double coercion we
> > > > perform for template arguments: convert_nontype_argument called from
> > > > finish_template_type got a { }, and since a class type was involved and
> > > > we were in a template, convert_like created an IMPLICIT_CONV_EXPR.  Then
> > > > the second conversion of the same argument crashed in constexpr.c
> > > > because the IMPLICIT_CONV_EXPR had gotten wrapped in a TARGET_EXPR.
> > > > Another issue was that an IMPLICIT_CONV_EXPR leaked to constexpr.c when
> > > > building an aggregate init.
> > > > 
> > > > We should have instantiated the IMPLICIT_CONV_EXPR in the first call to
> > > > convert_nontype_argument, but we didn't, because the call to
> > > > is_nondependent_constant_expression returned false because it checks
> > > > !BRACE_ENCLOSED_INITIALIZER_P.  Then non_dep was false even though the
> > > > expression didn't contain anything dependent and we didn't instantiate
> > > > it in convert_nontype_argument.  I'm not sure what the point
> > > > of that BRACE_ENCLOSED_INITIALIZER_P. check was, but removing it doesn't
> > > > break anything and fixes these crashes.
> > > 
> > > The point was to avoid trying to get a constant value for an untyped
> > > braced-init-list.  I'm happy to remove the check from these functions, but
> > > let's add it back to maybe_constant_{value,init}, where it was until
> > > r6-7825-geb07f187a471f9a203626aecced17d6947c3cc46 .
> > 
> > Thanks for the pointer.
> > 
> > > Or better, put it in cxx_eval_outermost_constant_expr.
> > 
> > Done here.  Since we didn't set non_constant_p and emit an error, I'm not
> > doing it here, either.
> 
> Hmm, maybe checking_assert allow_non_constant to make sure we don't need an
> error.  OK with that change.
 
Thanks; pushed after having been bootstrapped/regtested on x86_64-pc-linux-gnu.

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

Re: [PATCH][libstd++][PR92156]

[kamlesh kumar via Gcc-patches]

Thank you for reviewing.
without  _Decay to decay_t in the constructor which takes inplace_type_t,
cases like this fails
auto a = std::any(std::in_place_type, 5);

for these constructors, standard does not say anything about
not-sameness checks with any.
https://en.cppreference.com/w/cpp/utility/any/any.

./kamlesh


On Mon, Apr 20, 2020 at 11:54 PM Ville Voutilainen
 wrote:
>
> On Mon, 20 Apr 2020 at 21:09, Ville Voutilainen
>  wrote:
> >
> > On Sat, 18 Apr 2020 at 03:35, kamlesh kumar via Libstdc++
> >  wrote:
> > >
> > > On Fri, Apr 17, 2020, 10:59 PM kamlesh kumar 
> > > wrote:
> > >
> > > > Fixes all this.
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92156
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91630
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90415
> > > >
> > > > On Fri, Apr 17, 2020 at 10:45 PM kamlesh kumar 
> > > > wrote:
> > > > >
> > > > > This patch corrects the requirement  of 4,5 and 6th constructor
> > > > > As per https://en.cppreference.com/w/cpp/utility/any/any.
> >
> > The patch looks correct to me. We have some old cruft there, like the
> > overload your patch removes, it was
> > there to support copy-only types, but LWG issues axed that bit. This
> > constructor indeed should not check is_constructible,
> > because it'll end up instantiating this constructor itself, and
> > compute its constraints, and instantiate itself.
> > The in_place constructor doesn't have that problem, because it won't
> > instantiate itself.
>
> ..except the change from _Decay to decay_t looks wrong. _Decay also
> checks the non-sameness with
> any. That change shouldn't be made.

[PATCH] csa, postreload: Improve csa after recent cselib changes [PR94516]

[Jakub Jelinek via Gcc-patches]

Hi!

This patch addresses a missed optimization caused by the cselib changes.
Already in the past postreload could replace sp = sp + const_int with
sp = regxy if regxy already has the right value, but with the cselib
changes it happens several times more often.  It can result in smaller
code, so it seems undesirable to prevent such optimizations, but
unfortunately it can get into the way of stack adjustment coalescing,
where e.g. if we used to have sp = sp + 32; sp = sp - 8;, previously
we'd turn that into sp = sp + 24;, but now postreload optimizes
into sp = r12; sp = sp - 8; and csa gives up.

The patch just adds a REG_EQUAL note when changing sp = sp + const into
sp = reg, where we remember it was actually a stack adjustment by certain
constant, and the combine-stack-adj changes than make use of those REG_EQUAL
notes, together with LR tracking (csa did enable the note problem, just
didn't simulate each insn) so that we can add the needed clobbers etc.
(taken from the other stack adjustment insn).

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

2020-04-20  Jakub Jelinek  

PR rtl-optimization/94516
* postreload.c (reload_cse_simplify): When replacing sp = sp + const
with sp = reg, add REG_EQUAL note with sp + const.
* combine-stack-adj.c (try_apply_stack_adjustment): Change return
type from int to bool.  Add LIVE and OTHER_INSN arguments.  Undo
postreload sp = sp + const to sp = reg optimization if needed and
possible.
(combine_stack_adjustments_for_block): Add LIVE argument.  Handle
reg = sp insn with sp + const REG_EQUAL note.  Adjust
try_apply_stack_adjustment caller, call
df_simulate_initialize_forwards and df_simulate_one_insn_forwards.
(combine_stack_adjustments): Allocate and free LIVE bitmap,
adjust combine_stack_adjustments_for_block caller.

--- gcc/postreload.c.jj 2020-04-19 12:10:19.042877054 +0200
+++ gcc/postreload.c2020-04-20 12:16:01.672848537 +0200
@@ -97,6 +97,16 @@ reload_cse_simplify (rtx_insn *insn, rtx
   if (NO_FUNCTION_CSE && CALL_P (insn))
 return false;
 
+  /* Remember if this insn has been sp += const_int.  */
+  rtx sp_set = set_for_reg_notes (insn);
+  rtx sp_addend = NULL_RTX;
+  if (sp_set
+  && SET_DEST (sp_set) == stack_pointer_rtx
+  && GET_CODE (SET_SRC (sp_set)) == PLUS
+  && XEXP (SET_SRC (sp_set), 0) == stack_pointer_rtx
+  && CONST_INT_P (XEXP (SET_SRC (sp_set), 1)))
+sp_addend = XEXP (SET_SRC (sp_set), 1);
+
   if (GET_CODE (body) == SET)
 {
   int count = 0;
@@ -180,6 +190,15 @@ reload_cse_simplify (rtx_insn *insn, rtx
reload_cse_simplify_operands (insn, testreg);
 }
 
+  /* If sp += const_int insn is changed into sp = reg;, add REG_EQUAL
+ note so that the stack_adjustments pass can undo it if beneficial.  */
+  if (sp_addend
+  && SET_DEST (sp_set) == stack_pointer_rtx
+  && REG_P (SET_SRC (sp_set)))
+set_dst_reg_note (insn, REG_EQUAL,
+ gen_rtx_PLUS (Pmode, stack_pointer_rtx,
+   sp_addend), stack_pointer_rtx);
+
 done:
   return (EDGE_COUNT (insn_bb->succs) != insn_bb_succs);
 }
--- gcc/combine-stack-adj.c.jj  2020-01-12 11:54:36.221416305 +0100
+++ gcc/combine-stack-adj.c 2020-04-20 14:52:47.294323991 +0200
@@ -70,9 +70,10 @@ static rtx single_set_for_csa (rtx_insn
 static void free_csa_reflist (struct csa_reflist *);
 static struct csa_reflist *record_one_stack_ref (rtx_insn *, rtx *,
 struct csa_reflist *);
-static int try_apply_stack_adjustment (rtx_insn *, struct csa_reflist *,
-  HOST_WIDE_INT, HOST_WIDE_INT);
-static void combine_stack_adjustments_for_block (basic_block);
+static bool try_apply_stack_adjustment (rtx_insn *, struct csa_reflist *,
+   HOST_WIDE_INT, HOST_WIDE_INT,
+   bitmap, rtx_insn *);
+static void combine_stack_adjustments_for_block (basic_block, bitmap);
 
 
 /* Main entry point for stack adjustment combination.  */
@@ -81,9 +82,12 @@ static void
 combine_stack_adjustments (void)
 {
   basic_block bb;
+  bitmap live = BITMAP_ALLOC (_obstack);
 
   FOR_EACH_BB_FN (bb, cfun)
-combine_stack_adjustments_for_block (bb);
+combine_stack_adjustments_for_block (bb, live);
+
+  BITMAP_FREE (live);
 }
 
 /* Recognize a MEM of the form (sp) or (plus sp const).  */
@@ -219,18 +223,60 @@ no_unhandled_cfa (rtx_insn *insn)
as each of the memories and stack references in REFLIST.  Return true
on success.  */
 
-static int
+static bool
 try_apply_stack_adjustment (rtx_insn *insn, struct csa_reflist *reflist,
-   HOST_WIDE_INT new_adjust, HOST_WIDE_INT delta)
+   HOST_WIDE_INT new_adjust, HOST_WIDE_INT delta,
+   bitmap live, rtx_insn *other_insn)
 {
   struct 

[PATCH] ubsan: Avoid -Wpadded warnings [PR94641]

[Jakub Jelinek via Gcc-patches]

Hi!

-Wpadded warnings aren't really useful for the artificial types that GCC
lays out for ubsan.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2020-04-20  Jakub Jelinek  

PR c/94641
* ubsan.c (ubsan_get_type_descriptor_type,
ubsan_get_source_location_type, ubsan_create_data): Temporarily
disable warn_padded for the layout_type calls.

* c-c++-common/ubsan/pr94641.c: New test.

--- gcc/ubsan.c.jj  2020-01-12 11:54:38.529381484 +0100
+++ gcc/ubsan.c 2020-04-20 09:51:16.805090228 +0200
@@ -229,7 +229,10 @@ ubsan_get_type_descriptor_type (void)
   TYPE_FIELDS (ret) = fields[0];
   TYPE_NAME (ret) = type_decl;
   TYPE_STUB_DECL (ret) = type_decl;
+  int saved_warn_padded = warn_padded;
+  warn_padded = 0;
   layout_type (ret);
+  warn_padded = saved_warn_padded;
   ubsan_type_descriptor_type = ret;
   return ret;
 }
@@ -277,7 +280,10 @@ ubsan_get_source_location_type (void)
   TYPE_FIELDS (ret) = fields[0];
   TYPE_NAME (ret) = type_decl;
   TYPE_STUB_DECL (ret) = type_decl;
+  int saved_warn_padded = warn_padded;
+  warn_padded = 0;
   layout_type (ret);
+  warn_padded = saved_warn_padded;
   ubsan_source_location_type = ret;
   return ret;
 }
@@ -593,7 +599,10 @@ ubsan_create_data (const char *name, int
   TYPE_FIELDS (ret) = fields[0];
   TYPE_NAME (ret) = type_decl;
   TYPE_STUB_DECL (ret) = type_decl;
+  int saved_warn_padded = warn_padded;
+  warn_padded = 0;
   layout_type (ret);
+  warn_padded = saved_warn_padded;
 
   /* Now, fill in the type.  */
   char tmp_name[32];
--- gcc/testsuite/c-c++-common/ubsan/pr94641.c.jj   2020-04-20 
09:54:02.036564064 +0200
+++ gcc/testsuite/c-c++-common/ubsan/pr94641.c  2020-04-20 09:53:01.101495679 
+0200
@@ -0,0 +1,11 @@
+/* PR c/94641 */
+/* { dg-do compile } */
+/* { dg-options "-fsanitize=undefined -Wpadded" } */
+
+void foo (void *) __attribute__((nonnull));
+
+void
+bar (void *p)
+{
+  foo (p);
+}

Jakub

Re: [PATCH v2] c++: Fix ICE with { } as template argument [PR94592]

[Jason Merrill via Gcc-patches]

On 4/20/20 4:44 PM, Marek Polacek wrote:

On Mon, Apr 20, 2020 at 11:51:59AM -0400, Jason Merrill wrote:

On 4/17/20 4:28 PM, Marek Polacek wrote:

As an extension (there should be a CWG about this though), we support
braced-init-list as a template argument, but convert_nontype_argument
had trouble digesting them.  We ICEd because of the double coercion we
perform for template arguments: convert_nontype_argument called from
finish_template_type got a { }, and since a class type was involved and
we were in a template, convert_like created an IMPLICIT_CONV_EXPR.  Then
the second conversion of the same argument crashed in constexpr.c
because the IMPLICIT_CONV_EXPR had gotten wrapped in a TARGET_EXPR.
Another issue was that an IMPLICIT_CONV_EXPR leaked to constexpr.c when
building an aggregate init.

We should have instantiated the IMPLICIT_CONV_EXPR in the first call to
convert_nontype_argument, but we didn't, because the call to
is_nondependent_constant_expression returned false because it checks
!BRACE_ENCLOSED_INITIALIZER_P.  Then non_dep was false even though the
expression didn't contain anything dependent and we didn't instantiate
it in convert_nontype_argument.  I'm not sure what the point
of that BRACE_ENCLOSED_INITIALIZER_P. check was, but removing it doesn't
break anything and fixes these crashes.


The point was to avoid trying to get a constant value for an untyped
braced-init-list.  I'm happy to remove the check from these functions, but
let's add it back to maybe_constant_{value,init}, where it was until
r6-7825-geb07f187a471f9a203626aecced17d6947c3cc46 .


Thanks for the pointer.


Or better, put it in cxx_eval_outermost_constant_expr.


Done here.  Since we didn't set non_constant_p and emit an error, I'm not
doing it here, either.


Hmm, maybe checking_assert allow_non_constant to make sure we don't need 
an error.  OK with that change.



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

-- >8 --
As an extension (there should be a CWG about this though), we support
braced-init-list as a template argument, but convert_nontype_argument
had trouble digesting them.  We ICEd because of the double coercion we
perform for template arguments: convert_nontype_argument called from
finish_template_type got a { }, and since a class type was involved and
we were in a template, convert_like created an IMPLICIT_CONV_EXPR.  Then
the second conversion of the same argument crashed in constexpr.c
because the IMPLICIT_CONV_EXPR had gotten wrapped in a TARGET_EXPR.
Another issue was that an IMPLICIT_CONV_EXPR leaked to constexpr.c when
building an aggregate init.

We should have instantiated the IMPLICIT_CONV_EXPR in the first call to
convert_nontype_argument, but we didn't, because the call to
is_nondependent_constant_expression returned false because it checks
!BRACE_ENCLOSED_INITIALIZER_P.  Then non_dep was false even though the
expression didn't contain anything dependent and we didn't instantiate
it in convert_nontype_argument.  To fix this, check
BRACE_ENCLOSED_INITIALIZER_P in cxx_eval_outermost_constant_expr rather
than in is_nondependent_*.

PR c++/94592
* constexpr.c (cxx_eval_outermost_constant_expr): Return when T is
a BRACE_ENCLOSED_INITIALIZER_P.
(is_nondependent_constant_expression): Don't check
BRACE_ENCLOSED_INITIALIZER_P.
(is_nondependent_static_init_expression): Likewise.

* g++.dg/cpp2a/nontype-class34.C: New test.
* g++.dg/cpp2a/nontype-class35.C: New test.
---
  gcc/cp/constexpr.c   |  5 +++--
  gcc/testsuite/g++.dg/cpp2a/nontype-class34.C | 16 
  gcc/testsuite/g++.dg/cpp2a/nontype-class35.C | 17 +
  3 files changed, 36 insertions(+), 2 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/nontype-class34.C
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/nontype-class35.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index c8e7d083f40..fa592834f0a 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -6534,6 +6534,9 @@ cxx_eval_outermost_constant_expr (tree t, bool 
allow_non_constant,
bool non_constant_p = false;
bool overflow_p = false;
  
+  if (BRACE_ENCLOSED_INITIALIZER_P (t))

+return t;
+
constexpr_global_ctx global_ctx;
constexpr_ctx ctx = { _ctx, NULL, NULL, NULL, NULL, NULL, NULL,
allow_non_constant, strict,
@@ -8295,7 +8298,6 @@ bool
  is_nondependent_constant_expression (tree t)
  {
return (!type_unknown_p (t)
- && !BRACE_ENCLOSED_INITIALIZER_P (t)
  && is_constant_expression (t)
  && !instantiation_dependent_expression_p (t));
  }
@@ -8307,7 +8309,6 @@ bool
  is_nondependent_static_init_expression (tree t)
  {
return (!type_unknown_p (t)
- && !BRACE_ENCLOSED_INITIALIZER_P (t)
  && is_static_init_expression (t)
  && !instantiation_dependent_expression_p (t));
  }
diff --git a/gcc/testsuite/g++.dg/cpp2a/nontype-class34.C 

Re: [PATCH], rs6000, PR/target 94622, Be more careful with plq for atomic_load

[will schmidt via Gcc-patches]

Hi,

On Mon, 2020-04-20 at 14:00 -0500, Aaron Sawdey via Gcc-patches wrote:
> For future architecture with prefix instructions, always use plq
> rather than lq for atomi load of quadword. Then we never have to

atomic :-)

> do the doubleword swap on little endian. Before this fix, -mno-pcrel
> would generate lq with the doubleword swap (which was ok) and -mpcrel
> would generate plq, also with the doubleword swap, which was wrong.
> 
> OK for trunk if regstrap passes on ppc64le power9?

> 
> Thanks,
>Aaron
> 
> 2020-04-20  Aaron Sawdey  
> 
>   PR target/94622
>   * config/rs6000/sync.md (load_quadpti): Make this have attr
> prefixed
>   if TARGET_PREFIXED.

I'd rearrange to be
: Add attr "prefixed" if TARGET_PREFIXED.

but thats mostly cosmetic, so no big deal.  

>   (atomic_load): Do not swap doublewords if TARGET_PREFIXED
> as
>   plq will be used and doesn't need it.

Ok.   


> ---
>  gcc/config/rs6000/sync.md | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/gcc/config/rs6000/sync.md b/gcc/config/rs6000/sync.md
> index f27edc77b6a..64dfda6ef75 100644
> --- a/gcc/config/rs6000/sync.md
> +++ b/gcc/config/rs6000/sync.md
> @@ -129,7 +129,10 @@ (define_insn "load_quadpti"
>"TARGET_SYNC_TI
> && !reg_mentioned_p (operands[0], operands[1])"
>"lq %0,%1"
> -  [(set_attr "type" "load")])
> +  [(set_attr "type" "load")
> +   (set_attr "prefixed" (if_then_else (match_test "TARGET_PREFIXED")
> +  (const_string "yes")
> +  (const_string "no")))])
> 
>  (define_expand "atomic_load"
>[(set (match_operand:AINT 0 "register_operand");;
> output
> @@ -162,7 +165,7 @@ (define_expand "atomic_load"
> 
>emit_insn (gen_load_quadpti (pti_reg, op1));
> 
> -  if (WORDS_BIG_ENDIAN)
> +  if (WORDS_BIG_ENDIAN || TARGET_PREFIXED)
>   emit_move_insn (op0, gen_lowpart (TImode, pti_reg));
>else
>   {

seems straightforward.  lgtm.  

Thanks
-Will

Re: [Patch][OpenMP] Fix 'omp exit data' for Fortran arrays (PR 94635)

[Thomas Schwinge]

Hi!

On 2020-04-17T17:57:06+0200, Tobias Burnus  wrote:
> On 4/17/20 5:54 PM, Tobias Burnus wrote:
>> It turned out that doing
>>   omp enter data map(alloc:FortranArray)
>>   omp exit data map(delete:FortranArray)
>> left the array descriptor (fortranarray [as opposed to
>> fortranarray.data])
>> on the device. (cf. -fdump-tree-omplower in the PR.)
>>
>> Mapping FortranArray again (e.g. "map(tofrom:FortranArray)")
>> then failed by returning garbage.
>>
>> This patch now removes the descriptor with 'data exit',
>> which was passed as MAP_TO_PSET clause to the middle end,
>> but got removed.

So this is a fix-up for trunk r277631 "Fortran/OpenMP] Don't create
"alloc:" for 'target exit data'".  (Also cross-referencing PR92929
"OpenACC/OpenMP 'target' 'exit data'/'update' optimizations".)

>> Instead, the clause is now turned into MAP_DELETE.

Really 'GOMP_MAP_DELETE', or should that rather be 'GOMP_MAP_RELEASE'?
Considering nested data regions, for example:

  - 'enter data' // Increment reference count.
  - 'enter data' // Increment reference count.
  - 'exit data' // Should not "delete" here, but just "release"?
  - 'exit data' // Here, reference count the is zero, so "release" then equals 
"delete".

(I have neither tested this, not fully thought that through, especially
in context of (a) OpenMP, and (b) Fortran.)  ;-)


> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.fortran/target-enter-data-2.F90
> @@ -0,0 +1,40 @@
> +! { dg-additional-options "-DMEM_SHARED" { target offload_device_shared_as } 
> }
> +!
> +! PR middle-end/94635
> +  implicit none

As obvious, pushed the attached to master branch in commit
3f5d94c192b81a3868f32f309dadd5571ef51cdf "Add 'dg-do run' to
'libgomp.fortran/target-enter-data-2.F90'", see attached.


Grüße
 Thomas


-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
>From 3f5d94c192b81a3868f32f309dadd5571ef51cdf Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Mon, 20 Apr 2020 16:15:07 +0200
Subject: [PATCH] Add 'dg-do run' to 'libgomp.fortran/target-enter-data-2.F90'

Fix-up for commit af557050fd011a03d21dc26b31959033061a0443 "[OpenMP] Fix 'omp
exit data' for Fortran arrays (PR 94635)".

	libgomp/
	PR middle-end/94635
	* testsuite/libgomp.fortran/target-enter-data-2.F90: Add 'dg-do
	run'.
---
 libgomp/ChangeLog | 6 ++
 libgomp/testsuite/libgomp.fortran/target-enter-data-2.F90 | 1 +
 2 files changed, 7 insertions(+)

diff --git a/libgomp/ChangeLog b/libgomp/ChangeLog
index b1cf297a0d7..c524abbbfb6 100644
--- a/libgomp/ChangeLog
+++ b/libgomp/ChangeLog
@@ -1,3 +1,9 @@
+2020-04-20  Thomas Schwinge  
+
+	PR middle-end/94635
+	* testsuite/libgomp.fortran/target-enter-data-2.F90: Add 'dg-do
+	run'.
+
 2020-04-20  Tobias Burnus  
 
 	PR middle-end/94120
diff --git a/libgomp/testsuite/libgomp.fortran/target-enter-data-2.F90 b/libgomp/testsuite/libgomp.fortran/target-enter-data-2.F90
index 320d8bf419f..36a2ed5ef11 100644
--- a/libgomp/testsuite/libgomp.fortran/target-enter-data-2.F90
+++ b/libgomp/testsuite/libgomp.fortran/target-enter-data-2.F90
@@ -1,4 +1,5 @@
 ! { dg-additional-options "-DMEM_SHARED" { target offload_device_shared_as } }
+! { dg-do run }
 !
 ! PR middle-end/94635
   implicit none
-- 
2.17.1

[PATCH] correct strncpy range computation in restrict pass (PR 94647)

[Martin Sebor via Gcc-patches]

The restrict pass computes the wrong lower bound of the size
of accesses to member arrays passed to strncpy as the source:
it uses the third argument to the function even though the size
of the read is limited by the length of the source when it is
a string.  This results in false positive -Warray-bounds
warnings in such cases.

The attached patch corrects this bug.  In addition, it adjusts
the range of offsets of the overlap printed in diagnostics to
be in an increasing order (i.e., [LOW, HIGH]), and removes
a hack was in place to adjust the offsets that's obviated by
the fix above.

Tested on x86_64-linux.

Martin
PR middle-end/94647 - bogus -Warray-bounds on strncpy into a larger member array from a smaller array

gcc/ChangeLog:

	PR middle-end/94647
	* gimple-ssa-warn-restrict.c (builtin_access::builtin_access): Correct
	the computation of the lower bound of the source access size.
	(builtin_access::generic_overlap): Remove a hack for setting ranges
	of overlap offsets.

gcc/testsuite/ChangeLog:

	PR middle-end/94647
	* c-c++-common/Warray-bounds-2.c: Adjust a test case and add a new one.
	* c-c++-common/Warray-bounds-3.c: Add tests for missing warnings.
	* c-c++-common/Wrestrict.c: Invert bounds in printed ranges.
	* gcc.dg/Warray-bounds-59.c: New test.
	* gcc.dg/Wrestrict-10.c: Add a missing warning.
	* gcc.dg/Wrestrict-5.c: Adjust text of expected warning.
	* gcc.dg/Wrestrict-6.c: Expect to see a range of overlap offsets.

diff --git a/gcc/gimple-ssa-warn-restrict.c b/gcc/gimple-ssa-warn-restrict.c
index a6a96353a8c..19d2ec09aa5 100644
--- a/gcc/gimple-ssa-warn-restrict.c
+++ b/gcc/gimple-ssa-warn-restrict.c
@@ -831,8 +831,8 @@ builtin_access::builtin_access (gimple *call, builtin_memref ,
 }
   else if (srcref->sizrange[0] == 0 && srcref->sizrange[1] == maxobjsize)
 {
-  /* When the source size is unknown set it to the size of
-	 the destination.  */
+  /* When the size of the source access is unknown set it to the size
+	 of the destination first and adjust it later if necessary.  */
   srcref->sizrange[0] = dstref->sizrange[0];
   srcref->sizrange[1] = dstref->sizrange[1];
 
@@ -842,15 +842,11 @@ builtin_access::builtin_access (gimple *call, builtin_memref ,
 	{
 	  /* Read access by strncpy is constrained by the third
 		 argument but except for a zero bound is at least one.  */
-	  offset_int size = wi::umax (srcref->basesize, 1);
-	  offset_int bound = wi::umin (size, bounds[0]);
-	  if (bound < srcref->sizrange[0])
-		srcref->sizrange[0] = bound;
-	  bound = wi::umin (srcref->basesize, bounds[1]);
+	  srcref->sizrange[0] = bounds[1] > 0 ? 1 : 0;
+	  offset_int bound = wi::umin (srcref->basesize, bounds[1]);
 	  if (bound < srcref->sizrange[1])
 		srcref->sizrange[1] = bound;
 	}
-
 	  /* For string functions, adjust the size range of the source
 	 reference by the inverse boundaries of the offset (because
 	 the higher the offset into the string the shorter its
@@ -859,7 +855,7 @@ builtin_access::builtin_access (gimple *call, builtin_memref ,
 	  && srcref->offrange[1] < srcref->sizrange[0])
 	srcref->sizrange[0] -= srcref->offrange[1];
 	  else
-	srcref->sizrange[0] = 0;
+	srcref->sizrange[0] = 1;
 
 	  if (srcref->offrange[0] > 0)
 	{
@@ -1060,16 +1056,8 @@ builtin_access::generic_overlap ()
   ovloff[0] = HOST_WIDE_INT_MAX;
   ovloff[1] = HOST_WIDE_INT_MIN;
 
-  /* Adjustment to the lower bound of the offset of the overlap to
- account for a subset of unbounded string calls where the size
- of the destination string depends on the length of the source
- which in turn depends on the offset into it.  */
-  bool sub1;
-
   if (stxcpy_p)
 {
-  sub1 = acs.dstoff[0] <= acs.srcoff[0];
-
   /* Iterate over the extreme locations (on the horizontal axis formed
 	 by their offsets) and sizes of two regions and find their smallest
 	 and largest overlap and the corresponding offsets.  */
@@ -1102,11 +1090,9 @@ builtin_access::generic_overlap ()
 }
   else
 {
-  sub1 = !depends_p;
-
   /* Iterate over the extreme locations (on the horizontal axis
-	 formed by their offsets) and sizes of two regions and find
-	 their smallest and largest overlap and the corresponding
+	 formed by their offsets) and sizes of the two regions and
+	 find their smallest and largest overlap and the corresponding
 	 offsets.  */
 
   for (unsigned io = 0; io != 2; ++io)
@@ -1119,15 +1105,6 @@ builtin_access::generic_overlap ()
 	for (unsigned jo = 0; jo != 2; ++jo)
 	  for (unsigned js = 0; js != 2; ++js)
 		{
-		  if (depends_p)
-		{
-		  /* For st{p,r}ncpy the size of the source sequence
-			 depends on the offset into it.  */
-		  if (js)
-			break;
-		  js = !jo;
-		}
-
 		  const offset_int b[2] = {
 		acs.srcoff[jo], acs.srcoff[jo] + acs.srcsiz[js]
 		  };
@@ -1154,8 +1131,9 @@ builtin_access::generic_overlap ()
   ovlsiz[0] = siz[0].to_shwi ();
   

Re: [PATCH] c++: Recursive unification with packs and explicit targs [PR94628]

[Patrick Palka via Gcc-patches]

On Mon, 20 Apr 2020, Jason Merrill wrote:
> On 4/19/20 12:55 PM, Patrick Palka wrote:
> > This PR seems to be similar to PR c++/43382, except that the recursive call
> > to
> > the variadic function with trailing return type in this testcase is
> > additionally
> > given some explicit template arguments.
> > 
> > In the first testcase below, when resolving the recursive call to 'select',
> > fn_type_unification first substitutes in the call's explicit template
> > arguments
> > before doing unification, and so during this substitution the template
> > argument
> > pack for Args is incomplete.
> > 
> > Since the pack is incomplete, the substitution of 'args...' in the trailing
> > return type decltype(f(args...)) is handled by the unsubstituted_packs case
> > of
> > tsubst_pack_expansion.  But the handling of this case happens _before_ we
> > reset
> > local_specializations, and so the substitution ends up reusing the old
> > binding
> > for 'args' from local_specializations rather than building a new one.
> > 
> > This patch fixes this issue by setting up local_specializations sooner in
> > tsubst_pack_expansion, before the handling of the unsubstituted_packs case.
> > It also adds a new policy to local_specialization_stack so that we could use
> > the
> > class here to conditionally replace local_specializations.
> > 
> > Passes 'make check-c++', does this look OK to commit after
> > bootstrap/regtesting?
> > 
> > gcc/cp/ChangeLog:
> > 
> > PR c++/94628
> > * cp-tree.h (lss_policy::lss_inherit): New enumerator.
> > * pt.c (local_specialization_stack::local_specialization_stack):
> > Handle
> > an lss_inherit policy.
> > (local_specialization_stack::~local_specialization_stack): Likewise.
> > (tsubst_pack_expansion): Use a local_specialization_stack instead of
> > manually saving and restoring local_specializations.  Conditionally
> > replace local_specializations sooner, before the handling of the
> > unsubstituted_packs case.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > PR c++/94628
> > * g++.dg/cpp0x/variadic179.C: New test.
> > * g++.dg/cpp0x/variadic180.C: New test.
> > ---
> >   gcc/cp/cp-tree.h |  2 +-
> >   gcc/cp/pt.c  | 38 +++-
> >   gcc/testsuite/g++.dg/cpp0x/variadic179.C | 16 ++
> >   gcc/testsuite/g++.dg/cpp0x/variadic180.C | 25 
> >   4 files changed, 59 insertions(+), 22 deletions(-)
> >   create mode 100644 gcc/testsuite/g++.dg/cpp0x/variadic179.C
> >   create mode 100644 gcc/testsuite/g++.dg/cpp0x/variadic180.C
> > 
> > diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
> > index 000badc21ac..5b3b9507474 100644
> > --- a/gcc/cp/cp-tree.h
> > +++ b/gcc/cp/cp-tree.h
> > @@ -5424,7 +5424,7 @@ enum unification_kind_t {
> >   // An RAII class used to create a new pointer map for local
> >   // specializations. When the stack goes out of scope, the
> >   // previous pointer map is restored.
> > -enum lss_policy { lss_blank, lss_copy };
> > +enum lss_policy { lss_blank, lss_copy, lss_inherit };
> >   class local_specialization_stack
> >   {
> >   public:
> > diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
> > index 9e39f46a090..9cea663514d 100644
> > --- a/gcc/cp/pt.c
> > +++ b/gcc/cp/pt.c
> > @@ -83,7 +83,9 @@ static tree cur_stmt_expr;
> >   local_specialization_stack::local_specialization_stack (lss_policy policy)
> > : saved (local_specializations)
> >   {
> > -  if (policy == lss_blank || !saved)
> > +  if (policy == lss_inherit)
> > +;
> 
> Maybe assert that saved is non-null?

Hmm, it looks like adding an assert to that effect breaks substituting
into the TYPE_ARG_TYPES of a variadic function template, because
local_specializations is not set up until we finish substituting into
the decl and start instantiating the body.

> 
> lss_inherit suggests to me that we could add things and then pop back to the
> previous state, which is the actual meaning of lss_copy.  Maybe lss_nop or
> lss_same instead?

Sounds good, I will commit the patch with lss_inherit changed to
lss_nop shortly (and without the assert I suppose).

> 
> OK with those changes.
> 
> > +  else if (policy == lss_blank || !saved)
> >   local_specializations = new hash_map;
> > else
> >   local_specializations = new hash_map(*saved);
> > @@ -91,8 +93,11 @@ local_specialization_stack::local_specialization_stack
> > (lss_policy policy)
> > local_specialization_stack::~local_specialization_stack ()
> >   {
> > -  delete local_specializations;
> > -  local_specializations = saved;
> > +  if (local_specializations != saved)
> > +{
> > +  delete local_specializations;
> > +  local_specializations = saved;
> > +}
> >   }
> > /* True if we've recursed into fn_type_unification too many times.  */
> > @@ -12694,7 +12699,6 @@ tsubst_pack_expansion (tree t, tree args,
> > tsubst_flags_t complain,
> > bool unsubstituted_fn_pack = false;
> > int i, len = -1;
> > 

[committed] libstdc++: Add test for using istreambuf_iterator with sentinel

[Jonathan Wakely via Gcc-patches]

This test was supposed to be added two months ago as part of commit
120e873484f20d9a0b8400e2e464ac5b2088a747 but was omitted by mistake.

* testsuite/24_iterators/istreambuf_iterator/sentinel.cc: New test.

Tested x86_64-linux, committed to master.


commit 86119f14171a3e660e65004d9a168821c31f297e
Author: Jonathan Wakely 
Date:   Mon Apr 20 22:06:32 2020 +0100

libstdc++: Add test for using istreambuf_iterator with sentinel

This test was supposed to be added two months ago as part of commit
120e873484f20d9a0b8400e2e464ac5b2088a747 but was omitted by mistake.

* testsuite/24_iterators/istreambuf_iterator/sentinel.cc: New test.

diff --git 
a/libstdc++-v3/testsuite/24_iterators/istreambuf_iterator/sentinel.cc 
b/libstdc++-v3/testsuite/24_iterators/istreambuf_iterator/sentinel.cc
new file mode 100644
index 000..c39e83e5804
--- /dev/null
+++ b/libstdc++-v3/testsuite/24_iterators/istreambuf_iterator/sentinel.cc
@@ -0,0 +1,53 @@
+// { dg-options "-std=gnu++2a" }
+// { dg-do run { target c++2a } }
+
+// Copyright (C) 2020 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+#include 
+#include 
+#include 
+
+void
+test01()
+{
+  static_assert( std::sentinel_for> );
+
+  std::istreambuf_iterator i = std::default_sentinel;
+  VERIFY( i == std::default_sentinel );
+  VERIFY( std::default_sentinel == i );
+}
+
+void
+test02()
+{
+  std::istringstream in("abc");
+  std::istreambuf_iterator iter(in);
+  VERIFY( iter != std::default_sentinel );
+  VERIFY( std::default_sentinel != iter );
+
+  std::next(iter, 3);
+  VERIFY( iter == std::default_sentinel );
+  VERIFY( std::default_sentinel == iter );
+}
+
+int main()
+{
+  test01();
+  test02();
+}

[committed] libstdc++: Fix tests that fail in C++20 mode

[Jonathan Wakely via Gcc-patches]

* testsuite/20_util/is_constructible/51185.cc: Make test class a
non-aggregate so that the test verifies the same thing in all -std
modes.
* testsuite/20_util/is_constructible/value-2.cc: Adjust expected
results for some types when paren-init for aggregates is supported.

Tested x86_64-linux, committed to master.

commit 0ea89b15782a4ee92bae0175a0a963752c39076c
Author: Jonathan Wakely 
Date:   Mon Apr 20 22:06:32 2020 +0100

libstdc++: Fix tests that fail in C++20 mode

* testsuite/20_util/is_constructible/51185.cc: Make test class a
non-aggregate so that the test verifies the same thing in all -std
modes.
* testsuite/20_util/is_constructible/value-2.cc: Adjust expected
results for some types when paren-init for aggregates is supported.

diff --git a/libstdc++-v3/testsuite/20_util/is_constructible/51185.cc 
b/libstdc++-v3/testsuite/20_util/is_constructible/51185.cc
index d2750d8607e..8605135ad5a 100644
--- a/libstdc++-v3/testsuite/20_util/is_constructible/51185.cc
+++ b/libstdc++-v3/testsuite/20_util/is_constructible/51185.cc
@@ -20,7 +20,14 @@
 #include 
 
 struct A { };
-struct B : A { };
+struct B : A {
+#if __cpp_aggregate_bases && __cpp_aggregate_paren_init
+  // A user-declared constructor prevents B from being an aggregate.
+  // Otherwise 'B&& b{A{}};' becomes valid in C++17 (__cpp_aggregate_bases),
+  // and 'B&& b(A{});' becomes valid in C++17 (__cpp_aggregate_paren_init).
+  B();
+#endif
+};
 
 // libstdc++/51185
 void f()
diff --git a/libstdc++-v3/testsuite/20_util/is_constructible/value-2.cc 
b/libstdc++-v3/testsuite/20_util/is_constructible/value-2.cc
index c54b749c046..8ba50e1efe7 100644
--- a/libstdc++-v3/testsuite/20_util/is_constructible/value-2.cc
+++ b/libstdc++-v3/testsuite/20_util/is_constructible/value-2.cc
@@ -216,12 +216,20 @@ static_assert(std::is_constructible::value, "Error");
 static_assert(!std::is_constructible::value, "Error");
 static_assert(!std::is_constructible::value, "Error");
 
+#if __cpp_aggregate_bases && __cpp_aggregate_paren_init
+// In C++20 an rvalue reference or const lvalue reference can bind to a
+// temporary of aggregate type that is initialized from a base class value.
+constexpr bool v = true;
+#else
+constexpr bool v = false;
+#endif
+
 static_assert(!std::is_constructible::value, "Error");
-static_assert(!std::is_constructible::value, "Error");
+static_assert(v == std::is_constructible::value, "Error");
 static_assert(!std::is_constructible::value, "Error");
-static_assert(!std::is_constructible::value, "Error");
-static_assert(!std::is_constructible::value, "Error");
-static_assert(!std::is_constructible::value, "Error");
+static_assert(v == std::is_constructible::value, "Error");
+static_assert(v == std::is_constructible::value, "Error");
+static_assert(v == std::is_constructible::value, "Error");
 
 static_assert(!std::is_constructible::value, "Error");
 static_assert(!std::is_constructible::value, "Error");
@@ -754,14 +762,21 @@ 
static_assert(!std::is_constructible&,
  std::initializer_list&>, std::initializer_list,
  std::initializer_list>::value, "Error");
 
+#if __cpp_aggregate_paren_init
+// In C++20 arrays can be initialized using parentheses.
+constexpr bool w = true;
+#else
+constexpr bool w = false;
+#endif
+
 static_assert(!std::is_constructible>,
  int, int>::value, "Error");
 static_assert(!std::is_constructible>, int, int>::value, "Error");
-static_assert(!std::is_constructible::value, "Error");
-static_assert(!std::is_constructible::value, "Error");
-static_assert(!std::is_constructible::value, "Error");
-static_assert(!std::is_constructible::value, "Error");
+static_assert(w == std::is_constructible::value, "Error");
+static_assert(w == std::is_constructible::value, "Error");
+static_assert(w == std::is_constructible::value, "Error");
+static_assert(w == std::is_constructible::value, "Error");
 
 static_assert(!std::is_constructible::value, "Error");
 static_assert(!std::is_constructible::value, "Error");

Re: [PATCH v2] c++: Fix ICE with { } as template argument [PR94592]

[Marek Polacek via Gcc-patches]

On Mon, Apr 20, 2020 at 11:51:59AM -0400, Jason Merrill wrote:
> On 4/17/20 4:28 PM, Marek Polacek wrote:
> > As an extension (there should be a CWG about this though), we support
> > braced-init-list as a template argument, but convert_nontype_argument
> > had trouble digesting them.  We ICEd because of the double coercion we
> > perform for template arguments: convert_nontype_argument called from
> > finish_template_type got a { }, and since a class type was involved and
> > we were in a template, convert_like created an IMPLICIT_CONV_EXPR.  Then
> > the second conversion of the same argument crashed in constexpr.c
> > because the IMPLICIT_CONV_EXPR had gotten wrapped in a TARGET_EXPR.
> > Another issue was that an IMPLICIT_CONV_EXPR leaked to constexpr.c when
> > building an aggregate init.
> > 
> > We should have instantiated the IMPLICIT_CONV_EXPR in the first call to
> > convert_nontype_argument, but we didn't, because the call to
> > is_nondependent_constant_expression returned false because it checks
> > !BRACE_ENCLOSED_INITIALIZER_P.  Then non_dep was false even though the
> > expression didn't contain anything dependent and we didn't instantiate
> > it in convert_nontype_argument.  I'm not sure what the point
> > of that BRACE_ENCLOSED_INITIALIZER_P. check was, but removing it doesn't
> > break anything and fixes these crashes.
> 
> The point was to avoid trying to get a constant value for an untyped
> braced-init-list.  I'm happy to remove the check from these functions, but
> let's add it back to maybe_constant_{value,init}, where it was until
> r6-7825-geb07f187a471f9a203626aecced17d6947c3cc46 .

Thanks for the pointer.

> Or better, put it in cxx_eval_outermost_constant_expr.

Done here.  Since we didn't set non_constant_p and emit an error, I'm not
doing it here, either.

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

-- >8 --
As an extension (there should be a CWG about this though), we support
braced-init-list as a template argument, but convert_nontype_argument
had trouble digesting them.  We ICEd because of the double coercion we
perform for template arguments: convert_nontype_argument called from
finish_template_type got a { }, and since a class type was involved and
we were in a template, convert_like created an IMPLICIT_CONV_EXPR.  Then
the second conversion of the same argument crashed in constexpr.c
because the IMPLICIT_CONV_EXPR had gotten wrapped in a TARGET_EXPR.
Another issue was that an IMPLICIT_CONV_EXPR leaked to constexpr.c when
building an aggregate init.

We should have instantiated the IMPLICIT_CONV_EXPR in the first call to
convert_nontype_argument, but we didn't, because the call to
is_nondependent_constant_expression returned false because it checks
!BRACE_ENCLOSED_INITIALIZER_P.  Then non_dep was false even though the
expression didn't contain anything dependent and we didn't instantiate
it in convert_nontype_argument.  To fix this, check
BRACE_ENCLOSED_INITIALIZER_P in cxx_eval_outermost_constant_expr rather
than in is_nondependent_*.

PR c++/94592
* constexpr.c (cxx_eval_outermost_constant_expr): Return when T is
a BRACE_ENCLOSED_INITIALIZER_P.
(is_nondependent_constant_expression): Don't check
BRACE_ENCLOSED_INITIALIZER_P.
(is_nondependent_static_init_expression): Likewise.

* g++.dg/cpp2a/nontype-class34.C: New test.
* g++.dg/cpp2a/nontype-class35.C: New test.
---
 gcc/cp/constexpr.c   |  5 +++--
 gcc/testsuite/g++.dg/cpp2a/nontype-class34.C | 16 
 gcc/testsuite/g++.dg/cpp2a/nontype-class35.C | 17 +
 3 files changed, 36 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/nontype-class34.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/nontype-class35.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index c8e7d083f40..fa592834f0a 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -6534,6 +6534,9 @@ cxx_eval_outermost_constant_expr (tree t, bool 
allow_non_constant,
   bool non_constant_p = false;
   bool overflow_p = false;
 
+  if (BRACE_ENCLOSED_INITIALIZER_P (t))
+return t;
+
   constexpr_global_ctx global_ctx;
   constexpr_ctx ctx = { _ctx, NULL, NULL, NULL, NULL, NULL, NULL,
allow_non_constant, strict,
@@ -8295,7 +8298,6 @@ bool
 is_nondependent_constant_expression (tree t)
 {
   return (!type_unknown_p (t)
- && !BRACE_ENCLOSED_INITIALIZER_P (t)
  && is_constant_expression (t)
  && !instantiation_dependent_expression_p (t));
 }
@@ -8307,7 +8309,6 @@ bool
 is_nondependent_static_init_expression (tree t)
 {
   return (!type_unknown_p (t)
- && !BRACE_ENCLOSED_INITIALIZER_P (t)
  && is_static_init_expression (t)
  && !instantiation_dependent_expression_p (t));
 }
diff --git a/gcc/testsuite/g++.dg/cpp2a/nontype-class34.C 
b/gcc/testsuite/g++.dg/cpp2a/nontype-class34.C
new file mode 100644
index 

[PATCH] c++: Constrained inherited constructor template [PR94549]

[Patrick Palka via Gcc-patches]

A comment in satisfy_declaration constraints says

  /* For inherited constructors, consider the original declaration;
 it has the correct template information attached. */
  d = strip_inheriting_ctors (d);

But this comment seems to be false when the inherited constructor points to an
instantiation of a constructor template.  In this case, DECL_TEMPLATE_INFO is
correct and DECL_INHERITED_CTOR points to the constructor template of the base
class rather than to the particular instantiation of the constructor template
(and so the DECL_TI_ARGS of the DECL_INHERITED_CTOR are in their dependent
form).

So doing strip_inheriting_ctors in this case then eventually leads to
satisfy_associated_constraints returning true regardless of the constraints
themselves, due to the passed in 'args' being dependent.

Since DECL_TEMPLATE_INFO seems to be non-NULL for an inherited constructor only
when the inherited constructor points to an instantiation of a constructor
template, this patch fixes this issue by avoiding to call strip_inheriting_ctors
when DECL_TEMPLATE_INFO is already non-NULL.

There is another unguarded call to strip_inheriting_ctors in
get_normalized_constraints_from_decl, but this one seems to be safe to do
unconditionally because the rest of that function doesn't need/look at the
DECL_TI_ARGS of the decl.

Passes 'make check-c++', does this look OK to commit after bootstrap/regtesting?

gcc/cp/ChangeLog:

PR c++/94549
* constraint.cc (satisfy_declaration_constraints): Don't strip the
inherited constructor if it already has template information.

gcc/testsuite/ChangeLog:

PR c++/94549
* g++.dg/concepts/inherit-ctor3.C: Adjust expected diagnostics.
* g++.dg/cpp2a/concepts-inherit-ctor4.C: Adjust expected diagnostics.
* g++.dg/cpp2a/concepts-inherit-ctor8.C: New test.
---
 gcc/cp/constraint.cc  |  7 ---
 gcc/testsuite/g++.dg/concepts/inherit-ctor3.C |  4 ++--
 .../g++.dg/cpp2a/concepts-inherit-ctor4.C |  4 ++--
 .../g++.dg/cpp2a/concepts-inherit-ctor8.C | 20 +++
 4 files changed, 28 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-inherit-ctor8.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index 320792195d6..b76402c2f85 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -2737,9 +2737,10 @@ satisfy_declaration_constraints (tree t, subst_info info)
 {
   gcc_assert (DECL_P (t));
 
-  /* For inherited constructors, consider the original declaration;
- it has the correct template information attached. */
-  if (flag_new_inheriting_ctors)
+  if (!DECL_TEMPLATE_INFO (t))
+/* For inherited constructors without template information, consider
+   the original declaration; it has the correct template information
+   attached.  */
 t = strip_inheriting_ctors (t);
 
   /* Update the declaration for diagnostics.  */
diff --git a/gcc/testsuite/g++.dg/concepts/inherit-ctor3.C 
b/gcc/testsuite/g++.dg/concepts/inherit-ctor3.C
index abfe96e8240..6b7a7a43910 100644
--- a/gcc/testsuite/g++.dg/concepts/inherit-ctor3.C
+++ b/gcc/testsuite/g++.dg/concepts/inherit-ctor3.C
@@ -12,12 +12,12 @@ template
 
 template
   struct S2 : S1 { // { dg-error "no matching function" }
-using S1::S1; // { dg-error "no matching function" }
+using S1::S1;
   };
 
 struct X { } x;
 
 int main() {
-  S2 s1(0); // { dg-error "use of deleted function" }
+  S2 s1(0); // { dg-error "no matching function" }
   S2 s2; // { dg-error "use of deleted function" }
 }
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-inherit-ctor4.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-inherit-ctor4.C
index 75190eb3413..34eaf22c26c 100644
--- a/gcc/testsuite/g++.dg/cpp2a/concepts-inherit-ctor4.C
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-inherit-ctor4.C
@@ -10,9 +10,9 @@ template
 
 template
   struct S2 : S1 {
-using S1::S1; // { dg-error "no matching function" }
+using S1::S1;
   };
 
 int main() {
-  S2 s(0); // { dg-error "use of deleted function" }
+  S2 s(0); // { dg-error "no matching function" }
 }
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-inherit-ctor8.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-inherit-ctor8.C
new file mode 100644
index 000..5b571e32318
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-inherit-ctor8.C
@@ -0,0 +1,20 @@
+// PR c++/94549
+// { dg-do compile { target concepts } }
+
+struct base {
+  template 
+requires false
+  base(type);
+
+  template 
+requires true
+  base(type);
+};
+
+struct derived : base {
+  using base::base;
+};
+
+void foo() {
+  derived{'G'};
+}
-- 
2.26.1.107.gefe3874640

Re: [PATCH] c++: Detect long double -> double narrowing [PR94590]

[Jason Merrill via Gcc-patches]

On 4/20/20 12:25 PM, Marek Polacek wrote:

This PR points out that we don't detect long double -> double narrowing
when long double happens to have the same precision as double; on x86_64
this can be achieved by -mlong-double-64.

[dcl.init.list]#7.2 specifically says "from long double to double or float,
or from double to float", but check_narrowing only checks

   TYPE_PRECISION (type) < TYPE_PRECISION (ftype)

so we need to handle the other cases too, e.g. by same_type_p as in
the following patch.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
Or should this wait till GCC 11?  (Though I don't expect that this problem
is common enough.)


OK for GCC 11.


PR c++/94590 - Detect long double -> double narrowing.
* typeck2.c (check_narrowing): Detect long double -> double
narrowing even when double and long double have the same
precision.  Make it handle conversions to float too.

* g++.dg/cpp0x/Wnarrowing18.C: New test.
---
  gcc/cp/typeck2.c  |  9 -
  gcc/testsuite/g++.dg/cpp0x/Wnarrowing18.C | 15 +++
  2 files changed, 23 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/Wnarrowing18.C

diff --git a/gcc/cp/typeck2.c b/gcc/cp/typeck2.c
index 56fd9bafa7e..2165978bf1c 100644
--- a/gcc/cp/typeck2.c
+++ b/gcc/cp/typeck2.c
@@ -1008,10 +1008,17 @@ check_narrowing (tree type, tree init, tsubst_flags_t 
complain,
  || !int_fits_type_p (init, type)))
ok = false;
  }
+  /* [dcl.init.list]#7.2: "from long double to double or float, or from
+  double to float".  */
else if (TREE_CODE (ftype) == REAL_TYPE
   && TREE_CODE (type) == REAL_TYPE)
  {
-  if (TYPE_PRECISION (type) < TYPE_PRECISION (ftype))
+  if ((same_type_p (ftype, long_double_type_node)
+  && (same_type_p (type, double_type_node)
+  || same_type_p (type, float_type_node)))
+ || (same_type_p (ftype, double_type_node)
+ && same_type_p (type, float_type_node))
+ || (TYPE_PRECISION (type) < TYPE_PRECISION (ftype)))
{
  if (TREE_CODE (init) == REAL_CST)
{
diff --git a/gcc/testsuite/g++.dg/cpp0x/Wnarrowing18.C 
b/gcc/testsuite/g++.dg/cpp0x/Wnarrowing18.C
new file mode 100644
index 000..0dc7075cd62
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/Wnarrowing18.C
@@ -0,0 +1,15 @@
+// PR c++/94590 - Detect long double -> double narrowing.
+// { dg-do compile { target c++11 } }
+// { dg-additional-options "-mlong-double-64" { target x86_64-*-* i?86-*-* } }
+
+int
+main ()
+{
+  using T = long double;
+  extern long double ld;
+  extern T ld2;
+  extern const T ld3;
+  double d{ld}; // { dg-error "narrowing conversion" }
+  double d2{ld2}; // { dg-error "narrowing conversion" }
+  double d3{ld3}; // { dg-error "narrowing conversion" }
+}

base-commit: 5da301cbd81c41b2e9629f55dd1b1889f7dae75e

Re: [PATCH] c++: Fix bogus -Wparentheses warning with fold-expression [PR94505]

[Jason Merrill via Gcc-patches]

On 4/19/20 12:59 PM, Marek Polacek wrote:

We issue bogus -Wparentheses warnings (3 of them!) for this fold expression:

   ((B && true) || ...)

Firstly, issuing a warning for a compiler-generated expression is wrong
and secondly, B && true must be wrapped in ( ) otherwise you'll get
error: binary expression in operand of fold-expression.

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


OK.


PR c++/94505 - bogus -Wparentheses warning with fold-expression.
* pt.c (fold_expression): Add warning_sentinel for -Wparentheses
before calling build_x_binary_op.

* g++.dg/cpp1z/fold11.C: New test.
---
  gcc/cp/pt.c |  1 +
  gcc/testsuite/g++.dg/cpp1z/fold11.C | 12 
  2 files changed, 13 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/cpp1z/fold11.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 9e39f46a090..5d5941eddb7 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -12356,6 +12356,7 @@ fold_expression (tree t, tree left, tree right, 
tsubst_flags_t complain)
if (FOLD_EXPR_MODIFY_P (t))
  return build_x_modify_expr (input_location, left, code, right, complain);
  
+  warning_sentinel s(warn_parentheses);

switch (code)
  {
  case COMPOUND_EXPR:
diff --git a/gcc/testsuite/g++.dg/cpp1z/fold11.C 
b/gcc/testsuite/g++.dg/cpp1z/fold11.C
new file mode 100644
index 000..09a30555eee
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/fold11.C
@@ -0,0 +1,12 @@
+// PR c++/94505 - bogus -Wparentheses warning with fold-expression.
+// { dg-do compile { target c++17 } }
+// { dg-options "-Wparentheses" }
+
+template 
+bool foo () {
+return ((B && true) || ...); // { dg-bogus "suggest parentheses" }
+}
+
+int main () {
+foo ();
+}

base-commit: fc186077486fb6e5453157ad8507c66d0a34017c

Re: [PATCH] c++: Recursive unification with packs and explicit targs [PR94628]

[Jason Merrill via Gcc-patches]

On 4/19/20 12:55 PM, Patrick Palka wrote:

This PR seems to be similar to PR c++/43382, except that the recursive call to
the variadic function with trailing return type in this testcase is additionally
given some explicit template arguments.

In the first testcase below, when resolving the recursive call to 'select',
fn_type_unification first substitutes in the call's explicit template arguments
before doing unification, and so during this substitution the template argument
pack for Args is incomplete.

Since the pack is incomplete, the substitution of 'args...' in the trailing
return type decltype(f(args...)) is handled by the unsubstituted_packs case of
tsubst_pack_expansion.  But the handling of this case happens _before_ we reset
local_specializations, and so the substitution ends up reusing the old binding
for 'args' from local_specializations rather than building a new one.

This patch fixes this issue by setting up local_specializations sooner in
tsubst_pack_expansion, before the handling of the unsubstituted_packs case.
It also adds a new policy to local_specialization_stack so that we could use the
class here to conditionally replace local_specializations.

Passes 'make check-c++', does this look OK to commit after bootstrap/regtesting?

gcc/cp/ChangeLog:

PR c++/94628
* cp-tree.h (lss_policy::lss_inherit): New enumerator.
* pt.c (local_specialization_stack::local_specialization_stack): Handle
an lss_inherit policy.
(local_specialization_stack::~local_specialization_stack): Likewise.
(tsubst_pack_expansion): Use a local_specialization_stack instead of
manually saving and restoring local_specializations.  Conditionally
replace local_specializations sooner, before the handling of the
unsubstituted_packs case.

gcc/testsuite/ChangeLog:

PR c++/94628
* g++.dg/cpp0x/variadic179.C: New test.
* g++.dg/cpp0x/variadic180.C: New test.
---
  gcc/cp/cp-tree.h |  2 +-
  gcc/cp/pt.c  | 38 +++-
  gcc/testsuite/g++.dg/cpp0x/variadic179.C | 16 ++
  gcc/testsuite/g++.dg/cpp0x/variadic180.C | 25 
  4 files changed, 59 insertions(+), 22 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/variadic179.C
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/variadic180.C

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 000badc21ac..5b3b9507474 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -5424,7 +5424,7 @@ enum unification_kind_t {
  // An RAII class used to create a new pointer map for local
  // specializations. When the stack goes out of scope, the
  // previous pointer map is restored.
-enum lss_policy { lss_blank, lss_copy };
+enum lss_policy { lss_blank, lss_copy, lss_inherit };
  class local_specialization_stack
  {
  public:
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 9e39f46a090..9cea663514d 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -83,7 +83,9 @@ static tree cur_stmt_expr;
  local_specialization_stack::local_specialization_stack (lss_policy policy)
: saved (local_specializations)
  {
-  if (policy == lss_blank || !saved)
+  if (policy == lss_inherit)
+;


Maybe assert that saved is non-null?

lss_inherit suggests to me that we could add things and then pop back to 
the previous state, which is the actual meaning of lss_copy.  Maybe 
lss_nop or lss_same instead?


OK with those changes.


+  else if (policy == lss_blank || !saved)
  local_specializations = new hash_map;
else
  local_specializations = new hash_map(*saved);
@@ -91,8 +93,11 @@ local_specialization_stack::local_specialization_stack 
(lss_policy policy)
  
  local_specialization_stack::~local_specialization_stack ()

  {
-  delete local_specializations;
-  local_specializations = saved;
+  if (local_specializations != saved)
+{
+  delete local_specializations;
+  local_specializations = saved;
+}
  }
  
  /* True if we've recursed into fn_type_unification too many times.  */

@@ -12694,7 +12699,6 @@ tsubst_pack_expansion (tree t, tree args, 
tsubst_flags_t complain,
bool unsubstituted_fn_pack = false;
int i, len = -1;
tree result;
-  hash_map *saved_local_specializations = NULL;
bool need_local_specializations = false;
int levels;
  
@@ -12893,7 +12897,15 @@ tsubst_pack_expansion (tree t, tree args, tsubst_flags_t complain,

= build_extra_args (pattern, args, complain);
return t;
  }
-  else if (unsubstituted_packs)
+
+  /* If NEED_LOCAL_SPECIALIZATIONS then we're in a late-specified return
+ type, so create our own local specializations map; the current map is
+ either NULL or (in the case of recursive unification) might have
+ bindings that we don't want to use or alter.  */
+  local_specialization_stack lss (need_local_specializations
+ ? lss_blank : lss_inherit);
+
+  if (unsubstituted_packs)
  {
/* 

Re: [PATCH] c++: Fix crash with template spec in different namespace [PR94255]

[Jason Merrill via Gcc-patches]

On 4/18/20 10:49 AM, Marek Polacek wrote:

This is an ICE on invalid, because we're specializing S::foo in the
wrong namespace.  cp_parser_class_specifier_1 parses S::foo in M
and then it tries to push the nested-name-specifier of foo, which is
S.  By that, we're breaking the assumption of push_inner_scope that
the pushed scope must be a scope nested inside current scope: current
scope is M, but the namespace context of S is N, and N is not nested
in M, so we fell into an infinite loop in push_inner_scope_r.

(cp_parser_class_head called check_specialization_namespace which already
gave a permerror.)

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


This doesn't seem to be a regresssion, so OK for stage 1.


PR c++/94255
* parser.c (cp_parser_class_specifier_1): Check that the scope is
nested inside current scope before pushing it.

* g++.dg/template/spec41.C: New test.
---
  gcc/cp/parser.c|  7 ++-
  gcc/testsuite/g++.dg/template/spec41.C | 17 +
  2 files changed, 23 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/template/spec41.C

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index d2f3f853cb4..d4482ef5a90 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -23858,7 +23858,12 @@ cp_parser_class_specifier_1 (cp_parser* parser)
if (nested_name_specifier_p)
  {
scope = CP_DECL_CONTEXT (TYPE_MAIN_DECL (type));
-  old_scope = push_inner_scope (scope);
+  /* SCOPE must be a scope nested inside current scope.  */
+  if (is_nested_namespace (current_namespace,
+  decl_namespace_context (scope)))
+   old_scope = push_inner_scope (scope); > +  else
+   nested_name_specifier_p = false;
  }
type = begin_class_definition (type);
  
diff --git a/gcc/testsuite/g++.dg/template/spec41.C b/gcc/testsuite/g++.dg/template/spec41.C

new file mode 100644
index 000..249fde74c3a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/spec41.C
@@ -0,0 +1,17 @@
+// PR c++/94255 - crash with template spec in different namespace.
+// { dg-do compile { target c++11 } }
+
+namespace N {
+  class S {
+template  struct foo;
+  };
+  namespace M {
+using S = ::N::S;
+  }
+}
+
+namespace N {
+  namespace M {
+template <> struct S::foo {}; // { dg-error "specialization of" }
+  }
+}

base-commit: b57e1621eb76ba80c949ad098829aa8171a8c4ab

Re: [PATCH] coroutines: Fix STRIP_NOPS usage.

[Nathan Sidwell]

On 4/20/20 2:25 PM, Marek Polacek wrote:

parm = STRIP_NOPS (parm); is unnecessary and generates
warning: operation on 'parm' may be undefined [-Wsequence-point]
when cp/coroutines.cc is compiled with -std=c++11.

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


yup, thanks for catching it.



--
Nathan Sidwell

[PATCH], rs6000, PR/target 94622, Be more careful with plq for atomic_load

[Aaron Sawdey via Gcc-patches]

For future architecture with prefix instructions, always use plq
rather than lq for atomi load of quadword. Then we never have to
do the doubleword swap on little endian. Before this fix, -mno-pcrel
would generate lq with the doubleword swap (which was ok) and -mpcrel
would generate plq, also with the doubleword swap, which was wrong.

OK for trunk if regstrap passes on ppc64le power9?

Thanks,
   Aaron

2020-04-20  Aaron Sawdey  

PR target/94622
* config/rs6000/sync.md (load_quadpti): Make this have attr prefixed
if TARGET_PREFIXED.
(atomic_load): Do not swap doublewords if TARGET_PREFIXED as
plq will be used and doesn't need it.
---
 gcc/config/rs6000/sync.md | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/gcc/config/rs6000/sync.md b/gcc/config/rs6000/sync.md
index f27edc77b6a..64dfda6ef75 100644
--- a/gcc/config/rs6000/sync.md
+++ b/gcc/config/rs6000/sync.md
@@ -129,7 +129,10 @@ (define_insn "load_quadpti"
   "TARGET_SYNC_TI
&& !reg_mentioned_p (operands[0], operands[1])"
   "lq %0,%1"
-  [(set_attr "type" "load")])
+  [(set_attr "type" "load")
+   (set_attr "prefixed" (if_then_else (match_test "TARGET_PREFIXED")
+  (const_string "yes")
+  (const_string "no")))])
 
 (define_expand "atomic_load"
   [(set (match_operand:AINT 0 "register_operand")  ;; output
@@ -162,7 +165,7 @@ (define_expand "atomic_load"
 
   emit_insn (gen_load_quadpti (pti_reg, op1));
 
-  if (WORDS_BIG_ENDIAN)
+  if (WORDS_BIG_ENDIAN || TARGET_PREFIXED)
emit_move_insn (op0, gen_lowpart (TImode, pti_reg));
   else
{
-- 
2.17.1

[PATCH v2] aarch64: Add TX3 machine model

[Anton Youdkevitch]

Here is the patch introducing thunderxt311 maching model
for the scheduler. A name for the new chip was added to the
list of the names to be recognized as a valid parameter for mcpu
and mtune flags. The TX2 cost model was reused for TX3.

The previously used "cryptic" name for the command line
parameter is replaced with the same "thunderxt311" name.

Bootstrapped on AArch64.

2020-04-20 Anton Youdkevitch 

* config/aarch64/aarch64-cores.def: Add the chip name.
* config/aarch64/aarch64-tune.md: Regenerated.
* gcc/config/aarch64/aarch64.c: Add the cost tables for the chip.
* gcc/config/aarch64/thunderx3t11.md: New file: add the new
machine model for the scheduler
* gcc/config/aarch64/aarch64.md: Include the new model.

---
 gcc/config/aarch64/aarch64-cores.def |   3 +
 gcc/config/aarch64/aarch64-tune.md   |   2 +-
 gcc/config/aarch64/aarch64.c |  27 +
 gcc/config/aarch64/aarch64.md|   1 +
 gcc/config/aarch64/thunderx3t11.md   | 686 +++
 5 files changed, 718 insertions(+), 1 deletion(-)
diff --git a/gcc/config/aarch64/aarch64-cores.def b/gcc/config/aarch64/aarch64-cores.def
index ea9b98b..ece6c34 100644
--- a/gcc/config/aarch64/aarch64-cores.def
+++ b/gcc/config/aarch64/aarch64-cores.def
@@ -95,6 +95,9 @@ AARCH64_CORE("vulcan",  vulcan, thunderx2t99, 8_1A,  AARCH64_FL_FOR_ARCH8_1 | AA
 /* Cavium ('C') cores. */
 AARCH64_CORE("thunderx2t99",  thunderx2t99,  thunderx2t99, 8_1A,  AARCH64_FL_FOR_ARCH8_1 | AARCH64_FL_CRYPTO, thunderx2t99, 0x43, 0x0af, -1)
 
+/* Cavium ('??') cores (TX3). */
+AARCH64_CORE("thunderx3t11",  thunderx3t11,  thunderx3t11, 8_1A,  AARCH64_FL_FOR_ARCH8_1 | AARCH64_FL_CRYPTO, thunderx3t11, 0x43, 0x0b8, 0x0a)
+
 /* ARMv8.2-A Architecture Processors.  */
 
 /* ARM ('A') cores. */
diff --git a/gcc/config/aarch64/aarch64-tune.md b/gcc/config/aarch64/aarch64-tune.md
index 3cc1c4d..573a4a9 100644
--- a/gcc/config/aarch64/aarch64-tune.md
+++ b/gcc/config/aarch64/aarch64-tune.md
@@ -1,5 +1,5 @@
 ;; -*- buffer-read-only: t -*-
 ;; Generated automatically by gentune.sh from aarch64-cores.def
 (define_attr "tune"
-	"cortexa34,cortexa35,cortexa53,cortexa57,cortexa72,cortexa73,thunderx,thunderxt88p1,thunderxt88,octeontx,octeontxt81,octeontxt83,thunderxt81,thunderxt83,emag,xgene1,falkor,qdf24xx,exynosm1,phecda,thunderx2t99p1,vulcan,thunderx2t99,cortexa55,cortexa75,cortexa76,cortexa76ae,cortexa77,cortexa65,cortexa65ae,ares,neoversen1,neoversee1,octeontx2,octeontx2t98,octeontx2t96,octeontx2t93,octeontx2f95,octeontx2f95n,octeontx2f95mm,tsv110,saphira,cortexa57cortexa53,cortexa72cortexa53,cortexa73cortexa35,cortexa73cortexa53,cortexa75cortexa55,cortexa76cortexa55"
+	"cortexa34,cortexa35,cortexa53,cortexa57,cortexa72,cortexa73,thunderx,thunderxt88p1,thunderxt88,octeontx,octeontxt81,octeontxt83,thunderxt81,thunderxt83,emag,xgene1,falkor,qdf24xx,exynosm1,phecda,thunderx2t99p1,vulcan,thunderx2t99,thunderx3t11,cortexa55,cortexa75,cortexa76,cortexa76ae,cortexa77,cortexa65,cortexa65ae,ares,neoversen1,neoversee1,octeontx2,octeontx2t98,octeontx2t96,octeontx2t93,octeontx2f95,octeontx2f95n,octeontx2f95mm,tsv110,saphira,cortexa57cortexa53,cortexa72cortexa53,cortexa73cortexa35,cortexa73cortexa53,cortexa75cortexa55,cortexa76cortexa55"
 	(const (symbol_ref "((enum attr_tune) aarch64_tune)")))
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 24c055d..7abce6a 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -1216,6 +1216,33 @@ static const struct tune_params thunderx2t99_tunings =
   _prefetch_tune
 };
 
+static const struct tune_params thunderx3t11_tunings =
+{
+  _extra_costs,
+  _addrcost_table,
+  _regmove_cost,
+  _vector_cost,
+  _branch_cost,
+  _approx_modes,
+  SVE_NOT_IMPLEMENTED, /* sve_width  */
+  4, /* memmov_cost.  */
+  4, /* issue_rate.  */
+  (AARCH64_FUSE_ALU_BRANCH | AARCH64_FUSE_AES_AESMC
+   | AARCH64_FUSE_ALU_CBZ), /* fusible_ops  */
+  "16",	/* function_align.  */
+  "8",	/* jump_align.  */
+  "16",	/* loop_align.  */
+  3,	/* int_reassoc_width.  */
+  2,	/* fp_reassoc_width.  */
+  2,	/* vec_reassoc_width.  */
+  2,	/* min_div_recip_mul_sf.  */
+  2,	/* min_div_recip_mul_df.  */
+  0,	/* max_case_values.  */
+  tune_params::AUTOPREFETCHER_WEAK,	/* autoprefetcher_model.  */
+  (AARCH64_EXTRA_TUNE_NONE),	/* tune_flags.  */
+  _prefetch_tune
+};
+
 static const struct tune_params neoversen1_tunings =
 {
   _extra_costs,
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index c7c4d1d..d2123f8 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -438,6 +438,7 @@
 (include "../arm/xgene1.md")
 (include "thunderx2t99.md")
 (include "tsv110.md")
+(include "thunderx3t11.md")
 
 ;; ---
 ;; Jumps and other miscellaneous insns
diff --git a/gcc/config/aarch64/thunderx3t11.md b/gcc/config/aarch64/thunderx3t11.md
new file mode 100644
index 000..8a4b824
--- 

[PATCH] coroutines: Fix STRIP_NOPS usage.

[Marek Polacek via Gcc-patches]

parm = STRIP_NOPS (parm); is unnecessary and generates
warning: operation on 'parm' may be undefined [-Wsequence-point]
when cp/coroutines.cc is compiled with -std=c++11.

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

* coroutines.cc (captures_temporary): Don't assign the result of
STRIP_NOPS to the same variable.
---
 gcc/cp/coroutines.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index 0a8e7521c4f..ceb8daa4e46 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -2652,7 +2652,7 @@ captures_temporary (tree *stmt, int *do_subtree, void *d)
  parm = TREE_OPERAND (parm, 0);
  if (TREE_CODE (parm) == INDIRECT_REF)
parm = TREE_OPERAND (parm, 0);
- parm = STRIP_NOPS (parm);
+ STRIP_NOPS (parm);
}
 
   /* This isn't a temporary.  */

base-commit: 0fe12b0234a06e286df38d7b594abc23d1c371bc
-- 
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA

Re: [PATCH][libstd++][PR92156]

[Ville Voutilainen via Gcc-patches]

On Mon, 20 Apr 2020 at 21:09, Ville Voutilainen
 wrote:
>
> On Sat, 18 Apr 2020 at 03:35, kamlesh kumar via Libstdc++
>  wrote:
> >
> > On Fri, Apr 17, 2020, 10:59 PM kamlesh kumar 
> > wrote:
> >
> > > Fixes all this.
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92156
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91630
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90415
> > >
> > > On Fri, Apr 17, 2020 at 10:45 PM kamlesh kumar 
> > > wrote:
> > > >
> > > > This patch corrects the requirement  of 4,5 and 6th constructor
> > > > As per https://en.cppreference.com/w/cpp/utility/any/any.
>
> The patch looks correct to me. We have some old cruft there, like the
> overload your patch removes, it was
> there to support copy-only types, but LWG issues axed that bit. This
> constructor indeed should not check is_constructible,
> because it'll end up instantiating this constructor itself, and
> compute its constraints, and instantiate itself.
> The in_place constructor doesn't have that problem, because it won't
> instantiate itself.

..except the change from _Decay to decay_t looks wrong. _Decay also
checks the non-sameness with
any. That change shouldn't be made.

Re: [PATCH v2] aarch64: Add TX3 machine model

[Anton Youdkevitch]

Hi Kyrylo,

On 20.4.2020 20:13 , Kyrylo Tkachov wrote:

Hi Anton,


-Original Message-
From: Gcc-patches  On Behalf Of Anton
Youdkevitch
Sent: 20 April 2020 18:05
To: gcc-patches@gcc.gnu.org
Cc: jo...@marvell.com
Subject: [PATCH v2] aarch64: Add TX3 machine model

Here is the patch introducing thunderxt311 maching model
for the scheduler. A name for the new chip was added to the
list of the names to be recognized as a valid parameter for mcpu
and mtune flags. The TX2 cost model was reused for TX3.

The previously used "cryptic" name for the command line
parameter is replaced with the same "thunderxt311" name.

Bootstrapped on AArch64.

Please post the full patch you want applied to trunk.
I think the one you've sent is just a diff from the previous version you've 
posted.

Oh, geez.
You are right. Will resend in a minute.
Thanks a lot!

Re: [PATCH][libstd++][PR92156]

[Ville Voutilainen via Gcc-patches]

On Sat, 18 Apr 2020 at 03:35, kamlesh kumar via Libstdc++
 wrote:
>
> On Fri, Apr 17, 2020, 10:59 PM kamlesh kumar 
> wrote:
>
> > Fixes all this.
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92156
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91630
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90415
> >
> > On Fri, Apr 17, 2020 at 10:45 PM kamlesh kumar 
> > wrote:
> > >
> > > This patch corrects the requirement  of 4,5 and 6th constructor
> > > As per https://en.cppreference.com/w/cpp/utility/any/any.

The patch looks correct to me. We have some old cruft there, like the
overload your patch removes, it was
there to support copy-only types, but LWG issues axed that bit. This
constructor indeed should not check is_constructible,
because it'll end up instantiating this constructor itself, and
compute its constraints, and instantiate itself.
The in_place constructor doesn't have that problem, because it won't
instantiate itself.

[Committed] S/390: Fix PR94666

[Andreas Krebbel via Gcc-patches]

The vector popcount expanders use a hardcoded subreg.  This might lead
to double subregs being generated which then fail to match.  With this
patch simplify_gen_subreg is used instead to fold the subregs.

Boostrapped and regression-tested on IBM z14.

Committed to mainline

gcc/ChangeLog:

2020-04-20  Andreas Krebbel  

* config/s390/vector.md ("popcountv8hi2_vx", "popcountv4si2_vx")
("popcountv2di2_vx"): Use simplify_gen_subreg.

gcc/testsuite/ChangeLog:

2020-04-20  Andreas Krebbel  

* g++.dg/pr94666.C: New test.
---
 gcc/ChangeLog  |  5 +
 gcc/config/s390/vector.md  | 10 +++---
 gcc/testsuite/ChangeLog|  4 
 gcc/testsuite/g++.dg/pr94666.C | 20 
 4 files changed, 36 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/pr94666.C

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index ed3541d1264..721928d931d 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2020-04-20  Andreas Krebbel  
+
+   * config/s390/vector.md ("popcountv8hi2_vx", "popcountv4si2_vx")
+   ("popcountv2di2_vx"): Use simplify_gen_subreg.
+
 2020-04-20  Andreas Krebbel  
 
PR target/94613
diff --git a/gcc/config/s390/vector.md b/gcc/config/s390/vector.md
index 9d3df9813c9..08f2d4cbda6 100644
--- a/gcc/config/s390/vector.md
+++ b/gcc/config/s390/vector.md
@@ -871,7 +871,7 @@
 
 (define_expand "popcountv8hi2_vx"
   [(set (match_dup 2)
-   (unspec:V16QI [(subreg:V16QI (match_operand:V8HI 1 "register_operand" 
"v") 0)]
+   (unspec:V16QI [(match_operand:V8HI 1 "register_operand" "v")]
  UNSPEC_POPCNT))
; Make a copy of the result
(set (match_dup 3) (match_dup 2))
@@ -903,6 +903,8 @@
 ]
   "TARGET_VX && !TARGET_VXE"
 {
+  operands[1] = simplify_gen_subreg (V16QImode, operands[1],
+V8HImode, 0);
   operands[2] = gen_reg_rtx (V16QImode);
   operands[3] = gen_reg_rtx (V16QImode);
   operands[4] = gen_reg_rtx (V16QImode);
@@ -911,20 +913,21 @@
 
 (define_expand "popcountv4si2_vx"
   [(set (match_dup 2)
-   (unspec:V16QI [(subreg:V16QI (match_operand:V4SI 1 "register_operand" 
"v") 0)]
+   (unspec:V16QI [(match_operand:V4SI 1 "register_operand" "v")]
  UNSPEC_POPCNT))
(set (match_operand:V4SI 0 "register_operand" "=v")
(unspec:V4SI [(match_dup 2) (match_dup 3)]
 UNSPEC_VEC_VSUM))]
   "TARGET_VX && !TARGET_VXE"
 {
+  operands[1] = simplify_gen_subreg (V16QImode, operands[1], V4SImode, 0);
   operands[2] = gen_reg_rtx (V16QImode);
   operands[3] = force_reg (V16QImode, CONST0_RTX (V16QImode));
 })
 
 (define_expand "popcountv2di2_vx"
   [(set (match_dup 2)
-   (unspec:V16QI [(subreg:V16QI (match_operand:V2DI 1 "register_operand" 
"v") 0)]
+   (unspec:V16QI [(match_operand:V2DI 1 "register_operand" "v")]
  UNSPEC_POPCNT))
(set (match_dup 3)
(unspec:V4SI [(match_dup 2) (match_dup 4)]
@@ -934,6 +937,7 @@
 UNSPEC_VEC_VSUMG))]
   "TARGET_VX && !TARGET_VXE"
 {
+  operands[1] = simplify_gen_subreg (V16QImode, operands[1], V2DImode, 0);
   operands[2] = gen_reg_rtx (V16QImode);
   operands[3] = gen_reg_rtx (V4SImode);
   operands[4] = force_reg (V16QImode, CONST0_RTX (V16QImode));
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 117eed9e35b..ce31ed0cd44 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,7 @@
+2020-04-20  Andreas Krebbel  
+
+   * g++.dg/pr94666.C: New test.
+
 2020-04-20  Andreas Krebbel  
 
PR target/94613
diff --git a/gcc/testsuite/g++.dg/pr94666.C b/gcc/testsuite/g++.dg/pr94666.C
new file mode 100644
index 000..a9bfb24f795
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr94666.C
@@ -0,0 +1,20 @@
+// { dg-do compile }
+// { dg-options "-O3" }
+// { dg-additional-options "-march=z13" { target s390*-*-* } }
+
+int a, c;
+struct A {
+  int e() {
+int f;
+for (int b = 0; b < 4; b++) {
+  a = __builtin_popcountl(d[b]);
+  f += a;
+}
+return f;
+  }
+  long d[4];
+} * g;
+void h() {
+  for (int b; b; b++)
+c += g[b].e();
+}
-- 
2.17.1

[patch, committed] Add numerous symbol attributes to -fdump-fortran-original

[Thomas Koenig via Gcc-patches]

Hello world,

after finding myself debug a PR where showing all the attributes
of a symbol would have helped enormously (which I realized only
afterwards), I went ahead and added most of the flags to show_attr,
in the hope that this will help all of us debugging some murky corners
of the compiler where attributes are not what they should be.

If you see anything that is still missing, please freel free
to add.

Committed as obvious (no user impact) after testing that
the compiler still compiles :-)

Regards

Thomas

2020-04-20  Thomas Koenig  

* dump-parse-tree.c (show_attr): Add numerous flags, some cleanup.
diff --git a/gcc/fortran/dump-parse-tree.c b/gcc/fortran/dump-parse-tree.c
index d324bfd83c0..f32330685e7 100644
--- a/gcc/fortran/dump-parse-tree.c
+++ b/gcc/fortran/dump-parse-tree.c
@@ -735,7 +735,7 @@ show_attr (symbol_attribute *attr, const char * module)
   if (attr->flavor != FL_UNKNOWN)
 {
   if (attr->flavor == FL_DERIVED && attr->pdt_template)
-   fputs (" (PDT template", dumpfile);
+   fputs (" (PDT-TEMPLATE", dumpfile);
   else
 fprintf (dumpfile, "(%s ", gfc_code2string (flavors, attr->flavor));
 }
@@ -770,6 +770,12 @@ show_attr (symbol_attribute *attr, const char * module)
 fputs (" LEN", dumpfile);
   if (attr->pointer)
 fputs (" POINTER", dumpfile);
+  if (attr->subref_array_pointer)
+fputs (" SUBREF-ARRAY-POINTER", dumpfile);
+  if (attr->cray_pointer)
+fputs (" CRAY-POINTER", dumpfile);
+  if (attr->cray_pointee)
+fputs (" CRAY-POINTEE", dumpfile);
   if (attr->is_protected)
 fputs (" PROTECTED", dumpfile);
   if (attr->value)
@@ -791,6 +797,10 @@ show_attr (symbol_attribute *attr, const char * module)
 fputs (" RESULT", dumpfile);
   if (attr->entry)
 fputs (" ENTRY", dumpfile);
+  if (attr->entry_master)
+fputs (" ENTRY-MASTER", dumpfile);
+  if (attr->mixed_entry_master)
+fputs (" MIXED-ENTRY-MASTER", dumpfile);
   if (attr->is_bind_c)
 fputs (" BIND(C)", dumpfile);
 
@@ -819,15 +829,80 @@ show_attr (symbol_attribute *attr, const char * module)
 
   if (attr->sequence)
 fputs (" SEQUENCE", dumpfile);
+  if (attr->alloc_comp)
+fputs (" ALLOC-COMP", dumpfile);
+  if (attr->pointer_comp)
+fputs (" POINTER-COMP", dumpfile);
+  if (attr->proc_pointer_comp)
+fputs (" PROC-POINTER-COMP", dumpfile);
+  if (attr->private_comp)
+fputs (" PRIVATE-COMP", dumpfile);
+  if (attr->zero_comp)
+fputs (" ZERO-COMP", dumpfile);
+  if (attr->coarray_comp)
+fputs (" COARRAY-COMP", dumpfile);
+  if (attr->lock_comp)
+fputs (" LOCK-COMP", dumpfile);
+  if (attr->event_comp)
+fputs (" EVENT-COMP", dumpfile);
+  if (attr->defined_assign_comp)
+fputs (" DEFINED-ASSIGNED-COMP", dumpfile);
+  if (attr->unlimited_polymorphic)
+fputs (" UNLIMITED-POLYMORPHIC", dumpfile);
+  if (attr->has_dtio_procs)
+fputs (" HAS-DTIO-PROCS", dumpfile);
+  if (attr->caf_token)
+fputs (" CAF-TOKEN", dumpfile);
+  if (attr->select_type_temporary)
+fputs (" SELECT-TYPE-TEMPORARY", dumpfile);
+  if (attr->associate_var)
+fputs (" ASSOCIATE-VAR", dumpfile);
+  if (attr->pdt_kind)
+fputs (" PDT-KIND", dumpfile);
+  if (attr->pdt_len)
+fputs (" PDT-LEN", dumpfile);
+  if (attr->pdt_type)
+fputs (" PDT-TYPE", dumpfile);
+  if (attr->pdt_array)
+fputs (" PDT-ARRAY", dumpfile);
+  if (attr->pdt_string)
+fputs (" PDT-STRING", dumpfile);
+  if (attr->omp_udr_artificial_var)
+fputs (" OMP-UDT-ARTIFICIAL-VAR", dumpfile);
+  if (attr->omp_declare_target)
+fputs (" OMP-DECLARE-TARGET", dumpfile);
+  if (attr->omp_declare_target_link)
+fputs (" OMP-DECLARE-TARGET-LINK", dumpfile);
   if (attr->elemental)
 fputs (" ELEMENTAL", dumpfile);
   if (attr->pure)
 fputs (" PURE", dumpfile);
   if (attr->implicit_pure)
-fputs (" IMPLICIT_PURE", dumpfile);
+fputs (" IMPLICIT-PURE", dumpfile);
   if (attr->recursive)
 fputs (" RECURSIVE", dumpfile);
-
+  if (attr->unmaskable)
+fputs (" UNMASKABKE", dumpfile);
+  if (attr->masked)
+fputs (" MASKED", dumpfile);
+  if (attr->contained)
+fputs (" CONTAINED", dumpfile);
+  if (attr->mod_proc)
+fputs (" MOD-PROC", dumpfile);
+  if (attr->module_procedure)
+fputs (" MODULE-PROCEDURE", dumpfile);
+  if (attr->public_used)
+fputs (" PUBLIC_USED", dumpfile);
+  if (attr->array_outer_dependency)
+fputs (" ARRAY-OUTER-DEPENDENCY", dumpfile);
+  if (attr->noreturn)
+fputs (" NORETURN", dumpfile);
+  if (attr->always_explicit)
+fputs (" ALWAYS-EXPLICIT", dumpfile);
+  if (attr->is_main_program)
+fputs (" IS-MAIN-PROGRAM", dumpfile);
+
+  /* FIXME: Still missing are oacc_routine_lop and ext_attr.  */
   fputc (')', dumpfile);
 }
 

RE: [PATCH v2] aarch64: Add TX3 machine model

[Kyrylo Tkachov]

Hi Anton,

> -Original Message-
> From: Gcc-patches  On Behalf Of Anton
> Youdkevitch
> Sent: 20 April 2020 18:05
> To: gcc-patches@gcc.gnu.org
> Cc: jo...@marvell.com
> Subject: [PATCH v2] aarch64: Add TX3 machine model
> 
> Here is the patch introducing thunderxt311 maching model
> for the scheduler. A name for the new chip was added to the
> list of the names to be recognized as a valid parameter for mcpu
> and mtune flags. The TX2 cost model was reused for TX3.
> 
> The previously used "cryptic" name for the command line
> parameter is replaced with the same "thunderxt311" name.
> 
> Bootstrapped on AArch64.

Please post the full patch you want applied to trunk.
I think the one you've sent is just a diff from the previous version you've 
posted.

Thanks,
Kyrill

> 
> 2020-04-20 Anton Youdkevitch 
> 
> * config/aarch64/aarch64-cores.def: Add the chip name.
> * config/aarch64/aarch64-tune.md: Regenerated.
> * gcc/config/aarch64/aarch64.c: Add the cost tables for the chip.
> * gcc/config/aarch64/thunderx3t11.md: New file: add the new
> machine model for the scheduler
> * gcc/config/aarch64/aarch64.md: Include the new model.
> 
> ---
>  gcc/config/aarch64/aarch64-cores.def |   3 +
>  gcc/config/aarch64/aarch64-tune.md   |   2 +-
>  gcc/config/aarch64/aarch64.c |  27 +
>  gcc/config/aarch64/aarch64.md|   1 +
>  gcc/config/aarch64/thunderx3t11.md   | 686 +++
>  5 files changed, 718 insertions(+), 1 deletion(-)

[PATCH v2] aarch64: Add TX3 machine model

[Anton Youdkevitch]

Here is the patch introducing thunderxt311 maching model
for the scheduler. A name for the new chip was added to the
list of the names to be recognized as a valid parameter for mcpu
and mtune flags. The TX2 cost model was reused for TX3.

The previously used "cryptic" name for the command line
parameter is replaced with the same "thunderxt311" name.

Bootstrapped on AArch64.

2020-04-20 Anton Youdkevitch 

* config/aarch64/aarch64-cores.def: Add the chip name.
* config/aarch64/aarch64-tune.md: Regenerated.
* gcc/config/aarch64/aarch64.c: Add the cost tables for the chip.
* gcc/config/aarch64/thunderx3t11.md: New file: add the new
machine model for the scheduler
* gcc/config/aarch64/aarch64.md: Include the new model.

---
 gcc/config/aarch64/aarch64-cores.def |   3 +
 gcc/config/aarch64/aarch64-tune.md   |   2 +-
 gcc/config/aarch64/aarch64.c |  27 +
 gcc/config/aarch64/aarch64.md|   1 +
 gcc/config/aarch64/thunderx3t11.md   | 686 +++
 5 files changed, 718 insertions(+), 1 deletion(-)
diff --git a/gcc/config/aarch64/thunderx3t11.md b/gcc/config/aarch64/thunderx3t11.md
index 2c46f89..8a4b824 100644
--- a/gcc/config/aarch64/thunderx3t11.md
+++ b/gcc/config/aarch64/thunderx3t11.md
@@ -32,7 +32,7 @@
 (define_cpu_unit "thunderx3t11_sd" "thunderx3t11_ldst")
 
 ; Pseudo-units for multiply pipeline.
-; XXX unchanged from TX2, occupies I1 for four (1 + 3 additional) slots
+; unchanged from TX2, occupies I1 for four (1 + 3 additional) slots
 
 (define_cpu_unit "thunderx3t11_i1m1" "thunderx3t11_mult")
 (define_cpu_unit "thunderx3t11_i1m2" "thunderx3t11_mult")
@@ -55,6 +55,8 @@
 (define_cpu_unit "thunderx3t11_f3" "thunderx3t11_advsimd")
 
 (define_reservation "thunderx3t11_i23" "thunderx3t11_i2|thunderx3t11_i3")
+(define_reservation "thunderx3t11_i01"
+"thunderx3t11_i0|thunderx3t11_i1")
 (define_reservation "thunderx3t11_i012"
 "thunderx3t11_i0|thunderx3t11_i1|thunderx3t11_i2")
 (define_reservation "thunderx3t11_i0123"
@@ -62,13 +64,11 @@
 (define_reservation "thunderx3t11_ls01" "thunderx3t11_ls0|thunderx3t11_ls1")
 (define_reservation "thunderx3t11_f01" "thunderx3t11_f0|thunderx3t11_f1")
 (define_reservation "thunderx3t11_f23" "thunderx3t11_f2|thunderx3t11_f3")
-;(define_reservation "thunderx3t11_f012"
-;"thunderx3t11_f2|thunderx3t11_f1|thunderx3t11_f0")
 (define_reservation "thunderx3t11_f0123"
 "thunderx3t11_f0|thunderx3t11_f1|thunderx3t11_f2|thunderx3t11_f3")
 
 ; A load with delay in the ls0/ls1 pipes.
-; XXX this is always a delay of four
+; this is always a delay of four
 (define_reservation "thunderx3t11_l0delay"
 "thunderx3t11_ls0,thunderx3t11_ls0d1,thunderx3t11_ls0d2,\
  thunderx3t11_ls0d3")
@@ -79,7 +79,6 @@
 "thunderx3t11_l0delay|thunderx3t11_l1delay")
 ;; Branch and call instructions.
 
-; trap?
 (define_insn_reservation "thunderx3t11_branch" 1
   (and (eq_attr "tune" "thunderx3t11")
(eq_attr "type" "call,branch,trap"))
@@ -93,26 +92,22 @@
(eq_attr "type" "block"))
   "nothing")
 
-; XXX - mrs latency/throughput? Which units?
 (define_insn_reservation "thunderx3t11_mrs" 0
   (and (eq_attr "tune" "thunderx3t11")
(eq_attr "type" "mrs"))
   "thunderx3t11_i2")
 
-; XXX - remove untyped, only appears in SVE .md file
-; multiple: 16 byte moves, other 16 byte ops?
 (define_insn_reservation "thunderx3t11_multiple" 1
   (and (eq_attr "tune" "thunderx3t11")
-   (eq_attr "type" "multiple,untyped"))
+   (eq_attr "type" "multiple"))
   "thunderx3t11_i0+thunderx3t11_i1+thunderx3t11_i3+thunderx3t11_ls0+\
thunderx3t11_ls1+thunderx3t11_sd+thunderx3t11_i1m1+thunderx3t11_i1m2+\
thunderx3t11_i1m3+thunderx3t11_f0+thunderx3t11_f1")
 
 ;; Integer arithmetic/logic instructions.
 
-; Plain register moves are handled by renaming, and don't create any uops.
-
-; XXX - distinguish asimd UMOV from GPR mov;
+; Plain register moves are handled by renaming,
+; and don't create any uops.
 (define_insn_reservation "thunderx3t11_regmove" 0
   (and (eq_attr "tune" "thunderx3t11")
(eq_attr "type" "mov_reg"))
@@ -127,15 +122,24 @@
 			bfx,rbit,rev,extend,rotate_imm"))
   "thunderx3t11_i0123")
 
-; XXX distinguish between latency 1|2 and throughput 1/4|2/4?
-(define_insn_reservation "thunderx3t11_alu_shift" 1
+; distinguish between latency 1|2 and throughput 1/4|2/4?
+; is it actually 1,1/2,{i0,i1} vs 2,1/4,{i0,i1,i2,i3}
+(define_insn_reservation "thunderx3t11_alu_shift" 2
+  (and (eq_attr "tune" "thunderx3t11")
+   (eq_attr "type" "alu_shift_imm,alu_ext,\
+			alus_shift_imm,alus_ext,\
+			logic_shift_imm,logics_shift_imm"))
+  "thunderx3t11_i0123")
+
+(define_insn_reservation "thunderx3t11_alu_shift1" 1
   (and (eq_attr "tune" "thunderx3t11")
(eq_attr "type" "alu_shift_imm,alu_ext,\
 			alus_shift_imm,alus_ext,\
 			logic_shift_imm,logics_shift_imm"))
-  "thunderx3t11_i0123,thunderx3t11_i0123")
+  "thunderx3t11_i01")
 
-; XXX - is the optimistic answer (13) preferable than the 

Re: [PATCH] coroutines: Fix handling of ramp return value [PR94661]

[Nathan Sidwell]

On 4/19/20 3:35 PM, Iain Sandoe wrote:

Hi,

Coroutine ramp functions have synthesised return values (the
user-authored function body cannot have an explicit 'return').
The current implementation attempts to optimise by building
the return in-place, in the manner of C++17 code.  Clearly,
that was too ambitious and the fix builds a target expr for
the constructed version and passes that to finish_return_stmt.

This also means that we now get the same error messages as
non-coroutines code, for implicit use of deleted CTORs etc.



This is not part of PR94288, but the testcase for that also  has
the issue, so it’s preferable to apply this first.

tested on x86_64-darwin16,
OK if it passes regstrap on x86-64-Linux too?
thanks
Iain


gcc/cp/ChangeLog:

2020-04-19  Iain Sandoe  

PR c++/94661
* coroutines.cc (morph_fn_to_coro): Simplify return
value computation.



ok, thanks

--
Nathan Sidwell

[committed] libstdc++: Update __cpp_lib_three_way_comparison macro

[Jonathan Wakely via Gcc-patches]

With P1614R2 fully implemented (except for the  types which we
don't support at all) we can define the feature test macro to the new
value.

* include/std/version (__cpp_lib_three_way_comparison): Update value.
* libsupc++/compare (__cpp_lib_three_way_comparison): Likewise.

Tested powerpc64le-linux, committed to master.

After committing it I noticed I'd also accidentally added a change to
__synth3way as well, which I meant to do in a separate commit. I'll
update the changelog entry to reflect that.


commit 73a0a21d22da7db9687853a4ee7d55fc9aa818a4
Author: Jonathan Wakely 
Date:   Mon Apr 20 17:50:10 2020 +0100

libstdc++: Update __cpp_lib_three_way_comparison macro

With P1614R2 fully implemented (except for the  types which we
don't support at all) we can define the feature test macro to the new
value.

* include/std/version (__cpp_lib_three_way_comparison): Update 
value.
* libsupc++/compare (__cpp_lib_three_way_comparison): Likewise.

diff --git a/libstdc++-v3/include/std/version b/libstdc++-v3/include/std/version
index d9a47ee8e8a..6d7dcc46023 100644
--- a/libstdc++-v3/include/std/version
+++ b/libstdc++-v3/include/std/version
@@ -200,7 +200,7 @@
 #endif
 #define __cpp_lib_span 202002L
 #if __cpp_impl_three_way_comparison >= 201907L && __cpp_lib_concepts
-# define __cpp_lib_three_way_comparison 201711L
+# define __cpp_lib_three_way_comparison 201907L
 #endif
 #define __cpp_lib_to_array 201907L
 #endif
diff --git a/libstdc++-v3/libsupc++/compare b/libstdc++-v3/libsupc++/compare
index e5fb322ed9e..28dfe843ee7 100644
--- a/libstdc++-v3/libsupc++/compare
+++ b/libstdc++-v3/libsupc++/compare
@@ -39,7 +39,7 @@
 #include 
 
 #if __cpp_lib_concepts
-# define __cpp_lib_three_way_comparison 201711L
+# define __cpp_lib_three_way_comparison 201907L
 #endif
 
 namespace std
@@ -866,12 +866,23 @@ namespace std
 
   namespace __detail
   {
-// [expos.only.func]
+// [expos.only.func] synth-three-way
 inline constexpr struct _Synth3way
 {
+  template
+   static constexpr bool
+   _S_noexcept(const _Tp* __t = nullptr, const _Up* __u = nullptr)
+   {
+ if constexpr (three_way_comparable_with<_Tp, _Up>)
+   return noexcept(*__t <=> *__u);
+ else
+   return noexcept(*__t < *__u) && noexcept(*__u < *__t);
+   }
+
   template
constexpr auto
operator()(const _Tp& __t, const _Up& __u) const
+   noexcept(_S_noexcept<_Tp, _Up>())
requires requires
{
  { __t < __u } -> __boolean_testable;
@@ -892,6 +903,7 @@ namespace std
}
 } __synth3way = {};
 
+// [expos.only.func] synth-three-way-result
 template
   using __synth3way_t
= decltype(__detail::__synth3way(std::declval<_Tp&>(),

[committed] libphobos: Fix option name for --with-libphobos-druntime-only.

[Iain Buclaw via Gcc-patches]

Hi,

This patch fixes the option --with-libphobos-druntime-only to match the
help text, as the prefixing 'libphobos' was intentional.

Tested on x86_64-linux-gnu, and committed to mainline.

Regards
Iain.

---
libphobos/ChangeLog:

* configure: Regenerate.
* configure.ac: Fix option name for --with-libphobos-druntime-only.
---
 libphobos/configure| 18 +-
 libphobos/configure.ac | 10 +-
 2 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/libphobos/configure b/libphobos/configure
index 0d4656ed929..06b5d0047c5 100755
--- a/libphobos/configure
+++ b/libphobos/configure
@@ -842,7 +842,7 @@ with_cross_host
 enable_version_specific_runtime_libs
 with_toolexeclibdir
 enable_libphobos
-with_libdruntime_only
+with_libphobos_druntime_only
 enable_libphobos_checking
 '
   ac_precious_vars='build_alias
@@ -15237,17 +15237,17 @@ $as_echo "$enable_libphobos" >&6; }
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for 
--with-libphobos-druntime-only" >&5
 $as_echo_n "checking for --with-libphobos-druntime-only... " >&6; }
 
-# Check whether --with-libdruntime-only was given.
-if test "${with_libdruntime_only+set}" = set; then :
-  withval=$with_libdruntime_only;
+# Check whether --with-libphobos-druntime-only was given.
+if test "${with_libphobos_druntime_only+set}" = set; then :
+  withval=$with_libphobos_druntime_only;
 else
-  with_libdruntime_only=auto
+  with_libphobos_druntime_only=auto
 fi
 
-{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $with_libdruntime_only" >&5
-$as_echo "$with_libdruntime_only" >&6; }
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: 
$with_libphobos_druntime_only" >&5
+$as_echo "$with_libphobos_druntime_only" >&6; }
 
-case "$with_libdruntime_only" in
+case "$with_libphobos_druntime_only" in
   yes|no|auto) ;;
   *) as_fn_error $? "Invalid argument for --with-libphobos-druntime-only" 
"$LINENO" 5 ;;
 esac
@@ -15298,7 +15298,7 @@ fi
 
 
 # Decide if only libdruntime should be built.
-case $LIBDRUNTIME_ONLY:$with_libdruntime_only in
+case $LIBDRUNTIME_ONLY:$with_libphobos_druntime_only in
 *:no)  only_libdruntime=no  ;;
 *:yes) only_libdruntime=yes ;;
 yes:*) only_libdruntime=yes ;;
diff --git a/libphobos/configure.ac b/libphobos/configure.ac
index d82ad8e8c75..805e168881f 100644
--- a/libphobos/configure.ac
+++ b/libphobos/configure.ac
@@ -152,13 +152,13 @@ AC_ARG_ENABLE(libphobos,
 AC_MSG_RESULT($enable_libphobos)
 
 AC_MSG_CHECKING([for --with-libphobos-druntime-only])
-AC_ARG_WITH(libdruntime-only,
+AC_ARG_WITH(libphobos-druntime-only,
   AS_HELP_STRING([--with-libphobos-druntime-only={yes,no,auto}],
 [build only the druntime library (default: auto)]),,
-   [with_libdruntime_only=auto])
-AC_MSG_RESULT($with_libdruntime_only)
+   [with_libphobos_druntime_only=auto])
+AC_MSG_RESULT($with_libphobos_druntime_only)
 
-case "$with_libdruntime_only" in
+case "$with_libphobos_druntime_only" in
   yes|no|auto) ;;
   *) AC_MSG_ERROR([Invalid argument for --with-libphobos-druntime-only]) ;;
 esac
@@ -200,7 +200,7 @@ esac
 AM_CONDITIONAL(ENABLE_LIBPHOBOS, test x$use_libphobos = xyes)
 
 # Decide if only libdruntime should be built.
-case $LIBDRUNTIME_ONLY:$with_libdruntime_only in
+case $LIBDRUNTIME_ONLY:$with_libphobos_druntime_only in
 *:no)  only_libdruntime=no  ;;
 *:yes) only_libdruntime=yes ;;
 yes:*) only_libdruntime=yes ;;
-- 
2.20.1

[committed] libstdc++: Add comparison operators to associative containers

[Jonathan Wakely via Gcc-patches]

The last C++20 changes from P1614R2, "The Mothership has Landed"

* include/bits/stl_map.h (map): Define operator<=> and remove
operator< for C++20.
* include/bits/stl_multimap.h (multimap): Likewise.
* include/bits/stl_multiset.h (multiset): Likewise.
* include/bits/stl_set.h (set): Likewise.
* include/bits/stl_tree.h (_Rb_tree): Likewise.
(_Rb_tree_iterator, _Rb_tree_const_iterator): Remove redundant
operator!= for C++20.
* include/debug/map.h (__gnu_debug::map): Define operator<=> for C++20.
* include/debug/multimap.h (__gnu_debug::multimap): Likewise.
* include/debug/multiset.h (__gnu_debug::multiset): Likewise.
* include/debug/set.h (__gnu_debug::set): Likewise.
* testsuite/23_containers/map/operators/cmp_c++20.cc: New test.
* testsuite/23_containers/multimap/operators/cmp_c++20.cc: New test.
* testsuite/23_containers/multiset/operators/cmp_c++20.cc: New test.
* testsuite/23_containers/set/operators/cmp_c++20.cc: New test.

Tested powerpc64le-linux, committed to master.

commit 93843da69772d271a7247ab2536280646086a5ce
Author: Jonathan Wakely 
Date:   Mon Apr 20 17:50:10 2020 +0100

libstdc++: Add comparison operators to associative containers

The last C++20 changes from P1614R2, "The Mothership has Landed"

* include/bits/stl_map.h (map): Define operator<=> and remove
operator< for C++20.
* include/bits/stl_multimap.h (multimap): Likewise.
* include/bits/stl_multiset.h (multiset): Likewise.
* include/bits/stl_set.h (set): Likewise.
* include/bits/stl_tree.h (_Rb_tree): Likewise.
(_Rb_tree_iterator, _Rb_tree_const_iterator): Remove redundant
operator!= for C++20.
* include/debug/map.h (__gnu_debug::map): Define operator<=> for 
C++20.
* include/debug/multimap.h (__gnu_debug::multimap): Likewise.
* include/debug/multiset.h (__gnu_debug::multiset): Likewise.
* include/debug/set.h (__gnu_debug::set): Likewise.
* testsuite/23_containers/map/operators/cmp_c++20.cc: New test.
* testsuite/23_containers/multimap/operators/cmp_c++20.cc: New test.
* testsuite/23_containers/multiset/operators/cmp_c++20.cc: New test.
* testsuite/23_containers/set/operators/cmp_c++20.cc: New test.

diff --git a/libstdc++-v3/include/bits/stl_map.h 
b/libstdc++-v3/include/bits/stl_map.h
index fe930c15757..5039efd86b7 100644
--- a/libstdc++-v3/include/bits/stl_map.h
+++ b/libstdc++-v3/include/bits/stl_map.h
@@ -1400,10 +1400,17 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
operator==(const map<_K1, _T1, _C1, _A1>&,
   const map<_K1, _T1, _C1, _A1>&);
 
+#if __cpp_lib_three_way_comparison
+  template
+   friend __detail::__synth3way_t>
+   operator<=>(const map<_K1, _T1, _C1, _A1>&,
+   const map<_K1, _T1, _C1, _A1>&);
+#else
   template
friend bool
operator<(const map<_K1, _T1, _C1, _A1>&,
  const map<_K1, _T1, _C1, _A1>&);
+#endif
 };
 
 
@@ -1440,7 +1447,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
 map(initializer_list>, _Allocator)
 -> map<_Key, _Tp, less<_Key>, _Allocator>;
 
-#endif
+#endif // deduction guides
 
   /**
*  @brief  Map equality comparison.
@@ -1458,6 +1465,27 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   const map<_Key, _Tp, _Compare, _Alloc>& __y)
 { return __x._M_t == __y._M_t; }
 
+#if __cpp_lib_three_way_comparison
+  /**
+   *  @brief  Map ordering relation.
+   *  @param  __x  A `map`.
+   *  @param  __y  A `map` of the same type as `x`.
+   *  @return  A value indicating whether `__x` is less than, equal to,
+   *   greater than, or incomparable with `__y`.
+   *
+   *  This is a total ordering relation.  It is linear in the size of the
+   *  maps.  The elements must be comparable with @c <.
+   *
+   *  See `std::lexicographical_compare_three_way()` for how the determination
+   *  is made. This operator is used to synthesize relational operators like
+   *  `<` and `>=` etc.
+  */
+  template
+inline __detail::__synth3way_t>
+operator<=>(const map<_Key, _Tp, _Compare, _Alloc>& __x,
+   const map<_Key, _Tp, _Compare, _Alloc>& __y)
+{ return __x._M_t <=> __y._M_t; }
+#else
   /**
*  @brief  Map ordering relation.
*  @param  __x  A %map.
@@ -1502,6 +1530,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
 operator>=(const map<_Key, _Tp, _Compare, _Alloc>& __x,
   const map<_Key, _Tp, _Compare, _Alloc>& __y)
 { return !(__x < __y); }
+#endif // three-way comparison
 
   /// See std::map::swap().
   template
diff --git a/libstdc++-v3/include/bits/stl_multimap.h 
b/libstdc++-v3/include/bits/stl_multimap.h
index d38f530e123..65f4d0117a4 100644
--- a/libstdc++-v3/include/bits/stl_multimap.h
+++ 

[PATCH] coroutines: Fix handling of conditional statements [PR94288]

[Iain Sandoe]

Hi,

Normally, when we find a statement containing an await expression
this will be expanded to a statement list implementing the control
flow implied.  The expansion process successively replaces each
await expression in a statement with the result of its await_resume().

In the case of conditional statements (if, while, do, switch) the
expansion of the condition (or expression in the case of do-while)
cannot take place 'inline', leading to the PR.

The solution is to evaluate the expression separately, and to
transform while and do-while loops into endless loops with a break
on the required condition.

In fixing this, I realised that I'd also made a thinko in the case
of expanding truth-and/or-if expressions, where one arm of the
expression might need to be short-circuited.  The mechanism for
expanding via the tree walk will not work correctly in this case and
we need to pre-expand any truth-and/or-if with an await expression
on its conditionally-taken arm.  This applies to any statement with
truth-and/or-if expressions, so can be handled generically.

This has been tested in various permutations (including without-
checking) on x86_64-darwin, now testing on x86/power Linux.

The testcases do not include the testcase from the PR since that
fails because of PR94661 (it can be included when that’s resolved).

The testcases are appended as a text file.

OK for master, assuming that regstraps on x86/power Linux are OK?
thanks
Iain


gcc/cp/ChangeLog:

2020-04-20  Iain Sandoe  

PR c++/94288
* coroutines.cc (await_statement_expander): Simplify cases.
(struct susp_frame_data): Add fields for truth and/or if
cases, rename one field.
(analyze_expression_awaits): New.
(expand_one_truth_if): New.
(add_var_to_bind): New helper.
(coro_build_add_if_not_cond_break): New helper.
(await_statement_walker): Handle conditional expressions,
handle expansion of truth-and/or-if cases.
(bind_expr_find_in_subtree): New, checking-only.
(coro_body_contains_bind_expr_p): New, checking-only.
(morph_fn_to_coro): Ensure that we have a top level bind
expression.

gcc/testsuite/ChangeLog:

2020-04-20  Iain Sandoe  

PR c++/94288
* g++.dg/coroutines/torture/co-await-18-if-cond.C: New test.
* g++.dg/coroutines/torture/co-await-19-while-cond.C: New test.
* g++.dg/coroutines/torture/co-await-20-do-while-cond.C: New test.
* g++.dg/coroutines/torture/co-await-21-switch-value.C: New test.
* g++.dg/coroutines/torture/co-await-22-truth-and-of-if.C: New test.
* g++.dg/coroutines/torture/co-ret-16-simple-control-flow.C: New test.
---
 gcc/cp/coroutines.cc | 433 ++-
 1 file changed, 423 insertions(+), 10 deletions(-)

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index 0a8e7521c4f..4e0d50a529f 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -1627,9 +1627,8 @@ await_statement_expander (tree *stmt, int *do_subtree, 
void *d)
   tree res = NULL_TREE;
 
   /* Process a statement at a time.  */
-  if (TREE_CODE (*stmt) == BIND_EXPR)
-res = cp_walk_tree (_EXPR_BODY (*stmt), await_statement_expander,
-   d, NULL);
+  if (STATEMENT_CLASS_P (*stmt) || TREE_CODE (*stmt) == BIND_EXPR)
+return NULL_TREE; /* Just process the sub-trees.  */
   else if (TREE_CODE (*stmt) == STATEMENT_LIST)
 {
   tree_stmt_iterator i;
@@ -1642,8 +1641,6 @@ await_statement_expander (tree *stmt, int *do_subtree, 
void *d)
}
   *do_subtree = 0; /* Done subtrees.  */
 }
-  else if (STATEMENT_CLASS_P (*stmt))
-return NULL_TREE; /* Process the sub-trees.  */
   else if (EXPR_P (*stmt))
 {
   process_one_statement (stmt, d);
@@ -2586,12 +2583,14 @@ struct susp_frame_data
   vec *block_stack; /* Track block scopes.  */
   vec *bind_stack;  /* Track current bind expr.  */
   unsigned await_number;/* Which await in the function.  */
-  unsigned condition_number;/* Which replaced condition in the fn.  */
+  unsigned cond_number; /* Which replaced condition in the fn. 
 */
   /* Temporary values for one statement or expression being analyzed.  */
   hash_set captured_temps; /* The suspend captured these temps.  */
   vec *to_replace;  /* The VAR decls to replace.  */
+  hash_set *truth_aoif_to_expand; /* The set of TRUTH exprs to expand.  
*/
   unsigned saw_awaits;  /* Count of awaits in this statement  */
   bool captures_temporary;  /* This expr captures temps by ref.  */
+  bool needs_truth_if_exp;  /* We must expand a truth_if expression.  */
 };
 
 /* Walk the sub-tree looking for call expressions that both capture
@@ -2895,6 +2894,178 @@ maybe_promote_captured_temps (tree *stmt, void *d)
   return NULL_TREE;
 }
 
+/* Lightweight callback to determine two key factors:
+   1) If the statement/expression contains any await expressions.
+   2) If the 

[committed] libphobos: Remove undefined DRUNTIME_GC from configure scripts

[Iain Buclaw via Gcc-patches]

Hi,

This patch fixes up a previous commit that removed DRUNTIME_GC from
m4/druntime.m4

Committed to mainline.

Regards
Iain.

---
libphobos/ChangeLog:

* configure: Regenerate.
* configure.ac: Remove DRUNTIME_GC.
---
 libphobos/configure| 1 -
 libphobos/configure.ac | 1 -
 2 files changed, 2 deletions(-)

diff --git a/libphobos/configure b/libphobos/configure
index 2dcf15ed852..0d4656ed929 100755
--- a/libphobos/configure
+++ b/libphobos/configure
@@ -13982,7 +13982,6 @@ fi
   WERROR_FLAG="-Werror"
   fi
 
-DRUNTIME_GC
 
   druntime_target_cpu_parsed=""
   case "$target_cpu" in
diff --git a/libphobos/configure.ac b/libphobos/configure.ac
index 8c89ebd23b0..d82ad8e8c75 100644
--- a/libphobos/configure.ac
+++ b/libphobos/configure.ac
@@ -120,7 +120,6 @@ GCC_BASE_VER
 DRUNTIME_CONFIGURE
 DRUNTIME_MULTILIB
 DRUNTIME_WERROR
-DRUNTIME_GC
 DRUNTIME_CPU_SOURCES
 DRUNTIME_OS_SOURCES
 DRUNTIME_OS_THREAD_MODEL
-- 
2.20.1

[PATCH] c++: Detect long double -> double narrowing [PR94590]

[Marek Polacek via Gcc-patches]

This PR points out that we don't detect long double -> double narrowing
when long double happens to have the same precision as double; on x86_64
this can be achieved by -mlong-double-64.

[dcl.init.list]#7.2 specifically says "from long double to double or float,
or from double to float", but check_narrowing only checks

  TYPE_PRECISION (type) < TYPE_PRECISION (ftype)

so we need to handle the other cases too, e.g. by same_type_p as in
the following patch.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
Or should this wait till GCC 11?  (Though I don't expect that this problem
is common enough.)

PR c++/94590 - Detect long double -> double narrowing.
* typeck2.c (check_narrowing): Detect long double -> double
narrowing even when double and long double have the same
precision.  Make it handle conversions to float too.

* g++.dg/cpp0x/Wnarrowing18.C: New test.
---
 gcc/cp/typeck2.c  |  9 -
 gcc/testsuite/g++.dg/cpp0x/Wnarrowing18.C | 15 +++
 2 files changed, 23 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/Wnarrowing18.C

diff --git a/gcc/cp/typeck2.c b/gcc/cp/typeck2.c
index 56fd9bafa7e..2165978bf1c 100644
--- a/gcc/cp/typeck2.c
+++ b/gcc/cp/typeck2.c
@@ -1008,10 +1008,17 @@ check_narrowing (tree type, tree init, tsubst_flags_t 
complain,
  || !int_fits_type_p (init, type)))
ok = false;
 }
+  /* [dcl.init.list]#7.2: "from long double to double or float, or from
+  double to float".  */
   else if (TREE_CODE (ftype) == REAL_TYPE
   && TREE_CODE (type) == REAL_TYPE)
 {
-  if (TYPE_PRECISION (type) < TYPE_PRECISION (ftype))
+  if ((same_type_p (ftype, long_double_type_node)
+  && (same_type_p (type, double_type_node)
+  || same_type_p (type, float_type_node)))
+ || (same_type_p (ftype, double_type_node)
+ && same_type_p (type, float_type_node))
+ || (TYPE_PRECISION (type) < TYPE_PRECISION (ftype)))
{
  if (TREE_CODE (init) == REAL_CST)
{
diff --git a/gcc/testsuite/g++.dg/cpp0x/Wnarrowing18.C 
b/gcc/testsuite/g++.dg/cpp0x/Wnarrowing18.C
new file mode 100644
index 000..0dc7075cd62
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/Wnarrowing18.C
@@ -0,0 +1,15 @@
+// PR c++/94590 - Detect long double -> double narrowing.
+// { dg-do compile { target c++11 } }
+// { dg-additional-options "-mlong-double-64" { target x86_64-*-* i?86-*-* } }
+
+int
+main ()
+{
+  using T = long double;
+  extern long double ld;
+  extern T ld2;
+  extern const T ld3;
+  double d{ld}; // { dg-error "narrowing conversion" }
+  double d2{ld2}; // { dg-error "narrowing conversion" }
+  double d3{ld3}; // { dg-error "narrowing conversion" }
+}

base-commit: 5da301cbd81c41b2e9629f55dd1b1889f7dae75e
-- 
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA

shipments from/to China

[Bravo via Gcc-patches]

Greeting from China,

Nice to meet you here,this is Bravo from Long Sail Logistics Co., Ltd.

We are a top leading logistics company in China,with 23 branch offices all over 
China and overseas,over 1200 staffs work in Long Sail Logistics all over the 
world.

If you have any inquiry for shipments from/to China,please feel free to contact 
us,sincerely hope can help you and your business,have a great day!

(If you there email has bothered you,please just ignore,thanks.)
--
Tks  Rgds
Bravo Huang
Long Sail International Logistics Co., Ltd E-mail:bravo.hu...@longsailing.net
Mobile:+86 13728671080
Skype:bravohuang

Re: [PATCH] c++: Fix ICE with { } as template argument [PR94592]

[Jason Merrill via Gcc-patches]

On 4/17/20 4:28 PM, Marek Polacek wrote:

As an extension (there should be a CWG about this though), we support
braced-init-list as a template argument, but convert_nontype_argument
had trouble digesting them.  We ICEd because of the double coercion we
perform for template arguments: convert_nontype_argument called from
finish_template_type got a { }, and since a class type was involved and
we were in a template, convert_like created an IMPLICIT_CONV_EXPR.  Then
the second conversion of the same argument crashed in constexpr.c
because the IMPLICIT_CONV_EXPR had gotten wrapped in a TARGET_EXPR.
Another issue was that an IMPLICIT_CONV_EXPR leaked to constexpr.c when
building an aggregate init.

We should have instantiated the IMPLICIT_CONV_EXPR in the first call to
convert_nontype_argument, but we didn't, because the call to
is_nondependent_constant_expression returned false because it checks
!BRACE_ENCLOSED_INITIALIZER_P.  Then non_dep was false even though the
expression didn't contain anything dependent and we didn't instantiate
it in convert_nontype_argument.  I'm not sure what the point
of that BRACE_ENCLOSED_INITIALIZER_P. check was, but removing it doesn't
break anything and fixes these crashes.


The point was to avoid trying to get a constant value for an untyped 
braced-init-list.  I'm happy to remove the check from these functions, 
but let's add it back to maybe_constant_{value,init}, where it was until 
r6-7825-geb07f187a471f9a203626aecced17d6947c3cc46 .


Or better, put it in cxx_eval_outermost_constant_expr.


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

PR c++/94592
* constexpr.c (is_nondependent_constant_expression): Don't check
BRACE_ENCLOSED_INITIALIZER_P.
(is_nondependent_static_init_expression): Likewise.

* g++.dg/cpp2a/nontype-class34.C: New test.
* g++.dg/cpp2a/nontype-class35.C: New test.
---
  gcc/cp/constexpr.c   |  2 --
  gcc/testsuite/g++.dg/cpp2a/nontype-class34.C | 16 
  gcc/testsuite/g++.dg/cpp2a/nontype-class35.C | 17 +
  3 files changed, 33 insertions(+), 2 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/nontype-class34.C
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/nontype-class35.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index c8e7d083f40..21a5bbd798c 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -8295,7 +8295,6 @@ bool
  is_nondependent_constant_expression (tree t)
  {
return (!type_unknown_p (t)
- && !BRACE_ENCLOSED_INITIALIZER_P (t)
  && is_constant_expression (t)
  && !instantiation_dependent_expression_p (t));
  }
@@ -8307,7 +8306,6 @@ bool
  is_nondependent_static_init_expression (tree t)
  {
return (!type_unknown_p (t)
- && !BRACE_ENCLOSED_INITIALIZER_P (t)
  && is_static_init_expression (t)
  && !instantiation_dependent_expression_p (t));
  }
diff --git a/gcc/testsuite/g++.dg/cpp2a/nontype-class34.C 
b/gcc/testsuite/g++.dg/cpp2a/nontype-class34.C
new file mode 100644
index 000..2d3ba018618
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/nontype-class34.C
@@ -0,0 +1,16 @@
+// PR c++/94592 - ICE with { } as template argument.
+// { dg-do compile { target c++2a } }
+
+struct A {
+  constexpr A() {}
+};
+
+template  struct B { };
+
+template void bar () {
+B<{}> var;
+}
+
+void fu() {
+bar();
+}
diff --git a/gcc/testsuite/g++.dg/cpp2a/nontype-class35.C 
b/gcc/testsuite/g++.dg/cpp2a/nontype-class35.C
new file mode 100644
index 000..78cf0a39c81
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/nontype-class35.C
@@ -0,0 +1,17 @@
+// PR c++/94592 - ICE with { } as template argument.
+// { dg-do compile { target c++2a } }
+
+struct A {
+int i;
+constexpr A(int n) : i(n) {}
+};
+
+template  struct B { int i; constexpr B() : i(a.i) { } };
+
+template void bar () {
+B<{1}> var;
+}
+
+void fu() {
+bar();
+}

base-commit: a28edad3da5c59f09565d3d42e20be1a924986c4

Re: [og8] Report errors on missing OpenACC reduction clauses in nested reductions

[Thomas Schwinge]

Hi Frederik!

As you've been the last one to work on this code and get it into GCC
master branch (commit 5d183d1740d8d8b84991f186ce4d992ee799536f "Warn
about inconsistent OpenACC nested reduction clauses"), you get to look
into the following issue.

..., and yes, I'm aware that you have a follow-up patch which is
reworking this code, and which still needs to be reviewed --

-- but let's please first have a look at the current code in GCC master
branch, and address what might be a bug.

On 2018-12-20T15:28:33+0100, I wrote:
> On behalf of Gergő (who doesn't have write access yet) I've pushed the
> attached to openacc-gcc-8-branch.

> From a9e48066198ffb1e7bc2b137167a61a6cb47748c Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Gerg=C3=B6=20Barany?= 
> Date: Thu, 20 Dec 2018 15:07:34 +0100
> Subject: [PATCH] Report errors on missing OpenACC reduction clauses in nested
>  reductions
>
> ..., as suggested by OpenACC 2.6, 2.9.11. "reduction clause".

> --- a/gcc/omp-low.c
> +++ b/gcc/omp-low.c
> @@ -129,6 +129,12 @@ struct omp_context
>
>/* Hash map of dynamic arrays in this context.  */
>hash_map *dynamic_arrays;
> +
> +  /* A tree_list of the reduction clauses in this context.  */
> +  tree local_reduction_clauses;
> +
> +  /* A tree_list of the reduction clauses in outer contexts.  */
> +  tree outer_reduction_clauses;
>  };
>
>  static splay_tree all_contexts;
> @@ -1040,6 +1046,8 @@ new_omp_context (gimple *stmt, omp_context *outer_ctx)
>ctx->cb = outer_ctx->cb;
>ctx->cb.block = NULL;
>ctx->depth = outer_ctx->depth + 1;
> +  ctx->local_reduction_clauses = NULL;
> +  ctx->outer_reduction_clauses = ctx->outer_reduction_clauses;

Via  "10 issues located by the PVS-studio
static analyzer" (so please reference that one on any patch submission),
on  in "Fragment N3,
Assigning a variable to itself", we find this latter assignment qualified
as "very strange to assign a variable to itself".

Probably that should've been 'outer_ctx' instead of 'ctx'?  But: why/how
then does the current algorith still work despite this error?

(I haven't looked at the code very much.)


Grüße
 Thomas


>  }
>else
>  {
> @@ -1053,6 +1061,8 @@ new_omp_context (gimple *stmt, omp_context *outer_ctx)
>ctx->cb.eh_lp_nr = 0;
>ctx->cb.transform_call_graph_edges = CB_CGE_MOVE;
>ctx->depth = 1;
> +  ctx->local_reduction_clauses = NULL;
> +  ctx->outer_reduction_clauses = NULL;
>  }
>
>ctx->cb.decl_map = new hash_map;
> @@ -1276,6 +1286,9 @@ scan_sharing_clauses (tree clauses, omp_context *ctx,
> goto do_private;
>
>   case OMP_CLAUSE_REDUCTION:
> +  if (is_oacc_parallel (ctx) || is_oacc_kernels (ctx))
> +ctx->local_reduction_clauses
> +   = tree_cons (NULL, c, ctx->local_reduction_clauses);
> decl = OMP_CLAUSE_DECL (c);
> if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_REDUCTION
> && TREE_CODE (decl) == MEM_REF)
> @@ -2458,6 +2471,98 @@ scan_omp_for (gomp_for *stmt, omp_context *outer_ctx)
> gimple_omp_for_set_clauses (stmt, clauses);
> check_oacc_kernel_gwv (stmt, ctx);
>   }
> +
> +  /* Collect all variables named in reductions on this loop.  Ensure
> + that, if this loop has a reduction on some variable v, and there is
> + a reduction on v somewhere in an outer context, then there is a
> + reduction on v on all intervening loops as well.  */
> +  tree local_reduction_clauses = NULL;
> +  for (tree c = gimple_omp_for_clauses (stmt); c; c = OMP_CLAUSE_CHAIN 
> (c))
> +{
> +  if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_REDUCTION)
> +local_reduction_clauses
> +   = tree_cons (NULL, c, local_reduction_clauses);
> +}
> +  if (ctx->outer_reduction_clauses == NULL && ctx->outer != NULL)
> +ctx->outer_reduction_clauses
> +   = chainon (unshare_expr (ctx->outer->local_reduction_clauses),
> +  ctx->outer->outer_reduction_clauses);
> +  tree outer_reduction_clauses = ctx->outer_reduction_clauses;
> +  tree local_iter = local_reduction_clauses;
> +  for (; local_iter; local_iter = TREE_CHAIN (local_iter))
> +{
> +  tree local_clause = TREE_VALUE (local_iter);
> +  tree local_var = OMP_CLAUSE_DECL (local_clause);
> +  tree_code local_op = OMP_CLAUSE_REDUCTION_CODE (local_clause);
> +  bool have_outer_reduction = false;
> +  tree ctx_iter = outer_reduction_clauses;
> +  for (; ctx_iter; ctx_iter = TREE_CHAIN (ctx_iter))
> +{
> +  tree outer_clause = TREE_VALUE (ctx_iter);
> +  tree outer_var = OMP_CLAUSE_DECL (outer_clause);
> +  tree_code outer_op = OMP_CLAUSE_REDUCTION_CODE (outer_clause);
> +  if 

[committed] aarch64: Fix vector builds used by SVE vec_init [PR94668]

[Richard Sandiford]

This testcase triggered an ICE in rtx_vector_builder::step because
we were trying to use a stepped representation for floating-point
constants.  The underlying problem was that the arguments to
rtx_vector_builder were the wrong way around, meaning that some
variations were likely to be incorrectly encoded for integers
(but probably as a silent failure).

Also, aarch64_sve_expand_vector_init_handle_trailing_constants
tries to extend the trailing constant elements to a full vector
by following the "natural" pattern of the original vector, which
should generally lead to nicer constants.  However, for the testcase,
we'd then end up picking a variable for some elements.  Fixed by
stubbing out all variable elements with zeros.

That fix involved testing valid_for_const_vector_p.  For consistency,
the patch uses the same test when finding trailing constants, instead
of the previous aarch64_legitimate_constant_p.

Tested on aarch64-linux-gnu, pushed.

Richard


2020-04-20  Richard Sandiford  

gcc/
PR target/94668
* config/aarch64/aarch64.c (aarch64_sve_expand_vector_init): Fix
order of arguments to rtx_vector_builder.
(aarch64_sve_expand_vector_init_handle_trailing_constants): Likewise.
When extending the trailing constants to a full vector, replace any
variables with zeros.

gcc/testsuite/
PR target/94668
* gcc.target/aarch64/sve/pr94668.c: New test.
---
 gcc/ChangeLog |  9 +++
 gcc/config/aarch64/aarch64.c  | 26 ++-
 gcc/testsuite/ChangeLog   |  5 
 .../gcc.target/aarch64/sve/pr94668.c  |  8 ++
 4 files changed, 41 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve/pr94668.c

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index cc6c6389b90..4c9de79c1fd 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,12 @@
+2020-04-20  Richard Sandiford  
+
+   PR target/94668
+   * config/aarch64/aarch64.c (aarch64_sve_expand_vector_init): Fix
+   order of arguments to rtx_vector_builder.
+   (aarch64_sve_expand_vector_init_handle_trailing_constants): Likewise.
+   When extending the trailing constants to a full vector, replace any
+   variables with zeros.
+
 2020-04-20  Jan Hubicka  
 
PR ipa/94582
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 24c055df0dc..ee6a2de77a5 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -18382,15 +18382,27 @@ 
aarch64_sve_expand_vector_init_handle_trailing_constants
   int n_trailing_constants = 0;
 
   for (int i = nelts_reqd - 1;
-   i >= 0 && aarch64_legitimate_constant_p (elem_mode, builder.elt (i));
+   i >= 0 && valid_for_const_vector_p (elem_mode, builder.elt (i));
i--)
 n_trailing_constants++;
 
   if (n_trailing_constants >= nelts_reqd / 2)
 {
-  rtx_vector_builder v (mode, 1, nelts);
+  /* Try to use the natural pattern of BUILDER to extend the trailing
+constant elements to a full vector.  Replace any variables in the
+extra elements with zeros.
+
+??? It would be better if the builders supported "don't care"
+elements, with the builder filling in whichever elements
+give the most compact encoding.  */
+  rtx_vector_builder v (mode, nelts, 1);
   for (int i = 0; i < nelts; i++)
-   v.quick_push (builder.elt (i + nelts_reqd - n_trailing_constants));
+   {
+ rtx x = builder.elt (i + nelts_reqd - n_trailing_constants);
+ if (!valid_for_const_vector_p (elem_mode, x))
+   x = const0_rtx;
+ v.quick_push (x);
+   }
   rtx const_vec = v.build ();
   emit_move_insn (target, const_vec);
 
@@ -18508,7 +18520,7 @@ aarch64_sve_expand_vector_init (rtx target, const 
rtx_vector_builder ,
 
   /* Case 2: Vector contains leading constants.  */
 
-  rtx_vector_builder rev_builder (mode, 1, nelts_reqd);
+  rtx_vector_builder rev_builder (mode, nelts_reqd, 1);
   for (int i = 0; i < nelts_reqd; i++)
 rev_builder.quick_push (builder.elt (nelts_reqd - i - 1));
   rev_builder.finalize ();
@@ -18541,8 +18553,8 @@ aarch64_sve_expand_vector_init (rtx target, const 
rtx_vector_builder ,
   if (nelts_reqd <= 4)
 return false;
 
-  rtx_vector_builder v_even (mode, 1, nelts);
-  rtx_vector_builder v_odd (mode, 1, nelts);
+  rtx_vector_builder v_even (mode, nelts, 1);
+  rtx_vector_builder v_odd (mode, nelts, 1);
 
   for (int i = 0; i < nelts * 2; i += 2)
 {
@@ -18586,7 +18598,7 @@ aarch64_sve_expand_vector_init (rtx target, rtx vals)
   machine_mode mode = GET_MODE (target);
   int nelts = XVECLEN (vals, 0);
 
-  rtx_vector_builder v (mode, 1, nelts);
+  rtx_vector_builder v (mode, nelts, 1);
   for (int i = 0; i < nelts; i++)
 v.quick_push (XVECEXP (vals, 0, i));
   v.finalize ();
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 

Re: [PATCH] aarch64：Add an error message in large code model for ilp32 [PR94577]

[Richard Sandiford]

"duanbo (C)"  writes:
> Hi
>
>> -Original Message-
>> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
>> Sent: Friday, April 17, 2020 9:38 PM
>> To: duanbo (C) 
>> Cc: Wilco Dijkstra ; gcc-patches@gcc.gnu.org
>> Subject: Re: [PATCH PR94577] [AArch64] ：Add an error message in large
>> code model for ilp32
>> 
>> "duanbo (C)"  writes:
>> > Thank you for your suggestions.
>> > I have modified accordingly and a full test has been carried, no new 
>> > failure
>> witnessed.
>> > Attached please find the new patch which has been adjusted to be suitable
>> for git am.
>> > Does the v2 patch look better ?
>> >
>> > Thanks,
>> > Duan bo
>> >
>> > -Original Message-
>> > From: Wilco Dijkstra [mailto:wilco.dijks...@arm.com]
>> > Sent: Tuesday, April 14, 2020 4:40 AM
>> > To: GCC Patches ; duanbo (C)
>> > 
>> > Subject: Re: [PATCH PR2] aarch64：Add an error message in large
>> > code model for ilp32
>> >
>> > Hi Duanbo,
>> >
>> >> This is a simple fix for pr94577.
>> >> The option -mabi=ilp32 should not be used in large code model. Like x86,
>> using -mx32 and -mcmodel=large together will result in an error message.
>> >> On aarch64, there is no error message for this option conflict.
>> >> A solution to this problem can be found in the attached patch.
>> >> Bootstrap and tested on aarch64 Linux platform. No new regression
>> witnessed.
>> >> Any suggestion?
>> >
>> > Thanks for your patch, more than 4GB doesn't make any sense with ILP32
>> indeed.
>> > A few suggestions:
>> >
>> > It would be good to also update the documentation for -mcmodel=large to
>> state it is incompatible with -fpic, -fPIC and -mabi=ilp32.
>> >
>> > The patch adds a another switch statement on mcmodel that ignores the
>> previous processing done (which may changes the selected mcmodel). It
>> would be safer and more concise to use one switch at the top level and in
>> each case use an if statement to handle the special cases.
>> >
>> > A few minor nitpics:
>> >
>> > +   PR  target/94577
>> > +   * gcc.target/aarch64/pr94577.c : New test
>> >
>> > Just like comments, there should be a '.' at the end of changelog entries.
>> >
>> > AFAICT the format isn't exactly specified, but the email header should be
>> like:
>> >
>> > [PATCH][AArch64] PR94577: Add an error message in large code model for
>> > ilp32
>> >
>> > Sometimes the PR number is also placed in brackets.
>> >
>> > Cheers,
>> > Wilco
>> >
>> >
>> > From feb16a5e5d35d4f632e1be10ce0ac4f4c3505d22 Mon Sep 17 00:00:00
>> 2001
>> > From: Duan bo 
>> > Date: Wed, 15 Apr 2020 05:19:31 -0400
>> > Subject: [PATCH] aarch64: Add an error message in large code model for
>> > ilp32  [PR94577]
>> >
>> > The option -mabi=ilp32 should not be used in large code model. An
>> > error message is added for the option conflict.
>> >
>> > 2020-04-15  Duan bo  
>> >
>> >PR target/94577
>> >* config/aarch64/aarch64.c: Add an error message for option conflict.
>> >* doc/invoke.texi (-mcmodel=large): Mention that -mcmodel=large
>> is
>> >incompatible with -fpic, -fPIC and -mabi=ilp32.
>> >
>> > 2020-04-15  Duan bo  
>> >
>> >PR target/94577
>> >* gcc.target/aarch64/pr94577.c: New test.
>> > ---
>> >  gcc/ChangeLog  |  7 
>> >  gcc/config/aarch64/aarch64.c   | 41 --
>> >  gcc/doc/invoke.texi|  4 ++-
>> >  gcc/testsuite/ChangeLog|  5 +++
>> >  gcc/testsuite/gcc.target/aarch64/pr94577.c | 10 ++
>> >  5 files changed, 47 insertions(+), 20 deletions(-)  create mode
>> > 100644 gcc/testsuite/gcc.target/aarch64/pr94577.c
>> >
>> > diff --git a/gcc/ChangeLog b/gcc/ChangeLog index
>> > 3c6a45e8fe7..c2f1fcb7bff 100644
>> > --- a/gcc/ChangeLog
>> > +++ b/gcc/ChangeLog
>> > @@ -1,3 +1,10 @@
>> > +2020-04-15  Duan bo  
>> > +
>> > +  PR target/94577
>> > +  * config/aarch64/aarch64.c: Add an error message for option conflict.
>> > +  * doc/invoke.texi (-mcmodel=large): Mention that -mcmodel=large
>> is
>> > +  incompatible with -fpic, -fPIC and -mabi=ilp32.
>> > +
>> >  2020-04-14  Max Filippov  
>> >
>> >PR target/94584
>> > diff --git a/gcc/config/aarch64/aarch64.c
>> > b/gcc/config/aarch64/aarch64.c index 4af562a81ea..f8a38bd899a 100644
>> > --- a/gcc/config/aarch64/aarch64.c
>> > +++ b/gcc/config/aarch64/aarch64.c
>> > @@ -14707,32 +14707,35 @@ aarch64_init_expanders (void)  static void
>> > initialize_aarch64_code_model (struct gcc_options *opts)  {
>> > -   if (opts->x_flag_pic)
>> > +   aarch64_cmodel = opts->x_aarch64_cmodel_var;
>> > +   switch (opts->x_aarch64_cmodel_var)
>> >   {
>> > -   switch (opts->x_aarch64_cmodel_var)
>> > -   {
>> > -   case AARCH64_CMODEL_TINY:
>> > +   case AARCH64_CMODEL_TINY:
>> > +   if (opts->x_flag_pic)
>> 
>> Minor formatting nit, but: the case statement should be indented by the
>> same amount as the "{" for the switch statement.  The code after the case
>> statement should be indented by two 

Re: [PATCH] Avoid illegal argument to verbose in dg-test callback

[Jonathan Wakely via Gcc-patches]

On 16/04/20 15:21 +0200, Matthias Kretz wrote:

From: Matthias Kretz 

If extra_tool_flags starts with a dash, an error like 'ERROR: verbose:
illegal argument: -march=native -O2 -std=c++17' is printed. This is
easily fixed by inserting a double dash before the variable.

   * testsuite/lib/libstdc++.exp: Avoid illegal argument to
   verbose.


Committed, thanks.

Re: [RFC] split pseudos during loop unrolling in RTL unroller

[Richard Biener via Gcc-patches]

On Mon, Apr 20, 2020 at 3:38 PM Segher Boessenkool
 wrote:
>
> Hi!
>
> On Mon, Apr 20, 2020 at 09:56:34AM +0200, Richard Biener wrote:
> > On Fri, Apr 17, 2020 at 10:51 PM Segher Boessenkool
> >  wrote:
> > > > Yeah well, but RTL is not in SSA form
> > >
> > > "Webs" are not the *same* as SSA, in a few crucial ways; but they serve
> > > similar purposes: they both make code transformations easier to do.
> > > Both do this by having more different (independent) names.
> > >
> > > > and there's no RTL IL verification
> > > > in place to track degradation.
> > >
> > > Adding this isn't hard in principle.  But currently it is violated all
> > > over the place, including in backend code.
> >
> > It's a cheap excuse and clearly a lot of work.  But we've done it for GIMPLE
> > and it was clearly worth it.  If only for documentation purposes.
>
> Yes, I very much agree :-)  But how will we do this?  Make it warnings
> only, and have those opt-in (for a port) even?

Add -fcheck-rtl, when you're ready (per port?) make it default for
bootstrap.  When you're even more "ready", turn it on with -fchecking
(or --enable-checking=xyz).

We've gone a similar way with the GIMPLE checking (not SSA checking,
that was always present) which was formerly called "type" checking but
now verifies more details.  It was broken quite badly as well and mostly
incrementally fixed (some cases by intentionally weakening the checker).

Of course as you say with RTL you have all the targets to consider ...

> > > > And we even work in the opposite way
> > > > when expanding to RTL from SSA, coalescing as much as we can ...
> > >
> > > Which often is bad.  A lot of what expand does is premature optimisation
> > > that a) is much too complicated, and b) results in worse code in the end.
> > > Expand should not try to do *anything* "interesting", it should "merely"
> > > translate to RTL.
> > >
> > > (And in a way that can be debugged sanely at all, if possible ;-) )
> >
> > Sure.  I've tried to turn off TER with only moderate success.  Another 
> > approach
> > would be to not do any coalescing but for PHIs (and maybe there only for 
> > edges
> > where we cannot insert copies on w/o splitting it).
>
> Yeah, that would be much simpler to do as well.
>
> > But clearly all the magic expand does now should materialize itself on
> > GIMPLE (see the patch series Martin posted for vcond* / vec_cmp*
> > "expansion" on GIMPLE).
>
> Probably most, yeah, but some things that expand does should be done
> much *later* in RTL even :-)

We have combine for that.  Eh.

> > It's the magic that requires TER and TER clearly
> > introduces the most noise in the GIMPLE -> RTL translation step (as to
> > code motion and initial instruction selection if it "fails").
>
> Expand does a lot of things that are very much historic, too.

Sure...

Richard.

>
> Segher

Re: [C/C++, OpenACC] Reject vars of different scope in acc declare (PR94120) | Fix declare copyout in libgomp.oacc-c++/declare-pr94120.C

[Tobias Burnus]

Hi Thomas,

I have now fixed it temporarily differently – without actually
testing that feature. – See attachment.

For the proper fix, it would help to get the semantic right in
OpenACC itself (→ ongoing discussion). I think the patch
for PR94120 is probably not completely right – and should be
fixed for GCC 10, but I think one should wait for the next two
OpenACC meetings to get converged. One presumably needs to handle
'device_resident' and 'link' differently from 'copy* etc.

I added a note to PR 94140.

Regards,

Tobias

On 4/10/20 3:20 PM, Thomas Schwinge wrote:


Hi Tobias!

I do see the new 'libgomp.oacc-c++/declare-pr94120.C' (see below, for
reference) FAIL for '-foffload=nvptx-none' execution testing.  The reason
is that the 'C' array doesn't have the content it's checked to have.

Now, my question, shouldn't it be changed like the attached patch, or
similar, because we actually first need to return from function 'f' in
order for the 'copyout(C)' to be executed?

Or, otherwise, what's the use of the 'copyout' clause with OpenACC
'declare'?  I suppose it's only meant to be used with function arguments,
because for every locally-defined variable (like 'C' in
'libgomp.oacc-c++/declare-pr94120.C'), that variable will be gone just
after the 'copyout' is executed, so the 'copyout' conceptually
equals/acts as 'create' in that case.  However, OpenACC explicitly does
allow 'copyout' in certain scenarios.  Do you think my interpretation is
correct, or what am I missing?  (In case the answer isn't obvious to you,
too, please file an issue with OpenACC, linking to this email for
reference.)

However, GCC doesn't like my changes either; actually two errors are
diagnosed:

 [...]/libgomp.oacc-c++/declare-pr94120.C: In function ‘void f(int*)’:
 [...]/libgomp.oacc-c++/declare-pr94120.C:21:30: error: array section in 
‘#pragma acc declare’
21 | #pragma acc declare copyout (C[0:N])
   |  ^
 [...]/libgomp.oacc-c++/declare-pr94120.C:21:30: error: ‘C’ must be a 
variable declared in the same scope as ‘#pragma acc declare’

Please have a look, and as necessary file GCC PRs, and XFAIL the
'libgomp.oacc-c++/declare-pr94120.C' execution testing for
'-DACC_MEM_SHARED=0'.


Grüße
  Thomas


On 2020-03-11T13:28:44+0100, Tobias Burnus  wrote:

--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-c++/declare-pr94120.C
@@ -0,0 +1,57 @@
+#include 
+#include 
+
+#define N 8
+
+namespace one {
+  int A[N] = { 1, 2, 3, 4, 5, 6, 7, 8 };
+  #pragma acc declare copyin (A)
+};
+
+namespace outer {
+  namespace inner {
+int B[N];
+#pragma acc declare create (B)
+  };
+};
+
+static void
+f (void)
+{
+  int i;
+  int C[N];
+  #pragma acc declare copyout (C)
+
+  if (!acc_is_present (::A, sizeof (one::A)))
+abort ();
+
+  if (!acc_is_present (::inner::B, sizeof (outer::inner::B)))
+abort ();
+
+#pragma acc parallel
+  for (i = 0; i < N; i++)
+{
+  outer::inner::B[i] = one::A[i];
+  C[i] = outer::inner::B[i];
+}
+
+  for (i = 0; i < N; i++)
+{
+  if (C[i] != i + 1)
+abort ();
+}
+
+#pragma acc parallel
+  for (i = 0; i < N; i++)
+if (outer::inner::B[i] != i + 1)
+  abort ();
+}
+
+
+int
+main (int argc, char **argv)
+{
+  f ();
+
+  return 0;
+}

-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
r10-7810-g85d8c05a02bf7d1b256f806582a11e3fd8970a32
commit 85d8c05a02bf7d1b256f806582a11e3fd8970a32
Author: Tobias Burnus 
Date:   Mon Apr 20 12:38:50 2020 +0200

Fix declare copyout in libgomp.oacc-c++/declare-pr94120.C

Testing on the host does not make sense for 'declare copyout' for
a same-scope stack-allocated variable. Once the copyout is done,
the variable is gone. Hence, test the variable on the device. This
can be revisit after the OpenACC semantic has been fixed; but with
that fix, the test PASSes again with devices.

PR middle-end/94120
* testsuite/libgomp.oacc-c++/declare-pr94120.C: Fix 'declare copy(out)'
test case.

diff --git a/libgomp/ChangeLog b/libgomp/ChangeLog
index ce71ac6e783..b1cf297a0d7 100644
--- a/libgomp/ChangeLog
+++ b/libgomp/ChangeLog
@@ -1,3 +1,9 @@
+2020-04-20  Tobias Burnus  
+
+	PR middle-end/94120
+	* testsuite/libgomp.oacc-c++/declare-pr94120.C: Fix 'declare copy(out)'
+	test case.
+
 2020-04-17  Tobias Burnus  
 
 	PR middle-end/94635
diff --git a/libgomp/testsuite/libgomp.oacc-c++/declare-pr94120.C b/libgomp/testsuite/libgomp.oacc-c++/declare-pr94120.C
index 1e1254187ea..ed69359b533 100644
--- a/libgomp/testsuite/libgomp.oacc-c++/declare-pr94120.C
+++ b/libgomp/testsuite/libgomp.oacc-c++/declare-pr94120.C
@@ -35,6 +35,7 @@ f (void)
   C[i] = outer::inner::B[i];
 }
 
+#pragma acc parallel
   for (i = 0; i < N; i++)
 {
   if (C[i] != i + 1)

[PATCH,rs6000] enable -fweb for small loops unrolling

[guojiufu via Gcc-patches]

Hi,

Previously -fweb was disabled if only unroll small loops.  After that
we find there is cases where it could help to rename pseudos and aovid
some anti-dependence which may occur after unroll.

Below is a patch to disable -fweb during loop unrolling.

Bootstrap and regtest pass on powerpc, spec2017 run shows no performance
downgrade.

Is this ok for trunk?

BR,
Jiufu

gcc/
2020-04-20  Jiufu Guo   

* common/config/rs6000/rs6000-common.c
(rs6000_option_optimization_table)[OPT_LEVELS_ALL]: Remove turn off
-fweb.
* config/rs6000/rs6000.c (rs6000_option_override_internal): Avoid to
set flag_web. 


---
 gcc/common/config/rs6000/rs6000-common.c | 5 ++---
 gcc/config/rs6000/rs6000.c   | 4 +---
 2 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/gcc/common/config/rs6000/rs6000-common.c 
b/gcc/common/config/rs6000/rs6000-common.c
index 4f38d566844..87f7fda940a 100644
--- a/gcc/common/config/rs6000/rs6000-common.c
+++ b/gcc/common/config/rs6000/rs6000-common.c
@@ -38,9 +38,8 @@ static const struct default_options 
rs6000_option_optimization_table[] =
loops at -O2 and above by default.  */
 { OPT_LEVELS_2_PLUS_SPEED_ONLY, OPT_funroll_loops, NULL, 1 },
 { OPT_LEVELS_2_PLUS_SPEED_ONLY, OPT_munroll_only_small_loops, NULL, 1 },
-/* -fweb and -frename-registers are useless in general for rs6000,
-   turn them off.  */
-{ OPT_LEVELS_ALL, OPT_fweb, NULL, 0 },
+
+/* -frename-registers is not very helpful for rs6000, turn it off.  */
 { OPT_LEVELS_ALL, OPT_frename_registers, NULL, 0 },
 
 /* Double growth factor to counter reduced min jump length.  */
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index a2992e682c8..6a9e701bd60 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -4543,7 +4543,7 @@ rs6000_option_override_internal (bool global_init_p)
   SCHED_PRESSURE_MODEL);
 
   /* Explicit -funroll-loops turns -munroll-only-small-loops off, and
-turns -fweb and -frename-registers on.  */
+turns -frename-registers on.  */
   if ((global_options_set.x_flag_unroll_loops && flag_unroll_loops)
   || (global_options_set.x_flag_unroll_all_loops
   && flag_unroll_all_loops))
@@ -4552,8 +4552,6 @@ rs6000_option_override_internal (bool global_init_p)
unroll_only_small_loops = 0;
  if (!global_options_set.x_flag_rename_registers)
flag_rename_registers = 1;
- if (!global_options_set.x_flag_web)
-   flag_web = 1;
}
 
   /* If using typedef char *va_list, signal that
-- 
2.17.1

Re: [RFC] split pseudos during loop unrolling in RTL unroller

[Segher Boessenkool]

Hi!

On Mon, Apr 20, 2020 at 09:56:34AM +0200, Richard Biener wrote:
> On Fri, Apr 17, 2020 at 10:51 PM Segher Boessenkool
>  wrote:
> > > Yeah well, but RTL is not in SSA form
> >
> > "Webs" are not the *same* as SSA, in a few crucial ways; but they serve
> > similar purposes: they both make code transformations easier to do.
> > Both do this by having more different (independent) names.
> >
> > > and there's no RTL IL verification
> > > in place to track degradation.
> >
> > Adding this isn't hard in principle.  But currently it is violated all
> > over the place, including in backend code.
> 
> It's a cheap excuse and clearly a lot of work.  But we've done it for GIMPLE
> and it was clearly worth it.  If only for documentation purposes.

Yes, I very much agree :-)  But how will we do this?  Make it warnings
only, and have those opt-in (for a port) even?

> > > And we even work in the opposite way
> > > when expanding to RTL from SSA, coalescing as much as we can ...
> >
> > Which often is bad.  A lot of what expand does is premature optimisation
> > that a) is much too complicated, and b) results in worse code in the end.
> > Expand should not try to do *anything* "interesting", it should "merely"
> > translate to RTL.
> >
> > (And in a way that can be debugged sanely at all, if possible ;-) )
> 
> Sure.  I've tried to turn off TER with only moderate success.  Another 
> approach
> would be to not do any coalescing but for PHIs (and maybe there only for edges
> where we cannot insert copies on w/o splitting it).

Yeah, that would be much simpler to do as well.

> But clearly all the magic expand does now should materialize itself on
> GIMPLE (see the patch series Martin posted for vcond* / vec_cmp*
> "expansion" on GIMPLE).

Probably most, yeah, but some things that expand does should be done
much *later* in RTL even :-)

> It's the magic that requires TER and TER clearly
> introduces the most noise in the GIMPLE -> RTL translation step (as to
> code motion and initial instruction selection if it "fails").

Expand does a lot of things that are very much historic, too.


Segher

[PATCH v5 GCC] libffi/test: Fix compilation for build sysroot

[Maciej W. Rozycki via Gcc-patches]

Fix a problem with the libffi testsuite using a method to determine the 
compiler to use resulting in the tool being different from one the 
library has been built with, and causing a catastrophic failure from the 
inability to actually choose any compiler at all in a cross-compilation 
configuration.

Address this problem by providing a DejaGNU configuration file defining 
the compiler to use, via the CC_FOR_TARGET TCL variable, set from $CC by 
autoconf, which will have all the required options set for the target 
compiler to build executables in the environment configured, removing 
failures like:

FAIL: libffi.call/closure_fn0.c -W -Wall -Wno-psabi -O0 (test for excess errors)
Excess errors:
default_target_compile: No compiler to compile with
UNRESOLVED: libffi.call/closure_fn0.c -W -Wall -Wno-psabi -O0 compilation 
failed to produce executable

and bringing overall test results for the `riscv64-linux-gnu' target 
(here with the `x86_64-linux-gnu' host and RISC-V QEMU in the Linux user 
emulation mode as the target board) from:

=== libffi Summary ===

# of unexpected failures708
# of unresolved testcases   708
# of unsupported tests  30

to:

=== libffi Summary ===

# of expected passes1934
# of unsupported tests  28

This is a combined backport of the relevant parts of upstream libffi 
changes as follows:

- commit 8308984e479e ("[PATCH] Make sure we're running dejagnu tests 
  with the right compiler."),

- commit 2d9b3939751b ("[PATCH] Fix for closures with sunpro compiler"),

- commit 0c3824702d3d ("[PATCH] Always set CC_FOR_TARGET for dejagnu, to
  make the testsuite respect $CC"),

- commit 7d698125b1f0 ("[PATCH] Use the proper C++ compiler to run C++
  tests"),

- commit 6b6df1a7bb37 ("[PATCH] Adds `local.exp` to CLEANFILES"),

- commit 6cf0dea78a5a ("[PATCH] Change CLEANFILES to DISTCLEANFILES")

libffi/
* Makefile.am (DISTCLEANFILES): New variable.
* configure.ac: Produce `local.exp'.
* Makefile.in: Regenerate.
* configure: Regenerate.
* testsuite/Makefile.am (EXTRA_DEJAGNU_SITE_CONFIG): New 
variable.
* testsuite/Makefile.in: Regenerate.
---
Hi,

 As you may recall I have proposed a clean solution for the problem 
discussed here, which I posted for inclusion with upstream libffi, with an 
intent to have it backported to GCC as soon as it has been accepted by the 
maintainer, as a part of patch series that have been archived here: 
.

 I have pinged the series last week:
, 
and then again just now: 
.

 I think with the GCC 10 release about to be rolled out we need a 
contingency plan, so I propose that, unless my proposed libffi changes 
have been accepted upstream real soon now, such as by the end of this 
coming Friday AoE, we include this change instead.

 Therefore, OK to apply once Friday AoE has passed and the upstream libffi 
changes have gone nowhere?

  Maciej

[Change log corrected to include history before v4.]

Changes from v4:

- Replace with a backport of the partially complete solution already 
  present upstream.

Changes from v3:

- Replace with a backport of a change submitted upstream.

Changes from v2:

- Revert to v1.

- Rename testsuite/libffi-test-support.exp.in to
  testsuite/libffi-site-extra.exp.in.

Changes from v1:

- Remove testsuite/libffi-test-support.exp.in and the associated changes.

- Pass $(CC) via `--tool_exec' in $(AM_RUNTESTFLAGS).
---
 libffi/Makefile.am   |3 +++
 libffi/Makefile.in   |4 
 libffi/configure |5 +
 libffi/configure.ac  |5 +
 libffi/testsuite/Makefile.am |2 ++
 libffi/testsuite/Makefile.in |1 +
 6 files changed, 20 insertions(+)

gcc-test-libffi-cc-for-target.diff
Index: gcc/libffi/Makefile.am
===
--- gcc.orig/libffi/Makefile.am
+++ gcc/libffi/Makefile.am
@@ -15,6 +15,9 @@ EXTRA_DIST = LICENSE ChangeLog.v1 Change
libffi.xcodeproj/project.pbxproj\
libtool-ldflags
 
+# local.exp is generated by configure
+DISTCLEANFILES = local.exp
+
 # Automake Documentation:
 # If your package has Texinfo files in many directories, you can use the
 # variable TEXINFO_TEX to tell Automake where to find the canonical
Index: gcc/libffi/Makefile.in
===
--- gcc.orig/libffi/Makefile.in
+++ gcc/libffi/Makefile.in
@@ -454,6 +454,9 @@ EXTRA_DIST = LICENSE ChangeLog.v1 Change
libtool-ldflags
 
 
+# local.exp is generated by configure
+DISTCLEANFILES = local.exp
+
 # Automake Documentation:
 # If your package has Texinfo files in many directories, you can use the
 # variable TEXINFO_TEX 

Re: [PATCH V2]aarch64: falkor-tag-collision-avoidance.c fix valid_src_p for use of uninitialized value

[Andrea Corallo]

Kyrylo Tkachov  writes:

>> Bootstrapped and reg tested.  Ok for release/gcc-9?
>
> Ok.
> Thanks,
> Kyrill

Pushed as 5e022e3b3f7b.

Thanks
  Andrea

Re: [PATCH] Fix spacing in symtab_node::dump_references.

[Martin Liška]

On 4/20/20 1:03 PM, Martin Jambor wrote:

Hi,

On Mon, Apr 20 2020, Martin Liška wrote:

Hi.

The patch is about a space printed in between multiple
entries in Referring and References in symtab_node dump.

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

Ready to be installed?


Given that "called by" and "calls" cgraph_edge list dumps also do not
care about producing trailing spaces, I guess this is consistent and
fine, except that...


Yes, we don't care about trailing spaces.





gcc/ChangeLog:

2020-04-20  Martin Liska  

* symtab.c (symtab_node::dump_references): Add space after
one entry.
(symtab_node::dump_referring): Likewise.
---
   gcc/symtab.c | 14 ++
   1 file changed, 6 insertions(+), 8 deletions(-)


diff --git a/gcc/symtab.c b/gcc/symtab.c
index a36cdccf9c1..cced6bd8ac7 100644
--- a/gcc/symtab.c
+++ b/gcc/symtab.c
@@ -800,11 +800,10 @@ symtab_node::dump_references (FILE *file)
int i;
for (i = 0; iterate_reference (i, ref); i++)
  {
-  fprintf (file, "%s (%s)",
-  ref->referred->dump_asm_name (),
-  ipa_ref_use_name [ref->use]);
+  fprintf (file, "%s (%s) ", ref->referred->dump_asm_name (),
+  ipa_ref_use_name[ref->use]);
if (ref->speculative)
-   fprintf (file, " (speculative)");
+   fprintf (file, "(speculative)");


...you probably want a trailing space also here,


Yes, thank you!

I'm going to install the patch with this adjusted.

Thanks,
Martin




  }
fprintf (file, "\n");
  }
@@ -818,11 +817,10 @@ symtab_node::dump_referring (FILE *file)
int i;
for (i = 0; iterate_referring(i, ref); i++)
  {
-  fprintf (file, "%s (%s)",
-  ref->referring->dump_asm_name (),
-  ipa_ref_use_name [ref->use]);
+  fprintf (file, "%s (%s) ", ref->referring->dump_asm_name (),
+  ipa_ref_use_name[ref->use]);
if (ref->speculative)
-   fprintf (file, " (speculative)");
+   fprintf (file, "(speculative) ");


like you already have here.

Martin

Re: [PATCH 1/2] testsuite: [arm/cde] Include arm_cde.h and arm_mve.h in arm_v8*m_main_cde*

[Christophe Lyon via Gcc-patches]

On Mon, 20 Apr 2020 at 13:25, Matthew Malcomson
 wrote:
>
> On 20/04/2020 08:47, Christophe Lyon via Gcc-patches wrote:
> > Since arm_cde.h includes stdint.h, its use requires the presence of
> > the right gnu/stub-*.h, so make sure to include it when checking the
> > arm_v8*m_main_cde* effective targets, otherwise we can decide CDE is
> > supported while it's not really (all tests that use arm_v8m_main_cde*
> > also include arm_cde.h aynway).
> >
> > Similarly for the effective targets that also require MVE.
> >
> > This makes several tests unsupported rather than fail.
>
> Hi Christophe,
>
> This looks like a good idea to me -- though I'm not a maintainer so that
> means little ;-)
>
> I just wanted to ask -- is this needed mainly if testing without a fully
> functional C99 environment?
> I would imagine that a fully set up environment would have some sort of
> `stdint.h` available, even if not using the glibc gnu/stub-*.h files
> (e.g. using the newlib headers).
>

That's the same problem as with my patches about the MVE tests: for
arm-linux-gnueabi[hf] toolchains,
glibc does not support multilibs, we can't have both soft[fp] and hard
versions in the same toolchain,
unlike arm-eabi. So stdint.h is present, but at some point it tries to
include the  version of gnu/stub-XXX.h
which is not part of the toolchain.


> Cheers,
> Matthew
>
> > ---
> >   gcc/testsuite/lib/target-supports.exp | 10 --
> >   1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/gcc/testsuite/lib/target-supports.exp 
> > b/gcc/testsuite/lib/target-supports.exp
> > index d16498d..23a5abf 100644
> > --- a/gcc/testsuite/lib/target-supports.exp
> > +++ b/gcc/testsuite/lib/target-supports.exp
> > @@ -5140,21 +5140,25 @@ proc add_options_for_arm_v8_2a_bf16_neon { flags } {
> >   #   /* { dg-add-options arm_v8m_main_cde } */
> >   # The tests are valid for Arm.
> >
> > -foreach { armfunc armflag armdef } {
> > +foreach { armfunc armflag armdef arminc } {
> >   arm_v8m_main_cde
> >   "-march=armv8-m.main+cdecp0+cdecp6 -mthumb"
> >   "defined (__ARM_FEATURE_CDE)"
> > + ""
> >   arm_v8m_main_cde_fp
> >   "-march=armv8-m.main+fp+cdecp0+cdecp6 -mthumb -mfpu=auto"
> >   "defined (__ARM_FEATURE_CDE) && defined (__ARM_FP)"
> > + ""
> >   arm_v8_1m_main_cde_mve
> >   "-march=armv8.1-m.main+mve+cdecp0+cdecp6 -mthumb -mfpu=auto"
> >   "defined (__ARM_FEATURE_CDE) && defined (__ARM_FEATURE_MVE)"
> > + "#include "
> >   arm_v8_1m_main_cde_mve_fp
> >   "-march=armv8.1-m.main+mve.fp+cdecp0+cdecp6 -mthumb 
> > -mfpu=auto"
> >   "defined (__ARM_FEATURE_CDE) || __ARM_FEATURE_MVE == 3"
> > + "#include "
> >   } {
> > -eval [string map [list FUNC $armfunc FLAG $armflag DEF $armdef ] {
> > +eval [string map [list FUNC $armfunc FLAG $armflag DEF $armdef INC 
> > $arminc ] {
> >   proc check_effective_target_FUNC_ok_nocache { } {
> >   global et_FUNC_flags
> >   set et_FUNC_flags ""
> > @@ -5167,6 +5171,8 @@ foreach { armfunc armflag armdef } {
> >   #if !(DEF)
> >   #error "DEF failed"
> >   #endif
> > + #include 
> > + INC
> >   } "FLAG"] } {
> >   set et_FUNC_flags "FLAG"
> >   return 1
> >
>

[PATCH 1/1] testsuite: Handle --save-temps in schedule-cleanups

[Christophe Lyon via Gcc-patches]

Some tests use --save-temps, but schedule-cleanups strictly matches
-save-temps, so we leave many temporary files after validation.
Instead of fixing every offending testcase, it's simpler and
future-proof to make schedule-cleanups handle both --save-temps and
-save-temps.

2020-04-20  Christophe Lyon  

gcc/testsuite/
* lib/gcc-dg.exp (schedule-cleanups): Accept --save-temps.
---
 gcc/testsuite/lib/gcc-dg.exp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
index cccd3ce..27cc7c1 100644
--- a/gcc/testsuite/lib/gcc-dg.exp
+++ b/gcc/testsuite/lib/gcc-dg.exp
@@ -171,7 +171,7 @@ proc schedule-cleanups { opts } {
verbose "dg-keep-saved-temps ${keep_saved_temps_suffixes}" 2
 }
 # -save-temps -> cleanup-saved-temps()
-if [regexp -- {(^|\s+)-save-temps(\s+|$)} $opts] {
+if [regexp -- {(^|\s+)-?-save-temps(\s+|$)} $opts] {
verbose "Cleanup -save-temps seen" 4
if [info exists keep_saved_temps_suffixes] {
append finalcode "cleanup-saved-temps 
${keep_saved_temps_suffixes}\n"
-- 
2.7.4

Re: [PATCH 1/2] testsuite: [arm/cde] Include arm_cde.h and arm_mve.h in arm_v8*m_main_cde*

[Matthew Malcomson]

On 20/04/2020 08:47, Christophe Lyon via Gcc-patches wrote:

Since arm_cde.h includes stdint.h, its use requires the presence of
the right gnu/stub-*.h, so make sure to include it when checking the
arm_v8*m_main_cde* effective targets, otherwise we can decide CDE is
supported while it's not really (all tests that use arm_v8m_main_cde*
also include arm_cde.h aynway).

Similarly for the effective targets that also require MVE.

This makes several tests unsupported rather than fail.


Hi Christophe,

This looks like a good idea to me -- though I'm not a maintainer so that 
means little ;-)


I just wanted to ask -- is this needed mainly if testing without a fully 
functional C99 environment?
I would imagine that a fully set up environment would have some sort of 
`stdint.h` available, even if not using the glibc gnu/stub-*.h files 
(e.g. using the newlib headers).


Cheers,
Matthew


---
  gcc/testsuite/lib/target-supports.exp | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index d16498d..23a5abf 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -5140,21 +5140,25 @@ proc add_options_for_arm_v8_2a_bf16_neon { flags } {
  #   /* { dg-add-options arm_v8m_main_cde } */
  # The tests are valid for Arm.
  
-foreach { armfunc armflag armdef } {

+foreach { armfunc armflag armdef arminc } {
arm_v8m_main_cde
"-march=armv8-m.main+cdecp0+cdecp6 -mthumb"
"defined (__ARM_FEATURE_CDE)"
+   ""
arm_v8m_main_cde_fp
"-march=armv8-m.main+fp+cdecp0+cdecp6 -mthumb -mfpu=auto"
"defined (__ARM_FEATURE_CDE) && defined (__ARM_FP)"
+   ""
arm_v8_1m_main_cde_mve
"-march=armv8.1-m.main+mve+cdecp0+cdecp6 -mthumb -mfpu=auto"
"defined (__ARM_FEATURE_CDE) && defined (__ARM_FEATURE_MVE)"
+   "#include "
arm_v8_1m_main_cde_mve_fp
"-march=armv8.1-m.main+mve.fp+cdecp0+cdecp6 -mthumb -mfpu=auto"
"defined (__ARM_FEATURE_CDE) || __ARM_FEATURE_MVE == 3"
+   "#include "
} {
-eval [string map [list FUNC $armfunc FLAG $armflag DEF $armdef ] {
+eval [string map [list FUNC $armfunc FLAG $armflag DEF $armdef INC $arminc 
] {
proc check_effective_target_FUNC_ok_nocache { } {
global et_FUNC_flags
set et_FUNC_flags ""
@@ -5167,6 +5171,8 @@ foreach { armfunc armflag armdef } {
#if !(DEF)
#error "DEF failed"
#endif
+   #include 
+   INC
} "FLAG"] } {
set et_FUNC_flags "FLAG"
return 1

[patch, committed] Fix for PR 91800

[Thomas Koenig via Gcc-patches]

Hello world,

I just committed as obvious (alternatively, reviewed and
committed) Steve's patch for PR 91800 from the PR,
after regression-testing.

Regards

Thomas

PR 91800 - reject Hollerith constants as type initializer.

2020-04-20  Steve Kargl  
Thomas Koenig  

PR fortran/91800
* decl.c (variable_decl): Reject Hollerith constants as type
initializer.

2020-04-20  Steve Kargl  
Thomas Koenig  

PR fortran/91800
* gfortran.dg/hollerith_9.f90: New test.


diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index b3ed63c97cc..d650407da41 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -2903,6 +2903,15 @@ variable_decl (int elem)
   goto cleanup;
 }
 
+  if (gfc_current_state () == COMP_DERIVED
+  && initializer && initializer->ts.type == BT_HOLLERITH)
+{
+  gfc_error ("Initialization of structure component with a HOLLERITH "
+		 "constant at %L is not allowed", >where);
+  m = MATCH_ERROR;
+  goto cleanup;
+}
+
   if (gfc_current_state () == COMP_DERIVED
   && gfc_current_block ()->attr.pdt_template)
 {
! { dg-do compile }
! PR 91800 - this used to cause an ICE.
module m
   type t(n) ! { dg-error "does not have a component corresponding to parameter" }
  integer, len :: n = 4habcd ! { dg-error "Initialization of structure component with a HOLLERITH constant" }
   end type
end

Re: [PATCH] Fix spacing in symtab_node::dump_references.

[Martin Jambor]

Hi,

On Mon, Apr 20 2020, Martin Liška wrote:
> Hi.
>
> The patch is about a space printed in between multiple
> entries in Referring and References in symtab_node dump.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?

Given that "called by" and "calls" cgraph_edge list dumps also do not
care about producing trailing spaces, I guess this is consistent and
fine, except that...

>
> gcc/ChangeLog:
>
> 2020-04-20  Martin Liska  
>
>   * symtab.c (symtab_node::dump_references): Add space after
>   one entry.
>   (symtab_node::dump_referring): Likewise.
> ---
>   gcc/symtab.c | 14 ++
>   1 file changed, 6 insertions(+), 8 deletions(-)
>
>
> diff --git a/gcc/symtab.c b/gcc/symtab.c
> index a36cdccf9c1..cced6bd8ac7 100644
> --- a/gcc/symtab.c
> +++ b/gcc/symtab.c
> @@ -800,11 +800,10 @@ symtab_node::dump_references (FILE *file)
>int i;
>for (i = 0; iterate_reference (i, ref); i++)
>  {
> -  fprintf (file, "%s (%s)",
> -ref->referred->dump_asm_name (),
> -ipa_ref_use_name [ref->use]);
> +  fprintf (file, "%s (%s) ", ref->referred->dump_asm_name (),
> +ipa_ref_use_name[ref->use]);
>if (ref->speculative)
> - fprintf (file, " (speculative)");
> + fprintf (file, "(speculative)");

...you probably want a trailing space also here,

>  }
>fprintf (file, "\n");
>  }
> @@ -818,11 +817,10 @@ symtab_node::dump_referring (FILE *file)
>int i;
>for (i = 0; iterate_referring(i, ref); i++)
>  {
> -  fprintf (file, "%s (%s)",
> -ref->referring->dump_asm_name (),
> -ipa_ref_use_name [ref->use]);
> +  fprintf (file, "%s (%s) ", ref->referring->dump_asm_name (),
> +ipa_ref_use_name[ref->use]);
>if (ref->speculative)
> - fprintf (file, " (speculative)");
> + fprintf (file, "(speculative) ");

like you already have here.

Martin

[PATCH] Fix spacing in symtab_node::dump_references.

[Martin Liška]

Hi.

The patch is about a space printed in between multiple
entries in Referring and References in symtab_node dump.

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

Ready to be installed?
Thanks,
Martin

gcc/ChangeLog:

2020-04-20  Martin Liska  

* symtab.c (symtab_node::dump_references): Add space after
one entry.
(symtab_node::dump_referring): Likewise.
---
 gcc/symtab.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)


diff --git a/gcc/symtab.c b/gcc/symtab.c
index a36cdccf9c1..cced6bd8ac7 100644
--- a/gcc/symtab.c
+++ b/gcc/symtab.c
@@ -800,11 +800,10 @@ symtab_node::dump_references (FILE *file)
   int i;
   for (i = 0; iterate_reference (i, ref); i++)
 {
-  fprintf (file, "%s (%s)",
-	   ref->referred->dump_asm_name (),
-	   ipa_ref_use_name [ref->use]);
+  fprintf (file, "%s (%s) ", ref->referred->dump_asm_name (),
+	   ipa_ref_use_name[ref->use]);
   if (ref->speculative)
-	fprintf (file, " (speculative)");
+	fprintf (file, "(speculative)");
 }
   fprintf (file, "\n");
 }
@@ -818,11 +817,10 @@ symtab_node::dump_referring (FILE *file)
   int i;
   for (i = 0; iterate_referring(i, ref); i++)
 {
-  fprintf (file, "%s (%s)",
-	   ref->referring->dump_asm_name (),
-	   ipa_ref_use_name [ref->use]);
+  fprintf (file, "%s (%s) ", ref->referring->dump_asm_name (),
+	   ipa_ref_use_name[ref->use]);
   if (ref->speculative)
-	fprintf (file, " (speculative)");
+	fprintf (file, "(speculative) ");
 }
   fprintf (file, "\n");
 }

Re: [Patch, fortran] PR fortran/90350 - ubound ICE on assumed size array even though explicit bound is specified

[Thomas Koenig via Gcc-patches]

Am 19.04.20 um 20:03 schrieb José Rui Faustino de Sousa via Fortran:

Hi Thomas!

 > ? In other words, maybe a check on the upper bound
 > of the last dimension would be better?
 >

You mean enforcing:

C928 (R921) The second subscript shall not be omitted from a 
subscript-triplet in the last dimension of an assumed-size array.


right?

If I have correctly understood the way things are done this is a more 
general test which is already done at resolve.c around line 4690.


I just checked that it works, so I think this is fine.  It looks
like assumed_size_refs_4.f90 already checks for that, so that is
fine.

Other than that, a couple of points:

The style you used for your patch,

+  if (upper
+ && type == AR_FULL
+ && as
+ && as->type == AS_ASSUMED_SIZE)

doesn't conform to the GNU style guidelines. This should go on one
line (as long as it fits).

Also, I could not apply your patch via copy & paste from the text of
the e-mail. Could you send patches as an attachment in the future?
Due do some unfortunate limitations of the current mailing list
software, it is probably best if you send it as a *.txt file.

So, OK for trunk with the cosmetic corrections above.

Thanks a lot for the patch, and welcome aboard!


 > A question: Do you have a copyright assignment yet?
 >

Yes, I have already done that.


Excellent.

Best regards

Thomas

Re: [Patch fortran/93364] [9/10 Regression] ICE in gfc_set_array_spec, at fortran/array.c:879

[Thomas Koenig via Gcc-patches]

Hi Harald,


The attached patch fixes that.  OK for mainline / backport to 9-branch?


OK for both.

Thanks a lot for the patch!

Regards

Thomas

[PATCH] Do not remove ifunc_resolver in LTO.

[Martin Liška]

Hi.

The patch prevents a ifunc alias from removal in remove unreachable nodes.
Note that ifunc alias lives in a COMDAT section and so that
cgraph_node::can_remove_if_no_direct_calls_and_refs_p returned true for it.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
I was unable to create a lto test-case where a linked binary could be
scanned for assembly.

Ready to be installed?
Thanks,
Martin

gcc/ChangeLog:

2020-04-20  Martin Liska  

PR lto/94659
* cgraph.h (cgraph_node::can_remove_if_no_direct_calls_and_refs_p):
Do not remove ifunc_resolvers in remove unreachable nodes in LTO.
---
 gcc/cgraph.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


diff --git a/gcc/cgraph.h b/gcc/cgraph.h
index 43de3b4a8ac..5ddeb65269b 100644
--- a/gcc/cgraph.h
+++ b/gcc/cgraph.h
@@ -3162,7 +3162,7 @@ cgraph_node::can_remove_if_no_direct_calls_and_refs_p (void)
 return false;
   /* Only COMDAT functions can be removed if externally visible.  */
   if (externally_visible
-  && (!DECL_COMDAT (decl)
+  && ((!DECL_COMDAT (decl) || ifunc_resolver)
 	  || forced_by_abi
 	  || used_from_object_file_p ()))
 return false;

[stage1][PATCH] gcov: print total_lines summary for all files.

[Martin Liška]

Hi.

The patch prints total lines summary after all files are processed.
Moreover, I remove a check in generate_results where we should
be always given file_name != NULL.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
I'm planning to install the in next stage1 if there are not objections.

Thanks,
Martin

gcc/ChangeLog:

2020-04-17  Martin Liska  

PR gcov-profile/94636
* gcov.c (main): Print total lines summary at the end.
(generate_results): Expect file_name always being non-null.
Print newline after intermediate file is printed in order to align with
what we do for normal files.
---
 gcc/gcov.c | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)


diff --git a/gcc/gcov.c b/gcc/gcov.c
index a291bac3e9e..488847231c2 100644
--- a/gcc/gcov.c
+++ b/gcc/gcov.c
@@ -874,6 +874,9 @@ main (int argc, char **argv)
 	}
 }
 
+  if (!flag_use_stdout)
+executed_summary (total_lines, total_executed);
+
   return 0;
 }
 
@@ -1410,17 +1413,13 @@ generate_results (const char *file_name)
 }
 
   name_map needle;
-
-  if (file_name)
-{
-  needle.name = file_name;
-  vector::iterator it = std::find (names.begin (), names.end (),
-		 needle);
-  if (it != names.end ())
-	file_name = sources[it->src].coverage.name;
-  else
-	file_name = canonicalize_name (file_name);
-}
+  needle.name = file_name;
+  vector::iterator it
+= std::find (names.begin (), names.end (), needle);
+  if (it != names.end ())
+file_name = sources[it->src].coverage.name;
+  else
+file_name = canonicalize_name (file_name);
 
   gcov_intermediate_filename = get_gcov_intermediate_filename (file_name);
 
@@ -1462,7 +1461,11 @@ generate_results (const char *file_name)
   if (flag_gcov_file)
 	{
 	  if (flag_json_format)
-	output_json_intermediate_file (json_files, src);
+	{
+	  output_json_intermediate_file (json_files, src);
+	  if (!flag_use_stdout)
+		fnotice (stdout, "\n");
+	}
 	  else
 	{
 	  if (flag_use_stdout)
@@ -1509,9 +1512,6 @@ generate_results (const char *file_name)
 	}
 	}
 }
-
-  if (!file_name)
-executed_summary (total_lines, total_executed);
 }
 
 /* Release all memory used.  */

Re: GCC 9 backports

[Martin Liška]

On 4/3/20 12:32 PM, Martin Liška wrote:

Hi.

There's one more I've tested.

Martin


And one more.

Martin
>From 6db982d1cfccbde2a5812edf82ad330cf327bc23 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Fri, 17 Apr 2020 09:33:05 +0200
Subject: [PATCH] Backport e9f799d25973fc38022c5ea71ed5a2bca58a847f

ChangeLog:

2020-04-17  Martin Liska  
	Jonathan Yong <10wa...@gmail.com>

	PR gcov-profile/94570
	* ltmain.sh: Do not define HAVE_DOS_BASED_FILE_SYSTEM
	for CYGWIN.

gcc/ChangeLog:

2020-04-17  Martin Liska  
	Jonathan Yong <10wa...@gmail.com>

	PR gcov-profile/94570
	* coverage.c (coverage_init): Use separator properly.

include/ChangeLog:

2020-04-17  Martin Liska  
	Jonathan Yong <10wa...@gmail.com>

	PR gcov-profile/94570
	* filenames.h (defined): Do not define HAVE_DOS_BASED_FILE_SYSTEM
	for CYGWIN.
---
 gcc/coverage.c  | 12 ++--
 include/filenames.h |  3 ++-
 ltmain.sh   |  4 ++--
 3 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/gcc/coverage.c b/gcc/coverage.c
index 1ffefd5f482..9be446a862d 100644
--- a/gcc/coverage.c
+++ b/gcc/coverage.c
@@ -1201,6 +1201,11 @@ coverage_obj_finish (vec *ctor)
 void
 coverage_init (const char *filename)
 {
+#if HAVE_DOS_BASED_FILE_SYSTEM
+  const char *separator = "\\";
+#else
+  const char *separator = "/";
+#endif
   int len = strlen (filename);
   int prefix_len = 0;
 
@@ -1217,11 +1222,6 @@ coverage_init (const char *filename)
 	 of filename in order to prevent file path clashing.  */
   if (profile_data_prefix)
 	{
-#if HAVE_DOS_BASED_FILE_SYSTEM
-	  const char *separator = "\\";
-#else
-	  const char *separator = "/";
-#endif
 	  filename = concat (getpwd (), separator, filename, NULL);
 	  filename = mangle_path (filename);
 	  len = strlen (filename);
@@ -1240,7 +1240,7 @@ coverage_init (const char *filename)
   if (profile_data_prefix)
 {
   memcpy (da_file_name, profile_data_prefix, prefix_len);
-  da_file_name[prefix_len++] = '/';
+  da_file_name[prefix_len++] = *separator;
 }
   memcpy (da_file_name + prefix_len, filename, len);
   strcpy (da_file_name + prefix_len + len, GCOV_DATA_SUFFIX);
diff --git a/include/filenames.h b/include/filenames.h
index 1bcfddb87ac..790a27db873 100644
--- a/include/filenames.h
+++ b/include/filenames.h
@@ -32,7 +32,8 @@ Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston, MA 02110-1301, USA.
 extern "C" {
 #endif
 
-#if defined(__MSDOS__) || defined(_WIN32) || defined(__OS2__) || defined (__CYGWIN__)
+#if defined(__MSDOS__) || (defined(_WIN32) && ! defined(__CYGWIN__)) || \
+defined(__OS2__)
 #  ifndef HAVE_DOS_BASED_FILE_SYSTEM
 #define HAVE_DOS_BASED_FILE_SYSTEM 1
 #  endif
diff --git a/ltmain.sh b/ltmain.sh
index 79f9ba89af5..70990740b6c 100644
--- a/ltmain.sh
+++ b/ltmain.sh
@@ -3425,8 +3425,8 @@ int setenv (const char *, const char *, int);
 # define PATH_SEPARATOR ':'
 #endif
 
-#if defined (_WIN32) || defined (__MSDOS__) || defined (__DJGPP__) || \
-  defined (__OS2__)
+#if (defined (_WIN32) && ! defined(__CYGWIN__)) || defined (__MSDOS__) || \
+  defined (__DJGPP__) || defined (__OS2__)
 # define HAVE_DOS_BASED_FILE_SYSTEM
 # define FOPEN_WB "wb"
 # ifndef DIR_SEPARATOR_2
-- 
2.26.0

Re: [PATCH] libstdc++: don't use #include_next in c_global headers

[Jonathan Wakely via Gcc-patches]

On 20/04/20 07:01 +0200, Helmut Grohne wrote:

The  and  headers need their counter parts  and
 from the libc respectively, but libstdc++ wraps these
headers. Now  and  include these headers using

$ echo '#include ' | g++ -x c++ -E - -isystem /usr/include >/dev/null
In file included from :1:
/usr/include/c++/9/cstdlib:75:15: fatal error: stdlib.h: No such file or 
directory
  75 | #include_next 
 |   ^~
compilation terminated.
$

What happens here is that g++ includes
libstdc++-v3/include/c_global/cstdlib. That header temporarily #defines
_GLIBCXX_INCLUDE_NEXT_C_HEADERS and then does #include_next .
libstdc++-v3's replacement libstdc++-v3/include/c_comaptibility/stdlib.h
happens to come earlier and is not considered.  Unfortunately, the
-isystem above inserted glibc's header before the location containing
, so the #include_next continues searching and fails to find
.

Now you are probably going to say that "-isystem /usr/include" is a bad
idea and that you shouldn't do that.


Right.


I'm inclined to agree. This isn't a
problem just yet. Debian wants to move /usr/include/stdlib.h to
/usr/include//stdlib.h. After that move, the problematic flag
becomes "-isystem /usr/include/". Unfortunately, around 30
Debian packages[1] do pass exactly that flag. Regardless whether doing
so is a bad idea, I guess we will have to support that.


Or Debian should fix what they're going to break.


I am proposing to replace those two #include_next with plain #include.
That'll solve the problem described above, but it is not entirely
obvious that doing so doesn't break something else.

After switching those #include_next to #include,
libstdc++-v3/include/c_global/cstdlib will continue to temporarily
will #include . Now, it'll search all include directories. It
may find libstdc++-v3/include/c_comaptibility/stdlib.h or the libc's
version. We cannot tell which. If it finds the one from libstdc++-v3,
the header will notice the _GLIBCXX_INCLUDE_NEXT_C_HEADERS macro and
immediately #include_next  skipping the rest of the header.
That in turn will find the libc version. So in both cases, it ends up
using the right one. Precisely what we wanted.


As Marc said, this doesn't work.

If a program tries to include  it needs to get the libstdc++
version, otherwise only the libc versions of certain functions are
defined. That means the additional C++ overloads such as ::abs(long)
and ::abs(long long) won't be defined. That is the reason why
libstdc++ provides its own .

And if you do -isystem /usr/include (or any other option that causes
libstdc++'s  to be skipped) that doesn't work. Only
::abs(int) gets defined.

So -isystem /usr/include breaks code, with or without your patch.

Re: [PATCH] Fold (add -1; zero_ext; add +1) operations to zero_ext when not zero (PR37451, PR61837)

[luoxhu via Gcc-patches]

Tiny update to accommodate unsigned int compare.

On 2020/4/20 16:21, luoxhu via Gcc-patches wrote:

Hi,

On 2020/4/18 00:32, Segher Boessenkool wrote:

On Thu, Apr 16, 2020 at 08:21:40PM -0500, Segher Boessenkool wrote:

On Wed, Apr 15, 2020 at 10:18:16AM +0100, Richard Sandiford wrote:

luoxhu--- via Gcc-patches  writes:

-count = simplify_gen_binary (PLUS, mode, count, const1_rtx);
+{
+  /* Fold (add -1; zero_ext; add +1) operations to zero_ext based on addop0
+is never zero, as gimple pass loop ch will do optimization to simplify
+the loop to NO loop for loop condition is false.  */


IMO the code needs to prove this, rather than just assume that previous
passes have made it so.


Well, it should gcc_assert it, probably.

It is the left-hand side of a+b...  it cannot be 0, because niter always
is simplified!


Scratch that...  it cannot be *constant* 0, but that isn't the issue here.


Sorry that my comments in the code is a bit misleading, it is actually not
related to loop-ch at all.  The instruction sequence at 255r.loop2_invariant:

25: NOTE_INSN_BASIC_BLOCK 5
26: r133:SI=r123:DI#0-0x1
   REG_DEAD r123:DI
27: r123:DI=zero_extend(r133:SI)
   REG_DEAD r133:SI
28: r124:DI=r124:DI+0x4
30: r134:CC=cmp(r123:DI,0)
31: pc={(r134:CC!=0)?L69:pc}

And 257r.loop2_doloop (inserted #72,#73,#74, and #31 is replaced by #71):

;; Determined upper bound -1.
Loop 2 is simple:
   simple exit 6 -> 7
   number of iterations: (plus:SI (subreg:SI (reg:DI 123 [ doloop.6 ]) 0)
 (const_int -1 [0x]))
   upper bound: 2147483646
   likely upper bound: 2147483646
   realistic bound: -1
...
72: r144:SI=r123:DI#0-0x1
73: r143:DI=zero_extend(r144:SI)
74: r142:DI=r143:DI+0x1
...
25: NOTE_INSN_BASIC_BLOCK 5
26: r133:SI=r123:DI#0-0x1
   REG_DEAD r123:DI
27: r123:DI=zero_extend(r133:SI)
   REG_DEAD r133:SI
28: r124:DI=r124:DI+0x4
30: r134:CC=cmp(r123:DI,0)
71: {pc={(r142:DI!=0x1)?L69:pc};r142:DI=r142:DI-0x1;clobber scratch;clobber 
scratch;}

increment_count is true ensures the (condition NE const1_rtx), r123:DI#0-0x1 is 
the loop number
of iterations in doloop, it is definitely >= 0, and r123:DI#0 also shouldn't be 
zero as the
loop upper bound is 2147483646(0x7fffe)???

Since this simplification is in doloop-modify,  there is already some doloop 
form check like
!desc->simple_p || desc->assumptions|| desc->infinite in doloop_valid_p, so it 
seems
not necessary to repeat check it here again?
Maybe we just need check the loop upper bound is LEU than 0x7fffe to avoid 
if
instruction #26 overflow?

0xfffe




Updated patch, thanks:


This "subtract/extend/add" existed for a long time and still annoying us
(PR37451, PR61837) when converting from 32bits to 64bits, as the ctr
register is used as 64bits on powerpc64, Andraw Pinski had a patch but
caused some issue and reverted by Joseph S. Myers(PR37451, PR37782).

Andraw:
http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01070.html
http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01321.html
Joseph:
https://gcc.gnu.org/legacy-ml/gcc-patches/2011-11/msg02405.html

However, the doloop code improved a lot since so many years passed,
gcc.c-torture/execute/doloop-1.c is no longer a simple loop with constant
desc->niter_expr since r125:SI#0 is not SImode, so it is not a valid doloop
and no transform done in doloop again.  Thus we can do the simplification
from "subtract/extend/add" to only extend when loop upper_bound is known
to be LE than SINT_MAX-1(not do simplify when r120:DI#0-0x1 overflow).

UINT_MAX-1



Bootstrap and regression tested pass on Power8-LE.

gcc/ChangeLog

2020-04-20  Xiong Hu Luo  

PR rtl-optimization/37451, PR target/61837
* loop-doloop.c (doloop_modify): Simplify (add -1; zero_ext; add +1)
to zero_ext.
---
  gcc/loop-doloop.c | 41 -
  1 file changed, 40 insertions(+), 1 deletion(-)

diff --git a/gcc/loop-doloop.c b/gcc/loop-doloop.c
index db6a014e43d..da537aff60f 100644
--- a/gcc/loop-doloop.c
+++ b/gcc/loop-doloop.c
@@ -477,7 +477,46 @@ doloop_modify (class loop *loop, class niter_desc *desc,
  }

if (increment_count)
-count = simplify_gen_binary (PLUS, mode, count, const1_rtx);
+{
+  /* Fold (add -1; zero_ext; add +1) operations to zero_ext. i.e:
+
+73: r145:SI=r123:DI#0-0x1
+74: r144:DI=zero_extend(r145:SI)
+75: r143:DI=r144:DI+0x1
+...
+31: r135:CC=cmp(r123:DI,0)
+72: {pc={(r143:DI!=0x1)?L70:pc};r143:DI=r143:DI-0x1;clobber
+scratch;clobber scratch;}
+
+r123:DI#0-0x1 is the loop iterations be GE than 0, r143 is the loop
+count be saved to ctr, if this loop's upper bound is known, r123:DI#0
+won't be zero, then the expressions could be simplified to zero_extend
+only.  */
+  bool simplify_zext = false;
+  rtx extop0 = XEXP (count, 0);
+  if 

RE: [PATCH 0/19][GCC-8] aarch64: Backport outline atomics

[Kyrylo Tkachov]

Hi Andre,

> -Original Message-
> From: Andre Vieira (lists) 
> Sent: 16 April 2020 13:24
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Richard Sandiford
> ; s...@amazon.com
> Subject: [PATCH 0/19][GCC-8] aarch64: Backport outline atomics
> 
> Hi,
> 
> This series backports all the patches and fixes regarding outline
> atomics to the gcc-8 branch.
> 
> Bootstrapped the series for aarch64-linux-gnu and regression tested.
> Is this OK for gcc-8?
> 
> Andre Vieira (19):
> aarch64: Add early clobber for aarch64_store_exclusive
> aarch64: Simplify LSE cas generation
> aarch64: Improve cas generation
> aarch64: Improve swp generation
> aarch64: Improve atomic-op lse generation
> aarch64: Remove early clobber from ATOMIC_LDOP scratch
> aarch64: Extend %R for integer registers
> aarch64: Implement TImode compare-and-swap
> aarch64: Tidy aarch64_split_compare_and_swap
> aarch64: Add out-of-line functions for LSE atomics
> Add visibility to libfunc constructors
> aarch64: Implement -moutline-atomics
> Aarch64: Fix shrinkwrapping interactions with atomics (PR92692)
> aarch64: Fix store-exclusive in load-operate LSE helpers
> aarch64: Configure for sys/auxv.h in libgcc for lse-init.c
> aarch64: Fix up aarch64_compare_and_swaphi pattern [PR94368]
> aarch64: Fix bootstrap with old binutils [PR93053]

Thanks for putting these together.
Before they can go in we need to get this fix for PR93053 into GCC 9.
Can you please test it on that branch to help Jakub out?
Thanks,
Kyrill

> aarch64: Fix ICE due to aarch64_gen_compare_reg_maybe_ze [PR94435]
> re PR target/90724 (ICE with __sync_bool_compare_and_swap with
> -march=armv8.2-a+sve)

Re: [PATCH] Fold (add -1; zero_ext; add +1) operations to zero_ext when not zero (PR37451, PR61837)

[luoxhu via Gcc-patches]

Hi,

On 2020/4/18 00:32, Segher Boessenkool wrote:
> On Thu, Apr 16, 2020 at 08:21:40PM -0500, Segher Boessenkool wrote:
>> On Wed, Apr 15, 2020 at 10:18:16AM +0100, Richard Sandiford wrote:
>>> luoxhu--- via Gcc-patches  writes:
 -count = simplify_gen_binary (PLUS, mode, count, const1_rtx);
 +{
 +  /* Fold (add -1; zero_ext; add +1) operations to zero_ext based on 
 addop0
 +   is never zero, as gimple pass loop ch will do optimization to simplify
 +   the loop to NO loop for loop condition is false.  */
>>>
>>> IMO the code needs to prove this, rather than just assume that previous
>>> passes have made it so.
>>
>> Well, it should gcc_assert it, probably.
>>
>> It is the left-hand side of a+b...  it cannot be 0, because niter always
>> is simplified!
> 
> Scratch that...  it cannot be *constant* 0, but that isn't the issue here.

Sorry that my comments in the code is a bit misleading, it is actually not
related to loop-ch at all.  The instruction sequence at 255r.loop2_invariant:

   25: NOTE_INSN_BASIC_BLOCK 5
   26: r133:SI=r123:DI#0-0x1
  REG_DEAD r123:DI
   27: r123:DI=zero_extend(r133:SI)
  REG_DEAD r133:SI
   28: r124:DI=r124:DI+0x4
   30: r134:CC=cmp(r123:DI,0)
   31: pc={(r134:CC!=0)?L69:pc}

And 257r.loop2_doloop (inserted #72,#73,#74, and #31 is replaced by #71):   

;; Determined upper bound -1.
Loop 2 is simple:
  simple exit 6 -> 7
  number of iterations: (plus:SI (subreg:SI (reg:DI 123 [ doloop.6 ]) 0)
(const_int -1 [0x]))
  upper bound: 2147483646
  likely upper bound: 2147483646
  realistic bound: -1
...
   72: r144:SI=r123:DI#0-0x1
   73: r143:DI=zero_extend(r144:SI)
   74: r142:DI=r143:DI+0x1
...
   25: NOTE_INSN_BASIC_BLOCK 5
   26: r133:SI=r123:DI#0-0x1
  REG_DEAD r123:DI
   27: r123:DI=zero_extend(r133:SI)
  REG_DEAD r133:SI
   28: r124:DI=r124:DI+0x4
   30: r134:CC=cmp(r123:DI,0)
   71: {pc={(r142:DI!=0x1)?L69:pc};r142:DI=r142:DI-0x1;clobber scratch;clobber 
scratch;}

increment_count is true ensures the (condition NE const1_rtx), r123:DI#0-0x1 is 
the loop number
of iterations in doloop, it is definitely >= 0, and r123:DI#0 also shouldn't be 
zero as the
loop upper bound is 2147483646(0x7fffe)???

Since this simplification is in doloop-modify,  there is already some doloop 
form check like
!desc->simple_p || desc->assumptions|| desc->infinite in doloop_valid_p, so it 
seems
not necessary to repeat check it here again? 
Maybe we just need check the loop upper bound is LEU than 0x7fffe to avoid 
if
instruction #26 overflow?


Updated patch, thanks:


This "subtract/extend/add" existed for a long time and still annoying us
(PR37451, PR61837) when converting from 32bits to 64bits, as the ctr
register is used as 64bits on powerpc64, Andraw Pinski had a patch but
caused some issue and reverted by Joseph S. Myers(PR37451, PR37782).

Andraw:
http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01070.html
http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01321.html
Joseph:
https://gcc.gnu.org/legacy-ml/gcc-patches/2011-11/msg02405.html

However, the doloop code improved a lot since so many years passed,
gcc.c-torture/execute/doloop-1.c is no longer a simple loop with constant
desc->niter_expr since r125:SI#0 is not SImode, so it is not a valid doloop
and no transform done in doloop again.  Thus we can do the simplification
from "subtract/extend/add" to only extend when loop upper_bound is known
to be LE than SINT_MAX-1(not do simplify when r120:DI#0-0x1 overflow).

Bootstrap and regression tested pass on Power8-LE.

gcc/ChangeLog

2020-04-20  Xiong Hu Luo  

PR rtl-optimization/37451, PR target/61837
* loop-doloop.c (doloop_modify): Simplify (add -1; zero_ext; add +1)
to zero_ext.
---
 gcc/loop-doloop.c | 41 -
 1 file changed, 40 insertions(+), 1 deletion(-)

diff --git a/gcc/loop-doloop.c b/gcc/loop-doloop.c
index db6a014e43d..da537aff60f 100644
--- a/gcc/loop-doloop.c
+++ b/gcc/loop-doloop.c
@@ -477,7 +477,46 @@ doloop_modify (class loop *loop, class niter_desc *desc,
 }
 
   if (increment_count)
-count = simplify_gen_binary (PLUS, mode, count, const1_rtx);
+{
+  /* Fold (add -1; zero_ext; add +1) operations to zero_ext. i.e:
+
+73: r145:SI=r123:DI#0-0x1
+74: r144:DI=zero_extend(r145:SI)
+75: r143:DI=r144:DI+0x1
+...
+31: r135:CC=cmp(r123:DI,0)
+72: {pc={(r143:DI!=0x1)?L70:pc};r143:DI=r143:DI-0x1;clobber
+scratch;clobber scratch;}
+
+r123:DI#0-0x1 is the loop iterations be GE than 0, r143 is the loop
+count be saved to ctr, if this loop's upper bound is known, r123:DI#0
+won't be zero, then the expressions could be simplified to zero_extend
+only.  */
+  bool simplify_zext = false;
+  rtx extop0 = XEXP (count, 0);
+  if (loop->any_upper_bound
+ && wi::leu_p (loop->nb_iterations_upper_bound, 0x7ffe)
+ && GET_CODE 

RE: [PATCH V2]aarch64: falkor-tag-collision-avoidance.c fix valid_src_p for use of uninitialized value

[Kyrylo Tkachov]

> -Original Message-
> From: Andrea Corallo 
> Sent: 16 April 2020 09:01
> To: Kyrylo Tkachov 
> Cc: nd ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH V2]aarch64: falkor-tag-collision-avoidance.c fix
> valid_src_p for use of uninitialized value
> 
> Hi all,
> 
> I'd like to back-port this to the gcc-9 branch.
> This patch is directly based on:
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543627.html
> https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543901.html
> 
> Bootstrapped and reg tested.  Ok for release/gcc-9?

Ok.
Thanks,
Kyrill

> 
> Bests
>   Andrea
> 
> gcc/ChangeLog
> 
> 2020-??-??  Andrea Corallo  
> 
>   * config/aarch64/falkor-tag-collision-avoidance.c
>   (valid_src_p): Check for aarch64_address_info type before
>   accessing base field.
> 
> gcc/testsuite/ChangeLog
> 
> 2020-??-??  Andrea Corallo  
> 
>   * gcc.target/aarch64/pr94530.c: New test.

Re: [PATCH] vect: Tweak vect_better_loop_vinfo_p handling of variable VFs

[Richard Biener via Gcc-patches]

On Fri, Apr 17, 2020 at 5:21 PM Richard Sandiford
 wrote:
>
> This patch fixes a large lmbench performance regression with
> 128-bit SVE, compiled in length-agnostic mode.
>
> vect_better_loop_vinfo_p (new in GCC 10) tries to estimate whether
> a new loop_vinfo is cheaper than a previous one, with an in-built
> preference for the old one.  For variable VF it prefers the old
> loop_vinfo if it is cheaper for at least one VF.  However, we have
> no idea how likely that VF is in practice.
>
> Another extreme would be to do what most of the rest of the
> vectoriser does, and rely solely on the constant estimated VF.
> But as noted in the comment, this means that a one-unit cost
> difference would be enough to pick the new loop_vinfo,
> despite the target generally preferring the old loop_vinfo
> where possible.  The cost model just isn't accurate enough
> for that to produce good results as things stand: there might
> not be any practical benefit to the new loop_vinfo at the
> estimated VF, and it would be significantly worse for higher VFs.
>
> The patch instead goes for a hacky compromise: make sure that the new
> loop_vinfo is also no worse than the old loop_vinfo at double the
> estimated VF.  For all but trivial loops, this ensures that the
> new loop_vinfo is only chosen if it is better than the old one
> by a non-trivial amount at the estimated VF.  It also avoids
> putting too much faith in the VF estimate.
>
> I realise this isn't great, but it's supposed to be a conservative fix
> suitable for stage 4.  The only affected testcases are the ones for
> pr89007-*.c, where Advanced SIMD is indeed preferred for 128-bit SVE
> and is no worse for 256-bit SVE.
>
> Part of the problem here is that if the new loop_vinfo is better,
> we discard the old one and never consider using it even as an
> epilogue loop.  This means that if we choose Advanced SIMD over SVE,
> we're much more likely to have left-over scalar elements.
>
> Another is that the estimate provided by estimated_poly_value might have
> different probabilities attached.  E.g. when tuning for a particular core,
> the estimate is probably accurate, but when tuning for generic code,
> the estimate is more of a guess.  Relying solely on the estimate is
> probably correct for the former but not for the latter.
>
> Hopefully those are things that we could tackle in GCC 11.
>
> Tested on aarch64-linux-gnu, aarch64_be-elf and x86_64-linux-gnu.
> OK to install?

OK.

Richard.

> Richard
>
>
> 2020-04-17  Richard Sandiford  
>
> gcc/
> * tree-vect-loop.c (vect_better_loop_vinfo_p): If old_loop_vinfo
> has a variable VF, prefer new_loop_vinfo if it is cheaper for the
> estimated VF and is no worse at double the estimated VF.
>
> gcc/testsuite/
> * gcc.target/aarch64/sve/cost_model_8.c: New test.
> * gcc.target/aarch64/sve/cost_model_9.c: Likewise.
> * gcc.target/aarch64/sve/pr89007-1.c: Add -msve-vector-bits=512.
> * gcc.target/aarch64/sve/pr89007-2.c: Likewise.
> ---
>  .../gcc.target/aarch64/sve/cost_model_8.c | 12 +++
>  .../gcc.target/aarch64/sve/cost_model_9.c | 13 
>  .../gcc.target/aarch64/sve/pr89007-1.c|  2 +-
>  .../gcc.target/aarch64/sve/pr89007-2.c|  2 +-
>  gcc/tree-vect-loop.c  | 31 ++-
>  5 files changed, 57 insertions(+), 3 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/aarch64/sve/cost_model_8.c
>  create mode 100644 gcc/testsuite/gcc.target/aarch64/sve/cost_model_9.c
>
> diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
> index 265bcfdc5af..b6c3faeae51 100644
> --- a/gcc/tree-vect-loop.c
> +++ b/gcc/tree-vect-loop.c
> @@ -2414,7 +2414,36 @@ vect_better_loop_vinfo_p (loop_vec_info new_loop_vinfo,
>poly_widest_int rel_old = (old_loop_vinfo->vec_inside_cost
>  * poly_widest_int (new_vf));
>if (maybe_lt (rel_old, rel_new))
> -return false;
> +{
> +  /* When old_loop_vinfo uses a variable vectorization factor,
> +we know that it has a lower cost for at least one runtime VF.
> +However, we don't know how likely that VF is.
> +
> +One option would be to compare the costs for the estimated VFs.
> +The problem is that that can put too much pressure on the cost
> +model.  E.g. if the estimated VF is also the lowest possible VF,
> +and if old_loop_vinfo is 1 unit worse than new_loop_vinfo
> +for the estimated VF, we'd then choose new_loop_vinfo even
> +though (a) new_loop_vinfo might not actually be better than
> +old_loop_vinfo for that VF and (b) it would be significantly
> +worse at larger VFs.
> +
> +Here we go for a hacky compromise: pick new_loop_vinfo if it is
> +no more expensive than old_loop_vinfo even after doubling the
> +estimated old_loop_vinfo VF.  For all but trivial loops, this
> +ensures that we only pick new_loop_vinfo if it 

Re: [RFC] split pseudos during loop unrolling in RTL unroller

[Richard Biener via Gcc-patches]

On Fri, Apr 17, 2020 at 10:51 PM Segher Boessenkool
 wrote:
>
> On Fri, Apr 17, 2020 at 08:53:08AM +0200, Richard Biener wrote:
> > On Thu, Apr 16, 2020 at 7:46 PM Segher Boessenkool
> >  wrote:
> > >
> > > On Thu, Apr 16, 2020 at 10:33:45AM +0200, Richard Biener wrote:
> > > > On Wed, Apr 15, 2020 at 11:23 PM Segher Boessenkool
> > > > > On a general note, we shouldn't depend on some pass that may or may 
> > > > > not
> > > > > clean up the mess we make, when we could just avoid making a mess in 
> > > > > the
> > > > > first place.
> > > >
> > > > True - but the issue at hand is not trivial given you have to care for
> > > > partial defs, uses outside of the loop (or across the backedge), etc.
> > > > So there's plenty of things to go "wrong" here.
> > >
> > > Certainly.  But *all* RTL passes before RA should leave things in "web
> > > form" (compare to SSA form).  The code in web.c is probably just fine;
> > > but we shouldn't have one web pass, *all* passes should leave things in
> > > a useful form!
> >
> > Yeah well, but RTL is not in SSA form
>
> "Webs" are not the *same* as SSA, in a few crucial ways; but they serve
> similar purposes: they both make code transformations easier to do.
> Both do this by having more different (independent) names.
>
> > and there's no RTL IL verification
> > in place to track degradation.
>
> Adding this isn't hard in principle.  But currently it is violated all
> over the place, including in backend code.

It's a cheap excuse and clearly a lot of work.  But we've done it for GIMPLE
and it was clearly worth it.  If only for documentation purposes.

> > And we even work in the opposite way
> > when expanding to RTL from SSA, coalescing as much as we can ...
>
> Which often is bad.  A lot of what expand does is premature optimisation
> that a) is much too complicated, and b) results in worse code in the end.
> Expand should not try to do *anything* "interesting", it should "merely"
> translate to RTL.
>
> (And in a way that can be debugged sanely at all, if possible ;-) )

Sure.  I've tried to turn off TER with only moderate success.  Another approach
would be to not do any coalescing but for PHIs (and maybe there only for edges
where we cannot insert copies on w/o splitting it).

But clearly all the magic expand does now should materialize itself on
GIMPLE (see the patch series Martin posted for vcond* / vec_cmp*
"expansion" on GIMPLE).  It's the magic that requires TER and TER clearly
introduces the most noise in the GIMPLE -> RTL translation step (as to
code motion and initial instruction selection if it "fails").

Richard.

Re: [RFC] split pseudos during loop unrolling in RTL unroller

[Richard Biener via Gcc-patches]

On Fri, Apr 17, 2020 at 10:51 PM Segher Boessenkool
 wrote:
>
> On Fri, Apr 17, 2020 at 08:53:08AM +0200, Richard Biener wrote:
> > On Thu, Apr 16, 2020 at 7:46 PM Segher Boessenkool
> >  wrote:
> > >
> > > On Thu, Apr 16, 2020 at 10:33:45AM +0200, Richard Biener wrote:
> > > > On Wed, Apr 15, 2020 at 11:23 PM Segher Boessenkool
> > > > > On a general note, we shouldn't depend on some pass that may or may 
> > > > > not
> > > > > clean up the mess we make, when we could just avoid making a mess in 
> > > > > the
> > > > > first place.
> > > >
> > > > True - but the issue at hand is not trivial given you have to care for
> > > > partial defs, uses outside of the loop (or across the backedge), etc.
> > > > So there's plenty of things to go "wrong" here.
> > >
> > > Certainly.  But *all* RTL passes before RA should leave things in "web
> > > form" (compare to SSA form).  The code in web.c is probably just fine;
> > > but we shouldn't have one web pass, *all* passes should leave things in
> > > a useful form!
> >
> > Yeah well, but RTL is not in SSA form
>
> "Webs" are not the *same* as SSA, in a few crucial ways; but they serve
> similar purposes: they both make code transformations easier to do.
> Both do this by having more different (independent) names.
>
> > and there's no RTL IL verification
> > in place to track degradation.
>
> Adding this isn't hard in principle.  But currently it is violated all
> over the place, including in backend code.
>
> > And we even work in the opposite way
> > when expanding to RTL from SSA, coalescing as much as we can ...
>
> Which often is bad.  A lot of what expand does is premature optimisation
> that a) is much too complicated, and b) results in worse code in the end.
> Expand should not try to do *anything* "interesting", it should "merely"
> translate to RTL.
>
> (And in a way that can be debugged sanely at all, if possible ;-) )
>
> > > > > The web pass belongs immediately after expand; but ideally, even 
> > > > > expand
> > > > > would not reuse pseudos anyway.
> > > >
> > > > But for example when lower-subreg decomposes things in a way turning
> > > > partial defs into full defs new opportunities to split the web arise.
> > >
> > > But that is only for the new registers it creates, or what am I missing?
> >
> > No idea, just made up the example that maintaing "SSA" RTL is
> > not automagic.
>
> Oh sure, but in most cases, it is.
>
> My point is that making web form only once (and messing it up after that)
> isn't great.
>
> > > > > Maybe it would be better as some utility routines, not a pass?
> > > >
> > > > Sure, but then when do we apply it?
> > >
> > > All of the time!  Ideally every pass would leave things in a good shape.
> > > Usually it is cheapest as well as easiest to do things manually, but for
> > > some harder cases, such helper routines can be used.
> > >
> > > > Ideally scheduling would to
> > > > register renaming itself and thus not rely on the used pseudos
> > > > (I'm not sure if it tracks false dependences - I guess it must if it
> > > > isn't able to rename regs).  That would be a much better place
> > > > for improvements?
> > >
> > > sched2 runs after RA, so it has nothing to do with webs?  And sched1
> > > doesn't do much relevant here (it doesn't move insns much).
> > >
> > > I don't see how this is directly related to register renaming either?
> >
> > If scheduling ignores "false" dependences (anti dependence with
> > full defs) then when it schedules across such defs needs to perform
> > renaming.  Maybe I'm using bogus terms here.
>
> Your terminology is fine afaic, but I don't see what you mean, sorry.
> Maybe I don't know sched well enough...  I thought it would just refuse
> to move something if that would result in broken code?

Yes, I think that's what it does.  And I was suggesting it should learn to
schedule the use after the def in

(use (reg:SI 101))
(set (reg:SI 101) (...))

by renaming the pseudo, removing the false/anti dependence.  After RA
this means the ability to do simple local register allocation of course.
Before RA the trivial way to implement this is to not have those false
dependences, aka have webs / SSA ... ;)

Richard.

>
> Segher

Re: arm: Fix regression in contant handling for -mpure-code for v8m

[Christophe Lyon via Gcc-patches]

Hi,

You can disregard this patch, Wilco found problems with it, and I
think he is working on a more complete fix.

Thanks,

Christophe


On Thu, 16 Apr 2020 at 17:39, Christophe Lyon
 wrote:
>
> Hi,
>
> In PR94538, Wilco mentioned that my patch to enable -mpure-code for
> v6m caused regressions in the code generated for cortex-m23.
>
> Specifically, for
> int f3 (void) { return 0x1100; }
> int f3_bis (void) { return 0x12345678; }
>
> we currently generate (-O2 -mcpu=cortex-m23 -mpure-code)
> movsr0, #17
> lslsr0, r0, #8
> lslsr0, r0, #8
> lslsr0, r0, #8
> bx  lr
> and
> movsr0, #86
> lslsr0, r0, #8
> addsr0, r0, #120
> movtr0, 4660
> bx  lr
>
> The attached patch brings back the original code generation:
> movsr0, #136@ 12[c=4 l=2]  *thumb1_movsi_insn/1
> lslsr0, r0, #21 @ 9 [c=4 l=2]  *thumb1_ashlsi3/0
> bx  lr
> and
> movwr0, #22136  @ 12[c=4 l=4]  *thumb1_movsi_insn/2
> movtr0, 4660@ 13[c=4 l=4]  *arm_movtas_ze/1
> bx  lr
>
> This does not address the other problems discussed in the PR, so I'm
> not mentioning it in the ChangeLog.
>
> OK?
>
> Thanks,
>
> Christophe

[PATCH 1/2] testsuite: [arm/cde] Include arm_cde.h and arm_mve.h in arm_v8*m_main_cde*

[Christophe Lyon via Gcc-patches]

Since arm_cde.h includes stdint.h, its use requires the presence of
the right gnu/stub-*.h, so make sure to include it when checking the
arm_v8*m_main_cde* effective targets, otherwise we can decide CDE is
supported while it's not really (all tests that use arm_v8m_main_cde*
also include arm_cde.h aynway).

Similarly for the effective targets that also require MVE.

This makes several tests unsupported rather than fail.
---
 gcc/testsuite/lib/target-supports.exp | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index d16498d..23a5abf 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -5140,21 +5140,25 @@ proc add_options_for_arm_v8_2a_bf16_neon { flags } {
 #   /* { dg-add-options arm_v8m_main_cde } */
 # The tests are valid for Arm.
 
-foreach { armfunc armflag armdef } {
+foreach { armfunc armflag armdef arminc } {
arm_v8m_main_cde
"-march=armv8-m.main+cdecp0+cdecp6 -mthumb"
"defined (__ARM_FEATURE_CDE)"
+   ""
arm_v8m_main_cde_fp
"-march=armv8-m.main+fp+cdecp0+cdecp6 -mthumb -mfpu=auto"
"defined (__ARM_FEATURE_CDE) && defined (__ARM_FP)"
+   ""
arm_v8_1m_main_cde_mve
"-march=armv8.1-m.main+mve+cdecp0+cdecp6 -mthumb -mfpu=auto"
"defined (__ARM_FEATURE_CDE) && defined (__ARM_FEATURE_MVE)"
+   "#include "
arm_v8_1m_main_cde_mve_fp
"-march=armv8.1-m.main+mve.fp+cdecp0+cdecp6 -mthumb -mfpu=auto"
"defined (__ARM_FEATURE_CDE) || __ARM_FEATURE_MVE == 3"
+   "#include "
} {
-eval [string map [list FUNC $armfunc FLAG $armflag DEF $armdef ] {
+eval [string map [list FUNC $armfunc FLAG $armflag DEF $armdef INC $arminc 
] {
proc check_effective_target_FUNC_ok_nocache { } {
global et_FUNC_flags
set et_FUNC_flags ""
@@ -5167,6 +5171,8 @@ foreach { armfunc armflag armdef } {
#if !(DEF)
#error "DEF failed"
#endif
+   #include 
+   INC
} "FLAG"] } {
set et_FUNC_flags "FLAG"
return 1
-- 
2.7.4

[PATCH 2/2] testsuite: [arm] Include arm_acle.h in related effective targets

[Christophe Lyon via Gcc-patches]

Since arm_acle.h includes stdint.h, its use requires the presence of
the right gnu/stub-*.h, so make sure to include arm_acle.h when
checking the effective targets that generally imply that the testcase
will include it: arm_dsp, arm_crc, arm_coproc[1-4]

This makes several tests unsupported rather than fail.
---
 gcc/testsuite/lib/target-supports.exp | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 23a5abf..f3d3ae4 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -3731,6 +3731,7 @@ proc check_effective_target_arm_dsp { } {
#ifndef __ARM_FEATURE_DSP
#error not DSP
#endif
+   #include 
int i;
 }]
 }
@@ -4032,6 +4033,7 @@ proc check_effective_target_arm_crc_ok_nocache { } {
#if !defined (__ARM_FEATURE_CRC32)
#error FOO
#endif
+   #include 
 } "$et_arm_crc_flags"]
 }
 
@@ -9855,6 +9857,7 @@ proc check_effective_target_arm_coproc1_ok_nocache { } {
#if (__thumb__ && !__thumb2__) || __ARM_ARCH < 4
#error FOO
#endif
+   #include 
 }]
 }
 
@@ -9874,6 +9877,7 @@ proc check_effective_target_arm_coproc2_ok_nocache { } {
#if (__thumb__ && !__thumb2__) || __ARM_ARCH < 5
#error FOO
#endif
+   #include 
 }]
 }
 
@@ -9894,6 +9898,7 @@ proc check_effective_target_arm_coproc3_ok_nocache { } {
|| (__ARM_ARCH < 6 && !defined (__ARM_ARCH_5TE__))
#error FOO
#endif
+   #include 
 }]
 }
 
@@ -9913,6 +9918,7 @@ proc check_effective_target_arm_coproc4_ok_nocache { } {
#if (__thumb__ && !__thumb2__) || __ARM_ARCH < 6
#error FOO
#endif
+   #include 
 }]
 }
 
-- 
2.7.4

[PATCH] aarch64：Add an error message in large code model for ilp32 [PR94577]

[duanbo (C)]

Hi

> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Friday, April 17, 2020 9:38 PM
> To: duanbo (C) 
> Cc: Wilco Dijkstra ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH PR94577] [AArch64] ：Add an error message in large
> code model for ilp32
> 
> "duanbo (C)"  writes:
> > Thank you for your suggestions.
> > I have modified accordingly and a full test has been carried, no new failure
> witnessed.
> > Attached please find the new patch which has been adjusted to be suitable
> for git am.
> > Does the v2 patch look better ?
> >
> > Thanks,
> > Duan bo
> >
> > -Original Message-
> > From: Wilco Dijkstra [mailto:wilco.dijks...@arm.com]
> > Sent: Tuesday, April 14, 2020 4:40 AM
> > To: GCC Patches ; duanbo (C)
> > 
> > Subject: Re: [PATCH PR2] aarch64：Add an error message in large
> > code model for ilp32
> >
> > Hi Duanbo,
> >
> >> This is a simple fix for pr94577.
> >> The option -mabi=ilp32 should not be used in large code model. Like x86,
> using -mx32 and -mcmodel=large together will result in an error message.
> >> On aarch64, there is no error message for this option conflict.
> >> A solution to this problem can be found in the attached patch.
> >> Bootstrap and tested on aarch64 Linux platform. No new regression
> witnessed.
> >> Any suggestion?
> >
> > Thanks for your patch, more than 4GB doesn't make any sense with ILP32
> indeed.
> > A few suggestions:
> >
> > It would be good to also update the documentation for -mcmodel=large to
> state it is incompatible with -fpic, -fPIC and -mabi=ilp32.
> >
> > The patch adds a another switch statement on mcmodel that ignores the
> previous processing done (which may changes the selected mcmodel). It
> would be safer and more concise to use one switch at the top level and in
> each case use an if statement to handle the special cases.
> >
> > A few minor nitpics:
> >
> > +   PR  target/94577
> > +   * gcc.target/aarch64/pr94577.c : New test
> >
> > Just like comments, there should be a '.' at the end of changelog entries.
> >
> > AFAICT the format isn't exactly specified, but the email header should be
> like:
> >
> > [PATCH][AArch64] PR94577: Add an error message in large code model for
> > ilp32
> >
> > Sometimes the PR number is also placed in brackets.
> >
> > Cheers,
> > Wilco
> >
> >
> > From feb16a5e5d35d4f632e1be10ce0ac4f4c3505d22 Mon Sep 17 00:00:00
> 2001
> > From: Duan bo 
> > Date: Wed, 15 Apr 2020 05:19:31 -0400
> > Subject: [PATCH] aarch64: Add an error message in large code model for
> > ilp32  [PR94577]
> >
> > The option -mabi=ilp32 should not be used in large code model. An
> > error message is added for the option conflict.
> >
> > 2020-04-15  Duan bo  
> >
> > PR target/94577
> > * config/aarch64/aarch64.c: Add an error message for option conflict.
> > * doc/invoke.texi (-mcmodel=large): Mention that -mcmodel=large
> is
> > incompatible with -fpic, -fPIC and -mabi=ilp32.
> >
> > 2020-04-15  Duan bo  
> >
> > PR target/94577
> > * gcc.target/aarch64/pr94577.c: New test.
> > ---
> >  gcc/ChangeLog  |  7 
> >  gcc/config/aarch64/aarch64.c   | 41 --
> >  gcc/doc/invoke.texi|  4 ++-
> >  gcc/testsuite/ChangeLog|  5 +++
> >  gcc/testsuite/gcc.target/aarch64/pr94577.c | 10 ++
> >  5 files changed, 47 insertions(+), 20 deletions(-)  create mode
> > 100644 gcc/testsuite/gcc.target/aarch64/pr94577.c
> >
> > diff --git a/gcc/ChangeLog b/gcc/ChangeLog index
> > 3c6a45e8fe7..c2f1fcb7bff 100644
> > --- a/gcc/ChangeLog
> > +++ b/gcc/ChangeLog
> > @@ -1,3 +1,10 @@
> > +2020-04-15  Duan bo  
> > +
> > +   PR target/94577
> > +   * config/aarch64/aarch64.c: Add an error message for option conflict.
> > +   * doc/invoke.texi (-mcmodel=large): Mention that -mcmodel=large
> is
> > +   incompatible with -fpic, -fPIC and -mabi=ilp32.
> > +
> >  2020-04-14  Max Filippov  
> >
> > PR target/94584
> > diff --git a/gcc/config/aarch64/aarch64.c
> > b/gcc/config/aarch64/aarch64.c index 4af562a81ea..f8a38bd899a 100644
> > --- a/gcc/config/aarch64/aarch64.c
> > +++ b/gcc/config/aarch64/aarch64.c
> > @@ -14707,32 +14707,35 @@ aarch64_init_expanders (void)  static void
> > initialize_aarch64_code_model (struct gcc_options *opts)  {
> > -   if (opts->x_flag_pic)
> > +   aarch64_cmodel = opts->x_aarch64_cmodel_var;
> > +   switch (opts->x_aarch64_cmodel_var)
> >   {
> > -   switch (opts->x_aarch64_cmodel_var)
> > -{
> > -case AARCH64_CMODEL_TINY:
> > +   case AARCH64_CMODEL_TINY:
> > +if (opts->x_flag_pic)
> 
> Minor formatting nit, but: the case statement should be indented by the
> same amount as the "{" for the switch statement.  The code after the case
> statement should be indented by two further columns.
> (The formatting is wrong in the existing code too, which is probably what
> confused things.)
> 
> >aarch64_cmodel = 

Re: [RFA PATCH]: i386: Use generic division to generate INVALID and DIVZERO exceptions

[Richard Biener]

On Sun, 19 Apr 2020, Uros Bizjak wrote:

> This patch implements the idea from glibc, where generic division
> operations instead of assembly are used where appropriate.
> 
> --commit--
> i386: Use generic division to generate INVALID and DIVZERO exceptions
> 
> Introduce math_force_eval to evaluate generic division to generate
> INVALID and DIVZERO exceptions.
> 
> libgcc/ChangeLog:
> 
> 2020-04-19  Uroš Bizjak  
> 
> * config/i386/sfp-exceptions.c (math_force_eval): New define.
> (__sfp_handle_exceptions): Use math_force_eval to evaluete
> generic division to generate INVALID and DIVZERO exceptions.
> 
> libatomic/ChangeLog:
> 
> 2020-04-19  Uroš Bizjak  
> 
> * config/x86/fenv.c (math_force_eval): New define.
> (__atomic_feraiseexcept): Use math_force_eval to evaluete
> generic division to generate INVALID and DIVZERO exceptions.
> 
> libgfortran/ChangeLog:
> 
> 2020-04-19  Uroš Bizjak  
> 
> * config/fpu-387.h (_math_force_eval): New define.
> (local_feraiseexcept): Use math_force_eval to evaluete
> generic division to generate INVALID and DIVZERO exceptions.
> --/commit--
> 
> The patch was bootstrapped and regression tested on x86_64-linux-gnu
> {,-m32}. Also, as part of glibc's patch evaluation, I have extensively
> tested it to check that it really generates only correct exceptions
> for both, x87 and SSE math.
> 
> Additionally, the patch improves code for DIVZERO exception, as we can
> now use FDIVRP mnemonic. This mnemonic has its own share of confusion
> (see e.g. SYSV386_COMPAT macro definition) and its use in asm should
> be avoided.
> --/commit message--
> 
> The patch looks safe to me, but I'd like to ask RMs for approval.

If it doesn't fix a regression can it wait for stage1 please?

Thanks,
Richard.

Re: [PATCH] libstdc++: don't use #include_next in c_global headers

[Marc Glisse]

On Mon, 20 Apr 2020, Helmut Grohne wrote:


Now you are probably going to say that "-isystem /usr/include" is a bad
idea and that you shouldn't do that. I'm inclined to agree. This isn't a
problem just yet. Debian wants to move /usr/include/stdlib.h to
/usr/include//stdlib.h. After that move, the problematic flag
becomes "-isystem /usr/include/". Unfortunately, around 30
Debian packages[1] do pass exactly that flag. Regardless whether doing
so is a bad idea, I guess we will have to support that.


Urgh, no to "support that". I don't like those #include_next of a header 
with a different name and wouldn't mind seeing them go. But even if your 
patch, or some other patch, happens to make things kind of work, please do 
**not** consider this a supported feature, and keep fixing those broken 
packages (including the big bad cmake which regularly adds such flags to 
innocent packages).


With (or without) your patch, if a user has the bad -isystem and does 
#include , it will never see libstdc++'s version of stdlib.h, 
which contains important extra content, so that's still not working 
properly.


--
Marc Glisse