on this series as it was not
immediately clear what the first comment implied...
Thanks
Christophe
> On 11/07/2024 22:42, Christophe Lyon wrote:
> > Add a comment about the lack of "n" forms for floating-point nor 8-bit
> > integers, to make it clearer why we use build_1
On Fri, 2 Aug 2024 at 18:14, Andre Vieira (lists)
wrote:
>
> Hi,
>
> This looks great to me, only one small suggestion, but take it or leave
> it I think it's a matter of preference.
>
> On 11/07/2024 22:42, Christophe Lyon wrote:
>
> > + /* No predica
As discussed in the PR, aclocal.m4 and configure were incorrectly
regenerated at some point.
2024-04-17 Christophe Lyon
PR preprocessor/114748
libcpp/
* aclocal.m4: Regenerate.
* configure: Regenerate.
---
libcpp/aclocal.m4 | 1 +
libcpp/configure | 3 +++
2
On Thu, 18 Apr 2024 at 09:37, Jakub Jelinek wrote:
>
> Hi!
>
> The following testcase aborts on aarch64-linux but does not on x86_64-linux.
> In both cases there is UB in the __divmodbitint4 implemenetation.
> When the divisor is negative with most significant limb (even when partial)
> all ones,
using maintainer-mode, but this is not
covered by this script.
2024-04-19 Christophe Lyon
contrib/
* autogen.py: New script.
---
contrib/autoregen.py | 221 +++
1 file changed, 221 insertions(+)
create mode 100755 contrib/autoregen.py
On Fri, 19 Apr 2024 at 11:03, Christophe Lyon
wrote:
>
> This script is a copy of the current script used by Sourceware's
> autoregen buildbots.
>
> It is intended as a helper to regenerate files managed by autotools
> (autoconf, automake, aclocal, ), as well as the
Hi Patrick,
On Sat, 13 Apr 2024 at 22:12, Patrick Palka wrote:
>
> Pushed as obvious after verifying C++11 bootstrap is restored.
I guess this also fixes the bootstrap_ubsan breakage on aarch64
reported by Linaro CI?
See https://linaro.atlassian.net/browse/GNU-1199
(I think you also received a n
On Thu, 25 Apr 2024 at 17:44, Carlos O'Donell wrote:
>
> Discussion is here:
> https://inbox.sourceware.org/gcc/CAPS5khZeWkAD=v8ka9g5eecdnk3bdhfnzjumpvc+hedmkvj...@mail.gmail.com/
>
> Rough consensus from Jakub Jelinek, Richard Biener and others is
> that maintainers are for the change.
>
> This c
On Fri, 26 Apr 2024 at 10:25, Christophe Lyon
wrote:
>
> On Thu, 25 Apr 2024 at 17:44, Carlos O'Donell wrote:
> >
> > Discussion is here:
> > https://inbox.sourceware.org/gcc/CAPS5khZeWkAD=v8ka9g5eecdnk3bdhfnzjumpvc+hedmkvj...@mail.gmail.com/
> >
> > Ro
In this PR, we have to handle a case where MVE predicates are supplied
as a const_int, where individual predicates have illegal boolean
values (such as 0xc for a 4-bit boolean predicate). To avoid the ICE,
we canonicalize them, replacing a non-null value with -1.
2024-04-26 Christophe Lyon
commits we send, as soon as
> trunk reopens fully for 15.1.
>
Thanks!
Note that I already pushed the patch as r14-9865-g73fb0a6153f478
so you may have conflicts (easy to fix ;-) )
Christophe
> Best,
>
> Arthur
>
> On 4/4/24 18:27, Christophe Lyon wrote:
> > rust has the
On Mon, 29 Apr 2024 at 15:29, Jakub Jelinek wrote:
>
> On Fri, Apr 26, 2024 at 11:10:12PM +, Christophe Lyon wrote:
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/arm/mve/pr114801.c
> > @@ -0,0 +1,36 @@
> > +/* { dg-do compile } */
> > +/* { dg-requi
On Tue, 30 Apr 2024 at 04:01, Simon Marchi wrote:
>
> I get a diff when running "autoreconf" in this directory. I think that
> the current state is erroneous: it appears to have been generated using
>
> aclocal -I ../config -I ..
>
> even though configure.ac and Makefile.am list the include f
On Tue, 30 Apr 2024 at 04:25, Simon Marchi wrote:
>
> Add an "AC_CONFIG_MACRO_DIRS" call in configure.ac, with the same
> directories as specified in "ACLOCAL_AMFLAGS", in Makefile.in.
>
> This makes it possible to re-generate aclocal.m4 using "autoreconf".
Thanks, this LGTM, although like in you
Hi Alexandre,
On Tue, 30 Apr 2024 at 01:31, Alexandre Oliva wrote:
>
> On Apr 22, 2024, Richard Biener wrote:
>
> >> Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu. Also tested with
> >> gcc-13 on ppc64-vx7r2 and ppc-vx7r2. Ok to install?
>
> > That makes sense. OK
>
> >> for gcc/test
On Tue, 30 Apr 2024 at 17:47, Simon Marchi wrote:
>
> On 4/30/24 4:54 AM, Christophe Lyon wrote:
> > On Tue, 30 Apr 2024 at 04:25, Simon Marchi wrote:
> >>
> >> Add an "AC_CONFIG_MACRO_DIRS" call in configure.ac, with the same
> >> directories
On Thu, 2 May 2024 at 23:13, FX Coudert wrote:
>
> > libgfortran/ChangeLog:
> > * Makefile.am: Use sub-dirs, amend recipies accordingly.
> > * Makefile.in: Regenerate.
>
> Thanks Iain, I’ve tested it both with and without maintainer mode, and
> regenerated files with no issue. I can also confirm
On Thu, 2 May 2024 at 15:47, Gaius Mulley wrote:
>
> Simon Marchi writes:
>
> >
> > I don't have access to the gcc repo, so could you please push the patch
> > on my behalf?
>
> all done - many thanks for the patch!
>
Great, I think we now have to update autoregen.py on the buildbot so
that it s
Hi,
I've just pushed this patch series, congratulations!
Thanks,
Christophe
On Thu, 11 Apr 2024 at 15:40, Evgeny Karpov wrote:
>
> Hello,
>
> Thank you for reviewing v2!
> v3 addresses all comments on v2.
>
> v3 Changes:
> - Exclude the aarch64_calling_abi declaration from the patch series.
>
interpreted byte-by-byte at
instruction level, see
https://developer.arm.com/documentation/101028/0012/14--M-profile-Vector-Extension--MVE--intrinsics.
This is a workaround until we change such predicates representation to
V16BImode.
2024-05-06 Christophe Lyon
Jakub Jelinek
PR
Thank you Mark and sorry for missing this during the reviews.
Christophe
Le dim. 12 mai 2024, 14:54, Mark Wielaard a écrit :
> The new cygming.opt.urls and mingw.opt.urls in the
> gcc/config/mingw/cygming.opt.urls directory need to generated by make
> regenerate-opt-urls in the gcc subdirector
Hi Torbjörn,
On 9/3/24 11:30, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
Some of the test cases were scanning for "bti", but it would,
incorrectly, match the ".arch_extenssion pacbti".
Also, keep test cases active if a supported Cortex-M core is supplied.
gcc/testsuite/Ch
Add a comment about the lack of "n" forms for floating-point nor 8-bit
integers, to make it clearer why we use build_16_32 for MODE_n.
2024-07-11 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-shapes.cc (binary_orrq_def): Improve
comment.
---
gcc/config/a
g_type_suffix and half_type_suffix helpers to
avoid some code duplication.
Tested on arm-eabi with
--target_board=arm-qemu{-mthumb/-mfloat-abi=hard/-march=armv8.1-m.main+mve.fp+fp.dp}
Christophe Lyon (36):
arm: [MVE intrinsics] improve comment for orrq shape
arm: [MVE intrinsics] remove useless res
Factorize vcvtaq vcvtmq vcvtnq vcvtpq builtins so that they use the
same parameterized names.
2024-07-11 Christophe Lyon
gcc/
* config/arm/iterators.md (mve_insn): Add VCVTAQ_M_S, VCVTAQ_M_U,
VCVTAQ_S, VCVTAQ_U, VCVTMQ_M_S, VCVTMQ_M_U, VCVTMQ_S, VCVTMQ_U
Factorize vcvtbq, vcvttq so that they use the same parameterized
names.
2024-07-11 Christophe Lyon
gcc/
* config/arm/iterators.md (mve_insn): Add VCVTBQ_F16_F32,
VCVTTQ_F16_F32, VCVTBQ_F32_F16, VCVTTQ_F32_F16, VCVTBQ_M_F16_F32,
VCVTTQ_M_F16_F32
Implement vcvtbq_f16_f32, vcvttq_f16_f32, vcvtbq_f32_f16 and
vcvttq_f32_f16 using the new MVE builtins framework.
2024-07-11 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-base.cc (class vcvtxq_impl): New.
(vcvtbq, vcvttq): New.
* config/arm/arm-mve-builtins
This patch adds the vcvt shape description.
It needs to add a new type_suffix_info parameter to
explicit_type_suffix_p (), because vcvt uses overloads for type
suffixes for integer to floating-point conversions, but not for
floating-point to integer.
2024-07-11 Christophe Lyon
gcc
vcreateq have no overloaded forms, so there's no need for resolve ().
2024-07-11 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-shapes.cc (create_def): Remove
resolve.
---
gcc/config/arm/arm-mve-builtins-shapes.cc | 6 --
1 file changed, 6 deletions(-)
This patch adds the vcvt_f16_f32 and vcvt_f32_f16 shapes descriptions.
2024-07-11 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-shapes.cc (vcvt_f16_f32)
(vcvt_f32_f16): New.
* config/arm/arm-mve-builtins-shapes.h (vcvt_f16_f32)
(vcvt_f32_f16): New
Factorize vorn so that they use parameterized names.
2024-07-11 Christophe Lyon
gcc/
* config/arm/iterators.md (MVE_INT_M_BINARY_LOGIC): Add VORNQ_M_S,
VORNQ_M_U.
(MVE_FP_M_BINARY_LOGIC): Add VORNQ_M_F.
(mve_insn): Add VORNQ_M_S, VORNQ_M_U, VORNQ_M_F
Implement vcvtq using the new MVE builtins framework.
In config/arm/arm-mve-builtins-base.def, the patch also restores the
alphabetical order.
2024-07-11 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-base.cc (class vcvtq_impl): New.
(vcvtq): New.
* config
Factorize vcvtq so that they use parameterized names.
2024-07-11 Christophe Lyon
gcc/
* config/arm/iterators.md (mve_insn): Add VCVTQ_FROM_F_S,
VCVTQ_FROM_F_U, VCVTQ_M_FROM_F_S, VCVTQ_M_FROM_F_U,
VCVTQ_M_N_FROM_F_S, VCVTQ_M_N_FROM_F_U, VCVTQ_M_N_TO_F_S
This patch adds the vcvtx shape description for vcvtaq, vcvtmq,
vcvtnq, vcvtpq.
2024-07-11 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-shapes.cc (vcvtx): New.
* config/arm/arm-mve-builtins-shapes.h (vcvtx): New.
---
gcc/config/arm/arm-mve-builtins-shapes.cc
Implement vbicq using the new MVE builtins framework.
2024-07-11 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-base.cc (vbicq): New.
* config/arm/arm-mve-builtins-base.def (vbicq): New.
* config/arm/arm-mve-builtins-base.h (vbicq): New.
* config
Testing v[id]dup overloads with '1' as argument for uint32_t* does not
make sense: instead of choosing the '_wb' overload, we choose the
'_n', but we already do that in the '_n' tests.
This patch removes all such bogus foo2 functions.
2024-08-28
Implement vorn using the new MVE builtins framework.
2024-07-11 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-base.cc (vornq): New.
* config/arm/arm-mve-builtins-base.def (vornq): New.
* config/arm/arm-mve-builtins-base.h (vornq): New.
* config/arm
lling code_for_mve_q_XXX.
2024-07-11 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-functions.h
(unspec_based_mve_function_base): Add m_unspec_for_sint,
m_unspec_for_uint, m_unspec_for_fp and expand_unspec members.
(unspec_based_mve_function_exact_insn): Inherit
Implement vctp using the new MVE builtins framework.
2024-08-21 Christophe Lyon
gcc/ChangeLog:
* config/arm/arm-mve-builtins-base.cc (class vctpq_impl): New.
(vctp16q): New.
(vctp32q): New.
(vctp64q): New.
(vctp8q): New.
* config/arm/arm-mve
nsigned we just want to check that 'imm' is
an immediate, not the optional predicates.
[1] https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660262.html
2024-08-21 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-shapes.cc (binary_acca_int32): Fix
chec
We use code_for_mve_q_u_insn, rather than the expanders used by the
previous implementation, so we can remove the expanders and their
declaration as builtins.
2024-08-21 Christophe Lyon
gcc/
* config/arm/arm_mve_builtins.def (vddupq_n_u, vidupq_n_u)
(vddupq_m_n_u
Implement vcvtaq vcvtmq vcvtnq vcvtpq using the new MVE builtins
framework.
2024-07-11 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-base.cc (vcvtaq): New.
(vcvtmq): New.
(vcvtnq): New.
(vcvtpq): New.
* config/arm/arm-mve-builtins-base.def
vddup.u16 q3, r2, #1
now:
ldr r2, [r0]
vddup.u16 q3, r2, #1
str r2, [r0]
2024-08-21 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-base.cc (class viddup_impl): New.
(vddup): New.
(vidup): New
Factorize vddup and vidup so that they use the same parameterized
names.
This patch updates only the (define_insn
"@mve_q_u_insn") patterns and does not bother with the
(define_expand "mve_vidupq_n_u") ones, because a subsequent
patch avoids using them.
2024-08-21 Christophe
Like with vddup/vidup, we use code_for_mve_q_wb_u_insn, so we can drop
the expanders and their declarations as builtins, now useless.
2024-08-28 Christophe Lyon
gcc/
* config/arm/arm-builtins.cc
(arm_quinop_unone_unone_unone_unone_imm_pred_qualifiers): Delete
Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-shapes.cc (viddup): New.
* config/arm/arm-mve-builtins-shapes.h (viddup): New.
* config/arm/arm-mve-builtins.cc (report_not_one_of): New.
(function_checker::require_immediate_one_of): New
Implement vadciq using the new MVE builtins framework.
2024-08-28 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-base.cc (class vadc_vsbc_impl): New.
(vadciq): New.
* config/arm/arm-mve-builtins-base.def (vadciq): New.
* config/arm/arm-mve-builtins
This patch adds the vadc_vsbc shape description.
2024-08-28 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-shapes.cc (vadc_vsbc): New.
* config/arm/arm-mve-builtins-shapes.h (vadc_vsbc): New.
---
gcc/config/arm/arm-mve-builtins-shapes.cc | 36
This patch adds the vidwdup shape description for vdwdup and viwdup.
It is very similar to viddup, but accounts for the additional 'wrap'
scalar parameter.
2024-08-21 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-shapes.cc (vidwdup): New.
* config/a
t does not exist in SVE.
2024-08-28 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-shapes.cc (long_type_suffix): New.
(half_type_suffix): New.
(struct binary_move_narrow_def): Use new helper.
(struct binary_move_narrow_unsigned_def): Likewise.
.
2024-08-21 Christophe Lyon
gcc/
* config/arm/iterators.md (mve_insn): Add VIWDUPQ, VDWDUPQ,
VIWDUPQ_M, VDWDUPQ_M.
(VIDWDUPQ): New iterator.
(VIDWDUPQ_M): New iterator.
* config/arm/mve.md (mve_vdwdupq_wb_u_insn)
(mve_viwdupq_wb_u_insn
h a variable 'wrap' parameter (b)
and we need foo2 to test the overload with an immediate (1).
2024-08-28 Christophe Lyon
gcc/testsuite/
* gcc.target/arm/mve/intrinsics/vdwdupq_m_wb_u16.c: Use pointer
parameter in foo2.
* gcc.target/arm/mve/intrinsics/
This patch adds the vshlc shape description.
2024-08-28 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-shapes.cc (vshlc): New.
* config/arm/arm-mve-builtins-shapes.h (vshlc): New.
---
gcc/config/arm/arm-mve-builtins-shapes.cc | 44 +++
gcc
Implement vdwdup and viwdup using the new MVE builtins framework.
In order to share more code with viddup_impl, the patch swaps operands
1 and 2 in @mve_v[id]wdupq_m_wb_u_insn, so that the parameter
order is similar to what @mve_v[id]dupq_m_wb_u_insn uses.
2024-08-28 Christophe Lyon
Implement vshlc using the new MVE builtins framework.
2024-08-28 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-base.cc (class vshlc_impl): New.
(vshlc): New.
* config/arm/arm-mve-builtins-base.def (vshlcq): New.
* config/arm/arm-mve-builtins-base.h
Since we rewrote the implementation of vshlcq intrinsics, we no longer
need these expanders.
2024-08-28 Christophe Lyon
gcc/
* config/arm/arm-builtins.cc
(arm_ternop_unone_none_unone_imm_qualifiers)
(-arm_ternop_none_none_unone_imm_qualifiers): Delete
Implement vadcq using the new MVE builtins framework.
We re-use most of the code introduced by the previous patch to support
vadciq: we just need to initialize carry from the input parameter.
2024-08-28 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-base.cc (vadcq_vsbc
Factorize vadc/vsbc and vadci/vsbci so that they use the same
parameterized names.
2024-08-28 Christophe Lyon
gcc/
* config/arm/iterators.md (mve_insn): Add VADCIQ_M_S, VADCIQ_M_U,
VADCIQ_U, VADCIQ_S, VADCQ_M_S, VADCQ_M_U, VADCQ_S, VADCQ_U,
VSBCIQ_M_S
Implement vsbcq vsbciq using the new MVE builtins framework.
We re-use most of the code introduced by the previous patches.
2024-08-28 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-base.cc (class vadc_vsbc_impl): Add
support for vsbciq and vsbcq.
(vadciq
On 9/6/24 11:17, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
Changes since v1:
- Corrected changelog entry for pac-15.c
- Added a tab before all the asm instructions in the pac-*.c and bti-*.c tests
- Corrected the expected number of bti instructions for bti-2.c as it
previou
ping?
On Tue, 30 Jul 2024 at 23:41, Christophe Lyon wrote:
>
> Hi,
>
> v4 of patch 2/2 fixes a small mistake in 3 testcases, by relaxing the
> expected q0 as result register into q[0-9]+ to account for codegen
> differences depending on if the test is compiled with
>
From: Alfie Richards
Hi,
This patch series refactors the MVE vst and vld intrinsics to use the builtins
framework.
This is a prerequisite for a later patch which adds gimple folding which in
turn enables some optimisations that were being missed.
I have crosscompiled on an x64 machine and reg
From: Alfie Richards
This patch extends
function_expander::use_contiguous_load_insn and
function_expander::use_contiguous_store_insn functions to
support predicated versions.
2024-09-11 Alfie Richards
Christophe Lyon
gcc/
* config/arm/arm-mve-builtins.cc
From: Alfie Richards
This patch adds the extending load shape.
It also adds/fixes comments for the load and store shapes.
2024-09-11 Alfie Richards
Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-shapes.cc:
(load_ext): New.
* config/arm/arm
From: Alfie Richards
This patch adds the load_extending and store_truncating function bases
for MVE intrinsics.
The constructors have parameters describing the memory element
type/width which is part of the function base name (e.g. "h" in
vldrhq).
2024-09-11 Alfie Richards
gcc/
From: Alfie Richards
The tests for vst* instrinsics use functions which return a void
expression which can generate a warning. This hasn't come up previously
as the inlining presumably prevents the warning.
This change removed the uneccessary and incorrect returns.
2024-09-11 Alfie Richards
Alfie Richards
Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-base.cc (vld1q_impl): Add support
for predicated version.
(vst1q_impl): Likewise.
(vstrq_impl): New class.
(vldrq_impl): New class.
(vldrbq): New.
(vldrhq
, but I think this could (should) be
improved independently.
I have attached the sample C source and the code generated with
(frane64.s.O2) and without (frame64.s.O2.ref) my patch when compiling
at -O2.
What do you think?
Thanks,
Christophe.
On 28 June 2013 13:41, Christophe Lyon wrote:
>
Hi,
We have just committed backports of the following revisions from trunk
to linaro/gcc-4_8-branch:
r201636 (as 202175)
r201501 (as 202176) (should have picked it up by 4.8 branch merge)
r201341 (as 202181)
Thanks,
Christophe.
Hi,
We have recently committed backports from trunk to linaro/gcc-4_8-branch:
201624,201666 (as 202196)
201589 (as 202276)
201599 (as 202277)
201730,201731
Kugan,
>> I have changed all of the above in the attached patch and ChangeLog. If this
>> is OK, could someone please commit it for me. I don’t have access to commit
>> it.
>>
>> Bootstrapped and regtested on x86_64-unknown-linux-gnu and arm-none
>> linux-gnueabi.
>
> Ok.
>
> Thanks and sorry that
committed the attached patch, which I hope fixes all the
spaces/indentation issues introduced.
Christophe.
2013-09-24 Christophe Lyon
* gimple-pretty-print.c: Various whitespace tweaks.
* tree-core.h: Likewise.
* tree-pretty-print.c: Likewise.
* tree-ssa-alias.c: Likewise.
Ping?
May I commit this small patch?
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00580.html
Thanks,
Christophe.
On 10 September 2012 14:23, Christophe Lyon wrote:
> On 9 September 2012 12:46, Gerald Pfeifer wrote:
>> On Mon, 3 Sep 2012, Christophe Lyon wrote:
>>>
Hi Richard,
On 21 September 2012 10:49, Richard Earnshaw wrote:
> On 21/09/12 09:47, Matthew Gretton-Dann wrote:
>> On 20 September 2012 23:06, Christophe Lyon
>> wrote:
>>> Hi,
>>>
>>> GCC for ARM does not support compiling in Thumb1 mode and
>>
e original ones).
I'd like to keep the modifications at a minimal level, to save my time
when adapting each test (there are currently 145 test files, so 143
left :-).
Thanks,
Christophe.
This patch only introduces new files.
2013-10-03 Christophe Lyon
testsuite/gcc.target/arm/neo
Committed on Charles' behalf as rev 203799 with this ChangeLog entry:
2013-10-17 Charles Bayis
* gcc.dg/builtin-apply2.c: Skip test on arm hardfloat ABI targets.
* gcc.dg/tls/pr42894.c: Remove dg-options for arm*-*-* targets.
* gcc.target/arm/thumb-ltu.c: Remove dg-skip-if and require
effective
Hi,
We have recently committed backports from trunk to linaro/gcc-4_8-branch:
203059,203116 (as 203137,203138)
201250 (as 203139)
202275 (as 203179)
202279 (as 203180)
202164 (as 203181)
201260,202400 (as 203183)
202023,202108
Hi Kyrill,
Kugan only fixes the tests we have observed to fail.
The different allocation is not caused by LRA, since we haven't
backported it to our 4.8-based branch.
The different allocation is caused by another difference between 4.8 and trunk.
Christophe.
On 24 October 2013 16:39, Kyrill Tka
Ping?
On 10 October 2013 00:16, Christophe Lyon wrote:
> Hi,
>
> This patch is a first small sample of dejagnu-ization of my ARM Neon
> intrinsics tests.
>
> It's derived from my previous work at
> http://gitorious.org/arm-neon-tests/arm-neon-tests which supports all
On 29 October 2013 03:24, Ramana Radhakrishnan wrote:
> On 10/09/13 23:16, Christophe Lyon wrote:
> Irrespective of our earlier conversations on this now I'm actually wondering
> if instead of doing this and integrating this in the GCC source base it
> maybe easier to write
Hi Ramana,
>> More later I need to get back to something else and I need to play more with
>> your original testsuite - but I'd like some discussion around some of these
>> points anyway.
>>
Rob Savoye is going to have a look at how to integrate the tests in a
more straightforward way (he knows d
On 29 October 2013 10:38, Ramana Radhakrishnan wrote:
> On 10/24/13 00:04, Kugan wrote:
>>
>> Hi,
>>
>> arm testcases neon-vcond-ltgt.c and neon-vcond-unordered.c fails in
>> Linaro 4.8 branch. It is not reproducable with trunk but it can happen.
>> Both neon-vcond-ltgt.c and neon-vcond-unordered.
On 19 January 2016 at 12:51, Ramana Radhakrishnan
wrote:
> On Thu, Nov 12, 2015 at 3:16 PM, Andre Vieira
> wrote:
>> On 12/11/15 15:08, Andre Vieira wrote:
>>>
>>> Hi,
>>>
>>>This patch changes the memset-inline-10.c testcase to make sure that
>>> it is only compiled for ARM targets that supp
On 19 January 2016 at 15:51, Alan Lawrence wrote:
> On 19/01/16 11:15, Christophe Lyon wrote:
>
>>>> For neon_vdupn, I chose to implement neon_vdup_nv4hf and
>>>> neon_vdup_nv8hf instead of updating the VX iterator because I thought
>>>>
On 22 January 2016 at 18:07, Richard Henderson wrote:
> The bare CONST_INT inside the CCmode IF_THEN_ELSE is causing combine to make
> incorrect simplifications. At this stage it feels safer to wrap the
> CONST_INT inside of an UNSPEC than make more generic changes to combine.
>
> But we should d
On 22 January 2016 at 18:06, Alan Lawrence wrote:
> On 20/01/16 21:10, Christophe Lyon wrote:
>>
>> On 19 January 2016 at 15:51, Alan Lawrence
>> wrote:
>>>
>>> On 19/01/16 11:15, Christophe Lyon wrote:
>>>
>>>>>> For neon_vdup
arm hard-float
targets (eg. arm-none-linux-gnueabihf).
I'm not sure it counts as obvious, so here it is.
OK?
Christophe.
DATE Christophe Lyon
* gcc.target/arm/pr68674.c: Check and use arm_fp effective target.
> Thanks,
> Richard.
>
>> bootstrapped / tested for
Hi,
This is a followup to PR63304.
As discussed in bugzilla, this patch disables pcrelative_literal_loads
when -mfix-cortex-a53-843419 (or its default configure option) is
used.
I copied the behavior of -mfix-cortex-a53-835769 (e.g. in
aarch64_can_inline_p), and I have tested by building the Lin
With the attachment
On 26 January 2016 at 15:42, Christophe Lyon wrote:
> Hi,
>
> This is a followup to PR63304.
>
> As discussed in bugzilla, this patch disables pcrelative_literal_loads
> when -mfix-cortex-a53-843419 (or its default configure option) is
> used.
>
On 26 January 2016 at 14:20, Kyrill Tkachov wrote:
> Hi Christophe,
>
> On 20/01/16 21:10, Christophe Lyon wrote:
>>
>> On 19 January 2016 at 15:51, Alan Lawrence
>> wrote:
>>>
>>> On 19/01/16 11:15, Christophe Lyon wrote:
>>>
>>&
On 9 February 2016 at 13:42, Richard Biener wrote:
>
> It turns out if-conversions poor job on
>
> if (a)
>x[i] = ...;
> else
>x[i] = ...;
>
> results in bogus uninit warnings of x[i] for a variety of reasons.
> First of all forwprop (aka match.pd simplification) doesn't fixup
> all of i
On 11 February 2016 at 14:10, Kyrill Tkachov
wrote:
>
> On 10/02/16 10:39, James Greenhalgh wrote:
>>
>> On Wed, Feb 10, 2016 at 10:32:16AM +, Kyrill Tkachov wrote:
>>>
>>> Hi James,
>>>
>>> On 10/02/16 10:11, James Greenhalgh wrote:
On Thu, Feb 04, 2016 at 01:50:31PM +, Kyrill T
On 11 February 2016 at 19:04, Kyrill Tkachov
wrote:
>
> On 11/02/16 17:57, Christophe Lyon wrote:
>>
>> On 11 February 2016 at 14:10, Kyrill Tkachov
>> wrote:
>>>
>>> On 10/02/16 10:39, James Greenhalgh wrote:
>>>>
>>>&
On 15 February 2016 at 23:16, Janne Blomqvist wrote:
> On Mon, Feb 15, 2016 at 11:45 PM, Jerry DeLisle wrote:
>> The title of the PR should be "Mishandling of namelist comments" or
>> "Interpreting '!' as a comment in non-namelist reads".
>>
>> The attached patch fixes the regression by reverting
On 16 February 2016 at 10:53, James Greenhalgh wrote:
> On Tue, Feb 16, 2016 at 09:27:00AM +, Kyrill Tkachov wrote:
>> Hi all,
>>
>> As Christophe reported at:
>> https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00784.html
>>
>> The test gcc.target/aarch64/assembler_arch_1.c fails to assemble on
On 16 February 2016 at 18:49, Jerry DeLisle wrote:
> On 02/16/2016 12:06 AM, Christophe Lyon wrote:
>> On 15 February 2016 at 23:16, Janne Blomqvist
>> wrote:
>>> On Mon, Feb 15, 2016 at 11:45 PM, Jerry DeLisle
>>> wrote:
>>>> The title of the P
On 15 February 2016 at 12:32, Kyrill Tkachov
wrote:
>
> On 04/02/16 08:58, Ramana Radhakrishnan wrote:
>>
>> On Tue, Jun 30, 2015 at 2:15 AM, Jim Wilson wrote:
>>>
>>> This is my suggested fix for PR 65932, which is a linux kernel
>>> miscompile with gcc-5.1.
>>>
>>> The problem here is caused by
On 17 February 2016 at 11:05, Kyrill Tkachov
wrote:
>
> On 17/02/16 10:03, Christophe Lyon wrote:
>>
>> On 15 February 2016 at 12:32, Kyrill Tkachov
>> wrote:
>>>
>>> On 04/02/16 08:58, Ramana Radhakrishnan wrote:
>>>>
>&g
On 17 February 2016 at 11:22, Kyrill Tkachov
wrote:
>
> On 17/02/16 10:20, Christophe Lyon wrote:
>>
>> On 17 February 2016 at 11:05, Kyrill Tkachov
>> wrote:
>>>
>>> On 17/02/16 10:03, Christophe Lyon wrote:
>>>>
>>>> On 15 Feb
On 16 February 2016 at 18:19, Nick Clifton wrote:
> Hi Richard, Hi Ramana,
>
> The ARM backend has some problems compiling for the old ARMv3
> architecture. See:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62254
>
> for an example of this. v3 is very old now, and I am not sure how
201 - 300 of 3170 matches
Mail list logo
