Bug 30783 - "character(*), value" produces SEGV at runtime
Summary: "character(*), value" produces SEGV at runtime
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.3.0
: P3 normal
Target Milestone: ---
Assignee: Tobias Burnus
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2007-02-13 08:55 UTC by Tobias Burnus
Modified: 2007-02-20 09:45 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2007-02-13 18:30:14


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2007-02-13 08:55:02 UTC
The combination of the VALUE attribute with CHARACTER(*) gives segmentation faults (SIGSEGV, SIGBUS). Without VALUE or with "CHARACTER(10), VALUE" it works.

------ Test case ------------
program x
  implicit none
  character(10) :: c
  c = 'Main'
  print *, c
  call foo(c)
  print *, c
contains
  subroutine foo(a)
    character(*) :: a
    value :: a
    print *, 'Foo: ',a
    a = 'Hello'
    print *, 'Foo: ',a
  end subroutine foo
end program x
------ Test case ------------

I don't know whether it can be made to work, if not, one could do something like   Chris does in the Fortran-Experiments branch (except of only disallowing the length "*"):

      /* Character strings are a hassle because they may be length 1,
         or assumed length (*), etc., so we need to find a way to
         prevent by-value dummy char args from being anything but
         length 1 constants, because C will only pass a pointer in
         any other cases.  However, we can't help the following with the
         logic being used below:
         character(c_char), value :: my_char
         character(kind=c_char, len=1), value :: my_char_str
         hope the user does the right thing.  */
     if (sym->attr.value == 1 && sym->ts.type == BT_CHARACTER)
       /* if we can't verify the length of 1...error */
       if (sym->ts.cl == NULL || sym->ts.cl->length == NULL
           || (sym->ts.cl->length->value.character.length != 1))
         gfc_error_now ("VALUE attribute at %L cannot be used "
                        "for character strings", &(sym->declared_at));
Comment 1 Dominique d'Humieres 2007-02-13 09:54:27 UTC
Compiling the test with xlf gives:

"pr30783.f90", line 6.12: 1513-061 (S) Actual argument attributes do not match those specified by an accessible explicit interface.
"pr30783.f90", line 11.14: 1516-181 (S) Objects of type CHARACTER with length greater than 1, with run time length, or with assumed length must not be declared with the VALUE attribute.

and with g95

Error: Character dummy variable 'a' at (1) with the VALUE attribute must have a constant length


Comment 2 Tobias Burnus 2007-02-13 18:19:10 UTC
From the Fortran 2003 standard:
--------------
C528 (R501) If the VALUE attribute is specified, the length type parameter values shall be omitted or specified by initialization expressions.
--------------

Which rules out deferred type parameters such as "*" or ":".

However, I fail to see anything which rules out "(10)" even though also sunf95 and NAG f95 claim that anything but nothing or "(1)" is wrong.

ifort and g95 allow "(10)" but crash or at least access uninitialized memory.

And as said: gfortran allows "(10)" and it works properly.
Comment 3 patchapp@dberlin.org 2007-02-14 08:55:44 UTC
Subject: Bug number PR30783

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01226.html
Comment 4 Tobias Burnus 2007-02-20 09:17:09 UTC
Subject: Bug 30783

Author: burnus
Date: Tue Feb 20 09:16:58 2007
New Revision: 122156

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122156
Log:
2007-02-20  Tobias Burnus  <burnus@net-b.de>

       PR fortran/30783
       * resolve.c (resolve_symbol): Add character dummy VALUE check.


Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/resolve.c

Comment 5 Tobias Burnus 2007-02-20 09:45:38 UTC
Fixed in 4.3 (not present in 4.2).