[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #38 from Thomas Henlich --- (In reply to Thomas Henlich from comment #37) > It would make sense to keep optimization in mind: > > Several calls to conversions of the same value should be performed only once. > > As a special case: Calls to compute sind(x) and cosd(x) should be optimized > to a conversion, followed by a call to sincos. > > The conversion could also be provided as a user function, for example in > code like y=tand(x)-deg2rad(x) the conversion would need to be performed > only once. I just realized this is probably a lot harder than it sounds, since it is incompatible with some of the range reduction steps, or at the least requires some further folding into x <= 45 for sincos to get sufficient accuracy. On the other hand side, always folding sind(45...90) to cosd(45...0) and cosd(45...90) to sind(45...0) probably wouldn't be such a bad thing.
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #40 from Thomas Henlich --- Now I get it, symmetry is beautiful: Both sin(x) and cos(x) for any x can always be calculated with one range reduction to 0...45, one call to sincos(), and a sign transfer for each result.
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #41 from Thomas Henlich --- One would assume that fast FMA (https://en.wikipedia.org/wiki/FMA_instruction_set) is or will be available to the modern Fortran enthusiast, in the year 202x.
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #43 from Thomas Henlich --- (In reply to Steve Kargl from comment #42) > gfortran currently does not implement IEEE_FMA along > with a few additional IEEE_ARITHMETIC features added > in F2018. > > Note, gcc/builtins.def has fma, fmaf, and fmal covered. > We'll need a mapping in libquadmath if it has a __float128 > fma. It has: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46402
[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374 --- Comment #34 from Thomas Henlich --- Created attachment 47976 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47976&action=edit Patch to fix issue with wrong exponent width for w=0 I appear to have found a fix for one of the remaining issues. This fixes "(D0.3)" -> got "0.314D-2", expected "0.314D-02" "(E0.10)" -> got "0.313928E-2", expected "0.313928E-02" More issues remain.
[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374 --- Comment #35 from Thomas Henlich --- I tried to investigate the next issue: write (aresult,fmt="(G0.10e0)") rn if (aresult /= "0.313928E-2") stop 52 triggers "E specifier not allowed with g0 descriptor in format string" during compilation. But it is allowed, according to F2018. The following works as it should: afmt = "(G0.10e0)" write (aresult,fmt=afmt) rn if (aresult /= "0.313928E-2") stop 33 That is how far I got. Probably some changes are required in io.c (check_format)
[Bug fortran/93733] F2008: G0.d output editing for integer/logical/character data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93733 --- Comment #3 from Thomas Henlich --- (In reply to Dominique d'Humieres from comment #2) > Does it look good? Agreed, that should fix the bug.
[Bug fortran/93733] F2008: G0.d output editing for integer/logical/character data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93733 --- Comment #5 from Thomas Henlich --- (In reply to Dominique d'Humieres from comment #4) > But reject valid too! AFAIU this cannot captured ay the format level. Please explain, what valid code according to Fortran 2008 does -std=f2008 reject?
[Bug fortran/93733] F2008: G0.d output editing for integer/logical/character data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93733 --- Comment #7 from Thomas Henlich --- (In reply to Dominique d'Humieres from comment #6) > > Please explain, what valid code according to Fortran 2008 does -std=f2008 > > reject? > > FAIL: gfortran.dg/fmt_g0_4.f08 -O (test for excess errors) I think there is another bug, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36725#c8
[Bug fortran/93733] F2008: G0.d output editing for integer/logical/character data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93733 --- Comment #9 from Thomas Henlich --- I think this standard conformity check is only performed at compile-time, and can only work if the format is defined in a constant. So, changing the definition to: character(4), parameter :: fmt="(g0)" character(6), parameter :: fmt2="(g0.2)" when compiled with -std=f95 gives 6 times: Error: Fortran 2008: 'G0' in format at (1)
[Bug libfortran/93550] Implement control of leading zero in formatted numeric output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93550 Thomas Henlich changed: What|Removed |Added Priority|P3 |P5 Severity|normal |enhancement
[Bug fortran/36725] g0 edit descriptor: Missing compile-time checking for invalid g0.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36725 Thomas Henlich changed: What|Removed |Added Status|RESOLVED|REOPENED CC||thenlich at gcc dot gnu.org Blocks||90374 Resolution|FIXED |--- --- Comment #8 from Thomas Henlich --- This bug is now apparently invalid. "C1007 (R1007) For the G edit descriptor, d shall be specified if w is not zero" (There is no "and only if") The compiler does the right thing now (good). gfortran.dg/fmt_go_4.f08 should be fixed to check for standard-conforming run-time output, which is currently broken by an incomplete fix for bug 90374. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374 [Bug 90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output
[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374 Bug 90374 depends on bug 36725, which changed state. Bug 36725 Summary: g0 edit descriptor: Missing compile-time checking for invalid g0.d https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36725 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug fortran/36725] g0 edit descriptor: Missing compile-time checking for invalid g0.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36725 --- Comment #9 from Thomas Henlich --- Created attachment 47827 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47827&action=edit Proposed patch to perform runtime check in fmt_g0_4.f08 This checks ensure that G0.d output is not broken.
[Bug libfortran/93727] New: Fortran 2018: EX edit descriptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727 Bug ID: 93727 Summary: Fortran 2018: EX edit descriptor Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: thenlich at gcc dot gnu.org Target Milestone: --- 13.7.2.3.6 EX editing 1 The EX edit descriptor produces an output field in the form of a hexadecimal-significand number. 2 The EXw.d and EXw.dEe edit descriptors indicate that the external field occupies w positions, except when w is zero in which case the processor selects the field width. The fractional part of the field contains d hexadecimal digits, except when d is zero in which case the processor selects the number of hexadecimal digits to be the minimum required so that the output field is equal to the internal value; d shall not be zero if the radix of the internal value is not a power of two. The hexadecimal point, represented by a decimal symbol, appears after the first hexadecimal digit. For the form EXw.d, and for EXw.dE0, the exponent part contains the minimum number of digits needed to represent the exponent; otherwise the exponent contains e digits. The e has no effect on input. The scale factor has no effect on output. 3 The form and interpretation of the input field is the same as for Fw.d editing (13.7.2.3.2). 4 For an internal value that is an IEEE infinity or NaN, the form of the output field is the same as for Fw.d. 5 For an internal value that is neither an IEEE infinity nor a NaN, the form of the output field is [ ± ] 0X x0 . x1x2 . . . exp where: • ± signifies a plus sign or a minus sign; • . signifies a decimal symbol (13.6); • x0x1x2 . . . are the most significant hexadecimal digits of the internal value, after rounding if d is not zero (13.7.2.3.8); • exp is a binary exponent expressed as a decimal integer; for EXw.d and EXw.dE0, the form is P ±z1 . . . zn20 , where n is the minimum number of digits needed to represent exp, and for EXw.dEe with e greater than zero the form is P ±z1 . . . ze22 . The choice of binary exponent is processor dependent. If the most significant binary digits of the internal value are b0b1b2 . . ., the binary exponent might make the value of x0 be that of b0, b0b1, b0b1b2, or b0b1b2b3. A plus sign is produced if the exponent value is zero. Examples: Internal value Edit descriptor Possible output with SS in effect 1.375 EX0.10X1.6P+0 −15.625 EX14.4E3 -0X1.F400P+003 1048580.0 EX0.00X1.4P+20 2.375 EX0.10X2.6P+0
[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374 --- Comment #33 from Thomas Henlich --- Created attachment 47834 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47834&action=edit Proposed fix for test Proposed test for verifying the correct output after finishing this bug.
[Bug fortran/93733] New: F2008: G0.d output editing for integer/logical/character data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93733 Bug ID: 93733 Summary: F2008: G0.d output editing for integer/logical/character data Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: thenlich at gcc dot gnu.org Target Milestone: --- This example compiles and runs. But the second part should be rejected with -std=f2008 because these are Fortran 2018 features. program g0d_ilc !F2008: write(*, "(g0)") 23 write(*, "(g0)") .true. write(*, "(g0)") 'hello' !F2018: write(*, "(g0.2)") -23 write(*, "(g0.2)") .true. write(*, "(g0.2)") 'hello' end gfortran -std=f2008 g0d_ilc.f90 && ./a.out 23 T hello -23 T hello The new features of Fortran 2018 (ISO/IEC JTC1/SC22/WG5 N2145): "The g0.d edit descriptor can be used to specify the output of integer, logical, and character data. It follows the rules for the i0, l1, and a edit descriptors, respectively." F2008: 10.7.5.2.1 Generalized integer editing When used to specify the input/output of integer data, the Gw.d and Gw.d Ee edit descriptors follow the rules for the Iw edit descriptor (10.7.2.2), except that w shall not be zero. When used to specify the output of integer data, the G0 edit descriptor follows the rules for the I0 edit descriptor. 10.7.5.3 Generalized logical editing When used to specify the input/output of logical data, the Gw.d and Gw.d Ee edit descriptors follow the rules for the Lw edit descriptor (10.7.3). When used to specify the output of logical data, the G0 edit descriptor follows the rules for the L1 edit descriptor. 10.7.5.4 Generalized character editing When used to specify the input/output of character data, the Gw.d and Gw.d Ee edit descriptors follow the rules for the Aw edit descriptor (10.7.4). When used to specify the output of character data, the G0 edit descriptor follows the rules for the A edit descriptor with no field width. F2018: 13.7.5.2.2 Generalized integer editing When used to specify the input/output of integer data, the Gw, Gw.d, and Gw.d Ee edit descriptors follow the rules for the Iw edit descriptor (13.7.2.2). Note that w cannot be zero for input editing (13.7.5.1). 13.7.5.3 Generalized logical editing When used to specify the input/output of logical data, the Gw.d and Gw.d Ee edit descriptors with nonzero w follow the rules for the Lw edit descriptor (13.7.3). When used to specify the output of logical data, the G0 and G0.d edit descriptors follow the rules for the L1 edit descriptor. 13.7.5.4 Generalized character editing When used to specify the input/output of character data, the Gw.d and Gw.d Ee edit descriptors with nonzero w follow the rules for the Aw edit descriptor (13.7.4). When used to specify the output of character data, the G0 and G0.d edit descriptors follow the rules for the A edit descriptor with no field width.
[Bug fortran/93736] New: Add .f18 and .F18 file suffixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93736 Bug ID: 93736 Summary: Add .f18 and .F18 file suffixes Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: thenlich at gcc dot gnu.org Target Milestone: --- The Fortran compiler should recognize Fortran source files with the .f18 and .F18 filename extension.
[Bug fortran/93736] Add .f18 and .F18 file suffixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93736 --- Comment #2 from Thomas Henlich --- I don't know why the Fortran compiler doesn't treat all files as free-form Fortran source files, unless they have a known extension indicating otherwise.
[Bug fortran/93736] Add .f18 and .F18 file suffixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93736 Thomas Henlich changed: What|Removed |Added Priority|P3 |P5 --- Comment #4 from Thomas Henlich --- Additionally, we could also imply -std=f2018 with the .f18/.F18 suffix. That would make them more useful.
[Bug fortran/93736] Add .f18 and .F18 file suffixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93736 --- Comment #6 from Thomas Henlich --- Created attachment 47842 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47842&action=edit Proposed patch to add .f18/.F18 suffix Add .f18 and .F18 to list of recognized filename suffixes to match the most recent standard Fortran 2018
[Bug fortran/27452] gfortran support for non-standard sind,cosd and friends intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27452 Thomas Henlich changed: What|Removed |Added CC||thenlich at gcc dot gnu.org Resolution|INVALID |FIXED Assignee|unassigned at gcc dot gnu.org |foreese at gcc dot gnu.org --- Comment #13 from Thomas Henlich --- Update: these functions have now been implemented: https://gcc.gnu.org/ml/fortran/2016-09/msg00163.html
[Bug libfortran/93871] New: COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 Bug ID: 93871 Summary: COTAN is slow for complex types Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: thenlich at gcc dot gnu.org Target Milestone: --- Runtime tests show that the COTAN function (cotangent function, GNU extension) needs about twice the time as TAN for complex types. This is surprising, since it basically performs the same operations as TAN, only in a different order. I would expect COTAN to perform about the same as TAN.
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #1 from Thomas Henlich --- Created attachment 47883 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47883&action=edit Proposed patch for COTAN speedup This is basically the same method mpc uses internally to compute mpc_tan (only reversed)
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #5 from Thomas Henlich --- Created attachment 47884 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47884&action=edit Test case Output: th@THe-Surface:~$ /opt/gcc/bin/gfortran -L/opt/gcc/lib64 -Wl,-rpath -Wl,/opt/gcc/lib64 -fdec-math /mnt/c/Temp/test_cotan_complex.f90 && ./a.out Testing(+1.2E-003,+0.) 1/tan= (+999.9996664454,+0.) time: +0.243003011 cotan= (+999.9996664443,-0.) time: +0.535230994 cos/sin= (+999.9996664443,-0.) time: +0.530906022 tan(pi/2-a)= (+1000.0433799820958,+0.) time: +0.263039947 Testing (+1.,+0.) 1/tan= (+0.64209261593433076,+0.) time: +0.264049053 cotan= (+0.64209261593433076,-0.) time: +0.602337122 cos/sin=(+0.64209261593433076,-0.) time: +0.600989103 tan(pi/2-a)=(+0.64209267766718214,+0.) time: +0.247081995 Testing (+1.5701,+0.) 1/tan= (+7.96326963223192592E-004,+0.) time: +0.258723021 cotan= (+7.96326963223192592E-004,-0.) time: +0.588716030 cos/sin= (+7.96326963223192592E-004,-0.) time: +0.590244293 tan(pi/2-a)= (+7.96370674640914985E-004,+0.) time: +0.230789661 Testing (+3.,+0.) 1/tan= (-7.0152525514345339,-0.) time: +0.321346283 cotan= (-7.0152525514345339,-0.) time: +0.733272552 cos/sin= (-7.0152525514345339,-0.) time: +0.718843937 tan(pi/2-a)= (-7.0152503565215953,+0.) time: +0.266773224 t
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #6 from Thomas Henlich --- (In reply to kargl from comment #2) > Can you post the code you used for testing? Your patch to simplify.c > affects compile-time constant folding. simplify.c has nothing to do > with a run-time evaluation. Ok, I was looking in the wrong place. It's still a cool patch though ;-)
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #14 from Thomas Henlich --- Come for the runtime, stay for the ICE!
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #16 from Thomas Henlich --- Additional note: The issue is not restricted to complex types, but also occurs for real types. On i686-mingw32, by a factor 2...10 depending on kind. However I could not measure any slowdown on i686-pc-linux-gnu. Due to this, and my earlier confusion about mpc/mpfr, I chose not to include it in this bug report.
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #17 from Thomas Henlich --- The following should give an error message, not a ICE: program test_dtrig2 real, parameter :: d = asind(1.1) print *, d end gfortran -fdec-math test_dtrig2.f90 f951.exe: internal compiler error: Segmentation fault ... program test_dtrig2 real, parameter :: d = asin(1.1) print *, d end test_dtrig2.f90:2:30: 2 | real, parameter :: d = asin(1.1) | 1 Error: Argument of ASIN at (1) must be between -1 and 1
[Bug fortran/93736] Add .f18 and .F18 file suffixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93736 --- Comment #7 from Thomas Henlich --- This should have a test-case added, ideally by renaming an already existing test-case containing Fortran 2018 features to .f18.
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #19 from Thomas Henlich --- Regarding the following: https://stackoverflow.com/questions/3738384/stable-cotangent#56864824 Is there a more stable implementation for the cotangent function than return 1.0/tan(x)? No. No machine number x can get close enough to multiples of π/2 to cause tan(x) to overflow, therefore tan(x) is well-defined and finite for all floating-point encodings for any of the IEEE-754 floating-point formats, and by extension, so is cot(x) = 1.0 / tan(x). ... Using a math library with an accurate implementation of tan() with a maximum error of ~= 0.5 ulp, we find that computing cot(x) = 1.0 / tan(x) incurs a maximum error of less than 1.5 ulp, where the additional error compared to tan() itself is contributed by the rounding error of the division. Repeating this exhaustive test over all float values with cot(x) = cos(x) / sin(x), where sin() and cos() are computed with a maximum error of ~= 0.5 ulp, we find that the maximum error in cot() is less than 2.0 ulps, so slightly larger. This is easily explained by having three sources of error instead of two in the previous formula. it may be best (and fastest) to just implement it like above: cot=1/tan
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #21 from Thomas Henlich --- One should also ask: What is the least surprising way to implement the cotangent function? If someone uses a (non-standard) function bearing a name similar to "tangent", they probably expect a function similar in precision and runtime to the standard tangent function, and nothing which is more accurate in certain ranges, but which is also slower. For being able to use a construct like "y = a * cotan(x)" instead of "y = a / tan(x)" there should be no additional punishment aside from standard non-compliance.
[Bug fortran/47485] gfortran -M output is incorrect when -MT option is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47485 Thomas Henlich changed: What|Removed |Added Severity|normal |minor
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 Thomas Henlich changed: What|Removed |Added Severity|normal |minor
[Bug fortran/47485] gfortran -M output is incorrect when -MT option is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47485 Thomas Henlich changed: What|Removed |Added Severity|minor |normal
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #26 from Thomas Henlich --- Created attachment 47914 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47914&action=edit Demonstration of range reduction There is a danger of some inaccuracy in the degree trigonometric functions (sind, cosd, tand, cotand) because a full period of 360 degrees can not be expressed accurately in radians. This can be circumvented by using some trigonometric identities to reduce the range and also place the inaccurate x range to where |dy/dx|→min, and away from y values near zero toward high y values so that the error is mostly cancelled. This is a best effort to still be able to use the standard library functions but also get an increased accuracy expected from the degree functions. Thus: 1. Calculate cosd(x) = sind(90 - x) 2. Calculate cotand(x) = tand(90 - x) 3. Reduce range of sind() argument from (0...360) further to x-360 if it is above 270, and to 180-x if it is above 90 Considering the demonstration program: $ gf10 -fdec-math periods.f90 && ./a.exe cos( 90.000 )= -4.37113883E-08 0. sin( 180.00 )= -8.74227766E-08 0. cos( 270.00 )= 1.19248806E-08 0. sin( -360.00 )= -0. 0. sin( 3600.0 )= 0. 0. sin( 36000180.0 )= -8.74227766E-08 0. cotan( 90.000 )= -4.37113883E-08 0. $ gf10 -fdec-math -fdefault-real-8 periods.f90 && ./a.exe cos( 90.000 )= 6.1230317691118863E-017 0. sin( 180.00 )= 1.2246063538223773E-016 0. cos( 270.00 )= -1.8369095307335659E-016 0. sin( -360.00 )= -0.0. sin( 3600.0 )= 0.0. sin( 36000180.0 )= 1.2246063538223773E-016 0. cotan( 90.000 )= 6.1230317691118863E-017 0. showing that values for all multiples of 90 degrees can be computed to be exactly zero.
[Bug fortran/93948] New: Surprising option processing of -fdec and -fdec-math in combination with -std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93948 Bug ID: 93948 Summary: Surprising option processing of -fdec and -fdec-math in combination with -std Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: thenlich at gcc dot gnu.org Target Milestone: --- It is surprising that the -std option leads to the -fdec-math option to be silently ignored, while the -fdec option is honoured. This makes it hard to enforce standard-compliant code while allowing only the small subset of the DEC math extensions. For example program dec1 print "(g0)", sind(0.) end program $ gf10 -std=f2008 dec1.f90 && ./a.exe cco91hFa.o:dec1.f90:(.text+0x57): undefined reference to `sind_' $ gf10 -std=f2008 -fdec dec1.f90 && ./a.exe 0. $ gf10 -std=f2008 -fdec-math dec1.f90 && ./a.exe cc6E3irl.o:dec1.f90:(.text+0x57): undefined reference to `sind_' collect2.exe: error: ld returned 1 exit status $ gf10 -fdec-math dec1.f90 && ./a.exe 0.
[Bug fortran/93948] Surprising option processing of -fdec and -fdec-math in combination with -std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93948 Thomas Henlich changed: What|Removed |Added Severity|normal |minor
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #29 from Thomas Henlich --- (In reply to Steve Kargl from comment #28) > ! Fold into [0,90] range ... > if (arg == 180) then I don't understand how (arg == 180) could be true after folding into [0,90] range.
[Bug fortran/93948] Surprising option processing of -fdec and -fdec-math in combination with -std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93948 --- Comment #2 from Thomas Henlich --- -fall-intrinsics is a nice workaround, but it also enables more than I want. I just find it not intuitive, that -fdec apparently has the same effect as -fall-intrinsics for some intrinsics, but -fdec-math (an option to actually enable some intrinsics) does not. As documented: "-fall-intrinsics This option causes all intrinsic procedures (including the GNU-specific extensions) to be accepted." Just not those which require -fdec or -fdec-math. "-fdec-math Enable legacy math intrinsics such as COTAN and degree-valued trigonometric functions (e.g. TAND, ATAND, etc...) for compatability with older code." Requiring one of -fdec or -fall-intrinsics, if -std is specified. Is redundant in the first case. Any plan for action regarding this option should probably consider the fact that decimal trigonometry functions are on the work list for Fortran 202X, which if passed would leave only COTAN as a non-standard function.
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #31 from Thomas Henlich --- I wonder, if some "correct" rounding could further increase accuracy: We know the sign and "real" magnitude of the difference deg2rad-π/180 and can round the result of sin() accordingly.
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #33 from Thomas Henlich --- Going back one step, I wonder if it would be good enough to perform a correctly rounded conversion from degrees to radians, and just use sin() as is. ... f = sgn * sin(deg2rad(arg)) end function fcn ! Compute correctly rounded value of x * pi / 180 for x = 0 ... 90 function deg2rad(x) result(y) real(sp) y real(sp), intent(in) :: x real(sp), parameter :: a = atan(1._4) / 45 real(sp), parameter :: b = atan(1._16) / 45 - a y = a * x + b * x end function deg2rad (The exact values of a and b still need some work)
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #35 from Thomas Henlich --- (In reply to Steve Kargl from comment #34) > Even this appears to have some irregularities as my exhaustive > test in the interval [1.e-8,1) with direct call to sinf() yields > This looks like a job for FMA: "Correctly rounded multiplication by arbitrary precision constants" (http://perso.ens-lyon.fr/jean-michel.muller/MultConstant.html) show that it can be proven to always work.
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #37 from Thomas Henlich --- It would make sense to keep optimization in mind: Several calls to conversions of the same value should be performed only once. As a special case: Calls to compute sind(x) and cosd(x) should be optimized to a conversion, followed by a call to sincos. The conversion could also be provided as a user function, for example in code like y=tand(x)-deg2rad(x) the conversion would need to be performed only once.
[Bug libfortran/93727] Fortran 2018: EX edit descriptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727 --- Comment #6 from Thomas Henlich --- (In reply to Jerry DeLisle from comment #5) > I have been studying this a bit by looking at the 2023 std and functionality > of printf(). > Specifically printf() provides the 'A' descriptor which can be used for > float (kind=4) and double (kind=8). It will accept a long double (80 bit > aka kind=10). I am noticing that the results of double and long double are > identical, no extra precision visible. It is very possible I am not doing > that correctly. > > I do not see anything related to quad precision floats. I am posting this > as i think we will have to do some of our own translating byte portions of > floats ourselves. Portability may be an issue. For example IBM 360 128bit > precision or some other processor may not follow the same internal > representations. > > Regardless I have preliminary code for the frontend that results in calling > anew fucntion write_ex in transfer.c > > I think that kind=4 and kind=8 will be fine. Any thoughts on kind=10 or > kind=16 I would appreciate as I further explore this. Just some thoughts: Have you tried "%LA" for long double? Have you tried quadmath_snprintf (https://gcc.gnu.org/onlinedocs/libquadmath/quadmath_005fsnprintf.html) with "%QA" for quad precision?
