Re: [PATCH 1/3] [builtins] Generic support for __builtin_load_no_speculate()

On 10/01/18 23:26, Jeff Law wrote: > On 01/08/2018 09:01 AM, Bill Schmidt wrote: >> On Jan 8, 2018, at 8:06 AM, Richard Earnshaw (lists) >> <richard.earns...@arm.com> wrote: >>> >>> On 08/01/18 02:20, Bill Schmidt wrote: >>>> Hi Ri

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On 09/01/18 18:00, Richard Earnshaw (lists) wrote: > On 09/01/18 17:57, Bernd Edlinger wrote: >> On 01/09/18 18:50, Richard Earnshaw (lists) wrote: >>> On 09/01/18 17:36, Bernd Edlinger wrote: >>>> Richard Earnshaw wrote: >>>>   > Let me give an exa

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On 09/01/18 17:57, Bernd Edlinger wrote: > On 01/09/18 18:50, Richard Earnshaw (lists) wrote: >> On 09/01/18 17:36, Bernd Edlinger wrote: >>> Richard Earnshaw wrote: >>>   > Let me give an example, we use the generic code expansion if we >>>   > encounter

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On 09/01/18 17:36, Bernd Edlinger wrote: > Richard Earnshaw wrote: >  > Let me give an example, we use the generic code expansion if we >  > encounter the builtin when generating code for Thumb on pre-ARMv7 >  > devices.  We don't have instructions in 'thumb1' to guard against >  > speculation and

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On 05/01/18 17:26, Jeff Law wrote: > On 01/04/2018 11:20 AM, Joseph Myers wrote: >> On Thu, 4 Jan 2018, Richard Earnshaw wrote: >> >>> 1 - generic modifications to GCC providing the builtin function for all >>> architectures and expanding to an implementation that gives the >>> logical

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On 09/01/18 13:27, Alexander Monakov wrote: > On Tue, 9 Jan 2018, Richard Earnshaw (lists) wrote: >> > Sorry, I don't follow. On ARM, it is surprising that CSEL-CSDB-LDR sequence >> > wouldn't work (applying CSEL to the address rather than loaded value), and >> > if

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On 05/01/18 17:24, Jeff Law wrote: > On 01/04/2018 06:58 AM, Richard Earnshaw wrote: >> >> Recently, Google Project Zero disclosed several classes of attack >> against speculative execution. One of these, known as variant-1 >> (CVE-2017-5753), allows explicit bounds checks to be bypassed under >>

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On 05/01/18 13:08, Alexander Monakov wrote: > On Fri, 5 Jan 2018, Richard Earnshaw (lists) wrote: >> This is quite tricky. For ARM we have to have a speculated load. > > Sorry, I don't follow. On ARM, it is surprising that CSEL-CSDB-LDR sequence > wouldn't work (applying C

Re: [PATCH 1/3] [builtins] Generic support for __builtin_load_no_speculate()

On 08/01/18 16:01, Bill Schmidt wrote: > On Jan 8, 2018, at 8:06 AM, Richard Earnshaw (lists) > <richard.earns...@arm.com> wrote: >> >> On 08/01/18 02:20, Bill Schmidt wrote: >>> Hi Richard, >>> >>> Unfortunately, I don't see any way that this

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On 08/01/18 16:10, Bernd Edlinger wrote: > I thought about your new builtin again, and I wonder if > something like that might work as well? > > > cat despec.s > .arch armv7-a > .eabi_attribute 28, 1 > .eabi_attribute 20, 1 > .eabi_attribute 21, 1 > .eabi_attribute

Re: [PATCH 1/3] [builtins] Generic support for __builtin_load_no_speculate()

On 08/01/18 14:19, Bill Schmidt wrote: > >> On Jan 7, 2018, at 10:47 PM, Jeff Law wrote: >> >> On 01/07/2018 07:20 PM, Bill Schmidt wrote: >>> Hi Richard, >>> >>> Unfortunately, I don't see any way that this will be useful for the ppc >>> targets. We don't >>> have a way to

Re: [PATCH 1/3] [builtins] Generic support for __builtin_load_no_speculate()

On 08/01/18 02:20, Bill Schmidt wrote: > Hi Richard, > > Unfortunately, I don't see any way that this will be useful for the ppc > targets. We don't > have a way to force resolution of a condition prior to continuing > speculation, so this > will just introduce another comparison that we would

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On 05/01/18 11:35, Jakub Jelinek wrote: > On Fri, Jan 05, 2018 at 10:59:21AM +0000, Richard Earnshaw (lists) wrote: >>> But the condition could be just 'true' in the instruction encoding? That >>> is, >>> why do you do both the jump-around and the csel? Maybe I

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On 05/01/18 11:37, Alexander Monakov wrote: > I believe the proposed behavior of the new builtin is over-specialized. > In principle the following snippet may be open to exploitation too: > >   if (predicate) >     foo = arr[(secret >> untrusted) & 64]; > > assuming the attacker has a means to

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On 05/01/18 10:47, Richard Biener wrote: > On Fri, Jan 5, 2018 at 11:40 AM, Richard Earnshaw (lists) > <richard.earns...@arm.com> wrote: >> On 05/01/18 09:44, Richard Biener wrote: >>> On Thu, Jan 4, 2018 at 2:58 PM, Richard Earnshaw >>> <richard.earns...@arm

Re: [PATCH 2/3] [aarch64] Implement support for __builtin_load_no_speculate.

On 05/01/18 09:51, Richard Biener wrote: > On Thu, Jan 4, 2018 at 2:58 PM, Richard Earnshaw > wrote: >> >> This patch implements support for __builtin_load_no_speculate on >> AArch64. On this architecture we inhibit speclation by emitting a >> combination of CSEL and a

Re: [PATCH 0/3] Add __builtin_load_no_speculate

On 05/01/18 09:44, Richard Biener wrote: > On Thu, Jan 4, 2018 at 2:58 PM, Richard Earnshaw > wrote: >> >> Recently, Google Project Zero disclosed several classes of attack >> against speculative execution. One of these, known as variant-1 >> (CVE-2017-5753), allows

[arm] PR target/83105: Minor change of default CPU for arm-linux-gnueabi

When GCC for ARM/linux is configured with --with-float=hard, or --with-float=softfp the compiler will now die when trying to build the support libraries because the baseline architecture is too old to support VFP (older versions of GCC just emitted the VFP instructions anyway, even though they

[arm] PR target/83206: Make native driver select fp-capable armv6 cores

A quirk in the historical naming of some ARMv6 products means that the main CPU name implies the presence or otherwise of the floating point unit. This causes problems when using -mfpu=auto with -mcpu=native: the driver is picking a CPU that does not support a floating-point unit, even though one

[arm] Don't strip off all architecture features from -march passed to assembler

When GCC invokes the assembler it generates a sanitized version of the user-specified -march option to pass through, since the assembler does not understand all the new FPU-related architectural options. Unfortunately it goes too far and strips off all the architectural extensions, including some

[arm] Generate a -mfpu= option for passing to the assembler

When gcc runs with the new -mfpu=auto option (either explicitly or when that's the default behaviour) then this option is not passed through to the assembler as we cannot rely on the assembler understanding it (currently it doesn't understand it at all, but in future that might change). That

Re: [Patch AArch64] Fixup floating point division with -march=armv8-a+nosimd

On 22/11/17 14:53, Ramana Radhakrishnan wrote: > Hi, > > I received a private report from a customer that gcc was putting out > calls to __divdf3 when compiling with +nosimd. When the reciprocal math > support was added this was probably an oversight or a typo. > > The canonical examples is : >

Re: [AArch64] Use aarch64_reg_or_imm instead of nonmemory_operand

On 06/11/17 20:08, Richard Sandiford wrote: > Some of the shift expanders accepted nonmemory_operands but were only > able to handle register_operands or CONST_INTs. This is probably > academic without SVE, since we're not likely to see shifts by other > types of constant (const_wide_ints,

Re: [PATCH PR79868 ][aarch64] Fix error calls in aarch64 code so they can be translated (version 2)

On 31/10/17 16:53, Steve Ellcey wrote: > On Tue, 2017-10-31 at 09:57 +0000, Richard Earnshaw (lists) wrote: >>   >> This is looking better... >> >> I may have missed some discussion on this topic, but what's the >> reasoning behind changing the quoting ar

Re: [PATCH PR79868 ][aarch64] Fix error calls in aarch64 code so they can be translated (version 2)

On 30/10/17 20:50, Steve Ellcey wrote: > On Thu, 2017-10-26 at 13:56 +0100, Richard Earnshaw (lists) wrote: >>   >> I can't help feeling that all this logic is somewhat excessive and >> changing the wording of each message to include "pragma or attribute"

Re: [PATCH PR79868 ][aarch64] Fix error calls in aarch64 code so they can be translated (version 2)

On 26/09/17 00:25, Steve Ellcey wrote: > This is a new version of my patch to fix PR target/79868, where some > error messages are impossible to translate correctly due to how the > strings are dynamically constructed.  It also includes some format > changes in the error messags to make the

Re: [PATCH][AArch64] Wrong type-attribute for stp and str

On 24/10/17 15:54, Dominik Inführ wrote: > >> On 24 Oct 2017, at 11:40, Richard Earnshaw (lists) >> <richard.earns...@arm.com> wrote: >> >> On 23/10/17 17:36, Dominik Inführ wrote: >>> I’ve added your suggestions. I would also like to propose to ch

Re: [PATCH][AArch64] Wrong type-attribute for stp and str

1reg, neon_store1_1reg,\ > - neon_stp, neon_logic, multiple, multiple,\ > + [(set_attr "type" "neon_load1_1reg, store_16, neon_store1_1reg,\ > + neon_logic, multiple, multiple,\ >multiple, neon_move")

Re: [ARM] PR 67591 ARM v8 Thumb IT blocks are deprecated part 2

On 13/10/17 08:41, Christophe Lyon wrote: > Hi, > > The attached small patch solves PR 67591 and removes occurrences of > "IT blocks containing 32-bit Thumb instructions are deprecated in > ARMv8". It is similar to the patch I committed recently and updates > the 3 remaining patterns that can

Re: [PATCH][AArch64] Wrong type-attribute for stp and str

On 16/10/17 14:26, Dominik Inführ wrote: > Hi, > > it seems the type attributes for neon_stp and neon_store1_1reg should be > the other way around. > Yes, I agree, but there's more Firstly, we have two patterns that are named *aarch64_simd_mov, with different iterators. That's slightly

Re: [testsuite] Fix directives order

On 16/10/17 21:45, Christophe Lyon wrote: > Hi, > > I have noticed a few testcases where dg-do should be moved as the > first directive, and others where dg-options should be moved before > dg-add-options. The attached patch does that. I noticed no difference > in testing, at least because the

Re: [PATCH] Fix nrv-1.c false failure on aarch64.

On 20/10/17 13:45, Alexandre Oliva wrote: > On Oct 19, 2017, "Richard Earnshaw (lists)" <richard.earns...@arm.com> > wrote: > >> On 19/10/17 09:14, Richard Biener wrote: >>> I guess Alex work on stmt frontiers will fix this instance? > >> Don't s

[arm] Fix architecture selection when building libatomic with automatic FPU selection

Libatomic builds a few functions for Arm with an explicit -march option. This option does not specify an FPU, which can lead to problems when targeting a hard-float or softfp environment since the architecture appears to be incompatible with the selected ABI. This is some fallout from the move

Re: [PATCH] PR libgcc/59714 complex division is surprising on aarch64

On 19/10/17 14:07, Wilco Dijkstra wrote: > Vladimir wrote: > > +# Disable floating-point expression contraction > +LIBGCC2_FFP_CONTRAST_CFLAGS = -ffp-contract=off > + > > It looks like this disables fp-contract in all of libgcc... > What is the the number of FMAs in libgcc before/after? > > If

[ARM] PR 82445 - suppress 32-bit aligned ldrd/strd peepholing with -mno-unaligned-access

Peephole patterns exist in the arm backend to spot load/store operations to adjacent memory operations in order to convert them into ldrd/strd instructions. However, when we have strict alignment enforced, then we can only do this if the accesses are known to be 64-bit aligned; this is unlikely

Re: [PATCH] Fix nrv-1.c false failure on aarch64.

On 19/10/17 09:14, Richard Biener wrote: > On Wed, Oct 18, 2017 at 6:59 PM, Egeyar Bagcioglu > wrote: >> Hello, >> >> Test case "guality.exp=nrv-1.c" fails on aarch64. Optimizations reorder the >> instructions and cause the value of a variable to be checked before its

Re: [patch][arm] gcc-7-branch: Fix bootstrap on FreeBSD

On 17/10/17 14:00, Kyrill Tkachov wrote: > > On 17/10/17 13:42, Andreas Tobler wrote: >> Hi Kyrill, >> >> On 17.10.17 12:02, Kyrill Tkachov wrote: >> >> > On 16/10/17 20:00, Andreas Tobler wrote: >> >> Hi all, >> >> >> >> I struggled over a bootstrap issue while building gcc-7 for >> >>

Re: [PATCH, GCC/ARM] Allow +nodsp for -mcpu=cortex-m33

On 16/10/17 10:27, Thomas Preudhomme wrote: > Hi, > > DSP instructions are optional for Arm Cortex-M33, yet its -mcpu option > does not allow +nodsp. Users are thus left with using > -march=armv8-m.main -mtune=cortex-m33. This patch allows +nodsp to > -mcpu=cortex-m33. > > ChangeLog entry is as

Re: [PATCH][GCC][Testsuite][ARM][AArch64] Enable Dot Product for generic tests for ARM and AArch64 [Patch (7/8)]

On 06/10/17 13:45, Tamar Christina wrote: > Hi All, > > this is a respin with the changes suggested. Note that this patch is no 8/8 > in the series. > > Regtested on arm-none-eabi, armeb-none-eabi, > aarch64-none-elf and aarch64_be-none-elf with no issues found. > > Ok for trunk? > >

Re: [PATCH][GCC][ARM] Dot Product NEON patterns [Patch (2/8)]

On 06/10/17 13:44, Tamar Christina wrote: > Hi All, > > this is a minor respin with changes echo'd from feedback from aarch64. > I assume still OK for trunk. > > Regtested on arm-none-eabi, armeb-none-eabi, > aarch64-none-elf and aarch64_be-none-elf with no issues found. > > Ok for trunk? > >

Re: [PATCH, ARM] correctly encode the CC reg data flow

On 06/09/17 14:17, Bernd Edlinger wrote: > On 09/06/17 14:51, Richard Earnshaw (lists) wrote: >> On 06/09/17 13:44, Bernd Edlinger wrote: >>> On 09/04/17 21:54, Bernd Edlinger wrote: >>>> Hi Kyrill, >>>> >>>> Thanks for your review! >>&g

Re: [PATCH] Fix PR80295[aarch64] [7/8 Regression] ICE in __builtin_update_setjmp_buf expander

On 06/10/17 20:56, Qing Zhao wrote: > Thanks a lot for Wilco’s help on this bug. > > Yes, Aarch64 does NOT do anything wrong. > > The implementation of __builtin_update_setjmp_buf is not correct. It takes a > pointer > as an operand and treats the Mode of the pointer as Pmode, which is not

Re: [PATCH][GCC][ARM] Dot Product commandline options [Patch (1/8)]

dotprod, ALL_SIMD_INTERNAL): New. > (ALL_FPU_INTERNAL): Use ALL_SIMD_INTERNAL. > * config/arm/t-multilib (v8_2_a_simd_variants): Add dotprod. > * doc/invoke.texi (armv8.2-a): Document dotprod > OK. R. > The 10/06/2017 17:23, Richard Earnshaw (lists) wrote: >&g

Re: [PATCH][GCC][ARM] Dot Product commandline options [Patch (1/8)]

On 06/10/17 13:44, Tamar Christina wrote: > Hi All, > > This is a respin of the patch with the feedback processed. > > Regtested on arm-none-eabi, armeb-none-eabi, > aarch64-none-elf and aarch64_be-none-elf with no issues found. > > Ok for trunk? > > gcc/ > 2017-10-06 Tamar Christina

Re: [PATCH][AArch64] Fix ICE caused in aarch64_simd_valid_immediate

On 06/10/17 12:01, Sudi Das wrote: > > Hi Jakub > > I have modified the entries: > > *** gcc/ChangeLog *** > > 2017-10-05 Sudakshina Das > > PR target/82440 > * config/aarch64/predicates.md (aarch64_reg_or_orr_imm): Changed to > to only call

Re: [PATCH] Fix PR80295[aarch64] [7/8 Regression] ICE in __builtin_update_setjmp_buf expander

On 25/09/17 17:35, Qing Zhao wrote: > Hi, Andreas, > > thanks for the comment. > >> GNU style is line break before the operator, not after. > > updated per your comment. > > Qing. > > --- > gcc/config/aarch64/aarch64.c | 12 +--- > gcc/config/aarch64/aarch64.h

Re: [PATCH v3 7/14] D: Add D language support to GCC targets.

On 02/10/17 10:00, Iain Buclaw wrote: > This patch add D language support to targets of GCC itself. > > Changes since previous are just removing patches for untested target > configurations, these can be re-added later on an as-per basis. > > --- > > > 07-v3-d-gcc-target.patch > > >

Re: [PATCH] Fix PR81422[aarch64] internal compiler error: in update_equiv_regs, at ira.c:3425

On 19/09/17 20:22, Qing Zhao wrote: > Hi, > > This patch fixes the aarch64 bug 81422 > https://gcc.gnu.org/PR81422 > > Before adding REG_EQUIV notes in the TLS symbol handling code, > we should check whether the "dest" is a REG or NOT (sometimes, > it's a SUBREG as in this bug). Only when the

Re: [GCC][PATCH][testsuite][mid-end] Fix failing slp test on aarch64 and arm.

On 02/10/17 14:20, Tamar Christina wrote: > Hi All, > > The slp vectorization test currently fails on AArch32 and AArch64 > due to it not taking into account that we do have 128 bit vectors in > NEON. This means that two of the loops get vectorized instead of just 1. > > So update the conditions

Re: [PATCH][GCC][testsuite][mid-end][ARM][AARCH64] Fix failing vec align tests.

On 02/10/17 14:13, Tamar Christina wrote: > Hi All, > > Previously I had corrected the vect_hw_misalign check which prompted these > three test to start failing because the condition needs to be inverted in the > testcases. > > Regtested on aarch64-none-elf, arm-none-linux-gnueabihf and >

Re: [PATCH] PR target/68256 Defining TARGET_USE_CONSTANT_BLOCKS_P causes go bootstrap failure on aarch64

On 04/10/17 00:50, vladimir.mezent...@oracle.com wrote: > From: Vladimir Mezentsev > > Tested on aarch64-linux-gnu. > No regression. > No bootstrap failure. > > gcc/ChangeLog: > 2017-09-26 Vladimir Mezentsev > > *

Re: [AArch64] Backport to gcc-7 PR71727 fix -mstrict-align

On 04/10/17 14:35, Christophe Lyon wrote: > Hi, > > I've recently committed a follow-up fix for PR71727 for -mstrict-align > on aarch64 (r253242). > I think it would be appropriate to apply it to gcc-7-branch. The patch > from trunk applies cleanly to gcc-7-branch. > > Although the original bug

Re: [PATCH][ARM][GCC] Add a self test for FPU feature bits

On 05/10/17 10:59, Tamar Christina wrote: > Hi All, > > This patch adds a more elaborate self-test to the arm back-end > which tests to make sure you don't have any bit specified in > ISA_ALL_FPU_INTERNAL that are not defined by any fpu configuration. > > Catching this during the self-test

Re: [PATCH][AArch64] Add BIC-imm and ORR-imm SIMD pattern

ic_imm): Likewise. > > > 2017-10-02 Sudakshina Das <sudi@arm.com> > > * gcc.target/aarch64/bic_imm_1.c: New test. > * gcc.target/aarch64/orr_imm_1.c: Likewise. > OK. R. > > From: Richard Earnshaw (lists) <richard.earns...@arm.com> >

Re: Avoid assembler warnings from AArch64 constructor/destructor priorities

On 28/09/17 13:31, Joseph Myers wrote: > Many GCC tests fail for AArch64 with current binutils because of > assembler warnings of the form "Warning: ignoring incorrect section > type for .init_array.00100". The same issue was fixed for ARM in > r247015 by using SECTION_NOTYPE when creating those

Re: [PATCH][AArch64] Add BIC-imm and ORR-imm SIMD pattern

On 27/09/17 18:57, Sudi Das wrote: > > > Hi James > > I have made the requested changes to the patch. > > > 2017-09-27 Sudakshina Das > > * config/aarch64/aarch64-protos.h (enum simd_immediate_check): New > check type > for aarch64_simd_valid_immediate. >

Re: [AArch64] PR71307: Define union class of POINTER+FP

On 18/09/17 17:39, Richard Sandiford wrote: > ALL_REGS doesn't function as a union class of POINTER_REGS and FP_REGS > since it includes the CC register as well. REGNO_REG_CLASS (CC_REGNUM) > is NO_REGS, but of course NO_REGS rightly doesn't include CC_REGNUM. > > Adding a union class for

Re: [PATCH] [testsuite, ARM] Backport to GCC 7 branch

On 21/09/17 09:32, Christophe Lyon wrote: > Hi, > > Can I backport my patch r249639 (Add -mfloat-abi=hard to arm_neon_ok) > to the gcc-7 branch ? > It fixes a few false failures. > > It applies cleanly to current trunk, and we have had it in our > linaro-7-branch for a while. > OK. R. >

Re: [GCC][PATCH][testsuite][mid-end] Fix failing slp test on aarch64 and arm.

On 26/09/17 14:12, Tamar Christina wrote: > Hi All, > > The slp vectorization test currently fails on AArch32 and AArch64 > due to it not taking into account that we do have 128 bit vectors in > NEON. This means that two of the loops get vectorized instead of just 1. > > So update the conditions

[patch] [arm] Fix pr82175 - fix -mcpu=native not working correctly

The new option processing machinery relies on %< rules in the specs to suppress options that are rewritten. Suppression appears to be a two phase process where the option is partially suppressed when %< is processed and then fully suppressed at the end of the string. Strings are separated by

[PATCH 2/2] [arm] Improve error checking in parsecpu.awk

This patch adds a bit more error checking to parsecpu.awk to ensure that statements are not missing arguments or have excess arguments beyond those permitted. It also slightly improves the handling of errors so that we terminate properly if parsing fails and be as helpful as we can while in the

[arm] auto-generate arm-isa.h from CPU descriptions

This patch autogenerates arm-isa.h from new entries in arm-cpus.in. This has the primary advantage that it makes the description file more self-contained, but it also solves the 'array dimensioning' problem that Tamar recently encountered. It adds two new constructs to arm-cpus.in: features and

Re: [PATCH, ARM] correctly encode the CC reg data flow

r wrote: >>>> On 01/13/17 19:28, Bernd Edlinger wrote: >>>>> On 01/13/17 17:10, Bernd Edlinger wrote: >>>>>> On 01/13/17 14:50, Richard Earnshaw (lists) wrote: >>>>>>> On 18/12/16 12:58, Bernd Edlinger wrote: >>>>>

Re: [PATCH][GCC][ARM] Dot Product commandline options [Patch (1/8)]

On 01/09/17 14:19, Tamar Christina wrote: > Hi All, > > This patch adds support for the +dotprod extension to ARM. > Dot Product requires Adv.SIMD to work and so enables this option > by default when enabled. > > It is available from ARMv8.2-a and onwards and is enabled by > default on

Re: [PATCH] Fix PR81921

On 22/08/17 13:55, Kyrill Tkachov wrote: > Hi Richard, > [roping in more aarch64 maintainers] > > On 22/08/17 13:27, Richard Biener wrote: >> On Tue, 22 Aug 2017, Uros Bizjak wrote: >> >>> On Tue, Aug 22, 2017 at 12:15 PM, Richard Biener >>> wrote: The following patch

Re: [AArch64, PATCH] Improve Neon store of zero

atch. R. > On 08/11/2017 02:56 PM, Richard Earnshaw (lists) wrote: > >> On 10/08/17 14:12, Jackson Woodruff wrote: >>> Hi all, >>> >>> This patch changes patterns in aarch64-simd.md to replace >>> >>> moviv0.4s, 0 >>>

Re: [AArch64, PATCH] Improve Neon store of zero

On 10/08/17 14:12, Jackson Woodruff wrote: > Hi all, > > This patch changes patterns in aarch64-simd.md to replace > > moviv0.4s, 0 > strq0, [x0, 16] > > With: > > stp xzr, xzr, [x0, 16] > > When we are storing zeros to vectors like this: > > void f(uint32x4_t *p) { >

Re: [PATCH] Add libgcc support for cache clearing on ARM VxWorks

On 01/08/17 15:31, Olivier Hainque wrote: > Hello, > > On top of previous changes reworking the arm-vxworks support > > https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00085.html > https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00075.html >

Re: gcc behavior on memory exhaustion

On 09/08/17 14:05, Andrew Roberts wrote: > I routinely build the weekly snapshots and RC's, on x64, arm and aarch64. > > The last gcc 8 snapshot and the two recent 7.2 RC's have failed to build > on aarch64 (Raspberry Pi 3, running Arch Linux ARM). I have finally > traced this to the system

Re: [PATCH][Arm] Test suite failures resulting from deprecation of -mstructure-size-boundary

ze boundary > option and fix comment. > * testsuite/gcc.dg/builtin-stringop-chk-1.c: Remove > -mstructure-size boundary option. > > -Original Message- > From: Richard Earnshaw (lists) [mailto:richard.earns...@arm.com] > Sent: Wednesday, August 9, 2017

Re: [PATCH][testsuite] Add check_effective_target_autoincdec

On 09/08/17 12:37, Wilco Dijkstra wrote: > Richard Earnshaw wrote: >> Except that I think this would be better done as an 'effective target' >> test; something like >> >> dg-require-effective-target autoincdec > > Right I figured out how to do this - not trivial as it needs a secret flag in >

Re: [PATCH][Arm] Test suite failures resulting from deprecation of -mstructure-size-boundary

one-elf options. > > If we could just delete the -mstructure-size-boundary=8 option why was it > added in the first place? > Because the comment it out of date. It was added at a time when the default structure size boundard (pre eabi) was 32. R. > -Original Message----- &

Re: [COMMITTED] PR46932: Fix unresolved in testsuite

On 07/08/17 15:42, Wilco Dijkstra wrote: > Richard Earnshaw wrote: >> >> Except that I think this would be better done as an 'effective target' >> test; something like >> >> dg-require-effective-target autoincdec >> >> that way new ports will be more likely to pick up relevant tests like this. >

Re: [COMMITTED] PR46932: Fix unresolved in testsuite

On 07/08/17 14:59, Wilco Dijkstra wrote: > Build only if pre-increment is supported. Given there is no config test, > add a list of targets which have HAVE_PRE_INCREMENT set. > > Committed as obvious. > Except that I think this would be better done as an 'effective target' test; something like

Re: [PATCH][AArch64] Use gen_frame_mem for callee-saves

On 04/08/17 13:24, Wilco Dijkstra wrote: > The frame code uses a mixture of gen_rtx_MEM and gen_frame_mem for > callee-saves. Callee-saves never alias with local variables, so using > gen_frame_mem is correct. Minor cleanup - no change in code. > > OK for commit? OK. R. > > ChangeLog: >

Re: [PATCH, AArch64] Add falkor pipeline description.

On 02/08/17 22:54, Jim Wilson wrote: > This adds a pipeline description for the Qualcomm Falkor core. This was > tested with a bootstrap and make check. There were no regressions. This > gives about 0.5% performance gain on SPEC CPU2006 on our internal tree, which > has a few other patches that

Re: [PATCH][Arm] Test suite failures resulting from deprecation of -mstructure-size-boundary

On 06/08/17 00:25, Michael Collison wrote: > This patch fixes test case failures on arm targets due to > '-mstructure-size-boundary' being deprecated. The test cases were failing > because a warning was being issued and due to the fact that the size of > packed and unpacked structures is the

Re: [PATCH] Switch vec_init and vec_extract optabs to 2 mode optab to allow extraction of vector from vector or initialization of vector from smaller vectors (PR target/80846)

On 25/07/17 10:14, Jakub Jelinek wrote: > Hi! > > The following patch adjusts the vec_init and vec_extract optabs, so that > they don't have in the expander names just the vector mode, but also another > mode, for vec_extract the mode of the result and for vec_init the mode of > the elts of the

Re: [ARM, VXworks] Fix build

On 25/07/17 11:31, Olivier Hainque wrote: > Hi Richard, > > (back from a few days away) > >> On Jul 17, 2017, at 12:01 , Eric Botcazou wrote: >> >>> That's good news. Does that mean we'll be able to drop the old stuff >>> though? I'd really like to make progress towards

Re: [PATCH] Add RDMA support to Falkor.

On 29/06/17 21:53, Jim Wilson wrote: > Falkor is an ARMV8-A part, but also includes the RDMA extension from > ARMV8.1-A. > I'd like to enable support for the RDMA instructions when -mcpu=falkor is > used, > and also make the RDMA intrisics available. To do that, I need to add rdma > as an

Re: [Arm] Obsoleting Command line option -mstructure-size-boundary in eabi configurations

t; * config/arm/arm.c (arm_option_override): Deprecate > use of -mstructure-size-boundary. > * config/arm/arm.opt: Deprecate -mstructure-size-boundary. > * doc/invoke.texi: Deprecate -mstructure-size-boundary. > > -Original Message- > From: Richard Earnshaw (lis

Re: [PATCH][GCC][ARM] Implement a stricter self check.

On 20/07/17 15:57, Tamar Christina wrote: > Hi All, > > This patch makes the self-test for the ARM options validations a bit > stricter. > > When you specify a new architecture extension, neither the options flag in > arm-cpus.in nor the ISA definition in arm.h should contain any other >

Re: [ARM, VXworks] Fix build

On 16/07/17 10:21, Eric Botcazou wrote: >> The port is also *very* out-of-date. Not only does it not use the EABI, >> but it hasn't had support for any core added since ARMv5 (and ARMv6 was >> announced in 2002)! > > What do you mean exactly? The port works fine on ARMv7. What I said. looking

Re: [PATCH, GCC/ARM] Rewire -mfpu=fp-armv8 as VFPv5 + D32 + DP

On 14/07/17 09:20, Thomas Preudhomme wrote: > Hi, > > fp-armv8 is currently defined as a double precision FPv5 with 32 D > registers *and* a special FP_ARMv8 bit. However FP for ARMv8 should only > bring 32 D registers on top of FPv5-D16 so this FP_ARMv8 bit is > spurious. As a consequence, many

[ARM, VXworks] Fix build

My patch last week to address selection of be8 linking mode broke the build for vxworks. It turns out that this port is one of the few remaining that is still not based on the EABI/AAPCS. This patch fixes the build, but I've not really tested it beyond building the core compiler binaries.

Re: AARCH64 vs SLOW_BYTE_ACCESS

On 11/07/17 05:16, Andrew Pinski wrote: > I was looking into some bitfield code for aarch64 and was wondering > why SLOW_BYTE_ACCESS is set to 0. I can't seem to figure out why > though. > The header says: >Although there's no difference in instruction count or cycles, > in AArch64 we don't

Re: [PATCH][Aarch64] Relational compare zero not merged into subtract

On 02/06/17 00:54, Michael Collison wrote: > This patch improves code generation for relational compares against zero that > are not merged into a subtract instruction. This patch improves the >= and < > cases. > > An example of the '<' case: > > int lt (int x, int y) > { > if ((x - y) < 0)

Re: [PATCH, GCC/ARM] Remove ARMv8-M code for D17-D31

On 06/07/17 13:36, Thomas Preudhomme wrote: > Hi Richard, > > On 28/06/17 16:56, Richard Earnshaw (lists) wrote: > >>> >> >> This is silently baking in dangerous assumptions about GCC's internal >> numbering of the registers. That's not a good idea from

Re: [PATCH v11] add -fpatchable-function-entry=N,M option

On 06/07/17 15:03, Torsten Duwe wrote: > Permit A 38 > > gcc/c-family/ChangeLog > 2017-07-06 Torsten Duwe > > * c-attribs.c (c_common_attribute_table): Add entry for > "patchable_function_entry". > > gcc/lto/ChangeLog > 2017-07-06 Torsten Duwe > >

Re: [PATCH 2/3, GCC/ARM] Add support for ARMv8-R architecture

On 06/07/17 13:40, Thomas Preudhomme wrote: > Please find an updated patch in attachment. ChangeLog entry are now as > follows: > > *** gcc/ChangeLog *** > > 2017-07-06 Thomas Preud'homme > > * config/arm/arm-cpus.in (armv8-r): Add new entry. > *

Re: [Arm] Obsoleting Command line option -mstructure-size-boundary in eabi configurations

On 06/07/17 06:46, Michael Collison wrote: > NetBSD/Arm requires that DEFAULT_STRUCTURE_SIZE_BOUNDARY (see > config/arm/netbsd-elf.h for details). This patch disallows > -mstructure-size-boundary on netbsd if the value is not equal to the > DEFAULT_STRUCTURE_SIZE_BOUNDARY. > > Okay for trunk?

[arm] Fix warning in parsecpu.awk

In awk, single quotes within a quoted string do not need escaping. The existing code causes awk to grumble in the build logs. * config/arm/parsecpu.awk (gen_comm_data): Do not escape single quotes in quoted strings. Committed. R. diff --git a/gcc/config/arm/parsecpu.awk

[arm] Fix cross-native builds

The patch I committed yesterday to remove some generated headers from the source tree unfortunately has a dependency missing that is only revealed when doing a cross-native or full Canadian cross build. The gen* programs were missing a dependency on one of the generated headers. Fixed by adding

Re: [PATCH][Aarch64] Add support for overflow add and sub operations

pred-reg = cond-op (A, B) makes sense, but not on ARM or AArch64. R. > > Regards, > > Michael Collison > > -Original Message- > From: Richard Earnshaw (lists) [mailto:richard.earns...@arm.com] > Sent: Wednesday, July 5, 2017 2:38 AM > To: Michael Collis

Re: [PATCH v10] add -fpatchable-function-entry=N,M option

On 05/07/17 16:38, Sandra Loosemore wrote: > On 07/05/2017 01:36 AM, Torsten Duwe wrote: >> Changes since v9: >> >> * Do not store (declare static) the nop pattern template string. >>In the future, it might depend on the particular function >>being emitted. Fetch it freshly each time

[ARM] Implement TARGET_FIXED_CONDITION_CODE_REGS

This patch implements TARGET_FIXED_CONDITION_CODE_REGS on ARM. We have two main cases to consider: in Thumb1 code there are no condition code registers, so we simply return false. For other cases we set the the first pointer to CC_REGNUM and the second to VFPCC_REGNUM iff generating hard-float

Re: [PATCH][Aarch64] Add support for overflow add and sub operations

On 19/05/17 22:11, Michael Collison wrote: > Christophe, > > I had a type in the two test cases: "addcs" should have been "adcs". I caught > this previously but submitted the previous patch incorrectly. Updated patch > attached. > > Okay for trunk? > Apologies for the delay responding, I've

Re: [PATCH][AArch64] Fix strict aliasing issue in gcc.target/aarch64/simd/vminmaxnm_1.c

On 04/07/17 15:39, Kyrill Tkachov wrote: > Hi all, > > While doing some unrelated work the > gcc.target/aarch64/simd/vminmaxnm_1.c testcase started failing for me. > Upon investigation it turns out that it breaks the C strict aliasing > rules in the CHECK macro by casting > a pointer to an

[PATCH][arm] Move some generated files out of the source tree

When I originally started work on the new options framework for ARM I'd worked on the assumption that AWK might not be available on every build machine (only on developer's machines). However, looking again I notice that all the options framework relies on it being present for every build. This

Re: [PATCH v9] add -fpatchable-function-entry=N,M option

On 04/07/17 14:14, Torsten Duwe wrote: > On Tue, Jul 04, 2017 at 12:02:47PM +0100, Richard Earnshaw (lists) wrote: >> On 13/06/17 18:00, Torsten Duwe wrote: >>> Changes since v8: >>> >>> * Documentation changes as requested by Sandra >>> * 3 fu

<    3   4   5   6   7   8   9   10   11   12   >