[Bug fortran/96018] Optimization issue with external HDF5 library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96018 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2020-07-01 --- Comment #1 from Dominique d'Humieres --- Can you please provide the file(s) needed for use hdf5 ? TIA.
[Bug fortran/96018] Optimization issue with external HDF5 library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96018 --- Comment #2 from martin.schlipf at damnthespam dot com --- Well hdf5 is not developed by me, its a huge library. You can install it manually if you want (https://www.hdfgroup.org/solutions/hdf5/), but it is available on Ubuntu as mentioned sudo apt-get install libhdf5-dev There is probably a similar package for other linux distributions.
[Bug fortran/96018] Optimization issue with external HDF5 library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96018 --- Comment #3 from anlauf at gcc dot gnu.org --- You are not using HDF5's "native" Fortran interface directly, but a clumsy way with c_f_pointer to obscure your code. Any reason for that? Have you considered using RESHAPE for what you seem to try to get? Your code will run into issues if the dummy "array" is not contiguous. Also, I'd consider not checking a library's return code bad style. Also, can you give details on the exact compiler version and HDF5?
[Bug fortran/96018] Optimization issue with external HDF5 library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96018 --- Comment #4 from martin.schlipf at damnthespam dot com --- Hdf5 doesn't have native support for complex datatypes, so we convert to real and write that it is a complex as an attribute. If you replace the conversion logic by an array instead of a pointer allocate(real_array(2,size(array,1),size(array,2),size(array,3))) reshape(transfer(array, real_array), shape(real_array)) it doesn't alert the behavior. I agree that the error code should be checked and in fact, I already started a merge request for that particular part. But for this bug report, I need to leave it away, because otherwise the compiler does the right thing. Finally, I reproduced it with gfortran 9.3.0 + hdf 1.12.0 and gfortran 10.0 + hdf 1.10.4. With older versions of gfortran 7.3.0 it does not appear.
[Bug fortran/96018] Optimization issue with external HDF5 library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96018 --- Comment #5 from anlauf at gcc dot gnu.org --- (In reply to martin.schlipf from comment #4) > Finally, I reproduced it with gfortran 9.3.0 + hdf 1.12.0 and gfortran 10.0 > + hdf 1.10.4. With older versions of gfortran 7.3.0 it does not appear. Workarounds: - compile with -O0, not sure why this makes a difference - or replace in write_real_array_nd: real, intent(in) :: array(*) by real :: array(*) I'd recommend to additionally replace in write_complex_array_3d ierr = write_real_array_4d(locid, dataset_name, ptr) by ierr = write_real_array_4d(locid, dataset_name, & reshape (transfer(array,[1.0]),[2, shape(array)])) The latter is IMO much cleaner Fortran. There might by a bug in gfortran with the way you use c_f_pointer and assumed-size, which generates wrong code for argument packing, or there is a bug elsewhere which may corrupt data subtly.
[Bug fortran/96018] Optimization issue with external HDF5 library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96018 --- Comment #6 from martin.schlipf at damnthespam dot com --- Sorry, if that has not been clear enough. I already know how to work around this issue. You can simply check the error flag [if (ierr /= 0) return]. What I do not understand is why gfortran removes the call to the first function when I switch on the optimization.
[Bug fortran/96018] Optimization issue with external HDF5 library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96018 --- Comment #7 from Thomas Koenig --- I can not test at the moment, that will have to wait for a few days. A general comment: In Fortran, functions exist to return a value. C-style „return an error status“ fit rather badly to the language, that is much better expressed wirh a subroutine (plus an optional error reporting argument). Having said that, one thing that might influence the behavior is front-end optimization. What happens if -fno-frontend-optimize -O is specified?
[Bug fortran/96018] Optimization issue with external HDF5 library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96018 --- Comment #8 from Thomas Koenig --- Comment on attachment 48817 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48817 Minimal example to demonstrate the issue. Hm, I cannot reproduce this because I do not have the hdf5 library installed. Is there a way to create a self-contained test case? I'd like to run a bisection on this.
[Bug fortran/96018] Optimization issue with external HDF5 library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96018 martin.schlipf at damnthespam dot com changed: What|Removed |Added Attachment #48817|0 |1 is obsolete|| --- Comment #9 from martin.schlipf at damnthespam dot com --- Created attachment 48833 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48833&action=edit Minimal example to demonstrate the issue. The example is now independent of HDF5 which makes it much simpler.
