[Bug fortran/66227] [OOP] EXTENDS_TYPE_OF n returns wrong result for polymorphic variable allocated to extended type

2015-09-15 Thread patnel97269-gfortran at yahoo dot fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66227 --- Comment #2 from patnel97269-gfortran at yahoo dot fr --- Yes the first and third should be True as i understand.

[Bug fortran/66227] New: [OOP] EXTENDS_TYPE_OF n returns wrong result for polymorphic variable allocated to extended type

2015-05-20 Thread patnel97269-gfortran at yahoo dot fr
Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: patnel97269-gfortran at yahoo dot fr Target Milestone: --- Hi, The extends_type_of intrisic return the wrong value for the a polymorphic variable

[Bug fortran/58175] [OOP] Incorrect warning message on scalar finalizer

2015-01-02 Thread patnel97269-gfortran at yahoo dot fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58175 patnel97269-gfortran at yahoo dot fr changed: What|Removed |Added CC||patnel97269

[Bug fortran/64397] [OOP] Runtime segfault with parenthesis expression passed to polymorphic dummy argument

2014-12-23 Thread patnel97269-gfortran at yahoo dot fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64397 --- Comment #7 from patnel97269-gfortran at yahoo dot fr --- (In reply to janus from comment #6) > (In reply to patnel97269-gfortran from comment #5) > > I agree that this example still trigger a bug, but I remember in my original

[Bug fortran/64397] [OOP] Runtime segfault with parenthesis expression passed to polymorphic dummy argument

2014-12-23 Thread patnel97269-gfortran at yahoo dot fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64397 --- Comment #5 from patnel97269-gfortran at yahoo dot fr --- (In reply to janus from comment #3) > Actually one can reduce it even further: > > > program main > > type :: my_integer > real, allocatable :: x(:)

[Bug fortran/64397] New: memory allocation failed with parenthesis

2014-12-23 Thread patnel97269-gfortran at yahoo dot fr
: fortran Assignee: unassigned at gcc dot gnu.org Reporter: patnel97269-gfortran at yahoo dot fr Hi all, I want to report a bug which i describe orignially here, https://gcc.gnu.org/ml/fortran/2014-12/msg00117.html . The expression (a+b) works well, while ((a)+(b)) triggers a memory

[Bug fortran/63640] move_alloc memory leak

2014-11-05 Thread patnel97269-gfortran at yahoo dot fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63640 patnel97269-gfortran at yahoo dot fr changed: What|Removed |Added Severity|critical|normal

[Bug fortran/63640] move_alloc memory leak

2014-11-04 Thread patnel97269-gfortran at yahoo dot fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63640 --- Comment #2 from patnel97269-gfortran at yahoo dot fr --- Thanks for the tip and the comment. So the standard say that move_alloc deallocate the array "from". Does that mean that the compiler mark the array as not allocated but doe

[Bug fortran/63640] move_alloc memory leak

2014-10-29 Thread patnel97269-gfortran at yahoo dot fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63640 patnel97269-gfortran at yahoo dot fr changed: What|Removed |Added Severity|major |critical

[Bug fortran/63640] New: move_alloc memory leak

2014-10-24 Thread patnel97269-gfortran at yahoo dot fr
Assignee: unassigned at gcc dot gnu.org Reporter: patnel97269-gfortran at yahoo dot fr Hi, The move_alloc intrisic has a memory leak, the object "from" doesn't seems to be deallocated. Here is a small test case with integer, but leaks also for dp. I'm using version 4.9.1

[Bug fortran/63553] [OOP] Wrong code when assigning a CLASS to a TYPE

2014-10-20 Thread patnel97269-gfortran at yahoo dot fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63553 --- Comment #5 from patnel97269-gfortran at yahoo dot fr --- Thanks for the patch. Another similar case, this time the type contains an allocatable field, produces a internal compiler error (without applying the patch) : internal compiler

[Bug fortran/63553] [OOP] Wrong code when assigning a CLASS to a TYPE

2014-10-16 Thread patnel97269-gfortran at yahoo dot fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63553 patnel97269-gfortran at yahoo dot fr changed: What|Removed |Added CC||patnel97269

[Bug fortran/60596] Inquire size for stream zero

2014-03-19 Thread patnel97269-gfortran at yahoo dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60596 --- Comment #4 from patnel97269-gfortran at yahoo dot fr --- Ok so if I understand well, for gfortran once the input_unit is closed, the unit number corresponding to input_unit can be used for another file. But, the input_unit is defined to be

[Bug fortran/60596] Inquire size for stream zero

2014-03-19 Thread patnel97269-gfortran at yahoo dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60596 --- Comment #2 from patnel97269-gfortran at yahoo dot fr --- Using your program, I get the same behavior I describe . Running with gfortran I get ./a.out < tmp.dat 400 0 0 Running with ifort I get ./a.

[Bug fortran/60596] New: Inquire size for stream zero

2014-03-19 Thread patnel97269-gfortran at yahoo dot fr
Assignee: unassigned at gcc dot gnu.org Reporter: patnel97269-gfortran at yahoo dot fr Created attachment 32398 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32398&action=edit program Hi all, When calling inquire for a stream size, the size is reported to be zero. In th

[Bug fortran/52774] New: A check is needed to prevent deallocation in realloc-lhs

2012-03-29 Thread patnel97269-gfortran at yahoo dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52774 Bug #: 52774 Summary: A check is needed to prevent deallocation in realloc-lhs Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED