Re: [PATCH] C-SKY: Fix wrong ld name with option -mfloat-abi=hard.

Approved. Thanks, Cooper On 9/16/20 11:28 AM, Jojo R wrote: gcc/ChangeLog: * config/csky/csky-linux-elf.h (GLIBC_DYNAMIC_LINKER): Use mfloat-abi. --- gcc/config/csky/csky-linux-elf.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/config/csky/csky-linux-elf

Re: [PATCH] Fortran : Two further previously missed ICEs PR53298

Hi Mark, a few remarks: [...] > [PATCH] Fortran  : Two further previously missed ICEs PR53298 > > There were 3 ICEs with different call stacks in the comments of this > PR.  A previous commit fixed only one of those ICEs. > > The ICEs fixed here are in trans-array.c and trans-expr.c. > > The

Re: [RS6000] rs6000_rtx_costs for AND

On Tue, Sep 15, 2020 at 01:15:34PM -0500, will schmidt wrote: > On Tue, 2020-09-15 at 10:49 +0930, Alan Modra via Gcc-patches wrote: > > The existing "case AND" in this function is not sufficient for > > optabs.c:avoid_expensive_constant usage, where the AND is passed in > > outer_code. > > > >

[PATCH] C-SKY: Support multilib for mfloat-abi=.

gcc/ChangeLog: * config/csky/t-csky-linux (CSKY_MULTILIB_OSDIRNAMES): Use mfloat-abi. (MULTILIB_OPTIONS): Likewise. * config/csky/t-csky-elf (MULTILIB_OPTIONS): Likewise. (MULTILIB_EXCEPTIONS): Likewise. --- gcc/config/csky/t-csky-elf | 13 - gcc/con

Re: [Patch] Fortran: Avoid double-free with parse error (PR96041, PR93423)

Hi Tobias, diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c index c612b492f3e..326e6f5db7a 100644 --- a/gcc/fortran/decl.c +++ b/gcc/fortran/decl.c @@ -9819,6 +9819,15 @@ gfc_match_submod_proc (void) if (gfc_match_eos () != MATCH_YES) { + /* Unset st->n.sym. Note: in reject_stat

Re: [PATCH] arm: Fix up gcc.target/arm/lto/pr96939_* FAIL

On Tue, Sep 15, 2020 at 03:32:40PM +, Vaseeharan Vinayagamoorthy wrote: > I am seeing this unused parameter 'opts' error when building for this > configuration: > Build: arm-none-linux-gnueabihf > Host: arm-none-linux-gnueabihf > Target: arm-none-linux-gnueabihf > > In function 'void arm_opti

Re: [PATCH v2] rs6000: Expand vec_insert in expander instead of gimple [PR79251]

On Tue, Sep 15, 2020 at 6:18 PM Segher Boessenkool wrote: > > On Tue, Sep 15, 2020 at 08:51:09AM +0200, Richard Biener wrote: > > On Tue, Sep 15, 2020 at 5:56 AM luoxhu wrote: > > > > u[n % 4] = i; > > > > > > > > I guess. Is the % 4 mandated by the vec_insert semantics btw? > > (As an aside

Re: [Patch] Fortran: Avoid double-free with parse error (PR96041, PR93423)

Hi Andre, On 9/16/20 9:58 AM, Andre Vehreschild wrote: + st->n.sym = NULL; Don't we need free or unlink the st node from the symtree, too? I did not see a way to simply remove a single symtree; as this is the error case, I left the item in the symtree. The symtree itself is removed when

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

Tamar Christina 于2020年9月12日周六 上午1:39写道： > Hi Martin, > > > > > can you please confirm that the difference between these two is all due > to > > the last option -fno-inline-functions-called-once ? Is LTo necessary? > I.e., can > > you run the benchmark also built with the branch compiler and > -m

Re: [PATCH v2] rs6000: Expand vec_insert in expander instead of gimple [PR79251]

On Wed, Sep 16, 2020 at 8:15 AM luoxhu wrote: > > > > On 2020/9/15 14:51, Richard Biener wrote: > > > >> I only see VAR_DECL and PARM_DECL, is there any function to check the tree > >> variable is global? I added DECL_REGISTER, but the RTL still expands to > >> stack: > > > > is_global_var () or

[PATCH] Fix testcases to avoid plusminus-with-convert pattern (PR 97066)

With the new pattern rule (T)(A) +- (T)(B) -> (T)(A +- B), some testcases are simplified and could not keep expected code pattern as test-check. Minor changes are made to those cases to avoid simplification effect of the rule. Tested on x86_64-linux and aarch64-linux. Feng --- 2020-09-16 Feng Xu

Re: [PATCH] C-SKY: Support multilib for mfloat-abi=.

Approved. Thanks, Cooper On 9/16/20 3:29 PM, Jojo R wrote: gcc/ChangeLog: * config/csky/t-csky-linux (CSKY_MULTILIB_OSDIRNAMES): Use mfloat-abi. (MULTILIB_OPTIONS): Likewise. * config/csky/t-csky-elf (MULTILIB_OPTIONS): Likewise. (MULTILIB_EXCEPTIONS): Likewis

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

On 15 September 2020 21:47:46 CEST, Martin Sebor via Gcc-patches wrote: >Overflowing the size of a dynamic allocation (e.g., malloc or VLA) >can lead to a subsequent buffer overflow corrupting the heap or >stack. The attached patch diagnoses a subset of these cases where >the overflow/wraparound

Re: [PATCH] arm: Add new vector mode macros

Ping Richard Sandiford writes: > [ This is related to Dennis's subtraction patch > https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553339.html > and the discussion about how the patterns were written. I wanted > to see whether there was a way that we could simplify the current >

[PATCH] [OG10] Fix warning messages in privatized-ref-[23].C testcases

Hello The libgomp.oacc-c++/privatized-ref-[23].C testcases request 64 workers in a parallel section, but Nvidia only supports a maximum of 32 workers, and GCN a maximum of 16. The worker numbers are overridden by the compiler with a warning message printed, which causes test failures on Nvidia

Re: [PATCH] rs6000: Fix misnamed built-in

On Tue, Sep 15, 2020 at 08:38:42PM -0500, Bill Schmidt wrote: > The description in rs6000-builtin.def provides for a builtin named > __builtin_altivec_xst_len_r. However, it is hand-defined in > altivec_init_builtins as __builtin_xst_len_r, against the usual naming > practice. Fix that. >

[PATCH 1/3] C-SKY: Enable crtbegin/crtend.o of libgcc for elf target

libgcc/ChangeLog: * config.host (C-SKY): Enable crtbegin/crtend.o of libgcc for elf target. --- libgcc/config.host | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libgcc/config.host b/libgcc/config.host index 7a3e29d..dbb378f 100644 --- a/libgcc/config.host +++ b/lib

[PATCH 3/3] C-SKY: Refine target name for elf target test

gcc/testsuite/ChangeLog: * lib/target-supports.exp (check_profiling_available): Refine name of elf target. --- gcc/testsuite/lib/target-supports.exp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supp

[PATCH 2/3] C-SKY: Set use_gcc_stdint=wrap for elf target

gcc/ChangeLog: * config.gcc (C-SKY): Set use_gcc_stdint=wrap for elf target. --- gcc/config.gcc | 1 + 1 file changed, 1 insertion(+) diff --git a/gcc/config.gcc b/gcc/config.gcc index 797f0ad..845f10e 100644 --- a/gcc/config.gcc +++ b/gcc/config.gcc @@ -1543,6 +1543,7 @@ csky-*-*)

Re: [Patch] OpenMP: Handle cpp_implicit_alias in declare-target discovery (PR96390)

On Mon, Sep 14, 2020 at 03:25:29PM +0200, Tobias Burnus wrote: > Updated version attached. Does it seem to make sense? I think you want Honza on this primarily, I'm always lost in the cgraph alias code. > --- a/gcc/omp-offload.c > +++ b/gcc/omp-offload.c > @@ -196,21 +196,34 @@ omp_declare_target

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

On Tue, Sep 15, 2020 at 08:51:57PM -0500, Qing Zhao wrote: > > On Sep 15, 2020, at 6:09 PM, Segher Boessenkool > > wrote: > > If you want the zeroing insns to stay with the return, you have to > > express that in RTL. > > What do you mean by “express that in RTL”? > Could you please explain th

[Patch] [middle-end & nvptx] gcc/tracer.c: Don't split BB with SIMT LANE [PR95654]

Hi Tom, hi Richard, hello all, @Richard: does it look okay from the ME side? @Tom: Can you check which IFN_GOMP_SIMT should be excluded with -ftracer? Pre-remark, I do not know much about SIMT – except that they only appear with nvptx and somehow relate to lanes on the GPU. In any case, as the

RE: [PATCH 5/5][Arm] New pattern for CSEL, CSET and CSETM instructions

Hi Kyrill, It's been a while, but I believe you had the following comment about implementing CSEL: > (define_insn_and_split "*thumb2_movsicc_insn" >[(set (match_operand:SI 0 "s_register_operand" "=l,l,r,r,r,r,r,r,r,r,r,r") > (if_then_else:SI > @@ -449,17 +473,14 @@ > it\\t%d3

RE: [PATCH] arm: Add new vector mode macros

Hi Richard, > -Original Message- > From: Richard Sandiford > Sent: 16 September 2020 11:15 > To: gcc-patches@gcc.gnu.org > Cc: ni...@redhat.com; Richard Earnshaw ; > Ramana Radhakrishnan ; Kyrylo > Tkachov ; Dennis Zhang > > Subject: Re: [PATCH] arm: Add new vector mode macros > > Ping

Re: libbacktrace: Add support for MiniDebugInfo

Hi Ian, On 14/09/2020 14:12, Ian Lance Taylor via Gcc-patches wrote: > This patch to libbacktrace adds support for MiniDebugInfo, as > requested in PR 93608. This appears to introduce a failure in the libbacktrace testsuite (observed on both x86 and aarch64): ../gcc/libbacktrace/../test-driver:

Re: [PATCH V2] vec: don't select partial vectors when looping on full vectors

Andrea Corallo writes: > Hi all, > > here is the update version of the patch implementing suggestions. > > The check for 'vect_need_peeling_or_partial_vectors_p' (and its > comment) has also been move just before so we can short-circuit the > partial vector handling if we know we are using full ve

[PATCH] remove STMT_VINFO_NUM_SLP_USES

This removes STMT_VINFO_NUM_SLP_USES by pushing the setting of the shared stmt_vec_info vector type to where we actually need it which is alignment analysis and vectorizable_* analysis (where we could eventually elide it for non-load/store operations). In particular "uses" in the cache and in disq

Re: [PATCH v5 5/8] libstdc++ futex: Loop when waiting against arbitrary clock

On 29/05/20 07:17 +0100, Mike Crowe via Libstdc++ wrote: > > diff --git a/libstdc++-v3/include/bits/atomic_futex.h > > b/libstdc++-v3/include/bits/atomic_futex.h > > index 4375129..5f95ade 100644 > > --- a/libstdc++-v3/include/bits/atomic_futex.h > > +++ b/libstdc++-v3/include/bits/atomic_futex.h

Re: [Patch] [middle-end & nvptx] gcc/tracer.c: Don't split BB with SIMT LANE [PR95654]

[ cc-ing author omp support for nvptx. ] On 9/16/20 12:39 PM, Tobias Burnus wrote: > Hi Tom, hi Richard, hello all, > > @Richard: does it look okay from the ME side? > @Tom: Can you check which IFN_GOMP_SIMT should be > excluded with -ftracer? > > Pre-remark, I do not know much about SIMT – exce

Re: [PATCH v2] rs6000: Expand vec_insert in expander instead of gimple [PR79251]

On Wed, Sep 16, 2020 at 10:31:54AM +0200, Richard Biener wrote: > On Tue, Sep 15, 2020 at 6:18 PM Segher Boessenkool > wrote: > > > > On Tue, Sep 15, 2020 at 08:51:09AM +0200, Richard Biener wrote: > > > On Tue, Sep 15, 2020 at 5:56 AM luoxhu wrote: > > > > > u[n % 4] = i; > > > > > > > > > >

Re: [Patch] [middle-end & nvptx] gcc/tracer.c: Don't split BB with SIMT LANE [PR95654]

Can you supply a tar with tree dumps for me to look at please? Also, if you can check if the problem can be triggered without a collapsed loop (e.g. try removing collapse(2), remove mentions of d2) and if so supply dumps from that instead, I'd appreciate that too. Alexander On Wed, 16 Sep 2020,

Re: [PATCH] Ignore the clobbered stack pointer in asm statment

Jakub Jelinek via Gcc-patches writes: > On Mon, Sep 14, 2020 at 08:57:18AM -0700, H.J. Lu via Gcc-patches wrote: >> Something like this for GCC 8 and 9. > > Guess my preference would be to do this everywhere and then let's discuss if > we change the warning into error there or keep it being deprec

Re: [PATCH 3/3] C-SKY: Refine target name for elf target test

All of the three pathes have been pushed to trunk. Thanks, Cooper On 9/16/20 6:34 PM, Jojo R wrote: gcc/testsuite/ChangeLog: * lib/target-supports.exp (check_profiling_available): Refine name of elf target. --- gcc/testsuite/lib/target-supports.exp | 2 +- 1 file changed, 1 ins

Re: [PATCH] aarch64: Fix ICE on fpsr fpcr getters [PR96968]

Andrea Corallo writes: > @@ -2034,6 +2034,16 @@ aarch64_expand_fpsr_fpcr_setter (int unspec, > machine_mode mode, tree exp) >emit_insn (gen_aarch64_set (unspec, mode, op)); > } > > +/* Expand a fpsr or fpcr getter (depending on UNSPEC) using MODE. > + Return the target. */ > +static rtx

[PATCH] C-SKY: Add -msim option

gcc/ChangeLog: * config/csky/csky.opt (msim): New. * doc/invoke.texi (C-SKY Options): Document -msim. * config/csky/csky-elf.h (LIB_SPEC): Add simulator runtime. --- gcc/config/csky/csky-elf.h | 10 -- gcc/config/csky/csky.opt | 4 gcc/doc/invoke.texi

Re: [PATCH] Ignore the clobbered stack pointer in asm statment

On Wed, Sep 16, 2020 at 12:34:50PM +0100, Richard Sandiford wrote: > Jakub Jelinek via Gcc-patches writes: > > On Mon, Sep 14, 2020 at 08:57:18AM -0700, H.J. Lu via Gcc-patches wrote: > >> Something like this for GCC 8 and 9. > > > > Guess my preference would be to do this everywhere and then let'

openmp question

Jakub, is libgomp/testsuite/libgomp.c++/udr-3.C well formed? Specifically V::baz? If you remove the templatedness and plug in typedefs for T & D on its only instantiation (as the attached does), you get the following errors: devvm293:414>g++ -std=c++11 -c -fopenmp udr-3.C udr-3.C: In member f

Re: openmp question

On Wed, Sep 16, 2020 at 08:00:01AM -0400, Nathan Sidwell wrote: > is libgomp/testsuite/libgomp.c++/udr-3.C well formed? > > Specifically V::baz? > > If you remove the templatedness and plug in typedefs for T & D on its only > instantiation (as the attached does), you get the following errors: >

Re: [PATCH] IBM Z: Fix *vec_tf_to_v1tf constraints

On 03.09.20 08:39, Ilya Leoshkevich wrote: > Bootstrapped (with BOOT_CFLAGS='-g -O2 -Wno-error=maybe-uninitialized') > and regtested on s390x-redhat-linux. Ok for master? > > > > Certain alternatives of *vec_tf_to_v1tf use "v" constraint for its > TFmode source operand. Therefore it is assigned

Re: [PATCH] libstdc++: use a link test to test for -Wl,-z,relro

On 9/13/20 3:37 PM, JonY wrote: > On 9/10/20 2:23 PM, JonY wrote: >> Do a link test instead of just a grep. The linker can >> support multiple targets, but not all targets can use it. >> >> Cygwin/MinGW ld can support ELF but the PE format for Windows itself >> does not support such a feature. Atta

Re: [PATCH] Fix testcases to avoid plusminus-with-convert pattern (PR 97066)

On Wed, Sep 16, 2020 at 10:54 AM Feng Xue OS via Gcc-patches wrote: > > With the new pattern rule (T)(A) +- (T)(B) -> (T)(A +- B), > some testcases are simplified and could not keep expected > code pattern as test-check. Minor changes are made to those > cases to avoid simplification effect of the

Re: [PATCH PR93334][RFC]Skip output dep if values stored are byte wise the same

On Tue, Sep 15, 2020 at 2:28 PM bin.cheng via Gcc-patches wrote: > > Hi, > As suggested by PR93334 comments, this patch adds an interface identifying > output dependence which can be skipped in terms of reordering and skip it in > loop distribution. It also adds a new test case. Any comment? Lo

Re: [PATCH] debug: Pass --gdwarf-N to assembler if fixed gas is detected during configure

Hi, On Tue, 2020-09-15 at 20:40 +0200, Jakub Jelinek wrote: > Ok, here it is in patch form. > I've briefly tested it, with the older binutils I have around (no --gdwarf-N > support), with latest gas (--gdwarf-N that can be passed to as even when > compiling C/C++ etc. code and emitting .debug_line

Re: [aarch64] Backport missing NEON intrinsics to GCC8

On Wed, 16 Sep 2020 at 07:21, Pop, Sebastian via Gcc-patches wrote: > > Thanks Kyrill for your review. > > I committed the patches to the gcc-8 branch: > https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=2c55e6caa9432b2c1f081cb3aeddd36abec03233 > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a4004

RE: [aarch64] Backport missing NEON intrinsics to GCC8

> -Original Message- > From: Christophe Lyon > Sent: 16 September 2020 13:43 > To: Pop, Sebastian > Cc: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org > Subject: Re: [aarch64] Backport missing NEON intrinsics to GCC8 > > On Wed, 16 Sep 2020 at 07:21, Pop, Sebastian via Gcc-patches > wrote:

Re: [PATCH] Increase rtx_cost of sse_to_integer in skylake_cost.

> gcc/ChangeLog > > PR target/96861 > * config/i386/x86-tune-costs.h (skylake_cost): increase rtx > cost of sse_to_integer from 2 to 6. > > gcc/testsuite > > * gcc.target/i386/pr95021-3.c: Add -mtune=generic. OK. Thanks, Uros.

Re: [PATCH] -mno-xsave should imply -mno-avx since -mavx implies -mxsave

> gcc/ChangeLog > > * common/config/i386/i386-common.c > (OPTION_MASK_ISA_AVX_UNSET): Remove OPTION_MASK_ISA_XSAVE_UNSET. > (OPTION_MASK_ISA_XSAVE_UNSET): Add OPTION_MASK_ISA_AVX_UNSET. > > gcc/testsuite/ChangeLog > > * gcc.target/i386/xsave-avx-1.c: New test. OK fo

[PATCH] libstdc++: use lt_host_flags for libstdc++.la

For platforms like Mingw and Cygwin, cygwin refuses to generate the shared library without using -no-undefined. Attached patch makes sure the right flags are used, since libtool is already used to link libstdc++. Patch OK? From 4ba039687182fccd67e1170f89e259e1c4a58eeb Mon Sep 17 00:00:00 2001 Fro

Re: [PATCH] rs6000: Fix misnamed built-in

On 9/16/20 5:32 AM, Segher Boessenkool wrote: On Tue, Sep 15, 2020 at 08:38:42PM -0500, Bill Schmidt wrote: The description in rs6000-builtin.def provides for a builtin named __builtin_altivec_xst_len_r. However, it is hand-defined in altivec_init_builtins as __builtin_xst_len_r, against the us

Re: [PATCH] debug: Pass --gdwarf-N to assembler if fixed gas is detected during configure

On Wed, Sep 16, 2020 at 02:33:03PM +0200, Mark Wielaard wrote: > > 2020-09-15 Jakub Jelinek > > > > * configure.ac (HAVE_AS_GDWARF_5_DEBUG_FLAG, > > HAVE_AS_WORKING_DWARF_4_FLAG): New tests. > > * gcc.c (ASM_DEBUG_DWARF_OPTION): Define. > > (ASM_DEBUG_SPEC): Use ASM_DEBUG_DWARF_

[PATCH] rs6000: Add rs6000_cfun_pcrel_p

This is a cleanup requested by Segher in a previous review. Most uses of rs6000_pcrel_p are called for the current function. A specialized version for cfun is more efficient for these uses. (Actually all uses are called for the current function, so now rs6000_pcrel_p is an orphan. However, I th

[PATCH] IRA: Don't make a global register eliminable

On Tue, Sep 15, 2020 at 7:44 AM Richard Sandiford wrote: > > Thanks for looking at this. > > "H.J. Lu" writes: > > commit 1bcb4c4faa4bd6b1c917c75b100d618faf9e628c > > Author: Richard Sandiford > > Date: Wed Oct 2 07:37:10 2019 + > > > > [LRA] Don't make eliminable registers live (PR919

Re: [PATCH V2] vec: don't select partial vectors when looping on full vectors

Richard Sandiford writes: > OK with two incredibly petty comments fixed: [...] Installed with the two suggestions as 052204fac58. Thanks for reviewing! Andrea

[PATCH] Canonicalize real X - CST to X + -CST

This removes the canonicalization of X + -CST to X - CST to facilitate SLP vectorization analysis where we currently treat the added testcase as two-operation plus blend vectorization opportunity. While there may be the possibility to avoid this in the vectorizer itself the canonicalization is som

[PATCH, OpenMP 5, C++] Implement implicit mapping of this[:1] (PR92120)

Hi Jakub, this patch implements automatically adding map(tofrom: this[:1]) to omp target regions inside non-static member functions, as specified in OpenMP 5.0. This patch factors away some parts of cp_parser_omp_target, into a new finish_omp_target function, and implements the new clause adding

[Patch] Fortran: OpenMP - fix simd with (last)private (PR97061

Using linear (added by the compiler) + explicit lastprivate gives an error. To quote Jakub from the PR: "If it is the FE that adds the linear clause, then it shouldn't when there is explicit lastprivate clause. This is a new thing in OpenMP 5.0, in 4.5 it was invalid to make the iterate anything

Re: [Patch] Fortran: OpenMP - fix simd with (last)private (PR97061

On Wed, Sep 16, 2020 at 04:08:16PM +0200, Tobias Burnus wrote: > Using linear (added by the compiler) + explicit lastprivate gives an error. > > To quote Jakub from the PR: > "If it is the FE that adds the linear clause, then it > shouldn't when there is explicit lastprivate clause. > This is a ne

Re: [PATCH, 1/3, OpenMP] Target mapping changes for OpenMP 5.0, front-end parts

Ping this patch set. Thanks, Chung-Lin On 2020/9/1 9:16 PM, Chung-Lin Tang wrote: Hi Jakub, this patch set implements parts of the target mapping changes introduced in OpenMP 5.0, mainly the attachment requirements for pointer-based list items, and the clause ordering. The first patch here are

c++: Break out actual instantiation from instantiate_decl

This refactors instantiate_decl, breaking out the actual instantiation work to instantiate_body. That'll allow me to address the OMP UDR issue, but it also means we have slightly neater code in instantiate_decl anyway. gcc/cp/ * pt.c (instantiate_body): New, broken out o

Re: libbacktrace: Add support for MiniDebugInfo

On Wed, Sep 16, 2020, 4:03 AM Alex Coplan wrote: > Hi Ian, > > On 14/09/2020 14:12, Ian Lance Taylor via Gcc-patches wrote: > > This patch to libbacktrace adds support for MiniDebugInfo, as > > requested in PR 93608. > > This appears to introduce a failure in the libbacktrace testsuite > (observe

Re: [PATCH] IRA: Don't make a global register eliminable

"H.J. Lu" writes: > On Tue, Sep 15, 2020 at 7:44 AM Richard Sandiford > wrote: >> >> Thanks for looking at this. >> >> "H.J. Lu" writes: >> > commit 1bcb4c4faa4bd6b1c917c75b100d618faf9e628c >> > Author: Richard Sandiford >> > Date: Wed Oct 2 07:37:10 2019 + >> > >> > [LRA] Don't make

c++: Avoid confusing 'nested' name

instantiate_body has a local var call 'nested', which indicates that this instantiation was caused during the body of some function -- not necessarily its containing scope. That's confusing, let's just use 'current_function_decl' directly. Then we can also simplify the push_to_top_level logic,

Re: [PATCH] IRA: Don't make a global register eliminable

On Wed, Sep 16, 2020 at 7:46 AM Richard Sandiford wrote: > > "H.J. Lu" writes: > > On Tue, Sep 15, 2020 at 7:44 AM Richard Sandiford > > wrote: > >> > >> Thanks for looking at this. > >> > >> "H.J. Lu" writes: > >> > commit 1bcb4c4faa4bd6b1c917c75b100d618faf9e628c > >> > Author: Richard Sandifo

[PATCH] preprocessor: Fix ICE with too long line in fmtwarn [PR96935]

Here we ICE in char_span::subspan because the offset it gets is -1. It's -1 because get_substring_ranges_for_loc gets a location whose column was 0. That only happens in testcases like the attached where we're dealing with extremely long lines (at least 4065 chars it seems). This does happen in pr

Re: [aarch64] Backport missing NEON intrinsics to GCC8

Thanks Christophe for reporting the errors. On 9/16/20, 7:45 AM, "Kyrylo Tkachov" wrote: > > The new tests vld1x3 and vld1x4 fail on arm, I am seeing new failures > > on gcc-8 and gcc-9 branches > > after r8-10451, r8-10452 and r9-8874. > > Is that expected/fixed later in the backport series? > >

Re: libbacktrace: Add support for MiniDebugInfo

On 16/09/2020 07:26, Ian Lance Taylor wrote: > On Wed, Sep 16, 2020, 4:03 AM Alex Coplan wrote: > > > Hi Ian, > > > > On 14/09/2020 14:12, Ian Lance Taylor via Gcc-patches wrote: > > > This patch to libbacktrace adds support for MiniDebugInfo, as > > > requested in PR 93608. > > > > This appears

Re: [Patch] [middle-end & nvptx] gcc/tracer.c: Don't split BB with SIMT LANE [PR95654]

On 9/16/20 1:24 PM, Alexander Monakov wrote: > Can you supply a tar with tree dumps for me to look at please? > Hi Alexander, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95654#c6 . > Also, if you can check if the problem can be triggered without a > collapsed loop (e.g. try removing collapse(2

[PATCH][Arm] Enable MVE SIMD modes for vectorization

Hi all, This patch enables SIMD modes for MVE auto-vectorization. In this patch, the integer and float MVE SIMD modes are returned by arm_preferred_simd_mode (TARGET_VECTORIZE_PREFERRED_SIMD_MODE hook) when MVE or MVE_FLOAT is enabled. Then the expanders for auto-vectorization can be used for ge

Re: [PATCH] Allow copying of symbolic ranges to an irange.

>> // Swap min/max if they are out of order. Return TRUE if further > these seems OK, but can't there be anti-ranges with symbolics too? ie > ~[a_12, a_12] > The code for that just does: > > else if (src.kind () == VR_ANTI_RANGE) > set (src.min (), src.max (), VR_ANTI_RANGE); > > That

Problem with static const objects and LTO

Consider a TU with file scoped "static const object utf8_sb_map".   A routine within the TU will stuff &utf8_sb_map into an object, something like: fu (...) {   if (cond)     dfa->sb_char = utf8_sb_map;   else     dfa->sb_char = malloc (...); } There is another routine in the TU which loo

Re: Problem with static const objects and LTO

On Wed, Sep 16, 2020 at 9:53 AM Jeff Law via Gcc-patches wrote: > > > Consider a TU with file scoped "static const object utf8_sb_map". A > routine within the TU will stuff &utf8_sb_map into an object, something > like: > > fu (...) > > { > > if (cond) > > dfa->sb_char = utf8_sb_map; > >

Re: [PATCH] aarch64: Add extend-as-extract-with-shift pattern [PR96998]

Hi Richard, On 10/09/2020 19:18, Richard Sandiford wrote: > Alex Coplan writes: > > Hello, > > > > Since r11-2903-g6b3034eaba83935d9f6dfb20d2efbdb34b5b00bf introduced a > > canonicalization from mult to shift on address reloads, a missing > > pattern in the AArch64 backend was exposed. > > > > In

Re: Problem with static const objects and LTO

On 9/16/20 11:05 AM, H.J. Lu wrote: > On Wed, Sep 16, 2020 at 9:53 AM Jeff Law via Gcc-patches > wrote: >> >> Consider a TU with file scoped "static const object utf8_sb_map". A >> routine within the TU will stuff &utf8_sb_map into an object, something >> like: >> >> fu (...) >> >> { >> >> if

Re: [PATCH] rs6000: Add rs6000_cfun_pcrel_p

On Wed, Sep 16, 2020 at 08:36:35AM -0500, Bill Schmidt wrote: > This is a cleanup requested by Segher in a previous review. Most > uses of rs6000_pcrel_p are called for the current function. A > specialized version for cfun is more efficient for these uses. Then rename that one to rs6000_functio

Re: Problem with static const objects and LTO

On Wed, Sep 16, 2020 at 10:10 AM Jeff Law wrote: > > > On 9/16/20 11:05 AM, H.J. Lu wrote: > > On Wed, Sep 16, 2020 at 9:53 AM Jeff Law via Gcc-patches > > wrote: > >> > >> Consider a TU with file scoped "static const object utf8_sb_map". A > >> routine within the TU will stuff &utf8_sb_map int

Re: Problem with static const objects and LTO

On 9/16/20 11:13 AM, H.J. Lu wrote: > On Wed, Sep 16, 2020 at 10:10 AM Jeff Law wrote: >> >> On 9/16/20 11:05 AM, H.J. Lu wrote: >>> On Wed, Sep 16, 2020 at 9:53 AM Jeff Law via Gcc-patches >>> wrote: Consider a TU with file scoped "static const object utf8_sb_map". A routine within

Re: Problem with static const objects and LTO

On Wed, Sep 16, 2020 at 10:24 AM Jeff Law wrote: > > > On 9/16/20 11:13 AM, H.J. Lu wrote: > > On Wed, Sep 16, 2020 at 10:10 AM Jeff Law wrote: > >> > >> On 9/16/20 11:05 AM, H.J. Lu wrote: > >>> On Wed, Sep 16, 2020 at 9:53 AM Jeff Law via Gcc-patches > >>> wrote: > Consider a TU with file

Re: [PATCH] c++: premature analysis of requires-expression [PR96410]

On Thu, 13 Aug 2020, Jason Merrill wrote: > On 8/13/20 11:21 AM, Patrick Palka wrote: > > On Mon, 10 Aug 2020, Jason Merrill wrote: > > > > > On 8/10/20 2:18 PM, Patrick Palka wrote: > > > > On Mon, 10 Aug 2020, Patrick Palka wrote: > > > > > > > > > In the below testcase, semantic analysis of t

[PATCH] [OG10] Xfail libgomp.oacc-fortran/privatized-ref-2.f90 when offloading to nvptx

Hello I have committed this patch to xfail libgomp.oacc-fortran/privatized-ref-2.f90 when the offload target is nvptx, as the generated code has some alloca calls which are currently not supported by nvptx (PR65181). Kwok commit 1245f6f615fa08d2ab4165598c9db72c4dad4467 Author: Kwok Cheung Ye

Re: Problem with static const objects and LTO

On 9/16/20 11:32 AM, H.J. Lu wrote: > On Wed, Sep 16, 2020 at 10:24 AM Jeff Law wrote: >> >> On 9/16/20 11:13 AM, H.J. Lu wrote: >>> On Wed, Sep 16, 2020 at 10:10 AM Jeff Law wrote: On 9/16/20 11:05 AM, H.J. Lu wrote: > On Wed, Sep 16, 2020 at 9:53 AM Jeff Law via Gcc-patches > wro

Re: Problem with static const objects and LTO

On Wed, 16 Sep 2020, Jeff Law via Gcc-patches wrote: > ISTM this is a lot like the problem we have where we inline functions > with static data.   To fix those we use STB_GNU_UNIQUE.  But I don't see > any code in the C front-end which would utilize STB_GNU_UNIQUE.  It's > support seems limited to

c++: local-scope OMP UDR reductions have no template head

Jakub, are you ok with the bool return from cp_check_omp_declare_reduction? That seemed like the least invasive change. This corrects the earlier problems with removing the template header from local omp reductions. And it uncovered a latent bug. When we tsubst such a decl, we immediately tsu

Commit 052204fac580 was never sent to gcc-patches

... and it causes testsuite regressions on Power. We haven't determined et if it actually is worse code, but there are testcases that trip on it. Either way, all patches should be send to gcc-patches@, whether pre-approved or not. Please correct this. Thanks! Segher

Re: [Patch] [middle-end & nvptx] gcc/tracer.c: Don't split BB with SIMT LANE [PR95654]

On Wed, 16 Sep 2020, Tom de Vries wrote: > [ cc-ing author omp support for nvptx. ] The issue looks familiar. I recognized it back in 2017 (and LLVM people recognized it too for their GPU targets). In an attempt to get agreement to fix the issue "properly" for GCC I found a similar issue that

Re: c++: local-scope OMP UDR reductions have no template head

On Wed, Sep 16, 2020 at 02:11:32PM -0400, Nathan Sidwell wrote: > Jakub, > are you ok with the bool return from cp_check_omp_declare_reduction? That > seemed like the least invasive change. > > This corrects the earlier problems with removing the template header > from local omp reductions. And i

Re: Commit 052204fac580 was never sent to gcc-patches

Segher Boessenkool writes: > ... and it causes testsuite regressions on Power. We haven't determined > et if it actually is worse code, but there are testcases that trip on > it. Either way, all patches should be send to gcc-patches@, whether > pre-approved or not. > > Please correct this. Tha

Re: c++: local-scope OMP UDR reductions have no template head

On 9/16/20 2:31 PM, Jakub Jelinek wrote: On Wed, Sep 16, 2020 at 02:11:32PM -0400, Nathan Sidwell wrote: Jakub, are you ok with the bool return from cp_check_omp_declare_reduction? That seemed like the least invasive change. This corrects the earlier problems with removing the template header f

Re: c++: local-scope OMP UDR reductions have no template head

On Wed, Sep 16, 2020 at 02:38:22PM -0400, Nathan Sidwell wrote: > On 9/16/20 2:31 PM, Jakub Jelinek wrote: > > On Wed, Sep 16, 2020 at 02:11:32PM -0400, Nathan Sidwell wrote: > > > Jakub, > > > are you ok with the bool return from cp_check_omp_declare_reduction? That > > > seemed like the least inv

[pushed] libbacktrace, Mach-O : Support PowerPC archs.

Hi, This adds the PPC architecture variants for Mach-O libbacktrace. With this (as for X86 and Arm) when dsymutil is run on the binary we get a basic usable backtrace. Testsuite results on powerpc-apple-darwin9 are the same as for X86: * btest fails (TBC why) * dwarf5 tests fail because dsymu

Re: [PATCH] Allow copying of symbolic ranges to an irange.

On 9/16/20 12:25 PM, Aldy Hernandez wrote: >>  // Swap min/max if they are out of order.  Return TRUE if further > these seems OK, but can't there be anti-ranges with symbolics  too? ie > ~[a_12, a_12] > The code for that just does: > >   else if (src.kind () == VR_ANTI_RANGE) >  set (src.m

Re: [PATCH] rs6000: Add rs6000_cfun_pcrel_p

On 9/16/20 12:09 PM, Segher Boessenkool wrote: On Wed, Sep 16, 2020 at 08:36:35AM -0500, Bill Schmidt wrote: This is a cleanup requested by Segher in a previous review. Most uses of rs6000_pcrel_p are called for the current function. A specialized version for cfun is more efficient for these u

Re: [PING 2][PATCH 2/5] C front end support to detect out-of-bounds accesses to array parameters

On 9/15/20 5:02 PM, Joseph Myers wrote: On Wed, 9 Sep 2020, Martin Sebor via Gcc-patches wrote: Joseph, do you have any concerns with or comments on the most recent patch or is it okay as is? https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552266.html I'm not yet convinced by the logic

Re: [PATCH] preprocessor: Fix ICE with too long line in fmtwarn [PR96935]

On Wed, 2020-09-16 at 11:16 -0400, Marek Polacek wrote: > Here we ICE in char_span::subspan because the offset it gets is -1. > It's -1 because get_substring_ranges_for_loc gets a location whose > column was 0. That only happens in testcases like the attached where > we're dealing with extremely l

Re: Commit 052204fac580 was never sent to gcc-patches

Hi! On Wed, Sep 16, 2020 at 08:37:34PM +0200, Andrea Corallo wrote: > Segher Boessenkool writes: > > > ... and it causes testsuite regressions on Power. We haven't determined > > et if it actually is worse code, but there are testcases that trip on > > it. Either way, all patches should be sen

[OG10] Backporting + merge of GCC 10 into branch

OG10 = devel/omp/gcc-10 e0e1d281472 Fortran: OpenMP - fix simd with (last)private (PR97061) 13ae89bc9c9 Merge remote-tracking branch 'origin/releases/gcc-10' into devel/omp/gcc-10 5a7ae4f073f [OpenMP] Fix mapping of artificial variables (PR94874) 3a6cb32b2c7 OpenMP/Fortran: Permit impure ELEMENT

Re: [PATCH] preprocessor: Fix ICE with too long line in fmtwarn [PR96935]

On Wed, Sep 16, 2020 at 03:15:19PM -0400, David Malcolm via Gcc-patches wrote: > On Wed, 2020-09-16 at 11:16 -0400, Marek Polacek wrote: > > Here we ICE in char_span::subspan because the offset it gets is -1. > > It's -1 because get_substring_ranges_for_loc gets a location whose > > column was 0.

Re: Problem with static const objects and LTO

On 9/16/20 11:52 AM, Joseph Myers wrote: > On Wed, 16 Sep 2020, Jeff Law via Gcc-patches wrote: > >> ISTM this is a lot like the problem we have where we inline functions >> with static data.   To fix those we use STB_GNU_UNIQUE.  But I don't see >> any code in the C front-end which would utilize

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

On 9/15/20 5:15 PM, Joseph Myers wrote: On Wed, 9 Sep 2020, Martin Sebor via Gcc-patches wrote: Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552500.html Aldy provided a bunch of comments on this patch but I'm still looking for a formal approval. This patch is OK. Some testin

Re: [PATCH] aarch64: Add extend-as-extract-with-shift pattern [PR96998]

Hi! On Thu, Sep 10, 2020 at 07:18:01PM +0100, Richard Sandiford wrote: > It's all a bit unfortunate really. Having different representations > for shifts inside and outside MEMs is the Second Great RTL Mistake. Yes... All targets with something that computes shifted addresses (like in a LEA

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

Segher and Richard, Now there are two major concerns from the discussion so far: 1. (From Richard): Inserting zero insns should be done after pass_thread_prologue_and_epilogue since later passes (for example, pass_regrename) might introduce new used caller-saved registers. So, we should

  1   2   >