* [Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
2021-02-23 3:35 [Bug analyzer/99212] New: [11 Regression] gcc.dg/analyzer/data-model-1.c line 971 hp at gcc dot gnu.org
@ 2021-02-23 8:27 ` rguenth at gcc dot gnu.org
2021-02-23 14:49 ` hp at gcc dot gnu.org
` (23 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-02-23 8:27 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
2021-02-23 3:35 [Bug analyzer/99212] New: [11 Regression] gcc.dg/analyzer/data-model-1.c line 971 hp at gcc dot gnu.org
2021-02-23 8:27 ` [Bug analyzer/99212] " rguenth at gcc dot gnu.org
@ 2021-02-23 14:49 ` hp at gcc dot gnu.org
2021-02-25 23:02 ` dmalcolm at gcc dot gnu.org
` (22 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: hp at gcc dot gnu.org @ 2021-02-23 14:49 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
2021-02-23 3:35 [Bug analyzer/99212] New: [11 Regression] gcc.dg/analyzer/data-model-1.c line 971 hp at gcc dot gnu.org
2021-02-23 8:27 ` [Bug analyzer/99212] " rguenth at gcc dot gnu.org
2021-02-23 14:49 ` hp at gcc dot gnu.org
@ 2021-02-25 23:02 ` dmalcolm at gcc dot gnu.org
2021-02-25 23:03 ` dmalcolm at gcc dot gnu.org
` (21 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2021-02-25 23:02 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
2021-02-23 3:35 [Bug analyzer/99212] New: [11 Regression] gcc.dg/analyzer/data-model-1.c line 971 hp at gcc dot gnu.org
` (2 preceding siblings ...)
2021-02-25 23:02 ` dmalcolm at gcc dot gnu.org
@ 2021-02-25 23:03 ` dmalcolm at gcc dot gnu.org
2021-02-26 12:58 ` rguenth at gcc dot gnu.org
` (20 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2021-02-25 23:03 UTC (permalink / raw)
To: gcc-bugs
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);
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
2021-02-23 3:35 [Bug analyzer/99212] New: [11 Regression] gcc.dg/analyzer/data-model-1.c line 971 hp at gcc dot gnu.org
` (3 preceding siblings ...)
2021-02-25 23:03 ` dmalcolm at gcc dot gnu.org
@ 2021-02-26 12:58 ` rguenth at gcc dot gnu.org
2021-02-26 14:23 ` dmalcolm at gcc dot gnu.org
` (19 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-02-26 12:58 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
2021-02-23 3:35 [Bug analyzer/99212] New: [11 Regression] gcc.dg/analyzer/data-model-1.c line 971 hp at gcc dot gnu.org
` (4 preceding siblings ...)
2021-02-26 12:58 ` rguenth at gcc dot gnu.org
@ 2021-02-26 14:23 ` dmalcolm at gcc dot gnu.org
2021-02-26 14:33 ` dmalcolm at gcc dot gnu.org
` (18 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2021-02-26 14:23 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
2021-02-23 3:35 [Bug analyzer/99212] New: [11 Regression] gcc.dg/analyzer/data-model-1.c line 971 hp at gcc dot gnu.org
` (5 preceding siblings ...)
2021-02-26 14:23 ` dmalcolm at gcc dot gnu.org
@ 2021-02-26 14:33 ` dmalcolm at gcc dot gnu.org
2021-04-04 21:57 ` hp at gcc dot gnu.org
` (17 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2021-02-26 14:33 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
2021-02-23 3:35 [Bug analyzer/99212] New: [11 Regression] gcc.dg/analyzer/data-model-1.c line 971 hp at gcc dot gnu.org
` (6 preceding siblings ...)
2021-02-26 14:33 ` dmalcolm at gcc dot gnu.org
@ 2021-04-04 21:57 ` hp at gcc dot gnu.org
2021-04-09 8:24 ` rguenth at gcc dot gnu.org
` (16 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: hp at gcc dot gnu.org @ 2021-04-04 21:57 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
2021-02-23 3:35 [Bug analyzer/99212] New: [11 Regression] gcc.dg/analyzer/data-model-1.c line 971 hp at gcc dot gnu.org
` (7 preceding siblings ...)
2021-04-04 21:57 ` hp at gcc dot gnu.org
@ 2021-04-09 8:24 ` rguenth at gcc dot gnu.org
2021-04-09 23:11 ` hp at gcc dot gnu.org
` (15 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-04-09 8:24 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
2021-02-23 3:35 [Bug analyzer/99212] New: [11 Regression] gcc.dg/analyzer/data-model-1.c line 971 hp at gcc dot gnu.org
` (8 preceding siblings ...)
2021-04-09 8:24 ` rguenth at gcc dot gnu.org
@ 2021-04-09 23:11 ` hp at gcc dot gnu.org
2021-04-10 17:45 ` dmalcolm at gcc dot gnu.org
` (14 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: hp at gcc dot gnu.org @ 2021-04-09 23:11 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
2021-02-23 3:35 [Bug analyzer/99212] New: [11 Regression] gcc.dg/analyzer/data-model-1.c line 971 hp at gcc dot gnu.org
` (9 preceding siblings ...)
2021-04-09 23:11 ` hp at gcc dot gnu.org
@ 2021-04-10 17:45 ` dmalcolm at gcc dot gnu.org
2021-04-12 12:59 ` dmalcolm at gcc dot gnu.org
` (13 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2021-04-10 17:45 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
2021-02-23 3:35 [Bug analyzer/99212] New: [11 Regression] gcc.dg/analyzer/data-model-1.c line 971 hp at gcc dot gnu.org
` (10 preceding siblings ...)
2021-04-10 17:45 ` dmalcolm at gcc dot gnu.org
@ 2021-04-12 12:59 ` dmalcolm at gcc dot gnu.org
2021-04-13 2:23 ` hp at gcc dot gnu.org
` (12 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2021-04-12 12:59 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
2021-02-23 3:35 [Bug analyzer/99212] New: [11 Regression] gcc.dg/analyzer/data-model-1.c line 971 hp at gcc dot gnu.org
` (11 preceding siblings ...)
2021-04-12 12:59 ` dmalcolm at gcc dot gnu.org
@ 2021-04-13 2:23 ` hp at gcc dot gnu.org
2021-04-13 2:23 ` cvs-commit at gcc dot gnu.org
` (11 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: hp at gcc dot gnu.org @ 2021-04-13 2:23 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
2021-02-23 3:35 [Bug analyzer/99212] New: [11 Regression] gcc.dg/analyzer/data-model-1.c line 971 hp at gcc dot gnu.org
` (12 preceding siblings ...)
2021-04-13 2:23 ` hp at gcc dot gnu.org
@ 2021-04-13 2:23 ` cvs-commit at gcc dot gnu.org
2021-04-27 11:40 ` [Bug analyzer/99212] [11/12 " jakub at gcc dot gnu.org
` (10 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-04-13 2:23 UTC (permalink / raw)
To: gcc-bugs
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-*-*.
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug analyzer/99212] [11/12 Regression] gcc.dg/analyzer/data-model-1.c line 971
2021-02-23 3:35 [Bug analyzer/99212] New: [11 Regression] gcc.dg/analyzer/data-model-1.c line 971 hp at gcc dot gnu.org
` (13 preceding siblings ...)
2021-04-13 2:23 ` cvs-commit at gcc dot gnu.org
@ 2021-04-27 11:40 ` jakub at gcc dot gnu.org
2021-05-04 12:32 ` rguenth at gcc dot gnu.org
` (9 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-04-27 11:40 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug analyzer/99212] [11/12 Regression] gcc.dg/analyzer/data-model-1.c line 971
2021-02-23 3:35 [Bug analyzer/99212] New: [11 Regression] gcc.dg/analyzer/data-model-1.c line 971 hp at gcc dot gnu.org
` (14 preceding siblings ...)
2021-04-27 11:40 ` [Bug analyzer/99212] [11/12 " jakub at gcc dot gnu.org
@ 2021-05-04 12:32 ` rguenth at gcc dot gnu.org
2021-06-08 18:46 ` cvs-commit at gcc dot gnu.org
` (8 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-05-04 12:32 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug analyzer/99212] [11/12 Regression] gcc.dg/analyzer/data-model-1.c line 971
2021-02-23 3:35 [Bug analyzer/99212] New: [11 Regression] gcc.dg/analyzer/data-model-1.c line 971 hp at gcc dot gnu.org
` (15 preceding siblings ...)
2021-05-04 12:32 ` rguenth at gcc dot gnu.org
@ 2021-06-08 18:46 ` cvs-commit at gcc dot gnu.org
2021-06-08 19:30 ` [Bug analyzer/99212] [11 " dmalcolm at gcc dot gnu.org
` (7 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-06-08 18:46 UTC (permalink / raw)
To: gcc-bugs
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>
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
2021-02-23 3:35 [Bug analyzer/99212] New: [11 Regression] gcc.dg/analyzer/data-model-1.c line 971 hp at gcc dot gnu.org
` (16 preceding siblings ...)
2021-06-08 18:46 ` cvs-commit at gcc dot gnu.org
@ 2021-06-08 19:30 ` dmalcolm at gcc dot gnu.org
2021-06-15 8:05 ` stefansf at linux dot ibm.com
` (6 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2021-06-08 19:30 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
2021-02-23 3:35 [Bug analyzer/99212] New: [11 Regression] gcc.dg/analyzer/data-model-1.c line 971 hp at gcc dot gnu.org
` (17 preceding siblings ...)
2021-06-08 19:30 ` [Bug analyzer/99212] [11 " dmalcolm at gcc dot gnu.org
@ 2021-06-15 8:05 ` stefansf at linux dot ibm.com
2021-06-15 14:28 ` dmalcolm at gcc dot gnu.org
` (5 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: stefansf at linux dot ibm.com @ 2021-06-15 8:05 UTC (permalink / raw)
To: gcc-bugs
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".
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
2021-02-23 3:35 [Bug analyzer/99212] New: [11 Regression] gcc.dg/analyzer/data-model-1.c line 971 hp at gcc dot gnu.org
` (18 preceding siblings ...)
2021-06-15 8:05 ` stefansf at linux dot ibm.com
@ 2021-06-15 14:28 ` dmalcolm at gcc dot gnu.org
2021-06-15 21:54 ` cvs-commit at gcc dot gnu.org
` (4 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2021-06-15 14:28 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
2021-02-23 3:35 [Bug analyzer/99212] New: [11 Regression] gcc.dg/analyzer/data-model-1.c line 971 hp at gcc dot gnu.org
` (19 preceding siblings ...)
2021-06-15 14:28 ` dmalcolm at gcc dot gnu.org
@ 2021-06-15 21:54 ` cvs-commit at gcc dot gnu.org
2021-06-18 7:36 ` stefansf at linux dot ibm.com
` (3 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-06-15 21:54 UTC (permalink / raw)
To: gcc-bugs
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>
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
2021-02-23 3:35 [Bug analyzer/99212] New: [11 Regression] gcc.dg/analyzer/data-model-1.c line 971 hp at gcc dot gnu.org
` (20 preceding siblings ...)
2021-06-15 21:54 ` cvs-commit at gcc dot gnu.org
@ 2021-06-18 7:36 ` stefansf at linux dot ibm.com
2021-07-02 19:22 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: stefansf at linux dot ibm.com @ 2021-06-18 7:36 UTC (permalink / raw)
To: gcc-bugs
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!
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
2021-02-23 3:35 [Bug analyzer/99212] New: [11 Regression] gcc.dg/analyzer/data-model-1.c line 971 hp at gcc dot gnu.org
` (21 preceding siblings ...)
2021-06-18 7:36 ` stefansf at linux dot ibm.com
@ 2021-07-02 19:22 ` cvs-commit at gcc dot gnu.org
2021-07-02 19:22 ` cvs-commit at gcc dot gnu.org
2021-07-02 19:31 ` dmalcolm at gcc dot gnu.org
24 siblings, 0 replies; 26+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-07-02 19:22 UTC (permalink / raw)
To: gcc-bugs
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>
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
2021-02-23 3:35 [Bug analyzer/99212] New: [11 Regression] gcc.dg/analyzer/data-model-1.c line 971 hp at gcc dot gnu.org
` (22 preceding siblings ...)
2021-07-02 19:22 ` cvs-commit at gcc dot gnu.org
@ 2021-07-02 19:22 ` cvs-commit at gcc dot gnu.org
2021-07-02 19:31 ` dmalcolm at gcc dot gnu.org
24 siblings, 0 replies; 26+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-07-02 19:22 UTC (permalink / raw)
To: gcc-bugs
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>
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
2021-02-23 3:35 [Bug analyzer/99212] New: [11 Regression] gcc.dg/analyzer/data-model-1.c line 971 hp at gcc dot gnu.org
` (23 preceding siblings ...)
2021-07-02 19:22 ` cvs-commit at gcc dot gnu.org
@ 2021-07-02 19:31 ` dmalcolm at gcc dot gnu.org
24 siblings, 0 replies; 26+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2021-07-02 19:31 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 26+ messages in thread