On Thu, Sep 2, 2021 at 7:54 PM Richard Sandiford
wrote:
>
> Hongtao Liu via Gcc-patches writes:
> > On Wed, Sep 1, 2021 at 8:52 PM Richard Sandiford
> > wrote:
> >>
> >> Richard Biener writes:
> >> > On Wed, Sep 1, 2021 at 8:28 AM Hongtao Liu wrote:
> >> >>
> >> >> On Tue, Aug 31, 2021 at 7:56
Hi,
The patch optimized the code generation for vec_xl_sext builtin. Now
all the sign extensions are done on VSX registers directly.
Bootstrapped and tested on powerpc64le-linux with no regressions. Is
this okay for trunk? Any recommendations? Thanks a lot.
ChangeLog
2021-09-06 Haoch
Hi
The patch optimized expansion for long long or double vec_reve builtin.
Bootstrapped and tested on powerpc64le-linux with no regressions.
Is this okay for trunk? Any recommendations? Thanks a lot.
ChangeLog
2021-09-06 Haochen Gui
gcc/
* config/rs6000/altivec.md (altivec_vrev
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578162.html
Thanks
On 26/8/2021 上午 9:19, HAO CHEN GUI wrote:
Hi Bill,
Thanks for your comments.
Hi Segher,
Here is the ChangeLog and patch diff. Thanks.
2021-08-25 Haochen Gui
gcc/
* config/rs6000
On Sun, Sep 5, 2021 at 5:56 AM H.J. Lu via Gcc-patches
wrote:
>
> Enable FMA in scalar/vector unsigned SI to SF expanders.
>
> gcc/
>
> PR target/85819
> * config/i386/i386-expand.c (ix86_expand_convert_uns_sisf_sse):
> Enable FMA.
> (ix86_expand_vector_convert_uns_
From: Andrew Pinski
These two testcases have been failing since GCC 5 but things
have improved such that adding a simplification to match.pd
for this case is easier than before.
In the end we have the following IR:
_5 = &a[1] + _4;
_7 = &a + _13;
if (_5 != _7)
So we can fold the _5 !=
On 9/5/21 7:29 PM, H.J. Lu wrote:
On Sun, Sep 5, 2021 at 11:02 AM Sandra Loosemore
wrote:
On 9/5/21 7:31 AM, H.J. Lu wrote:
On Sat, Sep 4, 2021 at 7:31 PM Sandra Loosemore wrote:
The testcase gfortran.dg/PR100914.f90 that I recently checked in
(originally written by José Rui Faustino de So
On Sun, Sep 5, 2021 at 5:54 AM H.J. Lu via Gcc-patches
wrote:
>
> Add non-destructive source alternative to @xorsign3_1 for AVX.
LGTM.
>
> gcc/
>
> PR target/89984
> * config/i386/i386-expand.c (ix86_split_xorsign): Use operands[2].
> * config/i386/i386.md (@xorsign3_1): Ad
If the first predicate value is different and copied, the comparison will then
be between val->result and the copied one, which seems to be a bug. That can
cause inserting extra vn_pvals.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
Regards,
Di Zhao
gcc/ChangeLog:
* tree-ssa-s
On Fri, Sep 3, 2021 at 8:42 PM Jakub Jelinek via Gcc-patches
wrote:
>
> On Mon, Aug 02, 2021 at 02:31:12PM +0800, liuhongt via Gcc-patches wrote:
> > * doc/extend.texi (Half-Precision Floating Point): Documemt
> > _Float16 for x86.
>
> > --- a/gcc/doc/extend.texi
> > +++ b/gcc/doc/exte
On Fri, Sep 3, 2021 at 5:01 PM Jakub Jelinek via Gcc-patches
wrote:
>
> On Fri, Sep 03, 2021 at 03:41:13PM +0800, liuhongt via Gcc-patches wrote:
> > --- a/libgcc/config/i386/64/t-softfp
> > +++ b/libgcc/config/i386/64/t-softfp
> > @@ -1 +1,6 @@
> > softfp_extras := fixhfti fixunshfti floattihf f
On Fri, Sep 3, 2021 at 5:01 PM Jakub Jelinek via Gcc-patches
wrote:
>
> On Fri, Sep 03, 2021 at 03:41:13PM +0800, liuhongt via Gcc-patches wrote:
> > --- a/libgcc/config/i386/64/t-softfp
> > +++ b/libgcc/config/i386/64/t-softfp
> > @@ -1 +1,6 @@
> > softfp_extras := fixhfti fixunshfti floattihf f
On Sun, Sep 5, 2021 at 11:02 AM Sandra Loosemore
wrote:
>
> On 9/5/21 7:31 AM, H.J. Lu wrote:
> > On Sat, Sep 4, 2021 at 7:31 PM Sandra Loosemore
> > wrote:
> >>
> >> The testcase gfortran.dg/PR100914.f90 that I recently checked in
> >> (originally written by José Rui Faustino de Sousa) depends
Ping^2, thanks.
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572330.html
On 2021/6/30 09:47, Xionghu Luo via Gcc-patches wrote:
Gentle ping, thanks.
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572330.html
On 2021/6/9 16:03, Xionghu Luo via Gcc-patches wrote:
Hi,
On 2021/6/9
Ping^2, thanks.
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570333.html
On 2021/6/30 09:42, Xionghu Luo via Gcc-patches wrote:
Gentle ping, thanks.
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570333.html
On 2021/5/14 14:57, Xionghu Luo via Gcc-patches wrote:
Hi,
On 2021/5/13
This patch updates libgo to the final Go 1.17 release. (I'm aware of
a couple of bug reports building libgo, I haven't had time to get to
them yet.) Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.
Committed to mainline.
Ian
patch.txt
1d98014a8ae3c357071478d337f0169edec2ce0c
diff --git
This patch simplifies the RTX (subreg:HI (truncate:QI (reg:SI))) as
(truncate:HI (reg:SI)), and closely related variants. In RTL, a
paradoxical SUBREG where the outermode is wider than the innermode
is like the extensions zero_extend or sign_extend, but where we
don't care about the contents of t
As diagnosed with Jakub and Richard in the analysis of PR 102134, the
current implementation of wi::clz has incorrect/inconsistent behaviour.
As mentioned by Richard in comment #7, clz should (always) return zero
for negative values, but the current implementation can only return 0
when precision
Hello Jason,
> On 3 Sep 2021, at 15:23, Iain Sandoe wrote:
>> On 3 Sep 2021, at 15:07, Jason Merrill via Gcc-patches
>> wrote:
>>
>> On 9/1/21 6:56 AM, Iain Sandoe wrote:
>>> This adds top level proxy variables for the coroutine frame
>>> + add_decl_expr (parm_i->copy_var);
>>
>> Are the
Hello Jason,
The patch below is a squashed version of:
(approved) [PATCH 4/8] coroutines: Make some of the artificial names more
debugger-friendly.
[PATCH 5/8] coroutines: Define and populate accessors for
debug state.
[PATCH 6/8] coroutines: Convert imple
Here is the third version of the patch. This also
fixes the index zero case. Thus, this should be
a complete fix for 91038 and should fix all cases
also supported by clang. Still not working is
returning a struct of variable size from a
statement expression (29970) when the size depends
on compu
On 9/5/21 7:31 AM, H.J. Lu wrote:
On Sat, Sep 4, 2021 at 7:31 PM Sandra Loosemore wrote:
The testcase gfortran.dg/PR100914.f90 that I recently checked in
(originally written by José Rui Faustino de Sousa) depends on the
header file to obtain a typedef for __complex128. It
appears not to be p
The path solver's range_of_stmt() was handcuffed to only fold
GIMPLE_COND statements, since those were the only statements the
backward threader needed to resolve. However, there is no need for this
restriction, as the folding code is perfectly capable of folding any
statement.
This can be the ca
On Sat, Sep 4, 2021 at 7:31 PM Sandra Loosemore wrote:
>
> The testcase gfortran.dg/PR100914.f90 that I recently checked in
> (originally written by José Rui Faustino de Sousa) depends on the
> header file to obtain a typedef for __complex128. It
> appears not to be possible to define an equival
Keeping track of unreachable calculations while traversing a path is
useful to determine edge reachability, among other things. We've been
doing this ad-hoc in the backwards threader, so this provides a cleaner
way of accessing the information.
This patch also makes it easier to compare different
All callers to maybe_register_path() call find_taken_edge() beforehand
and pass the edge as an argument. There's no reason to repeat this
at each call site.
This is a clean-up in preparation for some other enhancements to the
backwards threader.
Tested on x86-64 Linux.
Committed as obvious.
gc
26 matches
Mail list logo
