https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
--- Comment #19 from CVS Commits ---
The releases/gcc-11 branch has been updated by Eric Botcazou
:
https://gcc.gnu.org/g:01e80c4c630a5a6286a521b047d0ef80631c892c
commit r11-10463-g01e80c4c630a5a6286a521b047d0ef80631c892c
Author: Eric Botcazou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
--- Comment #18 from CVS Commits ---
The releases/gcc-12 branch has been updated by Eric Botcazou
:
https://gcc.gnu.org/g:eec3a65ed638a1c58fa08ddf508d2d60b64d311d
commit r12-9041-geec3a65ed638a1c58fa08ddf508d2d60b64d311d
Author: Eric Botcazou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
Eric Botcazou changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
Andreas Krebbel changed:
What|Removed |Added
Version|13.0|12.2.1
--- Comment #16 from Andreas K
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
Andreas Krebbel changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
--- Comment #14 from CVS Commits ---
The master branch has been updated by Eric Botcazou :
https://gcc.gnu.org/g:3e1cba12a8d71e70235a9a9b8f1a237a561db3e7
commit r13-5109-g3e1cba12a8d71e70235a9a9b8f1a237a561db3e7
Author: Eric Botcazou
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
Eric Botcazou changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
--- Comment #12 from Eric Botcazou ---
> How are the bits numbered in there, IOW is bit 0 always the LSB or not?
Answering to myself: no, they are numbered in memory order, which is
problematic because, in the implementation model, stand-alone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
--- Comment #11 from Eric Botcazou ---
> Here is a testcase for the trunk on x86_64-linux-gnu:
Thanks. The problem is indeed the BIT_FIELD_REF of a scalar, which is an
undocumented extension of GENERIC:
/* Reference to a group of bits within
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #10 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
Eric Botcazou changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #9 from Eric Botcaz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
Richard Biener changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
--- Comment #7 from Andreas Krebbel ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Andreas Krebbel from comment #5)
> > In:
> >
> > _1 = src_6(D)->a;
> > dst$val_9 = _1;
> > _2 = BIT_FIELD_REF ;
> > _3 = _2 & 64;
> > i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
--- Comment #6 from Andrew Pinski ---
(In reply to Andreas Krebbel from comment #5)
> In:
>
> _1 = src_6(D)->a;
> dst$val_9 = _1;
> _2 = BIT_FIELD_REF ;
> _3 = _2 & 64;
> if (_3 != 0)
There is only 2 accesses going on in the above IR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
--- Comment #5 from Andreas Krebbel ---
In:
_1 = src_6(D)->a;
dst$val_9 = _1;
_2 = BIT_FIELD_REF ;
_3 = _2 & 64;
if (_3 != 0)
src, dst and the BIT_FIELD_REF carry storage order flags which result in either
bswaps being emitted or, in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-12-22
Summary|Bitfields
17 matches
Mail list logo
