gfortran.org
Hi, for quite some time, there was a forwarding from http://gfortran.org to my dumping ground http://gfortran.meteodat.ch. At the moment, at least for me, this domain points to some gaming blog. Does anybody know what is going on? There were some ideas what do with this domain at some point (Jerry, Paul?). Bud, are you still owner of this domain? Do you have some plans what to do with it? Cheers, Manfred PS: the domain gfortran.com still points to my site, but the above questions apply to this domain as well, of course.
*PING* [PATCH] PR fortran/102715 - [12 Regression] ICE in gfc_simplify_transpose, at fortran/simplify.c:8184
Early ping. Am 31.10.21 um 22:35 schrieb Harald Anlauf via Fortran: Dear Fortranners, the fix for initialization of DT arrays caused an apparent regression for cases where inconsistent ranks were used in such an initialization. This caused either an ICE in subsequent uses of these arrays, or showed up in valgrind as invalid reads, all of which seemed to be related to this rank mismatch. The cleanest solution seems to be to strictly reject rank mismatch earlier than we used to, which helps error recovery. I had to adjust one testcase accordingly. The place I inserted the check does not distinguish between explicit shape and implied shape. The Intel compiler does give a slightly different error message for the implied shape case. If anyone feels strongly about this, I'm open to suggestions for better choices of handling this. Regtested on x86_64-pc-linux-gnu. OK for mainline / affected branches? Thanks, Harald
Re: [PATCH,Fortran] Fortran: Delete unused decl in gfortran.h
Le 27/10/2021 à 23:11, Bernhard Reutner-Fischer via Fortran a écrit : Delete some more declarations without definitions and make some functions static. Bootstrapped and regtested on x86_64-unknown-linux without regressions. Ok for trunk? Ok. Thanks Mikael
Re: [PATCH,FORTRAN] Fix memory leak in finalization wrappers
Le 29/10/2021 à 01:58, Bernhard Reutner-Fischer via Fortran a écrit : On Wed, 27 Oct 2021 23:39:43 +0200 Bernhard Reutner-Fischer wrote: Ping [hmz. it's been a while, I'll rebase and retest this one. Ok if it passes?] Testing passed without any new regressions. Ok for trunk? thanks, 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. I’m a bit concerned by the loss of the null_expr’s type interface. I can’t convince myself that it’s either absolutely necessary or completely useless. Tobias didn’t include a test in his commit unfortunately, but I bet he did the change on purpose. Don’t you get the same effect on the memory leaks if you keep just the following hunk? >>> @@ -1605,8 +1608,7 @@ generate_finalization_wrapper (gfc_symbol *derived, gfc_namespace *ns, >>> /* Set up the namespace. */ >>> sub_ns = gfc_get_namespace (ns, 0); >>> sub_ns->sibling = ns->contained; >>> - if (!expr_null_wrapper) >>> -ns->contained = sub_ns; >>> + ns->contained = sub_ns; >>> sub_ns->resolved = 1; >>> >>> /* Set up the procedure symbol. */ The rest of the changes (appart from class.c) are mostly OK with the nit below and should be put in their own commit. >>> @@ -3826,10 +3828,8 @@ free_tb_tree (gfc_symtree *t) >>> >>> free_tb_tree (t->left); >>> free_tb_tree (t->right); >>> - >>> - /* TODO: Free type-bound procedure structs themselves; probably needs some >>> - sort of ref-counting mechanism. */ >>> free (t->n.tb); Please keep a comment; it remains somehow valid but could be updated maybe: gfc_typebound_proc’s u.generic field for example is nowhere freed as far as I know. Thanks. Mikael
Re: [PATCH,Fortran 1/1] Tweak locations around CAF simplify
Le 27/10/2021 à 23:29, Bernhard Reutner-Fischer via Fortran a écrit : From: Bernhard Reutner-Fischer addresses: FIXME: gfc_current_locus is wrong by using the locus of the current intrinsic. Regtests clean, ok for trunk? Hello, I’m not convinced that replacing a global variable by an other really fixes things. gfc_current_intrinsic_where is only valid if the simplification functions are called from gfc_intrinsic_func_interface. The fatal errors hardly need a location anyway; as for the rest, well... A proper fix would add a location argument to gfc_simplify_f’s union fields (and maybe gfc_check_f’s as well), and the associated simplification functions. As the impact would be somewhat massive, maybe add new distinct union fields with location arguments and a procedure (a switch on the intrinsic id basically) to decide which field to use. Does it sound good to you? Mikael
Re: [PATCH] Fortran: Missing error with IMPLICIT none (external) [PR100972]
Le 31/10/2021 à 18:25, Bernhard Reutner-Fischer via Fortran a écrit : As Gerhard Steinmetz noticed, gfc_match_implicit_none() had a notify_std that mentioned IMPORT instead of IMPLICIT. Fix that typo. IMPLICIT NONE (external) is supposed to require external procedures to be explicitly declared with EXTERNAL. We cannot do this when parsing in e.g. gfc_match_rvalue->gfc_match_varspec because the procedure might live way down in a CONTAINS like in bind-c-contiguous-3.f90. Hence diagnose missing EXTERNAL declaraions when resolving. Bootstrapped and regtested on x86_64-unknown-linux without regressions. Ok for trunk? OK, thanks. Mikael
[committed] Fortran: Add more documentation for mixed-language programming
I was recently pinged about PR35276. It's an old issue, but a couple of
the concerns raised there haven't been fixed yet, so I've checked in
this patch to fill in the gaps.
-Sandra
commit b8bf685ed44dba9bd4bbd600bc8bc2be0a2abb1b
Author: Sandra Loosemore
Date: Fri Nov 5 14:01:03 2021 -0700
Fortran: Add more documentation for mixed-language programming [PR35276]
2021-11-05 Sandra Loosemore
PR fortran/35276
gcc/fortran/
* gfortran.texi (Mixed-Language Programming): Talk about C++,
and how to link.
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index f3a961e..3264709 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -2718,11 +2718,23 @@ reading from the position marked previously.
* Naming and argument-passing conventions::
@end menu
-This chapter is about mixed-language interoperability, but also applies
-if one links Fortran code compiled by different compilers. In most cases,
-use of the C Binding features of the Fortran 2003 standard is sufficient,
-and their use is highly recommended.
-
+This chapter is about mixed-language interoperability, but also
+applies if you link Fortran code compiled by different compilers. In
+most cases, use of the C Binding features of the Fortran 2003 and
+later standards is sufficient.
+
+For example, it is possible to mix Fortran code with C++ code as well
+as C, if you declare the interface functions as @code{extern "C"} on
+the C++ side and @code{BIND(C)} on the Fortran side, and follow the
+rules for interoperability with C. Note that you cannot manipulate
+C++ class objects in Fortran or vice versa except as opaque pointers.
+
+You can use the @command{gfortran} command to link both Fortran and
+non-Fortran code into the same program, or you can use @command{gcc}
+or @command{g++} if you also add an explicit @option{-lgfortran} option
+to link with the Fortran library. If your main program is written in
+C or some other language instead of Fortran, see
+@ref{Non-Fortran Main Program}, below.
@node Interoperability with C
@section Interoperability with C
[PATCH 1/2] Add free_cpp_dirs()
From: Bernhard Reutner-Fischer
gcc/ChangeLog:
* incpath.c (free_cpp_dirs): New function.
* incpath.h (free_cpp_dirs): Ditto.
---
This adds a helper to allow the fortran FE to free it's include dirs.
Bootstrapped and regtested without new regressions on x86_64-unknown-linux.
Ok for trunk?
---
gcc/incpath.c | 13 +
gcc/incpath.h | 1 +
2 files changed, 14 insertions(+)
diff --git a/gcc/incpath.c b/gcc/incpath.c
index 52dbb806b1b..de77a56062c 100644
--- a/gcc/incpath.c
+++ b/gcc/incpath.c
@@ -513,6 +513,19 @@ get_added_cpp_dirs (incpath_kind chain)
return heads[chain];
}
+/* Free all cpp dirs. */
+void
+free_cpp_dirs (void)
+{
+ struct cpp_dir **pcur, *cur;
+ for (pcur = &heads[INC_QUOTE]; *pcur;)
+{
+ cur = *pcur;
+ *pcur = cur->next;
+ free_path (cur, REASON_QUIET);
+}
+}
+
#if !(defined TARGET_EXTRA_INCLUDES) || !(defined TARGET_EXTRA_PRE_INCLUDES)
static void hook_void_charptr_charptr_int (const char *sysroot
ATTRIBUTE_UNUSED,
const char *iprefix ATTRIBUTE_UNUSED,
diff --git a/gcc/incpath.h b/gcc/incpath.h
index 2a4a314d7f9..4bf878b4e74 100644
--- a/gcc/incpath.h
+++ b/gcc/incpath.h
@@ -34,6 +34,7 @@ extern void register_include_chains (cpp_reader *, const char
*,
int, int, int);
extern void add_cpp_dir_path (struct cpp_dir *, incpath_kind);
extern struct cpp_dir *get_added_cpp_dirs (incpath_kind);
+extern void free_cpp_dirs(void);
struct target_c_incpath_s {
/* Do extra includes processing. STDINC is false iff -nostdinc was given.
*/
--
2.33.0
[PATCH 2/2] Fortran: Fix memory leak in gfc_add_include_path [PR68800]
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
PR fortran/68800
* cpp.h (gfc_cpp_free_cpp_dirs): New declaration.
* cpp.c (gfc_cpp_free_cpp_dirs): New definition.
(gfc_cpp_add_include_path, gfc_cpp_add_include_path_after): Add
comment.
* f95-lang.c (gfc_finish): Call gfc_cpp_free_cpp_dirs.
* scanner.c (add_path_to_list): Allocate unzeroed memory.
(gfc_add_include_path): Add comment and fix formatting.
---
Bootstrapped and regtested without regressions on x86_64-unknown-linux.
Ok for trunk?
Note: in add_path_to_list i changed dir->path = XCNEWVEC to XNEWVEC
since strcpy and strcat add a terminating null byte for us anyway.
Fixes:
-== 68 bytes in 1 blocks are still reachable in loss record 228 of 371
-==at : malloc (vg_replace_malloc.c:380)
-==by : xmalloc (xmalloc.c:149)
-==by : xstrdup (xstrdup.c:34)
-==by : gfc_add_include_path(char const*, bool, bool, bool, bool) (scanner.c
:428)
-==by : gfc_handle_option(unsigned long, char const*, long, int, unsigned in
t, cl_option_handlers const*) (options.c:702)
-==by : handle_option(gcc_options*, gcc_options*, cl_decoded_option const*,
unsigned int, int, unsigned int, cl_option_handlers const*, bool, diagnostic_con
text*) (opts-common.c:1181)
-==by : read_cmdline_option(gcc_options*, gcc_options*, cl_decoded_option*,
unsigned int, unsigned int, cl_option_handlers const*, diagnostic_context*) (opt
s-common.c:1431)
-==by : read_cmdline_options (opts-global.c:237)
-==by : decode_options(gcc_options*, gcc_options*, cl_decoded_option*, unsig
ned int, unsigned int, diagnostic_context*, void (*)()) (opts-global.c:319)
-==by : toplev::main(int, char**) (toplev.c:2273)
-==by : main (main.c:39)
---
gcc/fortran/cpp.c | 13 +++--
gcc/fortran/cpp.h | 1 +
gcc/fortran/f95-lang.c | 2 +-
gcc/fortran/scanner.c | 7 ---
4 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/gcc/fortran/cpp.c b/gcc/fortran/cpp.c
index e86386c8b17..04fe8fe460b 100644
--- a/gcc/fortran/cpp.c
+++ b/gcc/fortran/cpp.c
@@ -728,12 +728,20 @@ gfc_cpp_done (void)
cpp_clear_file_cache (cpp_in);
}
-/* PATH must be malloc-ed and NULL-terminated. */
+/* Free all cpp include dirs. */
+void
+gfc_cpp_free_cpp_dirs (void)
+{
+ free_cpp_dirs ();
+}
+
+/* PATH must be NULL-terminated. */
void
gfc_cpp_add_include_path (char *path, bool user_supplied)
{
/* CHAIN sets cpp_dir->sysp which differs from 0 if PATH is a system
- include path. Fortran does not define any system include paths. */
+ include path. Fortran does not define any system include paths.
+ incpath.c manages the incoming, xstrdup()ed path. */
int cxx_aware = 0;
add_path (path, INC_BRACKET, cxx_aware, user_supplied);
@@ -742,6 +750,7 @@ gfc_cpp_add_include_path (char *path, bool user_supplied)
void
gfc_cpp_add_include_path_after (char *path, bool user_supplied)
{
+ /* incpath.c manages the incoming, xstrdup()ed path. */
int cxx_aware = 0;
add_path (path, INC_AFTER, cxx_aware, user_supplied);
}
diff --git a/gcc/fortran/cpp.h b/gcc/fortran/cpp.h
index 44644a2a333..963b9a9c89e 100644
--- a/gcc/fortran/cpp.h
+++ b/gcc/fortran/cpp.h
@@ -46,6 +46,7 @@ void gfc_cpp_post_options (bool);
bool gfc_cpp_preprocess (const char *source_file);
void gfc_cpp_done (void);
+void gfc_cpp_free_cpp_dirs (void);
void gfc_cpp_add_include_path (char *path, bool user_supplied);
void gfc_cpp_add_include_path_after (char *path, bool user_supplied);
diff --git a/gcc/fortran/f95-lang.c b/gcc/fortran/f95-lang.c
index 58dcaf01d75..ec4c2cf01d9 100644
--- a/gcc/fortran/f95-lang.c
+++ b/gcc/fortran/f95-lang.c
@@ -275,7 +275,7 @@ gfc_finish (void)
gfc_cpp_done ();
gfc_done_1 ();
gfc_release_include_path ();
- return;
+ gfc_cpp_free_cpp_dirs ();
}
/* These functions and variables deal with binding contours. We only
diff --git a/gcc/fortran/scanner.c b/gcc/fortran/scanner.c
index 69b81ab97f8..268d1e3e7fb 100644
--- a/gcc/fortran/scanner.c
+++ b/gcc/fortran/scanner.c
@@ -370,7 +370,7 @@ add_path_to_list (gfc_directorylist **list, const char
*path,
char *q;
size_t len;
int i;
-
+
p = path;
while (*p == ' ' || *p == '\t') /* someone might do "-I include" */
if (*p++ == '\0')
@@ -409,7 +409,7 @@ add_path_to_list (gfc_directorylist **list, const char
*path,
*list = dir;
dir->use_for_modules = use_for_modules;
dir->warn = warn;
- dir->path = XCNEWVEC (char, strlen (p) + 2);
+ dir->path = XNEWVEC (char, strlen (p) + 2);
strcpy (dir->path, p);
strcat (dir->path, "/"); /* make '/' last character */
}
@@ -424,8 +424,9 @@ gfc_add_include_path (const char *path, bool
use_for_modules, bool file_dir,
defer_warn);
/* For '#include "..."' these directories are automatically searched. */
+ /* CPP manages 'path' on it's own via incpath.c so give it it's own copy. */
if (!file_dir)
-gfc_cpp_add_include
[PATCH 0/2] incpath, Fortran: Fix memory leak in gfc_add_include_path
Hi! In order to fix this very minor leak, we need a knob to free all cpp_dirs that were added. This adds a free_cpp_dirs() to gcc/incpath and needs review from some global maintainer or maybe libcpp maintainer for this hunk. Bootstrapped and regtested on x86_64-unknown-linux without regressions. Ok for tunk? Bernhard Reutner-Fischer (2): Add free_cpp_dirs() Fortran: Fix memory leak in gfc_add_include_path [PR68800] gcc/fortran/cpp.c | 13 +++-- gcc/fortran/cpp.h | 1 + gcc/fortran/f95-lang.c | 2 +- gcc/fortran/scanner.c | 7 --- gcc/incpath.c | 13 + gcc/incpath.h | 1 + 6 files changed, 31 insertions(+), 6 deletions(-) -- 2.33.0
Re: [PATCH] PR fortran/102817 - [12 Regression] ICE in gfc_clear_shape, at fortran/expr.c:422
Le 01/11/2021 à 22:39, Harald Anlauf via Fortran a écrit : Dear Fortranners, a recent patch uncovered a latent issue with simplification of array-valued expressions where the resulting shape was not set from the referenced subobject. Once found, the fix looks obvious. Regtested on x86_64-pc-linux-gnu. OK? Hello, diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c index 4dea840e348..c5360dfaede 100644 --- a/gcc/fortran/expr.c +++ b/gcc/fortran/expr.c @@ -2129,6 +2129,7 @@ simplify_parameter_variable (gfc_expr *p, int type) return false; e->rank = p->rank; + e->shape = gfc_copy_shape (p->shape, p->rank); I think e->shape can be non-null, and should be freed beforehand. Ok with that change. Mikael
Re: *PING* [PATCH] PR fortran/69419 - ICE: tree check: expected array_type, have real_type in gfc_conv_array_initializer, at fortran/trans-array.c:5618
Le 04/11/2021 à 20:49, Harald Anlauf via Fortran a écrit : Let's see what others think. OK, thanks. Mikael
Re: [PATCH,FORTRAN] Fix memory leak in finalization wrappers
On Fri, 5 Nov 2021 19:46:16 +0100 Mikael Morin wrote: > Le 29/10/2021 à 01:58, Bernhard Reutner-Fischer via Fortran a écrit : > > On Wed, 27 Oct 2021 23:39:43 +0200 > > Bernhard Reutner-Fischer wrote: > > > >> Ping > >> [hmz. it's been a while, I'll rebase and retest this one. > >> Ok if it passes?] > > Testing passed without any new regressions. > > Ok for trunk? > > thanks, > >> > >> 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. > >>> > I’m a bit concerned by the loss of the null_expr’s type interface. > I can’t convince myself that it’s either absolutely necessary or > completely useless. It's a delicate spot, yes, but i do think they are completely useless. If we do NOT need a finalization, the initializer can (and has to be AFAIU) be a null_expr and AFAICS then does not need an interface. > Tobias didn’t include a test in his commit unfortunately, but I bet he > did the change on purpose. > Don’t you get the same effect on the memory leaks if you keep just the > following hunk? No, i don't think emitting the finalization-wrappers unconditionally is correct. In https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582894.html i noted: ---8<--- We were generating (and emitting to modules) finalization wrapper needlessly, i.e. even when they were not called for. This 1) leaked like shown in the initial submission and 2) polluted module files with unwarranted (wrong) mention of finalization wrappers even when compiling without any coarray stuff. E.g. a modified udr10.f90 (from libgomp) has the following diff in the module which illustrates the positive side-effect of the fix: -26 'array' '' '' 25 ((VARIABLE INOUT UNKNOWN-PROC UNKNOWN UNKNOWN 0 0 -ARTIFICIAL DIMENSION CONTIGUOUS DUMMY) () (DERIVED 3 0 0 0 DERIVED ()) 0 -0 () (0 0 ASSUMED_RANK) 0 () () () 0 0) -27 'byte_stride' '' '' 25 ((VARIABLE UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN -UNKNOWN 0 0 ARTIFICIAL VALUE DUMMY) () (INTEGER 8 0 0 0 INTEGER ()) 0 0 -() () 0 () () () 0 0) -28 'fini_coarray' '' '' 25 ((VARIABLE UNKNOWN-INTENT UNKNOWN-PROC -UNKNOWN UNKNOWN 0 0 ARTIFICIAL VALUE DUMMY) () (LOGICAL 1 0 0 0 LOGICAL -()) 0 0 () () 0 () () () 0 0) ---8<--- [Should be visible with the original udr10.f90 too.] If something in a module would trigger finalization to be emitted legitimately then this will continue to work as before. But IMHO it is not proper to emit them in an undue manner. Hence it does not help to just wire the sub_ns up in the program when it should not be wired up (and not generated in the first place) I'd say. > > >>> @@ -1605,8 +1608,7 @@ generate_finalization_wrapper (gfc_symbol > *derived, gfc_namespace *ns, > >>> /* Set up the namespace. */ > >>> sub_ns = gfc_get_namespace (ns, 0); > >>> sub_ns->sibling = ns->contained; > >>> - if (!expr_null_wrapper) > >>> -ns->contained = sub_ns; > >>> + ns->contained = sub_ns; > >>> sub_ns->resolved = 1; > >>> > >>> /* Set up the procedure symbol. */ > > > The rest of the changes (appart from class.c) are mostly OK with the nit > below and should be put in their own commit. > > >>> @@ -3826,10 +3828,8 @@ free_tb_tree (gfc_symtree *t) > >>> > >>> free_tb_tree (t->left); > >>> free_tb_tree (t->right); > >>> - > >>> - /* TODO: Free type-bound procedure structs themselves; probably > needs some > >>> - sort of ref-counting mechanism. */ > >>> free (t->n.tb); > > Please keep a comment; it remains somehow valid but could be updated > maybe: gfc_typebound_proc’s u.generic field for example is nowhere freed > as far as I know. Well that's a valid point, not sure where they are freed indeed. Do you have a specific testcase in mind that leaks tbp's u.generic (or specific for that matter) for me to look at? I'm happy to change the comment to TODO: Free type-bound procedure u.generic and u.specific fields to reflect the current state. Ok? > > Thanks. Many thanks for looking at the patch! > > Mikael
Re: [PATCH] PR fortran/102817 - [12 Regression] ICE in gfc_clear_shape, at fortran/expr.c:422
Hi Mikael,
Am 05.11.21 um 22:28 schrieb Mikael Morin:
Le 01/11/2021 à 22:39, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
a recent patch uncovered a latent issue with simplification of
array-valued expressions where the resulting shape was not set
from the referenced subobject. Once found, the fix looks obvious.
Regtested on x86_64-pc-linux-gnu. OK?
Hello,
diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 4dea840e348..c5360dfaede 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -2129,6 +2129,7 @@ simplify_parameter_variable (gfc_expr *p, int type)
return false;
e->rank = p->rank;
+ e->shape = gfc_copy_shape (p->shape, p->rank);
I think e->shape can be non-null, and should be freed beforehand.
good point. I've added this and tested again.
See attached patch for the update.
Ok with that change.
Mikael
Thanks for the review!
Harald
From bcf3728abe842922005166d3065fc5fdfea1 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 5 Nov 2021 23:48:20 +0100
Subject: [PATCH] Fortran: fix simplification of array-valued parameter
expressions
gcc/fortran/ChangeLog:
PR fortran/102817
* expr.c (simplify_parameter_variable): Copy shape of referenced
subobject when simplifying.
gcc/testsuite/ChangeLog:
PR fortran/102817
* gfortran.dg/pr102817.f90: New test.
---
gcc/fortran/expr.c | 2 ++
gcc/testsuite/gfortran.dg/pr102817.f90 | 17 +
2 files changed, 19 insertions(+)
create mode 100644 gcc/testsuite/gfortran.dg/pr102817.f90
diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 087d822021a..941d29cf7cd 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -2128,6 +2128,8 @@ simplify_parameter_variable (gfc_expr *p, int type)
if (e == NULL)
return false;
+ gfc_free_shape (&e->shape, e->rank);
+ e->shape = gfc_copy_shape (p->shape, p->rank);
e->rank = p->rank;
if (e->ts.type == BT_CHARACTER && p->ts.u.cl)
diff --git a/gcc/testsuite/gfortran.dg/pr102817.f90 b/gcc/testsuite/gfortran.dg/pr102817.f90
new file mode 100644
index 000..c081a69f0ea
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr102817.f90
@@ -0,0 +1,17 @@
+! { dg-do compile }
+! PR fortran/102817 - ICE in gfc_clear_shape
+
+program test
+ type t
+ integer :: a(1,2) = 3
+ end type t
+ type(t), parameter :: u= t(4)
+ type(t), parameter :: x(1) = t(4)
+ integer, parameter :: p(1,2) = (x(1)%a)
+ integer:: z(1,2) = (x(1)%a)
+ integer:: y(1,2), v(1,2), w(1,2)
+ v = (u %a)
+ w = x(1)%a
+ y = (x(1)%a)
+ print *, v, w, y, z, p
+end
--
2.26.2
Re: [PATCH 0/2] incpath, Fortran: Fix memory leak in gfc_add_include_path
On Fri, 5 Nov 2021 22:17:16 +0100
Bernhard Reutner-Fischer wrote:
> Hi!
>
> In order to fix this very minor leak, we need a knob to free all
> cpp_dirs that were added.
> This adds a free_cpp_dirs() to gcc/incpath and needs review from some
> global maintainer or maybe libcpp maintainer for this hunk.
One thing that i want to note is that it sounds a tiny bit odd that we
(the fortran FE) pull in the usual C paths, but maybe that's
deliberate and agreed on? We have in incpath.c:
> /* Exported function to handle include chain merging, duplicate
>removal, and registration with cpplib. */
> void
> register_include_chains (cpp_reader *pfile, const char *sysroot,
>const char *iprefix, const char *imultilib,
>int stdinc, int cxx_stdinc, int verbose)
> {
> static const char *const lang_env_vars[] =
> { "C_INCLUDE_PATH", "CPLUS_INCLUDE_PATH",
> "OBJC_INCLUDE_PATH", "OBJCPLUS_INCLUDE_PATH" };
> cpp_options *cpp_opts = cpp_get_options (pfile);
> size_t idx = (cpp_opts->objc ? 2: 0);
>
> if (cpp_opts->cplusplus)
> idx++;
> else
> cxx_stdinc = false;
>
> /* CPATH and language-dependent environment variables may add to the
> include chain. */
> add_env_var_paths ("CPATH", INC_BRACKET);
> add_env_var_paths (lang_env_vars[idx], INC_SYSTEM);
>
> target_c_incpath.extra_pre_includes (sysroot, iprefix, stdinc);
where we pass cxx_stdinc=0 and cpp_pts->cplusplus==0 (and nobody
complains anout that chatty cxx_stdinc=false and not =0 but so be it)
I.e. we do honor both CPATH as well as C_INCLUDE_PATH from the env for
fortran preprocessing. Maybe we should document this fact somehow as i
do not think we want to change it?
[ in gcc/doc/cppenv.texi:
@itemx OBJC_INCLUDE_PATH
@c Commented out until ObjC++ is part of GCC:
@c @itemx OBJCPLUS_INCLUDE_PATH
where i think objc++ is currently (still) in the tree so maybe someone
may want to tweak the docs here. But i digress..
]
gcc/ada/gnat_ugn.texi documents caveats for globally set C_INCLUDE_PATH
when using more than one compiler. [It's the only user of :envvar:`` in
the tree, everybody else seems to use @env{} btw.] I cannot judge if
ada is aware of pulling in CPATH or if maybe they somehow prevent this,
didn't look.
Thoughts on the env vars for fortran preprocessing?
thanks,
>
> Bootstrapped and regtested on x86_64-unknown-linux without regressions.
> Ok for tunk?
>
> Bernhard Reutner-Fischer (2):
> Add free_cpp_dirs()
> Fortran: Fix memory leak in gfc_add_include_path [PR68800]
>
> gcc/fortran/cpp.c | 13 +++--
> gcc/fortran/cpp.h | 1 +
> gcc/fortran/f95-lang.c | 2 +-
> gcc/fortran/scanner.c | 7 ---
> gcc/incpath.c | 13 +
> gcc/incpath.h | 1 +
> 6 files changed, 31 insertions(+), 6 deletions(-)
>
