This is the mail archive of the
mailing list for the GCC project.
Re: [patch, arm] fix bug in long long divide-by-zero handling
- From: Ramana Radhakrishnan <ramana dot gcc at googlemail dot com>
- To: Sandra Loosemore <sandra at codesourcery dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 17 Feb 2015 08:14:15 +0000
- Subject: Re: [patch, arm] fix bug in long long divide-by-zero handling
- Authentication-results: sourceware.org; auth=none
- References: <54C1ACCE dot 1000308 at codesourcery dot com>
- Reply-to: ramrad01 at arm dot com
On Fri, Jan 23, 2015 at 2:07 AM, Sandra Loosemore
> The ARM run-time ABI says that long long division by zero should return the
> result of calling __aeabi_ldiv0 with an argument that is either zero if the
> numerator is zero, the largest value of the type if the numerator is
> positive, or the smallest value of the type if the numerator is negative.
> We had an internal bug report from Mentor's Nucleus RTOS team that it is
> incorrectly passing the negative magic value for positive numerators between
> 0x80000000LL and 0xffffffffLL.
> There are three implementations of this code in libgcc -- ARM, Thumb-2, and
> ARMv6-m -- and they are all structured similarly and all have the same bug.
> The source of the trouble is that the divide-by-zero handling is first
> checking to see if the high word is zero and substituting the low word
> instead if so, before proceeding to use signed conditionals to handle the
> positive/negative cases. So, it's doing the wrong thing if the high word is
> zero and the high-order bit is set in the low word. The solution I've
> implemented is to test the negative case on the high word first, and then
> bypass the rest of the code, which can simply test zero/nonzero on whichever
> word to distinguish the remaining two cases.
> I've regression-tested this on mainline head with arm-none-eabi, and also in
> our local 4.9-based tree with a much larger set of multilibs to get test
> coverage of all three implementations.
> This isn't a regression (AFAICT, this has never worked properly), so I don't
> know if it's appropriate to consider this for trunk at this time. If not,
> is it OK for when trunk re-opens for GCC 6?
While we are at it I'd rather get this fixed in time for 5.0 and all
release branches rather than wait for 6.0.
> 2015-01-22 Sandra Loosemore <firstname.lastname@example.org>
> * bpabi.S (test_div_by_zero): Make label names consistent
> between thumb2 and arm mode cases. Separate the signed
> comparison on the high word of the numerator from the
> unsigned comparison on the low word.
> * bpabi-v6m.S (test_div_by_zero): Similarly separate signed
> * gcc.target/arm/divzero.c: New test case.