Most armv7-a implementations support a number of basic extensions to the
architecture which are not particularly important to the compiler, but
can matter if code contains inline assembly. This patch adds support
for these extensions, based on the capabilities that GAS already
provides for the
Further investigation showed that my previous patch for this issue was
still incomplete.
The problem stemmed from what I suspect was a mis-understanding of the
way overflow is calculated on aarch64 when values are subtracted (and
hence in comparisons). In this case, unlike addition, the carry
Investigating PR target/86891 revealed a number of issues with the way
the AArch64 backend was handing overflow detection patterns. Firstly,
expansion for signed and unsigned types is not the same as in one form
the overflow is detected via the C flag and in the other it is done via
the V flag in
On 14/12/2018 23:28, Thomas Preudhomme wrote:
> Hi,
>
> Commit r242693 forced fp to be saved/restored when needed due to an
> instance of GCC using fp as a scratch register to save sp while it's
> being clobbered by an inline asm. The normal path in
> thumb1_compute_save_reg_mask saving
On 12/12/2018 21:32, Andreas Tobler wrote:
> Hi all,
>
> I have this patch since a longer time in my tree. No obvious fallout
> visible.
>
> I'm going to commit this patch in the next days if no one objects.
>
> TIA,
> Andreas
>
> 2018-12-12 Andreas Tobler
>
> * config.gcc: Enable
On 19/12/2018 17:17, Richard Biener wrote:
> On Wed, 19 Dec 2018, Florian Weimer wrote:
>
>> * Peter Bergner:
>>
>>> On 12/19/18 7:59 AM, Florian Weimer wrote:
* Richard Biener:
> Sure, if we'd ever deploy this in production placing this in the
> TCB for glibc targets might be
On 19/12/2018 11:25, Richard Biener wrote:
> On Tue, 18 Dec 2018, Richard Earnshaw (lists) wrote:
>
>> On 18/12/2018 15:36, Richard Biener wrote:
>>>
>>> Hi,
>>>
>>> in the past weeks I've been looking into prototyping both spectre V1
he rest of the patch, this is OK. I'm not entirely sure that what
you've done will reliably work in terms of guaranteeing to find the weak
definition first within the same library, but at least it should be safe.
R.
> Best regards,
>
> Thomas
> On Fri, 7 Dec 2018 at 14:14, Richard Ear
>
> *** gcc/testsuite/ChangeLog ***
>
> 2018-12-14 thomas Preud'homme
>
> * gcc.target/arm/cmse/baseline/softfp.c: Force an FPU.
>
> Testing: No testsuite regression when targeting arm-none-eabi Armv6S-M
> with -mfloat-abi=softfp
>
> Is this ok for stage3?
>
> Be
On 19/12/2018 03:11, Shaokun Zhang wrote:
> For HiSilicon's tsv110 cpu core, it supports some v8_4A features, but
> some mandatory features are not implemented. Revert to ARMv8.2 that
> all mandatory features are supported.
>
Thanks, I've put this in.
I've modified the ChangeLog entry slightly
On 18/12/2018 15:36, Richard Biener wrote:
>
> Hi,
>
> in the past weeks I've been looking into prototyping both spectre V1
> (speculative array bound bypass) diagnostics and mitigation in an
> architecture independent manner to assess feasability and some kind
> of upper bound on the
Unfortunately another PCS bug has come to light with the layout of
structs whose alignment is dominated by a 64-bit bitfield element. Such
fields in the type list appear to have alignment 1, but in reality, for
the purposes of alignment of the underlying structure, the alignment is
derived from
On 12/12/2018 15:47, Olivier Hainque wrote:
> Hello,
>
> Ping for part of the changes last proposed here:
>
> https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00761.html
>
> Submitted separately as an attempt to facilitate the review
> process.
>
> This piece is the change of static chain from
On 30/08/2018 13:24, Richard Sandiford wrote:
> Joey Ye writes:
>> Hi Bin & Richard,
>>
>> It is not as simple as keeping the assertion, which still fails even
>> with the change in reorg.c. The testing result is as following:
>>
>> I. With Bin's patch version 2 (removing the assertion in
The copysign operations will almost always be performed on values in
floating-point registers. As such, we do not want the compiler to
simplify the operations into code sequences that can only be done using
the general-purpose register set. Unfortunately, this is what is
currently happening.
On 07/12/2018 15:52, Jeff Law wrote:
> As I suggested in the BZ, this patch rejects constants with just the
> high bit set for the recently added "bfxil" pattern. As a result we'll
> return to using "bit" for the test in the BZ.
>
> I'm not versed enough in aarch64 performance tuning to know if
On 19/11/2018 09:57, Thomas Preudhomme wrote:
> Softfloat single precision and double precision floating-point
> multiplication routines in libgcc share some code with the
> floating-point division of their corresponding precision. As the code
> is structured now, this leads to *all* division code
On 06/12/2018 15:36, Jeff Law wrote:
>
> As outlined in the PR, the aarch64 has a non-default value for
> CASE_VALUES_THRESHOLD which changes decisions in switch lowering. Those
> changes in switch lowering can expose additional jump threads later in
> the pipeline which cause heartburn for a
On 30/11/2018 14:19, Kyrill Tkachov wrote:
>
> On 23/11/18 17:01, Sam Tebbs wrote:
>> Hi all,
>>
>> Currently on AArch32, invoking with -march=armv8.2-a+dotprod -mfpu=neon
>> incorrectly enables armv7 dotproduct. This patch restricts dotproduct
>> to armv8
>> to correct the issue.
>>
>> When
On 29/11/2018 10:51, Thomas Preudhomme wrote:
> Hi,
>
> FP instructions are only enabled for TARGET_32BIT and TARGET_HARD_FLOAT
> but GCC only gives an error when TARGET_HARD_FLOAT is true and -mfpu is
> not set. Among other things, it makes some of the cmse tests (eg.
>
On 26/11/2018 19:50, Christoph Muellner wrote:
> The aarch64 ISA specification allows a left shift amount to be applied
> after extension in the range of 0 to 4 (encoded in the imm3 field).
>
> This is true for at least the following instructions:
>
> * ADD (extend register)
> * ADDS (extended
On 27/11/2018 11:41, Christoph Müllner wrote:
> This patch adds "Ampere eMAG" to the list of new supported AArch64 cores
> in changes.html for GCC 9.
>
> Ok to commit to CVS?
OK.
R.
>
> Thanks,
> Christoph
>
> --- htdocs/gcc-9/changes.html.orig 2018-11-26 20:40:38.069556986 +0100
> +++
On 28/11/2018 10:43, Andre Vieira (lists) wrote:
> On 27/11/18 14:18, Richard Earnshaw (lists) wrote:
>> On 27/11/2018 14:10, Andre Vieira (lists) wrote:
>>>
>>> Both Cortex-R7 and Cortex-R8 support FP16 conversion instructions and both
>>> have
&g
On 27/11/2018 14:10, Andre Vieira (lists) wrote:
>
> Hi,
>
> This patch fixes the FPU configurations of Cortex-R7 and Cortex-R8,
> enabling the use of FP16 conversion instructions for both and adding the
> option to disable double precision instruction support using '+nofp.dp'.
>
> Passes the
On 20/11/2018 18:00, Christoph Muellner wrote:
> Tested with "make check" and no regressions found.
>
> This patch depends on the struct xgene1_prefetch_tune,
> which has been acknowledged already:
> https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00985.html
>
> *** gcc/ChangeLog ***
>
>
On 12/11/2018 19:14, Christoph Muellner wrote:
> *** gcc/ChangeLog ***
>
> 2018-xx-xx Christoph Muellner
>
> * config/aarch64/aarch64.c (xgene1_tunings): Optimize Xgene1 tunings for
> GCC 9.
OK.
R.
> ---
> gcc/config/aarch64/aarch64.c | 4 ++--
> 1 file changed, 2
On 12/11/2018 19:14, Christoph Muellner wrote:
> *** gcc/ChangeLog ***
>
> 2018-xx-xx Christoph Muellner
>
> * config/aarch64/aarch64.c (xgene1_tunings): Add Xgene1 specific
> prefetch tunings.
OK.
R.
> ---
> gcc/config/aarch64/aarch64.c | 13 -
> 1 file changed,
On 12/11/2018 19:14, Christoph Muellner wrote:
> *** gcc/ChangeLog ***
>
> 2018-xx-xx Christoph Muellner
>
> * config/aarch64/aarch64.c (xgene1_addrcost_table): Correct the post
> modify
> costs.
OK.
R.
> ---
> gcc/config/aarch64/aarch64.c | 2 +-
> 1 file changed, 1
On 12/11/2018 19:14, Christoph Muellner wrote:
> *** gcc/ChangeLog ***
>
> 2018-xx-xx Christoph Muellner
>
> * config/arm/aarch-cost-tables.h (xgene1_extra_costs): Update the cost
> table
> for Xgene1.
OK.
R.
> ---
> gcc/config/arm/aarch-cost-tables.h | 88
>
On 12/11/2018 15:13, Kyrill Tkachov wrote:
> Hi Richard,
>
> On 12/11/18 14:13, Richard Biener wrote:
>> On Fri, Nov 9, 2018 at 6:23 PM Sudakshina Das wrote:
>> >
>> > Hi
>> >
>> > I am posting this patch on behalf of Carey (cc'ed). I also have some
>> > review comments that I will make as a
A couple of very minor issues with the new support for CPU
aliases.
* config/arm/parsecpu.awk (/alias/): Tighten invisible alias
matching criteria. Remove unused array initializer.
Committed.
diff --git a/gcc/config/arm/parsecpu.awk b/gcc/config/arm/parsecpu.awk
index
On 09/11/2018 15:07, Alexandre Oliva wrote:
> Richard,
>
> Olivier tells me he talked to you briefly at the Cauldron about allowing
> custom multilib sets to be configured from custom Makefile fragments
> supplied at configure time, and that you was somewhat receptive to the
> idea. I have
This patch simplifies the table of CPUs supported in GCC by making
use of the new alias feature. Most of the changes are fairly
straight-forward:
- arm7tdmi and arm7tdmi-s are the same thing.
- arm710t, arm720t and arm740t differ only in features external to the core
- arm920 and arm920t are the
On 07/11/2018 23:02, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Nov 05, 2018 at 06:16:16PM +, Renlin Li wrote:
>> Sorry, this is not correct. Instructions scheduled between x and x+1
>> directly use hard register r1.
>> It is not IRA/LRA assigning r1 to the operands.
>>
>>
>> To reproduce
This patch adds support for defining an alias for a CPU name that can
then be used in conjunction with the -mcpu option in the same way that
the primary name can be used. Aliases do not lead to a short-cut of
the feature options; they are literally an alternative name for the
core CPU.
The new
On 07/11/2018 09:47, Kyrill Tkachov wrote:
> Hi all,
>
> This adds support for the Arm Ares CPU for AArch64.
> It implements the Armv8.2-A architecture with the optional features
> of statistical profiling, dot product and FP16 on by default.
>
> Note: Ares is a codename to enable early adopters
On 06/11/2018 20:18, Segher Boessenkool wrote:
> On Tue, Nov 06, 2018 at 07:43:36PM +0000, Richard Earnshaw (lists) wrote:
>> On 06/11/2018 18:18, Segher Boessenkool wrote:
>>> On Tue, Nov 06, 2018 at 11:46:53AM +, Richard Earnshaw (lists) wrote:
>>>> Well
On 06/11/2018 19:43, Richard Earnshaw (lists) wrote:
> On 06/11/2018 18:18, Segher Boessenkool wrote:
>> Hi Richard,
>>
>> On Tue, Nov 06, 2018 at 11:46:53AM +0000, Richard Earnshaw (lists) wrote:
>>> On 06/11/2018 01:40, Segher Boessenkool wrote:
>>>>
On 06/11/2018 18:18, Segher Boessenkool wrote:
> Hi Richard,
>
> On Tue, Nov 06, 2018 at 11:46:53AM +, Richard Earnshaw (lists) wrote:
>> On 06/11/2018 01:40, Segher Boessenkool wrote:
>>> Hi Richard,
>>>
>>> On Mon, Nov 05, 2018 at 10:09:
The speculation tracker insn in my recent patch set for CVE-2017-5753
was missing a mode on the UNSPEC. Although this didn't break the
build, it did cause an unnecessary warning from the MD parsing
mechanism that I missed at the time. It's a trivial fix, as follows:
*
On 06/11/2018 01:40, Segher Boessenkool wrote:
> Hi Richard,
>
> On Mon, Nov 05, 2018 at 10:09:30AM +, Richard Earnshaw (lists) wrote:
>>>>> Shouldn't you be able to do this per function at least?
>>>>
>>>> do what per function? track specul
On 05/11/2018 10:05, Richard Biener wrote:
> On Fri, Nov 2, 2018 at 3:04 PM Richard Earnshaw (lists)
> wrote:
>>
>> On 02/11/2018 13:53, Richard Biener wrote:
>>> On Fri, Nov 2, 2018 at 2:38 PM Richard Earnshaw (lists)
>>> wrote:
>>>>
>&g
On 02/11/2018 13:53, Richard Biener wrote:
> On Fri, Nov 2, 2018 at 2:38 PM Richard Earnshaw (lists)
> wrote:
>>
>> Although there's no fundamental reason why shrink wrapping and
>> speculation tracking are incompatible, a phase-ordering requirement (we
>> need to
Although there's no fundamental reason why shrink wrapping and
speculation tracking are incompatible, a phase-ordering requirement (we
need to do speculation tracking before the final basic block clean-up)
means that the shrink wrapping pass can undo some of the changes the
speculation tracking
On 01/11/2018 01:52, Andrew Pinski wrote:
> On Tue, Oct 30, 2018 at 10:21 AM Richard Earnshaw (lists)
> wrote:
>>
>> On 30/10/2018 17:06, Andrew Pinski wrote:
>>> Hi all,
>>> There was a name change of the Products, ThunderX T81 and ThunderX
>>&
On 31/10/2018 22:04, co...@sdf.org wrote:
> On Wed, Oct 31, 2018 at 03:23:27PM +0000, Richard Earnshaw (lists) wrote:
>> On 31/10/2018 14:10, co...@sdf.org wrote:
>>> +
>>> +# Currently there is a bug somewhere in GCC's alias analysis
>>> +# or scheduling code
On 31/10/2018 14:10, co...@sdf.org wrote:
> +
> +# Currently there is a bug somewhere in GCC's alias analysis
> +# or scheduling code that is breaking _fpmul_parts in fp-bit.c.
> +# Disabling function inlining is a workaround for this problem.
> +HOST_LIBGCC2_CFLAGS += -fno-inline
This needs to
On 30/10/2018 17:06, Andrew Pinski wrote:
> Hi all,
> There was a name change of the Products, ThunderX T81 and ThunderX
> T83 to OcteonTX family name. This change was done a few years ago but
> I had not submmitted the change at that time. This is also the first
> patch in a series to add
PR bootstrap/87747 would have been significantly easier to track down if
the pool allocator had faulted an attempt to configure it to allocate
zero-sized objects. Instead, this slipped through and we later hit
memory corruption when the assumed size turned out to be different to
the configured
On 30/10/2018 10:09, Sameera Deshpande wrote:
> On Tue, 9 Oct 2018 at 04:08, Eric Botcazou wrote:
>>
>>> Other notes need not be changed, as they don't hold renamed register
>>> information.
>>>
>>> Ok for trunk?
>>
>> No, REG_DEAD & REG_UNUSED note must be recomputed by passes consuming them.
>>
On 26/10/2018 16:25, Christophe Lyon wrote:
> On Tue, 23 Oct 2018 at 16:07, Richard Earnshaw (lists)
> wrote:
>>
>> On 19/10/2018 14:40, Christophe Lyon wrote:
>>> On 12/10/2018 12:45, Richard Earnshaw (lists) wrote:
>>>> On 11/10/18 14:34, Christophe Lyon
On 26/10/2018 00:46, Paul Koning wrote:
> In my target (pdp11) which has 16 bit words, I see some test suite failures
> because of unresolved references to __cmpsi2. The strange thing is that most
> of the time 32 bit compares are expanded by GCC into a sequence of word
> compares and
On 25/10/2018 14:29, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux.
>
> r264556 and r264537 changed the format of EQ_ATTR_ALT RTXs to "ww",
> which also required adjusting rtx_code_size initializer. In order to
> simplify things, the list of rtx_codes known to use
On 24/09/2018 22:49, Ilya Leoshkevich wrote:
> Bootstrap and regtest running on s390x-redhat-linux.
>
> "r264537: Change EQ_ATTR_ALT to support up to 64 alternatives" changed
> the format of EQ_ATTR_ALT from ii to ww. This broke the bootstrap on
> 32-bit systems, because the formula for
On 24/10/2018 12:29, co...@sdf.org wrote:
>>> +/* Default to full VFP if -mhard-float is specified. */
>>> +#undef SUBTARGET_ASM_FLOAT_SPEC
>>> +#define SUBTARGET_ASM_FLOAT_SPEC \
>>> + "%{mhard-float:%{!mfpu=*:-mfpu=vfp}} \
>>> + %{mfloat-abi=hard:%{!mfpu=*:-mfpu=vfp}}"
>>
>> Please
On 19/10/2018 14:40, Christophe Lyon wrote:
> On 12/10/2018 12:45, Richard Earnshaw (lists) wrote:
>> On 11/10/18 14:34, Christophe Lyon wrote:
>>> The FDPIC register is hard-coded to r9, as defined in the ABI.
>>>
>>> We have to disable tailcall optimization
On 15/10/2018 11:10, Christophe Lyon wrote:
> On Fri, 12 Oct 2018 at 12:01, Richard Earnshaw (lists) <
> richard.earns...@arm.com> wrote:
>
>> On 11/10/18 14:34, Christophe Lyon wrote:
>>> In FDPIC mode, we set -fPIE unless the user provides -fno-PIE, -fpie,
>>
On 22/10/2018 10:02, Sam Tebbs wrote:
> Hi all,
>
> This patch replaces the umov instruction in the aarch64 popcount
> expansion with
> the less expensive fmov instruction.
>
> Example:
>
> int foo (int a) {
> return __builtin_popcount (a);
> }
>
> would generate:
>
> foo:
> uxtw x0,
Thanks for posting this. Before we can commit it, however, we need to
sort out the authorship and ensure that all the appropriate copyright
assignments are in place. Are you the sole author, or are other NetBSD
developers involved?
Firstly, please provide a ChangeLog description for the patch.
On 22/10/2018 19:14, co...@sdf.org wrote:
> On Mon, Oct 22, 2018 at 03:56:24PM +0100, Richard Earnshaw (lists) wrote:
>> I think strongarm would be a better choice. I'm not aware of anyone
>> running NetBSD on Arm8 cpus.
>>
>> Otherwise, this is fine with a suitab
On 22/10/2018 16:36, co...@sdf.org wrote:
> On Mon, Oct 22, 2018 at 03:56:24PM +0100, Richard Earnshaw (lists) wrote:
>> I think strongarm would be a better choice. I'm not aware of anyone
>> running NetBSD on Arm8 cpus.
>
> Clarifying: this is the global default fo
On 21/10/2018 05:53, co...@sdf.org wrote:
> Regarding target/86383, it wasn't sufficient to not just pick arm6 for
> netbsd, as the default -mcpu is still arm6, which also fails to build.
>
> I assume the default is expected to be the oldest support, and I think
> now that's arm8, so maybe
On 11/10/18 14:34, Christophe Lyon wrote:
> Use local binding rules to decide whether we can use GOTOFFFUNCDESC to
> compute the function address.
>
> 2018-XX-XX Christophe Lyon
> Mickaël Guêné
>
> gcc/
> * config/arm/arm.c (arm_local_funcdesc_p): New function.
>
On 11/10/18 14:34, Christophe Lyon wrote:
> 2018-XX-XX Christophe Lyon
> Mickaël Guêné
>
> gcc/
> * config/arm/arm.c (arm_compute_save_reg0_reg12_mask): Handle
> FDPIC.
> (thumb1_compute_save_core_reg_mask): Likewise.
The hunk for this bit is missing.
>
> diff
On 11/10/18 14:34, Christophe Lyon wrote:
> The main difference with existing support is that function addresses
> are function descriptor addresses instead. This means that all code
> dealing with function pointers now has to cope with function
> descriptors instead.
>
> For the same reason,
On 11/10/18 14:34, Christophe Lyon wrote:
> In FDPIC, we need to make sure __do_global_dtors_aux and frame_dummy
> are referenced by their address, not by pointers to the function
> descriptors.
>
> 2018-XX-XX Christophe Lyon
> Mickaël Guêné
>
> * libgcc/crtstuff.c: Add support
On 11/10/18 14:34, Christophe Lyon wrote:
> The FDPIC register is hard-coded to r9, as defined in the ABI.
>
> We have to disable tailcall optimizations if we don't know if the
> target function is in the same module. If not, we have to set r9 to
> the value associated with the target module.
>
On 11/10/18 14:34, Christophe Lyon wrote:
> In FDPIC mode, we set -fPIE unless the user provides -fno-PIE, -fpie,
> -fPIC or -fpic: indeed FDPIC code is PIC, but we want to generate code
> for executables rather than shared libraries by default.
>
> We also make sure to use the --fdpic assembler
On 11/10/18 14:34, Christophe Lyon wrote:
> The new arm-uclinuxfdpiceabi target behaves pretty much like
> arm-linux-gnueabi. In order the enable the same set of features, we
> have to update several configure scripts that generally match targets
> like *-*-linux*: in most places, we add
On 11/10/18 14:34, Christophe Lyon wrote:
> 2018-XX-XX Christophe Lyon
> Mickaël Guêné
>
> gcc/
> * config/arm/arm.opt: Add -mfdpic option.
> * doc/invoke.texi: Add documentation for -mfdpic.
This is OK (once the rest of the series is approved).
R.
>
> diff --git
On 11/10/18 19:37, Wilco Dijkstra wrote:
> Here is the same version again with an extra test added:
>
> The popcount expansion uses SIMD instructions acting on 64-bit values.
> As a result a popcount of a 32-bit integer requires zero-extension before
> moving the zero-extended value into an FP
On 08/10/18 11:29, Richard Biener wrote:
> On Mon, Oct 8, 2018 at 12:14 PM Martin Liška wrote:
>>
>> On 10/8/18 11:55 AM, Richard Earnshaw (lists) wrote:
>>> On 08/10/18 10:47, Martin Liška wrote:
>>>> On 10/8/18 10:46 AM, Renlin Li wrote:
>>>>>
On 08/10/18 10:47, Martin Liška wrote:
> On 10/8/18 10:46 AM, Renlin Li wrote:
>> Hi Martin,
>>
>> pr82625.C failed on compiler builds which don't support "default" and "avx"
>> target.
>> For example, arm/aarch64 native linux gcc compiler.
>>
>>
>> As I found in this gcc wiki:
On 26/09/18 17:21, Steve Ellcey wrote:
> A patch for PR tree-optimized/71625 caused regressions in the
> gcc.target/aarch64/vclz.c and gcc.target/aarch64/vneg_s.c tests
> because a couple of routines that were not getting inlined before
> started getting inlined. The inlining is not a bug, the
>
This is the wrong place to report bugs. Please use bugzilla:
https://gcc.gnu.org/bugzilla/
You also need to include a *complete* description of the bug and provide
code that can be used to reproduce it. Your minimal description below
is completely inadequate.
R.
On 01/10/18 02:27, Jason A.
On 28/09/18 15:28, Richard Earnshaw (lists) wrote:
> On 28/09/18 13:33, Wilco Dijkstra wrote:
>> Matthew wrote:
>>
>>> The canonical way to require even-odd pairs of registers to implement a
>>> TImode
>>> pseudo register as mentioned in the documentat
On 28/09/18 13:33, Wilco Dijkstra wrote:
> Matthew wrote:
>
>> The canonical way to require even-odd pairs of registers to implement a
>> TImode
>> pseudo register as mentioned in the documentation is to limit *all* TImode
>> registers to being even-odd by using the TARGET_HARD_REGNO_MODE_OK
On 26/09/18 15:44, Steve Ellcey wrote:
>
> The patch for PR rtl-optimization/85160 which allowed combine to convert
> two instructions into two different instructions if they had a lower cost
> caused a couple of regressions on aarch64. This patch fixes one of them.
>
> After the above patch,
On 27/09/18 16:18, Matthew Malcomson wrote:
>
> I had a superfluous #include in the testcase and some
> spelling mistakes in documentation -- corrected patch attached.
>
>
> On 27/09/18 15:02, Matthew Malcomson wrote:
>> Hello,
>>
>> LSE instructions like casp require even-odd pairs of
On 27/09/18 18:07, Wilco Dijkstra wrote:
> The popcount expansion uses SIMD instructions acting on 64-bit values.
> As a result a popcount of a 32-bit integer requires zero-extension before
> moving the zero-extended value into an FP register. This patch adds
> support for zero-extended int->FP
On 24/09/18 10:22, Matthew Malcomson wrote:
> A few places in the arm and aarch64 backends check whether an atomic
> operation needs acquire or release semantics.
> This is generally done with a check like
>
> (is_mm_relaxed (model)
> || is_mm_consume (model)
> || is_mm_release (model))
>
>
On 24/09/18 10:19, Eric Botcazou wrote:
>> Ah! But that still doesn't explain why you want to skip these passes
>> when building thunks.
>
> They simply don't work because there is no CFG for thunks; I can add a blurb
> about that.
Yes, this needs a comment as it's far from obvious when
On 21/09/18 11:34, Jonathan Wakely wrote:
> On 21/09/18 11:24 +0100, Richard Earnshaw (lists) wrote:
>> On 21/09/18 01:52, Hans-Peter Nilsson wrote:
>>>> Date: Thu, 20 Sep 2018 15:22:23 +0100
>>>> From: Jonathan Wakely
>>>
>>>> On 20/09/18 15
On 21/09/18 01:52, Hans-Peter Nilsson wrote:
>> Date: Thu, 20 Sep 2018 15:22:23 +0100
>> From: Jonathan Wakely
>
>> On 20/09/18 15:36 +0200, Christophe Lyon wrote:
>>> On Wed, 19 Sep 2018 at 23:13, Rainer Orth
>>> wrote:
Hi Christophe,
> I have noticed failures on
On 18/09/18 16:36, Matthew Malcomson wrote:
>
>>> diff --git a/gcc/config/aarch64/atomics.md
>>> b/gcc/config/aarch64/atomics.md
>>> index
>>> 36c06756a1f94cadae097b3aad654fbeba1cf2f3..73078e412d01a43c05195f01488b95a2bc7a20ec
>>> 100644
>>> --- a/gcc/config/aarch64/atomics.md
>>> +++
On 18/09/18 10:15, Matthew Malcomson wrote:
> [PATCH][GCC][AARCH64] Use STLUR for atomic_store
>
> Use the STLUR instruction introduced in Armv8.4-a.
> This instruction has the store-release semantic like STLR but can take a
> 9-bit unscaled signed immediate offset.
>
> Example test case:
> ```
On 18/09/18 10:00, Eric Botcazou wrote:
>> this seems to contradict your statement above about having to work
>> harder to fix up minipools.
>
> Why? Fixing up minipools is done in the generic ARM reorg pass, not in the
> Thumb reorg pass(es).
>
Ah! But that still doesn't explain why you
On 17/09/18 12:19, Eric Botcazou wrote:
> Hi,
>
> this is a regression present on mainline, 8 and 7 branches. The new, RTL
> implementation of arm32_output_mi_thunk breaks during the libstdc++ build if
> you configure the compiler with -mlong-calls by default:
>
> 0xdb57eb
On 05/09/18 17:43, Denis Khalikov wrote:
> Thanks for the answers.
>
> I understood that, this hack makes more mess in codegen for arm,
> but can you please clarify what did you mean by
>
>>Only a single register can be used
>> as the frame chain.
>
> As far as I understood, GCC for arm with
On 05/09/18 14:55, Denis Khalikov wrote:
> Hi Wilco,
> thanks for the answer.
>
>> Adding support for a frame chain would require an ABI change. It would
> have to
>> work across GCC, LLVM, Arm, Thumb-1 and Thumb-2 - not a trivial amount of
>> effort.
>
> Clang already works that way.
> Please
On 29/08/18 11:46, Kyrill Tkachov wrote:
> Hi Christophe,
>
> On 13/07/18 17:10, christophe.l...@st.com wrote:
>> From: Christophe Lyon
>>
>> The FDPIC register is hard-coded to r9, as defined in the ABI.
>>
>> We have to disable tailcall optimizations if we don't know if the
>> target function
On 24/08/18 14:51, Akhilesh chirlancha wrote:
> Hello All,
>
> I'm using gcc 5.4.0 for armhf target.
>
> I was compiling simple stack over flow test code with '-mapcs-stack-check'
> option.
> # gcc -mapcs-stack-check test.c
> test.c:1:0: warning: -mapcs-stack-check incompatible with
On 02/08/18 10:46, Martin Liška wrote:
> On 08/02/2018 11:39 AM, Richard Earnshaw (lists) wrote:
>> 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
On 23/08/18 09:52, Richard Sandiford wrote:
> This patch fixes a typo in aarch64_expand_vec_perm_const_1 that I
> introduced as part of the SVE changes. I don't know of any cases in
> which it has any practical effect, since we'll eventually try to use
> TBL as a variable permute instead. Having
On 23/08/18 08:23, Matthew Malcomson wrote:
> Hello,
>
> arm.md has some attributes "arch" and "arch_enabled" to aid enabling and
> disabling insn alternatives based on the architecture being targeted.
> This patch introduces a similar attribute in the aarch64 backend.
> The new attribute will be
The AArch32 instruction sets prior to Armv7 do not define the ISB and
DSB instructions that are needed to form a speculation barrier. While I
do not know of any instances of cores based on those instruction sets
being vulnerable to speculative side channel attacks it is possible to
run code built
On 16/08/18 09:45, Sam Tebbs wrote:
> Hi all,
>
> This patch replaces the "Common" attribute in some aarch64 options with
> "Target"
> to make them target-dependent. This doesn't affect their behaviour or
> how they
> are documented with "--help", but does mean that they follow the option
>
On 10/08/18 14:38, Anton Youdkevitch wrote:
> The patch inlines strlen for 8-byte aligned strings on
> AARCH64 like it's done on other platforms (power, s390).
> The implementation falls back to the library call if the
> string is not aligned. Synthetic testing on Cavium T88
> and Cavium T99
On 09/08/18 21:08, dmalcolm at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86904
>
> Bug ID: 86904
>Summary: Column numbers ignore tab characters
>Product: gcc
>Version: unknown
> Status: UNCONFIRMED
>
On 03/08/18 23:44, Sandra Loosemore wrote:
> I've checked in this patch to fix the c-c++-common/spec-barrier-1.c test
> failure on nios2. Per previous discussions about Spectre
> vulnerabilities with Altera/Intel, this architecture is not affected so
> no special handling is required here.
>
>
501 - 600 of 1136 matches
Mail list logo
