| Submitter | Julian Brown |
|---|---|
| Date | July 20, 2012, 10:35 a.m. |
| Message ID | <20120720113552.5b452950@octopus> |
| Download | mbox | patch |
| Permalink | /patch/172198/ |
| State | New |
| Headers | show |
Comments
On Jul 20, 2012, at 3:35 AM, Julian Brown wrote: > On several architectures, the test gcc.c-torture/execute/20101011-1.c > tests the raising of a signal when a division by zero occurs, but at > present the test is simply skipped on ARM. We can make the test > slightly more useful by using the EABI-provided ability to define a > division-by-zero handling function which raises SIGFPE -- thus > mimicking the behaviour of other targets, and allowing us to run the > test as intended. > > If the target has hardware integer division instructions, the test is > still skipped. > > OK to apply? Ok. (with the idea that the arm folks have the last say...)
On 20/07/12 11:35, Julian Brown wrote: > Hi, > > On several architectures, the test gcc.c-torture/execute/20101011-1.c > tests the raising of a signal when a division by zero occurs, but at > present the test is simply skipped on ARM. We can make the test > slightly more useful by using the EABI-provided ability to define a > division-by-zero handling function which raises SIGFPE -- thus > mimicking the behaviour of other targets, and allowing us to run the > test as intended. > > If the target has hardware integer division instructions, the test is > still skipped. > > The new test passes for a bare-metal config. OK to apply? > Which permutations (CPU, ARM, Thumb) did you test? R. > Thanks, > > Julian > > ChangeLog > > gcc/testsuite/ > * gcc.c-torture/execute/20101011-1.c (__aeabi_idiv0): Define for > ARM. > (DO_TEST): Define to 1 for appropriate ARM targets. > > > div-by-zero-trapping-2.diff > > > Index: gcc/testsuite/gcc.c-torture/execute/20101011-1.c > =================================================================== > --- gcc/testsuite/gcc.c-torture/execute/20101011-1.c (revision 189656) > +++ gcc/testsuite/gcc.c-torture/execute/20101011-1.c (working copy) > @@ -15,9 +15,6 @@ > #elif defined (__TMS320C6X__) > /* On TI C6X division by zero does not trap. */ > # define DO_TEST 0 > -#elif defined (__arm__) > - /* We cannot rely on division by zero generating a trap. */ > -# define DO_TEST 0 > #elif defined (__mips__) && !defined(__linux__) > /* MIPS divisions do trap by default, but libgloss targets do not > intercept the trap and raise a SIGFPE. The same is probably > @@ -36,6 +33,24 @@ > /* Attempting to trap division-by-zero in this way isn't likely to work on > bare-metal m68k systems. */ > # define DO_TEST 0 > +#elif defined (__arm__) && defined (__ARM_EABI__) > +# ifdef __ARM_ARCH_EXT_IDIV__ > + /* Hardware division instructions may not trap, and handle trapping > + differently anyway. Skip the test if we have those instructions. */ > +# define DO_TEST 0 > +# else > +# include <signal.h> > + /* ARM division-by-zero behaviour is to call a helper function, which > + can do several different things, depending on requirements. Emulate > + the behaviour of other targets here by raising SIGFPE. */ > +int __attribute__((used)) > +__aeabi_idiv0 (int return_value) > +{ > + raise (SIGFPE); > + return return_value; > +} > +# define DO_TEST 1 > +# endif > #else > # define DO_TEST 1 > #endif >
On Fri, 20 Jul 2012 17:24:36 +0100 Richard Earnshaw <rearnsha@arm.com> wrote: > On 20/07/12 11:35, Julian Brown wrote: > > Hi, > > > > On several architectures, the test > > gcc.c-torture/execute/20101011-1.c tests the raising of a signal > > when a division by zero occurs, but at present the test is simply > > skipped on ARM. We can make the test slightly more useful by using > > the EABI-provided ability to define a division-by-zero handling > > function which raises SIGFPE -- thus mimicking the behaviour of > > other targets, and allowing us to run the test as intended. > > > > If the target has hardware integer division instructions, the test > > is still skipped. > > > > The new test passes for a bare-metal config. OK to apply? > > > > Which permutations (CPU, ARM, Thumb) did you test? > > R. On mainline, merely the defaults for an arm-none-eabi toolchain, i.e. armv4t, -marm and -mthumb. On our internal branches (where a version of the patch has been present for some time), a much wider set of CPUs, including Cortex-M's and so forth with hardware multiplication instructions. (The list is approximately: ARMv4 ARM & Thumb, ARMv5te ARM mode with & without VFP, various ARMv7-A configs including ARM & Thumb-2 mode, Cortex-M3 & VFP-enabled Cortex-M4.) Julian
On 20/07/12 17:52, Julian Brown wrote: > On Fri, 20 Jul 2012 17:24:36 +0100 > Richard Earnshaw <rearnsha@arm.com> wrote: > >> On 20/07/12 11:35, Julian Brown wrote: >>> Hi, >>> >>> On several architectures, the test >>> gcc.c-torture/execute/20101011-1.c tests the raising of a signal >>> when a division by zero occurs, but at present the test is simply >>> skipped on ARM. We can make the test slightly more useful by using >>> the EABI-provided ability to define a division-by-zero handling >>> function which raises SIGFPE -- thus mimicking the behaviour of >>> other targets, and allowing us to run the test as intended. >>> >>> If the target has hardware integer division instructions, the test >>> is still skipped. >>> >>> The new test passes for a bare-metal config. OK to apply? >>> >> >> Which permutations (CPU, ARM, Thumb) did you test? >> >> R. > > On mainline, merely the defaults for an arm-none-eabi toolchain, i.e. > armv4t, -marm and -mthumb. On our internal branches (where a version > of the patch has been present for some time), a much wider set of CPUs, > including Cortex-M's and so forth with hardware multiplication > instructions. > > (The list is approximately: ARMv4 ARM & Thumb, ARMv5te ARM mode with & > without VFP, various ARMv7-A configs including ARM & Thumb-2 mode, > Cortex-M3 & VFP-enabled Cortex-M4.) > > Julian > OK, I'm happy with that. R.
Patch
Index: gcc/testsuite/gcc.c-torture/execute/20101011-1.c =================================================================== --- gcc/testsuite/gcc.c-torture/execute/20101011-1.c (revision 189656) +++ gcc/testsuite/gcc.c-torture/execute/20101011-1.c (working copy) @@ -15,9 +15,6 @@ #elif defined (__TMS320C6X__) /* On TI C6X division by zero does not trap. */ # define DO_TEST 0 -#elif defined (__arm__) - /* We cannot rely on division by zero generating a trap. */ -# define DO_TEST 0 #elif defined (__mips__) && !defined(__linux__) /* MIPS divisions do trap by default, but libgloss targets do not intercept the trap and raise a SIGFPE. The same is probably @@ -36,6 +33,24 @@ /* Attempting to trap division-by-zero in this way isn't likely to work on bare-metal m68k systems. */ # define DO_TEST 0 +#elif defined (__arm__) && defined (__ARM_EABI__) +# ifdef __ARM_ARCH_EXT_IDIV__ + /* Hardware division instructions may not trap, and handle trapping + differently anyway. Skip the test if we have those instructions. */ +# define DO_TEST 0 +# else +# include <signal.h> + /* ARM division-by-zero behaviour is to call a helper function, which + can do several different things, depending on requirements. Emulate + the behaviour of other targets here by raising SIGFPE. */ +int __attribute__((used)) +__aeabi_idiv0 (int return_value) +{ + raise (SIGFPE); + return return_value; +} +# define DO_TEST 1 +# endif #else # define DO_TEST 1 #endif
Hi, On several architectures, the test gcc.c-torture/execute/20101011-1.c tests the raising of a signal when a division by zero occurs, but at present the test is simply skipped on ARM. We can make the test slightly more useful by using the EABI-provided ability to define a division-by-zero handling function which raises SIGFPE -- thus mimicking the behaviour of other targets, and allowing us to run the test as intended. If the target has hardware integer division instructions, the test is still skipped. The new test passes for a bare-metal config. OK to apply? Thanks, Julian ChangeLog gcc/testsuite/ * gcc.c-torture/execute/20101011-1.c (__aeabi_idiv0): Define for ARM. (DO_TEST): Define to 1 for appropriate ARM targets.