public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/51961] New: [OOP] ALLOCATE with MOLD=  rejects if source-expr has a different rank
@ 2012-01-23 11:10 burnus at gcc dot gnu.org
  2013-01-08 15:37 ` [Bug fortran/51961] " dominiq at lps dot ens.fr
  0 siblings, 1 reply; 2+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-01-23 11:10 UTC (permalink / raw)
  To: gcc-bugs

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

             Bug #: 51961
           Summary: [OOP] ALLOCATE with MOLD=  rejects if source-expr has
                    a different rank
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Keywords: rejects-valid
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: burnus@gcc.gnu.org


Fortran 2008 has:
  C638 (R626) Each allocate-object shall be type compatible (4.3.1.3) with
              source-expr. If SOURCE= appears, source-expr shall be a scalar or
              have the same rank as each allocate-object.

gfortran properly diagnoses this for SOURCE, but it also diagnoses it for MOLD=
which is valid:

allocate (a(2), mold=b)   ! Valid
          2          1
Error: Source-expr at (1) must be scalar or have the same rank as the
allocate-object at (2)



type t
end type t
class(T), allocatable :: a(:), b(:,:)
allocate(b(2,2))

allocate (a(2), source=b) ! Invalid - and correctly rejected
allocate (a(2), mold=b)   ! Valid - but not accepted
end


^ permalink raw reply	[flat|nested] 2+ messages in thread

* [Bug fortran/51961] [OOP] ALLOCATE with MOLD=  rejects if source-expr has a different rank
  2012-01-23 11:10 [Bug fortran/51961] New: [OOP] ALLOCATE with MOLD= rejects if source-expr has a different rank burnus at gcc dot gnu.org
@ 2013-01-08 15:37 ` dominiq at lps dot ens.fr
  0 siblings, 0 replies; 2+ messages in thread
From: dominiq at lps dot ens.fr @ 2013-01-08 15:37 UTC (permalink / raw)
  To: gcc-bugs


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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-01-08
     Ever Confirmed|0                           |1

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2013-01-08 15:37:02 UTC ---

What is allocate supposed to do if the array and the mold are not
conformable?

>From the 2008 draft:

Data usage and computation:

A structure constructor can omit the value for an allocatable component. 
SOURCE= in an ALLOCATE statement can give an array variable the bounds as
well as the value of an expression.
MOLD= in an ALLOCATE statement can give a polymorphic variable the shape,  
                                                                   ^^^^^
type,and type parameters of an expression without copying the value. 
The real and imaginary parts of a complex entity can be accessed
independently with a component-like syntax.  Intrinsic assignment to an
allocatable polymorphic variable is allowed.  A pointer function reference
can denote a variable in any variable definition context.  Some restrictions
on the use of dummy arguments in elemental subprograms have been removed.


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2013-01-08 15:37 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-01-23 11:10 [Bug fortran/51961] New: [OOP] ALLOCATE with MOLD= rejects if source-expr has a different rank burnus at gcc dot gnu.org
2013-01-08 15:37 ` [Bug fortran/51961] " dominiq at lps dot ens.fr

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).