[Bug libgomp/109904] linking with -static flag generates undefined references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 --- Comment #8 from GARY.WHITE at ColoState dot edu --- So send me the link where I should get the binaries from. Gary C. White, CWB(r) Professor Emeritus Department of Fish, Wildlife, and Conservation Biology 10 Wagar Colorado State University Fort Collins, CO 80523 (515)450-2768 Mobile gary.wh...@colostate.edu https://sites.warnercnr.colostate.edu/gwhite/ he/him/his See where we are! "Leadership is a privilege to better the lives of others. It is not an opportunity to satisfy personal greed." Mwai Kibaki -Original Message- From: pinskia at gcc dot gnu.org Sent: Thursday, May 18, 2023 2:59 PM To: White,Gary Subject: [Bug libgomp/109904] linking with -static flag generates undefined references ** Caution: EXTERNAL Sender ** https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 --- Comment #7 from Andrew Pinski --- (In reply to gary.wh...@colostate.edu from comment #6) > So using -ldl seems really quirky. Doesn't seem to work for > generating 32-bit executables. Plus, not working at all on my second > machine. Is there a better solution? Yes use a differently built gcc where libgomp does NOT depend on dl* functions. Again this is not the right place to report these issues, the correct place is where you got the binary GCC from. In your case that would be https://github.com/brechtsanders/winlibs_mingw/issues . -- You are receiving this mail because: You reported the bug.
[Bug libgomp/109904] linking with -static flag generates undefined references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 --- Comment #6 from GARY.WHITE at ColoState dot edu --- So using -ldl seems really quirky. Doesn't seem to work for generating 32-bit executables. Plus, not working at all on my second machine. Is there a better solution? Gary C. White, CWB(r) Professor Emeritus Department of Fish, Wildlife, and Conservation Biology 10 Wagar Colorado State University Fort Collins, CO 80523 (515)450-2768 Mobile gary.wh...@colostate.edu https://sites.warnercnr.colostate.edu/gwhite/ he/him/his See where we are! "Leadership is a privilege to better the lives of others. It is not an opportunity to satisfy personal greed." Mwai Kibaki -Original Message- From: pinskia at gcc dot gnu.org Sent: Thursday, May 18, 2023 12:33 PM To: White,Gary Subject: [Bug libgomp/109904] linking with -static flag generates undefined references ** Caution: EXTERNAL Sender ** https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 --- Comment #4 from Andrew Pinski --- (In reply to gary.wh...@colostate.edu from comment #3) > Linking with -ldl fixed the issue Where is there documentation of -ldl? -l says to link against a specified library in this case libdl; libgomp needs to open a library at runtime due to offloading support and dl* functions do that and for windows dl* functions are implemented in libdl-win32. But as I mentioned you should be asking where you got the binary toolchain instead of here. -- You are receiving this mail because: You reported the bug.
[Bug libgomp/109904] linking with -static flag generates undefined references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 --- Comment #5 from GARY.WHITE at ColoState dot edu --- I'm getting gfortran downloads from here: https://github.com/brechtsanders/winlibs_mingw/releases Gary C. White, CWB(r) Professor Emeritus Department of Fish, Wildlife, and Conservation Biology 10 Wagar Colorado State University Fort Collins, CO 80523 (515)450-2768 Mobile gary.wh...@colostate.edu https://sites.warnercnr.colostate.edu/gwhite/ he/him/his See where we are! "Leadership is a privilege to better the lives of others. It is not an opportunity to satisfy personal greed." Mwai Kibaki -Original Message- From: pinskia at gcc dot gnu.org Sent: Thursday, May 18, 2023 12:33 PM To: White,Gary Subject: [Bug libgomp/109904] linking with -static flag generates undefined references ** Caution: EXTERNAL Sender ** https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 --- Comment #4 from Andrew Pinski --- (In reply to gary.wh...@colostate.edu from comment #3) > Linking with -ldl fixed the issue Where is there documentation of -ldl? -l says to link against a specified library in this case libdl; libgomp needs to open a library at runtime due to offloading support and dl* functions do that and for windows dl* functions are implemented in libdl-win32. But as I mentioned you should be asking where you got the binary toolchain instead of here. -- You are receiving this mail because: You reported the bug.
[Bug libgomp/109904] linking with -static flag generates undefined references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 --- Comment #3 from GARY.WHITE at ColoState dot edu --- Linking with -ldl fixed the issue Where is there documentation of -ldl? Gary C. White, CWB(r) Professor Emeritus Department of Fish, Wildlife, and Conservation Biology 10 Wagar Colorado State University Fort Collins, CO 80523 (515)450-2768 Mobile gary.wh...@colostate.edu https://sites.warnercnr.colostate.edu/gwhite/ he/him/his See where we are! "Leadership is a privilege to better the lives of others. It is not an opportunity to satisfy personal greed." Mwai Kibaki -Original Message- From: pinskia at gcc dot gnu.org Sent: Thursday, May 18, 2023 12:11 PM To: White,Gary Subject: [Bug libgomp/109904] linking with -static flag generates undefined references ** Caution: EXTERNAL Sender ** https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 --- Comment #1 from Andrew Pinski --- >--enable-offload-targets=nvptx-none I suspect this might be the issue. offloading only works with targets that have dlopen . Maybe you need to link with -ldl to get it working. -- You are receiving this mail because: You reported the bug.
[Bug fortran/109904] New: linking with -static flag generates undefined references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 Bug ID: 109904 Summary: linking with -static flag generates undefined references Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Gary.White at ColoState dot edu Target Milestone: --- What follows are a portion of the undefined references when using -static with gfortran-13. I require the -static flag to be able to distribute executable to users not having gfortran on their machines. gfortran -m64 -fopenmp mark.o glabrd.o xmatrx.o tmread.o rlabrd.o blabrd.o dlabrd.o estmat.o varmat.o derivedest.o piread.o func.o saturd.o chprob.o chprob001.o chprob002.o chprob008.o chprob009.o chprob032.o chprob115.o chprob119.o chprob121.o chprob126.o chprob139.o chprob140.o chprob141.o chprob142.o chprob143.o chprob144.o chprob160.o chprob170.o chprob171.o chprob172.o chprob173.o chprob174.o chprob175.o chprob176.o chprob177.o chprob178.o chprob179.o chprob180.o chprob181.o chprob182.o chprob183.o chprob184.o rcread.o kfread.o nsread.o optmiz.o status_module.o prcisub.o prfunc.o mcmc.o hyperread.o gibbsitsub.o optimizers_module.o gaussquad.o hyper_dist_module.o profile_conf_interval_module.o data_module.o design_matrix_funcs_module.o random_values_module.o Linpack.a -o mark64.exe -static -static-libgfortran C:/tdm-gcc-64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/tdm-gcc-64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../lib\libgomp.a(target.o):(.text+0x94f): undefined reference to `dlopen' C:/tdm-gcc-64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/tdm-gcc-64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../lib\libgomp.a(target.o):(.text+0x96a): undefined reference to `dlsym' C:/tdm-gcc-64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/tdm-gcc-64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../lib\libgomp.a(target.o):(.text+0x99f): undefined reference to `dlclose' C:/tdm-gcc-64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/tdm-gcc-64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../lib\libgomp.a(oacc-profiling.o):(.text+0x83d): undefined reference to `dlerror' Specifics of the installation of gfortran are: gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=C:/tdm-gcc-64/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/13.1.0/lto-wrapper.exe OFFLOAD_TARGET_NAMES=nvptx-none Target: x86_64-w64-mingw32 Configured with: ../configure --prefix=/R/winlibs64ucrt_stage/inst_gcc-13.1.0/share/gcc --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --enable-offload-targets=nvptx-none --with-pkgversion='MinGW-W64 x86_64-msvcrt-posix-seh, built by Brecht Sanders' --with-tune=generic --enable-checking=release --enable-threads=posix --disable-sjlj-exceptions --disable-libunwind-exceptions --disable-serial-configure --disable-bootstrap --enable-host-shared --enable-plugin --disable-default-ssp --disable-rpath --disable-libstdcxx-debug --disable-version-specific-runtime-libs --with-stabs --disable-symvers --enable-languages=c,c++,fortran,lto,objc,obj-c++ --disable-gold --disable-nls --disable-stage1-checking --disable-win32-registry --disable-multilib --enable-ld --enable-libquadmath --enable-libada --enable-libssp --enable-libstdcxx --enable-lto --enable-fully-dynamic-string --enable-libgomp --enable-graphite --enable-mingw-wildcard --enable-libstdcxx-time --enable-libstdcxx-pch --with-mpc=/d/Prog/winlibs64ucrt_stage/custombuilt --with-mpfr=/d/Prog/winlibs64ucrt_stage/custombuilt --with-gmp=/d/Prog/winlibs64ucrt_stage/custombuilt --with-isl=/d/Prog/winlibs64ucrt_stage/custombuilt --enable-libstdcxx-backtrace --enable-install-libiberty --enable-__cxa_atexit --without-included-gettext --with-diagnostics-color=auto --enable-clocale=generic --with-libiconv --with-system-zlib --with-build-sysroot=/R/winlibs64ucrt_stage/gcc-13.1.0/build_mingw/mingw-w64 CFLAGS='-I/d/Prog/winlibs64ucrt_stage/custombuilt/include/libdl-win32 -Wno-int-conversion' CXXFLAGS=-Wno-int-conversion LDFLAGS='-pthread -Wl,--dynamicbase -Wl,--high-entropy-va -Wl,--nxcompat -Wl,--tsaware' Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.1.0 (MinGW-W64 x86_64-msvcrt-posix-seh, built by Brecht Sanders)
[Bug fortran/109865] different results when routine moved inside the contains statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 GARY.WHITE at ColoState dot edu changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #16 from GARY.WHITE at ColoState dot edu --- I resolved the issue. The parameter ir was declared intent(out) in subroutine mc11ad, but there was a check in an if statement to see if ir == 0, meaning ir was defined on input. This check followed code that set ir when n == 1, and this was never executed when the code did not produce correct answers. Anyway, changing intent(out) to intent(in out) resolved the -O3 optimization issue and the code works as expected. I guess its too much to expect that the compiler would detect that a parameter was actually being access before being set if the parameter is declared intent(out) only.
[Bug fortran/109865] different results when routine moved inside the contains statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 --- Comment #14 from GARY.WHITE at ColoState dot edu --- Clarification on the last post. I'm compiling everything with -O3, except va09ad.f90. If va09ad.f90 is compiled with -O3, you get the bug. If va09ad.f90 is compiled with -O0, the code produces correct answers. Since LAPACK is a common library, you should be able to duplicate the bug with little difficulty by changing the makefile.
[Bug fortran/109865] different results when routine moved inside the contains statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 --- Comment #12 from GARY.WHITE at ColoState dot edu --- I just checked, and the bug occurs with the LAPACK routines instead of LinPack. So "make type=markLAPACK" will generate markLAPACK that will fail with -O3, but work with -O0. --- Comment #13 from GARY.WHITE at ColoState dot edu --- I just checked, and the bug occurs with the LAPACK routines instead of LinPack. So "make type=markLAPACK" will generate markLAPACK that will fail with -O3, but work with -O0.
[Bug fortran/109865] different results when routine moved inside the contains statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 --- Comment #12 from GARY.WHITE at ColoState dot edu --- I just checked, and the bug occurs with the LAPACK routines instead of LinPack. So "make type=markLAPACK" will generate markLAPACK that will fail with -O3, but work with -O0. --- Comment #13 from GARY.WHITE at ColoState dot edu --- I just checked, and the bug occurs with the LAPACK routines instead of LinPack. So "make type=markLAPACK" will generate markLAPACK that will fail with -O3, but work with -O0.
[Bug fortran/109865] different results when routine moved inside the contains statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 --- Comment #11 from GARY.WHITE at ColoState dot edu --- I've never used valgrind -- what would it do? The problem isn't that the code is wrong -- otherwise -O0 would not generate correct results. The compiler is optimizing something incorrectly with -O1 that causes the numerical optimizer, i.e., va09ad code, to not work correctly. I included 2 files in the zip file that show incorrect and correct results -- basically va09ad just doesn't go anywhere, not finding an optimum after running to the maximum number of function calls. It's not blowing up or aborting -- just producing wrong answers. I am willing to walk you through where the critical code is located, but need to know more of what system you're working on and how I can help.
[Bug fortran/109865] different results when routine moved inside the contains statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 --- Comment #9 from GARY.WHITE at ColoState dot edu --- Another clue. I'm seeing the same bug in gfortran-13, except that I have to use -O0 for both cases of mc11ad.f90 in or out of the contains statement. Similarly, if I put the set of va09ad.f90 routines in a module, I have to use -O0 to get correct answers. -O3 causes a bug with va09ad.f90 in a module as well.
[Bug fortran/109865] different results when routine moved inside the contains statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 --- Comment #8 from GARY.WHITE at ColoState dot edu --- I just tried to send you a zip file with all the code and instructions (see below), but it is over 6Mb in size, and was rejected. Where can I put it that you can access it? I have put the file test_case.zip on my Onedrive account at https://1drv.ms/u/s!Ak8uiHyJ2kc2iqIPdvZKUGDak3CZ9A?e=yFcRJZ Gary Gary C. White, CWB(r) Professor Emeritus Department of Fish, Wildlife, and Conservation Biology 10 Wagar Colorado State University Fort Collins, CO 80523 (515)450-2768 Mobile gary.wh...@colostate.edu https://sites.warnercnr.colostate.edu/gwhite/ he/him/his See where we are! "Leadership is a privilege to better the lives of others. It is not an opportunity to satisfy personal greed." Mwai Kibaki -Original Message- From: White,Gary Sent: Monday, May 15, 2023 3:53 PM To: kargl at gcc dot gnu.org Subject: RE: [Bug fortran/109865] different results when routine moved inside the contains statement Sorry I can't simplify this down to a nice compact piece of code, but ... In the attached test_case.zip file are all the *.f90 files, makefile, and some library files that work on ubuntu with gfortran-12. I can provide Windows libraries if that is easier. Create the executable file, mark64, by a simple make or make type=mark64 Right now, the makefile does not have an -O0 on the va09ad.f90 compile line. As we found out, over-riding -O3 on va09ad.f90 compilation produces correct code. Execute the test case with ./mark64 i=dipper.inp o=dipper.out I've included 2 output files, dipper_correct.out and dipper_incorrect.out so you can see what correct and incorrect outputs look like. Hopefully this all works out. Thanks. Gary Gary C. White, CWB(r) Professor Emeritus Department of Fish, Wildlife, and Conservation Biology 10 Wagar Colorado State University Fort Collins, CO 80523 (515)450-2768 Mobile gary.wh...@colostate.edu https://sites.warnercnr.colostate.edu/gwhite/ he/him/his See where we are! "Leadership is a privilege to better the lives of others. It is not an opportunity to satisfy personal greed." Mwai Kibaki -Original Message- From: kargl at gcc dot gnu.org Sent: Monday, May 15, 2023 2:42 PM To: White,Gary Subject: [Bug fortran/109865] different results when routine moved inside the contains statement ** Caution: EXTERNAL Sender ** https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 --- Comment #6 from kargl at gcc dot gnu.org --- (In reply to gary.wh...@colostate.edu from comment #5) > (In reply to Steve Kargl from comment #4) > > I assume you've also tried with -fcheck=all. > > Your report states you're using og12. If it supports the sanitizer, > > can you add -fsanitize=undefined to the options? > > -fcheck=all does not generate any warnings. > -fsanitize=undefined returns pages when loading of: > > undefined reference to `__ubsan_handle_pointer_overflow' > > which makes no sense to me Hmmm. Thanks for checking. Either your version of gcc is not built with --enable-libsanitizer or gfortran cannot find the library. At this point, it seems we're going to need a complete testcase. -- You are receiving this mail because: You reported the bug.
[Bug fortran/109865] different results when routine moved inside the contains statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 --- Comment #7 from GARY.WHITE at ColoState dot edu --- Sorry I can't simplify this down to a nice compact piece of code, but ... In the attached test_case.zip file are all the *.f90 files, makefile, and some library files that work on ubuntu with gfortran-12. I can provide Windows libraries if that is easier. Create the executable file, mark64, by a simple make or make type=mark64 Right now, the makefile does not have an -O0 on the va09ad.f90 compile line. As we found out, over-riding -O3 on va09ad.f90 compilation produces correct code. Execute the test case with ./mark64 i=dipper.inp o=dipper.out I've included 2 output files, dipper_correct.out and dipper_incorrect.out so you can see what correct and incorrect outputs look like. Hopefully this all works out. Thanks. Gary Gary C. White, CWB(r) Professor Emeritus Department of Fish, Wildlife, and Conservation Biology 10 Wagar Colorado State University Fort Collins, CO 80523 (515)450-2768 Mobile gary.wh...@colostate.edu https://sites.warnercnr.colostate.edu/gwhite/ he/him/his See where we are! "Leadership is a privilege to better the lives of others. It is not an opportunity to satisfy personal greed." Mwai Kibaki -Original Message- From: kargl at gcc dot gnu.org Sent: Monday, May 15, 2023 2:42 PM To: White,Gary Subject: [Bug fortran/109865] different results when routine moved inside the contains statement ** Caution: EXTERNAL Sender ** https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 --- Comment #6 from kargl at gcc dot gnu.org --- (In reply to gary.wh...@colostate.edu from comment #5) > (In reply to Steve Kargl from comment #4) > > I assume you've also tried with -fcheck=all. > > Your report states you're using og12. If it supports the sanitizer, > > can you add -fsanitize=undefined to the options? > > -fcheck=all does not generate any warnings. > -fsanitize=undefined returns pages when loading of: > > undefined reference to `__ubsan_handle_pointer_overflow' > > which makes no sense to me Hmmm. Thanks for checking. Either your version of gcc is not built with --enable-libsanitizer or gfortran cannot find the library. At this point, it seems we're going to need a complete testcase. -- You are receiving this mail because: You reported the bug.
[Bug fortran/109865] different results when routine moved inside the contains statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 --- Comment #5 from GARY.WHITE at ColoState dot edu --- (In reply to Steve Kargl from comment #4) > On Mon, May 15, 2023 at 07:11:17PM +, Gary.White at ColoState dot edu > wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 > > (In reply to kargl from comment #2) > > > (In reply to gary.wh...@colostate.edu from comment #0) > > > > > > > Options being used to compile the code: > > > > COPTIONS = -cpp -std=f2018 -c -D ieee -D dbleprecision -m64 > > > > -fsignaling-nans -ffpe-summary='invalid','zero','overflow','underflow' > > > > -O3 > > > > -funroll-loops -ffast-math > > > > > > What happens if you remove -ffast-math and use -O0 or -O1? > > > > -O0 generates correct code with or without -ffastmath, -O1 does not generate > > correct code. > > I assume you've also tried with -fcheck=all. > Your report states you're using og12. If > it supports the sanitizer, can you add > -fsanitize=undefined to the options? -fcheck=all does not generate any warnings. -fsanitize=undefined returns pages when loading of: undefined reference to `__ubsan_handle_pointer_overflow' which makes no sense to me
[Bug fortran/109865] different results when routine moved inside the contains statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 --- Comment #3 from GARY.WHITE at ColoState dot edu --- (In reply to kargl from comment #2) > (In reply to gary.wh...@colostate.edu from comment #0) > > Created attachment 55087 [details] > > set of subroutines where moving mc11ad inside the contains statement > > produces incorrect results > > > > In the following code, when the subroutine mc11ad is moved inside the > > contains statement, incorrect results are produced. > > Produce wrong results is meaningless as you haven't told what the > correct results and wrong results are. A difference in the 7 > decimal place for REAL may be entirely possible due to floating > point round-off > > > Options being used to compile the code: > > COPTIONS = -cpp -std=f2018 -c -D ieee -D dbleprecision -m64 > > -fsignaling-nans -ffpe-summary='invalid','zero','overflow','underflow' -O3 > > -funroll-loops -ffast-math > > What happens if you remove -ffast-math and use -O0 or -O1? -O0 generates correct code with or without -ffastmath, -O1 does not generate correct code.
[Bug fortran/109865] New: different results when routine moved inside the contains statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 Bug ID: 109865 Summary: different results when routine moved inside the contains statement Product: gcc Version: og12 (devel/omp/gcc-12) Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Gary.White at ColoState dot edu Target Milestone: --- Created attachment 55087 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55087=edit set of subroutines where moving mc11ad inside the contains statement produces incorrect results In the following code, when the subroutine mc11ad is moved inside the contains statement, incorrect results are produced. Works fine outside the contains statement as provided here. This subroutine is only called from the main subroutine va09ad, nowhere else. Other clues are that if I put this routine inside a module, incorrect results are produced. This set of routines is used in a much larger code, so I'm not able to isolate the problem down to a simple example. I have verified that this is a gfortran bug because the code produces correct results with the Intel compiler with mc11ad inside or outside the contains statement. gfortran compiler I'm using: Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 12.1.0-2ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-12 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-12-sZcx2y/gcc-12-12.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-sZcx2y/gcc-12-12.1.0/debian/tmp-gcn/usr --enable-offload-defaulted --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.1.0 (Ubuntu 12.1.0-2ubuntu1~22.04) Options being used to compile the code: COPTIONS = -cpp -std=f2018 -c -D ieee -D dbleprecision -m64 -fsignaling-nans -ffpe-summary='invalid','zero','overflow','underflow' -O3 -funroll-loops -ffast-math subroutine va09ad(functn,n,x,f,g,h,w,dfn,eps2,mode,maxfn,iprint,iexit,itn,parm,beta,design) use status_module, only : int32, wp, sysout, syscrn, nlogit, ncovs_nlbetas, ncovs, & zero, one, two, modnam, num_to_str, outtext implicit none integer(kind=int32), intent(in) :: n, mode, maxfn, iprint integer(kind=int32), intent(out) :: iexit, itn real(kind=wp), intent(in) :: dfn, eps2(n) real(kind=wp), intent(out) :: x(n),g(n),h(n*(n+1)/2),w(n*3), f real(kind=wp), intent(out) :: parm(nlogit), beta(ncovs_nlbetas), design(nlogit,ncovs) external functn integer(kind=int32) ig, igg, is, ir, mk, ij, i, ifn, icon real(kind=wp) alphalocal, z, gs, gys, df, gs0, tot, fy, zz, dgs, sigma, epsln character(len=:), allocatable :: frmt interface subroutine functn(nparm, xbeta, xloglk, g, parm, beta, design) use status_module use data_module implicit none integer(kind=int32), intent(in) :: nparm real(kind=wp), intent(in out) :: xbeta(nparm), g(nparm), parm(nlogit), beta(ncovs_nlbetas), design(nlogit,ncovs) real(kind=wp), intent(out) :: xloglk end subroutine functn end interface ! This interface causes problems with prcisub.f90, ! just as does including mc11ad inside the contains statement. !interface ! subroutine mc11ad(a,n,z,sigma,w,ir,mk,eps2) ! use status_module, only : wp, int32, zero, one ! implicit none ! integer(kind=int32), intent(in) :: n, mk ! integer(kind=int32), intent(out) :: ir ! real(kind=wp), intent(in out) :: a(n*(n+1)/2),z(n),w(n*3) ! real(kind=wp), intent(in) :: eps2 ! real(kind=wp),
[Bug libfortran/106509] executable hangs if -static is included in compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106509 --- Comment #4 from GARY.WHITE at ColoState dot edu --- Somewhat resolved -- does not happen with UCRT, only with MSVCRT.
[Bug libfortran/106509] executable hangs if -static is included in compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106509 --- Comment #2 from GARY.WHITE at ColoState dot edu --- (In reply to Andrew Pinski from comment #1) > -static and glibc and pthreads (which openmp uses) has always been > problematic. Why do you want to use -static? Because I'm distributing a large code to users that do not have gfortran available.
[Bug fortran/106509] New: executable hangs if -static is included in compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106509 Bug ID: 106509 Summary: executable hangs if -static is included in compile Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Gary.White at ColoState dot edu Target Milestone: --- Created attachment 53398 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53398=edit gfortran code to reproduce this bug When the attached code is compiled as: gfortran bug.f90 -fopenmp -o bug.exe -static the executable hangs even with a STOP message shown. If -static is removed, the code executes. Also, if the number of threads specified is equal to the number available, the code executes with -static . But the combination of -static and fewer threads specified than available on the machine causes the code to hang. This bug only occurs with gfortran 12.1. The identical code compiled with gfortran 11 does not hang.
