When __builtin_ia32_vzeroupper is called explicitly, the corresponding
vzeroupper pattern does not carry any CLOBBERS or SETs before LRA,
which leads to incorrect optimization in pass_reload. In order to
solve this problem, this patch refine instructions as call_insns in
which the call has a specia
Use "used" flag for CALL_INSN to indicate it's a fake call. If it's a
fake call, it won't have its own function stack.
gcc/ChangeLog
PR target/82735
* df-scan.c (df_get_call_refs): When call_insn is a fake call,
it won't use stack pointer reg.
* final.c (leaf_funct
On 2021/6/3 08:46, Xionghu Luo via Gcc-patches wrote:
> Hi,
>
> On 2021/6/3 06:20, Segher Boessenkool wrote:
>> On Wed, Jun 02, 2021 at 03:19:32AM -0500, Xionghu Luo wrote:
>>> On P8LE, extra rot64+rot64 load or store instructions are generated
>>> in float128 to vector __int128 conversion.
>>>
Hi Nilsson,
on 2021/6/2 下午8:45, Hans-Peter Nilsson wrote:
>> From: Kewen Lin
>> Date: Wed, 2 Jun 2021 07:04:54 +0200
>
>> gcc/ChangeLog:
>>
>> * config/cris/cris.md (*addi_reload): Fix empty split condition.
>> ---
>> gcc/config/cris/cris.md | 2 +-
>> 1 file changed, 1 insertion(+), 1 del
From: Andrew Pinski
This improves match_simplify_replace in phi-opt to handle the
case where there is one cheap (non-call) preparation statement in the
middle basic block similar to xor_replacement and others.
This allows to remove xor_replacement which it does too.
OK? Bootstrapped and tested
Hi Richi/Richard/Jeff/Segher,
Thanks for the comments!
on 2021/6/3 上午7:52, Segher Boessenkool wrote:
> On Wed, Jun 02, 2021 at 06:32:13PM +0100, Richard Sandiford wrote:
>> Richard Biener writes:
>>> So what Richard suggests would be to disallow split conditions
>>> that do not start with "&& ",
Hi!
On Wed, Jun 02, 2021 at 11:05:00PM -0500, Aaron Sawdey wrote:
> This certainly causes a bootstrap miscompare, and might also be
> responsible for PR/100820. The operands to subf were reversed
> in the logical-add/sub fusion patterns, and I screwed up my
> bootstrap test which is how it ended u
This certainly causes a bootstrap miscompare, and might also be
responsible for PR/100820. The operands to subf were reversed
in the logical-add/sub fusion patterns, and I screwed up my
bootstrap test which is how it ended up getting committed.
If bootstrap and regtest passes, ok for trunk (and ev
On 6/2/21 7:05 PM, Patrick Palka wrote:
On Wed, 2 Jun 2021, Jason Merrill wrote:
On 6/2/21 4:56 PM, Patrick Palka wrote:
On Wed, 2 Jun 2021, Patrick Palka wrote:
On Wed, 2 Jun 2021, Jason Merrill wrote:
On 6/2/21 2:39 PM, Patrick Palka wrote:
Here, the dependent template name in the retur
Update move expanders to convert the CONST_WIDE_INT operand to vector
broadcast from a byte with AVX2. Add ix86_gen_scratch_sse_rtx to
return a scratch SSE register which won't increase stack alignment
requirement and blocks transformation by the combine pass.
A small benchmark:
https://gitlab.c
Hi Richard,
on 2021/6/3 上午1:19, Richard Sandiford wrote:
> "Kewen.Lin via Gcc-patches" writes:
>> Hi,
>>
>> As PR100794 shows, in the current implementation PRE bypasses
>> some optimization to avoid introducing loop carried dependence
>> which stops loop vectorizer to vectorize the loop. At -O2
On Wed, Jun 02, 2021 at 05:13:16PM -0500, Paul A. Clarke wrote:
> + for (i = 0; i < NUM; i++)
> +src.s[i] = i * i - 68 * i + 1200;
Could you do tests with some identical elements as well? Because that
is where I think it fails on BE currently.
Segher
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570854.html
Thanks.
On 20/5/2021 下午 5:49, HAO CHEN GUI wrote:
Hi,
The patch removes mode promotion for pseudos on rs6000 target.
The attachments are the patch diff and change log file.
Bootstrapped and t
Hi,
On 2021/6/3 06:20, Segher Boessenkool wrote:
> On Wed, Jun 02, 2021 at 03:19:32AM -0500, Xionghu Luo wrote:
>> On P8LE, extra rot64+rot64 load or store instructions are generated
>> in float128 to vector __int128 conversion.
>>
>> This patch teaches pass swaps to also handle such pattens to re
On Fri, May 13, 2016 at 12:07 PM Marc Glisse wrote:
>
> Hello,
>
> maybe this would fit better in VRP, but it is easier (and not completely
> useless) to put it in match.pd.
>
> Since the transformation is restricted to GIMPLE, I think I don't need to
> check that @0 is SSA_NAME. I didn't test if
Hi!
On Wed, Jun 02, 2021 at 05:13:15PM -0500, Paul A. Clarke wrote:
> Add a naive implementation of the subject x86 intrinsic to
> ease porting.
> +/* Return horizontal packed word minimum and its index in bits [15:0]
> + and bits [18:16] respectively. */
> +extern __inline __m128i __attribute
On Wed, Jun 02, 2021 at 06:32:13PM +0100, Richard Sandiford wrote:
> Richard Biener writes:
> > So what Richard suggests would be to disallow split conditions
> > that do not start with "&& ", it's probably easy to do that as well
> > and look for build fails. That should catch all cases to look
On Wed, Jun 02, 2021 at 04:18:46PM +0800, Kewen.Lin wrote:
> on 2021/6/2 下午3:43, Richard Biener wrote:
> Yes, the "" in split condition does mean 'true' (always).
Right -- which means it will be split whenever it matches. This *can*
be intended, but in define_insn_and_split it is almost always a
On Wed, 2 Jun 2021, Jason Merrill wrote:
> On 6/2/21 4:56 PM, Patrick Palka wrote:
> > On Wed, 2 Jun 2021, Patrick Palka wrote:
> >
> > > On Wed, 2 Jun 2021, Jason Merrill wrote:
> > >
> > > > On 6/2/21 2:39 PM, Patrick Palka wrote:
> > > > > Here, the dependent template name in the return type
Hi!
On Wed, Jun 02, 2021 at 06:07:28PM +0100, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > Since times immemorial there has been const_int_rtx for all values from
> > -64 to 64, but only constm1_rtx..const2_rtx have been available for
> > convenient use. Change this, so that we can
This patch adds support for 'omp loop' to gfortran including the combined
constructs. It also fixes some splitting issues with clauses in
combined constructs.
It does not attempt to clean up all remaining Fortran issues with
clauses in combined constructs (cf. below + PR).
* * *
Since 'paralle
Hi,
> -Original Message-
> From: Vladimir Makarov
> Sent: 31 May 2021 16:52
> To: Przemyslaw Wirkus ; Richard Biener
>
> Cc: gcc-patches@gcc.gnu.org; ja...@redhat.com; ni...@redhat.com;
> Richard Earnshaw ; Ramana Radhakrishnan
> ; Kyrylo Tkachov
>
> Subject: Re: [backport gcc10, gcc9]
On Wed, Jun 02, 2021 at 03:19:32AM -0500, Xionghu Luo wrote:
> On P8LE, extra rot64+rot64 load or store instructions are generated
> in float128 to vector __int128 conversion.
>
> This patch teaches pass swaps to also handle such pattens to remove
> extra swap instructions.
Did you check if this
Copy the test for _mm_minpos_epu16 from
gcc/testsuite/gcc.target/i386/sse4_1-phminposuw.c, with
a few adjustments:
- Adjust the dejagnu directives for powerpc platform.
- Make the data not be monotonically increasing,
such that some of the returned values are not
always the first value (index
Add a naive implementation of the subject x86 intrinsic to
ease porting.
2021-06-02 Paul A. Clarke
gcc/ChangeLog:
* config/rs6000/smmintrin.h (_mm_minpos_epu16): New.
---
gcc/config/rs6000/smmintrin.h | 27 +++
1 file changed, 27 insertions(+)
diff --git a/gcc
Added compatible implementation of _mm_minpos_epu16 for powerpc.
Copied, improved, and fixed testcase from i386.
Tested on BE, LE (32 and 64bit).
Paul A. Clarke (2):
rs6000: Add support for _mm_minpos_epu16
rs6000: Add test for _mm_minpos_epu16
gcc/config/rs6000/smmintrin.h |
On Wed, Jun 02, 2021 at 03:40:49PM -0600, Martin Sebor via Gcc-patches wrote:
> + if (!gimple_call_builtin_p (stmt, BUILT_IN_NORMAL))
> +{
> + /* See if this is a call to placement new. */
> + if (!fn
> + || !DECL_IS_OPERATOR_NEW_P (fn)
> + || DECL_IS_REPLACEABLE_OPERATO
The two forms of placement operator new defined in return their
pointer argument and may not be displaced by user-defined functions.
But because they are ordinary (not built-in) functions this property
isn't reflected in their declarations alone, and there's no user-
level attribute to annotate t
On 6/2/21 4:56 PM, Patrick Palka wrote:
On Wed, 2 Jun 2021, Patrick Palka wrote:
On Wed, 2 Jun 2021, Jason Merrill wrote:
On 6/2/21 2:39 PM, Patrick Palka wrote:
Here, the dependent template name in the return type of f() resolves to
an alias of int& after substitution, and we end up complai
As mentioned earlier, I abstracted the on-entry cache at the beginning
of stage1. This was to make it easier to port future changes back to
GCC11 so we could provide alternate representations to deal with memory
issues, or what have you.
This patch introduces a sparse representation of the cac
On Mon, May 10, 2021 at 5:39 AM Christoph Muellner
wrote:
> gcc/ChangeLog:
> PR rtl-optimization/100264
> * ree.c (get_sub_rtx): Ignore SET expressions without register
> destinations and remove assertion, as it is not valid anymore
> with this new behaviour.
>
On Wed, 2 Jun 2021, Patrick Palka wrote:
> On Wed, 2 Jun 2021, Jason Merrill wrote:
>
> > On 6/2/21 2:39 PM, Patrick Palka wrote:
> > > Here, the dependent template name in the return type of f() resolves to
> > > an alias of int& after substitution, and we end up complaining about
> > > qualifyi
Hi Richard,
Thanks for reviewing my patch. I did a search online and you're right -- there
isn't a vector modulo instruction. I'll remove the X * (Y / X) --> Y - (Y % X)
pattern and the existing X - (X / Y) * Y --> X % Y from triggering on vector
types.
I looked into why the following pattern
On Wed, 2 Jun 2021, Jason Merrill wrote:
> On 6/2/21 2:39 PM, Patrick Palka wrote:
> > Here, the dependent template name in the return type of f() resolves to
> > an alias of int& after substitution, and we end up complaining about
> > qualifying this reference type with 'const' from cp_build_qual
Hi!
On Wed, Jun 02, 2021 at 09:07:35AM +0200, Richard Biener wrote:
> On Wed, Jun 2, 2021 at 7:41 AM liuhongt via Gcc-patches
> wrote:
> > For i386, it will enable below opt
> >
> > from
> > notl%edi
> > vpbroadcastd%edi, %xmm0
> > vpand %xmm1, %xmm0, %xmm0
> > t
On 5/31/21 7:25 AM, Martin Liška wrote:
Hello.
I've made quite some progress with the porting of the documentation and
I would like to present it to the community now:
https://splichal.eu/scripts/sphinx/
Just a few issues I noticed in the warnings section:
The headings of some warnings mentio
On 6/2/21 2:39 PM, Patrick Palka wrote:
Here, the dependent template name in the return type of f() resolves to
an alias of int& after substitution, and we end up complaining about
qualifying this reference type with 'const' from cp_build_qualified_type
rather than just silently dropping the qual
On 6/2/21 2:39 PM, Patrick Palka wrote:
When copying the enumerators imported by a class-scope using-enum
declaration, we need to override current_access_specifier so that
finish_member_declaration gives them the same access as the using-enum
decl. The processing of a using-enum is performed aft
With TI official wiki gone, let's put stable links to their proprietary
toolchain documents, which happen to describe ABI and instruction set.
Signed-off-by: Dimitar Dimitrov
---
htdocs/readings.html | 2 ++
1 file changed, 2 insertions(+)
diff --git a/htdocs/readings.html b/htdocs/readings.htm
On 5/31/2021 4:46 AM, Martin Liška wrote:
PING^1
On 5/20/21 12:43 PM, Martin Liška wrote:
The simplification patch improves option completion and
handling of the option.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/Change
tf_no_cleanup only applies to the outermost TARGET_EXPR, and we already
clear it for nested calls in build_over_call, but in this case both
constructor calls came from convert_like, so we need to clear it in the
recursive call as well. This revealed that we were adding an extra
ck_rvalue in direct
Here, the dependent template name in the return type of f() resolves to
an alias of int& after substitution, and we end up complaining about
qualifying this reference type with 'const' from cp_build_qualified_type
rather than just silently dropping the qualification as per [dcl.ref]/1.
We already
When copying the enumerators imported by a class-scope using-enum
declaration, we need to override current_access_specifier so that
finish_member_declaration gives them the same access as the using-enum
decl. The processing of a using-enum is performed after we've seen the
entire definition of the
Christophe Lyon writes:
> This patch adds support for auto-vectorization of absolute value
> computation using vabs.
>
> We use a similar pattern to what is used in neon.md and extend the
> existing neg2 expander to match both 'neg' and 'abs'. This
> implies renaming the existing abs2 define_insn
On 6/2/2021 11:09 AM, Jakub Jelinek wrote:
Hi!
When building gcc targetting xtensa-linux, there are 2 warnings the PR
complains about:
../../gcc/dwarf2cfi.c: In function ‘void init_one_dwarf_reg_size(int,
machine_mode, rtx, machine_mode, init_one_dwarf_reg_state*)’:
../../gcc/dwarf2cfi.c:291
On 6/2/2021 11:32 AM, Richard Sandiford wrote:
Richard Biener writes:
On Wed, Jun 2, 2021 at 12:01 PM Kewen.Lin wrote:
on 2021/6/2 下午5:13, Richard Sandiford wrote:
"Kewen.Lin" writes:
Hi Richard,
on 2021/6/2 锟斤拷锟斤拷4:11, Richard Sandiford wrote:
Kewen Lin writes:
Hi all,
define_insn
Christophe Lyon writes:
> This patch adds support for auto-vectorization of average value
> computation using vhadd or vrhadd, for both MVE and Neon.
>
> The patch adds the needed [u]avg3_[floor|ceil] patterns to
> vec-common.md, I'm not sure how to factorize them without introducing
> an unspec i
On 6/2/21 1:38 AM, Claudiu Zissulescu wrote:
> Approved.
Thx for the super quick action on this Claudiu. Can this be slated for
backports too as it causes issues when building toolchains for modern
cores without explicit defaults.
-Vineet
>
> //Claudiu
> ---
Richard Biener writes:
> On Wed, Jun 2, 2021 at 12:01 PM Kewen.Lin wrote:
>>
>> on 2021/6/2 下午5:13, Richard Sandiford wrote:
>> > "Kewen.Lin" writes:
>> >> Hi Richard,
>> >>
>> >> on 2021/6/2 锟斤拷锟斤拷4:11, Richard Sandiford wrote:
>> >>> Kewen Lin writes:
>> Hi all,
>>
>> define_in
On Mon, 31 May 2021, Martin Liška wrote:
> https://splichal.eu/scripts/sphinx/
Looking at some examples there:
https://splichal.eu/scripts/sphinx/gcc/_build/html/c-implementation-defined-behavior/preprocessing-directives.html
has some conversion problems:
* "See Implementation-defined behavio
"Kewen.Lin via Gcc-patches" writes:
> Hi,
>
> As PR100794 shows, in the current implementation PRE bypasses
> some optimization to avoid introducing loop carried dependence
> which stops loop vectorizer to vectorize the loop. At -O2,
> there is no downstream pass to re-catch this kind of opportun
On 6/1/2021 11:04 PM, Kewen Lin via Gcc-patches wrote:
gcc/ChangeLog:
* config/mips/mips.md (, bswapsi2, bswapdi2): Fix empty
split condition.
The mips, or1k and sparc changes are fine. They're all preserving
existing behavior.
jeff
On 6/1/2021 11:04 PM, Kewen Lin wrote:
gcc/ChangeLog:
* config/h8300/combiner.md (*andsi3_lshiftrt_n_sb): Fix empty split
condition.
Hold off on this. We may need a stronger condition in there and that's
something I'm in the process of cleaning up in the H8 port.
jeff
Hi!
When building gcc targetting xtensa-linux, there are 2 warnings the PR
complains about:
../../gcc/dwarf2cfi.c: In function ‘void init_one_dwarf_reg_size(int,
machine_mode, rtx, machine_mode, init_one_dwarf_reg_state*)’:
../../gcc/dwarf2cfi.c:291:12: warning: comparison of integer expressions
On 6/1/2021 11:04 PM, Kewen Lin wrote:
gcc/ChangeLog:
* config/m68k/m68k.md (*zero_extend_inc, *zero_extend_dec,
*zero_extendsidi2): Fix empty split condition.
OK. Thanks.
jeff
Segher Boessenkool writes:
> Since times immemorial there has been const_int_rtx for all values from
> -64 to 64, but only constm1_rtx..const2_rtx have been available for
> convenient use. Change this, so that we can use all values in
> {-64,...,64} in RTL easily. This matters, because then we w
Hi Richard,
> No. It's never correct to completely wipe out the existing cost - you
> don't know the context where this is being used.
>
> The most you can do is not add any additional cost.
Remember that aarch64_rtx_costs starts like this:
/* By default, assume that everything has equivale
On Wed, 2 Jun 2021, Joel Sherrill wrote:
> For RTEMS, we switched from texinfo to Sphinx and the dependency
> on Python3 for Sphinx has caused a bit of hassle. Is this going to be
> an issue for GCC?
What Sphinx (and, thus, Python) versions does the GCC manual build work
with? Can it work with
> On Jun 2, 2021, at 11:03 AM, Jason Merrill via Gcc-patches
> wrote:
>
> On 6/1/21 3:22 PM, Richard Biener via Gcc wrote:
>> On June 1, 2021 7:30:54 PM GMT+02:00, David Malcolm via Gcc
>> wrote:
...
>>>
>>> The MAINTAINERS file doesn't seem to have such a "DCO list"
>>> yet; does the
On Wed, Jun 02, 2021 at 10:25:34AM +0200, Andreas Schwab wrote:
> On Jun 01 2021, Segher Boessenkool wrote:
> > -* ^List-Id: .*<.*@gcc.gnu.org>$
> > +* ^List-Id: .*<.*.gcc.gnu.org>$
>
> Shouldn't the < and > be mangled as < and >?
"It works fine for me!"
You are right of course.
Segher
On Wed, Jun 02, 2021 at 09:17:20AM +0200, Gerald Pfeifer wrote:
> On Tue, 1 Jun 2021, Segher Boessenkool wrote:
> > Brown paper bag time. The List-Id: should look like a hostname, not
> > like an email address. Somehow I put in an at-sign when changing my
> > gcc-patches example to the match-all
On 6/2/21 11:25 AM, Jakub Jelinek wrote:
On Wed, Jun 02, 2021 at 11:09:45AM -0400, Jason Merrill wrote:
On 6/2/21 3:59 AM, Jakub Jelinek wrote:
if (!allows_reg && !cxx_mark_addressable (*op))
operand = error_mark_node;
+ else if (!allows_reg && bitfield
For RTEMS, we switched from texinfo to Sphinx and the dependency
on Python3 for Sphinx has caused a bit of hassle. Is this going to be
an issue for GCC?
Also we rely on TexLive for PDF output and that's a bit of a pain to
install. Tex was incorrectly packaged on some RHEL/CentOS versions.
This ig
On 6/2/21 12:55 AM, Richard Biener wrote:
On Tue, Jun 1, 2021 at 9:56 PM Martin Sebor wrote:
On 5/27/21 2:53 PM, Jason Merrill wrote:
On 4/27/21 11:52 AM, Martin Sebor via Gcc-patches wrote:
On 4/27/21 8:04 AM, Richard Biener wrote:
On Tue, Apr 27, 2021 at 3:59 PM Martin Sebor wrote:
On
On 02/06/2021 11:21, Wilco Dijkstra via Gcc-patches wrote:
Hi,
Given the large improvements from better register allocation of GOT accesses,
I decided to generalize it to get large gains for normal addressing too:
Improve rematerialization costs of addresses. The current costs are set too
On 01/06/2021 18:16, Srinath Parvathaneni via Gcc-patches wrote:
Hi Richard,
-Original Message-
From: Richard Earnshaw
Sent: 13 April 2021 14:55
To: Srinath Parvathaneni ; gcc-
patc...@gcc.gnu.org
Cc: Richard Earnshaw
Subject: Re: [GCC][Patch] arm: Fix the mve multilib for the brok
On Wed, Jun 02, 2021 at 11:09:45AM -0400, Jason Merrill wrote:
> On 6/2/21 3:59 AM, Jakub Jelinek wrote:
> > if (!allows_reg && !cxx_mark_addressable (*op))
> > operand = error_mark_node;
> > + else if (!allows_reg && bitfield_p (*op))
> > + {
> > +
On 6/2/21 3:59 AM, Jakub Jelinek wrote:
if (!allows_reg && !cxx_mark_addressable (*op))
operand = error_mark_node;
+ else if (!allows_reg && bitfield_p (*op))
+ {
+ error_at (loc, "attempt to take address of bit-field");
Hm
On 6/1/21 3:22 PM, Richard Biener via Gcc wrote:
On June 1, 2021 7:30:54 PM GMT+02:00, David Malcolm via Gcc
wrote:
On Tue, 2021-06-01 at 10:00 -0400, David Edelsohn via Gcc wrote:
GCC was created as part of the GNU Project but has grown to operate
asan autonomous project.
The GCC Steering C
On 6/2/21 9:19 AM, Segher Boessenkool wrote:
> On Wed, Jun 02, 2021 at 08:23:48AM -0500, Pat Haugen wrote:
>> On 6/2/21 7:01 AM, Richard Biener wrote:
>>> So did you check the RTL (and alias-sets) produced by
>>> __builtin_return_address? Test coverage might
>>> be low here and w/o scheduling oppo
On 6/2/21 1:52 PM, Richard Biener wrote:
On Wed, Jun 2, 2021 at 12:34 PM Aldy Hernandez via Gcc-patches
wrote:
But the whole point of all this singing and dancing is not to make
warnings but to be able to implement assert (); or assume (); that
will result in no code but optimization based
On Wed, Jun 02, 2021 at 10:44:34AM +0200, Gerald Pfeifer wrote:
> On Tue, 1 Jun 2021, Segher Boessenkool wrote:
> > We haven't had Sender: for a while now.
>
> "a while now" was about four(?) hours when you sent that yesterday. :-)
Ah, I thought it was since we moved to the new mailing list soft
On Wed, Jun 02, 2021 at 08:23:48AM -0500, Pat Haugen wrote:
> On 6/2/21 7:01 AM, Richard Biener wrote:
> > So did you check the RTL (and alias-sets) produced by
> > __builtin_return_address? Test coverage might
> > be low here and w/o scheduling opportunities to break things.
>
> __builtin_return
On 01/06/2021 18:08, Srinath Parvathaneni via Gcc-patches wrote:
Hi All,
On passing +cdecp[0-7] extension to the -march string in command line options,
multilib linking is failing as mentioned in PR100856. This patch fixes this
issue by generating a separate -march string only for multilib co
Ping?
вс, 25 окт. 2020 г. в 16:09, Matwey V. Kornilov :
>
>
> Ping?
>
> чт, 4 июн. 2020 г. в 18:30, Matwey V. Kornilov :
>>
>> Reference: https://www.microchip.com/wwwproducts/en/ATMEGA324PB
>> ---
>> gcc/config/avr/avr-mcus.def | 1 +
>> gcc/doc/avr-mmcu.texi | 2 +-
>> 2 files changed, 2
On Wed, Jun 2, 2021 at 12:02 AM Richard Biener
wrote:
>
> On Wed, Jun 2, 2021 at 3:57 AM H.J. Lu via Gcc-patches
> wrote:
> >
> > On Tue, Jun 1, 2021 at 6:17 PM Hongtao Liu wrote:
> > >
> > > On Wed, Jun 2, 2021 at 7:07 AM H.J. Lu via Gcc-patches
> > > wrote:
> > > >
> > > > On Tue, Jun 1, 2021
Hi Martin,
Testsuite isn't very happy with it:
Before:
# of expected passes149743
# of unexpected failures294
# of unexpected successes 2
# of expected failures 947
# of unresolved testcases 56
# of unsupported tests 8248
After:
On Wed, 2 Jun 2021 13:59:05 +0200
Richard Biener wrote:
> On Wed, Jun 2, 2021 at 12:47 PM Julian Brown
> wrote:
> >
> > For historical reasons, it seems that extract_base_bit_offset
> > unnecessarily used two different ways to strip
> > ARRAY_REF/INDIRECT_REF nodes from component accesses. I ver
On 6/2/21 7:01 AM, Richard Biener wrote:
> On Wed, Jun 2, 2021 at 1:15 PM Pat Haugen wrote:
>>
>> On 6/2/21 1:51 AM, Richard Biener wrote:
>>> On Tue, Jun 1, 2021 at 10:37 PM Pat Haugen via Gcc-patches
>>> wrote:
Make sure link reg save MEM has frame alias set, to match other link reg
>
On 6/2/21 7:52 AM, Richard Biener wrote:
On Wed, Jun 2, 2021 at 12:34 PM Aldy Hernandez via Gcc-patches
wrote:
We've been having "issues" in our branch when exporting to the global
space ranges that take into account previously known ranges
(SSA_NAME_RANGE_INFO, etc). For the longest time we h
> From: Kewen Lin
> Date: Wed, 2 Jun 2021 07:04:54 +0200
> gcc/ChangeLog:
>
> * config/cris/cris.md (*addi_reload): Fix empty split condition.
> ---
> gcc/config/cris/cris.md | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/config/cris/cris.md b/gcc/config/cri
The allocator, hash function and equality function should all be
value-initialized by the default constructor of an unordered container.
Do it in the EBO helper, so we don't have to get it right in multiple
places.
Signed-off-by: Jonathan Wakely
libstdc++-v3/ChangeLog:
PR libstdc++/1008
On 01/06/21 19:10 +0100, Jonathan Wakely wrote:
On 01/06/21 18:47 +0100, Jonathan Wakely wrote:
On 01/06/21 18:45 +0100, Jonathan Wakely wrote:
On 22/05/21 18:35 +0200, François Dumont wrote:
diff --git a/libstdc++-v3/testsuite/23_containers/unordered_set/96088.cc
b/libstdc++-v3/testsuite/23_
On Wed, Jun 2, 2021 at 2:05 PM Eric Botcazou wrote:
>
> Hi,
>
> as explained in the audit trail, the return part has a major performance
> impact in Ada where variable-sized types are first-class citizens, but it
> turns out that it is not exercized in the testsuite yet.
>
> Tested on x86-64/Linux
Hi,
as explained in the audit trail, the return part has a major performance
impact in Ada where variable-sized types are first-class citizens, but it
turns out that it is not exercized in the testsuite yet.
Tested on x86-64/Linux, OK for mainline and 11 branch?
2021-06-02 Eric Botcazou
On Wed, Jun 2, 2021 at 1:15 PM Pat Haugen wrote:
>
> On 6/2/21 1:51 AM, Richard Biener wrote:
> > On Tue, Jun 1, 2021 at 10:37 PM Pat Haugen via Gcc-patches
> > wrote:
> >>
> >> Make sure link reg save MEM has frame alias set, to match other link reg
> >> save/restore code.
> >>
> >> Bootstrap/re
On Wed, Jun 2, 2021 at 12:47 PM Julian Brown wrote:
>
> For historical reasons, it seems that extract_base_bit_offset
> unnecessarily used two different ways to strip ARRAY_REF/INDIRECT_REF
> nodes from component accesses. I verified that the two ways of performing
> the operation gave the same re
On Wed, Jun 2, 2021 at 12:34 PM Aldy Hernandez via Gcc-patches
wrote:
>
> We've been having "issues" in our branch when exporting to the global
> space ranges that take into account previously known ranges
> (SSA_NAME_RANGE_INFO, etc). For the longest time we had the export
> feature turned off b
Signed-off-by: Jonathan Wakely
libstdc++-v3/ChangeLog:
* doc/xml/manual/status_cxxis29124.xml: Improve punctuation.
* doc/xml/manual/status_cxxtr1.xml: Likewise.
* doc/xml/manual/status_cxxtr24733.xml: Likewise.
* doc/html/*: Regenerate.
Committed to trunk.
comm
On 6/2/21 1:51 AM, Richard Biener wrote:
> On Tue, Jun 1, 2021 at 10:37 PM Pat Haugen via Gcc-patches
> wrote:
>>
>> Make sure link reg save MEM has frame alias set, to match other link reg
>> save/restore code.
>>
>> Bootstrap/regtest on powerpc64/powerpc64le with no new regressions. Ok for
>> tr
This patch reworks indirect struct handling in gimplify.c (i.e. for
struct components mapped with "mystruct->a[0:n]", "mystruct->b", etc.),
for OpenACC. The key observation leading to these changes was that
component mappings of references-to-structures is already implemented
and working, and indi
This patch is a second attempt at refactoring struct component mapping
handling for OpenACC/OpenMP during gimplification, after the patch I
posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2018-November/510503.html
And improved here, post-review:
https://gcc.gnu.org/pipermail/gcc-patch
For historical reasons, it seems that extract_base_bit_offset
unnecessarily used two different ways to strip ARRAY_REF/INDIRECT_REF
nodes from component accesses. I verified that the two ways of performing
the operation gave the same results across the whole testsuite (and
several additional benchm
It never makes sense for a GOMP_MAP_ATTACH_DETACH mapping to survive
beyond gimplify.c, so this patch rewrites such mappings to GOMP_MAP_ATTACH
or GOMP_MAP_DETACH unconditionally (rather than checking for a list
of types of OpenACC or OpenMP constructs), in cases where it hasn't
otherwise been done
This is a merge to the og11 branch of the patch series posted for
mainline here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570396.html
and for the og10 branch here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570810.html
Re-tested with offloading to NVPTX. I will push to the
We've been having "issues" in our branch when exporting to the global
space ranges that take into account previously known ranges
(SSA_NAME_RANGE_INFO, etc). For the longest time we had the export
feature turned off because it had the potential of removing
__builtin_unreachable code early in t
Hi,
Given the large improvements from better register allocation of GOT accesses,
I decided to generalize it to get large gains for normal addressing too:
Improve rematerialization costs of addresses. The current costs are set too
high
which results in extra register pressure and spilling. Usi
On Wed, Jun 2, 2021 at 12:01 PM Kewen.Lin wrote:
>
> on 2021/6/2 下午5:13, Richard Sandiford wrote:
> > "Kewen.Lin" writes:
> >> Hi Richard,
> >>
> >> on 2021/6/2 锟斤拷锟斤拷4:11, Richard Sandiford wrote:
> >>> Kewen Lin writes:
> Hi all,
>
> define_insn_and_split should avoid to use emp
on 2021/6/2 下午5:13, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi Richard,
>>
>> on 2021/6/2 锟斤拷锟斤拷4:11, Richard Sandiford wrote:
>>> Kewen Lin writes:
Hi all,
define_insn_and_split should avoid to use empty split condition
if the condition for define_insn isn't empty,
> -Original Message-
> From: Tamar Christina
> Sent: 02 June 2021 10:34
> To: Tamar Christina
> Cc: Richard Earnshaw ; nd ;
> Ramana Radhakrishnan ; Kyrylo
> Tkachov
> Subject: RE: [PATCH][AArch32]: Correct sdot RTL on aarch32
>
> ping
>
> > -Original Message-
> > From: Gcc-p
1 - 100 of 134 matches
Mail list logo
