This: real*8 :: x = 10.0e9 do i = 10, 22 x = 10d0 * x print '(a,i2,a,g14.8)', "mod (10**",i,", 1.7_8) = ",mod (x, 1.7_8) end do end does this with cvs gfortran mod (10**10, 1.7_8) = 1.3000026 mod (10**11, 1.7_8) = 1.1000261 mod (10**12, 1.7_8) = 0.80026150 mod (10**13, 1.7_8) = 1.2026138 mod (10**14, 1.7_8) = 0.12609863 mod (10**15, 1.7_8) = 1.2607422 mod (10**16, 1.7_8) = 5.8125000 mod (10**17, 1.7_8) = -50.687500 mod (10**18, 1.7_8) = 364.00000 mod (10**19, 1.7_8) = -.70000000E+20 mod (10**20, 1.7_8) = -.70000000E+21 mod (10**21, 1.7_8) = -.70000000E+22 mod (10**22, 1.7_8) = -.70000000E+23 and this with a leading commercial brand: mod (10**10, 1.7_8) = 1.3000026 mod (10**11, 1.7_8) = 1.1000261 mod (10**12, 1.7_8) = 0.80026123 mod (10**13, 1.7_8) = 1.2026123 mod (10**14, 1.7_8) = 0.12612289 mod (10**15, 1.7_8) = 1.2612289 mod (10**16, 1.7_8) = 0.71228947 mod (10**17, 1.7_8) = 0.32289470 mod (10**18, 1.7_8) = 1.5289470 mod (10**19, 1.7_8) = 1.6894697 mod (10**20, 1.7_8) = 1.5946971 mod (10**21, 1.7_8) = 0.64697063 mod (10**22, 1.7_8) = 0.86970625 gfortran loses it at around 10**16 and starts producing values larger than the second argument. Whilst, to some degree, one deserves to be hit on the nose for trying to calculate mod for these values, a slightly less deviant behaviour might be better. As noted in the list http://gcc.gnu.org/ml/fortran/2005-10/msg00482.html, this leading brand is about twice as fast in calulating mod, as gfortran, in spite of its apparently using 64 bit arithmetic.
Confirmed.
Why exactly aren't we using BUILT_IN_FMOD{F,,L}? $ cat a.f90 real*8 :: x = 10.0e9 do i = 10, 22 x = 10d0 * x print '(a,i2,a,g14.8," = ",g14.8)', "mod (10**",i,", 1.7_8) = ", & fmod (x, 1.7_8), mod (x, 1.7_8); end do end $ cat a.c #include <math.h> double fmod_ (double *x, double *y) { return fmod(*x,*y); } $ gfortran a.f90 a.c && ./a.out mod (10**10, 1.7_8) = 1.3000026 = 1.3000026 mod (10**11, 1.7_8) = 1.1000261 = 1.1000261 mod (10**12, 1.7_8) = 0.80026120 = 0.80026150 mod (10**13, 1.7_8) = 1.2026123 = 1.2026138 mod (10**14, 1.7_8) = 0.12612289 = 0.12609863 mod (10**15, 1.7_8) = 1.2612289 = 1.2607422 mod (10**16, 1.7_8) = 0.71228945 = 5.8125000 mod (10**17, 1.7_8) = 0.32289469 = -50.687500 mod (10**18, 1.7_8) = 1.5289470 = 364.00000 mod (10**19, 1.7_8) = 1.6894697 = -.70000000E+20 mod (10**20, 1.7_8) = 1.5946971 = -.70000000E+21 mod (10**21, 1.7_8) = 0.64697063 = -.70000000E+22 mod (10**22, 1.7_8) = 0.86970627 = -.70000000E+23 It's actually slower: 55% slower at -O0 and 230% slower at -O2, on a loop with real(kind=8) variables modulo. But then, we're already testing whether the division can be represented by an integer, we could call fmod only in the case where it's not possible. Opinions?
Subject: RE: Intrinsic MOD incorrect for large arg1/arg2 and slow. FX, I do not have the slightest idea! I wrote various versions using BUILT_IN_FMOD and got bogged down in a discussion about the use of built-in fast-math versions. These seem to me to have more useful arithmetical properties, as well as being faster. I lost interest after that. I am stuck with a build problem that is causing me to scratch my head. PRECISION and RANGE do not seem to be known to the build any more and, in consequence it goes down in flames at selected_int/real_kind.f90. This is with a completely clean build. I cannot see any obvious culprit yet but we will see! Paul > -----Message d'origine----- > De : fxcoudert at gcc dot gnu dot org > [mailto:gcc-bugzilla@gcc.gnu.org] > Envoyé : mardi 20 juin 2006 14:23 > À : THOMAS Paul Richard 169137 > Objet : [Bug fortran/24518] Intrinsic MOD incorrect for large > arg1/arg2 > and slow. > > > > > ------- Comment #2 from fxcoudert at gcc dot gnu dot org > 2006-06-20 12:22 ------- > Why exactly aren't we using BUILT_IN_FMOD{F,,L}? > > $ cat a.f90 > real*8 :: x = 10.0e9 > do i = 10, 22 > x = 10d0 * x > print '(a,i2,a,g14.8," = ",g14.8)', "mod (10**",i,", 1.7_8) = ", & > fmod (x, 1.7_8), mod > (x, 1.7_8); > end do > end > $ cat a.c > #include <math.h> > double fmod_ (double *x, double *y) > { return fmod(*x,*y); } > $ gfortran a.f90 a.c && ./a.out > mod (10**10, 1.7_8) = 1.3000026 = 1.3000026 > mod (10**11, 1.7_8) = 1.1000261 = 1.1000261 > mod (10**12, 1.7_8) = 0.80026120 = 0.80026150 > mod (10**13, 1.7_8) = 1.2026123 = 1.2026138 > mod (10**14, 1.7_8) = 0.12612289 = 0.12609863 > mod (10**15, 1.7_8) = 1.2612289 = 1.2607422 > mod (10**16, 1.7_8) = 0.71228945 = 5.8125000 > mod (10**17, 1.7_8) = 0.32289469 = -50.687500 > mod (10**18, 1.7_8) = 1.5289470 = 364.00000 > mod (10**19, 1.7_8) = 1.6894697 = -.70000000E+20 > mod (10**20, 1.7_8) = 1.5946971 = -.70000000E+21 > mod (10**21, 1.7_8) = 0.64697063 = -.70000000E+22 > mod (10**22, 1.7_8) = 0.86970627 = -.70000000E+23 > > It's actually slower: 55% slower at -O0 and 230% slower at > -O2, on a loop with > real(kind=8) variables modulo. But then, we're already > testing whether the > division can be represented by an integer, we could call fmod > only in the case > where it's not possible. Opinions? > > > -- > > fxcoudert at gcc dot gnu dot org changed: > > What |Removed |Added > -------------------------------------------------------------- > -------------- > CC| |fxcoudert at > gcc dot gnu dot > | |org > Last reconfirmed|2006-01-24 04:26:11 |2006-06-20 12:22:57 > date| | > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24518 > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. >
Having thought about it some more, MODULO should be implemented using fmod{f,,l} and MOD should use remainder{f,,l}. See how BUILT_IN_POWL is used, for example, to emit the same kind of code in gfc_conv_intrinsic_mod. Beginner project for someone? :)
Created attachment 12477 [details] Example patch I don't know if it's giving correct results in all cases, or if it works even on platforms without C99 math functions, but the idea is here.
Revision 118024 clears the way for MOD and MODULO implementation: http://gcc.gnu.org/ml/gcc-cvs/2006-10/msg00703.html BTW: I don't know fortran requirements, but built-in functions produce faster code if errno is not needed. -mno-math-errno should be used in this case.
I'm adding Steve Kargl to the CC list, since he's our arithmetics expert :) (In reply to comment #6) > Revision 118024 clears the way for MOD and MODULO implementation: > http://gcc.gnu.org/ml/gcc-cvs/2006-10/msg00703.html Just to be sure I understand: we are garanteed that BUILT_IN_REMAINDER{F,,L} and BUILT_IN_FMOD{F,,L} are always available, right? > BTW: I don't know fortran requirements, but built-in functions produce faster > code if errno is not needed. -mno-math-errno should be used in this case. [Hum... I think you mean -fno-math-errno.] gfortran doesn't have a need for errno to be set after math functions are called. However, we do want that have "correct" results in all cases: Inf, NaN, subnormals, etc. From my reading of the manual, -fno-math-errno would imply that we do not get such correct results, am I right?
(In reply to comment #7) > Just to be sure I understand: we are garanteed that BUILT_IN_REMAINDER{F,,L} > and BUILT_IN_FMOD{F,,L} are always available, right? Yes. The expansion does not depend on -ffast-math anymore. However, the named pattern should be present in .md files. Currently, i386 provides named pattern for -mfpmath=387, but not for -mfpmath=sse. In the later case, expansion will fall-back to normal library call. > gfortran doesn't have a need for errno to be set after math functions are > called. However, we do want that have "correct" results in all cases: Inf, > NaN, subnormals, etc. From my reading of the manual, -fno-math-errno would > imply that we do not get such correct results, am I right? Fortunatelly, no. The result will be correct. You can see the effect of -fno-math-errno at http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01158.html. Fixup code detects NaN (as an abnormal return from builtin funcion) and calls library function in order to set global variable errno. If global variable errno is not needed (as I suspect is the case with fortran libraries), fixup code is not needed, so -fno-math-errno shoul be used.
(In reply to comment #8) > In the later case, expansion will fall-back to normal library call. OK. So on system where the math library doesn't have remainderl, for example, we shouldn't use BUILT_IN_REMAINDERL or it will be missing at link-time? If that's the case, then we can't implement MOD/MODULO with these built-ins. > Fortunatelly, no. The result will be correct. You can see the effect of > -fno-math-errno at http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01158.html. And now, a harder question: could we activate no-math-errno on a per-call basis? That is, have the front-end emit a call to BUILT_IN_FOO and specify that, for this call, errno doesn't have to be set?
(In reply to comment #9) > > In the later case, expansion will fall-back to normal library call. > > OK. So on system where the math library doesn't have remainderl, for example, > we shouldn't use BUILT_IN_REMAINDERL or it will be missing at link-time? If > that's the case, then we can't implement MOD/MODULO with these built-ins. You can check for TARGET_C99_FUNCTIONS before they are used. > > Fortunatelly, no. The result will be correct. You can see the effect of > > -fno-math-errno at http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01158.html. > > And now, a harder question: could we activate no-math-errno on a per-call > basis? That is, have the front-end emit a call to BUILT_IN_FOO and specify > that, for this call, errno doesn't have to be set? errno expansion for this particular built-in is inhibited in line 1995 of builtins.c. For a per-call basis, we need an argument to expand_builtin() function to disable errno expansion. However, the rationale for this is unclear to me. IMO - either we use errno, or we don't.
Subject: Re: Intrinsic MOD incorrect for large arg1/arg2 and slow. On Wed, Oct 25, 2006 at 08:19:21AM -0000, fxcoudert at gcc dot gnu dot org wrote: > > I'm adding Steve Kargl to the CC list, since he's our arithmetics expert :) You flatter me. :-O > > (In reply to comment #6) > > Revision 118024 clears the way for MOD and MODULO implementation: > > http://gcc.gnu.org/ml/gcc-cvs/2006-10/msg00703.html > > Just to be sure I understand: we are garanteed that BUILT_IN_REMAINDER{F,,L} > and BUILT_IN_FMOD{F,,L} are always available, right? If a target supports the builtin, then gfortran can be made to use it. In fact, you can't disable builtins. troutmask:sgk[274] gfc -fno-builtin -c sqrt90.f90 f951: warning: command line option "-fno-builtin" is valid for C/C++/ObjC/ObjC++ but not for Fortran If a target does not have builtins for fmod and remainder and configure provides HAVE_FMOD and HAVE_REMAINDER macros, gfortranr could punt to library routines like we do for spacing, rrspacing, etc.
FX and Steve, I'll dig out my version of MOD and MODULO that uses the library call, if you like. The availability of the builtin can be tested and the existing call used, if not present. That I already did because MODULO was not available. As soo as I am home, I will have a root around. Paul PS Thanks again for remembering us Uros.
Just some performance numbers (sorry for the C testcase...) on x86_64: --cut here-- #include <math.h> #include <stdio.h> int main() { double x; double t = 0.0; for (x = 10000000.0; x > 0.0; x -= 1.0) t += fmod (x, 1.7e-8); printf("%f\n", t); return 0; } --cut here-- [uros@localhost x86_64-test]$ gcc -march=k8 -O2 -lm mod.c [uros@localhost x86_64-test]$ time ./a.out 0.089927 real 0m4.304s user 0m4.294s sys 0m0.009s [uros@localhost x86_64-test]$ gcc -march=k8 -O2 -lm -mfpmath=387 mod.c [uros@localhost x86_64-test]$ time ./a.out 0.089927 real 0m0.351s user 0m0.349s sys 0m0.002s I know that this measurement depends on the library implementation, but this is current situation, where above tests shows that intrinsic MOD is 12.3 _times_ faster.
Created attachment 12518 [details] A fix for the PR: FX and Uros, I believe that this correctly detects the presence of the built_in. It also does MODULO correctly, although I am not sure that I understand why anybody would use this intrinsic knowingly! I have not done a full regtest, nor checked the timing yet, but the testsuite cases with MOD and MODULO in them all survive. Paul
(In reply to comment #14) > It also does MODULO correctly Why not use remainder{f,,l}? Is it incorrect? > although I am not sure that I understand why anybody > would use this intrinsic knowingly! Agreed :)
Subject: RE: Intrinsic MOD incorrect for large arg1/arg2 and slow. FX, > > ------- Comment #15 from fxcoudert at gcc dot gnu dot org > 2006-10-31 16:05 ------- > (In reply to comment #14) > > It also does MODULO correctly > > Why not use remainder{f,,l}? Is it incorrect? I understood that remainder (a, b) = a - round (a/b) * b, whereas mod (a, b) = a - int (a/b) * b and modulo (a, b) = a - floor (a/b) * b but I am ready to stand corrected on the first. The latter two are taken from the fortran standard. Paul
The fortran version of Uros' #13: real(8) :: x real(8) :: t = 0.0 x = 10000000.0 do while (x > 0.0) t = t + mod (x, 1.7e-8) x = x - 1.0 end do print *, t end Yields: $ /irun/bin/gfortran -O2 -march=pentium -mfpmath=387 uros_test.f90 PT169137@PC-THOMAS-P /cygdrive/d/svn/pr24518 $ time ./a 8.499998368231765E-002 real 0m0.344s user 0m0.327s sys 0m0.015s on a PIV running at 2.5GHz Changing MOD => MODULO, the user time increases to 0.405s for the implementation in the second attachment. Paul
(In reply to comment #16) > I understood that remainder (a, b) = a - round (a/b) * b, whereas > mod (a, b) = a - int (a/b) * b > and modulo (a, b) = a - floor (a/b) * b Right you are, master. :)
Subject: Bug 24518 Author: pault Date: Sun Nov 5 06:27:48 2006 New Revision: 118492 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118492 Log: 2006-11-05 Francois-Xavier Coudert <fxcoudert@gcc.gnu,org> Paul Thomas <pault@gcc.gnu.org> PR fortran/24518 * trans-intrinsic.c (gfc_conv_intrinsic_mod): Use built_in fmod for both MOD and MODULO, if it is available. PR fortran/29565 * trans-expr.c (gfc_conv_aliased_arg): For an INTENT(OUT), save the declarations from the unused loops by merging the block scope for each; this ensures that the temporary is declared. 2006-11-05 Paul Thomas <pault@gcc.gnu.org> PR fortran/29565 * gfortran.dg/gfortran.dg/aliasing_dummy_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/aliasing_dummy_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/f95-lang.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog
Subject: Bug 24518 Author: pault Date: Sun Nov 5 08:46:02 2006 New Revision: 118493 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118493 Log: 2006-11-05 Francois-Xavier Coudert <fxcoudert@gcc.gnu,org> Paul Thomas <pault@gcc.gnu.org> PR fortran/24518 * trans-intrinsic.c (gfc_conv_intrinsic_mod): Use built_in fmod for both MOD and MODULO, if it is available. 2006-11-05 Paul Thomas <pault@gcc.gnu.org> PR fortran/29565 * trans-expr.c (gfc_conv_aliased_arg): For an INTENT(OUT), save the declarations from the unused loops by merging the block scope for each; this ensures that the temporary is declared. PR fortran/29387 * trans-intrinsic.c (gfc_conv_intrinsic_len): Rearrange to have a specific case for EXPR_VARIABLE and, in default, build an ss to call gfc_conv_expr_descriptor for array expressions.. PR fortran/29490 * trans-expr.c (gfc_set_interface_mapping_bounds): In the case that GFC_TYPE_ARRAY_LBOUND is not available, use descriptor values for it and GFC_TYPE_ARRAY_UBOUND. PR fortran/29641 * trans-types.c (gfc_get_derived_type): If the derived type namespace has neither a parent nor a proc_name, set NULL for the search namespace. 2006-11-05 Paul Thomas <pault@gcc.gnu.org> PR fortran/29565 * gfortran.dg/gfortran.dg/aliasing_dummy_3.f90: New test. PR fortran/29387 * gfortran.dg/intrinsic_actual_2.f90: New test. PR fortran/29490 * gfortran.dg/actual_array_interface_1.f90: New test. PR fortran/29641 * gfortran.dg/used_types_11.f90: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/actual_array_interface_1.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/aliasing_dummy_3.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/intrinsic_actual_2.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/used_types_11.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/f95-lang.c branches/gcc-4_2-branch/gcc/fortran/trans-expr.c branches/gcc-4_2-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_2-branch/gcc/fortran/trans-types.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog
Fixed on trunk and 4.2 - will soon be fixed on 4.1. Paul
Subject: Bug 24518 Author: pault Date: Fri Nov 10 21:52:00 2006 New Revision: 118666 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118666 Log: 2006-11-10 Paul Thomas <pault@gcc.gnu.org> Backport from mainline. PR fortran/29371 * trans-expr.c (gfc_trans_pointer_assignment): Add the expression for the assignment of null to the data field to se->pre, rather than block. PR fortran/29392 * data.c (create_character_intializer): Copy and simplify the expressions for the start and end of a sub-string reference. PR fortran/29216 PR fortran/29314 * gfortran.h : Add EXEC_INIT_ASSIGN. * dump-parse-tree.c (gfc_show_code_node): The same. * trans-expr.c (gfc_trans_init_assign): New function. * trans-stmt.h : Add prototype for gfc_trans_init_assign. * trans.c (gfc_trans_code): Implement EXEC_INIT_ASSIGN. * resolve.c (resolve_allocate_exp): Replace EXEC_ASSIGN by EXEC_INIT_ASSIGN. (resolve_code): EXEC_INIT_ASSIGN does not need resolution. (apply_default_init): New function. (resolve_symbol): Call it for derived types that become defined but which do not already have an initialization expression.. * st.c (gfc_free_statement): Include EXEC_INIT_ASSIGN. PR fortran/29387 * trans-intrinsic.c (gfc_conv_intrinsic_len): Rearrange to have a specific case for EXPR_VARIABLE and, in default, build an ss to call gfc_conv_expr_descriptor for array expressions.. PR fortran/29490 * trans-expr.c (gfc_set_interface_mapping_bounds): In the case that GFC_TYPE_ARRAY_LBOUND is not available, use descriptor values for it and GFC_TYPE_ARRAY_UBOUND. PR fortran/29641 * trans-types.c (gfc_get_derived_type): If the derived type namespace has neither a parent nor a proc_name, set NULL for the search namespace. PR fortran/24518 * trans-intrinsic.c (gfc_conv_intrinsic_mod): Use built_in fmod for both MOD and MODULO, if it is available. PR fortran/29565 * trans-expr.c (gfc_conv_aliased_arg): For an INTENT(OUT), save the declarations from the unused loops by merging the block scope for each; this ensures that the temporary is declared. 2006-11-10 Paul Thomas <pault@gcc.gnu.org> PR fortran/29371 * gfortran.dg/nullify_3.f90: New test. PR fortran/29392 * gfortran.dg/data_char_3.f90: New test. PR fortran/29216 * gfortran.dg/result_default_init_1.f90: New test. PR fortran/29314 * gfortran.dg/automatic_default_init_1.f90: New test. PR fortran/29387 * trans-intrinsic.c (gfc_conv_intrinsic_len): Rearrange to have a specific case for EXPR_VARIABLE and, in default, build an ss to call gfc_conv_expr_descriptor for array expressions.. PR fortran/29490 * trans-expr.c (gfc_set_interface_mapping_bounds): In the case that GFC_TYPE_ARRAY_LBOUND is not available, use descriptor values for it and GFC_TYPE_ARRAY_UBOUND. PR fortran/29641 * trans-types.c (gfc_get_derived_type): If the derived type namespace has neither a parent nor a proc_name, set NULL for the search namespace. PR fortran/29565 * gfortran.dg/gfortran.dg/aliasing_dummy_3.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/actual_array_interface_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/aliasing_dummy_3.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/automatic_default_init_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/data_char_3.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/intrinsic_actual_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/nullify_3.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/result_default_init_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/used_types_11.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/used_types_12.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/data.c branches/gcc-4_1-branch/gcc/fortran/dump-parse-tree.c branches/gcc-4_1-branch/gcc/fortran/f95-lang.c branches/gcc-4_1-branch/gcc/fortran/gfortran.h branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/st.c branches/gcc-4_1-branch/gcc/fortran/trans-expr.c branches/gcc-4_1-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.h branches/gcc-4_1-branch/gcc/fortran/trans-types.c branches/gcc-4_1-branch/gcc/fortran/trans.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog
Just to let you know that the Fortran compiler has been broken for about a month on all Solaris versions (except release 10) with: Undefined first referenced symbol in file fmodf /opt/build/eric/gcc/sparc64-sun-solaris2.9/. /libgfortran/.libs/libgfortran.so fmodl /opt/build/eric/gcc/sparc64-sun-solaris2.9/. /libgfortran/.libs/libgfortran.so ld: fatal: Symbol referencing errors. No output written to ./PR19754_2.exe collect2: ld returned 1 exit status compiler exited with status 1 NAME fmod, fmodf, fmodl - floating-point remainder function CONFORMING TO SVID 3, POSIX, BSD 4.3, ISO 9899. The float and the long double vari- ants are C99 requirements. Given that you guys regularly break the compiler on non-C99 platforms, I'd suggest to arrange for having your changes tested on one of them beforehand, possibly by asking Laurent Guerby of the CompileFarm project to install an old Linux distro on one of his old machine.
(In reply to comment #23) > Just to let you know that the Fortran compiler has been broken for about a > month on all Solaris versions (except release 10) with I just filled this as PR30048.
Author: jb Date: Sat May 5 07:59:22 2012 New Revision: 187191 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187191 Log: PR 49010,24518 MOD/MODULO fixes. gcc/fortran: 2012-05-05 Janne Blomqvist <jb@gcc.gnu.org> PR fortran/49010 PR fortran/24518 * intrinsic.texi (MOD, MODULO): Mention sign and magnitude of result. * simplify.c (gfc_simplify_mod): Use mpfr_fmod. (gfc_simplify_modulo): Likewise, use copysign to fix the result if zero. * trans-intrinsic.c (gfc_conv_intrinsic_mod): Remove fallback as builtin_fmod is always available. For modulo, call copysign to fix the result when signed zeros are enabled. testsuite: 2012-05-05 Janne Blomqvist <jb@gcc.gnu.org> PR fortran/49010 PR fortran/24518 * gfortran.dg/mod_sign0_1.f90: New test. * gfortran.dg/mod_large_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/mod_large_1.f90 trunk/gcc/testsuite/gfortran.dg/mod_sign0_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.texi trunk/gcc/fortran/simplify.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog