VN currently replaces a load of a 16 byte entity 128 bits of precision
(TImode) with the result of a load of a 16 byte entity with 80 bits of
mode precision (XFmode). That will go downhill since if the padding
bits are not actually filled with memory contents those bits are
missing.
I'm
Hi all,
This patch is part of a series that adds support for the ARMv8.m Custom
Datapath Extension.
This patch defines the options cdecp0-cdecp7 for CLI to enable the CDE on
corresponding coprocessor 0-7.
It also adds new check-effective for CDE feature.
ISA has been announced at
Hi.
I'm sending extended version of the patch where I address Honza's note
about backward compatibility. So I add a next section _lto.extension_symtab
where I put new bits. With that, new LTO bytecode can be opened with older
LTO plugin.
Moreover, I've also tested lto.exp tests and binutils
On Thu, Mar 12, 2020 at 4:06 AM Jeff Law via Gcc-patches
wrote:
>
> On Wed, 2020-03-11 at 13:04 +, Nidal Faour via Gcc-patches wrote:
> > This patch is a code density oriented and attempt to remove redundant
> > sign/zero
> > extension from assignment statement.
> > The approach taken is to
The answer is simple:
diff --git a/lto-plugin/lto-plugin.c b/lto-plugin/lto-plugin.c
index fbe2c6885f0..83f1ac38d37 100644
--- a/lto-plugin/lto-plugin.c
+++ b/lto-plugin/lto-plugin.c
@@ -1033,6 +1033,7 @@ static int
process_lto_section (void *data, const char *name, off_t offset, off_t len)
{
Hi Srinath,
On 3/10/20 6:19 PM, Srinath Parvathaneni wrote:
Hello Kyrill,
This patch addresses all the comments in patch version v2.
(version v2)
https://gcc.gnu.org/pipermail/gcc-patches/2020-February/540416.html
Hello,
This patch is part of MVE ACLE intrinsics framework.
This
"J.W. Jagersma" writes:
> On 2020-03-09 13:13, Richard Sandiford wrote:
>> Thanks for doing this.
>
> Hi Richard, thanks for your response.
>
>> "J.W. Jagersma" writes:
>>> On 2020-03-07 20:20, Segher Boessenkool wrote:
Some comments:
> +When non-call exceptions
Hi Srinath,
On 3/10/20 6:19 PM, Srinath Parvathaneni wrote:
Hello Kyrill,
This patch addresses all the comments in patch version v2.
(version v2)
https://gcc.gnu.org/pipermail/gcc-patches/2020-February/540417.html
Hello,
This patch is part of MVE ACLE intrinsics framework.
The
On Thu, Mar 12, 2020 at 10:15 AM Andre Vieira (lists)
wrote:
>
> Hi all,
>
> This is a prototype I have put together to look at the feasibility and
> profitability of vectorizing loops with breaks as suggested in PR 91246.
> I am posting this here for comments as I am curious what your opinions
>
I'm getting this ICE with -mabi=ilp32:
during RTL pass: fwprop1
/opt/gcc/gcc-20200312/gcc/testsuite/gcc.dg/pr94121.c: In function 'bar':
/opt/gcc/gcc-20200312/gcc/testsuite/gcc.dg/pr94121.c:16:1: internal compiler
error: in decompose, at rtl.h:2279
0xca5063 wi::int_traits >::decompose(l
Hi all,
This is a prototype I have put together to look at the feasibility and
profitability of vectorizing loops with breaks as suggested in PR 91246.
I am posting this here for comments as I am curious what your opinions
are on my approach. I don't expect much attention to this in stage 4,
Please CC libstd...@gcc.gnu.org for all libstdc++ patches, as per
https://gcc.gnu.org/lists.html
On 11/03/20 21:24 -0700, Fangrui Song wrote:
Alternatively, we can delete it, because no user code should call it.
It may be weird that libc is expected to define this function.
This function is a
Hi!
scripts/update_web_docs_git -r 9.3.0 -d gcc-9.3.0
failed after the sourceware upgrade, there is no python-sphinx10 package and
python3-sphinx is new enough that the docs build succeeded.
Ok for trunk?
2020-03-12 Jakub Jelinek
* update_web_docs_git: Use
Hi.
I noticed a strange error during parsing of .gnu.lto_.lto section
in LTO plugin:
$ cat bss.c
int global_zero;
int global_one = 1;
int main() { return 0; }
$ gcc -flto bss.c -c
$ gcc bss.o
read version 9.0
while:
$ ar r x.a bss.o
ar: creating x.a
$ gcc x.a
read version 13617.13368
$
This test fails in the Fedora RPM build (but not elsewhere, for unknown
reasons). The warning is correct, we're passing a null pointer.
* testsuite/tr1/8_c_compatibility/cstdlib/functions.cc: Do not pass
a null pointer to functions with nonnull(1) attribute.
Tested x86_64-linux,
On Wed, Mar 11, 2020 at 8:53 PM Jeff Law wrote:
>
> On Sat, 2020-02-29 at 06:16 -0800, H.J. Lu wrote:
> > There is no need to set mode attribute to XImode since ix86_output_ssemov
> > can properly encode xmm16-xmm31 registers with and without AVX512VL.
> >
> > Remove ext_sse_reg_operand since it
Hi Srinath,
On 3/10/20 6:19 PM, Srinath Parvathaneni wrote:
Hello Kyrill,
This patch addresses all the comments in patch version v2.
(version v2)
https://gcc.gnu.org/pipermail/gcc-patches/2020-February/540415.html
Hello,
This patch creates the required framework for MVE ACLE
On Thu, Mar 12, 2020 at 01:58:20AM -0400, Jason Merrill wrote:
> > + if (reuse && nelts < CONSTRUCTOR_NELTS (new_init))
> > + {
> > + vec *v = NULL;
> > + if (nelts)
>
> vec_alloc does nothing if nelts is 0, so this test seems unnecessary. OK
> either way.
I wasn't sure, but now
On Thu, 12 Mar 2020, Jakub Jelinek wrote:
> Hi!
>
> When looking into PR94134, I've noticed bugs in the
> ASM_OUTPUT_ALIGNED_DECL_LOCAL documentation. varasm.c has:
> #if defined ASM_OUTPUT_ALIGNED_DECL_LOCAL
> unsigned int align = symtab_node::get (decl)->definition_alignment ();
>
On Thu, 12 Mar 2020, Jakub Jelinek wrote:
> Hi!
>
> As the testcase shows, if DSE decides to head trim {mem{set,cpy,move},strncpy}
> and the call has lhs, it is incorrect to leave the lhs as is, because it
> will then point to the adjusted address (base + head_trim) instead of the
> original
On Thu, Mar 12, 2020 at 09:20:08AM +0100, Richard Biener wrote:
> On Thu, 12 Mar 2020, Jakub Jelinek wrote:
>
> > Hi!
> >
> > As the testcase shows, if DSE decides to head trim
> > {mem{set,cpy,move},strncpy}
> > and the call has lhs, it is incorrect to leave the lhs as is, because it
> > will
Hi!
When looking into PR94134, I've noticed bugs in the
ASM_OUTPUT_ALIGNED_DECL_LOCAL documentation. varasm.c has:
#if defined ASM_OUTPUT_ALIGNED_DECL_LOCAL
unsigned int align = symtab_node::get (decl)->definition_alignment ();
ASM_OUTPUT_ALIGNED_DECL_LOCAL (asm_out_file, decl, name,
(I assume that should have gone to gcc-patches@ and fortran@ as well.)
Forwarded Message
Subject:Re: [Fortran, OpenACC] Reject vars of different scope in $acc
declare (PR94120)
Date: Tue, 10 Mar 2020 18:02:41 +
From: Paul Richard Thomas
To: Tobias Burnus
Hi!
As the testcase shows, if DSE decides to head trim {mem{set,cpy,move},strncpy}
and the call has lhs, it is incorrect to leave the lhs as is, because it
will then point to the adjusted address (base + head_trim) instead of the
original base.
The following patch fixes that by dropping the lhs
On Thu, 12 Mar 2020, Jakub Jelinek wrote:
> On Thu, Mar 12, 2020 at 09:20:08AM +0100, Richard Biener wrote:
> > On Thu, 12 Mar 2020, Jakub Jelinek wrote:
> >
> > > Hi!
> > >
> > > As the testcase shows, if DSE decides to head trim
> > > {mem{set,cpy,move},strncpy}
> > > and the call has lhs,
On Thu, Mar 12, 2020 at 11:01 AM Richard Sandiford
wrote:
>
> "J.W. Jagersma" writes:
> > On 2020-03-09 13:13, Richard Sandiford wrote:
> >> Thanks for doing this.
> >
> > Hi Richard, thanks for your response.
> >
> >> "J.W. Jagersma" writes:
> >>> On 2020-03-07 20:20, Segher Boessenkool wrote:
On 3/12/20 1:55 PM, Jan Hubicka wrote:
gcc/ChangeLog:
2020-03-12 Martin Liska
* lto-section-in.c: Add extension_symtab.
* lto-streamer-out.c (write_symbol_extension_info):
New.
(produce_symtab_extension): New.
(produce_asm_for_decls): Stream also
On 3/11/20 3:30 PM, Martin Sebor wrote:
On 3/11/20 2:10 PM, Jason Merrill wrote:
On 3/11/20 12:57 PM, Martin Sebor wrote:
On 3/9/20 6:08 PM, Jason Merrill wrote:
On 3/9/20 5:39 PM, Martin Sebor wrote:
On 3/9/20 1:40 PM, Jason Merrill wrote:
On 3/9/20 12:31 PM, Martin Sebor wrote:
On
Hello,
The following patch removes the CTRLREG_CPEN register variable.
According to the RX software manual:
https://www.renesas.com/cn/en/doc/products/mpumcu/doc/rx_family/r01us0316ej0100-rxv3sm.pdf
there is no control register called cpen.
Regression test is OK, without additional fails, and
Segher:
>
> From the GCC manual:
>
> -mmfcrfp4 2.01
> -mpopcntb p5 2.02
> -mfprndp5+ 2.04 ("info gcc" says 2.03, that's wrong? But the
> ISA
> says this is 2.02 even? Now what!)
> -mcmpb p6 2.05
> -mpopcntd p7 2.06
>
> (and there are more,
Hi!
After the sourceware migration, seems the gcc_release -u gccadmin ...
created directories had 2700 permissions instead of 2755.
Fxed thusly, committed to trunk.
2020-03-12 Jakub Jelinek
* gcc_release (upload_files): Without -l, pass -m 755 to the mkdir
command invoked
On Thu, Mar 12, 2020 at 12:03:08PM -0600, Jeff Law wrote:
> On Sat, 2020-02-08 at 10:41 -0600, Segher Boessenkool wrote:
> > I don't think each stanza of code should use it's own "noop-ness", no.
> Richard's patch is actually better than mine in that regard as it handles mem
> and
> reg nop moves
I would swear that I selected "reply all" but... Never mind, you put it right!
Cheers
Paul
On Thu, 12 Mar 2020 at 08:44, Tobias Burnus wrote:
>
> (I assume that should have gone to gcc-patches@ and fortran@ as well.)
>
>
> Forwarded Message
> Subject:Re: [Fortran,
On Thu, 2020-03-12 at 13:23 -0500, Segher Boessenkool wrote:
>
> > > I don't know if this patch makes matters worse or not. It doesn't seem
> > > suitable for stage 4 though. And Richard said the cse.c part breaks
> > > rs6000, if that is true, yes I do object ;-)
> > The rs6000 port breakage
In build_over_call, we are emitting a redundant -Wdeprecated-declarations
warning about the deprecated callee function, first from mark_used and again
from build_addr_func <- decay_conversion <- cp_build_addr_expr <- mark_used.
It seems this warning coming from build_addr_func will always be
On Thu, Mar 12, 2020 at 07:42:30PM +0100, J.W. Jagersma wrote:
> On 2020-03-12 16:32, Segher Boessenkool wrote:
> > On Thu, Mar 12, 2020 at 02:08:18PM +0100, Richard Biener wrote:
> >>> It wasn't clear from my message above, but: I was mostly worried about
> >>> requiring the asm to treat memory
Hi!
On Thu, Mar 12, 2020 at 01:18:50PM +1030, Alan Modra wrote:
> With lazy PLT resolution the first load of a PLT entry may be a value
> pointing at a resolver stub. gcc's loop processing can result in the
> PLT load in inline PLT calls being hoisted out of a loop in the
> mistaken idea that
On Sat, 2020-02-08 at 10:41 -0600, Segher Boessenkool wrote:
> On Fri, Feb 07, 2020 at 09:00:40AM -0700, Jeff Law wrote:
> > On Thu, 2020-02-06 at 07:56 -0600, Segher Boessenkool wrote:
> > > On Wed, Feb 05, 2020 at 11:48:23AM -0700, Jeff Law wrote:
> > > > Yea, it's closely related. In your case
I wonder if this fix is correct because if it is you spent more time
making ext_ptr.cc works than fixing it :-)
libstdc++ Hashtable: Fix node manipulation when using custom pointer
Use std::__to_address to get NodeHandle when reinserting nodes.
* include/bits/hashtable.h
On 2020-03-12 16:32, Segher Boessenkool wrote:
> On Thu, Mar 12, 2020 at 02:08:18PM +0100, Richard Biener wrote:
>>> It wasn't clear from my message above, but: I was mostly worried about
>>> requiring the asm to treat memory operands in a certain way when the
>>> exception is thrown. IMO it
Hi Carl,
On Thu, Mar 12, 2020 at 09:57:06AM -0700, Carl Love wrote:
> > From the GCC manual:
> >
> > -mmfcrfp4 2.01
> > -mpopcntb p5 2.02
> > -mfprndp5+ 2.04 ("info gcc" says 2.03, that's wrong? But the
> > ISA
> > says this is 2.02 even? Now what!)
>
This patch implements Jason's suggestion of pushing a lambda scope when
parsing a global variable initializer. That bit worked fine, but
happened to cause g++.dg/opt/dump1.C to not give any
used-but-not-defined warnings.
The reason was no_linkage_check, which considers any lambda that has an
Hi Richard,
I have updated the patch, changelog is the same.
bootstrapped and regtested on aarch64-none-linux-gnu and no issues.
OK for gcc 9 and 8?
Thanks,
Tamar
The 03/10/2020 11:49, Richard Sandiford wrote:
> Tamar Christina writes:
> > Hi All,
> >
> > This works around an ICE in reload
On Thu, Mar 12, 2020 at 2:11 PM Martin Liška wrote:
>
> On 3/12/20 1:55 PM, Jan Hubicka wrote:
> >> gcc/ChangeLog:
> >>
> >> 2020-03-12 Martin Liska
> >>
> >> * lto-section-in.c: Add extension_symtab.
> >> * lto-streamer-out.c (write_symbol_extension_info):
> >> New.
> >>
Hi,
On Thu, 27 Feb 2020 at 18:03, Kyrill Tkachov
wrote:
>
> Hi Mihail,
>
> On 2/27/20 2:44 PM, Mihail Ionescu wrote:
> > Hi Kyrill,
> >
> > On 02/27/2020 11:09 AM, Kyrill Tkachov wrote:
> >> Hi Mihail,
> >>
> >> On 2/27/20 10:27 AM, Mihail Ionescu wrote:
> >>> Hi,
> >>>
> >>> This patch adds
> gcc/ChangeLog:
>
> 2020-03-12 Martin Liska
>
> * lto-section-in.c: Add extension_symtab.
> * lto-streamer-out.c (write_symbol_extension_info):
> New.
> (produce_symtab_extension): New.
> (produce_asm_for_decls): Stream also produce_symtab_extension.
> *
Hi.
There's updated version of the patch.
Changes from the previous version:
- comment added to ld_plugin_symbol
- new section renamed to ext_symtab
- assert added for loop iterations in produce_symtab and
produce_symtab_extension
Martin
>From ad24565cfb3166fdd9995381b25c1f558c7bcf8c Mon Sep
On 10/02/2020 15:51, Richard Earnshaw wrote:
The peephole that detects a mov of one register to another followed by
a comparison of the original register against zero is only used in Arm
state; but the instruction that matches this is generic to all 32-bit
compilation states. That instruction
On Thu, 2020-03-12 at 13:16 +0100, Jakub Jelinek wrote:
> Hi!
>
> scripts/update_web_docs_git -r 9.3.0 -d gcc-9.3.0
> failed after the sourceware upgrade, there is no python-sphinx10
> package and
> python3-sphinx is new enough that the docs build succeeded.
>
> Ok for trunk?
>
> 2020-03-12
Tobias Burnus writes:
Hi Tobias,
> Fortran patch: https://gcc.gnu.org/pipermail/gcc-patches/current/541774.html
>
> "A declare directive must be in the same scope
> as the declaration of any var that appears in
> the data clauses of the directive."
>
> ("A declare directive is used […]
On Thu, Mar 12, 2020 at 12:27:48PM +0100, Andreas Schwab wrote:
> I'm getting this ICE with -mabi=ilp32:
>
> during RTL pass: fwprop1
> /opt/gcc/gcc-20200312/gcc/testsuite/gcc.dg/pr94121.c: In function 'bar':
> /opt/gcc/gcc-20200312/gcc/testsuite/gcc.dg/pr94121.c:16:1: internal co
On 3/12/20 2:15 PM, Richard Biener wrote:
#elif defined __LITTLE_ENDIAN__
Hmm, the macro is not defined. Even a simple test-case shows that:
$ cat le.c
#ifdef __LITTLE_ENDIAN__
asdfa
#endif
$ gcc le.c -c
[no error]
On Thu, Mar 12, 2020 at 02:08:18PM +0100, Richard Biener wrote:
> > It wasn't clear from my message above, but: I was mostly worried about
> > requiring the asm to treat memory operands in a certain way when the
> > exception is thrown. IMO it would be better to say that the values of
> > memory
On 1/27/20 2:02 PM, Jeff Law wrote:
[snip]
While I think we've missed the boat for gcc-10, I think these patches
should go forward in gcc-11. I'll own getting the paths sorted so that
this problem is avoided.
I recently retested these patches on trunk, and I found some new
regressions in
On Thu, Mar 12, 2020 at 2:38 AM Richard Biener via Gcc-patches
wrote:
>
> On Thu, Mar 12, 2020 at 4:06 AM Jeff Law via Gcc-patches
> wrote:
> >
> > On Wed, 2020-03-11 at 13:04 +, Nidal Faour via Gcc-patches wrote:
> > > This patch is a code density oriented and attempt to remove redundant
>
On Thu, 2020-03-12 at 13:23 -0500, Segher Boessenkool wrote:
> On Thu, Mar 12, 2020 at 12:03:08PM -0600, Jeff Law wrote:
> > On Sat, 2020-02-08 at 10:41 -0600, Segher Boessenkool wrote:
> > > I don't think each stanza of code should use it's own "noop-ness", no.
> > Richard's patch is actually
On Thu, 2020-03-12 at 19:49 +0200, Darius Galis wrote:
> Hello,
>
> The following patch removes the CTRLREG_CPEN register variable.
> According to the RX software manual:
> https://www.renesas.com/cn/en/doc/products/mpumcu/doc/rx_family/r01us0316ej0100-rxv3sm.pdf
> there is no control register
On 12/03/20 19:33 +0100, François Dumont via Libstdc++ wrote:
I wonder if this fix is correct because if it is you spent more time
making ext_ptr.cc works than fixing it :-)
I don't remember the details, but I think this is not correct. We need
to store the fancy pointer, not a raw pointer.
On 2020-03-12 10:59, Richard Sandiford wrote:
> The other case I mentioned was equivalent to:
>
> int
> test_mem2 ()
> {
>int i = 2;
>try
> {
>asm volatile ("ud2; mov%z0 $1, %0" : "=m" (i));
> }
>catch (const illegal_opcode&)
>
On Thu, Mar 12, 2020 at 12:47:04PM -0600, Jeff Law wrote:
> On Thu, 2020-03-12 at 13:23 -0500, Segher Boessenkool wrote:
> > > else if (n_sets == 1
> > > -&& MEM_P (trial)
> > > +&& ! CALL_P (insn)
> > > +&& (MEM_P (trial) || REG_P (trial))
> > >
On Mon, 2020-03-09 at 14:33 -0600, Martin Sebor wrote:
> On 3/5/20 5:26 PM, Jeff Law wrote:
> > On Fri, 2020-02-14 at 15:41 -0700, Martin Sebor wrote:
> > > Because attribute weakref introduces a kind of a definition, it can
> > > only be applied to declarations of symbols that are not defined.
On Thu, 2020-03-12 at 15:26 -0500, Segher Boessenkool wrote:
> On Thu, Mar 12, 2020 at 12:47:04PM -0600, Jeff Law wrote:
> > On Thu, 2020-03-12 at 13:23 -0500, Segher Boessenkool wrote:
> > > > else if (n_sets == 1
> > > > - && MEM_P (trial)
> > > > + &&
On 3/12/20 11:03 AM, Martin Sebor wrote:
On 3/11/20 3:30 PM, Martin Sebor wrote:
On 3/11/20 2:10 PM, Jason Merrill wrote:
On 3/11/20 12:57 PM, Martin Sebor wrote:
On 3/9/20 6:08 PM, Jason Merrill wrote:
On 3/9/20 5:39 PM, Martin Sebor wrote:
On 3/9/20 1:40 PM, Jason Merrill wrote:
On
On Thu, Mar 12, 2020 at 11:57:17AM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Mar 12, 2020 at 01:18:50PM +1030, Alan Modra wrote:
> > With lazy PLT resolution the first load of a PLT entry may be a value
> > pointing at a resolver stub. gcc's loop processing can result in the
> > PLT
From f650ed07ed13c40624b72b7b4bebd967fa33f917 Mon Sep 17 00:00:00 2001
From: Thomas Rodgers
Date: Thu, 12 Mar 2020 17:50:09 -0700
Subject: [PATCH] Add C++2a wait/notify_one/notify_all support to std::atomic<>
* include/Makefile.am (bits_headers): Add new header.
* include/Mamefile.in:
Hi,
On Thu, Mar 12, 2020 at 10:29:45PM +, Segher Boessenkool wrote:
> The df dataflow solvers use the aux field in the basic_block struct,
> although that is reserved for any use by passes. And not only that,
> it is required that you set all such fields to NULL before calling
> the solvers,
Hi!
On Thu, Mar 12, 2020 at 02:43:06PM -0700, Jim Wilson wrote:
> I looked at combine because I'm familiar with that pass, but the ree
> pass might be the right place to handle this.
IMO, part of this should perhaps be done on Gimple already. But the part
that should be done on RTL should be
On Thu, 5 Mar 2020, Martin Sebor wrote:
> Tested on x86_64-linux. Is this acceptable for GCC 10? How about 9?
OK for GCC 10.
--
Joseph S. Myers
jos...@codesourcery.com
On Thu, 30 Jan 2020, Lewis Hyatt wrote:
> Is this something that would be desirable to change for GCC 10? Attached
> patch would do so, and the output would become instead:
This patch is OK. (It may mean some translation updates, but we generally
do such bug fixes when the issue is found by
The df dataflow solvers use the aux field in the basic_block struct,
although that is reserved for any use by passes. And not only that,
it is required that you set all such fields to NULL before calling
the solvers, or you quietly get wrong results.
This changes the solvers to use a local array
Hi!
Please Cc: me on combine patches; you sent it nine days ago, and I didn't
see it until now.
On Wed, Mar 04, 2020 at 08:39:36AM +, Yangfei (Felix) wrote:
> This is a simple fix for PR94026.
> With this fix, combine will try make an extraction if we are in a equality
> comparison
On 2020-03-12 20:26, Segher Boessenkool wrote:
> On Thu, Mar 12, 2020 at 07:42:30PM +0100, J.W. Jagersma wrote:
>> On 2020-03-12 16:32, Segher Boessenkool wrote:
>>> On Thu, Mar 12, 2020 at 02:08:18PM +0100, Richard Biener wrote:
> It wasn't clear from my message above, but: I was mostly
On 3/12/20 3:28 PM, Patrick Palka wrote:
In build_over_call, we are emitting a redundant -Wdeprecated-declarations
warning about the deprecated callee function, first from mark_used and again
from build_addr_func <- decay_conversion <- cp_build_addr_expr <- mark_used.
It seems this warning
> -Original Message-
> From: Segher Boessenkool [mailto:seg...@kernel.crashing.org]
> Sent: Friday, March 13, 2020 7:50 AM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org; Zhanghaijian (A)
> Subject: Re: [PATCH PR94026] combine missed opportunity to simplify
> comparisons with zero
>
74 matches
Mail list logo
