[Bug c/99779] New: [GCC-10.1.0]A bug when assign to a pointer by function which process the pointer inside.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99779
Bug ID: 99779
Summary: [GCC-10.1.0]A bug when assign to a pointer by function
which process the pointer inside.
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: xin@compiler-dev.com
Target Milestone: ---
As shown in the following testcase：
int helloa = 12;
int hellob = 13;
int *fp=&helloa;
int __attribute__((noinline)) foo()
{
fp=&hellob;
return 15;
}
int main()
{
*fp = foo();
printf("helloa=%d,hellob=%d\n",helloa,hellob);
}
compile with gcc-10.1.0 and any optimization, the result is
helloa=15,hellob=13
but with clang-10.0.1, the result is
helloa=12,hellob=15
According to this testcase, in my opinion ,the clang's result is right.
gcc do not process it correctly.
[Bug fortran/97920] New: [FINAL] -O2 segment fault due to extend derive type's member being partially allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97920 Bug ID: 97920 Summary: [FINAL] -O2 segment fault due to extend derive type's member being partially allocated Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: xin@compiler-dev.com Target Milestone: --- Consider the following Fortran testcase: module m type t1 real, dimension(:), pointer :: a contains final :: t1f end type type, extends(t1) :: t2 real, dimension(:), pointer :: b contains final :: t2f end type contains subroutine t1f(x) type(t1) :: x if (associated(x%a)) deallocate(x%a) end subroutine subroutine t2f(x) type(t2) :: x if (associated(x%b)) deallocate(x%b) end subroutine end module subroutine test use m implicit none type(t1) :: a type(t2) :: b allocate(b%a(3)) ! allocate(b%b(3)) end subroutine program p use m call test() end program Compiled with gfortran 10.1.0 in -O2, the testcase prints: Program received signal SIGSEGV: Segmentation fault - invalid memory reference. If add a statement as 'allocate(b%b(3))', it will pass with no segment fault.I guess this segment fault maybe due to extend derive type's member being partially allocated.
[Bug fortran/97920] [FINAL] -O2 segment fault due to extend derive type's member being partially allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97920 --- Comment #4 from xin liu --- (In reply to Thomas Koenig from comment #3) > Paul is correct, the state of the pointers is undefined. > > What you can do to correct this is to use > > module m > type t1 > real, dimension(:), pointer :: a => NULL() > contains > final :: t1f > end type > > type, extends(t1) :: t2 > real, dimension(:), pointer :: b => NULL() > contains > final :: t2f > end type > > which will then run as expected. OK,Thanks!
[Bug fortran/97920] [FINAL] -O2 segment fault due to extend derive type's member being partially allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97920 --- Comment #5 from xin liu --- (In reply to Paul Thomas from comment #2) > (In reply to Martin Liška from comment #1) > > Confirmed with valgrind. At least as old as 4.9.0. > > Hi, > > From a quick perusal of the standard, I find in F2003 16.4.2.1: > > "Unless a pointer is initialized (explicitly or by default), it has an > initial association status of undefined. A pointer may be initialized to > have an > association status of disassociated". > > In your testcase, the status of b%b is undefined and so the compiler can do > anything it wants with it, including segfaulting. I think therefore that you > should initialize the derived types in your application as follows: > > type t1 > real, dimension(:), pointer :: a => NULL () > contains > final :: t1f > end type > > type, extends(t1) :: t2 > real, dimension(:), pointer :: b => NULL () > contains > final :: t2f > end type > > This clears the valgrind error "Conditional jump or move depends on > uninitialised value(s)". Also the finalization is invoked so that the > programme completes with zero memory allocation, > > To my surprise (probably due to standard ignorance), leaving the declared > type declarations as you have them, and declaring 'b' as > > type(t2) :: b = t2 (NULL(), NULL()) > > clears the valgrind fault but no finalization occurs. I notice that > finalization does not occur if an entity has the save attribute. gfortran > assigns 'b' the IMPLICIT-SAVE attribute, which is why the finalization does > not occur. I have been unable to find whether or not this is conforming. > > However, initializing 'b' in an assignment: > b = t2(NULL(), NULL()) > > clears the valgrind fault and results in the deallocation of memory. This > confirms my suspicion about the save attribute. > > In conclusion, I do not believe that this is a bug. If you do not use > pointers as pointers, make them allocatable instead. These are automatically > nullified on entry into scope. > > Thanks for the report by the way! > > Paul I get it, Thanks for your explain.
[Bug fortran/102699] New: Stream access input/output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102699 Bug ID: 102699 Summary: Stream access input/output Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: xin@compiler-dev.com Target Milestone: --- Consider the following Fortran program: ! program streamio implicit none integer :: k(5) = [5_4, 4_4, 3_4, 2_4, 1_4] open(10, file="123.txt", form="formatted", access="stream") ! open(10, file="123.txt", form="formatted") write(10, "(A6)") '098765' write(10, "(A6)") '239345' write(10, "(A6)") '123789' write(10, "(A6)") '789509' write(10, "(A6)") '543210' rewind(10) read(10, "(I2)") k(1) read(10, "(I3)") k(2) read(10, "(I2)") k(3) read(10, "(I3)") k(4) read(10, "(I1)") k(5) print *,k end program ! Compiled with gfortran 10.1.0. Regardless of whether the access uses "stream",the result is the same. the result: 9 239 12 789 5 the file: 098765 239345 123789 789509 543210 IMHO, when using access="stream", the result should be 9 876 52 393 4 and the file shoule be 098765239345123789789509543210 is it a bug or is there something wrong with my understanding?
