[Bug target/54723] New: test gcc.target/arm/div64-unwinding.c fails for GNU/Linux target

[Bug target/54723] New: test gcc.target/arm/div64-unwinding.c fails for GNU/Linux target

[janis at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54723

             Bug #: 54723
           Summary: test gcc.target/arm/div64-unwinding.c fails for
                    GNU/Linux target
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: janis@gcc.gnu.org
            Target: arm-none-linux-gnueabi


Test gcc.target/arm/div64-unwinding.c checks that performing a 64-bit division
does not pull in the unwinder.  When Julian Brown added the test he mentioned
that it was for use with bare-metal targets, but the test is not restricted to
them.  When asked about it recently he said "Actually the mechanism through
which the test fails for Linux/glibc is unknown: it might be worth trying to
figure out what causes the unwinder to be pulled into the binary for Linux
toolchains. Or it might not..."

I plan to XFAIL the test for GNU/Linux targets, so this PR provides a handy
place to record additional thoughts about the failure.

[Bug target/54723] test gcc.target/arm/div64-unwinding.c fails for GNU/Linux target

[janis at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54723

Janis Johnson <janis at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #1 from Janis Johnson <janis at gcc dot gnu.org> 2012-10-12 19:27:49 UTC ---
I'm declaring this Not a Bug based on this response from Richard Earnshaw in
<http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00966.html>:

I don't believe there's a bug here.   The ARM EABI defines __aeabi_idiv0 
as a hook that will be called if division by zero occurs.  While the 
default implementation simply raises SIGFPE on linux, it is perfectly 
possible to provide your own definition of this hook and then throw() a 
C++ exception.  In order to do that you'd need unwind information in the 
divdi implementation ([u]divsi tailcalls the hook).

Technically you could argue the same for bare metal, but in that case 
the arguments against the code bloat outweigh this very small corner 
case and users wanting this will have to rebuild their support code.

On linux, I think the presence of the unwind information is correct, 
since the code bloat problem is very much a secondary concern.