Re: [PATCH] Support multi-versioning on self-recursive function (ipa/92133)

Hi, On 2019/10/17 16:23, Feng Xue OS wrote: > IPA does not allow constant propagation on parameter that is used to control > function recursion. > > recur_fn (i) > { >if ( !terminate_recursion (i)) > { >... >recur_fn (i + 1); >... > } >... > } > > This

Re: [SVE] PR91272

On Tue, 22 Oct 2019 at 13:12, Richard Sandiford wrote: > > Prathamesh Kulkarni writes: > > diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c > > index acdd90784dc..dfd33b142ed 100644 > > --- a/gcc/tree-vect-stmts.c > > +++ b/gcc/tree-vect-stmts.c > > @@ -10016,25 +10016,26 @@

[C++ PATCH] 'std' identifier not needed

There's no need to retain "std" identifier as a global tree -- we can simply use {push,/pop}_ nested_namespace on the std_node we have there. Also simplify the in-std-namespace predicate by checking against std::node. applying to trunk. nathan -- Nathan Sidwell 2019-10-23 Nathan Sidwell

[Committed] Update Fortran expression dumper for BT_BOZ

The attached and committed patch updates gfortran expression dumper to do something sensible with a gfc_expr that is a BT_BOZ basic type. That is, for program a real :: x = real(b'10101') real :: y = real(o'') real :: z = real(z'abcd') print *, x, y, z end program a if one is

[C++ PATCH] Fix a C++17/20 regression on indirect function calls (PR c++/92201)

Hi! For middle-end pointer conversions are useless, which means the gimplifier can change the type of the value being gimplified. gimplify_call_expr is careful about this and remembers the fnptrtype early before gimplification and else /* Remember the original function type. */

Re: RFC/A: Add a targetm.vectorize.related_mode hook

On Wed, Oct 23, 2019 at 4:51 AM Richard Sandiford wrote: > > Richard Biener writes: > > On Wed, Oct 23, 2019 at 1:00 PM Richard Sandiford > > wrote: > >> > >> This patch is the first of a series that tries to remove two > >> assumptions: > >> > >> (1) that all vectors involved in vectorisation

Re: [PATCHv2] Change the library search path when using --with-advance-toolchain

On 10/5/19 12:20 PM, Segher Boessenkool wrote: > On Fri, Oct 04, 2019 at 06:31:34PM -0300, Tulio Magno Quites Machado Filho > wrote: >> Remove all -L directories from LINK_OS_EXTRA_SPEC32 and >> LINK_OS_EXTRA_SPEC64 so that user directories specified at >> build time have higher preference over

PR92163

Hi, The attached patch tries to fix PR92163 by calling gimple_purge_dead_eh_edges from ifcvt_local_dce if we need eh cleanup. Does it look OK ? Thanks, Prathamesh 2019-10-24 Prathamesh Kulkarni PR tree-optimization/92163 * tree-if-conv.c (ifcvt_local_dce): Call

Re: [PATCH] V6, #1 of 17: Use ADJUST_INSN_LENGTH for prefixed instructions

On Wed, Oct 23, 2019 at 05:00:58PM -0400, Michael Meissner wrote: > On Tue, Oct 22, 2019 at 05:27:19PM -0500, Segher Boessenkool wrote: > > On Wed, Oct 16, 2019 at 09:35:33AM -0400, Michael Meissner wrote: > > > - int n = get_attr_length (insn) / 4; > > > + /* If the insn tells us how many insns

Re: RFC/A: Add a targetm.vectorize.related_mode hook

On Wed, Oct 23, 2019 at 4:16 AM Richard Biener wrote: > Note I delayed thinking about relaxing the single-vector-size > constraint in the vectorizer until after we're SLP only because > that looked more easily done there. I also remember patches > relaxing this a bit from RISCV folks. Probably

Re: [PATCH] V6, #1 of 17: Use ADJUST_INSN_LENGTH for prefixed instructions

On Tue, Oct 22, 2019 at 05:27:19PM -0500, Segher Boessenkool wrote: > Hi! > > On Wed, Oct 16, 2019 at 09:35:33AM -0400, Michael Meissner wrote: > > This patch uses the target hook ADJUST_INSN_LENGTH to change the length of > > instructions that contain prefixed memory/add instructions. > > That

[C++ PATCH] Implement P1286R2, Contra CWG1778

The C++11 requirement that an explicit exception-specification on a defaulted function match the implicit one was found to be problematic for std::atomic. This paper, adopted in February, simply removes that requirement: if an explicitly defaulted function has a different exception-specification,

Re: [Patch][Fortran] OpenACC – permit common blocks in some clauses

Hi Thomas, Updated version attached. Changes: * Use "true" instead of "openacc" for the OpenACC-only "copy()" clause (as not shared w/ OpenMP) * Add some documentation to gimplify.c * Use GOVD_FIRSTPRIVATE also for "kernel" The patch survived bootstrapping + regtesting on my laptop (no

Re: Order symbols before section copying in the lto streamer

> Hi, > this patch orders symbols where we copy sections to match the order > of files in the command line. This optimizes streaming process since we > are not opening and closing files randomly and also we read them more > sequentially. This saves some kernel time though I think more can be >

Re: [PATCH] Add support for C++2a stop_token

Thomas Rodgers writes: Let's try this again.From 23e1c9402cc15666d099fd61b58a0019181a9115 Mon Sep 17 00:00:00 2001 From: Thomas Rodgers Date: Tue, 22 Oct 2019 17:53:00 -0700 Subject: [PATCH] Add support for C++2a stop_token * include/Makefile.am: Add header. * include/Makefile.in:

[PATCH] Add C++20 jthread type to (2nd attempt)

From 56b78956a003b91e538cd5c680d614fdaee9c9eb Mon Sep 17 00:00:00 2001 From: Thomas Rodgers Date: Wed, 23 Oct 2019 12:32:31 -0700 Subject: [PATCH] Add C++20 jthread type to --- libstdc++-v3/ChangeLog| 8 + libstdc++-v3/include/std/stop_token | 14 ++

[PATCH] Add C++20 jthread type to --text follows this line-<#part type="text/x-patch" filename="/home/remote/trodgers/src/oss/gcc/jt/0001-Add-C-20-jthread-type-to-thread.patch" disposition=at

[PATCH] Make std::invoke usable in constant expressions

* include/std/functional (invoke): Add constexpr for C++20. * include/std/version (__cpp_lib_constexpr_invoke): Define. * testsuite/20_util/function_objects/invoke/constexpr.cc: New test. This is an easy one, because I already made std::__invoke constexpr, so all that's

[PATCH] PR c++/91369 Implement P0784R7 changes to allocation and construction

This patch is the first part of library support for constexpr std::vector and std::string. This only includes the changes to std::allocator, std::allocator_traits, std::construct_at, std::destroy_at, std::destroy and std::destroy_n. std::allocator::allocate and std::allocator::deallocate need to

Re: Make ipa-reference bitmaps dense

> On Wed, Oct 23, 2019 at 08:20:12PM +0200, Jan Hubicka wrote: > > Hi, > > this is variant of patch I comitted. It additionally register variable > > removal hook to be sure that we do not mix up the static variable for > > some other decl allocated later. > > > > Bootstrapped/regtested x86_64 >

Re: Make ipa-reference bitmaps dense

On Wed, Oct 23, 2019 at 08:20:12PM +0200, Jan Hubicka wrote: > Hi, > this is variant of patch I comitted. It additionally register variable > removal hook to be sure that we do not mix up the static variable for > some other decl allocated later. > > Bootstrapped/regtested x86_64 This doesn't

Re: Make ipa-reference bitmaps dense

Hi, this is variant of patch I comitted. It additionally register variable removal hook to be sure that we do not mix up the static variable for some other decl allocated later. Bootstrapped/regtested x86_64 Honza 2019-10-13 Jan Hubicka * ipa-reference.h (ipa_reference_var_uid):

Re: PING*2 : Fwd: [PATCH][gcov-profile/91971]Profile directory concatenated with object file path

Thank you! Just committed the change at: https://gcc.gnu.org/viewcvs/gcc?view=revision=277344 Qing > On Oct 23, 2019, at 5:15 AM, Martin Liška wrote: > > On 10/21/19 5:32 PM, Qing Zhao wrote: >> Please let me know whether this patch is

[PATCH] PR fortran/92178 -- Re-order argument deallocation

The attached patch has been tested on x86_64-*-freebsd. OK to commit? 2019-10-23 Steven G. Kargl PR fortran/92178 * trans-expr.c (gfc_conv_procedure_call): Evaluate args and then deallocate actual args assocated with intent(out) dummies. 2019-10-23 Steven G. Kargl

C++ PATCH for c++/91548 - fix detecting modifying const objects for ARRAY_REF

This fixes a bogus "modifying a const object" error for an array that actually isn't declared const. The problem was how I handled ARRAY_REFs here; we shouldn't look at the ARRAY_REF itself, but at the array its accessing. Bootstrapped/regtested on x86_64-linux, ok for trunk? 2019-10-23 Marek

Re: Pass the data vector mode to get_mask_mode

On 23 October 2019 13:16:19 CEST, Richard Sandiford wrote: >+++ gcc/config/gcn/gcn.c 2019-10-23 12:13:54.091122156 +0100 >@@ -3786,8 +3786,7 @@ gcn_expand_builtin (tree exp, rtx target >a vector. */ > > opt_machine_mode >-gcn_vectorize_get_mask_mode (poly_uint64 ARG_UNUSED (nunits),

[COMMITTED][MSP430] Fix incorrect determination of hardware multiply support

Some areas of the MSP430 backend modify code generation based on whether the target device has hardware multiply support. However comparisons of the form "msp430_hwmult_type != MSP430_HWMULT_NONE" are invalid, since MSP430_HWMULT_AUTO might be set (to infer hwmult support from the MCU specified

[COMMITTED][MSP430] Cleanup code in hardware multiply library

The libgcc hardware multiply library for MSP430 uses its own naming scheme, which has some similarities, but is still different, to how TI names the registers across the documentation for all its MSP430 devices. Furthermore, 32-bit and f5series specific hwmult registers have their addresses

Re: [PATCH] Refactor rust-demangle to be independent of C++ demangling.

On Wed, Oct 23, 2019 at 07:28:48PM +0200, Jakub Jelinek wrote: > On Wed, Oct 23, 2019 at 12:19:10PM -0500, Segher Boessenkool wrote: > > I of course know that for e.g. strcmp or strlen we need to be careful of > > page crossings; but this is strncmp, which has a size argument saying the > > size

[PATCH][MSP430] Use hardware multiply routine to perform HImode widening multiplication (mulhisi3)

For MSP430 in some configurations, GCC will generate code for mulhisi3 by inserting instructions to widen each 16-bit operand before calling a library routine for mulsi3. However, there exists a hardware multiply routine to perform this widening multiplication, but it is only made use of at -O3

Re: [PATCH] Refactor rust-demangle to be independent of C++ demangling.

On Wed, Oct 23, 2019 at 12:19:10PM -0500, Segher Boessenkool wrote: > I of course know that for e.g. strcmp or strlen we need to be careful of > page crossings; but this is strncmp, which has a size argument saying the > size of the array objects of its arguments!

Re: [PATCH] Refactor rust-demangle to be independent of C++ demangling.

On Wed, Oct 23, 2019 at 06:46:14PM +0200, Jakub Jelinek wrote: > On Wed, Oct 23, 2019 at 11:37:26AM -0500, Segher Boessenkool wrote: > > On Wed, Oct 23, 2019 at 07:22:47PM +0300, Alexander Monakov wrote: > > > On Wed, 23 Oct 2019, Eduard-Mihai Burtescu wrote: > > > > @@ -384,6 +384,14 @@

Re: [PATCH] Refactor rust-demangle to be independent of C++ demangling.

On Wed, Oct 23, 2019 at 11:37:26AM -0500, Segher Boessenkool wrote: > On Wed, Oct 23, 2019 at 07:22:47PM +0300, Alexander Monakov wrote: > > On Wed, 23 Oct 2019, Eduard-Mihai Burtescu wrote: > > > @@ -384,6 +384,14 @@ rust_demangle_callback (const char *mangled, int > > > options, > > >

Re:lemire.me:Increase the number of visitors

Dear lemire.me, Is your website truly effective in reaching its audience? Which is why I propose to SEO optimize your website lemire.me, so it could capture the attention of its customers.. in its targeted geography and demography. My research on lemire.me suggests that though the website

Re: [PATCH] Refactor rust-demangle to be independent of C++ demangling.

On Wed, Oct 23, 2019 at 07:22:47PM +0300, Alexander Monakov wrote: > On Wed, 23 Oct 2019, Eduard-Mihai Burtescu wrote: > > @@ -384,6 +384,14 @@ rust_demangle_callback (const char *mangled, int > > options, > > return 0; > >rdm.sym_len--; > > > > + /* Legacy Rust symbols

Re: [PATCH] Refactor rust-demangle to be independent of C++ demangling.

On Wed, 23 Oct 2019, Eduard-Mihai Burtescu wrote: > @@ -384,6 +384,14 @@ rust_demangle_callback (const char *mangled, int options, > return 0; >rdm.sym_len--; > > + /* Legacy Rust symbols also always end with a path segment > + that encodes a 16 hex digit hash,

Re: Reduce inline-heuristics-hint-percent (to fix exchange2 regression)

> On 10/23/19 9:07 AM, Jan Hubicka wrote: > > Hi, > > this patch reduces inline-heuristics-hint-percent so inliner behaves > > more similarly to what it did before I introduced this param. > > > > Bootstrapped/regtested x86_64-linux, comitted. > > I plan to do more tuning on this parameter, but

[PATCH] Replace C++14 feature used in C++11 test

* testsuite/20_util/bind/91371.cc: Fix test to compile as C++11. Tested powerpvc64le-linux, committed to trunk. commit d51d04301d30e199c53a705777d263b3f596e86f Author: Jonathan Wakely Date: Wed Oct 23 16:49:55 2019 +0100 Replace C++14 feature used in C++11 test

[PATCH] Qualify type names in

* include/ext/throw_allocator.h (throw_allocator_base): Qualify size_t and ptrdiff_t. Tested powerpc64le-linux, committed to trunk. commit a1dcc5b28035e241ac766c7699559f06b88f786c Author: Jonathan Wakely Date: Wed Oct 23 15:23:11 2019 +0100 Qualify type names in

[PATCH] Adjust pb_ds extensions to use allocator_traits

This fixes the PDBS containers to support C++11-style allocators. I consider the hours spent doing this completely wasted, but it was necessary to keep the testsuite clean. I still want this code to go away. Tested powerpc64le-linux, committed to trunk. These changes are largely useless,

Re: [PATCH] Remove redundant std::allocator members for C++20

On 22/10/19 23:09 +0100, Jonathan Wakely wrote: On 22/10/19 22:40 +0100, Jonathan Wakely wrote: C++20 removes a number of std::allocator members that have correct defaults provided by std::allocator_traits, so aren't needed. Several extensions including __gnu_cxx::hash_map and tr1 containers

Re: Fix PR90796

Hello, On Tue, 22 Oct 2019, Rainer Orth wrote: > > testsuite/ > > * gcc.dg/unroll-and-jam.c: Add three invalid and one valid case. > > this testcase now FAILs on 32-bit targets (seen on i386-pc-solaris2.11 > and sparc-sun-solaris2.11, also reports for i686-pc-linux-gnu and >

Re: [PATCH] Fix algo constexpr tests in Debug mode

On 28/09/19 23:12 +0200, François Dumont wrote: 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

Re: Reduce inline-heuristics-hint-percent (to fix exchange2 regression)

On 10/23/19 9:07 AM, Jan Hubicka wrote: > Hi, > this patch reduces inline-heuristics-hint-percent so inliner behaves > more similarly to what it did before I introduced this param. > > Bootstrapped/regtested x86_64-linux, comitted. > I plan to do more tuning on this parameter, but the value of

Reduce inline-heuristics-hint-percent (to fix exchange2 regression)

Hi, this patch reduces inline-heuristics-hint-percent so inliner behaves more similarly to what it did before I introduced this param. Bootstrapped/regtested x86_64-linux, comitted. I plan to do more tuning on this parameter, but the value of 1600 was actually a typo. Index: ChangeLog

[PATCH, GCC/ARM, 9/10] Call nscall function with blxns

[PATCH, GCC/ARM, 9/10] Call nscall function with blxns Hi, === Context === This patch is part of a patch series to add support for Armv8.1-M Mainline Security Extensions architecture. Its purpose is to call functions with the cmse_nonsecure_call attribute directly using blxns with no undue

[PATCH, GCC/ARM, 2/10] Add command line support for Armv8.1-M Mainline

[PATCH, GCC/ARM, 2/10] Add command line support Hi, === Context === This patch is part of a patch series to add support for Armv8.1-M Mainline Security Extensions architecture. Its purpose is to add command-line support for that new architecture. === Patch description === Besides the expected

[PATCH, GCC/ARM, 3/10] Save/restore FPCXTNS in nsentry functions

[PATCH, GCC/ARM, 3/10] Save/restore FPCXTNS in nsentry functions Hi, === Context === This patch is part of a patch series to add support for Armv8.1-M Mainline Security Extensions architecture. Its purpose is to enable saving/restoring of nonsecure FP context in function with the

[PATCH, GCC/ARM, 4/10] Clear GPR with CLRM

[PATCH, GCC/ARM, 4/10] Clear GPR with CLRM Hi, === Context === This patch is part of a patch series to add support for Armv8.1-M Mainline Security Extensions architecture. Its purpose is to improve code density of functions with the cmse_nonsecure_entry attribute and when calling function with

[PATCH, GCC/ARM, 6/10] Clear GPRs inline when calling nscall function

[PATCH, GCC/ARM, 6/10] Clear GPRs inline when calling nscall function Hi, === Context === This patch is part of a patch series to add support for Armv8.1-M Mainline Security Extensions architecture. Its purpose is to generate inline callee-saved register clearing when calling a function with

[PATCH, GCC/ARM, 8/10] Do lazy store & load inline when calling nscall function

[PATCH, GCC/ARM, 8/10] Do lazy store & load inline when calling nscall function Hi, === Context === This patch is part of a patch series to add support for Armv8.1-M Mainline Security Extensions architecture. Its purpose is to generate lazy store and load instruction inline when calling a

[PATCH, GCC/ARM, 1/10] Fix -mcmse check in libgcc

[PATCH, GCC/ARM, 1/10] Fix -mcmse check in libgcc Hi, === Context === This patch is part of a patch series to add support for Armv8.1-M Mainline Security Extensions architecture. Its purpose is to fix the check to determine whether -mcmse is supported by the host compiler. === Patch

[PATCH, GCC/ARM, 5/10] Clear VFP registers with VSCCLRM

[PATCH, GCC/ARM, 5/10] Clear VFP registers with VSCCLRM Hi, === Context === This patch is part of a patch series to add support for Armv8.1-M Mainline Security Extensions architecture. Its purpose is to improve code density of functions with the cmse_nonsecure_entry attribute and when calling

[PATCH, GCC/ARM, 7/10] Clear all VFP regs inline in hardfloat nscall functions

[PATCH, GCC/ARM, 7/10] Clear all VFP regs inline in hardfloat nscall functions Hi, === Context === This patch is part of a patch series to add support for Armv8.1-M Mainline Security Extensions architecture. Its purpose is to generate inline instructions to save, clear and restore callee-saved

[PATCH, GCC/ARM, 10/10] Enable -mcmse

[PATCH, GCC/ARM, 10/10] Enable -mcmse Hi, === Context === This patch is part of a patch series to add support for Armv8.1-M Mainline Security Extensions architecture. Its purpose is to enable the -mcmse option now that support for Armv8.1-M Security Extension is complete. === Patch description

[PATCH, GCC/ARM, 0/10] Add support for Armv8.1-M Mainline Security Extension

This is a patch series to implement support for the Armv8.1-M Mainline Security Extensions. The specification can be found in: https://developer.arm.com/docs/ddi0553/latest Mihail Ionescu(10) [PATCH, GCC/ARM, 1/10] Fix -mcmse check in libgcc [PATCH, GCC/ARM, 2/10] Add command line support for

Re: [PATCH] Refactor rust-demangle to be independent of C++ demangling.

On Tue, Oct 22, 2019, at 9:39 PM, Ian Lance Taylor wrote: > I have to assume that C++ demangling is still quite a bit more common > than Rust demangling, so it's troubling that it looks like we're going > to do extra work for each symbol that starts with _ZN, which is not a > particularly uncommon

Re: [PATCH 00/29] [arm] Rewrite DImode arithmetic support

On 23/10/2019 09:28, Christophe Lyon wrote: On 21/10/2019 14:24, Richard Earnshaw (lists) wrote: On 21/10/2019 12:51, Christophe Lyon wrote: On 18/10/2019 21:48, Richard Earnshaw wrote: Each patch should produce a working compiler (it did when it was originally written), though since the

[Patch, Fortran] PR91863 - fix call to bind(C) with array descriptor

With the trunk, there are three issues: (a) With bind(C), the callee side handles deallocation with intent(out). This should produce the code:     if (cfi.0 != 0B)   {     __builtin_free (cfi.0);     cfi.0 = 0B;   } This fails as cfi.0 (of type 'void*') is dereferenced and

[PATCH] Fix the easy part of PR65930

The following enables vectorization of int bar (unsigned int *x) { int sum = 0; for (int i = 0; i < 32; ++i) sum += x[i]; return sum; } which is currently not done because the loop has a conversion to unsigned int for 'sum' for doing the addition part of the reduction. That can now

[RFC C++ PATCH] OpenMP declare variant for C++

Hi! The following patch attempts to implement the declare variant lookup. As suggested by Jonathan and Jason, we have #pragma omp declare variant(variant-func-id) clause new-line function-declaration-or-definition where variant-func-id is id-expression. This is supposed to establish a variant

Re: RFC/A: Add a targetm.vectorize.related_mode hook

Richard Biener writes: > On Wed, Oct 23, 2019 at 1:51 PM Richard Sandiford > wrote: >> >> Richard Biener writes: >> > On Wed, Oct 23, 2019 at 1:00 PM Richard Sandiford >> > wrote: >> >> >> >> This patch is the first of a series that tries to remove two >> >> assumptions: >> >> >> >> (1) that

Re: GCC 9 backports

On 9/2/19 10:56 AM, Martin Liška wrote: > Hi. > > There are 2 more patches that I've just tested. > > Martin Hi. There are 2 more patches that I've just tested. Martin >From e1299829fce26b60105e09e2c6e60d8b998a566b Mon Sep 17 00:00:00 2001 From: jakub Date: Fri, 27 Sep 2019 10:28:48 +

Re: [PR47785] COLLECT_AS_OPTIONS

On Mon, Oct 21, 2019 at 10:04 AM Kugan Vivekanandarajah wrote: > > Hi Richard, > > Thanks for the pointers. > > > > On Fri, 11 Oct 2019 at 22:33, Richard Biener > wrote: > > > > On Fri, Oct 11, 2019 at 6:15 AM Kugan Vivekanandarajah > > wrote: > > > > > > Hi Richard, > > > Thanks for the

Re: RFC/A: Add a targetm.vectorize.related_mode hook

On Wed, Oct 23, 2019 at 1:51 PM Richard Sandiford wrote: > > Richard Biener writes: > > On Wed, Oct 23, 2019 at 1:00 PM Richard Sandiford > > wrote: > >> > >> This patch is the first of a series that tries to remove two > >> assumptions: > >> > >> (1) that all vectors involved in vectorisation

Re: RFC/A: Add a targetm.vectorize.related_mode hook

Richard Biener writes: > On Wed, Oct 23, 2019 at 1:00 PM Richard Sandiford > wrote: >> >> This patch is the first of a series that tries to remove two >> assumptions: >> >> (1) that all vectors involved in vectorisation must be the same size >> >> (2) that there is only one vector mode for a

Re: [PATCH] OpenACC reference count overhaul

Hi Julian! On 2019-10-21T16:14:11+0200, I wrote: > On 2019-10-03T09:35:04-0700, Julian Brown wrote: >> This patch has been broken out of the patch supporting OpenACC 2.6 manual >> deep copy last posted here: >> >> https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01084.html > > Thanks. I

[PATCH][OBVIOUS] Initialize a field in fibonacci_node.

The patch fixes a cppcheck where we have potentially uninitialized struct field. Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Ready to be installed? Thanks, Martin gcc/ChangeLog: 2019-10-23 Martin Liska PR middle-end/81669 * fibonacci_heap.h

Pass the data vector mode to get_mask_mode

This patch passes the data vector mode to get_mask_mode, rather than its size and nunits. This is a bit simpler and allows targets to distinguish between modes that happen to have the same size and number of elements. Tested individually on aarch64-linux-gnu and as a series on x86_64-linux-gnu.

Re: RFC/A: Add a targetm.vectorize.related_mode hook

On Wed, Oct 23, 2019 at 1:00 PM Richard Sandiford wrote: > > This patch is the first of a series that tries to remove two > assumptions: > > (1) that all vectors involved in vectorisation must be the same size > > (2) that there is only one vector mode for a given element mode and > number of

Remove build_{same_sized_,}truth_vector_type

build_same_sized_truth_vector_type was confusingly named, since for SVE and AVX512 the returned vector isn't the same byte size (although it does have the same number of elements). What it really returns is the "truth" vector type for a given data vector type. The more general truth_type_for

Add build_truth_vector_type_for_mode

Callers of vect_halve_mask_nunits and vect_double_mask_nunits already know what mode the resulting vector type should have, so we might as well create the vector type directly with that mode, just like build_vector_type_for_mode lets us build normal vectors with a known mode. This avoids the

Replace mode_for_int_vector with related_int_vector_mode

mode_for_int_vector, like mode_for_vector, can sometimes return an integer mode or an unsupported vector mode. But no callers are interested in that case, and only want supported vector modes. This patch therefore replaces mode_for_int_vector with related_int_vector_mode, which gives the target a

[PATCH] S/390: Use UNSPEC_GET_TP for thread pointer loads

Boostrapped and regtested on s390x-redhat-linux. gcc/ChangeLog: 2019-10-21 Ilya Leoshkevich * config/s390/s390.c (s390_get_thread_pointer): Use gen_get_thread_pointer. (s390_expand_split_stack_prologue): Likewise. * config/s390/s390.md (UNSPEC_GET_TP): New

Re: [Patch 0/X] [WIP][RFC][libsanitizer] Introduce HWASAN to GCC

Hi Martin, I'm getting close to putting up a patch series that I believe could go in before stage1 close. I currently have to do testing on sanitizing the kernel, and track down a bootstrap comparison diff in the code handling shadow-stack cleanup during exception unwinding. I just thought

RFC/A: Add a targetm.vectorize.related_mode hook

This patch is the first of a series that tries to remove two assumptions: (1) that all vectors involved in vectorisation must be the same size (2) that there is only one vector mode for a given element mode and number of elements Relaxing (1) helps with targets that support multiple vector

[committed][AArch64] Don't apply mode_for_int_vector to scalars

aarch64_emit_approx_sqrt handles both vectors and scalars and was using mode_for_int_vector even for the scalar case. Although that happened to work, it isn't how mode_for_int_vector is supposed to be used. Tested on aarch64-linux-gnu and applied as r277311. Richard 2019-10-23 Richard

Re: [PATCH V3] Loop split upon semi-invariant condition (PR tree-optimization/89134)

On Wed, Oct 23, 2019 at 11:11 AM Feng Xue OS wrote: > > Patch attached. + /* For PHI node that is not in loop header, its source operands should +be defined inside the loop, which are seen as loop variant. */ + if (def_bb != loop->header || !skip_head) + return false;

Re: PING*2 : Fwd: [PATCH][gcov-profile/91971]Profile directory concatenated with object file path

On 10/21/19 5:32 PM, Qing Zhao wrote: > Please let me know whether this patch is reasonable or not. The patch is fine. Please add PR entry to the ChangeLog and install the patch. Thanks, Martin

Re: [PATCH] Improve debug info in ivopts optimized loops (PR debug/90231)

On Tue, Oct 22, 2019 at 3:32 PM Jakub Jelinek wrote: > > On Mon, Oct 21, 2019 at 01:24:30PM +0200, Jakub Jelinek wrote: > > So I wonder if for correctness I don't need to add: > > > > if (!use->iv->no_overflow > > && !cand->iv->no_overflow > > && !integer_pow2p (cstep)) > >

[PATCH 3/3][rs6000] vector conversion RTL pattern update for diff unit size

Hi, Following the previous one 2/3, this patch is to update the vector conversions between fixed point and floating point with different element unit sizes, such as: SP <-> DI, DP <-> SI. Bootstrap and regression testing just launched. gcc/ChangeLog 2019-10-23 Kewen Lin *

[PATCH 2/3][rs6000] vector conversion RTL pattern update for same unit size

Hi, For those fixed point <-> floating point vector conversion with same element unit size, such as: SP <-> SI, DP <-> DI, it's fine to use the existing RTL operations like any_fix/any_float for them. This patch is to update them with any_fix/any_float. Bootstrapped and regress tested on

[PATCH 1/3][rs6000] Replace vsx_xvcdpsp by vsx_xvcvdpsp

Hi, I noticed that vsx_xvcdpsp and vsx_xvcvdpsp are almost the same, and vsx_xvcdpsp looks replaceable with vsx_xvcvdpsp since it's only called by gen_*. Bootstrapped and regress tested on powerpc64le-linux-gnu. gcc/ChangeLog 2019-10-23 Kewen Lin * config/rs6000/vsx.md

Re: [PATCH V3] Loop split upon semi-invariant condition (PR tree-optimization/89134)

Patch attached. Feng From: Richard Biener Sent: Wednesday, October 23, 2019 5:04 PM To: Feng Xue OS Cc: Michael Matz; Philipp Tomsich; gcc-patches@gcc.gnu.org; Christoph Müllner; erick.oc...@theobroma-systems.com Subject: Re: [PATCH V3] Loop split upon

[PATCH] Fix PR92179

More vectorizable_shift fallout - I've removed another disparity of SLP vs. non-SLP plus allowed type but not mode changing cases for SLP to go through (which originally caused the reported ICEs). Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. Richard. 2019-10-23 Richard

Re: [PATCH V3] Loop split upon semi-invariant condition (PR tree-optimization/89134)

On Wed, Oct 23, 2019 at 5:36 AM Feng Xue OS wrote: > > Michael, > > > I've only noticed a couple typos, and one minor remark. > Typos corrected. > > > I just wonder why you duplicated these three loops instead of integrating > > the real body into the existing LI_FROM_INNERMOST loop. I would

Re: [patch] Fix PR tree-optimization/92131

ization/92131 > * tree-vrp.c (extract_range_from_plus_minus_expr): If the resulting > range would be symbolic, drop to varying for any explicit overflow > in the constant part or if one of the ranges is not a singleton. > > > 2019-10-23 Eric Botcazou > > *

Re: [PATCH] Do not ICE in IPA inliner.

On Tue, Oct 22, 2019 at 2:47 PM Martin Liška wrote: > > Hi. > > We should not call to_gcov_type on a count that is uninitialized. > That's the case for a THUNK cgraph_node that we inline. > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > Ready to be installed? OK. >

[patch] Fix PR tree-optimization/92131

explicit overflow in the constant part or if one of the ranges is not a singleton. 2019-10-23 Eric Botcazou * gcc.c-torture/execute/20191023-1.c: New test. -- Eric BotcazouIndex: tree-vrp.c === --- tree-vrp.c

Re: [PATCH 00/29] [arm] Rewrite DImode arithmetic support

On 21/10/2019 14:24, Richard Earnshaw (lists) wrote: On 21/10/2019 12:51, Christophe Lyon wrote: On 18/10/2019 21:48, Richard Earnshaw wrote: Each patch should produce a working compiler (it did when it was originally written), though since the patch set has been re-ordered slightly there is a

Re: Ping: [PATCH V4] Extend IPA-CP to support arithmetically-computed value-passing on by-ref argument (PR ipa/91682)

Thanks for your comment, I will update the case accordingly. Feng From: luoxhu Sent: Wednesday, October 23, 2019 4:02 PM To: Feng Xue OS; Martin Jambor; Jan Hubicka; gcc-patches@gcc.gnu.org Subject: Re: Ping: [PATCH V4] Extend IPA-CP to support

Re: Ping: [PATCH V4] Extend IPA-CP to support arithmetically-computed value-passing on by-ref argument (PR ipa/91682)

Hi Feng, Thanks for the patch. It works for me as expected. I am not a reviewer, just tiny comment after tried. This is quite a good case for newbies to go through the ipa-cp pass. Is it necessary to update the test case a bit as attached to include more circumstances for callee's aggregate

Re: [PATCH] Define [range.cmp] comparisons for C++20

On Wed, 23 Oct 2019 at 00:33, Tam S. B. wrote: > > > commit b948d3f92d7bbe4d53237cb20ff40a15fa123988 > > Author: Jonathan Wakely > > Date: Thu Oct 17 15:20:38 2019 +0100 > > > > Define [range.cmp] comparisons for C++20 > > > > Define std::identity, std::ranges::equal_to,

*ping* Re: [Patch][OpenMP] use_device_addr/use_device_ptr with Fortran allocatable/pointer arrays (= array descriptor)

*ping* On 10/14/19 3:11 PM, Tobias Burnus wrote: This is a follow-up patch to the use_device_addr work. In particular, it replaces the patch at https://gcc.gnu.org/ml/fortran/2019-09/msg00088.html Fortran array descriptors need special handling, which this patch adds. [The

[PATCH] Adjust BB vect from-scalar build

After the latest changes we now end up building more SLP nodes from scalars - the fact that we have SLP childs for externals triggers this for the case where previously all ops were external (no scalar build was considered). The following adjusts the heuristic to treat constant operands as