public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cosmos at claycon dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/55393] New: gcc/g++ multiplies two unsigned integers using the IMULQ instruction
Date: Mon, 19 Nov 2012 11:28:00 -0000	[thread overview]
Message-ID: <bug-55393-4@http.gcc.gnu.org/bugzilla/> (raw)


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

             Bug #: 55393
           Summary: gcc/g++ multiplies two unsigned integers using the
                    IMULQ instruction
    Classification: Unclassified
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: cosmos@claycon.org


g++ -Wall -Wextra -O2 -o mult mult.cpp
g++ (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2)
64bit

mult.cpp:

#include <iostream>

void
display(
        unsigned long int num,
        unsigned long int mult)
{
        unsigned long int tmp = num * mult;
        std::cout << "mult " << mult << "\n num " << num
                << "\n tmp " << tmp << std::endl;

        if (tmp < num)
                std::cout << "overflow" << std::endl;
}

int
main(
        int /* argc */,
        char ** /* argv */)
{
        unsigned long int num = 999999999999999999;
        unsigned long int mult = 1024;

        display(num, mult);
        return 0;
}

Problem:
"overflow" is not displayed as expected.

Analysis:
gcc generates an IMULQ instruction to calculate the value of tmp.
The value of num has bit 63 set.  Since IMULQ sees that argument
as signed, it results in an incorrect number that happens to be
greater than num.

IMULQ will generate the wrong result when the result just fits
into 64 bits too, even though the result would have been correct
(with no overflow) had the proper instruction been used.

Fix:
Whenever the multiplication operands are both unsigned, gcc should
generate an unsigned multiply instruction (MULQ in this case), unless
it can prove that the result would fit into 63 bits.


             reply	other threads:[~2012-11-19 11:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-19 11:28 cosmos at claycon dot org [this message]
2012-11-19 14:03 ` [Bug rtl-optimization/55393] " jakub at gcc dot gnu.org
2012-11-20  7:46 ` cosmos at claycon dot org
2012-11-20  7:56 ` jakub at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-55393-4@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).