RE: Intergraph CLIPPER bug...

["Mackinlay, Patrick" <patrick dot mackinlay at kjv dot com dot au>]

> > Obviously, r1 cannot be used both as the source address pointer and the
> > register holding the data value.
> 
> Does this happen in top of tree.  If not, we'll recommend you upgrade
> now, rather than later, and help you with it instead.

I'm sure that it would, considering the CLIPPER port hasn't been played with
for a long while...

> > Can someone explain to me more about how these constructs in the .md
> > file work
> 
> Did you read the 500+ page book that describes this in detail
> (http://gcc.gnu.org/)?

I was hoping someone who was already experienced with the software could
help me out. I'm not really in this to become a GCC guru, I just want the
existing CLIPPER port to be brought up to a running state, and I'm doing my
best to learn what I need to know along the way to achieve that. It seems to
me that there's a very minor problem somewhere in that section of the code
that's preventing the compiler from allocating an additional register as
required, and I'm reasonably confident that an experienced gcc developer
could probably see by inspection what the issue is.

If I don't get any tips from anyone, I'll have to take the long way around
and work it out myself <sigh>.

> > I'm using gcc-2.95.3 for the moment, and once I have it building
> > valid CLIPPER code, I'll start afresh with a current gcc snapshot
> > (probably 3.0.2 by the time I get there).

> Hum, I probably would not recommend this.  I'd start with top of tree,
> or if you want to be very conservative, 3.0.x.

My main reason for not doing this is that my system has no network (hence no
NFS), and a 14 character file system limitation. This makes building 3.x a
problem for me right now. I still believe 2.95.3 is my best bet for early
success. Once I know what needs to be changed to make 2.95.3 work, I'll be
on a fast-track to fixing the same (CLIPPER-specific) things in 3.x.

Thanks for your response.

Regards,
Pat Mackinlay