Quantcast
Channel: Intel® Fortran Compiler for Linux* and macOS*
Viewing all 2583 articles
Browse latest View live

Using GDB to debug an MPI program in Fortran (on MAC)

$
0
0

 

0down votefavorite

 

Hello, I am trying to debug an MPI fortran program using the advice from this post: (Using GDB to debug an MPI program in Fortran). The idea is to place an MPI_BARRIER inside a DO WHILE loop and then attach gdb to the right process with something like 

gdb -pid 12345

However, I keep getting the following message:

warning: unhandled dyld version (15)

0x00007fffb6f2ef46 in ?? ()

 When I try:

(gdb) info locals

I get "No symbol table info available". As a result, I can not attach gdb to the running process. I am working with MacOS 10.12 (Sierra), gdb 8.0, and compiling with mpif90 configured for ifort (version: 17.0.4). Any ideas about what could be the cause for this problem?

Thread Topic: 

Question

Lining against correct version of libmkl_blacs_*.so

$
0
0

Dear folks,

I am about to build an MPI executable with ifort/mpif90, linking it to the MKL and the OpenMPI libs. I came to the point where a serious problem wrt. to linking with the correct version of the mkl_blacs library occurs. I. e., I try to link with the library libmkl_blacs_ilp64.so (one of the MKL libraries), but the ifort/mpif90 inserts an incorrect library symbol into the ELF object file of the executable:

    libmkl_blacs_ilp64.so => not found

How should I tell the ifort/mpif90 compiler to link with libmkl_blacs_openmpi_ilp64.so and not wirh libmkl_blacs_ilp64.so?

 

Thanks for your help

Sebastian

Thread Topic: 

Help Me

catastrophic error: **Internal compiler error: segmentation violation signal raised** Please report this error along with the ci

$
0
0

Hi,

I received the following error:

ifort    -qopenmp -c mod_transition.f90

mod_transition.f90: 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 mod_transition.f90 (code 1)
Makefile:64: recipe for target 'mod_transition.o' failed
make: *** [mod_transition.o] Error 1

Using ifort/2017.1.132-GCC-6.3.0-2.27

I received the error after making some changes to the mod_transition.f90 file. But have since reverted to a previous commit which compiled fine, and the error still persists. I've found that compiling with the -g debug flag the error does not occur.

The problem also occurs if instead I use ifort/2017.1.132-GCC-5.4.0-2.26

 

 

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px 'Andale Mono'; color: #28fe14; background-color: #000000; background-color: rgba(0, 0, 0, 0.9)}
span.s1 {font-variant-ligatures: no-common-ligatures}

Thread Topic: 

Bug Report

Unsuccessful OpenMPI configuration

$
0
0

Dear Community,

Could you please help me out with the following issue:

1. I have installed Intel Package and source compilers (i.e. icc compiler) in my system:   /opt/intel/compilers_and_libraries_2017.4.196/linux/bin/intel64/icc

2. I try to run ./configure with flags:   $ ./configure --prefix=/usr/local CC=icc CXX=icpc F77=ifort FC=ifort

3. Finally the system says that there is no icc existed, but it is recognizable from which icc command.

Please tell me what I do wrong...

I paste small part of the output log from OpenMPI configuration and also send the whole file in the attachment.

 

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by Open MPI configure 1.10.7, which was
generated by GNU Autoconf 2.69.  Invocation command line was

  $ ./configure --prefix=/usr/local CC=icc CXX=icpc F77=ifort FC=ifort

## --------- ##
## Platform. ##
## --------- ##

hostname = d25
uname -m = x86_64
uname -r = 4.4.0-83-generic
uname -s = Linux
uname -v = #106-Ubuntu SMP Mon Jun 26 17:54:43 UTC 2017

/usr/bin/uname -p = unknown
/bin/uname -X     = unknown

/bin/arch              = unknown
/usr/bin/arch -k       = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo      = unknown
/bin/machine           = unknown
/usr/bin/oslevel       = unknown
/bin/universe          = unknown

PATH: /usr/local/sbin
PATH: /usr/local/bin
PATH: /usr/sbin
PATH: /usr/bin
PATH: /sbin
PATH: /bin
PATH: /snap/bin

## ----------- ##
## Core tests. ##
## ----------- ##

configure:5535: checking build system type
configure:5549: result: x86_64-pc-linux-gnu
configure:5569: checking host system type
configure:5582: result: x86_64-pc-linux-gnu
configure:5602: checking target system type
configure:5615: result: x86_64-pc-linux-gnu
configure:5744: checking for gcc
configure:5771: result: icc
configure:6000: checking for C compiler version
configure:6009: icc --version >&5
./configure: line 6011: icc: command not found
configure:6020: $? = 127
configure:6009: icc -v >&5
./configure: line 6011: icc: command not found
configure:6020: $? = 127
configure:6009: icc -V >&5
./configure: line 6011: icc: command not found
configure:6020: $? = 127
configure:6009: icc -qversion >&5
./configure: line 6011: icc: command not found
configure:6020: $? = 127
configure:6040: checking whether the C compiler works
configure:6062: icc    conftest.c  >&5
./configure: line 6064: icc: command not found
configure:6066: $? = 127
configure:6104: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "Open MPI"
| #define PACKAGE_TARNAME "openmpi"
| #define PACKAGE_VERSION "1.10.7"
| #define PACKAGE_STRING "Open MPI 1.10.7"
| #define PACKAGE_BUGREPORT "http://www.open-mpi.org/community/help/"
| #define PACKAGE_URL ""
| #define OPAL_ARCH "x86_64-pc-linux-gnu"
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:6109: error: in `/tmp/openmpi-1.10.7':
configure:6111: error: C compiler cannot create executables
See `config.log' for more details

 

AttachmentSize
Downloadtext/plainlog.txt56.36 KB

ifort 18 beta: severe bug with the SYNC IMAGES statement

$
0
0

I am using ifort 18 beta update 1 on Linux Ubuntu and did observe a severe bug with the SYNC IMAGES statement yet. Can someone confirm that the following program does work with ifort 17 but does not execute if compiled with ifort 18 beta yet?

ifort -coarray -coarray-num-images=2 Main.f90 -o a.out

program Main
  !
  if (this_image() == 1) then
    sync images(*)
  else
    sync images(1)
  end if
  !
end program Main

With ifort 18 beta I am getting the following runtime error:

forrtl: severe (778): One of the images to be synchronized with has terminated.
In coarray image 2
Image              PC                Routine            Line        Source
libicaf.so         00007EFD79C4D607  for_rtl_ICAF_BARR     Unknown  Unknown
a.out              0000000000403CD4  Unknown               Unknown  Unknown
a.out              0000000000403C62  Unknown               Unknown  Unknown
libc-2.19.so       00007EFD7937BF45  __libc_start_main     Unknown  Unknown
a.out              0000000000403B69  Unknown               Unknown  Unknown

forrtl: severe (778): One of the images to be synchronized with has terminated.
In coarray image 1
Image              PC                Routine            Line        Source
libicaf.so         00007FAED9063607  for_rtl_ICAF_BARR     Unknown  Unknown
libicaf.so         00007FAED906333E  for_rtl_ICAF_BARR     Unknown  Unknown
a.out              0000000000403CE7  Unknown               Unknown  Unknown
a.out              0000000000403C62  Unknown               Unknown  Unknown
libc-2.19.so       00007FAED8791F45  __libc_start_main     Unknown  Unknown
a.out              0000000000403B69  Unknown               Unknown  Unknown

application called MPI_Abort(comm=0x84000004, 3) - process 0

(As an aside: It took some time to identify the source of this error, because I do not use SYNC IMAGES regularly and only together with customized synchronization procedures (using sync memory and atomic subroutines) within the same program.)

Best Regards

Thread Topic: 

Bug Report

Setting MKL to use with Intel ParallelAccelerator

$
0
0

I am programming in Julia and for Parallel computing i am using ParallelAccelerator.jl package. I was able to setup OpenBLAS with g++. Kindly help me out to set up Intel MKL with g++. I have installed Julia using macOS dmg package hence I am unable find Make.inc file. This is article from Intel which explains setting up Julia with Intel MKL I am unable to setup Julia to use MKL instead its currently using OpenBLAS as you can see from the below output. 

julia> versioninfo()
Julia Version 0.5.2
Commit f4c6c9d4bb (2017-05-06 16:34 UTC)
Platform Info:
  OS: macOS (x86_64-apple-darwin13.4.0)
  CPU: Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.7.1 (ORCJIT, haswell)
julia> Pkg.build("ParallelAccelerator")
INFO: Building ParallelAccelerator
ParallelAccelerator: build.jl begin.
ParallelAccelerator: Building j2c-array shared library
System installed BLAS found
Checking for OpenMP support...
OpenMP support found in g++-7
Max OpenMP threads: 8
Using g++-7 to build ParallelAccelerator array runtime.
ParallelAccelerator: build.jl done.

This is how i setup openblas 

export CPLUS_INCLUDE_PATH=$CPLUS_INCLUDE_PATH:/usr/local/opt/openblas/include/
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/opt/openblas/lib/

Kindly let me know if there any other way to Setup MKL.

Thank You
Regards
Saran

Zone: 

Thread Topic: 

Help Me

ifort: command line warning #10006: ignoring unknown option '-rpath'

$
0
0

I am a student working in atmospheric sciences. I am trying to compile a source code of RegESM-1.0.0. while running the configure command it completes successfully but make and make install program issues the following warning: 

............................

-ldl -lpnetcdf /home/ROMS/ROMS_LIB/lib/libxerces-c.so -lnsl /home/ROMS/REGCM-ROMS/src/esm/RegESM-1.0.0/libatm.a /home/ROMS/REGCM-ROMS/src/esm/RegESM-1.0.0/libocn.a -rpath /home/ROMS/ROMS_LIB/lib -rpath /home/ROMS/ROMS_LIB/lib

ifort: command line warning #10006: ignoring unknown option '-rpath'

ifort: command line warning #10006: ignoring unknown option '-rpath'

........

Though, the make and make install command did not abort, it did not produce any executable after compilation. I seek help from the community to overcome this error. I looked upon the makefile and libtool files but could not infer much of it.

Any lead will in solving this is appreciated.

Thanks in anticipation.

 

Regards

Dhirendra

Zone: 

Thread Topic: 

Help Me

ifort GLIBC dependencies

$
0
0

When compiling with ifort 17 on Linux, I notice very different GLIBC dependencies than when compiling with icc.  In particular, the following code

      program main
      write(*,*) 'Hello world!'
      end program main

when compiled on my RHEL 6 system (GLIBC2.11) produces an executable that when examined with objdump -x shows dependencies on 

    0x0d696914 0x00 10 GLIBC_2.4
    0x0d696913 0x00 08 GLIBC_2.3
    0x0d696917 0x00 07 GLIBC_2.7
    0x06969191 0x00 06 GLIBC_2.11
    0x09691974 0x00 05 GLIBC_2.3.4
    0x09691a75 0x00 02 GLIBC_2.2.5

On the other hand, an equivalent C program:

#include <stdio.h>

int main() {
  // call a function in another file
  printf("Hello world!\n");

  return(0);
}

shows dependencies only on

    0x0d696914 0x00 04 GLIBC_2.4
    0x09691a75 0x00 03 GLIBC_2.2.5
    0x09691974 0x00 02 GLIBC_2.3.4

Is there a way to eliminate the GLIBC2.11 dependency of the executable generated by ifort?  Compiling with ifort -D_XOPEN_SOURCE=500 results in no complains but identical GLIBC dependencies.

 


Missing files during code coverage

$
0
0

I have a project that I compile with the intel toolchain. All the .f90 files are compiled to corresponding .o files in the bin directory. When I use the codecov utility I get an HTML with the list of covered files. However that list is missing a bunch of files which should be eligible for coverage. Some of the modules contained in those files are even used during the runs.

What could be a reason why these these files are missing from the coverage report?

 

error #6236: A specification statement cannot appear in the executable section

$
0
0

Hello:

I am writing a user subroutine, UMAT, for Abaqus where I need the UMAT subroutine to update and use my own specified stiffness matrix and solution dependent state variables.

I am attaching the fortran file. This is the error message I am getting!

umat_sdvini4.f(41): error #6236: A specification statement cannot appear in the executable section.
      integer i, j
------^
 Intel(R) Fortran 15.0-1684
compilation aborted for umat_sdvini4.f (code 1)

If any of you can help, that would be great!

Thank you very much,

Mousumi Ghosh

AttachmentSize
Downloadapplication/octet-streamumat_sdvini4.f2.25 KB

command line remark #10148: option '-i-dynamic' not supported

$
0
0

Hello:

How do I fix this error? The file (used in conjuction with Abaqus) is attached!

ifort: command line remark #10148: option '-i-dynamic' not supported

Please help! Thanks!

Mousumi

AttachmentSize
Downloadapplication/octet-streamumat_sdvini4.f2.25 KB

Visual Studio Code?

New WG5 web site and Fortran 2020 feature survey!

$
0
0

For many years, the "web home" of ISO/IEC JTC1/SC22/WG5 (the international Fortran standards committee, or WG5 for short) has been graciously hosted by NAG. I am pleased to announce that WG5 now has its own web site: https://wg5-fortran.org/ The site is served over https and is "mobile friendly".

The WG5 web site is where you'll find news about what's happening with the Fortran standard, and links to all WG5 documents. Information on current and past standards is also available there.

On the home page you will see a link to a survey, requesting opinions on and suggestions for features that you would like to see in the next Fortran standard, tentatively titled Fortran 2020. If you want to help shape the future of Fortran, please take a few minutes and fill out the survey. While the survey will remain open through January 2018, we will start analyzing responses at the October J3 meeting. Also, the list of features the survey asks you to rank may be amended based on suggestions received.

I welcome all comments on the web site, and especially if you discover any problems. Not yet done are the email list indexes and news older than 2016.

speed difference contiguous pointers vs call_by_reference

$
0
0

Hi there,

in the course of modernizing some of my code I have moved to putting many "call by refernce" routines which were previously "stand-alone" behind types. In addition arrays are now passed using type bound pointers, usually with the "contiguous" attribute. This has the big advantage of avoiding to pass array boundaries explicitly (because many of my arrays start at index value zero). However, I have noticed a speed difference to an extent that the type bound routines need up to twice as much time for processing large arrays than the direct routines.

The below program mimics the above structure. It implements the frist part of an implicit multiplication of a 4.5 Mio x 100 matrix with an 4.8 Mio x 4.8 Mio structured sparse co-variance matrix (the latter matrix can be stored in form of four vectors and is held by the type). This routine needs about 4.8 seconds when called directly, and about 6.6 seconds when called through the type. This is n ot a big difference in absolute numbers, but sums up when performed several thousand times. Given that the type transports the array into the routine via a pointer with attribute "contiguous" this difference in speed should not appear. however, may be I haven't understood the standard incorrectly. The speed was measured on a Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz with 56 processors. The compiler was ifort 17.4. The data set can be supplied on request.

Any Ideas?

Thanks a lot

Module Mod_Direct
contains
  Subroutine SubDrop(ISUBound1,ISUBound2,RMInOut,ivi,ivs&&,ivd,rvp,ISNThreads)
    !$ use omp_lib
    Implicit None
    Integer*8, Intent(In) :: ISUbound1, ISUBound2
    Real*8, Intent(InOut) :: RMInOut(0:ISUbound1,1:ISUBound2)
    Integer*8, Intent(In) :: ivs(:), ivd(:), ivi(:)
    Real*8, Intent(In) :: RVp(:)
    Integer*4, intent(in), optional :: ISNThreads
    Integer*8 :: c1, c2, ss, dd, ii
    outer:block
      RMInOut(0,:)=0.0D00
      !$ if(present(ISNThreads)) Then
      !$   if(ISNThreads>size(RMInOUt,2)) Then
      !$     call omp_set_num_threads(size(RMInOut,2))
      !$   else
      !$     call omp_set_num_threads(ISNThreads)
      !$   End if
      !$ else
      !$   c1=omp_get_max_threads()
      !$   if(c1>size(RMInout,2)) Then
      !$     call omp_set_num_threads(size(RMInout,2))
      !$   else
      !$     call omp_set_num_threads(int(c1,4))
      !$   End if
      !$ end if
      !$OMP PARALLEL DO PRIVATE(ss,dd,c2,c1)
      Do c1=1,size(RMInOut,2)
        Do c2=1,size(IVI,1)
          ss=ivs(c2)
          dd=ivd(c2)
          ii=ivi(c2)
          RMInOut(ii,c1)=RMInOut(ii,c1)+rvp(c2)*(RMInOut(ss,c1)&&+RMInOut(dd,c1))
        End Do
      End Do
      !$OMP END PARALLEL DO
    End block outer
  End Subroutine SubDrop
end Module Mod_Direct
Module Mod_Type
  Type :: Testtype
    Integer*8, Allocatable :: ivi(:), ivs(:), ivd(:)
    Integer*8 :: isn
    Integer*4 :: ISSubStat
    Real*8, Allocatable :: rvp(:)
    Real*8, Pointer, contiguous :: RMInout(:,:)
    Character(:), allocatable :: csmsg
  contains
    procedure, pass, public :: drop=>subdrop
  End type Testtype
  Interface
    Module Subroutine SubDrop(this,ISNThreads)
      Class(TestType) :: this
      Integer*4, optional :: ISNThreads
    end Subroutine
  End Interface
  Private :: SubDrop
end Module Mod_Type
SubModule(Mod_Type) Drop
contains
  Module Procedure SubDrop
  !$ use omp_lib
    Implicit None
    Integer*8 :: c1, c2, ss, dd, ii
    outer:block
      if(.not.associated(this%RMInOut)) Then
        this%CSMSG="ERROR"
        this%ISSubStat=1;exit outer
      end if
      if(lbound(this%RMInOut,1)/=0) Then
        this%CSMSG="ERROR"
        this%ISSubStat=1;exit outer
      End if
      if(ubound(this%RMInOut,1)/=this%isn) Then
        this%CSMSG="ERROR"
        this%ISSubStat=1;exit outer
      End if
      this%RMInOut(0,:)=0.0D0
      !$ if(present(ISNThreads)) Then
      !$   if(ISNThreads>size(this%RMInOUt,2)) Then
      !$     call omp_set_num_threads(size(this%RMInOut,2))
      !$   else
      !$     call omp_set_num_threads(ISNThreads)
      !$   End if
      !$ else
      !$   c1=omp_get_max_threads()
      !$   if(c1>size(this%RMInout,2)) Then
      !$     call omp_set_num_threads(size(this%RMInout,2))
      !$   else
      !$     call omp_set_num_threads(int(c1,4))
      !$   End if
      !$ end if
      !$OMP PARALLEL DO PRIVATE(ss,dd,c2,c1)
      Do c1=1,size(this%RMInOut,2)
        Do c2=1,size(this%ivi,1)
          ss=this%ivs(c2)
          dd=this%ivd(c2)
          ii=this%Ivi(c2)
          this%RMInOut(ii,c1)=this%RMInOut(ii,c1)+this%RVP(c2)&&*(this%RMInOut(ss,c1)+this%RMInOut(dd,c1))
        End Do
      End Do
      !$OMP END PARALLEL DO
    End block outer
  end Procedure
End SubModule Drop
Program Test
  use Mod_Type
  use Mod_Direct
  Implicit none
  Type(TestType) :: TST
  integer :: dim=4876565, dim3=100, c1
  real*8, target, allocatable :: rmtmp(:,:)
  real*8 :: t0, t1
  !$ call omp_set_nested(.TRUE.)
  Allocate(TST%ivi(dim),TST%ivs(dim),TST%ivd(dim),TST&&%rvp(dim))
  open(55,file="input.txt",action="read")
  Do c1=1,dim
    read(55,*) TST%ivi(c1),tst%ivs(c1),tst%ivd(c1),tst%rvp(c1)
  end Do
  tst%isn=maxval(tst%ivi)
  Allocate(rmtmp(0:tst%isn,dim3),source=0.0D0)
  !!@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  TST%RMInOut=>rmtmp
  call TST%drop()
  !!@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  !!call SubDrop(ISUBound1=Int(tst%isn,8),ISUBound2=Int(dim3,8),RMInout&
  !!  &=rmtmp,ivi=tst%ivi,ivs=tst%ivs,ivd=tst%ivd,rvp=tst%rvp)
End Program Test

 

Compiler not warning on poor syntax in DO loop construct

$
0
0

I've been chasing my tail for an hour trying to understand why some variables were not initialised and finally twigged that I had a missing comma in a do loop.

I had;

DO J=NCHAN, 1 -1

   DO STUFF

END DO

I had missed the comma between the end of iteration control and the step. I have IMPLICIT NONE and  I'm compiling with  -c -m64 -g -check all -debug full -traceback -warn all -heap-arrays

Shouldn't this get flagged at compile time? I'm using XE 2017 Update 4.

Cheers

Kim


parallel programming using OPENMP

$
0
0

 

Hi ifort develiper and users,

I have written a fortran code(where four loops are present) in openMP. Here i share the openMP code, where the second loop is parallelized.

first: do i=1,NMAX,1
xmsd_1(i) = 0.0
!$omp parallel default(none) &
!$omp shared (NTMAX,nmol,i,com_xu,P_1,xmsd_1) &
!$omp private(k,m,dx,xmsd,pr_1)
!$omp do reduction(+:xmsd_1)
second: do j=1,NTMAX,1
third : do k =1,nmol,1

pr_1 = 1
fourth : do m=jframe,jframe+iframe,1
        pr_1 = pr_1 * P_1(m,k)
end do fourth

if(pr_1 .eq. 1) then
dx = com_xu(k,j+i) - com_xu(k,j)
xmsd = dx*dx
xmsd_1(i) = xmsd_1(i) + xmsd * pr_1
end if

end do third
end do second
!$omp end do 

!$omp end parallel

print*, i,xmsd(i)

end do first

My openMP code(where second loop was parallelized) results do not match the serial code results.  could you please suggest a solution to this problem?

 

Determining DIRECT_IO_FACTOR on Linux

$
0
0

Hello,

 

 

I have compiled Quantum Espresso (QE) in a Linux cluster using intel2016.4.258 and openmpi-2.1.1. I get a runtime error for IOSTAT=121. The DIRECT_IO_FACTOR ( block length byte) in the QE code is set to 8. 

My understanding is that DIRECT_IO_FACTOR is system dependent. Is there a way to find out what DIRECT_IO_FACTOR value is on any Linux system?

Thank you,

Vahid

Initializing allocatable arrays to NaN

$
0
0

Hello,

 

A search indicates that this question was asked (in the Fortran for Windows Forum) before, but that was three years ago, and I can't find any update.

I'm using Intel Fortran version16.1 and I'd like to initialize allocatable arrays to NaN to aid in debugging.  I am familiar with the -ftrapuv and -init=snan,array options but it is my understanding they do not work for allocatable arrays.  The answer in the three year old question I found was "it is something we are working on for the future".  It is now the "future", and since that topic is closed, I've opened a new question to ask again.  Has that capability been added?  Or is it still part of future plans?

Chris Harrop

__intel_avx_rep_memcpy page fault

$
0
0

Dear All,

I'm using Systemstamp probes (vm.pagefault) to avoid page faults in my code by forcing to read/write in all memory. The probe says that __intel_avx_rep_memcpy has page fault:

fault address: 0x424000, symbol: __intel_avx_rep_memcpy+0x80/0x17c0, access: r, type: minor, delay: 36

according to asm it is:

(gdb) info symbol __intel_avx_rep_memcpy+0x80
__intel_avx_rep_memcpy + 128 in section .text

0x0000000000423fb9 <+121>:	shr    $0x2,%r9
0x0000000000423fbd <+125>:	sub    %r9,%r11
0x0000000000423fc0 <+128>:	cmp    %r11,%rcx
0x0000000000423fc3 <+131>:	jae    0x424060 <__intel_avx_rep_memcpy+288>
0x0000000000423fc9 <+137>:	nopl   0x0(%rax)

So could you help me to understand what memory should be forced there?

Regards,

Roman

Compilation options for error checking

$
0
0

Recently I found a compilation difference between the compiler for Linux and the one for windows. The Windows one can report some errors, like miss matching of dummy arguments and actual ones, which the Linux one can't.  I'd like to know if there is any option which can force the compiler to do that. Thanks!

Viewing all 2583 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>