On Wed, Oct 20, 2021 at 1:14 AM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 10/18/2021 10:54 PM, apinski--- via Gcc-patches wrote:
> > From: Andrew Pinski
> >
> > Instead of putting a full blow DCE after execute_fixup_cfg, it makes sense
> > to try to remove the defining statement for the store th
Endian fix – but not well tested on big endian - hence, reports
whether it now passes are highly welcome (thanks!).
Committed as r12-4528-gd4044db034b40c275b5f287d5854a102d22e07c0
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Ges
On Tue, Oct 19, 2021 at 8:23 PM H.J. Lu wrote:
>
> commit 247c407c83f0015f4b92d5f71e45b63192f6757e
> Author: Roger Sayle
> Date: Mon Oct 18 12:15:40 2021 +0100
>
> Try placing RTL folded constants in the constant pool.
>
> My recent attempts to come up with a testcase for my patch to ev
Am Montag, den 18.10.2021, 12:35 -0400 schrieb Jason Merrill:
> On 10/17/21 09:52, Uecker, Martin wrote:
> >
> > Here is the 4th version of the patch. I tried to implement
> > Jason's suggestion and this also fixes the problem. But
> > I am not sure I understand the condition on
> > the TREE_SIDE_
On Tue, Oct 19, 2021 at 9:05 AM Jonathan Wakely via Gcc-patches
wrote:
>
> +constexpr bool
> +test_copy_elision()
> +{
> + return true;
> +}
> +
> +static_assert( test_copy_elision() );
> +
This isn't much of a test :)
Since _Float16 type is enabled under sse2 target, returning
V8HFmode vector without AVX512F target would generate wrong
vmovdqa64 instruction. Adjust ix86_get_ssemov to avoid this.
Bootstraped/regtested on x86_64-pc-linux-gnu{-m32,} and sde.
OK for master?
gcc/ChangeLog:
PR target/102812
From: dianhong xu
Add -muse-unaligned-vector-move option to emit unaligned vector move
instaructions.
gcc/ChangeLog:
* config/i386/i386-options.c (ix86_target_string): Add
-muse-unaligned-vector-move.
* config/i386/i386.c (ix86_get_ssemov): Emit unaligned vector if use
On 2021-10-20 10:44, Andrew Pinski wrote:
On Tue, Oct 19, 2021 at 7:30 PM Jiufu Guo via Gcc-patches
wrote:
In tree_simplify_using_condition_1, there is code which should be
logic:
"op0 || op1"/"op0 && op1". When creating expression for TRUTH_OR_EXPR
and TRUTH_AND_EXPR, fold_build2 would be
The test gcc.dg/plugin/gil-1.c should be reporting UNSUPPORTED when the
analyzer is not enabled, but instead it's showing up as a FAIL. This is
because it's missing an appropriate dg-require-effective-target marker.
Committed to the trunk,
Jeff
commit f36240f8c835d792f788b6724e272fc0a4a4f26f
> On Sep 26, 2021, at 11:45 PM, Matt Jacobson wrote:
>
> Fix protocol list layout for non-LP64. clang and objc4 both give the `count`
> field as `long`, not `intptr_t`. Those are the same on LP64, but not
> everywhere. For non-LP64, this fixes binary compatibility with clang-built
> class
On 10/19/21 13:15, Jakub Jelinek wrote:
Ok for trunk if it passes bootstrap/regtest.
Pushed now, no new issues seen in bootstrap and regtest.
Thanks,
Siddhesh
On Tue, Oct 19, 2021 at 7:30 PM Jiufu Guo via Gcc-patches
wrote:
>
> In tree_simplify_using_condition_1, there is code which should be logic:
> "op0 || op1"/"op0 && op1". When creating expression for TRUTH_OR_EXPR
> and TRUTH_AND_EXPR, fold_build2 would be used instead fold_binary which
> always
In tree_simplify_using_condition_1, there is code which should be logic:
"op0 || op1"/"op0 && op1". When creating expression for TRUTH_OR_EXPR
and TRUTH_AND_EXPR, fold_build2 would be used instead fold_binary which
always return NULL_TREE for this kind of expr.
Bootstrap and regtest pass on ppc a
Add libffi/ to ignored_prefixes for syncing with libffi upstream:
commit c095f8f2e6f26bfc2ff8e3276c6af23ab153f5ff
Author: H.J. Lu
Date: Tue Aug 31 07:14:47 2021 -0700
libffi: Sync with libffi 3.4.2
Merged commit: f9ea41683444ebe11cfa45b05223899764df28fb
to avoid
remote: *** The foll
On Tue, Oct 19, 2021 at 3:32 PM Andrew MacLeod wrote:
>
> On 10/19/21 5:13 PM, Andrew Pinski wrote:
> > On Tue, Oct 19, 2021 at 1:29 PM Andrew MacLeod via Gcc-patches
> > wrote:
> >> using testcase ifcvt-4.c:
> >>
> >>
> >> typedef int word __attribute__((mode(word)));
> >>
> >> word
> >> foo (wo
On 10/18/2021 10:54 PM, apinski--- via Gcc-patches wrote:
From: Andrew Pinski
Instead of putting a full blow DCE after execute_fixup_cfg, it makes sense
to try to remove the defining statement for the store that is being removed.
Right now we only handle PHI node statements as there needs no
On 10/18/2021 10:54 PM, apinski--- via Gcc-patches wrote:
From: Andrew Pinski
To make it easier to fix PR 102703, factoring this code out
to its own function makes it easier to read and less indentions
too.
gcc/ChangeLog:
* tree-cfg.c (maybe_remove_writeonly_store): New function
On 10/18/2021 10:54 PM, apinski--- via Gcc-patches wrote:
From: Andrew Pinski
The comment about execute_fixup_cfg not being able to
run as a standalone pass is not true for a long time
now. It has been a standalone pass for a while now.
gcc/ChangeLog:
* tree-cfg.c (execute_fixup_c
On 10/18/2021 10:54 PM, apinski--- via Gcc-patches wrote:
From: Andrew Pinski
While debugging PR 102703, I found it was hard to figure out where
the store was being removed as there was no pass which was outputting
why the store was removed.
This adds to execute_fixup_cfg the output.
Also no
On 10/19/2021 1:33 AM, Aldy Hernandez wrote:
On Tue, Oct 19, 2021 at 8:52 AM Richard Biener
wrote:
On Mon, Oct 18, 2021 at 4:03 PM Aldy Hernandez wrote:
On 10/18/21 3:41 PM, Aldy Hernandez wrote:
I've been experimenting with reducing the total number of threading
passes, and I'd like t
On 10/18/2021 8:03 AM, Aldy Hernandez wrote:
On 10/18/21 3:41 PM, Aldy Hernandez wrote:
I've been experimenting with reducing the total number of threading
passes, and I'd like to see if there's consensus/stomach for altering
the pipeline. Note, that the goal is to remove forward threader
On 10/18/2021 7:41 AM, Aldy Hernandez wrote:
After some playing, it looks like if we enable fully-resolving mode in
the *.thread passes immediately preceeding VRP, we can remove the VRP
threading passes altogether, thus removing 2 threading passes (and
forward threading passes at that!).
Who
On 10/19/21 5:13 PM, Andrew Pinski wrote:
On Tue, Oct 19, 2021 at 1:29 PM Andrew MacLeod via Gcc-patches
wrote:
using testcase ifcvt-4.c:
typedef int word __attribute__((mode(word)));
word
foo (word x, word y, word a)
{
word i = x;
word j = y;
/* Try to make taking the branch lik
On Tue, Oct 19, 2021 at 1:29 PM Andrew MacLeod via Gcc-patches
wrote:
>
> using testcase ifcvt-4.c:
>
>
> typedef int word __attribute__((mode(word)));
>
> word
> foo (word x, word y, word a)
> {
>word i = x;
>word j = y;
>/* Try to make taking the branch likely. */
>__builtin_exp
That's odd. Yeah, please open a PR.
Thanks.
Aldy
On Tue, Oct 19, 2021, 22:47 Jan-Benedict Glaw wrote:
> Hi Aldy!
>
> On Thu, 2021-10-14 16:25:48 +0200, Aldy Hernandez via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
> > The new backward threader makes some of the --param knobs used to
> > co
Hi Aldy!
On Thu, 2021-10-14 16:25:48 +0200, Aldy Hernandez via Gcc-patches
wrote:
> The new backward threader makes some of the --param knobs used to
> control it questionable at best or no longer applicable at worst.
>
> The fsm-maximum-phi-arguments param is unused and can be removed.
>
> Th
using testcase ifcvt-4.c:
typedef int word __attribute__((mode(word)));
word
foo (word x, word y, word a)
{
word i = x;
word j = y;
/* Try to make taking the branch likely. */
__builtin_expect (x > y, 1);
if (x > y)
{
i = a;
j = i;
}
return i * j;
The current V
On Linux/x86_64,
247c407c83f0015f4b92d5f71e45b63192f6757e is the first bad commit
commit 247c407c83f0015f4b92d5f71e45b63192f6757e
Author: Roger Sayle
Date: Mon Oct 18 12:15:40 2021 +0100
Try placing RTL folded constants in the constant pool.
caused
FAIL: gcc.target/i386/pr22076.c scan-as
Clement,
+ /* Use __C_runtime_pstartup to run ctors and register dtors.
+ This whole part should normally be in libgcc but as
+ AIX cdtors format is currently not the default, managed
+ that in collect2. */
Why are you emitting the special startup function call in collect2.c
instead of plac
On Tue, 19 Oct 2021 at 15:35, Patrick Palka via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> This patch also reverts the r11-3504 workaround since it's made obsolete
> by this resolution.
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk only?
>
OK, thanks.
> libstdc++-v3/ChangeLog:
gcc/ChangeLog:
* doc/extend.texi (Basic PowerPC Built-in Functions): Fix typo.
Committed as obvious.
commit c6a1fdd6dde3a95997731c8339d70970aca67594
Author: Jonathan Wakely
Date: Tue Oct 19 20:37:53 2021
doc: Fix typo in name of PowerPC __builtin_cpu_supports built-in
On Thu, Oct 14, 2021 at 5:13 PM Fangrui Song wrote:
>
> On 2021-10-06, Fangrui Song wrote:
> >On 2021-09-27, Fangrui Song wrote:
> >>On 2021-09-27, Florian Weimer wrote:
> >>>* Fangrui Song:
> >>>
> Sanitizer runtimes need static TLS boundaries for a variety of use cases.
>
> * asan/h
On 10/10/21 07:28, Anthony Sharp wrote:
Hi Jason,
Hope you are well. Thanks for the feedback.
I like adding the configurability, but I think let's keep committing as
the default behavior. And adding the parameter to the rollback function
seems unnecessary. For the behavior argumen
On 10/19/21 11:21, Jakub Jelinek wrote:
On Tue, Oct 19, 2021 at 10:48:04AM -0400, Jason Merrill wrote:
What if we use NULL_TREE for the error case instead of error_mark_node, i.e.
- DECL_LOCAL_DECL_ALIAS (decl) = alias;
+ if (alias != error_mark_node)
+DECL_LOCAL_DECL_ALIAS (decl) = alias
On Tue, 19 Oct 2021, 19:30 Patrick Palka via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk and branches?
>
Yes, thanks.
> libstdc++-v3/ChangeLog:
>
> * include/bits/ranges_util.h
> (__detail::__uses_nonqualification_point
On Tue, 19 Oct 2021, 19:31 Patrick Palka via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
Yes, thanks.
(The branches don't have P2325R3.)
>
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges (basic_istream_view::_M_object): V
On Tue, 19 Oct 2021, 19:33 Patrick Palka via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk and branches?
>
Yes, thanks.
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges (iota_view::operator+): Adjust definition
> as p
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and branches?
libstdc++-v3/ChangeLog:
* include/std/ranges (iota_view::operator+): Adjust definition
as per LWG 3580.
(iota_view::operator-): Likewise.
---
libstdc++-v3/include/std/ranges | 10 --
1 file c
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
(The branches don't have P2325R3.)
libstdc++-v3/ChangeLog:
* include/std/ranges (basic_istream_view::_M_object): Value
initialize as per LWG 3568.
---
libstdc++-v3/include/std/ranges | 2 +-
1 file changed, 1 insertion(+
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and branches?
libstdc++-v3/ChangeLog:
* include/bits/ranges_util.h
(__detail::__uses_nonqualification_pointer_conversion): Define
and use it ...
(__convertible_to_nonslicing): ... here, as per LWG 3470.
commit 247c407c83f0015f4b92d5f71e45b63192f6757e
Author: Roger Sayle
Date: Mon Oct 18 12:15:40 2021 +0100
Try placing RTL folded constants in the constant pool.
My recent attempts to come up with a testcase for my patch to evaluate
ss_plus in simplify-rtx.c, identified a missed opti
On Tue, Oct 19, 2021 at 8:03 AM David Edelsohn wrote:
>
> Hi, H.J.
>
> My colleague built GCC, including GCC Go, with your patch:
>
> "I was able to build libgo and test it partially. The results are
> similar to the current master without libffi updates. But 64bit tests
> aren't working in both
The ISA-3.0 instruction set includes DARN ("deliver a random number")
which can be used similar to the existing support for RDRAND and RDSEED.
libstdc++-v3/ChangeLog:
* src/c++11/random.cc (USE_DARN): Define.
(__ppc_darn): New function to use POWER9 DARN instruction.
(Whic
Currently this function only returns a non-zero value for /dev/random
and /dev/urandom. When a hardware instruction such as RDRAND is in use
it should (in theory) be perfectly random and produce 32 bits of entropy
in each 32-bit result. Add a helper function to identify the source of
randomness fro
In r12-826 I tried to remove some redundant steps from the doxygen
build, but they are needed when configure is run as a relative path. The
use of pwd is to resolve the relative path to an absolute one.
libstdc++-v3/ChangeLog:
* doc/Makefile.am (stamp-html-doxygen, stamp-html-doxygen)
On Tue, Oct 19, 2021 at 09:32:20AM -0500, Segher Boessenkool wrote:
> On Mon, Oct 18, 2021 at 08:15:12PM -0500, Paul A. Clarke via Gcc-patches
> wrote:
> > Some compatibility implementations of x86 intrinsics include
> > Power intrinsics which require POWER8. Guard them.
>
> I assume this improv
On Tue, Oct 19, 2021 at 10:48:04AM -0400, Jason Merrill wrote:
> What if we use NULL_TREE for the error case instead of error_mark_node, i.e.
>
> - DECL_LOCAL_DECL_ALIAS (decl) = alias;
> + if (alias != error_mark_node)
> +DECL_LOCAL_DECL_ALIAS (decl) = alias;
>
> ? That ought to avoid the
Hi, H.J.
My colleague built GCC, including GCC Go, with your patch:
"I was able to build libgo and test it partially. The results are
similar to the current master without libffi updates. But 64bit tests
aren't working in both cases. It's related to LIBPATH issues..."
- David
On Mon, Oct 18, 2
On 10/18/21 16:35, Richard Sandiford wrote:
Jason Merrill writes:
On 9/24/21 13:53, Richard Sandiford wrote:
+ if (type == error_mark_node)
+return lhd_simulate_record_decl (loc, name, fields);
Why fall back to the language-independent function on error? Is there a
case where that give
Hi Richard,
> The problem is that you're effectively asking for these values to be
> taken on faith without providing any analysis and without describing
> how you arrived at the new numbers. Did you try other values too?
> If so, how did they compare with the numbers that you finally chose?
> At
On 16.10.21 20:54, Jan Hubicka wrote:
I wrote:
Fortran has for a long time 'character(len=5), allocatable" or
"character(len=*)". In the first case, the "5" can be ignored as both
caller and callee know the length. In the second case, the length is
determined by the argument, but it cannot be ch
On 10/11/21 07:18, Jakub Jelinek wrote:
Hi!
My recent push_local_extern_decl_alias change broke error-recovery,
do_pushdecl can return error_mark_node and set_decl_tls_model can't be
called on that. There are other code paths that store error_mark_node
into DECL_LOCAL_DECL_ALIAS, with the inten
On 10/19/21 16:23, Segher Boessenkool wrote:
On Fri, Oct 15, 2021 at 05:24:32PM +0200, Martin Liška wrote:
On 10/14/21 17:10, Bill Schmidt via Gcc-patches wrote:
Looks like you got your parentheses wrong here.
Whoops, thanks for the heads up.
I'm testing this fixed version.
Please start a
On 19 October 2021 15:23:58 CEST, Richard Sandiford via Gcc-patches
wrote:
>Wilco Dijkstra writes:
>> Hi Richard,
>>
>>> I'm just concerned that here we're using the same explanation but with
>>> different numbers. Why are the new numbers more right than the old ones
>>> (especially when it com
This patch also reverts the r11-3504 workaround since it's made obsolete
by this resolution.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk only?
libstdc++-v3/ChangeLog:
* include/bits/ranges_base.h (view_interface): Forward declare.
(__detail::__is_derived_from_view_
On Mon, Oct 18, 2021 at 08:15:12PM -0500, Paul A. Clarke via Gcc-patches wrote:
> Some compatibility implementations of x86 intrinsics include
> Power intrinsics which require POWER8. Guard them.
I assume this improves on all previous commented things (you don't say
if it does).
> gcc
> PR
On Tue, Oct 19, 2021 at 08:10:06AM -0500, Bill Schmidt via Gcc-patches wrote:
> Hi Paul,
>
> On 10/18/21 8:15 PM, Paul A. Clarke wrote:
> > Fix an ommission in commit 29fb1e831bf1c25e4574bf2f98a9f534e5c67665.
(Typo, s/mm/m/)
> > 2021-10-18 Paul A. Clarke
> >
> > gcc
> > * config/config.gc
Prathamesh Kulkarni writes:
> Hi,
> The attached patch emits a more verbose diagnostic for target attribute that
> is an architecture extension needing a leading '+'.
>
> For the following test,
> void calculate(void) __attribute__ ((__target__ ("sve")));
>
> With patch, the compiler now emits:
>
On Fri, Oct 15, 2021 at 05:24:32PM +0200, Martin Liška wrote:
> On 10/14/21 17:10, Bill Schmidt via Gcc-patches wrote:
> >Looks like you got your parentheses wrong here.
>
> Whoops, thanks for the heads up.
>
> I'm testing this fixed version.
Please start a new thread for every new patch (series
Hi!
On Thu, Oct 14, 2021 at 09:49:30AM +0200, Martin Liška wrote:
> gcc/ChangeLog:
> * config/rs6000/rs6000.c (rs6000_override_options_after_change):
> Do not set flag_rename_registers, it's already default behavior.
It defaults to *off*?
frename-registers
Common Var(flag_rename_regi
This refactors vect_supportable_dr_alignment to get the misalignment
as input parameter which allows us to elide modifying/restoring
of DR_MISALIGNMENT during alignment peeling analysis which eventually
makes it more straight-forward to split out the negative step
handling.
Bootstrapped and tested
On Tue, Oct 19, 2021 at 09:03:06PM +0800, Chung-Lin Tang wrote:
> 2021-10-19 Chung-Lin Tang
>
> gcc/fortran/ChangeLog:
>
> * openmp.c (gfc_match_omp_clause_reduction): Add 'openmp_target' default
> false parameter. Add 'always,tofrom' map for OMP_LIST_IN_REDUCTION case.
> (gf
This more clearly expresses the intent (a completely unused, trivial
type) than using char. It's also consistent with the unions in
std::optional.
libstdc++-v3/ChangeLog:
* include/std/variant (_Uninitialized): Use an empty struct
for the unused union member, instead of char.
Tes
Another new addition to the C++23 working draft.
The new member functions of std::optional are only defined for C++23,
but the new members of _Optional_payload_base are defined for C++20 so
that they can be used in non-propagating-cache in . The
_Optional_payload_base::_M_construct member can also
libstdc++-v3/ChangeLog:
* include/bits/stl_stack.h (stack(Iterator, Iterator)): Remove
non-deducible template parameter from deduction guide.
* testsuite/23_containers/stack/deduction.cc: Check new C++23
deduction guides.
Tested powerpc64le-linux. Committed to trun
On October 19, 2021 2:35:47 PM GMT+02:00, Jan Hubicka via Gcc-patches
wrote:
>Hi,
>this patch fixes two issues I noticed while proofreading the code.
>First is that I have added conditional around setting of nonlocal and
>escaped flags (since they may be set from solver) while keeping the
>variab
On Tue, Oct 19, 2021 at 02:00:21PM +0200, Jakub Jelinek via Gcc-patches wrote:
> And another thing isn't in a patch, but I'm wondering whether we don't
> handle it incorrectly. constexpr.c has:
> /* Check that immediate invocation does not return an expression referencing
> any immediate fu
Wilco Dijkstra writes:
> Hi Richard,
>
>> I'm just concerned that here we're using the same explanation but with
>> different numbers. Why are the new numbers more right than the old ones
>> (especially when it comes to code size, where the trade-off hasn't
>> really changed)?
>
> Like all tuning
Here, the problem is that the param.expr was:
&"abc" -> type: "char*"
as that's an ADDR_EXPR, the previous code dereferrenced it:
*&"abc" -> type *(char*)
but that's the type 'char'. Thus, at the end, the result
was
scalar = 'a' -> type char
instead of
scalar "abc" -> type char array of s
Hi Paul,
On 10/18/21 8:15 PM, Paul A. Clarke wrote:
> Fix an ommission in commit 29fb1e831bf1c25e4574bf2f98a9f534e5c67665.
>
> 2021-10-18 Paul A. Clarke
>
> gcc
> * config/config.gcc (extra_headers): Add nmmintrin.h.
> ---
> gcc/config.gcc | 1 +
> 1 file changed, 1 insertion(+)
>
> diff
Hi Martin,
On 10/19/21 3:53 AM, Martin Liška wrote:
> On 10/15/21 17:24, Martin Liška wrote:
>> P.S. Next time, please CC me.
>
> All right, I tested the updated patch and it works fine
> on ppc64le-linux-gnu.
>
> May I install it?
I'm not a maintainer, so can't approve -- CCing those who can.
T
Hi Jakub,
On 2021/9/18 12:11 AM, Jakub Jelinek wrote:
@@ -3496,7 +3509,8 @@ static match
match_omp (gfc_exec_op op, const omp_mask mask)
{
gfc_omp_clauses *c;
- if (gfc_match_omp_clauses (&c, mask) != MATCH_YES)
+ if (gfc_match_omp_clauses (&c, mask, true, true, false,
+
Hi Richard,
> I'm just concerned that here we're using the same explanation but with
> different numbers. Why are the new numbers more right than the old ones
> (especially when it comes to code size, where the trade-off hasn't
> really changed)?
Like all tuning/costing parameters, these values
The garbage collector of AIX linker might remove the reference to
__tls_get_addr if it's added inside an unused csect, which can be
the case of .data with very simple programs.
gcc/ChangeLog:
2021-10-19 Clément Chigot
* config/rs6000/rs6000.c (rs6000_xcoff_file_end): Move
__tls
On Tue, 19 Oct 2021 at 13:18, Patrick Palka via Libstdc++
wrote:
>
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges (iota_view::_Iterator): Befriend iota_view.
> (iota_view::_Sentinel): Likewise.
> (iota_view::iota_view): Add three overloads each taking an
> itera
Hi,
this patch fixes two issues I noticed while proofreading the code.
First is that I have added conditional around setting of nonlocal and
escaped flags (since they may be set from solver) while keeping the
variable in assignment that is confusing.
Second is that we still do not set pt in the ca
Martin Liška writes:
> On 10/19/21 12:52, Richard Sandiford wrote:
>> It looks like this ought to happen after the alloca and copy, since it
>> modifies the string.
>
> Oh yeah, good point.
>
> Ready to be installed with the change?
> Thanks,
> Martin
>
> From 68df4cba3bccb714a14e3c795e6d9e4a44c54
On 10/19/21 12:52, Richard Sandiford wrote:
It looks like this ought to happen after the alloca and copy, since it
modifies the string.
Oh yeah, good point.
Ready to be installed with the change?
Thanks,
MartinFrom 68df4cba3bccb714a14e3c795e6d9e4a44c54318 Mon Sep 17 00:00:00 2001
From: Martin
This implements P1739R4 along with the resolution for LWG 3407 which
corrects the paper's wording.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/bits/ranges_util.h (views::_Drop): Forward declare.
(subrange): Befriend views::_Drop.
libstdc++-v3/ChangeLog:
* include/std/ranges (iota_view::_Iterator): Befriend iota_view.
(iota_view::_Sentinel): Likewise.
(iota_view::iota_view): Add three overloads each taking an
iterator/sentinel pair as per LWG 3523.
* testsuite/std/ranges/iota/iota_vie
On Mon, Oct 18, 2021 at 12:42:00PM -0400, Jason Merrill wrote:
> > --- gcc/cp/typeck.c.jj 2021-10-05 09:53:55.382734051 +0200
> > +++ gcc/cp/typeck.c 2021-10-15 19:28:38.034213437 +0200
> > @@ -6773,9 +6773,21 @@ cp_build_addr_expr_1 (tree arg, bool str
> > return error_mark_node;
> >
This passes down the already available alignment scheme and
misalignment to the load/store costing routines, removing
redundant queries.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-10-19 Richard Biener
* tree-vect-data-refs.c (vect_get_data_access_cost): Get
On 10/19/21 12:55 PM, Richard Biener wrote:
On Tue, Oct 19, 2021 at 10:48 AM Aldy Hernandez wrote:
As suggested. Thanks.
gcc/ChangeLog:
* passes.def: Change threading comment before pass_ccp pass.
---
gcc/passes.def | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
di
On Tue, 19 Oct 2021, Prathamesh Kulkarni wrote:
> On Tue, 19 Oct 2021 at 13:02, Richard Biener
> wrote:
> >
> > On Tue, Oct 19, 2021 at 9:03 AM Prathamesh Kulkarni via Gcc-patches
> > wrote:
> > >
> > > On Mon, 18 Oct 2021 at 17:23, Richard Biener wrote:
> > > >
> > > > On Mon, 18 Oct 2021, Pr
ChangeLog:
2021-10-19 Clément Chigot
* MAINTAINERS: Add myself for write after approval.
From 13ddc381ea7bde6df9e48fb968d9324564f7a540 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Cl=C3=A9ment=20Chigot?=
Date: Tue, 19 Oct 2021 13:20:14 +0200
Subject: [PATCH] MAINTAINERS: Add myself for wri
On Tue, 19 Oct 2021 at 13:02, Richard Biener wrote:
>
> On Tue, Oct 19, 2021 at 9:03 AM Prathamesh Kulkarni via Gcc-patches
> wrote:
> >
> > On Mon, 18 Oct 2021 at 17:23, Richard Biener wrote:
> > >
> > > On Mon, 18 Oct 2021, Prathamesh Kulkarni wrote:
> > >
> > > > On Mon, 18 Oct 2021 at 17:10,
On Tue, Oct 19, 2021 at 10:48 AM Aldy Hernandez wrote:
>
> As suggested. Thanks.
>
> gcc/ChangeLog:
>
> * passes.def: Change threading comment before pass_ccp pass.
> ---
> gcc/passes.def | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/gcc/passes.def b/gcc/pas
On Tue, Oct 19, 2021 at 11:34 AM Martin Liška wrote:
>
> On 10/19/21 11:12, Richard Biener wrote:
> > On Fri, Oct 15, 2021 at 5:22 PM Martin Liška wrote:
> >>
> >> All right, and there's second part that moves the code
> >> from toplev.c to opts.c (finish_options) as I've done in the original
>
Martin Liška writes:
> Hello.
>
> The patch does the same as g:df592811f950301ed3b10a08e476dad0f2eff26a for
> aarch64.
>
> Tested locally with cross compiler.
>
> Ready for master?
>
> Thanks,
> Martin
>
> PR target/102375
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64.c (aarch64_pro
libstdc++-v3/ChangeLog:
PR libstdc++/102825
* include/bits/mofunc_impl.h (move_only_function): Remove
invalid base initializer.
* testsuite/20_util/move_only_function/cons.cc: Instantiate
constructors to check bodies.
Tested powerpc64le-linux. Committed to
This moves the computation of a negative offset that needs to be
applied when we vectorize a negative stride access to
get_load_store_type alongside where we compute the actual access
method.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-10-19 Richard Biener
* tree
The PR shows that when carefully crafting the runtime alias
condition in the vectorizer we might end up using defs from
the loop preheader but will end up inserting the condition
before the .LOOP_VECTORIZED call. So the following makes
sure to insert invariants before that when we versioned the
lo
On 10/19/21 11:12, Richard Biener wrote:
On Fri, Oct 15, 2021 at 5:22 PM Martin Liška wrote:
All right, and there's second part that moves the code
from toplev.c to opts.c (finish_options) as I've done in the original version.
The patch also handles PR102766 where nvptx.c target sets:
debug_n
On Tue, Oct 19, 2021 at 11:06 AM Aldy Hernandez wrote:
>
>
>
> On 10/19/21 10:40 AM, Richard Biener wrote:
> > On Tue, Oct 19, 2021 at 9:33 AM Aldy Hernandez wrote:
> >>
> >> On Tue, Oct 19, 2021 at 8:52 AM Richard Biener
> >> wrote:
> >>>
> >>> On Mon, Oct 18, 2021 at 4:03 PM Aldy Hernandez wr
Hello.
The patch does the same as g:df592811f950301ed3b10a08e476dad0f2eff26a for
aarch64.
Tested locally with cross compiler.
Ready for master?
Thanks,
Martin
PR target/102375
gcc/ChangeLog:
* config/aarch64/aarch64.c (aarch64_process_one_target_attr):
Strip whitespa
On Fri, Oct 15, 2021 at 5:22 PM Martin Liška wrote:
>
> All right, and there's second part that moves the code
> from toplev.c to opts.c (finish_options) as I've done in the original version.
>
> The patch also handles PR102766 where nvptx.c target sets:
> debug_nonbind_markers_p = 0;
>
> So the e
On 10/19/21 10:40 AM, Richard Biener wrote:
On Tue, Oct 19, 2021 at 9:33 AM Aldy Hernandez wrote:
On Tue, Oct 19, 2021 at 8:52 AM Richard Biener
wrote:
On Mon, Oct 18, 2021 at 4:03 PM Aldy Hernandez wrote:
On 10/18/21 3:41 PM, Aldy Hernandez wrote:
I've been experimenting with red
updated patch:
1. Add documents in doc/sourcebuild.texi (Effective-Target Keywords).
2. Reduce -novec.c testcases to contain only new failed parted which
is caused by O2 vectorization.
3. Add PR in dg-warning comment.
As discussed in [1], this patch add xfail/target selector to those
testcas
Committed as r12-4494. Thanks to all of you.
Gui Haochen
On 15/10/2021 上午 2:53, David Edelsohn wrote:
On Thu, Oct 14, 2021 at 2:17 AM HAO CHEN GUI wrote:
Hi,
The patch optimizes the code generation for vec_xl_sext builtin. Now all
the sign extensions are done on VSX registers directly.
On 10/15/21 17:24, Martin Liška wrote:
P.S. Next time, please CC me.
All right, I tested the updated patch and it works fine
on ppc64le-linux-gnu.
May I install it?
Thanks,
Martin
1 - 100 of 112 matches
Mail list logo
