public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/99765] New: Explicit dimension size declaration of pointer array allowed
@ 2021-03-25  9:22 nickpapior at gmail dot com
  2021-03-25 11:43 ` [Bug fortran/99765] " dominiq at lps dot ens.fr
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: nickpapior at gmail dot com @ 2021-03-25  9:22 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 99765
           Summary: Explicit dimension size declaration of pointer array
                    allowed
           Product: gcc
           Version: 4.8.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: nickpapior at gmail dot com
  Target Milestone: ---

A mishandling of variable declarations

Consider this program:

program test
  real, dimension(10), pointer :: a(:) => null()

  print *, associated(a)
  allocate(a(2))
  print *, size(a)
  !print *, size(a(1)) ! obviously fails as a(1) is a scalar

end program test


It is ambiguous to determine the size of a. The programmer may think that after
allocation one has 2x10 elements a(1:2)(1:10) however what is happening is that
the dimension(10) attribute is completely ignored.

I can't find anywhere in the standard mentioning that this way of definition is
wrong, but I think it clearly shouldn't be allowed.

I.e. it is unclear whether the user wants a(1:2)(1:10) or a(1:10)(1:2), in any
case neither of the results are achieved.

I found this bug in 4.8.4 and also in 9.3.0, so I assume it exists in all in
between.

A few more cases that resemble this:

  real, dimension(10), allocatable :: a(:)

behaves exactly like with pointers. It is not well-defined and gets to the
a(1:2) case.

  real, dimension(10), allocatable :: a(10)

rightfully errors out on compilation with a somewhat unclear error message

    3 |   real, dimension(10) :: a(10)
      |                          1
Error: Symbol ‘a’ at (1) already has basic type of REAL

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

* [Bug fortran/99765] Explicit dimension size declaration of pointer array allowed
  2021-03-25  9:22 [Bug fortran/99765] New: Explicit dimension size declaration of pointer array allowed nickpapior at gmail dot com
@ 2021-03-25 11:43 ` dominiq at lps dot ens.fr
  2021-03-25 11:47 ` nickpapior at gmail dot com
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: dominiq at lps dot ens.fr @ 2021-03-25 11:43 UTC (permalink / raw)
  To: gcc-bugs

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-03-25
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
The standard says:

C832 An array with the POINTER or ALLOCATABLE attribute shall have an
array-spec 
that is a deferred-shape-spec-list.

so I think

  real, dimension(10), pointer :: a(:) => null()

and

  real, dimension(10), allocatable :: a(10)

are invalid and shall give an error.

Note that a(1:2)(1:10) looks like C syntax, a rank 2 array is a(1:2,1:10).
The only case for valid fortran is for a being of type CHARACTER, a(1;2) being
a slice and (1:10) a substring.

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

* [Bug fortran/99765] Explicit dimension size declaration of pointer array allowed
  2021-03-25  9:22 [Bug fortran/99765] New: Explicit dimension size declaration of pointer array allowed nickpapior at gmail dot com
  2021-03-25 11:43 ` [Bug fortran/99765] " dominiq at lps dot ens.fr
@ 2021-03-25 11:47 ` nickpapior at gmail dot com
  2021-03-25 15:48 ` burnus at gcc dot gnu.org
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: nickpapior at gmail dot com @ 2021-03-25 11:47 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #2 from Nick <nickpapior at gmail dot com> ---
Thanks for finding that in the standard!

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

* [Bug fortran/99765] Explicit dimension size declaration of pointer array allowed
  2021-03-25  9:22 [Bug fortran/99765] New: Explicit dimension size declaration of pointer array allowed nickpapior at gmail dot com
  2021-03-25 11:43 ` [Bug fortran/99765] " dominiq at lps dot ens.fr
  2021-03-25 11:47 ` nickpapior at gmail dot com
@ 2021-03-25 15:48 ` burnus at gcc dot gnu.org
  2021-03-26  6:41 ` nickpapior at gmail dot com
  2021-03-26  7:36 ` burnus at gcc dot gnu.org
  4 siblings, 0 replies; 6+ messages in thread
From: burnus at gcc dot gnu.org @ 2021-03-25 15:48 UTC (permalink / raw)
  To: gcc-bugs

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

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

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #1)
> so I think
>   real, dimension(10), pointer :: a(:) => null()
> and
>   real, dimension(10), allocatable :: a(10)
> are invalid and shall give an error.

I concur with the second example (violating the cited constraint), but the
first one looks valid to me. In particular:

F2018 has in 8.2 [92:1-3]): "The type declaration statement also specifies the
attributes whose keywords appear in the attr-spec, except that the DIMENSION
attribute can be specified or overridden for an entity by the appearance of
array-spec in its entity-decl,"

Thus, unless I missed some example, this PR looks invalid to me.

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

* [Bug fortran/99765] Explicit dimension size declaration of pointer array allowed
  2021-03-25  9:22 [Bug fortran/99765] New: Explicit dimension size declaration of pointer array allowed nickpapior at gmail dot com
                   ` (2 preceding siblings ...)
  2021-03-25 15:48 ` burnus at gcc dot gnu.org
@ 2021-03-26  6:41 ` nickpapior at gmail dot com
  2021-03-26  7:36 ` burnus at gcc dot gnu.org
  4 siblings, 0 replies; 6+ messages in thread
From: nickpapior at gmail dot com @ 2021-03-26  6:41 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #4 from Nick <nickpapior at gmail dot com> ---
I see. I can't seem to find the mentioned line in f2003.

I don't know if anything needs to be done. If the programmer expected something
different than the last dimension specifier, they would very quickly figure out
that it doesn't work as intended.

In any case, I would be fine if this is marked as invalid and you left it as it
is since f2008 denotes this as valid code.


By the way

 real, dimension(10), allocatable :: a(10)

is currently still recognized as an error (as I also mentioned). So basically
everything is fine.

Sorry for the blurp.

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

* [Bug fortran/99765] Explicit dimension size declaration of pointer array allowed
  2021-03-25  9:22 [Bug fortran/99765] New: Explicit dimension size declaration of pointer array allowed nickpapior at gmail dot com
                   ` (3 preceding siblings ...)
  2021-03-26  6:41 ` nickpapior at gmail dot com
@ 2021-03-26  7:36 ` burnus at gcc dot gnu.org
  4 siblings, 0 replies; 6+ messages in thread
From: burnus at gcc dot gnu.org @ 2021-03-26  7:36 UTC (permalink / raw)
  To: gcc-bugs

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|NEW                         |RESOLVED

--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Nick from comment #4)
> I see. I can't seem to find the mentioned line in f2003.

Should be there as well.

In Fortran 2008, it is in "5.2 Type declaration statements", p.88, lines 1-4
(same/similar to F2018).

In Fortran 2003, it is in "5.1.2.5  DIMENSION attribute", p. 78, ll. 3-5:

"The DIMENSION attribute specifies that an entity is an array.  The rank or
rank and shape is specified by the array-spec, if there is one, in the
entity-decl, or by the array-spec in the DIMENSION attr-spec otherwise."

That choice makese sense, e.g. for:

complex(kind=my_cmplx_kind), intent(in), asynchronous, dimension(n,n) :: A, B,
C, D, v(n)

such that one does not need to repeat all the lengthy stuff just to denote the
different array spec for 'v'. (On the other hand, whether there is a need to
specify everything in several different ways and permit overriding in addition
is another question.)

Thus, the standard made a sensible choice – and the standard is the standard
:-) 


> In any case, I would be fine if this is marked as invalid

Done so: CLOSE as INVALID.


> Sorry for the blurp.

Better some noise than missing some real bugs or useful improvements. Hence:
Thanks!

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

end of thread, other threads:[~2021-03-26  7:36 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-25  9:22 [Bug fortran/99765] New: Explicit dimension size declaration of pointer array allowed nickpapior at gmail dot com
2021-03-25 11:43 ` [Bug fortran/99765] " dominiq at lps dot ens.fr
2021-03-25 11:47 ` nickpapior at gmail dot com
2021-03-25 15:48 ` burnus at gcc dot gnu.org
2021-03-26  6:41 ` nickpapior at gmail dot com
2021-03-26  7:36 ` burnus at gcc dot gnu.org

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).