[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #23 from David Malcolm --- Fixed on branch (for gcc 11.2) by above commits; marking as resolved.
[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212 --- Comment #22 from CVS Commits --- The releases/gcc-11 branch has been updated by David Malcolm : https://gcc.gnu.org/g:21b470a9c976f3db7cce6d58a07c58a58676f93c commit r11-8681-g21b470a9c976f3db7cce6d58a07c58a58676f93c Author: David Malcolm 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
[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212 --- Comment #21 from CVS Commits --- The releases/gcc-11 branch has been updated by David Malcolm : https://gcc.gnu.org/g:fa92642b26ee236098ed51752feecc7cf5711f8c commit r11-8678-gfa92642b26ee236098ed51752feecc7cf5711f8c Author: David Malcolm 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
[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212 --- Comment #20 from Stefan Schulze Frielinghaus --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212 --- Comment #19 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:ec3fafa9ec7d16b9d89076efd3bac1d1af0502b8 commit r12-1491-gec3fafa9ec7d16b9d89076efd3bac1d1af0502b8 Author: David Malcolm 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
[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212 --- Comment #18 from David Malcolm --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212 Stefan Schulze Frielinghaus changed: What|Removed |Added CC||stefansf at linux dot ibm.com --- Comment #17 from Stefan Schulze Frielinghaus --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212 David Malcolm 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 --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212 --- Comment #13 from CVS Commits --- The master branch has been updated by Hans-Peter Nilsson : https://gcc.gnu.org/g:07b27384de56ce2f6a93007d018743ef9d5c8cc4 commit r11-8143-g07b27384de56ce2f6a93007d018743ef9d5c8cc4 Author: Hans-Peter Nilsson 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 Regression] gcc.dg/analyzer/data-model-1.c line 971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212 Hans-Peter Nilsson changed: What|Removed |Added Keywords||xfail --- Comment #12 from Hans-Peter Nilsson --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212 --- Comment #11 from David Malcolm --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212 David Malcolm changed: What|Removed |Added Priority|P3 |P5 --- Comment #10 from David Malcolm --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212 --- Comment #9 from Hans-Peter Nilsson --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212
Richard Biener changed:
What|Removed |Added
Target||cris-elf
--- Comment #8 from Richard Biener ---
Just to repeat - we have folding that turns BIT_FIELD_REF into
VIEW_CONVERT_EXPR (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212 --- Comment #7 from Hans-Peter Nilsson --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212 --- Comment #6 from David Malcolm --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212 --- Comment #5 from David Malcolm --- 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) constant 8> unit-size constant 1> align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffea7a83f0 precision:1 min max > On a 3-bit unsigned bitfield I'm seeing: (gdb) call debug_tree(m_type) constant 8> unit-size constant 1> align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffea7a8498 precision:3 min max > 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212 --- Comment #4 from Richard Biener --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212 --- Comment #3 from David Malcolm --- (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 ; _2 = _1 & 1; _3 = _2 != 0; _4 = (int) _3; __analyzer_eval (_4); bits.b456 = 5; _5 = BIT_FIELD_REF ; _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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212
--- Comment #2 from David Malcolm ---
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 ;
_2 = _1 & 1;
_3 = _2 != 0;
_4 = (int) _3;
__analyzer_eval (_4);
bits.b0 = 1;
_1 = BIT_FIELD_REF ;
_2 = _1 & 1;
_3 = _2 != 0;
_4 = (int) _3;
__analyzer_eval (_4);
whereas cris-axis-elf has:
bits.b0 = 1;
_1 = VIEW_CONVERT_EXPR(bits);
_2 = _1 & 1;
_3 = _2 != 0;
_4 = (int) _3;
__analyzer_eval (_4);
bits.b456 = 5;
_5 = VIEW_CONVERT_EXPR(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212 Hans-Peter Nilsson changed: What|Removed |Added Last reconfirmed||2021-02-23 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Hans-Peter Nilsson --- Current observation: 198c56052ea8 / r11-7337
[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0
