On 06/11/2018 20:18, Segher Boessenkool wrote:
> On Tue, Nov 06, 2018 at 07:43:36PM +, 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 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
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 en
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 th
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 s
. Those are tricky
enough to get right as it is, and requests to support additional libs as
well as those with changes to these makefile fragments might be an
issue. As such, I think I'd want to say that you either use the builtin
lists *or* you supply your own fragment.
- I'd also be con
On 05/11/18 12:41, Richard Biener wrote:
> On Mon, Nov 5, 2018 at 1:07 PM Andre Vieira (lists)
> wrote:
>>
>>
>> Hi,
>>
Hi,
Thank you for the quick response! See inline responses below.
>> This patch enables targets to describe DR_TARGET_ALIGNMENT 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 ba2dee5fdcb
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 repl
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 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 insertion
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, 12
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 insertions(+)
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 ***
>
> 2018-xx-x
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 self-check during building for an arm target.
Is this OK for trunk
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 '+no
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
>> SP only and SP + DP configurations.
>
> You're missing th
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 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
> +++ h
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 28/11/18 10:57, Richard Earnshaw (lists) wrote:
> 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 sup
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.
> gcc.target/arm/cmse/baseli
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 using
On 25/06/2019 21:22, acsaw...@linux.ibm.com wrote:
> From: Aaron Sawdey
>
> * config/aarch64/aarch64-protos.h: Change movmem to cpymem.
> * config/aarch64/aarch64.c (aarch64_expand_movmem): Change movmem
> to cpymem.
> * config/aarch64/aarch64.h: Change movmem to cpymem.
>
Hi Richard(s),
I am trying to tackle PR88915 and get GCC to further vectorize the
"fallback" loop when doing loop versioning as it does when loop
versioning is not required.
I have a prototype patch that needs further testing, but at first glance
it seems to be achieving the desired outcome.
On 12/07/2019 11:19, Richard Biener wrote:
On Thu, 11 Jul 2019, Andre Vieira (lists) wrote:
I think for code-size reason it would make sense to do it like
if (iterations_check_for_lowest_VF ())
{
if (alias_check_for_highest_VF
Looking through the arm backend I noticed that the modes used to pass
comparison types into subtract-with-carry operations were being
incorrectly set. The result is that the compiler is not truly
self-consistent. To clean this up I've introduced a new predicate,
arm_borrow_operation (borrowed fr
On 17/07/2019 18:00, Segher Boessenkool wrote:
On Wed, Jul 17, 2019 at 12:54:32PM +0200, Jakub Jelinek wrote:
On Wed, Jul 17, 2019 at 12:37:59PM +0200, Richard Biener wrote:
I'm not sure if it makes sense to have both LROTATE_EXPR and
RROTATE_EXPR on the GIMPLE level then (that CPUs only
sup
On 18/07/2019 16:17, Jakub Jelinek wrote:
On Thu, Jul 18, 2019 at 04:12:48PM +0100, Richard Earnshaw (lists) wrote:
Both directions:
aarch64 c6x ia64 m68k nios2 parisc sh x86 xtensa
AArch64 is Right only.
Maybe hw-wise, but it has both rotr3 and rotl3 expanders.
At least for GPRs
On 18/07/2019 16:30, Jakub Jelinek wrote:
On Thu, Jul 18, 2019 at 04:26:26PM +0100, Richard Earnshaw (lists) wrote:
On 18/07/2019 16:17, Jakub Jelinek wrote:
On Thu, Jul 18, 2019 at 04:12:48PM +0100, Richard Earnshaw (lists) wrote:
Both directions:
aarch64 c6x ia64 m68k nios2 parisc
On 15/07/2019 11:54, Richard Biener wrote:
On Mon, 15 Jul 2019, Andre Vieira (lists) wrote:
On 12/07/2019 11:19, Richard Biener wrote:
On Thu, 11 Jul 2019, Andre Vieira (lists) wrote:
I have code that can split the condition and alias checks in
'vect_loop_versioning'
On 19/07/2019 12:35, Richard Biener wrote:
On Fri, 19 Jul 2019, Andre Vieira (lists) wrote:
On 15/07/2019 11:54, Richard Biener wrote:
On Mon, 15 Jul 2019, Andre Vieira (lists) wrote:
On 12/07/2019 11:19, Richard Biener wrote:
On Thu, 11 Jul 2019, Andre Vieira (lists) wrote:
I
On 18/06/2019 14:50, Sylvia Taylor wrote:
Hi Wilco,
Combined them into one pattern. Updated the diff and the changelog is now:
gcc/ChangeLog:
2019-06-18 Sylvia Taylor
* config/aarch64/aarch64.c
(aarch64_load_symref_appropriately): Change SYMBOL_TINY_GOT.
* config
On 24/07/2019 16:16, Wilco Dijkstra wrote:
The Thumb-2 movsi patterns try to prefer low registers for loads and stores.
However this is done incorrectly by using 2 separate variants with 'l' and 'h'
register classes. The register allocator will only use low registers, and
as a result we end u
Hi Vlad,
On 13/02/2019 16:46, Vladimir Makarov wrote:
On 2019-02-13 5:54 a.m., Andre Vieira (lists) wrote:
PING.
Since Jeff is away can another maintainer have a look at this please?
I see the following patch
Yeah I uploaded the wrong patch... sorry. See attached, including a
testcase
On 27/02/2019 10:56, Jakub Jelinek wrote:
> On Mon, Feb 25, 2019 at 10:23:52AM +, Kyrill Tkachov wrote:
>>> The only bootstraps I'm doing are distro builds with
>>> --with-tune=generic-armv7-a --with-arch=armv7-a \
>>> --with-float=hard --with-fpu=vfpv3-d16 --with-abi=aapcs-li
This patch to wwwdocs updates the changes file for the fix to PR
target/88469 in gcc-9.
Committed.
Index: htdocs/gcc-9/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v
retrieving revision 1.46
diff -u -r1.46 ch
On 27/01/2019 11:20, Bernd Edlinger wrote:
> Hi,
>
> I know I am a bit late on the party.
Sorry for the delay replying, I've been off sick...
>
> But I have a question...
>
> Consider this test case:
>
> $ cat test.c
> struct s {
> int a, b;
> } __attribute__((aligned(8)));
>
> struct s f0
On 28/02/2019 14:51, Bernd Edlinger wrote:
> On 2/28/19 1:10 PM, Richard Earnshaw (lists) wrote:
>> On 27/01/2019 11:20, Bernd Edlinger wrote:
>>>
>>> $ arm-linux-gnueabihf-gcc -march=armv5te -O3 -S test.c
>>> $ cat test.s
>>> f:
>>> @ ar
On 05/02/2019 15:07, Bernd Edlinger wrote:
> Hi,
>
> due to the AAPCS parameter passing of 8-byte aligned structures, which happen
> to
> be 8-byte aligned or only 4-byte aligned in the test case, ldrd instructions
> are generated that may access 4-byte aligned stack slots, which will trap on
>
On 01/03/2019 12:57, Tamar Christina wrote:
> Hi All,
>
> Due to config.gcc all the options need to be on one line because of the grep
> lines which would select only the first line of the option.
>
> This causes it not to select the right bits on options that are spread over
> multiple lines whe
On 01/03/2019 12:58, Tamar Christina wrote:
> Hi All,
>
> Due to config.gcc all the options need to be on one line because of the grep
> lines which would select only the first line of the option.
>
> This causes it not to select the right bits on options that are spread over
> multiple lines whe
Hi,
vcvtb.f16.f64 and vcvtb.f64.f16 were being made available even for FPUs
that do not support double precision. This patch fixes that.
Regression tested for arm-none-eabi.
Committed in r269499.
Cheers,
Andre
gcc/ChangeLog:
2019-03-08 Andre Vieira
* config/arm/arm.h (TARGET_FP
Hi,
Any objections to me backporting this to GCC 8 and 7?
Cheers,
Andre
On 08/03/2019 17:30, Andre Vieira (lists) wrote:
Hi,
vcvtb.f16.f64 and vcvtb.f64.f16 were being made available even for FPUs
that do not support double precision. This patch fixes that.
Regression tested for arm-none
* gcc.target/arm/f16_f64_conv_no_dp.c: Add arm_fp16_ok effective
target.
On 11/03/2019 20:50, Ramana Radhakrishnan wrote:
Nope, just do it after testing it and adjust with Christophes follow up
R
On Mon, 11 Mar 2019, 10:36 Andre Vieira (lists),
mailto:andre.simoesdiasvie...@arm.com>>
Christophe Lyon
* gcc.target/arm/f16_f64_conv_no_dp.c: Add arm_fp16_ok effective
target.
On 12/03/2019 14:54, Andre Vieira (lists) wrote:
Hi,
Thanks Christophe! I have committed a backport of r269499 including the
testism fix r269596 to gcc-8 branch in r269613.
gcc/ChangeLog
On 29/03/2019 11:01, Andrea Corallo wrote:
> Hi all,
> simple patch addressing minor style issue into
> gcc/config/aarch64/cortex-a57-fma-steering.c.
>
> make BOOT_CFLAGS='-mcpu=cortex-a57' bootstrap
>
> Okay for trunk?
>
> Bests
> Andrea
>
>
> 2019-03-29 Andrea Corallo
>
> PR tar
On 05/04/2019 16:53, Andrea Corallo wrote:
>
> Richard Earnshaw (lists) writes:
>
>> On 29/03/2019 11:01, Andrea Corallo wrote:
>>> Hi all,
>>> simple patch addressing minor style issue into
>>> gcc/config/aarch64/cortex-a57-fma-steering.c.
>>>
On 06/04/2019 00:00, Richard Earnshaw (lists) wrote:
> On 05/04/2019 16:53, Andrea Corallo wrote:
>>
>> Richard Earnshaw (lists) writes:
>>
>>> On 29/03/2019 11:01, Andrea Corallo wrote:
>>>> Hi all,
>>>> simple patch addressing minor st
On 08/04/2019 09:59, Andrea Corallo wrote:
>
> Richard Earnshaw (lists) writes:
>
>> Ah, you've just changed the ChangeLog entries. By comments, I meant in
>> the source code, so that it's clear these don't exist. ChangeLog update
>> is good
On 09/04/2019 16:04, Jeff Law wrote:
> On 4/8/19 9:17 AM, co...@sdf.org wrote:
>> Pinging again in the hope of getting the patch in, I'd like to have
>> less outstanding patches :) (I have quite a few and new releases
>> can become painful!)
>>
>> gcc/ChangeLog
>>
>> config.gcc (arm*-*-netbsdelf*)
'to N' is now redundant and misleading given the earlier change to use
.
Removed
* config/aarch64/aarch64.opt (msve-vector-bits): Remove redundant and
obsolete reference to N.
R.
diff --git a/gcc/config/aarch64/aarch64.opt b/gcc/config/aarch64/aarch64.opt
index 5a1e687091c..3dc76
On 01/04/2019 18:23, Steve Ellcey wrote:
> This is a ping**3 for a patch to fix one of the test failures in PR 877763.
> It fixes the gcc.target/aarch64/combine_bfi_1.c failure, but not the other
> ones.
>
> Could one of the Aarch64 maintainers take a look at it? This version of
> the patch was o
On 10/04/2019 21:31, Steve Ellcey wrote:
> On Wed, 2019-04-10 at 11:10 +0100, Richard Earnshaw (lists) wrote:
>>
>> OK with those changes.
>>
>> R.
>
> I made the changes you suggested and checked in the patch. Just to be
> complete, here is the final ve
On 11/04/2019 16:21, Steve Ellcey wrote:
> On Thu, 2019-04-11 at 14:58 +, Steve Ellcey wrote:
>>
>>> You've removed the ..._noshift_alt variant. That wasn't my
>>> intention,
>>> so perhaps you misunderstood what I was trying to say.
>>>
>>> The two versions are both needed, since the register
On 10/04/2019 23:03, Steve Ellcey wrote:
>
> Here is another patch to fix one of the failures
> listed in PR rtl-optimization/87763. This change
> fixes gcc.target/aarch64/lsl_asr_sbfiz.c by adding
> an alternative version of *ashiftsi_extv_bfiz that
> has a subreg in it.
>
> Tested with bootstra
On 18/04/2019 03:38, Martin Sebor wrote:
> The fix for pr89797 committed in r270326 was limited to targets
> with NUM_POLY_INT_COEFFS == 1 which I think is all but aarch64.
> The tests for the fix have been failing with an ICE on aarch64
> because it suffers from more or less the same problem but i
On 18/04/2019 09:58, Richard Earnshaw (lists) wrote:
> On 18/04/2019 03:38, Martin Sebor wrote:
>> The fix for pr89797 committed in r270326 was limited to targets
>> with NUM_POLY_INT_COEFFS == 1 which I think is all but aarch64.
>> The tests for the fix have been failing w
On 24/04/2019 12:10, Iain Buclaw wrote:
> On Wed, 24 Apr 2019 at 09:33, Andreas Schwab wrote:
>>
>> On Apr 24 2019, Iain Buclaw wrote:
>>
>>> This patch adds arch64*-*-linux* as a supported libphobos target,
>>> something that has been passing the testsuite for a while now.
>>>
>>> Committed to t
On 25/04/2019 16:45, Jakub Jelinek wrote:
> On Thu, Apr 25, 2019 at 03:32:41PM +0100, Richard Earnshaw (lists) wrote:
>>> --- a/libphobos/libdruntime/core/sys/posix/sys/stat.d
>>> +++ b/libphobos/libdruntime/core/sys/posix/sys/stat.d
>>> @@ -709,10 +709
On 26/04/2019 15:13, Jeff Law wrote:
> On 4/16/19 10:29 AM, Steve Ellcey wrote:
>> Re-ping. I know there are discussions about bigger changes to fix the
>> various failures listed in PR rtl-optimization/87763 but this patch
>> at least fixes one of them (gcc.target/aarch64/lsl_asr_sbfiz.c).
>>
>>
On 26/04/2019 17:08, Jeff Law wrote:
> On 4/26/19 8:52 AM, Richard Earnshaw (lists) wrote:
>> On 26/04/2019 15:13, Jeff Law wrote:
>>> On 4/16/19 10:29 AM, Steve Ellcey wrote:
>>>> Re-ping. I know there are discussions about bigger changes to fix the
>>
On 26/04/2019 22:54, Jeff Law wrote:
> On 4/26/19 3:09 PM, Segher Boessenkool wrote:
>> On Fri, Apr 26, 2019 at 06:06:37PM +0100, Richard Earnshaw (lists) wrote:
>>> On 26/04/2019 17:08, Jeff Law wrote:
>>>>> So is that valid RTL (DI extract of SI value)? W
On 29/04/2019 17:56, Srinath Parvathaneni wrote:
> Hi All,
>
> This patch is to fix the ICE caused in expand pattern of copysignf
> builtin. This is a back port to r267019 of trunk.
>
> Bootstrapped on aarch64-none-linux-gnu and regression tested on
> aarch64-none-elf.
>
> Ok for gcc 8 branch?
On 29/04/2019 17:58, Srinath Parvathaneni wrote:
> Hi All,
>
> This patch is to fix the ICE caused by expand pattern of copysignf
> builtin. This is a back port to r267019 of trunk.
>
> Bootstrapped on aarch64-none-linux-gnu and regression tested on
> aarch64-none-elf.
>
> Ok for gcc 7 branch?
On 09/04/2019 10:50, Ramana Radhakrishnan wrote:
> This keeps coming up repeatedly and the ACLE has finally added
> __ARM_FEATURE_ATOMICS for the LSE feature in GCC. This is now part of
> the latest ACLE release
> (https://developer.arm.com/docs/101028/latest/5-feature-test-macros)
>
> I know it's
On 16/04/2019 19:32, Jakub Jelinek wrote:
> On Tue, Apr 16, 2019 at 07:50:35PM +0200, Jakub Jelinek wrote:
>> On Fri, Apr 12, 2019 at 05:10:48PM +0100, Ramana Radhakrishnan wrote:
>>> No, that's not right. we should get rid of this.
>>
>> Here is a patch for that.
>>
>> Bootstrapped/regtested on ar
Armv6 has support for unaligned accesses to memory. However, the
thumb1 code patterns were trying to use the 32-bit code constraints.
One failure mode from this was that the patterns are designed to be
compatible with conditional execution and this was then causing an
assert in the compiler.
The
On 18/12/2018 12:53, Mihail Ionescu wrote:
>
>
> On 12/18/2018 09:32 AM, Mihail Ionescu wrote:
>> Hi All,
>>
>> In Thumb mode when the function prologue gets expanded, in case of a
>> multiple register push, additional mov instructions are generated to
>> save the high registers which result in l
-mtpcs-leaf-frame causes an APCS-style backtrace frame to be created
on the stack. This should probably be deprecated, but it did reveal
an issue with the patch I committed previously to improve the code
generation when pushing high registers, in that
thumb_find_work_register had a different idea
On 10/05/2019 00:33, co...@sdf.org wrote:
> On Tue, Apr 09, 2019 at 05:36:47PM +0100, Richard Earnshaw (lists) wrote:
>>> So we're well into stage4 which means technically it's too late for
>>> something like this. However, given it's limited scope I won'
On 15/05/2019 03:39, kugan.vivekanandara...@linaro.org wrote:
> From: Kugan Vivekanandarajah
>
The subject line to this email is not helpful. Why should I be
interested in reviewing this patch? Also, why does it claim to be 2/2
when there's no 1/2 to go with it?
Please include with all patche
On 15/05/2019 13:48, Richard Earnshaw (lists) wrote:
> On 15/05/2019 03:39, kugan.vivekanandara...@linaro.org wrote:
>> From: Kugan Vivekanandarajah
>>
>
> The subject line to this email is not helpful. Why should I be
> interested in reviewing this patch? Also, why
On 20/05/2019 23:42, Joseph Myers wrote:
> I'm not particularly concerned with distinguishing between different names
> and email addresses for an author depending on when or in what capacity
> they contributed a change, or with the cases where a patch was committed
> for someone else and SVN s
On 21/05/2019 15:44, Jeff Law wrote:
> On 5/21/19 8:24 AM, Richard Earnshaw (lists) wrote:
>> On 20/05/2019 23:42, Joseph Myers wrote:
>>
>>> I'm not particularly concerned with distinguishing between different names
>>> and email addresses for an author
On 07/01/2019 22:50, Jeff Law wrote:
On 1/7/19 7:42 AM, Andre Vieira (lists) wrote:
Hi,
This patch fixes the way 'uses_hard_regs_p' handles paradoxical subregs.
The function is supposed to detect whether a register access of 'x'
overlaps with 'set'. For S
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 fla
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 app
And this time with the patch...
On 18/01/2019 11:52, Richard Earnshaw (lists) wrote:
> 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 p
On 18/01/2019 11:52, Richard Earnshaw (lists) wrote:
> 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 thes
e bug. I'm therefore reasonably confident that this idiom
won't be a widely hit problem. I'm therefore looking to mitigate it in
the GCC-7/8 sources rather than try to back-port an ABI changing bug.
I'll post a patch for that shortly.
R.
On 17/12/2018 16:04, Richa
This patch, for gcc 8/9 is a mitigation patch for PR target/88469 where
gcc-6/7/8 miscompile a structure whose alignment is dominated by a
64-bit bitfield member. Since the PCS rules for such a type must ignore
any overalignment of the base type we cannot address this by simply
adding a larger ali
On 22/01/2019 15:20, Richard Biener wrote:
> On Tue, 22 Jan 2019, Richard Earnshaw (lists) wrote:
>
>> This patch, for gcc 8/9 is a mitigation patch for PR target/88469 where
>> gcc-6/7/8 miscompile a structure whose alignment is dominated by a
>> 64-bit bitfield member.
On 22/01/2019 14:50, Jakub Jelinek wrote:
> On Tue, Jan 22, 2019 at 02:10:59PM +, Richard Earnshaw (lists) wrote:
>> @@ -6630,6 +6633,13 @@ arm_needs_doubleword_align (machine_mode mode,
>> const_tree type)
>> Make sure we can warn about that with -Wpsabi.
On 22/01/2019 15:46, Jakub Jelinek wrote:
> On Tue, Jan 22, 2019 at 02:43:38PM +, Richard Earnshaw (lists) wrote:
>> PR target/88469
>> * profile-count.h (profile_count): Add dummy file with 64-bit alignment
>> on arm-based systems using gcc-6/7/8.
>
On 23/01/2019 17:12, David Malcolm wrote:
> Running:
> $ valgrind ./xgcc -B. -c test.c -march=native
> on aarch64 shows a use-after-free in host_detect_local_cpu due
> to the std::string result of aarch64_get_extension_string_for_isa_flags
> only living until immediately after a c_str call.
>
>
On 24/01/2019 15:36, Wilco Dijkstra wrote:
> The TST instruction no longer matches in all cases due to changes in
> Combine. The fix is simple, we now need to allow a subreg as well when
> selecting the cc_mode. This fixes the tst_5.c and tst_6.c failures.
>
> AArch64 regress & bootstrap OK.
>
On 24/01/2019 23:17, Steve Ellcey wrote:
> Here is my attempt at creating a couple of new instructions to
> generate more bfi instructions on aarch64. I haven't finished
> testing this but it helps with gcc.target/aarch64/combine_bfi_1.c.
>
> Before I went any further with it I wanted to see if a
On 15/01/2019 15:28, Kyrill Tkachov wrote:
> Hi all,
>
> This patch adds a tuning struct for the Arm Ares CPU and uses it for
> -m{cpu,tune}=ares.
> The tunings are an initial attempt and may be improved upon in the
> future, but they serve
> as a decent starting point for GCC 9.
>
> With this I
This is pretty unlikely in real code, but similar to Arm, the AArch64
ABI has a bug with the handling of 128-bit bit-fields, where if the
bit-field dominates the overall alignment the back-end code may end up
passing the argument correctly. This is a regression that started in
gcc-6 when the ABI s
Hi,
This patch adds the documentation to the FPU configuration fixes for
Cortex-R7 and Cortex-R8 to changes.html for GCC9.
See https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02183.html
I have validated the html using the W3C validator.
Is it OK?
Cheers,
Andre
? .changes.html.swp
? patch
cvs d
On 11/01/2019 22:54, Jeff Law wrote:
On 1/8/19 8:21 AM, Andre Vieira (lists) wrote:
On 07/01/2019 22:50, Jeff Law wrote:
On 1/7/19 7:42 AM, Andre Vieira (lists) wrote:
Hi,
This patch fixes the way 'uses_hard_regs_p' handles paradoxical subregs.
The function is supposed
PING.
Since Jeff is away can another maintainer have a look at this please?
Cheers,
Andre
On 01/02/2019 14:31, Andre Vieira (lists) wrote:
On 11/01/2019 22:54, Jeff Law wrote:
On 1/8/19 8:21 AM, Andre Vieira (lists) wrote:
On 07/01/2019 22:50, Jeff Law wrote:
On 1/7/19 7:42 AM, Andre
On 03/08/16 23:42, Andrew Pinski wrote:
> Hi,
> This patch adds to the thunderx model, the vector cost model. I
> benchmarked this on SPEC CPU INT 2006 and got a small speed up. I
> have a few more cost model patches that I am going upstream but they
> are going to be split up.
>
> OK? Bootst
On 04/08/16 12:00, Wilco Dijkstra wrote:
> This patch adds legitimize_address_displacement hook so that stack accesses
> with large offsets are split into a more efficient sequence. Byte and
> halfword
> accesses use a 4KB range, wider accesses use a 16KB range to maximise the
> available address
On 04/08/16 12:06, Wilco Dijkstra wrote:
> Improve stack adjustment by reusing a temporary move immediate
> from the epilog if the register is still valid in the epilog. This generates
> smaller code for leaf functions:
>
> mov x16, 4
> sub sp, sp, x16
> ldr
On 04/08/16 22:16, Bernd Edlinger wrote:
> Hi,
>
> this patch introduces a new target hook that allows the target's
> INITIAL_ELIMINATION_OFFSET function to use cached values instead of
> re-computing the frame layout every time.
>
> I have updated the documentation a bit and hope it is clearer
On 04/08/16 16:56, Richard Earnshaw (lists) wrote:
> On 04/08/16 12:06, Wilco Dijkstra wrote:
>> Improve stack adjustment by reusing a temporary move immediate
>> from the epilog if the register is still valid in the epilog. This generates
>> smaller code for leaf functio
On 05/08/16 13:49, Bernd Edlinger wrote:
> On 08/05/16 11:29, Richard Earnshaw (lists) wrote:
>> On 04/08/16 22:16, Bernd Edlinger wrote:
>>> Hi,
>>>
>>> this patch introduces a new target hook that allows the target's
>>> INITIAL_ELIMINATION_OFFS
On 05/08/16 15:17, James Greenhalgh wrote:
> On Fri, Aug 05, 2016 at 11:15:24AM +0100, James Greenhalgh wrote:
>> On Fri, Aug 05, 2016 at 11:00:39AM +0100, Yao Qi wrote:
>>> On Tue, Jul 26, 2016 at 2:55 PM, James Greenhalgh
>>> wrote:
OK? As this is an ABI break, I'm not proposing for it
801 - 900 of 1884 matches
Mail list logo
