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
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
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.
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
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
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58175
patnel97269-gfortran at yahoo dot fr changed:
What|Removed |Added
CC||patnel97269
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63553
patnel97269-gfortran at yahoo dot fr changed:
What|Removed |Added
CC||patnel97269
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63640
patnel97269-gfortran at yahoo dot fr changed:
What|Removed |Added
Severity|major |critical
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63640
patnel97269-gfortran at yahoo dot fr changed:
What|Removed |Added
Severity|critical|normal
: 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
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(:)
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
16 matches
Mail list logo
