This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: m68k structure packing
- To: egcs at cygnus dot com
- Subject: Re: m68k structure packing
- From: mrs at wrs dot com (Mike Stump)
- Date: Wed, 1 Oct 1997 12:15:29 -0700
> 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.