diff mbox

[ARM] Tweak gcc.c-torture/execute/20101011-1.c to test division-by-zero trapping on ARM

Message ID 20120720113552.5b452950@octopus
State New
Headers show

Commit Message

Julian Brown July 20, 2012, 10:35 a.m. UTC
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.

Comments

Mike Stump July 20, 2012, 4:18 p.m. UTC | #1
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...)
Richard Earnshaw July 20, 2012, 4:24 p.m. UTC | #2
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
>
Julian Brown July 20, 2012, 4:52 p.m. UTC | #3
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
Richard Earnshaw July 20, 2012, 4:56 p.m. UTC | #4
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.
diff mbox

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