[Bug fortran/41948] New: [4.5.0 regression] mismatch in optional arguments triggers segmentation fault

[Bug fortran/41948] New: [4.5.0 regression] mismatch in optional arguments triggers segmentation fault

[reuter at physik dot uni-freiburg dot de]

When compiling the sample program, gfortran 4.5.0 (referring to Revision
v153847)
the running of it triggers a seg fault due to an optional argument, which was
not present in the beginning, but astonishingly is when calling the
corresponding subroutine:
$ ./test_case
 model_set_particle_data:  present(name) =  F
 particle_data_set: present (name) =  T
Segmentation fault (core dumped)


-- 
           Summary: [4.5.0 regression] mismatch in optional arguments
                    triggers segmentation fault
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: reuter at physik dot uni-freiburg dot de
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug fortran/41948] [4.5.0 regression] mismatch in optional arguments triggers segmentation fault

[reuter at physik dot uni-freiburg dot de]

------- Comment #1 from reuter at physik dot uni-freiburg dot de  2009-11-05 10:39 -------
Created an attachment (id=18972)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18972&action=view)
Test program showing the issue.


-- 


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

[Bug fortran/41948] [4.5.0 regression] mismatch in optional arguments triggers segmentation fault

[burnus at gcc dot gnu dot org]

------- Comment #2 from burnus at gcc dot gnu dot org  2009-11-05 12:42 -------
> gfortran 4.5.0 (referring to Revision v153847)

Could you re-try with r153854 ? I think it is a duplicate of PR 41907. I do not
get a crash with:
  gcc version 4.5.0 20091105 (experimental) [trunk revision 153928] (GCC)


-- 


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

[Bug fortran/41948] [4.5.0 regression] mismatch in optional arguments triggers segmentation fault

[burnus at gcc dot gnu dot org]

------- Comment #3 from burnus at gcc dot gnu dot org  2009-11-05 13:01 -------
I forgot to thank for the bugreport - even if it is already fixed.


And I want to additionally answer the question:

> the running of it triggers a seg fault due to an optional argument, which was
> not present in the beginning, but astonishingly is when calling the
> corresponding subroutine:

  subroutine model_set_particle_data (model, i, name)
    type(string_t), dimension(:), intent(in), optional :: name
    call particle_data_set (model%prt(i), name)

The problem is that one does not pass the same "name" variable all the time.
The dummy argument "name" in the first line is the array descriptor of the
actual arguments - including the original bounds (could be e.g. "name(-5:4)"). 

(An array descriptor is something like a "struct" in C or a derived "TYPE" in
Fortran, which contains a pointer to the actual data and information about the
array bounds and - if present - the strides.)

In model_set_particle_data a new array descriptor is created which has the
bounds starting at 1 (e.g. "name(1:10)").

In creating the new edit descriptor, one accesses "name" as in
  name0.data = &name.data[0]
which is invalid if "name" is itself a NULL pointer. This properly guarded by 
"if (name != NULL)".

However, before the call one needs to check again:
  dummy = (name == NULL) ? NULL : name;
  call proc(dummy);
unless "name" is the original argument and not a new edit descriptor. (If it is
the unmodified original argument, using "call proc(name)" is identical and
saves one check and introducing another variable.)

My old patch had a wrong check and thus wrongly removed the "dummy = (...)?"
for the case of array-descriptors (assumed-shape arrays) -- and kept it for
assumed-size arrays (were it is not needed). This was fixed in PR 41907.

(The idea of removing the check is to make life easier for the optimizer -
sometimes it cannot see whether a variable aliases or not, if some using such
constructs. Also it improves the human readability of the dump.)


-- 


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

[Bug fortran/41948] [4.5.0 regression] mismatch in optional arguments triggers segmentation fault

[reuter at physik dot uni-freiburg dot de]

------- Comment #4 from reuter at physik dot uni-freiburg dot de  2009-11-05 20:45 -------
I tested with the trunk from today (r153950) everything works nicely again. 
But I do not want to close this report, it might be a duplicate issue to
PR 41907. I leave it to the developers to close the report.


-- 


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

[Bug fortran/41948] [4.5.0 regression] mismatch in optional arguments triggers segmentation fault

[burnus at gcc dot gnu dot org]

------- Comment #5 from burnus at gcc dot gnu dot org  2009-11-06 11:19 -------
> But I do not want to close this report, it might be a duplicate issue to
> PR 41907. I leave it to the developers to close the report.

Actually, I do not care whether it is marked as duplicate or simply closed :-)
I now did the former.

*** This bug has been marked as a duplicate of 41907 ***


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE


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