User account creation filtered due to spam.
This bug has two parts. !here we have types of data: type cParticle real(4) :: v(3),r0(2),rS(3),r1(2),SinA,CosA endtype cParticle type aParticle real(4) :: v(3),r0(2) endtype aParticle type pCItem type(aParticle) :: Atm type(cParticle) :: Ele type(cParticle) :: Ion end type pCItem !and array+pointers: type(pCItem),allocatable,target,dimension(:,:)::pCellArray type(cParticle),pointer,dimension(:,:)::pArray type(cParticle),pointer::p_pointer real(4),pointer,dimension(:)::v_pointer real(4),pointer::s_pointer allocate( pCellArray(1:ipMax,1:iCells) ) pArray=>pCellArray%Ele !for example !now let's try p_pointer=>pArray(1,1); and we have ~/src gfortran -Wall bug.f95 data_types.f95: In function ‘MAIN__’: data_types.f95:19: internal compiler error: Ошибка сегментирования Please submit a full bug report, with preprocessed source if appropriate. See <file:///usr/share/doc/gcc-4.4/README.Bugs> for instructions. and we can achive this bug if we write s_pointer=>pArray(1,1)%SinA, but not if v_pointer=>pArray(1,1)%v !%%%%%%%%%%%%%%%%%%%%%%% the second part of this bug is wrong assignments. if we write "pArray(1,1)%v=10" -- only first component of vector will be written, but if we make it via transitional pointer "v_pointer=>pArray(1,1)%v ; v_pointer=10" -- everything is fine.
it was tested under ubuntu 10.04 and 12.04, (gfortran-4.4.3 & 4.4.6), and there is no such problem in g95.
(In reply to comment #0) > and we have > ~/src gfortran -Wall bug.f95 > data_types.f95: In function ‘MAIN__’: > data_types.f95:19: internal compiler error: Ошибка сегментирования This part I can reproduce. I have reduced it as much as I could: type pCItem integer :: Ele end type type(pCItem), target, dimension(1:2,1:2) :: pCellArray integer, pointer, dimension(:,:) :: pArray integer, pointer :: p_pointer pArray => pCellArray%Ele p_pointer => pArray(1,1) end This gives the ICE internal compiler error: Segmentation fault type pCItem ^ 0x89099f crash_signal /home/janus/gcc49/trunk/gcc/toplev.c:332 0x5c6f8a gfc_get_symbol_decl(gfc_symbol*) /home/janus/gcc49/trunk/gcc/fortran/trans-decl.c:1464 0x5c733f generate_local_decl /home/janus/gcc49/trunk/gcc/fortran/trans-decl.c:4652 0x5965b3 do_traverse_symtree /home/janus/gcc49/trunk/gcc/fortran/symbol.c:3571 0x5c929a generate_local_vars /home/janus/gcc49/trunk/gcc/fortran/trans-decl.c:4811 0x5c929a gfc_generate_function_code(gfc_namespace*) /home/janus/gcc49/trunk/gcc/fortran/trans-decl.c:5385 with 4.7, 4.8 and trunk at least, but works with 4.3. So it seems to be a regression introduced in 4.4. Thanks for reporting! About the second part, I'm not fully sure how to reproduce it. Can you give a full self-contained code example instead of describing it in words?
(In reply to comment #2) > /home/janus/gcc49/trunk/gcc/fortran/trans-decl.c:1464 For this line, svn blame reports the following commit (which is quite likely the origin of the regression): http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=139782
>About the second part, I'm not fully sure how to reproduce it. Can you give a >full self-contained code example instead of describing it in words? type cParticle real(4) :: v(3) endtype cParticle type pCItem type(cParticle) :: Ele end type pCItem type(pCItem),target,dimension(1:1,1:1)::pCellArray type(cParticle),pointer,dimension(:,:)::pArray real(4),pointer,dimension(:)::v_pointer real(4),dimension(3)::v_real=99. pArray=>pCellArray%Ele v_pointer=>pArray(1,1)%v;v_pointer=v_real. !OK %%%%%%%%%%%% write(*,*) pArray(1,1) v_real=88. pArray(1,1)%v=v_real !SEGFAULT %%%%%%%%%%%%%%%%%%%%%%%% write(*,*) pArray(1,1) end in original code it is not cause segfault, but it make wrong assignment -- only pArray(1,1)%v(1) becomes 88. v(2:3) is still 99.
I can confirm a runtime segfault (invalid memory reference) on comment 4 with 4.7, 4.8 and trunk. With 4.3 one does not get a segfault, but the output is 99.0000000 99.0000000 99.0000000 88.0000000 99.0000000 99.0000000 which means that the assignment really only sets v(1). So there is already a wrong-code issue in 4.3, but the segfault itself is a regression (which might be connected to the other one, see comment 2).
I have spent an hour or so looking at this one. I think that I can see how to fix it. The problem is that expr.c(is_subref_array) is triggering the use of pointer arithmetic, using the hidden .span variable, when it should not. The expressions below work fine with array indices. I just have to sit down and figure out a consistent logic. Something for next weekend! Cheers Paul
The 4.7 branch is being closed, moving target milestone to 4.8.4.
This will be fixed once the work on fortran-dev is finished and the branch is merged into trunk. Kludges night be possible but I do not think that the diversion of effort is worth it. Thanks for the report - the PR will remain but it will take a few months yet to get it fixed. Paul
GCC 4.8.4 has been released.
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.
GCC 4.9.3 has been released.
GCC 4.9 branch is being closed
The original test compiles with the patch for pr34640. However the test in comment 4 still segfault.