On 06/12/2018 03:16 PM, David Malcolm wrote: > On Tue, 2018-06-12 at 14:50 -0600, Jeff Law wrote: > > Ultimately these boil down to: > > gcc_checking_assert (INSN_P (rt) > || NOTE_P (rt) > || JUMP_TABLE_DATA_P (rt) > || BARRIER_P (rt) > || LABEL_P (rt)); > > (with an "if (rt)" for the safe_a_a variant), and hence they're runtime > checks (and only enabled when #if CHECKING_P). Ack.
> >> Obviously your testing ought to be sufficient for the >> former. Mine will help with the latter since it'll build arc, bfin >> and >> c6x elf targets through newlib. For sh it'll build a mixture of -elf >> things through newlib and it'll bootstrap sh4. > > Is this testing something that you've already triggered, or does it > happen upon commit to trunk? THe jobs poll the various relevant git servers (gcc, binutils, newlib, glibc, linux kernel) once per day . When a change is detected in any of the repos a full build is started. > > (The sh changes are the only aspect of this kit that I'm keen for > review/testing of, as it needed extra casts; I *think* everywhere I > added them are places where rtx are already being unconditionally > treated as instruction nodes, but your eyes/testing would be helpful). They looked reasonable to me. Thankfully sh is one that we can actually bootstrap GCC within a chroot using qemu, so it'll get fairly extensive testing. It takes ~8hrs, but that's not too bad :-) jeff
