[Bug c/102291] New: dubious overflow warning

[Bug c/102291] New: dubious overflow warning

[hv at crypt dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102291

            Bug ID: 102291
           Summary: dubious overflow warning
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hv at crypt dot org
  Target Milestone: ---

The following code warns with gcc-11.2.0 (but not with 9.2.1-17ubuntu1~18.04.1)
in testera(), but not in testerb() which differs only by the removal of an
assert. I don't understand this, and cannot see what is overflowing.

This is reduced from a report against the UTF8_ACCUMULATE macro in perl source.
This build of gcc was configured as follows (including the error in prefix):
  ../gcc/configure --prefix=/opt/gcc-12 --disable-gcov --disable-multilib
--enable-languages=c --disable-nls --disable-decimal-float


% uname -a
Linux zen2 5.4.0-73-generic #82~18.04.1-Ubuntu SMP Fri Apr 16 15:10:02 UTC 2021
x86_64 x86_64 x86_64 GNU/Linux

% gcc --version | head -1
gcc (GCC) 11.2.0

% cat test.c
/* #include <assert.h> */
extern void __assert_fail (const char *__assertion, const char *__file,
      unsigned int __line, const char *__function)
    __attribute__ ((__nothrow__ , __leaf__))
            __attribute__ ((__noreturn__));
#define assert(expr)                          \
  ((void) sizeof ((expr) ? 1 : 0), __extension__ ({         \
      if (expr)                             \
        ; /* empty */                           \
      else                              \
        __assert_fail (#expr, __FILE__, __LINE__, __ASSERT_FUNCTION);   \
    }))
#define __ASSERT_FUNCTION    __extension__ __PRETTY_FUNCTION__
/* end assert.h */

typedef unsigned long ulong;
typedef unsigned char uchar;

#define FIT8(c) assert(((sizeof(c) == 1) || (((ulong) (c)) >> 8) == 0))
#define BE8a(c) (FIT8(c), ((uchar) (c)))
#define BE8b(c) (         ((uchar) (c)))
#define NUM(c) ((c) | 0)

#define TESTER(old, new) ((((ulong)(old)) << 6) | (((uchar) NUM(new)) & 0x3f))

ulong testera(ulong ul) {
    return TESTER(ul, BE8a(0x80));
}

ulong testerb(ulong ul) {
    return TESTER(ul, BE8b(0x80));
}

% gcc -c test.c 
test.c: In function 'testera':
test.c:24:49: warning: overflow in conversion from 'int' to 'long unsigned int'
changes value from '((((void)4, (({...}))), 128)) & 63' to '0' [-Woverflow]
   24 | #define TESTERa(old, new) ((((ulong)(old)) << 6) | (((uchar) NUM(new))
& 0x3f))
      |                                                  ^
test.c:27:12: note: in expansion of macro 'TESTERa'
   27 |     return TESTERa(ul, BE8a(0x80));
      |            ^~~~~~~
%

[Bug c/102291] [9/10/11/12 Regression] wrong overflow warning for compound expression conversion and bit_and expressions

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102291

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|dubious overflow warning    |[9/10/11/12 Regression]
                   |                            |wrong overflow warning for
                   |                            |compound expression
                   |                            |conversion and bit_and
                   |                            |expressions
      Known to work|9.4.0                       |4.1.2
      Known to fail|                            |4.4.7
   Target Milestone|---                         |9.5

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I don't think this really a regression from GCC 9 but rather a regression from
a long time ago.
Take:
typedef unsigned long ulong;
typedef unsigned char uchar;


ulong testera(ulong ul) {
    return ((((uchar) (((void)0, ((uchar) (0x80)))|0)) & 0x3f));
}
----- CUT ----
This is slightly different from your teststcase but it warns all the way back
until sometime before 4.4.0 (I only can test 4.1.2).

[Bug c/102291] [9/10/11/12 Regression] wrong overflow warning for compound expression conversion and bit_and expressions

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102291

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2021-09-11
             Status|UNCONFIRMED                 |NEW

[Bug c/102291] [9/10/11/12 Regression] wrong overflow warning for compound expression conversion and bit_and expressions

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102291

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=32643

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Related to PR 32643.

[Bug c/102291] [9/10/11/12 Regression] wrong overflow warning for compound expression conversion and bit_and expressions

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102291

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The #c0 testcase regressed with my
r10-7344-gca6c722561ce9b9dc7b59cfd9d29c9b466732721

[Bug c/102291] [9/10/11/12 Regression] wrong overflow warning for compound expression conversion and bit_and expressions

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102291

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org,
                   |                            |jsm28 at gcc dot gnu.org,
                   |                            |mpolacek at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I'm afraid I'm getting lost in what convert does though with the TREE_OVERFLOW
flag.
In the testcase, we have a cast of BIT_IOR_EXPR with (whatever, 0x80) and 0 int
arguments to unsigned char.
do_narrow is called and does:
      /* Don't do unsigned arithmetic where signed was wanted,
         or vice versa.
         Exception: if both of the original operands were
         unsigned then we can safely do the work as unsigned.
         Exception: shift operations take their type solely
         from the first argument.
         Exception: the LSHIFT_EXPR case above requires that
         we perform this operation unsigned lest we produce
         signed-overflow undefinedness.
         And we may need to do it as unsigned
         if we truncate to the original size.  */
and as BIT_IOR_EXPR isn't listed, type == typex is unsigned and TREE_TYPE
(arg0) and TREE_TYPE (arg1) are signed goes the:
          if (TYPE_UNSIGNED (typex))
            typex = signed_type_for (typex);
way.  Those conversions create TYPE_OVERFLOW constant, even when there was
nothing wrong in the source and because of the COMPOUND_EXPRs in there we don't
manage to optimize those TYPE_OVERFLOW constants away and warn on it.

For BIT_AND_EXPR/BIT_IOR_EXPR/BIT_XOR_EXPR, I must say I miss the reason why
it would be ever a good idea to use typex = signed_type_for (typex), when we
want unsigned result, just converting to that right away doesn't have any
downsides I can come up with.
But I wonder even about the other operations, do we really want to introduce
TYPE_OVERFLOWs in such cases where the operations are originally on wider
signed operands and are cast to some narrower unsigned type?

[Bug c/102291] [9/10/11/12 Regression] wrong overflow warning for compound expression conversion and bit_and expressions

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102291

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I have tried:
--- gcc/convert.c.jj    2021-01-04 10:25:38.977232194 +0100
+++ gcc/convert.c       2021-12-06 16:28:51.279775640 +0100
@@ -398,6 +398,9 @@ do_narrow (location_t loc,
         Exception: the LSHIFT_EXPR case above requires that
         we perform this operation unsigned lest we produce
         signed-overflow undefinedness.
+        Exception: for BIT_*_EXPR if type is unsigned, just
+        convert operands to that unsigned type, there is no
+        point converting to a singled type instead.
         And we may need to do it as unsigned
         if we truncate to the original size.  */
       if (TYPE_UNSIGNED (TREE_TYPE (expr))
@@ -424,7 +427,11 @@ do_narrow (location_t loc,
                      > outprec))
              && (ex_form == PLUS_EXPR
                  || ex_form == MINUS_EXPR
-                 || ex_form == MULT_EXPR)))
+                 || ex_form == MULT_EXPR))
+          || ((ex_form == BIT_AND_EXPR
+               || ex_form == BIT_IOR_EXPR
+               || ex_form == BIT_XOR_EXPR)
+              && TYPE_UNSIGNED (typex)))
        {
          if (!TYPE_UNSIGNED (typex))
            typex = unsigned_type_for (typex);
--- gcc/testsuite/gcc.dg/pr102291.c.jj  2021-12-06 16:35:36.600984273 +0100
+++ gcc/testsuite/gcc.dg/pr102291.c     2021-12-06 16:35:25.531143307 +0100
@@ -0,0 +1,33 @@
+/* PR c/102291 */
+/* { dg-do compile } */
+
+extern void __assert_fail (const char *, const char *,
+                          unsigned int, const char *)
+  __attribute__ ((__nothrow__ , __leaf__, __noreturn__));
+#define assert(expr)                                   \
+  ((void) sizeof ((expr) ? 1 : 0), __extension__ ({    \
+    if (expr)                                          \
+      ; /* empty */                                    \
+    else                                               \
+      __assert_fail (#expr, __FILE__, __LINE__,                \
+                    __ASSERT_FUNCTION);                \
+    }))
+#define __ASSERT_FUNCTION __extension__ __PRETTY_FUNCTION__
+
+#define A(c) assert (sizeof (c) == 1 || (((unsigned long) (c)) >> 8) == 0)
+#define B(c) (A (c), ((unsigned char) (c)))
+#define C(c) (((unsigned char) (c)))
+#define D(c) ((c) | 0)
+#define E(old, new) ((((unsigned long) (old)) << 6) | (((unsigned char) D
(new)) & 0x3f))
+
+unsigned long
+foo (unsigned long x)
+{
+  return E (x, B (0x80));
+}
+
+unsigned long
+bar (unsigned long x)
+{
+  return E (x, C (0x80));
+}
but it regressed:
FAIL: gcc.dg/overflow-warn-5.c  (test for warnings, line 6)
FAIL: gcc.dg/tree-ssa/pr94882-3.c scan-tree-dump-times optimized "_[0-9] \\^
_[0-9]" 4
FAIL: gcc.dg/tree-ssa/pr94882-3.c scan-tree-dump-times optimized "~_[0-9]+" 8
FAIL: gcc.dg/vect/vect-over-widen-3-big-array.c scan-tree-dump vect
"vect_recog_over_widening_pattern: detected:[^\\n]* << 3"
FAIL: gcc.dg/vect/vect-over-widen-3-big-array.c scan-tree-dump vect
"vect_recog_over_widening_pattern: detected:[^\\n]* << 9"
FAIL: gcc.dg/vect/vect-over-widen-3.c scan-tree-dump vect
"vect_recog_over_widening_pattern: detected:[^\\n]* << 3"
FAIL: gcc.dg/vect/vect-over-widen-3.c scan-tree-dump vect
"vect_recog_over_widening_pattern: detected:[^\\n]* << 9"
FAIL: gcc.dg/vect/vect-over-widen-1-big-array.c scan-tree-dump vect
"vect_recog_over_widening_pattern: detected:[^\\n]* << 3"
FAIL: gcc.dg/vect/vect-over-widen-1-big-array.c scan-tree-dump vect
"vect_recog_over_widening_pattern: detected:[^\\n]* << 8"
FAIL: gcc.dg/vect/vect-over-widen-4-big-array.c scan-tree-dump vect
"vect_recog_over_widening_pattern: detected:[^\\n]* << 3"
FAIL: gcc.dg/vect/vect-over-widen-4-big-array.c scan-tree-dump vect
"vect_recog_over_widening_pattern: detected:[^\\n]* << 8"
FAIL: gcc.dg/vect/vect-over-widen-1.c scan-tree-dump vect
"vect_recog_over_widening_pattern: detected:[^\\n]* << 3"
FAIL: gcc.dg/vect/vect-over-widen-1.c scan-tree-dump vect
"vect_recog_over_widening_pattern: detected:[^\\n]* << 8"
FAIL: gcc.dg/vect/vect-over-widen-4.c scan-tree-dump vect
"vect_recog_over_widening_pattern: detected:[^\\n]* << 3"
FAIL: gcc.dg/vect/vect-over-widen-4.c scan-tree-dump vect
"vect_recog_over_widening_pattern: detected:[^\\n]* << 8"
FAIL: gcc.dg/vect/vect-over-widen-1-big-array.c -flto -ffat-lto-objects 
scan-tree-dump vect "vect_recog_over_widening_pattern: detected:[^\\n]* << 3"
FAIL: gcc.dg/vect/vect-over-widen-1-big-array.c -flto -ffat-lto-objects 
scan-tree-dump vect "vect_recog_over_widening_pattern: detected:[^\\n]* << 8"
FAIL: gcc.dg/vect/vect-over-widen-4-big-array.c -flto -ffat-lto-objects 
scan-tree-dump vect "vect_recog_over_widening_pattern: detected:[^\\n]* << 3"
FAIL: gcc.dg/vect/vect-over-widen-4-big-array.c -flto -ffat-lto-objects 
scan-tree-dump vect "vect_recog_over_widening_pattern: detected:[^\\n]* << 8"
FAIL: gcc.dg/vect/vect-over-widen-1.c -flto -ffat-lto-objects  scan-tree-dump
vect "vect_recog_over_widening_pattern: detected:[^\\n]* << 3"
FAIL: gcc.dg/vect/vect-over-widen-1.c -flto -ffat-lto-objects  scan-tree-dump
vect "vect_recog_over_widening_pattern: detected:[^\\n]* << 8"
FAIL: gcc.dg/vect/vect-over-widen-4.c -flto -ffat-lto-objects  scan-tree-dump
vect "vect_recog_over_widening_pattern: detected:[^\\n]* << 3"
FAIL: gcc.dg/vect/vect-over-widen-4.c -flto -ffat-lto-objects  scan-tree-dump
vect "vect_recog_over_widening_pattern: detected:[^\\n]* << 8"
FAIL: gcc.dg/vect/vect-over-widen-3-big-array.c -flto -ffat-lto-objects 
scan-tree-dump vect "vect_recog_over_widening_pattern: detected:[^\\n]* << 3"
FAIL: gcc.dg/vect/vect-over-widen-3-big-array.c -flto -ffat-lto-objects 
scan-tree-dump vect "vect_recog_over_widening_pattern: detected:[^\\n]* << 9"
FAIL: gcc.dg/vect/vect-over-widen-3.c -flto -ffat-lto-objects  scan-tree-dump
vect "vect_recog_over_widening_pattern: detected:[^\\n]* << 3"
FAIL: gcc.dg/vect/vect-over-widen-3.c -flto -ffat-lto-objects  scan-tree-dump
vect "vect_recog_over_widening_pattern: detected:[^\\n]* << 9"
The overflow-warn-5.c case is just weird, there is no overflow, the function
does return p & 512; where p and return type are unsigned char,
just briefly looked at vect-over-widen-1.c and we vectorize one loop before and
after, just the detected cases are different.

[Bug c/102291] [9/10/11/12 Regression] wrong overflow warning for compound expression conversion and bit_and expressions

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102291

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The #c1 testcase also started to warn with r10-7344.

[Bug c/102291] [9/10/11/12 Regression] wrong overflow warning for compound expression conversion and bit_and expressions

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102291

--- Comment #7 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
I don't think TREE_OVERFLOW should be introduced in folding expressions 
that didn't have undefined behavior in the original source code.

[Bug c/102291] [9/10/11/12 Regression] wrong overflow warning for compound expression conversion and bit_and expressions

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102291

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

[Bug c/102291] [10/11/12/13 Regression] wrong overflow warning for compound expression conversion and bit_and expressions

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102291

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.5                         |10.4

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9 branch is being closed

[Bug c/102291] [10/11/12/13 Regression] wrong overflow warning for compound expression conversion and bit_and expressions

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102291

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.4                        |10.5

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.

[Bug c/102291] [11/12/13/14 Regression] wrong overflow warning for compound expression conversion and bit_and expressions

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102291

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.5                        |11.5

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10 branch is being closed.