Re: [PATCH 1/3] Power10: Add PCREL_OPT load support

Hi! On Tue, Aug 18, 2020 at 02:34:01AM -0400, Michael Meissner wrote: > +// Maximum number of insns to scan between the load address and the load that Please don't mix /* and // comments. Just stick to /* comments, like all the rest of our backend? > +const int MAX_PCREL_OPT_INSNS= 10;

How to decide if a target supports relocations or not?

Hi, Some questions about relocation. Could anyone kindly help on them? Thanks a lot. 1 If targetm.asm_out.reloc_rw_mask () returns 0, does it mean the target doesn't support relocations in read only section. So it should be put in read-write section? 2 Here, does the read only section

[committed] analyzer: add regression tests [PR95152]

PR analyzer/95152 reports various ICEs in region_model::get_or_create_mem_ref. I removed this function as part of the state rewrite in r11-2694-g808f4dfeb3a95f50f15e71148e5c1067f90a126d. I've verified that these two test cases reproduce the issue with 10.2 and don't ICE with trunk; adding them as

Re: [PATCH] improve validation of attribute arguments (PR c/78666)

On 8/20/20 3:00 PM, Aldy Hernandez wrote: First, didn't Marek say in the PR that the diagnostic code should go in diagnose_mismatched_attributes? My understanding of the structure of the attribute handling code is that with just a few exceptions, for C and C++ it's pretty much all in

Re: [PATCH 0/3] Power10 PCREL_OPT support

Hi! On Tue, Aug 18, 2020 at 02:31:41AM -0400, Michael Meissner wrote: > Currently on power10, the compiler compiles this as: > > ret_var: > pld 9,ext_variable@got@pcrel > lwa 3,0(9) > blr > > store_var: > pld

[committed] d: Merge upstream dmd 1b5a53d01.

Hi, This patch fixes an ICE in setValue at dmd/dinterpret.c:7046 This was originally seen when running the testsuite for a 16-bit target, however, it could be reproduced on 32-bit using long[] as well. Regstrapped on x86_64-linux-gnu/-m32/-mx32, committed to mainline and backported to gcc-10

Re: [Patch, fortran, v2] PR fortran/96728 - Fatal Error: Reading module inquiry functions on assumed-rank

Hi all! Exactly the same thing, only actually including the patch this time. Sorry for the mishap. Thank you very much. Best regards, José Rui On 20/08/20 19:33, José Rui Faustino de Sousa wrote: Hi all! Proposed patch to PR96728 - Fatal Error: Reading module inquiry functions on

[Patch, fortran] PR fortran/94110 - Passing an assumed-size to an assumed-shape argument should be rejected

Hi all! Proposed patch to PR94110 - Passing an assumed-size to an assumed-shape argument should be rejected. Patch tested only on x86_64-pc-linux-gnu. Add code to also check for deferred-shape and assumed-rank pointer (allocatable arguments are checked elsewhere) dummy arguments being

Re: [Patch 5/5] rs6000, Conversions between 128-bit integer and floating point values.

Hi! On Tue, Aug 11, 2020 at 12:23:13PM -0700, Carl Love wrote: [ Perfect stuff, or I don't see anything anyway! ] Okay for trunk. Thank you! Segher

Re: [PATCH 4/6] Add `+' for Jobserver Integration

On Thu, 20 Aug 2020, Giuliano Belinassi via Gcc-patches wrote: > libbacktrace/Makefile.in | 2 +- > zlib/Makefile.in | 64 ++-- These directories use makefiles generated by automake. Rather than modifying the generated files, you need to modify the sources (whether that's

Re: [PATCH] libgccjit: Fix several memory leaks in the driver

On Thu, 9 Jul 2020, Alex Coplan wrote: > 2020-07-09 Alex Coplan > > * gcc.c (set_static_spec): New. > (set_static_spec_owned): New. > (set_static_spec_shared): New. > (driver::maybe_putenv_COLLECT_LTO_WRAPPER): Use > set_static_spec_owned() to take ownership of

[PATCH 4/6] Add `+' for Jobserver Integration

GNU Make expects that a `+' token is present on the beggining of the rule command if it wants to interact with the Jobserver [1]. This commit add such token for the Makefiles in GCC. [1] https://www.gnu.org/software/make/manual/html_node/POSIX-Jobserver.html#POSIX-Jobserver gcc/ChangeLog:

[PATCH 2/6] Implement a new partitioner for parallel compilation

When using the LTO infrastructure to compile files in parallel, we can't simply use any of the LTO partitioner, once extra dependency analysis is required to ensure that some nodes are correctly partitioned together. Therefore, here we implement a new partitioner called "lto_merge_comdat_map"

[PATCH 3/6] Implement fork-based parallelism engine

This patch belongs to the "Parallelize GCC with Processes" series. Here, we implement the parallelism by forking the compiler into multiple processes after what would be the LTO LTRANS stage, partitioning the callgraph into several partitions, as implemented in "maybe_compile_in_parallel". From a

[PATCH 5/6] Add invoke documentation

Add documentation about how to invoke GCC in order to use parallel compilation. gcc/ChangeLog: 20-08-2020 Giuliano Belinassi * doc/invoke.texi: Document -fparallel-jobs=. --- gcc/doc/invoke.texi | 32 +++- 1 file changed, 31 insertions(+), 1 deletion(-)

[PATCH 6/6] New tests for parallel compilation feature

Adds new tests for testing the parallel compilation engine. They mainly test issues with regard to symbol promotion clash and incorrect early assembler output. 2020-08-20 Giuliano Belinassi * gcc.dg/parallel-early-constant.c: New test. * gcc.dg/parallel-static-1.c: New test.

[PATCH 1/6] Modify gcc driver for parallel compilation

Update the driver for parallel compilation. This process work as follows: When calling gcc, the driver will check if the flag "-fparallel-jobs" was provided by the user. If yes, then we will check what is the desired output, and if it can be parallelized. There are the following cases, which is

[PATCH 0/6] Parallelize Intra-Procedural Optimizations using the LTO Engine.

This patch series add a new flag "-fparallel-jobs=" to control if the compiler should try to compile the current file in parallel. There are three modes which is supported by now: 1. -fparallel-jobs=: Try to compile the file using a maximum of N jobs. 2. -fparallel-jobs=jobserver: Check if

Re: [Patch 4/5] rs6000, Test 128-bit shifts for just the int128 type.

Hi! On Tue, Aug 11, 2020 at 12:23:05PM -0700, Carl Love wrote: > +;; 128-bit int modes > +(define_mode_iterator VEC_I128 [V1TI TI]) We already have VSX_TI for this (in vsx.md). Rename that to something without VSX, and move it to vector.md or such? Maybe name it VEC_TI or anyTI. Do that

[committed 2/3] [og10] Annotate inner loops in "acc kernels loop" directives (C/C++).

Normally explicit loop directives in a kernels region inhibit automatic annotation of other loops in the same nest, on the theory that users have indicated they want manual control over that section of code. However there seems to be an expectation in user code that the combined "kernels loop"

[committed 3/3] [OG10] Annotate inner loops in "acc kernels loop" directives (Fortran).

Normally explicit loop directives in a kernels region inhibit automatic annotation of other loops in the same nest, on the theory that users have indicated they want manual control over that section of code. However there seems to be an expectation in user code that the combined "kernels loop"

[committed 1/3] [OG10] Add a "combined" flag for "acc kernels loop" etc directives.

2020-08-19 Sandra Loosemore gcc/ * tree.h (OACC_LOOP_COMBINED): New. gcc/c/ * c-parser.c (c_parser_oacc_loop): Set OACC_LOOP_COMBINED. gcc/cp/ * parser.c (cp_parser_oacc_loop): Set OACC_LOOP_COMBINED. gcc/fortran/ *

[committed 0/3] [OG10] openacc: Fix annotation of inner loops in combined "acc kernels loop" directives

The annotator that detects loops in kernels regions and adds "auto" attributes to them presently ignores loops nested in an explicitly-annotated loop, on the theory that the user likely marked up only some of the loops in the nest as a means of deliberately controlling the parallelism. Inspection

[committed] analyzer: fix infinite recursion ICE on unions [PR96723]

Attempts to store sm-state into a union in C++ triggered an infinite recursion when trying to generate a representative tree, due to erroneously trying to use the dtor of the union as a field. Fix it by filtering out non-FIELD_DECLs when walking TYPE_FIELDs in region::get_subregions_for_binding.

Re: [PATCH] improve validation of attribute arguments (PR c/78666)

First, didn't Marek say in the PR that the diagnostic code should go in diagnose_mismatched_attributes? An overall comment-- could we write a generic validator rather than having to special case validation on a case by case basis? Is there way of marking attributes as immutable if specified

Re: [PATCH] configure: Require C++11 for building code generation tools

Hi Tobias, This patch fixes the issue that I was seeing, thanks. I will also now try your updated patch from https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552330.html Kind Regards Vasee On 20/08/2020, 17:29, "Tobias Burnus" wrote: Hi, how about my (unreviewed) patch for PR

Re: [RFC PATCH v1 1/1] PPC64: Implement POWER Architecture Vector Function ABI.

On Thu, Aug 20, 2020 at 07:31:50PM +, GT wrote: > I'm still trying to understand why we need attribute((target("vsx"))). You need Power8, even! "vsx" alone is not enough (that only guarantees Power7). Your minimum version ("b") requires Power8. Segher

[PATCH] c++: Implement P1009: Array size deduction in new-expressions.

This patch implements C++20 P1009, allowing code like new double[]{1,2,3}; // array bound will be deduced Since this proposal makes the initialization rules more consistent, it is applied to all previous versions of C++ (thus, effectively, all the way back to C++11). My patch is based on

Re: [RFC PATCH v1 1/1] PPC64: Implement POWER Architecture Vector Function ABI.

On Thu, Aug 20, 2020 at 07:31:50PM +, GT wrote: > I'm still trying to understand why we need attribute((target("vsx"))). > > https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes > > The documentation for target(string) states that the purpose is to

[Patch, fortran] PR fortran/96728 - Fatal Error: Reading module inquiry functions on assumed-rank

Hi all! Proposed patch to PR96728 - Fatal Error: Reading module inquiry functions on assumed-rank. Patch tested only on x86_64-pc-linux-gnu. The rank of the argument to specification functions gets written when writing the module file, but, since the value will be negative for assumed-rank

Re: [RFC PATCH v1 1/1] PPC64: Implement POWER Architecture Vector Function ABI.

‐‐‐ Original Message ‐‐‐ On Thursday, August 13, 2020 5:00 PM, Jakub Jelinek wrote: > On Thu, Aug 13, 2020 at 08:40:22PM +, GT wrote: > > > I'm looking at ix86_simd_clone_adjust and also aarch64_simd_clone_adjust. > > The latter is > > much simpler and I see how I would add PPC

Re: [Patch] configure: Also check C++11 (flags) for ${build} compiler not only for ${host}

On Thu, 20 Aug 2020, Tobias Burnus wrote: > Thanks for the first review; new version attached. Thanks, this version is OK for GCC (but the GCC version will need updating if autoconf-archive ends up with a different version of these changes). -- Joseph S. Myers jos...@codesourcery.com

Re: reorg.c (fill_slots_from_thread): Improve for TARGET_FLAGS_REGNUM targets

Hans-Peter Nilsson via Gcc-patches writes: >> > @@ -2411,6 +2411,21 @@ fill_slots_from_thread (rtx_jump_insn *insn, rtx >> > condition, >> >CLEAR_RESOURCE (); >> >CLEAR_RESOURCE (); >> > >> > + /* Handle the flags register specially, to be able to accept a >> > + candidate that

Re: [Patch] configure: Also check C++11 (flags) for ${build} compiler not only for ${host}

On 8/20/20 7:12 PM, Joseph Myers wrote: It appears you're requiring _FOR_BUILD here and considering other suffixes invalid, which would prevent any other use, e.g. _FOR_TARGET. Actually, the main reason I required _FOR_BUILD was that I couldn't find m4_ifnblank and then gave up ... Now having

[PATCH] libstdc++: Fix iota_view::size() to avoid overflow

This avoids overfow that occurs when negating the most negative value of an integral type. Also prevent returning signed int when the values have lower rank and promote to int. libstdc++-v3/ChangeLog: * include/std/ranges (ranges::iota_view::size()): Perform all calculations in

Re: [PATCH v2] libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS

On Wed, 19 Aug 2020, Richard Earnshaw wrote: > > That said I'm of course happy to keep the ARM overrides if you consider > > them still necessary in the context of the generic change made. Let me > > know what you prefer, and if required, I will submit v3 with the ARM > > pieces removed.

[PATCH v3] libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS

Complement commit b932f770f70d ("x86_64 frame unwind info"), SVN r46374, , and replace `-fexceptions -fnon-call-exceptions' with `-fasynchronous-unwind-tables' in LIB2_DIVMOD_FUNCS compilation flags so as to provide unwind tables for

Re: [committed] libstdc++: Make __int128 meet integer-class requirements [PR 96042]

On 19/08/20 20:36 +0100, Jonathan Wakely wrote: On 19/08/20 17:00 +0100, Jonathan Wakely wrote: Because __int128 can be used as the difference type for iota_view, we need to ensure that it meets the requirements of an integer-class type. The requirements in [iterator.concept.winc] p10 include

[Patch, fortran] PR fortran/96727 - ICE with character length specified using specification function on assumed-rank array

Hi all! Proposed patch to PR96727 - ICE with character length specified using specification function on assumed-rank array. Patch tested only on x86_64-pc-linux-gnu. Add missing default error message for the assumed-rank array case. Thank you very much. Best regards, José Rui 2020-8-20

[Patch, fortran] PR fortran/96726 - ICE with user defined specification function on assumed-rank array

Hi all! Proposed patch to PR96726 - ICE with user defined specification function on assumed-rank array. Patch tested only on x86_64-pc-linux-gnu. Obvious fix, replace different operator with less than to avoid infinite loop. Thank you very much. Best regards, José Rui 2020-8-20 José

Re: [RFC PATCH v1 1/1] PPC64: Implement POWER Architecture Vector Function ABI.

On Thu, Aug 20, 2020 at 04:19:36PM +, GT wrote: > > Great! Please repost with what I already pointed out fixed, that > > explanation added, and working links to the documentation? > > Are you ok with the titles of the patch and this document? > >

Re: [PATCH] configure: Require C++11 for building code generation tools

On 20/08/2020 18:07, Vaseeharan Vinayagamoorthy wrote: > Hi Szabolcs, > > In the top level gcc config.log, I see: > > configure:5541: checking whether aarch64-none-linux-gnu-g++ supports C++11 > features by default > configure:5837: aarch64-none-linux-gnu-g++ -c -g -O2 conftest.cpp >&5 >

Re: reorg.c (fill_slots_from_thread): Improve for TARGET_FLAGS_REGNUM targets

> From: Richard Sandiford > Date: Thu, 20 Aug 2020 10:30:56 +0200 > Anything I once knew about reorg.c has long since faded away, but since > noone else has reviewed it... Thanks. I forgot to add PATCH and/or RFA: in the subject and forgot to CC Eric, assuming he's interested (I did CC him as

Re: [Patch] configure: Also check C++11 (flags) for ${build} compiler not only for ${host}

On Thu, 13 Aug 2020, Tobias Burnus wrote: > diff --git a/config/ax_cxx_compile_stdcxx.m4 b/config/ax_cxx_compile_stdcxx.m4 > index 9413da624d2..0cd515fc65b 100644 > --- a/config/ax_cxx_compile_stdcxx.m4 > +++ b/config/ax_cxx_compile_stdcxx.m4 > @@ -25,6 +25,10 @@ > # regardless, after defining

Re: [PATCH] configure: Require C++11 for building code generation tools

Hi Szabolcs, In the top level gcc config.log, I see: configure:5541: checking whether aarch64-none-linux-gnu-g++ supports C++11 features by default configure:5837: aarch64-none-linux-gnu-g++ -c -g -O2 conftest.cpp >&5 configure:5837: $? = 0 configure:5844: result: yes configure:6542: checking

[Patch, fortran] PR fortran/96724 - Bogus warnings with the repeat intrinsic and the flag -Wconversion-extra

Hi all! Proposed patch to PR96724 - Bogus warnings with the repeat intrinsic and the flag -Wconversion-extra. Patch tested only on x86_64-pc-linux-gnu. Add code to force conversion to the default wider integer type before multiplication. Thank you very much. Best regards, José Rui

Re: [PATCH] configure: Require C++11 for building code generation tools

Hi, how about my (unreviewed) patch for PR 96612 at https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551900.html ? That one also tries to solve the CXX_FOR_BUILD issue with an older GCC. Would that solve your issue as well? Tobias On 8/20/20 4:19 PM, Ilya Leoshkevich via Gcc-patches

Re: [Patch, committed] Fortran: Fix OpenMP's 'if(simd:' etc. conditions

On Thu, Aug 20, 2020 at 01:36:01PM +0200, Tobias Burnus wrote: > gcc/fortran/ChangeLog: > > * openmp.c (gfc_match_omp_clauses): Re-order 'if' clause pasing > to avoid creating spurious symbols. > > libgomp/ChangeLog: > > *

Re: [RFC PATCH v1 1/1] PPC64: Implement POWER Architecture Vector Function ABI.

‐‐‐ Original Message ‐‐‐ On Tuesday, August 18, 2020 5:32 PM, Segher Boessenkool wrote: > On Tue, Aug 18, 2020 at 07:14:19PM +, GT wrote: > > > > That sounds like libmvec? > > > I still don't know what this is. > > > > Yes, it is libmvec. > > Now look at what GCC does to the code in

Re: [PATCH] Fortran : get_environment_variable runtime error PR96486

Hi Mark, Please find attached a fix for PR96486. OK to commit? OK. Thanks for the patch! Best regards Thomas

Re: [Patch] Fortran: Add 'device_type' clause to OpenMP's declare target

Hi Tobias, to me this looks OK now. Regards, Andre On Thu, 20 Aug 2020 11:51:50 +0200 Tobias Burnus wrote: > Updated patch – taking Andre's suggestions into account + > extending the testcase, which now catches the previous (NO)HOST > module issue. > > OK? > > Tobias > > On 8/19/20

Re: [RISC-V] Add support for AddressSanitizer on RISC-V GCC

On Wed, 19 Aug 2020 02:25:37 PDT (-0700), gcc-patches@gcc.gnu.org wrote: Hi Andrew: I am not sure the reason why some targets pick different numbers. It seems it's not only target dependent but also OS dependent[1]. For RV32, I think using 1<<29 like other 32 bit targets is fine. [1]

Re: [Patch, fortran, coarray] Fix obvious typo in co_broadcast's argument assembly

Hi, commited with the input by Tobias applied. The full commit message now is: Fix obvious typo were errmsg_len was assigned to errmsg. gcc/fortran/ChangeLog: 2020-08-20 Andre Vehreschild PR fortran/94958 * trans-array.c

Re: [PATCH] PR libstdc++/71579 assert that type traits are not misused with an incomplete type

ср, 19 авг. 2020 г. в 14:29, Jonathan Wakely : <...> > Do we also want to check > (std::__is_complete_or_unbounded(__type_identity<_ArgTypes>{}) && ...) > for invoke_result and the is_invocable traits? Done. Changelog: 2020-08-20 Antony Polukhin PR libstdc/71579 *

Re: [PATCH] configure: Require C++11 for building code generation tools

The 08/20/2020 13:59, Vasee Vinayagamoorthy wrote: > +# Also require C++11 for building code generation tools. > +# Do nothing if "${build}" = "${host}", because in this case > +# CXX_FOR_BUILD="\$(CXX)", and $CXX is already set to the correct value > above. > +if test "${build}" != "${host}";

Re: [PATCH] arm: Require MVE memory operand for destination of vst1q intrinsic

On Thu, Aug 20, 2020 at 3:31 PM Joe Ramsay wrote: > > Hi Ramana, > > Thanks for the review. > > On 18/08/2020, 18:37, "Ramana Radhakrishnan" > wrote: > > On Thu, Aug 13, 2020 at 2:18 PM Joe Ramsay wrote: > > > > From: Joe Ramsay > > > > Hi, > > > > Previously, the

Re: [PATCH] arm: Require MVE memory operand for destination of vst1q intrinsic

Hi Ramana, Thanks for the review. On 18/08/2020, 18:37, "Ramana Radhakrishnan" wrote: On Thu, Aug 13, 2020 at 2:18 PM Joe Ramsay wrote: > > From: Joe Ramsay > > Hi, > > Previously, the machine description patterns for vst1q accepted a generic memory >

Re: [PATCH, nvptx, libgomp] Avoid use of GOMP_PLUGIN_acc_thread() in nvptx_free()

Hi Tom, thanks for the extremely quick review :) On 2020/8/20 9:33 PM, Tom de Vries wrote: I reviewed the CUDA API docs and see that CUDA_ERROR_NOT_PERMITTED is returned for such CUDA calls inside callback context, Right, that's "Callbacks must not make any CUDA API calls. Attempting to use a

Re: [PATCH] configure: Require C++11 for building code generation tools

On Thu, 2020-08-20 at 13:59 +0100, Vasee Vinayagamoorthy wrote: > Hello, > > After commit [1] ("Redefine NULL to nullptr"), building gcc > fails when $CXX_FOR_BUILD is not using C++11 mode by default. > This happens with gcc-4.8 which is still supported. > > This patch fixes this by adding

Re: [PATCH, nvptx, libgomp] Avoid use of GOMP_PLUGIN_acc_thread() in nvptx_free()

On 8/20/20 3:03 PM, Chung-Lin Tang wrote: > Hi Tom, > this patch adjusts nvptx_free() in libgomp/plugin/plugin-nvptx.c to avoid a > "GOMP_PLUGIN_acc_thread() == NULL" check that was causing problems under > OpenMP offloading. > > This check was originally used to determine if nvptx_free() was

[PATCH, nvptx, libgomp] Avoid use of GOMP_PLUGIN_acc_thread() in nvptx_free()

Hi Tom, this patch adjusts nvptx_free() in libgomp/plugin/plugin-nvptx.c to avoid a "GOMP_PLUGIN_acc_thread() == NULL" check that was causing problems under OpenMP offloading. This check was originally used to determine if nvptx_free() was running under CUDA callback context, when freeing

[PATCH] configure: Require C++11 for building code generation tools

Hello, After commit [1] ("Redefine NULL to nullptr"), building gcc fails when $CXX_FOR_BUILD is not using C++11 mode by default. This happens with gcc-4.8 which is still supported. This patch fixes this by adding -std=c++11 or its equivalent to $CXX_FOR_BUILD using AX_CXX_COMPILE_STDCXX(11).

Re: [PATCH] vxworks: Fix GCC selftests for *-wrs-vxworks7-* targets

Excerpts from Olivier Hainque's message of August 20, 2020 11:01 am: > Hello Iain, > >> On 19 Aug 2020, at 14:17, Iain Buclaw wrote: > >> Ah, no worries, attached updated patch. > >> As we have discussed this off the lists though, we agreed to compromise >> and leave -nostdinc as it is in

Re: [PATCH] PR target/96347: non-delegitimized UNSPEC UNSPEC_TP (19) found in variable location

Excerpts from Richard Sandiford's message of August 19, 2020 1:22 pm: > Iain Buclaw via Gcc-patches writes: >> Hi, >> >> On x86, a memory reference reference to a TLS address can be broken out >> and stored in a register, for instance: >> >> movq %fs:8+testYearsBC@tpoff, %rdx >> >>

RE: [PATCH PR94442] [AArch64] Redundant ldp/stp instructions emitted at -O3

> -Original Message- > From: Richard Sandiford [mailto:richard.sandif...@arm.com] > Sent: Thursday, August 20, 2020 4:55 PM > To: xiezhiheng > Cc: Richard Biener ; gcc-patches@gcc.gnu.org > Subject: Re: [PATCH PR94442] [AArch64] Redundant ldp/stp instructions > emitted at -O3 > >

Re: [PATCH] emit-rtl.c: Allow splitting of RTX_FRAME_RELATED_P insns?

Sorry for the slow reply. Senthil Kumar Selvaraj writes: > 2020-08-13 Senthil Kumar Selvaraj > > gcc/ChangeLog: > > * emit-rtl.c (try_split): Call copy_frame_info_to_split_insn > to split certain RTX_FRAME_RELATED_P insns. > * recog.c

Re: [PATCH] ipa-inline: Improve growth accumulation for recursive calls

Hi, On Thu, Aug 20 2020, Richard Sandiford wrote: >> >> >> Really appreciate for your detailed explanation. BTW, My previous patch >> for PGO build on exchange2 takes this similar method by setting each cloned >> node to 1/10th of the frequency several month agao :) >> >>

Re: [PATCH] cmpelim: recognize extra clobbers in insns

On Wed, Aug 19, 2020 at 11:05 AM Richard Sandiford wrote: > Sorry for the slow reply. Not a problem at all. Thank you for responding! > Pip Cet via Gcc-patches writes: > > I'm working on the AVR cc0 -> CCmode conversion (bug#92729). One > > problem is that the cmpelim pass is currently very

[Patch, committed] Fortran: Fix OpenMP's 'if(simd:' etc. conditions

This patch adds two 'simdlen' testcases by converting the respective C testcases. When doing so, it turned out that 'if (simd: x)' generated the symbol 'simd' due to: gfc_match ("if ( ") == MATCH_YES ... gfc_match ("%e )", >if_expr) The latter matches "%e", which creates the symbol and

Re: [PATCH] ipa-inline: Improve growth accumulation for recursive callsg

> > > > Really appreciate for your detailed explanation. BTW, My previous patch > > for PGO build on exchange2 takes this similar method by setting each cloned > > node to 1/10th of the frequency several month agao :) > > > > https://gcc.gnu.org/pipermail/gcc-patches/2020-June/546926.html I was

Re: [Patch] Fortran: Add 'device_type' clause to OpenMP's declare target

Updated patch – taking Andre's suggestions into account + extending the testcase, which now catches the previous (NO)HOST module issue. OK? Tobias On 8/19/20 2:51 PM, Tobias Burnus wrote: Am 18.08.20 um 19:33 schrieb Andre Vehreschild: +case OMP_DEVICE_TYPE_HOST: + MIO_NAME

Re: [PATCH] ipa-inline: Improve growth accumulation for recursive calls

Xionghu, thanks for working on fixing the exchange regression. luoxhu via Gcc-patches writes: > On 2020/8/13 20:52, Jan Hubicka wrote: >>> Since there are no other callers outside of these specialized nodes, the >>> guessed profile count should be same equal? Perf tool shows that even >>> each

[PATCH] [obvious] testsuite: Remove test for arm32 in arm_soft_ok

There is no reason to check for arm32 when checking for -mfloat=abi-soft support. Instead this implies skipping some tests when targetting a thumb-1 cpu, while they pass. This patch removes the arm32 check, and uses the same skeleton as arm_softfp_ok and arm_hard_ok. Committed as obvious.

Re: [PATCH] [FIX] Remove object adjustment to preserve object attributes

Hello Ricard! Thank you very much for your reply. The case is that currently the "uncached" attribute is used to generate special "cache bypass" instructions instead of regular one by ARC backend. That decision is made based on the result of "lookup_attribute()" call for a specified MEM_REF. For

Re: [PATCH] vxworks: Fix GCC selftests for *-wrs-vxworks7-* targets

Hello Iain, > On 19 Aug 2020, at 14:17, Iain Buclaw wrote: > Ah, no worries, attached updated patch. > As we have discussed this off the lists though, we agreed to compromise > and leave -nostdinc as it is in SELFTEST_FLAGS. > Iain. > > --- > gcc/ChangeLog: > > * config/vxworks.h

[PATCH] [obvious] testsuite: Skip arm/pure-code tests for arm*-*-uclinuxfdpiceabi

FDPIC it uses PIC code, which is incompatible with -mpure-code, so we want to skip these tests for arm*-*-uclinuxfdpiceabi. This patch also fixes a typo where the final closing bracket was commented out. Committed as obvious. 2020-08-20 Christophe Lyon gcc/testsuite/ *

Re: [PATCH PR94442] [AArch64] Redundant ldp/stp instructions emitted at -O3

xiezhiheng writes: >> -Original Message- >> From: Richard Sandiford [mailto:richard.sandif...@arm.com] >> Sent: Wednesday, August 19, 2020 6:06 PM >> To: xiezhiheng >> Cc: Richard Biener ; gcc-patches@gcc.gnu.org >> Subject: Re: [PATCH PR94442] [AArch64] Redundant ldp/stp instructions >>

Re: reorg.c (fill_slots_from_thread): Improve for TARGET_FLAGS_REGNUM targets

Anything I once knew about reorg.c has long since faded away, but since noone else has reviewed it… Do you know what guarantees that REG_DEAD and REG_UNUSED notes are reliable during reorg.c? It was written at a time when passes were expected to keep the notes up-to-date, but that's not true

RE: [PATCH PR94442] [AArch64] Redundant ldp/stp instructions emitted at -O3

> -Original Message- > From: Richard Sandiford [mailto:richard.sandif...@arm.com] > Sent: Wednesday, August 19, 2020 6:06 PM > To: xiezhiheng > Cc: Richard Biener ; gcc-patches@gcc.gnu.org > Subject: Re: [PATCH PR94442] [AArch64] Redundant ldp/stp instructions > emitted at -O3 > >

Re: [PATCH] [FIX] Remove object adjustment to preserve object attributes

Petro Karashchenko via Gcc-patches writes: > for bitfield MEMREFs > > [FIX] Propagate uncached type attributes to unaligned/packed types This doesn't look safe in general. The current code was added to avoid wrong-code problems for accesses that step outside the bounds of the original MEM_EXPR.

Re: [PATCH 4/4][PR target/88808]Enable bitwise operator for AVX512 masks.

On Thu, Aug 20, 2020 at 3:40 PM Uros Bizjak wrote: > > On Thu, Aug 20, 2020 at 9:31 AM Hongtao Liu wrote: > > > > On Thu, Aug 20, 2020 at 3:24 PM Hongtao Liu wrote: > > > > > > On Wed, Aug 19, 2020 at 3:05 PM Uros Bizjak wrote: > > > > > > > > On Wed, Aug 19, 2020 at 4:25 AM Hongtao Liu

Re: [PATCH 4/4][PR target/88808]Enable bitwise operator for AVX512 masks.

On Thu, Aug 20, 2020 at 9:31 AM Hongtao Liu wrote: > > On Thu, Aug 20, 2020 at 3:24 PM Hongtao Liu wrote: > > > > On Wed, Aug 19, 2020 at 3:05 PM Uros Bizjak wrote: > > > > > > On Wed, Aug 19, 2020 at 4:25 AM Hongtao Liu wrote: > > > > > > > > On Mon, Aug 17, 2020 at 6:08 PM Uros Bizjak

Re: [PATCH 2/4][PR target/88808]Enable bitwise operator for AVX512 masks.

On Wed, Aug 19, 2020 at 2:31 PM Uros Bizjak wrote: > > On Wed, Aug 19, 2020 at 4:17 AM Hongtao Liu wrote: > > OK, modulo: > > +/* { dg-final { scan-assembler-not "%xmm" } } */ > > It is not clear to me what the testcase is testing here. The scan > string is probably too broad and can generate

Re: [PATCH 4/4][PR target/88808]Enable bitwise operator for AVX512 masks.

On Thu, Aug 20, 2020 at 3:24 PM Hongtao Liu wrote: > > On Wed, Aug 19, 2020 at 3:05 PM Uros Bizjak wrote: > > > > On Wed, Aug 19, 2020 at 4:25 AM Hongtao Liu wrote: > > > > > > On Mon, Aug 17, 2020 at 6:08 PM Uros Bizjak wrote: > > > > > > > > On Fri, Aug 14, 2020 at 10:26 AM Hongtao Liu

Re: [PATCH 4/4][PR target/88808]Enable bitwise operator for AVX512 masks.

On Wed, Aug 19, 2020 at 3:05 PM Uros Bizjak wrote: > > On Wed, Aug 19, 2020 at 4:25 AM Hongtao Liu wrote: > > > > On Mon, Aug 17, 2020 at 6:08 PM Uros Bizjak wrote: > > > > > > On Fri, Aug 14, 2020 at 10:26 AM Hongtao Liu wrote: > > > > > > > > Enable operator or/xor/and/andn/not for mask

[PATCH] Fortran : Runtime error, reshape constant array assignment, PR96624

Please find attached a fix for PR96624.  The original patch was by Steve Kargl. Also occurs on releases/gcc-10, releases/gcc-9 and releases/gcc-8 branches. OK to commit to master and backport? [PATCH] Fortran  : Runtime error, reshape constant array assignment  PR96624 When assigning a