[Bug target/107846] New: error: result of '8000 << 8' requires 22 bits to represent, but 'short int' only has 16 bits

[Bug target/107846] New: error: result of '8000 << 8' requires 22 bits to represent, but 'short int' only has 16 bits

[james.hilliard1 at gmail dot com]

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

            Bug ID: 107846
           Summary: error: result of '8000 << 8' requires 22 bits to
                    represent, but 'short int' only has 16 bits
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: james.hilliard1 at gmail dot com
  Target Milestone: ---

I'm seeing this error which does not occur in llvm for a bpf
test(test_tc_tunnel.c) in bpf-next, I'm not sure if this is an upstream bug in
the test itself or a bug in gcc:

In function '__encap_ipv4':
cc1: error: result of '8000 << 8' requires 22 bits to represent, but 'short
int' only has 16 bits [-Werror=shift-overflow=]
cc1: error: result of '20000 << 8' requires 24 bits to represent, but 'short
int' only has 16 bits [-Werror=shift-overflow=]
progs/test_tc_tunnel.c:228:31: warning: taking address of packed member of
'struct v4hdr' may result in an unaligned pointer value
[-Waddress-of-packed-member]
  228 |         set_ipv4_csum((void *)&h_outer.ip);
      |                               ^~~~~~~~~~~
In function '__encap_ipv6':
cc1: error: result of '8000 << 8' requires 22 bits to represent, but 'short
int' only has 16 bits [-Werror=shift-overflow=]
cc1: error: result of '20000 << 8' requires 24 bits to represent, but 'short
int' only has 16 bits [-Werror=shift-overflow=]

[Bug target/107846] error: result of '8000 << 8' requires 22 bits to represent, but 'short int' only has 16 bits

[david.faust at oracle dot com]

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

--- Comment #1 from David Faust <david.faust at oracle dot com> ---
I think this is a bug in the test itself (or with these macros from libbpf).

libbpf/src/bpf_endian.h
#define ___bpf_mvb(x, b, n, m) ((__u##b)(x) << (b-(n+1)*8) >> (b-8) << (m*8))

#define ___bpf_swab16(x) ((__u16)(                      \
                          ___bpf_mvb(x, 16, 0, 1) |     \
                          ___bpf_mvb(x, 16, 1, 0)))

# define __bpf_constant_htons(x)        ___bpf_swab16(x)

In tools/testing/selftests/bpf/progs/test_tc_tunnel.c:

static const int cfg_port = 8000;
static const int cfg_udp_src = 20000;
...

then at e.g. line 276

        if (tcph.dest != __bpf_constant_htons(cfg_port))
                return TC_ACT_OK;

Expanding this __bpf_constant_htons macro:

__bpf_constant_htons (cfg_port)
__bpf_constant_htons (8000)
((__u16)(8000) << (16-(0+1)*8) >> (16-8) << (1*8)
((__u16)(8000) << (16-(1)*8) >> (8) << 8)
((__u16)(8000) << (8) >> 8 << 8
((__u16)(8000) << 8)

...which raises the shift-overflow warning.

[Bug target/107846] error: result of '8000 << 8' requires 22 bits to represent, but 'short int' only has 16 bits

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to David Faust from comment #1)
> I think this is a bug in the test itself (or with these macros from libbpf).
No I think there might be a bug in GCC though I have to double check.

cc1: error: result of '8000 << 8' requires 22 bits to represent, but 'short
int' only has 16 bits [-Werror=shift-overflow=]

((__u16)(8000) << 8)

Hmm, we should have prompted that to int and not warned about it ...

[Bug c/107846] [13 Regression] error: result of '8000 << 8' requires 22 bits to represent, but 'short int' only has 16 bits

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic, needs-bisection
   Last reconfirmed|                            |2022-11-23
             Status|UNCONFIRMED                 |NEW
      Known to work|                            |11.1.0, 12.1.0, 12.2.0,
                   |                            |9.1.0
          Component|target                      |c
   Target Milestone|---                         |13.0
     Ever confirmed|0                           |1
            Summary|error: result of '8000 <<   |[13 Regression] error:
                   |8' requires 22 bits to      |result of '8000 << 8'
                   |represent, but 'short int'  |requires 22 bits to
                   |only has 16 bits            |represent, but 'short int'
                   |                            |only has 16 bits
             Target|bpf                         |

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Short testcase:

typedef unsigned short __u16;

#define ___bpf_mvb(x, b, n, m) ((__u##b)(x) << (b-(n+1)*8) >> (b-8) << (m*8))

#define ___bpf_swab16(x) ((__u16)(                      \
                          ___bpf_mvb(x, 16, 0, 1) |     \
                          ___bpf_mvb(x, 16, 1, 0)))

# define __bpf_constant_htons(x)        ___bpf_swab16(x)

static const int cfg_port = 8000;


unsigned short f(int t)
{
  if (t != __bpf_constant_htons (cfg_port))
    return 1;
  return 0;
}
--- CUT ---
This is definitely a bug in GCC though there might be a dup.
the line info is also missing ...
Note this only happens at -O1 and also a regression from GCC 12 even.

[Bug c/107846] [13 Regression] error: result of '8000 << 8' requires 22 bits to represent, but 'short int' only has 16 bits

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
#0  warning_at (location=0, opt=765, gmsgid=0x30ecaf8 "result of %qE requires
%u bits to represent, but %qT only has %u bits") at
/home/apinski/src/upstream-gcc-git/gcc/gcc/diagnostic.cc:1845
#1  0x0000000000d3a2e2 in maybe_warn_shift_overflow (loc=0, op0=0x7ffff6e949c0,
op1=0x7ffff6e94960) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/c-family/c-warn.cc:2645
#2  0x0000000000c62e14 in c_fully_fold_internal (expr=0x7ffff6e84cf8,
in_init=false, maybe_const_operands=0x7fffffffce5b,
maybe_const_itself=0x7fffffffce5a, for_int_const=false, lval=false) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/c/c-fold.cc:429
#3  0x0000000000c62358 in c_fully_fold_internal (expr=0x7ffff6e84d20,
in_init=false, maybe_const_operands=0x7fffffffce5b,
maybe_const_itself=0x7fffffffce5a, for_int_const=false, lval=false) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/c/c-fold.cc:354
#4  0x0000000000c63089 in c_fully_fold_internal (expr=0x7ffff6e96420,
in_init=false, maybe_const_operands=0x7fffffffce5b,
maybe_const_itself=0x7fffffffce5a, for_int_const=false, lval=false) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/c/c-fold.cc:473
#5  0x0000000000c614ab in c_fully_fold (expr=0x7ffff6e96420, in_init=false,
maybe_const=0x7fffffffce5b, lval=false) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/c/c-fold.cc:125

[Bug c/107846] [13 Regression] error: result of '8000 << 8' requires 22 bits to represent, but 'short int' only has 16 bits

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |sayle at gcc dot gnu.org
           Keywords|needs-bisection             |

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r13-1100-gacb1e6f43dc2bbedd1248ea61c7ab537a11fe59b
So, either we should limit that new match.pd folding to GIMPLE, or
should take into account such narrowing vs. integral promotion.

[Bug c/107846] [13 Regression] error: result of '8000 << 8' requires 22 bits to represent, but 'short int' only has 16 bits

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 53984
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53984&action=edit
gcc13-pr107846.patch

Untested fix.

[Bug c/107846] [13 Regression] error: result of '8000 << 8' requires 22 bits to represent, but 'short int' only has 16 bits

[james.hilliard1 at gmail dot com]

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

--- Comment #7 from James Hilliard <james.hilliard1 at gmail dot com> ---
(In reply to Jakub Jelinek from comment #6)
> Created attachment 53984 [details]
> gcc13-pr107846.patch
> 
> Untested fix.

This appears to fix error, the warning is still present:
progs/test_tc_tunnel.c: In function '__encap_ipv4':
progs/test_tc_tunnel.c:228:31: warning: taking address of packed member of
'struct v4hdr' may result in an unaligned pointer value
[-Waddress-of-packed-member]
  228 |         set_ipv4_csum((void *)&h_outer.ip);
      |                               ^~~~~~~~~~~

[Bug c/107846] [13 Regression] error: result of '8000 << 8' requires 22 bits to represent, but 'short int' only has 16 bits

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to James Hilliard from comment #7)
> (In reply to Jakub Jelinek from comment #6)
> > Created attachment 53984 [details]
> > gcc13-pr107846.patch
> > 
> > Untested fix.
> 
> This appears to fix error, the warning is still present:
> progs/test_tc_tunnel.c: In function '__encap_ipv4':
> progs/test_tc_tunnel.c:228:31: warning: taking address of packed member of
> 'struct v4hdr' may result in an unaligned pointer value
> [-Waddress-of-packed-member]
>   228 |         set_ipv4_csum((void *)&h_outer.ip);
>       |                               ^~~~~~~~~~~

That is unrelated and why do you think it is wrong?  I don't think that warning
has false positives.

[Bug c/107846] [13 Regression] error: result of '8000 << 8' requires 22 bits to represent, but 'short int' only has 16 bits

[pinskia at gcc dot gnu.org]

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

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to James Hilliard from comment #7)
> This appears to fix error, the warning is still present:
> progs/test_tc_tunnel.c: In function '__encap_ipv4':
> progs/test_tc_tunnel.c:228:31: warning: taking address of packed member of
> 'struct v4hdr' may result in an unaligned pointer value
> [-Waddress-of-packed-member]
>   228 |         set_ipv4_csum((void *)&h_outer.ip);
>       |                               ^~~~~~~~~~~

That warning is correct and is a bug in the test program ...

[Bug c/107846] [13 Regression] error: result of '8000 << 8' requires 22 bits to represent, but 'short int' only has 16 bits

[james.hilliard1 at gmail dot com]

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

--- Comment #10 from James Hilliard <james.hilliard1 at gmail dot com> ---
(In reply to Jakub Jelinek from comment #8)
> (In reply to James Hilliard from comment #7)
> > (In reply to Jakub Jelinek from comment #6)
> > > Created attachment 53984 [details]
> > > gcc13-pr107846.patch
> > > 
> > > Untested fix.
> > 
> > This appears to fix error, the warning is still present:
> > progs/test_tc_tunnel.c: In function '__encap_ipv4':
> > progs/test_tc_tunnel.c:228:31: warning: taking address of packed member of
> > 'struct v4hdr' may result in an unaligned pointer value
> > [-Waddress-of-packed-member]
> >   228 |         set_ipv4_csum((void *)&h_outer.ip);
> >       |                               ^~~~~~~~~~~
> 
> That is unrelated and why do you think it is wrong?  I don't think that
> warning has false positives.

I wasn't entirely sure if it was wrong or not, was just testing the patch.

[Bug c/107846] [13 Regression] error: result of '8000 << 8' requires 22 bits to represent, but 'short int' only has 16 bits

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:db1405ddf566fe6129328229579b3f98a574b34c

commit r13-6474-gdb1405ddf566fe6129328229579b3f98a574b34c
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sat Mar 4 10:14:33 2023 +0100

    c-family: Account for integral promotions of left shifts for
-Wshift-overflow warning [PR107846]

    The r13-1100-gacb1e6f43dc2bbedd124 change added match.pd narrowing
    of left shifts, and while I believe the C++ FE calls the warning on
unfolded
    trees, the C FE folds them and so left shifts where integral promotion
    happened and so were done in int type will be usually narrowed back to
    char/signed char/unsigned char/short/unsigned short left shifts if the
    shift count is constant and fits into the precision of the var being
    shifted.
    One possibility would be to restrict the match.pd optimization to GIMPLE
    only, another don't fold in C FE before this warning (well, we need to
    fold the shift count operand to constant if possible), the following patch
    just takes integral promotion into account in the warning code.

    2023-03-04  Jakub Jelinek  <jakub@redhat.com>

            PR c/107846
            * c-warn.cc: Include langhooks.h.
            (maybe_warn_shift_overflow): Set type0 to what TREE_TYPE (op0)
            promotes to rather than TREE_TYPE (op0) itself, if TREE_TYPE (op0)
            is narrower than type0 and unsigned, use wi::min_precision with
            UNSIGNED and fold_convert op0 to type0 before emitting the warning.

            * gcc.dg/pr107846.c: New test.

[Bug c/107846] [13 Regression] error: result of '8000 << 8' requires 22 bits to represent, but 'short int' only has 16 bits

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.