[committed] Fortran: Fix character(len=cst) dummies with bind(C) [PR102885] (erratum: should be: 'len=noncst')

2021-10-26 Thread Tobias Burnus

I forgot to handle len= correctly. This patch does the
same as for non-BIND(C). In the latter case, the call is:

  gfc_generate_function_code → gfc_trans_deferred_vars → 
gfc_trans_deferred_array

and that function has

  if (sym->ts.type == BT_CHARACTER
  && !INTEGER_CST_P (sym->ts.u.cl->backend_decl))
{
  gfc_conv_string_length (sym->ts.u.cl, NULL, &init);
  gfc_trans_vla_type_sizes (sym, &init);
}

Expect a déjà vu if you read the attached patch ...

Thanks to Dominique for testing with -flto and finding this issue
and to Richard for helping me to understand what goes wrong.

Committed as obvious as r12-4703.

Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
commit a31a3d0421f0cf1f7eefacfec8cbf37e7f91600d
Author: Tobias Burnus 
Date:   Tue Oct 26 10:53:53 2021 +0200

Fortran: Fix character(len=cst) dummies with bind(C) [PR102885]

PR fortran/102885

gcc/fortran/ChangeLog:

* trans-decl.c (gfc_conv_cfi_to_gfc): Properly handle nonconstant
character lenghts.

gcc/testsuite/ChangeLog:

* gfortran.dg/lto/bind-c-char_0.f90: New test.
---
 gcc/fortran/trans-decl.c|  7 
 gcc/testsuite/gfortran.dg/lto/bind-c-char_0.f90 | 49 +
 2 files changed, 56 insertions(+)

diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index fe5511b5285..49ba9060eae 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -6837,6 +6837,13 @@ gfc_conv_cfi_to_gfc (stmtblock_t *init, stmtblock_t *finally,
   gfc_add_modify (&block, sym->ts.u.cl->backend_decl, tmp);
 }
 
+  if (sym->ts.type == BT_CHARACTER
+  && !INTEGER_CST_P (sym->ts.u.cl->backend_decl))
+{
+  gfc_conv_string_length (sym->ts.u.cl, NULL, init);
+  gfc_trans_vla_type_sizes (sym, init);
+}
+
   /* gfc->data = cfi->base_addr - or for scalars: gfc = cfi->base_addr.
  assumed-size/explicit-size arrays end up here for character(len=*)
  only. */
diff --git a/gcc/testsuite/gfortran.dg/lto/bind-c-char_0.f90 b/gcc/testsuite/gfortran.dg/lto/bind-c-char_0.f90
new file mode 100644
index 000..48b495b1d29
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/lto/bind-c-char_0.f90
@@ -0,0 +1,49 @@
+! { dg-lto-do link }
+! { dg-lto-options {{ -O0 -flto }} }
+!
+! PR fortran/102885
+
+module m
+  use iso_c_binding, only: c_char
+  implicit none (type, external)
+
+contains
+
+! Assumed-shape array, nonallocatable/nonpointer
+
+subroutine ar3 (xn, n) bind(C)
+  integer :: n
+  character(len=n) :: xn(..)
+  if (size(xn) /= 6) stop
+  if (len(xn) /= 5) stop  
+  select rank(xn)
+rank(1)
+  xn = ['FDGhf', &
+'hdrhg', &
+'fDgFl', &
+'DFHs3', &
+'4a54G', &
+'hSs6k']
+  rank default
+stop
+  end select
+end
+
+end
+
+program main
+  use m
+  implicit none (type, external)
+  character(kind=c_char, len=5) :: str5a6(6)
+
+  ! assumed rank - with array descriptor
+
+  str5a6 = ['DDGhf', &
+'hdrh$', &
+'fDGSl', &
+'DFHs3', &
+'43grG', &
+'hFG$k']
+  call ar3 (str5a6, 5)
+
+end


Re: [PATCH,Fortran 3/7] Fortran: make some constructor* functions static

2021-10-26 Thread Tobias Burnus

On 25.10.21 00:30, Bernhard Reutner-Fischer via Fortran wrote:

From: Bernhard Reutner-Fischer 
gfc_constructor_expr_foreach and gfc_constructor_swap were just stubs.
gcc/fortran/ChangeLog:

  * constructor.c (gfc_constructor_get_base): Make static.
  (gfc_constructor_expr_foreach, (gfc_constructor_swap): Delete.
  * constructor.h (gfc_constructor_get_base): Remove declaration.
  (gfc_constructor_expr_foreach, (gfc_constructor_swap): Delete.


OK. Thanks for the cleanup.

Tobias


---
  gcc/fortran/constructor.c | 20 ++--
  gcc/fortran/constructor.h | 10 --
  2 files changed, 2 insertions(+), 28 deletions(-)

diff --git a/gcc/fortran/constructor.c b/gcc/fortran/constructor.c
index 3e4377a5ad3..4b5a748271b 100644
--- a/gcc/fortran/constructor.c
+++ b/gcc/fortran/constructor.c
@@ -85,7 +85,8 @@ gfc_constructor_get (void)
return c;
  }

-gfc_constructor_base gfc_constructor_get_base (void)
+static gfc_constructor_base
+gfc_constructor_get_base (void)
  {
return splay_tree_new (splay_tree_compare_ints, NULL, node_free);
  }
@@ -209,23 +210,6 @@ gfc_constructor_lookup_expr (gfc_constructor_base base, 
int offset)
  }


-int
-gfc_constructor_expr_foreach (gfc_constructor *ctor ATTRIBUTE_UNUSED,
-   int(*f)(gfc_expr *) ATTRIBUTE_UNUSED)
-{
-  gcc_assert (0);
-  return 0;
-}
-
-void
-gfc_constructor_swap (gfc_constructor *ctor ATTRIBUTE_UNUSED,
-  int n ATTRIBUTE_UNUSED, int m ATTRIBUTE_UNUSED)
-{
-  gcc_assert (0);
-}
-
-
-
  gfc_constructor *
  gfc_constructor_first (gfc_constructor_base base)
  {
diff --git a/gcc/fortran/constructor.h b/gcc/fortran/constructor.h
index 85a72dcfc0e..25cd6a8f192 100644
--- a/gcc/fortran/constructor.h
+++ b/gcc/fortran/constructor.h
@@ -23,8 +23,6 @@ along with GCC; see the file COPYING3.  If not see
  /* Get a new constructor structure.  */
  gfc_constructor *gfc_constructor_get (void);

-gfc_constructor_base gfc_constructor_get_base (void);
-
  /* Copy a constructor structure.  */
  gfc_constructor_base gfc_constructor_copy (gfc_constructor_base base);

@@ -64,14 +62,6 @@ gfc_constructor *gfc_constructor_lookup 
(gfc_constructor_base base, int n);
  */
  gfc_expr *gfc_constructor_lookup_expr (gfc_constructor_base base, int n);

-
-int gfc_constructor_expr_foreach (gfc_constructor *ctor, int(*)(gfc_expr *));
-
-
-void gfc_constructor_swap (gfc_constructor *ctor, int n, int m);
-
-
-
  /* Get the first constructor node in the constructure structure.
 Returns NULL if there is no such expression.  */
  gfc_constructor *gfc_constructor_first (gfc_constructor_base base);

-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955


Re: [PATCH,Fortran 1/7] Fortran: make some trans* functions static

2021-10-26 Thread Tobias Burnus

On 25.10.21 00:30, Bernhard Reutner-Fischer via Fortran wrote:


From: Bernhard Reutner-Fischer 

This makes some trans* functions static and deletes declarations of
functions that either do not exist anymore like gfc_get_function_decl
or that are unused like gfc_check_any_c_kind.

gcc/fortran/ChangeLog:
  * expr.c (is_non_empty_structure_constructor): Make static.
  * gfortran.h (gfc_check_any_c_kind): Delete.
  * match.c (gfc_match_label): Make static.
  * match.h (gfc_match_label): Delete declaration.
  * scanner.c (file_changes_cur, file_changes_count,
  file_changes_allocated): Make static.
  * trans-expr.c (gfc_get_character_len): Make static.
  (gfc_class_len_or_zero_get): Make static.
  (VTAB_GET_FIELD_GEN): Undefine.
  (gfc_get_class_array_ref): Make static.
  (gfc_finish_interface_mapping): Make static.
  * trans-types.c (gfc_check_any_c_kind): Delete.
  (pfunc_type_node, dtype_type_node, gfc_get_ppc_type): Make static.
  * trans-types.h (gfc_get_ppc_type): Delete declaration.
  * trans.c (gfc_msg_wrong_return): Delete.
  * trans.h (gfc_class_len_or_zero_get, gfc_class_vtab_extends_get,
  gfc_vptr_extends_get, gfc_get_class_array_ref, gfc_get_character_len,
  gfc_finish_interface_mapping, gfc_msg_wrong_return,
  gfc_get_function_decl): Delete declaration.


OK.

Thanks for the cleanup!

Tobias


---
  gcc/fortran/expr.c|  2 +-
  gcc/fortran/gfortran.h|  1 -
  gcc/fortran/match.c   |  2 +-
  gcc/fortran/match.h   |  1 -
  gcc/fortran/scanner.c |  4 ++--
  gcc/fortran/trans-expr.c  | 10 +-
  gcc/fortran/trans-types.c | 25 +++--
  gcc/fortran/trans-types.h |  1 -
  gcc/fortran/trans.c   |  1 -
  gcc/fortran/trans.h   | 11 ---
  10 files changed, 12 insertions(+), 46 deletions(-)

diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index b19d3a26c60..4dea840e348 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -4817,7 +4817,7 @@ gfc_apply_init (gfc_typespec *ts, symbol_attribute *attr, 
gfc_expr *init)
  /* Check whether an expression is a structure constructor and whether it has
 other values than NULL.  */

-bool
+static bool
  is_non_empty_structure_constructor (gfc_expr * e)
  {
if (e->expr_type != EXPR_STRUCTURE)
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 66192c07d8c..f7662c59a5d 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -3284,7 +3284,6 @@ bool gfc_check_character_range (gfc_char_t, int);
  extern bool gfc_seen_div0;

  /* trans-types.c */
-bool gfc_check_any_c_kind (gfc_typespec *);
  int gfc_validate_kind (bt, int, bool);
  int gfc_get_int_kind_from_width_isofortranenv (int size);
  int gfc_get_real_kind_from_width_isofortranenv (int size);
diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index 53a575e616e..91cde55d7a1 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -599,7 +599,7 @@ cleanup:
 it.  We also make sure the symbol does not refer to another
 (active) block.  A matched label is pointed to by gfc_new_block.  */

-match
+static match
  gfc_match_label (void)
  {
char name[GFC_MAX_SYMBOL_LEN + 1];
diff --git a/gcc/fortran/match.h b/gcc/fortran/match.h
index 21e94f79d95..eb9459ea99c 100644
--- a/gcc/fortran/match.h
+++ b/gcc/fortran/match.h
@@ -47,7 +47,6 @@ match gfc_match_space (void);
  match gfc_match_eos (void);
  match gfc_match_small_literal_int (int *, int *);
  match gfc_match_st_label (gfc_st_label **);
-match gfc_match_label (void);
  match gfc_match_small_int (int *);
  match gfc_match_small_int_expr (int *, gfc_expr **);
  match gfc_match_name (char *);
diff --git a/gcc/fortran/scanner.c b/gcc/fortran/scanner.c
index 5a450692ba3..69b81ab97f8 100644
--- a/gcc/fortran/scanner.c
+++ b/gcc/fortran/scanner.c
@@ -78,8 +78,8 @@ static struct gfc_file_change
gfc_linebuf *lb;
int line;
  } *file_changes;
-size_t file_changes_cur, file_changes_count;
-size_t file_changes_allocated;
+static size_t file_changes_cur, file_changes_count;
+static size_t file_changes_allocated;

  static gfc_char_t *last_error_char;

diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 2d7f9e0fb91..e7aec3845d3 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -45,7 +45,7 @@ along with GCC; see the file COPYING3.  If not see

  /* Calculate the number of characters in a string.  */

-tree
+static tree
  gfc_get_character_len (tree type)
  {
tree len;
@@ -278,7 +278,7 @@ gfc_class_len_get (tree decl)
  /* Try to get the _len component of a class.  When the class is not unlimited
 poly, i.e. no _len field exists, then return a zero node.  */

-tree
+static tree
  gfc_class_len_or_zero_get (tree decl)
  {
tree len;
@@ -382,7 +382,7 @@ VTAB_GET_FIELD_GEN (def_init, VTABLE_DEF_INIT_FIELD)
  VTAB_GET_FIELD_GEN (copy, VTABLE_COPY_FIELD)
  VTAB_GET_FIELD_GEN (final, VTABLE_FINAL_FIELD)
  VTAB_GET_FIELD_GEN (dealloc

Re: [PATCH,Fortran 2/7] Fortran: make some match* functions static

2021-10-26 Thread Tobias Burnus

On 25.10.21 00:30, Bernhard Reutner-Fischer via Gcc-patches wrote:


From: Bernhard Reutner-Fischer 

gfc_match_small_int_expr was unused, delete it.
gfc_match_gcc_unroll should use gfc_match_small_literal_int and then

(but wasn't in this patch)

gfc_match_small_int can be deleted since it will be unused.

gcc/fortran/ChangeLog:

  * decl.c (gfc_match_old_kind_spec, set_com_block_bind_c,
  set_verify_bind_c_sym, set_verify_bind_c_com_block,
  get_bind_c_idents, gfc_match_suffix, gfc_get_type_attr_spec,
  (check_extended_derived_type): Make static.
  (gfc_match_gcc_unroll): Add comment.
  * match.c (gfc_match_small_int_expr): Delete definition.
  * match.h (gfc_match_small_int_expr): Delete declaration.
  (gfc_match_name_C, gfc_match_old_kind_spec, set_com_block_bind_c,
  set_verify_bind_c_sym, set_verify_bind_c_com_block,
  get_bind_c_idents, gfc_match_suffix,
  gfc_get_type_attr_spec): Delete declaration.


OK. Thanks for the cleanup.

Tobias


---
  gcc/fortran/decl.c  | 15 ---
  gcc/fortran/match.c | 26 --
  gcc/fortran/match.h |  9 -
  3 files changed, 8 insertions(+), 42 deletions(-)

diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 6043e100fbb..1e034d1b344 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -3128,7 +3128,7 @@ cleanup:
 This assumes that the byte size is equal to the kind number for
 non-COMPLEX types, and equal to twice the kind number for COMPLEX.  */

-match
+static match
  gfc_match_old_kind_spec (gfc_typespec *ts)
  {
match m;
@@ -5867,7 +5867,7 @@ set_binding_label (const char **dest_label, const char 
*sym_name,
  /* Set the status of the given common block as being BIND(C) or not,
 depending on the given parameter, is_bind_c.  */

-void
+static void
  set_com_block_bind_c (gfc_common_head *com_block, int is_bind_c)
  {
com_block->is_bind_c = is_bind_c;
@@ -6055,7 +6055,7 @@ verify_bind_c_sym (gfc_symbol *tmp_sym, gfc_typespec *ts,
 the type is C interoperable.  Errors are reported by the functions
 used to set/test these fields.  */

-bool
+static bool
  set_verify_bind_c_sym (gfc_symbol *tmp_sym, int num_idents)
  {
bool retval = true;
@@ -6075,7 +6075,7 @@ set_verify_bind_c_sym (gfc_symbol *tmp_sym, int 
num_idents)
  /* Set the fields marking the given common block as BIND(C), including
 a binding label, and report any errors encountered.  */

-bool
+static bool
  set_verify_bind_c_com_block (gfc_common_head *com_block, int num_idents)
  {
bool retval = true;
@@ -6095,7 +6095,7 @@ set_verify_bind_c_com_block (gfc_common_head *com_block, 
int num_idents)
  /* Retrieve the list of one or more identifiers that the given bind(c)
 attribute applies to.  */

-bool
+static bool
  get_bind_c_idents (void)
  {
char name[GFC_MAX_SYMBOL_LEN + 1];
@@ -6804,7 +6804,7 @@ match_result (gfc_symbol *function, gfc_symbol **result)
 clause and BIND(C), either one, or neither.  The draft does not
 require them to come in a specific order.  */

-match
+static match
  gfc_match_suffix (gfc_symbol *sym, gfc_symbol **result)
  {
match is_bind_c;   /* Found bind(c).  */
@@ -10116,7 +10116,7 @@ check_extended_derived_type (char *name)
 not a handled attribute, and MATCH_YES otherwise.  TODO: More error
 checking on attribute conflicts needs to be done.  */

-match
+static match
  gfc_get_type_attr_spec (symbol_attribute *attr, char *name)
  {
/* See if the derived type is marked as private.  */
@@ -11794,6 +11794,7 @@ gfc_match_gcc_unroll (void)
  {
int value;

+  /* FIXME: use gfc_match_small_literal_int instead, delete small_int  */
if (gfc_match_small_int (&value) == MATCH_YES)
  {
if (value < 0 || value > USHRT_MAX)
diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index 91cde55d7a1..5d07f897e45 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -530,32 +530,6 @@ gfc_match_small_int (int *value)
  }


-/* This function is the same as the gfc_match_small_int, except that
-   we're keeping the pointer to the expr.  This function could just be
-   removed and the previously mentioned one modified, though all calls
-   to it would have to be modified then (and there were a number of
-   them).  Return MATCH_ERROR if fail to extract the int; otherwise,
-   return the result of gfc_match_expr().  The expr (if any) that was
-   matched is returned in the parameter expr.  */
-
-match
-gfc_match_small_int_expr (int *value, gfc_expr **expr)
-{
-  match m;
-  int i;
-
-  m = gfc_match_expr (expr);
-  if (m != MATCH_YES)
-return m;
-
-  if (gfc_extract_int (*expr, &i, 1))
-m = MATCH_ERROR;
-
-  *value = i;
-  return m;
-}
-
-
  /* Matches a statement label.  Uses gfc_match_small_literal_int() to
 do most of the work.  */

diff --git a/gcc/fortran/match.h b/gcc/fortran/match.h
index eb9459ea99c..e9368db281d 100644
--- a/gcc/fortran/match.h
+++ b/gcc/fortran/match.h
@@ -48,9 +48,7 @@ m

Re: [PATCH,Fortran 4/7] Fortran: make some trans-array functions static

2021-10-26 Thread Tobias Burnus

On 25.10.21 00:30, Bernhard Reutner-Fischer via Fortran wrote:

From: Bernhard Reutner-Fischer 

gcc/fortran/ChangeLog:

  * trans-array.c (gfc_trans_scalarized_loop_end): Make static.
  * trans-array.h (gfc_trans_scalarized_loop_end,
  gfc_conv_tmp_ref, gfc_conv_array_transpose): Delete declaration.


(the later are declared but no longer exist)

OK. Thanks for the cleanup!

Tobias


---
  gcc/fortran/trans-array.c | 2 +-
  gcc/fortran/trans-array.h | 6 --
  2 files changed, 1 insertion(+), 7 deletions(-)

diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index bceb8b24ba4..5ceb261b698 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -4161,7 +4161,7 @@ gfc_start_scalarized_body (gfc_loopinfo * loop, 
stmtblock_t * pbody)

  /* Generates the actual loop code for a scalarization loop.  */

-void
+static void
  gfc_trans_scalarized_loop_end (gfc_loopinfo * loop, int n,
 stmtblock_t * pbody)
  {
diff --git a/gcc/fortran/trans-array.h b/gcc/fortran/trans-array.h
index 1d3dc4819eb..12068c742a5 100644
--- a/gcc/fortran/trans-array.h
+++ b/gcc/fortran/trans-array.h
@@ -118,8 +118,6 @@ void gfc_copy_loopinfo_to_se (gfc_se *, gfc_loopinfo *);

  /* Marks the start of a scalarized expression, and declares loop variables.  
*/
  void gfc_start_scalarized_body (gfc_loopinfo *, stmtblock_t *);
-/* Generates one actual loop for a scalarized expression.  */
-void  gfc_trans_scalarized_loop_end (gfc_loopinfo *, int, stmtblock_t *);
  /* Generates the actual loops for a scalarized expression.  */
  void gfc_trans_scalarizing_loops (gfc_loopinfo *, stmtblock_t *);
  /* Mark the end of the main loop body and the start of the copying loop.  */
@@ -137,8 +135,6 @@ tree gfc_build_null_descriptor (tree);
  void gfc_conv_array_ref (gfc_se *, gfc_array_ref *, gfc_expr *, locus *);
  /* Translate a reference to a temporary array.  */
  void gfc_conv_tmp_array_ref (gfc_se * se);
-/* Translate a reference to an array temporary.  */
-void gfc_conv_tmp_ref (gfc_se *);

  /* Calculate the overall offset, including subreferences.  */
  void gfc_get_dataptr_offset (stmtblock_t*, tree, tree, tree, bool, gfc_expr*);
@@ -149,8 +145,6 @@ void gfc_conv_expr_descriptor (gfc_se *, gfc_expr *);
  /* Convert an array for passing as an actual function parameter.  */
  void gfc_conv_array_parameter (gfc_se *, gfc_expr *, bool,
 const gfc_symbol *, const char *, tree *);
-/* Evaluate and transpose a matrix expression.  */
-void gfc_conv_array_transpose (gfc_se *, gfc_expr *);

  /* These work with both descriptors and descriptorless arrays.  */
  tree gfc_conv_array_data (tree);

-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955


Re: [PATCH,Fortran 5/7] Fortran: Delete unused decl in trans-stmt.h

2021-10-26 Thread Tobias Burnus

On 25.10.21 00:30, Bernhard Reutner-Fischer via Gcc-patches wrote:

From: Bernhard Reutner-Fischer 

gcc/fortran/ChangeLog:

  * trans-stmt.h (gfc_trans_deallocate_array): Delete.


OK. Thanks!

Tobias


---
  gcc/fortran/trans-stmt.h | 1 -
  1 file changed, 1 deletion(-)

diff --git a/gcc/fortran/trans-stmt.h b/gcc/fortran/trans-stmt.h
index 1a24d9b4cdc..e824caf4d08 100644
--- a/gcc/fortran/trans-stmt.h
+++ b/gcc/fortran/trans-stmt.h
@@ -66,7 +66,6 @@ tree gfc_trans_sync_team (gfc_code *);
  tree gfc_trans_where (gfc_code *);
  tree gfc_trans_allocate (gfc_code *);
  tree gfc_trans_deallocate (gfc_code *);
-tree gfc_trans_deallocate_array (tree);

  /* trans-openmp.c */
  tree gfc_trans_omp_directive (gfc_code *);

-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955


Re: [PATCH,Fortran 6/7] Fortran: Delete unused decl in trans-types.h

2021-10-26 Thread Tobias Burnus

On 25.10.21 00:30, Bernhard Reutner-Fischer via Fortran wrote:

From: Bernhard Reutner-Fischer 
gcc/fortran/ChangeLog:

  * trans-types.h (gfc_convert_function_code): Delete.


OK.

Tobias


---
  gcc/fortran/trans-types.h | 3 ---
  1 file changed, 3 deletions(-)

diff --git a/gcc/fortran/trans-types.h b/gcc/fortran/trans-types.h
index 1b43503092b..3bc236cad0d 100644
--- a/gcc/fortran/trans-types.h
+++ b/gcc/fortran/trans-types.h
@@ -65,9 +65,6 @@ enum gfc_packed {
PACKED_STATIC
  };

-/* be-function.c */
-void gfc_convert_function_code (gfc_namespace *);
-
  /* trans-types.c */
  void gfc_init_kinds (void);
  void gfc_init_types (void);

-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955


Re: [PATCH] PR fortran/102917 - PDT type parameters are not restricted to default integer

2021-10-26 Thread Tobias Burnus

Dear Harald, dear all,

On 24.10.21 21:00, Harald Anlauf via Fortran wrote:

I've created PR 102917 for tracking this issue and packaged
the attached patch.

Regtested on x86_64-pc-linux-gnu.  OK mainline?


OK. I wonder whether a valid len/kind example should be added which uses
such a PDT with non-default-kind integer.

Tobias


Gesendet: Freitag, 22. Oktober 2021 um 22:25 Uhr
Von: "Steve Kargl" 
An: "Harald Anlauf" 
Cc: fortran@gcc.gnu.org
Betreff: Re: PDT type parameters are not restricted to default integer

On Fri, Oct 22, 2021 at 10:16:05PM +0200, Harald Anlauf wrote:

Hi Steve,

Am 22.10.21 um 21:35 schrieb Steve Kargl via Fortran:

Here's an obvious quick fix.  Please apply.


diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 6043e100fbb..e889bb44142 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -5619,14 +5619,6 @@ match_attr_spec (void)
 m = MATCH_ERROR;
 goto cleanup;
   }
-if (current_ts.kind != gfc_default_integer_kind)
-  {
-gfc_error ("Component with LEN attribute at %C must be "
-   "default integer kind (%d)",
-gfc_default_integer_kind);
-m = MATCH_ERROR;
-goto cleanup;
-  }
   }
 else
   {

I think you are right.  We should always have allowed any integer kind.

However, have you checked whether this change introduces regressions?
If you don't, somebody else will.  Please open a PR, then.


It seems that pdt_4.f03 will fail with the above patch because
it explicitly tests for this error message.  That's the only
failure in the testsuite.  For the record, F2003, page 48,

R435 type-param-def-stmt  is INTEGER [ kind-selector ] , ...

Each type parameter is itself of type integer.  If its kind selector
is omitted, the kind type parameter is default integer.

Now that I think about and look, there is a nearby similar gcc_error()
for KIND.  This should be removed too.

--
Steve


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955


Re: [PATCH] PR fortran/102816 - [12 Regression] ICE in resolve_structure_cons, at fortran/resolve.c:1467

2021-10-26 Thread Tobias Burnus

Dear Harald, hi all,

On 22.10.21 21:36, Harald Anlauf via Fortran wrote:

the recently introduced shape validation for array components
in DT constructors did not properly deal with invalid code
created by ingenious testers.

Obvious solution: replace the gcc_assert by a suitable error message.

Regarding the error message: before the shape validation, gfortran
would emit the same error message twice referring to the same line,
namely the bad declaration of the component.  With the attached patch
we get one error message for the bad declaration of the component,
and one for the structure constructor referring to that DT component.
One could easily change that and make the second message refer to the
same as the declaration, giving two errors for the same line.

Comments / opinions?


Does not really matter in this case as long as there is one error for
the invalid "integer :: a([2])".

In other cases, it requires some careful weighting whether error should
have the error location "use m" or where the symbol is used. (Here, it
cannot occur as the module won't get generated and an error is already
printed at the proper location.)


Regtested on x86_64-pc-linux-gnu.  OK?


OK.

Tobias

-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955


Re: Replacing keyword in RISC-V Fortran

2021-10-26 Thread Amit Hmath via Fortran
Thanks Arjen. Let me work on your comments.



On Mon, Oct 25, 2021 at 12:53 PM Arjen Markus 
wrote:

> I am not sure I understand your question correctly, but Fortran uses the
> KIND mechanism to declare the precise characteristics of floating-point
> variables and constants. Typically, these are identifying integer numbers
> for single precision, double precision and quadruple precision. A custom
> floating-point type would mean an additional KIND number with the relevant
> runtime support and support from the various intrinsic functions and
> modules In the directory gcc/fortran I find several source files that use
> the typedef gfc_real_info and the array of kinds gfc_rel_kinds to deal with
> floating-point data of various kinds. Would that help? (Caveat: I am a mere
> beginner, and perhaps not even that, when it comes to the internals of the
> GCC compiler suite)
>
> Regards,
>
> Arjen
>
> Op za 23 okt. 2021 om 03:28 schreef Amit Hmath via Fortran <
> fortran@gcc.gnu.org>:
>
>> Hello All,
>>
>> I am working on a custom float in RISC-V 32, one can replace keyword
>> "float" with  custom keyword like "fp_custom" at line # 482
>> riscv-gcc/gcc/c-family/c-common.c. But in the case of Fortran,  can you
>> please tell which files to modify to replace the "float" keyword?
>>
>> And also, in case of c/c++ one can do custom encoding and decoding of
>> custom floats in gcc/real.c how about in fortran for custom real data
>> type,
>> which file(s) one has to modify?
>>
>> Many Thanks,
>> -Amit
>>
>


Re: [PATCH] PR fortran/102816 - [12 Regression] ICE in resolve_structure_cons, at fortran/resolve.c:1467

2021-10-26 Thread Harald Anlauf via Fortran
Hi Tobias,

> In other cases, it requires some careful weighting whether error should
> have the error location "use m" or where the symbol is used. (Here, it
> cannot occur as the module won't get generated and an error is already
> printed at the proper location.)

I had though about this but couldn't come up with a way to create
a module file from an invalid type definition.

The closest is sth. which imports it, such as in

program p
  type t
 integer :: a([2]) ! { dg-error "must be scalar" }
  end type
  type(t) :: x = t([3, 4]) ! { dg-error "Bad array spec of component" }
  interface
 subroutine foo (x)
   import t
   type(t) :: x
   type(t), parameter :: y = t([5, 6]) ! { dg-error "Bad array spec of 
component" }
 end subroutine foo
  end interface
end

However (= fortunately) this works just fine.

> > Regtested on x86_64-pc-linux-gnu.  OK?
> 
> OK.

Will commit tonight.  Thanks for the review!

Harald

> Tobias
> 
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
> München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
> Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
> München, HRB 106955
>


Re: [PATCH] PR fortran/102917 - PDT type parameters are not restricted to default integer

2021-10-26 Thread Harald Anlauf via Fortran
Hi Tobias,

> OK. I wonder whether a valid len/kind example should be added which uses
> such a PDT with non-default-kind integer.

the testcase pdt_4.f03 did actually check for the error message that gets
removed and had to be adjusted.  Removing just the dg-error does that job :-)

Thanks,
Harald

> Tobias
> 
> >> Gesendet: Freitag, 22. Oktober 2021 um 22:25 Uhr
> >> Von: "Steve Kargl" 
> >> An: "Harald Anlauf" 
> >> Cc: fortran@gcc.gnu.org
> >> Betreff: Re: PDT type parameters are not restricted to default integer
> >>
> >> On Fri, Oct 22, 2021 at 10:16:05PM +0200, Harald Anlauf wrote:
> >>> Hi Steve,
> >>>
> >>> Am 22.10.21 um 21:35 schrieb Steve Kargl via Fortran:
>  Here's an obvious quick fix.  Please apply.
> 
> 
>  diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
>  index 6043e100fbb..e889bb44142 100644
>  --- a/gcc/fortran/decl.c
>  +++ b/gcc/fortran/decl.c
>  @@ -5619,14 +5619,6 @@ match_attr_spec (void)
>   m = MATCH_ERROR;
>   goto cleanup;
> }
>  -if (current_ts.kind != gfc_default_integer_kind)
>  -  {
>  -gfc_error ("Component with LEN attribute at %C must be "
>  -   "default integer kind (%d)",
>  -gfc_default_integer_kind);
>  -m = MATCH_ERROR;
>  -goto cleanup;
>  -  }
> }
>   else
> {
> >>> I think you are right.  We should always have allowed any integer kind.
> >>>
> >>> However, have you checked whether this change introduces regressions?
> >>> If you don't, somebody else will.  Please open a PR, then.
> >>>
> >> It seems that pdt_4.f03 will fail with the above patch because
> >> it explicitly tests for this error message.  That's the only
> >> failure in the testsuite.  For the record, F2003, page 48,
> >>
> >> R435 type-param-def-stmt  is INTEGER [ kind-selector ] , ...
> >>
> >> Each type parameter is itself of type integer.  If its kind selector
> >> is omitted, the kind type parameter is default integer.
> >>
> >> Now that I think about and look, there is a nearby similar gcc_error()
> >> for KIND.  This should be removed too.
> >>
> >> --
> >> Steve
> >>
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
> München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
> Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
> München, HRB 106955
>


[PATCH] PR fortran/102956 - PDT KIND and LEN type parameters are mutually exclusive

2021-10-26 Thread Harald Anlauf via Fortran
Dear Fortranners,

we were missing a conflict check for PDT KIND and LEN type parameters:


F2018: 7.5.3.1  Type parameter definition statement

R732  type-param-def-stmt is
  integer-type-spec, type-param-attr-spec :: type-param-decl-list

R734  type-param-attr-spec  is KIND or LEN

(3) The type-param-attr-spec explicitly specifies whether a type parameter is a 
kind parameter or a length parameter.

Thus the KIND and LEN attributes are mutually exclusive.


The attached trivial patch remedies that.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?

Thanks,
Harald

Fortran: [PDT] KIND and LEN type parameters are mutually exclusive

gcc/fortran/ChangeLog:

	PR fortran/102956
	* symbol.c (gfc_check_conflict): Add conflict check for PDT KIND
	and LEN type parameters.

gcc/testsuite/ChangeLog:

	PR fortran/102956
	* gfortran.dg/pdt_32.f03: New test.

diff --git a/gcc/fortran/symbol.c b/gcc/fortran/symbol.c
index 2c4acd5abe1..c77f3f84962 100644
--- a/gcc/fortran/symbol.c
+++ b/gcc/fortran/symbol.c
@@ -720,6 +720,7 @@ gfc_check_conflict (symbol_attribute *attr, const char *name, locus *where)
   conf (pdt_len, pointer)
   conf (pdt_len, dimension)
   conf (pdt_len, codimension)
+  conf (pdt_len, pdt_kind)

   if (attr->access == ACCESS_PRIVATE)
 {
diff --git a/gcc/testsuite/gfortran.dg/pdt_32.f03 b/gcc/testsuite/gfortran.dg/pdt_32.f03
new file mode 100644
index 000..f8d40410828
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pdt_32.f03
@@ -0,0 +1,17 @@
+! { dg-do compile }
+! PR fortran/102956
+! PDT KIND and LEN type parameters are mutually exclusive (F2018:R734)
+!
+module m
+  type :: good_pdt (k,l)
+ integer, kind   :: k = 1
+ integer, len:: l = 1
+ character(kind=k,len=l) :: c
+  end type good_pdt
+
+  type :: bad_pdt (k,l)   ! { dg-error "does not have a component" }
+ integer, kind, len  :: k = 1 ! { dg-error "attribute conflicts with" }
+ integer, len, kind  :: l = 1 ! { dg-error "attribute conflicts with" }
+ character(kind=k,len=l) :: c ! { dg-error "has not been declared" }
+  end type bad_pdt
+end


Re: [PATCH] PR fortran/102956 - PDT KIND and LEN type parameters are mutually exclusive

2021-10-26 Thread Tobias Burnus

On 26.10.21 21:40, Harald Anlauf via Fortran wrote:


we were missing a conflict check for PDT KIND and LEN type parameters:


F2018: 7.5.3.1  Type parameter definition statement

R732  type-param-def-stmt is
   integer-type-spec, type-param-attr-spec :: type-param-decl-list

R734  type-param-attr-spec  is KIND or LEN

(3) The type-param-attr-spec explicitly specifies whether a type parameter is a 
kind parameter or a length parameter.

Thus the KIND and LEN attributes are mutually exclusive.


The attached trivial patch remedies that.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?


LGTM, thanks.

Tobias

-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955


[PATCH, committed] PR fortran/86551 - ICE on invalid code with select type

2021-10-26 Thread Harald Anlauf via Fortran
Dear Fortranners,

as has been validated by others before and checked again, the underlying
issue of this PR has been fixed before by an unknown commit.

To ensure that it doesn't pop up again, and as suggested in the PR,
I've packaged the testcase and committed as obvious.

Thanks,
Harald


commit 0ec53a3df536f83ec72ef25b045768c06c363f86
Author: Harald Anlauf 
Date:   Tue Oct 26 22:22:36 2021 +0200

Fortran: error recovery on invalid code with SELECT TYPE

gcc/testsuite/ChangeLog:

PR fortran/86551
* gfortran.dg/pr86551.f90: New test to verify that PR86551 remains
fixed.

diff --git a/gcc/testsuite/gfortran.dg/pr86551.f90 
b/gcc/testsuite/gfortran.dg/pr86551.f90
new file mode 100644
index 000..d96e17a1884
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr86551.f90
@@ -0,0 +1,12 @@
+! { dg-do compile }
+! PR fortran/86551 - ICE on invalid code with select type / end select type
+
+subroutine b
+  type :: t1
+  end type t1
+  class(t1) :: c2
+  select type (d => c2)
+  end select type   ! { dg-error "Syntax error" }
+end ! { dg-error "END SELECT statement expected" }
+
+! { dg-prune-output "Unexpected end of file" }