Message ID | 71064e87-e296-4bfd-e934-9b582e2ed3de@foss.st.com |
---|---|
State | New |
Headers | show |
Series | arm: Fix multilib mapping for CDE extensions [PR100856] | expand |
ping? On Thu, 15 Jul 2021 at 15:07, Christophe LYON via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > This is a followup to Srinath's recent patch: the newly added test is > failing e.g. on arm-linux-gnueabihf without R/M profile multilibs. > > It is also failing on arm-eabi with R/M profile multilibs if the > execution engine does not support v8.1-M instructions. > > The patch avoids this by adding check_effective_target_FUNC_multilib > in target-supports.exp which effectively checks whether the target > supports linking and execution, like what is already done for other > ARM effective targets. pr100856.c is updated to use it instead of > arm_v8_1m_main_cde_mve_ok (which makes the testcase a bit of a > duplicate with check_effective_target_FUNC_multilib). > > In addition, I noticed that requiring MVE does not seem necessary and > this enables the test to pass even when targeting a CPU without MVE: > since the test does not involve actual CDE instructions, it can pass > on other architecture versions. For instance, when requiring MVE, we > have to use cortex-m55 under QEMU for the test to pass because the > memset() that comes from v8.1-m.main+mve multilib uses LOB > instructions (DLS) (memset is used during startup). Keeping > arm_v8_1m_main_cde_mve_ok would mean we would enable the test provided > we have the right multilibs, causing a runtime error if the simulator > does not support LOB instructions (e.g. when targeting cortex-m7). > > I do not update sourcebuild.texi since the CDE effective targets are > already collectively documented. > > Finally, the patch fixes two typos in comments. > > 2021-07-15 Christophe Lyon <christophe.lyon@foss.st.com> > > PR target/100856 > gcc/ > * config/arm/arm.opt: Fix typo. > * config/arm/t-rmprofile: Fix typo. > > gcc/testsuite/ > * gcc.target/arm/acle/pr100856.c: Use arm_v8m_main_cde_multilib > and arm_v8m_main_cde. > * lib/target-supports.exp: Add > check_effective_target_FUNC_multilib for ARM CDE. > >
ping? https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575310.html On Wed, Aug 4, 2021 at 11:13 AM Christophe Lyon via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > ping? > > On Thu, 15 Jul 2021 at 15:07, Christophe LYON via Gcc-patches > <gcc-patches@gcc.gnu.org> wrote: > > > > This is a followup to Srinath's recent patch: the newly added test is > > failing e.g. on arm-linux-gnueabihf without R/M profile multilibs. > > > > It is also failing on arm-eabi with R/M profile multilibs if the > > execution engine does not support v8.1-M instructions. > > > > The patch avoids this by adding check_effective_target_FUNC_multilib > > in target-supports.exp which effectively checks whether the target > > supports linking and execution, like what is already done for other > > ARM effective targets. pr100856.c is updated to use it instead of > > arm_v8_1m_main_cde_mve_ok (which makes the testcase a bit of a > > duplicate with check_effective_target_FUNC_multilib). > > > > In addition, I noticed that requiring MVE does not seem necessary and > > this enables the test to pass even when targeting a CPU without MVE: > > since the test does not involve actual CDE instructions, it can pass > > on other architecture versions. For instance, when requiring MVE, we > > have to use cortex-m55 under QEMU for the test to pass because the > > memset() that comes from v8.1-m.main+mve multilib uses LOB > > instructions (DLS) (memset is used during startup). Keeping > > arm_v8_1m_main_cde_mve_ok would mean we would enable the test provided > > we have the right multilibs, causing a runtime error if the simulator > > does not support LOB instructions (e.g. when targeting cortex-m7). > > > > I do not update sourcebuild.texi since the CDE effective targets are > > already collectively documented. > > > > Finally, the patch fixes two typos in comments. > > > > 2021-07-15 Christophe Lyon <christophe.lyon@foss.st.com> > > > > PR target/100856 > > gcc/ > > * config/arm/arm.opt: Fix typo. > > * config/arm/t-rmprofile: Fix typo. > > > > gcc/testsuite/ > > * gcc.target/arm/acle/pr100856.c: Use arm_v8m_main_cde_multilib > > and arm_v8m_main_cde. > > * lib/target-supports.exp: Add > > check_effective_target_FUNC_multilib for ARM CDE. > > > > >
ping? On 11/08/2021 16:06, Christophe Lyon wrote: > ping? > https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575310.html > <https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575310.html> > > > On Wed, Aug 4, 2021 at 11:13 AM Christophe Lyon via Gcc-patches > <gcc-patches@gcc.gnu.org <mailto:gcc-patches@gcc.gnu.org>> wrote: > > ping? > > On Thu, 15 Jul 2021 at 15:07, Christophe LYON via Gcc-patches > <gcc-patches@gcc.gnu.org <mailto:gcc-patches@gcc.gnu.org>> wrote: > > > > This is a followup to Srinath's recent patch: the newly added > test is > > failing e.g. on arm-linux-gnueabihf without R/M profile multilibs. > > > > It is also failing on arm-eabi with R/M profile multilibs if the > > execution engine does not support v8.1-M instructions. > > > > The patch avoids this by adding check_effective_target_FUNC_multilib > > in target-supports.exp which effectively checks whether the target > > supports linking and execution, like what is already done for other > > ARM effective targets. pr100856.c is updated to use it instead of > > arm_v8_1m_main_cde_mve_ok (which makes the testcase a bit of a > > duplicate with check_effective_target_FUNC_multilib). > > > > In addition, I noticed that requiring MVE does not seem > necessary and > > this enables the test to pass even when targeting a CPU without MVE: > > since the test does not involve actual CDE instructions, it can pass > > on other architecture versions. For instance, when requiring > MVE, we > > have to use cortex-m55 under QEMU for the test to pass because the > > memset() that comes from v8.1-m.main+mve multilib uses LOB > > instructions (DLS) (memset is used during startup). Keeping > > arm_v8_1m_main_cde_mve_ok would mean we would enable the test > provided > > we have the right multilibs, causing a runtime error if the > simulator > > does not support LOB instructions (e.g. when targeting cortex-m7). > > > > I do not update sourcebuild.texi since the CDE effective targets are > > already collectively documented. > > > > Finally, the patch fixes two typos in comments. > > > > 2021-07-15 Christophe Lyon <christophe.lyon@foss.st.com > <mailto:christophe.lyon@foss.st.com>> > > > > PR target/100856 > > gcc/ > > * config/arm/arm.opt: Fix typo. > > * config/arm/t-rmprofile: Fix typo. > > > > gcc/testsuite/ > > * gcc.target/arm/acle/pr100856.c: Use > arm_v8m_main_cde_multilib > > and arm_v8m_main_cde. > > * lib/target-supports.exp: Add > > check_effective_target_FUNC_multilib for ARM CDE. > > > > >
ping? On 16/08/2021 13:51, Christophe LYON via Gcc-patches wrote: > ping? > > On 11/08/2021 16:06, Christophe Lyon wrote: >> ping? >> https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575310.html >> <https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575310.html> >> >> >> On Wed, Aug 4, 2021 at 11:13 AM Christophe Lyon via Gcc-patches >> <gcc-patches@gcc.gnu.org <mailto:gcc-patches@gcc.gnu.org>> wrote: >> >> ping? >> >> On Thu, 15 Jul 2021 at 15:07, Christophe LYON via Gcc-patches >> <gcc-patches@gcc.gnu.org <mailto:gcc-patches@gcc.gnu.org>> wrote: >> > >> > This is a followup to Srinath's recent patch: the newly added >> test is >> > failing e.g. on arm-linux-gnueabihf without R/M profile multilibs. >> > >> > It is also failing on arm-eabi with R/M profile multilibs if the >> > execution engine does not support v8.1-M instructions. >> > >> > The patch avoids this by adding >> check_effective_target_FUNC_multilib >> > in target-supports.exp which effectively checks whether the target >> > supports linking and execution, like what is already done for >> other >> > ARM effective targets. pr100856.c is updated to use it instead of >> > arm_v8_1m_main_cde_mve_ok (which makes the testcase a bit of a >> > duplicate with check_effective_target_FUNC_multilib). >> > >> > In addition, I noticed that requiring MVE does not seem >> necessary and >> > this enables the test to pass even when targeting a CPU without >> MVE: >> > since the test does not involve actual CDE instructions, it can >> pass >> > on other architecture versions. For instance, when requiring >> MVE, we >> > have to use cortex-m55 under QEMU for the test to pass because the >> > memset() that comes from v8.1-m.main+mve multilib uses LOB >> > instructions (DLS) (memset is used during startup). Keeping >> > arm_v8_1m_main_cde_mve_ok would mean we would enable the test >> provided >> > we have the right multilibs, causing a runtime error if the >> simulator >> > does not support LOB instructions (e.g. when targeting cortex-m7). >> > >> > I do not update sourcebuild.texi since the CDE effective >> targets are >> > already collectively documented. >> > >> > Finally, the patch fixes two typos in comments. >> > >> > 2021-07-15 Christophe Lyon <christophe.lyon@foss.st.com >> <mailto:christophe.lyon@foss.st.com>> >> > >> > PR target/100856 >> > gcc/ >> > * config/arm/arm.opt: Fix typo. >> > * config/arm/t-rmprofile: Fix typo. >> > >> > gcc/testsuite/ >> > * gcc.target/arm/acle/pr100856.c: Use >> arm_v8m_main_cde_multilib >> > and arm_v8m_main_cde. >> > * lib/target-supports.exp: Add >> > check_effective_target_FUNC_multilib for ARM CDE. >> > >> > >>
> -----Original Message----- > From: Gcc-patches <gcc-patches- > bounces+kyrylo.tkachov=arm.com@gcc.gnu.org> On Behalf Of Christophe > LYON via Gcc-patches > Sent: 15 July 2021 14:05 > To: gcc Patches <gcc-patches@gcc.gnu.org> > Subject: [PATCH] arm: Fix multilib mapping for CDE extensions [PR100856] > > This is a followup to Srinath's recent patch: the newly added test is > failing e.g. on arm-linux-gnueabihf without R/M profile multilibs. > > It is also failing on arm-eabi with R/M profile multilibs if the > execution engine does not support v8.1-M instructions. > > The patch avoids this by adding check_effective_target_FUNC_multilib > in target-supports.exp which effectively checks whether the target > supports linking and execution, like what is already done for other > ARM effective targets. pr100856.c is updated to use it instead of > arm_v8_1m_main_cde_mve_ok (which makes the testcase a bit of a > duplicate with check_effective_target_FUNC_multilib). > > In addition, I noticed that requiring MVE does not seem necessary and > this enables the test to pass even when targeting a CPU without MVE: > since the test does not involve actual CDE instructions, it can pass > on other architecture versions. For instance, when requiring MVE, we > have to use cortex-m55 under QEMU for the test to pass because the > memset() that comes from v8.1-m.main+mve multilib uses LOB > instructions (DLS) (memset is used during startup). Keeping > arm_v8_1m_main_cde_mve_ok would mean we would enable the test > provided > we have the right multilibs, causing a runtime error if the simulator > does not support LOB instructions (e.g. when targeting cortex-m7). > > I do not update sourcebuild.texi since the CDE effective targets are > already collectively documented. Ok. Sorry for the delay, I was on holiday. Thanks, Kyrill > > Finally, the patch fixes two typos in comments. > > 2021-07-15 Christophe Lyon <christophe.lyon@foss.st.com> > > PR target/100856 > gcc/ > * config/arm/arm.opt: Fix typo. > * config/arm/t-rmprofile: Fix typo. > > gcc/testsuite/ > * gcc.target/arm/acle/pr100856.c: Use arm_v8m_main_cde_multilib > and arm_v8m_main_cde. > * lib/target-supports.exp: Add > check_effective_target_FUNC_multilib for ARM CDE. >
diff --git a/gcc/config/arm/arm.opt b/gcc/config/arm/arm.opt index af478a946b2..7417b55122a 100644 --- a/gcc/config/arm/arm.opt +++ b/gcc/config/arm/arm.opt @@ -82,7 +82,7 @@ EnumValue Enum(arm_arch) String(native) Value(-1) DriverOnly ; Set to the name of target architecture which is required for -; multilib linking. This option is undocumented becuase it +; multilib linking. This option is undocumented because it ; should not be used by the users. mlibarch= Target RejectNegative JoinedOrMissing NoDWARFRecord DriverOnly Undocumented diff --git a/gcc/config/arm/t-rmprofile b/gcc/config/arm/t-rmprofile index 3e75fcc9635..a6036bf0a51 100644 --- a/gcc/config/arm/t-rmprofile +++ b/gcc/config/arm/t-rmprofile @@ -54,7 +54,7 @@ MULTILIB_REQUIRED += mthumb/march=armv8.1-m.main+mve/mfloat-abi=hard MULTILIB_MATCHES += march?armv6s-m=march?armv6-m # For all MULITIB_MATCHES for v8-m and above add mlibarch? on the right hand side -# of = in the variant string instead of march?. This is needed becuase all the +# of = in the variant string instead of march?. This is needed because all the # MULITIB_MATCHES variant strings are compared with mlibarch option for multilib # linking. diff --git a/gcc/testsuite/gcc.target/arm/acle/pr100856.c b/gcc/testsuite/gcc.target/arm/acle/pr100856.c index 5bc030e2e46..adbe1ab08f7 100644 --- a/gcc/testsuite/gcc.target/arm/acle/pr100856.c +++ b/gcc/testsuite/gcc.target/arm/acle/pr100856.c @@ -1,6 +1,6 @@ /* { dg-do run } */ -/* { dg-require-effective-target arm_v8_1m_main_cde_mve_ok } */ -/* { dg-add-options arm_v8_1m_main_cde_mve } */ +/* { dg-require-effective-target arm_v8m_main_cde_multilib } */ +/* { dg-add-options arm_v8m_main_cde } */ #include "arm_cde.h" diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp index 7f78c5593ac..c29247c5bcf 100644 --- a/gcc/testsuite/lib/target-supports.exp +++ b/gcc/testsuite/lib/target-supports.exp @@ -5518,6 +5518,24 @@ foreach { armfunc armflag armdef arminc } { global et_FUNC_flags return "$flags $et_FUNC_flags" } + + proc check_effective_target_FUNC_multilib { } { + if { ! [check_effective_target_FUNC_ok] } { + return 0; + } + return [check_runtime FUNC_multilib { + #if !(DEF) + #error "DEF failed" + #endif + #include <arm_cde.h> + INC + int + main (void) + { + return 0; + } + } [add_options_for_FUNC ""]] + } }] }
This is a followup to Srinath's recent patch: the newly added test is failing e.g. on arm-linux-gnueabihf without R/M profile multilibs. It is also failing on arm-eabi with R/M profile multilibs if the execution engine does not support v8.1-M instructions. The patch avoids this by adding check_effective_target_FUNC_multilib in target-supports.exp which effectively checks whether the target supports linking and execution, like what is already done for other ARM effective targets. pr100856.c is updated to use it instead of arm_v8_1m_main_cde_mve_ok (which makes the testcase a bit of a duplicate with check_effective_target_FUNC_multilib). In addition, I noticed that requiring MVE does not seem necessary and this enables the test to pass even when targeting a CPU without MVE: since the test does not involve actual CDE instructions, it can pass on other architecture versions. For instance, when requiring MVE, we have to use cortex-m55 under QEMU for the test to pass because the memset() that comes from v8.1-m.main+mve multilib uses LOB instructions (DLS) (memset is used during startup). Keeping arm_v8_1m_main_cde_mve_ok would mean we would enable the test provided we have the right multilibs, causing a runtime error if the simulator does not support LOB instructions (e.g. when targeting cortex-m7). I do not update sourcebuild.texi since the CDE effective targets are already collectively documented. Finally, the patch fixes two typos in comments. 2021-07-15 Christophe Lyon <christophe.lyon@foss.st.com> PR target/100856 gcc/ * config/arm/arm.opt: Fix typo. * config/arm/t-rmprofile: Fix typo. gcc/testsuite/ * gcc.target/arm/acle/pr100856.c: Use arm_v8m_main_cde_multilib and arm_v8m_main_cde. * lib/target-supports.exp: Add check_effective_target_FUNC_multilib for ARM CDE. From baa9ed42d986dd2569697ac8903b3ca70ad73bb9 Mon Sep 17 00:00:00 2001 From: Christophe Lyon <christophe.lyon@foss.st.com> Date: Thu, 15 Jul 2021 12:57:18 +0000 Subject: [PATCH] arm: Fix multilib mapping for CDE extensions [PR100856] This is a followup to Srinath's recent patch: the newly added test is failing e.g. on arm-linux-gnueabihf without R/M profile multilibs. It is also failing on arm-eabi with R/M profile multilibs if the execution engine does not support v8.1-M instructions. The patch avoids this by adding check_effective_target_FUNC_multilib in target-supports.exp which effectively checks whether the target supports linking and execution, like what is already done for other ARM effective targets. pr100856.c is updated to use it instead of arm_v8_1m_main_cde_mve_ok (which makes the testcase a bit of a duplicate with check_effective_target_FUNC_multilib). In addition, I noticed that requiring MVE does not seem necessary and this enables the test to pass even when targeting a CPU without MVE: since the test does not involve actual CDE instructions, it can pass on other architecture versions. For instance, when requiring MVE, we have to use cortex-m55 under QEMU for the test to pass because the memset() that comes from v8.1-m.main+mve multilib uses LOB instructions (DLS) (memset is used during startup). Keeping arm_v8_1m_main_cde_mve_ok would mean we would enable the test provided we have the right multilibs, causing a runtime error if the simulator does not support LOB instructions (e.g. when targeting cortex-m7). I do not update sourcebuild.texi since the CDE effective targets are already collectively documented. Finally, the patch fixes two typos in comments. 2021-07-15 Christophe Lyon <christophe.lyon@foss.st.com> PR target/100856 gcc/ * config/arm/arm.opt: Fix typo. * config/arm/t-rmprofile: Fix typo. gcc/testsuite/ * gcc.target/arm/acle/pr100856.c: Use arm_v8m_main_cde_multilib and arm_v8m_main_cde. * lib/target-supports.exp: Add check_effective_target_FUNC_multilib for ARM CDE. --- gcc/config/arm/arm.opt | 2 +- gcc/config/arm/t-rmprofile | 2 +- gcc/testsuite/gcc.target/arm/acle/pr100856.c | 4 ++-- gcc/testsuite/lib/target-supports.exp | 18 ++++++++++++++++++ 4 files changed, 22 insertions(+), 4 deletions(-)