Re: [PATCH, ARM] Fix PR77904 testcase failure

Forgot the reference: [1] https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01308.html On Monday, 31 December 2018, Thomas Preudhomme wrote: > Hi Richard, > > On Thursday, 20 December 2018, Richard Earnshaw (lists) < richard.earns...@arm.com> wrote: >> On 14/12/2018 23:28, Th

Re: [PATCH, ARM] Fix PR77904 testcase failure

Hi Richard, On Thursday, 20 December 2018, Richard Earnshaw (lists) < richard.earns...@arm.com> wrote: > 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

[PATCH, committed] Changing maintainer email address

Hi, I've updated my email address in MAINTAINERS file since I'm leaving my company. I'll do the copyright assignment paperwork before contributing any new patches. Best regards, Thomas From c486e31b10ae0ec648ba256a92d5a4bcef1ef83d Mon Sep 17 00:00:00 2001 From: thopre01 Date: Fri, 21 Dec 2018 1

[PATCH, ARM, committed] Fix size-optimization-ieee testcase failure

I've committed the obvious attached patch to fix the gcc.target/arm/size-optimization-ieee-* testcase failures. On some version of dejagnu, options in RUNTESTFLAGS are appended to the command-line and thus any -mfloat-abi=softfp or -mfloat-abi=hard in there overwrite the -mfloat-abi=soft in the dg

Re: [PATCH, ARM] Do softfloat when -mfpu set, -mfloat-abi=softfp and targeting Thumb-1

Good catch. Committed patch in attachment. Best regards, Thomas On Wed, 19 Dec 2018 at 14:13, Richard Earnshaw (lists) wrote: > > On 14/12/2018 21:15, Thomas Preudhomme wrote: > > Hi Richard, > > > > Thanks for catching the problem with this approach. Hopefully this >

[PATCH, ARM] Fix PR77904 testcase failure

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-saved registers which are live in the function does not work

Re: [PATCH, ARM] Do softfloat when -mfpu set, -mfloat-abi=softfp and targeting Thumb-1

: Force an FPU. Testing: No testsuite regression when targeting arm-none-eabi Armv6S-M with -mfloat-abi=softfp Is this ok for stage3? Best regards, Thomas On Thu, 29 Nov 2018 at 14:52, Richard Earnshaw (lists) wrote: > > On 29/11/2018 10:51, Thomas Preudhomme wrote: > > Hi, >

Re: [PATCH, libgcc/ARM & testsuite] Optimize executable size when using softfloat fmul/dmul

enefit from the size optimization. Best regards, Thomas On Fri, 7 Dec 2018 at 14:14, Richard Earnshaw (lists) wrote: > > On 19/11/2018 09:57, Thomas Preudhomme wrote: > > Softfloat single precision and double precision floating-point > > multiplication routines in libgcc share some cod

Re: [PATCH] [RFC] PR target/52813 and target/11807

or message. Best regards, Thomas On Wed, 12 Dec 2018 at 15:13, Christophe Lyon wrote: > > On Wed, 12 Dec 2018 at 14:19, Christophe Lyon > wrote: > > > > On Wed, 12 Dec 2018 at 12:21, Thomas Preudhomme > > wrote: > > > > > > So my understanding is that

Re: [PATCH] [RFC] PR target/52813 and target/11807

solution and r242693 can be reverted. That will remove the failing test. Best regards, Thomas On Wed, 12 Dec 2018 at 10:30, Thomas Preudhomme wrote: > > Hi Christophe, > > That PR was about a bug occuring when sp was clobbered so if it cannot > be clobbered anymore the whole commi

Re: [PATCH] [RFC] PR target/52813 and target/11807

Hi Christophe, That PR was about a bug occuring when sp was clobbered so if it cannot be clobbered anymore the whole commit (r242693) can be removed. Let me check the original code that lead to the PR why it's clobbering sp though. Best regards, Thomas On Wed, 12 Dec 2018 at 09:43, Christophe Ly

Re: [PATCH, ARM] Improve robustness of -mslow-flash-data

nder is to deal with load under those circumstances. Best regards, Thomas On Fri, 30 Nov 2018 at 14:11, Kyrill Tkachov wrote: > > Hi Thomas, > > On 19/11/18 17:56, Thomas Preudhomme wrote: > > Hi, > > > > Current code to handle -mslow-flash-data in machine descript

[PATCH, ARM] Error out when -mfpu set and targeting Thumb-1

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/baseline/softfp.c) fail when targeting -march=armv8-m.base -mfpu

Re: [PATCH, ARM, ping] Improve robustness of -mslow-flash-data

Ping? Best regards, Thomas On 19/11/2018 17:56, Thomas Preudhomme wrote: Hi, Current code to handle -mslow-flash-data in machine description files suffers from a number of issues which this patch fixes: 1) The insn_and_split in vfp.md to load a generic floating-point constant via GPR first

Re: [PATCH, libgcc/ARM & testsuite, ping] Optimize executable size when using softfloat fmul/dmul

Ping? Best regards, Thomas On Mon, 19 Nov 2018 at 10:51, Thomas Preudhomme wrote: > > FWIW, the testcases were taken from > https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01026.html > > Previous approach for fixing tying of fmul to fdiv can be seen in > https://gcc.gnu.org/m

Re: [PATCH, ARM, ping3] PR85434: Prevent spilling of stack protector guard's address on ARM

e the same instruction happening in the prologue to set the canary. In arm backend it was but the PIC access is of the form (mem (reg) (unspec offset)), ie the outermost rtx in the source is not an unspec. Best regards, Thomas On Wed, 21 Nov 2018 at 17:54, Segher Boessenkool wrote: > > On Fr

Re: [PATCH, ARM, ping3] PR85434: Prevent spilling of stack protector guard's address on ARM

Thanks Kyrill. Committed the attached patch. Best regards, Thomas On Wed, 21 Nov 2018 at 16:06, Kyrill Tkachov wrote: > > Hi Thomas, > > Sorry for the delay. > > On 16/11/18 14:56, Thomas Preudhomme wrote: > > Ping? > > > > Best regards, > > >

Re: [PATCH, ARM, ping3] PR85434: Prevent spilling of stack protector guard's address on ARM

t; On 11/16/18 7:56 AM, Thomas Preudhomme wrote: > > Ping? > I thought I acked the target independent stuff a while back. What's > still waiting on review here? > > jeff

[PATCH, ARM] Improve robustness of -mslow-flash-data

Hi, Current code to handle -mslow-flash-data in machine description files suffers from a number of issues which this patch fixes: 1) The insn_and_split in vfp.md to load a generic floating-point constant via GPR first and move it to VFP register are guarded by !reload_completed which is forbidde

Re: [PATCH, libgcc/ARM & testsuite] Optimize executable size when using softfloat fmul/dmul

approach and does not share any code besides the testcases. Best regards, Thomas On Mon, 19 Nov 2018 at 09:57, Thomas Preudhomme wrote: > > Softfloat single precision and double precision floating-point > multiplication routines in libgcc share some code with the > floating-point divis

[PATCH, libgcc/ARM & testsuite] Optimize executable size when using softfloat fmul/dmul

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 being pulled in an executable in softfloat mode even i

Re: [PATCH, ARM, ping3] PR85434: Prevent spilling of stack protector guard's address on ARM

Ping? Best regards, Thomas On Sat, 10 Nov 2018 at 15:07, Thomas Preudhomme wrote: > > Thanks Kyrill. > > Updated patch in attachment. Best regards, > > Thomas > On Thu, 8 Nov 2018 at 15:53, Kyrill Tkachov > wrote: > > > > Hi Thomas, > > >

Re: [PATCH, ARM, ping2] PR85434: Prevent spilling of stack protector guard's address on ARM

Thanks Kyrill. Updated patch in attachment. Best regards, Thomas On Thu, 8 Nov 2018 at 15:53, Kyrill Tkachov wrote: > > Hi Thomas, > > On 08/11/18 09:52, Thomas Preudhomme wrote: > > Ping? > > > > Best regards, > > > > Thomas > > > > On

Re: [PATCH, ARM, ping2] PR85434: Prevent spilling of stack protector guard's address on ARM

Ping? Best regards, Thomas On Thu, 1 Nov 2018 at 16:03, Thomas Preudhomme wrote: > > Ping? > > Best regards, > > Thomas > On Fri, 26 Oct 2018 at 22:41, Thomas Preudhomme > wrote: > > > > Hi, > > > > Please find updated patch to fix PR85434: sp

Re: [PATCH, ARM, ping] PR85434: Prevent spilling of stack protector guard's address on ARM

Ping? Best regards, Thomas On Fri, 26 Oct 2018 at 22:41, Thomas Preudhomme wrote: > > Hi, > > Please find updated patch to fix PR85434: spilling of stack protector > guard's address on ARM. Quite a few changes have been made to the ARM > part since last round of review s

Re: [PATCH, GCC/ARM, ping3] Fix PR87374: ICE with -mslow-flash-data and -mword-relocations

Ping? Best regards, Thomas On Tue, 23 Oct 2018 at 10:10, Thomas Preudhomme wrote: > > Ping? > > Best regards, > > Thomas > > On Mon, 15 Oct 2018 at 16:01, Thomas Preudhomme > wrote: > > > > Ping? > > > > Best regards, > > >

Re: [PATCH, ARM] PR85434: Prevent spilling of stack protector guard's address on ARM

ct_combined_test): Document new standard pattern name. (stack_protect_test): Clarify that the operand for guard's address is legal. *** gcc/testsuite/ChangeLog *** 2018-07-05 Thomas Preud'homme * gcc.target/arm/pr85434.c: New test. Is this ok for trunk? Best regards, Thomas On T

Re: [PATCH, ARM] PR85434: Prevent spilling of stack protector guard's address on ARM

Good thing I did, found a missing earlyclobber in the process. Rerunning all tests again. Best regards, Thomas On Wed, 24 Oct 2018 at 10:13, Thomas Preudhomme wrote: > > Please hold on for the reviews, found a small improvement that could > be done. Am testing it right now, sh

Re: [PATCH, contrib] dg-cmp-results: display NA->FAIL by default

# Compare this new test to the first queued old one. -- 2.19.1 Best regards, Thomas On Thu, 25 Oct 2018 at 08:29, Richard Sandiford wrote: > > Thomas Preudhomme writes: > > And now with the patch. My apologies for the omission. > > > > Best regards, > > > > Th

Re: [PATCH, ARM] PR85434: Prevent spilling of stack protector guard's address on ARM

Please hold on for the reviews, found a small improvement that could be done. Am testing it right now, should have something by tonight or tomorrow. Best regards, Thomas On Tue, 23 Oct 2018 at 13:35, Thomas Preudhomme wrote: > > [Removing Jeff Law since middle end code hasn't chan

[PATCH, testsuite] Fix sibcall-9 and sibcall-10 with -fPIC

Hi, gcc.dg/sibcall-9.c and gcc.dg/sibcall-10.c give execution failure on ARM when compiled with -fPIC due to the PIC access to volatile variable v creating an extra spill which causes the frame size of the two recursive functions to be different. Making the variable static solve the issue because

Re: [PATCH, contrib] dg-cmp-results: display NA->FAIL by default

And now with the patch. My apologies for the omission. Best regards, Thomas On Tue, 23 Oct 2018 at 12:08, Thomas Preudhomme wrote: > > Hi, > > Currently, dg-cmp-results will not print anything for a test that was > not run before, even if it is a FAIL now. This means that when &

Re: [PATCH, ARM] PR85434: Prevent spilling of stack protector guard's address on ARM

e PASS if making the global variable static). Is this ok for trunk? Best regards, Thomas [1] https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01412.html On Tue, 25 Sep 2018 at 17:10, Kyrill Tkachov wrote: > > Hi Thomas, > > On 29/08/18 10:51, Thomas Preudhomme wrote: > > Resend hop

[PATCH, contrib] dg-cmp-results: display NA->FAIL by default

Hi, Currently, dg-cmp-results will not print anything for a test that was not run before, even if it is a FAIL now. This means that when contributing a code change together with a testcase in the same commit one must run dg-cmp-results twice: once to check for regression on a full testsuite run an

Re: [PATCH, GCC/ARM, ping2] Fix PR87374: ICE with -mslow-flash-data and -mword-relocations

Ping? Best regards, Thomas On Mon, 15 Oct 2018 at 16:01, Thomas Preudhomme wrote: > > Ping? > > Best regards, > > Thomas > On Fri, 5 Oct 2018 at 17:50, Thomas Preudhomme > wrote: > > > > Hi Ramana and Kyrill, > > > > I've reworked the patch

Re: [PATCH, GCC/ARM] Fix PR87374: ICE with -mslow-flash-data and -mword-relocations

Ping? Best regards, Thomas On Fri, 5 Oct 2018 at 17:50, Thomas Preudhomme wrote: > > Hi Ramana and Kyrill, > > I've reworked the patch to add some documentation of the option > conflict and reworked the -mword-relocation logic slightly to set the > variable explicitely

Re: [PATCH, GCC/ARM] Fix PR87374: ICE with -mslow-flash-data and -mword-relocations

On Tue, 2 Oct 2018 at 13:39, Ramana Radhakrishnan wrote: > > On 02/10/2018 11:42, Thomas Preudhomme wrote: > > Hi Ramana, > > > > On Thu, 27 Sep 2018 at 11:14, Ramana Radhakrishnan > > wrote: > >> > >> On 27/09/2018 09:26, Kyrill Tkachov wrote: &g

Re: [PATCH, LRA] Never reload fixed form constraints memory operand

12:31, H.J. Lu wrote: > > On Wed, Oct 3, 2018 at 8:12 PM Vladimir Makarov wrote: > > > > On 10/03/2018 12:47 PM, Thomas Preudhomme wrote: > > > Best regards, > > > > > > Thomas > > > > > > never_reload_fixed_address_operand.patch >

[PATCH, LRA] Never reload fixed form constraints memory operand

Hi, The unconditional reload of address operand for recognized instruction in process_address_1 prevent the patch for fixing "PR85434: Address of stack protector guard spilled to stack on ARM" proposed at [1]. The code in this patch attempt to control which registers are used to make PIC access bu

Re: [PATCH, GCC/ARM] Fix PR87374: ICE with -mslow-flash-data and -mword-relocations

Hi Ramana, On Thu, 27 Sep 2018 at 11:14, Ramana Radhakrishnan wrote: > > On 27/09/2018 09:26, Kyrill Tkachov wrote: > > Hi Thomas, > > > > On 26/09/18 18:39, Thomas Preudhomme wrote: > >> Hi, > >> > >> GCC ICEs under -mslow-flash-data and -mwo

[PATCH, GCC/ARM] Fix PR87374: ICE with -mslow-flash-data and -mword-relocations

Hi, GCC ICEs under -mslow-flash-data and -mword-relocations because there is no way to load an address, both literal pools and MOVW/MOVT being forbidden. This patch gives an error message when both options are specified by the user and adds the according dg-skip-if directives for tests that use ei

Re: [PATCH, ARM] PR85434: Prevent spilling of stack protector guard's address on ARM

Hi all, Ping? This new version changes both the middle-end and back-end part so will need a review for both of those. Best regards, Thomas On Wed, 29 Aug 2018 at 11:07, Thomas Preudhomme wrote: > > Forgot another important change in ARM backend: > > The expander were causing

Re: [PATCH, ARM] PR85434: Prevent spilling of stack protector guard's address on ARM

ed by manual inspection of the code. I've attached the interdiff from previous version for reference. Best regards, Thomas On Wed, 29 Aug 2018 at 10:51, Thomas Preudhomme wrote: > > Resend hopefully without HTML this time. > > On Wed, 29 Aug 2018 at 10:49, Thomas Preudhomm

Re: [PATCH, ARM] PR85434: Prevent spilling of stack protector guard's address on ARM

Resend hopefully without HTML this time. On Wed, 29 Aug 2018 at 10:49, Thomas Preudhomme wrote: > > Hi, > > I've reworked the patch fixing PR85434 (spilling of stack protector guard's > address on ARM) to address the testsuite regression on powerpc and x86 as

Re: [PATCH][GCC][AArch64] Limit movmem copies to TImode copies.

Hi Tamar, Thanks for your patch. Just one comment about your ChangeLog entry for the testsuiet change: shouldn't it mention that it is a new testcase? The patch you attached seems to create the file. Best regards, Thomas On Mon, 13 Aug 2018 at 10:33, Tamar Christina wrote: > Hi All, > > On A

[PATCH] Clarify source of tm.texi to copy for GFDL grant

When tm.texi.in is updated in the source tree, the following message gets displayed: Verify that you have permission to grant a GFDL license for all new text in tm.texi, then copy it to /gcc/doc/tm.texi. Having been myself and some colleagues confused several time by that message as to what tm.te

Re: [PATCH][GCC][Arm] Fix subreg crash in different way by enabling the FP16 pattern unconditionally.

On Thu, 26 Jul 2018 at 12:01, Tamar Christina wrote: > > Hi Thomas, > > > -Original Message- > > From: Thomas Preudhomme > > Sent: Thursday, July 26, 2018 09:29 > > To: Tamar Christina > > Cc: gcc-patches@gcc.gnu.org; nd ; Ramana Radhak

Re: [PATCH][GCC][Arm] Fix subreg crash in different way by enabling the FP16 pattern unconditionally.

Hi Tamar, On Wed, 25 Jul 2018 at 16:28, Tamar Christina wrote: > > Hi Thomas, > > Thanks for the review! > > > > > > > I don't believe the TARGET_FP16 guard to be needed, because the > > > pattern doesn't actually generate code and requires another pattern > > > for that, and a reg to reg move sh

Re: [PATCH, ARM] PR85434: Prevent spilling of stack protector guard's address on ARM

8-07-05 Thomas Preud'homme * gcc.target/arm/pr85434.c: New test. Bootstrapped again for Arm and Thumb-2 and regtested with and without -fstack-protector-all without any regression. Best regards, Thomas On Thu, 19 Jul 2018 at 17:34, Thomas Preudhomme wrote: > > [Dropping Jeff

Re: [PATCH][GCC][Arm] Fix subreg crash in different way by enabling the FP16 pattern unconditionally.

Hi Tamar, On Mon, 23 Jul 2018 at 17:56, Tamar Christina wrote: > > Hi All, > > My previous patch changed arm_can_change_mode_class to allow subregs of > 64bit registers on arm big-endian. However it seems that we can't do this > because a the data in 64 bit VFP registers are stored in little-end

Re: [PATCH, ARM] PR85434: Prevent spilling of stack protector guard's address on ARM

[Dropping Jeff Law from the list since he already commented on the middle end parts] Hi Kyrill, On Thu, 19 Jul 2018 at 12:02, Kyrill Tkachov wrote: > > Hi Thomas, > > On 17/07/18 12:02, Thomas Preudhomme wrote: > > Fixed in attached patch. ChangeLog entries are unchange

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

Hi Martin, Why is this needed when -mfpu does not seem to need it for instance? Regarding the patch: > -print "Name(processor_type) Type(enum processor_type)" > -print "Known ARM CPUs (for use with the -mcpu= and -mtune= options):\n" > +print "Name(processor_type) Type(enum processor_

Re: [PATCH, ARM] PR85434: Prevent spilling of stack protector guard's address on ARM

* gcc/testsuite/ChangeLog *** 2018-07-05 Thomas Preud'homme PR target/85434 * gcc.target/arm/pr85434.c: New test. Best regards, Thomas On Mon, 16 Jul 2018 at 22:46, Jeff Law wrote: > > On 07/05/2018 08:48 AM, Thomas Preudhomme wrote: > > In case of high register pres

Re: [PATCH, ARM] PR85434: Prevent spilling of stack protector guard's address on ARM

Adding Jeff and Eric since the patch adds an RTL target hook. Best regards, Thomas On Thu, 5 Jul 2018 at 15:48, Thomas Preudhomme wrote: > > In case of high register pressure in PIC mode, address of the stack > protector's guard can be spilled on ARM targets as shown in P

[PATCH, ARM] PR85434: Prevent spilling of stack protector guard's address on ARM

In case of high register pressure in PIC mode, address of the stack protector's guard can be spilled on ARM targets as shown in PR85434, thus allowing an attacker to control what the canary would be compared against. ARM does lack stack_protect_set and stack_protect_test insn patterns, defining the

[ARM] Fix PR85434: spill of stack protector's guard address

I'll make a fool of myself but I still have further questions if you don't mind (see inline). On Friday, 4 May 2018, Segher Boessenkool wrote: > Hi! > > On Wed, May 02, 2018 at 07:57:55AM +0100, Thomas Preudhomme wrote: >> As mentionned in the ticket this was my fir

Re: [ARM] Fix PR85434: spill of stack protector's guard address

> On Sat, Apr 28, 2018 at 12:32:26AM +0100, Thomas Preudhomme wrote: >> On Arm (Aarch32 and Aarch64) the stack protector's guard is accessed by >> loading its address first before loading its value from it as part of >> the stack_protect_set or stack_protect_check insn pat

[ARM] Fix PR85434: spill of stack protector's guard address

On Arm (Aarch32 and Aarch64) the stack protector's guard is accessed by loading its address first before loading its value from it as part of the stack_protect_set or stack_protect_check insn pattern. This creates the risk of spilling between the two. It is particularly likely on Aarch32 when comp

Re: [PATCH, GCC/ARM] Fix PR85261: ICE with FPSCR setter builtin

Hi Kyrill, On 11/04/18 10:02, Kyrill Tkachov wrote: Hi Thomas, On 09/04/18 15:29, Thomas Preudhomme wrote: Hi Ramana, On 06/04/18 17:17, Thomas Preudhomme wrote: > > > On 06/04/18 17:08, Ramana Radhakrishnan wrote: >> On 06/04/2018 16:54, Thomas Preudhomme wrote: >>>

Re: [PATCH, GCC/ARM] Fix PR85203: cmse_nonsecure_caller returns wrong result

Hi Kyrill, One week went by so I've committed the change to GCC 7 as announced. Best regards, Thomas On 05/04/18 16:36, Kyrill Tkachov wrote: On 05/04/18 16:13, Thomas Preudhomme wrote: Hi Kyrill, On 04/04/18 18:20, Thomas Preudhomme wrote: Hi Kyrill, On 04/04/18 18:19, Kyrill Tk

Re: [PATCH, GCC/ARM] Fix PR85261: ICE with FPSCR setter builtin

Hi Ramana, On 06/04/18 17:17, Thomas Preudhomme wrote: On 06/04/18 17:08, Ramana Radhakrishnan wrote: On 06/04/2018 16:54, Thomas Preudhomme wrote: Instruction pattern for setting the FPSCR expects the input value to be in a register. However, __builtin_arm_set_fpscr expander does not

Re: [PATCH, GCC/ARM] Fix PR85261: ICE with FPSCR setter builtin

On 06/04/18 17:08, Ramana Radhakrishnan wrote: On 06/04/2018 16:54, Thomas Preudhomme wrote: Instruction pattern for setting the FPSCR expects the input value to be in a register. However, __builtin_arm_set_fpscr expander does not ensure that this is the case and as a result GCC ICEs when the

[PATCH, GCC/ARM] Fix PR85261: ICE with FPSCR setter builtin

Instruction pattern for setting the FPSCR expects the input value to be in a register. However, __builtin_arm_set_fpscr expander does not ensure that this is the case and as a result GCC ICEs when the builtin is called with a constant literal. This commit fixes the builtin to force the input valu

Re: [PATCH, GCC/ARM] Fix PR85203: cmse_nonsecure_caller returns wrong result

Hi Kyrill, On 04/04/18 18:20, Thomas Preudhomme wrote: Hi Kyrill, On 04/04/18 18:19, Kyrill Tkachov wrote: Hi Thomas, On 04/04/18 18:03, Thomas Preudhomme wrote: Hi, __builtin_cmse_nonsecure_caller implementation returns true in almost all cases due to 2 separate bugs: * gen_addsi is used

Re: [PATCH, GCC/ARM] Fix PR85203: cmse_nonsecure_caller returns wrong result

Hi Kyrill, On 04/04/18 18:19, Kyrill Tkachov wrote: Hi Thomas, On 04/04/18 18:03, Thomas Preudhomme wrote: Hi, __builtin_cmse_nonsecure_caller implementation returns true in almost all cases due to 2 separate bugs: * gen_addsi is used instead of gen_andsi to retrieve the lsb * the lsb

Re: [PATCH, GCC/ARM] Fix PR85203: cmse_nonsecure_caller returns wrong result

Oops, forgot the link. On 04/04/18 18:03, Thomas Preudhomme wrote: Hi, __builtin_cmse_nonsecure_caller implementation returns true in almost all cases due to 2 separate bugs: * gen_addsi is used instead of gen_andsi to retrieve the lsb * the lsb boolean value is not negated but the

[PATCH, GCC/ARM] Fix PR85203: cmse_nonsecure_caller returns wrong result

Hi, __builtin_cmse_nonsecure_caller implementation returns true in almost all cases due to 2 separate bugs: * gen_addsi is used instead of gen_andsi to retrieve the lsb * the lsb boolean value is not negated but the specification [1] says the intrinsic should return true for a nonsecure caller

[arm-embedded][PATCH] Add multilib mapping for -mcpu=cortex-r52

Hi, Currently -mcpu=cortex-r52 gets assigned the default multilib due to lack of mapping from -mcpu=cortex-r52 to an -march option. This is inconsistent with -march=armv8-r which gets the thumb/v7-ar multilib. This patch adds the appropriate mapping. ChangeLog entry is as follows: *** gcc/Chan

[arm-embedded][PATCH] Add multilib mapping for -mcpu=cortex-m33+nodsp

Hi, Currently -mcpu=cortex-m33+nodsp gets assigned the thumb multilib due to lack of mapping from -mcpu=cortex-m33+nodsp to an -march option. This leads to link failures for linking Armv4T Thumb code from the multilib with Armv8-M Mainline code from the code being compiled. This patch adds the a

[PATCH, GCC/testsuite] Fix FAIL display for some scan-*-times directives

Hi, scan-assembler-times and scan-tree-dump-times dejagnu directives show a different output in the summary files depending on whether they PASS or FAIL. This means that dg-cmp-results would not show a regression because it would not see a connection between the two output. The difference comes

[PATCH, GCC/testsuite/ARM] Fix copysign_softfloat_1.c option directives

gcc.target/arm/copysign_softfloat_1.c's use of arm_arch_v6t2 in dg-add-option changes the architecture to -march=armv6t2. Since the test only requires Thumb-2 capable architecture, we just need to add -mthumb on the command line since arm_thumb2_ok guarantees by definition that doing that is enoug

Re: [PATCH, GCC/testsuite] Fix dump-noaddr dumpbase

Finally committed to gcc-7-branch, sorry for doing this so late. I've merged the two commits into one. Patch attached for reference. Best regards, Thomas On 05/12/17 21:26, Mike Stump wrote: On Dec 5, 2017, at 12:56 PM, Thomas Preudhomme wrote: Thanks, I've tested after the t

[arm-embedded] Allow -mcpu=cortex-m33+nodsp

Hi, we decided to apply the following patch to ARM/embedded-7-branch to support -mcpu=cortex-m33+nodsp. DSP instructions are optional for Arm Cortex-M33, yet its -mcpu option does not allow +nodsp. Users are thus left with using -march=armv8-m.main -mtune=cortex-m33. This patch creates a new cpu

[PATCH, arm-embedded] Multilib mapping for Armv8-R

Hi, We have decided to apply the following patch to the ARM/embedded-7-branch to provide better multilib for Armv8-R targets. Due to there being no multilib mapping for Armv8-R, default multilib built for -march=armv4t with softfloat floating-point arithmetic is being used. This patch maps it in

Re: [PATCH, GCC/ARM] Multilib mapping for Armv8-R

ard arm-none-eabi-gcc -march=armv8-r+crc+fp.sp+simd+crypto -mfloat-abi=hard -print-multi-directory: thumb/v7+fp/hard On 13/02/18 10:27, Kyrill Tkachov wrote: Hi Thomas, On 13/02/18 10:24, Thomas Preudhomme wrote: Hi, Due to there being no multilib mapping for Armv8-R, default multilib tar

[PATCH, GCC/ARM] Multilib mapping for Armv8-R

Hi, Due to there being no multilib mapping for Armv8-R, default multilib targeting -march=armv4t with softfloat floating-point arithmetic is being used. This patch maps it instead to the existing Armv7 multilibs. Note that since there is no single-precision multilib compatible with R profile, -ma

Re: [PATCH, GCC/testsuite] Fix dump-noaddr dumpbase

n 05/12/17 19:27, Mike Stump wrote: On Dec 5, 2017, at 11:11 AM, Thomas Preudhomme wrote: On 05/12/17 17:54, Andrew Pinski wrote: On Tue, Dec 5, 2017 at 9:50 AM, Thomas Preudhomme wrote: Hi, dump-noaddr test FAILS when $tmpdir is not the same as the directory where runtest is called from.

Re: [PATCH, GCC/testsuite] Fix dump-noaddr dumpbase

On 05/12/17 17:54, Andrew Pinski wrote: On Tue, Dec 5, 2017 at 9:50 AM, Thomas Preudhomme wrote: Hi, dump-noaddr test FAILS when $tmpdir is not the same as the directory where runtest is called from. Note that this does not happen when running make check because tmpdir is set to srcdir. In

[PATCH, GCC/testsuite] Fix dump-noaddr dumpbase

Hi, dump-noaddr test FAILS when $tmpdir is not the same as the directory where runtest is called from. Note that this does not happen when running make check because tmpdir is set to srcdir. In that case, file mkdir will create the directory in the current directory while GCC is invoked from tmp

[PATCH, GCC/testsuite] Improve fstack_protector effective target

Hi, Effective target fstack_protector fails to return an error for newlib-based target (such as arm-none-eabi targets) which does not support stack protector. This is due to the test being too simplist for stack protection code to be generated by GCC: it does not contain a local buffer and does n

[arm-embedded] [PATCH, GCC/LTO, ping] Fix PR69866: LTO with def for weak alias in regular object file

Hi, We have decided to apply the forwarded patch to the embedded-7-branch to fix an ICE when doing partial LTO with weak symbols. ChangeLog entry is as follows: 2017-11-28 Thomas Preud'homme Backport from mainline 2017-06-15 Jan Hubicka Thomas Preud'

Re: [PATCH, GCC/ARM] Factor out CMSE register clearing code

On 22/11/17 14:45, Kyrill Tkachov wrote: Hi Thomas, On 15/11/17 17:12, Thomas Preudhomme wrote: Hi, Functions cmse_nonsecure_call_clear_caller_saved and cmse_nonsecure_entry_clear_before_return both contain very similar code to clear registers. What's worse, they differ slightly at tim

[PATCH, GCC/ARM] Remove useless variable in CMSE code

Hi, Functions cmse_nonsecure_call_clear_caller_saved () and cmse_nonsecure_entry_clear_before_return () use a separate variable holding a pointer to padding_bits_to_clear array's first entry which is used when calling function compute_not_to_clear_mask (). This does not save space over using &pa

Re: [PATCH, GCC/ARM] Use bitmap to control cmse_nonsecure_call register clearing

Thanks Kyrill. Committed the attached rebased patch (same patch but without the last hunk because a better fix was done in an earlier commit). Best regards, Thomas On 22/11/17 11:57, Kyrill Tkachov wrote: Hi Thomas, On 15/11/17 17:08, Thomas Preudhomme wrote: Hi, As part of r253256

Re: [PATCH, GCC/ARM] Fix cmse_nonsecure_entry return insn size

Hi Kyrill, On 09/11/17 14:26, Kyrill Tkachov wrote: Hi Thomas, On 08/11/17 09:50, Thomas Preudhomme wrote: Hi, A number of instructions are output in assembler form by output_return_instruction () when compiling a function with the cmse_nonsecure_entry attribute for Armv8-M Mainline with

Re: [PATCH] Use bswap framework in store-merging (PR tree-optimization/78821)

Hi Jakub, On 16/11/17 17:06, Jakub Jelinek wrote: Hi! This patch uses the bswap pass framework inside of the store merging pass to handle adjacent stores which produce together a 16/32/64 bit store of bswapped value (loaded or from SSA_NAME) or identity (usually only from SSA_NAME, the code pre

[PATCH, GCC/ARM] Do no clobber r4 in Armv8-M nonsecure call

Hi, Expanders for Armv8-M nonsecure call unnecessarily clobber r4 despite the libcall they perform not writing to r4. Furthermore, the requirement for the branch target address to be in r4 as expected by the libcall is modeled in a convoluted way in the define_insn patterns: the address is a reg

[PATCH, GCC/ARM] Factor out CMSE register clearing code

Hi, Functions cmse_nonsecure_call_clear_caller_saved and cmse_nonsecure_entry_clear_before_return both contain very similar code to clear registers. What's worse, they differ slightly at times so if a bug is found in one careful thoughts is needed to decide whether the other function needs fixing

[PATCH, GCC/ARM] Use bitmap to control cmse_nonsecure_call register clearing

Hi, As part of r253256, cmse_nonsecure_entry_clear_before_return has been rewritten to use auto_sbitmap instead of an integer bitfield to control which register needs to be cleared. This commit continue this work in cmse_nonsecure_call_clear_caller_saved. ChangeLog entry is as follows: *** gcc/

[PATCH, GCC/testsuite/ARM] Rework expectation for call to Armv8-M nonsecure function

Hi, Testcase gcc.target/arm/cmse/cmse-14.c checks whether bar is called via __gnu_cmse_nonsecure_call libcall and not via a direct call. However the pattern is a bit surprising in that it needs to explicitely allow "by" due to allowing anything before the 'b'. This patch rewrites the logic to lo

[PATCH, GCC/testsuite/ARM] Fix selection of effective target for cmse tests

Hi, Some of the tests in the gcc.target/arm/cmse directory (eg. gcc.target/arm/cmse/mainline/bitfield-4.c) are failing when run without an architecture specified in RUNTESTFLAGS due to them not adding the option to select an Armv8-M architecture. This patch fixes the issue by adding the right op

[PATCH, GCC/ARM] Fix ICE in Armv8-M Security Extensions code

Hi, Commit r253825 which introduced some sanity checks for sbitmap revealed a bug in the conversion of cmse_nonsecure_entry_clear_before_return () to using bitmap structure. bitmap_and expects that the two bitmaps have the same length, yet the code in cmse_nonsecure_entry_clear_before_return () h

Re: [PATCH, GCC/testsuite/ARM] Consolidate sources for cmse tests

e and include above file. * gcc.target/arm/cmse/mainline/union-2.c: Likewise. Testing: Running cmse.exp for both Armv8-M Baseline and Mainline shows no regression. Is this ok for trunk? Best regards, Thomas On 10/11/17 11:19, Thomas Preudhomme wrote: For the most part, testcases

[PATCH, GCC/testsuite/ARM] Consolidate sources for cmse tests

For the most part, testcases under gcc.target/arm/cmse/baseline and gcc.target/arm/cmse/mainline are duplicate copies with only different dejagnu directives. Although there is no requirement for them to be similar, having them both identical allow to compare the code generated and make it easier i

[PATCH, GCC/testsuite] Fix retrieval of testname

When gcc-dg-runtest is used to run a test the test is run several times with different options. For clarity of the log, the test infrastructure then append the options to the testname. This means that all the code that must deal with the testcase itself (eg. removing the output files after the tes

[PATCH, GCC/ARM] Fix cmse_nonsecure_entry return insn size

Hi, A number of instructions are output in assembler form by output_return_instruction () when compiling a function with the cmse_nonsecure_entry attribute for Armv8-M Mainline with hardfloat float ABI. However, the corresponding thumb2_cmse_entry_return insn pattern does not account for all thes

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

Hi, DSP instructions are optional for Arm Cortex-M33, yet its -mcpu option does not allow +nodsp. Users are thus left with using -march=armv8-m.main -mtune=cortex-m33. This patch allows +nodsp to -mcpu=cortex-m33. ChangeLog entry is as follows: *** gcc/ChangeLog *** 2017-10-11 Thomas Preud'ho

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

Committed (sorry for delay). Best regards, Thomas On 06/09/17 09:12, Kyrill Tkachov wrote: Hi Thomas, On 05/09/17 10:04, Thomas Preudhomme wrote: Ping? This is ok if a bootstrap and test run on arm-none-linux-gnueabihf shows no problems. Thanks, Kyrill Best regards, Thomas On 25/08

[arm-embedded] [PATCH 3/3, GCC/ARM] Add support for ARM Cortex-R52 processor

y of fp.dp extension for -mcpu=cortex-r52. Best regards, Thomas --- Begin Message --- Hi, On 29/06/17 16:13, Thomas Preudhomme wrote: Please ignore this patch. I'll respin the patch on a more recent GCC. Please find an updated patch in attachment. This patch adds support for the ARM Corte

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

Hi, We have decided to apply the following patch to the embedded-7-branch to enable ARMv8-R support. ChangeLog entry is as follows: *** gcc/ChangeLog.arm *** 2017-09-04 Thomas Preud'homme Backport from mainline 2017-07-14 Thomas Preud'homme * config/arm/arm-isa.h (isa_

  1   2   3   4   5   >