> rusi_pathan gmail.com> wrote:

>> Correct me if I am wrong but isnt 'z%%x' in tt_sum being lost here?

>
> Yes, that's the same thing as what Paul said. Perhaps you are looking at
> the variable from different perspectives. It is "created" as the z in
> tt_sum and then used as the x in tt_def that Paul mentioned. But its the
> same thing.
>

>> Also isnt this more like a compiler bug?

>
> Let's not suggest compiler bug every time one finds a problem. While
> compilers have been known to have bugs, those people who first think
> compiler bug every time they see something wrong don't tend to do a very
> good job of debugging... because they too quickly stop looking for their
> own bugs, which are where most bugs are, after all. Calling "compiler
> bug" too quickly is a habit that often has to be "beat out" of new
> users. There sometimes seems to be an inverse correlation in that the
> people who most often suggest they have found compiler bugs are the
> people least likely to have actually done so.
>
> Do you have any actual basis for the suggestion other than that
> something undesireable happened so it must be a compiler bug? Perhaps do
> you see somewhere that the compiler is supposed to have done something
> differently? Or do you have some basis to believe that a correct
> compilation of the code can't leak memory and therefore the compilation
> must be wrong? (For example, allocatables aren't supposed to be able to
> leak memory, though even there, user bugs in other parts of the code can
> have symptoms that show up in allocatables.)
>
> I suggest that the answer to all of those is "no". Pointer stuff like
> this is notorious for memory leaks. Furthermore, the memory leak in this
> one can be quickly spotted by hand, without even resorting to a
> compiler. No, it isn't a compiler bug.
>
> --
> Richard Maine | Good judgement comes from experience;
> email: last name at domain . net | experience comes from bad judgement.
> domain: summertriangle | -- Mark Twain