Re: RFC: default insn length should be 1 but that breaks m68hc11and regresses mn10300.

[Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>]

> Date: Sun, 03 Apr 2005 21:30:02 +0200
> From: Stephane Carrez <stcarrez@nerim.fr>

> The m68hc11 port does not use the length attribute at all.
> I suspect the problem is present even without your patch.

That's what I meant.  It wouldn't be logical to depend on an
attribute that doesn't exist for your port. :-)

To wit: something is messing up the BB info, and the change in
generated code resulting from changing the default length to 1
is trigging it in a plain build.

If you and mn10300 maintainers could check on and fix these
supposedly latent bugs, I'm willing to go further with that
patch.  (But in response to Mark's comment, I'm not willing to
do that at the moment and not setting "length" to 0 for those
targets.)  A comment from the other non-"length"-attribute
target maintainers (specifically test results or general testing
thumbs-up) would help too.  (Even better a simulator in src/sim
and a committed newlib port, of course.)

> Concerning these bad validation results:
>  - There are several fixes in the reload pass which are necessary.
>  - Several tests must be fixed as they are not valid on a 16-bit target
>    (http://m68hc11.serveftp.org/m68hc11_src.php).

What about the nonexistent sim-valid.x script?

It's best if trunk GCC can be fixed, so people can
regression-test changes like mine against m68hc11-elf without
local changes.  Posting results for something else doesn't help.

> On gcc 3.3.5 and with the fixes,

Sorry, comparing against an old release branch isn't really
significant when the problems appear on trunk.

brgds, H-P