[Bug fortran/97345] FE passes do_subscript leaks gmp memory

2023-01-10 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97345

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org
   Target Milestone|--- |13.0

--- Comment #7 from anlauf at gcc dot gnu.org ---
Should be fixed for gcc-13.  Closing.

Thanks for the report!

[Bug fortran/97345] FE passes do_subscript leaks gmp memory

2023-01-10 Thread sgk at troutmask dot apl.washington.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97345

--- Comment #6 from Steve Kargl  ---
On Tue, Jan 10, 2023 at 09:50:08PM +, cvs-commit at gcc dot gnu.org wrote:
> 
> --- Comment #5 from CVS Commits  ---
> The master branch has been updated by Harald Anlauf :
> 
> https://gcc.gnu.org/g:fec9fc1a17ec44461cee841513f1b6b8ad680fe4
> 
> commit r13-5095-gfec9fc1a17ec44461cee841513f1b6b8ad680fe4
> Author: Harald Anlauf 
> Date:   Tue Jan 10 22:41:17 2023 +0100
> 
> Fortran: frontend passes do_subscript leaks gmp memory [PR97345]
> 
> gcc/fortran/ChangeLog:
> 
> PR fortran/97345
> * frontend-passes.cc (do_subscript): Clear used gmp variables.
> 

Thanks for taking care of this one.  Sorry I got sidetracked.

[Bug fortran/97345] FE passes do_subscript leaks gmp memory

2023-01-10 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97345

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:fec9fc1a17ec44461cee841513f1b6b8ad680fe4

commit r13-5095-gfec9fc1a17ec44461cee841513f1b6b8ad680fe4
Author: Harald Anlauf 
Date:   Tue Jan 10 22:41:17 2023 +0100

Fortran: frontend passes do_subscript leaks gmp memory [PR97345]

gcc/fortran/ChangeLog:

PR fortran/97345
* frontend-passes.cc (do_subscript): Clear used gmp variables.

[Bug fortran/97345] FE passes do_subscript leaks gmp memory

2023-01-10 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97345

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #3)
> (In reply to anlauf from comment #2)
> > +
> > + mpz_clear (do_start);
> > + mpz_clear (do_end);
> > + mpz_clear (do_step);
> > }
> 
> Harald, when I was looking at this PR, I came to the conclusion that only
> do_step needs to be cleared.  I think the do_start and do_end get hooked
> into an iterator, but don't remember the details.  I got sidetracked on the
> the broken valgrind utilities I have on FreeBSD.

The above is almost correct; the clearing of do_start and do_end does need to
be protected by if (have_do_...).  Otherwise regtesting goes sideways... :-O

> I don't think a test case is needed if you use valgrind to verify that the
> memory leaks are gone.  Sure, there are enough do-loop tests already present
> in the testsuite that will fail if the patch goes left.

Indeed!

[Bug fortran/97345] FE passes do_subscript leaks gmp memory

2023-01-10 Thread kargl at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97345

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #2)
> +
> +   mpz_clear (do_start);
> +   mpz_clear (do_end);
> +   mpz_clear (do_step);
>   }

Harald, when I was looking at this PR, I came to the conclusion that only
do_step needs to be cleared.  I think the do_start and do_end get hooked into
an iterator, but don't remember the details.  I got sidetracked on the the
broken valgrind utilities I have on FreeBSD.

I don't think a test case is needed if you use valgrind to verify that the
memory leaks are gone.  Sure, there are enough do-loop tests already present in
the testsuite that will fail if the patch goes left.

[Bug fortran/97345] FE passes do_subscript leaks gmp memory

2023-01-10 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97345

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
Visual inspection of function do_subscript() suggests the following patch:

diff --git a/gcc/fortran/frontend-passes.cc b/gcc/fortran/frontend-passes.cc
index 612c12d233d..6731de64539 100644
--- a/gcc/fortran/frontend-passes.cc
+++ b/gcc/fortran/frontend-passes.cc
@@ -2892,7 +2892,12 @@ do_subscript (gfc_expr **e)

  cmp = mpz_cmp (do_end, do_start);
  if ((sgn > 0 && cmp < 0) || (sgn < 0 && cmp > 0))
-   break;
+   {
+ mpz_clear (do_start);
+ mpz_clear (do_end);
+ mpz_clear (do_step);
+ break;
+   }
}

  /* May have to correct the end value if the step does not equal
@@ -2965,6 +2970,10 @@ do_subscript (gfc_expr **e)
  mpz_clear (val);
}
}
+
+ mpz_clear (do_start);
+ mpz_clear (do_end);
+ mpz_clear (do_step);
}
}
 }

Can this be committed without a testcase after regtesting?
Or how should a testcase look like?

[Bug fortran/97345] FE passes do_subscript leaks gmp memory

2022-12-17 Thread kargl at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97345

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Richard Biener from comment #0)
> ==15138== 8 bytes in 1 blocks are definitely lost in loss record 5 of 742
> ==15138==at 0x4C2E2DF: malloc (in
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==15138==by 0x568C698: __gmp_default_allocate (in
> /usr/lib64/libgmp.so.10.3.2)
> ==15138==by 0x569CA22: __gmpz_init_set (in /usr/lib64/libgmp.so.10.3.2)
> ==15138==by 0xC04033: do_subscript(gfc_expr**) (frontend-passes.c:2861)
> ==15138==by 0xC03C58: do_function(gfc_expr**, int*, void*)
> (frontend-passes.c:2699)
> ==15138==by 0xC0A1CD: gfc_expr_walker(gfc_expr**, int (*)(gfc_expr**,
> int*, void*), void*) (frontend-passes.c:5189)
> 
> the code is doing mpz_init_set (...) but no where freeing the memory
> associated with mpz_t do_start, do_step, do_end

While I can find reporting of the above, I see  

%  valgrind -s ~/work/libexec/gcc/x86_64-unknown-freebsd14.0/13.0.0/f951 a.f90
...
==46939== 183 errors in context 102 of 102:
==46939== Mismatched free() / delete / delete []
==46939==at 0x484F55C: operator delete[](void*) (in
/usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==46939==by 0xADF6E2: (anonymous namespace)::dom_info::~dom_info()
(dominance.cc:284)
==46939==by 0xAE127C: verify_dominators(cdi_direction) (dominance.cc:1185)
==46939==by 0xA76D5C: verify_loop_structure() (cfgloop.cc:1419)
==46939==by 0xD85B64: checking_verify_loop_structure (cfgloop.h:646)
==46939==by 0xD85B64: loop_optimizer_init(unsigned int) (loop-init.cc:130)
==46939==by 0xF9C25E: execute_build_cfg (tree-cfg.cc:382)
==46939==by 0xF9C25E: (anonymous
namespace)::pass_build_cfg::execute(function*) (tree-cfg.cc:412)
==46939==by 0xE6C281: execute_one_pass(opt_pass*) (passes.cc:2644)
==46939==by 0xE6CBA7: execute_pass_list_1(opt_pass*) (passes.cc:2753)
==46939==by 0xE6CBF0: execute_pass_list(function*, opt_pass*)
(passes.cc:2764)
==46939==by 0xAA9863: cgraph_node::analyze() (cgraphunit.cc:686)
==46939==by 0xAAC597: analyze_functions(bool) (cgraphunit.cc:1240)
==46939==by 0xAAD2D5: symbol_table::finalize_compilation_unit()
(cgraphunit.cc:2514)
==46939==  Address 0x5d4e6a0 is 0 bytes inside a block of size 56 alloc'd
==46939==at 0x484D064: operator new(unsigned long) (in
/usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==46939==by 0xADFBF9: new_zero_array (dominance.cc:153)
==46939==by 0xADFBF9: (anonymous namespace)::dom_info::dom_init()
(dominance.cc:166)
==46939==by 0xADFD18: (anonymous namespace)::dom_info::dom_info(function*,
cdi_direction) (dominance.cc:195)
==46939==by 0xAE11AC: verify_dominators(cdi_direction) (dominance.cc:1159)
==46939==by 0xA76D5C: verify_loop_structure() (cfgloop.cc:1419)
==46939==by 0xD85B64: checking_verify_loop_structure (cfgloop.h:646)
==46939==by 0xD85B64: loop_optimizer_init(unsigned int) (loop-init.cc:130)
==46939==by 0xF9C25E: execute_build_cfg (tree-cfg.cc:382)
==46939==by 0xF9C25E: (anonymous
namespace)::pass_build_cfg::execute(function*) (tree-cfg.cc:412)
==46939==by 0xE6C281: execute_one_pass(opt_pass*) (passes.cc:2644)
==46939==by 0xE6CBA7: execute_pass_list_1(opt_pass*) (passes.cc:2753)
==46939==by 0xE6CBF0: execute_pass_list(function*, opt_pass*)
(passes.cc:2764)
==46939==by 0xAA9863: cgraph_node::analyze() (cgraphunit.cc:686)
==46939==by 0xAAC597: analyze_functions(bool) (cgraphunit.cc:1240)
==46939== 
==46939== ERROR SUMMARY: 2511 errors from 102 contexts (suppressed: 0 from 0)

[Bug fortran/97345] FE passes do_subscript leaks gmp memory

2021-04-16 Thread tkoenig at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97345

Thomas Koenig  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Assignee|tkoenig at gcc dot gnu.org |unassigned at gcc dot 
gnu.org

[Bug fortran/97345] FE passes do_subscript leaks gmp memory

2021-01-25 Thread tkoenig at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97345

Thomas Koenig  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2021-01-25
 Status|UNCONFIRMED |ASSIGNED