Re: [Patch, Fortran] PR 86935: Bad locus in ASSOCIATE statement
AFAICS current trunk still has this issue.
Any takers?
thanks,
On Sun, 2 Sep 2018 17:16:07 +0200
Bernhard Reutner-Fischer wrote:
>i spotted one
> (pre-existing) possible inconsistency that i did overlook back then:
>
> gfc_match_associate () reads
> ...
> if (gfc_match (" %e", &newAssoc->target) != MATCH_YES)
> {
> /* Have another go, allowing for procedure pointer selectors. */
> gfc_matching_procptr_assignment = 1;
> if (gfc_match (" %e", &newAssoc->target) != MATCH_YES)
> {
> gfc_error ("Invalid association target at %C");
> goto assocListError;
> }
> gfc_matching_procptr_assignment = 0;
> }
>
> i.e. we retry a match, but in the second attempt we turn on procptr
> assignment matching and if that works, we turn procptr assignment
> matching off again.
> But if we fail that retry, we forget to turn it off again.
> I suppose we should:
>
> $ svn diff -x -p gcc/fortran/match.c
> Index: gcc/fortran/match.c
> ===
> --- gcc/fortran/match.c (revision 264040)
> +++ gcc/fortran/match.c (working copy)
> @@ -1898,13 +1898,16 @@ gfc_match_associate (void)
>if (gfc_match (" %e", &newAssoc->target) != MATCH_YES)
> {
> /* Have another go, allowing for procedure pointer selectors. */
> + match m;
> +
> gfc_matching_procptr_assignment = 1;
> - if (gfc_match (" %e", &newAssoc->target) != MATCH_YES)
> + m = gfc_match (" %e", &newAssoc->target);
> + gfc_matching_procptr_assignment = 0;
> + if (m != MATCH_YES)
> {
> gfc_error ("Invalid association target at %C");
> goto assocListError;
> }
> - gfc_matching_procptr_assignment = 0;
> }
>newAssoc->where = gfc_current_locus;
>
>
> Untested. Maybe someone wants to give it a whirl...
> If it wrecks havoc then leaving it set deliberately deserves at least a
> comment.
>
> PS: It would be nice to get rid of gfc_matching_procptr_assignment,
> gfc_matching_ptr_assignment, gfc_matching_prefix, FWIW.
> cheers,
> >
> > Thanks everyone!
> >
> > Cheers,
> > Janus
[PATCH] PR fortran/69419 - ICE: tree check: expected array_type, have real_type in gfc_conv_array_initializer, at fortran/trans-array.c:5618
Dear Fortranners,
when debugging the testcase, I noticed that a coarray declaration in
a COMMON statement wrongly set the dimension attribute instead of the
codimension. As a consequence, subsequent checks that catch this
invalid situation would not trigger.
I see two possible solutions:
- in gfc_match_common, replace
/* Deal with an optional array specification after the
symbol name. */
m = gfc_match_array_spec (&as, true, true);
by
m = gfc_match_array_spec (&as, true, false);
which in turn would lead to a syntax error. Interestingly, the Intel
compiler also takes this route and gives a syntax error.
- check the resulting as->corank and emit an error as in the attached
patch.
The attached patch regtests fine on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
Fortran: a symbol in a COMMON cannot be a coarray
gcc/fortran/ChangeLog:
PR fortran/69419
* match.c (gfc_match_common): Check array spec of a symbol in a
COMMON object list and reject it if it is a coarray.
gcc/testsuite/ChangeLog:
PR fortran/69419
* gfortran.dg/pr69419.f90: New test.
diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index 53a575e616e..df97620634d 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -5314,6 +5314,13 @@ gfc_match_common (void)
goto cleanup;
}
+ if (as->corank)
+ {
+ gfc_error ("Symbol %qs in COMMON at %C cannot be a "
+ "coarray", sym->name);
+ goto cleanup;
+ }
+
if (!gfc_add_dimension (&sym->attr, sym->name, NULL))
goto cleanup;
diff --git a/gcc/testsuite/gfortran.dg/pr69419.f90 b/gcc/testsuite/gfortran.dg/pr69419.f90
new file mode 100644
index 000..7329808611c
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr69419.f90
@@ -0,0 +1,9 @@
+! { dg-do compile }
+! { dg-options "-fcoarray=lib" }
+! PR fortran/69419 - ICE on invalid coarray in common
+
+blockdata b
+ real x ! { dg-error "must be in COMMON" }
+ common /c/ x[*] ! { dg-error "cannot be a coarray" }
+ data x /1.0/
+end
Re: [Patch, Fortran] PR 86935: Bad locus in ASSOCIATE statement
Hi Bernhard,
Am 27.10.21 um 19:40 schrieb Bernhard Reutner-Fischer via Fortran:
AFAICS current trunk still has this issue.
Any takers?
thanks,
can you create a PR tracking this issue?
AFAICS PR86935 has been fixed for gcc-9+.
Harald
On Sun, 2 Sep 2018 17:16:07 +0200
Bernhard Reutner-Fischer wrote:
i spotted one
(pre-existing) possible inconsistency that i did overlook back then:
gfc_match_associate () reads
...
if (gfc_match (" %e", &newAssoc->target) != MATCH_YES)
{
/* Have another go, allowing for procedure pointer selectors. */
gfc_matching_procptr_assignment = 1;
if (gfc_match (" %e", &newAssoc->target) != MATCH_YES)
{
gfc_error ("Invalid association target at %C");
goto assocListError;
}
gfc_matching_procptr_assignment = 0;
}
i.e. we retry a match, but in the second attempt we turn on procptr
assignment matching and if that works, we turn procptr assignment
matching off again.
But if we fail that retry, we forget to turn it off again.
I suppose we should:
$ svn diff -x -p gcc/fortran/match.c
Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (revision 264040)
+++ gcc/fortran/match.c (working copy)
@@ -1898,13 +1898,16 @@ gfc_match_associate (void)
if (gfc_match (" %e", &newAssoc->target) != MATCH_YES)
{
/* Have another go, allowing for procedure pointer selectors. */
+ match m;
+
gfc_matching_procptr_assignment = 1;
- if (gfc_match (" %e", &newAssoc->target) != MATCH_YES)
+ m = gfc_match (" %e", &newAssoc->target);
+ gfc_matching_procptr_assignment = 0;
+ if (m != MATCH_YES)
{
gfc_error ("Invalid association target at %C");
goto assocListError;
}
- gfc_matching_procptr_assignment = 0;
}
newAssoc->where = gfc_current_locus;
Untested. Maybe someone wants to give it a whirl...
If it wrecks havoc then leaving it set deliberately deserves at least a comment.
PS: It would be nice to get rid of gfc_matching_procptr_assignment,
gfc_matching_ptr_assignment, gfc_matching_prefix, FWIW.
cheers,
Thanks everyone!
Cheers,
Janus
Re: [Patch, Fortran] PR 86935: Bad locus in ASSOCIATE statement
On Wed, 27 Oct 2021 21:44:52 +0200 Harald Anlauf via Fortran wrote: > Hi Bernhard, > > Am 27.10.21 um 19:40 schrieb Bernhard Reutner-Fischer via Fortran: > > AFAICS current trunk still has this issue. > > Any takers? > > thanks, > > can you create a PR tracking this issue? now https://gcc.gnu.org/PR102973 > > AFAICS PR86935 has been fixed for gcc-9+. Yes, it is a pre existing possible bug that caught my eye when i looked at that patch, so admittedly unrelated to PR86935. thanks,
[PATCH,Fortran] Fortran: Delete unused decl in gfortran.h
From: Bernhard Reutner-Fischer
Hi!
Delete some more declarations without definitions and make some
functions static.
Bootstrapped and regtested on x86_64-unknown-linux without regressions.
Ok for trunk?
gcc/fortran/ChangeLog:
* decl.c (gfc_insert_kind_parameter_exprs): Make static.
* expr.c (gfc_build_init_expr): Make static
(gfc_build_default_init_expr): Move below its static helper.
* gfortran.h (gfc_insert_kind_parameter_exprs, gfc_add_saved_common,
gfc_add_common, gfc_use_derived_tree, gfc_free_charlen,
gfc_get_ultimate_derived_super_type,
gfc_resolve_oacc_parallel_loop_blocks, gfc_build_init_expr,
gfc_iso_c_sub_interface): Delete.
* symbol.c (gfc_new_charlen, gfc_get_derived_super_type): Make
static.
---
gcc/fortran/decl.c | 2 +-
gcc/fortran/expr.c | 20 ++--
gcc/fortran/gfortran.h | 9 -
gcc/fortran/symbol.c | 4 ++--
4 files changed, 13 insertions(+), 22 deletions(-)
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 2788348d1be..e9e23fe1acb 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -3713,7 +3713,7 @@ insert_parameter_exprs (gfc_expr* e, gfc_symbol* sym
ATTRIBUTE_UNUSED,
}
-bool
+static bool
gfc_insert_kind_parameter_exprs (gfc_expr *e)
{
return gfc_traverse_expr (e, NULL, &insert_parameter_exprs, 0);
diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 4dea840e348..087d822021a 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -4587,21 +4587,12 @@ gfc_check_assign_symbol (gfc_symbol *sym, gfc_component
*comp, gfc_expr *rvalue)
return true;
}
-/* Invoke gfc_build_init_expr to create an initializer expression, but do not
- * require that an expression be built. */
-
-gfc_expr *
-gfc_build_default_init_expr (gfc_typespec *ts, locus *where)
-{
- return gfc_build_init_expr (ts, where, false);
-}
-
/* Build an initializer for a local integer, real, complex, logical, or
character variable, based on the command line flags finit-local-zero,
finit-integer=, finit-real=, finit-logical=, and finit-character=.
With force, an initializer is ALWAYS generated. */
-gfc_expr *
+static gfc_expr *
gfc_build_init_expr (gfc_typespec *ts, locus *where, bool force)
{
gfc_expr *init_expr;
@@ -4758,6 +4749,15 @@ gfc_build_init_expr (gfc_typespec *ts, locus *where,
bool force)
return init_expr;
}
+/* Invoke gfc_build_init_expr to create an initializer expression, but do not
+ * require that an expression be built. */
+
+gfc_expr *
+gfc_build_default_init_expr (gfc_typespec *ts, locus *where)
+{
+ return gfc_build_init_expr (ts, where, false);
+}
+
/* Apply an initialization expression to a typespec. Can be used for symbols or
components. Similar to add_init_expr_to_sym in decl.c; could probably be
combined with some effort. */
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index f7662c59a5d..8c11cf6d18d 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -3116,7 +3116,6 @@ struct gfc_vect_builtin_tuple
extern hash_map *gfc_vectorized_builtins;
/* Handling Parameterized Derived Types */
-bool gfc_insert_kind_parameter_exprs (gfc_expr *);
bool gfc_insert_parameter_exprs (gfc_expr *, gfc_actual_arglist *);
match gfc_get_pdt_instance (gfc_actual_arglist *, gfc_symbol **,
gfc_actual_arglist **);
@@ -3348,11 +3347,9 @@ bool gfc_add_threadprivate (symbol_attribute *, const
char *, locus *);
bool gfc_add_omp_declare_target (symbol_attribute *, const char *, locus *);
bool gfc_add_omp_declare_target_link (symbol_attribute *, const char *,
locus *);
-bool gfc_add_saved_common (symbol_attribute *, locus *);
bool gfc_add_target (symbol_attribute *, locus *);
bool gfc_add_dummy (symbol_attribute *, const char *, locus *);
bool gfc_add_generic (symbol_attribute *, const char *, locus *);
-bool gfc_add_common (symbol_attribute *, locus *);
bool gfc_add_in_common (symbol_attribute *, const char *, locus *);
bool gfc_add_in_equivalence (symbol_attribute *, const char *, locus *);
bool gfc_add_data (symbol_attribute *, const char *, locus *);
@@ -3387,7 +3384,6 @@ bool gfc_copy_attr (symbol_attribute *, symbol_attribute
*, locus *);
int gfc_copy_dummy_sym (gfc_symbol **, gfc_symbol *, int);
bool gfc_add_component (gfc_symbol *, const char *, gfc_component **);
gfc_symbol *gfc_use_derived (gfc_symbol *);
-gfc_symtree *gfc_use_derived_tree (gfc_symtree *);
gfc_component *gfc_find_component (gfc_symbol *, const char *, bool, bool,
gfc_ref **);
@@ -3428,7 +3424,6 @@ void gfc_undo_symbols (void);
void gfc_commit_symbols (void);
void gfc_commit_symbol (gfc_symbol *);
gfc_charlen *gfc_new_charlen (gfc_namespace *, gfc_charlen *);
-void gfc_free_charlen (gfc_charlen *, gfc_charlen *);
void gfc_free_namespace (gfc_namespace *);
void gfc_symbol_init_2 (void);
@@ -3448,7 +
[PATCH,Fortran 0/1] Correct CAF locations in simplify
Hi! I found this lying around in an oldish tree. Regtest running over night, ok for trunk if it passes? Bernhard Reutner-Fischer (1): Tweak locations around CAF simplify gcc/fortran/simplify.c | 28 +++- 1 file changed, 15 insertions(+), 13 deletions(-) -- 2.33.0
[PATCH,Fortran 1/1] Tweak locations around CAF simplify
From: Bernhard Reutner-Fischer
addresses: FIXME: gfc_current_locus is wrong
by using the locus of the current intrinsic.
Regtests clean, ok for trunk?
gcc/fortran/ChangeLog:
2018-09-20 Bernhard Reutner-Fischer
* simplify.c (gfc_simplify_failed_or_stopped_images): Use
current intrinsic where locus.
(gfc_simplify_get_team): Likewise.
(gfc_simplify_num_images): Likewise.
(gfc_simplify_image_status): Likewise.
(gfc_simplify_this_image): Likewise.
---
gcc/fortran/simplify.c | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index d675f2c3aef..46e88bb2bf1 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -2985,8 +2985,9 @@ gfc_simplify_failed_or_stopped_images (gfc_expr *team
ATTRIBUTE_UNUSED,
{
if (flag_coarray == GFC_FCOARRAY_NONE)
{
- gfc_current_locus = *gfc_current_intrinsic_where;
- gfc_fatal_error ("Coarrays disabled at %C, use %<-fcoarray=%> to
enable");
+ gfc_fatal_error ("Coarrays disabled at %L, use %<-fcoarray=%> to enable",
+ gfc_current_intrinsic_where);
+
return &gfc_bad_expr;
}
@@ -2999,7 +3000,8 @@ gfc_simplify_failed_or_stopped_images (gfc_expr *team
ATTRIBUTE_UNUSED,
else
actual_kind = gfc_default_integer_kind;
- result = gfc_get_array_expr (BT_INTEGER, actual_kind,
&gfc_current_locus);
+ result = gfc_get_array_expr (BT_INTEGER, actual_kind,
+ gfc_current_intrinsic_where);
result->rank = 1;
return result;
}
@@ -3015,15 +3017,16 @@ gfc_simplify_get_team (gfc_expr *level ATTRIBUTE_UNUSED)
{
if (flag_coarray == GFC_FCOARRAY_NONE)
{
- gfc_current_locus = *gfc_current_intrinsic_where;
- gfc_fatal_error ("Coarrays disabled at %C, use %<-fcoarray=%> to
enable");
+ gfc_fatal_error ("Coarrays disabled at %L, use %<-fcoarray=%> to enable",
+ gfc_current_intrinsic_where);
return &gfc_bad_expr;
}
if (flag_coarray == GFC_FCOARRAY_SINGLE)
{
gfc_expr *result;
- result = gfc_get_array_expr (BT_INTEGER, gfc_default_integer_kind,
&gfc_current_locus);
+ result = gfc_get_array_expr (BT_INTEGER, gfc_default_integer_kind,
+ gfc_current_intrinsic_where);
result->rank = 0;
return result;
}
@@ -6340,7 +6343,8 @@ gfc_simplify_num_images (gfc_expr *distance
ATTRIBUTE_UNUSED, gfc_expr *failed)
if (flag_coarray == GFC_FCOARRAY_NONE)
{
- gfc_fatal_error ("Coarrays disabled at %C, use %<-fcoarray=%> to
enable");
+ gfc_fatal_error ("Coarrays disabled at %L, use %<-fcoarray=%> to enable",
+ gfc_current_intrinsic_where);
return &gfc_bad_expr;
}
@@ -6350,9 +6354,8 @@ gfc_simplify_num_images (gfc_expr *distance
ATTRIBUTE_UNUSED, gfc_expr *failed)
if (failed && failed->expr_type != EXPR_CONSTANT)
return NULL;
- /* FIXME: gfc_current_locus is wrong. */
result = gfc_get_constant_expr (BT_INTEGER, gfc_default_integer_kind,
- &gfc_current_locus);
+ gfc_current_intrinsic_where);
if (failed && failed->value.logical != 0)
mpz_set_si (result->value.integer, 0);
@@ -8345,8 +8348,8 @@ gfc_simplify_image_status (gfc_expr *image, gfc_expr
*team ATTRIBUTE_UNUSED)
{
if (flag_coarray == GFC_FCOARRAY_NONE)
{
- gfc_current_locus = *gfc_current_intrinsic_where;
- gfc_fatal_error ("Coarrays disabled at %C, use %<-fcoarray=%> to
enable");
+ gfc_fatal_error ("Coarrays disabled at %L, use %<-fcoarray=%> to enable",
+ gfc_current_intrinsic_where);
return &gfc_bad_expr;
}
@@ -8383,9 +8386,8 @@ gfc_simplify_this_image (gfc_expr *coarray, gfc_expr *dim,
if (coarray == NULL || !gfc_is_coarray (coarray))
{
gfc_expr *result;
- /* FIXME: gfc_current_locus is wrong. */
result = gfc_get_constant_expr (BT_INTEGER, gfc_default_integer_kind,
- &gfc_current_locus);
+ gfc_current_intrinsic_where);
mpz_set_si (result->value.integer, 1);
return result;
}
--
2.33.0
Re: [PATCH,FORTRAN] Fix memory leak in finalization wrappers
Ping [hmz. it's been a while, I'll rebase and retest this one. Ok if it passes?] On Mon, 15 Oct 2018 10:23:06 +0200 Bernhard Reutner-Fischer wrote: > If a finalization is not required we created a namespace containing > formal arguments for an internal interface definition but never used > any of these. So the whole sub_ns namespace was not wired up to the > program and consequently was never freed. The fix is to simply not > generate any finalization wrappers if we know that it will be unused. > Note that this reverts back to the original r190869 > (8a96d64282ac534cb597f446f02ac5d0b13249cc) handling for this case > by reverting this specific part of r194075 > (f1ee56b4be7cc3892e6ccc75d73033c129098e87) for PR fortran/37336. > > Regtests cleanly, installed to the fortran-fe-stringpool branch, sent > here for reference and later inclusion. > I might plug a few more leaks in preparation of switching to hash-maps. > I fear that the leaks around interfaces are another candidate ;) > > Should probably add a tag for the compile-time leak PR68800 shouldn't i. > > valgrind summary for e.g. > gfortran.dg/abstract_type_3.f03 and gfortran.dg/abstract_type_4.f03 > where ".orig" is pristine trunk and ".mine" contains this fix: > > at3.orig.vg:LEAK SUMMARY: > at3.orig.vg- definitely lost: 8,460 bytes in 11 blocks > at3.orig.vg- indirectly lost: 13,288 bytes in 55 blocks > at3.orig.vg- possibly lost: 0 bytes in 0 blocks > at3.orig.vg- still reachable: 572,278 bytes in 2,142 blocks > at3.orig.vg-suppressed: 0 bytes in 0 blocks > at3.orig.vg- > at3.orig.vg-Use --track-origins=yes to see where uninitialised values come > from > at3.orig.vg-ERROR SUMMARY: 38 errors from 33 contexts (suppressed: 0 from 0) > -- > at3.mine.vg:LEAK SUMMARY: > at3.mine.vg- definitely lost: 344 bytes in 1 blocks > at3.mine.vg- indirectly lost: 7,192 bytes in 18 blocks > at3.mine.vg- possibly lost: 0 bytes in 0 blocks > at3.mine.vg- still reachable: 572,278 bytes in 2,142 blocks > at3.mine.vg-suppressed: 0 bytes in 0 blocks > at3.mine.vg- > at3.mine.vg-ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) > at3.mine.vg-ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) > at4.orig.vg:LEAK SUMMARY: > at4.orig.vg- definitely lost: 13,751 bytes in 12 blocks > at4.orig.vg- indirectly lost: 11,976 bytes in 60 blocks > at4.orig.vg- possibly lost: 0 bytes in 0 blocks > at4.orig.vg- still reachable: 572,278 bytes in 2,142 blocks > at4.orig.vg-suppressed: 0 bytes in 0 blocks > at4.orig.vg- > at4.orig.vg-Use --track-origins=yes to see where uninitialised values come > from > at4.orig.vg-ERROR SUMMARY: 18 errors from 16 contexts (suppressed: 0 from 0) > -- > at4.mine.vg:LEAK SUMMARY: > at4.mine.vg- definitely lost: 3,008 bytes in 3 blocks > at4.mine.vg- indirectly lost: 4,056 bytes in 11 blocks > at4.mine.vg- possibly lost: 0 bytes in 0 blocks > at4.mine.vg- still reachable: 572,278 bytes in 2,142 blocks > at4.mine.vg-suppressed: 0 bytes in 0 blocks > at4.mine.vg- > at4.mine.vg-ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0) > at4.mine.vg-ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0) > > gcc/fortran/ChangeLog: > > 2018-10-12 Bernhard Reutner-Fischer > > * class.c (generate_finalization_wrapper): Do leak finalization > wrappers if they will not be used. > * expr.c (gfc_free_actual_arglist): Formatting fix. > * gfortran.h (gfc_free_symbol): Pass argument by reference. > (gfc_release_symbol): Likewise. > (gfc_free_namespace): Likewise. > * symbol.c (gfc_release_symbol): Adjust acordingly. > (free_components): Set procedure pointer components > of derived types to NULL after freeing. > (free_tb_tree): Likewise. > (gfc_free_symbol): Set sym to NULL after freeing. > (gfc_free_namespace): Set namespace to NULL after freeing. > --- > gcc/fortran/class.c| 25 + > gcc/fortran/expr.c | 2 +- > gcc/fortran/gfortran.h | 6 +++--- > gcc/fortran/symbol.c | 19 ++- > 4 files changed, 23 insertions(+), 29 deletions(-) > > diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c > index 69c95fc5dfa..e0bb381a55f 100644 > --- a/gcc/fortran/class.c > +++ b/gcc/fortran/class.c > @@ -1533,7 +1533,6 @@ generate_finalization_wrapper (gfc_symbol *derived, > gfc_namespace *ns, >gfc_code *last_code, *block; >const char *name; >bool finalizable_comp = false; > - bool expr_null_wrapper = false; >gfc_expr *ancestor_wrapper = NULL, *rank; >gfc_iterator *iter; > > @@ -1561,13 +1560,17 @@ generate_finalization_wrapper (gfc_symbol *derived, > gfc_namespace *ns, > } > >/* No wrapper of the ancestor and no own FINAL subroutines and allocatable > - components: Return a NULL() expression; we defer this a bit to have have > + components: Return a NULL() expression; we defer this a bit to have >
Re: [PATCH,FORTRAN] Fix memory leak of gsymbol
ping
[I'll rebase and retest this too since it's been a while.
Ok if it passes?]
On Sun, 21 Oct 2018 16:04:34 +0200
Bernhard Reutner-Fischer wrote:
> Hi!
>
> Regtested on x86_64-unknown-linux, installing on
> aldot/fortran-fe-stringpool.
>
> We did not free global symbols. For a simplified abstract_type_3.f03
> valgrind reports:
>
> 96 bytes in 1 blocks are still reachable in loss record 461 of 602
>at 0x48377D5: calloc (vg_replace_malloc.c:711)
>by 0x21257C3: xcalloc (xmalloc.c:162)
>by 0x98611B: gfc_get_gsymbol(char const*) (symbol.c:4341)
>by 0x932C58: parse_module() (parse.c:5912)
>by 0x9336F8: gfc_parse_file() (parse.c:6236)
>by 0x991449: gfc_be_parse_file() (f95-lang.c:204)
>by 0x11D8EDE: compile_file() (toplev.c:455)
>by 0x11DB9C3: do_compile() (toplev.c:2170)
>by 0x11DBCAF: toplev::main(int, char**) (toplev.c:2305)
>by 0x2045D37: main (main.c:39)
>
> This patch reduces leaks to
>
> LEAK SUMMARY:
> definitely lost: 344 bytes in 1 blocks
> indirectly lost: 3,024 bytes in 4 blocks
> possibly lost: 0 bytes in 0 blocks
> - still reachable: 1,576,174 bytes in 2,277 blocks
> + still reachable: 1,576,078 bytes in 2,276 blocks
> suppressed: 0 bytes in 0 blocks
>
> gcc/fortran/ChangeLog:
>
> 2018-10-21 Bernhard Reutner-Fischer
>
> * parse.c (clean_up_modules): Free gsym.
> ---
> gcc/fortran/parse.c | 18 +++---
> 1 file changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c
> index b7265c42f58..f7c369a17ac 100644
> --- a/gcc/fortran/parse.c
> +++ b/gcc/fortran/parse.c
> @@ -6066,7 +6066,7 @@ resolve_all_program_units (gfc_namespace
> *gfc_global_ns_list)
>
>
> static void
> -clean_up_modules (gfc_gsymbol *gsym)
> +clean_up_modules (gfc_gsymbol *&gsym)
> {
>if (gsym == NULL)
> return;
> @@ -6074,14 +6074,18 @@ clean_up_modules (gfc_gsymbol *gsym)
>clean_up_modules (gsym->left);
>clean_up_modules (gsym->right);
>
> - if (gsym->type != GSYM_MODULE || !gsym->ns)
> + if (gsym->type != GSYM_MODULE)
> return;
>
> - gfc_current_ns = gsym->ns;
> - gfc_derived_types = gfc_current_ns->derived_types;
> - gfc_done_2 ();
> - gsym->ns = NULL;
> - return;
> + if (gsym->ns)
> +{
> + gfc_current_ns = gsym->ns;
> + gfc_derived_types = gfc_current_ns->derived_types;
> + gfc_done_2 ();
> + gsym->ns = NULL;
> +}
> + free (gsym);
> + gsym = NULL;
> }
>
>
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
I've played with some patches to PowerPC to set the defaults for fortran. But without doing a full rebuild like you would do with a new distribution, I think it will be problematical, unless you build everything with the default long double set to IEEE 128-bit. First off all, libquadmath is currently built on Linux 64-bit systems. I never removed building libquadmath once we got the official glibc 2.34 support So to go in more detail of what I've tried. I added an undocumented switch -mfortran that says set the defaults for Fortran. This switch would be used to build libgfortran, and also set with TARGET_F951_OPTIONS for all Fortran invocations. I tried to switch to float128_type_node instead of long_double_type_node. I ran into problems with gimplify in that it could not do a conversion from _Float128 to float. I suspect I didn't actually use the right type. I then went to patches where -mfortran silently switches the long double type to IEEE 128-bit. There you get into various compatibility issues where the linker complains that you are calling between the different long double types. For instance because we are still building libquadmath, libquadmath is marked as having long double being IBM 128-bit, but it is called from Fortran modules that have long double being IEEE 128-bit. I then did a build supressing building libquadmath since I was using LE with glibc 2.34, and I got much further. This time instead of a lot of failures, I got 29 failures, due to libgfortran still being marked as IBM long double and the fortran modules are marked as IEEE long double. Right now, the only way to avoid these things is to build the entire toolchain defaulting to IEEE 128-bit. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meiss...@linux.ibm.com
