[Bug c++/103825] ICE on switch on enum class in bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103825 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Marek Polacek --- Fixed for 14/13.
[Bug c++/103825] ICE on switch on enum class in bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103825
--- Comment #5 from GCC Commits ---
The releases/gcc-13 branch has been updated by Marek Polacek
:
https://gcc.gnu.org/g:22510e4a68aa9ca850db34ae62c21c58442d8ab3
commit r13-8560-g22510e4a68aa9ca850db34ae62c21c58442d8ab3
Author: Marek Polacek
Date: Fri Mar 29 16:59:37 2024 -0400
c++: ICE with scoped enum in switch condition [PR103825]
Here we ICE when gimplifying
enum class Type { Pawn };
struct Piece {
Type type : 4;
};
void foo() {
switch (Piece().type)
case Type::Pawn:;
}
because we ended up with TYPE_PRECISION (cond) < TYPE_PRECISION (case).
That's because the case expr type here is the unlowered type Type,
whereas the conditional's type is the lowered . This
is not supposed to happen: see the comment in pop_switch around the
is_bitfield_expr_with_lowered_type check.
But here we did not revert to the lowered SWITCH_STMT_TYPE, because
the conditional contains a TARGET_EXPR, which has side-effects, which
means that finish_switch_cond -> maybe_cleanup_point_expr wraps it
in a CLEANUP_POINT_EXPR. And is_bitfield_expr_with_lowered_type does
not see through those.
PR c++/103825
gcc/cp/ChangeLog:
* typeck.cc (is_bitfield_expr_with_lowered_type): Handle
CLEANUP_POINT_EXPR.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/enum44.C: New test.
(cherry picked from commit daa2e7c7ffe49b788357f7f2c9ef1c9b125c1f8c)
[Bug c++/103825] ICE on switch on enum class in bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103825
--- Comment #4 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:daa2e7c7ffe49b788357f7f2c9ef1c9b125c1f8c
commit r14-9758-gdaa2e7c7ffe49b788357f7f2c9ef1c9b125c1f8c
Author: Marek Polacek
Date: Fri Mar 29 16:59:37 2024 -0400
c++: ICE with scoped enum in switch condition [PR103825]
Here we ICE when gimplifying
enum class Type { Pawn };
struct Piece {
Type type : 4;
};
void foo() {
switch (Piece().type)
case Type::Pawn:;
}
because we ended up with TYPE_PRECISION (cond) < TYPE_PRECISION (case).
That's because the case expr type here is the unlowered type Type,
whereas the conditional's type is the lowered . This
is not supposed to happen: see the comment in pop_switch around the
is_bitfield_expr_with_lowered_type check.
But here we did not revert to the lowered SWITCH_STMT_TYPE, because
the conditional contains a TARGET_EXPR, which has side-effects, which
means that finish_switch_cond -> maybe_cleanup_point_expr wraps it
in a CLEANUP_POINT_EXPR. And is_bitfield_expr_with_lowered_type does
not see through those.
PR c++/103825
gcc/cp/ChangeLog:
* typeck.cc (is_bitfield_expr_with_lowered_type): Handle
CLEANUP_POINT_EXPR.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/enum44.C: New test.
[Bug c++/103825] ICE on switch on enum class in bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103825 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- Started with r5-3726-g083e891e69429f, so mine. commit 083e891e69429f93b958f6c18e2d52f515bae572 Author: Marek Polacek Date: Wed Sep 24 17:23:56 2014 + re PR c/61405 (Not emitting "enumeration value not handled in switch" warning for bit-field enums)
[Bug c++/103825] ICE on switch on enum class in bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103825 Andrew Pinski changed: What|Removed |Added CC||Alexandre.BUSTICO at enac dot fr --- Comment #2 from Andrew Pinski --- *** Bug 114451 has been marked as a duplicate of this bug. ***
[Bug c++/103825] ICE on switch on enum class in bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103825 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-12-25 Status|UNCONFIRMED |NEW See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=98043 --- Comment #1 from Andrew Pinski --- Confirmed, the ICE is not a regression or rather it is hard to tell if it is a regression or not just using godbolt as it even ICEs in GCC 6.1.0 with -fchecking, GCC 5 didn't have -fchecking.
