Coldfire Diffs

[Jeffrey A Law]

  In message <Pine.BSF.3.96.970919134654.21863C-100000@vespucci.advicom.net>Joel wrote:
  > 
  > Below my signature are some diffs from the win32 cdk which may or may not
  > be included in current egcs snapshots.  There are about 200 lines of diffs
  > to about 5 files.  I am pretty sure some are already included in egcs
  > snapshots.  
  > 
  > David Fiddes <D.J.Fiddes@hw.ac.uk> uses these to build a Coldfire toolset
  > he has been graciously distributing to those interested in the Coldfire. 
  > At my request, he sent these to me so I could try to helkp get them into
  > the egcs tree.
Unfortunately, the changes are in old-style diff format, which makes them
extremely difficult to read or apply.  So if my analysis is incorrect, it
may be due to not being able to 100% be sure exactly what patterns the
changes apply to.  It's also worth noting there are no testcases or explanation
of why the patches are needed, which makes it hard to analyze the changes.


What's the point behind the config-ml.in change?  Shouldn't that be handled
in the m68k target files?

Providing names to the various patterns may be useful, but isn't strictly
necessary as far as I can tell.  If you want to add names for them, please
prefix them with a "*" so as not to cause confusion with named patterns that
have a particular purpose.  Submit this as a separate patch since it is 
independent of coldfire support.

The one actual bugfix for the btst patterns is already in egcs.

I believe your change to the movqi pattern for the coldfire is incorrect
as we had it in our toolchain once and it was failing.  I think egcs has
a correct set of constraints for the movqi pattern on the coldfire.

I also believe your changes to movstrictqi have also been overtaken by
events and are no longer necessary.

Similarly for the XFmode move insn changes and jump table pattern changes.

We've also got the appropriate multilib changes for t-m68kbare.

So, basically I don't see anything in this patch that hasn't already been
addressed in the egcs sources.

So I guess the thing to do is for you to determine if egcs does the right
thing for the code which caused you to make the various changes to the m68k.md
file.  If egcs is still generating incorrect code we'll have to analyze it
further using whatever testcode is causing the compiler to generate incorrect
code.

Thanks,
jeff