Re: pointer components and memory leaks

On Sep 16, 4:02 pm, nos...@xxxxxxxxxxxxx (Richard Maine) wrote:
rusi_pathan <tabrez...@xxxxxxxxx> 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

Apologies for blaming it on the compiler so quickly. I was under the
impression that the compiler should somehow take care of deallocating
the 'z' after the result has been passed to main.

Also the code given in the first post doesnt leak memory when compiled
with IFC 7.1 but does leak it with compiled with IFC 10.015 and
gfortran 4.1.2.
.

Relevant Pages

  • Re: pointer components and memory leaks
    ... that's the same thing as what Paul said. ... Let's not suggest compiler bug every time one finds a problem. ... leak memory, though even there, user bugs in other parts of the code can ...
    (comp.lang.fortran)
  • Re: Really wierd bug
    ... > it has to be a compiler bug because it works fine for other population ... > My compiler is Compaq Visual Fortran 1997-1999. ... > with allocating the array sizes because I've defined the arrays as ... your program does indeed contain an array bounds error -- this ...
    (comp.lang.fortran)
  • Re: Questions in Optimization !!
    ... that the problem is absolutely, positively not a compiler bug, because ... "But it works as long as I don't use optimization! ... resulting in stack corruption ...
    (comp.os.vxworks)
  • Re: mutex question
    ... This is not a compiler bug -- this is a code bug. ... use 'volatile' on variables shared between threads. ... Memory barriers, not volatile, are the correct mechanism to force updating of variables between threads. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Wrong optimisation in Visual C++.net Release Build
    ... > It's not a compiler bug; it's bad code that relies on undefined behavior. ... The program in question does not invoke undefined behavior. ... The C++ standard is very clear that evaluation order is not ...
    (microsoft.public.vc.language)
Loading