On Fri, 8 Apr 2016, Jake Hamby wrote: > Thanks for the info! I've discovered a few additional clues which should > help, namely the optimizer pass that's introducing the problem. Through > process of elimination, I discovered that adding "-fno-tree-ter" will > prevent the unrecognizable insn error. Strangely, I can't cause the > problem by using "-ftree-ter" and -O0, which seems odd, unless the code > is checking directly for a -O flag.
You can't turn most optimisations on at -O0, you need to globally enable optimisation in the first place -- any -O setting will do, e.g. -O, -Os, etc., as per the GCC manual: "Most optimizations are only enabled if an `-O' level is set on the command line. Otherwise they are disabled, even if individual optimization flags are specified." So to enable a single optimisation only you'll have to use e.g. -O combined with a list of negated -f options to disable this level's optimisation defaults. Yes, I agree this sounds like an awkward UI; I guess it dates back to GCC's early days and nobody bothered to fix it. Maybe we need -Onone or suchlike. > I'll continue to clean up the diffs that I've been working on, and send > out something when I've made more progress. I like the "cc" attr code > that I've added to fix the overaggressive elimination of CC0 tests, but > the problem is that now it's too conservative, because many insns are > defined as calls into C code which may or may not generate insns that > set the condition codes. I have a few ideas on how to clean up and > refactor that code, but first I had to convince myself that most of > what's in there now are actually useful optimizations, and they seem to > be. Good luck! > Thanks for the help! You are welcome! Maciej