[Bug analyzer/99212] New: [11 Regression] gcc.dg/analyzer/data-model-1.c line 971

[Bug analyzer/99212] New: [11 Regression] gcc.dg/analyzer/data-model-1.c line 971

[hp at gcc dot gnu.org]

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

            Bug ID: 99212
           Summary: [11 Regression] gcc.dg/analyzer/data-model-1.c line
                    971
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: analyzer
          Assignee: dmalcolm at gcc dot gnu.org
          Reporter: hp at gcc dot gnu.org
                CC: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

For cris-elf, this test has failed as follows, since some change in the range
cd0233527af1..0dc80505562c (usual suspects are several gcc/analyzer changes):

Running /x/gcc/gcc/testsuite/gcc.dg/analyzer/analyzer.exp ...
XPASS: gcc.dg/analyzer/data-model-1.c desired (test for warnings, line 971)
FAIL: gcc.dg/analyzer/data-model-1.c status quo (test for warnings, line 971)

similarly for pru-unknown-elf:
https://gcc.gnu.org/pipermail/gcc-testresults/2021-February/652712.html
and m68k-unknown-linux-gnu:
https://gcc.gnu.org/pipermail/gcc-testresults/2021-February/652763.html

These targets have a couple of structure layout characteristics in common.

[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.0

[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson <hp at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-02-23
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #1 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
Current observation: 198c56052ea8 / r11-7337

[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Failing test is in test_45 at:
  __analyzer_eval (bits.b0 == 1); /* { dg-warning "TRUE" "desired" { xfail
*-*-* } } */
  /* { dg-warning "UNKNOWN" "status quo" { target *-*-* } .-1 } */


x86_64-pc-linux-gnu has:
  bits.b0 = 1;
  _1 = BIT_FIELD_REF <bits, 8, 0>;
  _2 = _1 & 1;
  _3 = _2 != 0;
  _4 = (int) _3;
  __analyzer_eval (_4);
  bits.b0 = 1;
  _1 = BIT_FIELD_REF <bits, 8, 0>;
  _2 = _1 & 1;
  _3 = _2 != 0;
  _4 = (int) _3;
  __analyzer_eval (_4);

whereas cris-axis-elf has:
  bits.b0 = 1;
  _1 = VIEW_CONVERT_EXPR<unsigned char>(bits);
  _2 = _1 & 1;
  _3 = _2 != 0;
  _4 = (int) _3;
  __analyzer_eval (_4);
  bits.b456 = 5;
  _5 = VIEW_CONVERT_EXPR<unsigned char>(bits);
  _6 = _5 & 112;
  _7 = _6 == 80;
  _8 = (int) _7;
  __analyzer_eval (_8);

BIT_FIELD_REF doesn't work (hence the "UNKNOWN" in the expected output),
whereas the first VIEW_CONVERT_EXPR does work, unexpectedly emitting "TRUE",
hence the XPASS (and the FAIL on the "UNKNOWN" directive, which is there to
swallow the "UNKNOWN" output)

[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
(In reply to David Malcolm from comment #2)
> x86_64-pc-linux-gnu has:

I messed up the copy and paste here; the x86_64 gimple actually reads:

  bits.b0 = 1;
  _1 = BIT_FIELD_REF <bits, 8, 0>;
  _2 = _1 & 1;
  _3 = _2 != 0;
  _4 = (int) _3;
  __analyzer_eval (_4);
  bits.b456 = 5;
  _5 = BIT_FIELD_REF <bits, 8, 0>;
  _6 = _5 & 112;
  _7 = _6 == 80;
  _8 = (int) _7;
  __analyzer_eval (_8);

[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
I guess cris-elf simply has different type sizes / bitfield layout here.  The
dumps hint at sizeof (ubits) == 1 for cris.  So you should eventually get
the same on x86_64 when you use unsigned char : ...; bitfields in ubits.

[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Possibly a dumb question, but how am I meant to get at the size in bits of a
bitfield?  TYPE_SIZE appears to be expressed in bytes, rather than bits (or
maybe I messed up when debugging?)

On a 1-bit unsigned bitfield I'm seeing:

(gdb) call debug_tree(m_type)
 <integer_type 0x7fffea7a83f0 sizes-gimplified public unsigned QI
    size <integer_cst 0x7fffea644dc8 type <integer_type 0x7fffea65d0a8
bitsizetype> constant 8>
    unit-size <integer_cst 0x7fffea644de0 type <integer_type 0x7fffea65d000
sizetype> constant 1>
    align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea7a83f0 precision:1 min <integer_cst 0x7fffea78a1c8 0> max <integer_cst
0x7fffea78a1e0 1>>

On a 3-bit unsigned bitfield I'm seeing:
(gdb) call debug_tree(m_type)
 <integer_type 0x7fffea7a8498 sizes-gimplified public unsigned QI
    size <integer_cst 0x7fffea644dc8 type <integer_type 0x7fffea65d0a8
bitsizetype> constant 8>
    unit-size <integer_cst 0x7fffea644de0 type <integer_type 0x7fffea65d000
sizetype> constant 1>
    align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea7a8498 precision:3 min <integer_cst 0x7fffea78a1f8 0> max <integer_cst
0x7fffea78a210 7>>

so it looks like the "precision" is what I should be using for such types (but
when?)

Is there an equivalent to int_size_in_bytes for bits that I'm missing?  Thanks

[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971

[dmalcolm at gcc dot gnu.org]

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

--- Comment #6 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Answering my own question:
  https://gcc.gnu.org/onlinedocs/gccint/Types.html

INTEGER_TYPE

    Used to represent the various integral types, including char, short, int,
long, and long long. This code is not used for enumeration types, nor for the
bool type. The TYPE_PRECISION is the number of bits used in the representation,
represented as an unsigned int. (Note that in the general case this is not the
same value as TYPE_SIZE; suppose that there were a 24-bit integer type, but
that alignment requirements for the ABI required 32-bit alignment. Then,
TYPE_SIZE would be an INTEGER_CST for 32, while TYPE_PRECISION would be 24.)
The integer type is unsigned if TYPE_UNSIGNED holds; otherwise, it is signed.

[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971

[hp at gcc dot gnu.org]

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

--- Comment #7 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
(In reply to David Malcolm from comment #6)
> Answering my own question:
>   https://gcc.gnu.org/onlinedocs/gccint/Types.html
> [...]

Nothing here for a month+.  Any chance of this getting progress in (say) the
following week?  If not, I'll just do the equivalence of xfailing it.

[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |cris-elf

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
Just to repeat - we have folding that turns BIT_FIELD_REF <bits, 8, 0> into
VIEW_CONVERT_EXPR <type> (bits) if the size of bits is the size of the
extracted
bits which, for cris likely means that sizeof (ubits) is 1.  To quote

struct ubits
{
  unsigned int b0 : 1;
  unsigned int b123 : 3;
  unsigned int b456 : 3;
  unsigned int b7 : 1;
};

to make the IL the same for both targets it might be enough to insert padding:

struct ubits
{
  unsigned int b0 : 1;
  unsigned int b123 : 3;
  unsigned int b456 : 3;
  unsigned int b7 : 1;
  unsigned int pad : 24; // or 8
};

xfail/pass depending on sizeof (int) might be possible but as said it might
be that cris doesn't have sizeof (int) == 1 but instead just lays out
struct ubits in a way to have its size being 1.

[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971

[hp at gcc dot gnu.org]

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

--- Comment #9 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #8)
> xfail/pass depending on sizeof (int) might be possible but as said it might
> be that cris doesn't have sizeof (int) == 1

You meant something else here than what you wrote.  If you meant (effectively)
sizeof (int) == 4, then "every port" has INT_TYPE_SIZE 32 (bits), including
those mentioned in this PR.

> but instead just lays out
> struct ubits in a way to have its size being 1.

It's true that sizeof (struct ubits) == 1 (byte) for cris-elf.

FWIW, I don't know what it is that pru-elf, cris-elf and m68k-linux have in
common that matters here.  First I was dead sure it was they got "#define
PCC_BITFIELD_TYPE_MATTERS false" but that doesn't seem to grep to true for
pru-elf.  cris-elf and m68k include config/elfos.h then #undef
PCC_BITFIELD_TYPE_MATTERS, so you get the quoted defaults.h line, but pru
doesn't have the #undef.

[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971

[dmalcolm at gcc dot gnu.org]

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

David Malcolm <dmalcolm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P5

--- Comment #10 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Reducing the priority of this from P3 to P5: this is a synthetic test case to
try to exercise bitfields (and check that we don't ICE), but the impact of the
failure is minimal, I think - beyond the noise for test runs on the affected
targets (sorry).

[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971

[dmalcolm at gcc dot gnu.org]

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

--- Comment #11 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
I experimented with fixing this properly so that it works for all targets, but
the fix involves adding a new region subclass to handle bitfields, and so feels
far too risky for GCC 11.

Hence this should be XFAILed for GCC 11; I'm not yet sure exactly what the
target selector should be.

[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson <hp at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |xfail

--- Comment #12 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
(In reply to David Malcolm from comment #11)
> I experimented with fixing this properly so that it works for all targets,
> but the fix involves adding a new region subclass to handle bitfields, and
> so feels far too risky for GCC 11.
> 
> Hence this should be XFAILed for GCC 11; I'm not yet sure exactly what the
> target selector should be.

Me fix.  Thanks for looking.

[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Hans-Peter Nilsson <hp@gcc.gnu.org>:

https://gcc.gnu.org/g:07b27384de56ce2f6a93007d018743ef9d5c8cc4

commit r11-8143-g07b27384de56ce2f6a93007d018743ef9d5c8cc4
Author: Hans-Peter Nilsson <hp@axis.com>
Date:   Tue Apr 13 04:08:08 2021 +0200

    gcc.dg/analyzer/data-model-1.c: Inverse xfail for cris-*-*, PR99212

    See PR99212.  Now, cris-elf isn't the only target for which this line
    shows a failure; pru-unknown-elf and m68k-unknown-linux-gnu are two
    others.  I'll leave adjustments to the respective maintainers, but
    trivially appending more triplets should work: no extra bracketing needed.
    A specific effective_target specifier would as always be perferable, but I
    couldn't without accountable effort find out what was the common factor.

    Besides cris-elf, sanity-checked for native x86_64-*-linux*.

    gcc/testsuite:
            PR analyzer/99212
            * gcc.dg/analyzer/data-model-1.c (test_45): Inverse xfail at
            line 971 for cris-*-*.

[Bug analyzer/99212] [11/12 Regression] gcc.dg/analyzer/data-model-1.c line 971

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.0                        |11.2

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 11.1 has been released, retargeting bugs to GCC 11.2.

[Bug analyzer/99212] [11/12 Regression] gcc.dg/analyzer/data-model-1.c line 971

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

[Bug analyzer/99212] [11/12 Regression] gcc.dg/analyzer/data-model-1.c line 971

[cvs-commit at gcc dot gnu.org]

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

--- Comment #15 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by David Malcolm <dmalcolm@gcc.gnu.org>:

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

commit r12-1303-gd3b1ef7a83c0c0cd5b20a1dd1714b868f3d2b442
Author: David Malcolm <dmalcolm@redhat.com>
Date:   Tue Jun 8 14:45:57 2021 -0400

    analyzer: bitfield fixes [PR99212]

    This patch verifies the previous fix for bitfield sizes by implementing
    enough support for bitfields in the analyzer to get the test cases to pass.

    The patch implements support in the analyzer for reading from a
    BIT_FIELD_REF, and support for folding BIT_AND_EXPR of a mask, to handle
    the cases generated in tests.

    The existing bitfields tests in data-model-1.c turned out to rely on
    undefined behavior, in that they were assigning values to a signed
    bitfield that were outside of the valid range of values.  I believe that
    that's why we were seeing target-specific differences in the test
    results (PR analyzer/99212).  The patch updates the test to remove the
    undefined behaviors.

    gcc/analyzer/ChangeLog:
            PR analyzer/99212
            * region-model-manager.cc
            (region_model_manager::maybe_fold_binop): Add support for folding
            BIT_AND_EXPR of compound_svalue and a mask constant.
            * region-model.cc (region_model::get_rvalue_1): Implement
            BIT_FIELD_REF in terms of...
            (region_model::get_rvalue_for_bits): New function.
            * region-model.h (region_model::get_rvalue_for_bits): New decl.
            * store.cc (bit_range::from_mask): New function.
            (selftest::test_bit_range_intersects_p): New selftest.
            (selftest::assert_bit_range_from_mask_eq): New.
            (ASSERT_BIT_RANGE_FROM_MASK_EQ): New macro.
            (selftest::assert_no_bit_range_from_mask_eq): New.
            (ASSERT_NO_BIT_RANGE_FROM_MASK): New macro.
            (selftest::test_bit_range_from_mask): New selftest.
            (selftest::analyzer_store_cc_tests): Call the new selftests.
            * store.h (bit_range::intersects_p): New.
            (bit_range::from_mask): New decl.
            (concrete_binding::get_bit_range): New accessor.
            (store_manager::get_concrete_binding): New overload taking
            const bit_range &.

    gcc/testsuite/ChangeLog:
            PR analyzer/99212
            * gcc.dg/analyzer/bitfields-1.c: New test.
            * gcc.dg/analyzer/data-model-1.c (struct sbits): Make bitfields
            explicitly signed.
            (test_44): Update test values assigned to the bits to ones that
            fit in the range of the bitfield type.  Remove xfails.
            (test_45): Remove xfails.

    Signed-off-by: David Malcolm <dmalcolm@redhat.com>

[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971

[dmalcolm at gcc dot gnu.org]

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

David Malcolm <dmalcolm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[11/12 Regression]          |[11 Regression]
                   |gcc.dg/analyzer/data-model- |gcc.dg/analyzer/data-model-
                   |1.c line 971                |1.c line 971

--- Comment #16 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Should be fixed on trunk (for gcc 12) by the above commit

[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971

[stefansf at linux dot ibm.com]

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

Stefan Schulze Frielinghaus <stefansf at linux dot ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |stefansf at linux dot ibm.com

--- Comment #17 from Stefan Schulze Frielinghaus <stefansf at linux dot ibm.com> ---
The new testcases introduced by commit d3b1ef7a83c fail on IBM Z as well as
some older data-model tests:

+FAIL: gcc.dg/analyzer/bitfields-1.c  (test for warnings, line 113)
+FAIL: gcc.dg/analyzer/bitfields-1.c  (test for warnings, line 115)
+FAIL: gcc.dg/analyzer/bitfields-1.c  (test for warnings, line 117)
+FAIL: gcc.dg/analyzer/bitfields-1.c  (test for warnings, line 119)
+FAIL: gcc.dg/analyzer/bitfields-1.c  (test for warnings, line 121)
+FAIL: gcc.dg/analyzer/bitfields-1.c  (test for warnings, line 123)
+FAIL: gcc.dg/analyzer/bitfields-1.c  (test for warnings, line 125)
+FAIL: gcc.dg/analyzer/bitfields-1.c  (test for warnings, line 127)
+FAIL: gcc.dg/analyzer/bitfields-1.c  (test for warnings, line 24)
+FAIL: gcc.dg/analyzer/bitfields-1.c  (test for warnings, line 26)
+FAIL: gcc.dg/analyzer/bitfields-1.c  (test for warnings, line 29)
+FAIL: gcc.dg/analyzer/bitfields-1.c  (test for warnings, line 31)
+FAIL: gcc.dg/analyzer/bitfields-1.c  (test for warnings, line 36)
+FAIL: gcc.dg/analyzer/bitfields-1.c  (test for warnings, line 41)
+FAIL: gcc.dg/analyzer/bitfields-1.c  (test for warnings, line 81)
+FAIL: gcc.dg/analyzer/bitfields-1.c  (test for warnings, line 83)
+FAIL: gcc.dg/analyzer/bitfields-1.c  (test for warnings, line 85)
+FAIL: gcc.dg/analyzer/bitfields-1.c  (test for warnings, line 87)
+FAIL: gcc.dg/analyzer/bitfields-1.c  (test for warnings, line 92)
+FAIL: gcc.dg/analyzer/bitfields-1.c  (test for warnings, line 94)
+FAIL: gcc.dg/analyzer/bitfields-1.c  (test for warnings, line 96)
+FAIL: gcc.dg/analyzer/bitfields-1.c (test for excess errors)
+FAIL: gcc.dg/analyzer/data-model-1.c  (test for warnings, line 947)
+FAIL: gcc.dg/analyzer/data-model-1.c  (test for warnings, line 950)
+FAIL: gcc.dg/analyzer/data-model-1.c  (test for warnings, line 965)
+FAIL: gcc.dg/analyzer/data-model-1.c  (test for warnings, line 968)
+FAIL: gcc.dg/analyzer/data-model-1.c (test for excess errors)

The actual warning for those failing tests is "UNKNOWN".

[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971

[dmalcolm at gcc dot gnu.org]

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

--- Comment #18 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
(In reply to Stefan Schulze Frielinghaus from comment #17)
> The new testcases introduced by commit d3b1ef7a83c fail on IBM Z as well as
> some older data-model tests:

Sorry about this; it sounds similar to the issues reported by Christophe Lyon
on armeb-none-linux-gnueabihf here:
  https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572375.html

That one appears to be a bug with that patch, for targets where
BYTES_BIG_ENDIAN is set.

I'm testing a fix for it, using config-list.mk to test all targets, but it's
taking a while; FWIW the fix seems to work on s390-linux-gnu, which for my
reference has:

  BITS_BIG_ENDIAN: 1
  BYTES_BIG_ENDIAN: 1
  WORDS_BIG_ENDIAN: 1

[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971

[cvs-commit at gcc dot gnu.org]

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

--- Comment #19 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by David Malcolm <dmalcolm@gcc.gnu.org>:

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

commit r12-1491-gec3fafa9ec7d16b9d89076efd3bac1d1af0502b8
Author: David Malcolm <dmalcolm@redhat.com>
Date:   Tue Jun 15 17:53:34 2021 -0400

    analyzer: fix bitfield endianness issues [PR99212,PR101082]

    Looks like my patch for PR analyzer/99212 implicitly assumed
    little-endian, which the following patch fixes.

    Fixes bitfields-1.c on:
    - armeb-none-linux-gnueabihf
    - cris-elf
    - powerpc64-darwin
    - s390-linux-gnu

    gcc/analyzer/ChangeLog:
            PR analyzer/99212
            PR analyzer/101082
            * engine.cc: Include "target.h".
            (impl_run_checkers): Log BITS_BIG_ENDIAN, BYTES_BIG_ENDIAN, and
            WORDS_BIG_ENDIAN.
            * region-model-manager.cc
            (region_model_manager::maybe_fold_binop): Move support for masking
            via ARG0 & CST into...
            (region_model_manager::maybe_undo_optimize_bit_field_compare):
            ...this new function.  Flatten by converting from nested
            conditionals to a series of early return statements to reject
            failures.  Reject if type is not unsigned_char_type_node.
            Handle BYTES_BIG_ENDIAN when determining which bits are bound
            in the binding_map.
            * region-model.h
            (region_model_manager::maybe_undo_optimize_bit_field_compare):
            New decl.
            * store.cc (bit_range::dump): New function.
            * store.h (bit_range::dump): New decl.

    Signed-off-by: David Malcolm <dmalcolm@redhat.com>

[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971

[stefansf at linux dot ibm.com]

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

--- Comment #20 from Stefan Schulze Frielinghaus <stefansf at linux dot ibm.com> ---
The mentioned failing test cases are fixed on IBM Z, now. Thanks for your help!

[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971

[cvs-commit at gcc dot gnu.org]

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

--- Comment #21 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by David Malcolm
<dmalcolm@gcc.gnu.org>:

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

commit r11-8678-gfa92642b26ee236098ed51752feecc7cf5711f8c
Author: David Malcolm <dmalcolm@redhat.com>
Date:   Fri Jul 2 15:19:45 2021 -0400

    analyzer: bitfield fixes [PR99212]

    This patch verifies the previous fix for bitfield sizes by implementing
    enough support for bitfields in the analyzer to get the test cases to pass.

    The patch implements support in the analyzer for reading from a
    BIT_FIELD_REF, and support for folding BIT_AND_EXPR of a mask, to handle
    the cases generated in tests.

    The existing bitfields tests in data-model-1.c turned out to rely on
    undefined behavior, in that they were assigning values to a signed
    bitfield that were outside of the valid range of values.  I believe that
    that's why we were seeing target-specific differences in the test
    results (PR analyzer/99212).  The patch updates the test to remove the
    undefined behaviors.

    gcc/analyzer/ChangeLog:
            PR analyzer/99212
            * region-model-manager.cc
            (region_model_manager::maybe_fold_binop): Add support for folding
            BIT_AND_EXPR of compound_svalue and a mask constant.
            * region-model.cc (region_model::get_rvalue_1): Implement
            BIT_FIELD_REF in terms of...
            (region_model::get_rvalue_for_bits): New function.
            * region-model.h (region_model::get_rvalue_for_bits): New decl.
            * store.cc (bit_range::from_mask): New function.
            (selftest::test_bit_range_intersects_p): New selftest.
            (selftest::assert_bit_range_from_mask_eq): New.
            (ASSERT_BIT_RANGE_FROM_MASK_EQ): New macro.
            (selftest::assert_no_bit_range_from_mask_eq): New.
            (ASSERT_NO_BIT_RANGE_FROM_MASK): New macro.
            (selftest::test_bit_range_from_mask): New selftest.
            (selftest::analyzer_store_cc_tests): Call the new selftests.
            * store.h (bit_range::intersects_p): New.
            (bit_range::from_mask): New decl.
            (concrete_binding::get_bit_range): New accessor.
            (store_manager::get_concrete_binding): New overload taking
            const bit_range &.

    gcc/testsuite/ChangeLog:
            PR analyzer/99212
            * gcc.dg/analyzer/bitfields-1.c: New test.
            * gcc.dg/analyzer/data-model-1.c (struct sbits): Make bitfields
            explicitly signed.
            (test_44): Update test values assigned to the bits to ones that
            fit in the range of the bitfield type.  Remove xfails.
            (test_45): Remove xfails.

    Signed-off-by: David Malcolm <dmalcolm@redhat.com>

[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971

[cvs-commit at gcc dot gnu.org]

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

--- Comment #22 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by David Malcolm
<dmalcolm@gcc.gnu.org>:

https://gcc.gnu.org/g:21b470a9c976f3db7cce6d58a07c58a58676f93c

commit r11-8681-g21b470a9c976f3db7cce6d58a07c58a58676f93c
Author: David Malcolm <dmalcolm@redhat.com>
Date:   Fri Jul 2 15:19:46 2021 -0400

    analyzer: fix bitfield endianness issues [PR99212,PR101082]

    Looks like my patch for PR analyzer/99212 implicitly assumed
    little-endian, which the following patch fixes.

    Fixes bitfields-1.c on:
    - armeb-none-linux-gnueabihf
    - cris-elf
    - powerpc64-darwin
    - s390-linux-gnu

    gcc/analyzer/ChangeLog:
            PR analyzer/99212
            PR analyzer/101082
            * engine.cc: Include "target.h".
            (impl_run_checkers): Log BITS_BIG_ENDIAN, BYTES_BIG_ENDIAN, and
            WORDS_BIG_ENDIAN.
            * region-model-manager.cc
            (region_model_manager::maybe_fold_binop): Move support for masking
            via ARG0 & CST into...
            (region_model_manager::maybe_undo_optimize_bit_field_compare):
            ...this new function.  Flatten by converting from nested
            conditionals to a series of early return statements to reject
            failures.  Reject if type is not unsigned_char_type_node.
            Handle BYTES_BIG_ENDIAN when determining which bits are bound
            in the binding_map.
            * region-model.h
            (region_model_manager::maybe_undo_optimize_bit_field_compare):
            New decl.
            * store.cc (bit_range::dump): New function.
            * store.h (bit_range::dump): New decl.

    Signed-off-by: David Malcolm <dmalcolm@redhat.com>

[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971

[dmalcolm at gcc dot gnu.org]

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

David Malcolm <dmalcolm at gcc dot gnu.org> changed:

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

--- Comment #23 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Fixed on branch (for gcc 11.2) by above commits; marking as resolved.