Re: [PATCH 2/3] PowerPC: require IBM long double for pr70117.

[Michael Meissner via Gcc-patches]

On Sat, Nov 21, 2020 at 10:46:45AM -0500, David Edelsohn wrote:
> On Sat, Nov 21, 2020 at 12:37 AM Michael Meissner
>  wrote:
> >
> > PowerPC: require IBM long double for pr70117.
> >
> > Since the test is explicitly checking for IBM extended double, do not try to
> > run it when long double is IEEE 128-bit.
> >
> > I have tested this patch and the first patch in the series on a little 
> > endian
> > power9 system with 3 compilers that have the 3 different long double types
> > configured.  I verified that this test is listed as unsupported if long 
> > double
> > is not IBM 128-bit, and it passes if long double is IBM 128-bit.
> >
> > Can I check this patch into the master branch?  After an appropriate soak-in
> > time, can I back port this patch to the previous open GCC trees?
> >
> > gcc/testsuite/
> > 2020-11-21  Michael Meissner  
> >
> > PR target/70117
> > * gcc.target/powerpc/pr70117.c: Only run the test if long double
> > uses the IBM extended double format.
> > ---
> >  gcc/testsuite/gcc.target/powerpc/pr70117.c | 22 --
> >  1 file changed, 4 insertions(+), 18 deletions(-)
> >
> > diff --git a/gcc/testsuite/gcc.target/powerpc/pr70117.c 
> > b/gcc/testsuite/gcc.target/powerpc/pr70117.c
> > index 3bbd2c595e0..2077d15afd4 100644
> > --- a/gcc/testsuite/gcc.target/powerpc/pr70117.c
> > +++ b/gcc/testsuite/gcc.target/powerpc/pr70117.c
> > @@ -1,26 +1,12 @@
> > -/* { dg-do run { target { powerpc*-*-linux* powerpc*-*-darwin* 
> > powerpc*-*-aix* rs6000-*-* } } } */
> > -/* { dg-options "-std=c99 -mlong-double-128 -O2" } */
> > +/* { dg-require-effective-target ppc_long_double_ibm } */
> > +/* { dg-options "-std=c99 -O2" } */
> 
> Mike,
> 
> You still need a
> 
> /* { dg-do run } */
> 
> line.  But without any target specified.
> 
> Segher may have other comments.
> 
> Thanks, David

Thanks.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH] unshare expressions in attribute arguments

[Jeff Law via Gcc-patches]

On 11/20/20 12:00 PM, Martin Sebor via Gcc-patches wrote:
> To detect a subset of VLA misuses, the C front associates the bounds
> of VLAs in function argument lists with the corresponding variables
> by implicitly adding an instance of attribute access to each function
> declared to take VLAs with the bound expressions chained on the list
> of attribute arguments.
>
> Some of these expressions end up modified by the middle end, which
> results in references to nonlocal variables (and perhaps other nodes)
> used in these expression getting garbage collected.  A simple example
> of this is described in pr97172.
>
> By unsharing the bound expressions the patch below prevents this from
> happening (it's not a fix for pr97172).
>
> My understanding of the details of node sharing and garbage collection
> in GCC is very limited (I didn't expect a tree to be garbage-collected
> if it's still referenced by something).  Is this the right approach
> to solving this problem?
So if the tree node is reachable from a GC root, then it won't be
removed by the GC system. It's a simple mark/sweep with a set of
registered roots.  The only real complexity is the auto-generated code
to walk the data structures (ie, all the gengtype insanity).

>From the BZ:


 
    arg:0 
    arg:1 
    /build/tmp/z.c:2:48 start: /build/tmp/z.c:2:46 finish:
/build/tmp/z.c:2:50>>>

Then later indicate it looks like this (presumably at LTO stream-out time):


 
  
    arg:0 
    nothrow
    def_stmt
    version:1 in-free-list>
    arg:1 
    /build/tmp/z.c:2:55 start: /build/tmp/z.c:2:45 finish:
/build/tmp/z.c:2:57>>>


Note the structure of the value in the tree list, in particular note the
PLUS_EXPR node.  It's at address 0x7fffea924c80 in both.  But in the
first it's a VAR_DECL.  In the second it's a released SSA_NAME.


That to me doesn't look like a GC issue.  To me it looks like you have
violated the structure sharing assumptions by inadvertently sharing the
PLUS_EXPR node.  Naturally when the gimplifier and SSA renaming does its
thing, the first operand of the PLUS_EXPR gets changed to an SSA_NAME. 
I strongly suspect that SSA_NAME ultimately ends up dead and gets
released back to the SSA_NAME manager for re-use (hence the
error_mark_node for the type and in-free-list tag for arg0 of the
PLUS_EXPR in the second instance).

So the first question is presumably you want the original form with the
_DECL node?   That argues that you need the unshare_expr so that your
copy is independent of the actions of gimplification and SSA renaming. 
However, as Jakub noted, there may be a SAVE_EXPR issue that needs to be
addressed here.



jeff

Re: [PATCH 30/31] PR target/95294: VAX: Convert backend to MODE_CC representation

[Jeff Law via Gcc-patches]

On 11/19/20 8:36 PM, Maciej W. Rozycki wrote:
> In the VAX ISA INSV bitfield insert instruction is the only computational
> operation that keeps the condition codes, held in the PSL or Processor
> Status Longword register, intact.  The instruction is flexible enough it
> could potentially be used for data moves post-reload, but then reportedly
> it is not the best choice performance-wise, and then we have no addition
> operation available that would keep the condition codes unchanged.
>
> Futhermore, as usually with a complex CISC ISA, for many operations we
> have several machine instructions or instruction sequences to choose
> from that set condition codes in a different manner.
>
> Use the approach then where the condition codes only get introduced by
> reload, by definining instruction splitters for RTL insns that change
> condition codes in some way, by default considering them clobbered.
>
> Then to prevent code generated from regressing too much provide insns
> that include a `compare' operation setting the condition codes in
> parallel to the main operation.  The manner condition codes are set by
> each insn is supposed to be provided by the whatever the SELECT_CC_MODE
> macro expands to.
>
> Given that individual patterns provided for the same RTL basic operation
> may set the condion codes differently keeping the information away from
> the insn patterns themselves would cause a maintenance nightmare and
> would be bound to fail in a horrible way sooner or later.  Therefore
> instead let the patterns themselves choose which condition modes they
> support, by having one or more subst iterators applied and then have
> individual comparison operators require the specific condition mode each
> according to the codes used by the operation.
>
> While subst iterators only support one alternative each, there is
> actually no problem with applying multiple ones to a single insn with
> the result as intended, and if the corresponding subst attribute
> supplies an empty NO-SUBST-VALUE, then no mess results even.  Make use
> of this observation.
>
> Add appropriate subst iterators to all the computational patterns then,
> according to the condition codes they usably set, including DImode ones
> and a substitute DImode comparison instruction in the absence of a CMPQ
> machine instruction, however do not provide a `cbranchdi4' named pattern
> as without a further development it regresses code quality by resorting
> to the `__cmpdi2' libcall where a simpler operation would do, e.g. to
> check for negativity the TSTL machine instruction may be executed over
> the upper longword only.  This is good material for further work.
>
> Do not apply subst iterators to the increment- or decrement-and-branch
> patterns at this time; these may yet have to be reviewed, in particular
> whether `*jsobneq_minus_one' is still relevant in the context of the
> recent integer constant cost review.
>
> Also add a couple of peepholes to help eliminating comparisons in some
> problematic cases, such as with the BIT instruction which is bitwise-AND
> for condition codes only that has no direct counterpart for the actual
> calculation, because the BIC instruction which does do bitwise-AND and
> produces a result implements the operation with a bitwise negation of
> its input `mask' operand.  Or the FFS instruction which sets the Z
> condition code according to its `field' input operand rather than the
> result produced.  Or the bitfield comparisons we don't have generic
> middle-end support for.
>
> Code size stats are as follows, obtained from 17640 and 9086 executables
> built in `check-c' and `check-c++' GCC testing respectively:
>
>   check-c check-c++
>   samples average  median  samples average  median
> ---
> regressions  1813  0.578%  0.198%  289  0.349%  0.175%
> unchanged   15160  0.000%  0.000% 8662  0.000%  0.000%
> progressions  667 -0.589% -0.194%  135 -0.944% -0.191%
> 
> total   17640  0.037%  0.000% 9086 -0.003%  0.000%
>
> Outliers:
>
> old new change  %change filename
> 
> 24062950+544+22.610 20111208-1.exe
> 43145329+1015   +23.528 pr39417.exe
> 22353055+820+36.689 990404-1.exe
> 26314213+1582   +60.129 pr57521.exe
> 30635579+2516   +82.142 2422-1.exe
>
> and:
>
> old new change  %change filename
> 
> 63174845-1472   -23.302 vector-compare-1.exe
> 63134845-1468   -23.254 vector-compare-1.exe
> 64745002-1472   -22.737 vector-compare-1.exe
> 64705002-1468   -22.689 vector-compare-1.exe
>
> We have some code quality regressions like:
>
> 10861:9e ef d9 12 movab 11b40 ,r0
> 10865:00 00 50
>   

Re: [PATCH] libstdc++: Add C++2a synchronization support

[Jonathan Wakely via Gcc-patches]

On Sat, 21 Nov 2020 at 23:55, David Edelsohn via Libstdc++
 wrote:
>
> I am seeing 93 new libstdc++ failures on AIX, even after Jonathan's
> fixes.  And a few c++ failures with similar symptoms.  I'm not certain
> that it is due to this patch, but it's the likely suspect.
Yes, it's that patch.

This should fix most of those errors, but I haven't finished testing
it, and can't commit it now anyway.
commit c304e59c2fd8c500232c4c88b632e051e481991f
Author: Jonathan Wakely 
Date:   Sun Nov 22 01:00:46 2020

libstdc++: make atomic waiting depend on gthreads or futexes

libstdc++-v3/ChangeLog:

* include/bits/atomic_wait.h: Do not define anything unless
gthreads or futexes are available.
* include/bits/atomic_timed_wait.h: Likewise.
* include/bits/semaphore_base.h: Likewise.
* include/std/semaphore: Likewise.
* include/bits/atomic_base.h (atomic_flag::wait)
(atomic_flag::notify_one, atomic_flag::notify_all)
(__atomic_base::wait, __atomic_base::notify_one)
(__atomic_base::notify_all, __atomic_base::wait)
(__atomic_base::notify_one, __atomic_base::notify_all)
(__atomic_impl::wait, __atomic_impl::notify_one)
(__atomic_impl::notify_all, __atomic_float::wait)
(__atomic_float::notify_one, __atomic_float::notify_all)
(__atomic_ref::wait, __atomic_ref::notify_one)
(__atomic_ref::notify_all): Only define if gthreads or futexes
are available.
* include/std/atomic (atomic::wait, atomic::notify_one)
(atomic::notify_all): Likewise.

diff --git a/libstdc++-v3/include/bits/atomic_base.h 
b/libstdc++-v3/include/bits/atomic_base.h
index 7de02f169977..d7db8612889e 100644
--- a/libstdc++-v3/include/bits/atomic_base.h
+++ b/libstdc++-v3/include/bits/atomic_base.h
@@ -230,6 +230,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   return __v == __GCC_ATOMIC_TEST_AND_SET_TRUEVAL;
 }
 
+#if defined _GLIBCXX_HAS_GTHREADS || _GLIBCXX_HAVE_LINUX_FUTEX
 _GLIBCXX_ALWAYS_INLINE void
 wait(bool __old,
memory_order __m = memory_order_seq_cst) const noexcept
@@ -252,6 +253,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 { std::__atomic_notify(&_M_i, true); }
 
 // TODO add const volatile overload
+#endif // GTHREADS || LINUX_FUTEX
 #endif // C++20
 
 _GLIBCXX_ALWAYS_INLINE void
@@ -603,6 +605,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   }
 
 #if __cplusplus > 201703L
+#if defined _GLIBCXX_HAS_GTHREADS || _GLIBCXX_HAVE_LINUX_FUTEX
   _GLIBCXX_ALWAYS_INLINE void
   wait(__int_type __old,
  memory_order __m = memory_order_seq_cst) const noexcept
@@ -625,6 +628,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   { std::__atomic_notify(&_M_i, true); }
 
   // TODO add const volatile overload
+#endif // GTHREADS || LINUX_FUTEX
 #endif // C++2a
 
   _GLIBCXX_ALWAYS_INLINE __int_type
@@ -897,6 +901,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   }
 
 #if __cplusplus > 201703L
+#if defined _GLIBCXX_HAS_GTHREADS || _GLIBCXX_HAVE_LINUX_FUTEX
   _GLIBCXX_ALWAYS_INLINE void
   wait(__pointer_type __old,
   memory_order __m = memory_order_seq_cst) noexcept
@@ -919,6 +924,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   { std::__atomic_notify(&_M_p, true); }
 
   // TODO add const volatile overload
+#endif // GTHREADS || LINUX_FUTEX
 #endif // C++2a
 
   _GLIBCXX_ALWAYS_INLINE __pointer_type
@@ -1010,6 +1016,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   }
 
 #if __cplusplus > 201703L
+#if defined _GLIBCXX_HAS_GTHREADS || _GLIBCXX_HAVE_LINUX_FUTEX
 template
   _GLIBCXX_ALWAYS_INLINE void
   wait(const _Tp* __ptr, _Val<_Tp> __old,
@@ -1034,6 +1041,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   { std::__atomic_notify(__ptr, true); }
 
   // TODO add const volatile overload
+#endif // GTHREADS || LINUX_FUTEX
 #endif // C++2a
 
 template
@@ -1289,6 +1297,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   __cmpexch_failure_order(__order));
   }
 
+#if defined _GLIBCXX_HAS_GTHREADS || _GLIBCXX_HAVE_LINUX_FUTEX
   _GLIBCXX_ALWAYS_INLINE void
   wait(_Fp __old, memory_order __m = memory_order_seq_cst) const noexcept
   { __atomic_impl::wait(&_M_fp, __old, __m); }
@@ -1306,6 +1315,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   { __atomic_impl::notify_all(&_M_fp); }
 
   // TODO add const volatile overload
+#endif // GTHREADS || LINUX_FUTEX
 
   value_type
   fetch_add(value_type __i,
@@ -1444,6 +1454,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   __cmpexch_failure_order(__order));
   }
 
+#if defined _GLIBCXX_HAS_GTHREADS || _GLIBCXX_HAVE_LINUX_FUTEX
   _GLIBCXX_ALWAYS_INLINE void
   wait(_Tp __old, memory_order __m = memory_order_seq_cst) const noexcept
   { __atomic_impl::wait(_M_ptr, __old, __m); }
@@ -1461,6 +1472,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   { __atomic_impl::n

Re: [PATCH] libstdc++: Add C++2a synchronization support

[H.J. Lu via Gcc-patches]

On Sat, Nov 21, 2020 at 9:40 AM Jonathan Wakely via Gcc-patches
 wrote:
>
> On 21/11/20 17:04 +, Jonathan Wakely wrote:
> >On 21/11/20 16:16 +0100, Andreas Schwab wrote:
> >>In file included from 
> >>/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/shared_ptr_atomic.h:33,
> >>    from 
> >> /daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/memory:78,
> >>from 
> >> /daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/stdc++.h:82,
> >>from 
> >> /daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/extc++.h:32,
> >>from 
> >> /daten/aranym/gcc/gcc-20201121/libstdc++-v3/testsuite/17_intro/headers/c++2020/all_attributes.cc:37:
> >>/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_base.h:
> >> In member function 'void std::atomic_flag::wait(bool, std::memory_order) 
> >>const':
> >>/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_base.h:239:
> >> error: no matching function for call to '__atomic_wait(const 
> >>__atomic_flag_data_type*, bool&, std::atomic_flag::wait(bool, 
> >>std::memory_order) const::)'
> >>In file included from 
> >>/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_base.h:41,
> >>from 
> >> /daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/shared_ptr_atomic.h:33,
> >>from 
> >> /daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/memory:78,
> >>from 
> >> /daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/stdc++.h:82,
> >>    from 
> >> /daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/extc++.h:32,
> >>from 
> >> /daten/aranym/gcc/gcc-20201121/libstdc++-v3/testsuite/17_intro/headers/c++2020/all_attributes.cc:37:
> >>/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_wait.h:265:
> >> note: candidate: 'template void 
> >>std::__atomic_wait(const _Tp*, _Tp, _Pred)'
> >>/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_wait.h:265:
> >> note:   template argument deduction/substitution failed:
> >>In file included from 
> >>/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/shared_ptr_atomic.h:33,
> >>from 
> >> /daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/memory:78,
> >>    from 
> >> /daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/stdc++.h:82,
> >>from 
> >> /daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/extc++.h:32,
> >>from 
> >> /daten/aranym/gcc/gcc-20201121/libstdc++-v3/testsuite/17_intro/headers/c++2020/all_attributes.cc:37:
> >>/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_base.h:239:
> >> note:   deduced conflicting types for parameter '_Tp' ('unsigned char' and 
> >>'bool')
> >
> >I'm testing this.
>
> I'm committing this instead, it's the same but also disables
> 29_atomics/atomic/wait_notify/generic.cc on non-linux targets.
>
> Tested sparc-solaris2.11 and powerpc64le-linux.
>
> There are still some timeouts on linux:
>
> FAIL: 30_threads/latch/3.cc execution test
> FAIL: 30_threads/semaphore/try_acquire_for.cc execution test
>

I opened:

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

-- 
H.J.

Re: [PATCH] libstdc++: Add C++2a synchronization support

[David Edelsohn via Gcc-patches]

I am seeing 93 new libstdc++ failures on AIX, even after Jonathan's
fixes.  And a few c++ failures with similar symptoms.  I'm not certain
that it is due to this patch, but it's the likely suspect.

FAIL: 17_intro/headers/c++2020/all_attributes.cc (test for excess errors)
FAIL: 17_intro/headers/c++2020/all_no_exceptions.cc (test for excess errors)
FAIL: 17_intro/headers/c++2020/all_no_rtti.cc (test for excess errors)
FAIL: 17_intro/headers/c++2020/all_pedantic_errors.cc (test for excess errors)
FAIL: 17_intro/headers/c++2020/operator_names.cc (test for excess errors)
FAIL: 17_intro/headers/c++2020/stdc++.cc (test for excess errors)
FAIL: 17_intro/headers/c++2020/stdc++_multiple_inclusion.cc (test for
excess errors)
FAIL: 20_util/allocator/rebind_c++20.cc (test for excess errors)
FAIL: 20_util/allocator/requirements/constexpr.cc (test for excess errors)
FAIL: 20_util/allocator/requirements/typedefs_c++20.cc (test for excess errors)
FAIL: 20_util/allocator_traits/header.cc (test for excess errors)
FAIL: 20_util/allocator_traits/members/92878_92947.cc (test for excess errors)
UNRESOLVED: 20_util/allocator_traits/members/92878_92947.cc
compilation failed to produce executable
FAIL: 20_util/assume_aligned/1.cc (test for excess errors)
UNRESOLVED: 20_util/assume_aligned/1.cc compilation failed to produce executable
FAIL: 20_util/assume_aligned/2_neg.cc (test for excess errors)
FAIL: 20_util/assume_aligned/3.cc (test for excess errors)
UNRESOLVED: 20_util/assume_aligned/3.cc scan-assembler-not undefined
FAIL: 20_util/assume_aligned/97132.cc (test for excess errors)
FAIL: 20_util/function_objects/bind_front/2.cc (test for excess errors)
UNRESOLVED: 20_util/function_objects/bind_front/2.cc compilation
failed to produce executable
FAIL: 20_util/pair/comparison_operators/constexpr_c++20.cc (test for
excess errors)
FAIL: 20_util/pair/cons/92878_92947.cc (test for excess errors)
UNRESOLVED: 20_util/pair/cons/92878_92947.cc compilation failed to
produce executable
etc.

The errors all are of the form:

/tmp/GCC/powerpc-ibm-aix7.2.3.0/libstdc++-v3/include/bits/atomic_wait.h:125:
error: 'mutex' is not a member of 'std'
/tmp/GCC/powerpc-ibm-aix7.2.3.0/libstdc++-v3/include/bits/atomic_wait.h:125:
error: template argument 1 is invalid
/tmp/GCC/powerpc-ibm-aix7.2.3.0/libstdc++-v3/include/bits/atomic_wait.h:125:
error: '' in namespace 'std' does not name a type
/tmp/GCC/powerpc-ibm-aix7.2.3.0/libstdc++-v3/include/bits/atomic_wait.h:126:
error: '__lock_t' does not name a type; did you mean 'clock_t'?
/tmp/GCC/powerpc-ibm-aix7.2.3.0/libstdc++-v3/include/bits/atomic_wait.h:132:
error: '__gthread_cond_t' does not name a type; did you mean
'pthread_cond_t'?
/tmp/GCC/powerpc-ibm-aix7.2.3.0/libstdc++-v3/include/bits/atomic_wait.h:135:
error: '_M_cond' was not declared in this scope
/tmp/GCC/powerpc-ibm-aix7.2.3.0/libstdc++-v3/include/bits/atomic_wait.h:135:
error: '__GTHREAD_COND_INIT_FUNCTION' was not declared in this scope
/tmp/GCC/powerpc-ibm-aix7.2.3.0/libstdc++-v3/include/bits/atomic_wait.h:164:
error: '__lock_t' is not a member of 'std::__detail::__waiters'
/tmp/GCC/powerpc-ibm-aix7.2.3.0/libstdc++-v3/include/bits/atomic_wait.h:165:
error: '_M_cv' was not declared in this scope
/tmp/GCC/powerpc-ibm-aix7.2.3.0/libstdc++-v3/include/bits/atomic_wait.h:165:
error: '__l' was not declared in this scope; did you mean '__lg'?
/tmp/GCC/powerpc-ibm-aix7.2.3.0/libstdc++-v3/include/bits/atomic_wait.h:165:
error: '__gthread_cond_wait' was not declared in this scope; did you
mean 'pthread_cond_t'?
/tmp/GCC/powerpc-ibm-aix7.2.3.0/libstdc++-v3/include/bits/atomic_wait.h:191:
error: '_M_cv' was not declared in this scope
/tmp/GCC/powerpc-ibm-aix7.2.3.0/libstdc++-v3/include/bits/atomic_wait.h:191:
error: '__gthread_cond_broadcast' was not declared in this scope
/tmp/GCC/powerpc-ibm-aix7.2.3.0/libstdc++v3/include/bits/atomic_timed_wait.h:144:
error: '__gthread_cond_t' was not declared in this scope; did you mean
'pthread_cond_t'?
/tmp/GCC/powerpc-ibm-aix7.2.3.0/libstdc++v3/include/bits/atomic_timed_wait.h:144:
error: '__cv' was not declared in this scope

Re: [PATCH] c++: Reject identifier label in constexpr [PR97846]

[Marek Polacek via Gcc-patches]

On Fri, Nov 20, 2020 at 05:18:55PM -0500, Jason Merrill via Gcc-patches wrote:
> On 11/16/20 9:58 PM, Marek Polacek wrote:
> > [dcl.constexpr]/3 says that the function-body of a constexpr function
> > shall not contain an identifier label, but we aren't enforcing that.
> > 
> > This patch implements that.  Of course, we can't reject artificial
> > labels.
> > 
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > 
> > gcc/cp/ChangeLog:
> > 
> > PR c++/97846
> > * constexpr.c (potential_constant_expression_1): Reject
> > LABEL_EXPRs that use non-artifical LABEL_DECLs.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > PR c++/97846
> > * g++.dg/cpp1y/constexpr-label.C: New test.
> > ---
> >   gcc/cp/constexpr.c   | 9 -
> >   gcc/testsuite/g++.dg/cpp1y/constexpr-label.C | 9 +
> >   2 files changed, 17 insertions(+), 1 deletion(-)
> >   create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-label.C
> > 
> > diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
> > index e6ab5eecd68..e4fbce14065 100644
> > --- a/gcc/cp/constexpr.c
> > +++ b/gcc/cp/constexpr.c
> > @@ -7484,7 +7484,6 @@ potential_constant_expression_1 (tree t, bool 
> > want_rval, bool strict, bool now,
> >   case OVERLOAD:
> >   case TEMPLATE_ID_EXPR:
> >   case LABEL_DECL:
> > -case LABEL_EXPR:
> >   case CASE_LABEL_EXPR:
> >   case PREDICT_EXPR:
> >   case CONST_DECL:
> > @@ -8393,6 +8392,14 @@ potential_constant_expression_1 (tree t, bool 
> > want_rval, bool strict, bool now,
> > return false;
> > }
> > +case LABEL_EXPR:
> > +  t = LABEL_EXPR_LABEL (t);
> > +  if (DECL_ARTIFICIAL (t) && DECL_IGNORED_P (t))
> 
> Is it useful to check DECL_IGNORED_P?  I'd think we want to allow any
> artificial labels, regardless of whether we're emitting debug info for them.

Not really; I only checked it because create_artificial_label sets it.  I'll
commit the patch without that check.

> OK either way.

Thanks,

Marek

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

[Toon Moene]

[ cc'd to the fortran mailing list to hopely get some more knowledgeable 
input ... ]


On 11/20/20 4:38 AM, Maciej W. Rozycki wrote:


2. libgfortran -- oddly enough for Fortran a piece requires IEEE 754
floating-point arithmetic (possibly a porting problem too).


gcc/libgfortran/config.h.in does have:

/* Define to 1 if you have the  header file. */
#undef HAVE_IEEEFP_H

So perhaps it does do the "right thing" if you do not have this header 
file on your VAX operating system.


The Fortran Standard allows an implementation *not* to have IEEE 
floating point support ...


Kind regards,

--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands

Re: [PATCH] c++: Fix ICE-on-invalid with -Wvexing-parse [PR97881]

[Marek Polacek via Gcc-patches]

On Fri, Nov 20, 2020 at 05:23:56PM -0500, Jason Merrill wrote:
> On 11/17/20 2:32 PM, Marek Polacek wrote:
> > --- /dev/null
> > +++ b/gcc/testsuite/g++.dg/warn/Wvexing-parse9.C
> > @@ -0,0 +1,8 @@
> > +// PR c++/97881
> > +// { dg-do compile }
> > +
> > +void
> > +cb ()
> > +{
> > +  volatile _Atomic (int) a1; // { dg-error "expected initializer" }
> 
> I'm not sure it's useful to test for this particular error, since a missing
> initializer isn't the problem with this declaration.  OK either way.

True, I pushed the patch with { dg-error "" } instead.


Thanks,
Marek

Re: [PATCH] vect: Add a “very cheap” cost model

[Jan Hubicka]

> > I tested this by building and running a bunch of workloads for SVE,
> > with three options:
> >
> >   (1) -O2
> >   (2) -O2 -ftree-vectorize -fvect-cost-model=very-cheap
> >   (3) -O2 -ftree-vectorize [-fvect-cost-model=cheap]
> >
> > All three builds used the default -msve-vector-bits=scalable and
> > ran with the minimum vector length of 128 bits, which should give
> > a worst-case bound for the performance impact.
> >
> > The workloads included a mixture of microbenchmarks and full
> > applications.  Because it's quite an eclectic mix, there's not
> > much point giving exact figures.  The aim was more to get a general
> > impression.
> >
> > Code size growth with (2) was much lower than with (3).  Only a
> > handful of tests increased by more than 5%, and all of them were
> > microbenchmarks.
> >
> > In terms of performance, (2) was significantly faster than (1)
> > on microbenchmarks (as expected) but also on some full apps.
> > Again, performance only regressed on a handful of tests.
> >
> > As expected, the performance of (3) vs. (1) and (3) vs. (2) is more
> > of a mixed bag.  There are several significant improvements with (3)
> > over (2), but also some (smaller) regressions.  That seems to be in
> > line with -O2 -ftree-vectorize being a kind of -O2.5.
> 
> So previous attempts at enabling vectorization at -O2 also factored
> in compile-time requirements.  We've looked mainly at SPEC and
> there even the current "cheap" model doesn't fare very well IIRC
> and costs quite some compile-time and code-size.  Turning down
> vectorization even more will have even less impact on performance
> but the compile-time cost will likely not shrink very much.
> 
> I think we need ways to detect candidates that will end up
> cheap or very cheap without actually doing all of the analysis
> first.
The current cheap model indeed costs quite some code size.  I 
was playing with similar patch (mine simply changed the cheap model).
Richard's patch tests as follows:

https://lnt.opensuse.org/db_default/v4/CPP/latest_runs_report?younger_in_days=14&older_in_days=0&all_changes=on&min_percentage_change=0.02&revisions=e4360e452b4c6cd56d4e21663703e920763413f5%2C11d39d4b278efb4a0134f495d698c2cd764c06e4%2Ca0917becd66182eee6eb6a7a150e38f0463b765d&include_user_branches=on
https://lnt.opensuse.org/db_default/v4/SPEC/latest_runs_report?younger_in_days=14&older_in_days=0&all_changes=on&min_percentage_change=0.02&revisions=e4360e452b4c6cd56d4e21663703e920763413f5%2C11d39d4b278efb4a0134f495d698c2cd764c06e4%2Ca0917becd66182eee6eb6a7a150e38f0463b765d&include_user_branches=on
(not all of SPEC2k runs are finished at the time of writting the email)

Here baseline is current trunk, first run is with vectorizer forced to
very cheap for both -O2 and -O3/fast and last is with vectorizer forced to
dynamic (so -O3/fast is same as baseline)

6.5% SPECint2017 improvement at -O2 is certainly very nice even if 
large part comes from x264 benchmark.
CPU2006 is affected by regression of tonto and cactusADM where the
second is known to be bit random.

There are some regressions but they exists already at -O3 and I guess
those are easier to track than usual -O3 vectorization failure so I will
check if they are tracked by bugzilla.
(for example 100% regression on cray should be very easy)

libxul LTO linktime at -O2 goes up from
real7m47.358s
user76m49.109s
sys 2m2.403s

to

real8m12.651s
user80m0.704s
sys 2m9.275s

so about 4.1% of backend time. (overall firefox build time is about 45
minutes on my setup)

For comparsion  -O2 --disable-tree-pre gives me:

real7m36.438s
user73m20.167s
sys 2m3.460s

So 4.7% backend time.
These values should be off-noise, I re-run the tests few times.

I would say that the speedups for vectorization are justified especially
when there are essentially zero code size costs.  It depends where we
set the bar on compile time...

Honza

Re: [PATCH v2] Fix -ffast-math flags handling inconsistencies

[Segher Boessenkool]

Hi!

On Fri, Nov 20, 2020 at 09:33:48PM -0700, Jeff Law wrote:
> On 2/11/20 11:43 AM, Ulrich Weigand wrote:
> > 1. If a component flag of -ffast-math (or -funsafe-math-optimizations)
> >is explicitly set (or reset) on the command line, this should override
> >any implicit change due to -f(no-)fast-math, no matter in which order
> >the flags come on the command line.  This change affects all flags.
> >
> > 2. Any component flag modified from its default by -ffast-math should
> >be reset to the default by -fno-fast-math.  This was previously
> >not done for the following flags:
> >   -fcx-limited-range
> >   -fexcess-precision=
> >
> > 3. Once -ffinite-math-only is true, the -f(no-)signaling-nans flag has
> >no meaning (if we have no NaNs at all, it does not matter whether
> >there is a difference between quiet and signaling NaNs).  Therefore,
> >it does not make sense for -ffast-math to imply -fno-signaling-nans.
> >This is also a documentation change.
> >
> > 4. -ffast-math is documented to imply -fno-rounding-math, however the
> >latter setting is the default anyway; therefore it does not make
> >sense to try to modify it from its default setting.
> >
> > 5. The __FAST_MATH__ preprocessor macro should be defined if and only
> >if all the component flags of -ffast-math are set to the value that
> >is documented as the effect of -ffast-math.  The following flags
> >were currently *not* so tested:
> >  -fcx-limited-range
> >  -fassociative-math
> >  -freciprocal-math
> >  -frounding-math
> >(Note that we should still *test* for -fno-rounding-math here even
> >though it is not set as per 4.  -ffast-math -frounding-math should
> >not set the __FAST_MATH__ macro.)
> >This is also a documentation change.

> It appears this was dropped on the floor.  It looks reasonable to me. 
> Please retest and commit.  Thanks!

It all makes sense, and is a nice improvement :-)  But please mention it
in the release notes?  No doubt people did use non-sensical flag
combinations, and they will be affected.  Thanks!


Segher

Re: [PATCH] libstdc++: Add C++2a synchronization support

[Jonathan Wakely via Gcc-patches]

On 21/11/20 17:04 +, Jonathan Wakely wrote:

On 21/11/20 16:16 +0100, Andreas Schwab wrote:

In file included from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/shared_ptr_atomic.h:33,
   from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/memory:78,
   from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/stdc++.h:82,
   from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/extc++.h:32,
   from 
/daten/aranym/gcc/gcc-20201121/libstdc++-v3/testsuite/17_intro/headers/c++2020/all_attributes.cc:37:
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_base.h:
 In member function 'void std::atomic_flag::wait(bool, std::memory_order) 
const':
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_base.h:239:
 error: no matching function for call to '__atomic_wait(const __atomic_flag_data_type*, 
bool&, std::atomic_flag::wait(bool, std::memory_order) const::)'
In file included from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_base.h:41,
   from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/shared_ptr_atomic.h:33,
   from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/memory:78,
   from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/stdc++.h:82,
   from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/extc++.h:32,
   from 
/daten/aranym/gcc/gcc-20201121/libstdc++-v3/testsuite/17_intro/headers/c++2020/all_attributes.cc:37:
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_wait.h:265:
 note: candidate: 'template void 
std::__atomic_wait(const _Tp*, _Tp, _Pred)'
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_wait.h:265:
 note:   template argument deduction/substitution failed:
In file included from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/shared_ptr_atomic.h:33,
   from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/memory:78,
   from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/stdc++.h:82,
   from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/extc++.h:32,
   from 
/daten/aranym/gcc/gcc-20201121/libstdc++-v3/testsuite/17_intro/headers/c++2020/all_attributes.cc:37:
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_base.h:239:
 note:   deduced conflicting types for parameter '_Tp' ('unsigned char' and 
'bool')


I'm testing this.


I'm committing this instead, it's the same but also disables
29_atomics/atomic/wait_notify/generic.cc on non-linux targets.

Tested sparc-solaris2.11 and powerpc64le-linux.

There are still some timeouts on linux:

FAIL: 30_threads/latch/3.cc execution test
FAIL: 30_threads/semaphore/try_acquire_for.cc execution test


commit 6f5387b7c9047baa5ee1385c8f5148d2c351bd20
Author: Jonathan Wakely 
Date:   Sat Nov 21 16:52:22 2020

libstdc++: Fix atomic waiting for non-linux targets

This fixes some UNRESOLVED tests on (at least) Solaris and Darwin, and
disables some tests that hang forever on Solaris. A proper fix is still
needed.

libstdc++-v3/ChangeLog:

* include/bits/atomic_base.h (atomic_flag::wait): Use correct
type for __atomic_wait call.
* include/bits/atomic_timed_wait.h (__atomic_wait_until): Check
_GLIBCXX_HAVE_LINUX_FUTEX.
* include/bits/atomic_wait.h (__atomic_notify): Likewise.
* include/bits/semaphore_base.h (_GLIBCXX_HAVE_POSIX_SEMAPHORE):
Only define if SEM_VALUE_MAX or _POSIX_SEM_VALUE_MAX is defined.
* testsuite/29_atomics/atomic/wait_notify/bool.cc: Disable on
non-linux targes.
* testsuite/29_atomics/atomic/wait_notify/generic.cc: Likewise.
* testsuite/29_atomics/atomic/wait_notify/pointers.cc: Likewise.
* testsuite/29_atomics/atomic_flag/wait_notify/1.cc: Likewise.
* testsuite/29_atomics/atomic_float/wait_notify.cc: Likewise.

diff --git a/libstdc++-v3/include/bits/atomic_base.h b/libstdc++-v3/include/bits/atomic_base.h
index dd4db926592e..7de02f169977 100644
--- a/libstdc++-v3/include/bits/atomic_base.h
+++ b/libstdc++-v3/include/bits/atomic_base.h
@@ -234,7 +234,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 wait(bool __old,
 	memory_order __m = memory_order_seq_cst) const noexcept
 {
-  std::__atomic_wait(&_M_i, __old,
+  std::__atomic_wait(&_M_i, static_cast<__atomi

Re: [PATCH 28/31] RTL: Add `const_double_zero' syntactic rtx

[Jeff Law via Gcc-patches]

On 11/19/20 8:36 PM, Maciej W. Rozycki wrote:
> The use of a constant double zero is required for post-reload compare
> elimination to be able to discard redundant floating-point comparisons,
> for example with a VAX RTL instruction stream like:
>
> (insn 34 4 3 2 (parallel [
> (set (reg/v:DF 0 %r0 [orig:24 x ] [24])
> (mem/c:DF (plus:SI (reg/f:SI 12 %ap)
> (const_int 4 [0x4])) [1 x+0 S8 A32]))
> (clobber (reg:CC 16 %psl))
> ]) ".../gcc/testsuite/gcc.target/vax/cmpelim-eq-movdf.c":9:1 37 
> {*movdf}
>  (nil))
> (note 3 34 35 2 NOTE_INSN_FUNCTION_BEG)
> (insn 35 3 36 2 (set (reg:CCZ 16 %psl)
> (compare:CCZ (reg/v:DF 0 %r0 [orig:24 x ] [24])
> (const_double:DF 0.0 [0x0.0p+0]))) 
> ".../gcc/testsuite/gcc.target/vax/cmpelim-eq-movdf.c":10:6 21 {*cmpdf_ccz}
>  (nil))
> (jump_insn 36 35 9 2 (set (pc)
> (if_then_else (eq (reg:CCZ 16 %psl)
> (const_int 0 [0]))
> (label_ref 11)
> (pc))) ".../gcc/testsuite/gcc.target/vax/cmpelim-eq-movdf.c":10:6 
> 537 {*branch_ccz}
>  (int_list:REG_BR_PROB 536870916 (nil))
>  -> 11)
>
> that we want to transform into:
>
> (insn 34 4 3 2 (parallel [
> (set (reg:CCZ 16 %psl)
> (compare:CCZ (mem/c:DF (plus:SI (reg/f:SI 12 %ap)
> (const_int 4 [0x4])) [1 x+0 S8 A32])
> (const_double:DF 0.0 [0x0.0p+0])))
> (set (reg/v:DF 0 %r0 [orig:24 x ] [24])
> (mem/c:DF (plus:SI (reg/f:SI 12 %ap)
> (const_int 4 [0x4])) [1 x+0 S8 A32]))
> ]) ".../gcc/testsuite/gcc.target/vax/cmpelim-eq-movdf.c":9:1 40 
> {*movdf_ccz}
>  (nil))
> (note 3 34 36 2 NOTE_INSN_FUNCTION_BEG)
> (jump_insn 36 3 9 2 (set (pc)
> (if_then_else (eq (reg:CCZ 16 %psl)
> (const_int 0 [0]))
> (label_ref 11)
> (pc))) ".../gcc/testsuite/gcc.target/vax/cmpelim-eq-movdf.c":10:6 
> 537 {*branch_ccz}
>  (int_list:REG_BR_PROB 536870916 (nil))
>  -> 11)
>
> with the upcoming MODE_CC representation.
>
> For this we need to express the `const_double:DF 0.0 [0x0.0p+0]' rtx as
> recorded above in the relevant pattern(s) in machine description.  The
> way we represent double constants, as a host-dependent number of wide
> integers, however means that we currently have no portable way to encode
> a double zero constant in machine description.
>
> Define a syntactic rtx alias then to represent `(const_double 0 0 ...)'
> as if the suitable number of zeros have been supplied according to the
> host-specific definition of CONST_DOUBLE_FORMAT.
>
>   gcc/
>   * read-rtl.c (rtx_reader::read_rtx_code): Handle syntactic
>   `const_double_zero' rtx.
>   * doc/rtl.texi (Constant Expression Types): Document it.
OK
jeff

Re: libbacktrace integration for _GLIBCXX_DEBUG mode

[François Dumont via Gcc-patches]

Maybe this last patch that has been out for a while.

Here it is again rebased as some symbols have been added since my last 
proposal.


François

On 14/10/20 6:10 pm, François Dumont wrote:
After further testing this version was bugged because ld considered 
that __create_backtrace/__render_backtrace symbols existed several 
times in the different linked .o.


I tried making those inline but it failed, __render_backtrace was not 
substituted anymore, only __create_backtrace was.


The correct (tested) fix was to make _Error_formatter methods using 
those symbols outline. So here is the new patch.



    libstdc++: [_GLIBCXX_DEBUG] Integrate libbacktrace

  New _GLIBCXX_DEBUG_BACKTRACE macro to activate backtrace 
generation on

    _GLIBCXX_DEBUG assertions using libbacktrace.

    * config/abi/pre/gnu.ver: Add new symbols.
    * include/debug/formatter.h [_GLIBCXX_DEBUG_BACKTRACE]:
    Include .
    [_GLIBCXX_DEBUG_BACKTRACE && BACKTRACE_SUPPORTED]:
    Include .
    [(!_GLIBCXX_DEBUG_BACKTRACE || !BACKTRACE_SUPPORTED) &&
    _GLIBCXX_USE_C99_STDINT_TR1]: Include .
    [BACKTRACE_SUPPORTED || _GLIBCXX_USE_C99_STDINT_TR1]
    [_GLIBCXX_DEBUG_USE_LIBBACKTRACE]
    (__gnu_debug::__create_backtrace_state): New.
    [_GLIBCXX_DEBUG_USE_LIBBACKTRACE]
    (__gnu_debug::__render_backtrace): New.
[_GLIBCXX_DEBUG_USE_LIBBACKTRACE](_Error_formatter::_M_print_backtrace):
    New.
[_GLIBCXX_DEBUG_USE_LIBBACKTRACE](_Error_formatter::_M_backtrace_state):
    New.
    (_Error_formatter::_Error_formatter): Outline definition.
    * src/c++11/debug.cc: Include .
    (_Print_func_t): New.
    (print_word): Use '%.*s' format in fprintf to render only 
expected

    number of chars.
    (print_raw(PrintContext&, const char*, ptrdiff_t)): New.
    (print_function(PrintContext&, const char*, 
_Print_func_t)): New.

    (print_type): Use latter.
    (print_string(PrintContext&, const char*, const 
_Parameter*, size_t)):

    Change signature to...
    (print_string(PrintContext&, const char*, ptrdiff_t, const 
_Parameter*,
    size_t)): ...this and adapt. Remove intermediate buffer to 
render input

    string.
    (print_string(PrintContext&, const char*, ptrdiff_t)): New.
    [_GLIBCXX_DEBUG_USE_LIBBACKTRACE]
    (print_backtrace(void*, uintptr_t, const char*, int, const 
char*)): New.

    (_Error_formatter::_M_error()): Adapt.
    [_GLIBCXX_DEBUG_USE_LIBBACKTRACE]
    (__gnu_debug::__create_backtrace_state): New, weak symbol.
    [_GLIBCXX_DEBUG_USE_LIBBACKTRACE]
    (__gnu_debug::__render_backtrace): New, weak symbol.
    * doc/xml/manual/debug_mode.xml: Document 
_GLIBCXX_DEBUG_BACKTRACE.

    * doc/xml/manual/using.xml: Likewise.

Ok to commit once I run all testsuite in _GLIBCXX_DEBUG with backtrace ?

François


On 08/10/20 9:32 pm, François Dumont wrote:
I eventually consider your last remark about using weak symbols to 
inject libbacktrace calls when _GLIBCXX_DEBUG_BACKTRACE is defined.


    libstdc++: [_GLIBCXX_DEBUG] Integrate libbacktrace

  Add _GLIBCXX_DEBUG_BACKTRACE macro to ask for a backtrace on 
_GLIBCXX_DEBUG

    assertions using libbacktrace.

    * config/abi/pre/gnu.ver: Add new symbols.
    * include/debug/formatter.h [_GLIBCXX_DEBUG_BACKTRACE]:
    Include .
    [_GLIBCXX_DEBUG_BACKTRACE && BACKTRACE_SUPPORTED]:
    Include .
    [(!_GLIBCXX_DEBUG_BACKTRACE || !BACKTRACE_SUPPORTED) &&
    _GLIBCXX_USE_C99_STDINT_TR1]: Include .
    [BACKTRACE_SUPPORTED || _GLIBCXX_USE_C99_STDINT_TR1]
    [_GLIBCXX_DEBUG_USE_LIBBACKTRACE]
    (__gnu_debug::__create_backtrace_state): New.
    [_GLIBCXX_DEBUG_USE_LIBBACKTRACE]
    (__gnu_debug::__render_backtrace): New.
[_GLIBCXX_DEBUG_USE_LIBBACKTRACE](_Error_formatter::_M_print_backtrace):
    New.
[_GLIBCXX_DEBUG_USE_LIBBACKTRACE](_Error_formatter::_M_backtrace_state):
    New.
    * src/c++11/debug.cc: Include .
    (_Print_func_t): New.
    (print_word): Use '%.*s' format in fprintf to render only 
expected

    number of chars.
    (print_raw(PrintContext&, const char*, ptrdiff_t)): New.
    (print_function(PrintContext&, const char*, 
_Print_func_t)): New.

    (print_type): Use latter.
    (print_string(PrintContext&, const char*, const 
_Parameter*, size_t)):

    Change signature to...
    (print_string(PrintContext&, const char*, ptrdiff_t, 
const _Parameter*,
    size_t)): ...this and adapt. Remove intermediate buffer 
to render input

    string.
    (print_string(PrintContext&, const char*, ptrdiff_t)): New.
    [_GLIBCXX_DEBUG_USE_LIB

Re: [PATCH 24/31] VAX: Fix predicates and constraints for bitfield comparison insns

[Jeff Law via Gcc-patches]

On 11/19/20 8:36 PM, Maciej W. Rozycki wrote:
> It makes no sense for insn operand predicates, as long as they accept a
> register operand, to be more restrictive than the set of the associated
> constraints, because expand will choose the insn based on the relevant
> operand being a pseudo register then and reload keep it happily as a
> memory reference if a constraint permits it.  So the restriction posed
> by such a predicate will be happily ignored, and moreover if a splitter
> is added, such as required for MODE_CC support, the new instructions
> will reject the original operands supplied, causing an ICE.  An actual
> example will be given with a subsequent change.
>
> Therefore, similarly to EXTV/EXTZV/INSV insns, remove inconsistencies
> with predicates and constraints of bitfield comparison insns, observing
> that a bitfield located in memory is byte-addressed by the respective
> machine instructions and therefore SImode may only be used with a
> register or an offsettable memory operand (i.e. not an indexed,
> pre-decremented, or post-incremented one).
>
> Also give the insns names, for easier reference here and elsewhere.
>
>   gcc/
>   * config/vax/vax.md (*cmpv_2): Name insn.
>   (*cmpv, *cmpzv, *cmpzv_2): Likewise.  Fix location predicate and
>   constraint.
OK
jeff

Re: [PATCH 23/31] VAX: Make `extv' an expander matching the remaining bitfield operations

[Jeff Law via Gcc-patches]

On 11/19/20 8:36 PM, Maciej W. Rozycki wrote:
> We have matching insns defined for `sign_extract' and `zero_extract'
> expressions, so make the three named patterns for bitfield operations
> consistent and make `extv' an expander rather than an insn taking a
> SImode, a QImode, and a SImode general operand for the LOC, SIZE, and
> POS operands respectively, like with the `extzv' and `insv' patterns,
> matching the machine instructions and giving the middle end more choice
> as to which actual insn to choose in a given situation.
>
> Given this program:
>
> typedef struct
> {
>   int f0:1;
>   int f1:7;
>   int f8:8;
>   int f16:16;
> } bit_t;
>
> typedef struct
> {
>   unsigned int f0:1;
>   unsigned int f1:7;
>   unsigned int f8:8;
>   unsigned int f16:16;
> } ubit_t;
>
> typedef union
> {
>   bit_t b;
>   int i;
> } bit_u;
>
> typedef union
> {
>   ubit_t b;
>   unsigned int i;
> } ubit_u;
>
> int
> ins1 (bit_u x, int y)
> {
>   asm volatile ("" : "+r" (x), "+r" (y));
>   x.b.f1 = y;
>   return x.i;
> }
>
> int
> ext1 (bit_u x)
> {
>   asm volatile ("" : "+r" (x));
>   return x.b.f1;
> }
>
> unsigned int
> extz1 (ubit_u x)
> {
>   asm volatile ("" : "+r" (x));
>   return x.b.f1;
> }
>
> int
> ins8 (bit_u x, int y)
> {
>   asm volatile ("" : "+r" (x), "+r" (y));
>   x.b.f8 = y;
>   return x.i;
> }
>
> int
> ext8 (bit_u x)
> {
>   asm volatile ("" : "+r" (x));
>   return x.b.f8;
> }
>
> unsigned int
> extz8 (ubit_u x)
> {
>   asm volatile ("" : "+r" (x));
>   return x.b.f8;
> }
>
> int
> ins16 (bit_u x, int y)
> {
>   asm volatile ("" : "+r" (x), "+r" (y));
>   x.b.f16 = y;
>   return x.i;
> }
>
> int
> ext16 (bit_u x)
> {
>   asm volatile ("" : "+r" (x));
>   return x.b.f16;
> }
>
> unsigned int
> extz16 (ubit_u x)
> {
>   asm volatile ("" : "+r" (x));
>   return x.b.f16;
> }
>
> this results in the following code change:
>
> @@ -16,12 +16,12 @@ ins1:
>  .globl ext1
>   .type   ext1, @function
>  ext1:
> - .word 0 # 19[c=0]  procedure_entry_mask
> - subl2 $4,%sp# 20[c=32]  addsi3
> + .word 0 # 18[c=0]  procedure_entry_mask
> + subl2 $4,%sp# 19[c=32]  addsi3
>   movl 4(%ap),%r0 # 2 [c=16]  movsi_2
> - cvtbl %r0,%r0   # 7 [c=4]  extendqisi2
> - ashl $-1,%r0,%r0# 14[c=40]  *vax.md:624
> - ret # 24[c=0]  return
> + extv $1,$7,%r0,%r0  # 7 [c=60]  *extv_non_const
> + cvtbl %r0,%r0   # 13[c=4]  extendqisi2
> + ret # 23[c=0]  return
>   .size   ext1, .-ext1
>   .align 1
>  .globl extz1
> @@ -49,12 +49,12 @@ ins8:
>  .globl ext8
>   .type   ext8, @function
>  ext8:
> - .word 0 # 20[c=0]  procedure_entry_mask
> - subl2 $4,%sp# 21[c=32]  addsi3
> + .word 0 # 18[c=0]  procedure_entry_mask
> + subl2 $4,%sp# 19[c=32]  addsi3
>   movl 4(%ap),%r0 # 2 [c=16]  movsi_2
> - cvtwl %r0,%r0   # 7 [c=4]  extendhisi2
> - ashl $-8,%r0,%r0# 15[c=40]  *vax.md:624
> - ret # 25[c=0]  return
> + rotl $24,%r0,%r0# 13[c=60]  *extv_non_const
> + cvtbl %r0,%r0
> + ret # 23[c=0]  return
>   .size   ext8, .-ext8
>   .align 1
>  .globl extz8
>
> If there is a performance degradation with the replacement sequences,
> then it can and should be sorted within `extv_non_const'.
>
>   gcc/
>   * config/vax/vax.md (extv): Rename insn to...
>   (*extv): ... this.
>   (extv): New expander.
OK
jeff

Re: [PATCH 21/31] VAX: Remove EXTV/EXTZV/INSV instruction use from aligned case insns

[Jeff Law via Gcc-patches]

On 11/19/20 8:35 PM, Maciej W. Rozycki wrote:
> The INSV machine instruction is the only computational operation in the
> VAX ISA that keeps condition codes intact.  In preparation to MODE_CC
> transition keep patterns apart then that make or do not make use of said
> instruction.  For consistency update EXTV and EXTZV instruction uses
> accordingly.  In expand SUBREGs will be presented as operands, so handle
> that possibility in the insn condition.
>
> This actually yields better code by avoiding EXTV/EXTZV instructions in
> pseudo-aligned register cases previously resorting to those instructions:
>
> @@ -42,7 +42,7 @@ ins8:
>   subl2 $4,%sp# 21[c=32]  addsi3
>   movl 4(%ap),%r0 # 2 [c=16]  movsi_2
>   movl 8(%ap),%r1 # 17[c=16]  movsi_2
> - insv %r1,$8,$8,%r0  # 9 [c=4]  *insv_aligned
> + insv %r1,$8,$8,%r0  # 9 [c=4]  *insv_2
>   ret # 25[c=0]  return
>   .size   ins8, .-ins8
>   .align 1
> @@ -60,12 +60,12 @@ ext8:
>  .globl extz8
>   .type   extz8, @function
>  extz8:
> - .word 0 # 19[c=0]  procedure_entry_mask
> - subl2 $4,%sp# 20[c=32]  addsi3
> + .word 0 # 18[c=0]  procedure_entry_mask
> + subl2 $4,%sp# 19[c=32]  addsi3
>   movl 4(%ap),%r0 # 2 [c=16]  movsi_2
> - extzv $8,$8,%r0,%r1 # 13[c=60]  *extzv_aligned
> - movl %r1,%r0# 18[c=4]  movsi_2
> - ret # 24[c=0]  return
> + rotl $24,%r0,%r0# 13[c=60]  *extzv_non_const
> + movzbl %r0,%r0
> + ret # 23[c=0]  return
>   .size   extz8, .-extz8
>   .align 1
>  .globl ins16
> @@ -75,7 +75,7 @@ ins16:
>   subl2 $4,%sp# 21[c=32]  addsi3
>   movl 4(%ap),%r0 # 2 [c=16]  movsi_2
>   movl 8(%ap),%r1 # 17[c=16]  movsi_2
> - insv %r1,$16,$16,%r0# 9 [c=4]  *insv_aligned
> + insv %r1,$16,$16,%r0# 9 [c=4]  *insv_2
>   ret # 25[c=0]  return
>   .size   ins16, .-ins16
>   .align 1
> @@ -94,8 +94,9 @@ ext16:
>  extz16:
>   .word 0 # 18[c=0]  procedure_entry_mask
>   subl2 $4,%sp# 19[c=32]  addsi3
> - movl 4(%ap),%r1 # 2 [c=16]  movsi_2
> - extzv $16,$16,%r1,%r0   # 7 [c=60]  *extzv_aligned
> + movl 4(%ap),%r0 # 2 [c=16]  movsi_2
> + rotl $16,%r0,%r0# 7 [c=60]  *extzv_non_const
> + movzwl %r0,%r0
>   movzwl %r0,%r0  # 13[c=4]  zero_extendhisi2
>   ret # 23[c=0]  return
>   .size   extz16, .-extz16
>
> demonstrated with this program:
>
> typedef struct
> {
>   int f0:1;
>   int f1:7;
>   int f8:8;
>   int f16:16;
> } bit_t;
>
> typedef struct
> {
>   unsigned int f0:1;
>   unsigned int f1:7;
>   unsigned int f8:8;
>   unsigned int f16:16;
> } ubit_t;
>
> typedef union
> {
>   bit_t b;
>   int i;
> } bit_u;
>
> typedef union
> {
>   ubit_t b;
>   unsigned int i;
> } ubit_u;
>
> int
> ins1 (bit_u x, int y)
> {
>   asm volatile ("" : "+r" (x), "+r" (y));
>   x.b.f1 = y;
>   return x.i;
> }
>
> int
> ext1 (bit_u x)
> {
>   asm volatile ("" : "+r" (x));
>   return x.b.f1;
> }
>
> unsigned int
> extz1 (ubit_u x)
> {
>   asm volatile ("" : "+r" (x));
>   return x.b.f1;
> }
>
> int
> ins8 (bit_u x, int y)
> {
>   asm volatile ("" : "+r" (x), "+r" (y));
>   x.b.f8 = y;
>   return x.i;
> }
>
> int
> ext8 (bit_u x)
> {
>   asm volatile ("" : "+r" (x));
>   return x.b.f8;
> }
>
> unsigned int
> extz8 (ubit_u x)
> {
>   asm volatile ("" : "+r" (x));
>   return x.b.f8;
> }
>
> int
> ins16 (bit_u x, int y)
> {
>   asm volatile ("" : "+r" (x), "+r" (y));
>   x.b.f16 = y;
>   return x.i;
> }
>
> int
> ext16 (bit_u x)
> {
>   asm volatile ("" : "+r" (x));
>   return x.b.f16;
> }
>
> unsigned int
> extz16 (ubit_u x)
> {
>   asm volatile ("" : "+r" (x));
>   return x.b.f16;
> }
>
> It also papers over a regression:
>
> FAIL: gcc.dg/pr83623.c (internal compiler error)
> FAIL: gcc.dg/pr83623.c (test for excess errors)
>
> from an ICE like:
>
> during RTL pass: final
> .../gcc/testsuite/gcc.dg/pr83623.c: In function 'foo':
> .../gcc/testsuite/gcc.dg/pr83623.c:13:1: internal compiler error: in 
> change_address_1, at emit-rtl.c:2275
> 0x10a056e3 change_address_1
>   .../gcc/emit-rtl.c:2275
> 0x10a0645f adjust_address_1(rtx_def*, machine_mode, poly_int<1u, long>, int, 
> int, int, poly_int<1u, long>)
>   .../gcc/emit-rtl.c:2409
> 0x11cb588f output_97
>   .../gcc/config/vax/vax.md:808
> 0x10aafb2f get_insn_template(int, rtx_insn*)
>   .../gcc/final.c:2070
> 0x10ab2b3f final_scan_insn_1
>   .../gcc/final.c:3039
> 0x10ab313b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
>   .../gcc/final.c:3152
> 0x10aaf887 final_1
>   .../gcc/final.c:2020
> 0x10ab703b rest_of_handle_final
>   .../gcc/final.c:4658
> 0x10ab757b execute
>   .../gcc/final.c:4736
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace w

Update vect-35.c testcase

[Jan Hubicka]

Hi,
We now determine depnedencies across union fields correctly so 2 instead
of 1 loops are vectorized.

regtsted x86_64-linux, comitted.

* gcc.dg/vect/vect-35-big-array.c: Excpect 2 loops to be vectorized.
* gcc.dg/vect/vect-35.c: Excpect 2 loops to be vectorized.

diff --git a/gcc/testsuite/gcc.dg/vect/vect-35-big-array.c 
b/gcc/testsuite/gcc.dg/vect/vect-35-big-array.c
index ca57a10f714..28a99c910fd 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-35-big-array.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-35-big-array.c
@@ -20,10 +20,6 @@ int main1 ()
   s.b[i] = i;
 }
 
-  /* Dependence analysis fails cause s.a and s.b may overlap.
- Try to use runtime aliasing test with versioning, and
- later versioning/vectorization are skipped because the
- overlap is proven at compilation time.  */
   for (i = 0; i < N; i++)
 {
   s.a[i] = s.b[i] + 1;
@@ -47,5 +43,4 @@ int main (void)
 }
 
 
-/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect"  { xfail { 
ia64-*-* sparc*-*-* } } } } */
-/* { dg-final { scan-tree-dump "can't determine dependence between" "vect" } } 
*/
+/* { dg-final { scan-tree-dump-times "vectorized 2 loops" 1 "vect"  { xfail { 
ia64-*-* sparc*-*-* } } } } */
diff --git a/gcc/testsuite/gcc.dg/vect/vect-35.c 
b/gcc/testsuite/gcc.dg/vect/vect-35.c
index 76fe32d68ad..a7ec0f16d4c 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-35.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-35.c
@@ -20,10 +20,6 @@ int main1 ()
   s.b[i] = i;
 }
 
-  /* Dependence analysis fails cause s.a and s.b may overlap.
- Try to use runtime aliasing test with versioning, and
- later versioning/vectorization are skipped because the
- overlap is proven at compilation time.  */
   for (i = 0; i < N; i++)
 {
   s.a[i] = s.b[i] + 1;
@@ -47,5 +43,4 @@ int main (void)
 } 
 
 
-/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect"  { xfail { 
ia64-*-* sparc*-*-* } } } } */
-/* { dg-final { scan-tree-dump "can't determine dependence between" "vect" } } 
*/
+/* { dg-final { scan-tree-dump-times "vectorized 2 loops" 1 "vect"  { xfail { 
ia64-*-* sparc*-*-* } } } } */

Re: [PATCH] libstdc++: Add C++2a synchronization support

[Jonathan Wakely via Gcc-patches]

On 21/11/20 16:16 +0100, Andreas Schwab wrote:

In file included from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/shared_ptr_atomic.h:33,
from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/memory:78,
from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/stdc++.h:82,
from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/extc++.h:32,
from 
/daten/aranym/gcc/gcc-20201121/libstdc++-v3/testsuite/17_intro/headers/c++2020/all_attributes.cc:37:
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_base.h:
 In member function 'void std::atomic_flag::wait(bool, std::memory_order) 
const':
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_base.h:239:
 error: no matching function for call to '__atomic_wait(const __atomic_flag_data_type*, 
bool&, std::atomic_flag::wait(bool, std::memory_order) const::)'
In file included from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_base.h:41,
from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/shared_ptr_atomic.h:33,
from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/memory:78,
from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/stdc++.h:82,
from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/extc++.h:32,
from 
/daten/aranym/gcc/gcc-20201121/libstdc++-v3/testsuite/17_intro/headers/c++2020/all_attributes.cc:37:
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_wait.h:265:
 note: candidate: 'template void 
std::__atomic_wait(const _Tp*, _Tp, _Pred)'
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_wait.h:265:
 note:   template argument deduction/substitution failed:
In file included from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/shared_ptr_atomic.h:33,
    from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/memory:78,
    from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/stdc++.h:82,
    from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/extc++.h:32,
    from 
/daten/aranym/gcc/gcc-20201121/libstdc++-v3/testsuite/17_intro/headers/c++2020/all_attributes.cc:37:
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_base.h:239:
 note:   deduced conflicting types for parameter '_Tp' ('unsigned char' and 
'bool')


I'm testing this.


commit 613ac97bed57eb0edb1803b66d5ce3510e665b3d
Author: Jonathan Wakely 
Date:   Sat Nov 21 16:52:22 2020

libstdc++: Fix atomic waiting for non-linux targets

This fixes some UNRESOLVED tests on (at least) Solaris and Darwin, and
disables some tests that hang forever on Solaris. A proper fix is still
needed.

libstdc++-v3/ChangeLog:

* include/bits/atomic_base.h (atomic_flag::wait): Use correct
type for __atomic_wait call.
* include/bits/atomic_timed_wait.h (__atomic_wait_until): Check
_GLIBCXX_HAVE_LINUX_FUTEX.
* include/bits/atomic_wait.h (__atomic_notify): Likewise.
* include/bits/semaphore_base.h (_GLIBCXX_HAVE_POSIX_SEMAPHORE):
Only define if SEM_VALUE_MAX or _POSIX_SEM_VALUE_MAX is defined.
* testsuite/29_atomics/atomic/wait_notify/bool.cc: Disable on
non-linux targes.
* testsuite/29_atomics/atomic/wait_notify/pointers.cc: Likewise.
* testsuite/29_atomics/atomic_flag/wait_notify/1.cc: Likewise.
* testsuite/29_atomics/atomic_float/wait_notify.cc: Likewise.

diff --git a/libstdc++-v3/include/bits/atomic_base.h b/libstdc++-v3/include/bits/atomic_base.h
index dd4db926592e..7de02f169977 100644
--- a/libstdc++-v3/include/bits/atomic_base.h
+++ b/libstdc++-v3/include/bits/atomic_base.h
@@ -234,7 +234,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 wait(bool __old,
 	memory_order __m = memory_order_seq_cst) const noexcept
 {
-  std::__atomic_wait(&_M_i, __old,
+  std::__atomic_wait(&_M_i, static_cast<__atomic_flag_data_type>(__old),
 			 [__m, this, __old]()
 			 { return this->test(__m) != __old; });
 }
diff --git a/libstdc++-v3/include/bits/atomic_timed_wait.h b/libstdc++-v3/include/bits/atomic_timed_wait.h
index 7712a6c591dc..405f7e93ca85 100644
--- a/libstdc++-v3/include/bits/atomic_timed_wait.h
+++ b/libstdc++-v3/include/bits/atomic_timed_wait.h
@@ -240,12 +240,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   do

Re: [PATCH 22/31] VAX: Ensure PIC mode address is adjustable with aligned bitfield insns

[Jeff Law via Gcc-patches]

On 11/19/20 8:35 PM, Maciej W. Rozycki wrote:
> With the `*insv_aligned', `*extzv_aligned' and `*extv_aligned' insns we
> are going to adjust the bitfield location if it is in memory, so only
> allow such location addresses that can be offset, excluding external
> symbol references in the PIC mode in particular.
>
> This fixes an ICE like:
>
> during RTL pass: final
> In file included from .../gcc/testsuite/gcc.dg/torture/vshuf-v16qi.c:11:
> .../gcc/testsuite/gcc.dg/torture/vshuf-main.inc: In function 'test_13':
> .../gcc/testsuite/gcc.dg/torture/vshuf-main.inc:27:1: internal compiler 
> error: in change_address_1, at emit-rtl.c:2275
> .../gcc/testsuite/gcc.dg/torture/vshuf-16.inc:16:1: note: in expansion of 
> macro 'T'
> .../gcc/testsuite/gcc.dg/torture/vshuf-main.inc:28:1: note: in expansion of 
> macro 'TESTS'
> 0x10a34b33 change_address_1
>   .../gcc/emit-rtl.c:2275
> 0x10a358af adjust_address_1(rtx_def*, machine_mode, poly_int<1u, long>, int, 
> int, int, poly_int<1u, long>)
>   .../gcc/emit-rtl.c:2409
> 0x11d2505f output_97
>   .../gcc/config/vax/vax.md:806
> 0x10adec4b get_insn_template(int, rtx_insn*)
>   .../gcc/final.c:2070
> 0x10ae1c5b final_scan_insn_1
>   .../gcc/final.c:3039
> 0x10ae2257 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
>   .../gcc/final.c:3152
> 0x10ade9a3 final_1
>   .../gcc/final.c:2020
> 0x10ae6157 rest_of_handle_final
>   .../gcc/final.c:4658
> 0x10ae6697 execute
>   .../gcc/final.c:4736
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> compiler exited with status 1
> FAIL: gcc.dg/torture/vshuf-v16qi.c   -O2  (internal compiler error)
>
> triggered by an RTL instruction like:
>
> (insn 97 96 98 (set (reg:SI 5 %r5 [88])
> (zero_extract:SI (mem/c:SI (symbol_ref:SI ("b")  0x77f801b0 b>) [0 b+0 S4 A128])
> (const_int 8 [0x8])
> (const_int 24 [0x18]))) 
> ".../gcc/testsuite/gcc.dg/torture/vshuf-main.inc":28:1 97 {*extzv_aligned}
>  (nil))
>
> and removes these regressions:
>
> FAIL: gcc.dg/torture/vshuf-v16qi.c   -O2  (internal compiler error)
> FAIL: gcc.dg/torture/vshuf-v16qi.c   -O2  (test for excess errors)
> FAIL: gcc.dg/torture/vshuf-v4hi.c   -O2  (internal compiler error)
> FAIL: gcc.dg/torture/vshuf-v4hi.c   -O2  (test for excess errors)
> FAIL: gcc.dg/torture/vshuf-v8hi.c   -O2  (internal compiler error)
> FAIL: gcc.dg/torture/vshuf-v8hi.c   -O2  (test for excess errors)
> FAIL: gcc.dg/torture/vshuf-v8qi.c   -O2  (internal compiler error)
> FAIL: gcc.dg/torture/vshuf-v8qi.c   -O2  (test for excess errors)
>
> However expand typically presents pseudo-registers rather than memory
> references to these insns, so a further rework is required to make a
> better use of the code variant they are supposed to produce.  This at
> least fixes the problem at hand.
>
>   gcc/
>   * config/vax/vax.md (*insv_aligned, *extzv_aligned)
>   (*extv_aligned): Also make sure the memory address of a bitfield
>   location can be adjusted in the PIC mode.
OK
jeff

Re: [PATCH 20/31] VAX: Fix predicates and constraints for EXTV/EXTZV/INSV insns

[Jeff Law via Gcc-patches]

On 11/19/20 8:35 PM, Maciej W. Rozycki wrote:
> It makes no sense for insn operand predicates, as long as they accept a
> register operand, to be more restrictive than the set of the associated
> constraints, because expand will choose the insn based on the relevant
> operand being a pseudo register then and reload keep it happily as a
> memory reference if a constraint permits it.  So the restriction posed
> by such a predicate will be happily ignored, and moreover if a splitter
> is added, such as required for MODE_CC support, the new instructions
> will reject the original operands supplied, causing an ICE.  An actual
> example will be given with a subsequent change.
>
> Remove such inconsistencies we have with the EXTV/EXTZV/INSV insns then,
> observing that a bitfield located in memory is byte-addressed by the
> respective machine instructions and therefore SImode may only be used
> with a register or an offsettable memory operand (i.e. not an indexed,
> pre-decremented, or post-incremented one), which has already been taken
> into account with the constraints currently used, except for `*insv_2'.
> The QI machine mode may be used for the bitfield location with any kind
> of memory operand, but we got the constraint wrong, although harmlessly
> in reality, with `*insv'.  Fix that for consistency though.
>
> Also give the insns names, for easier reference here and elsewhere.
>
>   gcc/
>   * config/vax/vax.md (*insv_aligned, *extzv_aligned)
>   (*extv_aligned, *extv_non_const, *extzv_non_const): Name insns.
>   Fix location predicate.
>   (*extzv): Name insn.
>   (*insv): Likewise.  Fix location constraint.
>   (*insv_2): Likewise, and the predicate.
OK.
jeff

Re: [09/32] core diagnostics

[Jeff Law via Gcc-patches]

On 11/3/20 2:14 PM, Nathan Sidwell wrote:
> The 'included from ...' chain that one gets at the start of a
> diagnostic needs extending to include importing.  There are a few
> combinations to handle, but nothing particularly exciting.
>
>
> 09-core-diag.diff
>
OK with a ChangeLog
jeff

Re: [09/33] core diagnostics

[Jeff Law via Gcc-patches]

On 11/3/20 1:03 PM, Nathan Sidwell wrote:
> Here are the changes for gcc/configure.ac (config.h.in and configure
> get rebuilt).  This is adding smarts to check for networking features,
> so that a network-aware module mapper can be built.
>
>
>
> 10-core-config.diff
>
OK with a ChangeLog.

jeff

Re: [PATCH 3/3] Implement the "persistent" attribute

[Jeff Law via Gcc-patches]

On 11/15/20 3:06 PM, Jozef Lawrynowicz wrote:
> The "persistent" attribute is used for variables that are initialized
> by the program loader, but are not initialized by the runtime startup
> code. "persistent" variables are placed in a non-volatile area of
> memory, which allows their value to "persist" between processor resets.
>
> Successfully regtested for arm-none-eabi.
>
> Ok for trunk?
>
> 0003-Implement-the-persistent-attribute.patch
>
> From c67b1bb6f46a69916c7de74617f4301b95c894d8 Mon Sep 17 00:00:00 2001
> From: Jozef Lawrynowicz 
> Date: Sun, 15 Nov 2020 21:44:10 +
> Subject: [PATCH 3/3] Implement the "persistent" attribute
>
> The "persistent" attribute is used for variables that are initialized
> by the program loader, but are not initialized by the runtime startup
> code. "persistent" variables are placed in a non-volatile area of
> memory, which allows their value to "persist" between processor resets.
>
> gcc/c-family/ChangeLog:
>
>   * c-attribs.c (handle_special_var_sec_attribute): New.
>   (handle_noinit_attribute): Remove.
>   (attr_noinit_exclusions): Rename to...
>   (attr_section_exclusions): ...this, and add "persistent" attribute
>   exclusion.
>   (c_common_attribute_table): Add "persistent" attribute.
>
> gcc/ChangeLog:
>
>   * doc/extend.texi: Document the "persistent" variable attribute.
>   * tree.h (DECL_PERSISTENT_P): Define.
>   * varasm.c (bss_initializer_p): Return false for a
>   DECL_PERSISTENT_P decl initialized to zero.
>   (default_section_type_flags): Handle the ".persistent" section.
>   (default_elf_select_section): Likewise.
>   (default_unique_section): Likewise.
>
> gcc/testsuite/ChangeLog:
>
>   * gcc.c-torture/execute/noinit-attribute.c: Moved to...
>   * c-c++-common/torture/attr-noinit-main.inc: ...here.
>   * lib/target-supports.exp (check_effective_target_persistent): New.
>   * c-c++-common/torture/attr-noinit-1.c: New test.
>   * c-c++-common/torture/attr-noinit-2.c: New test.
>   * c-c++-common/torture/attr-noinit-3.c: New test.
>   * c-c++-common/torture/attr-noinit-invalid.c: New test.
>   * c-c++-common/torture/attr-persistent-1.c: New test.
>   * c-c++-common/torture/attr-persistent-2.c: New test.
>   * c-c++-common/torture/attr-persistent-3.c: New test.
>   * c-c++-common/torture/attr-persistent-invalid.c: New test.
>   * c-c++-common/torture/attr-persistent-main.inc: New test.
I think you need to document the new effective target check in
sourcebuild.texi.  With that change this is OK

jeff

Re: [PATCH] Hurd: Enable ifunc by default

[Samuel Thibault via Gcc-patches]

Ping?

I was able to pass glibc's complete ifunc tests with no problem.

Samuel

Samuel Thibault, le dim. 08 nov. 2020 23:52:51 +0100, a ecrit:
> The binutils bugs seem to have been fixed.
> 
> 2020-11-08  Samuel Thibault  
> 
>   gcc/
>   * config.gcc: Enable default_gnu_indirect_function in *-*-gnu*
>   target (but not *-*-kfreebsd*-gnu | *-*-kopensolaris*-gnu).
> ---
>  gcc/config.gcc | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index b42ebc4e5be..a347c2cec7c 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -3538,7 +3538,9 @@ esac
>  case ${target} in
>  *-*-linux*android*|*-*-linux*uclibc*|*-*-linux*musl*)
>  ;;
> -*-*-linux*)
> +*-*-kfreebsd*-gnu | *-*-kopensolaris*-gnu)
> +;;
> +*-*-linux* | *-*-gnu*)
>   case ${target} in
>   aarch64*-* | arm*-* | i[34567]86-* | powerpc*-* | s390*-* | sparc*-* | 
> x86_64-*)
>   default_gnu_indirect_function=yes
> -- 
> 2.20.1
> 

-- 
Samuel
 bon comment on fait de l'investigation pour savoir qui est le vilain ?
 on débranche le routeur et on regarde qui s'affole
 -+- #ens-mim administre -+-

Re: [PATCH 2/3] cp/decl.c: Set DECL_INITIAL before attribute processing

[Jeff Law via Gcc-patches]

On 11/15/20 3:05 PM, Jozef Lawrynowicz wrote:
> Attribute handlers may want to examine DECL_INITIAL for a decl, to
> validate the attribute being applied. For C++, DECL_INITIAL is currently
> not set until cp_finish_decl, by which time attribute validation has
> already been performed.
>
> For msp430-elf this causes the "persistent" attribute to always be
> rejected for C++, since DECL_INITIAL must be non-null for the
> attribute to be applied to a decl.
>
> This patch ensures DECL_INITIAL is set for initialized decls early in
> start_decl, before attribute handlers run. This allows the
> initialization status of the decl to be examined by the handlers.
> DECL_INITIAL must be restored to it's initial value after attribute
> validation is performed, so as to not interfere with later decl
> processing.
>
> Successfully regtested for arm-none-eabi.
>
> Ok for trunk?
>
> 0002-cp-decl.c-Set-DECL_INITIAL-before-attribute-processi.patch
>
> From f87d3c3aa131cadeaa2f32c9a36609b4dd42db96 Mon Sep 17 00:00:00 2001
> From: Jozef Lawrynowicz 
> Date: Sun, 15 Nov 2020 21:43:00 +
> Subject: [PATCH 2/3] cp/decl.c: Set DECL_INITIAL before attribute processing
>
> Attribute handlers may want to examine DECL_INITIAL for a decl, to
> validate the attribute being applied. For C++, DECL_INITIAL is currently
> not set until cp_finish_decl, by which time attribute validation has
> already been performed.
>
> For msp430-elf this causes the "persistent" attribute to always be
> rejected for C++, since DECL_INITIAL must be non-null for the
> attribute to be applied to a decl.
>
> This patch ensures DECL_INITIAL is set for initialized decls early in
> start_decl, before attribute handlers run. This allows the
> initialization status of the decl to be examined by the handlers.
> DECL_INITIAL must be restored to it's initial value after attribute
> validation is performed, so as to not interfere with later decl
> processing.
>
> gcc/cp/ChangeLog:
>
>   * decl.c (start_decl): Set DECL_INITIAL for initialized decls
>   before attribute processing.
>
> gcc/testsuite/ChangeLog:
>
>   * gcc.target/msp430/data-attributes-2.c: Adjust test.
>   * g++.target/msp430/data-attributes.C: New test.
>   * g++.target/msp430/msp430.exp: New test.
Normally I'd leave this to the C++ maintainers, but it's simple enough
that I'm comfortable ACKing.  Even more so since my first thought after
reading the description was to shove an error_mark_node into
DECL_INITIAL for the duration of the attribute processing.

The other alternative would be to make the attribute processing only
conditionally look at DECL_INITIAL.

jeff

Re: [PATCH 1/3] Fix "noinit" attribute being ignored for -O0 and -fdata-sections

[Jeff Law via Gcc-patches]

On 11/15/20 3:03 PM, Jozef Lawrynowicz wrote:
> Variables with the "noinit" attribute are ignored at -O0 because they
> are treated like a regular bss variable and placed in the .bss section.
>
> With -fdata-sections they are ignored because they are not handled in
> resolve_unique_section.
>
> Successfully regtested for arm-none-eabi.
>
> Ok for trunk?
>
> 0001-Fix-noinit-attribute-being-ignored-for-O0-and-fdata-.patch
>
> From d501b36fc92f1506427836ded69997cc576beda4 Mon Sep 17 00:00:00 2001
> From: Jozef Lawrynowicz 
> Date: Sun, 15 Nov 2020 21:43:22 +
> Subject: [PATCH 1/3] Fix "noinit" attribute being ignored for -O0 and
>  -fdata-sections
>
> Variables with the "noinit" attribute are ignored at -O0 because they
> are treated like a regular bss variable and placed in the .bss section.
>
> With -fdata-sections they are ignored because they are not handled in
> resolve_unique_section.
>
> gcc/ChangeLog:
>
>   * tree.h (DECL_NOINIT_P): Define.
>   * varasm.c (DECL_NOINIT_P): Check DECL_NOINIT_P before using
>   unnamed bss/lcomm sections for bss_initializer variables.
>   (default_elf_select_section): Use DECL_NOINIT_P instead of
>   looking up attribute for .noinit section selection.
>   (default_unique_section): Check DECL_NOINIT_P for .noinit
>   section selection.
>
> gcc/testsuite/ChangeLog:
>
>   * gcc.c-torture/execute/noinit-attribute.c: Don't override
>   optimization options set by torture test harness.
>   * lib/target-supports.exp (check_effective_target_noinit): Adjust
>   comment formatting.
OK
jeff

Re: OpenACC 'kernels' testsuite failures

[David Edelsohn via Gcc-patches]

Hi, Thomas

I see

"during GIMPLE pass: omplower"

message for kernels-decompose-ice-2.c.  kernels-decompose-ice-1.c
explicitly prunes that output, but kernels-decompose-ice-2.c does not.
Is there a reason that the second testcase does not prune that output
or can we add it?

Thanks, David

On Tue, Nov 17, 2020 at 8:18 PM David Edelsohn  wrote:
>
> Hi, Thomas
>
> The patch resolves the "no such variable" error message, but I see
>
> "during GIMPLE pass: omplower"
>
> excess error message.
>
> I installed Tcl 8.6 with Expect 5.45.  This removes the "no such
> variable" error messages for C and C++ test cases, but they still
> occur for Fortran.
>
> I guess that the patch is necessary because there seems to be
> something else still behaving differently on AIX.
>
> Any insights?
>
> Thanks, David
>
> On Tue, Nov 17, 2020 at 10:03 AM David Edelsohn  wrote:
> >
> > Hi, Thomas
> >
> > The standard version of Tcl installed on AIX currently is Tcl 8.4.
> > I'll see if I can have a newer version on the side.
> >
> > The patch resolves the "no such variable" error message.  (Great!
> > Thanks!)  I now see:
> >
> > during GIMPLE pass: omplower
> >
> > as an Excess error.  Any idea where that comes from and why it doesn't
> > appear on other targets?  Does that need to be captured and ignored?
> >
> > Thanks, David
> >
> > On Mon, Nov 16, 2020 at 11:46 AM Thomas Schwinge
> >  wrote:
> > >
> > > Hi David!
> > >
> > > While you were writing your email, I've also been busy:
> > >
> > > On 2020-11-16T11:32:46-0500, David Edelsohn  wrote:
> > > > On Mon, Nov 16, 2020 at 9:16 AM Thomas Schwinge 
> > > >  wrote:
> > > >> On 2020-11-15T15:47:15-0500, David Edelsohn  wrote:
> > > >> > I am seeing a number of new failures on AIX related to the OpenACC
> > > >> > kernels patches.
> > > >> >
> > > >> > c-c++-common/goacc/kernels-decompose-1.c
> > > >> > c-c++-common/goacc/kernels-decompose-2.c
> > > >> > gfortran.dg/goacc/kernels-decompose-1.f95
> > > >> > gfortran.dg/goacc/kernels-decompose-2.f95
> > > >> > libgomp.oacc-c++/../libgomp.oacc-c-c++-common/kernels-decompose-1.c
> > > >> > libgomp.oacc-fortran/pr94358-1.f90
> > > >>
> > > >> I suppose what you're asking about is what appears in
> > > >>  reports as:
> > > >>
> > > >> ERROR: c-c++-common/goacc/kernels-decompose-1.c: can't read 
> > > >> "c_loop_i": no such variable for " dg-line 24 l_loop_i[incr c_loop_i] "
> > > >> UNRESOLVED: c-c++-common/goacc/kernels-decompose-1.c: can't read 
> > > >> "c_loop_i": no such variable for " dg-line 24 l_loop_i[incr c_loop_i] "
> > > >>
> > > >> Etc.
> > >
> > > In the mean time, I did remember that weeks ago, I had noticed this
> > > following "detail": on  we
> > > read that "Starting with the Tcl 8.5 release, the variable 'varName'
> > > passed to 'incr' may be unset, and in that case, it will be set to
> > > [...]".  Tcl 8.5 has been released in 2007.
> > >
> > > Per 'gcc/doc/install.texi' we require:
> > >
> > > @item DejaGnu 1.4.4
> > > @itemx Expect
> > > @itemx Tcl
> > >
> > > Necessary to run the GCC testsuite; [...]
> > >
> > > DejaGnu has been released in 2004 (so cannot have required Tcl 8.5
> > > released in 2007).
> > >
> > > >> However, per the reports posted there, these really only (!) appear to
> > > >> fail for your "Native configuration is powerpc-ibm-aix7.2.3.0" testing,
> > > >> strange.  Which versions of DejaGnu and Tcl are used?
> > > >
> > > > For my internal tester DejaGNU reports the following:
> > > >
> > > > Expect version is 5.42.1
> > > > Tcl version is 8.4
> > > > Framework version is 1.5.3
> > >
> > > There we go: you're on Tcl 8.4.  ;-D
> > >
> > > >> On  I see there are AIX
> > > >> systems gcc111, gcc119 -- maybe I'll have luck reproducing the issue
> > > >> there.
> > >
> > > On these, we've got:
> > >
> > > tschwinge@gcc111:[/home/tschwinge]/opt/freeware/bin/runtest --version
> > > WARNING: Couldn't find the global config file.
> > > Expect version is   5.45.4
> > > Tcl version is  8.6
> > > Framework version is1.4.4
> > >
> > > tschwinge@gcc119:[/home/tschwinge]/opt/freeware/bin/runtest --version
> > > WARNING: Couldn't find the global config file.
> > > Expect version is   5.44.1.15
> > > Tcl version is  8.5
> > > Framework version is1.5.3
> > >
> > > ..., so can't (easily) be used to reproduce the issue.  (... but it
> > > wouldn't be specific to AIX, anyway.)
> > >
> > > Before I spend time on building/verifying with Tcl 8.4: are you able to
> > > give the attached patch "[testsuite] Avoid Tcl 8.5-specific behavior" a
> > > try?
> > >
> > >
> > > Grüße
> > >  Thomas
> > >
> > >
> > > >> Admittedly, using Tcl code inside DejaGnu directives is not most 
> > > >> common,
> > > >> but it does make sense conceptually (at least to me), and reportedly 
> > > >> does
> > > >> work with a large number of DejaGnu/Tcl

Re: [PATCH 2/3] PowerPC: require IBM long double for pr70117.

[David Edelsohn via Gcc-patches]

On Sat, Nov 21, 2020 at 12:37 AM Michael Meissner
 wrote:
>
> PowerPC: require IBM long double for pr70117.
>
> Since the test is explicitly checking for IBM extended double, do not try to
> run it when long double is IEEE 128-bit.
>
> I have tested this patch and the first patch in the series on a little endian
> power9 system with 3 compilers that have the 3 different long double types
> configured.  I verified that this test is listed as unsupported if long double
> is not IBM 128-bit, and it passes if long double is IBM 128-bit.
>
> Can I check this patch into the master branch?  After an appropriate soak-in
> time, can I back port this patch to the previous open GCC trees?
>
> gcc/testsuite/
> 2020-11-21  Michael Meissner  
>
> PR target/70117
> * gcc.target/powerpc/pr70117.c: Only run the test if long double
> uses the IBM extended double format.
> ---
>  gcc/testsuite/gcc.target/powerpc/pr70117.c | 22 --
>  1 file changed, 4 insertions(+), 18 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr70117.c 
> b/gcc/testsuite/gcc.target/powerpc/pr70117.c
> index 3bbd2c595e0..2077d15afd4 100644
> --- a/gcc/testsuite/gcc.target/powerpc/pr70117.c
> +++ b/gcc/testsuite/gcc.target/powerpc/pr70117.c
> @@ -1,26 +1,12 @@
> -/* { dg-do run { target { powerpc*-*-linux* powerpc*-*-darwin* 
> powerpc*-*-aix* rs6000-*-* } } } */
> -/* { dg-options "-std=c99 -mlong-double-128 -O2" } */
> +/* { dg-require-effective-target ppc_long_double_ibm } */
> +/* { dg-options "-std=c99 -O2" } */

Mike,

You still need a

/* { dg-do run } */

line.  But without any target specified.

Segher may have other comments.

Thanks, David

Re: [PATCH] libstdc++: Add C++2a synchronization support

[Andreas Schwab]

In file included from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/shared_ptr_atomic.h:33,
 from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/memory:78,
 from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/stdc++.h:82,
 from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/extc++.h:32,
 from 
/daten/aranym/gcc/gcc-20201121/libstdc++-v3/testsuite/17_intro/headers/c++2020/all_attributes.cc:37:
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_base.h:
 In member function 'void std::atomic_flag::wait(bool, std::memory_order) 
const':
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_base.h:239:
 error: no matching function for call to '__atomic_wait(const 
__atomic_flag_data_type*, bool&, std::atomic_flag::wait(bool, 
std::memory_order) const::)'
In file included from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_base.h:41,
 from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/shared_ptr_atomic.h:33,
 from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/memory:78,
 from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/stdc++.h:82,
 from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/extc++.h:32,
 from 
/daten/aranym/gcc/gcc-20201121/libstdc++-v3/testsuite/17_intro/headers/c++2020/all_attributes.cc:37:
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_wait.h:265:
 note: candidate: 'template void 
std::__atomic_wait(const _Tp*, _Tp, _Pred)'
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_wait.h:265:
 note:   template argument deduction/substitution failed:
In file included from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/shared_ptr_atomic.h:33,
     from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/memory:78,
     from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/stdc++.h:82,
     from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/extc++.h:32,
     from 
/daten/aranym/gcc/gcc-20201121/libstdc++-v3/testsuite/17_intro/headers/c++2020/all_attributes.cc:37:
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_base.h:239:
 note:   deduced conflicting types for parameter '_Tp' ('unsigned char' and 
'bool')

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [PATCH] widening_mul: pattern recognize further forms of __builtin_add_overflow [PR95853]

[Richard Biener]

On November 21, 2020 8:21:42 AM GMT+01:00, Jakub Jelinek  
wrote:
>Hi!
>
>The following patch recognizes some further forms of additions with
>overflow
>checks as shown in the testcase, in particular where the unsigned
>addition is
>performed in a wider mode just to catch overflow with a >
>narrower_utype_max
>check.
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Ok. 

Thanks, 
Richard. 

>2020-11-21  Jakub Jelinek  
>
>   PR tree-optimization/95853
>   * tree-ssa-math-opts.c (uaddsub_overflow_check_p): Add maxval
>   argument, if non-NULL, instead look for r > maxval or r <= maxval
>   comparisons.
>   (match_uaddsub_overflow): Pattern recognize even other forms of
>   __builtin_add_overflow, in particular when addition is performed
>   in a wider type and result compared to maximum of the narrower
>   type.
>
>   * gcc.dg/pr95853.c: New test.
>
>--- gcc/tree-ssa-math-opts.c.jj2020-10-29 15:20:38.463180338 +0100
>+++ gcc/tree-ssa-math-opts.c   2020-11-20 18:44:06.340209014 +0100
>@@ -3457,7 +3457,7 @@ convert_mult_to_fma (gimple *mul_stmt, t
>and 0 otherwise.  */
> 
> static int
>-uaddsub_overflow_check_p (gimple *stmt, gimple *use_stmt)
>+uaddsub_overflow_check_p (gimple *stmt, gimple *use_stmt, tree maxval)
> {
>   enum tree_code ccode = ERROR_MARK;
>   tree crhs1 = NULL_TREE, crhs2 = NULL_TREE;
>@@ -3505,6 +3505,15 @@ uaddsub_overflow_check_p (gimple *stmt,
> {
> case GT_EXPR:
> case LE_EXPR:
>+  if (maxval)
>+  {
>+/* r = a + b; r > maxval or r <= maxval  */
>+if (crhs1 == lhs
>+&& TREE_CODE (crhs2) == INTEGER_CST
>+&& tree_int_cst_equal (crhs2, maxval))
>+  return ccode == GT_EXPR ? 1 : -1;
>+break;
>+  }
>   /* r = a - b; r > a or r <= a
>r = a + b; a > r or a <= r or b > r or b <= r.  */
>   if ((code == MINUS_EXPR && crhs1 == lhs && crhs2 == rhs1)
>@@ -3514,6 +3523,8 @@ uaddsub_overflow_check_p (gimple *stmt,
>   break;
> case LT_EXPR:
> case GE_EXPR:
>+  if (maxval)
>+  break;
>   /* r = a - b; a < r or a >= r
>r = a + b; r < a or r >= a or r < b or r >= b.  */
>   if ((code == MINUS_EXPR && crhs1 == rhs1 && crhs2 == lhs)
>@@ -3535,7 +3546,21 @@ uaddsub_overflow_check_p (gimple *stmt,
>x = REALPART_EXPR <_7>;
>_8 = IMAGPART_EXPR <_7>;
>if (_8)
>-   and similarly for addition.  */
>+   and similarly for addition.
>+
>+   Also recognize:
>+   yc = (type) y;
>+   zc = (type) z;
>+   x = yc + zc;
>+   if (x > max)
>+   where y and z have unsigned types with maximum max
>+   and there are other uses of x and all of those cast x
>+   back to that unsigned type and again replace it with
>+   _7 = ADD_OVERFLOW (y, z);
>+   _9 = REALPART_EXPR <_7>;
>+   _8 = IMAGPART_EXPR <_8>;
>+   if (_8)
>+   and replace (utype) x with _9.  */
> 
> static bool
> match_uaddsub_overflow (gimple_stmt_iterator *gsi, gimple *stmt,
>@@ -3548,14 +3573,16 @@ match_uaddsub_overflow (gimple_stmt_iter
>   bool use_seen = false;
>   bool ovf_use_seen = false;
>   gimple *use_stmt;
>+  gimple *add_stmt = NULL;
>+  bool add_first = false;
> 
>   gcc_checking_assert (code == PLUS_EXPR || code == MINUS_EXPR);
>   if (!INTEGRAL_TYPE_P (type)
>   || !TYPE_UNSIGNED (type)
>   || has_zero_uses (lhs)
>-  || has_single_use (lhs)
>-  || optab_handler (code == PLUS_EXPR ? uaddv4_optab :
>usubv4_optab,
>-  TYPE_MODE (type)) == CODE_FOR_nothing)
>+  || (code == MINUS_EXPR
>+&& optab_handler (usubv4_optab,
>+  TYPE_MODE (type)) == CODE_FOR_nothing))
> return false;
> 
>   FOR_EACH_IMM_USE_FAST (use_p, iter, lhs)
>@@ -3564,7 +3591,7 @@ match_uaddsub_overflow (gimple_stmt_iter
>   if (is_gimple_debug (use_stmt))
>   continue;
> 
>-  if (uaddsub_overflow_check_p (stmt, use_stmt))
>+  if (uaddsub_overflow_check_p (stmt, use_stmt, NULL_TREE))
>   ovf_use_seen = true;
>   else
>   use_seen = true;
>@@ -3572,21 +3599,205 @@ match_uaddsub_overflow (gimple_stmt_iter
>   break;
> }
> 
>-  if (!ovf_use_seen || !use_seen)
>-return false;
>-
>-  tree ctype = build_complex_type (type);
>   tree rhs1 = gimple_assign_rhs1 (stmt);
>   tree rhs2 = gimple_assign_rhs2 (stmt);
>+  tree maxval = NULL_TREE;
>+  if (!ovf_use_seen
>+  || !use_seen
>+  || (code == PLUS_EXPR
>+&& optab_handler (uaddv4_optab,
>+  TYPE_MODE (type)) == CODE_FOR_nothing))
>+{
>+  if (code != PLUS_EXPR)
>+  return false;
>+  if (TREE_CODE (rhs1) != SSA_NAME
>+|| !gimple_assign_cast_p (SSA_NAME_DEF_STMT (rhs1)))
>+  return false;
>+  rhs1 = gimple_assign_rhs1 (SSA_NAME_DEF_STMT (rhs1));
>+  tree type1 = TREE_TYPE (rhs1);
>+  if (!INTEGRAL_TYPE_P (type1)
>+|| !TYPE_UNSIGNED (type1)
>+|| TYPE_PRECISION (type1) >= TYPE_PRECISION (type)
>+|| (TYPE_PRECISION (type1)
>+ 

Re: [PATCH] warn for integer overflow in allocation calls (PR 96838)

[Andrew MacLeod via Gcc-patches]

On 11/21/20 12:07 AM, Jeff Law wrote:


On 11/9/20 9:00 AM, Martin Sebor wrote:

Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554000.html

Jeff, I don't expect to have the cycles to reimplement this patch
using the Ranger APIs before stage 1 closes.  I'm open to giving
it a try in stage 3 if it's still in scope for GCC 11.  Otherwise,
is this patch okay to commit?

So all we're going to get from the ranger is ranges of operands, right?
Meaning that we still need to either roll our own evaluator
(eval_size_vflow) or overload range_for_stmt with our own, which likely
looks like eval_size_vflow anyway, right?

My hope was to avoid the roll our own evaluator, but that doesn't look
like it's in the cards in the reasonably near future.


Is there a PR open showing what exactly you are looking for?
I'm using open PRs to track enhancement requests, and they will all feed 
back into the development roadmap  I am working on.





If my summary of the current state is correct, then I'd suggest we go
with the patch as-is.  If we want to override eval_size_vflow in the
future, we can still do that.  And if we want to replace the call to
determine_value_range with a ranger API, that seems like a fairly
straightforward change to make in gcc-12.



Jeff

Re: [PATCH v3 1/2] generate EH info for volatile asm statements (PR93981)

[J.W. Jagersma via Gcc-patches]

On 2020-11-19 06:55, Jeff Law wrote:
> 
> 
> On 11/15/20 6:04 AM, J.W. Jagersma via Gcc-patches wrote:
>> On 2020-11-13 09:41, Richard Biener wrote:
>>> On Thu, Mar 12, 2020 at 1:41 AM J.W. Jagersma via Gcc-patches
>>>  wrote:
 diff --git a/gcc/tree-eh.c b/gcc/tree-eh.c
 index 2a409dcaffe..58b16aa763a 100644
 --- a/gcc/tree-eh.c
 +++ b/gcc/tree-eh.c
 @@ -2077,6 +2077,8 @@ lower_eh_constructs_2 (struct leh_state *state, 
 gimple_stmt_iterator *gsi)
 DECL_GIMPLE_REG_P (tmp) = 1;
   gsi_insert_after (gsi, s, GSI_SAME_STMT);
 }
 +
 +record_throwing_stmt:
/* Look for things that can throw exceptions, and record them.  */
if (state->cur_region && stmt_could_throw_p (cfun, stmt))
 {
 @@ -2085,6 +2087,36 @@ lower_eh_constructs_2 (struct leh_state *state, 
 gimple_stmt_iterator *gsi)
 }
break;

 +case GIMPLE_ASM:
 +  {
 +   /* As above with GIMPLE_ASSIGN.  Change each register output 
 operand
 +  to a temporary and insert a new stmt to assign this to the 
 original
 +  operand.  */
 +   gasm *asm_stmt = as_a  (stmt);
 +   if (stmt_could_throw_p (cfun, stmt)
 +   && gimple_asm_noutputs (asm_stmt) > 0
 +   && gimple_stmt_may_fallthru (stmt))
 + {
 +   for (unsigned i = 0; i < gimple_asm_noutputs (asm_stmt); ++i)
 + {
 +   tree op = gimple_asm_output_op (asm_stmt, i);
 +   tree opval = TREE_VALUE (op);
 +   if (tree_could_throw_p (opval)
 +   || !is_gimple_reg_type (TREE_TYPE (opval))
 +   || !is_gimple_reg (get_base_address (opval)))
 + continue;
 +
 +   tree tmp = create_tmp_reg (TREE_TYPE (opval));
 +   gimple *s = gimple_build_assign (opval, tmp);
 +   gimple_set_location (s, gimple_location (stmt));
 +   gimple_set_block (s, gimple_block (stmt));
 +   TREE_VALUE (op) = tmp;
 +   gsi_insert_after (gsi, s, GSI_SAME_STMT);
 + }
 + }
 +  }
 +  goto record_throwing_stmt;
>>> Can you avoid the ugly goto by simply duplicating the common code please?
>>>
>>> Otherwise OK.
>>>
>>> As you say volatile asms are already considered throwing in some pieces of
>>> code so this is a step towards fulfilling that promise.
>>>
>>> Thanks,
>>> Richard.
>>>
>> Hi Richard,
>>
>> Thanks for your feedback.  I'll have to check again if I made any other
>> changes since this.  If not, and if there are no further objections, I will
>> resubmit this patch soon with this goto removed.
> Sounds good.  I'll keep an eye out for it.  I think we'll want to look
> at the doc text one more time too to make sure it matches the semantics
> we can actually guarantee.
> 
> Jeff

The only hard guarantees we can make with this patch as-is, is for "=r" and
"+r" operands (clobber), and "+m" (keep).  I suppose the test case for memory
operands should be altered to use '+' and the inverse should be tested too
(what happens when it doesn't throw).

For "=rm" and "=m" we could say that the output value is undefined on
exception, as the first depends on whether the operand is a GIMPLE register
type or not, and the latter may have earlier assignments optimized out.  And
that is valid too, as there may be cases (possibly most cases) where you
wouldn't care what the value is either before or after the asm, if an
exception is thrown.

Another idea I had is to introduce a new operand modifier, eg. '-', which
would signify that the output *must* be considered clobbered on exception,
and it would be an error if a copy is not possible.  Then the meaning of '+'
can be extended to say that the output must be valid regardless of whether an
exception occured or not.  Modifier '=' would mean the same as '+' with the
additional implication that it is okay to eliminate earlier assignments, so
that its value on the EH edge would be undefined.

[pushed] Darwin, libsanitizer : Support libsanitizer for x86_64-darwin20.

[Iain Sandoe]

Hi

The sanitizer is supported for at least x86_64 and Darwin20.

tested on a bunch of darwin platforms (including x86_64-darwin20) and
on x86_64-linux,
pushed to master
thanks
Iain

libsanitizer/ChangeLog:

* configure.tgt: Allow x86_64 Darwin2x.
---
 libsanitizer/configure.tgt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt
index 52503f1a880..ef9150209c4 100644
--- a/libsanitizer/configure.tgt
+++ b/libsanitizer/configure.tgt
@@ -62,7 +62,7 @@ case "${target}" in
TSAN_TARGET_DEPENDENT_OBJECTS=tsan_rtl_aarch64.lo
fi
;;
-  x86_64-*-darwin1[2-9]* | i?86-*-darwin1[2-9]*)
+  x86_64-*-darwin2* | x86_64-*-darwin1[2-9]* | i?86-*-darwin1[2-9]*)
TSAN_SUPPORTED=no
;;
   x86_64-*-solaris2.11* | i?86-*-solaris2.11*)
--
2.24.1

Re: [PATCH] Darwin, libgfortran : Do not use environ directly from the library.

[Iain Sandoe]

Hi Thomas,

Thomas Koenig via Fortran  wrote:


tested on a number of Darwin platforms old and new, and on
x86_64/powerpc64-linux,
OK for master?
… and backports to open branches?


One question...


+# ifdef __APPLE__
+#  include 
+#  define environ (*_NSGetEnviron ())


Is it guaranteed that crt_externs.h is present if __APPLE__
is defined?


__APPLE__ is defined by GCC when targetting macOS (actually by other  
compilers too,

although that’s probably not important for building libgfortran).

The header is present on all macOS systems supported by GCC (and at least  
two revisions

prior to the earliest that currently builds GCC open branches).

Of course, a user with -D on the command line can define it .. but then  
will get a build
error - which is fine __APPLE__ is in the implementation namespace, the  
user gets what

they deserve ;)

We could be paranoid and write #if defined (__APPLE__) &&  
__has_include()

but that seems over the top here.


If that's the case, OK for master and backports.


applied to master,
will deal with the backports along with other Darwin ones.
thanks
Iain

*ping* [patch, fortran] Correct fndecls for some library functions

[Thomas Koenig via Gcc-patches]

this patch makes sure that we pass the correct fn decls for
some of our library functions. cshift and others still remain
to be implemented.

This is a step in our voyage to stop lying to the middle end :-)

Regression-tested. OK for trunk?


Ping?

(I am not 100% sure this mail ever made it to the mailing list,
but it is in the archive at

https://gcc.gnu.org/pipermail/fortran/2020-November/055303.html

).

Re: [PATCH] Darwin, libgfortran : Do not use environ directly from the library.

[Thomas Koenig via Gcc-patches]

Hi Iain,


tested on a number of Darwin platforms old and new, and on
x86_64/powerpc64-linux,

OK for master?
… and backports to open branches?


One question...


+# ifdef __APPLE__
+#  include 
+#  define environ (*_NSGetEnviron ())


Is it guaranteed that crt_externs.h is present if __APPLE__
is defined?

If that's the case, OK for master and backports.

Best regards

Thomas

Re: [PATCH] unshare expressions in attribute arguments

[Jakub Jelinek via Gcc-patches]

On Fri, Nov 20, 2020 at 03:44:01PM -0700, Martin Sebor via Gcc-patches wrote:
> > So that likely means you are doing it too early.
> 
> The bounds are added to attribute "arg spec" for each param in
> push_parm_decl.  I think that's both as early and (except maybe
> in function definitions) as late as can be.  After that point,
> the association between a VLA parameter and its most significant
> bound is lost.

If the most significant bound is lost, why don't you save in the attribute
early only the most significant bound before it is lost and for the other
bounds just refer to the SAVE_EXPRs in the FUNCTION_TYPE's TYPE_ARG_TYPES
ARRAY_TYPEs?  And for function definitions, even the outermost bounds
aren't really lost, the FE for
int bar ();
int baz ();

int
foo (int n, int x[bar () + 4][baz () + 2])
{
  return sizeof (x[0]);
}
emits all the side-effects, though not sure if it creates a SAVE_EXPR for
that.  But for the definitions you really want to use the same SAVE_EXPR
as the function evaluates.

Jakub