On 02/07/2019 15:49, Christophe Lyon wrote:
On Tue, 2 Jul 2019 at 12:30, Richard Earnshaw wrote:
On 02/07/2019 11:13, Richard Earnshaw wrote:
On 02/07/2019 09:39, Richard Earnshaw wrote:
On 01/07/2019 16:58, Kyrill Tkachov wrote:
Hi Christophe,
On 6/13/19 4:13 PM, Christophe Lyon
On 02/07/2019 11:13, Richard Earnshaw wrote:
On 02/07/2019 09:39, Richard Earnshaw wrote:
On 01/07/2019 16:58, Kyrill Tkachov wrote:
Hi Christophe,
On 6/13/19 4:13 PM, Christophe Lyon wrote:
Hi,
Similar to what already exists for TI msp430 or in TI compilers for
arm, this patch adds
On 02/07/2019 09:39, Richard Earnshaw wrote:
On 01/07/2019 16:58, Kyrill Tkachov wrote:
Hi Christophe,
On 6/13/19 4:13 PM, Christophe Lyon wrote:
Hi,
Similar to what already exists for TI msp430 or in TI compilers for
arm, this patch adds support for "noinit" attribute for
On 02/07/2019 09:39, Richard Earnshaw wrote:
On 01/07/2019 16:58, Kyrill Tkachov wrote:
Hi Christophe,
On 6/13/19 4:13 PM, Christophe Lyon wrote:
Hi,
Similar to what already exists for TI msp430 or in TI compilers for
arm, this patch adds support for "noinit" attribute for
On 01/07/2019 16:58, Kyrill Tkachov wrote:
Hi Christophe,
On 6/13/19 4:13 PM, Christophe Lyon wrote:
Hi,
Similar to what already exists for TI msp430 or in TI compilers for
arm, this patch adds support for "noinit" attribute for arm. It's very
similar to the corresponding code in GCC for ms
On 25/06/2019 21:22, acsaw...@linux.ibm.com wrote:
> From: Aaron Sawdey
>
> * config/arm/arm-protos.h: Change movmem to cpymem in names.
> * config/arm/arm.c (arm_movmemqi_unaligned, arm_gen_movmemqi,
> gen_movmem_ldrd_strd, thumb_expand_movmemqi) Change movmem to cpymem.
>
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.
>
On 26/06/2019 09:36, Richard Sandiford wrote:
> Jeff Law writes:
>> On 6/25/19 2:22 PM, acsaw...@linux.ibm.com wrote:
>>> From: Aaron Sawdey
>>>
>>> * builtins.c (get_memory_rtx): Fix comment.
>>> * optabs.def (movmem_optab): Change to cpymem_optab.
>>> * expr.c (emit_block_move_via_c
On 20/06/2019 15:10, Nick Clifton wrote:
> Hi Richard,
>
> Please may I apply this patch to the gcc-9, gcc-8 and gcc-7 branches ?
>
> I have tested it on all three branches and found no problems.
>
> Cheers
> Nick
>
> 2019-06-07 Nick Clifton
>
> Import these changes from the bin
I noticed while adding the AArch64 NetBSD support code that we now had
four ports all using and defining the same errata work-around headers.
That's silly and long-term becomes a maintenance burden.
So this patch factors all that code into a single header to eliminate
all the duplication.
* confi
On 18/06/2019 17:20, Nick Clifton wrote:
> Hi Richard,
>
>>> OK, here is a resubmission of my patch with just the addition of the
>>> libctf patches this time.
>
> [Sorry - this one got put on a back burner].
>
>> Would it be feasible to backport this to the other maintained branches
>> so
On 07/06/2019 17:03, Szabolcs Nagy wrote:
> Move the ifunc symbol tests into a separate file with dg-require-ifunc.
> And added a base pcs ifunc symbol to the test for completeness.
>
> gcc/testsuite/ChangeLog:
>
> 2019-06-07 Szabolcs Nagy
>
> * gcc.target/aarch64/pcs_attribute-2.c: Rem
On 18/06/2019 10:11, Joel Hutton wrote:
> Hi,
>
> On 13/06/2019 18:26, Wilco Dijkstra wrote:
>> Wouldn't it be easier to just do exact_log2 (real_to_integer (&r0))
>> and then check the range is in 1..31?
> I've revised this section.
>> --- a/gcc/config/aarch64/aarch64.md
>> +++ b/gcc/config/aarch
On 14/06/2019 16:38, co...@sdf.org wrote:
> Hi folks,
>
> This patch adds support for netbsd/aarch64.
> It would be nice to have it committed, please tell me if anything is
> wrong.
>
> Thanks.
>
> Matthew Green
> Maya Rashish
>
> gcc:
> * config.gcc (aarch64*-*-netbsd*): New target.
>
On 10/06/2019 10:47, Nick Clifton wrote:
> Hi Richard,
>
> OK, here is a resubmission of my patch with just the addition of the
> libctf patches this time. (Sorry about the previous bad patch).
> Tested with a bootstrap and a normal build. OK to apply ?
>
> Cheers
> Nick
Would it be fe
e things removed.
> +LIB1ASMFUNCS += _udivsi3 _divsi3 _umodsi3 _modsi3 _dvmd_tls _bb_init_func \
> + _call_via_rX _interwork_call_via_rX \
> + _arm_fixunsdfsi _arm_fixunssfsi \
> + _arm_floatdidf _arm_floatdisf _arm_floatundidf _arm_floatundisf \
> + _lshrdi3 _ashrdi3
On 13/06/2019 14:00, Alexandre Oliva wrote:
> On Jun 12, 2019, Alexandre Oliva wrote:
>
>> I'm looking into a regression between gcc-7 and gcc-8 that causes
>> compilation with -mfloat-abi=hard to fail on arm-eabi with:
>
>> $ arm-eabi-gcc -c -mfloat-abi=hard t.c
>> cc1: error: -mfloat-abi=hard:
On 29/05/2019 14:46, Richard Biener wrote:
> On Wed, May 29, 2019 at 3:40 PM Nick Clifton wrote:
>>
>> Hi Guys,
>>
>> I would like to bring over a few additions that have recently been
>> made to the binutils versions of the Makefile.def and configure.ac
>> files. Any objections ?
>>
>> N
On 07/06/2019 00:50, Ian Lance Taylor wrote:
> On Thu, Jun 6, 2019 at 4:41 PM Joseph Myers wrote:
>>
>> On Thu, 6 Jun 2019, Richard Earnshaw (lists) wrote:
>>
>>>> For email addresses, I think that using @gcc.gnu.org would be the best
>>>> approach fo
On 05/06/2019 19:04, Jason Merrill wrote:
> On 6/3/19 6:33 PM, Joseph Myers wrote:
>> On Sun, 2 Jun 2019, Segher Boessenkool wrote:
>>
> Git has an identity (well, two) _per commit_, and there is no way
> you can
> reconstruct people's prefered name and email address (at any point
>
On 24/05/2019 11:28, Matthew Malcomson wrote:
> Commit r271514 missed changing the type of two functions in
> aarch64-protos.h. The function definitions had been updated to use
> uint64_t while the function declarations had been missed.
> They were missed since I only tested the patch on aarch64 w
On 23/05/2019 17:01, Richard Earnshaw (lists) wrote:
> On 23/05/2019 15:11, Richard Earnshaw (lists) wrote:
>> On 23/05/2019 15:03, Richard Earnshaw (lists) wrote:
>>> On 20/05/2019 20:24, Jeff Law wrote:
>>>> On 4/9/19 10:36 AM, Richard Earnshaw (lists) wrote:
>&
On 23/05/2019 15:11, Richard Earnshaw (lists) wrote:
> On 23/05/2019 15:03, Richard Earnshaw (lists) wrote:
>> On 20/05/2019 20:24, Jeff Law wrote:
>>> On 4/9/19 10:36 AM, Richard Earnshaw (lists) wrote:
>>>> On 09/04/2019 16:04, Jeff Law wrote:
>>>&g
On 23/05/2019 15:03, Richard Earnshaw (lists) wrote:
> On 20/05/2019 20:24, Jeff Law wrote:
>> On 4/9/19 10:36 AM, Richard Earnshaw (lists) wrote:
>>> On 09/04/2019 16:04, Jeff Law wrote:
>>>> On 4/8/19 9:17 AM, co...@sdf.org wrote:
>>>>> Pinging again
On 20/05/2019 20:24, Jeff Law wrote:
> On 4/9/19 10:36 AM, Richard Earnshaw (lists) wrote:
>> 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
>>>&
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 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 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 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 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'
-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
g
related to the CPU or architecture.
Whilst reviewing this patch I noticed that we could probably do better
when generating prologue and epilogue code in situations similar to
this. Specifically, that we could often make more use of the low
registers rather than forcing a work register and th
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 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
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
V_INT_EQUIV): Add mode for
> integer equivalent of floating point values.
>
> Backport from mainline
> 2018-12-11 Richard Earnshaw
>
> PR target/37369
> * config/aarch64/iterators.md (sizem1): Add sizes for
> SFmode and DFmode.
>
;
> Ok for gcc 8 branch? If ok, could someone commit the patch on my behalf,
> I don't have commit rights.
Applied.
R.
>
> *** gcc/ChangeLog ***
>
> 2019-04-29 Srinath Parvathaneni
>
> Backport from mainline
> 2018-12-11 Richard Earns
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 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 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 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 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 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 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 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 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 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 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
'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 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*)
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 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 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 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 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
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 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 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 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
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/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 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
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
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 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 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 22/01/2019 15:46, Jakub Jelinek wrote:
> On Tue, Jan 22, 2019 at 02:43:38PM +0000, 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 22/01/2019 14:50, Jakub Jelinek wrote:
> On Tue, Jan 22, 2019 at 02:10:59PM +0000, 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: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.
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
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
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
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
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
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
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 callee-sav
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 TARGE
On the 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 a
.
R.
>
> *** 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?
>
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 -
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 th
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 r1
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 aarch64.
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.
For
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 cou
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 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 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
> +++ h
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 se
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
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 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_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/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 repl
901 - 1000 of 2759 matches
Mail list logo
