Phillip Helbig wrote:
>> In the one I commented on, the error message reported was
>> "Panic: ...
>> Internal error, please report this bug"
>>
>> If that does not clearly indicate that is a bug I don't know what will!
>
>I think we basically all agree here. As I pointed out that Richard
>Maine had pointed out, such a message is ALWAYS a bug in some sense.
>However, it does not mean that the ONLY problem is a bug in the
>compiler; there might be a bug in the code as well...
>
>> >I had several cases in the last 2 or 3 years, where it took me some
>> >time, and help from the contributors of this list, to decide whether
>> >a problem was a compiler bug or not.
>
>...thus the need, while the compiler bug is being investigated, to
>determine whether the code is non-standard. Of course, common things
>are well-tested; it is things on the edge of the standard---possibly
>requiring interpretations---which can cause trouble. Again, one can and
>should separate the two questions: compiler bug? standard code?
My experience when reporting a compiler failure is that my vendor (undoubtedly
as with Malcolm and others) investigates this PDQ. Although I am on the
opposite side of the world, I get an answer within less than 24 hours.
I prefer to get on with something else rather than try to interpret the
standard. My vendor usually tells me 1). we know the reason for the compiler
bug and (possibly) 2). you were doing .... non-standard. The bug then is that
the compiler should have reported a non-standard or erratic code practice.
Much as I learn from here and c.l.f, I do not see them as alternatives to my
vendor when their compiler bugchecks.
Incidentally, whilst I'm here, as with compiler vendors the NAG library support
staff are very expeditious at responding (if not giving work-arounds) to
problems with their code.
Regards Paddy (I've got a problem with my normal sig file at the moment).
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|