public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/67430] New: reallocate lhs with overloaded assignment operators causes memory error and wrong size
@ 2015-09-02 5:37 alipasha.celeris at gmail dot com
2015-09-02 6:07 ` [Bug fortran/67430] " kargl at gcc dot gnu.org
` (6 more replies)
0 siblings, 7 replies; 8+ messages in thread
From: alipasha.celeris at gmail dot com @ 2015-09-02 5:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67430
Bug ID: 67430
Summary: reallocate lhs with overloaded assignment operators
causes memory error and wrong size
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: alipasha.celeris at gmail dot com
Target Milestone: ---
Created attachment 36284
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36284&action=edit
the test file with line numbers matching the Valgrind output.
The following code produces a memory error in Valgrind (an invalid read) and
does not reallocate the LHS to the correct size.
MODULE A_TEST_M
TYPE :: A_TYPE
INTEGER :: INT
!
CONTAINS
!
GENERIC :: ASSIGNMENT (=) => ASGN_A
PROCEDURE, PRIVATE :: ASGN_A
END TYPE
CONTAINS
ELEMENTAL SUBROUTINE ASGN_A (A, B)
CLASS (A_TYPE), INTENT (INOUT) :: A
CLASS (A_TYPE), INTENT (IN) :: B
!
A%INT = 45
END SUBROUTINE
END MODULE A_TEST_M
PROGRAM ASGN_REALLOC_TEST
USE A_TEST_M
TYPE (A_TYPE), ALLOCATABLE :: A(:)
!
ALLOCATE (A(4))
A(1:2)%INT = 7
A(3:4)%INT = 13
!
A = A(1:2)
!
PRINT *, 'SIZE(A)', SIZE(A), 'A:', A
END PROGRAM
The results look like this (valgrind output):
==30070== Memcheck, a memory error detector
==30070== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==30070== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright
info
==30070== Command: ./a.out
==30070==
==30070== Invalid read of size 8
==30070== at 0x402F148: _intel_fast_memcpy (vg_replace_strmem.c:946)
==30070== by 0x400CA1: MAIN__ (asgn_realloc_test.f:29)
==30070== by 0x400DF3: main (asgn_realloc_test.f:22)
==30070== Address 0x50f37c8 is 0 bytes after a block of size 8 alloc'd
==30070== at 0x402BB20: malloc (vg_replace_malloc.c:299)
==30070== by 0x400C13: MAIN__ (asgn_realloc_test.f:29)
==30070== by 0x400DF3: main (asgn_realloc_test.f:22)
==30070==
SIZE(A) 4 A: 45 45 0 0
"A" should have size of 2 after assignment (being reallocated). It seems that
the overloaded operator is being used (it is rigged to assign 45).
The intrinsic assignment (when = is not overloaded) works fine.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug fortran/67430] reallocate lhs with overloaded assignment operators causes memory error and wrong size
2015-09-02 5:37 [Bug fortran/67430] New: reallocate lhs with overloaded assignment operators causes memory error and wrong size alipasha.celeris at gmail dot com
@ 2015-09-02 6:07 ` kargl at gcc dot gnu.org
2015-09-02 8:51 ` dominiq at lps dot ens.fr
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: kargl at gcc dot gnu.org @ 2015-09-02 6:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67430
kargl at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|major |normal
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug fortran/67430] reallocate lhs with overloaded assignment operators causes memory error and wrong size
2015-09-02 5:37 [Bug fortran/67430] New: reallocate lhs with overloaded assignment operators causes memory error and wrong size alipasha.celeris at gmail dot com
2015-09-02 6:07 ` [Bug fortran/67430] " kargl at gcc dot gnu.org
@ 2015-09-02 8:51 ` dominiq at lps dot ens.fr
2015-09-02 20:27 ` andrew at boldfriend dot org
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: dominiq at lps dot ens.fr @ 2015-09-02 8:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67430
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
The code in comment 0 is invalid: in
A = A(1:2)
you assign two elements to a four element array. If you compile your code with
'-fcheck=all', you get at run time the error
At line 29 of file pr67430.f90
Fortran runtime error: Array bound mismatch for dimension 1 of array 'a' (2/4)
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug fortran/67430] reallocate lhs with overloaded assignment operators causes memory error and wrong size
2015-09-02 5:37 [Bug fortran/67430] New: reallocate lhs with overloaded assignment operators causes memory error and wrong size alipasha.celeris at gmail dot com
2015-09-02 6:07 ` [Bug fortran/67430] " kargl at gcc dot gnu.org
2015-09-02 8:51 ` dominiq at lps dot ens.fr
@ 2015-09-02 20:27 ` andrew at boldfriend dot org
2015-09-02 21:51 ` anlauf at gmx dot de
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: andrew at boldfriend dot org @ 2015-09-02 20:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67430
--- Comment #2 from Andrew Baldwin <andrew at boldfriend dot org> ---
In 7.2.1.4 of my copy of the standard it states:
"A subroutine defines the defined assignment x1 = x2 if"
...
"(5) either
(a) the ranks of x1 and x2 match those of d1 and d2 or
(b) the subroutine is elemental, x1 and x2 are conformable, and there is no
other subroutine that defines the assignment."
Since x1 and x2 are not conformable in this instance the defined assignment
(overloaded assignment) my reading is that it should not occur.
However, assigning two elements to an allocatable array allocated to four
elements is not invalid for intrinsic assignment. Note 7.38 in my copy of the
standard states:
"If C is an allocatable array of rank 1, then
C = PACK(ARRAY,ARRAY>0)
will cause C to contain all the positive elements of ARRAY in array element
order; if C is not allocated or is allocated with the wrong size, it will be
re-allocated to be of the correct size to hold the result of PACK."
This behavior is observed when the overloaded assignment operator is not
provided. The output in that case is:
SIZE(A) 2 A: 7 7
It is also observed when the defined assignment does not meet the requirement
(5a). I.e. replacing the defined assignment with
SUBROUTINE ASGN_A (A, B)
CLASS (A_TYPE), INTENT (OUT) :: A(:)
CLASS (A_TYPE), INTENT (IN) :: B
!
A(:)%INT = 45
END SUBROUTINE
and changing the generic binding to a generic interface. The output in that
case is also:
SIZE(A) 2 A: 7 7
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug fortran/67430] reallocate lhs with overloaded assignment operators causes memory error and wrong size
2015-09-02 5:37 [Bug fortran/67430] New: reallocate lhs with overloaded assignment operators causes memory error and wrong size alipasha.celeris at gmail dot com
` (2 preceding siblings ...)
2015-09-02 20:27 ` andrew at boldfriend dot org
@ 2015-09-02 21:51 ` anlauf at gmx dot de
2015-09-04 9:39 ` dominiq at lps dot ens.fr
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: anlauf at gmx dot de @ 2015-09-02 21:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67430
Harald Anlauf <anlauf at gmx dot de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |anlauf at gmx dot de
--- Comment #3 from Harald Anlauf <anlauf at gmx dot de> ---
(In reply to Andrew Baldwin from comment #2)
> In 7.2.1.4 of my copy of the standard it states:
>
> "A subroutine defines the defined assignment x1 = x2 if"
>
> ...
>
> "(5) either
> (a) the ranks of x1 and x2 match those of d1 and d2 or
> (b) the subroutine is elemental, x1 and x2 are conformable, and there is
> no other subroutine that defines the assignment."
It also says:
"If d1 or d2 is an array, the shapes of x1 and x2 shall match the shapes of d1
and d2 , respectively."
This is not the case for your example.
(NAG and Crayftn also do not reallocation.)
> Since x1 and x2 are not conformable in this instance the defined assignment
> (overloaded assignment) my reading is that it should not occur.
I'm no standard expert, but (5)(a) appears to be satisfied, so the
non-conformance of x1 and x2 does not matter.
To be sure, consider posting your question on comp.lang.fortran.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug fortran/67430] reallocate lhs with overloaded assignment operators causes memory error and wrong size
2015-09-02 5:37 [Bug fortran/67430] New: reallocate lhs with overloaded assignment operators causes memory error and wrong size alipasha.celeris at gmail dot com
` (3 preceding siblings ...)
2015-09-02 21:51 ` anlauf at gmx dot de
@ 2015-09-04 9:39 ` dominiq at lps dot ens.fr
2015-09-05 21:05 ` dominiq at lps dot ens.fr
2021-01-23 12:13 ` tkoenig at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: dominiq at lps dot ens.fr @ 2015-09-04 9:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67430
--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Am I correct to summarize (simplify?) your expectation (interpretation as:
use the overloaded assignment if the lhs and rhs are conforming, otherwise use
the intrinsic assignment?
If yes, what the compiler should do if some bounds are only known at run time?
I agree with the first comment of Ian Harvey at
https://groups.google.com/forum/#!topic/comp.lang.fortran/Vk4D8iDZOdc.
I have no opinion for the second test in the above thread, beside a "don't do
that!". If you think it is a gfortran bug, please file a new PR and, if
possible, outputs from other compilers you have access to.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug fortran/67430] reallocate lhs with overloaded assignment operators causes memory error and wrong size
2015-09-02 5:37 [Bug fortran/67430] New: reallocate lhs with overloaded assignment operators causes memory error and wrong size alipasha.celeris at gmail dot com
` (4 preceding siblings ...)
2015-09-04 9:39 ` dominiq at lps dot ens.fr
@ 2015-09-05 21:05 ` dominiq at lps dot ens.fr
2021-01-23 12:13 ` tkoenig at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: dominiq at lps dot ens.fr @ 2015-09-05 21:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67430
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |SUSPENDED
Last reconfirmed| |2015-09-05
Resolution|INVALID |---
Ever confirmed|0 |1
--- Comment #5 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
>From https://groups.google.com/forum/#!topic/comp.lang.fortran/Vk4D8iDZOdc
This has just been discussed on the J3 mailing list. (Bob Corbett (I
think) picked up the original question and passed it on). My
understanding of the discussion so far is that
A) whoops, there's an error introduced by the reallocation on
assignment stuff
B) It has always been the intent of J3 to make the distinction between
defined and intrinsic assignment to be a compile time choice.
C) A (likely? possible?) fix is to add something like "unless the ranks
are different" to one of the rules in the disambiguation text for
intrinsic and defined assignment. (It's possible it was "ranks are the
same", I don't remember)
That's about all I remember of the discussion.
Dick Hendrickson
Marking this PR as SUSPENDED while waiting for the J3 ruling.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug fortran/67430] reallocate lhs with overloaded assignment operators causes memory error and wrong size
2015-09-02 5:37 [Bug fortran/67430] New: reallocate lhs with overloaded assignment operators causes memory error and wrong size alipasha.celeris at gmail dot com
` (5 preceding siblings ...)
2015-09-05 21:05 ` dominiq at lps dot ens.fr
@ 2021-01-23 12:13 ` tkoenig at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2021-01-23 12:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67430
Thomas Koenig <tkoenig at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tkoenig at gcc dot gnu.org
--- Comment #6 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #5)
> Marking this PR as SUSPENDED while waiting for the J3 ruling.
Do you know how the discussion turned out?
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-01-23 12:13 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-09-02 5:37 [Bug fortran/67430] New: reallocate lhs with overloaded assignment operators causes memory error and wrong size alipasha.celeris at gmail dot com
2015-09-02 6:07 ` [Bug fortran/67430] " kargl at gcc dot gnu.org
2015-09-02 8:51 ` dominiq at lps dot ens.fr
2015-09-02 20:27 ` andrew at boldfriend dot org
2015-09-02 21:51 ` anlauf at gmx dot de
2015-09-04 9:39 ` dominiq at lps dot ens.fr
2015-09-05 21:05 ` dominiq at lps dot ens.fr
2021-01-23 12:13 ` tkoenig 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).