[Bug fortran/51946] New: file compiles properly on IBM xlf compiler and cary compiler

[Bug fortran/51946] New: file compiles properly on IBM xlf compiler and cary compiler

[dominique.pelletier at polymtl dot ca]

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

             Bug #: 51946
           Summary: file compiles properly on IBM xlf compiler and cary
                    compiler
    Classification: Unclassified
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: dominique.pelletier@polymtl.ca


Created attachment 26412
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26412
taken from Damian Rouson's book , allocate seems to be the culprit

Source if from Damian Rouson from Sandia National Laboratories
It compiles properly with IBM xlf and Cray fortran compilers.

apparently the allocate statement

Allocate ( localprdct, source = rhs)

is the culprit

[Bug fortran/51946] file compiles properly on IBM xlf compiler and cary compiler

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org 2012-01-22 17:11:06 UTC ---
How is one going to compile this?

% module atmosphere_module
  use air_module ,only : air       ! puppet for 1st Lorenz eq. and corresonding
state variable
  use cloud_module ,only : cloud   ! puppet for 2nd Lorenz eq. and corresonding
state variable
  use ground_module ,only : ground ! puppet for 3rd Lorenz eq. and corresonding
state variable
  use integrable_model_module ,only : integrable_model ,integrate ! parent type
and polymorphic time integrator
  use global_parameters_module ,only : debugging                  ! print call
tree if true

[Bug fortran/51946] file compiles properly on IBM xlf compiler and cary compiler

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-01-22 17:12:12 UTC ---
The test case is incomplete:

  use air_module ,only : air       ! puppet for 1st Lorenz eq. and corresonding
      1
Fatal Error: Can't open module file 'air_module.mod' for reading at (1): No
such file or directory

Additionally, please state also the error message if you fill a bug.

[Bug fortran/51946] file compiles properly on IBM xlf compiler and cary compiler

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-01-22 17:12:39 UTC ---
*** Bug 51944 has been marked as a duplicate of this bug. ***

[Bug fortran/51946] file compiles properly on IBM xlf compiler and cary compiler

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-01-22 17:45:27 UTC ---
(In reply to comment #0)
> Created attachment 26412
> taken from Damian Rouson's book , allocate seems to be the culprit
> Source if from Damian Rouson from Sandia National Laboratories
> It compiles properly with IBM xlf and Cray fortran compilers.
> apparently the allocate statement
>   Allocate ( localprdct, source = rhs)
> is the culprit

I have to admit that I could not find that allocate statement. Neither in your
attachment nor in the book's resources available at
http://www.cambridge.org/rouson under "Resources available".

However, I think it is the example chapter08/puppeteer_f2003. Using today's
version of gfortran, it works. I can reproduce a segmentation fault using
gfortran 4.7 of 2012-01-11.

Could you try with a newer gfortran version? (We had some polymorphism-related
fixes on the 13th, 16th and 18th of January.)

 * * *

Otherwise, as far as I could see, all Fortran examples work except for
- those using a FINAL subroutine (not yet implemented)
- deferred-length strings as components of derived types (not yet implemented)
- chapter07/strategy_surrogate_f2003: Segfaults in
  __timed_lorenz_module_MOD___copy_timed_lorenz_module_Timed_lorenz
  (not yet debugged)
- chapter09: Fails at MOVE_ALLOC, see PR 51948
- chapter12/burgers_caf_v4: Issue with polymorphic coarrays, cf. PR 51947

[Disclaimer: That's with today's GCC 4.7 and with a patch applied for PR 51870
(alias PR48705) - I don't know whether it affects any result. In any case,
puppeteer_f2003 also works without that patch.]

[Bug fortran/51946] file compiles properly on IBM xlf compiler and cary compiler

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #5 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2012-01-22 18:16:38 UTC ---
On Sun, Jan 22, 2012 at 05:45:27PM +0000, burnus at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51946
> 
> --- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-01-22 17:45:27 UTC ---
> (In reply to comment #0)
> > Created attachment 26412
> > taken from Damian Rouson's book , allocate seems to be the culprit
> > Source if from Damian Rouson from Sandia National Laboratories
> > It compiles properly with IBM xlf and Cray fortran compilers.
> > apparently the allocate statement
> >   Allocate ( localprdct, source = rhs)
> > is the culprit
> 
> I have to admit that I could not find that allocate statement. Neither in your
> attachment nor in the book's resources available at
> http://www.cambridge.org/rouson under "Resources available".
> 

My guess is that it is line 204:

    allocate(local_product,source=rhs)

[Bug fortran/51946] file compiles properly on IBM xlf compiler and Cray compiler

[dominique.pelletier at polymtl dot ca]

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

--- Comment #6 from Dominique Pelletier <dominique.pelletier at polymtl dot ca> 2012-01-22 19:22:29 UTC ---
enclosed is a .zip archive of the source files

I compile as follows

     gfortran    -c global_parameters_module.f03
     gfortran    -c air_module.f03
     gfortran    -c cloud_modul.f03
     gfortran    -o ground_module.f03
     gfortran    -c  integrabale_model_module.f03

This where the compiler gives me  a compilation error.


could this be due to som features o fortran 2003 that is not yet implemented
in gfortran?


Le 2012-01-22 12:11, kargl at gcc dot gnu.org a écrit :
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51946
>
> kargl at gcc dot gnu.org changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                   CC|                            |kargl at gcc dot gnu.org
>
> --- Comment #1 from kargl at gcc dot gnu.org 2012-01-22 17:11:06 UTC ---
> How is one going to compile this?
>
> % module atmosphere_module
>    use air_module ,only : air       ! puppet for 1st Lorenz eq. and corresonding
> state variable
>    use cloud_module ,only : cloud   ! puppet for 2nd Lorenz eq. and corresonding
> state variable
>    use ground_module ,only : ground ! puppet for 3rd Lorenz eq. and corresonding
> state variable
>    use integrable_model_module ,only : integrable_model ,integrate ! parent type
> and polymorphic time integrator
>    use global_parameters_module ,only : debugging                  ! print call
> tree if true
>

[Bug fortran/51946] file compiles properly on IBM xlf compiler and Cray compiler

[dominique.pelletier at polymtl dot ca]

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

--- Comment #7 from Dominique Pelletier <dominique.pelletier at polymtl dot ca> 2012-01-22 19:36:44 UTC ---
here is the full code

i compileeach file separately  with

gfortran -c

in the following order

problems_parameter_module.f03
air_module.f03
clound_module.f03
ground_module.f03
integrable_model_module.f03

the error message is

In function 'intgrate':
internal compiler error: in conv_function_val.
at fortran/trans-expr.c:2191
plese submitt a full bug report ....

I use gfortran 4.7.1 build 2012.01.19 on a windowx xp laptop with MinGW

Thnks

Le 2012-01-22 12:45, burnus at gcc dot gnu.org a écrit :
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51946
>
> --- Comment #4 from Tobias Burnus<burnus at gcc dot gnu.org>  2012-01-22 17:45:27 UTC ---
> (In reply to comment #0)
>> Created attachment 26412
>> taken from Damian Rouson's book , allocate seems to be the culprit
>> Source if from Damian Rouson from Sandia National Laboratories
>> It compiles properly with IBM xlf and Cray fortran compilers.
>> apparently the allocate statement
>>    Allocate ( localprdct, source = rhs)
>> is the culprit
> I have to admit that I could not find that allocate statement. Neither in your
> attachment nor in the book's resources available at
> http://www.cambridge.org/rouson under "Resources available".
>
> However, I think it is the example chapter08/puppeteer_f2003. Using today's
> version of gfortran, it works. I can reproduce a segmentation fault using
> gfortran 4.7 of 2012-01-11.
>
> Could you try with a newer gfortran version? (We had some polymorphism-related
> fixes on the 13th, 16th and 18th of January.)
>
>   * * *
>
> Otherwise, as far as I could see, all Fortran examples work except for
> - those using a FINAL subroutine (not yet implemented)
> - deferred-length strings as components of derived types (not yet implemented)
> - chapter07/strategy_surrogate_f2003: Segfaults in
>    __timed_lorenz_module_MOD___copy_timed_lorenz_module_Timed_lorenz
>    (not yet debugged)
> - chapter09: Fails at MOVE_ALLOC, see PR 51948
> - chapter12/burgers_caf_v4: Issue with polymorphic coarrays, cf. PR 51947
>
> [Disclaimer: That's with today's GCC 4.7 and with a patch applied for PR 51870
> (alias PR48705) - I don't know whether it affects any result. In any case,
> puppeteer_f2003 also works without that patch.]
>

[Bug fortran/51946] file compiles properly on IBM xlf compiler and Cray compiler

[kargl at gcc dot gnu.org]

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

--- Comment #8 from kargl at gcc dot gnu.org 2012-01-22 19:54:11 UTC ---
Reduced testcase

module integrable_model_module

   implicit none

   type, abstract, public :: integrable_model
      contains
         procedure(default_constructor), deferred :: empty_instance
   end type

   abstract interface
      function default_constructor(this) result(blank_slate)
         import :: integrable_model
         class(integrable_model), intent(in)  :: this
         class(integrable_model), allocatable :: blank_slate
      end function
   end interface

   contains

      subroutine integrate(this)
         class(integrable_model), intent(inout) :: this
         class(integrable_model), allocatable   :: residual
         allocate(residual, source=this%empty_instance())
      end subroutine

end module integrable_model_module


laptop:kargl[315] gfc4x -c foo.f90
foo.f90: In function 'integrate':
foo.f90:23:0: internal compiler error: in conv_function_val, at
fortran/trans-expr.c:2191
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
laptop:kargl[316] gfc4x -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/home/kargl/work/libexec/gcc/i386-unknown-freebsd10.0/4.7.0/lto-wrapper
Target: i386-unknown-freebsd10.0
Configured with: ../gcc4x/configure --prefix=/usr/home/kargl/work
--enable-languages=c,fortran --disable-libmudflap --disable-bootstrap
Thread model: posix
gcc version 4.7.0 20120119 (experimental) (GCC)

[Bug fortran/51946] file compiles properly on IBM xlf compiler and Cray compiler

[burnus at gcc dot gnu.org]

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

--- Comment #9 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-01-22 22:00:28 UTC ---
(In reply to comment #8)
> Reduced testcase
> foo.f90:23:0: internal compiler error: in conv_function_val, at
> gcc version 4.7.0 20120119 (experimental)

OK, that issue is not solved by a current trunk issue. However, it is the same
as PR 51870, PR 48705 and as the just reported PR 51943.

The issue was solved by a draft version of the patch for PR 51870. As I just
saw, the final version of the patch has been submitted:
http://gcc.gnu.org/ml/fortran/2012-01/msg00199.html

[Bug fortran/51946] file compiles properly on IBM xlf compiler and Cray compiler

[burnus at gcc dot gnu.org]

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

--- Comment #10 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-01-23 17:37:18 UTC ---
(In reply to comment #4)
> Otherwise, as far as I could see, all Fortran examples work except for
> - chapter07/strategy_surrogate_f2003: Segfaults in
>   __timed_lorenz_module_MOD___copy_timed_lorenz_module_Timed_lorenz
>   (not yet debugged)

That's now PR 51972.

[Bug fortran/51946] file compiles properly on IBM xlf compiler and Cray compiler

[pault at gcc dot gnu.org]

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

--- Comment #11 from Paul Thomas <pault at gcc dot gnu.org> 2012-01-27 10:06:05 UTC ---
Author: pault
Date: Fri Jan 27 10:05:56 2012
New Revision: 183613

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183613
Log:
2012-01-27  Paul Thomas  <pault@gcc.gnu.org>
        Tobias Burnus <burnus@gcc.gnu.org>

    PR fortran/48705
    PR fortran/51870
    PR fortran/51943
    PR fortran/51946
    * trans-array.c (gfc_array_init_size): Add two extra arguments
    to convey the dynamic element size of a calls object and to
    return the number of elements that have been allocated.
    (gfc_array_allocate): Add the same arguments and use them to
    call gfc_array_init_size.  Before the allocation dereference
    the data pointer, if necessary. Set the allocated array to zero
    if the class element size or expr3 are non-null.
    * trans-expr.c (gfc_conv_class_to_class): Give this function
    global scope.
    (get_class_array_ref): New function.
    (gfc_copy_class_to_class): New function.
    * trans-array.h : Update prototype for gfc_array_allocate.
    * trans-stmt.c (gfc_trans_allocate): For non-variable class
    STATUS expressions extract the class object and the dynamic
    element size. Use the latter to call gfc_array_allocate and
    the former for setting the vptr and, via
    gfc_copy_class_to_clasfc_cs, to copy to the allocated data.
    * trans.h : Prototypes for gfc_get_class_array_ref,
    gfc_copy_class_to_class and gfc_conv_class_to_class.


2012-01-27  Paul Thomas  <pault@gcc.gnu.org>
        Tobias Burnus <burnus@gcc.gnu.org>

    PR fortran/48705
    * gfortran.dg/class_allocate_11.f03: New.

    PR fortran/51870
    PR fortran/51943
    PR fortran/51946
    * gfortran.dg/class_allocate_7.f03: New.
    * gfortran.dg/class_allocate_8.f03: New.
    * gfortran.dg/class_allocate_9.f03: New.
    * gfortran.dg/class_allocate_10.f03: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/class_allocate_10.f03
    trunk/gcc/testsuite/gfortran.dg/class_allocate_11.f03
    trunk/gcc/testsuite/gfortran.dg/class_allocate_7.f03
    trunk/gcc/testsuite/gfortran.dg/class_allocate_8.f03
    trunk/gcc/testsuite/gfortran.dg/class_allocate_9.f03
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-array.c
    trunk/gcc/fortran/trans-array.h
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/fortran/trans-stmt.c
    trunk/gcc/fortran/trans.h
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/51946] file compiles properly on IBM xlf compiler and Cray compiler

[pault at gcc dot gnu.org]

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

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |pault at gcc dot gnu.org
         Resolution|                            |FIXED

--- Comment #12 from Paul Thomas <pault at gcc dot gnu.org> 2012-01-27 10:13:27 UTC ---
Fixed on trunk

Thanks for the report

Paul