[Bug fortran/51434] ICE with scalar init of an array parameter, used in DT default init with transfer

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51434

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|6.5 |7.4

--- Comment #24 from kargl at gcc dot gnu.org ---
Fixed on 7-branch and trunk.  Thanks for bug reports.

The code in comment #13 still dies with an ICE, but
it is not a problem with TRANSFER.  gfortran seems to
have an issue with broadcasting a scalar derive type
across the elements of an array of derived type in
an initialization expression.  I'll a new PR for this.

[Bug fortran/51434] ICE with scalar init of an array parameter, used in DT default init with transfer

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51434

--- Comment #23 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Mar  3 19:02:28 2018
New Revision: 258222

URL: https://gcc.gnu.org/viewcvs?rev=258222=gcc=rev
Log:
2018-03-03  Steven G. Kargl  

PR fortran/51434
* simplify.c (gfc_simplify_transfer): Resolve mold.

2018-03-03  Steven G. Kargl  

PR fortran/51434
* gfortran.dg/pr51434.f90: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr51434.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/simplify.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/51434] ICE with scalar init of an array parameter, used in DT default init with transfer

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51434

--- Comment #22 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Mar  3 18:20:32 2018
New Revision: 258220

URL: https://gcc.gnu.org/viewcvs?rev=258220=gcc=rev
Log:
2018-03-03  Steven G. Kargl  

PR fortran/51434
* simplify.c (gfc_simplify_transfer): Resolve mold.

2018-03-03  Steven G. Kargl  

PR fortran/51434
* gfortran.dg/pr51434.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr51434.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/simplify.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/51434] ICE with scalar init of an array parameter, used in DT default init with transfer

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51434

--- Comment #21 from Dominique d'Humieres  ---
> > Should not it be
> > 
> >  abcde
> >  a
> 
> No. ...

OK! Sorry for my limited understanding of TRANSFER.

[Bug fortran/51434] ICE with scalar init of an array parameter, used in DT default init with transfer

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51434

--- Comment #20 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #18)
> > After several people including have gone down rabbit
> > holes trying to fix this bug, I have found a patch!
> 
> The patch at https://gcc.gnu.org/ml/fortran/2018-02/msg00181.html fixes
> several tests in this PR, but not the ones in comment 14

The code in comment 13 is irrelevant.  You get can the same
backtrace without transfer


  type t
character :: z
  end type t
  type(t), parameter :: s(5) = t('a')
  if (s%z /= 'a') stop 1
  end

f951: internal compiler error: Segmentation fault
0xcf8d7f crash_signal
../../gcc/gcc/toplev.c:325
0x1607d70 splay_tree_min
../../gcc/libiberty/splay-tree.c:484
0x75bd7d gfc_constructor_first(splay_tree_s*)
../../gcc/gcc/fortran/constructor.c:234
0x77b03f find_component_ref
../../gcc/gcc/fortran/expr.c:1356
0x77b03f simplify_const_ref
../../gcc/gcc/fortran/expr.c:1795
0x77b42d simplify_const_ref
../../gcc/gcc/fortran/expr.c:1740
0x77bbad gfc_simplify_expr(gfc_expr*, int)
../../gcc/gcc/fortran/expr.c:2004
0x77bccd simplify_parameter_variable
../../gcc/gcc/fortran/expr.c:1869
0x77bb8e gfc_simplify_expr(gfc_expr*, int)
../../gcc/gcc/fortran/expr.c:1976

[Bug fortran/51434] ICE with scalar init of an array parameter, used in DT default init with transfer

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51434

--- Comment #19 from Steve Kargl  ---
On Tue, Feb 27, 2018 at 01:54:11PM +, dominiq at lps dot ens.fr wrote:
> 
> In addition, I don't understand why
> 
>   type t
> character :: z
>   end type t
>   type(t), parameter :: s(5) = t('a')
>   type b
>   character :: y(5) = transfer('abcde', s(1)%z)
>   end type
>   type(b) :: zz
>   print *, zz
>   print *, s(1)%z
>   end
> 
> prints
> 
>  a
>  a
> 
> Should not it be
> 
>  abcde
>  a
> 

No.

Case (i): If MOLD is a scalar and SIZE is absent, the result is a scalar.

print *. s(1)%z, rank(s(1)%z) gives

 a   0

[Bug fortran/51434] ICE with scalar init of an array parameter, used in DT default init with transfer

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51434

--- Comment #18 from Dominique d'Humieres  ---
> After several people including have gone down rabbit
> holes trying to fix this bug, I have found a patch!

The patch at https://gcc.gnu.org/ml/fortran/2018-02/msg00181.html fixes several
tests in this PR, but not the ones in comment 14

f951: internal compiler error: Segmentation fault: 11

and comment 15

   end

internal compiler error: in output_constructor_regular_field, at varasm.c:5031

In addition, I don't understand why

  type t
character :: z
  end type t
  type(t), parameter :: s(5) = t('a')
  type b
  character :: y(5) = transfer('abcde', s(1)%z)
  end type
  type(b) :: zz
  print *, zz
  print *, s(1)%z
  end

prints

 a
 a

Should not it be

 abcde
 a

?

[Bug fortran/51434] ICE with scalar init of an array parameter, used in DT default init with transfer

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51434

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |6.5

--- Comment #17 from kargl at gcc dot gnu.org ---
After several people including have gone down rabbit
holes trying to fix this bug, I have found a patch!

[Bug fortran/51434] ICE with scalar init of an array parameter, used in DT default init with transfer

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51434

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #16 from Thomas Koenig  ---
This patch

> Draft patch - one probably needs to do something similar for derived types.
> 
> --- a/gcc/fortran/decl.c
> +++ b/gcc/fortran/decl.c
> @@ -1500,6 +1500,8 @@ add_init_expr_to_sym (const char *name, gfc_expr
> **initp, locus *var_locus)
>  >where);
> 
>   array->shape = gfc_get_shape (sym->as->rank);
> + if (init->ts.type == BT_CHARACTER)
> +   array->ts.u.cl = init->ts.u.cl;
>   for (n = 0; n < sym->as->rank; n++)
> spec_dimen_size (sym->as, n, >shape[n]);

fixes the test case, but regresses 

program p
   character(1), parameter :: x1(2) = 'a'
   character(*), parameter :: x2(2) = x1
end

which is a part of pr68154.f90 .

[Bug fortran/51434] ICE with scalar init of an array parameter, used in DT default init with transfer

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51434

--- Comment #14 from Tobias Burnus burnus at gcc dot gnu.org 2012-06-25 
13:28:34 UTC ---
(In reply to comment #13)
 Is the following variant 
...
 valid?

Looks valid - and with other compilers it does compile and run. What works in
gfortran is the following, which yields a scalar RHS of = 'a':
  character :: y(5) = transfer('abced', s(1)%z)

While for s%z or s(:)%z or even s(1:1)%z, one gets a size-5 array on the RHS,
namely =['a','a','a','a','a'] (or with 'abcde' the array
['a','b','c','d','e']). That case is ICEing in gfortran.


From F2008, 13.7.168 TRANSFER (SOURCE, MOLD [, SIZE]):

Result Characteristics. The result is of the same type and type parameters as
MOLD.
Case (i): If MOLD is a scalar and SIZE is absent, the result is a scalar.
Case (ii): If MOLD is an array and SIZE is absent, the result is an array and
of rank one. Its size is as small as possible such that its physical
representation is not shorter than that of SOURCE.
Case (iii): If SIZE is present, the result is an array of rank one and size
SIZE.

[Bug fortran/51434] ICE with scalar init of an array parameter, used in DT default init with transfer

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51434

--- Comment #15 from Dominique d'Humieres dominiq at lps dot ens.fr 
2012-06-25 13:45:09 UTC ---
The following test 

  character(len=2), parameter :: z(5) = ['af', 'bg', 'ch', 'di', 'ej']
  type b
  character :: y(5) = transfer('zyxwvutsrq', z)
  end type
  type(b) :: zz
  print *, zz
  print *, z
  end

gives

 zxvtr
 afbgchdiej

when compiled with g95, but an ICE when compiled with gfortran

pr51434_3_db_4.f90:8:0: internal compiler error: in
output_constructor_regular_field, at varasm.c:4768

[Bug fortran/51434] ICE with scalar init of an array parameter, used in DT default init with transfer

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51434

Dominique d'Humieres dominiq at lps dot ens.fr changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-06-23
 Ever Confirmed|0   |1

--- Comment #13 from Dominique d'Humieres dominiq at lps dot ens.fr 
2012-06-23 21:56:00 UTC ---
(In reply to comment #12)
 Actually, it does not - that was a left over from an earlier attempt (in
 expr.c's gfc_get_character_expr). The following should work, but is not
 regtested. I am not sure about the BT_DERIVED part; valid examples seem to 
 work
 fine while the following invalid code ICEs in decl.c's build_struct. That's
 independent of the patch.

Indeed even with the patch I get 

f951: internal compiler error: in build_struct, at fortran/decl.c:1620

Is the following variant 

  type t
character :: z
  end type t
  type(t), parameter :: s(5) = t('a')
  type b
  character :: y(5) = transfer('a', s%z)
  end type
  type(b) :: zz
  print *, zz
  print *, s%z
  end

valid? Compiling it with/without the patch gives a segmentation fault. For the
patched trunk of today, the backtrace is

#0  splay_tree_min (sp=0x1) at ../../work/libiberty/splay-tree.c:485
#1  0x000100013d8e in gfc_constructor_first (base=value optimized out) at
../../work/gcc/fortran/constructor.c:234
#2  0x00010002fbac in simplify_const_ref (p=0x142314d00) at
../../work/gcc/fortran/expr.c:1276
#3  0x000100030012 in simplify_const_ref (p=0x142314920) at
../../work/gcc/fortran/expr.c:1653
#4  0x0001000306fe in gfc_simplify_expr (p=0x142314920, type=0) at
../../work/gcc/fortran/expr.c:1917
#5  0x0001000309ea in simplify_parameter_variable (p=0x142314560, type=0)
at ../../work/gcc/fortran/expr.c:1782
#6  0x00010002f2f8 in gfc_check_init_expr (e=0x142314560) at
../../work/gcc/fortran/expr.c:2515
#7  0x00010002fa42 in check_init_expr_arguments (e=value optimized out)
at ../../work/gcc/fortran/expr.c:2228
#8  0x00010002f95e in gfc_check_init_expr (e=0x1423142b0) at
../../work/gcc/fortran/expr.c:2381
#9  0x00010002fae8 in gfc_reduce_init_expr (expr=0x1423142b0) at
../../work/gcc/fortran/expr.c:2626
#10 0x000100030b8a in gfc_match_init_expr (result=0x7fff5fbfd308) at
../../work/gcc/fortran/expr.c:2665
#11 0x000100021be5 in gfc_match_data_decl () at
../../work/gcc/fortran/decl.c:2042
#12 0x00010006e41a in match_word (subr=value optimized out,
old_locus=0x7fff5fbfd3f0, str=value optimized out)
at ../../work/gcc/fortran/parse.c:66
#13 0x00010006ede4 in decode_statement () at
../../work/gcc/fortran/parse.c:331
#14 0x0001000703c5 in next_statement () at
../../work/gcc/fortran/parse.c:778
#15 0x000100071ead in parse_spec (st=ST_DERIVED_DECL) at
../../work/gcc/fortran/parse.c:2093
#16 0x0001000740f9 in parse_progunit (st=value optimized out) at
../../work/gcc/fortran/parse.c:4110
#17 0x00010007507e in gfc_parse_file () at
../../work/gcc/fortran/parse.c:4585
#18 0x0001000b4726 in gfc_be_parse_file () at
../../work/gcc/fortran/f95-lang.c:191
#19 0x00010072c2af in compile_file () at ../../work/gcc/toplev.c:550
#20 0x00010072e115 in toplev_main (argc=2, argv=0x7fff5fbfd7a0) at
../../work/gcc/toplev.c:1867
#21 0x00011974 in start ()

[Bug fortran/51434] ICE with scalar init of an array parameter, used in DT default init with transfer

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51434

--- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org 2011-12-07 
11:44:48 UTC ---
(In reply to comment #7)
 Any guess when this ICE might get some attention and into a release version?

Well, as you can see from the discussion here, it does get attention.

But in general: Only regressions have a high priority. (Regression = something
which worked before but stopped doing so. At least the code of comment 4 never
worked in gfortran.) -- We try hard to fix also the other issues, but as the
development is based on volunteers and there are many bugs and feature
requests, it might take a while.

Release: The GCC development is now in the stabilization phase and GCC 4.7.0
will be presumably released around March next year. See
http://gcc.gnu.org/ml/fortran/2011-12/msg00028.html (esp. the Status part in
the forwarded email).


(In reply to comment #4)
 That's the line:
   else if (mpz_cmp (c-ts.u.cl-length-value.integer,
 c-initializer-ts.u.cl-length-value.integer))
 with
   c-initializer-ts.u.cl == NULL


Draft patch - one probably needs to do something similar for derived types.

--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -1500,6 +1500,8 @@ add_init_expr_to_sym (const char *name, gfc_expr **initp,
locus *var_locus)
 init-where);

  array-shape = gfc_get_shape (sym-as-rank);
+ if (init-ts.type == BT_CHARACTER)
+   array-ts.u.cl = init-ts.u.cl;
  for (n = 0; n  sym-as-rank; n++)
spec_dimen_size (sym-as, n, array-shape[n]);

[Bug fortran/51434] ICE with scalar init of an array parameter, used in DT default init with transfer

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51434

--- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org 2011-12-07 
15:31:11 UTC ---
(In reply to comment #9)
 Draft patch - one probably needs to do something similar for derived types.

The patch breaks the Different CHARACTER lengths (%d/%d) in array constructor
diagnostic, e.g. gfortran.dg/bounds_check_array_ctor_3.f90.

[Bug fortran/51434] ICE with scalar init of an array parameter, used in DT default init with transfer

[andy.nelson at lanl dot gov]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51434

--- Comment #11 from Andy Nelson andy.nelson at lanl dot gov 2011-12-07 
16:11:38 UTC ---
On Dec 6, 2011, at 7:17 PM, sgk at troutmask dot apl.washington.edu wrote:

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51434
 
 --- Comment #8 from Steve Kargl sgk at troutmask dot apl.washington.edu 
 2011-12-07 02:17:48 UTC ---
 On Tue, Dec 06, 2011 at 10:25:00PM +, andy.nelson at lanl dot gov wrote:
 
 Any guess when this ICE might get some attention and into a release version?
 
 
 Unfortunately, the only guess is the bug will be fixed
 when someone gets around to fixing it. :(  It comes 
 down to too few developers and too many things to do
 (e.g., fix bugs and implement new features) and too 
 little time.
 

Sure. I didn't mean to imply any particular pressure. In the environment
I work in, it would be years before I see this fix even if it got fixed today,
so any particular time pressure is rather soft. Basically, for most of the
codes 
that I work on and that pay my salary, I can't implement a feature or depend on
a bug not hitting me until the oldest machine we have is retired or upgraded
past the 
implementation/fix of whatever it is that I need for some bit of code or other.

Thanks for the attention,

Andy

[Bug fortran/51434] ICE with scalar init of an array parameter, used in DT default init with transfer

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51434

--- Comment #12 from Tobias Burnus burnus at gcc dot gnu.org 2011-12-07 
17:20:14 UTC ---
(In reply to comment #10)
  Draft patch - one probably needs to do something similar for derived types.
 The patch breaks the Different CHARACTER lengths (%d/%d) in array
 constructor diagnostic, e.g. gfortran.dg/bounds_check_array_ctor_3.f90.

Actually, it does not - that was a left over from an earlier attempt (in
expr.c's gfc_get_character_expr). The following should work, but is not
regtested. I am not sure about the BT_DERIVED part; valid examples seem to work
fine while the following invalid code ICEs in decl.c's build_struct. That's
independent of the patch.

  type t
character :: z
  end type t
  type(t), parameter :: s(5) = t('a')
  type b
  character :: y(5) = transfer('a', s)
end type
  end

--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -1502,6 +1502,18 @@ add_init_expr_to_sym (const char *name, gfc_expr
**initp, locus *var_locus)
  array-shape = gfc_get_shape (sym-as-rank);
  for (n = 0; n  sym-as-rank; n++)
spec_dimen_size (sym-as, n, array-shape[n]);
+ array-ts.is_c_interop = init-ts.is_c_interop;
+ if (init-ts.type == BT_CHARACTER)
+   {
+ if (init-ts.u.cl-length == NULL)
+   init-ts.u.cl-length
+   = gfc_get_int_expr (gfc_default_integer_kind,
+   init-where,
+   init-value.character.length);
+ array-ts.u.cl = init-ts.u.cl;
+   }
+ else if (init-ts.type == BT_DERIVED)
+   array-ts.u.derived = init-ts.u.derived;

  init = array;
  mpz_clear (size);

[Bug fortran/51434] ICE with scalar init of an array parameter, used in DT default init with transfer

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51434

Tobias Burnus burnus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||burnus at gcc dot gnu.org
Summary|internal compiler error |ICE with scalar init of an
   ||array parameter, used in DT
   ||default init with transfer

--- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2011-12-06 
08:53:24 UTC ---
Reduced test case. The TYPE is crucial - if t is just an initialization to a
module variable, no ICE occurs.

character, parameter :: s(5) = 'a'
type b
  character :: t(5) = transfer('abc  ', s)  !  ICE
end type
!type(b) :: x
!print *, x%t   ! shall print abc  
!print *, s ! prints successfully a
end

==14250== Invalid read of size 8
==14250==at 0x51A7CD: gfc_match_data_decl() (decl.c:1589)
==14250==by 0x55F429: _ZL10match_wordPKcPF5matchvEP5locus.part.3
(parse.c:65)
==14250==by 0x55FC39: decode_statement() (parse.c:283)

That's the line:
  else if (mpz_cmp (c-ts.u.cl-length-value.integer,
c-initializer-ts.u.cl-length-value.integer))
with
  c-initializer-ts.u.cl == NULL

[Bug fortran/51434] ICE with scalar init of an array parameter, used in DT default init with transfer

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51434

--- Comment #5 from Steve Kargl sgk at troutmask dot apl.washington.edu 
2011-12-06 15:47:41 UTC ---
On Tue, Dec 06, 2011 at 06:40:07AM +, andy.nelson at lanl dot gov wrote:
 
 character(c_char) :: raidnum(lenname) = 
   (/ 'r','a','i','d','n','u','m',.  /)
 
 Is this what you thought I was trying to do?
 Is what I am trying to do actually
 legal (would tend to think so atm, since pgi and intel don't have similar
 problems)?

What does 'character(c_char)' above declare?

What you have is an array of strings with each
string having a length of c_char.

R424 char-selector is length-selector
 or ( LEN = type-param-value ,
  KIND = scalar-int-initialization-expr )
 or ( type-param-value ,
  [ KIND = ] scalar-int-initialization-expr )
 or ( KIND = scalar-int-initialization-expr
  [ , LEN =type-param-value ] )

R425 length-selector is ( [ LEN = ] type-param-value )
 or * char-length [ , ]

Let nlen be the length and nknd the kind, you want to 
have one of the following forms:

character(len=nlen, kind=nknd) ...
character(nlen, kind=nknd) ...
character(len=nlen, nknd) ...
character(nlen, nknd) ...
character(kind=nknd) ...
character(kind=nknd, len=nlen) ...

For your case, nlen=1 and nknd=c_char.

As shown by Tobias, even if you fix your declarations, your
code will fail.

PS: I suspect yor code works with ifort and pgi because 
c_char is probably 1, default character kind is 1, and
these compilers only support a single character kind.  So,
you accidentally get want you want. 

PPS: Yes, I would use an ugly explicit array to do the
initializaton instead of transfer.  First, the explicit
array is clear and easy to understand.  Second, although
transfer should work, it is one ugly piece of code 
under the hood.

[Bug fortran/51434] ICE with scalar init of an array parameter, used in DT default init with transfer

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51434

--- Comment #6 from Steve Kargl sgk at troutmask dot apl.washington.edu 
2011-12-06 15:59:17 UTC ---
On Tue, Dec 06, 2011 at 06:40:07AM +, andy.nelson at lanl dot gov wrote:

 Can you recommend a better way to solve this problem, besides redefining the C
 standard to accept 'scalar' character strings longer than one character? 
 

Don't know if the code conforms to the C and Fortran standards,
but this appears to work.

% cat foo.c

#include stdio.h
void
foo(char *s)
{
   printf(%s\n, s);
}

% cat bar.f90

program bar
  use iso_c_binding
  character(len=5,kind=c_char) :: s
  interface
subroutine foo(s) bind(c)
  use iso_c_binding
  character(len=1, kind=c_char) :: s
end subroutine foo
  end interface
  s = 'abcd'
  call foo(s // char(0))
end program bar

% gcc46 -c foo.c
% gfortran46 -o z bar.f90 foo.c
% ./z
abcd 

It should be straight forward to modify your code.  The 
key is to null terminate the string you are passing into
the C routine, i.e., the char(0) above.

[Bug fortran/51434] ICE with scalar init of an array parameter, used in DT default init with transfer

[andy.nelson at lanl dot gov]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51434

--- Comment #7 from Andy Nelson andy.nelson at lanl dot gov 2011-12-06 
22:25:00 UTC ---
Seems it doesn't work in general. My attempt at getting it to work (perhaps
messed up, but still an attempt) on intel generated an error about length not
being the same or some such, and that being a violation of the f03 standard
somewhere. Didn't investigate too deeply.

I'm now going forward with the array specification version

character(kind=C_CHAR) :: blah(10) = (/ 'b','l','a','h',.. /)

since it seems to work on the places I've tried it.

Any guess when this ICE might get some attention and into a release version?


Thanks for your help, and the pointer about the kind=C_CHAR things that 
I was not doing correctly. 

Andy

On Dec 6, 2011, at 8:59 AM, sgk at troutmask dot apl.washington.edu wrote:

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51434
 
 --- Comment #6 from Steve Kargl sgk at troutmask dot apl.washington.edu 
 2011-12-06 15:59:17 UTC ---
 On Tue, Dec 06, 2011 at 06:40:07AM +, andy.nelson at lanl dot gov wrote:
 
 Can you recommend a better way to solve this problem, besides redefining the 
 C
 standard to accept 'scalar' character strings longer than one character? 
 
 
 Don't know if the code conforms to the C and Fortran standards,
 but this appears to work.
 
 % cat foo.c
 
 #include stdio.h
 void
 foo(char *s)
 {
   printf(%s\n, s);
 }
 
 % cat bar.f90
 
 program bar
  use iso_c_binding
  character(len=5,kind=c_char) :: s
  interface
subroutine foo(s) bind(c)
  use iso_c_binding
  character(len=1, kind=c_char) :: s
end subroutine foo
  end interface
  s = 'abcd'
  call foo(s // char(0))
 end program bar
 
 % gcc46 -c foo.c
 % gfortran46 -o z bar.f90 foo.c
 % ./z
 abcd 
 
 It should be straight forward to modify your code.  The 
 key is to null terminate the string you are passing into
 the C routine, i.e., the char(0) above.
 
 -- 
 Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
 --- You are receiving this mail because: ---
 You are on the CC list for the bug.
 You reported the bug.

[Bug fortran/51434] ICE with scalar init of an array parameter, used in DT default init with transfer

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51434

--- Comment #8 from Steve Kargl sgk at troutmask dot apl.washington.edu 
2011-12-07 02:17:48 UTC ---
On Tue, Dec 06, 2011 at 10:25:00PM +, andy.nelson at lanl dot gov wrote:
 
 Any guess when this ICE might get some attention and into a release version?
 

Unfortunately, the only guess is the bug will be fixed
when someone gets around to fixing it. :(  It comes 
down to too few developers and too many things to do
(e.g., fix bugs and implement new features) and too 
little time.

I breifly looked at the code path with gdb.  It seems to
be a problem with populating the first array.

This fails

integer, parameter :: n = 5
character(kind=c_char), parameter :: s(n) = 'a'
type b
  character(kind=c_char) :: t(n) = transfer(s, s,)
end type b 

because the scalar 'a' is not broadcasted over the array.

If one replaces the s(n) line with

character(kind=c_char), parameter :: s(n) = ['a', 'a', 'a', 'a', 'a']

then everything appears to work.  I haven't had time to
look at this any further.