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
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
* 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
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_
[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
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
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
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
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
On Friday 15 January 2016 12:45:04 Ramana Radhakrishnan wrote:
> On Wed, Dec 16, 2015 at 9:11 AM, Thomas Preud'homme
>
> wrote:
> > During reorg pass, thumb1_reorg () is tasked with rewriting mov rd, rn to
> > subs rd, rn, 0 to avoid a comparison against 0 instruction before doing a
> > condition
On Thursday 03 March 2016 09:44:31 Ramana Radhakrishnan wrote:
> On Thu, Mar 3, 2016 at 9:40 AM, Thomas Preudhomme
>
> wrote:
> > On Friday 15 January 2016 12:45:04 Ramana Radhakrishnan wrote:
> >> On Wed, Dec 16, 2015 at 9:11 AM, Thomas Preud'homme
> >>
On Thursday 03 March 2016 15:32:27 Thomas Preudhomme wrote:
> On Thursday 03 March 2016 09:44:31 Ramana Radhakrishnan wrote:
> > On Thu, Mar 3, 2016 at 9:40 AM, Thomas Preudhomme
> >
> > wrote:
> > > On Friday 15 January 2016 12:45:04 Ramana Radhakrishnan wrote:
&g
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
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
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
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
m-none-eabi GCC cross-compiler, neither does it show any regression with
native LTO-bootstrapped x86-64_linux-gnu and aarch64-linux-gnu compilers.
Is this ok for stage4?
Best regards,
Thomas
On 31/03/17 18:07, Richard Biener wrote:
On March 31, 2017 5:23:03 PM GMT+02:00, Jeff Law wrote:
Hi,
The general arm_arch_*_ok procedures check architecture availability by
substituting macros inside a defined preprocessor operator. This limits
them to only check definition of only one macro and force ARMv7VE to be
special cased.
This patch takes advantage of the fact that architecture macr
Ping?
Best regards,
Thomas
On 06/06/17 11:12, Thomas Preudhomme wrote:
On 09/05/17 23:36, Jan Hubicka wrote:
Ping?
Sorry for late reply
My turn to apologize now.
Hi,
This patch fixes an assert failure when linking one LTOed object file
having a weak alias with a regular object file
Hi,
Conditions checked for ARM targets in vector-related effective targets
are inconsistent:
* sometimes arm*-*-* is checked
* sometimes Neon is checked
* sometimes arm_neon_ok and sometimes arm_neon is used for neon check
* sometimes check_effective_target_* is used, sometimes is-effective-targ
Hi,
gen-vect-26.c tests the vectorizer but only requires vect_cmdline_needed
effective target. It should also depends on vect_int to make sure a
vector unit is available on the target. This patch fixes that.
ChangeLog entry is as follows:
*** gcc/testsuite/ChangeLog ***
2017-06-05 Thomas Preu
On 13/06/17 20:22, Christophe Lyon wrote:
Hi Thomas,
On 13 June 2017 at 11:08, Thomas Preudhomme
wrote:
Hi,
Conditions checked for ARM targets in vector-related effective targets
are inconsistent:
* sometimes arm*-*-* is checked
* sometimes Neon is checked
* sometimes arm_neon_ok and
On 14/06/17 09:29, Christophe Lyon wrote:
On 14 June 2017 at 10:25, Thomas Preudhomme
wrote:
On 13/06/17 20:22, Christophe Lyon wrote:
Hi Thomas,
On 13 June 2017 at 11:08, Thomas Preudhomme
wrote:
Hi,
Conditions checked for ARM targets in vector-related effective targets
are
Hi,
dg-cmp-results.sh contrib script is written to work with sum file for
a single tool only. It throws away the header including the first ===
line and everything starting from the following ===, assuming it is the
test result. This does not work well for sum files with results for
multiple tool
I've heard adding the patch usually helps getting it review so here it is. :-)
Best regards,
Thomas
On 07/06/17 16:42, Thomas Preudhomme wrote:
Hi,
The general arm_arch_*_ok procedures check architecture availability by
substituting macros inside a defined preprocessor operator. This l
Hi,
Testcase gcc.target/arm/its.c was added as part of a patch [1] to limit
IT blocks to 2 instructions maximum. However, the patch was only tested
indirectly by *aiming* to check that the assembly output does not
contain a single IT block with all conditional code in it. This was
actually implem
On 14/06/17 18:03, Richard Earnshaw (lists) wrote:
On 14/06/17 17:49, Thomas Preudhomme wrote:
Hi,
Testcase gcc.target/arm/its.c was added as part of a patch [1] to limit
IT blocks to 2 instructions maximum. However, the patch was only tested
indirectly by *aiming* to check that the assembly
Forgetting the patch: check!
Sending it later as a reply to the wrong message: check!
Hopefully I won't check a second time any of those.
Best regards,
Thomas
On 14/06/17 13:30, Thomas Preudhomme wrote:
Hi,
dg-cmp-results.sh contrib script is written to work with sum file for
a single
t
FPU and float ABI (soft). Testing was done with both compare_tests and the
updated dg-cmp-results proposed in
https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01030.html
Is this ok for trunk?
Best regards,
Thomas
On 13/06/17 20:22, Christophe Lyon wrote:
Hi Thomas,
On 13 June 2017 at 11:
On 19/06/17 08:41, Christophe Lyon wrote:
Hi Thomas,
On 15 June 2017 at 18:18, Thomas Preudhomme
wrote:
Hi,
Conditions checked for ARM targets in vector-related effective targets
are inconsistent:
* sometimes arm*-*-* is checked
* sometimes Neon is checked
* sometimes arm_neon_ok and
Wrong copy paste between the patch I tested and the patch I sent. The first and
second command of the sed should be replaced, not the second and third as in the
patch I sent. For more safety I'll rerun the tests.
Best regards,
Thomas
On 15/06/17 17:15, Thomas Preudhomme wrote:
Forge
On 19/06/17 10:16, Thomas Preudhomme wrote:
On 19/06/17 08:41, Christophe Lyon wrote:
Hi Thomas,
On 15 June 2017 at 18:18, Thomas Preudhomme
wrote:
Hi,
Conditions checked for ARM targets in vector-related effective targets
are inconsistent:
* sometimes arm*-*-* is checked
* sometimes
On 19/06/17 15:31, Christophe Lyon wrote:
On 19 June 2017 at 16:11, Thomas Preudhomme
wrote:
On 19/06/17 10:16, Thomas Preudhomme wrote:
On 19/06/17 08:41, Christophe Lyon wrote:
Hi Thomas,
On 15 June 2017 at 18:18, Thomas Preudhomme
wrote:
Hi,
Conditions checked for ARM
Hi,
We have decided to apply the following patch to the ARM/embedded-6-branch and
ARM/embedded-7-branch to implement the __ARM_FEATURE_COPROC coprocessor
intrinsic feature macro.
2017-06-20 Thomas Preud'homme
Backport from mainline
2017-06-20 Prakhar Bahuguna
g
Hi,
We have decided to apply the referenced fix (r249352) to the
ARM/embedded-6-branch along with its initial commit (r249224) to fix an ICE with
LTO and aliases.
Fix PR69866
2017-06-20 Thomas Preud'homme
Backport from mainline
2017-06-15 Jan Hubicka
Hi,
We have decided to apply the following patch to the embedded-6-branch to fix
naming of an ARM intrinsic.
ChangeLog entry is as follows:
2017-06-20 Thomas Preud'homme
Backport from mainline
2017-05-04 Prakhar Bahuguna
gcc/
* gcc/config/arm/arm-builti
Hi,
Function cmse_nonsecure_entry_clear_before_return has code to deal with
high VFP register (D16-D31) while ARMv8-M Baseline and Mainline both do
not support more than 16 double VFP registers (D0-D15). This makes this
security-sensitive code harder to read for not much benefit since
libcall for
pport sum files with multiple tools.
Is this still ok?
Best regards,
Thomas
On 19/06/17 16:55, Mike Stump wrote:
On Jun 14, 2017, at 5:30 AM, Thomas Preudhomme
wrote:
2017-06-14 Thomas Preud'homme
* dg-cmp-results.sh: Keep test result lines rather than throwing
Hi,
Commit r249422 to dg-cmp-results.sh broke the variant selection feature
where one can restrict the regression test to a specific target variant. This
fix restores the feature.
ChangeLog entry is as follows:
*** contrib/ChangeLog ***
2017-06-21 Thomas Preud'homme
* dg-cmp-resul
Hi Kyrill,
On 10/04/17 15:01, Kyrill Tkachov wrote:
Hi Prakhar,
Sorry for the delay,
On 22/03/17 10:46, Prakhar Bahuguna wrote:
The GCC documentation in section 6.60.8 ARM Floating Point Status and Control
Intrinsics states that the FPSCR register can be read and written to using the
intrinsic
Hi Christophe,
On 23/06/17 20:10, Christophe Lyon wrote:
Hi Thomas,
On 23 June 2017 at 17:48, Thomas Preudhomme
wrote:
Hi Kyrill,
On 10/04/17 15:01, Kyrill Tkachov wrote:
Hi Prakhar,
Sorry for the delay,
On 22/03/17 10:46, Prakhar Bahuguna wrote:
The GCC documentation in section
Hi,
As raised by Christophe Lyon, fpscr.c FAILs because arm_fp_ok and arm_fp
are not defined in GCC 5. This commit changes the test to use the same
recipe as gcc.target/arm/cmp-2.c
ChangeLog entry is as follows:
*** gcc/testsuite/ChangeLog ***
2017-06-26 Thomas Preud'homme
* gcc.t
Hi Christophe,
On 21/06/17 17:57, Christophe Lyon wrote:
Hi,
On 19 June 2017 at 11:32, Richard Earnshaw (lists)
wrote:
On 16/06/17 15:56, Prakhar Bahuguna wrote:
On 16/06/2017 15:37:18, Richard Earnshaw (lists) wrote:
On 16/06/17 08:48, Prakhar Bahuguna wrote:
On 15/06/2017 17:23:43, Rich
On 26/06/17 15:16, Christophe Lyon wrote:
On 26 June 2017 at 16:09, Thomas Preudhomme
wrote:
Hi Christophe,
On 21/06/17 17:57, Christophe Lyon wrote:
Hi,
On 19 June 2017 at 11:32, Richard Earnshaw (lists)
wrote:
On 16/06/17 15:56, Prakhar Bahuguna wrote:
On 16/06/2017 15:37:18
On 26/06/17 17:01, Thomas Preudhomme wrote:
On 26/06/17 15:16, Christophe Lyon wrote:
You mean the macro is expected not to be defined on ARMv8-A ?
Correct. Most instructions its value represent are not available on ARMv8-A and
for those that are the intrinsics are deprecated.
I&#x
Ping?
Best regards,
Thomas
On 26/06/17 12:32, Thomas Preudhomme wrote:
Hi,
As raised by Christophe Lyon, fpscr.c FAILs because arm_fp_ok and arm_fp
are not defined in GCC 5. This commit changes the test to use the same
recipe as gcc.target/arm/cmp-2.c
ChangeLog entry is as follows
On 20/06/17 13:44, Christophe Lyon wrote:
The results with a more recent trunk (r249356)) are here:
http://people.linaro.org/~christophe.lyon/cross-validation/gcc-test-patches/249356-consistent_neon_check.patch/report-build-info.html
They are slightly different, but still tedious to check ;-)
On 28/06/17 15:59, Kyrill Tkachov wrote:
Hi Thomas,
On 28/06/17 15:49, Thomas Preudhomme wrote:
On 20/06/17 13:44, Christophe Lyon wrote:
The results with a more recent trunk (r249356)) are here:
http://people.linaro.org/~christophe.lyon/cross-validation/gcc-test-patches/249356
k and all code related to it and make the remaining
entry a 64-bit scalar integer variable and adapt code accordingly.
Best regards,
Thomas
On 20/06/17 16:01, Thomas Preudhomme wrote:
Hi,
Function cmse_nonsecure_entry_clear_before_return has code to deal with
high VFP register (D1
Hi Richard,
On 28/06/17 16:56, Richard Earnshaw (lists) wrote:
On 20/06/17 16:01, Thomas Preudhomme wrote:
Hi,
Function cmse_nonsecure_entry_clear_before_return has code to deal with
high VFP register (D16-D31) while ARMv8-M Baseline and Mainline both do
not support more than 16 double VFP
Hi,
This patch series adds support for the ARMv8-R architecture[1] and ARM
Cortex-R52[2] to GCC. The patch series consist of the following patches:
[ 1/3] Add missing MIDR information for ARM Cortex-R7 and Cortex-R8 processor
[ 2/3] Add support for ARMv8-R architecture
[ 3/3] Add support for A
Hi,
The driver is missing MIDR information for processors ARM Cortex-R7 and
Cortex-R8 to support -march/-mcpu/-mtune=native on the command line.
This patch adds the missing information.
ChangeLog entry is as follows:
*** gcc/ChangeLog ***
2017-01-31 Thomas Preud'homme
* config/arm/
Hi,
This patch adds support for ARMv8-R architecture [1] which was recently
announced. User level instructions for ARMv8-R are the same as those in
ARMv8-A Aarch32 mode so this patch define ARMv8-R to have the same
features as ARMv8-A in ARM backend.
[1]
https://developer.arm.com/products/archi
Hi,
This patch adds support for the ARM Cortex-R52 processor rencently
announced.
[1] https://developer.arm.com/products/processors/cortex-r/cortex-r52
ChangeLog entry is as follows:
*** gcc/ChangeLog ***
2017-01-31 Thomas Preud'homme
* config/arm/arm-cpus.in (cortex-r52): Add new
On 29/06/17 15:34, Christophe Lyon wrote:
On 29 June 2017 at 15:52, Thomas Preudhomme
wrote:
Hi,
This patch series adds support for the ARMv8-R architecture[1] and ARM
Cortex-R52[2] to GCC. The patch series consist of the following patches:
Hi Thomas,
I think you need to rebase your patch
Please ignore this patch. I'll respin the patch on a more recent GCC.
Best regards,
Thomas
On 29/06/17 14:55, Thomas Preudhomme wrote:
Hi,
This patch adds support for ARMv8-R architecture [1] which was recently
announced. User level instructions for ARMv8-R are the same as those in
AR
Please ignore this patch. I'll respin the patch on a more recent GCC.
Best regards,
Thomas
On 29/06/17 14:56, Thomas Preudhomme wrote:
Hi,
This patch adds support for the ARM Cortex-R52 processor rencently
announced.
[1] https://developer.arm.com/products/processors/cortex-r/corte
On 29/06/17 16:12, Christophe Lyon wrote:
On 29 June 2017 at 16:37, Thomas Preudhomme
Why do you link armv8-r architecture definition to cortex-r4?
I understand, where did I do such a thing?
In patch #2 you have:
diff --git a/gcc/config/arm/arm-cpu-data.h b/gcc/config/arm/arm-cpu
Ping?
Best regards,
Thomas
On 28/06/17 12:35, Thomas Preudhomme wrote:
Ping?
Best regards,
Thomas
On 26/06/17 12:32, Thomas Preudhomme wrote:
Hi,
As raised by Christophe Lyon, fpscr.c FAILs because arm_fp_ok and arm_fp
are not defined in GCC 5. This commit changes the test to use the
Hi,
This patch fixes relative pathnames in gcc/ChangeLog for r247584. Committed as
obvious to trunk, GCC 5, 6 and 7.
Best regards,
Thomas
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index f9e00198bbfd352960685b5c72193570e232e68a..39bdcb12ebbad3cdbdce6b9d4dd87c28610e37fe 100644
--- a/gcc/Change
Ping?
Best regards,
Thomas
On 29/06/17 14:55, Thomas Preudhomme wrote:
Hi,
The driver is missing MIDR information for processors ARM Cortex-R7 and
Cortex-R8 to support -march/-mcpu/-mtune=native on the command line.
This patch adds the missing information.
ChangeLog entry is as follows
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
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
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
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
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
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
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
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/
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
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
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
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
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
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
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
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'
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
1 - 100 of 474 matches
Mail list logo
