| Message ID | 0f849537da2ed4ba59a53da920e3e0e6b1ea4f9c.1416885944.git.segher@kernel.crashing.org |
|---|---|
| State | New |
| Headers | show |
On 11/24/14 20:37, Segher Boessenkool wrote: > `lcc' is not an insn but just a pattern. This caused a build error in > libgcc. > Tested with a cross compiler build (which fails without and succeeds > with the patch). Not tested much more; this compiler really likes to > ICE, something with ipa-icf. > > Is this okay for trunk? > > > Segher > > > 2014-11-24 Segher Boessenkool <segher@kernel.crashing.org> > > gcc/ > * config/mn10300/mn10300.c (mn10300_insert_setlb_lcc): Remove > PATTERN call. OK. A good example of a case that would have been caught if we get to a point where stuff in the insn chain are not RTX objects, but something else entirely. jeff
On Tue, Nov 25, 2014 at 09:44:35AM -0700, Jeff Law wrote: > On 11/24/14 20:37, Segher Boessenkool wrote: > >`lcc' is not an insn but just a pattern. This caused a build error in > >libgcc. > A good example of a case that would have been caught if we get to a > point where stuff in the insn chain are not RTX objects, but something > else entirely. Hey, it already did ICE, easy to catch. But you mean "wouldn't even compile" I guess :-) Segher
On 11/25/14 10:14, Segher Boessenkool wrote: > On Tue, Nov 25, 2014 at 09:44:35AM -0700, Jeff Law wrote: >> On 11/24/14 20:37, Segher Boessenkool wrote: >>> `lcc' is not an insn but just a pattern. This caused a build error in >>> libgcc. > >> A good example of a case that would have been caught if we get to a >> point where stuff in the insn chain are not RTX objects, but something >> else entirely. > > Hey, it already did ICE, easy to catch. But you mean "wouldn't even > compile" I guess :-) Exactly. This kind of problem is something I want to catch at compile time rather than at runtime. jeff
On Tue, 2014-11-25 at 10:15 -0700, Jeff Law wrote: > On 11/25/14 10:14, Segher Boessenkool wrote: > > On Tue, Nov 25, 2014 at 09:44:35AM -0700, Jeff Law wrote: > >> On 11/24/14 20:37, Segher Boessenkool wrote: > >>> `lcc' is not an insn but just a pattern. This caused a build error in > >>> libgcc. > > > >> A good example of a case that would have been caught if we get to a > >> point where stuff in the insn chain are not RTX objects, but something > >> else entirely. > > > > Hey, it already did ICE, easy to catch. But you mean "wouldn't even > > compile" I guess :-) > Exactly. This kind of problem is something I want to catch at compile > time rather than at runtime. Right. FWIW I have a set of patches that converts PATTERN() to requiring a const rtx_insn * rather than a const_rtx, but so far they only compile on x86_64. Extending them to cover all archs would have caught this at compile time, I guess, since "lcc" would have been just an rtx. Presumably something for the next stage1.
diff --git a/gcc/config/mn10300/mn10300.c b/gcc/config/mn10300/mn10300.c index 20330f0..1fc64ed 100644 --- a/gcc/config/mn10300/mn10300.c +++ b/gcc/config/mn10300/mn10300.c @@ -3217,7 +3217,7 @@ mn10300_insert_setlb_lcc (rtx label, rtx branch) lcc = gen_Lcc (comparison, label); rtx_insn *jump = emit_jump_insn_before (lcc, branch); - mark_jump_label (XVECEXP (PATTERN (lcc), 0, 0), jump, 0); + mark_jump_label (XVECEXP (lcc, 0, 0), jump, 0); JUMP_LABEL (jump) = label; DUMP ("Replacing branch insn...", branch); DUMP ("... with Lcc insn:", jump);