| Message ID | 20111226161446.812E33BE18@mailhost.lps.ens.fr |
|---|---|
| State | New |
| Headers | show |
On Mon, Dec 26, 2011 at 05:14:46PM +0100, Dominique Dhumieres wrote: > > I regression tested the patch on i686-*-freebsd. No problems occurred. > > Can one of the other gfortran reviewers/committers cast a quick glance > > over the patch. I would like to commit this within next day or two. > > I have applied the patch on trunk (incremental update). I did not get any > regression on x86_64-apple-darwin10 with either -m32 or -m64. Thanks for testing. > I get > > === gfortran Summary for unix/-m32/-finteger-4-integer-8 === > > # of expected passes 37336 > # of unexpected failures 896 > # of expected failures 39 > # of unresolved testcases 1 > # of unsupported tests 570 > > === gfortran Summary for unix/-m64/-finteger-4-integer-8 === > > # of expected passes 37728 > # of unexpected failures 840 > # of expected failures 39 > # of unsupported tests 409 > > related to pr32770. > > I did not have the time to go through the details of the failures, but > (1) there are a few ICEs after error as in > > FAIL: gfortran.dg/coarray/image_index_1.f90 -fcoarray=lib -O2 -lcaf_single (internal compiler error) > Excess errors: > /opt/gcc/work/gcc/testsuite/gfortran.dg/coarray/image_index_1.f90:14:0:0: error: mismatching comparison operand types > integer(kind=4) > integer(kind=8) > one = _gfortran_caf_num_images.66 == 1; > ... > /opt/gcc/work/gcc/testsuite/gfortran.dg/coarray/image_index_1.f90:14:0:0: error: mismatching comparison operand types > integer(kind=8) > integer(kind=4) > D.2567 = D.2100 <= _gfortran_caf_num_images.66; > /opt/gcc/work/gcc/testsuite/gfortran.dg/coarray/image_index_1.f90:14:0:0: internal compiler error: verify_gimple failed > > These ICEs on invalid occur mostly in coarray tests, but I also see > > FAIL: gfortran.dg/popcnt_poppar_2.F90 -O0 (internal compiler error) > FAIL: gfortran.dg/popcnt_poppar_2.F90 -O0 (test for excess errors) > Excess errors: > /opt/gcc/work/gcc/testsuite/gfortran.dg/popcnt_poppar_2.F90:30:0:0: error: type mismatch in binary expression > integer(kind=8) > integer(kind=4) > integer(kind=4) > res = D.1935 + D.1938; > /opt/gcc/work/gcc/testsuite/gfortran.dg/popcnt_poppar_2.F90:30:0:0: internal compiler error: verify_gimple failed > > I think the errors are exepcted, but gfortran should exit without ICE. I'll` > fill a pr when the patch will be committed. This is worrisome. These types of options go from debugging aids to people depending on them for production codes. I'll seee if I can reproduce some of yor observation to try to understand the issues. > The manual could probably lists some expected breakages such as this one. Good point. I'll update the manual to indicate that these options are intended for debugging purposes and that there are known issues. > > The difference between -fdefault-*-8 and -f*-4-*-8 should probably also be documented. > It is documented for the -freal-* options. The manual has, for example, -freal-4-real-8 Promote REAL(KIND=4) entities to REAL(KIND=8) entities. If KIND=8 is unavail- able, then an error will be issued. All other real kind types are unaffected by this option. The last sentence is the same for the other options. This literally means that only REAL(4) is effected by the -freal-4-real-8 option. If one reads he description of -fdefault-*, one will that -freal-4-real-8 is equivalent to specifying both -fdefault-real-8 and -fdefault-double-8. > Last point for this batch is that using '-freal-8-real-10 -freal-8-real-16' does not > generate an error, the last option being the one used. Yes, that is correct. Consider it to be similar to '-Os -O -O2 -O0'. The last one wins. Note, there is this combination: '-freal-4-real-8 -freal-8-real-16' which will promote both REAL(4) and (8) to REAL(16).
On Mon, Dec 26, 2011 at 09:28:01AM -0800, Steve Kargl wrote: > On Mon, Dec 26, 2011 at 05:14:46PM +0100, Dominique Dhumieres wrote: > > > I regression tested the patch on i686-*-freebsd. No problems occurred. > > > Can one of the other gfortran reviewers/committers cast a quick glance > > > over the patch. I would like to commit this within next day or two. > > > > I have applied the patch on trunk (incremental update). I did not get any > > regression on x86_64-apple-darwin10 with either -m32 or -m64. > > Thanks for testing. > > > I get > > > > === gfortran Summary for unix/-m32/-finteger-4-integer-8 === > > > > # of expected passes 37336 > > # of unexpected failures 896 > > # of expected failures 39 > > # of unresolved testcases 1 > > # of unsupported tests 570 > > In gfortran.fortran-torture/execute, I did the simply test of #! /bin/csh foreach i (*.f90) echo $i gfortran -O -finteger-4-integer-8 -o z $i ./z end These 6 tests all aborted: intrinsic_bitops.f90 intrinsic_leadz.f90 intrinsic_si_kind.f90 intrinsic_trailz.f90 iolength_1.f90 iolength_2.f90 iolength_3.f90 There were no ICE's. Inspection of the tests show that indeed the programs should abort. For example, the guts of iolength_3.f90 are integer, parameter :: int32 = selected_int_kind(9) integer(int32) :: a, b, iol real(dp) :: c inquire (iolength = iol) a, b, c if ( 16 /= iol) then call abort end if With -finteger-4-integer-8, iol should be 24.
Hi all, Attached are three test file, that stress the type-promotion patch. >> The difference between -fdefault-*-8 and -f*-4-*-8 should probably also be documented. >> > > It is documented for the -freal-* options. The manual has, for example, > > -freal-4-real-8 > Promote REAL(KIND=4) entities to REAL(KIND=8) entities. If KIND=8 is unavail- > able, then an error will be issued. All other real kind types are unaffected > by this option. > > The last sentence is the same for the other options. This literally means > that only REAL(4) is effected by the -freal-4-real-8 option. If one reads > he description of -fdefault-*, one will that -freal-4-real-8 is equivalent > to specifying both -fdefault-real-8 and -fdefault-double-8. > -freal-4-real-8 is not equivalent to -fdefault-real-8 and -fdefault-double-8. -freal-4-real-8 interprets any 4-byte real type, whether it is a default real type or explicitly declared as 4-byte, as a 8-byte double precision type, and that applies to all variables, functions and constants. -fdefault-real-8 will promote only default real type to double precision and only variables and functions. Since constants are usually declared explicitly as 4-byte, e.g. 1.01223e0 is an explicitly defined 4-byte constant in gfortran, they will not be promoted. $ gfortran -freal-4-real-8 test-r4.f $ a.out 0.90929742682568171 0.90929742682568171 0.0000000000000000 0.0000000000000000 0.0000000000000000 0.0000000000000000 0.0000000000000000 0.0000000000000000 0.0000000000000000 0.0000000000000000 but $ gfortran -fdefault-real-8 -fdefault-double-8 test-r4.f $ a.out 0.90929742682568171 0.90929741 -2.01522503129325514E-008 -2.01522503129325514E-008 -2.01522503129325514E-008 -2.01522503129325514E-008 -2.01522503129325514E-008 -2.01522503129325514E-008 -2.01522503129325514E-008 -2.01522503129325514E-008 Note how constants are truncated to single precision, while using -fdefault-real-8 -fdefault-double-8. The same promotion convention applies to other -freal-*-real-*, and -finteger-*-integer-* flags. For example, -fdefault-integer-8 is not equivalent to -finteger-4-integer-8, because integer*4 types and constants are being interpreted in a different way, see test-i4.f test: $ gfortran -fdefault-integer-8 test-i4.f test-i4.f:6.8: j=2**40 1 Error: Arithmetic overflow converting INTEGER(8) to INTEGER(4) at (1). This check can be disabled with the option -fno-range-check The error above is due to inability of standard gfortran to promote explicitly declared integer*4 type to integer*8. $ gfortran -finteger-4-integer-8 test-i4.f $ a.out 1099511627776 1099511627776 This fixes the above problem. Finally, $ gfortran -freal-8-real-16 test-r8.f $ a.out 0.90929742682568169539601986591174487 0.90929742682568169539601986591174487 0.0000000000000000000000000000000000 0.0000000000000000000000000000000000 0.0000000000000000000000000000000000 0.0000000000000000000000000000000000 0.0000000000000000000000000000000000 0.0000000000000000000000000000000000 0.0000000000000000000000000000000000 0.0000000000000000000000000000000000 We have nothing to compare this result with since, currently, gfortran has no facility to promote double precision to real*16 (no -fdefault-double-16 flag). >> Last point for this batch is that using '-freal-8-real-10 -freal-8-real-16' does not >> generate an error, the last option being the one used. > > Yes, that is correct. Consider it to be similar to '-Os -O -O2 -O0'. The > last one wins. Note, there is this combination: '-freal-4-real-8 -freal-8-real-16' > which will promote both REAL(4) and (8) to REAL(16). > One caveat here, we have not attempted to chain constant conversion in this patch. This combination will promote real*4 constants to real*8, and real*8 constants to real*16, $ gfortran -freal-4-real-8 -freal-8-real-16 test-r4.f $ a.out 0.90929742682568169539601986591174487 0.90929742682568169539601986591174487 0.0000000000000000000000000000000000 0.0000000000000000000000000000000000 1.40209065578162555042101269140459185E-0017 <- constant truncation 0.0000000000000000000000000000000000 1.40209065578162555042101269140459185E-0017 <- constant truncation 0.0000000000000000000000000000000000 0.0000000000000000000000000000000000 0.0000000000000000000000000000000000 While this combination will promote real*4 constants to real*16, and real *8 constants to real*16, $ gfortran -freal-4-real-16 -freal-8-real-16 test-r4.f $ a.out 0.90929742682568169539601986591174487 0.90929742682568169539601986591174487 0.0000000000000000000000000000000000 0.0000000000000000000000000000000000 0.0000000000000000000000000000000000 0.0000000000000000000000000000000000 0.0000000000000000000000000000000000 0.0000000000000000000000000000000000 0.0000000000000000000000000000000000 0.0000000000000000000000000000000000 The second promotion declaration is cleaner, but the declaration chaining may be worth the effort. The patch has been tested on Fortran 77 and Fortran 95 codes, so as for the errors in coarray tests, it is quite possible that we have simply missed some kind of type processing/declaration since this is a relative new Fortran feature, sorry about that. Zydrunas
> -freal-4-real-8 is not equivalent to -fdefault-real-8 and -fdefault-double-8. > > -freal-4-real-8 interprets any 4-byte real type, whether it is a > default real type or explicitly declared as 4-byte, as a 8-byte double > precision type, and that applies to all variables, functions and > constants. > > -fdefault-real-8 will promote only default real type to double > precision and only variables and functions. Since constants are > usually declared explicitly as 4-byte, e.g. 1.01223e0 is an explicitly > defined 4-byte constant in gfortran, they will not be promoted. I agree with the above and I think this should go into the manual. One thing which can be done with -fdefault-real-8, but not with -freal-4-real-8 is to work around some pitfalls of these otions by specifying explicit kinds when needed (this probably explains why less tests fail with the former option than with the later, see results at the end of this mail). In my opinion, these options, while useful, have several pitfalls: (1) call to external procedures (especially in libraries), (2) alignements in EQUIVALENCE and/or COMMON, (3) generic interfaces, (4) BOZ, (5) I/Os, (6) ... I wonder if they should not have their own page in the manual with a big warning at the beginning telling the user that these options are likely to break "legacy" codes. The raw test results are the following make -k check-gfortran RUNTESTFLAGS="--target_board=unix'{-m32/-finteger-4-integer-8, -m64/-finteger-4-integer-8,-m32/-freal-4-real-8,-m64/-freal-4-real-8,-m32/-freal-8-real-10,-m64/-freal-8-real-10}'" === gfortran Summary for unix/-m32/-finteger-4-integer-8 === # of expected passes 37336 # of unexpected failures 896 # of expected failures 39 # of unresolved testcases 1 # of unsupported tests 570 === gfortran Summary for unix/-m64/-finteger-4-integer-8 === # of expected passes 37728 # of unexpected failures 840 # of expected failures 39 # of unsupported tests 409 === gfortran Summary for unix/-m32/-freal-4-real-8 === # of expected passes 37526 # of unexpected failures 702 # of expected failures 39 # of unsupported tests 570 === gfortran Summary for unix/-m64/-freal-4-real-8 === # of expected passes 37857 # of unexpected failures 698 # of expected failures 39 # of unsupported tests 409 === gfortran Summary for unix/-m32/-freal-8-real-10 === # of expected passes 37928 # of unexpected failures 394 # of expected failures 39 # of untested testcases 8 # of unsupported tests 570 === gfortran Summary for unix/-m64/-freal-8-real-10 === # of expected passes 38300 # of unexpected failures 357 # of expected failures 39 # of untested testcases 8 # of unsupported tests 409 === gfortran Summary === # of expected passes 226675 # of unexpected failures 3887 # of expected failures 234 # of unresolved testcases 1 # of untested testcases 16 # of unsupported tests 2937 to be compared with make -k check-gfortran RUNTESTFLAGS="--target_board=unix'{-m32/-fdefault-integer-8, -m64/-fdefault-integer-8,-m32/-fdefault-real-8,-m64/-fdefault-real-8}'" === gfortran Summary for unix/-m32/-fdefault-integer-8 === # of expected passes 37794 # of unexpected failures 489 # of expected failures 39 # of unresolved testcases 24 # of unsupported tests 570 === gfortran Summary for unix/-m64/-fdefault-integer-8 === # of expected passes 38111 # of unexpected failures 499 # of expected failures 39 # of unresolved testcases 24 # of unsupported tests 409 === gfortran Summary for unix/-m32/-fdefault-real-8 === # of expected passes 37705 # of unexpected failures 539 # of expected failures 39 # of untested testcases 8 # of unsupported tests 570 === gfortran Summary for unix/-m64/-fdefault-real-8 === # of expected passes 38028 # of unexpected failures 535 # of expected failures 39 # of untested testcases 8 # of unsupported tests 409 === gfortran Summary === # of expected passes 151638 # of unexpected failures 2062 # of expected failures 156 # of unresolved testcases 48 # of untested testcases 16 # of unsupported tests 1958 I did not have the time to look in detail to the results. From a quick glance I can tell that there are overlaps between the failures of -fdefault-*-8 and -f*-4-*-8. In particular the ICEs with coarray appear for both cases (I have open pr51682). Dominique
On Tue, Dec 27, 2011 at 6:52 AM, Dominique Dhumieres <dominiq@lps.ens.fr> wrote: >> -freal-4-real-8 is not equivalent to -fdefault-real-8 and -fdefault-double-8. >> >> -freal-4-real-8 interprets any 4-byte real type, whether it is a >> default real type or explicitly declared as 4-byte, as a 8-byte double >> precision type, and that applies to all variables, functions and >> constants. >> >> -fdefault-real-8 will promote only default real type to double >> precision and only variables and functions. Since constants are >> usually declared explicitly as 4-byte, e.g. 1.01223e0 is an explicitly >> defined 4-byte constant in gfortran, they will not be promoted. > > I agree with the above and I think this should go into the manual. One > thing which can be done with -fdefault-real-8, but not with > -freal-4-real-8 is to work around some pitfalls of these otions by > specifying explicit kinds when needed (this probably explains why less > tests fail with the former option than with the later, see results at the > end of this mail). > That is correct. -fdefault-real-8 provides a finely tuned type promotion mechanism, while -freal-*-real-* overrides all type definitions via brute force. We actually like that: some of the codes we have date back to the 70's, we don't want to convert them into Fortran 95 and/or maintain several copies with different type definitions - this is just too expensive and time consuming. In such cases, we really do want to override all old-style definitions. In our work, this doesn't happen often, usually, we are running our code in double precision, but from time to time we would like to raise precision to pre-compute tables with more digits or to investigate ill-conditioning and numerical stability issues. > In my opinion, these options, while useful, have several pitfalls: > > (1) call to external procedures (especially in libraries), > (2) alignements in EQUIVALENCE and/or COMMON, > (3) generic interfaces, > (4) BOZ, > (5) I/Os, > (6) ... > > I wonder if they should not have their own page in the manual with a big > warning at the beginning telling the user that these options are likely to > break "legacy" codes. > We do recompile all codes with the promotion flags to address this, usually, with only minor modifications. Things like calls to external C functions need to be fixed, although this is also needed if using -fdefault-* flags. Alignment could be also a problem, especially if promoting to quad precision which currently requires 128-bit variable aligment, again this also might also happen with -fdefault-* flags. The user has to be somewhat aware of this and adjust the code accordingly. We tend to ignore such issues in practice and proceed anyway with fingers crossed: everything works 90% of the time just fine! Zydrunas
On Tue, Dec 27, 2011 at 12:52:19PM +0100, Dominique Dhumieres wrote: > > -freal-4-real-8 is not equivalent to -fdefault-real-8 and -fdefault-double-8. > > > > -freal-4-real-8 interprets any 4-byte real type, whether it is a > > default real type or explicitly declared as 4-byte, as a 8-byte double > > precision type, and that applies to all variables, functions and > > constants. > > > > -fdefault-real-8 will promote only default real type to double > > precision and only variables and functions. Since constants are > > usually declared explicitly as 4-byte, e.g. 1.01223e0 is an explicitly > > defined 4-byte constant in gfortran, they will not be promoted. > > I agree with the above and I think this should go into the manual. One > thing which can be done with -fdefault-real-8, but not with > -freal-4-real-8 is to work around some pitfalls of these otions by > specifying explicit kinds when needed (this probably explains why less > tests fail with the former option than with the later, see results at the > end of this mail). AFAICT, the whole point of these options is to promote everything, so one doesn't need to remember, for example, if literal constants, which are declarated with kind suffixes, are promoted or not. I don't see that as a pitfall. If one is testing the stability or accuracy of an algorithm, then promoting 'x = 1._4 / 1._4' may be important. Consider program k real x x = 1._4 / 3._4 end program k gfc4x -c -fdump-tree-original -fdefault-real-8 k.f90 real(kind=8) x; x = 3.333333432674407958984375e-1; gfc4x -c -fdump-tree-original -freal-4-real-8 k.f90 real(kind=8) x; x = 3.33333333333333314829616256247390992939472198486328125e-1; The difference is one heck of alot of ULPs. > In my opinion, these options, while useful, have several pitfalls: > > (1) call to external procedures (especially in libraries), > (2) alignements in EQUIVALENCE and/or COMMON, > (3) generic interfaces, > (4) BOZ, > (5) I/Os, > (6) ... One needs to worry about these things with the -fdefault-* options as well. In particular, anything that may depend on NUMERIC_STORAGE_SIZE will present a problem, because it is always set to 32 (except on a possibly pathological target without a 32-bit float type). > I wonder if they should not have their own page in the manual with a big > warning at the beginning telling the user that these options are likely to > break "legacy" codes. These options as well as the -fdefault-* are likely to break any Fortran code. It is up to the user to test whether these options are suitable for his/her purpose. I'll update the manual with a sentence of the form: "This option should be used with case and may not be suitable for codes. Inspection of the intermediate representation of the translated Fortran code, produced by the -fdump-tree-original option, is suggested." > === gfortran Summary for unix/-m32/-finteger-4-integer-8 === > > # of expected passes 37336 > # of unexpected failures 896 > # of expected failures 39 > # of unresolved testcases 1 > # of unsupported tests 570 > Well, I think you'll find a large number of these unexpected failures are due to hard coded assumptions about sizeof(INTEGER) etc. All of the failures I saw in gfortran.fortran-torture were of this variety.
--- /opt/gcc/_clean/gcc/testsuite/lib/prune.exp 2011-10-17 12:04:23.000000000 +0200 +++ /opt/gcc/work/gcc/testsuite/lib/prune.exp 2011-12-26 13:59:57.000000000 +0100 @@ -42,6 +42,9 @@ proc prune_gcc_output { text } { regsub -all "(^|\n)\[^\n\]*: Additional NOP may be necessary to workaround Itanium processor A/B step errata" $text "" text regsub -all "(^|\n)\[^\n*\]*: Assembler messages:\[^\n\]*" $text "" text + # Ignore warning for gfortran options passed to the C compilers. + regsub -all "(^|\n)cc1: warning: command line option .-f\[^\"\]*. is valid for Fortran but not for C\[^\n\]*" $text "" text + # Ignore second line of IRIX 6 linker multiline message. regsub -all "(^|\n)\[ \t\]*that might degrade performance on an older version \\(rev. 2.2\\) R4000 processor.\[^\n\]*" $text "" text