Here is the updated patch.
* include/bits/stl_algobase.h (__niter_wrap): New.
(__copy_move_a2(_II, _II, _OI)): Use latter.
(__copy_move_backward_a2(_BI1, _BI1, _BI2)): Likewise.
(fill_n(_OI, _Size, const _Tp&)): Likewise.
(equal(_II1, _II1, _II2)): Use
The h8 port has 3 movqi and movhi patterns. One for the H8, another for
the H8/H and H8/S and another for the H8/SX. The basic H8 pattern can
be trivially merged with the H8/H and H8/S patterns. In addition to
just simplifing the port, the movqi H8/H and H8/S pattern is better WRT
condition
So the H8 port is the next planned conversion away from cc0. Given that
nearly every insn (including simple register moves) hits cc0,
essentially every pattern is going to need twiddling. Sigh.
This seems like a good time to fix some nits since the whole file is
about to change anyway.
This
Hi Jim:
It's no problem with current approach, I just think it can simplify
the .md file.
Thanks :)
On Tue, Jul 3, 2018 at 11:22 AM Jim Wilson wrote:
>
> On Mon, Jul 2, 2018 at 8:04 PM, Kito Cheng wrote:
> > Does it possible just combine those pattern into simple_return
> > pattern, and then
On Mon, Jul 2, 2018 at 8:04 PM, Kito Cheng wrote:
> Does it possible just combine those pattern into simple_return
> pattern, and then check the function type and output correct return
> instruction in riscv_output_return?
There might be problems with optimizations thinking this is a regular
Hi Jim:
Does it possible just combine those pattern into simple_return
pattern, and then check the function type and output correct return
instruction in riscv_output_return?
On Tue, Jul 3, 2018 at 8:22 AM Jim Wilson wrote:
>
> This fixes a problem found by someone trying to use the new RISC-V
This fixes a problem found by someone trying to use the new RISC-V interrupt
attribute support. With a slightly non-trivial example, and the -g option, we
get an abort in dwarf2cfi for an inconsistent CFI state. This is my fault
for not making the new interrupt return patterns look enough like
Hello world,
the attached patch is the third take on Nicolas' and my patch
for implementing asynchronous I/O. Some parts have been reworked, and
several bugs which caused either incorrect I/O or hangs have been
fixed in the process.
I have to say that getting out these bugs has been much
Extend __is_convertible_helper to also detect whether the conversion is
non-throwing, for std::is_nothrow_convertible in C++2a,
* include/std/type_traits [__cplusplus > 201703]
(__is_convertible_helper::__is_nothrow_type): Define new member.
I'd like to PING:
https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01713.html
I've included the entire patch below, since I missed the test cases in
the original submission and Segher asked for some updated text for the
hook documentation which I've included below.
Peter
gcc/
PR
[ I wonder if I ever sent this patch to the list. I now backported it
to 8 branch as well. Apologies. ]
We shouldn't init __ieee128 to be the same as long double if the
latter is not even a 128-bit type.
This also reorders the nearby __ibm128 code so both types use similar
logic.
Committing
Hi, Jeff,
thanks a lot for your review and comments.
I have addressed your comments,updated the patch, retested on both
aarch64 and x86.
The major changes in this version compared to the previous version are:
1. in routine expand_builtin_memcmp:
* move the inlining transformation AFTER
A recently-approved C++2a feature, trivial to implement.
* include/std/type_traits (type_identity, type_identity_t): Define
for C++2a.
* testsuite/20_util/type_identity/requirements/alias_decl.cc: New.
* testsuite/20_util/type_identity/requirements/
This patch adds the first destination for optinfo instances to be
emitted to: as "remarks" through the diagnostics subsystem.
Examples can be seen at
https://dmalcolm.fedorapeople.org/gcc/2018-06-18/test.cc.remarks.html
Remarks look a lot like the output of -fopt-info, with the following
This patch implements a way to consolidate dump_* calls into
optinfo objects, as enabling work towards being able to write out
optimization records to a file, or emit them as diagnostic "remarks".
The patch adds the support for building optinfo instances from dump_*
calls, but leaves implementing
On Fri, 2018-06-29 at 09:09 +0200, Richard Biener wrote:
> On Thu, Jun 28, 2018 at 4:29 PM David Malcolm
> wrote:
> >
> > On Thu, 2018-06-28 at 13:29 +0200, Richard Biener wrote:
> > > On Tue, Jun 26, 2018 at 3:54 PM David Malcolm > > m>
> > > wrote:
> > > >
> > > > On Mon, 2018-06-25 at 15:34
Hi, Jeff,
thanks a lot for your review and comments.
I have addressed your comments,updated the patch, retested on both
aarch64 and x86.
The major changes in this version compared to the previous version are:
1. in routine “expand_builtin_memcmp”:
* move the inlining transformation
Avoid creation of unnecessary basic_string objects by using a simplified
string_view type and performing comparisons on that type instead. A
temporary basic_string object is still used when the sub_match's
iterators are not contiguous, in order to get an object that the
__string_view can
This patch moves a workaround for locale differences from a
selftest in pretty-print.c to selftest.h/c to make it reusable; I need
this for a selftest in a followup patch.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Committed to trunk as r262317 (with my "diagnostic messages"
On Mon, 2018-07-02 at 12:58 +0200, Paolo Carlini wrote:
> Hi,
>
> I was double checking my pending patch and going through the errors
> we
> emit in decl.c and elsewhere about thread_local and __thread and
> noticed
> another place, in parser.c, where using rich_location::add_range
> seems
>
OK.
On Mon, Jul 2, 2018 at 6:58 AM, Paolo Carlini wrote:
> Hi,
>
> I was double checking my pending patch and going through the errors we emit
> in decl.c and elsewhere about thread_local and __thread and noticed another
> place, in parser.c, where using rich_location::add_range seems natural.
>
On Mon, 2 Jul 2018 at 19:00, David Malcolm wrote:
>
> On Mon, 2018-07-02 at 14:23 +0200, Christophe Lyon wrote:
> > On Fri, 29 Jun 2018 at 10:09, Richard Biener > com> wrote:
> > >
> > > On Tue, Jun 26, 2018 at 5:43 PM David Malcolm
> > > wrote:
> > > >
> > > > This patch adds a concept of
On 30/06/18 20:48 +, Bernd Edlinger wrote:
Hi,
the -Wabi option prints a warning as follows:
cc1plus: warning: -Wabi won't warn about anything [-Wabi]
cc1plus: note: -Wabi warns about differences from the most up-to-date
ABI, which is also used by default
cc1plus: note: use e.g. -Wabi=11
On Mon, 2018-07-02 at 14:23 +0200, Christophe Lyon wrote:
> On Fri, 29 Jun 2018 at 10:09, Richard Biener com> wrote:
> >
> > On Tue, Jun 26, 2018 at 5:43 PM David Malcolm
> > wrote:
> > >
> > > This patch adds a concept of nested "scopes" to dumpfile.c's
> > > dump_*_loc
> > > calls, and wires
Hi!
On Fri, Jun 29, 2018 at 07:38:39AM -0700, Carl Love wrote:
> +;; Unpack high elements of float vector to vector of doubles
> +(define_expand "altivec_unpackh_v4sf"
> + [(set (match_operand:V2DF 0 "register_operand" "=v")
> +(match_operand:V4SF 1 "register_operand" "v"))]
> +
Richard Biener writes:
> On Fri, 22 Jun 2018, David Malcolm wrote:
>
>> NightStrike and I were chatting on IRC last week about
>> issues with trying to vectorize the following code:
>>
>> #include
>> std::size_t f(std::vector> const & v) {
>> std::size_t ret = 0;
>> for (auto const &
This libgo patch checks the return value as well as the error from
waitid. https://gcc.gnu.org/PR86331 indicates that if a signal
handler runs it is possible for syscall.Syscall6 to return a non-zero
errno value even if no error occurs. That is a problem in general, but
this fix will let us work
Hi Jakub,
On Fri, Jun 29, 2018 at 12:52:59AM +0200, Jakub Jelinek wrote:
> The newly added rs6000-modes.h is now included from rs6000.h, so it is
> needed when building plugins that include tm.h, but it wasn't listed in the
> Makefile fragments and therefore included among PLUGIN_HEADERS.
>
>
On 07/02/2018 04:55 AM, Richard Sandiford wrote:
>> +;; Predicated floating-point operations with select matching output.
>> +(define_insn "*cond__0"
>> + [(set (match_operand:SVE_F 0 "register_operand" "+w, w, ?")
>> (unspec:SVE_F
>> - [(match_operand: 1 "register_operand" "Upl")
>> +
On Jun 28, 2018, at 12:39 PM, Tom de Vries wrote:
> This patch adds a dg-final override that passes it's first argument to the
> gdb-test action. This allows us to use relative line numbers in gdb-test.
>
> Tested pr45882.c.
>
> Any comments?
> 2018-06-28 Tom de Vries
>
> *
Hi.
This fixes broken tests gcc.dg/profile-dir*. I'm going to install the patch.
Martin
gcc/testsuite/ChangeLog:
2018-07-02 Martin Liska
PR testsuite/86366
* gcc.dg/profile-dir-1.c: Fix scanned pattern.
* gcc.dg/profile-dir-2.c: Likewise.
*
On 07/02/2018 07:14 AM, Tom de Vries wrote:
> On 06/21/2018 03:58 PM, Cesar Philippidis wrote:
>> On 06/20/2018 03:15 PM, Tom de Vries wrote:
>>> On 06/20/2018 11:59 PM, Cesar Philippidis wrote:
Now it follows the formula contained in
the "CUDA Occupancy Calculator" spreadsheet that's
Hi,
Hope you having a great day!
I just wanted to be aware if you looking to acquire database for your marketing
efforts? We provide database for all industry and technology.
Kindly review and let me be aware of your interest so that I can get back to
you with the exact counts, sample
On 06/21/2018 03:58 PM, Cesar Philippidis wrote:
> On 06/20/2018 03:15 PM, Tom de Vries wrote:
>> On 06/20/2018 11:59 PM, Cesar Philippidis wrote:
>>> Now it follows the formula contained in
>>> the "CUDA Occupancy Calculator" spreadsheet that's distributed with CUDA.
>>
>> Any reason we're not
Hi Christophe,
On 02/07/18 13:17, Christophe Lyon wrote:
On Fri, 29 Jun 2018 at 15:32, Kyrill Tkachov
wrote:
Hi all,
In this testcase the user forces an odd register as the starting reg for a
DFmode value.
The output_move_double function tries to store that using an STRD instruction.
But
On Fri, Jun 29, 2018 at 4:38 AM Kugan Vivekanandarajah
wrote:
>
> Hi Marc,
>
> Thanks for the review.
>
> On 28 June 2018 at 14:11, Marc Glisse wrote:
> > (why is there no mention of ABSU_EXPR in doc/* ?)
>
> I will fix this in a separate patch.
> >
> > --- a/gcc/match.pd
> > +++ b/gcc/match.pd
On Mon, 2 Jul 2018 at 15:37, Richard Sandiford
wrote:
>
> Christophe Lyon writes:
> > On Fri, 29 Jun 2018 at 13:36, Richard Sandiford
> > wrote:
> >>
> >> Richard Sandiford writes:
> >> > This patch is the main part of PR85694. The aim is to recognise at
> >> > least:
> >> >
> >> > signed
Christophe Lyon writes:
> On Fri, 29 Jun 2018 at 13:36, Richard Sandiford
> wrote:
>>
>> Richard Sandiford writes:
>> > This patch is the main part of PR85694. The aim is to recognise at least:
>> >
>> > signed char *a, *b, *c;
>> > ...
>> > for (int i = 0; i < 2048; i++)
>> > c[i] =
The following fixes an oversight in a previous patch to enhance VN
of memset calls.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
>From b35c162ee7126057134d3b478e80160880402f1a Mon Sep 17 00:00:00 2001
From: Richard Guenther
Date: Mon, 2 Jul 2018 13:11:39 +0200
On Fri, Jun 29, 2018 at 11:21 AM Richard Sandiford
wrote:
>
> This patch adds detection of average instructions:
>
>a = (((wide) b + (wide) c) >> 1);
>--> a = (wide) .AVG_FLOOR (b, c);
>
>a = (((wide) b + (wide) c + 1) >> 1);
>--> a = (wide) .AVG_CEIL (b, c);
>
> in cases
On Wed, Jun 20, 2018 at 12:39 PM Richard Sandiford
wrote:
>
> The main over-widening patch can introduce quite a few extra casts,
> and in many cases those casts simply "tap into" an intermediate
> point in an existing extension. E.g. if we have:
>
> unsigned char a;
> int ax = (int) a;
On Fri, Jun 29, 2018 at 1:36 PM Richard Sandiford
wrote:
>
> Richard Sandiford writes:
> > This patch is the main part of PR85694. The aim is to recognise at least:
> >
> > signed char *a, *b, *c;
> > ...
> > for (int i = 0; i < 2048; i++)
> > c[i] = (a[i] + b[i]) >> 1;
> >
> > as an
On Fri, 29 Jun 2018 at 10:09, Richard Biener wrote:
>
> On Tue, Jun 26, 2018 at 5:43 PM David Malcolm wrote:
> >
> > This patch adds a concept of nested "scopes" to dumpfile.c's dump_*_loc
> > calls, and wires it up to the DUMP_VECT_SCOPE macro in tree-vectorizer.h,
> > so that the nested
On Fri, 29 Jun 2018 at 15:32, Kyrill Tkachov
wrote:
>
> Hi all,
>
> In this testcase the user forces an odd register as the starting reg for a
> DFmode value.
> The output_move_double function tries to store that using an STRD instruction.
> But for TARGET_ARM the starting register of an STRD
On 01/07/18 21:20 +0200, François Dumont wrote:
Here is a new proposal between yours and mine.
It is still adding a function to wrap what __niter_base unwrap, I
called it __nwrap_iter for this reason. But it takes advantage of
Since "niter" refers to __normal_iterator I think a name
Richard Henderson writes:
> * config/aarch64/aarch64-protos.h, config/aarch64/aarch64.c
> (aarch64_sve_prepare_conditional_op): Remove.
> * config/aarch64/aarch64-sve.md (cond_):
> Allow aarch64_simd_reg_or_zero as select operand; remove
> the
Richard Henderson writes:
> The predicate is present within the containing UNSPEC_SEL;
> there is no need to duplicate it.
>
> * config/aarch64/aarch64-sve.md (cond_):
> Remove match_dup 1 from the inner unspec.
> (*cond_): Likewise.
OK, thanks.
Richard
> ---
>
Richard Henderson writes:
> * config/aarch64/aarch64.md (movprfx): New attr.
> (length): Default movprfx to 8.
> * config/aarch64/aarch64-sve.md (*mul3): Add movprfx alt.
> (*madd, *msub (*mul3_highpart): Likewise.
> (*3): Likewise.
> (*v3): Likewise.
>
Richard Henderson writes:
> @@ -2687,34 +2738,60 @@
>aarch64_sve_prepare_conditional_op (operands, 5, );
> })
>
> -;; Predicated floating-point operations.
> -(define_insn "*cond_"
> - [(set (match_operand:SVE_F 0 "register_operand" "=w")
> +;; Predicated floating-point operations with
On 07/02/2018 03:29 PM, Kyrill Tkachov wrote:
Nice! What were the regressions though? Would be nice to adjust the tests
to make them more robust so that we have as clean a testsuite as possible.
Sure, they're gcc.dg/guality/pr36728-2.c and gcc.target/aarch64/extend.c.
The addressing mode
On Sun, 1 Jul 2018 at 12:56, Aldy Hernandez wrote:
>
>
>
> On 06/29/2018 02:50 PM, Jeff Law wrote:
> > [ Returning to another old patch... ]
> >
> > On 11/07/2017 10:33 AM, Aldy Hernandez wrote:
> >> [One more time, but without rejected HTML mail, because apparently this
> >> is my first post to
On Fri, 29 Jun 2018 at 13:36, Richard Sandiford
wrote:
>
> Richard Sandiford writes:
> > This patch is the main part of PR85694. The aim is to recognise at least:
> >
> > signed char *a, *b, *c;
> > ...
> > for (int i = 0; i < 2048; i++)
> > c[i] = (a[i] + b[i]) >> 1;
> >
> > as an
Hi,
I was double checking my pending patch and going through the errors we
emit in decl.c and elsewhere about thread_local and __thread and noticed
another place, in parser.c, where using rich_location::add_range seems
natural. Note, we could in principle swap location and
On 29/06/18 14:29, Kyrill Tkachov wrote:
> Hi all,
>
> This patch adds support for the Arm Cortex-A76 processor in changes.html
> for GCC 9.
> It enables the AArch64 section of the page and adds the news blob there.
> It also adds an entry to the already-existing arm entry.
>
> Ok to commit to
On Mon, Jul 2, 2018 at 3:15 AM Kugan Vivekanandarajah
wrote:
>
> Hi Richard,
>
> On 29 June 2018 at 18:45, Richard Biener wrote:
> > On Wed, Jun 27, 2018 at 7:09 AM Kugan Vivekanandarajah
> > wrote:
> >>
> >> Hi Richard,
> >>
> >> Thanks for the review,
> >>
> >> On 25 June 2018 at 20:20,
> LGTM, but please note that the patch was already approved by Jeff on
> 22th of June [1].
Sorry, I missed that... Thanks for pointing it out.
--
Eric Botcazou
Hi Siddhesh,
On 02/07/18 10:15, Siddhesh Poyarekar wrote:
Hi,
This is a rewrite of the tag collision avoidance patch that Kugan had
written as a machine reorg pass back in February[1].
The falkor hardware prefetching system uses a combination of the
source, destination and offset to decide
Hi,
This is a rewrite of the tag collision avoidance patch that Kugan had
written as a machine reorg pass back in February[1].
The falkor hardware prefetching system uses a combination of the
source, destination and offset to decide which prefetcher unit to
train with the load. This is great
Hi Martin,
> On 06/22/2018 10:35 PM, Jeff Law wrote:
>> On 05/16/2018 05:53 AM, Martin Liška wrote:
>>> On 12/21/2017 10:13 AM, Martin Liška wrote:
On 12/20/2017 06:45 PM, Jakub Jelinek wrote:
> Another thing is that the "/" in there is wrong, so
> const char dir_separator_str[] =
On Mon, Jul 2, 2018 at 10:14 AM, Eric Botcazou wrote:
> Ping for https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01228.html
>
> Thanks in advance.
LGTM, but please note that the patch was already approved by Jeff on
22th of June [1].
[1] https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01466.html
On Mon, Jul 02, 2018 at 09:44:04AM +0200, Richard Biener wrote:
> Given the array has size i + 1 it's upper bound should be 'i' and 'i'
> should be available via DW_OP_[GNU_]entry_value.
>
> I see it is
>
> <175> DW_AT_upper_bound : 10 byte block: 75 1 8 20 24 8 20 26 31
> 1c
Ping for https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01228.html
Thanks in advance.
--
Eric Botcazou
On Sun, Jul 1, 2018 at 9:25 PM Tom de Vries wrote:
>
> On 07/01/2018 09:11 PM, Jakub Jelinek wrote:
> > On Sun, Jul 01, 2018 at 06:19:20PM +0200, Tom de Vries wrote:
> >> So, the local vla a is optimized away.
> >>
> >> This patch adds VOLATILE to 'a', which prevents it from being optimized
> >>
On Sun, Jul 1, 2018 at 10:05 AM Aldy Hernandez wrote:
>
> Boy those extract_range_from_*_expr functions are huge.
>
> OK to move the ABS_EXPR code into its own function?
OK.
Richard.
> Tested on x86-64 Linux.
>
> Aldy
On Fri, Jun 29, 2018 at 7:55 PM Aldy Hernandez wrote:
>
> Howdy!
>
> Attached are some cleanups to the VRP code dealing with PLUS/MINUS_EXPR
> on ranges. This will make it easier to share code with any other range
> implementation in the future, but is completely independent from any
> other
66 matches
Mail list logo
