🚀 go-pugleaf

>>       2.1
>>     makes it so that xdbx often thinks it can't proceed using "step" but
>>     if you have set an appropriate breakpoint then "cont" works.  Seems to
>>     me that 2.1 is not an improvement.
>
> I'm sad to hear this.  But what you are doing--posting vague
> grumbles that aren't useful--is not constructive criticism.
>
> If you care about getting this bug fixed, then you should do your
> share of the work: write a usable bug report that shows GCC
> maintainers what they need to know to find and fix the problem.
>

I agree, but haven't yet had time to write a useable bug report.  It's
my understanding that a useable bug report should consist of a
description of the problem, along with the simplest possible section
of code which generates it.  I will attempt to create such a section
of code and post a bug report early next week.

Meanwhile, I'm madly trying to finish off my thesis, so the best I
could do was to figure out a workaround, which I posted.  Since I have
seen no other messages yet about dbx problems, I wanted to reply to
this person's message to mention a specific problem that I had had and
a workaround.  The system operators here installed 2.1 without
mentioning that they had done so, with the result that I was not
longer able to debug my program at a critical time.  To me, that is
not an improvement--though it is probably more correct to say "not yet
an improvement".  I am prepared right now to post a

Non Bug Report:

My rather complex program (nearly 8000 lines of C code), which had
been developed under the most recent gcc 1.xx release, compiled under
gcc 2.1 and ran exactly as it should have done.  Compiling under gcc
2.1 did generate one more warning, about using "%lf", which helped me
eliminate a bad programming practice.  (I can't say that I notice any
particular speed increase or decrease, either in compilation or
runtime.  Unfortunately, I don't have any of the previous compiled
versions sitting around with which to compare.)

Thanks 

Nick