https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93044
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93044
--- Comment #7 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:cc2003cd87532f319c94028f17d20a327df5ccfa
commit r14-2890-gcc2003cd87532f319c94028f17d20a327df5ccfa
Author: Andrew Pinski
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93044
--- Comment #6 from Andrew Pinski ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625379.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93044
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93044
--- Comment #4 from Andrew Pinski ---
(In reply to Richard Biener from comment #3)
> Indeed that seems to disallow this case. The condition is complicated
> enough to warrant extra care fiddling with it though ;)
The main reason why I filed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93044
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93044
--- Comment #2 from Marc Glisse ---
In match.pd
&& ((inter_unsignedp && inter_prec > inside_prec)
== (final_unsignedp && final_prec > inter_prec))
looks suspicious.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93044
--- Comment #1 from Andrew Pinski ---
Note this is the original testcase where I saw the issue (even without the
bit-field lowering pass; that I am working on):
#define N 100
#define M
struct S { int a : 3; int b : 17; int c : 12; };
struct
