[Bug c/94631] New: Wrong codegen for arithmetic on bitfields

[Bug c/94631] New: Wrong codegen for arithmetic on bitfields

[bugdal at aerifal dot cx]

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

            Bug ID: 94631
           Summary: Wrong codegen for arithmetic on bitfields
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bugdal at aerifal dot cx
  Target Milestone: ---

Test case:

struct foo {
        unsigned long long low:12, hi:52;
};
unsigned long long bar(struct foo *p)
{
        return p->hi*4096;
}

Should generate only a mask off of the low bits, but gcc generates code to mask
off the low 12 bits and the high 12 bits (reducing the result to 52 bits).
Presumably GCC is interpreting the expression p->hi as having a phantom type
that's only 52 bits wide, rather than having type unsigned long long.

clang/LLVM compiles it correctly.

I don't believe there's any language in the standard supporting what GCC is
doing here.

[Bug c/94631] Wrong codegen for arithmetic on bitfields

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>I don't believe there's any language in the standard supporting what GCC is doing here.

Wrong, see C DR 120 where it talks about this specific thing.


See https://gcc.gnu.org/legacy-ml/gcc/2017-10/msg00192.html for on why GCC is
correct (and even why LLVM is correct too).

Even GCC's C++ front-end is differs from GCC's C front-end here too.

[Bug c/94631] Wrong codegen for arithmetic on bitfields

[bugdal at aerifal dot cx]

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

--- Comment #2 from Rich Felker <bugdal at aerifal dot cx> ---
So basically the outcome of DR120 was allowing the GCC behavior? It still seems
like a bad thing, not required, and likely to produce exploitable bugs (due to
truncation of arithmetic) as well as very poor-performance code (due to
constant masking).

[Bug c/94631] Wrong codegen for arithmetic on bitfields

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Rich Felker from comment #2)
> So basically the outcome of DR120 was allowing the GCC behavior? It still
> seems like a bad thing, not required, and likely to produce exploitable bugs
> (due to truncation of arithmetic) as well as very poor-performance code (due
> to constant masking).

Note this only matters when the size of the bit-field is less than the size of
int.

[Bug c/94631] Wrong codegen for arithmetic on bitfields

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Rich Felker from comment #2)
> > So basically the outcome of DR120 was allowing the GCC behavior? It still
> > seems like a bad thing, not required, and likely to produce exploitable bugs
> > (due to truncation of arithmetic) as well as very poor-performance code (due
> > to constant masking).
> 
> Note this only matters when the size of the bit-field is less than the size
> of int.

bigger than the size of int (due to default integer promotions still applying).

[Bug c/94631] Wrong codegen for arithmetic on bitfields

[bugdal at aerifal dot cx]

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

--- Comment #5 from Rich Felker <bugdal at aerifal dot cx> ---
No, GCC's treatment also seems to mess up bitfields smaller than int and fully
governed by the standard (no implementation-defined use of non-int types):

struct foo {
    unsigned x:31;
};

struct foo bar = {0};

bar.x-1 should yield UINT_MAX but yields -1 (same representation but different
type) because it behaves as a promotion from a phantom type unsigned:31 to int
rather than as having type unsigned to begin with.

This can of course be observed by comparing it against 0. It's subtle and
dangerous because it may also trigger optimization around UB of signed overflow
when the correct behavior would be well-defined modular arithmetic.

[Bug c/94631] Wrong codegen for arithmetic on bitfields

[joseph at codesourcery dot com]

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

--- Comment #6 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Fri, 17 Apr 2020, bugdal at aerifal dot cx wrote:

> No, GCC's treatment also seems to mess up bitfields smaller than int and fully
> governed by the standard (no implementation-defined use of non-int types):

"unsigned int" bit-fields narrower than int are *required* by the 
standard, for both C and C++, to be promoted to int by the integer 
promotions.

[Bug c/94631] Wrong codegen for arithmetic on bitfields

[bugdal at aerifal dot cx]

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

--- Comment #7 from Rich Felker <bugdal at aerifal dot cx> ---
Can you provide a citation for that?

[Bug c/94631] Wrong codegen for arithmetic on bitfields

[bugdal at aerifal dot cx]

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

--- Comment #8 from Rich Felker <bugdal at aerifal dot cx> ---
OK, I think it's in 6.3.1.1 Boolean, characters, and integers, ¶2, but somewhat
poorly worded:

"The following may be used in an expression wherever an int or unsigned int may
be used: 

- An object or expression with an integer type (other than int or unsigned int)
whose integer conversion rank is less than or equal to the rank of int and
unsigned int.
- A bit-field of type _Bool, int, signed int, or unsigned int.

If an int can represent all values of the original type (as restricted by the
width, for a bit-field), the value is converted to an int; otherwise, it is
converted to an unsigned int. These are called the integer promotions."

The first sentence with second bullet point suggests it should behave as
unsigned int, but the "as restricted by the width, for a bit-field" in the
paragraph after after the bulleted list seems to confirm your interpretation.

[Bug c/94631] Wrong codegen for arithmetic on bitfields

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl.tools at gmail dot com

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 107403 has been marked as a duplicate of this bug. ***