[PATCH, rs6000] Lower vec_perm vectorization cost for P8/P9

Hi, Recently we are revisiting vectorization cost setting in rs6000_builtin_vectorization_cost, and found the current cost of vec_perm on VSX looks overpriced for Power8 and Power9. The high cost was set for Power7 single VSU pipe, but Power8 and Power9 have supported more VSX units, the

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

Hi Segher, on 2019/9/28 上午12:12, Segher Boessenkool wrote: > On Fri, Sep 27, 2019 at 04:52:30PM +0800, Kewen.Lin wrote: >>> (Maybe one of the gen* tools complains any_fix needs a mode? :QI will do >>> if so, or :P if you like that better). >> >> I didn't encounter any errors, it sounds it's

[RFH][libgcc] fp-bit bit ordering (PR 78804)

Hi, I've been dragging this patch along with me for a while. At the moment, I don't have the resources to fully test it as requested by Ian in the PR discussion. So I would like to ask for general comments on this one and hope that folks with bigger automated test setups can run the patch

Re: [PATCH] PR fortran/91802 -- rank+corank must be less than 16

On Sat, Sep 28, 2019 at 03:06:13PM -0700, Steve Kargl wrote: > On Sat, Sep 28, 2019 at 01:13:42PM -0700, Jerry DeLisle wrote: > > On 9/28/19 10:11 AM, Steve Kargl wrote: > > > Committed as r276254. > > > > > > > I am getting this: > > > > gfc -c -fcoarray=single pr91802.f90 > > f951: internal

Re: [PATCH] PR fortran/91802 -- rank+corank must be less than 16

On Sat, Sep 28, 2019 at 01:13:42PM -0700, Jerry DeLisle wrote: > On 9/28/19 10:11 AM, Steve Kargl wrote: > > Committed as r276254. > > > > I am getting this: > > gfc -c -fcoarray=single pr91802.f90 > f951: internal compiler error: free_expr0(): Bad expr type > 0x809fc9 gfc_report_diagnostic >

[PATCH] Fix algo constexpr tests in Debug mode

Here is what I just commited. I try to use the asm trick in the _GLIBCXX_DEBUG_VERIFY_COND_AT but didn't notice any enhancement. So for now I kept my solution to just have a non-constexpr call compiler error. I fix my patch to use __builtin_is_constant_evaluated rather than

Re: [PATCH] Automatics in equivalence statements

On Aug 14 2019, Mark Eggleston wrote: >     * gfortran.dg/auto_in_equiv_3.f90: New test. This test fails everywhere. 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, libgfortran] Bug 91593 - Implicit enum conversions in libgfortran/io/transfer.c

On Fri, Sep 27, 2019 at 8:14 PM Jerry DeLisle wrote: > > On 9/23/19 8:12 PM, Jerry DeLisle wrote: > > On 9/23/19 8:52 AM, Bernhard Reutner-Fischer wrote: > >> On 22 September 2019 22:51:46 CEST, Jerry DeLisle > >> wrote: > >>> Hi all, > >>> > >>> The attached patch eliminates several warnings

Re: [PATCH] PR fortran/91802 -- rank+corank must be less than 16

On 9/28/19 10:11 AM, Steve Kargl wrote: Committed as r276254. I am getting this: gfc -c -fcoarray=single pr91802.f90 f951: internal compiler error: free_expr0(): Bad expr type 0x809fc9 gfc_report_diagnostic ../../trunk/gcc/fortran/error.c:776 0x80b62a gfc_internal_error(char const*,

[Darwin, PPC, Mode Iterators 4/n, committed] Update macho_high.

(since Segher asked, ’n’ is approximately 8 - some of the patterns will be harder to convert) Drop the expander for macho_high and use a mode iterator on the define_insn for @macho_high_ instead. as usual, tested on powerpc-darwin9 and powerpc64-linux-gnu applied to mainline thanks Iain

[PATCH] PR fortran/91714 -- Mangled type-spec

The attached patch issues errors for a few mangled type-specs. It has been regression tested on x86_64-*-freebsd. OK to commit? 2019-09-28 Steven G. Kargl PR fortran/91714 * decl.c (gfc_match_decl_type_spec): Issue errors for a few mangled types. 2019-09-28 Steven

Re: [PATCH] PR fortran/91802 -- rank+corank must be less than 16

Committed as r276254. -- steve On Tue, Sep 24, 2019 at 03:49:06PM -0700, Steve Kargl wrote: > The attached patch has been tested on x86_64-*-freebsd. OK to commit? > > 2019-09-24 Steven G. Kargl > > PR fortran/91802 > * decl.c (attr_decl1): Check if rank+corank > 15. > >

Re: [Patch, fortran] PR91726 - [7/8/9/10 Regression] ICE in gfc_conv_array_ref, at fortran/trans-array.c:3612

On Sun, Sep 22, 2019 at 04:28:49PM +0100, Paul Richard Thomas wrote: > Fixing the original problem in the module took a few minutes. Making > the module do something useful took rather longer! The testcase in the > patch compiles with 6-branch but segfaults in runtime. > > Bootstrapped and

Re: [patch, fortran] PR 84487

On Wed, Sep 25, 2019 at 10:24:51PM +0200, Thomas Koenig wrote: > > this patch makes sure that the __def_init variables, which have been > generated for normal allocatable arrays for quite some time, do not fill > up huge amounts of space in the object files with zeros. This is done by > not

Re: [PATCH, Fortran] Optionally suppress no-automatic overwrites recursive warning - for approval

On Thu, Sep 26, 2019 at 09:45:28AM +0100, Mark Eggleston wrote: > Original thread starts here > https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01185.html > > OK to commit? > I'm not a big fan of option proliferation. If you don't want to see warns just use -w. Of course, this is just MHO.

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

For some reason, presumably historical, the `install-gnatlib' target for the default multilib is invoked twice, once via the `ada.install-common' target in `gcc/ada/gcc-interface/Make-lang.in' invoked from gcc/ and again via the `install-libada' target in libada/. Apart from doing the same

Re: [patch, libgfortran] Bug 91593 - Implicit enum conversions in libgfortran/io/transfer.c

On Fri, Sep 27, 2019 at 10:14:34AM -0700, Jerry DeLisle wrote: > > If no objections, I will commit the attached updated patch > with a new ChangeLog. No objection. -- Steve

Re: [PATCH] PR fortran/91864 -- inquiry parameter is a constant

Committed as r276253. -- steve On Tue, Sep 24, 2019 at 03:07:31PM -0700, Steve Kargl wrote: > The attached patch has been tested on x86_64-*-freebsd. OK to commit? > > 2019-09-24 Steven G. Kargl > > PR fortran/91864 > * gcc/fortran/io.c (match_io_element): An inquiry parameter

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

On Sat, Sep 28, 2019 at 7:33 AM Marek Polacek wrote: > On Fri, Sep 27, 2019 at 10:08:49PM -0400, Jason Merrill wrote: > > On 9/26/19 9:45 PM, Marek Polacek wrote: > > > Jason, you remarked that adding a ck_qual under the ck_ref_bind might be > > > too much trouble, but it seems it's actually

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

On Fri, Sep 27, 2019 at 10:08:49PM -0400, Jason Merrill wrote: > On 9/26/19 9:45 PM, Marek Polacek wrote: > > Jason, you remarked that adding a ck_qual under the ck_ref_bind might be > > too much trouble, but it seems it's actually fairly simple. The comments > > hopefully explain my thinking.

[ping][PR target/85401] initialize the move cost table before using it

re-posting, now CC'ing vmakarov who might be the right person to ping about issues in this file. apologies for the noise if I'm wrong. -- This seems to be the way the rest of ira-color.c does it. I hope it's OK. It does fix the segfault. 2019-09-10 Maya Rashish PR target/85401

Re: [PATCH v2] libitm: sh: avoid absolute relocation in shared library (PR 86712)

On Sat, 2018-08-04 at 18:00 +0900, Oleg Endo wrote: > On Fri, 2018-08-03 at 14:54 -0600, Jeff Law wrote: > > On 07/28/2018 07:04 AM, slyfox.inbox.ru via gcc-patches wrote: > > > > > > From: Sergei Trofimovich > > > > > > Cc: Andreas Schwab > > > Cc: Torvald Riegel > > > Cc: Alexandre Oliva >

[SH][committed] Fix PR 86805

Hi, This also sets TARGET_HAVE_SPECULATION_SAFE_VALUE to speculation_safe_value_not_needed for SH. Tested with "make all-gcc". Committed on trunk as r276244 and on GCC 9 as r276245. Cheers, Oleg gcc/ChangeLog PR target/86805 * config/sh/sh.c

[PATCH 02/11] libstdc++ testsuite: Add timed_mutex::try_lock_until test

I was unable to find an existing tests for timed_mutex::try_lock_until and recursive_timed_mutex::try_lock_until timing out. It would have been easier to add a single templated test, but since these classes are tested in separate directories I've created two separate tests. *

[PATCH 10/11] libstdc++ timed_mutex: Ensure that try_lock_for waits for long enough

The user-defined clock used with shared_mutex::try_lock_for and shared_mutex::try_lock_shared_for may have higher precision than __clock_t. We may need to round the duration up to ensure that the timeout is long enough. (See __timed_mutex_impl::_M_try_lock_for) * include/std/shared_mutex:

[PATCH 08/11] libstdc++ testsuite: Also test shared_timed_mutex with steady_clock

* testsuite/30_threads/shared_timed_mutex/try_lock/3.cc: Convert existing test to templated function so that it can be called with both system_clock and steady_clock. --- libstdc++-v3/testsuite/30_threads/shared_timed_mutex/try_lock/3.cc | 17 - 1 file

[PATCH 06/11] libstdc++ testsuite: Move slow_clock to its own header

Move slow_clock test class into a header file so that it can be used by other tests in the future. * testsuite/util/slow_clock.h: New file. Move implementation of slow_clock test class. * testsuite/30_threads/condition_variable/members/2.cc: Include slow_clock

[PATCH 11/11] shared_mutex: Fix try_lock_until and try_lock_shared_until on arbitrary clock

This is the equivalent to PR libstdc++/91906, but for shared_mutex. A non-standard clock may tick more slowly than std::chrono::steady_clock. This means that we risk returning false early when the specified timeout may not have expired. This can be avoided by looping until the timeout time as

[PATCH 04/11] libstdc++ testsuite: Also test unique_lock::try_lock_until with steady_clock

* testsuite/30_threads/unique_lock/locking/4.cc: Template test functions so they can be used to test both steady_clock and system_clock. --- libstdc++-v3/testsuite/30_threads/unique_lock/locking/4.cc | 12 +-- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git

[PATCH 01/11] libstdc++ testsuite: Check return value from timed_mutex::try_lock_until

* testsuite/30_threads/unique_lock/locking/4.cc: Wrap call to timed_mutex::try_lock_until in VERIFY macro to check its return value. --- libstdc++-v3/testsuite/30_threads/unique_lock/locking/4.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 03/11] libstdc++ testsuite: Also test timed_mutex with steady_clock

* testsuite/30_threads/timed_mutex/try_lock_until/57641.cc: Template test functions and use them to test both steady_clock and system_clock. --- libstdc++-v3/testsuite/30_threads/timed_mutex/try_lock_until/57641.cc | 18 +- 1 file changed, 13 insertions(+), 5

[PATCH 05/11] PR libstdc++/78237 Add full steady_clock support to timed_mutex

The pthread_mutex_clocklock function is available in glibc since the 2.30 release. If this function is available in the C library it can be used to fix PR libstdc++/78237 by supporting steady_clock properly with timed_mutex. This means that code using timed_mutex::try_lock_for or

[PATCH 09/11] libstdc++ shared_mutex: Add full steady_clock support to shared_timed_mutex

The pthread_rwlock_clockrdlock and pthread_rwlock_clockwrlock functions were added to glibc in v2.30. They have also been added to Android Bionic. If these functions are available in the C library then they can be used to implement shared_timed_mutex::try_lock_until,

[PATCH 07/11] PR libstdc++/91906 Fix timed_mutex::try_lock_until on arbitrary clock

A non-standard clock may tick more slowly than std::chrono::steady_clock. This means that we risk returning false early when the specified timeout may not have expired. This can be avoided by looping until the timeout time as reported by the non-standard clock has been reached. Unfortunately, we

[PATCH 00/11] timed_mutex, shared_timed_mutex: Add full steady clock support

glibc v2.30 added the pthread_mutex_clocklock, pthread_rwlock_clockrdlock and pthread_rwlock_clockwrlock functions. These accept CLOCK_MONOTONIC, so they can be used to implement proper steady_clock support in timed_mutex, recursive_timed_mutex and shared_timed_mutex that is immune to the system

[SH][committed] Fix PR 80672

Hi, The attached patch fixes PR 80672. Tested by building the compiler with "make all-gcc" and manually invoking it and checking that the option is parsed as expected. Committed to trunk as r276240, GCC 9 as r276241, GCC 8 as r276242, GCC 7 as r276243. Cheers, Oleg gcc/ChangeLog PR

Re: [committed] [PR target/85993] Remove dead conditional in SH target code

On Sun, 2018-07-15 at 14:30 -0600, Jeff Law wrote: > > Per Oleg's comment in the PR, the second block is dead and should be > removed... > > Committing to the trunk. While I'm confident this won't change > anything, my tester will bootstrap sh4 & sh4eb overnight for > additional >

Re: [PR 91853] Prevent IPA-SRA ICEs on type-mismatched calls

On September 28, 2019 12:24:40 AM GMT+02:00, Martin Jambor wrote: >Hi, > >On Thu, Sep 26 2019, Richard Biener wrote: >> On Wed, 25 Sep 2019, Martin Jambor wrote: >> >>> Hi, >>> >>> PR 91853 and its duplicate PR 91894 show that IPA-SRA can stumble >when >>> presented with code with mismatched

Re: Fix endian issue in pr91656 testcases

On September 28, 2019 8:34:59 AM GMT+02:00, Alan Modra wrote: >Tested on powerpc64le-linux and powerpc64-linux. OK? Ok. Thanks, Richard. >pr91656-3.c didn't really need to be changed since popcount doesn't >care which bits are set, but I figured it was better to make the test >set the low

Fix endian issue in pr91656 testcases

Tested on powerpc64le-linux and powerpc64-linux. OK? pr91656-3.c didn't really need to be changed since popcount doesn't care which bits are set, but I figured it was better to make the test set the low 16 bits of the 64-bit value in both big and litte endian. PR testsuite/91676