Re: [PING, PATCH] fortran: fix -MT/-MQ adding additional target [PR47485]

[Jerry D]

Committed as:

commit e41a5a2a0832509fa1c0b7cab0c8001fadbd23d4 (HEAD -> master, 
origin/master, origin/HEAD)

Author: Jerry DeLisle 
Date:   Tue Feb 4 17:21:42 2025 -0800

Fortran: Fix PR 47485.

The -MT and -MQ options should replace the default target in the
generated dependency file. deps_add_target needs to be called before
cpp_read_main_file, otherwise the original object name is added.

Contributed by Vincent Vanlaer 

PR fortran/47485

gcc/fortran/ChangeLog:

* cpp.cc: fix -MT/-MQ adding additional target instead of
replacing the default.

gcc/testsuite/ChangeLog:

* gfortran.dg/dependency_generation_1.f90: New test.

Signed-off-by: Vincent Vanlaer 

[15 Regression]: seg fault on accessing an elemental procedure dummy argument's deferred-length character component

[Damian Rouson]

I'm attempting to submit the code below to Bugzilla, but the site
appears to be hanging.  I'll try again later.  Presumably this should
be added to the deferred-length character metabug.  This code executes
without error when compiled with gfortran 14.2.0, but seg faults when
compiled with a recent build of gfortran 15.

Damian

% cat all.f90
  implicit none

  type string_t
character(len=:), allocatable :: string_
  end type

  call check_allocation([foo()])

contains

  type(string_t) function foo()
foo%string_ = "foo"
  end function

  elemental subroutine check_allocation(string)
type(string_t), intent(in) ::  string
if (.not. allocated(string%string_)) error stop "unallocated"
  end subroutine

end

rouson@rouson-m73 julienne % gfortran all.f90

rouson@rouson-m73 julienne % ./a.out
a.out(64876,0x1eeb90f40) malloc: *** error for object 0x60bd8030:
pointer being freed was not allocated
a.out(64876,0x1eeb90f40) malloc: *** set a breakpoint in
malloc_error_break to debug

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0  0x1031a2b63
#1  0x1031a1ae3
#2  0x186d72583
#3  0x186d41c1f
#4  0x186c4ea2f
#5  0x186b5edc3
#6  0x186b6242f
#7  0x186b7c493
#8  0x102b33d57
#9  0x102b33e5b
zsh: abort  ./a.out

rouson@rouson-m73 julienne % gfortran --version
GNU Fortran (GCC) 15.0.1 20250119 (experimental)

Bug 118750 - [14/15 Regression] ICE on associate with elemental function with polymorphic array actual argument

[Damian Rouson]

I just submitted the following as the above PR:

The code below compiles without error with gfortran 12 and 13 but
causes internal compiler errors with gfortran 14.2.0 and 15.

% cat all.f90
  implicit none

  type string_t
  end type

  associate(string_array => get_string([string_t::]))
  end associate

contains

  type(string_t) elemental function get_string(mold)
class(string_t), intent(in) :: mold
get_string = string_t()
  end function

end

% gfortran-14 all.f90
all.f90:6:53:

6 |   associate(string_array => get_string([string_t::]))
  | 1
internal compiler error: Segmentation fault: 11
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.

% gfortran all.f90
all.f90:6:53:

6 |   associate(string_array => get_string([string_t::]))
  | 1
internal compiler error: in gfc_get_descriptor_field, at
fortran/trans-array.cc:248
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.

% gfortran --version
GNU Fortran (GCC) 15.0.1 20250119 (experimental)

[committed] fortran/trans-openmp.cc: Use the correct member in gfc_omp_namelist [PR118745]

[Tobias Burnus]

Found using UBSAN - and thanks to Martin for running it with UBSAN
and reporting it!

append_args and adjust_args can be easily confused being spelled
rather similarly and being used in the same code. Still, it makes
sense to use the right list...

(It seems as if the pointer dereferencing actually does not happen,
i.e. in that sense the code is "fine" as it does not crash. Still,
having NULL + some offset is not the best pointee.)

Committed asr15-7366-g3a5882707df50e Tobias
commit 3a5882707df50ed29905b3c47cbaa0868ea248c9
Author: Tobias Burnus 
Date:   Wed Feb 5 08:44:41 2025 +0100

fortran/trans-openmp.cc: Use the correct member in gfc_omp_namelist [PR118745]

gcc/fortran/ChangeLog:

PR fortran/118745
* trans-openmp.cc (gfc_trans_omp_declare_variant): Use
append_args_list in the condition for the append_arg location.
---
 gcc/fortran/trans-openmp.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/fortran/trans-openmp.cc b/gcc/fortran/trans-openmp.cc
index a593f5a8e5e..e29ef85ae39 100644
--- a/gcc/fortran/trans-openmp.cc
+++ b/gcc/fortran/trans-openmp.cc
@@ -8839,7 +8839,7 @@ gfc_trans_omp_declare_variant (gfc_namespace *ns)
 		last_arg->next = extra_arg;
 	  else if (extra_arg)
 		variant_proc_sym->formal = extra_arg;
-	  locus *loc = (odv->adjust_args_list
+	  locus *loc = (odv->append_args_list
 			? &odv->append_args_list->where :  &odv->where);
 	  int nextra_arg = 0;
 	  for (; extra_arg; extra_arg = extra_arg->next)

Re: [Patch, fortran] PR115265 - Generic function for constructor not invoked for same-name derived type with procedure pointer component

[Andre Vehreschild]

Hi Paul,

when the testcase adds a new way, that is not tested yet, then please add it.
Otherwise I'd say there are already enough tests in the suite making it run for
a long time.

Did you try how easy the backport is? When it simply applies, then I'd say, do
it. If you experience major issues, then I would not do it. Breaking 14 may be
worse then asking two customers to proceed to 15.

So far my voice. Other opinions highly welcome.

- Andre

On Tue, 4 Feb 2025 09:35:34 +
Paul Richard Thomas  wrote:

> Hi All,
>
> This PR was fixed by the patch for PR109066. I have had the attached
> testcase in my tree for more than a week now and I propose to push it
> tomorrow, unless there are any objections.
>
> The reporter has requested that the patch be backported. Neither PR is a
> regression and component defined assignment is so wrongly implemented that
> it will have to be reworked in 16. However, I am perfectly prepared to do
> the backport, which should keep at least two customers happy :-) Thoughts?
>
> Regards
>
> Paul


--
Andre Vehreschild * Email: vehre ad gmx dot de

Re: [PING, PATCH] fortran: fix -MT/-MQ adding additional target [PR47485]

[Jerry D]

On 2/3/25 4:46 PM, Vincent Vanlaer wrote:




On 4/02/2025 01:42, Jerry D wrote:

On 2/3/25 2:14 PM, Vincent Vanlaer wrote:

Hi all,

Gentle ping for the patch below: https://gcc.gnu.org/pipermail/ 
fortran/2024-December/061467.html


Best wishes,
Vincent

On 30/12/2024 00:19, Vincent Vanlaer wrote:

The -MT and -MQ options should replace the default target in the
generated dependency file. deps_add_target needs to be called before
cpp_read_main_file, otherwise the original object name is added.

gcc/fortran/
PR fortran/47485
* cpp.cc: fix -MT/-MQ adding additional target instead of
  replacing the default

gcc/testsuite/
PR fortran/47485
* gfortran.dg/dependency_generation_1.f90: New test

Signed-off-by: Vincent Vanlaer 
---
  gcc/fortran/cpp.cc | 18 +++ 
+--

  .../gfortran.dg/dependency_generation_1.f90    | 15 +++
  2 files changed, 27 insertions(+), 6 deletions(-)
  create mode 100644 gcc/testsuite/gfortran.dg/ 
dependency_generation_1.f90


diff --git a/gcc/fortran/cpp.cc b/gcc/fortran/cpp.cc
index 7c5f00cfd69..3b93d17b90f 100644
--- a/gcc/fortran/cpp.cc
+++ b/gcc/fortran/cpp.cc
@@ -96,6 +96,8 @@ struct gfc_cpp_option_data
    int deps_skip_system; /* -MM */
    const char *deps_filename;    /* -M[M]D */
    const char *deps_filename_user;   /* -MF  */
+  const char *deps_target_filename; /* -MT / -MQ  */
+  bool quote_deps_target_filename;  /* -MQ */
    int deps_missing_are_generated;   /* -MG */
    int deps_phony;   /* -MP */
    int warn_date_time;   /* -Wdate-time */
@@ -287,6 +289,8 @@ gfc_cpp_init_options (unsigned int 
decoded_options_count,

    gfc_cpp_option.deps_missing_are_generated = 0;
    gfc_cpp_option.deps_filename = NULL;
    gfc_cpp_option.deps_filename_user = NULL;
+  gfc_cpp_option.deps_target_filename = NULL;
+  gfc_cpp_option.quote_deps_target_filename = false;
    gfc_cpp_option.multilib = NULL;
    gfc_cpp_option.prefix = NULL;
@@ -439,9 +443,8 @@ gfc_cpp_handle_option (size_t scode, const char 
*arg, int value ATTRIBUTE_UNUSED

  case OPT_MQ:
  case OPT_MT:
- 
gfc_cpp_option.deferred_opt[gfc_cpp_option.deferred_opt_count].code 
= code;
- gfc_cpp_option.deferred_opt[gfc_cpp_option.deferred_opt_count].arg 
= arg;

-  gfc_cpp_option.deferred_opt_count++;
+  gfc_cpp_option.quote_deps_target_filename = (code == OPT_MQ);
+  gfc_cpp_option.deps_target_filename = arg;
    break;
  case OPT_P:
@@ -593,6 +596,12 @@ gfc_cpp_init_0 (void)
  }
    gcc_assert(cpp_in);
+
+  if (gfc_cpp_option.deps_target_filename)
+    if (mkdeps *deps = cpp_get_deps (cpp_in))
+  deps_add_target (deps, gfc_cpp_option.deps_target_filename,
+   gfc_cpp_option.quote_deps_target_filename);
+
    if (!cpp_read_main_file (cpp_in, gfc_source_file))
  errorcount++;
  }
@@ -635,9 +644,6 @@ gfc_cpp_init (void)
    else
  cpp_assert (cpp_in, opt->arg);
  }
-  else if (opt->code == OPT_MT || opt->code == OPT_MQ)
-    if (mkdeps *deps = cpp_get_deps (cpp_in))
-  deps_add_target (deps, opt->arg, opt->code == OPT_MQ);
  }
    /* Pre-defined macros for non-required INTEGER kind types.  */
diff --git a/gcc/testsuite/gfortran.dg/dependency_generation_1.f90 
b/ gcc/testsuite/gfortran.dg/dependency_generation_1.f90

new file mode 100644
index 000..d42a257f83a
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/dependency_generation_1.f90
@@ -0,0 +1,15 @@
+! This test case ensures that the -MT flag is correctly replacing 
the object name in the dependency file.

+! See PR 47485
+!
+! Contributed by Vincent Vanlaer 
+!
+! { dg-do preprocess }
+! { dg-additional-options "-cpp" }
+! { dg-additional-options "-M" }
+! { dg-additional-options "-MF deps" }
+! { dg-additional-options "-MT obj.o" }
+
+module test
+end module
+
+! { dg-final { scan-file "deps" "obj.o:.*" } }




Do you have commit rights to gcc? I did not catch your original post.

Jerry


I do not, this is my first time contributing to GCC.

Vincent


This all looks reasonable to me. I will push this if no objections come 
in today.


Regards,

Jerry

Re: [15 Regression]: seg fault on accessing an elemental procedure dummy argument's deferred-length character component

[Damian Rouson]

This is now PR 118747 and it has been marked as blocking 68241.

D

On Tue, Feb 4, 2025 at 10:10 AM Damian Rouson  wrote:
>
> I'm attempting to submit the code below to Bugzilla, but the site
> appears to be hanging.  I'll try again later.  Presumably this should
> be added to the deferred-length character metabug.  This code executes
> without error when compiled with gfortran 14.2.0, but seg faults when
> compiled with a recent build of gfortran 15.
>
> Damian
>
> % cat all.f90
>   implicit none
>
>   type string_t
> character(len=:), allocatable :: string_
>   end type
>
>   call check_allocation([foo()])
>
> contains
>
>   type(string_t) function foo()
> foo%string_ = "foo"
>   end function
>
>   elemental subroutine check_allocation(string)
> type(string_t), intent(in) ::  string
> if (.not. allocated(string%string_)) error stop "unallocated"
>   end subroutine
>
> end
>
> rouson@rouson-m73 julienne % gfortran all.f90
>
> rouson@rouson-m73 julienne % ./a.out
> a.out(64876,0x1eeb90f40) malloc: *** error for object 0x60bd8030:
> pointer being freed was not allocated
> a.out(64876,0x1eeb90f40) malloc: *** set a breakpoint in
> malloc_error_break to debug
>
> Program received signal SIGABRT: Process abort signal.
>
> Backtrace for this error:
> #0  0x1031a2b63
> #1  0x1031a1ae3
> #2  0x186d72583
> #3  0x186d41c1f
> #4  0x186c4ea2f
> #5  0x186b5edc3
> #6  0x186b6242f
> #7  0x186b7c493
> #8  0x102b33d57
> #9  0x102b33e5b
> zsh: abort  ./a.out
>
> rouson@rouson-m73 julienne % gfortran --version
> GNU Fortran (GCC) 15.0.1 20250119 (experimental)

Re: [PING, PATCH] fortran: fix -MT/-MQ adding additional target [PR47485]

[Jerry D]

On 2/4/25 9:29 AM, Jerry D wrote:

On 2/3/25 4:46 PM, Vincent Vanlaer wrote:




On 4/02/2025 01:42, Jerry D wrote:

On 2/3/25 2:14 PM, Vincent Vanlaer wrote:

Hi all,

Gentle ping for the patch below: https://gcc.gnu.org/pipermail/ 
fortran/2024-December/061467.html


Best wishes,
Vincent

On 30/12/2024 00:19, Vincent Vanlaer wrote:

The -MT and -MQ options should replace the default target in the
generated dependency file. deps_add_target needs to be called before
cpp_read_main_file, otherwise the original object name is added.

gcc/fortran/
PR fortran/47485
* cpp.cc: fix -MT/-MQ adding additional target instead of
  replacing the default

gcc/testsuite/
PR fortran/47485
* gfortran.dg/dependency_generation_1.f90: New test

Signed-off-by: Vincent Vanlaer 
---
  gcc/fortran/cpp.cc | 18 +++ 
+--

  .../gfortran.dg/dependency_generation_1.f90    | 15 +++
  2 files changed, 27 insertions(+), 6 deletions(-)
  create mode 100644 gcc/testsuite/gfortran.dg/ 
dependency_generation_1.f90


diff --git a/gcc/fortran/cpp.cc b/gcc/fortran/cpp.cc
index 7c5f00cfd69..3b93d17b90f 100644
--- a/gcc/fortran/cpp.cc
+++ b/gcc/fortran/cpp.cc
@@ -96,6 +96,8 @@ struct gfc_cpp_option_data
    int deps_skip_system; /* -MM */
    const char *deps_filename;    /* -M[M]D */
    const char *deps_filename_user;   /* -MF  */
+  const char *deps_target_filename; /* -MT / -MQ  */
+  bool quote_deps_target_filename;  /* -MQ */
    int deps_missing_are_generated;   /* -MG */
    int deps_phony;   /* -MP */
    int warn_date_time;   /* -Wdate-time */
@@ -287,6 +289,8 @@ gfc_cpp_init_options (unsigned int 
decoded_options_count,

    gfc_cpp_option.deps_missing_are_generated = 0;
    gfc_cpp_option.deps_filename = NULL;
    gfc_cpp_option.deps_filename_user = NULL;
+  gfc_cpp_option.deps_target_filename = NULL;
+  gfc_cpp_option.quote_deps_target_filename = false;
    gfc_cpp_option.multilib = NULL;
    gfc_cpp_option.prefix = NULL;
@@ -439,9 +443,8 @@ gfc_cpp_handle_option (size_t scode, const char 
*arg, int value ATTRIBUTE_UNUSED

  case OPT_MQ:
  case OPT_MT:
- 
gfc_cpp_option.deferred_opt[gfc_cpp_option.deferred_opt_count].code 
= code;
- 
gfc_cpp_option.deferred_opt[gfc_cpp_option.deferred_opt_count].arg 
= arg;

-  gfc_cpp_option.deferred_opt_count++;
+  gfc_cpp_option.quote_deps_target_filename = (code == OPT_MQ);
+  gfc_cpp_option.deps_target_filename = arg;
    break;
  case OPT_P:
@@ -593,6 +596,12 @@ gfc_cpp_init_0 (void)
  }
    gcc_assert(cpp_in);
+
+  if (gfc_cpp_option.deps_target_filename)
+    if (mkdeps *deps = cpp_get_deps (cpp_in))
+  deps_add_target (deps, gfc_cpp_option.deps_target_filename,
+   gfc_cpp_option.quote_deps_target_filename);
+
    if (!cpp_read_main_file (cpp_in, gfc_source_file))
  errorcount++;
  }
@@ -635,9 +644,6 @@ gfc_cpp_init (void)
    else
  cpp_assert (cpp_in, opt->arg);
  }
-  else if (opt->code == OPT_MT || opt->code == OPT_MQ)
-    if (mkdeps *deps = cpp_get_deps (cpp_in))
-  deps_add_target (deps, opt->arg, opt->code == OPT_MQ);
  }
    /* Pre-defined macros for non-required INTEGER kind types.  */
diff --git a/gcc/testsuite/gfortran.dg/dependency_generation_1.f90 
b/ gcc/testsuite/gfortran.dg/dependency_generation_1.f90

new file mode 100644
index 000..d42a257f83a
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/dependency_generation_1.f90
@@ -0,0 +1,15 @@
+! This test case ensures that the -MT flag is correctly replacing 
the object name in the dependency file.

+! See PR 47485
+!
+! Contributed by Vincent Vanlaer 
+!
+! { dg-do preprocess }
+! { dg-additional-options "-cpp" }
+! { dg-additional-options "-M" }
+! { dg-additional-options "-MF deps" }
+! { dg-additional-options "-MT obj.o" }
+
+module test
+end module
+
+! { dg-final { scan-file "deps" "obj.o:.*" } }




Do you have commit rights to gcc? I did not catch your original post.

Jerry


I do not, this is my first time contributing to GCC.

Vincent


This all looks reasonable to me. I will push this if no objections come 
in today.


Regards,

Jerry


Regression tested OK. New test case passes.

So far all is well. Standing by for any other comments.

Jerry

Re: [PATCH] OpenMP: Improve Fortran metadirective diagnostics [PR107067]

[Tobias Burnus]

Hi Sandra, hello world,

Sandra Loosemore wrote:

gcc/fortran/ChangeLog
PR middle-end/107067
* parse.cc (parse_omp_do): Diagnose missing "OMP END METADIRECTIVE"
after loop.
(parse_omp_structured_block): Likewise for strictly structured block.
(parse_omp_metadirective_body): Use better test for variants ending
at different places.  Issue a user diagnostic at the end if any
were inconsistent, instead of calling gcc_assert.

gcc/testsuite/ChangeLog
PR middle-end/107067
* gfortran.dg/gomp/metadirective-11.f90: Remove the dg-ice, update
for current behavior, and add more tests to exercise the new error
code.


First, a generic comment/rant: The OpenMP specification is vague enough to
make it rather unclear what exactly is supposed to be valid or not as it
both acts like a processor (one version wins and is then applied) and also
not (dynamic statements etc.).

(Note that 'omp atomic' with 'capture' consists of two statements: the
capture and the atomic update, which usually there is only one 
statement/construct
following a metadirective - or a delimited metadirective is required.)

For the following code,


--- a/gcc/testsuite/gfortran.dg/gomp/metadirective-11.f90
+++ b/gcc/testsuite/gfortran.dg/gomp/metadirective-11.f90

...

+   ! The "nothing" directive in a non-begin/end metadirective only applies to a
+   ! a single statement or block, while "atomic capture" permits multiple
+   ! assignment statements.
+   !$OMP metadirective &
+   !$OMP   when ( user = { condition ( UseDevice ) } &
+   !$OMP : nothing ) &
+   !$OMP   default (atomic capture)  ! { dg-error "Variants in a metadirective at 
.1. have different associations" }
+   n = n + 1; v = n


[IMHO when glancing at the code, it is not obvious why the compiler chokes
on it. And while the error message makes sense, it is not necessarily
clear enough for a struggling.]


It is rather unclear whether that is supposed to valid or not. If one just
applies 'nothing' that's clearly valid – but on the other hand, assuming
the normal block handling, it is not.

I think choosing not to handle it and print an error is fine. Albeit, as
mentioned, I find


+  if (saw_error)
+gfc_error_now ("Variants in a metadirective at %L have "
+  "different associations", &body_locus);
+


... not that helpful as error message and wonder whether GCC should give
a hint to the user how to solve the issue.

I could imagine adding the suggestion to the error message (to the
gfc_error_now message) - or it could be separate (cf. below).

Using BLOCK should always work - whether the OpenMP directive is
associated with a block or not.  If it is associated with a block
also the delimited form of metadirectives works.

How to do it inside gfc_error_now is obvious (and preexisting in
several gfortran error message). To add the hint after the actual
error, something like the following could be used:

inform (gfc_get_location(&body_locus),
"Consider enclosing in a BLOCK construct or using the "
"BEGIN/END METADIRECTIVE construct");

* * *

To conclude: The patch LGTM but consider giving the user some hint
how to solve it, e.g. using one of the ideas above.

Thanks for the patch!

Tobias

[Patch, fortran] PR115265 - Generic function for constructor not invoked for same-name derived type with procedure pointer component

[Paul Richard Thomas]

Hi All,

This PR was fixed by the patch for PR109066. I have had the attached
testcase in my tree for more than a week now and I propose to push it
tomorrow, unless there are any objections.

The reporter has requested that the patch be backported. Neither PR is a
regression and component defined assignment is so wrongly implemented that
it will have to be reworked in 16. However, I am perfectly prepared to do
the backport, which should keep at least two customers happy :-) Thoughts?

Regards

Paul
! { dg-do run }
!
! PR115265 was fixed by the patch for PR109066. This testcase makes sure
! that it stays that way :-)
!
! Contributed by Matthew Krupcale  
!
module t_mod
  implicit none
  private
  public :: t, my_f, extract_y_

  type t
 procedure(t_f), pointer, nopass :: f
 integer, dimension(:), allocatable :: x
 integer, private, dimension(:), allocatable :: y_
   contains
 final :: t_destructor
 procedure :: y => t_y
  end type t

  interface t
 module procedure t_constructor
  end interface t

  abstract interface
 subroutine t_f(x, y)
   integer, intent(in) :: x(:)
   integer, intent(out) :: y(:)
 end subroutine t_f
  end interface

contains

  function t_constructor(f, x)
implicit none

procedure(t_f), pointer, intent(in) :: f
integer, dimension(:), intent(in) :: x
type(t) :: t_constructor

integer :: n

n = size(x)

allocate(t_constructor%x(n))
allocate(t_constructor%y_(n))

t_constructor%f => f
t_constructor%x = x

  end function t_constructor

  subroutine t_destructor(this)
implicit none

type(t), intent(inout) :: this

if (allocated(this%x)) deallocate(this%x)
if (allocated(this%y_)) deallocate(this%y_)

  end subroutine t_destructor

  subroutine t_y(this)
implicit none

class(t), intent(inout) :: this

call this%f(this%x, this%y_)

  end subroutine t_y

  subroutine my_f(x, y)
implicit none
integer, intent(in) :: x(:)
integer, intent(out) :: y(:)

y = 2 * x  ! Runtime segfault here

  end subroutine my_f

  function extract_y_ (arg) result (res)
integer, dimension(:), allocatable :: res
type(t) :: arg
res = arg%y_
  end function extract_y_

end module t_mod

program main
  use t_mod
  implicit none

  type(t) :: my_t, res
  my_t = t(my_f, [1, 2, 3])
  call my_t%y()
  if (any (extract_y_ (my_t) .ne. [2,4,6])) stop 1

end program main