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++:
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
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'
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
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
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
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
> > > 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)
> > >
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
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
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
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
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
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
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
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
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
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
> >
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
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
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
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
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
> -
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
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
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
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:
> 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
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
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
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
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
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
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
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
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
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
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
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
> >
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
(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
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
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
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
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
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
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
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
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
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
[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
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/
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
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
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
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
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:
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
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
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
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 :(
--
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.
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
-
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
96 matches
Mail list logo
