[Bug c/35885] New: unsinged long long and while loop evaluation regression?

[Bug c/35885] New: unsinged long long and while loop evaluation regression?

[wilbert at jdg dot info]

The following program:
#include <stdio.h>

int main(int argc, char **argv) {
        unsigned int    testu32a = 0x506f85f;
        unsigned long long      testu64a = 0x9afa246709018f48ULL;

        printf("before: testu64a = %08x%08x, testu32a = %08x\n", (unsigned
int)( testu64a >> 32 ), (unsigned int)( testu64a & 0xffffffff ), testu32a );

        while ((unsigned long long)testu32a * (unsigned long long)0xffffffff <
testu64a)
                testu64a /= 2;

        printf("after: testu64a = %08x%08x, testu32a = %08x\n", (unsigned int)(
testu64a >> 32 ), (unsigned int)( testu64a & 0xffffffff ), testu32a );

        return 0;
}


When compiled under freebsd 6 using "gcc -o test test.c" gives different
results when using gcc 3.4.4 or gcc 4.2.4:

Using 3.4.4:
before: testu64a = 9afa246709018f48, testu32a = 0506f85f
after: testu64a = 04d7d12338480c7a, testu32a = 0506f85f

Using 4.2.4:
before: testu64a = 9afa246709018f48, testu32a = 0506f85f
after: testu64a = 9afa246709018f48, testu32a = 0506f85f


The behavior of 4.2.4 has also been seen on a linux gentoo machine running gcc
4.1.2, a 64bit xp machine running gcc 4.2.1, and a regular xp machine running
gcc 4.2.1.


-- 
           Summary: unsinged long long and while loop evaluation regression?
           Product: gcc
           Version: 4.2.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: wilbert at jdg dot info
 GCC build triplet: several
  GCC host triplet: several
GCC target triplet: several


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

[Bug c/35885] unsigned long long and while loop evaluation regression?

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2008-04-09 13:05 -------
This works for me.


-- 


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

[Bug c/35885] unsigned long long and while loop evaluation regression?

[wilbert at jdg dot info]

------- Comment #2 from wilbert at jdg dot info  2008-04-09 15:36 -------
I just did a fresh build of gcc 4.1.3 from the ports collection under freebsd
6.1

And got this (incorrect) result again:
before: testu64a = 9afa246709018f48, testu32a = 0506f85f
after: testu64a = 9afa246709018f48, testu32a = 0506f85f


-- 


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

[Bug c/35885] unsigned long long and while loop evaluation regression?

[wilson at tuliptree dot org]

------- Comment #3 from wilson at tuliptree dot org  2008-04-12 00:45 -------
Subject: Re:   New: unsinged long long and while loop evaluation
 regression?

I can reproduce this on a 32-bit x86-linux machine (i.e. a 32-bit HWI). 
  The unsigned long long 0xffffffff becomes a (const_double -1 0), and 
then in expand_mult in expmed.c we have
           /* If we are multiplying in DImode, it may still be a win 

              to try to work with shifts and adds.  */
           if (CONST_DOUBLE_HIGH (op1) == 0)
             coeff = CONST_DOUBLE_LOW (op1);
After this line, expand_mult thinks we are multiplying by -1 and we get 
the wrong result.

I think there is a false assumption here that we can get CONST_DOUBLEs 
which can be simplified to a single word.  Maybe in the olden days we 
always created a CONST_DOUBLE for DImode constants?  This stuff has 
changed so many times it is hard to remember.  I don't think we do it 
that way anymore.

Anyways, if this assumption is not false, then the code needs to look 
more like the code in immed_double_const in emit-rtl.c, which does
   /* If this integer fits in one word, return a CONST_INT.  */
   if ((i1 == 0 && i0 >= 0) || (i1 == ~0 && i0 < 0))
     return GEN_INT (i0);
where i1 is CONST_DOUBLE_HIGH and i0 is CONST_DOUBLE_LOW, and only in 
the case that this tests succeeds can we set coeff to CONST_DOUBLE_LOW.

The same bug is in mainline, and probably goes a long ways back.

Jim


-- 


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

[Bug middle-end/35885] unsigned long long and while loop evaluation regression?

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2008-04-12 03:10 -------
I think this is one of the reasons why x86 should change to HWI is 64bits, it
will get the same code generation between using -m32 on x86_64 and i?86.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
          Component|c                           |middle-end
  GCC build triplet|several                     |
   GCC host triplet|several                     |
 GCC target triplet|several                     |HWI == 32bits


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

[Bug middle-end/35885] unsigned long long and while loop evaluation regression?

[wilson at gcc dot gnu dot org]

------- Comment #5 from wilson at gcc dot gnu dot org  2008-04-15 00:25 -------
Gcc-2.5.8 uses the code I suggested was correct.  gcc-2.6.3 does not.  The
ChangeLog entry is

Fri Aug  5 12:29:42 1994  Jim Wilson  (wilson@cygnus.com)

        * expmed.c (expand_mult): Accept DImode for synth_mult only if
        CONST_DOUBLE_HIGH is zero.  Reject negative values for synth_mult
        if the mode is larger than HOST_BITS_PER_INT.  Don't do the
        negate_variant if the mode is larger than HOST_BITS_PER_INT.

So it seems that we used to allow any constant that would fit in a signed HWI,
then I found a bug with negative values so I changed it to any constant that
would fit in an unsigned HWI.  Now we found another bug with a constant that
doesn't fit in a signed HWI but does fit in an unsigned HWI.

So now the apparent solution is to only accept positive values that fit in a
signed HWI.  But of course such values should never be found in a CONST_DOUBLE
anyways.  If they fit in a signed HWI they would have been emitted as a
CONST_INT in the first place.  I think we should just drop all of this
CONST_DOUBLE nonsense.


-- 


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

[Bug middle-end/35885] [4.3/4.4/4.5 Regression] unsigned long long and while loop evaluation regression?

[jsm28 at gcc dot gnu dot org]

-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|unsigned long long and while|[4.3/4.4/4.5 Regression]
                   |loop evaluation regression? |unsigned long long and while
                   |                            |loop evaluation regression?
   Target Milestone|---                         |4.3.4


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

[Bug middle-end/35885] [4.3/4.4/4.5 Regression] unsigned long long and while loop evaluation regression?

[jakub at gcc dot gnu dot org]

------- Comment #6 from jakub at gcc dot gnu dot org  2009-04-01 08:18 -------


*** This bug has been marked as a duplicate of 37731 ***


-- 

jakub at gcc dot gnu dot org changed:

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


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