On Wed, 2012-07-18 at 18:30 +0100, Richard Sandiford wrote: > The abort sounds like the bug here. It's deliberate that things like > -msynci, -mbranch-likely, etc., are OK with -mips16. On the one hand, > you could compile with -mips16 but have an __attribute__((nomips16)) > function that could benefit from using SYNCI. On the other, you could > compile without -mips16 but have an __attribute__((mips16)) function > that needs to avoid SYNCI.
OK, I think that makes sense. > -mips16 really just sets the default ISA mode for functions that don't > specify one. That's why override_options hides mips16ness so early on, > like you say. Ah, I didn't really understand why we were hiding the -mips16 setting, now I do. I will see if I can figure out why we abort. The clear_cache insn in mips.md looks a bit odd to me, there is the part that is executed when TARGET_SYNCI is true and then a part that is only executed if mips_cache_flush_func is defined. It looks like if mips_cache_flush_func is not defined then we do nothing and I was wondering if that is correct or not? Should mips_cache_flush_func being NULL be an error? I am not even sure if you can make it NULL given that it is given a default value in mips.opt. My test case is: void f() { int size = 40; char *memory = __builtin_alloca(size); __builtin___clear_cache(memory, memory + size); } And the abort with -mips32r2 -mips16 -msynci is: x.c: In function âfâ: x.c:6:1: error: unrecognizable insn: } ^ (jump_insn 22 21 38 2 (set (pc) (if_then_else (eq (reg:SI 207) (reg/f:SI 196 [ D.1415 ])) (label_ref 33) (pc))) x.c:5 -1 (nil) -> 33) x.c:6:1: internal compiler error: in extract_insn, at recog.c:2129 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. If I can't figure out what is going on I will file a bug report. Steve Ellcey sell...@mips.com