On Fri, Sep 18, 2020 at 01:13:18PM -0500, Segher Boessenkool wrote:
> Thanks (to both of you). Interesting! Which of these unrelated changes
> does this come from?
Most of the changes I saw in code generation (not in spec, I didn't
look there, but in gcc) came down to this change to the cost for
On Sun, 20 Sep 2020, Jan Hubicka wrote:
> Hi,
> this is patch I am using to fix the assumed_alias_type.f90 failure by
> simply arranging alias set 0 for the problematic array descriptor.
There's no such named testcase on trunk. Can you be more specific
as to the problem at hand? It looks like g
On Fri, 18 Sep 2020, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Sep 17, 2020 at 01:20:35PM +0200, Richard Biener wrote:
> > This adds the capability to look for available negated multiplications
> > and divisions, replacing them with cheaper negates.
>
> It is longer latency than the original i
Qing Zhao writes:
> Hi, Richard,
>
> During my implementation of the new version of the patch. I still feel that
> it’s not practical to add a default definition in the middle end to just use
> move patterns to zero each selected register.
>
> The major issues are:
>
> There are some target spe
Richard Sandiford writes:
[...]
> Andrea, how should we handle this? Is it something you'd have time to
> look at?
Hi Richard,
I've not but FWIW your observations here and on today's mail make alot
of sense to me. We maybe want to install Kewen's fix anyway while we
rework this logic?
Andre
> On Sun, 20 Sep 2020, Jan Hubicka wrote:
>
> > Hi,
> > this is patch I am using to fix the assumed_alias_type.f90 failure by
> > simply arranging alias set 0 for the problematic array descriptor.
>
> There's no such named testcase on trunk. Can you be more specific
> as to the problem at hand?
On Mon, 21 Sep 2020, Jan Hubicka wrote:
> > On Sun, 20 Sep 2020, Jan Hubicka wrote:
> >
> > > Hi,
> > > this is patch I am using to fix the assumed_alias_type.f90 failure by
> > > simply arranging alias set 0 for the problematic array descriptor.
> >
> > There's no such named testcase on trunk.
On 9/8/20 11:22 AM, Rainer Orth wrote:
How am I supposed to install a ChangeLog entry like the one below? The
format is analogous to the one used for backports. Martin?]
Hello.
Currently we do not allow a changelog entry that prepends file changes.
You can put the:
'''
Sync from binu
> >
> > The problem is:
> >
> > alsize (struct array15_unknown & restrict a)
> > {
> > ...
> > _2 = *a_13(D).dtype.rank;
> > _3 = (integer(kind=8)) _2;
> > ...
> > }
> > }
> > and in main:
> >
> > struct array02_integer(kind=4) am;
> >:
> > MEM [(struct dtype_type *)&am + 24B] = {};
On 9/8/20 6:20 PM, Tobias Burnus wrote:
However, the new version of the patch stops after the first
'dg-error/dg-warning'.
LGTM.
Martin
Hi,
these testcases now fails because they contains an invalid type puning
that happens via const VALUE_TYPE *v pointer. Since the check function
is noinline, modref is needed to trigger the wrong code.
I think it is easiest to fix it by no-strict-aliasing.
Regtested x86_64-linux, OK?
* g
On Mon, 21 Sep 2020, Jan Hubicka wrote:
> > >
> > > The problem is:
> > >
> > > alsize (struct array15_unknown & restrict a)
> > > {
> > > ...
> > > _2 = *a_13(D).dtype.rank;
> > > _3 = (integer(kind=8)) _2;
> > > ...
> > > }
> > > }
> > > and in main:
> > >
> > > struct array02_integer(k
On Mon, 21 Sep 2020, Jan Hubicka wrote:
> Hi,
> these testcases now fails because they contains an invalid type puning
> that happens via const VALUE_TYPE *v pointer. Since the check function
> is noinline, modref is needed to trigger the wrong code.
> I think it is easiest to fix it by no-strict-
On Fri, Sep 18, 2020 at 8:18 AM Xiong Hu Luo wrote:
>
> This patch enables transformation from ARRAY_REF(VIEW_CONVERT_EXPR) to
> VEC_SET internal function in gimple-isel pass if target supports
> vec_set with variable index by checking can_vec_set_var_idx_p.
>
> gcc/ChangeLog:
>
> 2020-09-18 Xion
Andrea Corallo writes:
> Richard Sandiford writes:
> [...]
>> Andrea, how should we handle this? Is it something you'd have time to
>> look at?
>
> Hi Richard,
>
> I've not
OK, NP. In that case I'll give it a go.
> but FWIW your observations here and on today's mail make alot
> of sense to me
Richard Sandiford writes:
> Richard Sandiford writes:
>>> @@ -2034,6 +2034,18 @@ aarch64_expand_fpsr_fpcr_setter (int unspec,
>>> machine_mode mode, tree exp)
>>>emit_insn (gen_aarch64_set (unspec, mode, op));
>>> }
>>>
>>> +/* Expand a fpsr or fpcr getter (depending on UNSPEC) using MOD
PING^1
On 9/2/20 1:53 PM, Martin Liška wrote:
On 9/1/20 4:50 PM, David Malcolm wrote:
Hope this is constructive
Dave
Thank you David. All of them very very useful!
There's updated version of the patch.
Martin
On Linux/x86_64,
d119f34c952f8718fdbabc63e2f369a16e92fa07 is the first bad commit
commit d119f34c952f8718fdbabc63e2f369a16e92fa07
Author: Jan Hubicka
Date: Sun Sep 20 07:25:16 2020 +0200
New modref/ipa_modref optimization passes
caused
FAIL: gcc.target/i386/avx-vandnps-1.c execution test
On Linux/x86_64,
d119f34c952f8718fdbabc63e2f369a16e92fa07 is the first bad commit
commit d119f34c952f8718fdbabc63e2f369a16e92fa07
Author: Jan Hubicka
Date: Sun Sep 20 07:25:16 2020 +0200
New modref/ipa_modref optimization passes
caused
FAIL: gcc.target/i386/avx-vandnpd-1.c execution test
Hi all,
>From the `force_reg` description comment I see the returned register
should not be modified, thus IIUC should not be used as a GEN_FCN
target.
Assuming my interpretation is correct this fix this case inside
`aarch64_general_expand_builtin` while expanding expanding the
`__jcvt` intrinsic
Installing as obvious.
Before:
(gdb) p debug_tree(m_index_expr)
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x775ec7e0
precision:64 min max
pointer_to_this >
constant
elt0:
constant 2> elt1: >
After:
(gdb) p debug_tr
With SVE we can end up with:
switch (POLY_INT_CST [2, 2]) [INV], case 2: [INV], case 4:
[INV]>
which is fine to expand and we can remove the assert.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
PR tree-optimization/96915
* tree-switch-conversion.c (switch_conversion:
Andrea Corallo writes:
> Hi all,
>
> From the `force_reg` description comment I see the returned register
> should not be modified, thus IIUC should not be used as a GEN_FCN
> target.
>
> Assuming my interpretation is correct this fix this case inside
> `aarch64_general_expand_builtin` while expan
Hi Andrea,
> -Original Message-
> From: Gcc-patches On Behalf Of
> Richard Sandiford
> Sent: 21 September 2020 11:58
> To: Andrea Corallo
> Cc: Richard Earnshaw ; nd ;
> gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] aarch64: Do not alter value on a force_reg returned rtx
> expanding __j
On 9/6/20 1:24 PM, Sergei Trofimovich wrote:
From: Sergei Trofimovich
Before the change gcc did not stream correctly TOPN counters
if counters belonged to a non-local shared object.
As a result zero-section optimization generated TOPN sections
in a form not recognizable by '__gcov_merge_topn'.
On 9/10/20 1:57 PM, JonY via Gcc-patches wrote:
On 9/10/20 9:44 AM, Richard Biener wrote:
I can confirm liblto is still loaded correctly from the logs, likewise
renaming it away will cause an error.
Seems to be fine on Linux.
OK then.
Thanks,
Richard.
Thanks for reviewing, pushed to mast
On Mon, Sep 21, 2020 at 12:53 PM Martin Liška wrote:
>
> With SVE we can end up with:
> switch (POLY_INT_CST [2, 2]) [INV], case 2: [INV], case
> 4: [INV]>
> which is fine to expand and we can remove the assert.
>
> Ready to be installed?
OK.
Richard.
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
On Mon, Sep 21, 2020 at 1:33 PM Martin Liška wrote:
>
> On 9/10/20 1:57 PM, JonY via Gcc-patches wrote:
> > On 9/10/20 9:44 AM, Richard Biener wrote:
> >>>
> >>> I can confirm liblto is still loaded correctly from the logs, likewise
> >>> renaming it away will cause an error.
> >>>
> >>> Seems to
On 9/21/20 1:33 PM, Martin Liška wrote:
On 9/10/20 1:57 PM, JonY via Gcc-patches wrote:
On 9/10/20 9:44 AM, Richard Biener wrote:
I can confirm liblto is still loaded correctly from the logs, likewise
renaming it away will cause an error.
Seems to be fine on Linux.
OK then.
Thanks,
Richard
On 9/21/20 1:37 PM, Richard Biener wrote:
Isn't that eventually just because the 'gcc' package looks for
liblto_plugin.so.0.0.0 instead of liblto_plugin.so?
Yes.
Martin
The following fixes a dependence check where in the particular place
we cannot ignore self-dependences.
Bootstrapped / tested on x86_64-unknown-linux-gnu, pushed.
2020-09-21 Richard Biener
PR tree-optimization/97135
* tree-ssa-loop-im.c (sm_seq_push_down): Do not ignore
Kyrylo Tkachov writes:
> Hi Andrea,
>
>> -Original Message-
>> From: Gcc-patches On Behalf Of
>> Richard Sandiford
>> Sent: 21 September 2020 11:58
>> To: Andrea Corallo
>> Cc: Richard Earnshaw ; nd ;
>> gcc-patches@gcc.gnu.org
>> Subject: Re: [PATCH] aarch64: Do not alter value on a fo
On Fri, 18 Sep 2020, Patrick Palka wrote:
> This fixes a division by zero in the selection-sampling std::__search
Whoops, this line say std::__sample, not std::__search.
> overload when the input range is empty (and hence __unsampled_sz is 0).
>
> Tested on x86_64-pc-linux-gnu.
>
> libstdc++-v
Since "MASKMOVQ mm1, mm2" is an SSE instruction which requires MMX and
MMX/SSE ISAs are handled separately, make __builtin_ia32_maskmovq require
MMX instead of SSE.
gcc/
PR target/97140
* config/i386/i386-expand.c (ix86_expand_builtin): Require MMX
for __builtin_ia32_maskm
On 9/21/20 11:38 AM, Martin Liška wrote:
> Sorry, it's not caused by your patch. It's our SUSE-specific package setup.
>
How does liblto_plugin.so.0.0.0 get loaded? I find only mentions of
liblto_plugin.so.
Is Suse GCC patched to use the versioned library?
signature.asc
Description: OpenPGP d
On Mon, Sep 21, 2020 at 5:54 AM H.J. Lu wrote:
>
> Since "MASKMOVQ mm1, mm2" is an SSE instruction which requires MMX and
> MMX/SSE ISAs are handled separately, make __builtin_ia32_maskmovq require
> MMX instead of SSE.
>
> gcc/
>
> PR target/97140
> * config/i386/i386-expand.c (ix
On 9/21/20 3:09 PM, JonY wrote:
On 9/21/20 11:38 AM, Martin Liška wrote:
Sorry, it's not caused by your patch. It's our SUSE-specific package setup.
How does liblto_plugin.so.0.0.0 get loaded? I find only mentions of
liblto_plugin.so.
We make a symlink to bfd-plugins folder.
Is Suse GCC
The cast from void* to T* in std::assume_aligned is not valid in a
constexpr function. The optimization hint is redundant during constant
evaluation anyway (the compiler can see the object and knows its
alignment). Simply return the original pointer without applying the
__builtin_assume_aligned hin
libstdc++-v3/ChangeLog:
* include/std/ranges (transform_view, elements_view): Relax
constraints on operator- for iterators, as per LWG 3483.
* testsuite/std/ranges/adaptors/elements.cc: Check that we
can take the difference of two iterators from a non-random
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553321.html
On 06/09/2020 17.23, Armin Brauns wrote:
> There were some differences between the actual code in do_spec_1, its
> source comment, and the documentation in doc/invoke.texi. These should
> now be resolved.
>
Ping.
On 03/09/2020 16:29, Andrew Stubbs wrote:
On 28/08/2020 13:04, Andrew Stubbs wrote:
Hi all,
This patch introduces DWARF CFI support for architectures that require
multiple registers to hold pointers, such as the stack pointer, frame
pointer, and return address. The motivating case is t
On 9/19/20 4:32 PM, Martin Sebor wrote:
On 9/18/20 3:09 PM, Andrew MacLeod wrote:
On 9/18/20 4:35 PM, Martin Sebor wrote:
Do you really need 6 or 10 subranges to find out the answer to the
questions you are looking for? most of the time, 2 or 3 pairs
carries all the information anyone needs a
> On Sep 18, 2020, at 5:51 PM, Segher Boessenkool
> wrote:
>
> Hi!
>
> On Fri, Sep 18, 2020 at 03:31:12PM -0500, Qing Zhao wrote:
>> Let me know your opinion:
>>
>> A. Will not provide default definition in middle end to generate the
>> zeroing insn for selected registers. Move the gener
> On Sep 21, 2020, at 2:23 AM, Richard Sandiford
> wrote:
>
> Qing Zhao mailto:qing.z...@oracle.com>> writes:
>> Hi, Richard,
>>
>> During my implementation of the new version of the patch. I still feel that
>> it’s not practical to add a default definition in the middle end to just use
>>
On 15/09/20 20:35 -0700, Thomas Rodgers wrote:
From: Thomas Rodgers
From llvm-project/pstl @ 0b2e0e80d96
libstdc++-v3/ChangeLog:
* include/pstl/algorithm_impl.h: Update file.
* include/pstl/execution_impl.h: Likewise.
* include/pstl/glue_algorithm_impl.h: Likewise.
On Mon, Sep 14, 2020 at 5:44 PM Thomas Rodgers wrote:
> > On Sep 14, 2020, at 7:30 AM, Ville Voutilainen wrote:
> >
> > On Mon, 14 Sep 2020 at 15:49, Glen Fernandes wrote:
> >> Sounds like a good idea. Updated patch attached.
> >
> > Looks good to me.
>
> Agree.
Rebased patch on latest changes
On 21/09/20 10:42 -0400, Glen Fernandes via Libstdc++ wrote:
On Mon, Sep 14, 2020 at 5:44 PM Thomas Rodgers wrote:
> On Sep 14, 2020, at 7:30 AM, Ville Voutilainen wrote:
>
> On Mon, 14 Sep 2020 at 15:49, Glen Fernandes wrote:
>> Sounds like a good idea. Updated patch attached.
>
> Looks good
On 18/09/20 21:08 -0400, Patrick Palka via Libstdc++ wrote:
As per P0202.
Tested on x86_64-pc-linux-gnu.
libstdc++-v3/ChangeLog:
* include/bits/stl_algo.h (for_each_n): Mark constexpr for C++20.
(search): Likewise for the overload that takes a searcher.
* testsuite/25_a
This fixes SLP live lane extraction with pattern stmts.
Bootstrapped / tested on x86_64-unknown-linux-gnu, pushed.
2020-09-21 Richard Biener
PR tree-optimization/97139
* tree-vect-slp.c (vect_bb_slp_mark_live_stmts): Only mark the
pattern root, track visited vectorized
On 18/09/20 21:08 -0400, Patrick Palka via Libstdc++ wrote:
This fixes a division by zero in the selection-sampling std::__search
overload when the input range is empty (and hence __unsampled_sz is 0).
Tested on x86_64-pc-linux-gnu.
libstdc++-v3/ChangeLog:
* include/bits/stl_algo.h (__
On 9/20/20 12:39 AM, Aldy Hernandez wrote:
On 9/19/20 11:22 PM, Martin Sebor wrote:
On 9/18/20 12:29 AM, Aldy Hernandez wrote:
On 9/17/20 10:18 PM, Martin Sebor wrote:
On 9/17/20 12:39 PM, Andrew MacLeod wrote:
On 9/17/20 12:08 PM, Martin Sebor via Gcc-patches wrote:
On 9/16/20 9:23 PM,
> On Sep 21, 2020, at 7:40 AM, Jonathan Wakely wrote:
>
> On 15/09/20 20:35 -0700, Thomas Rodgers wrote:
>> From: Thomas Rodgers
>>
>> From llvm-project/pstl @ 0b2e0e80d96
>>
>> libstdc++-v3/ChangeLog:
>>
>> * include/pstl/algorithm_impl.h: Update file.
>> * include/pstl/executio
Qing Zhao writes:
> My major concern with the default implementation of the hook is:
>
> If a target has some special registers that should not be zeroed, and we do
> not provide an overridden implementation for this target, then the default
> implementation will generate incorrect code for this
Hi!
On Thu, Sep 17, 2020 at 01:12:19PM +0930, Alan Modra wrote:
> On Wed, Sep 16, 2020 at 07:02:06PM -0500, Segher Boessenkool wrote:
> > > + /* Test both regs even though the one in the mask is
> > > + constrained to be equal to the output. Increasing
> > > +
These testcases need thumb mode, which may not be the default.
Using dg-add-options arm_arch_v8_1m_main ensures that -mthumb is used
and makes the test pass in more configurations.
2020-09-21 Christophe Lyon
gcc/testsuite/
* gcc.target/arm/csinc-1.c: Use dg-add-options
On Tue, Sep 15, 2020 at 04:46:08PM +0930, Alan Modra wrote:
> On Tue, Sep 15, 2020 at 10:49:46AM +0930, Alan Modra wrote:
> > Implement more two insn constants.
>
> And tests. rot_cst1 checks the values generated, rot_cst2 checks
> instruction count.
>
> * gcc.target/powerpc/rot_cst.h,
>
On 21/09/20 08:19 -0700, Thomas Rodgers wrote:
On Sep 21, 2020, at 7:40 AM, Jonathan Wakely wrote:
On 15/09/20 20:35 -0700, Thomas Rodgers wrote:
From: Thomas Rodgers
From llvm-project/pstl @ 0b2e0e80d96
libstdc++-v3/ChangeLog:
* include/pstl/algorithm_impl.h: Update file.
> On Sep 21, 2020, at 10:35 AM, Richard Sandiford
> wrote:
>
> Qing Zhao writes:
>> My major concern with the default implementation of the hook is:
>>
>> If a target has some special registers that should not be zeroed, and we do
>> not provide an overridden implementation for this target
On 18.09.20 13:10, Stefan Schulze Frielinghaus wrote:
> This patch enables a peephole2 optimization which transforms a load of
> constant zero into a temporary register which is then finally used to
> compare against a floating-point register of interest into a single load
> and test instruction.
On Mon, 21 Sep 2020, Martin Liška wrote:
> On 9/6/20 1:24 PM, Sergei Trofimovich wrote:
> > From: Sergei Trofimovich
> >
> > Before the change gcc did not stream correctly TOPN counters
> > if counters belonged to a non-local shared object.
> >
> > As a result zero-section optimization generate
Thanks, I'll apply locally (and sync those changes to the patch I'm
preparing for upstream).
Jonathan Wakely writes:
> On 21/09/20 08:19 -0700, Thomas Rodgers wrote:
>>
>>
>>> On Sep 21, 2020, at 7:40 AM, Jonathan Wakely wrote:
>>>
>>> On 15/09/20 20:35 -0700, Thomas Rodgers wrote:
From:
On Linux/x86_64,
79f4e20dd1280e6a44736070b0d5213f9a8f85d4 is the first bad commit
commit 79f4e20dd1280e6a44736070b0d5213f9a8f85d4
Author: Martin Liska
Date: Wed Sep 2 14:30:16 2020 +0200
Use SIZE_AMOUNT macro for GGC memory allocation numbers.
caused
FAIL: g++.dg/ext/timevar2.C -std=gnu
On Linux/x86_64,
79f4e20dd1280e6a44736070b0d5213f9a8f85d4 is the first bad commit
commit 79f4e20dd1280e6a44736070b0d5213f9a8f85d4
Author: Martin Liska
Date: Wed Sep 2 14:30:16 2020 +0200
Use SIZE_AMOUNT macro for GGC memory allocation numbers.
caused
FAIL: g++.dg/ext/timevar2.C -std=gnu
After this patch, I am seeing this -Warray-parameter error:
In file included from ../include/pthread.h:1,
from ../sysdeps/nptl/thread_db.h:25,
from ../nptl/descr.h:32,
from ../sysdeps/aarch64/nptl/tls.h:44,
from ../include/errno.h
Hi,
The symver support is only available to ELF targets.
tested on x86_64-darwin16,
pushed to master
thanks
Iain
gcc/testsuite/ChangeLog:
* gcc.dg/ipa/symver1.c: Skip for Darwin.
---
gcc/testsuite/gcc.dg/ipa/symver1.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/testsuite/gc
On 9/21/20 12:20 PM, Vaseeharan Vinayagamoorthy wrote:
After this patch, I am seeing this -Warray-parameter error:
In file included from ../include/pthread.h:1,
from ../sysdeps/nptl/thread_db.h:25,
from ../nptl/descr.h:32,
from ../sysdeps/aar
For a span with empty static extent, we currently model the
preconditions of front(), back(), and operator[] as if they were
mandates, by using a static_assert to verify that extent != 0. This
causes us to incorrectly reject valid programs that instantiate these
member functions but never call the
I've been forced[*] to look at the bits of name-lookup I ran away from
when reimplementing namespace-scope lookup at the beginning of this
modules project. Here's the first change in an expected series.
We don't need ts_lambda, as IDENTIFIER_LAMBDA_P is sufficient. Killed
thusly.
g
Recent changes to libbacktrace have introduced a few more globally
symbols. These then need to be renamed in the libsanitizer copy.
This patch does that. Tested by configuring
--with-build-config=bootstrap-asan and running a bootstrap. Committed
to mainline as obvious.
Ian
* libbacktrace/backt
On Mon, Sep 21, 2020 at 12:04 PM Ian Lance Taylor wrote:
>
> Recent changes to libbacktrace have introduced a few more globally
> symbols. These then need to be renamed in the libsanitizer copy.
> This patch does that. Tested by configuring
> --with-build-config=bootstrap-asan and running a boot
On Mon, 21 Sep 2020, Patrick Palka wrote:
> For a span with empty static extent, we currently model the
> preconditions of front(), back(), and operator[] as if they were
> mandates, by using a static_assert to verify that extent != 0. This
> causes us to incorrectly reject valid programs that in
Qing Zhao writes:
>> But in cases where there is no underlying concept that can sensibly
>> be extracted out, it's OK if targets need to override the default
>> to get correct behaviour.
>
> Then, on the target that the default code is not right, and we haven’t
> provide overridden implementation
> On Sep 21, 2020, at 2:11 PM, Richard Sandiford
> wrote:
>
> Qing Zhao writes:
>>> But in cases where there is no underlying concept that can sensibly
>>> be extracted out, it's OK if targets need to override the default
>>> to get correct behaviour.
>>
>> Then, on the target that the defa
On Mon, Sep 21, 2020 at 10:41:19AM -0700, sunil.k.pandey via Gcc-patches wrote:
> On Linux/x86_64,
>
> 79f4e20dd1280e6a44736070b0d5213f9a8f85d4 is the first bad commit
> commit 79f4e20dd1280e6a44736070b0d5213f9a8f85d4
> Author: Martin Liska
> Date: Wed Sep 2 14:30:16 2020 +0200
>
> Use SIZ
On Mon, Sep 21, 2020 at 01:04:27AM -0400, Jason Merrill via Gcc-patches wrote:
> On 9/19/20 5:34 PM, Marek Polacek wrote:
> > I noticed that clang++ has this CTAD warning and thought that it might
> > be useful to have it. From clang++: "Some style guides want to allow
> > using CTAD only on types
DR 1722 clarifies that the conversion function from lambda to pointer to
function should be noexcept(true).
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
gcc/cp/ChangeLog:
PR c++/90583
DR 1722
* lambda.c (maybe_add_lambda_conv_op): Mark the conversion funct
> On Sep 21, 2020, at 2:22 PM, Qing Zhao via Gcc-patches
> wrote:
>
>
>
>> On Sep 21, 2020, at 2:11 PM, Richard Sandiford
>> wrote:
>>
>> Qing Zhao writes:
But in cases where there is no underlying concept that can sensibly
be extracted out, it's OK if targets need to override
On Mon, Sep 21, 2020 at 09:13:58AM -0500, Qing Zhao wrote:
> > On Sep 18, 2020, at 5:51 PM, Segher Boessenkool
> > wrote:
> >> B. Will provide a default definition in middle end to generate the
> >> zeroing insn for selected registers. Then need to add a new target hook
> >> “ZERO_CALL_USED_RE
> On Sep 21, 2020, at 3:34 PM, Segher Boessenkool
> wrote:
>
> On Mon, Sep 21, 2020 at 09:13:58AM -0500, Qing Zhao wrote:
>>> On Sep 18, 2020, at 5:51 PM, Segher Boessenkool
>>> wrote:
B. Will provide a default definition in middle end to generate the
zeroing insn for selected r
The SRA pass relies on the absence of function type attributes
to enable optimization like unused argument elision. The intent
appears to be to avoid messing with the positions of arguments
that may be relied on by some type attributes.
The recent enhancement to detect out-of-bounds accesses by
From: Joel Sherrill
* config/i386/t-rtems: Change from mtune to march when building
multilibs. The mtune argument tunes or optimizes for a specific
CPU model but does not ensure the generated code is appropriate
for the CPU model. Prior to this patch, i386 compati
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553906.html
(I'm working on rebasing the patch on top of the latest trunk which
has changed some of the same code but it'd be helpful to get a go-
ahead on substance the changes. I don't expect the rebase to
require any substantive m
On 21/09/20 15:07 -0400, Patrick Palka via Libstdc++ wrote:
On Mon, 21 Sep 2020, Patrick Palka wrote:
For a span with empty static extent, we currently model the
preconditions of front(), back(), and operator[] as if they were
mandates, by using a static_assert to verify that extent != 0. This
Will, Segher:
The following is the updated patch set for the 128-bit Binary Integer
Operation. I am reposting the entire set for completeness. I have
noted in each patch the changes made since the previous version.
The patches have been tested on Power 8 and Power 9 to ensure there are
no reg
On 9/19/20 3:49 PM, Patrick Palka wrote:
In the testcase below, the dependent specializations iter_reference_t
and iter_reference_t share the same tree due to specialization
caching. So when find_template_parameters walks through the
requires-expression (as part of normalization), it sees and in
On 9/21/20 3:57 PM, Marek Polacek wrote:
On Mon, Sep 21, 2020 at 01:04:27AM -0400, Jason Merrill via Gcc-patches wrote:
On 9/19/20 5:34 PM, Marek Polacek wrote:
I noticed that clang++ has this CTAD warning and thought that it might
be useful to have it. From clang++: "Some style guides want to
On 9/21/20 3:57 PM, Marek Polacek wrote:
DR 1722 clarifies that the conversion function from lambda to pointer to
function should be noexcept(true).
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
gcc/cp/ChangeLog:
PR c++/90583
DR 1722
* lambda.c (ma
This patch to libgo avoids putting golang.org packages in
zstdpkglist.go. This ensures that internal/goroot.IsStandardPackage
does not treat golang.org packages as being in the standard library.
This fixes https://golang.org/issue/41499. Committed to mainline and
GCC 10 branch.
Ian
507f392ade582
This libgo patch by Clément Chigot recognizes aixbigafMagic archives.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
to mainline.
Ian
1b785ecdc817ee14417beb1fd7389622fd8d035f
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index f79a1f04201..d8db888e4b6 100644
libstdc++-v3/ChangeLog:
* include/std/ranges (drop_view::begin()): Adjust constraints
to match the correct condition for O(1) ranges::next (LWG 3482).
* testsuite/std/ranges/adaptors/drop.cc: Check that iterator is
cached for non-sized_range.
Tested powerpc64le-lin
libstdc++-v3/ChangeLog:
* include/bits/c++config (__replacement_assert): Add noreturn
attribute.
(__glibcxx_assert_impl): Use __builtin_expect to hint that the
assertion is expected to pass.
Tested powerpc64le-linux. Committed to trunk.
commit 7db5967f1050eb2b45e9
Whilst debugging the remaining state explosion in PR analyzer/93355
I noticed that half of the states at an exploding program point had:
'malloc': {'&buf': 'non-heap'}
whereas the other half didn't, presumably depending on whether the path
to each enode had used this local buffer:
char buf[400]
Verify that arguments are pointers before calling handling code
that calls deref_rvalue on them.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as r11-3341-g1e19ecd79b45af6df87a6869d1936b857c9f71fc.
gcc/analyzer/ChangeLog:
PR analyzer/97130
* regio
This patch to the Go frontend finalizes methods for type aliases of
struct types. Previously we would finalize the methods of the alias
type itself, but since its a type alias we really need to finalize the
methods of the aliased type.
This patch also handles method expressions of unnamed struct
On Mon, 21 Sep 2020 20:38:07 +0300 (MSK)
Alexander Monakov wrote:
> On Mon, 21 Sep 2020, Martin Liška wrote:
>
> > On 9/6/20 1:24 PM, Sergei Trofimovich wrote:
> > > From: Sergei Trofimovich
> > >
> > > Before the change gcc did not stream correctly TOPN counters
> > > if counters belonged t
On Sun, 2020-09-20 at 19:30 +0200, Jan Hubicka wrote:
> > On Sun, 2020-09-20 at 00:32 +0200, Jan Hubicka wrote:
> > > Hi,
> > > this is cleaned up version of the patch. I removed unfinished
> > > bits,
> > > fixed
> > > propagation, cleaned it up and fixed fallout.
> >
> > [...]
> >
> > > While
Hi!
So, I tested this patch. The test builds Linux for all targets, and the
number reported here is just binary size (usually a good indicator for
combine effectiveness). C0 is the unmodified compiler, C1 is with your
patch. A size of 0 means it did not build.
C0C1
On Mon, Sep 21, 2020 at 10:49:17AM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Sep 17, 2020 at 01:12:19PM +0930, Alan Modra wrote:
> > On Wed, Sep 16, 2020 at 07:02:06PM -0500, Segher Boessenkool wrote:
> > > > + /* Test both regs even though the one in the mask is
> > > > +
Segher, Will:
Add support for converting to/from 128-bit integers and 128-bit
decimal floating point formats.
The updates from the previous version of the patch:
Removed stray ";; carll" comment.
Removed #if 1 and #endif in the test case.
Replaced TARGET_TI_VECTOR_OPS with POWER10.
The pa
Segher, Will:
Patch 1, adds the 128-bit sign extension instruction support and
corresponding builtin support.
No changes from the previous version.
The patch has been tested on
powerpc64le-unknown-linux-gnu (Power 9 LE)
with no regression errors.
Fixed the issues in the ChangeLog noted by
1 - 100 of 115 matches
Mail list logo
