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
