[Bug fortran/91337] gfortran skips an if statement with some mathematical optimisations with complex numbers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91337 Chinoune changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Chinoune --- Sorry, It wasn't a bug. the compiler is not skipping the if statement. -fassociative-math : Allow re-association of operands in series of floating-point operations. This violates the ISO C and C++ language standard by possibly changing computation result. NOTE: re-ordering may change the sign of zero as well as ignore NaNs and inhibit or create underflow or overflow (and thus cannot be used on code that relies on rounding behavior like (x + 2**52) - 2**52. May also reorder floating-point comparisons and thus may not be used when ordered comparisons are required. -fassociative-math is enabled by -funsafe-math-optimizations .
[Bug fortran/91337] gfortran skips an if statement with some mathematical optimisations with complex numbers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91337 --- Comment #2 from Steve Kargl --- On Sat, Aug 03, 2019 at 03:14:57PM +, kargl at gcc dot gnu.org wrote: > --- Comment #1 from kargl at gcc dot gnu.org --- > (In reply to Chinoune from comment #0) > > I have encountered some underflows/overflows in my code compiled with > > -Ofast, and after investigations it seems like the complex abs gives zero > > with small numbers. So I added a workaround. but it didn't work: > > > > (snip) > > > > > gfortran-9 -O1 -funsafe-math-optimizations -ffinite-math-only > > bug_skip_if.f90 -o test.x > > ./test.x > > (snip) > > > > > Q : Why does gfortran skip the if statement? > > What happens if you don't use options that allow > a compiler to violate the standard? > BTW, with the posted code, I cannot reproduce your results on either i586-*-freebsd or x86_64-*-freebsd.
[Bug fortran/91337] gfortran skips an if statement with some mathematical optimisations with complex numbers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91337 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Severity|normal |minor
[Bug fortran/91337] gfortran skips an if statement with some mathematical optimisations with complex numbers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91337 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to Chinoune from comment #0) > I have encountered some underflows/overflows in my code compiled with > -Ofast, and after investigations it seems like the complex abs gives zero > with small numbers. So I added a workaround. but it didn't work: > (snip) > > gfortran-9 -O1 -funsafe-math-optimizations -ffinite-math-only > bug_skip_if.f90 -o test.x > ./test.x (snip) > > Q : Why does gfortran skip the if statement? What happens if you don't use options that allow a compiler to violate the standard? '-Ofast' Disregard strict standards compliance. '-Ofast' enables all '-O3' optimizations. It also enables optimizations that are not valid for all standard-compliant programs. It turns on '-ffast-math' and the Fortran-specific '-fstack-arrays', unless '-fmax-stack-var-size' is specified, and '-fno-protect-parens'. '-ffast-math' Sets the options '-fno-math-errno', '-funsafe-math-optimizations', '-ffinite-math-only', '-fno-rounding-math', '-fno-signaling-nans', '-fcx-limited-range' and '-fexcess-precision=fast'. This option causes the preprocessor macro '__FAST_MATH__' to be defined. This option is not turned on by any '-O' option besides '-Ofast' since it can result in incorrect output for programs that depend on an exact implementation of IEEE or ISO rules/specifications for math functions. It may, however, yield faster code for programs that do not require the guarantees of these specifications. '-funsafe-math-optimizations' Allow optimizations for floating-point arithmetic that (a) assume that arguments and results are valid and (b) may violate IEEE or ANSI standards. When used at link time, it may include libraries or startup files that change the default FPU control word or other similar optimizations. This option is not turned on by any '-O' option since it can result in incorrect output for programs that depend on an exact implementation of IEEE or ISO rules/specifications for math functions
