On Tue, Apr 14, 2020 at 12:54:17PM +0200, Martin Liška wrote:
> On 4/14/20 10:37 AM, Jakub Jelinek wrote:
> > On Tue, Apr 14, 2020 at 09:11:37AM +0200, Martin Liška wrote:
> > > +/* PR c++/94314. */
> > > +/* { dg-do run } */
> > > +/* { dg-options "-O2 -fdump-tree-cddce-details -std=c++14" } */
>
On 4/16/20 6:10 PM, Maciej W. Rozycki wrote:
On Thu, 16 Apr 2020, Martin Li?ka wrote:
The patch is fix for Cygwin where we should not define
HAVE_DOS_BASED_FILE_SYSTEM
and use back slashes as a path component separator.
[...]
diff --git a/ltmain.sh b/ltmain.sh
index 79f9ba89af5..8ad183010f0
This fixes the obvious (to me) ones.
Bootstrap & regtest running on x86_64-unknown-linux-gnu.
Richard.
2020-04-17 Richard Biener
PR other/94629
* cgraphclones.c (cgraph_node::create_clone): Remove duplicate
initialization.
* dwarf2out.c (dw_val_equal_p): Fix
On Fri, Apr 17, 2020 at 09:24:34AM +0200, Richard Biener wrote:
> --- a/gcc/optabs.c
> +++ b/gcc/optabs.c
> @@ -1050,7 +1050,7 @@ expand_binop_directly (enum insn_code icode,
> machine_mode mode, optab binoptab,
>commutative_p = commutative_optab_p (binoptab);
>if (commutative_p
>&
Hi!
When I've added the VLA tweak for OpenMP to avoid error_mark_nodes in the IL in
type, I forgot that TYPE_DOMAIN could be NULL. Furthermore, as an optimization,
this patch checks the hopefully cheapest condition that is very likely false
most of the time (enabled only during OpenMP handling) f
On Fri, 17 Apr 2020, Jakub Jelinek wrote:
> On Fri, Apr 17, 2020 at 09:24:34AM +0200, Richard Biener wrote:
> > --- a/gcc/optabs.c
> > +++ b/gcc/optabs.c
> > @@ -1050,7 +1050,7 @@ expand_binop_directly (enum insn_code icode,
> > machine_mode mode, optab binoptab,
> >commutative_p = commutativ
Hi!
delete_insn_and_edges calls purge_dead_edges whenever deleting the last insn
in a bb, whatever it is. If it called it only for mandatory last insns
in the basic block (that may not be followed by DEBUG_INSNs, dunno if that
is control_flow_insn_p or something more complex), that wouldn't be a
> On 15 Apr 2020, at 11:41, Rasmus Villemoes wrote:
> On a somewhat related note, we're currently carrying this locally in
> order to build (link) the vxworks kernel image itself using gcc:
>
> diff --git a/gcc/config/vxworks.h b/gcc/config/vxworks.h
> index 0f604f1bcc4..06b4e2e6870 100644
> --
On Fri, Apr 17, 2020 at 09:39:20AM +0200, Richard Biener wrote:
> On Fri, 17 Apr 2020, Jakub Jelinek wrote:
>
> > On Fri, Apr 17, 2020 at 09:24:34AM +0200, Richard Biener wrote:
> > > --- a/gcc/optabs.c
> > > +++ b/gcc/optabs.c
> > > @@ -1050,7 +1050,7 @@ expand_binop_directly (enum insn_code icod
On Fri, 17 Apr 2020 at 08:05, Jakub Jelinek wrote:
> One needs to use check-c++-all or GXX_TESTSUITE_STDS=98,11,14,17,2a make check
> or similar to get that though, because 11 isn't tested by default, only 98,
> 14 and 17 are ATM I think.
Right.
> Fixed thusly, committed to trunk as obvious.
Alt
On Fri, 17 Apr 2020, Jakub Jelinek wrote:
> Hi!
>
> delete_insn_and_edges calls purge_dead_edges whenever deleting the last insn
> in a bb, whatever it is. If it called it only for mandatory last insns
> in the basic block (that may not be followed by DEBUG_INSNs, dunno if that
> is control_flow
On Fri, 17 Apr 2020, Jakub Jelinek wrote:
> On Fri, Apr 17, 2020 at 09:39:20AM +0200, Richard Biener wrote:
> > On Fri, 17 Apr 2020, Jakub Jelinek wrote:
> >
> > > On Fri, Apr 17, 2020 at 09:24:34AM +0200, Richard Biener wrote:
> > > > --- a/gcc/optabs.c
> > > > +++ b/gcc/optabs.c
> > > > @@ -105
Hi!
As the testcase shows, there are unfortunately more problematic cases
in *testqi_ext_3 if the mode is not CCZmode, because the sign flag might
not behave the same between the insn with zero_extract and what we split it
into.
The previous fix to the insn condition was because *testdi_1 for mas
Hi.
It's quite obvious fix where we ask for a compression algorithm
to file_data->lto_section_header which is unfilled.
Patch works with nvptx offloading compiler and lto.exp works fine
on x86_64-linux-gnu.
Ready to be installed?
Thanks,
Martin
gcc/lto/ChangeLog:
2020-04-17 Martin Liska
On Fri, Apr 17, 2020 at 10:44 AM Martin Liška wrote:
>
> Hi.
>
> It's quite obvious fix where we ask for a compression algorithm
> to file_data->lto_section_header which is unfilled.
>
> Patch works with nvptx offloading compiler and lto.exp works fine
> on x86_64-linux-gnu.
>
> Ready to be instal
Hi Szabolcs,
> -Original Message-
> From: Szabolcs Nagy
> Sent: 09 April 2020 15:20
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw ; Richard Sandiford
> ; Kyrylo Tkachov
> Subject: [PATCH] aarch64, libgcc: Fix unwinding from pac-ret to normal
> frames [PR94514]
>
> With -mbranch-p
Hi Szabolcs,
> -Original Message-
> From: Szabolcs Nagy
> Sent: 09 April 2020 15:20
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw ; Richard Sandiford
> ; Kyrylo Tkachov
> Subject: [PATCH] aarch64: Fix .cfi_window_save with pac-ret [PR94515]
>
> On aarch64 -mbranch-protection=pac-
On Fri, Apr 17, 2020 at 10:29 AM Jakub Jelinek wrote:
>
> Hi!
>
> As the testcase shows, there are unfortunately more problematic cases
> in *testqi_ext_3 if the mode is not CCZmode, because the sign flag might
> not behave the same between the insn with zero_extract and what we split it
> into.
>
On Fri, Apr 17, 2020 at 02:12:19PM +0200, Uros Bizjak wrote:
> Is it possible to perform widening only for !TARGET_PARTIAL_REG_STALL?
> I'm worried that highpart may not be cleared, so the effects of
> partial reg stall can be quite noticeable.
So, like this then?
All I've added was another condit
On Fri, Apr 17, 2020 at 2:38 PM Jakub Jelinek wrote:
>
> On Fri, Apr 17, 2020 at 02:12:19PM +0200, Uros Bizjak wrote:
> > Is it possible to perform widening only for !TARGET_PARTIAL_REG_STALL?
> > I'm worried that highpart may not be cleared, so the effects of
> > partial reg stall can be quite no
I've pushed this patch to avoid a warning introduced by 94426's change
to linkage of lambda.
The arm eabi wants to emit the vtable, other abis don't.
nathan
--
Nathan Sidwell
diff --git i/gcc/testsuite/ChangeLog w/gcc/testsuite/ChangeLog
index dd2cb04916f..b98c72cdd2a 100644
--- i/gcc/testsuite
On 4/17/20 1:53 AM, Richard Biener wrote:
Yeah well, but RTL is not in SSA form and there's no RTL IL verification
in place to track degradation. And we even work in the opposite way
when expanding to RTL from SSA, coalescing as much as we can ...
Which is itself problematic, introducing unne
"duanbo (C)" writes:
> Thank you for your suggestions.
> I have modified accordingly and a full test has been carried, no new failure
> witnessed.
> Attached please find the new patch which has been adjusted to be suitable for
> git am.
> Does the v2 patch look better ?
>
> Thanks,
> Duan bo
When updating an auto return type of an abbreviated function template in
splice_late_return_type, we should also propagate PLACEHOLDER_TYPE_CONSTRAINTS
(and cv-qualifiers) of the original auto node.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK to commit?
gcc/cp/ChangeLog:
Hi Fritz,
First, it appears if simplify_bound_dim returns &gfc_bad_expr (and a
div/0 occurs) then this code will free &gfc_bad_expr. I'm not sure
whether or not that can actually occur, but it is certainly incorrect,
since &gfc_bad_expr points to static storage. The only other possible
case is b
We were seeing performance regressions on 256-bit SVE with code like:
for (int i = 0; i < count; ++i)
#pragma GCC unroll 128
for (int j = 0; j < 128; ++j)
*dst++ = 1;
(derived from lmbench).
For 128-bit SVE, it's clearly better to use Advanced SIMD STPs here,
since they can store 2
On Wed, Apr 8, 2020 at 9:41 AM Jeff Law wrote:
>
> On Wed, 2020-04-08 at 09:23 -0700, H.J. Lu wrote:
> > On Wed, Apr 8, 2020 at 9:16 AM Jeff Law wrote:
> > > On Tue, 2020-03-31 at 08:11 -0700, H.J. Lu via Gcc-patches wrote:
> > > > Since constant_call_address_operand has
> > > >
> > > > ;; Test f
This patch fixes a large lmbench performance regression with
128-bit SVE, compiled in length-agnostic mode.
vect_better_loop_vinfo_p (new in GCC 10) tries to estimate whether
a new loop_vinfo is cheaper than a previous one, with an in-built
preference for the old one. For variable VF it prefers t
Some more C++20 changes from P1614R2, "The Mothership has Landed".
This adds three-way comparison support to std::char_traits,
std::basic_string, std::basic_string_view, and std::sub_match.
* include/bits/basic_string.h (basic_string): Define operator<=> and
remove redundant compa
It turned out that doing
omp enter data map(alloc:FortranArray)
omp exit data map(delete:FortranArray)
left the array descriptor (fortranarray [as opposed to fortranarray.data])
on the device. (cf. -fdump-tree-omplower in the PR.)
Mapping FortranArray again (e.g. "map(tofrom:FortranArray)")
t
Next try – with the proper patch instead of a full test case.
On 4/17/20 5:54 PM, Tobias Burnus wrote:
It turned out that doing
omp enter data map(alloc:FortranArray)
omp exit data map(delete:FortranArray)
left the array descriptor (fortranarray [as opposed to
fortranarray.data])
on the devi
On Thu, Apr 16, 2020 at 08:21:40PM -0500, Segher Boessenkool wrote:
> On Wed, Apr 15, 2020 at 10:18:16AM +0100, Richard Sandiford wrote:
> > luoxhu--- via Gcc-patches writes:
> > > -count = simplify_gen_binary (PLUS, mode, count, const1_rtx);
> > > +{
> > > + /* Fold (add -1; zero_ext
On Fri, Apr 17, 2020 at 05:57:06PM +0200, Tobias Burnus wrote:
> --- a/gcc/gimplify.c
> +++ b/gcc/gimplify.c
> @@ -8785,11 +8785,15 @@ gimplify_scan_omp_clauses (tree *list_p, gimple_seq
> *pre_p,
>'exit data' - and in particular for 'delete:' - having an 'alloc:'
>does not
On 4/16/20 1:53 PM, Patrick Palka wrote:
In this PR (which I think is misclassified as ice-on-invalid instead of
ice-on-valid), we're ICEing on a use of an 'int... a' template parameter pack as
part of the variadic lambda init-capture [...z=a].
The unexpected thing about this variadic init-captu
On 4/16/20 7:33 PM, Patrick Palka wrote:
In the testcase for this PR, we try to parse the statement
A(value<0>());
first tentatively as a declaration (with a parenthesized declarator), and during
this tentative parse we end up issuing a hard error from
cp_parser_check_template_parameters abo
On 4/17/20 6:08 AM, Kyrylo Tkachov wrote:
Hi Szabolcs,
-Original Message-
From: Szabolcs Nagy
Sent: 09 April 2020 15:20
To: gcc-patches@gcc.gnu.org
Cc: Richard Earnshaw ; Richard Sandiford
; Kyrylo Tkachov
Subject: [PATCH] aarch64: Fix .cfi_window_save with pac-ret [PR94515]
On aarch
On Fri, Apr 17, 2020 at 12:45:37PM -0400, Jason Merrill via Gcc-patches wrote:
> On 4/16/20 7:33 PM, Patrick Palka wrote:
> > In the testcase for this PR, we try to parse the statement
> >
> >A(value<0>());
> >
> > first tentatively as a declaration (with a parenthesized declarator), and
> >
Hi Andre,
the patch series passed bootstrap and check with no new fails on Graviton2
aarch64-linux.
Thanks,
Sebastian
On 4/16/20, 12:24 PM, "Pop, Sebastian" wrote:
Thanks Andre for the back-port to gcc-8. Overall the patches look good to
me.
Could you please move the patch "[PA
This patch corrects the requirement of 4,5 and 6th constructor
As per https://en.cppreference.com/w/cpp/utility/any/any.
ChangeLog:
2020-04-17 Kamlesh Kumar
PR libstdc++/92156
* include/std/any (ans::any(_ValueType &&):: Remove
is_constructible.
(any::any(in_place_type
Fixes all this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91630
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90415
On Fri, Apr 17, 2020 at 10:45 PM kamlesh kumar wrote:
>
> This patch corrects the requirement of 4,5 and 6th constructor
> As p
Hi,
This is the 3rd patch of the total 3 patches set for providing the new feature
-mzero-caller-saved-regs for linux kernel security improvement.
This patch is to
Update gcc.target/i386/ret-thunk-2[234].c
Qing
0003-Update-gcc.target-i386-ret-thunk-2-234-.c.patch
Description: Binary data
Hi,
This is the 2nd patch of the total 3 patches set for providing the new feature
-mzero-caller-saved-regs for linux kernel security improvement.
This patch is for resolving the new regressions triggered by the first patch.
This patch is to Add ix86_any_return_p to check simple_return in a PA
Hi,
This is a PING for an old patch proposed by H. J. Lu on Oct, 2018:
https://gcc.gnu.org/legacy-ml/gcc-patches/2018-10/msg02079.html
This is the first patch of the total 3 patches set, which provides the
following new feature:
-mzero-caller-saved-regs=[skip|used-gpr|all-gpr|used|all] co
In the testcase below, during specialization of c::d, we build two
identical specializations of the parameter type b -- one when
substituting into c::d's TYPE_ARG_TYPES and another when substituting into
c::d's DECL_ARGUMENTS.
We don't reuse the first specialization the second time around as a con
The 04/17/2020 12:50, Jason Merrill wrote:
> On 4/17/20 6:08 AM, Kyrylo Tkachov wrote:
> > Hi Szabolcs,
> >
> > > -Original Message-
> > > From: Szabolcs Nagy
> > > Sent: 09 April 2020 15:20
> > > To: gcc-patches@gcc.gnu.org
> > > Cc: Richard Earnshaw ; Richard Sandiford
> > > ; Kyrylo Tk
On Apr 9, 2020, Alexandre Oliva wrote:
> Some target C libraries that aren't recognized as freestanding don't
> have filesystem support, so calling tmpnam, fopen/open and
> remove/unlink fails to link.
> This patch introduces a tmpnam effective target to the testsuite, and
> requires it in the
The vsel instruction is a bit-wise select instruction. Using an
IF_THEN_ELSE to express it in RTL is wrong and leads to wrong code being
generated in the combine pass.
With the patch the pattern is written using bit operations. However,
I've just noticed that the manual still demands a fixed poi
On 4/17/20 9:40 AM, Patrick Palka wrote:
When updating an auto return type of an abbreviated function template in
splice_late_return_type, we should also propagate PLACEHOLDER_TYPE_CONSTRAINTS
(and cv-qualifiers) of the original auto node.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does
On 4/17/20 11:48 AM, Alexandre Oliva wrote:
On Apr 9, 2020, Alexandre Oliva wrote:
Some target C libraries that aren't recognized as freestanding don't
have filesystem support, so calling tmpnam, fopen/open and
remove/unlink fails to link.
This patch introduces a tmpnam effective target to
On 4/17/20 1:35 PM, Patrick Palka wrote:
In the testcase below, during specialization of c::d, we build two
identical specializations of the parameter type b -- one when
substituting into c::d's TYPE_ARG_TYPES and another when substituting into
c::d's DECL_ARGUMENTS.
We don't reuse the first spe
On 4/17/20 1:55 PM, Szabolcs Nagy wrote:
The 04/17/2020 12:50, Jason Merrill wrote:
On 4/17/20 6:08 AM, Kyrylo Tkachov wrote:
Hi Szabolcs,
-Original Message-
From: Szabolcs Nagy
Sent: 09 April 2020 15:20
To: gcc-patches@gcc.gnu.org
Cc: Richard Earnshaw ; Richard Sandiford
; Kyrylo Tk
On Fri, Apr 17, 2020 at 10:33 AM Thomas Koenig wrote:
>
> Hi Fritz,
>
> > First, it appears if simplify_bound_dim returns &gfc_bad_expr (and a
> > div/0 occurs) then this code will free &gfc_bad_expr. I'm not sure
> > whether or not that can actually occur, but it is certainly incorrect,
> > since
As an extension (there should be a CWG about this though), we support
braced-init-list as a template argument, but convert_nontype_argument
had trouble digesting them. We ICEd because of the double coercion we
perform for template arguments: convert_nontype_argument called from
finish_template_typ
On Fri, Apr 17, 2020 at 08:53:08AM +0200, Richard Biener wrote:
> On Thu, Apr 16, 2020 at 7:46 PM Segher Boessenkool
> wrote:
> >
> > On Thu, Apr 16, 2020 at 10:33:45AM +0200, Richard Biener wrote:
> > > On Wed, Apr 15, 2020 at 11:23 PM Segher Boessenkool
> > > > On a general note, we shouldn't de
On 4/17/20 12:19 AM, Jason Merrill wrote:
On 4/15/20 1:30 PM, Martin Sebor wrote:
On 4/13/20 8:43 PM, Jason Merrill wrote:
On 4/12/20 5:49 PM, Martin Sebor wrote:
On 4/10/20 8:52 AM, Jason Merrill wrote:
On 4/9/20 4:23 PM, Martin Sebor wrote:
On 4/9/20 1:32 PM, Jason Merrill wrote:
On 4/9/2
This isn't precisely the same issue that we were originally tracking with 90275,
but it's closely related and we might as well stuff it in the same bucket.
This time instead of having a NOP copy insn that we can completely ignore and
ultimately remove, we have a NOP set within a multi-set PARALLE
On Fri, 2020-04-17 at 08:18 -0700, H.J. Lu wrote:
> On Wed, Apr 8, 2020 at 9:41 AM Jeff Law wrote:
> > On Wed, 2020-04-08 at 09:23 -0700, H.J. Lu wrote:
> > > On Wed, Apr 8, 2020 at 9:16 AM Jeff Law wrote:
> > > > On Tue, 2020-03-31 at 08:11 -0700, H.J. Lu via Gcc-patches wrote:
> > > > > Since c
On Thu, 2020-04-16 at 19:15 -0400, David Malcolm via Gcc-patches wrote:
> Validates. The wording could probably use some work.
>
> OK to push to the website repo?
OK. As are any small updates if you wanted to twiddle the wording.
jeff
>
On Thu, 16 Apr 2020, David Malcolm wrote:
> Validates. The wording could probably use some work.
I did not really spot anything, and rather found your writing very
clear.
> OK to push to the website repo?
Yes, thank you.
> +https://cwe.mitre.org/";>CWE weakness identifiers, which
Here you
Some more C++20 changes from P1614R2, "The Mothership has Landed".
This implements <=> for sequence containers (and the __normal_iterator
and _Pointer_adapter class templates).
* include/bits/forward_list.h (forward_list): Define operator<=> and
remove redundant comparison operato
In C++20 the rebind and const_reference members of std::allocator are
gone, so this testsuite utility stopped working, causing
ext/pb_ds/regression/priority_queue_rand_debug.cc to FAIL.
* testsuite/util/native_type/native_priority_queue.hpp: Use
allocator_traits to rebind allocator
Some more C++20 changes from P1614R2, "The Mothership has Landed".
* include/std/chrono (duration, time_point): Define operator<=> and
remove redundant operator!= for C++20.
* testsuite/20_util/duration/comparison_operators/three_way.cc: New
test.
* testsuit
From: Douglas Rupp
Hello,
(submitting this on behalf of Doug Rupp, one of my colleagues)
We're getting an error when running this test on PowerPC VxWorks 7,
due to an unexpected warning:
| Excess errors:
| cc1: warning: '-mvsx' and '-mno-altivec' are incompatible
The warning comes fro
On Fri, Apr 17, 2020, 10:59 PM kamlesh kumar
wrote:
> Fixes all this.
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92156
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91630
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90415
>
> On Fri, Apr 17, 2020 at 10:45 PM kamlesh kumar
> wrote:
> >
> >
64 matches
Mail list logo
