aarch64 - PR target/86887 Fix missing register constraints in carryin patterns

Some of the carryin insn patterns are missing a register constraint. That means that the register allocator can pick practically anything to hold that value, including memory locations, or registers of the wrong class. PR target/86887 * config/aarch64/aarch64.md

Re: dejagnu version update?

On 08/08/18 12:17, Bernhard Reutner-Fischer wrote: > On 7 August 2018 18:34:30 CEST, Segher Boessenkool > wrote: >> On Mon, Aug 06, 2018 at 08:25:49AM -0700, Mike Stump wrote: >>> Since g++ already requires 1.5.3, it make no sense to bump to >> anything older that 1.5.3, so let's bump to 1.5.3.

Re: dejagnu version update?

On 08/08/18 12:17, Bernhard Reutner-Fischer wrote: > On 7 August 2018 18:34:30 CEST, Segher Boessenkool > wrote: >> On Mon, Aug 06, 2018 at 08:25:49AM -0700, Mike Stump wrote: >>> Since g++ already requires 1.5.3, it make no sense to bump to >> anything older that 1.5.3, so let's bump to 1.5.3.

Fix PR number in hppa commit for CVE-2017-5753)

This just fixes the PR number in the ChangeLog. Nothing we can do about the SVN history. gcc/ChangeLog Committed as obvious. Index: ChangeLog === --- ChangeLog (revision 263357) +++ ChangeLog (working copy) @@ -9,7 +9,7 @@

Re: [PATCH 00/11] (v2) Mitigation against unsafe data speculation (CVE-2017-5753)

On 06/08/18 22:52, John David Anglin wrote: > On 2018-08-03 5:06 AM, Richard Earnshaw (lists) wrote: >>> I don't think there's a suitable barrier.  The sync instruction seems >>> like overkill. >>> >>> So, I'm going to install attached change after tes

Re: [PATCH 02/11] Arm - add speculation_barrier pattern

On 06/08/18 15:00, Christophe Lyon wrote: > On Fri, 27 Jul 2018 at 11:38, Richard Earnshaw > wrote: >> >> >> This patch defines a speculation barrier for AArch32. >> >> * config/arm/unspecs.md (unspecv): Add VUNSPEC_SPECULATION_BARRIER. >> * config/arm/arm.md

Re: [PATCH][GCC][AARCH64] Use STLUR for atomic_store

On 02/08/18 17:26, matthew.malcom...@arm.com wrote: > Use the STLUR instruction introduced in Armv8.4-a. > This insruction has the store-release semantic like STLR but can take a > 9-bit unscaled signed immediate offset. > > Example test case: > ``` > void > foo () > { > int32_t *atomic_vals

Re: [PATCH 00/11] (v2) Mitigation against unsafe data speculation (CVE-2017-5753)

On 02/08/18 21:19, John David Anglin wrote: > On 2018-08-02 2:40 PM, Jeff Law wrote: >> It's been eons.   I think there's enough building blocks on the PA to >> mount a spectre v1 attack.  They've got branch prediction with varying >> degress of speculative execution, caches and user accessable

Re: [Patch-86512]: Subnormal float support in armv7(with -msoft-float) for intrinsics

On 27/07/18 17:45, Nicolas Pitre wrote: > On Fri, 27 Jul 2018, Wilco Dijkstra wrote: > >> Nicolas Pitre wrote: >> However if r4 is non-zero, the carry will be set, and the tsths will be executed. This clears the carry and sets the Z flag based on bit 20. >>> >>> No, not at all.

Re: [gen/AArch64] Generate helpers for substituting iterator values into pattern names

On 13/07/18 10:15, Richard Sandiford wrote: > Given a pattern like: > > (define_insn "aarch64_frecpe" ...) > > the SVE ACLE implementation wants to generate the pattern for a > particular (non-constant) mode. This patch automatically generates > helpers to do that, specifically: > > //

Re: [PATCH] Print default options selection for -march,-mcpu and -mtune for aarch64 (PR driver/83193).

On 18/07/18 16:48, Martin Liška wrote: > Hi. > > This is aarch64 fix for PR83193. It's about setting of default options > so that --help=target -Q prints proper numbers: > > Now this is seen on my cross-compiler: > > --- /home/marxin/Downloads/options-2-before.txt 2018-07-18 >

Re: [AArch64] Generate load-pairs when the last load clobbers the address register [2/2]

On 19/07/18 11:03, Jackson Woodruff wrote: > Hi Richard, > > > On 07/12/2018 05:35 PM, Richard Earnshaw (lists) wrote: >> On 11/07/18 17:48, Jackson Woodruff wrote: >>> Hi Sudi, >>> >>> On 07/10/2018 02:29 PM, Sudakshina Das wrote: >>>> H

Re: [PATCH 01/11] Add __builtin_speculation_safe_value

On 01/08/18 09:54, Jakub Jelinek wrote: > On Wed, Aug 01, 2018 at 09:48:50AM +0100, Richard Earnshaw (lists) wrote: >> Sorry about that, I did run a full bootstrap on x86, but I had the x86 >> mitigation patch applied, so it didn't trip this. > > Also, I see > FAIL: c-c++

Re: [PATCH 01/11] Add __builtin_speculation_safe_value

On 31/07/18 21:51, Ian Lance Taylor via gcc-patches wrote: > On Tue, Jul 31, 2018 at 12:25 PM, H.J. Lu wrote: >> On Mon, Jul 30, 2018 at 6:16 AM, Richard Biener wrote: >>> On Fri, 27 Jul 2018, Richard Earnshaw wrote: >>> This patch defines a new intrinsic function

Re: [PATCH] combine: Allow combining two insns to two insns

On 31/07/18 14:57, Segher Boessenkool wrote: > Hi Christophe, > > On Tue, Jul 31, 2018 at 02:34:06PM +0200, Christophe Lyon wrote: >> Since this was committed, I've noticed regressions >> on aarch64: >> FAIL: gcc.dg/zero_bits_compound-1.c scan-assembler-not \\(and: > > This went from >

Re: [PATCH 01/11] Add __builtin_speculation_safe_value

On 27/07/18 13:11, Nathan Sidwell wrote: > + if (!COMPLETE_TYPE_P (type)) > +goto incompatible; > > Are incomplete integral types a thing? (forward enum extension?) > I don't think so, at least not at the level of having an instance of such a type (as opposed to a pointer to one). Enums,

Re: [PATCH 01/11] Add __builtin_speculation_safe_value

On 27/07/18 13:11, Nathan Sidwell wrote: > On 07/27/2018 05:37 AM, Richard Earnshaw wrote: > > +/* Work out the size of the first argument of a call to > +   __builtin_speculation_safe_value.  Only pointers and integral types > +   are permitted.  Return -1 if the argument type is not supported

Re: [PATCH 1/7] Add __builtin_speculation_safe_value

On 27/07/18 01:46, Paul Koning wrote: > > >> On Jul 26, 2018, at 7:34 PM, Joseph Myers wrote: >> >> On Wed, 25 Jul 2018, Richard Earnshaw (lists) wrote: >> >>>>> Port maintainers DO need to decide what to do about speculation, even if >&g

Re: [PATCH 1/7] Add __builtin_speculation_safe_value

On 26/07/18 13:41, Richard Biener wrote: > On Thu, Jul 26, 2018 at 12:03 PM Richard Earnshaw (lists) > wrote: >> >> On 25/07/18 14:47, Richard Biener wrote: >>> On Wed, Jul 25, 2018 at 2:41 PM Richard Earnshaw (lists) >>> wrote: >>>> >>&g

Re: [PATCH 1/7] Add __builtin_speculation_safe_value

On 25/07/18 14:47, Richard Biener wrote: > On Wed, Jul 25, 2018 at 2:41 PM Richard Earnshaw (lists) > wrote: >> >> On 25/07/18 11:36, Richard Biener wrote: >>> On Wed, Jul 25, 2018 at 11:49 AM Richard Earnshaw (lists) >>> wrote: >>>> >>&g

Re: [PATCH 1/7] Add __builtin_speculation_safe_value

On 24/07/18 18:26, Richard Biener wrote: > So, please make resolve_overloaded_builtin return a no-op on such targets > which means you can remove the above warning. Maybe such targets > shouldn't advertise / initialize the builtins at all? So I tried to make resolve_overloaded_builtin collapse

Re: [PATCH 1/7] Add __builtin_speculation_safe_value

On 25/07/18 11:36, Richard Biener wrote: > On Wed, Jul 25, 2018 at 11:49 AM Richard Earnshaw (lists) > wrote: >> >> On 24/07/18 18:26, Richard Biener wrote: >>> On Mon, Jul 9, 2018 at 6:40 PM Richard Earnshaw >>> wrote: >>>> >&

Re: [Patch] [Aarch64] PR 86538 - Define __ARM_FEATURE_LSE if LSE is available

On 24/07/18 22:55, Steve Ellcey wrote: > On Tue, 2018-07-24 at 22:04 +0100, James Greenhalgh wrote: >>   >> >> I'd say this patch isn't desirable for trunk. I'd be interested in use cases >> that need a static decision on presence of LSE that are not better expressed >> using higher level language

Re: [PATCH 1/7] Add __builtin_speculation_safe_value

On 24/07/18 18:26, Richard Biener wrote: > On Mon, Jul 9, 2018 at 6:40 PM Richard Earnshaw > wrote: >> >> >> This patch defines a new intrinsic function >> __builtin_speculation_safe_value. A generic default implementation is >> defined which will attempt to use the backend pattern >>

Re: GCC 8.2 Status Report (2018-07-19), branch frozen for release

On 24/07/18 17:30, Richard Biener wrote: > On July 24, 2018 5:50:33 PM GMT+02:00, Ramana Radhakrishnan > wrote: >> On Thu, Jul 19, 2018 at 10:11 AM, Richard Biener >> wrote: >>> >>> Status >>> == >>> >>> The GCC 8 branch is frozen for preparation of the GCC 8.2 release. >>> All changes to

Re: GCC 8.2 Status Report (2018-07-19), branch frozen for release

On 24/07/18 17:30, Richard Biener wrote: > On July 24, 2018 5:50:33 PM GMT+02:00, Ramana Radhakrishnan > wrote: >> On Thu, Jul 19, 2018 at 10:11 AM, Richard Biener >> wrote: >>> >>> Status >>> == >>> >>> The GCC 8 branch is frozen for preparation of the GCC 8.2 release. >>> All changes to

Re: [PATCH 6/7] AArch64 - new pass to add conditional-branch speculation tracking

[sorry, missed this mail somehow] On 11/07/18 22:01, Jeff Law wrote: > On 07/09/2018 10:38 AM, Richard Earnshaw wrote: >> This patch is the main part of the speculation tracking code. It adds >> a new target-specific pass that is run just before the final branch >> reorg pass (so that it can

Re: [PATCH 1/7] Add __builtin_speculation_safe_value

Ping. This patch needs reviewing an appropriate maintainer. I'm aware that the documentation needs extending a bit to provide some example use cases as discussed in the follow-up to the generic discussion, but the rest of the patch still stands. R. On 09/07/18 17:38, Richard Earnshaw wrote: >

Re: [PATCH] Prototype of hook for possible list of option values.

On 20/07/18 12:06, Martin Liška wrote: > On 07/20/2018 12:58 PM, Richard Earnshaw (lists) wrote: >> Modifiers are context dependent. The architecture implies which >> modifiers can be applied (and what they mean in detail, so, for example, >> +fp means enable the default f

Re: That light at the end of the tunnel?

On 21/07/18 03:04, Eric S. Raymond wrote: > That light at the end of the tunnel turned out to be an oncoming train. > > Until recently I thought the conversion was near finished. I'd had > verified clean conversions across trunk and all branches, except for > one screwed-up branch that the

Re: [Patch-86512]: Subnormal float support in armv7(with -msoft-float) for intrinsics

So why is this only changing the double-precision implementation? Surely, a problem like this will normally be common to both SP and DP floating-point computations. R. On 23/07/18 08:46, Umesh Kalappa wrote: > Thank you Wilco for the inputs and we agree that the fix break down > for the case. >

Re: [PATCH] Prototype of hook for possible list of option values.

On 20/07/18 11:54, Martin Liška wrote: > On 07/20/2018 12:25 PM, Richard Earnshaw (lists) wrote: >> On 20/07/18 11:14, Martin Liška wrote: >>> On 07/20/2018 11:48 AM, Richard Earnshaw (lists) wrote: >>>> On 20/07/18 09:04, Martin Liška wrote: >>>>>

Re: [PATCH] Prototype of hook for possible list of option values.

On 20/07/18 11:14, Martin Liška wrote: > On 07/20/2018 11:48 AM, Richard Earnshaw (lists) wrote: >> On 20/07/18 09:04, Martin Liška wrote: >>> Hi. >>> >>> I'm sending patch candidate with suggested target common hook. It allows a >>> target >>

Re: [PATCH] Prototype of hook for possible list of option values.

On 20/07/18 09:04, Martin Liška wrote: > Hi. > > I'm sending patch candidate with suggested target common hook. It allows a > target > to list all possible values for an option. Using the API, I implemented > -march and > -mtune option listing on i386. > > Richard you asked about the values.

Re: [RFC] Adding Python as a possible language and it's usage

On 19/07/18 12:30, Florian Weimer wrote: > * Segher Boessenkool: > >> What would the advantage of using Python be? I haven't heard any yet. >> Awk may be a bit clunky but at least it is easily readable for anyone. > > I'm not an experienced awk programmer, but I don't think plain awk > supports

Re: [PATCH] Show valid options for -march and -mtune in --help=target for arm32 (PR driver/83193).

On 19/07/18 11:22, Martin Liška wrote: > On 07/19/2018 12:01 PM, Richard Earnshaw (lists) wrote: >> On 19/07/18 10:56, Martin Liška wrote: >>> On 07/19/2018 11:28 AM, Richard Earnshaw (lists) wrote: >>>> On 19/07/18 08:30, Martin Liška wrote: >>>>> This

Re: [PATCH] Show valid options for -march and -mtune in --help=target for arm32 (PR driver/83193).

On 19/07/18 10:56, Martin Liška wrote: > On 07/19/2018 11:28 AM, Richard Earnshaw (lists) wrote: >> On 19/07/18 08:30, Martin Liška wrote: >>> This is correct version of the patch. Anyway, I'm thinking about the >>> ForceHelp >>> attribute. I may do it in a b

Re: [PATCH] Show valid options for -march and -mtune in --help=target for arm32 (PR driver/83193).

On 19/07/18 08:30, Martin Liška wrote: > This is correct version of the patch. Anyway, I'm thinking about the ForceHelp > attribute. I may do it in a bit different version. Let me come up with one > another > version of the patch. > > Martin > I don't understand how this is supposed to work.

Re: [RFC] Adding Python as a possible language and it's usage

On 18/07/18 10:51, Richard Biener wrote: > On Tue, Jul 17, 2018 at 2:49 PM Martin Liška wrote: >> >> Hi. >> >> I've recently touched AWK option generate machinery and it's quite unpleasant >> to make any adjustments. My question is simple: can we starting using a >> scripting >> language like

Re: [GCC][PATCH][Aarch64] Exploiting BFXIL when OR-ing two AND-operations with appropriate bitmasks

On 17/07/18 02:33, Richard Henderson wrote: > On 07/16/2018 10:10 AM, Sam Tebbs wrote: >> +++ b/gcc/config/aarch64/aarch64.c >> @@ -1439,6 +1439,14 @@ aarch64_hard_regno_caller_save_mode (unsigned regno, >> unsigned, >> return SImode; >> } >> >> +/* Implement IS_LEFT_CONSECUTIVE. Check

Re: Avoid assembler warnings from AArch64 constructor/destructor priorities

On 17/07/18 12:09, Kyrill Tkachov wrote: > > On 02/02/18 15:14, Kyrill Tkachov wrote: >> >> On 01/02/18 17:26, Joseph Myers wrote: >>> On Thu, 1 Feb 2018, Kyrill  Tkachov wrote: >>> Hi Joseph, aarch64 maintainers, On 28/09/17 13:31, Joseph Myers wrote: > Many GCC tests fail for

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

arm - Add vendor and CPU id information to arm-cpus.in

This patch moves the vendor and CPU id data from driver-arm.c to the main table of CPU data in arm-cpus.in. It then adds rules to parsecpu.awk to build data tables that can be used by the driver for automatic CPU detection when running natively. This is the last major bit of CPU-specific data

Re: [PATCH][wwwdocs] Mention Cortex-A76 support in GCC 9 changes.html

On 13/07/18 00:26, Gerald Pfeifer wrote: > On Fri, 29 Jun 2018, Kyrill Tkachov wrote: >> This patch adds support for the Arm Cortex-A76 processor in changes.html >> for GCC 9. It enables the AArch64 section of the page and adds the news >> blob there. It also adds an entry to the

Re: [AArch64] Generate load-pairs when the last load clobbers the address register [2/2]

On 11/07/18 17:48, Jackson Woodruff wrote: > Hi Sudi, > > On 07/10/2018 02:29 PM, Sudakshina Das wrote: >> Hi Jackson >> >> >> On Tuesday 10 July 2018 09:37 AM, Jackson Woodruff wrote: >>> Hi all, >>> >>> This patch resolves PR86014.  It does so by noticing that the last >>> load may clobber the

Re: [Patch AArch64] Add early clobber for the store_exclusive patterns.

On 12/07/18 15:22, Ramana Radhakrishnan wrote: > Hi, > > > I've had this in my patch stack after discovering the gas issue where we > weren't warning on cases that were unpredictable according to the > architecture. > > I would like to backport this fix to earlier GCC branches too. I did a >

Re: [AArch64] Use arrays and loops rather than numbered variables in aarch64_operands_adjust_ok_for_ldpstp [1/2]

On 11/07/18 17:48, Jackson Woodruff wrote: > Hi Sudi, > > Thanks for the review. > > > On 07/10/2018 10:56 AM, Sudakshina wrote: >> Hi Jackson >> >> >> -  if (!MEM_P (mem_1) || aarch64_mem_pair_operand (mem_1, mode)) >> +  if (!MEM_P (mem[1]) || aarch64_mem_pair_operand (mem[1], mode)) >> >>

Re: [PATCH 0/7] Mitigation against unsafe data speculation (CVE-2017-5753)

On 11/07/18 21:46, Jeff Law wrote: > On 07/10/2018 10:43 AM, Richard Earnshaw (lists) wrote: >> On 10/07/18 16:42, Jeff Law wrote: >>> On 07/10/2018 02:49 AM, Richard Earnshaw (lists) wrote: >>>> On 10/07/18 00:13, Jeff Law wrote: >>>>> O

[arm] Put CPU's FPU capabilities directly in the ISA specification

As part of the transition from the original support for named FPUs to general FPU properties I defined an entry in the CPU definitions in arm-cpus.in to use a named FPU. However, that has now outlived its usefulness and increasingly we are likely to find that newer cores do not fit the legacy FPU

Re: [PATCH, contrib] Add contrib/maintainers-verify.sh

On 12/06/18 11:03, Tom de Vries wrote: > [ Fixed ENOPATCH ] > > On Tue, Jun 12, 2018 at 11:57:13AM +0200, Tom de Vries wrote: >> [ was: Re: [MAINTAINERS, committed] Remove redundant write-after-approval >> entries ] >> >> On Tue, Jun 12, 2018 at 10:26:31AM +0200, Martin Liška wrote: >>> Hi. >>>

Re: [Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests

te: >>> On 06.07.2018 15:26, Richard Earnshaw (lists) wrote: >>>> On 06/07/18 12:11, Kamil Rytarowski wrote: >>>>> On 06.07.2018 12:38, Richard Earnshaw (lists) wrote: >>>>>> On 06/07/18 11:32, Kamil Rytarowski wrote: >>>>>>> On 04.0

Re: [Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests

On 10/07/18 10:57, Kamil Rytarowski wrote: > On 06.07.2018 15:26, Richard Earnshaw (lists) wrote: >> On 06/07/18 12:11, Kamil Rytarowski wrote: >>> On 06.07.2018 12:38, Richard Earnshaw (lists) wrote: >>>> On 06/07/18 11:32, Kamil Rytarowski wrote: >>>>

Re: [PATCH 0/7] Mitigation against unsafe data speculation (CVE-2017-5753)

On 10/07/18 16:42, Jeff Law wrote: > On 07/10/2018 02:49 AM, Richard Earnshaw (lists) wrote: >> On 10/07/18 00:13, Jeff Law wrote: >>> On 07/09/2018 10:38 AM, Richard Earnshaw wrote: >>>> >>>> To address all of the above, these patches adopt a new

Re: [PATCH 0/7] Mitigation against unsafe data speculation (CVE-2017-5753)

On 10/07/18 14:48, Bill Schmidt wrote: > >> On Jul 10, 2018, at 3:49 AM, Richard Earnshaw (lists) >> wrote: >> >> On 10/07/18 00:13, Jeff Law wrote: >>> On 07/09/2018 10:38 AM, Richard Earnshaw wrote: >>>> >>>> The patches I posted

Re: [PATCH 0/7] Mitigation against unsafe data speculation (CVE-2017-5753)

On 10/07/18 12:21, Richard Biener wrote: > On Tue, Jul 10, 2018 at 12:53 PM Richard Earnshaw (lists) > wrote: >> >> On 10/07/18 11:10, Richard Biener wrote: >>> On Tue, Jul 10, 2018 at 10:39 AM Richard Earnshaw (lists) >>> wrote: >>>> >>&g

Re: [PATCH 0/7] Mitigation against unsafe data speculation (CVE-2017-5753)

On 10/07/18 11:10, Richard Biener wrote: > On Tue, Jul 10, 2018 at 10:39 AM Richard Earnshaw (lists) > wrote: >> >> On 10/07/18 08:19, Richard Biener wrote: >>> On Mon, Jul 9, 2018 at 6:39 PM Richard Earnshaw >>> wrote: >>>> >>>> >&g

Re: [PATCH 0/7] Mitigation against unsafe data speculation (CVE-2017-5753)

On 10/07/18 00:13, Jeff Law wrote: > On 07/09/2018 10:38 AM, Richard Earnshaw wrote: >> >> The patches I posted earlier this year for mitigating against >> CVE-2017-5753 (Spectre variant 1) attracted some useful feedback, from >> which it became obvious that a rethink was needed. This mail, and

Re: [PATCH 0/7] Mitigation against unsafe data speculation (CVE-2017-5753)

On 10/07/18 08:19, Richard Biener wrote: > On Mon, Jul 9, 2018 at 6:39 PM Richard Earnshaw > wrote: >> >> >> The patches I posted earlier this year for mitigating against >> CVE-2017-5753 (Spectre variant 1) attracted some useful feedback, from >> which it became obvious that a rethink was

Re: [Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests

On 06/07/18 12:11, Kamil Rytarowski wrote: > On 06.07.2018 12:38, Richard Earnshaw (lists) wrote: >> On 06/07/18 11:32, Kamil Rytarowski wrote: >>> On 04.07.2018 20:55, rearnsha at gcc dot gnu.org wrote: >>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383 >>

Re: [Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests

On 06/07/18 11:32, Kamil Rytarowski wrote: > On 04.07.2018 20:55, rearnsha at gcc dot gnu.org wrote: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383 >> >> --- Comment #2 from Richard Earnshaw --- >> I'm not sure how relevant the netbsd-elf port is these days. I believe >> they've >> now

Re: [PATCH][wwwdocs] Mention Cortex-A76 support in GCC 9 changes.html

On 29/06/18 14:29, Kyrill Tkachov wrote: > Hi all, > > This patch adds support for the Arm Cortex-A76 processor in changes.html > for GCC 9. > It enables the AArch64 section of the page and adds the news blob there. > It also adds an entry to the already-existing arm entry. > > Ok to commit to

Re: [PATCH][ARM] Use __ARM_ARCH instead of __ARM_ARCH__

On 15/06/18 15:30, Christophe Lyon wrote: > Hello, > > As suggested in [1], the attached patch removes all definitions and > uses of __ARM_ARCH__ and uses __ARM_ARCH instead. The later is indeed > defined by the preprocessor to the appropriate value. > > I ran make check on arm-none-eabi (with

Re: Vectorizer size preferences (-mprefer-* on x86)

On 15/06/18 12:48, Richard Biener wrote: > > Hi, > > I'm in the process of changing the vectorizer to consider all > vector sizes as advertised by targetm.autovectorize_vector_sizes > and to decide which one to use based on its cost model. > > I expect that to make sense for example when

Re: [ARM/FDPIC 06/21] [ARM] FDPIC: Add support for c++ exceptions

On 08/06/18 11:15, Kyrill Tkachov wrote: > Hi Christophe, > > On 25/05/18 09:03, Christophe Lyon wrote: >> When restoring a function address, we also have to restore the FDPIC >> register value (r9). >> >> 2018-XX-XX  Christophe Lyon  >>     Mickaël Guêné >> >>     gcc/ >>     *

Re: code-gen options for disabling multi-operand AArch64 and ARM instructions

On 07/06/18 10:46, Richard Biener wrote: > On Thu, Jun 7, 2018 at 11:45 AM Ard Biesheuvel > wrote: >> >> On 7 June 2018 at 11:35, Richard Biener wrote: >>> On Thu, Jun 7, 2018 at 10:45 AM Ard Biesheuvel >>> wrote: On 7 June 2018 at 10:21, Christoffer Dall wrote: > On Thu, Jun 07,

[arm] PR target/86003 build failures with --with-cpu=xscale

The XScale cpu configuration in GCC has always been somewhat non-conforming. Although XScale isn't an architecture (it's simply an implementation of ARMv5te), we do by tradition emit a specific pre-define for it. We achieve this effect by adding an additional feature bit to the xscale CPU

Re: [PATCH] testsuite: Introduce be/le selectors

On 24/05/18 18:28, Segher Boessenkool wrote: > On Wed, May 23, 2018 at 10:07:18AM +0100, Richard Earnshaw (lists) wrote: >> On 22/05/18 22:21, Jeff Law wrote: >>> On 05/21/2018 03:46 PM, Segher Boessenkool wrote: >>>> This patch creates "be" and

Re: [PATCH][arm][2/2] Remove support for -march=armv3 and older

On 23/05/18 16:26, Kyrill Tkachov wrote: > > On 21/05/18 12:29, Kyrill Tkachov wrote: >> >> On 18/05/18 11:33, Richard Earnshaw (lists) wrote: >>> On 17/05/18 11:26, Kyrill Tkachov wrote: >>>> Hi all, >>>> >>>> We deprecated architec

Re: [PATCH] testsuite: Introduce be/le selectors

On 22/05/18 22:21, Jeff Law wrote: > On 05/21/2018 03:46 PM, Segher Boessenkool wrote: >> This patch creates "be" and "le" selectors, which can be used by all >> architectures, similar to ilp32 and lp64. >> >> Is this okay for trunk? >> >> >> Segher >> >> >> 2017-05-21 Segher Boessenkool

Re: [PATCH 1/2][Aarch64] Improve FP to int conversions

On 18/05/18 21:34, Michael Collison wrote: > This patch improves additional cases of FP to integer conversions. > > Example 1: > > unsigned long > f7 (double x) > { > return (unsigned) y; > } > > > At -O2 > > Trunk generates: > > f7: > fcvtzu w0, d0 > uxtwx0, w0 >

Re: [PATCH][GCC][AArch64] Correct 3 way XOR instructions adding missing patterns.

On 30/04/18 15:12, Tamar Christina wrote: > Hi All, > > This patch adds the missing neon intrinsics for all 128 bit vector Integer > modes for the > three-way XOR and negate and xor instructions for Arm8.2-a to Armv8.4-a. > > Bootstrapped and regtested on aarch64-none-linux-gnue and no issues.

Re: [PATCH][AARCH64][PR target/84882] Add mno-strict-align

On 27/03/18 13:58, Sudakshina Das wrote: > Hi > > This patch adds the no variant to -mstrict-align and the corresponding > function attribute. To enable the function attribute, I have modified > aarch64_can_inline_p () to allow checks even when the callee function > has no attribute. The need for

Re: [PATCH][arm][2/2] Remove support for -march=armv3 and older

On 17/05/18 11:26, Kyrill Tkachov wrote: > Hi all, > > We deprecated architecture versions earlier than Armv4T in GCC 6 [1]. > This patch removes support for architectures lower than Armv4. > That is the -march values armv2, armv2a, armv3, armv3m are removed > with this patch.  I did not remove

Re: [PATCH][arm][1/2] Remove support for deprecated -march=armv5 and armv5e

On 17/05/18 11:26, Kyrill Tkachov wrote: > Hi all, > > The -march=armv5 and armv5e options have been deprecated in GCC 7 [1]. > This patch removes support for them. > It's mostly mechanical stuff. The functionality that was previously > gated on arm_arch5 is now gated on arm_arch5t and the

So what's the status of the Git migration?

Another year; another release; and still no sign of progress on the git migration. Any ideas on how much longer this is going to take? R.

Re: [PATCH, aarch64] Patch to update pipeline descriptions in thunderx2t99.md

On 09/05/18 23:37, Steve Ellcey wrote: > On Fri, 2018-05-04 at 14:05 -0700, Andrew Pinski wrote: >>   >>>    (thunderx2t99_loadpair): Fix cpu unit ordering. >> I think the original ordering was correct.  The address calculation >> happens before the actual load. >> thunderx2t99_asimd_load1_ldp

Re: [patch AArch64] Do not perform a vector splat for vector initialisation if it is not useful

On 16/05/18 09:37, Kyrill Tkachov wrote: > > On 15/05/18 10:58, Richard Biener wrote: >> On Tue, May 15, 2018 at 10:20 AM Kyrill Tkachov >> >> wrote: >> >>> Hi all, >>> This is a respin of James's patch from: >>

Re: [Aarch64] Vector Function Application Binary Interface Specification for OpenMP

On 16/05/18 17:21, Steve Ellcey wrote: > On Tue, 2018-05-15 at 18:29 +, Francesco Petrogalli wrote: > >> Hi Steve, >> >> I am happy to let you know that the Vector Function ABI for AArch64 >> is now public and available via the link at [1]. >> >> Don’t hesitate to contact me in case you have

Re: [PATCH][AArch64] Set SLOW_BYTE_ACCESS

On 16/05/18 14:56, Wilco Dijkstra wrote: > Richard Earnshaw wrote: > Which doesn't appear to have been approved.  Did you follow up with Jeff? >>> >>> I'll get back to that one at some point - it'll take some time to agree on >>> a way >>> forward with the callback. >>> >>> Wilco >>>

Re: [PATCH][AArch64] Set SLOW_BYTE_ACCESS

On 15/05/18 17:58, Wilco Dijkstra wrote: > Hi, > >> Which doesn't appear to have been approved.  Did you follow up with Jeff? > > I'll get back to that one at some point - it'll take some time to agree on a > way > forward with the callback. > > Wilco > > So it seems to me that this

Re: [PATCH][AArch64] Set SLOW_BYTE_ACCESS

On 15/05/18 17:01, Wilco Dijkstra wrote: > Hi, > >> I see nothing about you addressing James' comment from 17th November... > > I addressed that in a separate patch, see > https://patchwork.ozlabs.org/patch/839126/ > > Wilco > Which doesn't appear to have been approved. Did you follow up

Re: [PATCH][AArch64] Set SLOW_BYTE_ACCESS

On 15/05/18 14:24, Wilco Dijkstra wrote: > > ping > > I see nothing about you addressing James' comment from 17th November... > > > From: Wilco Dijkstra > Sent: 17 November 2017 15:21 > To: GCC Patches > Cc: nd > Subject: [PATCH][AArch64] Set SLOW_BYTE_ACCESS >   > > Contrary to all

Re: [PATCH][AArch64] Add combine pattern to fuse AESE/AESMC instructions

On 11/05/18 14:29, Kyrill Tkachov wrote: > Hi all, > > When the AESE,AESD and AESMC, AESMC instructions are generated through > the appropriate arm_neon.h intrinsics > we really want to keep them together when the AESE feeds into an AESMC > and fusion is supported by the target CPU. > We have

[arm] PR target/85733 Restore be8 linking behaviour for ARMv6-M and products deriving from its capabilities

My patch last year to automate passing the be8 flag to the linker had a nasty flaw in that I forgot entirely that the ARMv6-M architecture did not derive its capabilities directly from the ARMv6 capability list, but was a new group of capabilities (since it needs to leave out the ARM -- notm --

[arm] PR target/85606 prefer armv6s-m for armv6-m parts

When Arm introduced ARMv6-M there were two variants, ARMv6-M and ARMv6S-M. The two differed only in support for the SVC instruction. Later on SVC was then made a mandatory part of ARMv6-M and the ARMv6S-M name was dropped. GCC and GAS, however still recognize both names and at least some

[arm] PR target/85658 Fix operator precedence errors in parsecpu.awk

There are a number of places in parsecpu.awk where I've managed to get the operator precedence between ! and 'in' incorrect (! binds more tightly). In most cases this just makes a consistency test ineffective, but in a few cases it means we fail to correctly diagnose errors by the user (for

Re: r9 on ARM32?

On 24/04/18 03:22, Jay K wrote: > I'm wondering what is the role of r9 on ARM32, on Linux and Android. It's another callee-saved register and has no other special purpose. This is defined in the https://sourcery.mentor.com/GNUToolchain/kbattach142/arm_gnu_linux_abi.pdf which is the

Re: [PATCH][explow] PR target/85173: validize memory before passing it on to target probe_stack

On 10/04/18 08:37, Uros Bizjak wrote: > On Tue, Apr 10, 2018 at 12:26 AM, Jeff Law wrote: >> On 04/05/2018 08:20 AM, Kyrill Tkachov wrote: >>> Hi all, >>> >>> In this PR the expansion code emits an invalid memory address for the >>> stack probe, which the backend fails to

Re: Deprecate not defining NO_IMPLICIT_EXTERN_C

Isn't this an OS issue rather than a general port issue. Seems to me it will depend on the system header files. With a few notable exceptions I'm not sure the port maintainers can answer this for all their target OSs. R. On 21/03/18 12:15, Nathan Sidwell wrote: > Port maintainers CC'd,

Re: [PATCH][ARM][PR82989] Fix unexpected use of NEON instructions for shifts

On 14/03/18 10:11, Sudakshina Das wrote: > Hi > > This patch fixes PR82989 so that we avoid NEON instructions when > -mneon-for-64bits is not enabled. This is more of a short term fix for > the real deeper problem of making and early decision of choosing or > rejecting NEON instructions. There is

Re: [AARCH64 PATCH] Fix shift+rotate patterns with masking (PR target/84845)

On 14/03/18 08:43, Jakub Jelinek wrote: > Hi! > > The following testcase ICEs on aarch64-linux, because combiner matches the > (insn 25 24 26 2 (set (reg:DI 114) > (rotatert:DI (reg:DI 115 [ d ]) > (subreg:QI (neg:SI (and:SI (reg:SI 112) > (const_int

Re: [Patch][aarch64][PR target/83335] Fix regression, ICE on gcc.target/aarch64/asm-2.c

On 17/02/18 00:04, Steve Ellcey wrote: > On Thu, 2018-02-15 at 14:01 +0000, Richard Earnshaw (lists) wrote: >>   >> Wouldn't it be better to call output_operand_lossage() with a suitable >> diagnostic message?  If the operand isn't in Pmode assembly will >> (should) fai

Re: [Patch][aarch64][PR target/83335] Fix regression, ICE on gcc.target/aarch64/asm-2.c

On 05/01/18 22:14, Steve Ellcey wrote: > This is a fix for PR target/83335.  We are asserting in > aarch64_print_address_internal because we have a non Pmode > address coming from an asm instruction.  My fix is to  > just allow this by checking this_is_asm_operands. This is > what it was doing

Re: [PATCH] Use ptr_mode to save/restore pointers in builtin jmpbuf

On 02/02/18 20:55, Eric Botcazou wrote: >> But, that is not what the builtin setjmp/longjmp tests have. > > Yes, but I don't think that we want to risk breaking a working compiler on > some targets because peculiar tests don't pass on another. I think that > init_eh is OK for x32 so SJLJ

Re: [PATCH][AArch64] PR target/84164: Relax predicate in *aarch64__reg_di3_mask2

On 02/02/18 15:43, Kyrill Tkachov wrote: > Hi Richard, > > On 02/02/18 15:25, Richard Earnshaw (lists) wrote: >> On 02/02/18 15:10, Kyrill Tkachov wrote: >>> Hi all, >>> >>> In this [8 Regression] PR we ICE because we can't recognise the i

Re: [PATCH][AArch64] PR target/84164: Relax predicate in *aarch64__reg_di3_mask2

On 02/02/18 15:10, Kyrill Tkachov wrote: > Hi all, > > In this [8 Regression] PR we ICE because we can't recognise the insn: > (insn 59 58 43 7 (set (reg:DI 124) >     (rotatert:DI (reg:DI 125 [ c ]) >     (subreg:QI (and:SI (reg:SI 128) >     (const_int 65535

Re: Fix PR rtl-optimization/84071

On 02/02/18 12:21, Eric Botcazou wrote: >> That's always been my interpretation too. Seems like we may be changing >> the meaning of this macro... > > The main (and essentially only) effect of WORD_REGISTER_OPERATIONS in the > compiler happens during combine and is explained by this comment

Re: Fix PR rtl-optimization/84071

On 31/01/18 19:04, Richard Sandiford wrote: > Eric Botcazou writes: >>> Tested on SPARC64/Linux and ARM/EABI, applied on mainline and 7 branch. >> >> As discussed in the audit trail, this beefs up the internal documentation >> about WORD_REGISTER_OPERATIONS. >> >> Tested

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

On 18/01/18 12:44, Richard Biener wrote: > On Wed, Jan 17, 2018 at 3:55 PM, Richard Earnshaw > wrote: >> >> This patch adds generic support for the new builtin >> __builtin_speculation_safe_load. It provides the overloading of the >> different access sizes and a default

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

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