On Tue, Oct 20, 2020 at 04:34:46PM -0500, will schmidt wrote:
> This adds support for the VSX load/store rightmost element operations.
> This includes the instructions lxvrbx, lxvrhx, lxvrwx, lxvrdx,
> stxvrbx, stxvrhx, stxvrwx, stxvrdx; And the builtins
> vec_xl_sext() /* vector load sign extend *
On Tue, Oct 20, 2020 at 5:19 AM Richard Biener
wrote:
>
> On Tue, Oct 20, 2020 at 1:24 PM Martin Liška wrote:
> >
> > PING^5
>
> So can we use the same identifier as clang here as Nick
> requests? Thus, OK with re-naming everything alongside
> no_stack_protector. It isn't really the opposite of
On 10/21/20 12:37 PM, Patrick Palka wrote:
In the testcase below, folding of the initializer for 'ret' inside the
instantiated f::lambda ends up yielding an initializer for which
potential_constant_expression returns false. This causes finish_function
to mark the lambda as non-constexpr, which u
On Wed, Oct 21, 2020 at 02:04:15PM -0700, Nick Desaulniers via Gcc-patches
wrote:
> Tangentially related question:
> We're running into a bug related to LTO for the kernel when code
> compiled with -fno-stack-protector is called from and inlined into
> code that is compiled with -fstack-protector.
>
> Hello.
>
> Maybe a silly question, but isn't the code only an obfuscation?
> What about doing:
>
> if (__builtin_constant_p(x))
> return x < 2 ? 0 : __builtin_clz(x);
>
> which is fully eliminated in a c.031t.ccp1 pass right after einline happens
> for a call context where 'x' is a consta
> On Wed, Oct 21, 2020 at 09:03:03PM +0200, Martin Liška wrote:
> > Maybe a silly question, but isn't the code only an obfuscation?
> > What about doing:
> >
> > if (__builtin_constant_p(x))
> > return x < 2 ? 0 : __builtin_clz(x);
> >
> > which is fully eliminated in a c.031t.ccp1 pass right a
Thanks for the quick feedback!
On Wed, Oct 21, 2020 at 2:13 PM Jakub Jelinek wrote:
>
> On Wed, Oct 21, 2020 at 02:04:15PM -0700, Nick Desaulniers via Gcc-patches
> wrote:
> > Tangentially related question:
> > We're running into a bug related to LTO for the kernel when code
> > compiled with -f
On Wed, 21 Oct 2020, Jason Merrill wrote:
> On 10/8/20 4:47 PM, Patrick Palka wrote:
> > In the testcase below, we're ICEing during constexpr evaluation of the
> > CONSTRUCTOR {.data={{}, [1 ... 7]={}}} of type 'vector'. The apparently
> > unique thing about this CONSTRUCTOR is that it has a RANG
On 10/21/20 6:32 AM, kamlesh kumar wrote:
gcc/cp/ChangeLog
---
2020-10-21 Kamlesh Kumar
PR c++/97453
* pt.c (get_template_base): Implement DR2303,
Consider closest base while template
deduction when base of base also matches.
gcc/testsuite/ChangeLog
-
On 10/21/20 5:46 PM, Patrick Palka wrote:
On Wed, 21 Oct 2020, Jason Merrill wrote:
On 10/8/20 4:47 PM, Patrick Palka wrote:
In the testcase below, we're ICEing during constexpr evaluation of the
CONSTRUCTOR {.data={{}, [1 ... 7]={}}} of type 'vector'. The apparently
unique thing about this C
+ correct kernel mailing list this time.
On Wed, Oct 21, 2020 at 2:33 PM Nick Desaulniers
wrote:
>
> Thanks for the quick feedback!
>
> On Wed, Oct 21, 2020 at 2:13 PM Jakub Jelinek wrote:
> >
> > On Wed, Oct 21, 2020 at 02:04:15PM -0700, Nick Desaulniers via Gcc-patches
> > wrote:
> > > Tangen
On Wed, Oct 21, 2020 at 03:29:11PM -0500, Segher Boessenkool wrote:
> Anyway:
>
> + || (outer_code == AND
> + && rs6000_is_valid_2insn_and (x, mode)))
> {
> *total = COSTS_N_INSNS (1);
> return true;
>
> It should return COSTS_N_INSNS (2)
hi,
this patch makes builtin_constant_p hint to combine with other loop hints
we already support. This is necessary for it to be realy effective
since most such functions will already get big_speedup hint.
Bootstrapped/regtested x86_64-linux, comitted.
gcc/ChangeLog:
2020-10-22 Jan Hubicka
This libgo patch by Nikhil Benesch imports the upstream code for BSD
sockets and sysctls into the syscall package. This code is
sufficiently different that it doesn't get merged by the scripts.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
to mainline.
Ian
d031aa7b3be4155b
Full comments in the PR, but basically substitute and fold was expecting
to see a constant returned for any range which globally evaluates to a
constant.
This allowed it to replace all uses of an ssa name as they were encountered.
The ranger model can return UNDEFINED for the range of names in
Hi kyrylo,
>
> From: Kyrylo Tkachov
> Sent: Wednesday, October 14, 2020 10:14 AM
> To: Dennis Zhang; gcc-patches@gcc.gnu.org
> Cc: nd; Richard Earnshaw; Ramana Radhakrishnan
> Subject: RE: [PATCH][Arm] Auto-vectorization for MVE: vmul
>
> Hi Dennis,
>
>
Pick up the correct type for the RHS of a_2 = &b.
bootstrapped on x86_64-pc-linux-gnu, no regressions, pushed.
Andrew
commit 966fdb2e12c0347aa3f9efaf5f4e1cd8237fa024
Author: Andrew MacLeod
Date: Wed Oct 21 20:11:16 2020 -0400
Handle a_2= &b properly in range calculations.
when
Hi,
this patch moves nested function information out of cgraph_node (to a summary).
This saves memory (especially at WPA time) and also makes nested function
support more contained.
Bootstrapped/regtested x86_64-linux. Plan to commit it tomorrow.
gcc/ChangeLog:
2020-10-22 Jan Hubicka
Hi Kyrylo,
>
> From: Kyrylo Tkachov
> Sent: Wednesday, October 14, 2020 10:15 AM
> To: Dennis Zhang; gcc-patches@gcc.gnu.org
> Cc: nd; Richard Earnshaw; Ramana Radhakrishnan
> Subject: RE: [PATCH][Arm] Auto-vectorization for MVE: vmin/vmax
>
> Hi Dennis,
>
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555646.html
Thanks
From: Dennis Zhang
Sent: Tuesday, October 6, 2020 5:46 PM
To: gcc-patches@gcc.gnu.org
Cc: Kyrylo Tkachov; nd; Richard Earnshaw; Ramana Radhakrishnan
Subject: Re: [PATCH][Arm] A
On Wed, Oct 21, 2020 at 11:04 PM Vladimir Makarov wrote:
>
>
> On 2020-10-20 10:11 p.m., Hongtao Liu wrote:
> >
> > Changed, and it passed the i386/x86-64 regression test.
> >
> > Update patch.
> >
> Thank you, Hongtao. This patch is ok for the trunk.
>
>
Thanks for the review, committed.
--
B
On Fri, Oct 16, 2020 at 2:34 AM Kito Cheng wrote:
> +# Example 2:
> +# rv32imafd-ilp32d--c*b
> +# means that, in addition to rv32imafd, these configurations can also use
> the
> +# rv32imafd-ilp32d libraries: rv32imafd-ilp32dc, rv32imafd-ilp32db,
> +# rv32imafd-ilp32d
On Wed, Oct 21, 2020 at 7:36 PM Jim Wilson wrote:
>
>
> On Fri, Oct 16, 2020 at 2:34 AM Kito Cheng wrote:
>
>> +# Example 2:
>> +# rv32imafd-ilp32d--c*b
>> +# means that, in addition to rv32imafd, these configurations can also
>> use the
>> +# rv32imafd-ilp32d libraries: rv32imafd-ilp32dc, rv32
I had a wrong email setting and got your reply later. I modified the
patch according to your advice. Could you please review it again? Thanks.
On 2/10/2020 上午 1:47, Richard Sandiford wrote:
Sorry for the slow review.
HAO CHEN GUI via Gcc-patches writes:
diff --git a/gcc/config/mips/mips.c b/
On Thu, Oct 22, 2020 at 12:36 AM Segher Boessenkool
wrote:
>
> On Wed, Oct 21, 2020 at 04:43:29PM +0100, Richard Sandiford wrote:
> > Hongtao Liu writes:
> > > + poly_uint64 nunits
> > > + = GET_MODE_NUNITS (GET_MODE (SUBREG_REG (trueop0)));
> > > + rtx par = trueop1;
>
The sincos transformation does not take place on all platforms,
because the libc_has_function target hook disables it by default.
Current w64-mingw's math library supports sincos, sincosl and sincosf,
in 32- and 64-bit modes. I suppose this has been this way for long,
also with mingw32 and cygw
Err, sorry, I mislabeled this patch as [FYI,Ada], but it is neither
about Ada nor pre-approved. It does require a review before I can check
it in.
On Oct 22, 2020, Alexandre Oliva wrote:
> for gcc/ChangeLog
> * config/i386/cygming.h (TARGET_LIBC_HAS_FUNCTION): Enable
> sincos opti
On Oct 19, 2020, Alexandre Oliva wrote:
> Hello, Andreas,
> On Oct 19, 2020, Andreas Schwab wrote:
>> -nostdinc a-nallfl.ads -o a-nallfl.o
>> a-nallfl.ads:48:13: warning: intrinsic binding type mismatch on return value
>> a-nallfl.ads:48:13: warning: intrinsic binding type mismatch on argument
On Oct 20, 2020, Rainer Orth wrote:
> your patch similarly broke sparc*-sun-solaris* bootstrap. The attached
> snippet on top of this workaround fixes that.
Thanks, here's what I'm installing, approved by me with my build
machinery maintainer hat on ;-)
Use Aux_Long_Long_Float wraplf for spar
On Oct 18, 2020, Alexandre Oliva wrote:
> The option is provided by default, but there is an alternate version
> that doesn't, that is used for vxworks targets.
vxworks float EFs not precise enough -> use long float
From: Alexandre Oliva
Some acats-4 tests that check the precision of Float el
On Oct 18, 2020, Alexandre Oliva wrote:
> The Aux_Short_Float unit is implemented in terms of the Aux_Float one,
> and the others rely on the elementary functions from the C Math
> library for float, double and long double types, respectively.
Use Aux_Long_Float for all real types on LynxOS
Fr
This libgo patch by Nikhil Benesch only compiles the ptrace varargs
shim on GNU/Linux, to avoid compilation failures on some other
platforms. The C ptrace function is not entirely portable (e.g.,
NetBSD has `int data` instead of `void* data`), and so far Linux is
the only platform that needs the va
gcc.target/powerpc/vsx_mask-count-runnable.c and others
Assembler messages:
Error: unrecognized opcode: `vcntmb'
I'm applying this one as obvious. Ref
https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549757.html
* config/rs6000/vsx.md (vec_cntmb_, vec_extract_),
(vec_expand_):
FAIL: gcc.target/powerpc/vec-splati-runnable.c 1 blank line(s) in output
FAIL: gcc.target/powerpc/vec-splati-runnable.c (test for excess errors)
Excess errors:
rs6000_emit_xxspltidp_v2df called ...
and running the test fails. As the comment says
/* Although the instruction says the results are
These tests require -mno-pcrel because they are testing features
of the non-pcrel ABI.
* gcc.target/powerpc/cprophard.c: Add -mno-pcrel to options.
* gcc.target/powerpc/float128-hw3.c: Likewise.
* gcc.target/powerpc/pr79439-1.c: Likewise.
* gcc.target/powerpc/pr7943
101 - 135 of 135 matches
Mail list logo
