This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
c/693: Optimizer ignores possible zero result of an unsigned multiply
- To: gcc-gnats at gcc dot gnu dot org
- Subject: c/693: Optimizer ignores possible zero result of an unsigned multiply
- From: travis dot moulton at motorola dot com
- Date: 26 Oct 2000 15:20:08 -0000
- Reply-To: travis dot moulton at motorola dot com
- Resent-Cc: gcc-prs at gcc dot gnu dot org, gcc-bugs at gcc dot gnu dot org
- Resent-Reply-To: gcc-gnats@gcc.gnu.org, travis.moulton@motorola.com
>Number: 693
>Category: c
>Synopsis: Optimizer ignores possible zero result of an unsigned multiply
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: wrong-code
>Submitter-Id: net
>Arrival-Date: Thu Oct 26 08:26:00 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator: Travis Moulton
>Release: 2.95.2
>Organization:
>Environment:
m68k
>Description:
In the attached c file. func2 works correctly and is included only for comparison. In func1, the (product > 0) check assumed to always be true. This is wrong since
product can be zero or it can overflow and go negative.
A couple of related notes:
The fact that the compare with 200 is done with both a subq and then a cmp is a bit bogus (though it should work).
On some some Coldfire platforms a cmp immediately followed by a conditional branch, the branch will use the old value of the condition code register. This also occurs in the sample code. I'm waiting to hear from the correct people here at Mot as to whether or not this is an issue with the 5200 (which I targeted in the compile).
>How-To-Repeat:
Compile using the command:
68k_gcc -S -m5200 -O2 tmp.c -o tmp.s
note that the jump to .L3 (the else case) is based only on whether or not product is <= 200.
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: