dg-do must come before dg-skip-if, this patch fixes this oversight in
these two tests.
Committed as obvious.
2021-05-03 Christophe Lyon
gcc/testsuite/
* gcc.target/aarch64/advsimd-intrinsics/vmla_float_not_fused.c:
Fix dg directives order.
* gcc.target/aarch64/
On Tue, 4 May 2021 at 13:29, Andre Vieira (lists)
wrote:
>
> Hi Christophe,
>
> On 30/04/2021 15:09, Christophe Lyon via Gcc-patches wrote:
> > Since MVE has a different set of vector comparison operators from
> > Neon, we have to update the expansion to take into accou
nce I posted the patch series, I've noticed a regression in
armv8_2-fp16-arith-1.c, because we now vectorize all the float16x[48]_t loops,
but we lose the fact that some FP comparisons can throw exceptions.
I'll have to revisit this patch.
Thanks,
Christophe
> On 30/04/2021 15:09,
> Kind regards,
> Andre
>
> On 30/04/2021 15:09, Christophe Lyon via Gcc-patches wrote:
> > This patch enables MVE vld4/vst4 instructions for auto-vectorization.
> > We move the existing expanders from neon.md and enable them for MVE,
> > calling the respective emitter.
&g
an throw exceptions.
>
> I'll have to revisit this patch.
Actually it looks like my patch does the right thing: we now vectorize
appropriately, given that the testcase is compiled with -ffast-math.
I need to update the testcase, though.
>
> Thanks,
>
> Christophe
>
>
The new test gcc.c-torture/execute/ieee/cdivchkld.c needs fmaxl(),
which may not be available, for instance on aarch64-elf with newlib.
As discussed in the PR, requiring c99_runtime enables to skip the test
in this case.
2021-05-04 Christophe Lyon
PR testsuite/100355
gcc/testsu
On Tue, 4 May 2021 at 15:41, Christophe Lyon wrote:
>
> On Tue, 4 May 2021 at 13:29, Andre Vieira (lists)
> wrote:
> >
> > Hi Christophe,
> >
> > On 30/04/2021 15:09, Christophe Lyon via Gcc-patches wrote:
> > > Since MVE has a different set of vecto
> appropriately, given that the testcase is compiled with -ffast-math.
> I need to update the testcase, though.
>
Here is a new version, with armv8_2-fp16-arith-1.c updated to take
into account the new vectorization.
Christophe
> >
> > Thanks,
> >
> > Christoph
On Wed, 5 May 2021 at 19:39, Tamar Christina via Gcc-patches
wrote:
>
> Hi All,
>
> This adds optabs implementing usdot_prod.
>
> The following testcase:
>
> #define N 480
> #define SIGNEDNESS_1 unsigned
> #define SIGNEDNESS_2 signed
> #define SIGNEDNESS_3 signed
> #define SIGNEDNESS_4 unsigned
>
On Wed, 5 May 2021 at 09:56, Richard Biener wrote:
>
> This makes sure to follow SSA edges when folding eliminated stmts.
> This reaps the same benefit as forwprop folding all stmts, not
> waiting for one to produce copysign in the new testcase.
>
> Bootstrapped on x86_64-unknown-linux-gnu, testin
Ping for the series?
On Fri, 30 Apr 2021 at 16:09, Christophe Lyon
wrote:
>
> There is no need to have a signed and an unsigned version of these
> builtins. This is similar to what we do for Neon in arm_neon.h.
> This mechanical patch enables later cleanup patches.
>
> 2021-03-01 Christophe Lyon
Ping?
On Fri, 30 Apr 2021 at 16:06, Christophe Lyon
wrote:
>
> This patchs adds a test similar to mve-vsub_1.c, but operates on a
> scalar as second argument. For the moment we do not select the T2 vsub
> variant operating on a scalar final argument, and we use vadd of the
> opposite.
>
> 2021-04
Ping?
On Fri, 30 Apr 2021 at 16:06, Christophe Lyon
wrote:
>
> Support for vmul has been present for a while, but it was lacking a
> test for the scalar variant.
>
> This patch adds one, precisely noting that we do not yet use the T2
> variants of vmul, which take a scalar as final argument.
>
>
Ping?
On Fri, 30 Apr 2021 at 16:06, Christophe Lyon
wrote:
>
> This patch adds a test for the scalar mode of vadd, precisely noting
> that we do not yet use the T2 variants of vadd, which take a scalar as
> final argument.
>
> 2021-04-22 Christophe Lyon
>
> gcc/testsuite/
> * g
Ping?
On Tue, 27 Apr 2021 at 13:32, Christophe Lyon
wrote:
>
> Support for vadd has been present for a while, but it was lacking a
> test.
>
> 2021-04-22 Christophe Lyon
>
> gcc/testsuite/
> * gcc.target/arm/simd/mve-vadd-1.c: New.
> ---
> gcc/testsuite/gcc.target/arm/simd/mve
Ping?
On Tue, 27 Apr 2021 at 13:32, Christophe Lyon
wrote:
>
> Use a template macro to factorize the existing test functions.
>
> This patch also adds a version to check subtraction with __fp16 type.
>
> 2021-04-26 Christophe Lyon
>
> gcc/testsuite/
> * gcc.target/arm/simd/mve-
Ping?
On Tue, 27 Apr 2021 at 13:32, Christophe Lyon
wrote:
>
> Vector right shifts by immediate use vshr, while right shifts by
> vectors instead use vneg and vshl.
>
> This patch adds the corresponding scan-assembler-times that were
> missing.
>
> 2021-04-22 Christophe Lyon
>
> gcc/te
On Mon, 10 May 2021 at 13:50, Kyrylo Tkachov wrote:
>
>
>
> > -Original Message-
> > From: Gcc-patches On Behalf Of
> > Christophe Lyon via Gcc-patches
> > Sent: 30 April 2021 15:06
> > To: gcc-patches@gcc.gnu.org
> > Subject: [PATCH
On Mon, 10 May 2021 at 18:32, Richard Earnshaw
wrote:
>
>
>
> On 22/04/2021 08:01, Christophe Lyon via Gcc-patches wrote:
> > arm.h has had this error message since 1997, and was never updated to
> > take softfp into account. Anyway, it seems it was useful long ago, but
&g
arm.h has had this error message since 1997, but it is no longer
needed since option parsing has been improved: -mXXX-endian is handled
via arm.opt and updates the BIG_END mask. So, the last
instance of -mXXX-endian on the command line wins.
Tested on many arm* configurations, with no impact on th
On Wed, 12 May 2021 at 10:24, Richard Biener wrote:
>
> On Wed, 12 May 2021, Bernd Edlinger wrote:
>
> > Hi,
> >
> > this fixes another regression from my previous patch.
> >
> >
> > Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> > Is it OK for trunk?
>
> OK.
>
> Richard.
>
Hi,
As the new
ping?
On Fri, 30 Apr 2021 at 16:22, Christophe Lyon
wrote:
>
> ping?
>
> On Wed, 21 Apr 2021 at 22:48, Christophe Lyon
> wrote:
> >
> > The acle/saturation.c test uses __[su]sat() and
> > __saturation_occurred() intrinsics but __[su]sat() are defined in
> > acle.h if __ARM_FEATURE_SAT true, whil
ping?
On Mon, 10 May 2021 at 13:22, Christophe Lyon
wrote:
>
> Ping?
>
> On Tue, 27 Apr 2021 at 13:32, Christophe Lyon
> wrote:
> >
> > Vector right shifts by immediate use vshr, while right shifts by
> > vectors instead use vneg and vshl.
> >
> > This patch adds the corresponding scan-assembler
ping?
On Mon, 10 May 2021 at 13:22, Christophe Lyon
wrote:
>
> Ping?
>
> On Tue, 27 Apr 2021 at 13:32, Christophe Lyon
> wrote:
> >
> > Use a template macro to factorize the existing test functions.
> >
> > This patch also adds a version to check subtraction with __fp16 type.
> >
> > 2021-04-26
ping?
On Mon, 10 May 2021 at 13:22, Christophe Lyon
wrote:
>
> Ping?
>
> On Tue, 27 Apr 2021 at 13:32, Christophe Lyon
> wrote:
> >
> > Support for vadd has been present for a while, but it was lacking a
> > test.
> >
> > 2021-04-22 Christophe Lyon
> >
> > gcc/testsuite/
> > *
ping?
On Mon, 10 May 2021 at 13:22, Christophe Lyon
wrote:
>
> Ping?
>
> On Fri, 30 Apr 2021 at 16:06, Christophe Lyon
> wrote:
> >
> > This patch adds a test for the scalar mode of vadd, precisely noting
> > that we do not yet use the T2 variants of vadd, which take a scalar as
> > final argume
ping?
On Wed, 5 May 2021 at 16:08, Christophe Lyon wrote:
>
> On Tue, 4 May 2021 at 15:41, Christophe Lyon
> wrote:
> >
> > On Tue, 4 May 2021 at 13:29, Andre Vieira (lists)
> > wrote:
> > >
> > > Hi Christophe,
> > >
> >
ough.
> >
>
> Here is a new version, with armv8_2-fp16-arith-1.c updated to take
> into account the new vectorization.
>
> Christophe
>
>
> > >
> > > Thanks,
> > >
> > > Christophe
> > >
> > > > On 30/04/2021 15:09,
ping?
On Fri, 30 Apr 2021 at 16:09, Christophe Lyon
wrote:
>
> This patch enables MVE vld2/vst2 instructions for auto-vectorization.
> We move the existing expanders from neon.md and enable them for MVE,
> calling the respective emitter.
>
> 2021-03-12 Christophe Lyon
>
> gcc/
>
ly did code-review, did not try to build/run tests.
> >
>
> Hi Andre,
>
> Thanks for the comments!
>
> > Kind regards,
> > Andre
> >
> > On 30/04/2021 15:09, Christophe Lyon via Gcc-patches wrote:
> > > This patch enables MVE vld4/vst4 instruct
On Mon, 17 May 2021 at 12:35, Kyrylo Tkachov wrote:
>
>
>
> > -Original Message-
> > From: Gcc-patches On Behalf Of
> > Christophe Lyon via Gcc-patches
> > Sent: 05 May 2021 15:08
> > To: Andre Simoes Dias Vieira
> > Cc: gcc Patches
> &g
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,
While looking at PR 105549, which is about fixing the ABI break
introduced in GCC 9.1 in parameter alignment with bit-fields, we
noticed that the GCC 9.1 warning is not emitted in all the cases where
it should be. This patch fixes that and the next patch in the series
fixes the GCC 9.1 break.
We
On 1/12/23 14:19, Richard Sandiford wrote:
Christophe Lyon writes:
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 DF
On 1/12/23 14:03, Richard Sandiford wrote:
Christophe Lyon writes:
While looking at PR 105549, which is about fixing the ABI break
introduced in GCC 9.1 in parameter alignment with bit-fields, we
noticed that the GCC 9.1 warning is not emitted in all the cases where
it should be. This patch
Hi!
On 1/13/23 16:38, Jakub Jelinek wrote:
On Wed, Jan 11, 2023 at 03:18:06PM +0100, Christophe Lyon via Gcc-patches wrote:
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
Hi Jakub,
On 1/15/23 17:54, Christophe Lyon via Gcc-patches wrote:
Hi!
On 1/13/23 16:38, Jakub Jelinek wrote:
On Wed, Jan 11, 2023 at 03:18:06PM +0100, Christophe Lyon via
Gcc-patches wrote:
While working on enabling DFP for AArch64, I noticed new failures in
gcc.dg/compat/struct-layout-1
On 1/17/23 13:48, Jakub Jelinek wrote:
On Tue, Jan 17, 2023 at 01:43:35PM +0100, Christophe Lyon wrote:
As a follow-up to this, I ran the full testsuite with -fstack-protector-all
and this results in lots of failures (~65000 in gcc.sum alone).
I guess that is way too much.
Since you also
As discussed in the PR, these recently added tests fail when the
testsuite is executed with -fstack-protector-strong. To avoid this,
this patch adds -fno-stack-protector to dg-options.
PR target/108411
gcc/testsuite
* g++.target/aarch64/bitfield-abi-warning-align16-O2-extr
The previous patch added an assert which should not be applied to PST
types (Pure Scalable Types) because alignment does not matter in this
case. This patch moves the assert after the PST case is handled to
avoid the ICE.
PR target/108411
gcc/
* config/aarch64/aarch64.cc (
On 1/19/23 10:22, Richard Sandiford wrote:
Christophe Lyon writes:
The previous patch added an assert which should not be applied to PST
types (Pure Scalable Types) because alignment does not matter in this
case. This patch moves the assert after the PST case is handled to
avoid the ICE.
On Tue, 29 Aug 2023 at 08:06, Prathamesh Kulkarni <
prathamesh.kulka...@linaro.org> wrote:
> On Tue, 15 Aug 2023 at 00:05, Christophe Lyon via Gcc-patches
> wrote:
> >
> > Although they look like aliases for u8 and u16, we need to define them
> > so that we can h
As discussed in PR104167 (comments #8 and below), and PR111238, using
-Wl,-gc-sections in the libstdc++ testsuite for arm-eabi
(cross-toolchain) avoids link failures for a few tests:
27_io/filesystem/path/108636.cc
std/time/clock/gps/1.cc
std/time/clock/gps/io.cc
std/time/clock/tai/1.cc
std/time/c
On Thu, 31 Aug 2023 at 21:43, Jonathan Wakely wrote:
> On Thu, 31 Aug 2023 at 18:42, Jonathan Wakely wrote:
> >
> > On Thu, 31 Aug 2023 at 16:26, Christophe Lyon
> > wrote:
> > >
> > > As discussed in PR104167 (comments #8 and below), and PR111238, using
> > > -Wl,-gc-sections in the libstdc++
Hi Benjanmin,
On Fri, 1 Sept 2023 at 17:45, David Malcolm via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> On Fri, 2023-09-01 at 16:48 +0200, Benjamin Priour wrote:
> > Patch has been updated as per your suggestions and successfully
> > regstrapped
> > on x86_64-linux-gnu.
> >
The new testc
Tests under gcc.dg/vect use check_vect_support_and_set_flags to set
compilation flags as appropriate for the target, but they also set
dg-do-what-default to 'run' or 'compile', depending on the actual
target hardware (or simulator) capabilities.
For instance on arm, we use options to enable Neon,
Hi!
On Tue, 5 Sept 2023 at 16:38, Tobias Burnus wrote:
> That's based on the fail
> https://gcc.gnu.org/pipermail/gccadmin/2023q3/020349.html
> and on the discussion on IRC.
>
Sorry I didn't notice the problem, nor the discussion on IRC, but I can see
that my commits created the problem, sorry
On Thu, 7 Sept 2023 at 11:45, Jakub Jelinek wrote:
> On Thu, Sep 07, 2023 at 10:20:19AM +0200, Christophe Lyon via Gcc-patches
> wrote:
> > On Tue, 5 Sept 2023 at 16:38, Tobias Burnus
> wrote:
> >
> > > That's based on the fail
> > > https://gcc.g
The test was declaring 'int *carry;' and wrote to '*carry' without
initializing 'carry' first, leading to an attempt to write at address
zero, and a crash.
Fix by declaring 'int carry;' and passing '&carrry' instead of 'carry'
as parameter.
2023-09-08 Christophe Lyon
gcc/testsuite/
Some targets like arm-eabi with newlib and default settings rely on
__sync_synchronize() to ensure synchronization. Newlib does not
implement it by default, to make users aware they have to take special
care.
This makes a few tests fail to link.
This patch adds a new thread_fence effective targe
Some targets like arm-eabi with newlib and default settings rely on
__sync_synchronize() to ensure synchronization. Newlib does not
implement it by default, to make users aware they have to take special
care.
This makes a few tests fail to link.
This patch requires the missing thread-fence effec
On Mon, 11 Sept 2023 at 12:59, Jonathan Wakely wrote:
> On Sun, 10 Sept 2023 at 20:31, Christophe Lyon
> wrote:
> >
> > Some targets like arm-eabi with newlib and default settings rely on
> > __sync_synchronize() to ensure synchronization. Newlib does not
> > implement it by default, to make us
On Mon, 11 Sept 2023 at 15:12, Jonathan Wakely wrote:
> On Mon, 11 Sept 2023 at 13:36, Christophe Lyon
> wrote:
> >
> >
> >
> > On Mon, 11 Sept 2023 at 12:59, Jonathan Wakely
> wrote:
> >>
> >> On Sun, 10 Sept 2023 at 20:31, Christophe Lyon
> >> wrote:
> >> >
> >> > Some targets like arm-eabi
Hi!
On Wed, 6 Sept 2023 at 22:22, David Malcolm via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> On Wed, 2023-09-06 at 15:50 +0200, Benjamin Priour wrote:
> > Hi David,
> > Thanks for the review.
> >
> >
> >
> > On Tue, Sep 5, 2023 at 1:53 PM David Malcolm
> > wrote:
> >
> > > On Mon, 2023-0
On Mon, 11 Sept 2023 at 17:22, Jonathan Wakely wrote:
> On Mon, 11 Sept 2023 at 14:57, Christophe Lyon
> wrote:
> >
> >
> >
> > On Mon, 11 Sept 2023 at 15:12, Jonathan Wakely
> wrote:
> >>
> >> On Mon, 11 Sept 2023 at 13:36, Christophe Lyon
> >> wrote:
> >> >
> >> >
> >> >
> >> > On Mon, 11 Se
On Mon, 11 Sept 2023 at 18:11, Jonathan Wakely wrote:
> On Mon, 11 Sept 2023 at 16:40, Christophe Lyon
> wrote:
> >
> >
> >
> > On Mon, 11 Sept 2023 at 17:22, Jonathan Wakely
> wrote:
> >>
> >> On Mon, 11 Sept 2023 at 14:57, Christophe Lyon
> >> wrote:
> >> >
> >> >
> >> >
> >> > On Mon, 11 Se
Hi!
On Thu, 7 Sept 2023 at 11:30, Richard Sandiford via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> When I tried to use config-list.mk, the build for every triple except
> the build machine's failed for m2. This is because, unlike other
> languages, m2 builds target objects during all-gcc.
On Tue, 12 Sept 2023 at 11:07, Jonathan Wakely wrote:
> On Tue, 12 Sept 2023 at 08:59, Christophe Lyon
> wrote:
> >
> >
> >
> > On Mon, 11 Sept 2023 at 18:11, Jonathan Wakely
> wrote:
> >>
> >> On Mon, 11 Sept 2023 at 16:40, Christophe Lyon
> >> wrote:
> >> >
> >> >
> >> >
> >> > On Mon, 11 Se
Hi,
On Wed, 13 Sept 2023 at 14:32, Jonathan Wakely wrote:
> Tested x86_64-linux and aarch64-linux. I intend to push this to trunk.
>
> -- >8 --
>
> These atomics cause linker errors on arm4t where __sync_synchronize is
> not defined. For single-threaded targets we don't need the atomics.
>
>
I
On Thu, 14 Sept 2023 at 10:17, Jonathan Wakely wrote:
> On Thu, 14 Sept 2023 at 08:44, Christophe Lyon
> wrote:
> >
> > Hi,
> >
> >
> > On Wed, 13 Sept 2023 at 14:32, Jonathan Wakely
> wrote:
> >>
> >> Tested x86_64-linux and aarch64-linux. I intend to push this to trunk.
> >>
> >> -- >8 --
> >
Some targets like arm-eabi with newlib and default settings rely on
__sync_synchronize() to ensure synchronization. Newlib does not
implement it by default, to make users aware they have to take special
care.
This makes a few tests fail to link.
This patch requires the missing thread-fence effec
On Thu, 14 Sept 2023 at 11:06, Jonathan Wakely wrote:
> On Thu, 14 Sept 2023 at 09:41, Christophe Lyon
> wrote:
> >
> >
> >
> > On Thu, 14 Sept 2023 at 10:17, Jonathan Wakely
> wrote:
> >>
> >> On Thu, 14 Sept 2023 at 08:44, Christophe Lyon
> >> wrote:
> >> >
> >> > Hi,
> >> >
> >> >
> >> > On
ping?
On Fri, 8 Sept 2023 at 10:43, Christophe Lyon
wrote:
> The test was declaring 'int *carry;' and wrote to '*carry' without
> initializing 'carry' first, leading to an attempt to write at address
> zero, and a crash.
>
> Fix by declaring 'int carry;' and passing '&carrry' instead of 'carry'
On Wed, 5 Aug 2020 at 16:33, Richard Sandiford
wrote:
>
> The stack_protect_test patterns were leaving the canary value in the
> temporary register, meaning that it was often still in registers on
> return from the function. An attacker might therefore have been
> able to use it to defeat stack-s
On Mon, 10 Aug 2020 at 17:27, Richard Sandiford
wrote:
>
> Christophe Lyon writes:
> > On Wed, 5 Aug 2020 at 16:33, Richard Sandiford
> > wrote:
> >>
> >> The stack_protect_test patterns were leaving the canary value in the
> >> temporary register, meaning that it was often still in registers on
This patch fixes an incorrect parameter passing for $gcc_opts, which
produces a DejaGnu error: (DejaGnu) proc "gcc_opts" does not exist.
2020-08-11 Christophe Lyon
gcc/testsuite/
* gcc.target/arm/multilib.exp: Fix parameter passing for gcc_opts.
diff --git a/gcc/testsuite/gcc.
Hi James,
On Wed, 12 Aug 2020 at 10:40, James Greenhalgh wrote:
>
>
> Hi,
>
> As subject, this patch rewrites the mla intrinsics to use a + b * c rather
> than inline assembler, thereby opening them to CSE, scheduling, etc.
>
> Bootstrapped and tested on aarch64-none-linux-gnu.
>
Do we have test
On Tue, 11 Aug 2020 at 18:40, Richard Sandiford
wrote:
>
> Christophe Lyon via Gcc-patches writes:
> > This patch fixes an incorrect parameter passing for $gcc_opts, which
> > produces a DejaGnu error: (DejaGnu) proc "gcc_opts" does not exist.
>
> Huh, wonder h
On Tue, 11 Aug 2020 at 18:42, Richard Sandiford
wrote:
>
> Christophe Lyon writes:
> > On Mon, 10 Aug 2020 at 17:27, Richard Sandiford
> > wrote:
> >>
> >> Christophe Lyon writes:
> >> > On Wed, 5 Aug 2020 at 16:33, Richard Sandiford
> >> > wrote:
> >> >>
> >> >> The stack_protect_test pattern
Hi,
On Thu, 13 Aug 2020 at 03:54, qiaopeixin wrote:
>
> Thanks for the review and commit.
>
> All the best,
> Peixin
>
> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: 2020年8月13日 0:25
> To: qiaopeixin
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re:
Hi,
On Thu, 6 Aug 2020 at 16:39, Richard Biener wrote:
>
> On Thu, 6 Aug 2020, Jan Hubicka wrote:
>
> > Hello,
> > as discussed some time ago, I would like to discuss possibility to
> > backport the straming and enum improvements. The motivation is that
> > this brings quite noticeable improveme
Hi David,
On Thu, 13 Aug 2020 at 22:58, David Malcolm via Gcc-patches
wrote:
>
> This large patch reimplements how the analyzer tracks regions and
> values.
>
> Elimination of region_id and svalue_id
> **
>
> The patch eliminates region_id and svalue_id in fav
On Fri, 14 Aug 2020 at 11:21, Jan Hubicka wrote:
>
> > Hi,
> > >
> > > Since this was backported as
> > > r10-8623-g0d96c3424bbb5e5f994b78c8f65d8704d215be54,
> >
> > Yes, after discussion with Jakub on IRC.
> > > I've noticed ICEs on arm and aarch64:
> > > gcc.dg/pr34457-1.c (internal compile
On Sat, 15 Aug 2020 at 00:52, David Malcolm wrote:
>
> PR testsuite/96609 and PR analyzer/96616 report various testsuite
> failures seen on powerpc64, aarch64, and arm in new tests added by
> r11-2694-g808f4dfeb3a95f50f15e71148e5c1067f90a126d.
>
> Some of these failures (in gcc.dg/analyzer/init.c,
Hi Martin,
On Sat, 15 Aug 2020 at 01:14, Martin Sebor via Gcc-patches
wrote:
>
> On 8/13/20 11:44 AM, Martin Sebor wrote:
> > On 8/13/20 10:21 AM, Jeff Law wrote:
> >> On Fri, 2020-07-31 at 17:55 -0600, Martin Sebor via Gcc-patches wrote:
> >>> The folders for these functions (and some others) c
On Tue, 18 Aug 2020 at 05:38, qiaopeixin wrote:
>
> Hi Richard,
>
> Thanks for the review and explanation.
>
> The previous fix adding if condition of TARGET_FLOAT does crash glibc-2.29.
>
> I checked the past log of writing the function aarch64_init_cumulative_args,
> and did not find the reason
armv8-m.base (cortex-m23) has the movt instruction, so we need to
disable the define_split to generate a constant in this case,
otherwise we get incorrect insn constraints as described in PR94538.
We also need to fix the pure-code alternative for thumb1_movsi_insn
because the assembler complains w
FDPIC it uses PIC code, which is incompatible with -mpure-code, so we
want to skip these tests for arm*-*-uclinuxfdpiceabi.
This patch also fixes a typo where the final closing bracket was
commented out.
Committed as obvious.
2020-08-20 Christophe Lyon
gcc/testsuite/
* gcc.ta
There is no reason to check for arm32 when checking for
-mfloat=abi-soft support. Instead this implies skipping some tests
when targetting a thumb-1 cpu, while they pass.
This patch removes the arm32 check, and uses the same skeleton as
arm_softfp_ok and arm_hard_ok.
Committed as obvious.
2020-0
On Sat, 22 Aug 2020 at 00:44, Ramana Radhakrishnan
wrote:
>
> On Wed, Aug 19, 2020 at 10:32 AM Christophe Lyon via Gcc-patches
> wrote:
> >
> > armv8-m.base (cortex-m23) has the movt instruction, so we need to
> > disable the define_split to generate a constant in this
On Mon, 24 Aug 2020 at 11:09, Christophe Lyon
wrote:
>
> On Sat, 22 Aug 2020 at 00:44, Ramana Radhakrishnan
> wrote:
> >
> > On Wed, Aug 19, 2020 at 10:32 AM Christophe Lyon via Gcc-patches
> > wrote:
> > >
> > > armv8-m.base (cortex-m23) has the
> > > wrote:
> > > >
> > > > On Wed, Aug 19, 2020 at 10:32 AM Christophe Lyon via Gcc-patches
> > > > wrote:
> > > > >
> > > > > armv8-m.base (cortex-m23) has the movt instruction, so we need to
> > > > > disa
In comment 14 from PR94538, it was suggested to switch off jump tables
on thumb-1 cores when using -mpure-code, like we already do for thumb-2.
This is what this patch does, and also restores the previous value of
CASE_VECTOR_PC_RELATIVE since it was not the right way of handling
this.
It also ad
Hi,
On Thu, 27 Aug 2020 at 10:04, Richard Biener wrote:
>
> This makes sure to put special-ops expanded rhs left where
> expression rewrite expects it.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
>
> 2020-08-27 Richard Biener
>
> PR tree-optimization/96579
>
Hi Alex,
On Wed, 26 Aug 2020 at 17:15, Alex Coplan wrote:
>
> Thanks for the review, both.
>
> On 26/08/2020 09:19, Vladimir Makarov wrote:
> >
> > On 2020-08-26 5:06 a.m., Richard Sandiford wrote:
> > > Alex Coplan writes:
> > >
> > > Minor nit, should be formatted as:
> > >
> > > static rtx
>
Hi,
On Thu, 27 Aug 2020 at 13:07, Richard Biener wrote:
>
> The following streamlines TARGET_MEM_REF dumping building
> on what we do for MEM_REF and thus dumping things like
> access type, TBAA type and base/clique. I've changed it
> to do semantic dumping aka base + offset + step * index
> ra
On Fri, 28 Aug 2020 at 14:00, Richard Earnshaw
wrote:
>
> On 27/08/2020 14:27, Christophe Lyon via Gcc-patches wrote:
> > In comment 14 from PR94538, it was suggested to switch off jump tables
> > on thumb-1 cores when using -mpure-code, like we already do for thumb-2.
> &g
On Fri, 28 Aug 2020 at 16:27, Richard Earnshaw
wrote:
>
> On 28/08/2020 14:24, Christophe Lyon via Gcc-patches wrote:
> > On Fri, 28 Aug 2020 at 14:00, Richard Earnshaw
> > wrote:
> >>
> >> On 27/08/2020 14:27, Christophe Lyon via Gcc-patches wrote:
>
Hi,
On Wed, 26 Aug 2020 at 22:36, Jeff Law via Gcc-patches
wrote:
>
> On Tue, 2020-06-23 at 20:05 -0600, Martin Sebor wrote:
> > -Wstringop-overflow is issued for both writing and reading past
> > the end, even though the latter problem is often viewed as being
> > lower severity than the former,
On Mon, 31 Aug 2020 at 23:50, Martin Sebor wrote:
>
> On 8/31/20 4:51 AM, Christophe Lyon wrote:
> > Hi,
> >
> ...
> >
> > I pushed a small aarch64 patch as obvious:
> > 2020-08-31 Christophe Lyon
> >
> > gcc/testsuite/
> > * gcc.target/aarch64/strcmpopt_6.c: Suppress -Ws
On Wed, 2 Sep 2020 at 00:12, Martin Sebor via Gcc-patches
wrote:
>
> ILP32 failures in a test added for the new -Wstringop-overread
> option exposed an unnecessarily restrictive handling of offsets
> in ranges with an upper bound that's apparently less than
> the lower bound. I have relaxed the h
This patch moves the move-immediate splitter after the regular ones so
that it has lower precedence, and updates its constraints.
For
int f3 (void) { return 0x1100; }
int f3_2 (void) { return 0x12345678; }
we now generate:
* with -O2 -mcpu=cortex-m0 -mpure-code:
f3:
movsr0, #136
Since r204778 (g571880a0a4c512195aa7d41929ba6795190887b2), we favor
branches over IT blocks on Cortex-M. As a result, instead of
generating two nested IT blocks in thumb2-cond-cmp-[1234].c, we
generate either a single IT block, or use branches depending on
conditions tested by the program.
Since t
On Mon, 17 Aug 2020 at 11:00, Alex Coplan wrote:
>
> Hello,
>
> Given the following C function:
>
> double *f(double *p, unsigned x)
> {
> return p + x;
> }
>
> prior to this patch, GCC at -O2 would generate:
>
> f:
> add x0, x0, x1, uxtw 3
> ret
>
> but this add instructio
Hi Richard,
On Fri, 4 Sep 2020 at 15:42, Richard Biener wrote:
>
> The following adds the capability to code-generate live lanes in
> basic-block vectorization using lane extracts from vector stmts
> rather than keeping the original scalar code around for those.
> This eventually makes previously
On Tue, 8 Sep 2020 at 14:15, Richard Biener wrote:
>
> On Tue, 8 Sep 2020, Christophe Lyon wrote:
>
> > Hi Richard,
> >
> > On Fri, 4 Sep 2020 at 15:42, Richard Biener wrote:
> > >
> > > The following adds the capability to code-generate live lanes in
> > > basic-block vectorization using lane ex
On Tue, 8 Sep 2020 at 10:45, Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> As mentioned in the PR, the testcase fails to link, because when set_cfun is
> being called on the crc function, arm_override_options_after_change is
> called from set_cfun -> invoke_set_current_function_hook:
> /*
pz_tmp_base and pz_tmp_dot are always set, but used only when
_PC_NAME_MAX is defined.
This patch moves their declaration and definition undef #ifdef
_PC_NAME_MAX to avoid this warning.
2020-09-11 Torbjörn SVENSSON
Christophe Lyon
fixincludes/
* fixfixes.c (pz_tmp_ba
This patch adds the missing prototypes for the fonctions defined in fp16.c, to
avoid these warnings during the build:
/libgcc/config/arm/fp16.c:169:1: warning: no previous prototype for
'__gnu_h2f_internal' [-Wmissing-prototypes]
/libgcc/config/arm/fp16.c:194:1: warning: no previous prototype for
When building with -fno-exceptions, __GLIBCXX_THROW_OR_ABORT expands to
abort(), causing warnings:
unused parameter '__ecode'
unused parameter '__what'
This patch adds __attribute__((unused)) to avoid them.
2020-09-11 Torbjörn SVENSSON
Christophe Lyon
libstdc++-v3/
*
501 - 600 of 982 matches
Mail list logo
