A simple code:
program main
integer, allocatable :: A(:,:)
integer :: B(3,4)
B=1
A = B !A will get allocated, with the same shape and bounds as B
end program main
Compiling the above code with: gfortran-8 -std=f2008 -fcheck=all -Wall -Wextra -fbounds-check -fimplicit-none array.f90
I got the following warning:
Warning: ‘a.offset’ may be used uninitialized in this function
Warning: ‘a.dim[0].lbound’ may be used uninitialized in this function
Warning: ‘a.dim[0].ubound’ may be used uninitialized in this function [-Wmaybe-uninitialized]
Is there somebody having an idea of why I got these warnings?
This is a well known GCC bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77504 that has been reported in many duplicates to the bugzilla (even by myself) - see the Duplicates section for the other incarnations.
As far as I understand it the actual code generated by the compiler should work correctly and it is just an incorrect warning. As Steve pointed out in the comment, use -Wno-maybe-uninitialized to hide this warning. I have included it into my build scripts as well.
I use armadillo library. somewhere I get this exception:
error: Mat::init(): size is fixed and hence cannot be changed
terminate called after throwing an instance of 'std::logic_error'
what(): Mat::init(): size is fixed and hence cannot be changed
Aborted (core dumped)
I know why. But I dont know where.
Is there any way to obtained the line causing this problem? is valgrind or any other tool able to do that?
Update:
compile code:
g++ -g -Wall -Wfatal-errors -Wextra -std=c++11
main.cpp -lboost_filesystem -lboost_system
Can you post a small snippet of the code where the error comes in?
I had similar error but dont remember what caused it but try storing the result of the command in some other variable and check it. And put "cout" to find the statement causing the error.
I'm trying to compile multiple FORTRAN source files, where I applied some OpenMP directives to one of the source files. For instance :
The compilation flags :
COMPILE00='ifort -O3 -openmp -openmp_report -fpconstant -fp-model precise -fpe0 -traceback -ftrapuv'
COMPILE0='ifort -O3 -fpconstant -fp-model precise -fpe0 -traceback -ftrapuv'
The compiled files :
$COMPILE0 -c microprm.F90 modules.F90
$COMPILE0 -c jernewf3p_A.F90 SMAX.F90 DE_MOTT.F90 twoinitm.F90 helek03.F90
$COMPILE00 -c helek04.F90
$COMPILE0 -c jernewf3p_melt.F90 dmin_G.F90
$COMPILE0 -c submelt_condevap.F90
Linking :
$COMPILE00 -o TKE.x *.o -lm
So the source code helek04.F90 has some OpenMP directives. It is being called from submelt_condevap.F90 which hasn't.
Is this correct compilation practice ? How should I compile it using the use omp_lib module ? Is it code-safe to compile only one file with OpenMP and link all the others with OpenMP ?
The compilation was aborted. When compiling with $COMPILE00 for ALL the files, the simulation runs, but gets a floating point exception, which doesn't occur in the serial code.
There are couple of issues that can arise. Unfortunately your description is not detailed enough. I would generally recommend to use -openmp for all files, I don't see a reason for making a distinction. Intel Fortran by default does not make the code reentrant and if you call a subroutine that has not been compiled with -openmp from the parallel region race conditions can occur. Especially during I/O operations problems are quite likely. If you have some strange reason to avoid -openmp you can try -reentrancy threaded.
If there are no calls to other code from the parallel part, and it does not run concurrently with the non-parallel part, there shouldn't be issues with it.
It is quite possible you have some race condition or other threading problem in your OpenMP code. Use tools included in your compiler collection to debug them. Intel Inspector XE is a good tool for these kinds of problems. Use options like -warn -check -g -traceback to have some useful checks. Valgrind can also be useful.
we have started linking our application with -libmysqlcppconn-static for MySQL support.
When we compile for debugging everything is ok, but when we compile for release using gcc -O2 we get errors.
We have tracked down the offending compiler option to be -funit-at-a-time.
We get may errors of the form:
libmysqlcppconn-static.a(mysql_connection.cpp.o): In function
sql::mysql::MySQL_Savepoint::getSavepointId()':
mysql_connection.cpp:(.text+0x8d): undefined reference to
std::allocator: :allocator()'
mysql_connection.cpp:(.text+0x133): undefined reference to
`std::allocator ::~allocator()'
We are working around this for now by including -fno-unit-at-a-time. Any insight into how we can correct this would be appreciated
it might be because you are using using gcc to compile the code.. try using g++ to compile the file
otherwise try using following command
gcc -lstdc++ file.cpp
I am not a Fortran programmer (just a short experience), but I need to compile a program partly written in F77. Someone has compiled it with Absoft compiler before me, but now I need to repeat the procedure on another machine with g77. For Absoft, the makefile has
f77 -f -w -O -B100 -B108 -c *.f
mv *.f flib && mv *.o olib
f77 -B100 -o runme olib/*.o clib/*.o -L/usr/X11R6/lib64 -L/usr/X11R6/lib -lX11 -L$PVM_ROOT/lib/$PVM_ARCH -lfpvm3 -lpvm3 -L$ABSOFT/lib -lU77
I have modified these lines to be
g77 -w -O -B100 -B108 -c *.f
mv *.f flib && mv *.o olib
g77 -B100 -o runme olib/*.o clib/*.o -L/usr/X11R6/lib64 -L/usr/X11R6/lib -lX11 -L$PVM_ROOT/lib/$PVM_ARCH -lfpvm3 -lpvm3 -lgfortran -lgfortranbegin
But I get the following error messages
somefile.f:(.text+0x93): undefined reference to `for_open'
somefile.f:(.text+0xf4): undefined reference to `for_write_seq_fmt'
somefile.f:(.text+0x128): undefined reference to `for_write_seq_fmt_xmit'
somefile.f:(.text+0x454): undefined reference to `for_read_seq'
How can I fix this?
UPDATE1
If I add -libifcore to the end of the last line (linker), then I get
/usr/bin/ld: cannot find -libifcore
I have located the library
$ find /opt/intel/* -name 'libifcore*'
/opt/intel/fce/9.1.036/lib/libifcore.a
/opt/intel/fce/9.1.036/lib/libifcore.so
/opt/intel/fce/9.1.036/lib/libifcore.so.5
/opt/intel/fce/9.1.036/lib/libifcore_pic.a
/opt/intel/fce/9.1.036/lib/libifcoremt.a
/opt/intel/fce/9.1.036/lib/libifcoremt.so
/opt/intel/fce/9.1.036/lib/libifcoremt.so.5
/opt/intel/fce/9.1.036/lib/libifcoremt_pic.a
But even if I do the following in the source directory
$ export PATH=$PATH:/opt/intel/fce/9.1.036/lib/
$ ln -s /opt/intel/fce/9.1.036/lib/libifcore.so
it is not found.
Moreover, it is the same machine where I get another problem How to pass -libm to MPICC? libimf.so: warning: feupdateenv is not implemented and will always fail
It seems that the compiler should find the library, if needed
$ echo $LD_LIBRARY_PATH
/opt/intel/fce/9.1.036/lib:/opt/intel/cce/9.1.042/lib:/usr/local/lib/openmpi:/usr/local/lib:/usr/lib:
Absoft accepted an extended version of Fortran 77 that is not completely compatible with the extended version of Fortran 77 accepted by g77.
So there is no guarantee that you can do this without editing the code. I seem to recall that the Absoft compiler accepted a handy initialization syntax that can not be replicated with g77.
If you want to compile & link using g77, the easiest way is to use the command "g77". (What compiler does f77 invoke on your computer? Try "f77 -v" or similar to find out...) It should automatically find the g77 Fortran-specific libraries. You should not need to explicitly link to Fortran libraries, and especially not to the libraries of gfortran, which is a different compiler. You could also compile & link with gfortran -- it will probably recognize that the source code is Fortran 77 and compile appropriately if the files have the correct file type, otherwise you will have to use options -- for this compiler, use the command "gfortran".
With g77 and gfortran it should not need Intel libraries -- maybe f77 is connected to ifort, the Intel compiler, on your computer?
Edited later:
I suggest trying something simpler first to test your setup.
Try this FORTRAN 77 program as file "junk.f"
C234567
write (6, *) "Hello World"
stop
end
Try this command:
g77 junk.f -o junk.exe
Run it via:
./junk.exe
This will test whether g77 is working.
it looks like you are trying to link with libifcore.
Edit:
You can include this library by adding
'-lifcore' to your compiler options. To quote the gcc tutorial
In general, the compiler option -lNAME will attempt to link object files with a library file ‘libNAME.a’ in the standard library directories.
why do you use g77 and not gfortran?
what do you mean with multiprocessing? openmp or vectorized?
you can use openmp with the gfortran compiler and when you want to use vector mode like the ifort compiler does, you have to specify sse explicitly in the compiler options.
It seems that the problem was in an error in one of the source files, which wasn't a big deal for Absoft compiler. g77 was giving a warning about it, but compiling this file and producing the original errors (mentioned in the question) without a binary.
When I tried ifort, compilation of that file was aborted, but other files were compiled and a binary was created.
fortcom: Error: somefile.f, line 703: An extra comma appears in the format list. [)]
& (1p5e12.3,5h ...,))
-------------------------^
compilation aborted for somefile.f (code 1)
When I removed the extra comma, then both compilers have compiled everything and created binaries, although ifort produced a number of warnings.
Then, when I tried to run both binaries, the one made by Intel comiler was working fine, but the one by g77 was behaving very strange and didn't really do what I wanted.
So now the original problem is resolved, however the code doesn't run in multiprocessing mode, so the binary is unfortunately useless for me.