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

[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

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

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

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

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 description files >

[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

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

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 Fri, Nov

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

6/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

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-po

[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

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:

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 so I t

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

w 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 Thu, 25 Oct 2018 at 15:54, Thomas Preudho

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

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, > > > > Thomas > >

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 changed]

[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

tic). 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 hopefully without HTML this time. > &

[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

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 to a

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 in PI

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

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: > >>>

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

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

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

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

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 Preudhomme > wr

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 > well

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

[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

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

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

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 Law from the list si

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

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

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

/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 pressure in PIC m

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 PR8543

[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

[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 <seg...@kernel.crashing.org> wrote: > Hi! > > On Wed, May 02, 2018 at 07:57:55AM +0100, Thomas Preudhomme wrote: >> As mentionned in the tic

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

org> wrote: > Hi! > > 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

[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

Re: Stack protector: leak of guard's address on stack

a CVE for that issue? Best regards, Thomas On 27 April 2018 at 14:38, Jakub Jelinek <ja...@redhat.com> wrote: > On Fri, Apr 27, 2018 at 02:31:25PM +0100, Thomas Preudhomme wrote: > > On x86 yes, it's actually done in the same instruction that's doing the > > compariso

Re: Stack protector: leak of guard's address on stack

at 13:22, Jakub Jelinek <ja...@redhat.com> wrote: > On Fri, Apr 27, 2018 at 01:17:50PM +0100, Thomas Preudhomme wrote: > > It's not the canari which is spilled in this case, but the address to the > > canari. Which means an attacker could make it point to something else >

Re: Stack protector: leak of guard's address on stack

It's not the canari which is spilled in this case, but the address to the canari. Which means an attacker could make it point to something else than the real canari. On 27 April 2018 at 13:16, Jakub Jelinek <ja...@redhat.com> wrote: > On Thu, Apr 19, 2018 at 06:17:26PM +0100, Thomas P

Re: Stack protector: leak of guard's address on stack

Hi there, Any objection to filing a CVE for that? Best regards, Thomas On 19 April 2018 at 18:17, Thomas Preudhomme <thomas.preudho...@linaro.org> wrote: > Hi, > > For stack protector to be robust, at no point in time the guard against > which the canari is compar

Stack protector: leak of guard's address on stack

Hi, For stack protector to be robust, at no point in time the guard against which the canari is compared must be spilled to the stack. This is achieved by having dedicated insn pattern for setting the canari and comparing it against the guard which doesn't reflect at RTL what is happening.

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 Tkachov

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

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

[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

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

[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

[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: ***

[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

[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

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 <thomas.preudho...@foss.arm.com> wrote:

[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

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

t-multi-directory: thumb/v7+fp/hard 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 Ar

[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,

Re: Cortex-r52 FP double precision

ARMv8-R is not listed in t-rmprofile multilib ? Alex On Fri, Jan 26, 2018 at 9:25 PM, Thomas Preudhomme <thomas.preudho...@foss.arm.com> wrote: That or just use -mfpu=auto (as in -mcpu=cortex-r52 -mfpu=auto -mfloat-abi=(softfp|hard)). Best regards, Thomas On 26/01/18 16:44, Alexander F

Re: Cortex-r52 FP double precision

n Fri, Jan 26, 2018 at 12:52 PM, Thomas Preudhomme <thomas.preudho...@foss.arm.com> wrote: Hi Alexander, As mentioned in [1], Arm Cortex-R52 can have either single precision or double precision + Neon. This is reflected in GCC 8 by -mcpu=cortex-r52 defaulting to the latter (double precision +

Re: Cortex-r52 FP double precision

Hi Alexander, As mentioned in [1], Arm Cortex-R52 can have either single precision or double precision + Neon. This is reflected in GCC 8 by -mcpu=cortex-r52 defaulting to the latter (double precision + Neon) and -mcpu=cortex-r52+nofp.dp giving you the former (single precision). [1]

Re: glue file built with compiler in PATH in out of tree testing

On 07/12/17 15:17, Joseph Myers wrote: On Thu, 7 Dec 2017, Thomas Preudhomme wrote: That seems to go counter to the --prefix option of contrib/test_installed which is meant to test a compiler at an arbitrary path. This suggest the compiler is not expected to be in PATH or in any dejagnu

Re: glue file built with compiler in PATH in out of tree testing

Hi Joseph, On 06/12/17 17:53, Joseph Myers wrote: On Wed, 6 Dec 2017, Thomas Preudhomme wrote: == problem == I'm not sure where is the proper place to fix this. Obviously setting CC_FOR_TARGET in contrib/test_installed or when calling runtest manually would work but I wonder if this would

glue file built with compiler in PATH in out of tree testing

Hi, TL;DR: where to tell dejagnu about the compiler to use for building testglue? == context == I've just found out that testglue.c is built using the compiler in PATH when doing out of tree testing rather than using the one specified by GCC_UNDER_TEST (or other *_UNDER_TEST). This is

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

19:27, Mike Stump wrote: On Dec 5, 2017, at 11:11 AM, Thomas Preudhomme <thomas.preudho...@foss.arm.com> wrote: On 05/12/17 17:54, Andrew Pinski wrote: On Tue, Dec 5, 2017 at 9:50 AM, Thomas Preudhomme <thomas.preudho...@foss.arm.com> wrote: Hi, dump-noaddr test FAILS

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 <thomas.preudho...@foss.arm.com> 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

[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

[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

[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

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 times so

[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

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] 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

[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

[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

[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: ***

[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

  1   2   3   4   5   >