[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #61 from Jürgen Reuter --- (In reply to Thomas Koenig from comment #60) > r242780 works. > > With both r243586 and r244391, plus the patch for r245191 > applied, I got numerous failures in the test suite. > > Apparently, something else was wrong for some time, which > blocks the attempt at bisection for that particular error > in that range. There was also this PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79344 fixed in r245194. You don't apply any -fcheck= flags, right?
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #60 from Thomas Koenig --- r242780 works. With both r243586 and r244391, plus the patch for r245191 applied, I got numerous failures in the test suite. Apparently, something else was wrong for some time, which blocks the attempt at bisection for that particular error in that range.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #59 from Jürgen Reuter --- (In reply to Thomas Koenig from comment #58) > (In reply to Thomas Koenig from comment #57) > > And here comes the first problem... > > > > Running with rev 243584 (as a bisection) results in > > very many failed tests like > > *** Error in `/home/ig25/Downloads/whizard-2.4.1/src/.libs/whizard': double > free or corruption (!prev): 0x01e97360 *** > === Backtrace: = > /lib64/libc.so.6(+0x7383b)[0x7f05eded383b] > /lib64/libc.so.6(+0x79dee)[0x7f05eded9dee] > /lib64/libc.so.6(+0x7a5fe)[0x7f05ededa5fe] > /home/ig25/Downloads/whizard-2.4.1/src/.libs/libwhizard.so. > 1(__models_MOD___final_models_Model_t+0x23a)[0x7f05f00121ca] > /home/ig25/Downloads/whizard-2.4.1/src/.libs/libwhizard.so. > 1(__process_config_MOD_process_config_data_final+0x69)[0x7f05f005fb89] > /home/ig25/Downloads/whizard-2.4.1/src/.libs/libwhizard.so. > 1(__process_MOD_process_final+0x4e)[0x7f05f007d44e] > /home/ig25/Downloads/whizard-2.4.1/src/.libs/libwhizard.so. > 1(__process_stacks_MOD_process_stack_clear+0xbd)[0x7f05f00bee2d] > /home/ig25/Downloads/whizard-2.4.1/src/.libs/libwhizard.so. > 1(__process_stacks_MOD_process_stack_final+0xb)[0x7f05f00b6dab] > /home/ig25/Downloads/whizard-2.4.1/src/.libs/libwhizard.so. > 1(__rt_data_MOD_rt_data_global_final+0x2a)[0x7f05efca80fa] > /home/ig25/Downloads/whizard-2.4.1/src/.libs/libwhizard.so. > 1(__whizard_MOD_whizard_final+0x2a)[0x7f05efd41c1a] > /home/ig25/Downloads/whizard-2.4.1/src/whizard-core/.libs/libwhizard_main.so. > 0(+0x412f)[0x7f05f215d12f] > /home/ig25/Downloads/whizard-2.4.1/src/whizard-core/.libs/libwhizard_main.so. > 0(main+0x1f)[0x7f05f215b9bf] > /lib64/libc.so.6(__libc_start_main+0xf1)[0x7f05ede80541] > /home/ig25/Downloads/whizard-2.4.1/src/.libs/whizard[0x4005da] > > Hmm... seems like I need to apply revision 245191 on top. > We'll see what that does. Yep, that was https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79230 introduced in r243480.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #58 from Thomas Koenig --- (In reply to Thomas Koenig from comment #57) > And here comes the first problem... > > Running with rev 243584 (as a bisection) results in > very many failed tests like *** Error in `/home/ig25/Downloads/whizard-2.4.1/src/.libs/whizard': double free or corruption (!prev): 0x01e97360 *** === Backtrace: = /lib64/libc.so.6(+0x7383b)[0x7f05eded383b] /lib64/libc.so.6(+0x79dee)[0x7f05eded9dee] /lib64/libc.so.6(+0x7a5fe)[0x7f05ededa5fe] /home/ig25/Downloads/whizard-2.4.1/src/.libs/libwhizard.so.1(__models_MOD___final_models_Model_t+0x23a)[0x7f05f00121ca] /home/ig25/Downloads/whizard-2.4.1/src/.libs/libwhizard.so.1(__process_config_MOD_process_config_data_final+0x69)[0x7f05f005fb89] /home/ig25/Downloads/whizard-2.4.1/src/.libs/libwhizard.so.1(__process_MOD_process_final+0x4e)[0x7f05f007d44e] /home/ig25/Downloads/whizard-2.4.1/src/.libs/libwhizard.so.1(__process_stacks_MOD_process_stack_clear+0xbd)[0x7f05f00bee2d] /home/ig25/Downloads/whizard-2.4.1/src/.libs/libwhizard.so.1(__process_stacks_MOD_process_stack_final+0xb)[0x7f05f00b6dab] /home/ig25/Downloads/whizard-2.4.1/src/.libs/libwhizard.so.1(__rt_data_MOD_rt_data_global_final+0x2a)[0x7f05efca80fa] /home/ig25/Downloads/whizard-2.4.1/src/.libs/libwhizard.so.1(__whizard_MOD_whizard_final+0x2a)[0x7f05efd41c1a] /home/ig25/Downloads/whizard-2.4.1/src/whizard-core/.libs/libwhizard_main.so.0(+0x412f)[0x7f05f215d12f] /home/ig25/Downloads/whizard-2.4.1/src/whizard-core/.libs/libwhizard_main.so.0(main+0x1f)[0x7f05f215b9bf] /lib64/libc.so.6(__libc_start_main+0xf1)[0x7f05ede80541] /home/ig25/Downloads/whizard-2.4.1/src/.libs/whizard[0x4005da] Hmm... seems like I need to apply revision 245191 on top. We'll see what that does.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #57 from Thomas Koenig --- And here comes the first problem... Running with rev 243584 (as a bisection) results in very many failed tests like
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #56 from Jürgen Reuter --- (In reply to Thomas Koenig from comment #55) > (In reply to Jürgen Reuter from comment #52) > > I tried again to make a more reduced test case, but I couldn't really > > separate it from library structure of our code. Do you think you can work > > with the given test case? > > What I can (personally) do is to try and find the offending > revision by bisection. It should then be doable (hopefully by somebody > else) to find any differences due to that particular revision > by examining differences in tree and RTL dumps. > > This will take some time, though. Sure, take your time. As we have a workaround there is no panic on our side. In any case, the problem only appeared for using fp-80 as kind parameters for floats which is not the default application.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #55 from Thomas Koenig --- (In reply to Jürgen Reuter from comment #52) > I tried again to make a more reduced test case, but I couldn't really > separate it from library structure of our code. Do you think you can work > with the given test case? What I can (personally) do is to try and find the offending revision by bisection. It should then be doable (hopefully by somebody else) to find any differences due to that particular revision by examining differences in tree and RTL dumps. This will take some time, though.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #54 from Jürgen Reuter --- (In reply to Thomas Koenig from comment #53) > (In reply to Jürgen Reuter from comment #51) > > (In reply to Thomas Koenig from comment #50) > > > (In reply to Jürgen Reuter from comment #48) > > > > (In reply to Thomas Koenig from comment #47) > > > > > I'll try some bisection. > > > > > > > > Did you get the full tarball running on an x86_64? > > > > > > Yes, at least up to the point where I could "make check". > > > > > > I would have gone faster if "make -j4" worked to compile > > > the package in parallel :-) > > > > Strange. We always do `make -j4`. What went wrong? > > Well, "make -j4" worked, but the speedup due to parallel > processing was not big, around 29 min of CPU time for > 22 min of wall clock time: > > real22m21.054s > user28m7.053s > sys 0m52.747s I see. This is indeed true, but is IMHO the price to pay for OO code with many interdependencies. Up to now we refrained from using submodules.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #53 from Thomas Koenig --- (In reply to Jürgen Reuter from comment #51) > (In reply to Thomas Koenig from comment #50) > > (In reply to Jürgen Reuter from comment #48) > > > (In reply to Thomas Koenig from comment #47) > > > > I'll try some bisection. > > > > > > Did you get the full tarball running on an x86_64? > > > > Yes, at least up to the point where I could "make check". > > > > I would have gone faster if "make -j4" worked to compile > > the package in parallel :-) > > Strange. We always do `make -j4`. What went wrong? Well, "make -j4" worked, but the speedup due to parallel processing was not big, around 29 min of CPU time for 22 min of wall clock time: real22m21.054s user28m7.053s sys 0m52.747s
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #52 from Jürgen Reuter --- I tried again to make a more reduced test case, but I couldn't really separate it from library structure of our code. Do you think you can work with the given test case?
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #51 from Jürgen Reuter --- (In reply to Thomas Koenig from comment #50) > (In reply to Jürgen Reuter from comment #48) > > (In reply to Thomas Koenig from comment #47) > > > I'll try some bisection. > > > > Did you get the full tarball running on an x86_64? > > Yes, at least up to the point where I could "make check". > > I would have gone faster if "make -j4" worked to compile > the package in parallel :-) Strange. We always do `make -j4`. What went wrong?
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #50 from Thomas Koenig --- (In reply to Jürgen Reuter from comment #48) > (In reply to Thomas Koenig from comment #47) > > I'll try some bisection. > > Did you get the full tarball running on an x86_64? Yes, at least up to the point where I could "make check". I would have gone faster if "make -j4" worked to compile the package in parallel :-)
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #49 from Thomas Koenig --- (In reply to Bijan Chokoufe from comment #39) > Configure fails when I set FCFLAGS='-m32' with > ** > configure: error: Fortran compiler does not support get_command_argument; > configure aborted. > configure: error: > ** Can you compile a simple test program with -m32? You may have to recompile gcc trunk for that; do not specify --disable-multilib.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #48 from Jürgen Reuter --- (In reply to Thomas Koenig from comment #47) > I'll try some bisection. Did you get the full tarball running on an x86_64?
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #47 from Thomas Koenig --- I'll try some bisection.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #46 from Thomas Koenig --- gcc version 7.0.1 20170227 (experimental) (GCC) also fails.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #45 from Jürgen Reuter --- Looking into my backups, it seems that the revision 241975 from Nov 8, 2016 was still working without the `volatile` hack. Then I upgraded in early February to revision 245197 where the problem is already present. Unfortunately I cannot narrow it down any further. Any smaller test case is incredibly difficult to produce for us.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #44 from Bijan Chokoufe --- Created attachment 41222 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41222=edit Diff of generalized assembly using extended precision with and without volatile
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #43 from Bijan Chokoufe --- I actually made the same mistake when generating the diffs. I attach the correct diff when --with-precision=extended is given to configure. Similar contents though, as far as I can judge. Strangely, the code without volatile is overall larger: -rw-r--r-- 1 root root 1456592 Apr 18 14:43 shower_core.s -rw-r--r-- 1 root root 1450362 Apr 18 14:20 shower_core_volatile.s
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #42 from Thomas Koenig --- Using ./configure --with-precision=extended results in checking whether gfortran supports c_float128 (a gfortran extension)... yes checking the requested floating point precision... extended configure: error: *** configure: error: the requested default real kind 'extended' is not available in this environment configure: error: ***
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #41 from Thomas Koenig --- Created attachment 41221 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41221=edit Config log for PowerPC Here's the config.log for PowerPC.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #40 from Dominique d'Humieres --- > You have to > > ./configure --with-precision=extended I don't think this works on powerpc: no 80-bit fp.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #39 from Bijan Chokoufe --- (In reply to Thomas Koenig from comment #38) > (In reply to Bijan Chokoufe from comment #37) > > Concerning your PowerPC compilation: Have you set FCLAGS yourself > > No, I didn't.; I just ran "./configure" and "make -j16". > This is why I suspect a target issue. Of course, it could also > be that there are different inlining heuristics on PowerPC. > You have to ./configure --with-precision=extended to reproduce the FAIL. Also add the config.log so we can exclude that any environment variables are influencing the configure. In principle, it would be not too surprising if you can't reproduce it on PowerPC as it also does not happen when -O0 is used and I would assume that optimizations for different architectures are different. Configure fails when I set FCFLAGS='-m32' with ** configure: error: Fortran compiler does not support get_command_argument; configure aborted. configure: error: **
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #38 from Thomas Koenig --- (In reply to Bijan Chokoufe from comment #37) > (In reply to Thomas Koenig from comment #35) > > > [tkoenig@gcc1-power7 shower]$ pwd > > /home/tkoenig/whizard-2.4.1/src/shower > > [tkoenig@gcc1-power7 shower]$ grep -i volatile *.f90 > > [tkoenig@gcc1-power7 shower]$ > > > > Did you run a diff on the generated assembly with and without > > the VOLATILE statement? You can use the -save-temps option for that. > > I generated the .s files with -save-temps with and without volatile > attributes. The diff is attached. I can say the instructions are different > but that's about it. I looked at the diffs, but for me also, nothing stands out. > Concerning your PowerPC compilation: Have you set FCLAGS yourself No, I didn't.; I just ran "./configure" and "make -j16". This is why I suspect a target issue. Of course, it could also be that there are different inlining heuristics on PowerPC. You could add "-m32" to the compiler flags; this would build a 32-bit binary. Obviously, you would have to rebuild the whole source tree. What does that do? Additionally, if it is not possible to generate a smaller failing test case, the next step would be to see which revision failed first. What is the latest version of the compiler that still works? Specifically, did you ever try this with an earlier version of gcc 7 trunk?
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #37 from Bijan Chokoufe --- (In reply to Thomas Koenig from comment #35) > [tkoenig@gcc1-power7 shower]$ pwd > /home/tkoenig/whizard-2.4.1/src/shower > [tkoenig@gcc1-power7 shower]$ grep -i volatile *.f90 > [tkoenig@gcc1-power7 shower]$ > > Did you run a diff on the generated assembly with and without > the VOLATILE statement? You can use the -save-temps option for that. I generated the .s files with -save-temps with and without volatile attributes. The diff is attached. I can say the instructions are different but that's about it. Concerning your PowerPC compilation: Have you set FCLAGS yourself and if so have you included -O2? That other tests are failing is not too suprising and doesn't have to be a major problem as the test suite is not numerically waterproof (and partly can't be). The issue with memcpy looks like a bug though.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #36 from Bijan Chokoufe --- Created attachment 41219 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41219=edit Diff of generalized assembly with and without volatile
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #35 from Thomas Koenig --- (In reply to Bijan Chokoufe from comment #34) > Does mlm_matching_isr.run also work if you remove all uses of volatile in > src/shower/*f90? Yes, the test was with the original tarball mentioned in comment#1. [tkoenig@gcc1-power7 shower]$ pwd /home/tkoenig/whizard-2.4.1/src/shower [tkoenig@gcc1-power7 shower]$ grep -i volatile *.f90 [tkoenig@gcc1-power7 shower]$ Did you run a diff on the generated assembly with and without the VOLATILE statement? You can use the -save-temps option for that.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #34 from Bijan Chokoufe --- (In reply to Thomas Koenig from comment #32) > Running your testsuite on powerpc64-unknown-linux-gnu > with a current trunk and "make -k check" gets me > > PASS: mlm_matching_isr.run > > but also a few more failures: > > FAIL: bloch_vectors.run > FAIL: processes.run > FAIL: cascades.run > FAIL: sf_isr.run > > so I suspect a target issue. > > Could you tell me how just to run a single testcase? Does mlm_matching_isr.run also work if you remove all uses of volatile in src/shower/*f90?
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #33 from Thomas Koenig --- > Could you tell me how just to run a single testcase? Well, I figured that one out. Quite interesting, a different error with valgrind: | Events: event normalization mode '1' ==49974== Source and destination overlap in memcpy(0x7f3dae0, 0x7f3dae0, 176) ==49974==at 0x408B1A8: memcpy (in /usr/lib64/valgrind/vgpreload_memcheck-ppc64-linux.so) ==49974==by 0x441E1A7: __shower_core_MOD_shower_converttopythia (shower_core.f90:4010) ==49974==by 0x440C38B: __shower_core_MOD_shower_make_particle_set (shower_core.f90:451) ==49974==by 0x43E915B: __shower_MOD_evt_shower_make_particle_set (shower.f90:258) ==49974==by 0x43F49C3: __events_MOD_event_evaluate_transforms (events.f90:524) ==49974==by 0x43F3843: __events_MOD_event_generate (events.f90:751) ==49974==by 0x43739EF: __simulations_MOD_simulation_generate (simulations.f90:1639) ==49974==by 0x43992F7: __commands_MOD_cmd_simulate_execute (commands.f90:4501) ==49974==by 0x437CA6B: __commands_MOD_command_list_execute (commands.f90:5835) ==49974==by 0x43BD56B: __whizard_MOD_whizard_process_stream (whizard.f90:348) ==49974==by 0x43BCBF7: __whizard_MOD_whizard_process_file (whizard.f90:323) ==49974==by 0x40B547B: MAIN__ (main.f90:415) ==49974== The code there is temp_parton = final_partons(i + 1) final_partons(i + 1) = final_partons(j) final_partons(j) = temp_parton I have no idea if this is intended or not (if i + 1 is supposed to be identical to j) , but it points to a doubtful use of memcpy with gfortran which I will open a separate PR about.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #32 from Thomas Koenig --- Running your testsuite on powerpc64-unknown-linux-gnu with a current trunk and "make -k check" gets me PASS: mlm_matching_isr.run but also a few more failures: FAIL: bloch_vectors.run FAIL: processes.run FAIL: cascades.run FAIL: sf_isr.run so I suspect a target issue. Could you tell me how just to run a single testcase?
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #31 from Thomas Koenig --- (In reply to Bijan Chokoufe from comment #30) `bzip2 -d diff.bz2`) as I have no idea what to look for: > https://cloud.bijancn.de/index.php/s/ta2XMIVWhTUGAvX Thanks. I looked, but didn't find anything... I'll see if I get it to compile and run, maybe also on a powerpc machine.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #30 from Bijan Chokoufe --- > Could you maybe do the following: > > - Use your normal sources > > - Change the compilation options to add -fdump-tree-all to the relevant > file > > - Copy all the generated xxx.f90.whatever files (the tree dumps) > to a different directory > > - Change intent(in) to volatile > > - Rerun the compilation > > and then run diff on the tree dump files to the original ones? > If you see anything suspicious in the diffs, that might point > to something. Maybe you could also attach the diffs, so somebody > else could take a look at it. Did that, specifically I configured with FCFLAGS='-fdump-tree-all -O2 -g'. Then I copied `.libs` to `with_volatile` (our trunk currently has the volatile workaround per default), removed the `volatile` attribute and compiled again. Here is the diff between `.libs` and `with_volatile` (unpack with `bzip2 -d diff.bz2`) as I have no idea what to look for: https://cloud.bijancn.de/index.php/s/ta2XMIVWhTUGAvX
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #29 from Thomas Koenig --- (In reply to Jürgen Reuter from comment #24) > Actually, the volatile attribute conflicts with the intent(in) of the final > variable. But making the function result variable 'integral' volatile, does > the job. Thanks for the suggestion. And sorry again for not producing a > smaller case. Could you maybe do the following: - Use your normal sources - Change the compilation options to add -fdump-tree-all to the relevant file - Copy all the generated xxx.f90.whatever files (the tree dumps) to a different directory - Change intent(in) to volatile - Rerun the compilation and then run diff on the tree dump files to the original ones? If you see anything suspicious in the diffs, that might point to something. Maybe you could also attach the diffs, so somebody else could take a look at it.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #28 from Jakub Jelinek --- (In reply to Jürgen Reuter from comment #27) > Well, the valgrind output actually exactly that the comparison is optimized > away. > I actually would have to regenerate all the debug output, but the point is > that for the first appearance in the random seed chain, the code must not > run into the second part of the if clause: > else if (prt%child1%is_quark ()) then > !!! 1: q->qg > prt%type = prt%child1%type > prt%child2%type = GLUON > prt%child2%t = abs(prt%t) > call integral_over_z_part_isr & > (shower, prt,otherprt, shat, minz, maxz, integral, final) > if (integral > final) then > return > else > !!! 2: g->qqbar > prt%type = GLUON > prt%child2%type = -prt%child1%type > prt%child2%t = abs(prt%t) > call integral_over_z_part_isr & > (shower, prt,otherprt, shat, minz, maxz, integral, final) > end if > end if > so the return should be executed. We checked explicitly that the condition > integral > final was fulfilled, for the value of final as calculated inside > the routine integral_over_z_part_isr, but then the if clause did not > correctly execute the return, and the reason seemed to be that the value of > integral was not available anymore. It is of course possible that in the debugger you see some variables as no longer available, especially if they aren't used afterwards. But, as integral_over_z_part_isr is not inlined into this function (while the containing function is inlined ultimately into shower_generate_next_isr_branching, if you add a breakpoint on the call integral_over_z_part_isr insn and on the insn immediately after it and on the call you stepi into the function, as both final and integral are passed by reference, you should see the arguments (i.e. address where the final long double value is stored and address into which integral will be stored). Then immediately after the call returns, you can again inspect both, and on the fucomi instruction see if it compares the values you expect, and then where it branches afterwards. As the current function is inlined into others, the return doesn't actually mean return from function, but just branching to code that does something from other inlined functions.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #27 from Jürgen Reuter --- Well, the valgrind output actually exactly that the comparison is optimized away. I actually would have to regenerate all the debug output, but the point is that for the first appearance in the random seed chain, the code must not run into the second part of the if clause: else if (prt%child1%is_quark ()) then !!! 1: q->qg prt%type = prt%child1%type prt%child2%type = GLUON prt%child2%t = abs(prt%t) call integral_over_z_part_isr & (shower, prt,otherprt, shat, minz, maxz, integral, final) if (integral > final) then return else !!! 2: g->qqbar prt%type = GLUON prt%child2%type = -prt%child1%type prt%child2%t = abs(prt%t) call integral_over_z_part_isr & (shower, prt,otherprt, shat, minz, maxz, integral, final) end if end if so the return should be executed. We checked explicitly that the condition integral > final was fulfilled, for the value of final as calculated inside the routine integral_over_z_part_isr, but then the if clause did not correctly execute the return, and the reason seemed to be that the value of integral was not available anymore.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #26 from Jakub Jelinek --- I can see the mlm_matching_isr FAIL with current trunk, but certainly don't see the integral > final comparison being optimized out. 0x757978e1 <__shower_core_MOD_shower_generate_next_isr_branching+4529>: callq 0x7578e160 <__shower_core_MOD_integral_over_z_part_isr> 0x757978e6 <__shower_core_MOD_shower_generate_next_isr_branching+4534>: fldt 0x1f0(%rsp) 0x757978ed <__shower_core_MOD_shower_generate_next_isr_branching+4541>: pop%r10 0x757978ef <__shower_core_MOD_shower_generate_next_isr_branching+4543>: pop%r11 0x757978f1 <__shower_core_MOD_shower_generate_next_isr_branching+4545>: fld%st(0) 0x757978f3 <__shower_core_MOD_shower_generate_next_isr_branching+4547>: fldt 0x40(%rsp) 0x757978f7 <__shower_core_MOD_shower_generate_next_isr_branching+4551>: fxch %st(2) => 0x757978f9 <__shower_core_MOD_shower_generate_next_isr_branching+4553>: fucomi %st(2),%st 0x757978fb <__shower_core_MOD_shower_generate_next_isr_branching+4555>: fstp %st(2) 0x757978fd <__shower_core_MOD_shower_generate_next_isr_branching+4557>: fldt 0x70(%rsp) 0x75797901 <__shower_core_MOD_shower_generate_next_isr_branching+4561>: fldt 0x80(%rsp) 0x75797908 <__shower_core_MOD_shower_generate_next_isr_branching+4568>: ja 0x7579752a <__shower_core_MOD_shower_generate_next_isr_branching+3578> That fucomi is the comparison of integral and final. I have no idea what the code is meant to do and in which occurence of this call + comparison do you expect to see the return part (if I put a breakpoint on this spot, I see more than hundred cases). At least on the first one the final value integral_over_z_part_isr is called with is one of the comparison operands, final is 8.0709805577720652785753130409318601 and integral is 1.2830660500802092213986273722913488e-06 info float R7: Valid 0x40028122bc8264869727 +8.070980557772065279 R6: Valid 0x3febac35d05484382d81 +1.283066050080209221e-06 =>R5: Valid 0x3febac35d05484382d81 +1.283066050080209221e-06 R4: Empty 0xc009d3234afd757eb870 R3: Empty 0x3ffc9d2933f75a096595 R2: Empty 0x4007bfa6d946f18e35f7 R1: Empty 0xc009d32c3121bd4b4150 R0: Empty 0x3ffc9d2933f75a096595 on the fucomi. So, what values of integral or final do you expect the return on?
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #25 from Dominique d'Humieres --- AFAICT the IF is already optimized away at r240458. Note that r240271 cannot use the modules generated by later revisions.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #24 from Jürgen Reuter --- Actually, the volatile attribute conflicts with the intent(in) of the final variable. But making the function result variable 'integral' volatile, does the job. Thanks for the suggestion. And sorry again for not producing a smaller case.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #23 from Steve Kargl --- On Thu, Feb 09, 2017 at 10:42:08AM +, bijan at chokoufe dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 > > --- Comment #19 from Bijan Chokoufe --- > So in the build with '-O2 -g' (default), valgrind tells us > > ==8214== Conditional jump or move depends on uninitialised value(s) > ==8214==at 0x5300201: __shower_core_MOD_shower_generate_next_isr_branching > (shower_core.f90:3089) > ==8214==by 0x5306A90: __shower_core_MOD_shower_generate_emissions > (shower_core.f90:316) > ==8214==by 0x52D3CE6: __shower_MOD_evt_shower_generate_weighted.part.2 > (shower.f90:238) > ==8214==by 0x52B0BBF: __event_transforms_MOD_evt_generate_unweighted > (event_transforms.f90:203) > ==8214==by 0x52DCEA5: __events_MOD_event_evaluate_transforms > (events.f90:520) > ==8214==by 0x52DC247: __events_MOD_event_generate (events.f90:751) > ==8214==by 0x5260A2F: __simulations_MOD_simulation_generate > (simulations.f90:1639) > ==8214==by 0x5285A35: __commands_MOD_cmd_simulate_execute > (commands.f90:4501) > ==8214==by 0x5267A08: __commands_MOD_command_list_execute > (commands.f90:5835) > ==8214==by 0x52A84A5: __whizard_MOD_whizard_process_stream > (whizard.f90:348) > ==8214==by 0x52A7C25: __whizard_MOD_whizard_process_file (whizard.f90:323) > ==8214==by 0x4E3EF61: MAIN__ (main.f90:415) > ==8214== > > which is exactely the problematic point we also identified with print > debugging, mentioned in the description of this ticket. > If you change the declaration for 'final' to real(default), intent(in), volatile :: final do you still have a problem? Hopefully, this will suppress whatever is causing the optimizer to remove the if statement.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #22 from Dominique d'Humieres --- > With make -k you continue irrespective of the fact that some targets could > not have made. Without '-k' 'make check' stops at make[5]: *** No rule to make target `test_omega95.f90', needed by `test_omega95.o'. Stop. > Do you have OCaml installed? This is needed for that test. Yes, The OCaml toplevel, version 4.03.0. > Can you post the test results e.g. for the smtest_1 test? Running script ./smtest_1.run ** ** *** FATAL ERROR: Option '--logfile' needs a value ** ** WHIZARD run aborted. ... With no FILE, read standard input. 1,91d0 < ?openmp_logging = false < ?vis_history = false < ?integration_timer = false < seed = 0 < phs_off_shell = 1 < phs_t_channel = 2 < | Process library 'smtest_1_lib': recorded process 'smtest_1_nnh' ...
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #21 from Jürgen Reuter --- (In reply to Dominique d'Humieres from comment #20) > Is this really a regression? > > I have run 'make check -k' with gfortran 5.4.0, 6.3.0, and a patched trunk > at revision r245279. I see respectively 258, 259, and 199 FAILs, and > mlm_matching_isr is always failing. With make -k you continue irrespective of the fact that some targets could not have made. Do you have OCaml installed? This is needed for that test. Can you post the test results e.g. for the smtest_1 test?
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #20 from Dominique d'Humieres --- Is this really a regression? I have run 'make check -k' with gfortran 5.4.0, 6.3.0, and a patched trunk at revision r245279. I see respectively 258, 259, and 199 FAILs, and mlm_matching_isr is always failing.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #19 from Bijan Chokoufe --- So in the build with '-O2 -g' (default), valgrind tells us ==8214== Conditional jump or move depends on uninitialised value(s) ==8214==at 0x5300201: __shower_core_MOD_shower_generate_next_isr_branching (shower_core.f90:3089) ==8214==by 0x5306A90: __shower_core_MOD_shower_generate_emissions (shower_core.f90:316) ==8214==by 0x52D3CE6: __shower_MOD_evt_shower_generate_weighted.part.2 (shower.f90:238) ==8214==by 0x52B0BBF: __event_transforms_MOD_evt_generate_unweighted (event_transforms.f90:203) ==8214==by 0x52DCEA5: __events_MOD_event_evaluate_transforms (events.f90:520) ==8214==by 0x52DC247: __events_MOD_event_generate (events.f90:751) ==8214==by 0x5260A2F: __simulations_MOD_simulation_generate (simulations.f90:1639) ==8214==by 0x5285A35: __commands_MOD_cmd_simulate_execute (commands.f90:4501) ==8214==by 0x5267A08: __commands_MOD_command_list_execute (commands.f90:5835) ==8214==by 0x52A84A5: __whizard_MOD_whizard_process_stream (whizard.f90:348) ==8214==by 0x52A7C25: __whizard_MOD_whizard_process_file (whizard.f90:323) ==8214==by 0x4E3EF61: MAIN__ (main.f90:415) ==8214== which is exactely the problematic point we also identified with print debugging, mentioned in the description of this ticket. In the build with '-O0 -g', valgrind does not show this error! So it seems as if the call to integral_over_z_part_isr is optimized away although it is needed to set the variables used in the conditional. The variables are declared as intent(inout) therein.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 Bijan Chokoufe changed: What|Removed |Added CC||bijan at chokoufe dot com --- Comment #18 from Bijan Chokoufe --- Let me point out an idiosyncrasy of our configure script. When no FCFLAGS are defined, it automatically puts FCFLAGS='-O2 -g'. When FCFLAGS are defined, those are taken. This means that the disappearance of the problem with FCFLAGS=-Wall or FCFLAGS=-fno-inline is likely due to the removal of -O2. Valgrind runs are underway...
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #17 from Jürgen Reuter --- (In reply to Jerry DeLisle from comment #16) > (In reply to Jürgen Reuter from comment #15) > > With -fcheck=all nothing is flagged, but the test works as expected, as well > > as if I (independently from the fcheck) compile everything with -fno-inline > > . > > Also compile with -Wall and see if anything pops out. > > Try valgrind on executable compiled with and without the -fno-inline as well. -Wall shows only a lot of unused dummy arguments which are unavoidable for polymorphism . But when compiled with -Wall also the problem doesn't show up. We will try to run valgrind on the code without flags and with -fno-inline as well.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #16 from Jerry DeLisle --- (In reply to Jürgen Reuter from comment #15) > With -fcheck=all nothing is flagged, but the test works as expected, as well > as if I (independently from the fcheck) compile everything with -fno-inline . Also compile with -Wall and see if anything pops out. Try valgrind on executable compiled with and without the -fno-inline as well.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #15 from Jürgen Reuter --- With -fcheck=all nothing is flagged, but the test works as expected, as well as if I (independently from the fcheck) compile everything with -fno-inline .
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #14 from Steve Kargl --- On Wed, Feb 08, 2017 at 09:30:45PM +, juergen.reuter at desy dot de wrote: > > > > > Indeed, it looks as if kind=10 would be real128, but as you said this > > > is wrong and was fixed by you (I guess it is not yet in the trunk, as > > > of r245197 at least). > > > > You need r245255 to get the fix. There is, however, some discussion > > as to whether I should revert the change. > > Ah ok. Why? Because it is too late for anything than regression fixes now? That's one reason. The other reason given is that it changes the ABI. I don't think the ABI change is an issue because the ABI for libgfortran has alraedy changed, which will require a recompile of software. > As far as we can seen all our constants have valid and consistent > kind type. Any try to reduce the code, hasn't worked. Putting print > statements there are trying to pass the corresponding routine to an > output routine to access it without the heavy machinery of the whole > program let's the problem go away. Hmmm. Adding a print statement suggests stepping off the end of an array, accessing memory that has been free, and argument mismatch in a function/subroutine call. Have you tried adding -fcheck=all and/or running the failing code under valgrind?
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #13 from Jürgen Reuter --- (In reply to Steve Kargl from comment #12) > On Wed, Feb 08, 2017 at 08:39:43PM +, juergen.reuter at desy dot de > wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 > > > > --- Comment #11 from Jürgen Reuter --- > > (In reply to Steve Kargl from comment #10) > > > On Wed, Feb 08, 2017 at 07:32:53PM +, juergen.reuter at desy dot de > > > > > which may lead to conforming code suddening becoming nonconforming > > > due to violation of storage association. > > > > Interesting. Actually, we are not setting any flags using configure options, > > except for those that libtool sets for us as default (-g -O2). > > In our code, we use everywhere variables defined as > > real(kind=default) :: foo > > complex(kind=default) :: foo, > > and then we use a module kinds.f90 with the definitions: > > !!! available REAL kinds ! prec. ! ISO ! C > > integer, parameter :: single= 4 ! 1.. 6 ! real32 ! c_float > > integer, parameter :: double= 8 ! 7..15 ! real64 ! c_double > > integer, parameter :: extended = 10 ! 16..18 ! real128 ! c_long_double > > integer, parameter :: quadruple = 16 ! 19..33 ! -1 ! c_float128 > > > > When configuring with no flag or --with-precision=double, then in this file > > kind.f90 we > > set > > > > integer, parameter :: default = double > > configuring with --with-precision=extended sets > > integer, parameter :: default = extended > > and configuring with --with-precision=quadruple sets > > integer, parameter :: default = quadruple > > > > The integers above are determined during configure, depending on the > > compiler, > > and are always the same, only default is set depending on the configure > > option. > > The above should be fine. This then suggests that you may have > an unstable algorithm. Are literal constants properly decolorated, > e.g., 1.e0_default? Are kind types included in REAL and CMPLX, > e.g., real(1.e0, default) and cmplx(1, 2, default)? > > Without a reduced testcase, it will be difficult to track down > the problem. > > > Indeed, it looks as if kind=10 would be real128, but as you said this > > is wrong and was fixed by you (I guess it is not yet in the trunk, as > > of r245197 at least). > > You need r245255 to get the fix. There is, however, some discussion > as to whether I should revert the change. Ah ok. Why? Because it is too late for anything than regression fixes now? As far as we can seen all our constants have valid and consistent kind type. Any try to reduce the code, hasn't worked. Putting print statements there are trying to pass the corresponding routine to an output routine to access it without the heavy machinery of the whole program let's the problem go away.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #12 from Steve Kargl --- On Wed, Feb 08, 2017 at 08:39:43PM +, juergen.reuter at desy dot de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 > > --- Comment #11 from Jürgen Reuter --- > (In reply to Steve Kargl from comment #10) > > On Wed, Feb 08, 2017 at 07:32:53PM +, juergen.reuter at desy dot de > > > which may lead to conforming code suddening becoming nonconforming > > due to violation of storage association. > > Interesting. Actually, we are not setting any flags using configure options, > except for those that libtool sets for us as default (-g -O2). > In our code, we use everywhere variables defined as > real(kind=default) :: foo > complex(kind=default) :: foo, > and then we use a module kinds.f90 with the definitions: > !!! available REAL kinds ! prec. ! ISO ! C > integer, parameter :: single= 4 ! 1.. 6 ! real32 ! c_float > integer, parameter :: double= 8 ! 7..15 ! real64 ! c_double > integer, parameter :: extended = 10 ! 16..18 ! real128 ! c_long_double > integer, parameter :: quadruple = 16 ! 19..33 ! -1 ! c_float128 > > When configuring with no flag or --with-precision=double, then in this file > kind.f90 we > set > > integer, parameter :: default = double > configuring with --with-precision=extended sets > integer, parameter :: default = extended > and configuring with --with-precision=quadruple sets > integer, parameter :: default = quadruple > > The integers above are determined during configure, depending on the compiler, > and are always the same, only default is set depending on the configure > option. The above should be fine. This then suggests that you may have an unstable algorithm. Are literal constants properly decolorated, e.g., 1.e0_default? Are kind types included in REAL and CMPLX, e.g., real(1.e0, default) and cmplx(1, 2, default)? Without a reduced testcase, it will be difficult to track down the problem. > Indeed, it looks as if kind=10 would be real128, but as you said this > is wrong and was fixed by you (I guess it is not yet in the trunk, as > of r245197 at least). You need r245255 to get the fix. There is, however, some discussion as to whether I should revert the change.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #11 from Jürgen Reuter --- (In reply to Steve Kargl from comment #10) > On Wed, Feb 08, 2017 at 07:32:53PM +, juergen.reuter at desy dot de > which may lead to conforming code suddening becoming nonconforming > due to violation of storage association. Interesting. Actually, we are not setting any flags using configure options, except for those that libtool sets for us as default (-g -O2). In our code, we use everywhere variables defined as real(kind=default) :: foo complex(kind=default) :: foo, and then we use a module kinds.f90 with the definitions: !!! available REAL kinds ! prec. ! ISO ! C integer, parameter :: single= 4 ! 1.. 6 ! real32 ! c_float integer, parameter :: double= 8 ! 7..15 ! real64 ! c_double integer, parameter :: extended = 10 ! 16..18 ! real128 ! c_long_double integer, parameter :: quadruple = 16 ! 19..33 ! -1 ! c_float128 When configuring with no flag or --with-precision=double, then in this file kind.f90 we set integer, parameter :: default = double configuring with --with-precision=extended sets integer, parameter :: default = extended and configuring with --with-precision=quadruple sets integer, parameter :: default = quadruple The integers above are determined during configure, depending on the compiler, and are always the same, only default is set depending on the configure option. Indeed, it looks as if kind=10 would be real128, but as you said this is wrong and was fixed by you (I guess it is not yet in the trunk, as of r245197 at least). For ifort we get !!! available REAL kinds ! prec. ! ISO ! C integer, parameter :: single= 4 ! 1.. 6 ! real32 ! c_float integer, parameter :: double= 8 ! 7..15 ! real64 ! c_double integer, parameter :: quadruple = 16 ! 16..33 ! real128 ! c_long_double and for NAG: !!! available REAL kinds ! prec. ! ISO ! C integer, parameter :: single= 1 ! 1.. 6 ! real32 ! c_float integer, parameter :: double= 2 ! 7..15 ! real64 ! c_double integer, parameter :: quadruple = 3 ! 16..31 ! real128 ! -1 (with a different range then gfortran and ifort) and for PGF !!! available REAL kinds ! prec. ! ISO ! C integer, parameter :: single= 4 ! 1.. 6 ! real32 ! c_float integer, parameter :: double= 8 ! 7..15 ! real64 ! c_double
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #10 from Steve Kargl --- On Wed, Feb 08, 2017 at 07:32:53PM +, juergen.reuter at desy dot de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 > > --- Comment #8 from Jürgen Reuter --- > We are defining a real(default) which could be 4, 8, 10 or 16, as these are > the > real kinds supported by gfortran. If default = 10, this happens, but this is > not per se forbidden, is it? > I don't know. Spent 15-20 minutes looking through the whizard svn repository, but can't find what --with-precision=extended actually does. I assume that this is causing compiler options to be set. program foo use iso_fortran_env implicit none character(len=20), parameter :: fmt = '(I2,1X,I3,1X,I2)' real(real_kinds(1)) a real(real_kinds(2)) b real(real_kinds(3)) c real(real_kinds(4)) d real(real32) e real(real64) f real(real128) g write(*,fmt) kind(a), digits(a), precision(a) write(*,fmt) kind(b), digits(b), precision(b) write(*,fmt) kind(c), digits(c), precision(c) write(*,fmt) kind(d), digits(d), precision(d) write(*,*) write(*,fmt) kind(e), digits(e), precision(e) write(*,fmt) kind(f), digits(f), precision(f) write(*,fmt) kind(g), digits(g), precision(g) end program foo With trunk on x86_64-*-freebsd with my patch to fix REAL128, % gfc7 -o z a.f90 && ./z 4 24 6 8 53 15 10 64 18 16 113 33 4 24 6 8 53 15 16 113 33 With gfortran 6.3.0 on x86_64-*-freebsd without my patch to fix REAL128 % gfortran6 -static -o z a.f90 && ./z 4 24 6 8 53 15 10 64 18 16 113 33 4 24 6 8 53 15 10 64 18 If --with-precision=extended is setting -freal-4-real-10, you get % gfc7 -o z a.f90 -freal-4-real-10 && ./z 10 64 18 8 53 15 10 64 18 16 113 33 10 64 18 8 53 15 16 113 33 which may lead to conforming code suddening becoming nonconforming due to violation of storage association.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #9 from Jürgen Reuter --- (In reply to kargl from comment #7) > (In reply to Jürgen Reuter from comment #6) > > (In reply to Dominique d'Humieres from comment #5) > > > What does --with-precision=extended? > > > > It sets the default precision of real and complex floats (kind type > > parameter) to 80 bit instead of 64 bit (double) or 128bit (quadruple) > > precision according to: > > > > !!! available REAL kinds ! prec. ! ISO ! C > > integer, parameter :: single= 4 ! 1.. 6 ! real32 ! c_float > > integer, parameter :: double= 8 ! 7..15 ! real64 ! c_double > > integer, parameter :: extended = 10 ! 16..18 ! real128 ! c_long_double > > integer, parameter :: quadruple = 16 ! 19..33 ! -1 ! c_float128 > > > > integer, parameter :: default = extended > > Your use of terminology is unclear. The default real type in > Fortran is REAL. Real has a default real kind type value of 4. > This means that REAL == REAL(4), which is 32 bits. If you are > using some configure magic to map REAL to REAL(10), your version > of gfortran is too broken to save. > > Also note, I just fixed gfortran so that your table above is wrong. > If the four real types with kind = 4, 8, 10, and 16 are available. > Then the mapping is REAL(4) == REAL32, REAL(8) == REAL64, and > REAL(16) == REAL128. > > If a clever user messes up what default precision means, then > that clever user gets what they deserve. see my comment #8.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #8 from Jürgen Reuter --- We are defining a real(default) which could be 4, 8, 10 or 16, as these are the real kinds supported by gfortran. If default = 10, this happens, but this is not per se forbidden, is it?
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #7 from kargl at gcc dot gnu.org --- (In reply to Jürgen Reuter from comment #6) > (In reply to Dominique d'Humieres from comment #5) > > What does --with-precision=extended? > > It sets the default precision of real and complex floats (kind type > parameter) to 80 bit instead of 64 bit (double) or 128bit (quadruple) > precision according to: > > !!! available REAL kinds ! prec. ! ISO ! C > integer, parameter :: single= 4 ! 1.. 6 ! real32 ! c_float > integer, parameter :: double= 8 ! 7..15 ! real64 ! c_double > integer, parameter :: extended = 10 ! 16..18 ! real128 ! c_long_double > integer, parameter :: quadruple = 16 ! 19..33 ! -1 ! c_float128 > > integer, parameter :: default = extended Your use of terminology is unclear. The default real type in Fortran is REAL. Real has a default real kind type value of 4. This means that REAL == REAL(4), which is 32 bits. If you are using some configure magic to map REAL to REAL(10), your version of gfortran is too broken to save. Also note, I just fixed gfortran so that your table above is wrong. If the four real types with kind = 4, 8, 10, and 16 are available. Then the mapping is REAL(4) == REAL32, REAL(8) == REAL64, and REAL(16) == REAL128. If a clever user messes up what default precision means, then that clever user gets what they deserve.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #6 from Jürgen Reuter --- (In reply to Dominique d'Humieres from comment #5) > What does --with-precision=extended? It sets the default precision of real and complex floats (kind type parameter) to 80 bit instead of 64 bit (double) or 128bit (quadruple) precision according to: !!! available REAL kinds ! prec. ! ISO ! C integer, parameter :: single= 4 ! 1.. 6 ! real32 ! c_float integer, parameter :: double= 8 ! 7..15 ! real64 ! c_double integer, parameter :: extended = 10 ! 16..18 ! real128 ! c_long_double integer, parameter :: quadruple = 16 ! 19..33 ! -1 ! c_float128 integer, parameter :: default = extended
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-02-08 Ever confirmed|0 |1 --- Comment #5 from Dominique d'Humieres --- What does --with-precision=extended?
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #4 from Jürgen Reuter --- (In reply to Andrew Pinski from comment #3) > (In reply to Jürgen Reuter from comment #2) > > (In reply to Andrew Pinski from comment #1) > > > What target is this on? > > > > We reproduced it under MAC OS X as well as under Ubuntu Linux 14.04 and > > Scientific Linux 6.8. x86_64. > > Have you tried any non x86_64 targets? No, we haven't any 32bit machines left.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 Andrew Pinski changed: What|Removed |Added Target||x86_64-*-* --- Comment #3 from Andrew Pinski --- (In reply to Jürgen Reuter from comment #2) > (In reply to Andrew Pinski from comment #1) > > What target is this on? > > We reproduced it under MAC OS X as well as under Ubuntu Linux 14.04 and > Scientific Linux 6.8. x86_64. Have you tried any non x86_64 targets?
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #2 from Jürgen Reuter --- (In reply to Andrew Pinski from comment #1) > What target is this on? We reproduced it under MAC OS X as well as under Ubuntu Linux 14.04 and Scientific Linux 6.8. x86_64.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #1 from Andrew Pinski --- What target is this on?
