[Bug fortran/69654] ICE in gfc_trans_structure_assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69654 --- Comment #8 from Hossein Talebi --- Hi Paul, Thanks for following up on this. I actually changed my programming language for this bug, just kidding :-). Cheers Hossein On Thu, 14 Nov 2019, 16:05 pault at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69654 > > --- Comment #7 from Paul Thomas --- > Dear Hossein, > > This news is probably 1,379 days too late for you - I am just about to > post a > fix for this bug. I do apologise for the long delay but, for some reason, > I saw > the problem right away today having failed to do so on my previous > explorations. > > Best regards > > Paul > > -- > You are receiving this mail because: > You reported the bug.
[Bug libfortran/52537] slow trim function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52537 --- Comment #9 from Hossein Talebi 2012-06-07 16:03:09 UTC --- I think I found where the problem is. It is not with the trim(). It is mostly with read (st_input_all(j),*,IOSTAT=ios) I50(1:50). I attach a self contained program. With intel it takes 11sec but for gfortran takes 40sec. The input file is 404MB. program fileread integer :: linenum integer :: j,ferror, ios,i character (len=200) :: st_input character (len=200) :: st_input_all(5373122) integer :: funit2 integer :: I50(0:50) integer G_elid, nn !, pEidf, pEconnf,pEmatidf integer, allocatable :: element_tab(:), Elements(:,:) linenum=0; ferror=0; open (funit2, file = "/data/msh/bigmesh.elements", access = 'sequential',iostat=ferror) if (ferror/=0) then STOP "error reading the file" endif print *, "reading the file..." G_elid=0 do j=1,5373122 read (funit2,"(A200)",iostat=ferror) st_input_all(j) if (G_elid== 5373121 ) then print *, st_input_all(j) endif enddo G_elid=0 do j=1,5373122 G_elid=G_elid+1 read (st_input_all(j),*,IOSTAT=ios) I50(1:50) if (G_elid== 5373121 ) then print *, I50 endif enddo close(funit2) print *, I50 STOP "permix I am stopped" end program fileread
[Bug libfortran/52537] New: slow trim function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52537 Bug #: 52537 Summary: slow trim function Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: talebi.hoss...@gmail.com Hello, The trim function in Gfortran seems to be a a lot slower than the intel compiler. Sometimes I have to read some input text files which can very large(1.5GB); Comparing the intel and gfortran, the gfortran takes 150 seconds where intel spends only 50 seconds. I checked, and there seems to a large time spend on the trim function. I am not sure if intel does some other optimization but I never got such huge performance difference between gfortran and ifort. Thank you.
[Bug libfortran/52537] slow trim function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52537
--- Comment #3 from Hossein Talebi 2012-03-11
17:27:42 UTC ---
Hello,
Hummm, a self contained example... That will be possible when I go back to the
office. I can also check it myself with a simpler example. For now, maybe you
can figure out something from this subroutine. I can probably write this
subroutine in another way to make it faster. But, the question still is, why
intel does the same thing much faster.
!==
subroutine
femmesh_input_elements(this,funit,nelem,max_connectivity,fname,reflag,element_format)
!attention: here the Proc0 reads and distributes to other
! procs. also, the profiling is done here partially
! for the number of element and so on. The format of saving
! element connectivities is done according to METIS to make
! it easier to distribute the elements.
use strings
!--- INOUT variables--
class(ty_femmesh) :: this
type(ty_element_format) :: element_format
integer,intent(in) :: funit
character(*) :: fname, reflag
integer :: nelem,max_connectivity, linenum
integer :: j,ferror, ios,i
character (len=1200) :: st_input
integer :: maxc,funit2, buf_siz,iprc, ierror
integer, allocatable :: ELEMENTS_buf(:,:)
integer :: I50(0:50)
character(1200) :: pcommand
integer mstatus(MPI_STATUS_SIZE), tag, G_elid, elid, ipr, eltab,nn , pEidf,
pEconnf,pEmatidf
funit2=funit
linenum=0; ferror=0; eltab=0
this%max_connect=element_format%max_connectivity
this%max_Eltab=MIN_TABS+this%max_connect
pEidf=element_format%pEidf
pEconnf=element_format%pEconnf
pEmatidf=element_format%pEmatidf
! distribute the initial mesh to the processors so every processor knows
! what element it will get. The last element gets the remaining of the elements
+ its share
this%numElements= int( nelem / this%femcomm%nprocs)
if (this%femcomm%me == this%femcomm%nprocs-1) then
if (this%femcomm%me == this%femcomm%nprocs-1)
this%numElements=this%numElements+ mod(nelem,this%femcomm%nprocs)
endif
this%femcomm%elemdist(1)=1
!make elemdist and numEl_pp
do i=1, this%femcomm%nprocs
this%femcomm%elemdist(i+1) =this%femcomm%elemdist(i)+ int( nelem /
this%femcomm%nprocs)
this%femcomm%numEl_pp(i)=int( nelem / this%femcomm%nprocs)
enddo
this%femcomm%elemdist(this%femcomm%nprocs+1) =
this%femcomm%elemdist(this%femcomm%nprocs+1)+ mod(nelem,this%femcomm%nprocs)
this%femcomm%numEl_pp(this%femcomm%nprocs) =
this%femcomm%numEl_pp(this%femcomm%nprocs)+ mod(nelem,this%femcomm%nprocs)
!preparing the buffer to send and recieve elements
buf_siz=this%femcomm%numEl_pp(this%femcomm%nprocs) +1
eltab=2+max_connectivity
Call allocate_I2d(this%Elements_input,eltab,buf_siz)
Call allocate_I2d(ELEMENTS_buf,eltab,buf_siz)
Call allocate_I2d(this%Elements, this%max_Eltab ,this%numElements)
Call MPI_BARRIER(this%femcomm%femworld,ierror)
tag = 1; G_elid=0 ;I50=0
if (this%femcomm%me .eq. 0) then
if (trim(element_format%fname) /= '') then
if (element_format%reflag=='txt') then
funit2=openfile_txt(element_format%fname)
else
Call this%error%universe_one('femmesh_input_elements: I am not
able to read this type of element file')
endif
endif
ELEMENTS_buf=0
do ipr=0, this%femcomm%nprocs -1
j=0;
do
read (funit2,"(A200)",iostat=ferror) st_input
if (ferror < 0) then
call this%error%universe_one("femmesh_input_elements:
unexpected end of the file")
endif
call compact(st_input)
if (trim(st_input)=='' .or. st_input(1:1)=='#') then
cycle
endif
j=j+1
linenum=linenum+1
read (st_input,*,IOSTAT=ios) I50(1:50)
I50(0)=1 !set the zero index as 1, which sets all the unset values
1
elid=I50(1)
G_elid=G_elid+1
if (G_elid /=elid) then
print *,st_input
call this%error%universe_one("femmesh_input_elements: Bad
element numbering or number "// &
" of elements or element format")
endif
!ELEMENTS_buf(1:eltab,j)=I50(1:eltab)
ELEMENTS_buf(1,j)=I50(pEidf)
ELEMENTS_buf(2,j)=I50(pEmatidf)
ELEMENTS_buf(3:3+max_connectivity-1
,j)=I50(pEconnf:pEconnf+max_connectivity-1)
I50=0
if (j >= this%femcomm%numEl_pp(ipr+1)) exit
enddo
if (ipr ==0) then
this%Elements_input=ELEMENTS_buf
else
call MPI_SEND(ELEMENTS_buf, eltab*buf_siz, MPI_INTEGER, ipr, tag,
this%femcomm%femworld, ierror)
endif
enddo
else
call MPI_RECV(ELEMENTS_buf, eltab*buf_siz, MP
[Bug fortran/59493] New: internal compiler error: Segmentation fault on Class(*) pointer association with GCC 4.8.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59493 Bug ID: 59493 Summary: internal compiler error: Segmentation fault on Class(*) pointer association with GCC 4.8.1 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: talebi.hossein at gmail dot com Hi there, I get the segmentation fault on compilation of this code. This compiles with Intel Fortran Compiler. module mode1 implicit none integer :: a=1 type ty_mytype1 integer :: b1=1 end type ty_mytype1 type, extends(ty_mytype1) :: ty_extend integer :: b2=2 end type ty_extend end module mode1 program hello use mode1 implicit none class(ty_mytype1), allocatable,target:: cla1 class(*), pointer :: ptr_cla1 allocate(ty_extend :: cla1) ptr_cla1 => cla1 print *, 'cla1%b1', cla1%b1 end program
[Bug fortran/59493] [OOP] ICE: Segfault on Class(*) pointer association
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59493 --- Comment #3 from Hossein Talebi --- Will it be fixed in gfortran 4.8 or 4.9?
[Bug fortran/59678] New: Segmentation fault on equalizing variables of a complex derived data type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59678
Bug ID: 59678
Summary: Segmentation fault on equalizing variables of a
complex derived data type
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: talebi.hossein at gmail dot com
Hi,
Unfortunetely I could not repeat this with a simpler test example. So this code
below runs fine with Intel compiler but fails with Gfortan. The is the main
file can be replaced in my code from here:
http://sourceforge.net/p/permix/git_pub/ci/master/tree/
The minimalitsic serial version can be compiled with 'make minimal_serial'.
program permix
use permix_cmd_handling_mod
use prx_class, only: ty_prx
implicit none
! ty_prx is a complex derived data type
type(ty_prx) :: prx, prx2
! initializing prx
Call prx_init(prx,0,'mylog')
! running a simulation with giving an input
call prx%input%job('../verif/Test1/linearelastic_nonsolver.prx ')
! prininting a part of the data
print *,prx%parts%parts_fem(1)%OBJ%femmesh%X
prx2=prx ! ERROR: Segmentation fault occurs here
end program permix
Here is the definition of ty_prx:
type :: ty_prx
character(200) :: title
logical:: isInit=.false.
integer:: revision=1183
type(ty_input) :: input
type(ty_part) :: parts
type(ty_interaction) :: interactions
type(ty_define):: define
type(ty_analysis) :: analysis
type(ty_modify):: modify
type(ty_initial_condition) :: initial_conditions
type(ty_solver):: solver
type(ty_output):: output
type(ty_tools) :: tools
type(ty_restart) :: restart
type(ty_timer) :: timer
type(ty_universe) :: universe
type(ty_error) :: error
type(ty_prx_pointers) :: pointers
contains
!procedure :: init => prx_init
procedure :: finalize => prx_finalize !
end type ty_prx
[Bug fortran/59678] Segmentation fault on equalizing variables of a complex derived data type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59678 --- Comment #2 from Hossein Talebi --- I tried but I could not get it with a simple test case. It will take me 1-2 full days until I reduce my code to a minimalistic example. I know you GCC guys don't like this kind of error reporting; I understand; but I am quite busy too. Let's find a compromise..
[Bug fortran/59678] Segmentation fault on equalizing variables of a complex derived data type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59678
--- Comment #4 from Hossein Talebi ---
Created attachment 31574
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31574&action=edit
test case, permix.f90 and the external
Please replace the contents of permix.f90 with this below. Put the attached
libmpiseq.a into permix_home/externals/lib_LNX64_SRL_GCC4.63/ . Compile
again. It should be fine now. The executable will be in the permix_home/bin
folder. If this did not work, I will generate a test case next week.
program permix
use permix_cmd_handling_mod
use prx_class, only: ty_prx
implicit none
! ty_prx is a complex derived data type
type(ty_prx) :: prx, prx2
! initializing prx
Call prx_init(prx,0,'mylog')
! running a simulation with giving an input
call prx%input%job('../verif/Test1/linearelastic_nonsolver.prx ')
! prininting a part of the data
print *,prx%parts%parts_fem(1)%OBJ%femmesh%X
prx2=prx ! ERROR: Segmentation fault occurs here
end program permix
[Bug fortran/59678] Segmentation fault on equalizing variables of a complex derived data type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59678 --- Comment #6 from Hossein Talebi --- Thank you for trying it. Please spend 5 minutes to read and follow this. I have attached a zip files in proper folder which you have to overwrite to your local copy of PERMIX. I have modified the these to make it easy to compile and test. Method 1) You have OpenMPI or another mpi library and you want to compile PERMIX with it. After you overwrote the Makefile.minimal_mpi in the src/MAKE, just go to permix_home/src and type 'make minimal_mpi'. This will only need mpif90, mpicc and mpic++ to compile. That error you reported happened because you have not initialized MPI. Maybe if you add MPI initialization commands it will fix. But, I have updated the new permix.f90 with these commands and you just replace it. Method 2) You want to compile PERMIX in a full serial version. This case you need to supply some dummy MPI functions which are located in permix_home/src/STUBS folder. I have precompiled them (in the attached file, permix_home/externals/libmpiseq.a ). In case you have to compile libmpiseq.a by yourself go to permix_home/src/STUBS and run 'build.sh' which is the simplest way of compiling and linking in Linux. So, when you have the libmpiseq.a in the right place go to src folder and type 'make minimal_serial' . Please do not forget to replace every single file that I attached now, otherwise it won't work. Cheers Hossein On Sun, Jan 5, 2014 at 4:45 PM, dominiq at lps dot ens.fr < gcc-bugzi...@gcc.gnu.org> wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59678 > > Dominique d'Humieres changed: > >What|Removed |Added > > > Status|UNCONFIRMED |WAITING >Last reconfirmed||2014-01-05 > Ever confirmed|0 |1 > > --- Comment #5 from Dominique d'Humieres --- > After providing the link to the openmpi library, the executable is > generated > but fails at runtime with: > > [Book15] permix_home/src% ../bin/permix_minimal_serial > *** The MPI_Comm_f2c() function was called before MPI_INIT was invoked. > *** This is disallowed by the MPI standard. > *** Your MPI job will now abort. > [Book15.local:34330] Local abort before MPI_INIT completed successfully; > not > able to aggregate error messages, and not able to guarantee that all other > processes were killed! > > BTW I don't understand why serial make needs mpi stuff. > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You reported the bug. >
[Bug fortran/59678] Segmentation fault on equalizing variables of a complex derived data type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59678 --- Comment #8 from Hossein Talebi --- Basically it is similar. Below is the output and error message in Ubuntu x64 13.1 using GCC 4.8.1. You get a little more information though. PERMIX 28 July 2013 -- solver_init: Warning, Could not initialize an external solver; thus using basicinternal PERMIX solver which is serial and cannot handle very big problems. prx_read_input: reading the input ../verif/Test1/linearelastic_nonsolver.prx Adding a new PART_FEM femcomm_init: maximum number of threads to use is 1 femmesh_input_elements_onmaster: Reading Elements finished femmesh_input_nodes_onmaster2: Reading nodes finished nonlinear_bonet : nonlinear_static analysis setup fornonlin_to_ part_fem_profile: profiling the part p1 part_fem_distrubute: Distributing the elements femcomm_metis_partition: Doing the numbering of nodes and elements etc. femcomm_metis_partition: Finished doing the numbering of nodes and elements etc! part_fem_profile: creating metis meshes. part_fem_profile: creating element graphs. femmesh_make_metis_graph: metis is not connected to Permix part_fem_profile: Hisvar profiling. part_fem_profile: Building element index. part_fem_profile: Extra info allocation. part_fem_profile: Surface profiling. part_fem_profile: Initializing neighbors. part_profile: Profiling done for all of the parts initial_conditions_setup: Setting up initial conditions part_number_dofs: numbering DOFs part_number_dofs: Done, numbering DOFs part_communication_setup: Setting up communication part_communication_setup: setting up communication Done! matrix_alloc_dynamic: Total DOFs of the sytem=30 initial_condition_apply: Applying initial conditions modify_apply_initial_conditions: finished applying initial conditions! Dumping a paraview Down to disk at time step 0 nonlinear_bonet : nonlinear_static analysis started for nonlin_to_ nonlinear_bonet_execute: Load Step 1 nonlinear_bonet_execute: Newton Iteration 1 solver_solve_serial: solving linear system of equations with solver BASIC IERR =219 2-NORM OF RESIDUAL = 0.7676777D-14 MAX NORM OF RESIDUAL = 0.4575041D-14 nonlinear_bonet_execute: Line search iteration 2 Step: 1 iteration: 1 residual: 0.328E-14 load factor: 1. Dumping a paraview Down to disk at time step 1 Dumping a paraview Down to disk at time step 1 nonlinear_static: nonlinear_static Elastic analysis finished 0.0.0. 0.93525519689293113 -5.1386768226528851E-002 0. 1.8704479398935832 -0.209051353658980590. 2.8192502780015567 -0.470461462535627040. 3.8025869994892636 -0.781008297074059170. 0.1.00382466967916570. 1.0388142164215601 0.952276698753604430. 2.0767135602228310 0.798227785037066480. 3.0989617906167983 0.538887950604416410. 4.1063496520944476 0.201902000139214000. 0.1.97667760151370380. 1.14110343828084691.92531207020343900. 2.28240670796939731.77326747360523650. 3.43582741964522631.52482134162769990. 4.52317523478337961.17217470015875190. Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7FF93F00E7D7 #1 0x7FF93F00EDDE #2 0x7FF93E749FEF #3 0x7FF93E863ED6 #4 0x7EE377 in permix at permix.f90:57 (discriminator 32) Segmentation fault (core dumped)
[Bug fortran/69654] New: ICE in gfc_trans_structure_assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69654 Bug ID: 69654 Summary: ICE in gfc_trans_structure_assign Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: talebi.hossein at gmail dot com Target Milestone: --- Created attachment 37572 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37572&action=edit the minimalistic test file Hi, Compiling the attached file, using gfrotran versions 4.8.5, 5.3.0 and 6.0 (build 20160131) I get internal compiler error. Running 5.3.0 I get: $ gfortran-5 -c gfortranbug1.f90 gfortranbug1.f90:45:0: end subroutine foo_script1 1 internal compiler error: Segmentation fault 0xa3e2ef crash_signal ../../src/gcc/toplev.c:383 0x6b3565 gfc_trans_structure_assign ../../src/gcc/fortran/trans-expr.c:7064 0x6b41a4 gfc_trans_subcomponent_assign ../../src/gcc/fortran/trans-expr.c:6971 0x6b358b gfc_trans_structure_assign ../../src/gcc/fortran/trans-expr.c:7074 0x6b41a4 gfc_trans_subcomponent_assign ../../src/gcc/fortran/trans-expr.c:6971 0x6b358b gfc_trans_structure_assign ../../src/gcc/fortran/trans-expr.c:7074 0x6b4bd4 gfc_conv_structure(gfc_se*, gfc_expr*, int) ../../src/gcc/fortran/trans-expr.c:7103 0x6b5bb0 gfc_trans_assignment_1 ../../src/gcc/fortran/trans-expr.c:8990 0x69bf47 gfc_init_default_dt(gfc_symbol*, stmtblock_t*, bool) ../../src/gcc/fortran/trans-decl.c:3733 0x6a0b1b gfc_trans_deferred_vars(gfc_symbol*, gfc_wrapped_block*) ../../src/gcc/fortran/trans-decl.c:4288 0x6a258b gfc_generate_function_code(gfc_namespace*) ../../src/gcc/fortran/trans-decl.c:5917 0x685b41 gfc_generate_module_code(gfc_namespace*) ../../src/gcc/fortran/trans.c:2036 0x6403bd translate_all_program_units ../../src/gcc/fortran/parse.c:5330 0x6403bd gfc_parse_file() ../../src/gcc/fortran/parse.c:5540 0x67f9d5 gfc_be_parse_file ../../src/gcc/fortran/f95-lang.c:229 Please submit a full bug report, with preprocessed source if appropriate. Cheers H.
[Bug fortran/59678] [F03] Segfault on equalizing variables of a complex derived type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59678 --- Comment #15 from Hossein Talebi --- Hi, will this bug be fixed anytime soon or is it fixed already in GCC4.9?
[Bug fortran/59678] [F03] Segfault on equalizing variables of a complex derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59678 --- Comment #19 from Hossein Talebi --- Hi, This patch goes to Gfortran 4.8 or the current version? Thank you. Cheers H. On Tue, May 5, 2015 at 7:03 PM, vehre at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59678 > > vehre at gcc dot gnu.org changed: > >What|Removed |Added > > > Status|WAITING |RESOLVED > Resolution|--- |FIXED > > --- Comment #18 from vehre at gcc dot gnu.org --- > Resolved with commit r222477. No objections so far, closing. > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You reported the bug. >
[Bug fortran/59678] Segmentation fault on equalizing variables of a complex derived data type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59678 --- Comment #9 from Hossein Talebi --- I looked at it in more details by overloading the automatic assignment (=) with a self written one and I found the problem. This is a minimalistic example that the program crashes. Funny thing is that when I put MAX_PART_FEM=2, it runs but not with any other number. I use ubuntu 13.1, GCC 4.8.1. module module1 integer,parameter :: MAX_PART_FEM=32 type ty_type3 integer a,b integer, allocatable :: vec1(:) end type ty_type3 type ptr_ty_part_fem type(ty_type3), allocatable :: OBJ end type ptr_ty_part_fem type ty_type2 type(ptr_ty_part_fem):: parts_fem(MAX_PART_FEM) integer :: a2=1 end type ty_type2 end module module1 program hello use module1 implicit none type(ty_type2):: m2, m3 m3=m2 print *,m2%a2 end program
[Bug fortran/59678] Segmentation fault on equalizing variables of a complex derived data type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59678 --- Comment #10 from Hossein Talebi --- I forgot to say, when I allocate the variables manually and then do assignment, it works fine.
[Bug fortran/68415] New: Internal compiler error on Class variable containing array of allocatable polymorphic variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68415 Bug ID: 68415 Summary: Internal compiler error on Class variable containing array of allocatable polymorphic variable Product: gcc Version: 5.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: talebi.hossein at gmail dot com Target Milestone: --- Created attachment 36761 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36761&action=edit fortran module The compilation of the attached file gives the following error. If I change the class on line 31, to type it will not happen. Or if I remove the line 20 it will work as well. This might be related to the bug 59678. define_class.f90:39:0: End Module define_class 1 internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:6534 0x6a87b0 gfc_conv_expr_descriptor(gfc_se*, gfc_expr*) ../../src/gcc/fortran/trans-array.c:6534 0x6cb79b gfc_trans_pointer_assignment(gfc_expr*, gfc_expr*) ../../src/gcc/fortran/trans-expr.c:7635 0x6cbe3c gfc_reset_vptr(stmtblock_t*, gfc_expr*) ../../src/gcc/fortran/trans-expr.c:358 0x6f8065 gfc_trans_deallocate(gfc_code*) ../../src/gcc/fortran/trans-stmt.c:5993 0x696e57 trans_code ../../src/gcc/fortran/trans.c:1824 0x6edd63 gfc_trans_if_1 ../../src/gcc/fortran/trans-stmt.c:1115 0x6f409a gfc_trans_if(gfc_code*) ../../src/gcc/fortran/trans-stmt.c:1146 0x696f47 trans_code ../../src/gcc/fortran/trans.c:1762 0x6f53b1 gfc_trans_simple_do ../../src/gcc/fortran/trans-stmt.c:1654 0x6f53b1 gfc_trans_do(gfc_code*, tree_node*) ../../src/gcc/fortran/trans-stmt.c:1817 0x696f1a trans_code ../../src/gcc/fortran/trans.c:1774 0x6b6bc3 gfc_generate_function_code(gfc_namespace*) ../../src/gcc/fortran/trans-decl.c:5851 0x69a3a1 gfc_generate_module_code(gfc_namespace*) ../../src/gcc/fortran/trans.c:2036 0x654c1d translate_all_program_units ../../src/gcc/fortran/parse.c:5330 0x654c1d gfc_parse_file() ../../src/gcc/fortran/parse.c:5540 0x694235 gfc_be_parse_file ../../src/gcc/fortran/f95-lang.c:229 Please submit a full bug report, with preprocessed source if appropriate.
[Bug fortran/61819] [4.9/4.10 Regression] ICE in gfc_conv_descriptor_data_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819 --- Comment #18 from Hossein Talebi --- I am now trying this bug and the Bug 68415 with the new GCC from trunc and it is fine. Nevertheless, this other code does not compile. (gcc version 6.0.0 20151129 (experimental)) Module part_base2_class implicit none type :: ty_moc1 integer l end type ty_moc1 integer,parameter :: MAX_NUM_ELEMENT_TYPE=32 type :: ty_element_index2 class(ty_moc1),allocatable :: element class(ty_moc1),allocatable :: element_th(:) endtype ty_element_index2 type :: ty_part_base2 type(ty_element_index2)::element_index(MAX_NUM_ELEMENT_TYPE) end type ty_part_base2 class(ty_part_base2),allocatable :: part_tmp_obj End Module part_base2_class
[Bug fortran/68864] New: bug 61819 is not completely fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68864 Bug ID: 68864 Summary: bug 61819 is not completely fixed Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: talebi.hossein at gmail dot com Target Milestone: --- I am now trying bug 61819 and the Bug 68415 with the new GCC from trunk and it is fine. Nevertheless, this other code does not compile. (gcc version 6.0.0 20151129 (experimental)) Module part_base2_class implicit none type :: ty_moc1 integer l end type ty_moc1 integer,parameter :: MAX_NUM_ELEMENT_TYPE=32 type :: ty_element_index2 class(ty_moc1),allocatable :: element class(ty_moc1),allocatable :: element_th(:) endtype ty_element_index2 type :: ty_part_base2 type(ty_element_index2)::element_index(MAX_NUM_ELEMENT_TYPE) end type ty_part_base2 class(ty_part_base2),allocatable :: part_tmp_obj End Module part_base2_class
[Bug fortran/61819] [4.9/4.10 Regression] ICE in gfc_conv_descriptor_data_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819 --- Comment #20 from Hossein Talebi --- I just submitted a new bug. It is a pity that my code cannot be compiled with gfortran 4.9 and above for more than a year now.. On Fri, Dec 11, 2015 at 9:01 PM, kargl at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819 > > --- Comment #19 from kargl at gcc dot gnu.org --- > (In reply to Hossein Talebi from comment #18) > > I am now trying this bug and the Bug 68415 with the new GCC from trunc > and > > it is fine. Nevertheless, this other code does not compile. > > (gcc version 6.0.0 20151129 (experimental)) > > > > Please open a new bug report. Add a comment with code > exhibiting a bug to a CLOSED bug report is a good way > to get the report ignored. > > -- > You are receiving this mail because: > You are on the CC list for the bug. >
[Bug fortran/61819] [4.9/4.10 Regression] ICE in gfc_conv_descriptor_data_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819 --- Comment #23 from Hossein Talebi --- Thank you also for the great work and such a nice compiler. I should have actually noticed this a lot sooner but I was trying to keep my code compiling with gcc 4.8. > It is comments like the above that inspire me to invest my > time in gfortran. Thanks for your support. > >
