*ping*
On 10/14/19 3:11 PM, Tobias Burnus wrote:
This is a follow-up patch to the use_device_addr work. In particular,
it replaces the patch at
https://gcc.gnu.org/ml/fortran/2019-09/msg00088.html
Fortran array descriptors need special handling, which this patch adds.
[The use_device-addr-{3
After the latest changes we now end up building more SLP nodes from
scalars - the fact that we have SLP childs for externals triggers this
for the case where previously all ops were external (no scalar build
was considered). The following adjusts the heuristic to treat
constant operands as profi
Update patch:
Add m constraint to define_insn (sse_1_round):
Change constraint x to xm
since vround support memory operand.
* (*sse4_1_round): Ditto.
Bootstrap and regression test ok.
On Wed, Oct 23, 2019 at 9:56 AM Hongtao Liu wrote:
>
> Hi uros:
> This patch fixes false depen
Michael,
> I've only noticed a couple typos, and one minor remark.
Typos corrected.
> I just wonder why you duplicated these three loops instead of integrating
> the real body into the existing LI_FROM_INNERMOST loop. I would have
> expected your "if (!optimize_loop_for_size_p && split_loop_on_
---
gcc/cp/mangle.c| 3 ++-
gcc/testsuite/g++.dg/cpp0x/nullptr27.C | 2 +-
gcc/testsuite/g++.dg/cpp0x/pr91979.C | 15 +++
libiberty/cp-demangle.c| 10 ++
libiberty/testsuite/demangle-expected | 4
5 files changed, 32 insertions
Hi uros:
This patch fixes false dependence of scalar operations
vrcp/vsqrt/vrsqrt/vrndscale.
Bootstrap ok, regression test on i386/x86 ok.
It does something like this:
-
For scalar instructions with both xmm operands:
op %xmmN,%xmmQ,%xmmQ > op %xmmN, %xmmN, %xmmQ
for scalar instruc
0001-Add-support-for-C-2a-stop_token.patch
Description: le patch
On Mon, Oct 21, 2019 at 5:26 AM Andrew Burgess
wrote:
> Below is a new versions of this patch, I believe that this addresses
> the review comments from the earlier version. In addition this has
> been tested using Jim's idea of forcing -msave-restore (if the flag is
> not otherwise given) and I n
> commit b948d3f92d7bbe4d53237cb20ff40a15fa123988
> Author: Jonathan Wakely
> Date: Thu Oct 17 15:20:38 2019 +0100
>
> Define [range.cmp] comparisons for C++20
>
> Define std::identity, std::ranges::equal_to, std::ranges::not_equal_to,
> std::ranges::greater, std::ranges::less,
On Wed, Oct 16, 2019 at 09:42:16AM -0400, Michael Meissner wrote:
> 2019-10-15 Michael Meissner
>
> * config/rs6000/predicates.md (lwa_operand): If the bottom two
> bits of the offset for the memory address are non-zero, use PLWA
> if prefixed instructions are available.
Okay
Hi!
On Wed, Oct 16, 2019 at 09:38:54AM -0400, Michael Meissner wrote:
> This patch tweaks the code formatting that I noticed in making the previous
> patch for some of the 128-bit mode move instructions. Originally this was
> part
> of V5 patch #2, but it has been moved to a separate patch.
> @
Hi!
On Wed, Oct 16, 2019 at 09:35:33AM -0400, Michael Meissner wrote:
> This patch uses the target hook ADJUST_INSN_LENGTH to change the length of
> instructions that contain prefixed memory/add instructions.
That made this amazingly hard to review. But it might well be worth it,
thankfully :-)
On 22/10/19 22:40 +0100, Jonathan Wakely wrote:
C++20 removes a number of std::allocator members that have correct
defaults provided by std::allocator_traits, so aren't needed.
Several extensions including __gnu_cxx::hash_map and tr1 containers are
no longer usable with std::allocator in C++20 m
* include/bits/memoryfwd.h (uses_allocator): Do not declare for C++98.
* testsuite/17_intro/names.cc: Check uses_allocator in C++98.
Tested powerpc64le-linux, committed to trunk.
This should be backported too, as it should never have been declared
for C++98.
commit cdbab4a65ff6f
My recent change to this file broke running the testsuite with
-std=c++98 because std::unordered_map isn't available. This fixes it.
* testsuite/util/testsuite_abi.h: Restore use of tr1/unordered_map
when compiled as C++98.
Tested x86_64-linux, committed to trunk.
commit 8ffc60
C++20 removes a number of std::allocator members that have correct
defaults provided by std::allocator_traits, so aren't needed.
Several extensions including __gnu_cxx::hash_map and tr1 containers are
no longer usable with std::allocator in C++20 mode. They need to be
updated to use __gnu_cxx::__
Ping*2
Richard Sandiford writes:
> Ping
>
> To give a bit more rationale: some of the functions handled by
> https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01002.html operate
> on structs and enums. There are already langhooks for creating the
> necessary struct types, but there's no direct way o
Hi Michael,
> this was still collecting dust on my disk, so here it is. See the
> extensive comment in the patch for what happens, in short invariant IVs
> are affine but still have to be handled more conservative than other
> affine IVs in transformations that reorder instructions. Making ou
On Thu, Oct 17, 2019 at 6:22 PM Jakub Jelinek wrote:
>
> On Wed, Oct 16, 2019 at 04:36:07PM -0400, Jason Merrill wrote:
> > > As for CLEANUP_STMT, I've tried it (the second patch), but it didn't
> > > change
> > > anything, the diagnostics was still
> > > constexpr-dtor3.C:16:23: in ‘constexpr’
On 10/17/19 5:57 PM, Segher Boessenkool wrote:
> Hi Kelvin,
>
> On Wed, Oct 09, 2019 at 03:28:45PM -0500, Kelvin Nilsen wrote:
>> This new pass scans existing rtl expressions and replaces them with rtl
>> expressions that favor selection of the D-form instructions in contexts for
>> which the
On Tue, Oct 22, 2019 at 08:48:30PM +0200, Paolo Carlini wrote:
> Hi,
>
> at the moment I'm going through more typeck.c and typeck2.c functions: the
> below are some straightforward changes for build_x_unary_op (fwiw, the
> resulting locations are also consistent with clang)
>
> Tested x86_64-linu
Hi,
at the moment I'm going through more typeck.c and typeck2.c functions:
the below are some straightforward changes for build_x_unary_op (fwiw,
the resulting locations are also consistent with clang)
Tested x86_64-linux.
Thanks, Paolo.
/cp
2019-10-22 Paolo C
On Tue, Oct 22, 2019 at 11:08 AM Eduard-Mihai Burtescu wrote:
>
> @@ -160,27 +159,20 @@ cplus_demangle (const char *mangled, int options)
>if ((options & DMGL_STYLE_MASK) == 0)
> options |= (int) current_demangling_style & DMGL_STYLE_MASK;
>
> + /* The Rust demangling is implemented els
Committed as not so-obvious as I don't use UBSAN when fixing bugs.
The patch pushes the F2018:C822 check down a layer to prevent a segfault
when UBSAN is used.
2019-10-22 Steven G. Kargl
PR fortran/92174
* decl.c (attr_decl1): Move check for F2018:C822 from here ...
* array.c (gfc_set_array
This way, rust-demangle is closer to the official "rustc-demangle"
Rust demangler, which also doesn't require full C++ demangling for
the legacy format (implemented here), and only recognizes simple
"_ZN"..."E" paths with identifier components that the format uses.
The new code also has fewer depe
On Tue, Oct 22, 2019 at 10:53 PM kamlesh kumar wrote:
>
> diff --git a/gcc/cp/mangle.c b/gcc/cp/mangle.c
> index a9333b8..334610c 100644
> --- a/gcc/cp/mangle.c
> +++ b/gcc/cp/mangle.c
> @@ -3400,7 +3400,8 @@ write_template_arg_literal (const tree value)
>case INTEGER_CST:
> gcc_as
Thanks for doing this. Hope this message doesn't cover too much old
ground or duplicate too much...
"Andre Vieira (lists)" writes:
> @@ -2466,15 +2476,65 @@ vect_do_peeling (loop_vec_info loop_vinfo, tree
> niters, tree nitersm1,
>else
> niters_prolog = build_int_cst (type, 0);
>
> +
diff --git a/gcc/cp/mangle.c b/gcc/cp/mangle.c
index a9333b8..334610c 100644
--- a/gcc/cp/mangle.c
+++ b/gcc/cp/mangle.c
@@ -3400,7 +3400,8 @@ write_template_arg_literal (const tree value)
case INTEGER_CST:
gcc_assert (!same_type_p (TREE_TYPE (value), boolean_type_node)
On Tue, Oct 22, 2019 at 10:00:19PM +0530, kamlesh kumar wrote:
> diff --git a/gcc/cp/mangle.c b/gcc/cp/mangle.c
> index a9333b8..780da9f 100644
> --- a/gcc/cp/mangle.c
> +++ b/gcc/cp/mangle.c
> @@ -3400,7 +3400,8 @@ write_template_arg_literal (const tree value)
>case INTEGER_CST:
>
attached patch file.
On Tue, Oct 22, 2019 at 10:00 PM kamlesh kumar wrote:
>
> bootstrap and regtested on x86_64.
>
> Changelog:
> gcc
> --
> 2019-10-22 Kamlesh Kumar
>
> PR c++/91979 - mangling nullptr expression
> * mangle.c (write_template_arg_literal): Handle nullptr
>
bootstrap and regtested on x86_64.
Changelog:
gcc
--
2019-10-22 Kamlesh Kumar
PR c++/91979 - mangling nullptr expression
* mangle.c (write_template_arg_literal): Handle nullptr
mangling.
* testsuite/g++.dg/cpp0x/nullptr27.C: Modify Test.
* testsuite/
Hi,
I previously did not properly attach the diff.
Regards,
Mihail
On 10/22/2019 05:06 PM, Mihail Ionescu wrote:
Hi,
This is a backport from trunk for GCC9.
SVN revision: r277156.
Built and tested on arm-none-eabi (comparted
-march=armv7e-m+fp/-mfloat-abi=hard
to -march=armv7-r+fp.sp/-mf
Hi,
This is a backport from trunk for GCC9.
SVN revision: r277156.
Built and tested on arm-none-eabi (comparted
-march=armv7e-m+fp/-mfloat-abi=hard
to -march=armv7-r+fp.sp/-mfloat-abi=hard).
gcc/ChangeLog:
2019-10-21 Mihail Ionescu
Backport from mainline
2019-10-18 And
On Tue, Oct 22, 2019 at 11:20 AM Jakub Jelinek wrote:
>
> On Tue, Oct 22, 2019 at 10:57:42AM -0400, Jason Merrill wrote:
> > > So, do you prefer to do it the other way during build_cxx_call?
> >
> > It seems more straightforward.
>
> Ok.
>
> > > The issues that need to be resolved are the default
On Tue, Oct 22, 2019 at 10:57:42AM -0400, Jason Merrill wrote:
> > So, do you prefer to do it the other way during build_cxx_call?
>
> It seems more straightforward.
Ok.
> > The issues that need to be resolved are the default arguments,
> > which from my understanding are not full expressions an
Hi!
The following patch is just a partial fix for a regression introduced
in the PR90947 changes, the testcase is fixed for just C++17/20.
type_initializer_zero_p has been added to the generic code, supposedly
because similar initializer_zerop is in generic code too, but that
means it has a hand-w
On Tue, Oct 22, 2019 at 10:41 AM Jakub Jelinek wrote:
>
> On Tue, Oct 22, 2019 at 09:55:06AM -0400, Jason Merrill wrote:
> > On Mon, Oct 21, 2019 at 1:59 PM Jason Merrill wrote:
> > > On 10/15/19 1:04 PM, Jakub Jelinek wrote:
> >
> > > > Unlike the previous implementation, this doesn't invoke con
This patch implements C++20 P0960R3: Parenthesized initialization of aggregates
(; see R0 for more background info). Essentially, if you have
an aggregate, you can now initialize it by (x, y), similarly to {x, y}. E.g.
struct A {
int x, y;
// no A(int, int) ctor (see paren-init14.C for
On Tue, Oct 22, 2019 at 09:55:06AM -0400, Jason Merrill wrote:
> On Mon, Oct 21, 2019 at 1:59 PM Jason Merrill wrote:
> > On 10/15/19 1:04 PM, Jakub Jelinek wrote:
>
> > > Unlike the previous implementation, this doesn't invoke consteval function
> > > already during parsing, but later on, so the
On Tue, Oct 22, 2019 at 09:52:44AM -0400, Jason Merrill wrote:
> Sounds good.
>
> > (the latter perhaps just if !processing_template_decl)?
>
> I'd think we would want to be consistent with other immediate
> invocations in template context.
The other ones just call it regardless of processing_te
On 9/27/19 9:13 AM, luoxhu wrote:
> Thanks for your time of so many round of reviews.
You're welcome. One last request would be please to make
gimple_ic_transform a void function. See attached patch.
I'll remind the patch today to Honza.
Thanks,
Martin
diff --git a/gcc/value-prof.c b/gcc/value-p
OK.
On Tue, Oct 22, 2019 at 9:04 AM Jakub Jelinek wrote:
>
> Hi!
>
> As noticed by Richi,
> FAIL: g++.dg/guality/pr55665.C -O2 line 23 p == 40
> FAIL: g++.dg/guality/pr55665.C -O2 line 23 p == 40
> FAIL: g++.dg/guality/pr55665.C -O3 -g line 23 p == 40
> FAIL: g++.dg/guality/pr55665.C -
On Tue, 22 Oct 2019, Andre Vieira (lists) wrote:
> Hi Richi,
>
> See inline responses to your comments.
>
> On 11/10/2019 13:57, Richard Biener wrote:
> > On Thu, 10 Oct 2019, Andre Vieira (lists) wrote:
> >
> >> Hi,
> >>
>
> >
> > +
> > + /* Keep track of vector sizes we know we can vectori
On Mon, Oct 21, 2019 at 1:59 PM Jason Merrill wrote:
> On 10/15/19 1:04 PM, Jakub Jelinek wrote:
> > Unlike the previous implementation, this doesn't invoke consteval function
> > already during parsing, but later on, so there aren't issues with say
> > consteval constructors or consteval in defa
On Tue, Oct 22, 2019 at 3:15 AM Jakub Jelinek wrote:
>
> On Mon, Oct 21, 2019 at 04:44:22PM -0400, Jason Merrill wrote:
> > Perhaps we should bypass the existing virtual function call mechanism for
> > consteval, and instead find the complete object directly and call
> > non-virtually.
>
> Maybe,
On 21/10/2019 16:46, Richard Earnshaw (lists) wrote:
On 19/10/2019 17:17, Segher Boessenkool wrote:
Yes, but combine should have removed the move in a 2->1 combination
already, if it is beneficial: both 18->7 and 7->22 should have combined
just fine. This also points to a potential target pro
On Arm we have both carry and borrow operations, but borrow is
essentially '~carry'. Of course, with boolean logic ~carry is also
1-carry.
GCC transforms
(1 - X - LTU (cc, 0))
into
(GEU (cc, 0) - X)
Now the former matches a real insn in Arm state, using the RSC
instruction
Arm_carry_operation and arm_borrow_operation are duals: given that we
have a comparison that returns a result that relies solely in the carry
flag one is the inverse of the other. So there's no reason for
one to have a CC mode that the other does not have. This patch restores
that equivalence.
The following patch fixes an ICE when vectorizing shifts with the
simplified SLP operand code by adjusting the type of the shift
argument in vectorizable_shift. I took the liberty to enable
more SLP shift vectorization for originally not "scalar" (same)
but constant shift amounts as we do as fa
Hi!
As noticed by Richi,
FAIL: g++.dg/guality/pr55665.C -O2 line 23 p == 40
FAIL: g++.dg/guality/pr55665.C -O2 line 23 p == 40
FAIL: g++.dg/guality/pr55665.C -O3 -g line 23 p == 40
FAIL: g++.dg/guality/pr55665.C -O3 -g line 23 p == 40
aren't a mere wrong-debug, but actually wrong-code
Status
==
GCC trunk is open for general development, stage 1. Stage 1
tentatively ends at the end of Saturday, Nov. 16th, after which
we enter general bugfixing, Stage 3 which is expected to last
two months, closing with finalizing the transition to git.
Please make sure to get features in
Hi.
We should not call to_gcov_type on a count that is uninitialized.
That's the case for a THUNK cgraph_node that we inline.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2019-10-22 Martin Liska
PR ipa/9
Hi Richi,
See inline responses to your comments.
On 11/10/2019 13:57, Richard Biener wrote:
On Thu, 10 Oct 2019, Andre Vieira (lists) wrote:
Hi,
+
+ /* Keep track of vector sizes we know we can vectorize the epilogue
with. */
+ vector_sizes epilogue_vsizes;
};
please don't enlarge
On Tue, Oct 22, 2019 at 11:36 AM Michael Matz wrote:
>
> Hi,
>
> this was still collecting dust on my disk, so here it is. See the
> extensive comment in the patch for what happens, in short invariant IVs
> are affine but still have to be handled more conservative than other
> affine IVs in trans
The following fixes an ICE when vectorizable_reduction asks for
the optab for a shift but passes optab_default. Simply pass
optab_vector since that's what it code-generates later. As
optimization if its own code-generator fails try the regular
one.
Bootstrapped and tested on x86_64-unknown-lin
Hello,
I've only noticed a couple typos, and one minor remark. From my
perspective it's okay, but you still need the okay of a proper reviewer,
for which you might want to state the testing/regression state of this
patch relative to trunk. The remarks follow:
On Tue, 22 Oct 2019, Feng Xue OS
@Honza: PING^1
On 9/18/19 12:14 PM, Martin Liška wrote:
> On 9/11/19 1:38 PM, Martin Liška wrote:
>> The inline_clone manipulation happens in cgraph_node::find_replacement where
>> we manipulate the clone_of.
>
> I fixed that but there's a similar situation which goes other way around:
>
> cgrap
Installed as obvious.
* config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Update.
diff --git
a/libstdc++-v3/config/abi/post/aarch64-linux-gnu/baseline_symbols.txt
b/libstdc++-v3/config/abi/post/aarch64-linux-gnu/baseline_symbols.txt
index 53c87f115e0..99fd027827c 100644
--- a/libs
On Tue, Oct 22, 2019 at 10:00:39AM +, Tamar Christina wrote:
> Glibc has recently introduced changed to the mode field in ipc_perm
> in commit 2f959dfe849e0646e27403f2e4091536496ac0f0. For Arm this
> means that the mode field no longer has the same size.
>
> This causes an assert failure again
Hi, Michael,
Since gcc 10 release is coming, that will be good if we can add this patch
before that. Thanks
Feng.
From: Michael Matz
Sent: Wednesday, October 16, 2019 12:01 AM
To: Philipp Tomsich
Cc: Feng Xue OS; Richard Biener; gcc-patches@gcc.gnu.or
Hi All,
Glibc has recently introduced changed to the mode field in ipc_perm
in commit 2f959dfe849e0646e27403f2e4091536496ac0f0. For Arm this
means that the mode field no longer has the same size.
This causes an assert failure against libsanitizer's internal copy
of ipc_perm. Since this change ca
Hi,
this was still collecting dust on my disk, so here it is. See the
extensive comment in the patch for what happens, in short invariant IVs
are affine but still have to be handled more conservative than other
affine IVs in transformations that reorder instructions. Making our
dependence an
Update -mea option documentation.
gcc/
-xx-xx Claudiu Zissulescu
* config/arc/arc.opt (mea): Update help string.
* doc/invoke.texi(ARC): Update mea option info.
---
gcc/config/arc/arc.opt | 2 +-
gcc/doc/invoke.texi| 2 +-
2 files changed, 2 insertions(+), 2 deletions(
Do not split immediate constants for predicated instructions.
gcc/
-xx-xx Claudiu Zissulescu
* config/arc/arc.c (arc_split_ior): Add asserts.
(arc_split_mov_const): Likewise.
(arc_check_ior_const): Do not match known short immediate values.
* config/arc/arc.
Hi Andrew,
Please find a set of three patches for trunk as fallows:
[ARC] Cleanup sign/zero extend patterns
This is just insn patterns cleanup.
[ARC] Update mea option documentation
Update -mea option documentation.
[ARC] Don't split ior/mov predicated insns.
Found a
Cleanup sign/zero extend patterns (corrects the asm output string and
constraint letters).
gcc/
-xx-xx Claudiu Zissulescu
* config/arc/arc.md (zero_extendqihi2_i): Cleanup pattern.
(zero_extendqisi2_ac): Likewise.
(zero_extendhisi2_i): Likewise.
(extendqihi
From: Shahab Vahedi
Hi Andrew,
The movsi_ne variants are in a wrong order, leading to wrong
computation of the internal attribute "cond". Hence, to errors when
outputting annul-true or annul-false instructions. Testcase added.
The patch needs to go for trunk and gcc9 branch.
OK to apply?
Claud
Hi Andrew,
There are cases when an pic address gets complicated, and it needs to
be resolved via force_reg function found in
prepare_move_operands. When this happens, we need to disambiguate the
pic address and re-legitimize it. Testcase added as well.
The patch needs to be applied to trunk and g
On Tue, Oct 22, 2019 at 9:25 AM Richard Sandiford
wrote:
>
> I noticed yesterday that r277235 was a bit too mechanical and ended up
> introducing use after free bugs in both loop and SLP vectorisation.
> Sorry for the stupid mistake. :-(
>
> Moving "next_size += 1" down isn't part of the fix, but
On Tue, Oct 22, 2019 at 1:00 AM Giuliano Belinassi
wrote:
>
> Hi,
>
> When using lto-dump -callgraph with two or more .o files containing distinct
> functions with the same name, dump_graphviz incorrectly merged those functions
> into a single node. This patch fixes this issue by calling `dump_nam
On Okt 21 2019, Joseph Myers wrote:
> I've seen some versions of plain "git push" in the past warn about changed
> defaults for what it pushes, so being explicit avoids confusing people
> with that warning. Though it seems that warning was removed from git in
> 2016, so maybe avoiding it is no
Prathamesh Kulkarni writes:
> diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
> index acdd90784dc..dfd33b142ed 100644
> --- a/gcc/tree-vect-stmts.c
> +++ b/gcc/tree-vect-stmts.c
> @@ -10016,25 +10016,26 @@ vectorizable_condition (stmt_vec_info stmt_info,
> gimple_stmt_iterator *gsi,
>
On Mon, Oct 21, 2019 at 01:24:30PM +0200, Jakub Jelinek wrote:
> So I wonder if for correctness I don't need to add:
>
> if (!use->iv->no_overflow
> && !cand->iv->no_overflow
> && !integer_pow2p (cstep))
> return NULL_TREE;
>
> with some of the above as comment explaining why.
>
I noticed yesterday that r277235 was a bit too mechanical and ended up
introducing use after free bugs in both loop and SLP vectorisation.
Sorry for the stupid mistake. :-(
Moving "next_size += 1" down isn't part of the fix, but it seemed odd
to keep it where it was after moving the "next_size ==
On Mon, Oct 21, 2019 at 04:44:22PM -0400, Jason Merrill wrote:
> Perhaps we should bypass the existing virtual function call mechanism for
> consteval, and instead find the complete object directly and call
> non-virtually.
Maybe, but can that be done incrementally?
> > The finish_function was ju
75 matches
Mail list logo
