[Bug fortran/109865] different results when routine moved inside the contains statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 Andrew Pinski changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #17 from Andrew Pinski --- Since there is no GCC bug changing the issue status to invalid.
[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 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #15 from Jerry DeLisle --- (In reply to gary.wh...@colostate.edu from comment #11) > I've never used valgrind -- what would it do? > valgrind tracks and checks memory allocations during execution and can spot where things, such as pointers that go astray. This sometimes happens with optimization bugs. >From the man page. It has many tools and is very useful. Valgrind is a flexible program for debugging and profiling Linux executables. It consists of a core, which provides a synthetic CPU in software, and a series of debugging and profiling tools. The architecture is modular, so that new tools can be created easily and without disturbing the existing structure.
[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 #10 from Steve Kargl --- On Tue, May 16, 2023 at 03:55:51PM +, Gary.White at ColoState dot edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 > > --- Comment #9 from GARY.WHITE at ColoState dot edu 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. > Can you use valgrind? I got the zip file, but reducing that will be a pain. First, the included lapack, blas, and linpack archives are useless to me. Second, there is just way too much code with a complete lack of familiarity to try to reduce this. I suspect you may have to go old school with 'print *' debugging in the problematic subroutine.
[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 #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.
[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 #4 from Steve Kargl --- 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?
[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] different results when routine moved inside the contains statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- (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?
[Bug fortran/109865] different results when routine moved inside the contains statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2023-05-15 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Please provide a compilable, self-contained testcase. I get: varmat.F90:3:11: 3 | use status_module | 1 Fatal Error: Cannot open module file 'status_module.mod' for reading at (1): No such file or directory compilation terminated.
