Open Beliavsky opened 2 years ago
The following option -fno-range-check
seems to be missing. Could you check if it is present?
Thanks. When I run
fpm --flag -fno-range-check build --profile release
it works. The source files are compiled with the options
-O3 -Wimplicit-interface -fPIC -fmax-errors=1 -funroll-loops -fcoarray=single -fno-range-check -J
Please excuse a naive question, which is more about fpm, but where are those options coming from?
It seems like a gfortran 9's bug , and gfortran 10 and after fixed it.
fpm --flag -fno-range-check build --profile release
it works. The source files are compiled with the options
-O3 -Wimplicit-interface -fPIC -fmax-errors=1 -funroll-loops -fcoarray=single -fno-range-check -J
Please excuse a naive question, which is more about fpm, but where are those options coming from?
These options are triggerred by --profile release
. The option --profile debug
should result in other options.
The hash codes emulate unsigned arithmetic using signed arithmetic assuming the underlying arithmetic is two's complement for integer over or under flows. While there have been processors that use one's complement or signed magnitude implementations, such processors do not currently have a hosted Fortran 90+ compiler and the only processors with hosted Fortran 90 compilers have two's complement signed integers. Such compilers find it easiest to implement signed arithmetic using two's complement arithmetic. However over and underflowing in many contexts represent an error in the code and compilers often have flags to turn on or off over and underflow detection. As there is a performance cost for such detection, detection is typically turned off for runtime processing with significant optimization. However there is no such cost for compile time processing, and gfortran 9.x and earlier by default reported an error when a hexadecimal literal (which is defined to be an unsigned integer) was larger than the largest positive integer of that kind. The default for those versions of the compiler could be overridden by setting the flag -fno-range-check
. As some of the integer constants use in the hash algorithms had the highest bit set the flag had to be set for those versions of the compiler. Later version and Ifort, by default treat a set his bit as setting the sign bit as would be expected for two's complement integers.
This effectively breaks the use of stdlib as a dependency of conda-forge builds on MacOS, where GFortran 9.3.0 is the current default.
What prevents conda-forge from using the -fno-range-check
flag for GFortran 9.3.0?
@wclodius2 nothing it turns out. I was fetching stdlib with the CMake example here and apparently the standard compiler flags for stdlib are not retained in this procedure. I could now add -fno-range-check
back in again though and it works fine. Maybe @awvwgk would have an idea if this can be facilitated.
I pushed a fix for keeping the -fno-range-check
option to #642, which already fixes another CMake issue.
@awvwgk @Beliavsky was this issue solved by #642? Should it be closed?
This is only fixed for the CMake build, it is still an issue for fpm.
I ran
git checkout stdlib-fpm
. My gfortran version on WSL2 isWhen I build with fpm I get
Error: Arithmetic overflow converting INTEGER(16) to INTEGER(4) at (1)
in stdlib_hash_32bit.f90