Re: [PATCH] libgcc: allocate extra space for morestack expansion

On Wed, Feb 10, 2021 at 06:36:07AM -0800, Ian Lance Taylor wrote: > Rain Mark writes: > > > After enabling -fsplit-stack, dynamic stack expansion of the coroutine > > is realized, but calling functions without -fsplit-stack will directly > > expand the space by 1M, which is too wasteful for a sys

[PATCH v2 2/2] MIPS: add builtime option for -mcompact-branches

For R6+ target, it allows to configure gcc to use compact branches only. --- gcc/config.gcc | 12 +++- gcc/doc/install.texi | 19 +++ 2 files changed, 30 insertions(+), 1 deletion(-) diff --git a/gcc/config.gcc b/gcc/config.gcc index 17fea83b2e4..047f5631067 100644 -

[PATCH v2 1/2] MIPS: Not trigger error for pre-R6 and -mcompact-branches=always

For MIPSr6, we may wish to use compact-branches only. Currently, we have to use `always' option, while it is mark as conflict with pre-R6. cc1: error: unsupported combination: ‘mips32r2’ -mcompact-branches=always Just ignore -mcompact-branches=always for pre-R6. This patch also defines __mip

Re: [PATCH 2/3] MIPS: add builtime option for -mcompact-branches

Maciej W. Rozycki 于2021年2月17日周三 上午3:45写道： > > On Tue, 16 Feb 2021, Jeff Law via Gcc-patches wrote: > > > > diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi > > > index 4c38244ae58..6b9520569ba 100644 > > > --- a/gcc/doc/install.texi > > > +++ b/gcc/doc/install.texi > > > @@ -1464,6 +1464,2

Re: [PATCH v2] libiberty(argv.c): Fix memory leak in expandargv.

On 2/18/21 5:08 AM, Ayush Mittal via Gcc-patches wrote: > libiberty/ChangeLog: > > * argv.c (expandargv): free allocated buffer if read fails. I went ahead and committed this, even though we're in stage4 as other projects use libiberty and it's a trivial enough change that they shouldn't h

Re: [pushed] c++: Tuple of self-dependent classes [PR96926]

On 2/18/21 9:22 PM, Jason Merrill wrote: When compiling this testcase, trying to resolve the initialization for the tuple member ends up recursively considering the same set of tuple constructor overloads, and since two of them separately depend on is_constructible, the one we try second fails to

Re: [PATCH] improve warning suppression for inlined functions (PR 98465, 98512)

On 1/19/21 11:58 AM, Martin Sebor via Gcc-patches wrote: > std::string tends to trigger a class of false positive out of bounds > access warnings for code GCC cannot prove is unreachable because of > missing aliasing constrains, and that ends up expanded inline into > user code.  Simply insertin

Re: [PATCH] clear VLA bounds from all arguments (PR 97172)

On 2/18/21 7:23 PM, Martin Sebor wrote: > The fix for PR 97172 that removes non-constant VLA bounds from > attribute access is incomplete: it inadvertently removes the bounds > corresponding to just the first VLA argument, and not from subsequent > arguments. > > The attached change removes the

Re: [PATCH] PR 99133, Mark xxspltiw, xxspltidp, and xxsplti32x as being prefixed

On Wed, Feb 17, 2021 at 06:09:39PM -0600, Segher Boessenkool wrote: > Hi! > > On Wed, Feb 17, 2021 at 12:17:30PM -0500, Michael Meissner wrote: > > I noticed that the power10 xxspltiw, xxspltidp, and xxsplti32dx > > instructions are not flagged as prefixed instructions, which means the > > instruc

RE: [PATCH 1/1] libiberty(argv.c): Fix memory leak in expandargv.

Hi Martin, >> Dynamic memory referenced by 'buffer' was allocated using xmalloc but fails >> to free it >> when jump to 'error' label. >> >> Issue as per static analysis tool. > >The change looks okay to me although I can't approve it. Since GCC >is a regression fixing stage, unless the leak i

Re: [PATCH] rs6000: Use rldimi for vec init instead of shift + ior

Hi Segher & Will, Thanks for your review comments! on 2021/2/19 上午2:33, Segher Boessenkool wrote: > Hi! > > On Wed, Feb 03, 2021 at 02:37:05PM +0800, Kewen.Lin wrote: >> This patch merges the previously approved one[1] and its relied patch >> made by Segher here[2], it's to make unsigned int vec

[committed] jit: fix ICE on BUILT_IN_TRAP [PR99126]

I tried several approaches to fixing this; this seemed the least invasive. Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to trunk as r11-7288-gb258e263e0d74ca1f76aeaac5f4d1abef6b13707. gcc/jit/ChangeLog: PR jit/99126 * jit-builtins.c (gcc::jit::buil

[PATCH] clear VLA bounds from all arguments (PR 97172)

The fix for PR 97172 that removes non-constant VLA bounds from attribute access is incomplete: it inadvertently removes the bounds corresponding to just the first VLA argument, and not from subsequent arguments. The attached change removes the vestigial condition that causes this bug. Since it's

[pushed] c++: Tuple of self-dependent classes [PR96926]

When compiling this testcase, trying to resolve the initialization for the tuple member ends up recursively considering the same set of tuple constructor overloads, and since two of them separately depend on is_constructible, the one we try second fails to instantiate is_constructible because we're

Re: [PATCH] Fix producer string memory leaks

On 2/18/21 2:22 AM, Richard Biener wrote: On Tue, Feb 16, 2021 at 5:09 PM Martin Sebor wrote: On 2/15/21 7:39 AM, Richard Biener wrote: On Mon, Feb 15, 2021 at 2:46 PM Martin Liška wrote: On 2/12/21 5:56 PM, Martin Sebor wrote: On 2/12/21 2:09 AM, Richard Biener via Gcc-patches wrote: On

[committed] [PR96264] LRA: Check output insn hard regs when updating available rematerialization insns

The following patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96264 The patch was successfully bootstrapped and tested on ppc64le. commit e0d3041c9caece8b48be016fa515747eb2746d35 Author: Vladimir Makarov Date: Thu Feb 18 22:40:54 2021 + [PR96264] LRA: Check output insn har

[PATCH] constrain writing one too many bytes" warning (PR 97631)

The "writing one too many bytes" form of -Wstringop-overflow is designed to trigger for strcpy(d, s) calls into allocated destinations whose size is the result of (or depends on) strlen(s). But the warning is in code that's also called from handlers for bounded functions like memcpy and strncpy,

c++: header-unit build capability [PR 99023]

This defect really required building header-units and include translation of pieces of the standard library. This adds smarts to the modules test harness to do that -- accept .X files as the source file, but provide '-x c++-system-header $HDR' in the options. The .X file will be considered by

[PATCH] PR fortran/99147 - Sanitizer detects heap-use-after-free in gfc_add_flavor

Dear all, the PR reports an issue detected with an ASAN instrumented compiler, which can also be verified with valgrind. It appears that the state of gfc_new_block could be such that it should not be dereferenced. Reversing the order of condition evaluation helped. I failed to find out why this

Re: [PATCH] handle VLA of zero length arrays and vice versa (PR 99121)

On 2/18/21 11:03 AM, Jakub Jelinek wrote: On Thu, Feb 18, 2021 at 07:00:52PM +0100, Jakub Jelinek wrote: The size of the VLA is zero regardless of its bound and accessing it is invalid so the warning is expected. Yes, some warning, but not the one you are giving, that is nonsensical. Array sub

c++: Remove obsolete dg-module-headers [PR 99023]

PR99023's testcase is highlighting some missing functionality of the modules test harness. I did have some partial support, but it's only use in one place for a now-obsolete test. This patch expunges that support so I can add better functionality now I understand better what is necessary.

c++: Remove large abi-specific tests [PR 99150]

Remove the two large and incorrectly abi-specific testcases I added. Replacement tests will be forthcoming. PR c++/99150 gcc/testsuite/ * g++.dg/modules/pr99023_a.H: Delete. * g++.dg/modules/pr99023_b.H: Delete. No patch because it exceeds the ml size limit :( --

Re: [PATCH, rs6000] Add Power10 scheduling description

Ping2. On 1/26/21 11:30 AM, Pat Haugen via Gcc-patches wrote: > Ping. > > On 11/13/20 4:04 PM, Pat Haugen via Gcc-patches wrote: >> Add Power10 scheduling description. >> >> This patch adds the Power10 scheduling description. Since power10.md was >> pretty much a complete rewrite (existing versi

Re: [PATCH, rs6000] Update "prefix" attribute for Power10

Ping2. On 1/26/21 11:28 AM, Pat Haugen via Gcc-patches wrote: > Ping. > > On 12/10/20 3:32 PM, Pat Haugen via Gcc-patches wrote: >> Update prefixed attribute for Power10. >> >> >> This patch was broken out from my larger patch to update various attributes >> for >> Power10, in order to make the

Re: [PATCH, rs6000] Update "size" attribute for Power10

Ping2 On 1/26/21 11:27 AM, Pat Haugen via Gcc-patches wrote: > Ping > > On 12/8/20 3:46 PM, Pat Haugen via Gcc-patches wrote: >> Update size attribute for Power10. >> >> >> This patch was broken out from my larger patch to update various attributes >> for >> Power10, in order to make the review

Re: [PATCH v7] Add retain attribute to place symbols in SHF_GNU_RETAIN section

On Thu, Feb 18, 2021 at 7:15 AM Richard Biener wrote: > > On Thu, Feb 18, 2021 at 4:01 PM H.J. Lu wrote: > > > > On Thu, Feb 18, 2021 at 2:25 AM Richard Biener > > wrote: > > > > > > On Thu, Feb 18, 2021 at 5:15 AM H.J. Lu via Gcc-patches > > > wrote: > > > > > > > > On Wed, Feb 17, 2021 at 12:

Re: [PATCH] RISC-V: Zihintpause: add __builtin_riscv_pause

On Thu, Jan 7, 2021 at 12:50 AM Kito Cheng wrote: > My point is tracking info and consistent behavior/scheme with other > extensions, so personally I strongly prefer it should be guarded with > -march. > It is a hint. We should allow it even if the architecture extension is not enabled. For co

Re: [PATCH] c: Fix ICE with -fexcess-precision=standard [PR99136]

On Thu, 18 Feb 2021, Jakub Jelinek via Gcc-patches wrote: > Hi! > > The following testcase ICEs on i686-linux, because c_finish_return wraps > c_fully_folded retval back into EXCESS_PRECISION_EXPR, but when the function > return type is void, we don't call convert_for_assignment on it that would

[PATCH V2 3/5] CTF/BTF testsuites

This commit adds a new testsuite for the CTF debug format. 2021-02-18 Indu Bhagat David Faust gcc/testsuite/ * gcc.dg/debug/btf/btf-1.c: New test. * gcc.dg/debug/btf/btf-2.c: Likewise. * gcc.dg/debug/btf/btf-anonymous-struct-1.c: Likewise. * gcc.d

[PATCH V2 5/5] Enable BTF generation in the BPF backend

This patch changes the BPF GCC backend in order to use the DWARF debug hooks and therefore enables the user to generate BTF debugging information with -gbtf. Generating BTF is crucial when compiling BPF programs, since the CO-RE (compile-once, run-everwhere) mechanism used by the kernel BPF loader

[PATCH V2 4/5] CTF/BTF documentation

This commit documents the new command line options introduced by the CTF and BTF debug formats. 2021-02-18 Indu Bhagat * doc/invoke.texi: Document the CTF and BTF debug info options. --- gcc/doc/invoke.texi | 20 1 file changed, 20 insertions(+) diff --git a/gcc/

[PATCH V2 0/5] Support for the CTF and BTF debug formats

[Changes from V1: - Added support for BTF: implementation, documentation and tests. - The previous code has been refactored to accommodate BTF better. - The command-line option -gt has been renamed to -gctf.] Hi people! Last year we submitted a first patch series introducing support for the CTF d

[PATCH V2 1/5] Add new function lang_GNU_GIMPLE

2021-02-18 Indu Bhagat * langhooks.c (lang_GNU_GIMPLE): New Function. * langhooks.h: New Prototype. --- gcc/langhooks.c | 9 + gcc/langhooks.h | 1 + 2 files changed, 10 insertions(+) diff --git a/gcc/langhooks.c b/gcc/langhooks.c index 2354386f7b4..0082ee9f350 100644

Re: [PATCH] rs6000: Use rldimi for vec init instead of shift + ior

Hi! On Wed, Feb 03, 2021 at 02:37:05PM +0800, Kewen.Lin wrote: > This patch merges the previously approved one[1] and its relied patch > made by Segher here[2], it's to make unsigned int vector init go with > rldimi to merge two integers instead of shift and ior. > gcc/ChangeLog: > > 2020-02-03

Re: [PATCH] split, i386, v5: Fix up df uses in i386 splitters [PR99104]

On Thu, Feb 18, 2021 at 06:29:06PM +, Richard Sandiford wrote: > Yeah, agree that copying 1KB isn't great, but I think we should keep any > optimisations of the copy in recog.[hc]. So IMO it would be better & > safer to go with a plain copy for now and leave optimising it as a nice > future im

Re: [PATCH] rs6000: Use rldimi for vec init instead of shift + ior

On Thu, Feb 18, 2021 at 11:58:59AM -0600, will schmidt wrote: > On Wed, 2021-02-03 at 14:37 +0800, Kewen.Lin via Gcc-patches wrote: > > This patch merges the previously approved one[1] and its relied patch > > I don't see the review for [1] in the archives. I said: Can you make a different te

Re: [PATCH] split, i386, v5: Fix up df uses in i386 splitters [PR99104]

Jakub Jelinek writes: > On Wed, Feb 17, 2021 at 10:30:06AM +, Richard Sandiford wrote: >> Hmm. I think that just means that the optimisation performed by >> the copy constructor isn't valid in practice (even if it should be >> in principle). Guess this is the curse of manipulating data struc

Re: [PATCH] handle VLA of zero length arrays and vice versa (PR 99121)

On Thu, Feb 18, 2021 at 07:00:52PM +0100, Jakub Jelinek wrote: > > The size of the VLA is zero regardless of its bound and accessing > > it is invalid so the warning is expected. > > Yes, some warning, but not the one you are giving, that is nonsensical. > Array subscript 0 is not outside of array

Re: [PATCH] rs6000: Convert the vector element register to SImode [PR98914]

Hi! On Thu, Feb 18, 2021 at 10:46:11AM -0600, will schmidt wrote: > On Wed, 2021-02-03 at 03:01 -0600, Xionghu Luo via Gcc-patches wrote: > > v[k] will also be expanded to IFN VEC_SET if k is long type when > > built > > with -Og. -O0 didn't exposed the issue due to v is TREE_ADDRESSABLE, > > -O1

Re: [PATCH] handle VLA of zero length arrays and vice versa (PR 99121)

On Thu, Feb 18, 2021 at 09:24:28AM -0700, Martin Sebor via Gcc-patches wrote: > > Consider a different (GNU C, in C++ struct S has non-zero size) testcase: > > void f (void*); > > > > void g (int n) > > { > >struct S {} a[n]; > >((int*)a)[0] = 0; > >f (a); > > } > > yyy.c:6:12: warning

Re: [PATCH] rs6000: Use rldimi for vec init instead of shift + ior

On Wed, 2021-02-03 at 14:37 +0800, Kewen.Lin via Gcc-patches wrote: > Hi, > Hi, > This patch merges the previously approved one[1] and its relied patch I don't see the review for [1] in the archives. > made by Segher here[2], it's to make unsigned int vector init go with > rldimi to merge

[RFC][patch for gcc12][version 1] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

(CC’ing Kees Cook on this topic) Hi, This is the first version of the complete patch for the new security feature for GCC: Initialize automatic variables with new first class option -ftrivial-auto-var-init=[uninitialized|pattern|zero] and a new variable attribute “uninitialized” to exclude

Re: [PATCH 1/1] libiberty(argv.c): Fix memory leak in expandargv.

On 2/18/21 3:58 AM, Ayush Mittal via Gcc-patches wrote: Dynamic memory referenced by 'buffer' was allocated using xmalloc but fails to free it when jump to 'error' label. Issue as per static analysis tool. The change looks okay to me although I can't approve it. Since GCC is a regression fix

Re: [PATCH] ipa: Fix resolving speculations through cgraph_edge::set_call_stmt (PR 98078)

Hi, ping, please. Martin On Thu, Jan 21 2021, Martin Jambor wrote: > Hi, > > in the PR 98078 testcase, speculative call-graph edges which were > created by IPA-CP are confirmed during inlining but > cgraph_edge::set_call_stmt does not take it very well. > > The function enters the update_specul

Re: Patch for PR analyzer/98797

Hi David, Please find my revised patch attached. You should find all items addressed. I have bootstrapped and rerun the testsuite (gcc and g++ only). Also, you should have seen my legal paperwork go in. 1) The commit message has been updated to reflect the nomenclature in the testsuite, as well

Re: [PATCH] rs6000: Convert the vector element register to SImode [PR98914]

On Wed, 2021-02-03 at 03:01 -0600, Xionghu Luo via Gcc-patches wrote: Hi, > v[k] will also be expanded to IFN VEC_SET if k is long type when > built > with -Og. -O0 didn't exposed the issue due to v is TREE_ADDRESSABLE, > -O1 and above also didn't capture it because of v[k] is not optimized > to

RE: [AArch64] PR98657: Fix vec_duplicate creation in SVE's 3

Hi Andre, > -Original Message- > From: Andre Vieira (lists) > Sent: 17 February 2021 14:17 > To: gcc-patches@gcc.gnu.org > Cc: Kyrylo Tkachov ; Richard Sandiford > > Subject: [AArch64] PR98657: Fix vec_duplicate creation in SVE's > 3 > > Hi, > > This patch prevents generating a vec_dup

Re: [PATCH] Add -fgnu-retain/-fno-gnu-retain

On 2/18/21 3:19 AM, Richard Biener via Binutils wrote: > On Wed, Feb 17, 2021 at 12:25 PM Jozef Lawrynowicz > wrote: >> On Tue, Feb 16, 2021 at 05:45:47PM +0100, Jakub Jelinek via Gcc-patches >> wrote: >>> On Mon, Feb 15, 2021 at 02:35:07PM -0800, H.J. Lu via Gcc-patches wrote: When build

Re: [PATCH] handle VLA of zero length arrays and vice versa (PR 99121)

On 2/18/21 2:30 AM, Jakub Jelinek wrote: On Wed, Feb 17, 2021 at 02:11:43PM -0700, Martin Sebor wrote: On 2/17/21 1:47 PM, Jakub Jelinek wrote: On Wed, Feb 17, 2021 at 01:27:55PM -0700, Martin Sebor wrote: Not in this patch, but I've looked at what maxobjsize is and wonder why the roundtrip tr

[PATCH v2] libiberty(argv.c): Fix memory leak in expandargv.

libiberty/ChangeLog: * argv.c (expandargv): free allocated buffer if read fails. Signed-off-by: Ayush Mittal Signed-off-by: Maninder Singh --- v1 -> v2: corrected formatting and changelog commit libiberty/argv.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/l

Re: [PATCH] profiling: fix streaming of TOPN counters

On Thu, Feb 18, 2021 at 12:35 PM Martin Liška wrote: > > On 2/18/21 11:02 AM, Richard Biener wrote: > > On Thu, Feb 18, 2021 at 10:46 AM Martin Liška wrote: > >> > >> On 2/18/21 10:31 AM, Richard Biener wrote: > >>> On Wed, Feb 17, 2021 at 2:16 PM Martin Liška wrote: > > On 2/17/21 9:3

Re: [PATCH v7] Add retain attribute to place symbols in SHF_GNU_RETAIN section

On Thu, Feb 18, 2021 at 4:01 PM H.J. Lu wrote: > > On Thu, Feb 18, 2021 at 2:25 AM Richard Biener > wrote: > > > > On Thu, Feb 18, 2021 at 5:15 AM H.J. Lu via Gcc-patches > > wrote: > > > > > > On Wed, Feb 17, 2021 at 12:50 PM H.J. Lu wrote: > > > > > > > > On Wed, Feb 17, 2021 at 12:14 PM Jaku

Re: [PATCH] Add -fgnu-retain/-fno-gnu-retain

On Thu, Feb 18, 2021 at 03:38:46PM +0100, Jakub Jelinek via Gcc-patches wrote: > On Thu, Feb 18, 2021 at 02:22:35PM +, Jozef Lawrynowicz wrote: > > I think it is a enhancement, and true to the spirit of the attribute, > > for "used" to save a symbol from linker garbage collection. > > > > Why

[PATCH v7] Add retain attribute to place symbols in SHF_GNU_RETAIN section

On Thu, Feb 18, 2021 at 2:25 AM Richard Biener wrote: > > On Thu, Feb 18, 2021 at 5:15 AM H.J. Lu via Gcc-patches > wrote: > > > > On Wed, Feb 17, 2021 at 12:50 PM H.J. Lu wrote: > > > > > > On Wed, Feb 17, 2021 at 12:14 PM Jakub Jelinek wrote: > > > > > > > > On Wed, Feb 17, 2021 at 12:04:34PM

Re: [PATCH] Add -fgnu-retain/-fno-gnu-retain

On Thu, Feb 18, 2021 at 02:22:35PM +, Jozef Lawrynowicz wrote: > I think it is a enhancement, and true to the spirit of the attribute, > for "used" to save a symbol from linker garbage collection. > > Why should "used" mean: > Save this symbol from compiler optimization, but allow the linker

Re: [PATCH] Add -fgnu-retain/-fno-gnu-retain

On Thu, Feb 18, 2021 at 01:08:54PM +0100, Jakub Jelinek via Gcc-patches wrote: > On Thu, Feb 18, 2021 at 12:00:59PM +, Jozef Lawrynowicz wrote: > > If we can add ".retain " to GAS, then I agree, current GCC > > SHF_GNU_RETAIN behavior should be removed. For GCC 12 we leverage > > .retain to imp

Re: c++: Macros need to be GTY-reachable [PR 99023]

On Wed, Feb 17, 2021 at 01:46:37PM -0500, Nathan Sidwell wrote: > I'd missed that macros were allocated from GC storage, and that they can > become unattached from an identifier, and therefore not GC-reachable. > And then bad things happen. Fixed by making the module machinery's > ref

Re: [PATCH] Add -fgnu-retain/-fno-gnu-retain

On Thu, Feb 18, 2021 at 11:22:42PM +1030, Alan Modra via Binutils wrote: > On Wed, Feb 17, 2021 at 11:23:12AM +, Jozef Lawrynowicz wrote: > > In previous discussions, it seemed to me that there was general support > > for the "used" attribute implying SHF_GNU_RETAIN and saving symbols from > >

Re: [r11-7271 Regression] FAIL: g++.dg/modules/pr99023_a.H (test for excess errors) on Linux/x86_64

On 2/18/21 3:03 AM, Jakub Jelinek wrote: On Wed, Feb 17, 2021 at 02:19:11PM -0800, sunil.k.pandey via Gcc-patches wrote: On Linux/x86_64, Yeah: FAIL: g++.dg/modules/pr99023_a.H (test for excess errors) Excess errors: ../../..//src/libstdc++-v3/libsupc++/initializer_list:47:11: fatal error: d

Re: [PATCH] c++: Fix -std=c++20 ICE on virtual method call [PR99132]

On 2/18/21 3:30 AM, Jakub Jelinek wrote: Hi! On the following testcase we ICE in C++20 mode during cp_get_callee_fndecl -> constexpr evaluation. It is only in C++20 mode on this testcase because virtual methods can't be constexpr in C++17 and earlier and so potential_constant_expression_1 reject

Re: [PATCH] middle-end/99122 - Issues with VLA parameter inlining

On Thu, 18 Feb 2021, Jakub Jelinek wrote: > On Thu, Feb 18, 2021 at 01:37:29PM +0100, Richard Biener wrote: > > The following instructs IPA not to inline calls with VLA parameters > > and adjusts inlining not to create invalid view-converted VLA > > parameters on mismatch and makes the error_mark

Re: [PATCH] middle-end/99122 - Issues with VLA parameter inlining

On Thu, Feb 18, 2021 at 01:37:29PM +0100, Richard Biener wrote: > The following instructs IPA not to inline calls with VLA parameters > and adjusts inlining not to create invalid view-converted VLA > parameters on mismatch and makes the error_mark paths with debug > stmts actually work. > > The fi

Re: [PATCH] match.pd: Restrict clz cmp 0 replacement by single_use, PR99142

On Thu, Feb 18, 2021 at 1:21 PM Hans-Peter Nilsson wrote: > > > From: Richard Biener via Gcc-patches > > Date: Thu, 18 Feb 2021 11:12:26 +0100 > > > On Thu, Feb 18, 2021 at 12:35 AM Hans-Peter Nilsson via Gcc-patches > > wrote: > > > > > > If we're not going to eliminate the clz, it's better for

[PATCH 2/2] IBM Z: Fix long double <-> DFP conversions

When switching the s390 backend to store long doubles in vector registers, the patterns for long double <-> DFP conversions were forgotten. This did not cause observable problems so far, because libdfp calls are emitted instead of pfpo. However, when building libdfp itself, this leads to infinite

[PATCH 1/2] IBM Z: Improve FPRX2 <-> TF conversions

gcc/ChangeLog: * config/s390/vector.md (*fprx2_to_tf): Rename to fprx2_to_tf, add memory alternative. (tf_to_fprx2): New pattern. --- gcc/config/s390/vector.md | 36 +++- 1 file changed, 31 insertions(+), 5 deletions(-) diff --git a/gcc/con

[PATCH 0/2] IBM Z: Fix long double <-> DFP conversions

This series fixes PR99134. Patch 1 is factored out from the pending [1], patch 2 is the actual fix. Bootstrapped and regtested on s390x-redhat-linux. Ok for master? [1] https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564380.html Ilya Leoshkevich (2): IBM Z: Improve FPRX2 <-> TF conver

Re: [PATCH] Add -fgnu-retain/-fno-gnu-retain

On Wed, Feb 17, 2021 at 11:23:12AM +, Jozef Lawrynowicz wrote: > In previous discussions, it seemed to me that there was general support > for the "used" attribute implying SHF_GNU_RETAIN and saving symbols from > linker garbage collection[1]. Of course, the current implementation > results in

[PATCH] middle-end/99122 - Issues with VLA parameter inlining

The following instructs IPA not to inline calls with VLA parameters and adjusts inlining not to create invalid view-converted VLA parameters on mismatch and makes the error_mark paths with debug stmts actually work. The first part avoids the ICEs with the testcases already. Bootstrapped and teste

Re: [PATCH] match.pd: Restrict clz cmp 0 replacement by single_use, PR99142

> From: Richard Biener via Gcc-patches > Date: Thu, 18 Feb 2021 11:12:26 +0100 > On Thu, Feb 18, 2021 at 12:35 AM Hans-Peter Nilsson via Gcc-patches > wrote: > > > > If we're not going to eliminate the clz, it's better for the > > comparison to use that result than its input, so we don't > > ext

[PATCH] C++: target attribute - local decl

We crash when target attribute get_function_versions_dispatcher is called for a function that is not registered in call graph. This fixes that by emitting a new error. Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Ready to be installed? Thanks, Martin gcc/cp/ChangeLog:

Re: [PATCH] Add -fgnu-retain/-fno-gnu-retain

On Thu, Feb 18, 2021 at 12:00:59PM +, Jozef Lawrynowicz wrote: > If we can add ".retain " to GAS, then I agree, current GCC > SHF_GNU_RETAIN behavior should be removed. For GCC 12 we leverage > .retain to implement the functionality where "used" saves symbols form > linker garbage collection, w

Re: [PATCH] Add -fgnu-retain/-fno-gnu-retain

On Thu, Feb 18, 2021 at 11:19:50AM +0100, Richard Biener via Binutils wrote: > On Wed, Feb 17, 2021 at 12:25 PM Jozef Lawrynowicz > wrote: > > > > On Tue, Feb 16, 2021 at 05:45:47PM +0100, Jakub Jelinek via Gcc-patches > > wrote: > > > On Mon, Feb 15, 2021 at 02:35:07PM -0800, H.J. Lu via Gcc-pat

Re: [PATCH] profiling: fix streaming of TOPN counters

On 2/18/21 11:02 AM, Richard Biener wrote: On Thu, Feb 18, 2021 at 10:46 AM Martin Liška wrote: On 2/18/21 10:31 AM, Richard Biener wrote: On Wed, Feb 17, 2021 at 2:16 PM Martin Liška wrote: On 2/17/21 9:36 AM, Martin Liška wrote: I'll write it even more robust... This is more elegant a

Re: [PATCH 1/1] libiberty(argv.c): Fix memory leak in expandargv.

On Thu, 18 Feb 2021 at 16:32, Ayush Mittal via Gcc-patches wrote: > > Dynamic memory referenced by 'buffer' was allocated using xmalloc but fails > to free it > when jump to 'error' label. > > Issue as per static analysis tool. > > Signed-off-by: Ayush Mittal > Signed-off-by: Maninder Singh > -

[PATCH 1/1] libiberty(argv.c): Fix memory leak in expandargv.

Dynamic memory referenced by 'buffer' was allocated using xmalloc but fails to free it when jump to 'error' label. Issue as per static analysis tool. Signed-off-by: Ayush Mittal Signed-off-by: Maninder Singh --- libiberty/ChangeLog | 4 libiberty/argv.c| 5 - 2 files changed, 8 i

Re: [PATCH] match.pd: Restrict clz cmp 0 replacement by single_use, PR99142

On Thu, Feb 18, 2021 at 11:22 AM Jakub Jelinek wrote: > > On Thu, Feb 18, 2021 at 11:12:26AM +0100, Richard Biener via Gcc-patches > wrote: > > On Thu, Feb 18, 2021 at 12:35 AM Hans-Peter Nilsson via Gcc-patches > > wrote: > > > > > > If we're not going to eliminate the clz, it's better for the

Re: [PATCH v6] Add retain attribute to place symbols in SHF_GNU_RETAIN section

On Thu, Feb 18, 2021 at 5:15 AM H.J. Lu via Gcc-patches wrote: > > On Wed, Feb 17, 2021 at 12:50 PM H.J. Lu wrote: > > > > On Wed, Feb 17, 2021 at 12:14 PM Jakub Jelinek wrote: > > > > > > On Wed, Feb 17, 2021 at 12:04:34PM -0800, H.J. Lu wrote:> > > > > > + /* For -fretain-used-symbol, a "used

Re: [PATCH] match.pd: Restrict clz cmp 0 replacement by single_use, PR99142

On Thu, Feb 18, 2021 at 11:12:26AM +0100, Richard Biener via Gcc-patches wrote: > On Thu, Feb 18, 2021 at 12:35 AM Hans-Peter Nilsson via Gcc-patches > wrote: > > > > If we're not going to eliminate the clz, it's better for the > > comparison to use that result than its input, so we don't > > exte

Re: [PATCH] Add -fgnu-retain/-fno-gnu-retain

On Wed, Feb 17, 2021 at 12:25 PM Jozef Lawrynowicz wrote: > > On Tue, Feb 16, 2021 at 05:45:47PM +0100, Jakub Jelinek via Gcc-patches wrote: > > On Mon, Feb 15, 2021 at 02:35:07PM -0800, H.J. Lu via Gcc-patches wrote: > > > When building Linux kernel, ld in bninutils 2.36 with GCC 11 generates > >

Re: [PATCH v2] Add -fgnu-retain to place used symbols in SHF_GNU_RETAIN section

On Wed, Feb 17, 2021 at 3:33 PM Jakub Jelinek via Gcc-patches wrote: > > On Tue, Feb 16, 2021 at 11:59:21AM -0800, H.J. Lu wrote: > > PR target/99113 > > * common.opt: Add -fgnu-retain. > > I'm not sure -fgnu-retain as the option name. > Wouldn't say -fretain-used-vars be better? -fre

Re: [PATCH] match.pd: Restrict clz cmp 0 replacement by single_use, PR99142

On Thu, Feb 18, 2021 at 12:35 AM Hans-Peter Nilsson via Gcc-patches wrote: > > If we're not going to eliminate the clz, it's better for the > comparison to use that result than its input, so we don't > extend the lifetime of the input. Also, an additional use > of the result is more likely cheape

Re: [PATCH] profiling: fix streaming of TOPN counters

On Thu, Feb 18, 2021 at 10:46 AM Martin Liška wrote: > > On 2/18/21 10:31 AM, Richard Biener wrote: > > On Wed, Feb 17, 2021 at 2:16 PM Martin Liška wrote: > >> > >> On 2/17/21 9:36 AM, Martin Liška wrote: > >>> I'll write it even more robust... > >> > >> This is more elegant approach I've just t

Re: [PATCH] profiling: fix streaming of TOPN counters

On 2/18/21 10:31 AM, Richard Biener wrote: On Wed, Feb 17, 2021 at 2:16 PM Martin Liška wrote: On 2/17/21 9:36 AM, Martin Liška wrote: I'll write it even more robust... This is more elegant approach I've just tested on the instrumented clang. Patch can bootstrap on x86_64-linux-gnu and sur

Re: [PATCH] profiling: fix streaming of TOPN counters

On Wed, Feb 17, 2021 at 2:16 PM Martin Liška wrote: > > On 2/17/21 9:36 AM, Martin Liška wrote: > > I'll write it even more robust... > > This is more elegant approach I've just tested on the instrumented clang. > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > Ready t

Re: [PATCH] i386: Avoid C++ global constructors in every object that includes i386.h

On Thu, Feb 18, 2021 at 09:42:00AM +0100, Richard Biener wrote: > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > OK. Can you quickly try whether GCC 4.8 is happy with it? Yes, at least non-bootstrap build with GCC 4.8.5 is just fine with it. Jakub

Re: [PATCH] handle VLA of zero length arrays and vice versa (PR 99121)

On Wed, Feb 17, 2021 at 02:11:43PM -0700, Martin Sebor wrote: > On 2/17/21 1:47 PM, Jakub Jelinek wrote: > > On Wed, Feb 17, 2021 at 01:27:55PM -0700, Martin Sebor wrote: > > > > Not in this patch, but I've looked at what maxobjsize is and wonder why > > the roundtrip tree -> HOST_WIDE_INT -> offs

Re: [PATCH] Fix producer string memory leaks

On Tue, Feb 16, 2021 at 5:09 PM Martin Sebor wrote: > > On 2/15/21 7:39 AM, Richard Biener wrote: > > On Mon, Feb 15, 2021 at 2:46 PM Martin Liška wrote: > >> > >> On 2/12/21 5:56 PM, Martin Sebor wrote: > >>> On 2/12/21 2:09 AM, Richard Biener via Gcc-patches wrote: > On Thu, Feb 11, 2021 a

Re: [PATCH] Change semantics of -frecord-gcc-switches and add -frecord-gcc-switches-format.

On 2/16/21 10:17 PM, Qing Zhao wrote: Hello, What’s the status of this patch now? Is there any major technical issue with the patch? Our company has been waiting for this patch for almost one year, we need it for our important application. Hello. You are right, we've been waiting for quite

Re: [PATCH v2 2/2] ada: add 128bit operation to MIPS N32 and N64

> > > For MIPS N64 and N32: > > > add GNATRTL_128BIT_PAIRS to LIBGNAT_TARGET_PAIRS > > > add GNATRTL_128BIT_OBJS to EXTRA_GNATRTL_NONTASKING_OBJS > > > > > > gcc/ada/ChangeLog: > > > PR ada/98996 > > > * Makefile.rtl (LIBGNAT_TARGET_PAIRS, EXTRA_GNATRTL_NONTASKING_OBJS) > > >

Re: [PATCH v2 2/2] ada: add 128bit operation to MIPS N32 and N64

Arnaud Charlet 于2021年2月18日周四 下午3:38写道： > > > For MIPS N64 and N32: > > add GNATRTL_128BIT_PAIRS to LIBGNAT_TARGET_PAIRS > > add GNATRTL_128BIT_OBJS to EXTRA_GNATRTL_NONTASKING_OBJS > > > > gcc/ada/ChangeLog: > > PR ada/98996 > > * Makefile.rtl (LIBGNAT_TARGET_PAIRS, EXTRA_GNATRTL_N

Re: [PATCH] i386: Avoid C++ global constructors in every object that includes i386.h

On Wed, 17 Feb 2021, Jakub Jelinek wrote: > Hi! > > When looking at recog.o when working on the recog.[ch] changes to make sure > I have not introduced runtime construction of recog_data variable, I have > noticed that at least in unoptimized build, every single *.o file that > included i386.h ha

Re: [PATCH] array-bounds, v2: Fix up ICE on overaligned variables [PR99109]

On Thu, 18 Feb 2021, Jakub Jelinek wrote: > On Wed, Feb 17, 2021 at 02:38:04PM -0700, Martin Sebor via Gcc-patches wrote: > > How does build_printable_array_type sound? > > This adjusted version also works and has been successfully > bootstrapped/regtested on x86_64-linux and i686-linux. > > Ok

[PATCH] array-bounds, v2: Fix up ICE on overaligned variables [PR99109]

On Wed, Feb 17, 2021 at 02:38:04PM -0700, Martin Sebor via Gcc-patches wrote: > How does build_printable_array_type sound? This adjusted version also works and has been successfully bootstrapped/regtested on x86_64-linux and i686-linux. Ok for trunk? 2021-02-18 Jakub Jelinek PR middl

[PATCH] c: Fix ICE with -fexcess-precision=standard [PR99136]

Hi! The following testcase ICEs on i686-linux, because c_finish_return wraps c_fully_folded retval back into EXCESS_PRECISION_EXPR, but when the function return type is void, we don't call convert_for_assignment on it that would then be fully folded again, but just put the retval into RETURN_EXPR'

[PATCH] c++: Fix -std=c++20 ICE on virtual method call [PR99132]

Hi! On the following testcase we ICE in C++20 mode during cp_get_callee_fndecl -> constexpr evaluation. It is only in C++20 mode on this testcase because virtual methods can't be constexpr in C++17 and earlier and so potential_constant_expression_1 rejects it earlier. And the ICE is caused by gene

Re: [r11-7271 Regression] FAIL: g++.dg/modules/pr99023_a.H (test for excess errors) on Linux/x86_64

On Wed, Feb 17, 2021 at 02:19:11PM -0800, sunil.k.pandey via Gcc-patches wrote: > On Linux/x86_64, > > d8889c99aab4b599aa7ceb7079e69a9766171336 is the first bad commit > commit d8889c99aab4b599aa7ceb7079e69a9766171336 > Author: Nathan Sidwell > Date: Wed Feb 17 10:43:21 2021 -0800 > > c++: