[Bug c++/26729] New: bogus 'comparison is always 0' message

[Bug c++/26729] New: bogus 'comparison is always 0' message

[apl at alum dot mit dot edu]

trivial function using POD constructors says "comparison is always 0".

If I remove any of the UInt16 constructors, the warning goes away.
This doesn't seem to happen in gcc-4.1.0


typedef unsigned short UInt16;
UInt16 pipe;

UInt16 cmp ()
{
  UInt16 answer;
  answer = 
    UInt16((((((pipe & UInt16(0x8800u))))))) == UInt16(0x8000u)
    & ((((((pipe & 0x4000)!= 0)
          ? (((((((((pipe & 0x2000u)!= 0))))
                &(((((((pipe & 0x400u)!= 0))
                     ?(((((((((((pipe & 0x1001u)))))
                            ^ 0x1000u))) != 0)))
                     :(((((((((pipe & 0x1001u))))) == 0x1001u))))))))))))
           // Next line is reported as always false
          :((((UInt16((((((pipe & 0x3700u)))))) == UInt16(0x3000u)))))))));
  return answer;
}


-- 
           Summary: bogus 'comparison is always 0' message
           Product: gcc
           Version: 3.4.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: apl at alum dot mit dot edu
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c++/26729] bogus 'comparison is always 0' message

[apl at alum dot mit dot edu]

------- Comment #1 from apl at alum dot mit dot edu  2006-03-17 16:48 -------
Created an attachment (id=11063)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11063&action=view)
g++ -Wall -Werror -Wextra -O2 ...

(almost) trivial test case...


-- 


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

[Bug c++/26729] [3.3/3.4 Regression] bogus 'comparison is always 0' message

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2006-03-17 17:00 -------
Fixed in 4.0.0, 3.4.6 was the last release of 3.4.x.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
           Keywords|                            |diagnostic
         Resolution|                            |FIXED
            Summary|bogus 'comparison is always |[3.3/3.4 Regression] bogus
                   |0' message                  |'comparison is always 0'
                   |                            |message
   Target Milestone|---                         |4.0.0


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

[Bug c++/26729] [3.3/3.4 Regression] bogus 'comparison is always 0' message

[apl at alum dot mit dot edu]

------- Comment #3 from apl at alum dot mit dot edu  2006-03-17 17:04 -------
Any clue as to the specific patch?  We build with -Wall -Wextra -Werror, and
won't be able to upgrade to gcc-4.x for at least another couple of months.


-- 

apl at alum dot mit dot edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |3.4.3
      Known to work|                            |4.1.0 4.0.0


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

[Bug c++/26729] [3.3/3.4 Regression] bogus 'comparison is always 0' message

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2006-03-17 17:07 -------
Who knows, 3.4.x is dead, I would not doubt it was the merge of the tree-ssa
branch into the mainline which fixed this.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|3.4.3                       |3.4.3 3.3.3
      Known to work|4.1.0 4.0.0                 |4.1.0 4.0.0 3.2.3


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

[Bug c++/26729] [3.3/3.4 Regression] bogus 'comparison is always 0' message

[apl at alum dot mit dot edu]

------- Comment #5 from apl at alum dot mit dot edu  2006-03-28 15:09 -------
Created an attachment (id=11135)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11135&action=view)
simpler test that still fails in 4.x compilers

compile with

     g++ -c -Werror -Wall -Wextra -O2 b.cxx


-- 

apl at alum dot mit dot edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #11063|0                           |1
        is obsolete|                            |


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

[Bug c++/26729] [3.3/3.4 Regression] bogus 'comparison is always 0' message

[apl at alum dot mit dot edu]

------- Comment #6 from apl at alum dot mit dot edu  2006-03-28 15:21 -------
I was wrong, this is still broken in GCC 4.0.2 and 4.1.0 although the original
test case doesn't demonstrate the bug.

/tools/linux/gcc-4.1.0/bin/g++ -c -Werror -Wall -Wextra b.cxx -O2
cc1plus: warnings being treated as errors
b.cxx: In function 'void f()':

The slightly simpler test is attached


I did debug this in gcc-3.4.3 sources to discover that the problem was in
dealing with having set overflow on a complemented constant mask extended from
16 to 32 bits in fold_truthop() inside fold_const.c

This code fragment shows where 'integer_zerop() fails because while
const_binop() returned a ZERO value, it set the OVERFLOW flag causing
the predicate to reject it....

      if (! integer_zerop (const_binop (BIT_AND_EXPR, l_const,
                                        fold (build1 (BIT_NOT_EXPR,
                                                      lntype, ll_mask)),
                                        0)))
        {
          warning ("comparison is always %d", wanted_code == NE_EXPR);

I haven't looked inside the 4.1 sources to establish where the problem is
now...


-- 

apl at alum dot mit dot edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
      Known to fail|3.4.3 3.3.3                 |3.4.3 3.3.3 4.0.2 4.1.0
      Known to work|4.1.0 4.0.0 3.2.3           |
         Resolution|FIXED                       |


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

[Bug c++/26729] bogus 'comparison is always 0' message

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |minor
            Summary|[3.3/3.4 Regression] bogus  |bogus 'comparison is always
                   |'comparison is always 0'    |0' message
                   |message                     |
   Target Milestone|4.0.0                       |---


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

[Bug c++/26729] bogus 'comparison is always 0' message

[apl at alum dot mit dot edu]

------- Comment #7 from apl at alum dot mit dot edu  2006-03-28 18:40 -------
It's not minor, it causes incorrect code to be generated because it folds the
expression to zero!


-- 

apl at alum dot mit dot edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|minor                       |normal


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

[Bug c++/26729] bogus 'comparison is always 0' message

[falk at debian dot org]

------- Comment #8 from falk at debian dot org  2006-03-28 20:58 -------
Huh? The code does

  ((UInt16(word) & 0x3700) == (UInt16(0x3000) & UInt16(word & 0x8800))) ==
UInt16(0x8000);

which is of course always 0, the left part of the comparison is a comparison,
which can be only 0 or 1, and the right part is 0x8000. So never equal.


-- 

falk at debian dot org changed:

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


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

[Bug c++/26729] bogus 'comparison is always 0' message

[apl at alum dot mit dot edu]

------- Comment #9 from apl at alum dot mit dot edu  2006-03-28 21:26 -------
Created an attachment (id=11145)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11145&action=view)
simplified test case


-- 

apl at alum dot mit dot edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #11135|0                           |1
        is obsolete|                            |


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

[Bug c++/26729] bogus 'comparison is always 0' message

[apl at alum dot mit dot edu]

------- Comment #10 from apl at alum dot mit dot edu  2006-03-28 21:28 -------
No, you misread the parentheses.  I've removed all the EXCESS ONES, leaving


  answer = (UInt16(word & 0x3700) == UInt16(0x3000))
              & (UInt16(word & 0x8800) == UInt16(0x8000));

Showing that we're testing disjoint bits within word , e.g.

               word & 0x3700 == 0x3000
         and   word & 0x8800 == 0x8000

which is NOT always zero....

I've added a simplified test case that still shows the problem and contains a
near minimal number of parentheses....


-- 

apl at alum dot mit dot edu changed:

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


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

[Bug middle-end/26729] [4.0,4.1 regression] bad bitops folding

[falk at debian dot org]

------- Comment #11 from falk at debian dot org  2006-03-28 21:59 -------
Ah. I can reproduce it now. Here is a C test case:

void abort(void);

__attribute__((noinline))
int f (unsigned short word) {  
  return (word & 0x1) && (((unsigned short) (word & 0x8000)) == 0x8000);
}

int main(void) {
  if (!f(0x8001))
    abort();
  return 0;
}


-- 

falk at debian dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
          Component|c++                         |middle-end
     Ever Confirmed|0                           |1
           Keywords|diagnostic                  |wrong-code
      Known to fail|3.4.3 3.3.3 4.0.2 4.1.0     |3.3.6 3.4.3 4.0.2 4.1.0
                   |                            |4.2.0
      Known to work|                            |2.95.4
            Summary|bogus 'comparison is always |[4.0,4.1 regression] bad
                   |0' message                  |bitops folding


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

[Bug middle-end/26729] [4.0/4.1/4.2 regression] bad bitops folding

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.0,4.1 regression] bad    |[4.0/4.1/4.2 regression] bad
                   |bitops folding              |bitops folding
   Target Milestone|---                         |4.1.1


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

[Bug middle-end/26729] [4.0/4.1/4.2 regression] bad bitops folding

[steven at gcc dot gnu dot org]

------- Comment #12 from steven at gcc dot gnu dot org  2006-04-12 21:28 -------
fold_truthop is called with this input:

Breakpoint 11, fold_truthop (code=TRUTH_ANDIF_EXPR, truth_type=0x2aaaaadff4d0,
    lhs=0x2aaaaadf64b0, rhs=0x2aaaaadf6690) at fold-const.c:4820
4820      if (TREE_SIDE_EFFECTS (lhs) || TREE_SIDE_EFFECTS (rhs))
(gdb) p debug_generic_expr(lhs)
(intD.0) wordD.1878 & 1
$50 = void
(gdb) p debug_generic_expr(rhs)
((intD.0) wordD.1878 & 000008000) == 32768
$51 = void
(gdb) 

And it folds this input to 0, which is wrong.


-- 


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

[Bug middle-end/26729] [4.0/4.1/4.2 regression] bad bitops folding

[pinskia at gcc dot gnu dot org]

------- Comment #13 from pinskia at gcc dot gnu dot org  2006-04-13 00:54 -------
It has to be the:

  /* See if the comparisons can be merged.  Then get all the parameters for
     each side.  */


which gets it wrong for some reason.


-- 


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

[Bug middle-end/26729] [4.0/4.1/4.2 regression] bad bitops folding

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1


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

[Bug middle-end/26729] [4.0/4.1/4.2 regression] bad bitops folding

[jakub at gcc dot gnu dot org]

------- Comment #14 from jakub at gcc dot gnu dot org  2006-04-19 13:45 -------
It is the TREE_OVERFLOW set on 0x8000.
That seems to be created by convert_to_integer.
type in that case is unsigned short and expr is (intD.0) xD.1878 & 32768.
As the expr was using signed type, convert_to_integer decides to use
short int as typex:
                      typex = lang_hooks.types.signed_type (typex);
                    return convert (type,
                                    fold_build2 (ex_form, typex,
                                                 convert (typex, arg0),
                                                 convert (typex, arg1)));
but convert (<short int>, <int 32768>) creates <short int overflow -32768>
and since that point forward we carry the overflow bit.
I'd say convert_to_integer should be more careful here, if it sees convert on
one or both of the args created overflow bit, it should either bail out or
use unsigned type instead.


-- 


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

[Bug middle-end/26729] [4.0/4.1/4.2 regression] bad bitops folding

[falk at debian dot org]

------- Comment #15 from falk at debian dot org  2006-04-19 14:20 -------
Roger's patch
http://gcc.gnu.org/ml/gcc/2006-04/msg00008.html
fixes this. I don't know about the status of this patch, though.


-- 


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

[Bug middle-end/26729] [4.0/4.1 regression] bad bitops folding

[rguenth at gcc dot gnu dot org]

------- Comment #16 from rguenth at gcc dot gnu dot org  2006-04-27 11:21 -------
This is fixed on the mainline.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|3.3.6 3.4.3 4.0.2 4.1.0     |3.3.6 3.4.3 4.0.2 4.1.0
                   |4.2.0                       |
      Known to work|2.95.4                      |2.95.4 4.2.0
            Summary|[4.0/4.1/4.2 regression] bad|[4.0/4.1 regression] bad
                   |bitops folding              |bitops folding


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

[Bug middle-end/26729] [4.0/4.1 regression] bad bitops folding

[sayle at gcc dot gnu dot org]

------- Comment #17 from sayle at gcc dot gnu dot org  2006-05-14 04:19 -------
Subject: Bug 26729

Author: sayle
Date: Sun May 14 04:19:32 2006
New Revision: 113755

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113755
Log:

        PR middle-end/26729
        * fold-const.c (fold_truthop): Check integer_nonzerop instead of
        !integer_zerop to avoid problems with TREE_OVERFLOW.

        * gcc.dg/pr26729-1.c: New test case.


Added:
    branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr26729-1.c
Modified:
    branches/gcc-4_1-branch/gcc/ChangeLog
    branches/gcc-4_1-branch/gcc/fold-const.c
    branches/gcc-4_1-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/26729] [4.0 regression] bad bitops folding

[steven at gcc dot gnu dot org]

-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |sayle at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
      Known to fail|3.3.6 3.4.3 4.0.2 4.1.0     |3.3.6 3.4.3 4.0.2
      Known to work|2.95.4 4.2.0                |2.95.4 4.2.0 4.1.0
            Summary|[4.0/4.1 regression] bad    |[4.0 regression] bad bitops
                   |bitops folding              |folding


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

[Bug middle-end/26729] [4.0 regression] bad bitops folding

[apl at alum dot mit dot edu]

------- Comment #18 from apl at alum dot mit dot edu  2006-05-14 14:40 -------
I don't understand why this was changed by sayle to "known to work" on 4.1.0,
when at least ONE of the test cases (b.cxx) demonstrates the failure on 4.1.0

(for some reason bugzilla won't let me commit the above comment unless I
reassign the bug to the person it's already assigned to.


-- 


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

[Bug middle-end/26729] [4.0 regression] bad bitops folding

[sayle at gcc dot gnu dot org]

------- Comment #19 from sayle at gcc dot gnu dot org  2006-05-14 17:20 -------
Subject: Bug 26729

Author: sayle
Date: Sun May 14 17:20:01 2006
New Revision: 113764

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113764
Log:

        PR middle-end/26729
        * gcc.dg/pr26729-1.c: New test case.


Added:
    trunk/gcc/testsuite/gcc.dg/pr26729-1.c
Modified:
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/26729] [4.0 regression] bad bitops folding

[roger at eyesopen dot com]

------- Comment #20 from roger at eyesopen dot com  2006-05-14 17:39 -------
Hi APL,

Re: comment #18.  It was actually stevenb that changed the "known to work"
line,
and assigned this PR to me, after I'd committed a fix to the gcc-4_1-branch.
See http://gcc.gnu.org/ml/gcc-bugs/2006-05/msg01351.html
Marking 4.1.0 as known to work was a simple mistake/typo, and it should
read that 4.1.0 is known to fail, but 4.1.1 is known to work.  I retested
b.cxx explicitly to confirm that it really is fixed on the release branch.


-- 

roger at eyesopen dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|3.3.6 3.4.3 4.0.2           |3.3.6 3.4.3 4.0.2 4.1.0
      Known to work|2.95.4 4.2.0 4.1.0          |2.95.4 4.2.0 4.1.1


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

[Bug middle-end/26729] [4.0 regression] bad bitops folding

[sayle at gcc dot gnu dot org]

------- Comment #21 from sayle at gcc dot gnu dot org  2006-05-15 16:14 -------
Subject: Bug 26729

Author: sayle
Date: Mon May 15 16:14:46 2006
New Revision: 113795

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113795
Log:

        PR middle-end/26729
        * fold-const.c (fold_truthop): Check integer_nonzerop instead of
        !integer_zerop to avoid problems with TREE_OVERFLOW.

        * gcc.dg/pr26729-1.c: New test case.


Added:
    branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/pr26729-1.c
Modified:
    branches/gcc-4_0-branch/gcc/ChangeLog
    branches/gcc-4_0-branch/gcc/fold-const.c
    branches/gcc-4_0-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/26729] [4.0 regression] bad bitops folding

[roger at eyesopen dot com]

------- Comment #22 from roger at eyesopen dot com  2006-05-15 17:41 -------
This should now be fixed on all open branches.


-- 

roger at eyesopen dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|4.1.1                       |4.0.4


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