Jeff, Thank you for your quick response!
Yes, I have a custom ISA. I am building a custom back end. The project, in its current state, can be found at: http://opencores.com/project,zipcpu Can you tell me whether the difference between CC0 processing and non-CC0 processing is a GCC difference or a target ISA difference? Thanks, Dan On Mon, 2016-04-04 at 14:42 -0600, Jeff Law wrote: > On 04/04/2016 02:19 PM, Dan wrote: > > Greetings! > > > > GCC is usually so perfect, that I hate to write, but ... I think I'm > > chasing down quite the bug in it and would appreciate some thought to > > the following. > > > > The code that causes the bug looks like: > > > > if (ptr) { > > *ptr = 1; > > } > > > > This code evaluates, in the instruction set I am working with, into the > > following RTL: > > > > (set (cc0) (compare (reg 3) (reg 1))) > > (set (pc) (if-then-else (eq (cc0) (const_int 0)) (label_ref 258) (pc))) > > (set (mem (reg 3)) (reg 1)) > > > > (all modes are SI) > > > > This would be all fine and dandy, up until the if_convert modifications. > > if_convert() rightly decides that the store instruction is prime for a > > conditional execution conversion. Therefore, if_convert() transforms > > this code into: > > > > (cond_exec (ne (cc0) (const_int 0)) (set (mem (reg 3)) (reg 1))) > > > > This, by itself, is a valid conversion. > > > > The problem is that when cond_exec_process_if_block calls > > merge_if_block(ce_info) to package up the changes and make them > > permanent, merge_if_block then calls merge_block which deletes not only > > the conditional jump statement (set (pc) ... etc.), but also the compare > > that set the conditions prior to the jump statement (see > > rtl_merge_blocks within cfgrtl.c). Hence instead of the working RTL, > > > > (set (cc0) (compare (reg 3) (reg 1))) > > (cond_exec (ne (cc0) (const_int 0)) (set (mem (reg 3)) (reg 1))) > > > > I'm left with the broken RTL: > > > > (cond_exec (ne (cc0) (const_int 0)) (set (mem (reg 3)) (reg 1))) > > > > > > Can someone tell me if I am missing something, or whether this really is > > a bug in GCC? > It's a bug in GCC. I don't think we currently have any targets that use > cc0 and conditional execution, thus other targets aren't stumbling over > this problem. > > It sounds like you've got a custom ISA and thus a custom GCC backend. I > would strongly recommend against using cc0 in your backend. cc0 is an > old deprecated way to express condition code handling. > > > Jeff
