public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug tree-optimization/99919] New: [9/10/11 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field
@ 2021-04-05 20:29 msebor at gcc dot gnu.org
2021-04-05 20:51 ` [Bug tree-optimization/99919] " msebor at gcc dot gnu.org
` (12 more replies)
0 siblings, 13 replies; 14+ messages in thread
From: msebor at gcc dot gnu.org @ 2021-04-05 20:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99919
Bug ID: 99919
Summary: [9/10/11 Regression] bogus -Wmaybe-uninitialized with
a _Bool bit-field
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
This is the -Wmaybe-uninitialized subset of pr99918 showing how the failure to
fail _Bool bit-field expressions can cause bogus warnings. (Like pr99918, this
was most likely caused by r225825.)
$ cat z.c && gcc -O2 -S -Wall z.c
struct B { _Bool i: 1; _Bool j: 1; };
_Bool z;
void g (struct B b)
{
_Bool x;
if (b.i)
b.j = 0;
else
{
b.j = b.i;
x = b.i;
}
if (b.j)
z = x;
}
z.c: In function ‘g’:
z.c:18:7: warning: ‘x’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
18 | z = x;
| ~~^~~
z.c:7:9: note: ‘x’ was declared here
7 | _Bool x;
| ^
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/99919] [9/10/11 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field
2021-04-05 20:29 [Bug tree-optimization/99919] New: [9/10/11 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field msebor at gcc dot gnu.org
@ 2021-04-05 20:51 ` msebor at gcc dot gnu.org
2021-04-06 8:39 ` rguenth at gcc dot gnu.org
` (11 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: msebor at gcc dot gnu.org @ 2021-04-05 20:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99919
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |99918
--- Comment #1 from Martin Sebor <msebor at gcc dot gnu.org> ---
The IL below shows there is enough information in the IL for the warning to
determine that x_5 is never read from.
void g (struct B b)
{
_Bool b$j;
_Bool b$i;
_Bool x;
unsigned char _1;
unsigned char _2;
unsigned char _3;
unsigned char _4;
<bb 2> [local count: 1073741824]:
b$i_11 = b.i;
_1 = VIEW_CONVERT_EXPR<unsigned char>(b);
_2 = _1 & 1;
if (_2 != 0)
goto <bb 4>; [50.00%]
else
goto <bb 3>; [50.00%]
<bb 3> [local count: 536870912]:
<bb 4> [local count: 1073741824]:
# x_5 = PHI <x_8(D)(2), b$i_11(3)>
# b$j_10 = PHI <0(2), b$i_11(3)>
b.j = b$j_10;
_3 = VIEW_CONVERT_EXPR<unsigned char>(b);
_4 = _3 & 2;
if (_4 != 0)
goto <bb 5>; [50.00%]
else
goto <bb 6>; [50.00%]
<bb 5> [local count: 536870913]:
z = x_5;
<bb 6> [local count: 1073741824]:
return;
}
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99918
[Bug 99918] [9/10/11 Regression] suboptimal code for bool bitfield tests
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/99919] [9/10/11 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field
2021-04-05 20:29 [Bug tree-optimization/99919] New: [9/10/11 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field msebor at gcc dot gnu.org
2021-04-05 20:51 ` [Bug tree-optimization/99919] " msebor at gcc dot gnu.org
@ 2021-04-06 8:39 ` rguenth at gcc dot gnu.org
2021-04-08 14:22 ` rguenth at gcc dot gnu.org
` (10 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-04-06 8:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99919
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |9.4
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/99919] [9/10/11 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field
2021-04-05 20:29 [Bug tree-optimization/99919] New: [9/10/11 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field msebor at gcc dot gnu.org
2021-04-05 20:51 ` [Bug tree-optimization/99919] " msebor at gcc dot gnu.org
2021-04-06 8:39 ` rguenth at gcc dot gnu.org
@ 2021-04-08 14:22 ` rguenth at gcc dot gnu.org
2021-06-01 8:20 ` [Bug tree-optimization/99919] [9/10/11/12 " rguenth at gcc dot gnu.org
` (9 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-04-08 14:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99919
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P2
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/99919] [9/10/11/12 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field
2021-04-05 20:29 [Bug tree-optimization/99919] New: [9/10/11 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field msebor at gcc dot gnu.org
` (2 preceding siblings ...)
2021-04-08 14:22 ` rguenth at gcc dot gnu.org
@ 2021-06-01 8:20 ` rguenth at gcc dot gnu.org
2021-11-30 11:58 ` aldyh at gcc dot gnu.org
` (8 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-06-01 8:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99919
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|9.4 |9.5
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9.4 is being released, retargeting bugs to GCC 9.5.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/99919] [9/10/11/12 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field
2021-04-05 20:29 [Bug tree-optimization/99919] New: [9/10/11 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field msebor at gcc dot gnu.org
` (3 preceding siblings ...)
2021-06-01 8:20 ` [Bug tree-optimization/99919] [9/10/11/12 " rguenth at gcc dot gnu.org
@ 2021-11-30 11:58 ` aldyh at gcc dot gnu.org
2021-11-30 12:06 ` pinskia at gcc dot gnu.org
` (7 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: aldyh at gcc dot gnu.org @ 2021-11-30 11:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99919
Aldy Hernandez <aldyh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aldyh at gcc dot gnu.org
--- Comment #3 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #1)
> The IL below shows there is enough information in the IL for the warning to
> determine that x_5 is never read from.
>
> void g (struct B b)
> {
> _Bool b$j;
> _Bool b$i;
> _Bool x;
> unsigned char _1;
> unsigned char _2;
> unsigned char _3;
> unsigned char _4;
>
> <bb 2> [local count: 1073741824]:
> b$i_11 = b.i;
> _1 = VIEW_CONVERT_EXPR<unsigned char>(b);
> _2 = _1 & 1;
> if (_2 != 0)
> goto <bb 4>; [50.00%]
> else
> goto <bb 3>; [50.00%]
>
> <bb 3> [local count: 536870912]:
>
> <bb 4> [local count: 1073741824]:
> # x_5 = PHI <x_8(D)(2), b$i_11(3)>
> # b$j_10 = PHI <0(2), b$i_11(3)>
> b.j = b$j_10;
> _3 = VIEW_CONVERT_EXPR<unsigned char>(b);
> _4 = _3 & 2;
> if (_4 != 0)
> goto <bb 5>; [50.00%]
> else
> goto <bb 6>; [50.00%]
>
> <bb 5> [local count: 536870913]:
> z = x_5;
>
> <bb 6> [local count: 1073741824]:
> return;
>
> }
The warning on the above IL seems legit.
x_5 is initialized from b$i_11 when b & 1 == 0, but the read from x_5 happens
when b & 2 != 0. So the set and the read are predicated on two different
things.
Maybe I'm missing some subtle bit field thing. Does setting b.j somehow alter
b.i?
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/99919] [9/10/11/12 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field
2021-04-05 20:29 [Bug tree-optimization/99919] New: [9/10/11 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field msebor at gcc dot gnu.org
` (4 preceding siblings ...)
2021-11-30 11:58 ` aldyh at gcc dot gnu.org
@ 2021-11-30 12:06 ` pinskia at gcc dot gnu.org
2021-11-30 14:22 ` aldyh at gcc dot gnu.org
` (6 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-11-30 12:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99919
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2021-11-30
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org
Target Milestone|9.5 |13.0
Keywords| |deferred
--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #3)
> The warning on the above IL seems legit.
>
> x_5 is initialized from b$i_11 when b & 1 == 0, but the read from x_5
> happens when b & 2 != 0. So the set and the read are predicated on two
> different things.
>
> Maybe I'm missing some subtle bit field thing. Does setting b.j somehow
> alter b.i?
b.j is (b&2)<<1.
If lower bit field acceses it is fixed (but also becomes more obvious what the
of b.j is:
_20 = VIEW_CONVERT_EXPR<unsigned char>(b);
_21 = BIT_INSERT_EXPR <_20, b$j_15, 1 (1 bits)>;
VIEW_CONVERT_EXPR<unsigned char>(b) = _21;
_3 = VIEW_CONVERT_EXPR<unsigned char>(b);
_4 = _3 & 2;
So Mine for GCC 13.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/99919] [9/10/11/12 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field
2021-04-05 20:29 [Bug tree-optimization/99919] New: [9/10/11 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field msebor at gcc dot gnu.org
` (5 preceding siblings ...)
2021-11-30 12:06 ` pinskia at gcc dot gnu.org
@ 2021-11-30 14:22 ` aldyh at gcc dot gnu.org
2022-12-08 9:25 ` [Bug tree-optimization/99919] [10/11/12/13 " rguenth at gcc dot gnu.org
` (5 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: aldyh at gcc dot gnu.org @ 2021-11-30 14:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99919
--- Comment #5 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Aldy Hernandez from comment #3)
> > The warning on the above IL seems legit.
> >
> > x_5 is initialized from b$i_11 when b & 1 == 0, but the read from x_5
> > happens when b & 2 != 0. So the set and the read are predicated on two
> > different things.
> >
> > Maybe I'm missing some subtle bit field thing. Does setting b.j somehow
> > alter b.i?
> b.j is (b&2)<<1.
>
> If lower bit field acceses it is fixed (but also becomes more obvious what
> the of b.j is:
> _20 = VIEW_CONVERT_EXPR<unsigned char>(b);
> _21 = BIT_INSERT_EXPR <_20, b$j_15, 1 (1 bits)>;
> VIEW_CONVERT_EXPR<unsigned char>(b) = _21;
> _3 = VIEW_CONVERT_EXPR<unsigned char>(b);
> _4 = _3 & 2;
>
> So Mine for GCC 13.
You're a rockstar. Thanks.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/99919] [10/11/12/13 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field
2021-04-05 20:29 [Bug tree-optimization/99919] New: [9/10/11 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field msebor at gcc dot gnu.org
` (6 preceding siblings ...)
2021-11-30 14:22 ` aldyh at gcc dot gnu.org
@ 2022-12-08 9:25 ` rguenth at gcc dot gnu.org
2022-12-08 10:47 ` rguenth at gcc dot gnu.org
` (4 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-12-08 9:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99919
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Note the uninit pass has code to deal with this special
if (b.i)
b.j = 0;
...
if (b.j)
...
but it's confused by the b.j = 0 store appearing literally compared to the
b.j test being done via a (b & 2) test. That's also a missed jump threading
opportunity and possibly a missed CSE opportunity.
b.j = b$j_10;
_3 = VIEW_CONVERT_EXPR<unsigned char>(b);
_4 = _3 & 2;
here _4 could be CSEd as b$j_10. In fact we do have code for this in CSE
but the two pieces that would need to work together, a masked load and
partial def support, refuse to work together here. In particular the
mask can be used to fend off not relevant non-constants and to narrow
the bits we want to fill.
Not to say SRA does a bad job on this testcase, it's also premature
optimize_bit_field_compare "optimization" here. Maybe it's time to
kill off the case of bitfield vs constant compare "optimization".
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/99919] [10/11/12/13 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field
2021-04-05 20:29 [Bug tree-optimization/99919] New: [9/10/11 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field msebor at gcc dot gnu.org
` (7 preceding siblings ...)
2022-12-08 9:25 ` [Bug tree-optimization/99919] [10/11/12/13 " rguenth at gcc dot gnu.org
@ 2022-12-08 10:47 ` rguenth at gcc dot gnu.org
2023-04-26 6:55 ` [Bug tree-optimization/99919] [10/11/12/13/14 " rguenth at gcc dot gnu.org
` (3 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-12-08 10:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99919
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 54047
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54047&action=edit
patch
I also have a patch - this disables optimize_bit_field_compare for
bitfield vs. constant compares which is the source of most premature
obfuscation and avoids missing the optimization of multiple bitfield
extracts as if more aggressively removing this code.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/99919] [10/11/12/13/14 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field
2021-04-05 20:29 [Bug tree-optimization/99919] New: [9/10/11 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field msebor at gcc dot gnu.org
` (8 preceding siblings ...)
2022-12-08 10:47 ` rguenth at gcc dot gnu.org
@ 2023-04-26 6:55 ` rguenth at gcc dot gnu.org
2023-07-27 9:22 ` [Bug tree-optimization/99919] [11/12/13/14 " rguenth at gcc dot gnu.org
` (2 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-04-26 6:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99919
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|13.0 |13.2
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 13.1 is being released, retargeting bugs to GCC 13.2.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/99919] [11/12/13/14 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field
2021-04-05 20:29 [Bug tree-optimization/99919] New: [9/10/11 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field msebor at gcc dot gnu.org
` (9 preceding siblings ...)
2023-04-26 6:55 ` [Bug tree-optimization/99919] [10/11/12/13/14 " rguenth at gcc dot gnu.org
@ 2023-07-27 9:22 ` rguenth at gcc dot gnu.org
2023-12-15 13:33 ` rguenth at gcc dot gnu.org
2024-05-21 9:10 ` [Bug tree-optimization/99919] [11/12/13/14/15 " jakub at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-07-27 9:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99919
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|13.2 |13.3
--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 13.2 is being released, retargeting bugs to GCC 13.3.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/99919] [11/12/13/14 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field
2021-04-05 20:29 [Bug tree-optimization/99919] New: [9/10/11 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field msebor at gcc dot gnu.org
` (10 preceding siblings ...)
2023-07-27 9:22 ` [Bug tree-optimization/99919] [11/12/13/14 " rguenth at gcc dot gnu.org
@ 2023-12-15 13:33 ` rguenth at gcc dot gnu.org
2024-05-21 9:10 ` [Bug tree-optimization/99919] [11/12/13/14/15 " jakub at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-12-15 13:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99919
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed|2021-11-30 00:00:00 |2023-12-15
CC| |jamborm at gcc dot gnu.org
--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
This is also a missed SRA optimization. SRA produces
b$i_16 = b.i;
b$j_17 = b.j;
b.i = b$i_16;
b.j = b$j_17;
_1 = VIEW_CONVERT_EXPR<unsigned char>(b);
_2 = _1 & 1;
...
b.i = b$i_16;
b.j = b$j_15;
_4 = VIEW_CONVERT_EXPR<unsigned char>(b);
_5 = _4 & 2;
which is sub-optimal - for some reason it chooses to create replacements
for i and j instead of a unsigned char replacement for the whole
aggregate driven by the V_C_E access
access { base = (2771)'b', offset = 0, size = 8, expr = b, type = struct B,
reverse = 0, grp_read = 1, grp_write = 0, grp_assignment_read = 1,
grp_assignment_write = 0, grp_scalar_read = 0, grp_scalar_write = 0,
grp_total_scalarization = 0, grp_hint = 0, grp_covered = 0,
grp_unscalarizable_region = 0, grp_unscalarized_data = 1, grp_same_access_path
= 1, grp_partial_lhs = 0, grp_to_be_replaced = 0, grp_to_be_debug_replaced = 0}
is also odd because the access type is really 'unsigned char'? That seems
to be because
/* We need to dive through V_C_Es in order to get the size of its parameter
and not the result type. Ada produces such statements. We are also
capable of handling the topmost V_C_E but not any of those buried in other
handled components. */
if (TREE_CODE (expr) == VIEW_CONVERT_EXPR)
expr = TREE_OPERAND (expr, 0);
but I couldn't easily convince it to do sth here (and dumps turn out
empty as for reasoning of disqualification).
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/99919] [11/12/13/14/15 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field
2021-04-05 20:29 [Bug tree-optimization/99919] New: [9/10/11 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field msebor at gcc dot gnu.org
` (11 preceding siblings ...)
2023-12-15 13:33 ` rguenth at gcc dot gnu.org
@ 2024-05-21 9:10 ` jakub at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-05-21 9:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99919
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|13.3 |13.4
--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 13.3 is being released, retargeting bugs to GCC 13.4.
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2024-05-21 9:10 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-05 20:29 [Bug tree-optimization/99919] New: [9/10/11 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field msebor at gcc dot gnu.org
2021-04-05 20:51 ` [Bug tree-optimization/99919] " msebor at gcc dot gnu.org
2021-04-06 8:39 ` rguenth at gcc dot gnu.org
2021-04-08 14:22 ` rguenth at gcc dot gnu.org
2021-06-01 8:20 ` [Bug tree-optimization/99919] [9/10/11/12 " rguenth at gcc dot gnu.org
2021-11-30 11:58 ` aldyh at gcc dot gnu.org
2021-11-30 12:06 ` pinskia at gcc dot gnu.org
2021-11-30 14:22 ` aldyh at gcc dot gnu.org
2022-12-08 9:25 ` [Bug tree-optimization/99919] [10/11/12/13 " rguenth at gcc dot gnu.org
2022-12-08 10:47 ` rguenth at gcc dot gnu.org
2023-04-26 6:55 ` [Bug tree-optimization/99919] [10/11/12/13/14 " rguenth at gcc dot gnu.org
2023-07-27 9:22 ` [Bug tree-optimization/99919] [11/12/13/14 " rguenth at gcc dot gnu.org
2023-12-15 13:33 ` rguenth at gcc dot gnu.org
2024-05-21 9:10 ` [Bug tree-optimization/99919] [11/12/13/14/15 " jakub at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).