[Bug tree-optimization/18031] OR of a bitfield and a constant is not optimized at tree level

2009-06-08 Thread rguenth at gcc dot gnu dot org
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-06-08 15:40 --- Thus fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added

[Bug tree-optimization/18031] OR of a bitfield and a constant is not optimized at tree level

2009-06-07 Thread aldot at gcc dot gnu dot org
--- Comment #10 from aldot at gcc dot gnu dot org 2009-06-07 16:54 --- 4.3.3 does not simplify it, 4.4.0 onward do. for reference 4.3.3: Substituing values and folding statements Constants propagated: 0 Copies propagated: 0 Predicates folded: 0 ior (bD.1193) {

[Bug tree-optimization/18031] OR of a bitfield and a constant is not optimized at tree level

2006-10-24 Thread rguenth at gcc dot gnu dot org
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-10-24 13:07 --- We should at least fold b-bit = (unnamed type) (unsigned char) ((signed char) b-bit | 1); to b-bit = (unnamed type) ((signed char) b-bit | 1); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18031

[Bug tree-optimization/18031] OR of a bitfield and a constant is not optimized at tree level

2006-05-05 Thread pinskia at gcc dot gnu dot org
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-05-05 09:13 --- Here is a quick prototype addition for VRP, it does not handle the generic case only [0, 1] | 1: Index: tree-vrp.c === --- tree-vrp.c (revision

[Bug tree-optimization/18031] OR of a bitfield and a constant is not optimized at tree level

2006-04-27 Thread steven at gcc dot gnu dot org
--- Comment #5 from steven at gcc dot gnu dot org 2006-04-27 20:46 --- So I asked myself, why are we not catching this in vrp? I know we can derive ranges from types, so why don't we derive a [0,1] range from the bitfield load? It turns out that we make _all_ loads VARYING right away,

[Bug tree-optimization/18031] OR of a bitfield and a constant is not optimized at tree level

2006-04-27 Thread pinskia at gcc dot gnu dot org
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-04-27 21:14 --- (In reply to comment #5) So I asked myself, why are we not catching this in vrp? I know we can derive ranges from types, so why don't we derive a [0,1] range from the bitfield load? D.1883_4: [0, 1]

[Bug tree-optimization/18031] OR of a bitfield and a constant is not optimized at tree level

2006-04-27 Thread steven at gcc dot gnu dot org
--- Comment #7 from steven at gcc dot gnu dot org 2006-04-27 21:32 --- Yes, BIT_IOR_EXPR is also not handled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18031

[Bug tree-optimization/18031] OR of a bitfield and a constant is not optimized at tree level

2005-06-24 Thread pinskia at gcc dot gnu dot org
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-24 20:16 --- I think this is now fixed on the mainline at the RTL level: ior: movl4(%esp), %eax orb $1, (%eax) ret -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18031

[Bug tree-optimization/18031] OR of a bitfield and a constant is not optimized at tree level

2005-02-06 Thread pinskia at gcc dot gnu dot org
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-07 05:55 --- For the RTL level (at least on PPC), we could combine the following instructions and simplify them: (insn 15 13 16 0 (set (reg:SI 124) (const_int 1 [0x1])) 293 {*movsi_internal1} (nil) (nil))

[Bug tree-optimization/18031] OR of a bitfield and a constant is not optimized at tree level

2005-01-14 Thread pinskia at gcc dot gnu dot org
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-15 05:31 --- Well or just fold being fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18031

[Bug tree-optimization/18031] OR of a bitfield and a constant is not optimized at tree level

2004-10-16 Thread pinskia at gcc dot gnu dot org
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-16 13:57 --- Confirmed, this needs a tree combiner. -- What|Removed |Added