On 10/06/20 15:32 -0400, Patrick Palka via Libstdc++ wrote:
ranges::copy and a number of other ranges algorithms have unwrapping
optimizations for iterators of type __normal_iterator, move_iterator and
reverse_iterator. But in the checks that guard these optimizations we
currently only test that
On Wed, Jun 10, 2020 at 1:08 AM Kito Cheng wrote:
> * config/riscv/riscv-protos.h (riscv_output_gpr_save): Remove.
> * config/riscv/riscv-sr.c (riscv_sr_match_prologue): Update
> value.
> * config/riscv/riscv.c (riscv_output_gpr_save): Remove.
> * config/ris
On Wed, Jun 10, 2020 at 1:08 AM Kito Cheng wrote:
> * config/riscv/riscv.c (gpr_save_reg_order): New.
> (riscv_expand_prologue): Use riscv_gen_gpr_save_insn to gen gpr_save.
> (riscv_gen_gpr_save_insn): New.
> ...
Looks good to me. Though these two new functions should ha
Since r10-7096 convert_like, when called in a template, creates an
IMPLICIT_CONV_EXPR when we're converting to/from array type.
In this test, we have e[f], and we're converting f (of type class A) to
int, so convert_like in build_new_op_1 created the IMPLICIT_CONV_EXPR
that got into cp_build_array
Another indication that perhaps this warning is emitted too early. We
crash because same_type_p gets a null type: we have an enumerator
without a fixed underlying type and finish_enum_value_list hasn't yet
run. So check if the type is null before calling same_type_p.
(This is a regression and th
On Wed, 10 Jun 2020, Jonathan Wakely wrote:
> On 10/06/20 15:32 -0400, Patrick Palka via Libstdc++ wrote:
> > ranges::copy and a number of other ranges algorithms have unwrapping
> > optimizations for iterators of type __normal_iterator, move_iterator and
> > reverse_iterator. But in the checks t
A follow up note relating to use of fused multiply add in complex divide:
While reviewing bugs relating to complex divide in libgcc, I
rediscovered bug 59714 - complex division is surprising on targets
with FMA.
The specific concern was when you divide (1.0 + 3.0i) by itself and
fused multiply a
On Jun 9, 2020, Thomas Schwinge wrote:
> Are you able to easily create/suggest patches for these? (You're
> probably not set up for offloading compilation...)
I can try, but I can certainly use help, if not in coding, at least with
testing.
> Can you suggest
> how/where to adjust: producer-si
On Mon, 2019-07-22 at 12:39 -0400, Arvind Sankar wrote:
> The gcc configure script does not use the config/picflag.m4 macro to
> customize PICFLAG according to the host when using --enable-host-shared.
>
> Fix configure.ac to do so.
>
> Tested bootstrap on x86_64-linux-gnu.
>
> 2019-07-22 Arvin
Joseph,
Thank you again for your prompt and insightful response.
It's now clear that I was engaged in wishful thinking that I only needed
to handle double precision in my proposed change. I understand now that
the text above the routine:
- - - - -
#if defined(L_divhc3) || defined(L_divsc3) || def
On Wed, 10 Jun 2020, Patrick McGehearty wrote:
> #ifdef L_divhc3
> #define RBIG (correct value for half precision)
> #define RMIN (correct value for half precision)
> #define RMIN2 ... (correct value for half precision)
> #define RMINSCAL ... (correct value for half precision)
> #endif
> #ifdef
On Wed, Jun 10, 2020 at 04:27:27PM -0600, Jeff Law wrote:
> On Mon, 2019-07-22 at 12:39 -0400, Arvind Sankar wrote:
> > The gcc configure script does not use the config/picflag.m4 macro to
> > customize PICFLAG according to the host when using --enable-host-shared.
> >
> > Fix configure.ac to do s
On Jun 9, 2020, Martin Jambor wrote:
>> Before your changes, GCC produced the expected:
>>
>> $ ls -1 build-gcc/gcc/testsuite/brig/variables.*???t.*
>> build-gcc/gcc/testsuite/brig/variables.hsail.brig.004t.original
>> build-gcc/gcc/testsuite/brig/variables.hsail.brig.005t.gimple
>>
>> Are you
I will study real.c carefully along with the C99 std
to determine if I can find useful values for RMIN2 and RMINSCAL
for each format which are within range for all instances
of that format. A quick skim of real.c shows we have ieee half precision
and two arm half precision formats, for example.
I
On Thu, 11 Jun 2020, Patrick McGehearty wrote:
> I will study real.c carefully along with the C99 std
> to determine if I can find useful values for RMIN2 and RMINSCAL
> for each format which are within range for all instances
> of that format. A quick skim of real.c shows we have ieee half precis
Thanks for viewing and pushing this.
Thanks,
Haijian Zhang
> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Thursday, June 11, 2020 12:01 AM
> To: Zhanghaijian (A)
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH PR95523] aarch64:ICE in registe
On Jun 9, 2020, Richard Biener wrote:
> How about simply unconditionally doing dump_flags | TDF_SLIM here
> to have the whole mem_expr on one line.
SGTM
> OK with that change.
Thanks, here's what I'm installing.
slim up mem exprs to avoid line breaks in -fverbose-asm
From: Alexandre Oliva
On May 26, 2020, Alexandre Oliva wrote:
> On May 19, 2020, Joseph Myers wrote:
>> Allowing a missing executable name is reasonable enough, but I was
>> actually thinking that the messages should print "gcc" or whatever command
>> the user ran in place of "collect2".
> Should we make the rege
Committed.
On Thu, Jun 11, 2020 at 5:13 AM Jim Wilson wrote:
>
> On Wed, Jun 10, 2020 at 1:08 AM Kito Cheng wrote:
> > * config/riscv/riscv-protos.h (riscv_output_gpr_save): Remove.
> > * config/riscv/riscv-sr.c (riscv_sr_match_prologue): Update
> > value.
> > * c
Committed with adding comments for those two functions.
On Thu, Jun 11, 2020 at 5:10 AM Jim Wilson wrote:
>
> On Wed, Jun 10, 2020 at 1:08 AM Kito Cheng wrote:
> > * config/riscv/riscv.c (gpr_save_reg_order): New.
> > (riscv_expand_prologue): Use riscv_gen_gpr_save_insn to gen
>
As we are on patching algos we still have this old one.
From the original patch I only kept the memory optimization part as
the new performance test was not showing good result for the other part
to change pivot value. I also kept the small change in
get_temporary_buffer even if I don't ha
101 - 121 of 121 matches
Mail list logo
