In fortran 2003, classes and OOP are defined in the standard. I would like to know how upcasting and downcasting are performed.

Is it possible to perform without using SELECT TYPE since I'm dealing with a heterogeneous collection and I can not know all the types.

Thank you

Hi everybody,

I had to upgrade my Linux Mint from version 17.3 to version 19.1 as the first reached its end of life.

Under the new Linux Mint 19.1 I need now to reinstall my 'old' Intel compiler suite version 11.1.059. Unfortunately the installation process fails almost immediately.

Here follows the step I'm taking:

valerio@giusti-147:~/Downloads/l_cprof_p_11.1.059_intel64$ sudo ./install.sh
[sudo] password for valerio: **********

Step no: 1 of 7 | Welcome
--------------------------------------------------------------------------------
Welcome to the Intel(R) Fortran Compiler Professional Edition for Linux* version
11.1.
...
...
...
...
--------------------------------------------------------------------------------
Press "Enter" key to continue or "q" to quit: <enter>

Step no: 2 of 7 | License agreement
--------------------------------------------------------------------------------
To continue with the installation, you must accept the terms and conditions of
...
...
...
--------------------------------------------------------------------------------
Please type a selection or press "Enter" to accept default choice [1]: 1 <enter>

IMPORTANT - READ BEFORE COPYING, INSTALLING OR USING.
Do not copy, install, or use the Materials provided under this license agreement
...
...
...
Do you agree to be bound by the terms and conditions of this license agreement?
Type "accept" to continue or "decline" to back to the previous menu: accept <enter>
./install.sh: line 465: 14191 Segmentation fault      (core dumped) $pset_engine_binary --log-file=$log_file $silent_params $duplicate_params $params --PACKAGE_DIR=$fullpath

Echoing the failing command in the install.sh file I get the following:

/home/valerio/Downloads/l_cprof_p_11.1.059_intel64/./pset/32e/install.32e --log-file=/tmp/intel.pset.root.giusti-147_06.06.00.02.21.2019.log --PACKAGE_DIR=/home/valerio/Downloads/l_cprof_p_11.1.059_intel64/.

As it concerns my system, the command 'uname -a' returns the following information:

valerio@giusti-147:~/Downloads/l_cprof_p_11.1.059_intel64$ uname -a
Linux giusti-147 4.15.0-51-generic #55-Ubuntu SMP Wed May 15 14:27:21 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Any idea of what can be the problem?

For your information I can add that on my desktop, after upgrading the operating system from LMDE2 to LMDE3, I have been able to install the compilers without problems.

Thanks in advance

Valerio

Hi,

the following code generates an internal compiler error when compiled with 19.04

Module Mod_Paof
  Implicit none
  Private
  Type, Public :: parent
  contains
    Private
    Generic, Public :: bar => foo
    Procedure, Public :: foo => subfoo_parent
  End type parent
  Type, Public, extends(parent) :: offspring
  contains
    Private
    Procedure, Public :: foo => subfoo_offspring
  End type offspring
  Interface
    Module Subroutine subfoo_parent(this)
      Class(parent), Intent(inOut) :: this
    End Subroutine
    Module Subroutine subfoo_offspring(this)
      Class(offspring), Intent(inOut) :: this
    End Subroutine
  End Interface
End Module Mod_Paof
Submodule(Mod_Paof) parent_foo
contains
  Module Procedure subfoo_parent
    Implicit None
  End Procedure
End Submodule parent_foo
Submodule(Mod_Paof) offspring_foo
contains
  Module Procedure subfoo_offspring
    Implicit None
  End procedure
End Submodule offspring_foo
Module Mod_Ttt
  use Mod_Paof, only: offspring
  Implicit None
  Private
  Type, Public :: Ttt
    Type(offspring), allocatable :: xxx
  contains
    Private
    Procedure, Pass, Public :: bar=> Subbar
  End type Ttt
  Interface
    Module Subroutine Subbar(this)
      Class(Ttt), Intent(InOut) :: this
    End Subroutine
  End Interface
End Module Mod_Ttt
Submodule(Mod_Ttt) ttt_bar
contains
  Module Procedure Subbar
    Implicit None
    !!ice crash
    call this%xxx%bar()
    !!workaround (not really)
    !call this%xxx%foo()
  End Procedure
end Submodule Ttt_Bar

it compiles with gfortran 8.3 and ifort 17.08.

The workaround is to abandon the generic interface.

cheers

Dear all,

I am creating a program in Fortran90.

"Forrtl: severe (174): SIGSEGV, segmentation fault occurred" occurs in an array in a structure.
I tried to check the index by writing a print statement to identify the cause, but the error disappeared when I wrote the print statement for some reason. Also, when I added -check bounds, the error disappeared as well.

The compiler used intel Fortran, and an error occurred at that time, but when using gfortran, no error occurred.

If you know the cause, can you tell me?

Thank you.

Best
Christoph

Dear all,

I am creating a program in Fortran90.

"Forrtl: severe (174): SIGSEGV, segmentation fault occurred" occurs in an array in a structure.
I tried to check the index by writing a print statement to identify the cause, but the error disappeared when I wrote the print statement for some reason. Also, when I added -check bounds, the error disappeared as well.

The compiler used intel Fortran, and an error occurred at that time, but when using gfortran, no error occurred.

If you know the cause, can you tell me?

Thank you.

Hi all. Trying OOP and polymorphism I manage to code an example which runs properly in Windows with the ifort14 compiler. When trying to run this in a Linux system with ifort18 I receive the following run-time error message:

"forrtl: severe (189): LHS and RHS of an assignment statement have incompatible types", in line "stringer = CompositeHatSection()"

Any clue? Many thanks in advance  

Gustavo

------------------

program zz_demo_polymorphism
    
    type :: CompositeStringerSection
        real :: A   ! area
    end type
    
    type, extends(CompositeStringerSection) :: CompositeHatSection
        real :: H   ! height
    end type
    interface CompositeHatSection
        procedure composite_hat_section_constructor
    end interface
    
    type(CompositeStringerSection) :: stringer
    
    stringer = CompositeHatSection()
    
    print *, 'A = ', stringer%A
    print '(A)', 'Execution finished. Press Enter to continue...'
    read (*,*)
   
contains
    
    function composite_hat_section_constructor() result(this)
    
        ! polymorphic return value (derived class constructor)
        class(CompositeStringerSection), allocatable :: this    
        ! Warning : return value is a general composite stringer
                      
        ! Aux polymorphic variable to adjust derived class constructor
        class(CompositeHatSection), allocatable :: self         
       
        allocate(self)  
        self%A = 100.
        self%H = 25.

        call move_alloc(self, this)
                
    end function

end program

Hello.

I am a college student in Japan.

I'd like to have Intel Fortran Compiler ver. 10.0.025.

So I registered student account and tried to install Intell Parallel Studio XE.

But I can't find the version that I want.

This version is not supported?

I have a lib which is written in Fortran and is intent to be used by both Fortran and C using iso_c_binding. Basically, in the lib, a subroutine allocates a Fortran array (may be of any type) and return the allocated memory as a c_ptr. After the data is used, the memory is freed either by using the C routine "free" or Fortran "deallocate".

This works fine for Parallel studio XE 2016.5 (the current version we are using). However, it does not work for Parallel studio XE 2019.4. I get error message when I try to free the memory and the program crashes.

I uses Linux system.

Any one have similar problem?

I don't know how to reference what I am trying to do, but here is the explanation of what I desire to do.

In one module file "mod1.f" I have defined the following type

type md_typ1 

   real, pointer, contiguous :: x1(:) 
   integer, pointer, contiguous :: i1(:) 

   real, pointer, contiguous :: x11  ! no rank
   integer, pointer, contiguous :: i11 ! no rank

end type 

These pointer need to be an alias of a section of a buffer. Each of these pointers have an associated defined name as characters.

This allows me then to do the following in a different module file:

if( input_name == 'x1') typ1% x1 => buf(i1:i2) 

I want it to be a bit more generic, where I in mod1 define a subroutine that returns one of the pointers in md_typ1, so we instead can do:

call GIVE_ME_POINTER( input_name, ptr_corresponding_to_input_name)

ptr_corresponding_to_input_name => buf(i1:i2) ! assume here that input_name is x1 and hence the ptr_corresponding_to_input_name should have been associated to typ1% x1

I got two issues here:

1) Is it correct to assume (if everything done correctly) that `ptr_corresponding_to_input_name` is implicitly updating my `typ1% x1` - so EVEN THOUGH `ptr_corresponding_to_input_name` GOES OUT OF SCOPE, `typ1% x1` is still referencing to `buf(i1:i2)` ??

2) How do I make such a routine that can return the pointer generic. My attempts is the following

subroutine GIVE_ME_POINTER( name_str, ptr_out) 

character(len=*), intent(in) :: name_str
class(*), intent(out) :: ptr_out


select case(name_str) 

    case('x1') 
       ptr_out => typ1% x1 
    case('i1')
       ptr_out => typ1% i1 
 !etc etc 

end select

end subroutine

Is that legal in Fortran , especially w.r.t the use of class(*)

Thanks in advance,

Hi all.

I am a user of the WRF weather model. After reading an Intel article on improving the performance of WRF, I compiled WRF with (dm+sm). I used the Intel compiler in its 2018 version.

The compilation ends correctly, but with errors of this type:

COMPILING init_modules_em.F WITHOUT OMP

I asked in the WRF forum, but they do not know how to give me an answer. I understand that it can be a problem with some compiler flags. If someone could help me I would be very grateful.

I attach the configuration file and the output file.

my new version compiler is ifort version 19.0.2.187

my old version compiler is ifort version 15.0.3

system is linux(redhat)

my code use old compiler and link ,code run is right,

but we change to new compiler ,compiles have waring message ,and my cod run is wrong .

following parameter trc, channel is optional   default trc = 1 and channel = 0

following is new compiler waring:

ifort -c head_sublibf.f90 -std03 -fPIC -assume nounderscore -assume bscc -assume byterecl -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fpp
head_sublibf.f90(32): warning #8809: An OPTIONAL or EXTERNAL dummy argument to a BIND(C) procedure is not interoperable.   [TRC]
    integer( c_int ) function hdd_geti_by_no(no,head_buffer,result,trc,channel ) bind( C )

head_sublibf.f90(32): warning #8809: An OPTIONAL or EXTERNAL dummy argument to a BIND(C) procedure is not interoperable.   [CHANNEL]
    integer( c_int ) function hdd_geti_by_no(no,head_buffer,result,trc,channel ) bind( C )

please help me ,thank!

Dear all,

I am beginning with Linux computer and I would use a home code for a summer job. The code is written in fortran and I have to use Intel Fortran Compiler, but, when I compile the code, an error is detected. This is the errors :

doriat@doriat-X555LB:~/lusie$ make lusie
ifort  -c -g -check all -nofor-main InputModule_LUSIE.f90
InputModule_LUSIE.f90(46): error #7002: Error in opening the compiled module file.  Check INCLUDE paths.   [INHOMOGENEOUS]
      USE INHOMOGENEOUS
----------^
InputModule_LUSIE.f90(277): error #6404: This name does not have a type, and must have an explicit type.   [INHOM]
         ldest_ptrs(1)%ptrl => inhom;      ldest_name(1) = 'inhom'
-------------------------------^
InputModule_LUSIE.f90(277): error #6796: The variable must have the TARGET attribute or be a subobject of an object with the TARGET attribute, or it must have the POINTER attribute.   [INHOM]
         ldest_ptrs(1)%ptrl => inhom;      ldest_name(1) = 'inhom'
-------------------------------^
InputModule_LUSIE.f90(278): error #6404: This name does not have a type, and must have an explicit type.   [LINEAR]
         ldest_ptrs(2)%ptrl => LINEAR;     ldest_name(2) = 'LINEAR'
-------------------------------^
InputModule_LUSIE.f90(278): error #6796: The variable must have the TARGET attribute or be a subobject of an object with the TARGET attribute, or it must have the POINTER attribute.   [LINEAR]
         ldest_ptrs(2)%ptrl => LINEAR;     ldest_name(2) = 'LINEAR'
-------------------------------^
InputModule_LUSIE.f90(279): error #6404: This name does not have a type, and must have an explicit type.   [PARABOLIC]
         ldest_ptrs(3)%ptrl => PARABOLIC;  ldest_name(3) = 'PARABOLIC'
-------------------------------^
InputModule_LUSIE.f90(279): error #6796: The variable must have the TARGET attribute or be a subobject of an object with the TARGET attribute, or it must have the POINTER attribute.   [PARABOLIC]
         ldest_ptrs(3)%ptrl => PARABOLIC;  ldest_name(3) = 'PARABOLIC'
-------------------------------^
InputModule_LUSIE.f90(280): error #6404: This name does not have a type, and must have an explicit type.   [FERMI]
         ldest_ptrs(4)%ptrl => FERMI;      ldest_name(4) = 'FERMI'
-------------------------------^
InputModule_LUSIE.f90(280): error #6796: The variable must have the TARGET attribute or be a subobject of an object with the TARGET attribute, or it must have the POINTER attribute.   [FERMI]
         ldest_ptrs(4)%ptrl => FERMI;      ldest_name(4) = 'FERMI'
-------------------------------^
InputModule_LUSIE.f90(281): error #6404: This name does not have a type, and must have an explicit type.   [CYLINDER_DEV]
         ldest_ptrs(5)%ptrl => cylinder_dev;   ldest_name(5) = 'cylinder_dev'
-------------------------------^
InputModule_LUSIE.f90(281): error #6796: The variable must have the TARGET attribute or be a subobject of an object with the TARGET attribute, or it must have the POINTER attribute.   [CYLINDER_DEV]
         ldest_ptrs(5)%ptrl => cylinder_dev;   ldest_name(5) = 'cylinder_dev'
-------------------------------^
InputModule_LUSIE.f90(282): error #6404: This name does not have a type, and must have an explicit type.   [TURB_MIX]
         ldest_ptrs(6)%ptrl => TURB_MIX;   ldest_name(6) = 'TURB_MIX'
-------------------------------^
InputModule_LUSIE.f90(282): error #6796: The variable must have the TARGET attribute or be a subobject of an object with the TARGET attribute, or it must have the POINTER attribute.   [TURB_MIX]
         ldest_ptrs(6)%ptrl => TURB_MIX;   ldest_name(6) = 'TURB_MIX'
-------------------------------^
InputModule_LUSIE.f90(283): error #6404: This name does not have a type, and must have an explicit type.   [PHI_MAX]
         rdest_ptrs(1)%ptrr => PHI_MAX;    rdest_name(1) = 'PHI_MAX'
-------------------------------^
InputModule_LUSIE.f90(283): error #6796: The variable must have the TARGET attribute or be a subobject of an object with the TARGET attribute, or it must have the POINTER attribute.   [PHI_MAX]
         rdest_ptrs(1)%ptrr => PHI_MAX;    rdest_name(1) = 'PHI_MAX'
-------------------------------^
InputModule_LUSIE.f90(284): error #6404: This name does not have a type, and must have an explicit type.   [PHI_MIN]
         rdest_ptrs(2)%ptrr => PHI_MIN;    rdest_name(2) = 'PHI_MIN'
-------------------------------^
InputModule_LUSIE.f90(284): error #6796: The variable must have the TARGET attribute or be a subobject of an object with the TARGET attribute, or it must have the POINTER attribute.   [PHI_MIN]
         rdest_ptrs(2)%ptrr => PHI_MIN;    rdest_name(2) = 'PHI_MIN'
-------------------------------^
InputModule_LUSIE.f90(285): error #6404: This name does not have a type, and must have an explicit type.   [SOI]
         rdest_ptrs(3)%ptrr => SOI;        rdest_name(3) = 'SOI'
-------------------------------^
InputModule_LUSIE.f90(285): error #6796: The variable must have the TARGET attribute or be a subobject of an object with the TARGET attribute, or it must have the POINTER attribute.   [SOI]
         rdest_ptrs(3)%ptrr => SOI;        rdest_name(3) = 'SOI'
-------------------------------^
InputModule_LUSIE.f90(286): error #6404: This name does not have a type, and must have an explicit type.   [Y_0]
         rdest_ptrs(4)%ptrr => Y_0;        rdest_name(4) = 'Y_0'
-------------------------------^
InputModule_LUSIE.f90(286): error #6796: The variable must have the TARGET attribute or be a subobject of an object with the TARGET attribute, or it must have the POINTER attribute.   [Y_0]
         rdest_ptrs(4)%ptrr => Y_0;        rdest_name(4) = 'Y_0'
-------------------------------^
InputModule_LUSIE.f90(287): error #6404: This name does not have a type, and must have an explicit type.   [DY]
         rdest_ptrs(5)%ptrr => dY;         rdest_name(5) = 'dY'
-------------------------------^
InputModule_LUSIE.f90(287): error #6796: The variable must have the TARGET attribute or be a subobject of an object with the TARGET attribute, or it must have the POINTER attribute.   [DY]
         rdest_ptrs(5)%ptrr => dY;         rdest_name(5) = 'dY'
-------------------------------^
compilation aborted for InputModule_LUSIE.f90 (code 1)
Makefile:123 : la recette pour la cible « InputModule_LUSIE.o » a échouée
make: *** [InputModule_LUSIE.o] Erreur 1

I think that there is a porblem with the compiler or Linux.

Thank in advance for your help,

Aurélien !

Intel® Fortran Composer XE 2020 Technical Preview (beta) Update 1

We are pleased to announce Intel® Parallel Studio XE 2020 Technical Preview Composer Edition UPDATE 1 for Fortran is ready for testing.  Packages are available for Linux*, Windows*, and macOS* X.   

The UPDATE 1 packages for Linux* and macOS* includes bug fixes over the initial release.

These packages contain a Pre-Release version of Intel® Fortran version 19.1.  That's right, we have a "dot-1" minor release this year.  But for Fortran it's anything but minor!  This is one of our most ambitious releases to date.  We've added many Fortran 2018 features.  Get the DETAILS HERE.

When you're ready to join our test program, GO HERE to learn more and sign up!

I have recently been reading the book: Scientific software design: the objective oriented way by Rouson et al. and I came across the issue with memory leak in Fortran. It was specifically mentioning the issue with having complex overloading, like: Y=A+b*d , where each element corresponds to a declared type and hence the '=',+,* are all overloaded operators.

Now, I guess if you would use allocatables within a declared type rather than pointers, then you should not worry about memory leak when a function call is returned, Am i right in this assumption?   

What about the simple example shown below:
I got two things I would like to understand:
1) Doing 'tes => alloc(100)` is a function call where the pointer tes is pointing to the outcome of the function. I understand function calls in Fortran as they create a copy within themselves workout what needs to be worked out, and then copy it back to the LHS. I am wondering if this could potentially lead to a memory leak since the copied (within the function) has gone out of scope and there is no way we can reach it?

2) When I do `deallocate(tes)`; does it imply that I am deallocating its member 'x' as well, because it is an allocatable and NOT a pointer

Thanks in advance

program mem_leak
implicit none

type testy
   real, allocatable :: x(:)

end type
type(testy), pointer :: tes

tes => alloc(100)

deallocate(tes)

contains
function alloc(n)

   implicit none
   integer, intent(in) :: n
   type(testy), pointer :: alloc

   allocate(alloc)

   allocate(alloc%X(n))


end function


end program

I'd like to add user defined derived-type IO for an extended type. However I got an error message
"error #8638: The type/rank signature for arguments of this specific subroutine is identical to another specific subroutine that shares the same defined I/O." Anyone has idea how to do this?

The test code is here.

module mymod
type :: mydata_t
character(len=10) :: name
contains
procedure :: write_unfmt_mydata
generic :: write(unformatted) => write_unfmt_mydata
end type mydata_t

type, extends(mydata_t) :: myint_t
integer :: nn
integer, pointer :: xx(:)
contains
procedure :: write_unfmt_myint
!! How can I add an UDIO for an extended type?
!! The following line causes compilation error
generic :: write(unformatted) => write_unfmt_myint

end type myint_t

contains
subroutine write_unfmt_mydata(dtv, unit, iostat, iomsg)
class(mydata_t), intent(in) :: dtv
integer, intent(in) :: unit
integer, intent(out) :: iostat
character(len=*), intent(inout) :: iomsg

write(unit, iostat=iostat, iomsg=iomsg) dtv%name
end subroutine write_unfmt_mydata

subroutine write_unfmt_myint(dtv, unit, iostat, iomsg)
class(myint_t), intent(in) :: dtv
integer, intent(in) :: unit
integer, intent(out) :: iostat
character(len=*), intent(inout) :: iomsg

write(unit, iostat=iostat, iomsg=iomsg) dtv%mydata_t
write(unit, iostat=iostat, iomsg=iomsg) dtv%nn
write(unit, iostat=iostat, iomsg=iomsg) dtv%xx(1:nn)
end subroutine write_unfmt_myint

end module mymod
program test
use mymod

type(mydata_t) :: dd
type(myint_t) :: ii
dd = mydata_t( 'xyz' )
ii%name = 'abc'
ii%nn = 100
allocate(ii%xx(ii%nn))
ii%xx = 5

open(10, file='test.dat', form='unformatted')
write(10) dd
write(10) ii
end program test

Am trying to use select type and i have a parameterized data type.

I can't find whether it's possible to use the select type in order to do an upcasting.

And when i search in the standard i only find select type for derived type without parameters.

Thank you.

Hello,

I am trying to port a coarray fortran application from Windows to Linux (Ubuntu 16.04). This application compiles and works fine under Windows. I am using the Intel Fortran 19 Update 4. I applied all the compiler flags that were set on the Windows version including -coarray and -corray-num-images=10. Under Linux, when I try to compile, I get the following error:

Iwfm_f2.f90:(.text+0x76eb): undefined reference to `for_rtl_ICAF_LAUNCH'

An internet search turned nothing on this error. Can somebody let me know what I might be doing wrong?

Thanks,

Jon 

Hi,

I've been working on a bug for weeks that is very difficult to hunt. Finally, I've decided to go at the assembly level to track it down. I am not allowed to share or post the code, but I am quite puzzled by the assembly code. To simplify, the subroutine looks like this:

subroutine anonymized(this, k)
  implicit none
  class(my_type), intent(inout) :: this
  integer, intent(in) :: k

  real(8) :: aux
  integer :: i1, i2
  
  aux = this%something ...
  do i1 = 1, this%n
    do i2 = 1, this%m
      if (this%value(i1) < 1.0e-10) then
        ...

and the code crashes at the first comparison of this%value(i1). The crash is only observable with some flags such as -O2 -heap-arrays 0. If I try to print the value of this%value(i1), just before it is used, the code runs fine to completion and the bug dissapears. Sometimes, when I change the code that is *after* this one, the bug disappears. It just drives me crazy.

So I had a look at the assembly code. The beginning of this code is given here.

Dump of assembler code for function __anonymized:
=> 0x0000000000522970 <+0>:	push   %rbp
   0x0000000000522971 <+1>:	mov    %rsp,%rbp
   0x0000000000522974 <+4>:	push   %r12
   0x0000000000522976 <+6>:	push   %r13
   0x0000000000522978 <+8>:	push   %r14
   0x000000000052297a <+10>:	push   %r15
   0x000000000052297c <+12>:	push   %rbx
   0x000000000052297d <+13>:	sub    $0x148,%rsp
   0x0000000000522984 <+20>:	mov    (%rdi),%rbx
   0x0000000000522987 <+23>:	mov    %rsi,-0x80(%rbp)
   0x000000000052298b <+27>:	mov    %rdi,-0x78(%rbp)
   0x000000000052298f <+31>:	mov    0x79c58(%rbx),%rdx
   0x0000000000522996 <+38>:	neg    %rdx
   0x0000000000522999 <+41>:	movslq 0x7a6a8(%rbx),%rcx
   0x00000000005229a0 <+48>:	add    %rcx,%rdx
   0x00000000005229a3 <+51>:	mov    0x79c18(%rbx),%rax
   0x00000000005229aa <+58>:	movsd  0x7a688(%rbx),%xmm0
   0x00000000005229b2 <+66>:	mov    0x79ba0(%rbx),%r8d
   0x00000000005229b9 <+73>:	mov    %rcx,-0x88(%rbp)
   0x00000000005229c0 <+80>:	mulsd  (%rax,%rdx,8),%xmm0
   0x00000000005229c5 <+85>:	mov    %r8d,-0x48(%rbp)
   0x00000000005229c9 <+89>:	mov    0x79bc0(%rbx),%ecx
   0x00000000005229cf <+95>:	test   %r8d,%r8d
   0x00000000005229d2 <+98>:	jle    0x527bcf <__anonymized+21087>
   0x00000000005229d8 <+104>:	mov    %ecx,%r13d
   0x00000000005229db <+107>:	xor    %r12d,%r12d
   0x00000000005229de <+110>:	and    $0xfffffff8,%r13d
   0x00000000005229e2 <+114>:	pxor   %xmm2,%xmm2
   0x00000000005229e6 <+118>:	movslq -0x48(%rbp),%rax
   0x00000000005229ea <+122>:	pxor   %xmm3,%xmm3
   0x00000000005229ee <+126>:	movslq %r13d,%r10
   0x00000000005229f1 <+129>:	movslq %ecx,%rdx
   0x00000000005229f4 <+132>:	movsd  0x13bb9c(%rip),%xmm1        # 0x65e598
   0x00000000005229fc <+140>:	mov    %rax,-0x40(%rbp)
   0x0000000000522a00 <+144>:	mov    %r10,-0x160(%rbp)
   0x0000000000522a07 <+151>:	mov    %r13d,-0x168(%rbp)
   0x0000000000522a0e <+158>:	mov    %ecx,-0x30(%rbp)
   0x0000000000522a11 <+161>:	cmpl   $0x0,-0x30(%rbp)
   0x0000000000522a15 <+165>:	jle    0x522d10 <__anonymized+928>
   0x0000000000522a1b <+171>:	neg    %r11
   0x0000000000522a1e <+174>:	add    %r12,%r11
   0x0000000000522a21 <+177>:	mov    0x79fd8(%rbx),%rdi
   0x0000000000522a28 <+184>:	mov    0x7a018(%rbx),%r8
   0x0000000000522a2f <+191>:	mov    0x7a260(%rbx),%rsi
   0x0000000000522a36 <+198>:	comisd 0x8(%rdi,%r11,8),%xmm1

The code crashed on comisd. It seems that the jle are not taken (I am a beginner to assembly code). On the comisd line, 0x8(%rdi,%r11,8) is obviously trying to access the array at index r11. I have checkd %rdi which contains the right address. But what is surprising, is that r11 is set to 140737488332700 at the beginning of the function and is only neg at line 0x0000000000522a1b. So it feels to me that the register %r11 is never initialized.

What do you think of that?

Best regards

I believe I finally found a nasty compiler bug. Starting with compiler version intel/2017.5.239 up to the most recent avaiable for me intel/2019.0.117, there is a problem with pointing to a component of an allocated derived type. Opposing to the expectation using the pointer modifies always the first component of type instead of the one that it is pointing to. The following minimal reproducer compiled with -O0 returns:

 F F

In the example it is only output, however, it works also wrong for modifying, even with the type components have different POD types. The intel compiler 2016 and earlier shows the expected behavoir.

PROGRAM main
  IMPLICIT NONE

  TYPE t_traj
    LOGICAL :: a = .FALSE.
    LOGICAL :: b = .TRUE.
  END TYPE t_traj

  INTEGER, PARAMETER :: noPart = 3
  TYPE(t_traj), TARGET, ALLOCATABLE :: sps(:)
  LOGICAL, POINTER :: p_point(:)
  ALLOCATE( sps(noPart) )

  p_point(1:noPart-1) => sps(1:noPart-1)%b
  WRITE(*,*) p_point

  DEALLOCATE( sps )
END PROGRAM main

Hello,

Our code uses large arrays and the matmul intrinsic. Recently, when compiling with -check all, I got an internal compiler error. I have stripped down the problem to a simple program (see attached). I am not sure if the problem is due to a very "bad use" of matmul but I thought I would look for advice on the problem. When compiling the attached program, with

ifort MatMulTest.F90 -traceback -check all,noarg_temp_created -o MatMulTest.x

I get the following error:

/tmp/ifortLOaq88.i90: catastrophic error: **Internal compiler error: segmentation violation signal raised** Please report this error along with the circumstances in which it occurred in a Software Problem Report.  Note: File and line given may not be explicit cause of this error.

compilation aborted for MatMulTest.F90 (code 1)

Thanks,

Anthony