Xref: utzoo comp.os.msdos.programmer:1344 comp.lang.c:32659 comp.misc:10299
Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!samsung!munnari.oz.au!bruce!alanf
From: alanf@bruce.cs.monash.OZ.AU (Alan Grant Finlay)
Newsgroups: comp.os.msdos.programmer,comp.lang.c,comp.misc
Subject: Re: Which C compiler: TC or MS? (200+ lines)
Keywords: C Compiler on PC, MIX, Power C, Compiler Bugs
Message-ID: <3161@bruce.cs.monash.OZ.AU>
Date: 6 Oct 90 13:15:32 GMT
References: <4641@feldspar30.UUCP> <151565@felix.UUCP> <1990Oct3.154752.6996@NCoast.ORG>
Distribution: comp.lang.c
Organization: Monash Uni. Computer Science, Australia
Lines: 34

In article <1990Oct3.154752.6996@NCoast.ORG>, catfood@NCoast.ORG (Mark W. Schumann) writes:
>    I've posted in the past my complaints about some cryptic error
>    messages coming out of the Power C compiler/optimizer phase.
>    Here's an example of what I'm talking about.  Perhaps someone
>    out there in net-land can help me out.  (Or we could establish

I think you will be lucky to get anyone to solve this for you.  You have 
included too much information.  My (and probably the standard) practice in
this sort of situation (an incomprehensible error message from a compiler) is
to use a divide and conquer approach.  If you think you know which module the
"error" is in then replace the other modules with stubs so we can be sure.
Now if the error is still there then start cutting the culprit module in half
until you have the minimal set of statements that still cause the "error"
message.  Usually by now you will have discovered what the problem is.  If
not try changing the names of any identifiers that might be given another
interpretation or even all the identifiers just in case.  If you still have 
an "error" then let us know.  In some cases this strategy does not work 
(for example there is a bug in the compiler which generates a "random" error
message when the 1024th source line is over 60 characters long).  The strategy
depends upon the fact that such bugs are not USUALLY very context dependent.
You cannot expect to generate the error message with just one segment of the
original - there is usually some context sensitive aspect.  Hence you 
eventually have to work very painstakingly - rather like digging up an
archeological relic.  When you finaly advertise a four line program that is
obviously correct and causes the message you can expect to get the implementor's
attention pretty quickly - such people are really quite proud of their work.

N.B. Have you tried an alternative compiler?  (Just in case!)
N.N.B. If your complaint is simply that you expect better error messages then
consider the following quotation: "Any fool can write a compiler for correct
programs" - J.S. Rohl.  It is really really hard to anticipate every form of
error in a source program and provide meaningfull diagnostics.  Consider
how lucky you are that your compiler doesn't just have 3 error messages like
some I have heard of.