On 17 February 2016 at 17:06, Kyrill Tkachov
wrote:
> Hi all,
>
> I've thought about this check a bit more and I think we can compactly
> auto-generate checks
> for any aarch64 architecture extension support in the assembler.
> This is done in a similar way we autogenerate the arm_arch_*_ok checks
On 16 February 2016 at 16:37, Jeff Law wrote:
> On 02/16/2016 07:21 AM, Bernd Schmidt wrote:
>>
>> On 02/08/2016 05:30 PM, Jeff Law wrote:
>>>
>>> On 01/29/2016 04:40 AM, Bernd Schmidt wrote:
c/
PR c/69522
* c-parser.c (c_parser_braced_init): New arg outer_obstack. All
On 18 February 2016 at 14:20, Nick Clifton wrote:
> Hi Christophe,
>
>> Could you modify your new testcases, such that they call
>> check_effective_target_arm_arm_ok ?
>
> Good idea - done.
>
>> I'm just realizing that we currently generate arm_arch_vX_ok
>> for X >=4 only. Maybe you should also a
Ping?
On 26 January 2016 at 15:43, Christophe Lyon wrote:
> 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 pcre
On 26 February 2016 at 16:51, James Greenhalgh wrote:
> On Thu, Feb 25, 2016 at 11:04:21AM +, Kyrill Tkachov wrote:
>> Hi all,
>>
>> Seems like aarch64 is suffering from something similar to PR 69245 as well.
>> If a target pragma sets the target state to the same as the
>> target_option_defau
On 29 February 2016 at 15:28, Kyrill Tkachov
wrote:
> Hi Crhistophe,
>
>
> On 29/02/16 14:10, Christophe Lyon wrote:
>>
>> On 26 February 2016 at 16:51, James Greenhalgh
>> wrote:
>>>
>>> On Thu, Feb 25, 2016 at 11:04:21AM +, Kyrill Tkach
On 1 March 2016 at 10:51, James Greenhalgh wrote:
> On Tue, Mar 01, 2016 at 10:21:27AM +0100, Richard Biener wrote:
>> On Mon, 29 Feb 2016, James Greenhalgh wrote:
>>
>> > On Fri, Feb 26, 2016 at 09:32:53AM +0100, Richard Biener wrote:
>> > >
>> > > The following fixes PR69951, hopefully the last
On 2 March 2016 at 00:12, Jeff Law wrote:
>
> This patch clamps the number of statements to copy when not threading across
> a loop backedge in the FSM/backwards threader. This fixes the bulk of the
> regression in 69196. I'm still evaluating whether or not 69196 can be
> closed, but at the leas
On 2 March 2016 at 10:16, James Greenhalgh wrote:
> On Tue, Mar 01, 2016 at 05:56:30PM +0100, Christophe Lyon wrote:
>> On 1 March 2016 at 10:51, James Greenhalgh wrote:
>> > On Tue, Mar 01, 2016 at 10:21:27AM +0100, Richard Biener wrote:
>> >> On Mon, 29 Fe
On 29 February 2016 at 05:28, kugan wrote:
>
>> That looks better, but I think the unordered_remove will break operand
>> sorting
>> and thus you probably don't handle x + x + x + x + y + y + y + y + y +
>> y + z + z + z + z
>> optimally.
>>
>> I'd say you simply want to avoid the recursion and co
On 29 February 2016 at 18:48, Kyrill Tkachov
wrote:
> Hi all,
>
> Now that we've moved to pragmas guarding the various intrinsics in
> arm_neon.h I think we should still
> throw a #error if someone tries to include the header while compiling for
> -mfloat-abi=soft.
>
> This gives a more helpful er
On 2 March 2016 at 10:49, Christophe Lyon wrote:
> On 2 March 2016 at 10:16, James Greenhalgh wrote:
>> On Tue, Mar 01, 2016 at 05:56:30PM +0100, Christophe Lyon wrote:
>>> On 1 March 2016 at 10:51, James Greenhalgh wrote:
>>> > On Tue, Mar 01, 2016 at 10:21:27
ing of the test, like we do in several other similar tests.
OK?
Christophe.
2016-03-07 Christophe Lyon
* gcc.target/arm/pragma_cpp_fma.c: Reset default FPU.
diff --git a/gcc/testsuite/gcc.target/arm/pragma_cpp_fma.c
b/gcc/testsuite/gcc.target/arm/pragma_cpp_fma.c
index be63256..c72e
On 27 November 2013 06:53, Jeff Law wrote:
> On 11/25/13 17:29, Kugan wrote:
[...]
>> Thanks for the review. Is this OK for trunk now?
>
> Yes. Please install.
>
> jeff
>
Thanks, committed on Kugan's behalf as r205444.
Committed on Kugan's behalf as rev 205666.
Christophe.
On 3 December 2013 20:47, Jeff Law wrote:
> On 12/02/13 23:39, Kugan wrote:
>>>
>>>
>>> +2013-11-27 Kugan Vivekanandarajah
>>> +
>>> + * config/arm/bpapi-lib.h (TARGET_HAS_NO_HW_DIVIDE): Define for
>>> + architectures that do
We have committed several backports from trunk to linaro/gcc-4_8-branch:
r200956 as r203832 ([AArch64] -mcmodel=tiny -fPIC GOT support)
r204336 as r204569 (Fix testsuite testcase
neon-vcond-[ltgt,unordered].c)
r203267, r203603 and r204247 as r204570 (Fix PR target/58423)
r197526: rever
Committed on Kugan's behalf as rev 205891.
On 11 December 2013 13:27, Marcus Shawcroft wrote:
> On 10/12/13 20:23, Kugan wrote:
>
>> gcc/
>>
>> +2013-12-11 Kugan Vivekanandarajah
>> + * configure.ac: Add check for aarch64 assembler -mabi support.
>> + * configure: Regenerate.
>> +
We have committed several backports from trunk to linaro/gcc-4_8-branch:
r203799 as r205740 (fix testcases for ARM hardfloat targets)
r203327 as r205742 (Enhance phiopt to handle BIT_AND_EXPR)
r204737 as r205743 (Make AArch64 frame grow downwards)
r202872 as r205744 ([ARM][testsuite] Add effective
rather than FAIL).
OK?
Christophe.
2014-01-08 Christophe Lyon
* lib/target-supports.exp (check_effective_target_arm_crypto_ok):
Include arm_neon.h in sample test.
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index a8910bb..cc10936 100644
--- a/gcc/testsuite/ChangeLog
Hi Renlin,
The new test you added introduces 2 new FAILs when the target is
arm-none-linux-gnueabi (as opposed to arm-none-linux-gnueabihf).
Christophe.
On 24 December 2013 15:46, Renlin Li wrote:
> Hi,
>
> I just updated my patch according your suggestion.
> Thank you for committing it for me
On 8 January 2014 18:15, Renlin Li wrote:
> Hi Christophe,
>
> There is a minor issue about this test case. It requires the `float-abi` of
> your target to be either `softfp` or `hard` (to utilize the floating point
> hardware).
> Could you please check whether this solves the problem or not?
>
In
Hi,
>
> 2013-12-22 Eric Botcazou
>
> * gcc.target/arm/neon-nested-apcs.c: New test.
>
This new test fails when GCC is configured as target
arm-none-linux-gnueabihf and --with-float=hard:
tools/arm-none-linux-gnueabihf/bin/ld: error: ./neon-nested-apcs.exe
uses VFP register arguments, /tm
Hello,
It seems this patch causes several regressions in gfortran on ARM too:
gfortran.dg/default_format_1.f90
gfortran.dg/default_format_denormal_1.f90
gfortran.dg/fmt_bz_bn.f
gfortran.dg/fmt_read_bz_bn.f90
gfortran.dg/g77/f77-edit-t-in.f
gfortran.dg/list_read_4.f90
gfortran.dg/namelist_11.f
gfor
On 10 January 2014 17:45, Jakub Jelinek wrote:
> On Fri, Jan 10, 2014 at 05:44:22PM +0100, Christophe Lyon wrote:
>> It seems this patch causes several regressions in gfortran on ARM too:
>> gfortran.dg/default_format_1.f90
>> gfortran.dg/default_format_denormal_1.f90
>&
Hi Jakub,
I can confirm it's OK now.
Thanks,
Christophe.
On 10 January 2014 17:56, Christophe Lyon wrote:
> On 10 January 2014 17:45, Jakub Jelinek wrote:
>> On Fri, Jan 10, 2014 at 05:44:22PM +0100, Christophe Lyon wrote:
>>> It seems this patch causes several regress
Hi Kyrill,
Your patch fixes most of the problems I noticed, however, it makes the
compiler crash on vld1Q_dupp64 when the target is big-endian:
--with-target= armeb-none-linux-gnueabihf
--with-cpu=cortex-a9
--with-fpu=neon-fp16
/aci-gcc-fsf/sources/gcc-fsf/trunk/gcc/testsuite/gcc.target/arm/neon
On 13 January 2014 15:51, Kyrill Tkachov wrote:
> On 13/01/14 13:57, Christophe Lyon wrote:
>>
>> Hi Kyrill,
>>
>> Your patch fixes most of the problems I noticed, however, it makes the
>> compiler crash on vld1Q_dupp64 when the target is big-endian:
>> --
On 10 July 2015 at 09:14, Christian Bruel wrote:
>
> On 07/09/2015 05:39 PM, Christophe Lyon wrote:
>> Some multilibs do not support Thumb mode on ARM targets. This is the
>> case for instance when target is arm-linux-gnueabihf and with
>> -march=armv5-t: Thumb-1 h
On 10 July 2015 at 13:40, Ramana Radhakrishnan
wrote:
>
>
> On 10/07/15 12:35, Christophe Lyon wrote:
>> On 10 July 2015 at 09:14, Christian Bruel wrote:
>>>
>>> On 07/09/2015 05:39 PM, Christophe Lyon wrote:
>>>> Some multilibs do not support Thumb m
'reg_nelts = 2' to keep the code closer to what is done
elsewhere.
OK for trunk?
Christophe
2015-07-16 Christophe Lyon
* config/arm/neon.md (neon_vget_lanev2di): Handle big-endian
targets.
diff --git a/gcc/config/arm/neon.md b/gcc/config/arm/neon.md
index 654d9d5..59dd
Hi Michael,
It looks like this patch introduces regressions on armeb in:
gcc.dg/vect/vect-reduc-7.c
gcc.dg/vect/vect-reduc-8.c
gcc.dg/vect/vect-reduc-9.c
See
http://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/226476/report-build-info.html
for a bit more details.
Can you have a
On 21 July 2015 at 16:01, Kyrill Tkachov wrote:
>
> On 16/07/15 08:56, Christophe Lyon wrote:
>>
>> AdvSIMD vget_lane tests currently fail on armeb targets when dealing
>> with vectors of 2 64-bits elements. This patches fixes it, by adding a
>> code fragment sim
On 4 August 2015 at 14:09, Christophe Lyon wrote:
> On 21 July 2015 at 16:01, Kyrill Tkachov wrote:
>>
>> On 16/07/15 08:56, Christophe Lyon wrote:
>>>
>>> AdvSIMD vget_lane tests currently fail on armeb targets when dealing
>>> with vectors of 2 6
On 24 July 2015 at 18:18, Szabolcs Nagy wrote:
> On 24/07/15 14:20, Marcus Shawcroft wrote:
>> On 22 July 2015 at 18:22, Szabolcs Nagy wrote:
>>
>>> 2015-07-22 Szabolcs Nagy
>>>
>>> * config/aarch64/aarch64-elf-raw.h (LINK_SPEC): Handle -h, -static,
>>> -shared, -symbolic, -rdy
On 18 September 2015 at 01:18, Moore, Catherine
wrote:
>
>
>> -Original Message-
>> From: Jonathan Wakely [mailto:jwak...@redhat.com]
>> Sent: Thursday, September 17, 2015 6:54 PM
>> To: Moore, Catherine; fdum...@gcc.gnu.org
>> Cc: Gerald Pfeifer; libstd...@gcc.gnu.org; gcc-patches@gcc.gnu
On 25 May 2015 at 22:16, Manuel López-Ibáñez wrote:
> On 25 May 2015 at 21:56, Marek Polacek wrote:
>> Perhaps we should introduce GCC_BAD_LOC with a location_t argument and use it
>> here.
>
> Why would we want to obfuscate code like that? I would propose to
> actually remove GCC_BAD completely.
On 10 September 2015 at 16:02, James Greenhalgh
wrote:
>
> On Wed, Sep 09, 2015 at 10:28:28AM +0100, Christophe Lyon wrote:
>> On 9 September 2015 at 10:31, James Greenhalgh
>> wrote:
>> >
>> > Hi,
>> >
>> > This patch clears up some remaini
Hi Eric,
On 6 July 2015 at 17:46, Ramana Radhakrishnan
wrote:
>
>
> On 18/06/15 20:02, Eric Botcazou wrote:
>>> Please mark this pattern with (set_attr "type" "multiple").
>>
>> Done.
>>
>>> While I suspect that stack probing is done before any insns with invalid
>>> constants in the function, i
On 18 September 2015 at 17:03, Richard Earnshaw
wrote:
> On 18/09/15 15:38, Christian Bruel wrote:
>>
>>
>> On 09/18/2015 04:16 PM, Richard Earnshaw wrote:
>>> On 17/09/15 09:46, Christian Bruel wrote:
As obvious, bad operand number.
OK for trunk ?
Christian
On 20 September 2015 at 23:40, Manuel López-Ibáñez
wrote:
> On 20 September 2015 at 22:32, Christophe Lyon
> wrote:
>> On 25 May 2015 at 22:16, Manuel López-Ibáñez wrote:
>>> On 25 May 2015 at 21:56, Marek Polacek wrote:
>>>> Perhaps we should introduce GCC_B
On 21 September 2015 at 02:24, Manuel López-Ibáñez
wrote:
> On 21 September 2015 at 02:22, Christophe Lyon
> wrote:
>> It works for me if I replace 24 by 62.
>
> Wierd. What is the actual output of the compiler?
Here is what I have in gcc.log:
/home/christophe.lyon/src/GCC/sou
On 21 September 2015 at 02:33, Manuel López-Ibáñez
wrote:
> On 21 September 2015 at 02:29, Christophe Lyon
> wrote:
>> On 21 September 2015 at 02:24, Manuel López-Ibáñez
>> wrote:
>>> On 21 September 2015 at 02:22, Christophe Lyon
>>> wrote:
>&g
On 21 September 2015 at 12:55, Christian Bruel wrote:
> Hi Christophe,
>
>> It seems you committed the 1st version of your patch.
>
>
> Not sure what version you are talking about. I committed what was posted
> (https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01260.html) at revision
> #227880.
I th
On 23 July 2015 at 13:17, Richard Biener wrote:
> On Thu, 23 Jul 2015, Kyrill Tkachov wrote:
>
>>
>> On 23/07/15 10:02, Andreas Schwab wrote:
>> > Richard Biener writes:
>> >
>> > > Index: gcc/testsuite/gcc.dg/torture/pr66952.c
>> > > ==
On 21 September 2015 at 16:15, Christian Bruel wrote:
>
>
> On 09/18/2015 05:03 PM, Richard Earnshaw wrote:
>
>>> Index: attr_thumb-static2.c
>>> ===
>>> --- attr_thumb-static2.c(revision 227904)
>>> +++ attr_thumb-static2.c
unsupported.
The attached patch fixes the order on the few testcases where I
noticed it was wrong.
Tested on several arm* and aarch64* targets/multilibs with no regression.
OK?
Christophe.
2015-09-29 Christophe Lyon
* g++.dg/cpp0x/stdint.C: Move dg-require-effective-target after
Ping?
On 15 September 2015 at 18:25, Christophe Lyon
wrote:
> This patch re-implements vtbl[34] and vtbx4 AdvSIMD intrinsics using
> existing builtins, and fixes the behaviour on aarch64_be.
>
> Tested on aarch64_be-none-elf and aarch64-none-elf using the Foundation M
On 1 October 2015 at 11:10, Kyrill Tkachov wrote:
>
> On 30/09/15 17:39, Kyrill Tkachov wrote:
>>
>> On 09/06/15 09:17, Kyrill Tkachov wrote:
>>>
>>> On 05/06/15 14:14, Kyrill Tkachov wrote:
On 05/06/15 14:11, Richard Earnshaw wrote:
>
> On 05/06/15 14:08, Kyrill Tkachov wrote:
>
On 2 October 2015 at 15:05, Marcus Shawcroft wrote:
> On 2 October 2015 at 14:01, Ramana Radhakrishnan
> wrote:
>
#undef TARGET_ASM_NAMED_SECTION
-#define TARGET_ASM_NAMED_SECTION aarch64_elf_asm_named_section
+#define TARGET_ASM_NAMED_SECTION default_elf_asm_named_section
>>>
>
On 2 October 2015 at 19:08, Ramana Radhakrishnan
wrote:
>
>
> On 01/10/15 17:18, Marek Polacek wrote:
>> On Thu, Oct 01, 2015 at 11:02:09AM -0400, David Edelsohn wrote:
>>> On Thu, Oct 1, 2015 at 10:49 AM, Marek Polacek wrote:
Joseph reminded me that I had forgotten about this patch. As men
On 1 October 2015 at 11:41, James Greenhalgh wrote:
> On Thu, Oct 01, 2015 at 09:33:07AM +0100, Marcus Shawcroft wrote:
>> On 25/09/15 08:59, James Greenhalgh wrote:
>> >
>> > Hi,
>> >
>> > This patch introduces a new scheduling model for Cortex-A53.
>> >
>> > Bootstrapped and tested on arm-none-l
Ping?
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01096.html
On 29 September 2015 at 22:57, Christophe Lyon
wrote:
> Ping?
>
>
> On 15 September 2015 at 18:25, Christophe Lyon
> wrote:
>> This patch re-implements vtbl[34] and vtbx4 AdvSIMD intrinsics using
>> exist
On 7 October 2015 at 17:09, James Greenhalgh wrote:
> On Tue, Sep 15, 2015 at 05:25:25PM +0100, Christophe Lyon wrote:
>> This patch re-implements vtbl[34] and vtbx4 AdvSIMD intrinsics using
>> existing builtins, and fixes the behaviour on aarch64_be.
>>
>> Tested
On 8 October 2015 at 18:55, Richard Sandiford wrote:
> Marc Glisse writes:
>> On Mon, 5 Oct 2015, Richard Sandiford wrote:
>>
>>> + /* cbrt(sqrt(x)) -> pow(x,1/6). */
>>> + (simplify
>>> + (sqrts (cbrts @0))
>>> + (pows @0 { build_real_truncate (type, dconst<1, 6> ()); }))
>>> + /* sqrt(c
On 8 October 2015 at 11:12, James Greenhalgh wrote:
> On Wed, Oct 07, 2015 at 09:07:30PM +0100, Christophe Lyon wrote:
>> On 7 October 2015 at 17:09, James Greenhalgh
>> wrote:
>> > On Tue, Sep 15, 2015 at 05:25:25PM +0100, Christophe Lyon wrote:
>> >
>>
On 9 October 2015 at 18:17, Richard Sandiford wrote:
> Richard Sandiford writes:
>> Christophe Lyon writes:
>>> On 8 October 2015 at 18:55, Richard Sandiford
>>> wrote:
>>>> Marc Glisse writes:
>>>>> On Mon, 5 Oct 2015, Richard Sandifor
On 12 October 2015 at 15:30, James Greenhalgh wrote:
> On Fri, Oct 09, 2015 at 05:16:05PM +0100, Christophe Lyon wrote:
>> On 8 October 2015 at 11:12, James Greenhalgh
>> wrote:
>> > On Wed, Oct 07, 2015 at 09:07:30PM +0100, Christophe Lyon wrote:
>> >&g
On 9 October 2015 at 18:11, James Greenhalgh wrote:
> On Thu, Oct 08, 2015 at 01:29:34PM +0100, Richard Biener wrote:
>> > Thanks again for the comments Richard!
>> >
>> > A new algorithmic optimisation:
>> >
>> > ((X inner_op C0) outer_op C1)
>> > With X being a tree where value_range has reasone
uring 'make check'), and noticed that a few other cases
might read/write/delete the same file concurrently.
The proposed fix is to use different names for the different testcases.
I ran make check -jX on various ARM/AArch64 configuration with no regression.
OK?
Christophe.
2015-10-16
On 19 October 2015 at 15:54, Richard Biener wrote:
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
>
Hi Richard,
This patch caused arm and aarch64 builds of newlib to cause ICEs:
In file included from
/tmp/884316_1.tmpdir/aci-gcc-fsf/sources/newlib/newlib/libc/include/stdlib.h:
On 9 October 2015 at 09:46, Richard Biener wrote:
> On Thu, 8 Oct 2015, Martin Jambor wrote:
>
>> Hi,
>>
>> the following fixes PR 67794 by properly remapping SSA_NAMEs which are
>> based on PARM_DECLs which are about to be removed as unnecessary. And
>> by "properly" I mean also when they are de
On 27 October 2015 at 13:26, Martin Jambor wrote:
> On Tue, Oct 27, 2015 at 09:56:48AM +0100, Christophe Lyon wrote:
>> Hi Martin,
>>
>> After your backport in the gcc-5 branch, I see build failures:
>> /tmp/2849532_27.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc
Hi,
Since r229128, I see:
FAIL: c-c++-common/torture/vector-compare-1.c -O0 execution test
on arm targets, such as arm-none-eabi.
Christophe.
Hi Kyrill,
On 26 October 2015 at 12:52, Kyrill Tkachov wrote:
>
> On 26/10/15 11:28, Bernd Schmidt wrote:
>>
>> On 10/26/2015 12:12 PM, Bernd Schmidt wrote:
>>>
>>>
>>> But isn't that balanced by the fact that it doesn't seem to take into
>>> account the gain of removing the inc_insn either? So I
crtfastmath.o to $extra_parts, for
arm*-*-eabi*, arm*-*-symbianelf*, arm*-*-rtems* targets.
I tested on arm-none-eabi, and I am not sure if this is correct for
symbian/rtems.
OK? Or should I restrict the change to arm*-*-eabi* ?
Thanks,
Christophe.
2015-10-29 Christophe Lyon
On 29 October 2015 at 11:07, Ramana Radhakrishnan
wrote:
> On Thu, Oct 29, 2015 at 9:25 AM, Christophe Lyon
> wrote:
>> Hi,
>>
>> On arm*-*-eabi*, arm*-*-symbianelf*, arm*-*-rtems* targets,
>> crtfastmath.o is not part of $extra_parts, which means that it is not
On 23 October 2015 at 14:26, Matthew Wahab wrote:
> The ARMv8.1 architecture extension adds two Adv.SIMD instructions,
> sqrdmlah and sqrdmlsh. This patch adds the NEON intrinsics vqrdmlah and
> vqrdmlsh for these instructions. The new intrinsics are of the form
> vqrdml{as}h[q]_.
>
> Tested the s
On 30 October 2015 at 15:33, Ramana Radhakrishnan
wrote:
>
>
> On 29/10/15 17:23, Jim Wilson wrote:
>> I noticed a comment typo in this file while using grep to look for
>> other stuff. The typo is easy to fix.
>>
>> I tried running neon-testgen.ml to verify, but it is apparently no
>> longer val
On 2 November 2015 at 09:51, Yvan Roux wrote:
> On 2 November 2015 at 09:38, Ramana Radhakrishnan
> wrote:
>>
>
> 2015-10-12 Kyrylo Tkachov
>
> PR target/67929
> * gcc.target/arm/pr67929_1.c: New test.
>>>
>>> This test fails when tested on hard-float targets, addin
On 2 November 2015 at 15:20, Jiong Wang wrote:
> On 27 May 2015 at 22:15, Christophe Lyon wrote:
>>>
>>> * gcc.target/aarch64/advsimd-intrinsics/vtbX.c: Likewise.
>>>
>
> Noticed this testcase failed on big-endian on my local test
>
> gcc.tar
On 4 November 2015 at 16:37, James Greenhalgh wrote:
>
> On Wed, Nov 04, 2015 at 12:04:19PM +0100, Bernd Schmidt wrote:
>> On 10/30/2015 07:03 PM, James Greenhalgh wrote:
>> >+ i = tmp_i; <- Should be cleaned up
>>
>> Maybe reword as "Subsequent passes are expected to clean up the
>> extra mov
timal implementations in approved order": the previous ones really
seem to be in alphabetical order.
And I added a new testcase, skipped for arm* targets.
This has been tested on aarch64-none-elf and aarch64_be-none-elf
targets, using the Foundation model.
OK?
Christophe.
2015-11-06 Chris
Hi,
I've committed the attached fix for a comment in
gcc.target/aarch64/advsimd-intrinsics/vtbX.c.
(as revision 229858)
Christophe.
2015-11-06 Christophe Lyon
* gcc.target/aarch64/advsimd-intrinsics/vtbX.c: Fix typos in
co
On 4 November 2015 at 13:16, Ramana Radhakrishnan
wrote:
> On Fri, Oct 30, 2015 at 2:42 PM, Christophe Lyon
> wrote:
>> On 30 October 2015 at 15:33, Ramana Radhakrishnan
>> wrote:
>>>
>>>
>>> On 29/10/15 17:23, Jim Wilson wrote:
>>>>
On 6 November 2015 at 18:03, James Greenhalgh wrote:
> On Fri, Nov 06, 2015 at 02:49:38PM +0100, Christophe Lyon wrote:
>> Hi,
>>
>> As mentioned by James a few weeks ago, the vqtbl[lx][234] intrinsics
>> are failing on aarch64_be.
>>
>> The attached patch
On 30 October 2015 at 16:52, Matthew Wahab wrote:
> On 30/10/15 12:51, Christophe Lyon wrote:
>>
>> On 23 October 2015 at 14:26, Matthew Wahab
>> wrote:
>>>
>>> The ARMv8.1 architecture extension adds two Adv.SIMD instructions,
>>> sqrdmlah a
On 9 November 2015 at 18:01, Robert Suchanek wrote:
> Hi,
>
>> On 11/09/2015 02:32 PM, Robert Suchanek wrote:
>> > The results below were generated for CSiBE benchmark and the numbers in
>> > columns express bytes in format 'net (gain/loss)' to show the difference
>> > with and without the patch w
On 6 November 2015 at 12:11, Kyrill Tkachov wrote:
> Hi Richard,
>
>
> On 06/11/15 11:09, Richard Biener wrote:
>>
>> On Fri, 6 Nov 2015, Richard Biener wrote:
>>
>>> The following patch makes the BB vectorizer not only handle BB heads
>>> (until the first stmt with a data reference it cannot hand
On 10 November 2015 at 14:02, Richard Biener wrote:
> On Tue, 10 Nov 2015, Christophe Lyon wrote:
>
>> On 6 November 2015 at 12:11, Kyrill Tkachov wrote:
>> > Hi Richard,
>> >
>> >
>> > On 06/11/15 11:09, Richard Biener wrote:
>
On 10 November 2015 at 12:41, Robert Suchanek
wrote:
> Hi Christophe,
>
>> Hi,
>>
>> Since you committed this (r230087 if I'm correct), I can see that GCC
>> fails to build
>> ligfortran for target arm-none-linuxgnueabi --with-cpu=cortex-a9.
> ...
>>
>> Can you have a look?
>
> Sorry for the break
On 11 November 2015 at 09:50, Robert Suchanek
wrote:
> Hi,
>
>> I guess this is ok to stop the failures for now, but you may want to
>> move the check to the point where we set terminated_this_insn. Also, as
>> I pointed out earlier, clearing terminated_this_insn should probably
>> happen earlier.
On 12 November 2015 at 16:49, Andreas Schwab wrote:
> Richard Biener writes:
>
>> * tree-vectorizer.h (vect_slp_analyze_and_verify_instance_alignment):
>> Declare.
>> (vect_analyze_data_refs_alignment): Make loop vect specific.
>> (vect_verify_datarefs_alignment): Likewise
On 6 November 2015 at 21:29, Christophe Lyon wrote:
> On 4 November 2015 at 13:16, Ramana Radhakrishnan
> wrote:
>> On Fri, Oct 30, 2015 at 2:42 PM, Christophe Lyon
>> wrote:
>>> On 30 October 2015 at 15:33, Ramana Radhakrishnan
>>> wrote:
>>>&g
On 12 November 2015 at 21:04, Christophe Lyon
wrote:
> On 12 November 2015 at 16:49, Andreas Schwab wrote:
>> Richard Biener writes:
>>
>>> * tree-vectorizer.h (vect_slp_analyze_and_verify_instance_alignment):
>>> Declare.
>>> (vect_an
On 12 November 2015 at 23:18, Christophe Lyon
wrote:
> On 6 November 2015 at 21:29, Christophe Lyon
> wrote:
>> On 4 November 2015 at 13:16, Ramana Radhakrishnan
>> wrote:
>>> On Fri, Oct 30, 2015 at 2:42 PM, Christophe Lyon
>>> wrote:
>>>> O
On 13 November 2015 at 12:24, Kyrill Tkachov wrote:
>
> On 13/11/15 11:18, Ramana Radhakrishnan wrote:
>>>
>>> Hmm. I hadn't noticed that the crypto intrinsics tests where generated by
>>> neon-testgen.ml, I thought they were hand-written.
>>> The tests I added do not cover the crypto intrinsics,
On 13 November 2015 at 13:17, Richard Biener wrote:
> On Fri, Nov 13, 2015 at 1:04 PM, Martin Liška wrote:
>> Hello.
>>
>> Following patch fixes PR68311, can regbootstrap on x86_64-linux-gnu.
>>
>> Ready for trunk?
>
> Please use
>
> auto_vec newclasses;
>
> as it gets you a stack allocation.
On 13 November 2015 at 15:52, Jonathan Wakely wrote:
> On 12/11/15 13:39 +, Jonathan Wakely wrote:
>>
>> On 12/11/15 11:40 +, Jonathan Wakely wrote:
>>>
>>> On 18/09/15 12:01 -0400, Jennifer Yao wrote:
Forgot to include the patch.
On Fri, Sep 18, 2015 at 11:17 AM, Jenni
On 14 November 2015 at 17:32, Jonathan Wakely wrote:
> On 14/11/15 09:37 +0100, Christophe Lyon wrote:
>>
>> Hi, this commit makes the GCC build to fail for targets using newlib
>> (I tested arm-none-eabi and aarch64-none-elf)
>>
>> I'm seeing errors such a
On 15 November 2015 at 12:14, Jonathan Wakely wrote:
> On 15/11/15 09:58 +0100, Christophe Lyon wrote:
>>
>> Ha, and my newlib copy is not very recent, it's from Oct 30th 2013:
>> maybe it's too old?
>
>
> The autoconf checks should handle old versions as
On 15 November 2015 at 10:01, Martin Liška wrote:
> On 11/14/2015 09:33 AM, Christophe Lyon wrote:
>> On 13 November 2015 at 13:17, Richard Biener
>> wrote:
>>> On Fri, Nov 13, 2015 at 1:04 PM, Martin Liška wrote:
>>>> Hello.
>>>>
>>>&g
On 13 November 2015 at 17:18, Alan Lawrence wrote:
> On 10/11/15 12:51, Richard Biener wrote:
>>>
>>> Just noticing this... if we have a vectorization factor of 4 and matches
>>> is 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0 then this will split into 1, 1, 1, 1
>>> and
>>> 1, 1, 0, 0, 0, ... where we kn
On 23 November 2015 at 09:07, Jakub Jelinek wrote:
> On Mon, Nov 23, 2015 at 10:46:33AM +0300, Maxim Ostapenko wrote:
>> Index: libsanitizer/configure.ac
>> ===
>> --- libsanitizer/configure.ac (revision 230597)
>> +++ libsanitizer/co
On 23 November 2015 at 13:41, Jakub Jelinek wrote:
> On Mon, Nov 23, 2015 at 03:33:57PM +0300, Maxim Ostapenko wrote:
>> + Adhemerval
>>
>> Christophe, it looks like your kernel headers (asm/ptrace.h) don't contain
>> ARM_VFPREGS_SIZE. Do you use old kernel version?
>
Yes, I do use old kernel hea
On 24 November 2015 at 09:58, Maxim Ostapenko
wrote:
> On 24/11/15 11:38, Jakub Jelinek wrote:
>>
>> On Tue, Nov 24, 2015 at 11:36:20AM +0300, Maxim Ostapenko wrote:
>>>
>>> Ok, does it look better now?
>>
>> Sure, this is ok for trunk.
>>
>>> diff --git a/libsanitizer/ChangeLog b/libsanitizer/Cha
On 24 November 2015 at 10:21, Christophe Lyon
wrote:
> On 24 November 2015 at 09:58, Maxim Ostapenko
> wrote:
>> On 24/11/15 11:38, Jakub Jelinek wrote:
>>>
>>> On Tue, Nov 24, 2015 at 11:36:20AM +0300, Maxim Ostapenko wrote:
>>>>
>>>> Ok,
On 24 November 2015 at 12:12, Jakub Jelinek wrote:
> On Tue, Nov 24, 2015 at 12:08:13PM +0100, Christophe Lyon wrote:
>> > Sure.
>> > I had a build in progress with your proposed patch, but it didn't
>> > complete before you committed :-)
>> >
>>
On 24 November 2015 at 12:57, Jakub Jelinek wrote:
> On Tue, Nov 24, 2015 at 02:55:26PM +0300, Maxim Ostapenko wrote:
>> diff --git a/libsanitizer/ChangeLog b/libsanitizer/ChangeLog
>> index c392c57..895d3bd 100644
>> --- a/libsanitizer/ChangeLog
>> +++ b/libsanitizer/ChangeLog
>> @@ -1,5 +1,10 @@
On 13 November 2015 at 14:36, Christophe Lyon
wrote:
> On 13 November 2015 at 12:24, Kyrill Tkachov wrote:
>>
>> On 13/11/15 11:18, Ramana Radhakrishnan wrote:
>>>>
>>>> Hmm. I hadn't noticed that the crypto intrinsics tests where generated by
&g
res etc... all
this logic is likely to become even more complex.
That being said, OK for trunk?
Christophe
2015-11-27 Christophe Lyon
* lib/target-supports.exp
(check_effective_target_arm_vfp_ok_nocache): New.
(check_effective_target_arm_vfp_ok): Call the new
check
301 - 400 of 3154 matches
Mail list logo
