Re: m68k structure packing

[mrs@wrs.com (Mike Stump)]

> Date: Tue, 30 Sep 1997 23:05:48 -0600
> From: Jeffrey A Law <law@hurl.cygnus.com>

>   In message <199710010315.UAA28203@kankakee.wrs.com>you write:
>   > Don't know how.  All I can do it try a couple of testcases that should
>   > expose the tricky parts, I have done that.
> Read the docs for PCC_BITFIELD_MATTERS.

Sorry I have given the impression that I haven't read that, that isn't
the case.

> It describes a very particular problem (bitfields crossing certain
> alignment boundaries).

Yes.  Again, sorry I gave the impression that I didn't read, understand
and try the case discussed, as that isn't the case.

> It even includes code which attempts to set up this situation;

Yes...

> Then look at the resulting output

I must admit I didn't do that before because I didn't see that it
could offer any additional insight.  But, since you think it has some
relevance, I took a look at the output (and a few variations on it)
and I still don't see how it can offer any additional insight.  I did
see what I consider some additional minor nits... like padding at the
end when :0 is used, that we may want to go ahead and remove (padding
on a packed structure isn't desired or useful), and undesired
alignment when :0 is used, and because of the presence of the
undesired alignment, aligned loads and stores are generated, since the
data is aligned.  This, while it is a bug, won't cause codegen
problems, just incompatibilities if/when we fix that problem.

> and verify that you don't have any unaligned loads/stores.

Sorry I gave the impression that I haven't tested it, as that is not true.

> Doesn't seem all that hard to me.

Nor to me, as I I have already done all the testing that you seem to
imply.  Let me put it another way, I am to the point of happiness with
the code, that I don't know of any additional way to test it by hand.

> I think if you do that and can show Jim that it works then you'll
> both be happy.

Ah, now here is something I didn't do.  I have not shown you all all
the testcases I have looked at, nor all the resulting code...  I'll
see about putting together another mail message with all that you
request, but in general this isn't how I normally operate.  I normally
keep that level of detail to myself, and when the code is as I want,
then I submit the patches I've developed enmass.

I don't think we should force authors of code to prove to kenner that
a change is good enough for the FSF's compiler, and then force them to
go through the pain again to get it into the egcs compiler.  I think
we risk faster divergence that way, and keeping them converged is
better.  I thought that kenner would be generally be harder to deal
with, and while I may still generally think that is true, it wasn't in
this case.