public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/52010] New: Intrinsic assignment involving CLASS/TYPE
@ 2012-01-26 15:55 fmartinez at gmv dot com
2012-01-26 18:40 ` [Bug fortran/52010] " dominiq at lps dot ens.fr
` (9 more replies)
0 siblings, 10 replies; 11+ messages in thread
From: fmartinez at gmv dot com @ 2012-01-26 15:55 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52010
Bug #: 52010
Summary: Intrinsic assignment involving CLASS/TYPE
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: fmartinez@gmv.com
The attached examle generates a compiler error about not being able to convert
from CLASS to TYPE being the object of the same declared type.
Reported bug 41719 addresses partially this issue although looking at the
standard (7.4.1) I cannot really see that this assignment is incorrect.
The Intel compiler does not complain about this even with the stardard 2003
flags activated.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/52010] Intrinsic assignment involving CLASS/TYPE
2012-01-26 15:55 [Bug fortran/52010] New: Intrinsic assignment involving CLASS/TYPE fmartinez at gmv dot com
@ 2012-01-26 18:40 ` dominiq at lps dot ens.fr
2012-01-26 18:42 ` fmartinez at gmv dot com
` (8 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: dominiq at lps dot ens.fr @ 2012-01-26 18:40 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52010
--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-01-26 16:22:51 UTC ---
> The attached examle generates a compiler error about not being able to convert
> from CLASS to TYPE being the object of the same declared type.
There is no attachment!-(
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/52010] Intrinsic assignment involving CLASS/TYPE
2012-01-26 15:55 [Bug fortran/52010] New: Intrinsic assignment involving CLASS/TYPE fmartinez at gmv dot com
2012-01-26 18:40 ` [Bug fortran/52010] " dominiq at lps dot ens.fr
@ 2012-01-26 18:42 ` fmartinez at gmv dot com
2012-01-27 17:07 ` [Bug fortran/52010] [OOP] Intrinsic assignment of a CLASS to a TYPE burnus at gcc dot gnu.org
` (7 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: fmartinez at gmv dot com @ 2012-01-26 18:42 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52010
--- Comment #2 from Fran Martinez Fadrique <fmartinez at gmv dot com> 2012-01-26 16:25:41 UTC ---
Created attachment 26473
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26473
Test sample
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/52010] [OOP] Intrinsic assignment of a CLASS to a TYPE
2012-01-26 15:55 [Bug fortran/52010] New: Intrinsic assignment involving CLASS/TYPE fmartinez at gmv dot com
2012-01-26 18:40 ` [Bug fortran/52010] " dominiq at lps dot ens.fr
2012-01-26 18:42 ` fmartinez at gmv dot com
@ 2012-01-27 17:07 ` burnus at gcc dot gnu.org
2012-01-28 19:09 ` dominiq at lps dot ens.fr
` (6 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-01-27 17:07 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52010
--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-01-27 16:06:51 UTC ---
The following handles the checking part. However, one also needs to handle the
access internally (in trans-expr.c). Namely:
type_var = class_var
type_var = class_function ()
and both for "scalar = scalar", "array = scalar" and "array = array". Note that
the class_function can also be an intrinsic function such as RESHAPE. (Cf.
PR47505.)
--- expr.c (revision 183625)
+++ expr.c (working copy)
@@ -3256,3 +3256,8 @@ gfc_check_assign (gfc_expr *lvalue, gfc_
- if (gfc_compare_types (&lvalue->ts, &rvalue->ts))
+ if (lvalue->ts.type == BT_DERIVED && rvalue->ts.type == BT_CLASS)
+ {
+ if (gfc_compare_types (&lvalue->ts, &CLASS_DATA (rvalue)->ts))
+ return SUCCESS;
+ }
+ else if (gfc_compare_types (&lvalue->ts, &rvalue->ts))
return SUCCESS;
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/52010] [OOP] Intrinsic assignment of a CLASS to a TYPE
2012-01-26 15:55 [Bug fortran/52010] New: Intrinsic assignment involving CLASS/TYPE fmartinez at gmv dot com
` (2 preceding siblings ...)
2012-01-27 17:07 ` [Bug fortran/52010] [OOP] Intrinsic assignment of a CLASS to a TYPE burnus at gcc dot gnu.org
@ 2012-01-28 19:09 ` dominiq at lps dot ens.fr
2012-01-28 23:38 ` fmartinez at gmv dot com
` (5 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: dominiq at lps dot ens.fr @ 2012-01-28 19:09 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52010
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2012-01-28
Ever Confirmed|0 |1
--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-01-28 17:40:51 UTC ---
The error is gone with the patch in comment #3. Note that playing with the
code, the following two avatars give an ICE after error:
[macbook] f90/bug% diff -up pr52010.f90 pr52010_db_1.f90
--- pr52010.f90 2012-01-26 17:36:45.000000000 +0100
+++ pr52010_db_1.f90 2012-01-26 17:40:47.000000000 +0100
@@ -16,7 +16,7 @@ subroutine subrt( x )
class(t1), intent(in) :: x
- type(t1) :: local
+ class(t1) :: local
local = x
[macbook] f90/bug% gfc pr52010_db_1.f90
pr52010_db_1.f90:19.19:
class(t1) :: local
1
Error: CLASS variable 'local' at (1) must be dummy, allocatable or pointer
f951: internal compiler error: Segmentation fault
[macbook] f90/bug% diff -up pr52010.f90 pr52010_db_2.f90
--- pr52010.f90 2012-01-26 17:36:45.000000000 +0100
+++ pr52010_db_2.f90 2012-01-26 17:41:50.000000000 +0100
@@ -6,7 +6,7 @@ program test
integer :: a
end type
- type(t1) :: x
+ class(t1) :: x
call subrt( x )
[macbook] f90/bug% gfc pr52010_db_2.f90
pr52010_db_2.f90:9.15:
class(t1) :: x
1
Error: CLASS variable 'x' at (1) must be dummy, allocatable or pointer
f951: internal compiler error: Segmentation fault
The backtrace for the first case is
#0 gfc_find_typebound_intrinsic_op (derived=0x0, t=0x7fff5fbfd304,
op=INTRINSIC_ASSIGN, noaccess=false, where=0x0)
at ../../work/gcc/fortran/class.c:946
#1 0x0000000100037746 in matching_typebound_op (tb_base=0x7fff5fbfd368,
args=0x141e07910, op=INTRINSIC_ASSIGN, uop=0x0, gname=0x7fff5fbfd360)
at ../../work/gcc/fortran/interface.c:3199
#2 0x00000001000381db in gfc_extend_assign (c=0x141e16a30, ns=0x0) at
../../work/gcc/fortran/interface.c:3478
#3 0x000000010008c76f in resolve_code (code=<value optimized out>, ns=<value
optimized out>) at ../../work/gcc/fortran/resolve.c:9068
#4 0x000000010008f014 in resolve_codes (ns=<value optimized out>) at
../../work/gcc/fortran/resolve.c:13945
#5 0x000000010008ef18 in resolve_codes (ns=<value optimized out>) at
../../work/gcc/fortran/resolve.c:13931
#6 0x000000010007ee38 in gfc_resolve (ns=<value optimized out>) at
../../work/gcc/fortran/resolve.c:13972
#7 0x000000010007477b in gfc_parse_file () at
../../work/gcc/fortran/parse.c:4387
#8 0x00000001000b3486 in gfc_be_parse_file () at
../../work/gcc/fortran/f95-lang.c:250
#9 0x00000001007b8051 in toplev_main (argc=2, argv=0x7fff5fbfd7a0) at
../../work/gcc/toplev.c:557
#10 0x00000001000016c4 in start ()
and for the second case it is
#0 gfc_compare_derived_types (derived1=0x141e13d70, derived2=0x0) at
../../work/gcc/fortran/interface.c:402
#1 0x00000001000a6327 in gfc_type_is_extension_of (t1=0x141e13d70, t2=0x0) at
../../work/gcc/fortran/symbol.c:4823
#2 0x00000001000333cb in gfc_compare_types (ts1=0x141e146c0, ts2=0x141e14328)
at ../../work/gcc/fortran/interface.c:495
#3 0x00000001000347aa in compare_parameter (formal=0x141e146a0,
actual=0x141e14320, ranks_must_agree=0, is_elemental=<value optimized out>,
where=0x141e13878) at ../../work/gcc/fortran/interface.c:1697
#4 0x0000000100035a34 in compare_actual_formal (ap=0x141e138e0,
formal=0x141e05f40, ranks_must_agree=0, is_elemental=0, where=0x141e13878)
at ../../work/gcc/fortran/interface.c:2270
#5 0x0000000100037337 in gfc_procedure_use (sym=0x141e13fc0, ap=0x141e138e0,
where=<value optimized out>) at ../../work/gcc/fortran/interface.c:2961
#6 0x0000000100087d59 in resolve_call (c=<value optimized out>) at
../../work/gcc/fortran/resolve.c:3614
#7 0x000000010008c7ce in resolve_code (code=<value optimized out>, ns=<value
optimized out>) at ../../work/gcc/fortran/resolve.c:9480
#8 0x000000010008f014 in resolve_codes (ns=<value optimized out>) at
../../work/gcc/fortran/resolve.c:13945
#9 0x000000010007ee38 in gfc_resolve (ns=<value optimized out>) at
../../work/gcc/fortran/resolve.c:13972
#10 0x000000010007477b in gfc_parse_file () at
../../work/gcc/fortran/parse.c:4387
#11 0x00000001000b3486 in gfc_be_parse_file () at
../../work/gcc/fortran/f95-lang.c:250
#12 0x00000001007b8051 in toplev_main (argc=2, argv=0x7fff5fbfd7a0) at
../../work/gcc/toplev.c:557
#13 0x00000001000016c4 in start ()
Should I open new PR(s) for them?
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/52010] [OOP] Intrinsic assignment of a CLASS to a TYPE
2012-01-26 15:55 [Bug fortran/52010] New: Intrinsic assignment involving CLASS/TYPE fmartinez at gmv dot com
` (3 preceding siblings ...)
2012-01-28 19:09 ` dominiq at lps dot ens.fr
@ 2012-01-28 23:38 ` fmartinez at gmv dot com
2012-01-28 23:40 ` fmartinez at gmv dot com
` (4 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: fmartinez at gmv dot com @ 2012-01-28 23:38 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52010
--- Comment #5 from Fran Martinez Fadrique <fmartinez at gmv dot com> 2012-01-28 23:08:46 UTC ---
I have bumped into another problem that I think may be related to this same
topic.
I have an example that generates the following message:
m_pointer_test.f90:22.2:
b%pa => a
1
Error: Different types in pointer assignment at (1); attempted assignment of
CLASS(ta) to TYPE(ta)
If in line 14 I make the change from
type(ta), pointer :: pa => null()
to
class(ta), pointer :: pa => null()
Then it works but then it does not in my Intel version. Actually I do not see
the reason why the change should be made. I have not been able to trace this to
the standard.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/52010] [OOP] Intrinsic assignment of a CLASS to a TYPE
2012-01-26 15:55 [Bug fortran/52010] New: Intrinsic assignment involving CLASS/TYPE fmartinez at gmv dot com
` (4 preceding siblings ...)
2012-01-28 23:38 ` fmartinez at gmv dot com
@ 2012-01-28 23:40 ` fmartinez at gmv dot com
2014-12-29 3:46 ` pault at gcc dot gnu.org
` (3 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: fmartinez at gmv dot com @ 2012-01-28 23:40 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52010
--- Comment #6 from Fran Martinez Fadrique <fmartinez at gmv dot com> 2012-01-28 23:09:49 UTC ---
Created attachment 26494
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26494
Test sample to support comment 5
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/52010] [OOP] Intrinsic assignment of a CLASS to a TYPE
2012-01-26 15:55 [Bug fortran/52010] New: Intrinsic assignment involving CLASS/TYPE fmartinez at gmv dot com
` (5 preceding siblings ...)
2012-01-28 23:40 ` fmartinez at gmv dot com
@ 2014-12-29 3:46 ` pault at gcc dot gnu.org
2014-12-30 3:12 ` pault at gcc dot gnu.org
` (2 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: pault at gcc dot gnu.org @ 2014-12-29 3:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52010
Paul Thomas <pault at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pault at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
--- Comment #7 from Paul Thomas <pault at gcc dot gnu.org> ---
My patch for PR63205 fixes the first problem. I'll have a stab at the problem
in comment #6 although it has nothing to do with the first.
Paul
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/52010] [OOP] Intrinsic assignment of a CLASS to a TYPE
2012-01-26 15:55 [Bug fortran/52010] New: Intrinsic assignment involving CLASS/TYPE fmartinez at gmv dot com
` (6 preceding siblings ...)
2014-12-29 3:46 ` pault at gcc dot gnu.org
@ 2014-12-30 3:12 ` pault at gcc dot gnu.org
2015-10-18 20:54 ` dominiq at lps dot ens.fr
2015-10-19 4:40 ` paul.richard.thomas at gmail dot com
9 siblings, 0 replies; 11+ messages in thread
From: pault at gcc dot gnu.org @ 2014-12-30 3:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52010
Paul Thomas <pault at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |damian at sourceryinstitute dot or
| |g
--- Comment #8 from Paul Thomas <pault at gcc dot gnu.org> ---
In fact, it appears that both tests are fixed by the current patch in PR63205.
This works fine:
module m_test
implicit none
type ta
private
integer :: i = 99
contains
procedure :: suba
end type ta
type tb
private
class(ta), pointer :: pa => null()
contains
procedure :: disp
end type tb
contains
function suba( a, v) result(b)
class(ta), target, intent(inout) :: a
type(tb) :: b
integer :: v
a%i = v
b%pa => a
end function suba
subroutine disp (arg)
class(tb), intent(in) :: arg
print *, arg%pa%i
end subroutine
end module m_test
use m_test
class(ta), allocatable :: tgt
type(tb) :: PTR
allocate (tgt)
ptr = tgt%suba(42)
call ptr%disp
deallocate (tgt)
end
Paul
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/52010] [OOP] Intrinsic assignment of a CLASS to a TYPE
2012-01-26 15:55 [Bug fortran/52010] New: Intrinsic assignment involving CLASS/TYPE fmartinez at gmv dot com
` (7 preceding siblings ...)
2014-12-30 3:12 ` pault at gcc dot gnu.org
@ 2015-10-18 20:54 ` dominiq at lps dot ens.fr
2015-10-19 4:40 ` paul.richard.thomas at gmail dot com
9 siblings, 0 replies; 11+ messages in thread
From: dominiq at lps dot ens.fr @ 2015-10-18 20:54 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52010
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Known to work| |4.8.5, 4.9.3, 5.2.0, 6.0
Resolution|--- |FIXED
--- Comment #9 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> In fact, it appears that both tests are fixed by the current patch in PR63205.
> This works fine: ...
Confirmed. Closing as FIXED.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/52010] [OOP] Intrinsic assignment of a CLASS to a TYPE
2012-01-26 15:55 [Bug fortran/52010] New: Intrinsic assignment involving CLASS/TYPE fmartinez at gmv dot com
` (8 preceding siblings ...)
2015-10-18 20:54 ` dominiq at lps dot ens.fr
@ 2015-10-19 4:40 ` paul.richard.thomas at gmail dot com
9 siblings, 0 replies; 11+ messages in thread
From: paul.richard.thomas at gmail dot com @ 2015-10-19 4:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52010
--- Comment #10 from paul.richard.thomas at gmail dot com <paul.richard.thomas at gmail dot com> ---
Hi Dominique,
I was about to close this one right now.... :-)
Thanks
Paul
On 18 October 2015 at 22:54, dominiq at lps dot ens.fr
<gcc-bugzilla@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52010
>
> Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> Status|NEW |RESOLVED
> Known to work| |4.8.5, 4.9.3, 5.2.0, 6.0
> Resolution|--- |FIXED
>
> --- Comment #9 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
>> In fact, it appears that both tests are fixed by the current patch in PR63205.
>> This works fine: ...
>
> Confirmed. Closing as FIXED.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2015-10-19 4:40 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-01-26 15:55 [Bug fortran/52010] New: Intrinsic assignment involving CLASS/TYPE fmartinez at gmv dot com
2012-01-26 18:40 ` [Bug fortran/52010] " dominiq at lps dot ens.fr
2012-01-26 18:42 ` fmartinez at gmv dot com
2012-01-27 17:07 ` [Bug fortran/52010] [OOP] Intrinsic assignment of a CLASS to a TYPE burnus at gcc dot gnu.org
2012-01-28 19:09 ` dominiq at lps dot ens.fr
2012-01-28 23:38 ` fmartinez at gmv dot com
2012-01-28 23:40 ` fmartinez at gmv dot com
2014-12-29 3:46 ` pault at gcc dot gnu.org
2014-12-30 3:12 ` pault at gcc dot gnu.org
2015-10-18 20:54 ` dominiq at lps dot ens.fr
2015-10-19 4:40 ` paul.richard.thomas at gmail dot com
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).