https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
--- Comment #24 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #23)
> What would create those BIT_FIELD_REFs so early though? They should stay as
> COMPONENT_REFs.
I thought you'd never ask... why our friend fold_truth_andor_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
--- Comment #23 from Jakub Jelinek ---
What would create those BIT_FIELD_REFs so early though? They should stay as
COMPONENT_REFs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
Aldy Hernandez changed:
What|Removed |Added
Assignee|aldyh at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
Richard Biener changed:
What|Removed |Added
Target Milestone|7.3 |7.4
--- Comment #21 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
--- Comment #20 from Aldy Hernandez ---
Created attachment 43233
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43233=edit
WIP that fixes PR, but causes other regressions
I am attaching a proof of concept hack that fixes this PR by moving
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
--- Comment #19 from Jakub Jelinek ---
Testcase where in f1/f3/f5 this optimization is done early (already in
*.original dump), but in f2/f4/f6 is not.
struct S { unsigned a:5; unsigned b:3; unsigned c:2; };
void bar (void);
void
f1 (struct S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
--- Comment #18 from Jakub Jelinek ---
Note, it isn't just optimize_bit_field_compare, but also fold_truth_andor_1
that creates this stuff. Doing this at gimple might have best framework in the
reassoc pass, because you need to look through
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
--- Comment #17 from Jakub Jelinek ---
Sure, for working on GIMPLE the code needs to be adjusted. On the other side,
the advantage is that it will then be able to handle even cases that it
couldn't before.
Like right now it can handle:
struct S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
--- Comment #16 from Jeffrey A. Law ---
Well, my understanding of how other compilers have handled bitfields would
indicate that deferring optimization of them until later is advisable.
Essentially they pretended bitfields had word precision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
--- Comment #15 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #14)
> I think the easiest fix is move optimize_bit_field_compare from where it is
> currently done and do it only in some late gimple pass, around
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
--- Comment #14 from Jakub Jelinek ---
I think the easiest fix is move optimize_bit_field_compare from where it is
currently done and do it only in some late gimple pass, around
pass_fold_builtins/store merging or so? Dunno which exact one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
--- Comment #13 from Jeffrey A. Law ---
I realize the warnings are happening in VRP1. EVRP and VRP1 use different
styles of analysis and it can be the case that one is better suited for
cleaning things up than the other.
But I really should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
--- Comment #12 from Aldy Hernandez ---
The warning occurs in vrp1, not evrp, but for the record...
evrp dump:
tcp_chrono_set (struct tcp_sock * tp)
{
int type;
_1;
int _2;
unsigned char _3;
unsigned char _4;
:
_1 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
--- Comment #11 from Jeffrey A. Law ---
What do the dumps look like? In particular evrp & vrp1?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
--- Comment #10 from Aldy Hernandez ---
Further reduced testcase. Can be reproduced with -O2 -Wall.
struct tcp_sock {
int chrono_stat[3];
unsigned char chrono_type:2;
};
void tcp_chrono_set(struct tcp_sock *tp)
{
int type = 1;
if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
Richard Biener changed:
What|Removed |Added
Target Milestone|7.2 |7.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
Richard Biener changed:
What|Removed |Added
Target Milestone|7.2 |7.3
--- Comment #8 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
Richard Biener changed:
What|Removed |Added
Target Milestone|7.2 |7.3
--- Comment #8 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
--- Comment #6 from Patrick Palka ---
(In reply to Patrick Palka from comment #5)
> So what's the right way to fix this? To move optimize_bit_field_compare()
> from fold_binary to match.pd so that the conditions on
... so that conditions on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
--- Comment #5 from Patrick Palka ---
So what's the right way to fix this? To move optimize_bit_field_compare() from
fold_binary to match.pd so that the conditions on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
--- Comment #4 from Arnd Bergmann ---
Thanks for the analysis. I have now submitted a local workaround for the
kernel, adding a temporary variable to avoid accessing the bitfield twice, see
https://patchwork.kernel.org/patch/9869037/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
--- Comment #3 from Jakub Jelinek ---
The reason this doesn't trigger without -fsanitize= is that without the extra
UBSAN_* internal function calls we manage to find out earlier that this is a
dead code and optimize it away completely (during
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
--- Comment #2 from Jakub Jelinek ---
The -Warray-bounds warning has false positives, so you can run into them and in
that case using -Werror isn't really a good idea.
The problem is that the same bitfield, tp->chrono_start, is accessed 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
28 matches
Mail list logo
