Hi Bill,
Thanks for the review comments!
on 2021/9/3 下午11:57, Bill Schmidt wrote:
> Hi Kewen,
>
> Sorry that we lost track of this patch! The heuristic approach looks good.
> It is limited in scope and won't kick in often, and the case you're trying to
> account for is important.
>
> At the
On Wed, Sep 8, 2021 at 1:08 AM Segher Boessenkool
wrote:
>
> Hi!
>
> On Tue, Sep 07, 2021 at 03:12:36AM -0400, Michael Meissner wrote:
> > [PATCH] Fix SFmode subreg of DImode and TImode
> >
> > This patch fixes the breakage in the PowerPC due to a recent change in
> > SUBREG
> > behavior.
>
> But
Hi,
The patch optimized for vec_reve builtin on rs6000. For V2DI and
V2DF, it is implemented by xxswapd on all targets. For V16QI, V8HI, V4SI
and V4SF, it is implemented by quadword byte reverse plus halfword/word
byte reverse when p9_vector is defined.
Bootstrapped and tested on powerpc
On Wed, Sep 8, 2021 at 12:05 AM Joseph Myers wrote:
>
> When testing for Nios II (gcc-testresults shows this for various other
> targets as well), tests scanning cselim dumps produce an UNRESOLVED
> result because those dumps do not exist.
>
> cselim is enabled conditionally by code in toplev.c:
>
On Tue, Sep 7, 2021 at 10:11 PM Iain Sandoe wrote:
>
> Hi Folks,
>
> So, looking through the various email threads and the PR, I think that
> what has happened is :
>
> As the PR points out, our existing PCH model does not work if the compiler
> executable is PIE - which manifests on platforms lik
Hi:
The optimization is decribled in PR.
The two instruction sequences are almost as fast, but the optimized
instruction sequences could be one mov instruction less on sse2 and
2 mov instruction less on sse3.
Bootstrapped and regtested on x86_64-linux-gnu{-m32,}.
gcc/ChangeLog:
PR
On Sun, Aug 22, 2021 at 8:28 AM H.J. Lu wrote:
>
> On Tue, Mar 23, 2021 at 09:19:38AM +0100, Richard Biener wrote:
> > On Tue, Mar 23, 2021 at 3:41 AM Hongyu Wang wrote:
> > >
> > > > Hongyue, please collect code size differences on SPEC CPU 2017 and
> > > > eembc.
> > >
> > > Here is code size d
On Wed, Sep 8, 2021 at 10:54 AM Hongtao Liu wrote:
>
> On Wed, Jul 21, 2021 at 3:43 PM liuhongt wrote:
> >
> > Hi:
> > As discussed in [1], this patch support _Float16 under target sse2
> > and above, w/o avx512fp16, _Float16 type is storage only, all operations
> > are emulated by soft-fp and
On Wed, Jul 21, 2021 at 3:43 PM liuhongt wrote:
>
> Hi:
> As discussed in [1], this patch support _Float16 under target sse2
> and above, w/o avx512fp16, _Float16 type is storage only, all operations
> are emulated by soft-fp and float instructions. Soft-fp keeps the intermediate
> result of the
On Wed, Sep 8, 2021 at 8:54 AM Hongtao Liu wrote:
>
> On Tue, Sep 7, 2021 at 8:29 PM Jakub Jelinek via Gcc-patches
> wrote:
> >
> > On Mon, Sep 06, 2021 at 10:58:53AM +0200, Jakub Jelinek via Gcc-patches
> > wrote:
> > > On Mon, Sep 06, 2021 at 08:49:27AM +0100, Iain Sandoe wrote:
> > > > > Ok.
On 7/23/21 4:58 AM, Matthias Kretz wrote:
Hi Jason,
I found a few regressions from the last patch in the meantime. Version 4 of
the patch is attached.
Questions:
1. I simplified the condition for calling dump_template_parms in
dump_function_name. !DECL_FRIEND_PSEUDO_TEMPLATE_INSTANTIATION (t)
On Wed, Sep 8, 2021 at 7:20 AM Segher Boessenkool
wrote:
>
> On Fri, Sep 03, 2021 at 05:05:47PM +0200, Andreas Schwab wrote:
> > On Sep 02 2021, Segher Boessenkool wrote:
> > > On Tue, Aug 31, 2021 at 07:17:49PM +0800, liuhongt via Gcc-patches wrote:
> > >>* emit-rtl.c (validate_subreg): Get r
On Tue, Sep 7, 2021 at 8:29 PM Jakub Jelinek via Gcc-patches
wrote:
>
> On Mon, Sep 06, 2021 at 10:58:53AM +0200, Jakub Jelinek via Gcc-patches wrote:
> > On Mon, Sep 06, 2021 at 08:49:27AM +0100, Iain Sandoe wrote:
> > > > Ok. The *.ver changes are still needed (see above), but that can be
> >
On Fri, Sep 03, 2021 at 05:05:47PM +0200, Andreas Schwab wrote:
> On Sep 02 2021, Segher Boessenkool wrote:
> > On Tue, Aug 31, 2021 at 07:17:49PM +0800, liuhongt via Gcc-patches wrote:
> >>* emit-rtl.c (validate_subreg): Get rid of all float-int
> >>special cases.
> >
> > This caused vario
Hi!
On Tue, Sep 07, 2021 at 03:12:36AM -0400, Michael Meissner wrote:
> [PATCH] Fix SFmode subreg of DImode and TImode
>
> This patch fixes the breakage in the PowerPC due to a recent change in SUBREG
> behavior.
But what was that change? And was that intentional? If so, why wasn't
it document
2021-09-07 Takayuki 'January June' Suwa
gcc/
PR target/102115
* config/xtensa/xtensa.c (xtensa_emit_move_sequence): Add
'CONST_INT_P (src)' to the condition of the block that tries to
eliminate literal when loading integer contant.
---
gcc/config/xtensa/xtensa.c
On Fri, Sep 3, 2021 at 2:00 AM Matthias Klose wrote:
>
> On 8/31/21 3:24 PM, H.J. Lu via Gcc-patches wrote:
> > On Thu, Aug 12, 2021 at 8:24 PM Ian Lance Taylor via Gcc-patches
> > wrote:
> >>
> >> This patch updates libgo from the Go1.16.5 release to the Go 1.17rc2
> >> release. As usual with t
This libgo patch uses hash32 rather than hash64 for amd32p32 (x32
mode) and mips64p32 and mips64p32le (the n32 ABI). This should fix PR
102102. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.
Committed to mainline.
Ian
3e86f786c08a5ae8b3153352a1295ab7fe6a4b51
diff --git a/gcc/go/gofron
When testing for Nios II (gcc-testresults shows this for various other
targets as well), tests scanning cselim dumps produce an UNRESOLVED
result because those dumps do not exist.
cselim is enabled conditionally by code in toplev.c:
if (flag_tree_cselim == AUTODETECT_VALUE)
{
if (HAVE
When adding the initializer for an array, we need to make sure that
array bounds are properly simplified if that array is a PARAMETER.
Otherwise the generated initializer could be wrong and screw up
subsequent simplifications, see PR.
The minimal solution is to attempt simplification of array boun
This commit introduces support for BPF Compile Once - Run
Everywhere (CO-RE) in GCC.
gcc/ChangeLog:
* config/bpf/bpf.c: Adjust includes.
(bpf_handle_preserve_access_index_attribute): New function.
(bpf_attribute_table): Use it here.
(bpf_builtins): Add BPF_BUILTIN_
This commit adds several tests for the new BPF CO-RE functionality to
the BPF target testsuite.
gcc/testsuite/ChangeLog:
* gcc.target/bpf/core-attr-1.c: New test.
* gcc.target/bpf/core-attr-2.c: Likewise.
* gcc.target/bpf/core-attr-3.c: Likewise.
* gcc.target/bpf/c
Document the new command line options (-mco-re and -mno-co-re), the new
BPF target builtin (__builtin_preserve_access_index), and the new BPF
target attribute (preserve_access_index) introduced with BPF CO-RE.
gcc/ChangeLog:
* doc/extend.texi (BPF Type Attributes) New node.
Docume
Expose the function get_btf_id, so that it may be used by the BPF
backend. This enables the BPF CO-RE machinery in the BPF backend to
lookup BTF type IDs, in order to create CO-RE relocation records.
A prototype is added in ctfc.h
gcc/ChangeLog:
* btfout.c (get_btf_id): Function is no lo
Expose the function ctf_dtd_lookup, so that it can be used by the BPF
CO-RE machinery. The function is no longer static, and an extern
prototype is added in ctfc.h.
gcc/ChangeLog:
* ctfc.c (ctf_dtd_lookup): Function is no longer static.
* ctfc.h: Analogous change.
---
gcc/ctfc.c
Add a new function, ctf_lookup_tree_type, to return the CTF type ID
associated with a type via its is TREE node. The function is exposed via
a prototype in ctfc.h.
gcc/ChangeLog:
* ctfc.c (ctf_lookup_tree_type): New function.
* ctfc.h: Likewise.
---
gcc/ctfc.c | 16 ++
Expose the function lookup_type_die in dwarf2out, so that it can be used
by CTF/BTF when adding BPF CO-RE information. The function is now
non-static, and an extern prototype is added in dwarf2out.h.
gcc/ChangeLog:
* dwarf2out.c (lookup_type_die): Function is no longer static.
* d
[ Changes from V1:
All patches have been OK'd, but the prerequisite series "Allow means for late
BTF generation for BPF CO-RE" had not been accepted. Now that that series has
been applied, this can be pushed with some very minor tweaks:
- Accomodate rename of option '-mco-re' (was -mcore)
2
# of expected failures 351
# of unresolved testcases 3
# of unsupported tests 662
x/cris-elf/gccobj/gcc/xgcc version 12.0.0 20210907 (experimental)\
[master r12-3391-g849d5f5929fc] (GCC)
testsuite:
* gcc.dg/no_profile_instrument_function-attr-2.c: Fix
Hi Folks,
So, looking through the various email threads and the PR, I think that
what has happened is :
As the PR points out, our existing PCH model does not work if the compiler
executable is PIE - which manifests on platforms like Darwin (which is PIE
by default) or Linux when configured —enabl
On Tue, Sep 07, 2021 at 04:01:41PM -0400, Jason Merrill via Gcc-patches wrote:
> By the way, please avoid using non-ASCII characters in testcases unless
> that's specifically what you're testing:
>
> > +// { dg-error "name ‘A::foo’" }
>
> Here, change the smart quotes to . to match whatever the o
By the way, please avoid using non-ASCII characters in testcases unless
that's specifically what you're testing:
+// { dg-error "name ‘A::foo’" }
Here, change the smart quotes to . to match whatever the output locale
uses for quotes. And the error comments in dependent-name16.C seem to
be
On 9/2/21 8:10 PM, Barrett Adair wrote:
Thanks for the feedback, Jason. Coming back to this today, The problem
appears much deeper than I realized. I've attached another WIP version
of the patch, including a couple of new test cases based on your
feedback (for now, please excuse any misformatte
Hi,
This is a small code cleanup patch, but is useful in follow-on work to
fix actual bugs - by making it only one place that we need to consider
the flattening of a statement containing await expressions.
tested on x86-64, powerpc-linux, x86_64-darwin,
OK for master?
thanks
Iain
— commit me
> On Sep 7, 2021, at 11:57 AM, Qing Zhao via Gcc-patches
> wrote:
>
> Hi, Richard,
>
> Thanks a lot for your review.
>
>> On Sep 6, 2021, at 5:16 AM, Richard Biener wrote:
>>
>> On Sat, 21 Aug 2021, Qing Zhao wrote:
>>
>>> Hi,
>>>
>>> This is the 8th version of the patch for the new sec
Hi Tobias,
I think I can follow now what you are thinking, and I also had some
thoughts about what you be done in principle.
I was struggling the way I did because of:
(1) Intel rejects the code in the PR. For my previous patch,
% ifort coarray_allocated.f90 -coarray
coarray_allocated.f90(8):
On 9/6/21 8:21 AM, Matthias Kretz wrote:
Hi,
On Tuesday, 20 July 2021 22:22:02 CEST Jason Merrill wrote:
The C++ front end already uses PAREN_EXPR in templates to indicate
parenthesized initializers in cases where that matters for
decltype(auto). It should be fine to use it for both that and
_
On 9/7/21 3:56 AM, Jakub Jelinek wrote:
Hi!
We do not save bodies of constexpr clones and instead evaluate the bodies
of the constexpr functions they were cloned from.
I believe that is just fine for constructors because complete vs. base
ctors differ only in classes that have virtual bases and
On 9/5/21 3:50 PM, Iain Sandoe wrote:
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
On 9/5/21 3:47 PM, Iain Sandoe wrote:
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.
Hi, Richard,
Thanks a lot for your review.
> On Sep 6, 2021, at 5:16 AM, Richard Biener wrote:
>
> On Sat, 21 Aug 2021, Qing Zhao wrote:
>
>> Hi,
>>
>> This is the 8th version of the patch for the new security feature for GCC.
>> I have tested it with bootstrap on both x86 and aarch64, regres
On Tue, Sep 07, 2021 at 06:07:35PM +0200, Tobias Burnus wrote:
> > depend case from the other clauses. The depend parsing tries to parse it
> > as the rigid varname followed by optional . field or array section and if
> > that fails, parses it as an expression, verifies it is lvalue and just
> > u
I realized I still managed to mess up some WS. I have attached a patch that is
the same, except fixes the WS issue
underneath.
Regards, Petter
+ FOR_EACH_VEC_ELT (m_globals, i, global)
+rest_of_decl_compilation (global, true, true);
0001-libgccjit-Generate-debug-info-for-variables-WS
On 07.09.21 13:34, Jakub Jelinek wrote:
On Tue, Sep 07, 2021 at 01:22:43PM +0200, Tobias Burnus wrote:
On 07.09.21 12:49, Jakub Jelinek wrote:
s/taits/traits/ and I'd add /handled/& correctly/
fixed.
+@item C/C++'s lvalue expressions in @code{to}, @code{from}, @code{depend}
+ and @code{m
Now committed as r12-3384-gfc4f0631de806c89a383fd02428a16e91068b9f6
Sorry for the breakage – and thanks for the report on IRC, Richard!
Tobias
On 07.09.21 16:13, Tobias Burnus wrote:
Since the last libgfortran/Makefile.am commit,
https://gcc.gnu.org/g:13beaf9e8d2d8264c0ad8f6504793fdcf26f3f73
On 9/7/2021 7:23 AM, Aldy Hernandez wrote:
On 9/7/21 2:59 PM, Richard Biener wrote:
On September 7, 2021 12:02:27 PM GMT+02:00, Aldy Hernandez
wrote:
On 9/6/21 9:19 AM, Richard Biener wrote:
On Fri, Sep 3, 2021 at 3:59 PM Aldy Hernandez via Gcc-patches
wrote:
This patch abstracts ou
Now I actually tested the patch – and fixed some issues.
OK? – It does add support for 'allocated(a[i])' by treating
it as 'allocated(a)', as 'a' must be collectively allocated
("established") on all images of the team.*
'a[i]' is (probably) an allocatable, following Malcolm in
answer to my ques
Since the last libgfortran/Makefile.am commit,
https://gcc.gnu.org/g:13beaf9e8d2d8264c0ad8f6504793fdcf26f3f73
the ISO_Fortran_binding.h file is no longer copied to
$(build)/.../libgfortran/include/ – which breaks in-build-tree testing.
The Makefile does contain the rule:
ISO_Fortran_binding
> ctnode between the two loops isn't used, so I think it is cleaner to just
> use two
> for (comdat_type_node *ctnode = comdat_type_list; ctnode != NULL;
>ctnode = ctnode->next)
> loops instead of reusing the iterator variable.
Thanks. IMO it's more readable this way though and it's the
On 07/09/2021 13:05, Christophe LYON wrote:
On 07/09/2021 11:42, Richard Earnshaw wrote:
On 07/09/2021 10:15, Christophe Lyon via Gcc-patches wrote:
At some point during the development of this patch series, it appeared
that in some cases the register allocator wants “VPR or general”
rath
On 9/7/21 2:59 PM, Richard Biener wrote:
On September 7, 2021 12:02:27 PM GMT+02:00, Aldy Hernandez
wrote:
On 9/6/21 9:19 AM, Richard Biener wrote:
On Fri, Sep 3, 2021 at 3:59 PM Aldy Hernandez via Gcc-patches
wrote:
This patch abstracts out a couple common idioms in the forward
thread
On September 7, 2021 12:02:27 PM GMT+02:00, Aldy Hernandez
wrote:
>
>
>On 9/6/21 9:19 AM, Richard Biener wrote:
>> On Fri, Sep 3, 2021 at 3:59 PM Aldy Hernandez via Gcc-patches
>> wrote:
>>>
>>> This patch abstracts out a couple common idioms in the forward
>>> threader that I found useful while
On Mon, Sep 06, 2021 at 10:58:53AM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Mon, Sep 06, 2021 at 08:49:27AM +0100, Iain Sandoe wrote:
> > > Ok. The *.ver changes are still needed (see above), but that can be done
> > > incrementally.
> >
> > I can commit the .ver change if that’s approved
On Tue, Sep 07, 2021 at 02:06:29PM +0200, Eric Botcazou wrote:
> this is the recent LTO bootstrap failure with Ada enabled. The compiler now
> generates DW_OP_deref_type for a unit of the Ada front-end, which means that
> the offset of base types in the CU must be computed during early DWARF too
Hi,
this is the recent LTO bootstrap failure with Ada enabled. The compiler now
generates DW_OP_deref_type for a unit of the Ada front-end, which means that
the offset of base types in the CU must be computed during early DWARF too.
LTO-bootstrapped/regtested on x86-64/Linux, OK for the mainli
On 07/09/2021 11:42, Richard Earnshaw wrote:
On 07/09/2021 10:15, Christophe Lyon via Gcc-patches wrote:
At some point during the development of this patch series, it appeared
that in some cases the register allocator wants “VPR or general”
rather than “VPR or general or FP” (which is the sa
On Tue, Sep 07, 2021 at 01:22:43PM +0200, Tobias Burnus wrote:
> On 07.09.21 12:49, Jakub Jelinek wrote:
> > On Tue, Sep 07, 2021 at 12:39:01PM +0200, Tobias Burnus wrote:
> > > +@item @code{declare variant} directive @tab P @tab Only C and C++
> > Even for C/C++, we don't handle the simd stuff the
On 07.09.21 12:49, Jakub Jelinek wrote:
On Tue, Sep 07, 2021 at 12:39:01PM +0200, Tobias Burnus wrote:
+@item @code{declare variant} directive @tab P @tab Only C and C++
Even for C/C++, we don't handle the simd stuff there (where we should be
expecting a different function types in those cases,
This fixes re-use of the reduction value in epilogue vectorization
when a conversion from/to variable lenght vectors is required.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-09-07 Richard Biener
PR tree-optimization/102226
* tree-vect-loop.c (vect_transfo
On Tue, Sep 07, 2021 at 12:39:01PM +0200, Tobias Burnus wrote:
> +@item @code{declare variant} directive @tab P @tab Only C and C++
Even for C/C++, we don't handle the simd stuff there (where we should be
expecting a different function types in those cases, ones following the
declare simd ABIs).
Hi Jakub,
On 07.09.21 10:14, Jakub Jelinek wrote:
libgomp.texi: Add OpenMP Implementation Status
libgomp/
* libgomp.texi (Enabling OpenMP): Refer to OMP spec in general
not to 4.5; link to new section.
(OpenMP Implementation Status): New.
Ok. I'll try to provide the 5.0 impleme
On Tue, Sep 07, 2021 at 06:08:44PM +0800, Hongtao Liu wrote:
> -On x86 targets with @code{target("sse2")} and above, GCC supports
> half-precision
> -(16-bit) floating point via the @code{_Float16} type which is defined by
> -18661-3:2015. For C++, x86 provide a builtin type named @code{_Float16}
>
On Tue, Sep 7, 2021 at 3:18 PM Jakub Jelinek wrote:
>
> On Tue, Sep 07, 2021 at 09:52:57AM +0800, Hongtao Liu wrote:
> > Adjust the wording for x86 _Float16 type.
> >
> > gcc/ChangeLog:
> >
> > * doc/extend.texi: (@node Floating Types): Adjust the wording.
> > (@node Half-Precision): Ditto.
> >
>
On 9/6/21 9:19 AM, Richard Biener wrote:
On Fri, Sep 3, 2021 at 3:59 PM Aldy Hernandez via Gcc-patches
wrote:
This patch abstracts out a couple common idioms in the forward
threader that I found useful while navigating the code base.
Tested on x86-64 Linux.
OK?
gcc/ChangeLog:
*
Hi.
I'm planning some refactoring related to 'section *' and I noticed we have
quite ugly mask definitions (of form 1UL << N), where SECTION_FORGET is unused
and
#define SECTION_STYLE_MASK 0x60 /* bits used for SECTION_STYLE */
Is actually OR of 2 other values. What about making that a
On 07/09/2021 10:15, Christophe Lyon via Gcc-patches wrote:
At some point during the development of this patch series, it appeared
that in some cases the register allocator wants “VPR or general”
rather than “VPR or general or FP” (which is the same thing as
ALL_REGS). The series does not see
On 9/6/21 14:16, Richard Biener wrote:
On Mon, Sep 6, 2021 at 1:46 PM Jakub Jelinek wrote:
On Mon, Sep 06, 2021 at 01:37:46PM +0200, Martin Liška wrote:
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -1323,6 +1323,14 @@ finish_options (struct gcc_options *opts, struct
gcc_options *opts_set,
=
This patch covers a few non-load/store builtins where we do not use
the iterator and thus we cannot use .
We need to update the expected code in cde-mve-full-assembly.c because
we now use mve_movv16qi instead of movhi to generate the vmsr
instruction.
2021-09-02 Christophe Lyon
gcc/
This patch covers a few builtins where we do not use the
iterator and thus we cannot use .
However this introduces a problem for the v2di instructions, because
there is not predicate for this case. For instance, changing
STRSBS_P_QUALIFIERS breaks mve_vstrdq_scatter_base_p_v2di.
Similarly, this
This is mostly a mechanical change, only tested by the intrinsics
expansion tests.
2021-09-02 Christophe Lyon
gcc/
PR target/100757
PR target/101325
* config/arm/arm-builtins.c (BINOP_UNONE_NONE_NONE_QUALIFIERS):
Delete.
(TERNOP_UNONE_NONE_NONE_U
From: Christophe Lyon
The problem in this PR is that we call VPSEL with a mask of vector
type instead of HImode. This happens because operand 3 in vcond_mask
is the pre-computed vector comparison and has vector type.
This patch fixes it by implementing TARGET_VECTORIZE_GET_MASK_MODE,
returning t
We make use of qualifier_predicate to describe MVE builtins
prototypes, restricting to auto-vectorizable vcmp* and vpsel builtins,
as they are exercised by the tests added earlier in the series.
Special handling is needed for mve_vpselq because it has a v2di
variant, which has no natural VPR.P0 re
This patch implements support for vectors of booleans to support MVE
predicates, instead of HImode. Since the ABI mandates pred16_t (aka
uint16_t) to represent predicates in intrinsics prototypes, we
introduce a new "predicate" type qualifier so that we can map relevant
builtins HImode arguments a
The vmvnq_n* intrinsics and have [u]int[16|32]_t arguments, so use
iterator instead of HI in mve_vmvnq_n_.
2021-09-03 Christophe Lyon
gcc/
* config/arm/mve.md (mve_vmvnq_n_): Use V_elem mode
for operand 1.
diff --git a/gcc/config/arm/mve.md b/gcc/config/arm/mve.md
ind
VPR_REG is the only register in its class, so it should be handled by
TARGET_CLASS_LIKELY_SPILLED_P. No test fails without this patch, but
it seems it should be implemented.
2021-09-01 Christophe Lyon
gcc/
* config/arm/arm.c (arm_class_likely_spilled_p): Handle VPR_REG.
diff
This patch mainly adds Neon tests similar to existing MVE ones,
to make sure we do not break Neon when fixing MVE.
mve-vcmp-f32-2.c is similar to mve-vcmp-f32.c but uses a conditional
with 2.0f and 3.0f constants to help scan-assembler-times.
2021-09-01 Christophe Lyon
gcc/testsuite/
These tests currently trigger an ICE which is fixed later in the patch
series.
The pr100757*.c testcases are derived from
gcc.c-torture/compile/20160205-1.c, forcing the use of MVE, and using
various types and return values different from 0 and 1 to avoid
commonalization with boolean masks. In ad
At some point during the development of this patch series, it appeared
that in some cases the register allocator wants “VPR or general”
rather than “VPR or general or FP” (which is the same thing as
ALL_REGS). The series does not seem to require this anymore, but it
seems to be a good thing to do
This test is derived from the one provided in the PR: it is a
compile-only test because I do not have access to anything that could
execute it. We can switch it do 'dg-do run' later, however it would
be better to write a new executable test to ensure coverage in case
the tester cannot execute such
This patch series addresses PR 100757 and 101325 by representing
vectors of predicates (MVE VPR.P0 register) as vectors of booleans
rather than using HImode.
As this implies a lot of mostly mechanical changes, I have tried to
split the patches in a way that should help reviewers, but the split
is
This avoids doing redundant work during PHI translation to invalidate
mems when translating their corresponding VUSE through the blocks
virtual PHI node. All the invalidation work is already done by
prune_clobbered_mems.
This speeds up the compile of the testcase from 275s with PRE
taking 91% of
On Mon, Sep 06, 2021 at 06:48:25PM +0200, Tobias Burnus wrote:
> Hi Jakub, hi all,
>
> as the issue came up from time to time, I thought it
> makes sense to add an implementation status.
>
> I settled on putting it into libgomp.texi instead of
> a webpage or another location.
>
> The 5.1 section
On Mon, Sep 06, 2021 at 06:08:14PM +0200, Marcel Vollweiler wrote:
> C, C++, Fortran, OpenMP: Add support for 'flush seq_cst' construct.
>
> This patch adds support for the 'seq_cst' memory order clause on the 'flush'
> directive which was introduced in OpenMP 5.1.
>
> gcc/c-family/ChangeLog:
>
Hi Harald,
I spend yesterday about two hours with this. Now I am still
tired but understand more. I think the confusion between the
two of us is due to wording and in which directions the
thoughts then go:
Talking about coindexed, all of a[i], b[i]%c and c%d[i] are
coindexed and there are many
Hi!
We do not save bodies of constexpr clones and instead evaluate the bodies
of the constexpr functions they were cloned from.
I believe that is just fine for constructors because complete vs. base
ctors differ only in classes that have virtual bases and such constructors
aren't constexpr, simila
On Tue, Sep 07, 2021 at 09:52:57AM +0800, Hongtao Liu wrote:
> Adjust the wording for x86 _Float16 type.
>
> gcc/ChangeLog:
>
> * doc/extend.texi: (@node Floating Types): Adjust the wording.
> (@node Half-Precision): Ditto.
>
> 1 file changed, 15 insertions(+), 13 deletions(-)
> gcc/doc/extend.t
[PATCH] Fix SFmode subreg of DImode and TImode
This patch fixes the breakage in the PowerPC due to a recent change in SUBREG
behavior. While it is arguable that the patch that caused the breakage should
be reverted, this patch should be a bandage to prevent these changes from
happening again.
I
87 matches
Mail list logo