On 5/4/22 10:03, Kyrylo Tkachov wrote:
-Original Message-
From: Gcc-patches On Behalf Of Christophe
Lyon via Gcc-patches
Sent: Wednesday, May 4, 2022 8:51 AM
To: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] arm: Restrict support of vectors of boolean immediates
(PR target/104662
This iterator is not used anymore and is a leftover from previous
cleanup (r10-5890-gabbe1ed2735517).
2022-04-28 Christophe Lyon
gcc/
* config/aarch64/iterators.md (GPF_TF_F16): Delete.
---
gcc/config/aarch64/iterators.md | 3 ---
1 file changed, 3 deletions(-)
diff --git a/g
This test is executed in both C and C++ modes, lines 98 and 100 pass
in C++ and are xfail in C.
This results in similar lines in gcc.sum and g++.sum, differing by the
PASS or XFAIL prefix, which confuses compare_test: it reports these
tests twice, as "now fail, but worked before" and "now work, bu
This patch series enables support of DFP on AArch64, using the BID
format (Binary Integer Decimal). There is no HW support for DFP on
AArch64, and we made a choice similar to x86: BID format using
libgcc's libbid for software emulation.
This work was done independently from Andrew's patch, which
This patch updates the aarch64 backend as needed to support DFP modes
(SD, DD and TD).
2022-03-31 Christophe Lyon
gcc/
* config/aarch64/aarch64.cc
(aarch64_split_128bit_move): Handle DFP modes.
(aarch64_gen_storewb_pair): Likewise.
(aarch64_gen_loadwb_pa
These tests exercise exception handling with Decimal Floating-Point
type.
dfp-1.C and dfp-2.C check that thrown objects of such types are
properly caught, whether when using C++ classes (decimalXX) or via GCC
mode attributes.
dfp-saves-aarch64.C checks that such objects are properly restored,
and
Some tests for the BID format are currently restricted to i?86 and
x86_64, but they also pass on AArch64, so this patch enables them.
Since all these tests are related to the BID format, it seems useful
to introduce a new effective-target (dfp_bid) instead of adding
aarch64 to the current target l
This patch adds support for trunc and extend operations between HF
mode (__fp16) and Decimal Floating Point formats (_Decimal32,
_Decimal64 and _Decimal128).
For simplicity we rely on the implicit conversions inserted by the
compiler between HF and SD/DF/TF modes. The existing bid*_to_binary*
and
DFP support on AArch64 relies on libgcc, so enable its DFP routines
for all AArch64 targets.
2022-03-31 Christophe Lyon
* libgcc/config.host: Add t-dfprules to AArch64 targets.
---
libgcc/config.host | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libgcc/config.host b/libgcc
Some targets do not support XF mode (eg AArch64), so don't build the
corresponding to/from DFP modes convertion routines if
__LIBGCC_HAS_XF_MODE__ is not defined.
2022-03-31 Christophe Lyon
libgcc/
* config/libbid/_dd_to_xf.c: Check __LIBGCC_HAS_XF_MODE__.
* config/libb
This patch copies all existing tests involving float/double/long
double types and replaces them with _Decimal32/_Decimal64/_Decimal128.
I thought it would be clearer/easier to maintain to do it this way
rather than adding tests for DFP types in the existing testcases,
except for func-ret-1.c and fu
This patch enables DFP support on aarch64, by updating config/dfp.m4
and regenerating the involved configure scripts.
We enable the BID format.
2022-03-31 Christophe Lyon
* config/dfp.m4: Add aarch64 support.
* gcc/configure: Regenerate.
* libdecnumber/configure: Regene
This patch replaces libbid's implementations of clz and ctz for 32 and
64 bits inputs which used several masks, and switches to the
corresponding builtins. This will provide a better implementation,
especially on targets with clz/ctz instructions.
2022-05-06 Christophe Lyon
libgcc/config/libbi
The testcase in c-c++-common/dfp/pr39986.c detects if DFP constants
are correctly emitted in the assembly. However, AArch64 uses .word
instead of the expected .long directive. With this patch, we now
accept both.
2022-03-31 Christophe Lyon
gcc/testsuite/
* c-c++-common/dfp/pr39
On 5/9/22 23:27, Joseph Myers wrote:
On Mon, 9 May 2022, Christophe Lyon via Gcc-patches wrote:
This patch adds support for trunc and extend operations between HF
mode (__fp16) and Decimal Floating Point formats (_Decimal32,
_Decimal64 and _Decimal128).
For simplicity we rely on the
On 5/10/22 11:30, Richard Sandiford wrote:
Richard Sandiford writes:
The patch changes the scalar handling in aapcs_vfp_sub_candidate,
but not the complex handling. Is that deliberate?
TIL: we don't support complex decimal floats. So never mind that :-)
Indeed. Sorry, maybe I should ha
While working on enabling DFP for AArch64, I noticed new failures in
gcc.dg/compat/struct-layout-1.exp (t028) which were not actually
caused by DFP types handling. These tests are generated during 'make
check' and enabling DFP made generation different (not sure if new
non-DFP tests are generated,
This patch updates the aarch64 backend as needed to support DFP modes
(SD, DD and TD).
2022-03-31 Christophe Lyon
gcc/
* config/aarch64/aarch64.cc
(aarch64_split_128bit_move): Handle DFP modes.
(aarch64_mode_valid_for_sched_fusion_p): Likewise.
(aarch64_
This patch adds support for trunc and extend operations between HF
mode (__fp16) and Decimal Floating Point formats (_Decimal32,
_Decimal64 and _Decimal128).
For simplicity we rely on the implicit conversions inserted by the
compiler between HF and SD/DF/TF modes. The existing bid*_to_binary*
and
These tests exercise exception handling with Decimal Floating-Point
type.
dfp-1.C and dfp-2.C check that thrown objects of such types are
properly caught, whether when using C++ classes (decimalXX) or via GCC
mode attributes.
dfp-saves-aarch64.C checks that such objects are properly restored,
and
These tests exercise exception handling with Decimal Floating-Point
type.
dfp-1.C and dfp-2.C check that thrown objects of such types are
properly caught, whether when using C++ classes (decimalXX) or via GCC
mode attributes.
dfp-saves-aarch64.C checks that such objects are properly restored,
and
This patch adds support for trunc and extend operations between HF
mode (__fp16) and Decimal Floating Point formats (_Decimal32,
_Decimal64 and _Decimal128).
For simplicity we rely on the implicit conversions inserted by the
compiler between HF and SD/DF/TF modes. The existing bid*_to_binary*
and
On 5/13/22 20:23, Joseph Myers wrote:
On Fri, 13 May 2022, Christophe Lyon via Gcc-patches wrote:
diff --git a/gcc/testsuite/gcc.target/aarch64/convert-dfp-2.c
b/gcc/testsuite/gcc.target/aarch64/convert-dfp-2.c
I still think the tests should run for x86 as well - that is, for any
target
On 5/13/22 18:35, Richard Sandiford wrote:
Christophe Lyon via Gcc-patches writes:
@@ -19352,7 +19363,9 @@ aarch64_legitimate_constant_p (machine_mode mode, rtx x)
{
/* Support CSE and rematerialization of common constants. */
if (CONST_INT_P (x)
- || (CONST_DOUBLE_P (x
This patch adds support for trunc and extend operations between HF
mode (_Float16) and Decimal Floating Point formats (_Decimal32,
_Decimal64 and _Decimal128).
For simplicity we rely on the implicit conversions inserted by the
compiler between HF and SD/DF/TF modes. The existing bid*_to_binary*
a
Hi Joseph,
May I ping you on this version? (I've moved the tests to gcc.dg/torture/
and checked they work on aarch64 and x86_64.
Thanks,
Christophe
On 5/16/22 15:47, Christophe Lyon wrote:
This patch adds support for trunc and extend operations between HF
mode (_Float16) and Decimal Floatin
On 5/19/22 21:35, Joseph Myers wrote:
On Thu, 19 May 2022, Christophe Lyon via Gcc-patches wrote:
Hi Joseph,
May I ping you on this version? (I've moved the tests to gcc.dg/torture/ and
checked they work on aarch64 and x86_64.
This version is OK, given a bug report filed in Bugzill
On Tue, 27 Oct 2020 at 17:22, Richard Earnshaw
wrote:
>
> On 28/09/2020 10:09, Christophe Lyon via Gcc-patches wrote:
> > With -mpure-code on v6m (thumb-1), we can use small offsets with
> > upper/lower relocations to avoid the extra addition of the
> > offset.
&g
Hi,
On Fri, 30 Oct 2020 at 13:49, Richard Earnshaw
wrote:
>
> On 29/10/2020 19:18, Richard Earnshaw via Gcc-patches wrote:
> > On 28/10/2020 18:10, Christophe Lyon via Gcc-patches wrote:
> >> On Wed, 28 Oct 2020 at 18:44, Richard Earnshaw
> >> wrote:
> >&
On Fri, 30 Oct 2020 at 20:11, Vladimir Makarov via Gcc-patches
wrote:
>
> The following patch implements taking insn scratch requirements into
> account in global RA (IRA). Before the patch IRA simply ignored insn
> scratches. Only LRA took the scratches into account and assigned hard
> regist
On Mon, 2 Nov 2020 at 19:43, Thomas Rodgers via Gcc-patches
wrote:
>
>
> Testsed x86_64-pc-linux-gnu, committed to master.
>
Hi,
I can see the new tests failing on bare-metal targets using newlib
(arm-eabi, aarch64-elf):
27_io/basic_syncbuf/1.cc (test for excess errors)
27_io/basic_syncb
Hi,
Add -mfloat-abi=soft and skip the tests if -mfloat-abi=hard is
supplied.
This avoids failures when testing with overridden flags such as
mthumb/-mcpu=cortex-m4/-mfloat-abi=hard
Pushed as obvious.
2020-11-04 Christophe Lyon
gcc/testsuite/
* gcc.target/arm/pure-code/no-lit
On Wed, 4 Nov 2020 at 11:54, Tobias Burnus wrote:
>
> Three of the testcases fail on PowerPC:
> gcc.target/i386/zero-scratch-regs-{9,10,11}.c
>powerpc64le-linux-gnu/default/gcc.d/zero-scratch-regs-10.c:77:1: sorry,
> unimplemented: '-fzero-call-used_regs' not supported on this target
>
> Did
On Tue, 3 Nov 2020 at 07:39, Kewen.Lin via Gcc-patches
wrote:
>
> Hi Richard,
>
> Thanks again for your review!
>
> on 2020/11/2 下午6:23, Richard Sandiford wrote:
> > "Kewen.Lin" writes:
> >> diff --git a/gcc/function.c b/gcc/function.c
> >> index 2c8fa217f1f..3e92ee9c665 100644
> >> --- a/gcc/fun
On Tue, 3 Nov 2020 at 11:27, Kyrylo Tkachov via Gcc-patches
wrote:
>
> Hi Andrea,
>
> > -Original Message-
> > From: Andrea Corallo
> > Sent: 26 October 2020 15:59
> > To: gcc-patches@gcc.gnu.org
> > Cc: Kyrylo Tkachov ; Richard Earnshaw
> > ; nd
> > Subject: [PATCH 1/x] arm: Add vld1_la
On Wed, 4 Nov 2020 at 14:29, Christophe Lyon wrote:
>
> On Tue, 3 Nov 2020 at 11:27, Kyrylo Tkachov via Gcc-patches
> wrote:
> >
> > Hi Andrea,
> >
> > > -Original Message-
> > > From: Andrea Corallo
> > > Sent: 26 October 2020 15:59
> > > To: gcc-patches@gcc.gnu.org
> > > Cc: Kyrylo Tka
:
> > >
> > > Hi Christophe,
> > >
> > > I've spotted two very minors.
> > >
> > > Christophe Lyon via Gcc-patches writes:
> > >
> > > [...]
> > >
> > > > +/* For vceqq_p64, we rely on vceq_p64 for each of the tw
On Mon, 2 Nov 2020 at 23:01, Vladimir Makarov wrote:
>
>
> On 2020-11-02 4:30 p.m., Vladimir Makarov via Gcc-patches wrote:
> >
> > On 2020-11-02 3:12 p.m., Christophe Lyon wrote:
> >>
> >> Hi,
> >>
> >> This patch causes ICEs on arm (eg arm-none-linux-gnueabi)
> >> gcc.c-torture/compile/sync
On Thu, 5 Nov 2020 at 10:36, Kyrylo Tkachov wrote:
>
> H, Christophe,
>
> > -Original Message-
> > From: Gcc-patches On Behalf Of
> > Christophe Lyon via Gcc-patches
> > Sent: 15 October 2020 18:23
> > To: gcc-patches@gcc.gnu.org
> > Subject
On Thu, 5 Nov 2020 at 12:11, Andrea Corallo wrote:
>
> Christophe Lyon writes:
>
> [...]
>
> >> I think you need to add -mfloat-abi=hard to the dg-additional-options
> >> otherwise vld1_lane_bf16_1.c
> >> fails on targets with a soft float-abi default (eg arm-linux-gnueabi).
> >>
> >> See bf16_vl
On Tue, 3 Nov 2020 at 12:17, Dennis Zhang via Gcc-patches
wrote:
>
> Hi Richard,
>
> On 10/30/20 2:07 PM, Richard Sandiford wrote:
> > Dennis Zhang writes:
> >> diff --git a/gcc/config/aarch64/aarch64-simd-builtins.def
> >> b/gcc/config/aarch64/aarch64-simd-builtins.def
> >> index 332a0b6b1ea..3
On Thu, 5 Nov 2020 at 15:30, Andrea Corallo wrote:
>
> Christophe Lyon writes:
>
> > On Thu, 5 Nov 2020 at 12:11, Andrea Corallo wrote:
> >>
> >> Christophe Lyon writes:
> >>
> >> [...]
> >>
> >> >> I think you need to add -mfloat-abi=hard to the dg-additional-options
> >> >> otherwise vld1_lan
On Thu, 5 Nov 2020 at 11:21, Tamar Christina via Gcc-patches
wrote:
>
> > -Original Message-
> > From: rguent...@c653.arch.suse.de On
> > Behalf Of Richard Biener
> > Sent: Thursday, November 5, 2020 10:17 AM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd ; o...@ucw.cz
> > S
On Fri, 6 Nov 2020 at 11:18, Tamar Christina wrote:
>
>
>
> > -Original Message-
> > From: Christophe Lyon
> > Sent: Friday, November 6, 2020 8:42 AM
> > To: Tamar Christina
> > Cc: Richard Biener ; nd ; gcc-
> > patc...@gcc.gnu.org; o...@ucw.cz
> > Subject: Re: [PATCH] SLP: Move load/st
On Fri, 6 Nov 2020 at 12:33, Tamar Christina wrote:
>
>
>
> > -Original Message-
> > From: Christophe Lyon
> > Sent: Friday, November 6, 2020 10:27 AM
> > To: Tamar Christina
> > Cc: Richard Biener ; nd ; gcc-
> > patc...@gcc.gnu.org; o...@ucw.cz
> > Subject: Re: [PATCH] SLP: Move load/s
On Wed, 4 Nov 2020 at 10:59, Richard Biener wrote:
>
> On Wed, 4 Nov 2020, Jakub Jelinek wrote:
>
> > Hi!
> >
> > The following patch generalizes the x ? 1 : 0 -> (int) x optimization
> > to handle also left shifts by constant.
> >
> > During x86_64-linux and i686-linux bootstraps + regtests it tr
On Thu, 5 Nov 2020 at 12:55, Christophe Lyon wrote:
>
> On Thu, 5 Nov 2020 at 10:36, Kyrylo Tkachov wrote:
> >
> > H, Christophe,
> >
> > > -Original Message-
> > > From: Gcc-patches On Behalf Of
> > > Christophe Lyon via Gcc-patc
Hi,
On Tue, 27 Oct 2020 at 11:22, Jan Hubicka wrote:
>
> Hi,
> this patch makes C++ new and delete operators to be handled as
> malloc/free for fnspec.
>
> I still do not understand why free is ".co " and not ".cO ".
> I do not think we need to invalidate memory referenced to by blockbeing
> free
On Fri, 6 Nov 2020 at 15:06, Andrea Corallo wrote:
>
> Christophe Lyon writes:
>
> > On Thu, 5 Nov 2020 at 15:30, Andrea Corallo wrote:
> >>
> >> Christophe Lyon writes:
> >>
> >> > On Thu, 5 Nov 2020 at 12:11, Andrea Corallo
> >> > wrote:
> >> >>
> >> >> Christophe Lyon writes:
> >> >>
> >>
On Sat, 7 Nov 2020 at 00:59, Jeff Law wrote:
>
>
> On 9/18/20 6:33 AM, Christophe Lyon wrote:
> > On Thu, 17 Sep 2020 at 23:33, Jeff Law wrote:
> >>
> >> On 9/14/20 3:29 AM, Christophe Lyon via Gcc-patches wrote:
> >>> Initializing orig_err
Hi,
On Thu, 5 Nov 2020 at 17:12, David Candler via Gcc-patches
wrote:
>
> Hi Richard,
>
> Thanks for the feedback.
>
> Richard Sandiford writes:
> > > diff --git a/gcc/config/aarch64/aarch64-builtins.c
> > > b/gcc/config/aarch64/aarch64-builtins.c
> > > index 4f33dd936c7..f93f4e29c89 100644
>
Hi,
On Fri, 23 Oct 2020 at 10:02, Dennis Zhang via Gcc-patches
wrote:
>
> Hi Kyrylo,
>
> >
> > From: Kyrylo Tkachov
> > Sent: Thursday, October 22, 2020 9:40 AM
> > To: Dennis Zhang; gcc-patches@gcc.gnu.org
> > Cc: nd; Richard Earnshaw; Ramana Radhakrish
Hi,
On Mon, 9 Nov 2020 at 15:43, Aldy Hernandez via Gcc-patches
wrote:
>
> [This is actually part of a larger patch that actually changes
> behavior, but I thought I'd commit the non-invasive cleanups first
> which will simplify the upcoming work.]
>
> irange::set was doing more work than it shou
On 31/08/2021 18:33, Roger Sayle wrote:
My apologies for the inconvenience. My recent patch to preserve
SUBREG_PROMOTED_VAR_P on (extend:HI (subreg/s:QI (reg:SI))), and other
places in the middle-end, has broken the build on several targets.
The change to convert_modes inadvertently used the
On Wed, Sep 1, 2021 at 7:09 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> On 30/08/2021 14:01, Sebastian Huber wrote:
> > Do not declare abort in "libgcc/unwind-arm-common.inc" since it is
> already
> > provided by "tsystem.h". It fixes the following build error:
> >
> > In fi
On Mon, Aug 30, 2021 at 8:27 AM Jakub Jelinek via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> On Wed, Aug 25, 2021 at 12:14:09PM +0200, Marcel Vollweiler wrote:
> > Add support for device-modifiers for 'omp target device'.
> >
> > 'device_num' and 'ancestor' are now parsed on target device con
On Tue, Aug 24, 2021 at 10:17 AM Kyrylo Tkachov
wrote:
>
>
> > -Original Message-
> > From: Prathamesh Kulkarni
> > Sent: 24 August 2021 09:01
> > To: Christophe Lyon
> > Cc: Kyrylo Tkachov ; gcc Patches > patc...@gcc.gnu.org>
> > Subject: Re: [ARM] PR66791: Replace builtins for vdup_n
Hi,
On Thu, Aug 19, 2021 at 7:29 PM Sandra Loosemore
wrote:
> On 7/27/21 5:07 AM, Tobias Burnus wrote:
> > Hi Sandra, hi Thomas, hi all,
> >
> > @Thomas K: Comments about the following - and of course to the
> > testsuite itself - are highly welcome.
> >
> > In my opinion, the testsuite LGTM and
On 03/09/2021 10:35, Prathamesh Kulkarni via Gcc-patches wrote:
On Thu, 2 Sept 2021 at 14:32, Christophe Lyon
wrote:
On Tue, Aug 24, 2021 at 10:17 AM Kyrylo Tkachov wrote:
-Original Message-
From: Prathamesh Kulkarni
Sent: 24 August 2021 09:01
To: Christophe Lyon
Cc: Kyrylo T
On Mon, Sep 6, 2021 at 7:21 AM Sandra Loosemore
wrote:
> 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 <
> san...@codesourcery.com> wrote:
>
ping?
On 26/08/2021 17:53, Christophe Lyon wrote:
g++.dg/eh/arm-vfp-unwind.C uses an asm statement relying on
double-precision FPU support, but does not make sure it is actually
supported by the target.
Check (__ARM_FP & 8) to ensure this.
2021-08-26 Christophe Lyon
gcc/testsuite/
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 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
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
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
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/
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
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
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
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
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
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
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 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/
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
On 07/09/2021 15:35, Richard Earnshaw wrote:
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
When running the testsuite under Windows, we noticed failures in
testcase which attempt to match compiler error messages containing the
name of the executable.
For instance, gcc.dg/analyzer/signal-4a.c tries to match 'cc1:' which
obviously fails when the executable is called cc1.exe.
This patch r
On 10/09/2021 00:49, Qing Zhao via Gcc-patches wrote:
Hi, FYI
I just committed the following patch to gcc upstream:
https://gcc.gnu.org/pipermail/gcc-cvs/2021-September/353195.html
Hi,
Several of the new tests fail on arm and aarch64 with -mabi=ilp32.
On arm:
gcc:gcc.dg/dg.exp=c-c++-com
ping?
On 06/09/2021 09:23, Christophe LYON wrote:
ping?
On 26/08/2021 17:53, Christophe Lyon wrote:
g++.dg/eh/arm-vfp-unwind.C uses an asm statement relying on
double-precision FPU support, but does not make sure it is actually
supported by the target.
Check (__ARM_FP & 8) to ensure this.
202
ping?
On 08/09/2021 10:49, Christophe Lyon wrote:
When running the testsuite under Windows, we noticed failures in
testcase which attempt to match compiler error messages containing the
name of the executable.
For instance, gcc.dg/analyzer/signal-4a.c tries to match 'cc1:' which
obviously fail
ping?
On 07/09/2021 11:15, Christophe Lyon wrote:
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
On Fri, Sep 10, 2021 at 6:32 PM Jeff Law via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
>
>
> On 9/10/2021 7:53 AM, Aldy Hernandez via Gcc-patches wrote:
> >
> >
> > On 9/10/21 3:16 PM, Michael Matz wrote:
> >> Hi,
> >>
> >> On Fri, 10 Sep 2021, Aldy Hernandez via Gcc-patches wrote:
> >>
> >>>
On Fri, Sep 10, 2021 at 8:47 PM Jakub Jelinek via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> Hi!
>
> This patch implements OpenMP 5.1 atomics (with clarifications from
> upcoming 5.2).
> The most important changes are that it is now possible to write (for C/C++,
> for Fortran it was possible
On Mon, Sep 13, 2021 at 4:40 PM Jakub Jelinek wrote:
> On Mon, Sep 13, 2021 at 01:57:52PM +0200, Christophe Lyon wrote:
> > > --- gcc/testsuite/c-c++-common/gomp/atomic-29.c.jj 2021-09-10
> > > 11:47:17.093164041 +0200
> > > +++ gcc/testsuite/c-c++-common/gomp/atomic-29.c 2021-09-10
> > > 11
On 10/09/2021 15:16, Jason Merrill via Gcc-patches wrote:
OK, time to finish this up. The main change relative to the last patch I sent
to the list is dropping the -finterference-tune flag and making that behavior
the default. Any more comments?
The last missing piece of the C++17 stan
On Wed, Sep 15, 2021 at 12:25 PM Richard Earnshaw via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
>
>
> On 14/09/2021 08:56, Christophe LYON via Gcc-patches wrote:
> >
> > On 10/09/2021 15:16, Jason Merrill via Gcc-patches wrote:
> >> OK, time to finish this
On 15/09/2021 13:02, Richard Earnshaw wrote:
On 26/08/2021 16:53, Christophe Lyon via Gcc-patches wrote:
g++.dg/eh/arm-vfp-unwind.C uses an asm statement relying on
double-precision FPU support, but does not make sure it is actually
supported by the target.
Check (__ARM_FP & 8) to en
On Wed, Sep 15, 2021 at 2:49 PM Richard Earnshaw via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
>
>
> On 15/09/2021 13:26, Christophe LYON via Gcc-patches wrote:
> >
> > On 15/09/2021 13:02, Richard Earnshaw wrote:
> >>
> >>
> >> On 2
On Wed, Sep 15, 2021 at 5:39 PM Jason Merrill via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> On Wed, Sep 15, 2021 at 11:37 AM Jeff Law wrote:
>
> >
> >
> > On 9/15/2021 9:31 AM, Jason Merrill via Gcc-patches wrote:
> > > Most any compilation on ARM/AArch64 was warning because the default L1
On 15/09/2021 18:43, Richard Earnshaw via Gcc-patches wrote:
On 15/09/2021 17:13, Christophe Lyon via Gcc-patches wrote:
On Wed, Sep 15, 2021 at 2:49 PM Richard Earnshaw via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
On 15/09/2021 13:26, Christophe LYON via Gcc-patches wrote:
On Thu, Sep 16, 2021 at 11:21 AM Richard Earnshaw via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
>
>
> On 16/09/2021 10:12, Christophe LYON via Gcc-patches wrote:
> >
> > On 15/09/2021 18:43, Richard Earnshaw via Gcc-patches wrote:
> >>
> >>
>
Ping?
On 13/09/2021 10:33, Christophe LYON via Gcc-patches wrote:
ping?
On 07/09/2021 11:15, Christophe Lyon wrote:
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
On 23/09/2021 13:15, Aldy Hernandez via Gcc-patches wrote:
My upcoming improvements to the forward jump threader make it thread
more aggressively. In investigating some "regressions", I noticed
that it has always allowed threading through empty latches and across
loop boundaries. As we have d
On 28/09/2021 13:12, Kyrylo Tkachov wrote:
-Original Message-
From: Gcc-patches On Behalf Of Christophe
Lyon via Gcc-patches
Sent: 07 September 2021 10:15
To: gcc-patches@gcc.gnu.org
Subject: [PATCH 02/13] arm: Add tests for PR target/100757
These tests currently trigger an ICE
On 28/09/2021 13:14, Kyrylo Tkachov wrote:
-Original Message-
From: Gcc-patches On Behalf Of Christophe
Lyon via Gcc-patches
Sent: 07 September 2021 10:15
To: gcc-patches@gcc.gnu.org
Subject: [PATCH 03/13] arm: Add test for PR target/101325
This test is derived from the one
On 28/09/2021 13:18, Kyrylo Tkachov wrote:
Hi Christophe,
-Original Message-
From: Gcc-patches On Behalf Of Christophe
LYON via Gcc-patches
Sent: 08 September 2021 08:49
To: Richard Earnshaw ; gcc-
patc...@gcc.gnu.org
Subject: Re: [PATCH 04/13] arm: Add GENERAL_AND_VPR_REGS regclass
On 29/09/2021 12:20, Kyrylo Tkachov via Gcc-patches wrote:
Hi all,
Similar to my previous patch for setmem this one does the same for the cpymem
expansion.
We count the number of ops emitted and compare it against the alternative of
just calling
the library function when optimising for size.
Hi Tamar,
On Fri, Oct 29, 2021 at 5:23 PM Richard Sandiford via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> Tamar Christina writes:
> > Hi All,
> >
> > Attached is a new version that fixes the previous SVE fallouts in a new
> way.
> >
> > Ok for master?
>
Looks like you forgot to try to b
The movi, dup and extract costing fields were recently added to struct
vector_cost_table, but there initialization is missing for the arm
(aarch32) specific descriptions.
Although the arm port does not use these fields (only aarch64 does),
this is causing warnings during the build, and even build
On Wed, Nov 10, 2021 at 1:54 PM Tamar Christina via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> Hi All,
>
> My previous patch missed these tuning structures in arm.c as they
> are not where the rest of the structure are located.
>
> This applies the same default values to silence initializatio
301 - 400 of 982 matches
Mail list logo
