https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42972
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42972
Steven Bosscher changed:
What|Removed |Added
Last reconfirmed|2012-03-18 12:45:53 |2019-3-6
--- Comment #7 from Steven Bo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42972
Steven Bosscher changed:
What|Removed |Added
Target|arm-elf |arm-eabi
Last reconfirmed|2010-02-05
--- Comment #5 from matz at gcc dot gnu dot org 2010-02-05 15:36 ---
The code for the if() looks sane on x86-64:
-
;; if (D.2729_8 != 0)
(insn 16 15 17 pr42972.c:10 (set (reg:QI 87)
(mem/s:QI (reg/f:DI 82 [ D.2727 ]) [0 S1 A32])) -1 (nil))
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-02-05 13:25 ---
(In reply to comment #1)
> In the .expand dump there is already something funny about the code generated
> for the bit field expressions.
>
> For example the code generated for this:
> D.1966_8 = D.1965_7 & 1;
>
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-02-05 13:17 ---
On the (retired) mem-ref branch bitfield loads/stores were lowered very early
to read-extract-modify-write operations so the tree level would have optimized
this.
But of course people complained that architectures t
--- Comment #2 from steven at gcc dot gnu dot org 2010-02-05 12:45 ---
This is both a tree-optimization and an rtl-optimization problem, so setting
component to "middle-end" (there is no generic "optimization" component
anymore).
--
steven at gcc dot gnu dot org changed:
