On 2020/12/23 00:53, Richard Biener wrote:
On December 21, 2020 10:03:43 AM GMT+01:00, Xiong Hu Luo
wrote:
Here comes another case that requires run a pass once more, as this is
not the common suggested direction to solve problems, not quite sure
whether it is still a reasonble fix here. So
> Hongyue, please collect code size differences on SPEC CPU 2017 and
> eembc.
Here is code size difference for this patch
SPEC CPU 2017
difference w patch w/o patch
500.perlbench_r 0.051% 1622637 1621805
502.gcc
Bootstrap and regtest running on x86_64-redhat-linux,
ppc64le-redhat-linux and s390x-redhat-linux. Ok for master?
v1: https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566127.html
v1 -> v2: Pass a set_info instead of a def_info around.
Add single_nondebug_insn_use () - maybe this cou
On Mon, Mar 22, 2021 at 7:10 AM Jan Hubicka wrote:
>
> >
> > gcc/
> >
> > * config/i386/i386-expand.c (expand_set_or_cpymem_via_rep):
> > For TARGET_PREFER_KNOWN_REP_MOVSB_STOSB, don't convert QImode
> > to SImode.
> > (decide_alg): For TARGET_PREFER_KNOWN_REP_MOVSB_STOSB,
This implements the new string_view constructor proposed by P1989R2.
This hasn't been voted into the C++23 draft yet, but it's been reviewed
by LWG and is expected to be approved at the next WG21 meeting.
libstdc++-v3/ChangeLog:
* include/std/string_view (basic_string_view(Range&&)): Defi
On Mon, 2021-03-22 at 22:55 +, Richard Sandiford wrote:
> Ilya Leoshkevich writes:
> > On Mon, 2021-03-22 at 18:23 +, Richard Sandiford wrote:
> > > Ilya Leoshkevich writes:
> >
> > [...]
> >
> > > > Do you still want me to add single_nondebug_use() for
> > > > completeness
> > > > in
>
Ilya Leoshkevich writes:
> On Mon, 2021-03-22 at 18:23 +, Richard Sandiford wrote:
>> Ilya Leoshkevich writes:
>
> [...]
>
>> > Do you still want me to add single_nondebug_use() for completeness
>> > in
>> > this patch, or would it be better to add it later when it's
>> > actually
>> > needed
Bootstrapped and regtested on x86_64-redhat-linux, ppc64le-redhat-linux
and s390x-redhat-linux. Ok for master?
v1: https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566127.html
v1 -> v2: Pass a set_info instead of a def_info around.
Add single_nondebug_insn_use () - maybe this could
On 3/18/21 4:48 AM, Jakub Jelinek wrote:
Hi!
The following testcase results in -fcompare-debug failure.
The problem is the similar like in PR94272
https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542562.html
When genericizing, with -g0 we have just a TREE_SIDE_EFFECTS DO_STMT
in a branch of
On 3/19/21 4:25 PM, Martin Sebor wrote:
On 3/19/21 12:49 PM, Jakub Jelinek via Gcc-patches wrote:
On Fri, Mar 19, 2021 at 02:17:39PM -0400, Jason Merrill wrote:
--- gcc/cp/decl.c.jj 2021-03-16 21:17:41.014498713 +0100
+++ gcc/cp/decl.c 2021-03-18 19:31:22.430149523 +0100
@@ -8629,6 +8629,
On Mon, 2021-03-22 at 18:23 +, Richard Sandiford wrote:
> Ilya Leoshkevich writes:
[...]
> > Do you still want me to add single_nondebug_use() for completeness
> > in
> > this patch, or would it be better to add it later when it's
> > actually
> > needed?
>
> I was thinking that the fwprop.
We were not correctly handling cross-module redeclarations of
partial-specializations. They have their own TEMPLATE_DECL, which we
need to locate. I had a FIXME there about this case. Guess it's fixed now.
PR 99480
gcc/cp/
* module.cc (depset::hash::make_dependency)
On Mon, Mar 22, 2021 at 07:16:01PM +0100, Aldy Hernandez wrote:
> +void
> +irange::irange_set_1bit_anti_range (tree min, tree max)
> +{
> + tree type = TREE_TYPE (min);
> + gcc_checking_assert (TYPE_PRECISION (type) == 1);
> +
> + if (operand_equal_p (min, max))
> +{
> + // Since these
Ilya Leoshkevich writes:
> On Sun, 2021-03-21 at 13:19 +, Richard Sandiford wrote:
>> Ilya Leoshkevich writes:
>> > Bootstrapped and regtested on x86_64-redhat-linux, ppc64le-redhat-
>> > linux
>> > and s390x-redhat-linux. Ok for master?
>>
>> Given what was said downthread, I agree we shou
On Fri, Mar 19, 2021 at 4:17 PM Jakub Jelinek wrote:
>
> On Fri, Mar 19, 2021 at 10:01:50AM +0100, Aldy Hernandez via Gcc-patches
> wrote:
> > --- a/gcc/value-range.cc
> > +++ b/gcc/value-range.cc
> > @@ -184,12 +184,46 @@ irange::irange_set (tree min, tree max)
> > verify_range ();
> > }
>
On 2021-03-21 8:51 a.m., Richard Sandiford wrote:
Vladimir Makarov writes:
On 2021-03-19 11:42 a.m., Richard Sandiford wrote:
Vladimir Makarov via Gcc-patches writes:
The following patch solves P1 PR99581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
The patch was successfully
On Mon, Mar 22, 2021 at 10:28:48AM -0400, Vladimir Makarov wrote:
> On 2021-03-22 6:22 a.m., Richard Sandiford wrote:
> >'\0' is just a normal string null terminator and so I don't think we
> >should be processing it as if it were a constraint character.
> >How about having a gcc_unreachable on zer
On Mon, Mar 22, 2021 at 10:22:55AM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Sat, Mar 20, 2021 at 10:53:32AM -0400, Vladimir Makarov via Gcc-patches
> > wrote:
> >> It seems CONSTRAINT_LEN treats constraint '\0' as one having length 1.
> >
> > Maybe we should fix that?
Ping.
Cross builds on Advance Toolchain have been broken since GCC commit
'781183595ac Add conversions between _Float128 and Decimal' [0]. We've
been waiting for this patch for a while, as I believe either this and/or
the other patch [1] in this patchset could fix the issue.
Could this patch be
This implements the proposed changes for LWG 3537 (which we're allowed
to do as an extension whatever the outcome of the issue). I noticed we
didn't implement LWG 2280 completely, as the std::begin and std::end
overloads for arrays were not noexcept.
libstdc++-v3/ChangeLog:
* include/bits
> Discussion at:
> https://gcc.gnu.org/pipermail/libstdc++/2021-February/052043.html
>
> This patch set includes the uncontroversial parts that improve
> performance but don't otherwise change ABI.
>
> Please note we still need to decide on how to deal with the future ABI
> break.
>
> Thiago Mac
This failure was ultimately from incorrect handling of alias templates,
but required a specific set of occurrences to happen in the
specialization hash table. This cleans up the specialization streaming
to add alias instantiations at the same point as other instantiations.
I also removed som
On Sun, 2021-03-21 at 13:19 +, Richard Sandiford wrote:
> Ilya Leoshkevich writes:
> > Bootstrapped and regtested on x86_64-redhat-linux, ppc64le-redhat-
> > linux
> > and s390x-redhat-linux. Ok for master?
>
> Given what was said downthread, I agree we should fix this for GCC
> 11.
> Sorry
Hi Kyrill,
On 19/03/2021 17:18, Kyrylo Tkachov wrote:
> Hi Alex,
>
> > -Original Message-
> > From: Alex Coplan
> > Sent: 19 March 2021 16:45
> > To: gcc-patches@gcc.gnu.org
> > Cc: ni...@redhat.com; Richard Earnshaw ;
> > Ramana Radhakrishnan ; Kyrylo
> > Tkachov
> > Subject: [PATCH] a
On Sun, 14 Mar 2021, Marcus Comstedt wrote:
> How would you like to proceed? I don't feel confident that I will
> find a definitive solution to this issue anytime soon, but it feels
> like such a weird special case (who passes 64-bit floats in 32-bit
> integer registers to their asm?) that it mig
On 2021-03-22 6:22 a.m., Richard Sandiford wrote:
'\0' is just a normal string null terminator and so I don't think we
should be processing it as if it were a constraint character.
How about having a gcc_unreachable on zero instead?
I would be nice to use gcc_unreachable but it requires to re
>
> gcc/
>
> * config/i386/i386-expand.c (expand_set_or_cpymem_via_rep):
> For TARGET_PREFER_KNOWN_REP_MOVSB_STOSB, don't convert QImode
> to SImode.
> (decide_alg): For TARGET_PREFER_KNOWN_REP_MOVSB_STOSB, use
> "rep movsb/stosb" only for known sizes.
> * conf
On Mon, Mar 22, 2021 at 6:29 AM Richard Biener
wrote:
>
> On Mon, Mar 22, 2021 at 2:19 PM H.J. Lu via Gcc-patches
> wrote:
> >
> > Simply memcpy and memset inline strategies to avoid branches for
> > -mtune=generic:
> >
> > 1. With MOVE_RATIO and CLEAR_RATIO == 17, GCC will use integer/vector
> >
This avoids endless cycling when a PHI node with unchanged backedge
value (the PHI result appearing there) is subject to CSE since doing
that effectively alters the hash entry. The way to avoid this is
to ignore such edges when processing the PHI node.
Bootstrapped and tested on x86_64-unknown-li
On Mon, Mar 22, 2021 at 2:19 PM H.J. Lu via Gcc-patches
wrote:
>
> Simply memcpy and memset inline strategies to avoid branches for
> -mtune=generic:
>
> 1. With MOVE_RATIO and CLEAR_RATIO == 17, GCC will use integer/vector
>load and store for up to 16 * 16 (256) bytes when the data size is
>
Simply memcpy and memset inline strategies to avoid branches for
-mtune=icelake:
1. With MOVE_RATIO and CLEAR_RATIO == 17, GCC will use integer/vector
load and store for up to 16 * 16 (256) bytes when the data size is
fixed and known.
2. Inline only if data size is known to be <= 256.
a.
Simply memcpy and memset inline strategies to avoid branches for
-mtune=generic:
1. With MOVE_RATIO and CLEAR_RATIO == 17, GCC will use integer/vector
load and store for up to 16 * 16 (256) bytes when the data size is
fixed and known.
2. Inline only if data size is known to be <= 256.
a.
Simply memcpy and memset inline strategies to avoid branches for
Skylake family CPUs:
1. With MOVE_RATIO and CLEAR_RATIO == 17, GCC will use integer/vector
load and store for up to 16 * 16 (256) bytes when the data size is
fixed and known.
2. Inline only if data size is known to be <= 256.
Simply memcpy and memset inline strategies to avoid branches:
1. With MOVE_RATIO and CLEAR_RATIO == 17, GCC will use integer/vector
load and store for up to 16 * 16 (256) bytes when the data size is
fixed and known.
2. Inline only if data size is known to be <= 256.
a. Use "rep movsb/stos
On 3/22/2021 2:38 AM, Richard Biener wrote:
This adds a boiler-plate warning to the debug hooks structure to
strongly discourage people from adding new debug hook targets since
we want to get rid of the current abstraction in favor of maintaining
a DWARF view of debug in the middle-end and have
On Mon, Mar 22, 2021 at 1:39 PM Mark Harmstone wrote:
>
> Thanks Richard.
>
> > How do CV and DWARF debug differ and is emitting CV debug from a DWARF
> > representation possible (I suppose there might even exist offline
> > conversion tools?)
>
> I don't know enough about DWARF internals to answe
Thanks Richard.
> How do CV and DWARF debug differ and is emitting CV debug from a DWARF
> representation possible (I suppose there might even exist offline
> conversion tools?)
I don't know enough about DWARF internals to answer that, but I'd be surprised
if the answer is "no".
Do you mean that
On Mon, Mar 22, 2021 at 12:00 PM bin.cheng via Gcc-patches
wrote:
>
> Hi,
>
> This is the patch for PR98736. The root cause is like:
>
> Use programing order preserved RPO in loop distribution.
>
> Tree loop distribution uses RPO to build reduced dependence graph,
> it's important tha
On Mon, Mar 22, 2021 at 12:02 PM Jan Hubicka wrote:
>
> > > Hi,
> > > I plan to commit some retuning of znver3 codegen that is based on real
> > > hardware benchmarks. It turns out that there are not too many changes
> > > necessary sinze Zen3 is quite smooth upgrade to Zen2. In summary:
> > >
>
On 3/20/21 4:40 PM, Martin Liška wrote:
Hi.
The patch fixes the alloc-dealloc-mismatch reported by ASAN.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/cp/ChangeLog:
PR c++/99687
* module.cc (fini_modules): Call vec_
Hi Jakub!
On 2021-03-04T09:52:41+0100, Jakub Jelinek via Gcc-patches
wrote:
> On Thu, Jan 14, 2021 at 07:18:13PM +0100, Thomas Schwinge wrote:
>> libgomp/
>> PR libgomp/65099
>> * plugin/configfrag.ac (PLUGIN_NVPTX): Restrict to supported
>> configurations.
(I had copied for
> > Hi,
> > I plan to commit some retuning of znver3 codegen that is based on real
> > hardware benchmarks. It turns out that there are not too many changes
> > necessary sinze Zen3 is quite smooth upgrade to Zen2. In summary:
> >
> > - some instructions (like idiv) have shorter latencies. Adj
eserved by calling above.
gcc/testsuite/ChangeLog:
PR tree-optimization/98736
* gcc.c-torture/execute/pr98736.c: New test.
pr98736-20210322.txt
Description: Binary data
Segher Boessenkool writes:
> Hi!
>
> On Sat, Mar 20, 2021 at 10:53:32AM -0400, Vladimir Makarov via Gcc-patches
> wrote:
>> It seems CONSTRAINT_LEN treats constraint '\0' as one having length 1.
>
> Maybe we should fix that? See attached patch.
I don't strongly object, but CONSTRAINT_LEN (0) do
The argument is handy when one needs to generate ChangeLog entries
for a different project (e.g. binutils).
contrib/ChangeLog:
* mklog.py: Add --directory argument.
---
contrib/mklog.py | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/contrib/mklog.py b/contrib/mk
gcc/ChangeLog:
PR target/99702
* config/riscv/riscv.c (riscv_expand_block_move): Get RTL value
after type checking.
gcc/testsuite/ChangeLog:
PR target/99702
* gcc.target/riscv/pr99702.c: New.
---
gcc/config/riscv/riscv.c | 2 +-
gcc/testsu
On 3/22/21 9:43 AM, Kumar, Venkataramanan via Gcc-patches wrote:
[AMD Official Use Only - Internal Distribution Only]
Just brief note about this. You CC a public mailing list, thus the disclaimer
does not
make much sense. Please take a look here:
https://gcc.gnu.org/lists.html#policies
Hi
[AMD Official Use Only - Internal Distribution Only]
Hi Honza,
Thank you for working on this.
> -Original Message-
> From: Gcc-patches On Behalf Of Jan
> Hubicka
> Sent: Monday, March 15, 2021 3:33 PM
> To: gcc-patches@gcc.gnu.org; mjam...@suse.cz
> Subject: znver3 tuning part 1
>
>
This adds a boiler-plate warning to the debug hooks structure to
strongly discourage people from adding new debug hook targets since
we want to get rid of the current abstraction in favor of maintaining
a DWARF view of debug in the middle-end and have support for alternate
output formats to be gene
On Sat, Mar 20, 2021 at 5:28 PM Mark Harmstone wrote:
>
> This is a series of patches to allow gcc to emit debugging information
> in the PE-specific CodeView format, which allows Microsoft debuggers to
> work with mingw EXEs. The format is semi-documented: Microsoft have
> open-sourced some of th
On Mon, Mar 22, 2021 at 9:06 AM Richard Biener
wrote:
>
> On Mon, Mar 22, 2021 at 3:04 AM David Edelsohn via Gcc-patches
> wrote:
> >
> > The AIX power alignment rules apply the natural alignment of the
> > "first member" if it is of a floating-point data type (or is an aggregate
> > whose recurs
On Mon, Mar 22, 2021 at 3:04 AM David Edelsohn via Gcc-patches
wrote:
>
> The AIX power alignment rules apply the natural alignment of the
> "first member" if it is of a floating-point data type (or is an aggregate
> whose recursively "first" member or element is such a type). The alignment
> asso
52 matches
Mail list logo
