Re: [patch] Flag-controlled type conversions/promotions
On Sun, Jan 15, 2012 at 01:39:23PM -0500, Zydrunas Gimbutas wrote: > Hi, > > Everything seems to be ok in this patch, except for minor typos in > documentation: REAl -> REAL, alignement -> alignment. Good catch. > It would also be nice to extend the type conversion facility to > include -fdefault-real-16, -fdefault-double-16, -fdefault-real-10, > -fdefault-double-10, and add conversions for logical types, to > complete the conversion table. These are not very commonly used > (except for -fdefault-real-16, -fdefault-double-16, which would > correspond to -r16 and -autodouble flags in some compilers), so we > should be fine at this time. Well, historically, -fdefault-real-8, -fdefault-integer-8, and -fdefault-double-8 were provided for backwards compatibility with g77's -r8, -d8, and -i8 options. There was no consideration for other compilers.* Thus, I would discourage these new options in favor of your -freal-N-real-M options. * Craig Burley may have included -r8, -i8, and -d8 to be compatible with other compilers, but I'm too lazy to go code spelunking. -- Steve
Re: [patch] Flag-controlled type conversions/promotions
Hi, Everything seems to be ok in this patch, except for minor typos in documentation: REAl -> REAL, alignement -> alignment. It would also be nice to extend the type conversion facility to include -fdefault-real-16, -fdefault-double-16, -fdefault-real-10, -fdefault-double-10, and add conversions for logical types, to complete the conversion table. These are not very commonly used (except for -fdefault-real-16, -fdefault-double-16, which would correspond to -r16 and -autodouble flags in some compilers), so we should be fine at this time. Thanks to everyone for making this work! Zydrunas On Fri, Jan 13, 2012 at 6:43 PM, Steve Kargl wrote: > On Wed, Nov 09, 2011 at 06:09:58PM -0500, Andreas Kloeckner wrote: >> Hi there, >> >> please find attached the patch and the Changelog entry for our work on >> the fortran bug #48426. >> >> The attached patch implements the options >> >> -finteger-4-integer-8 >> -freal-4-real-8 >> -freal-4-real-10 >> -freal-4-real-16 >> -freal-8-real-4 >> -freal-8-real-10 >> -freal-8-real-16 >> >> to implement a variety of automatic type promotions. (This is particularly >> helpful if one wants to quickly check whether a certain code has a bug >> limiting >> its precision away from full machine accuracy.) >> > > I plan to commit the attached patch this weekend. > > 2011-11-09 Zydrunas Gimbutas > Andreas Kloeckner > Steven G. Kargl > > PR fortran/48426 > * gfortran.h (gfc_option_t): Add members flag_*_kind to store kind. > * lang.opt: Add options -freal-4-real-8, -freal-4-real-10, > -freal-4-real-16, -freal-8-real-4, -freal-8-real-10, -freal-8-real-16 > and -finteger-4-integer-8. User-desired type conversion information. > * decl.c (gfc_match_old_kind_spec,kind_expr): Type conversions > in declaration parsing. > * trans-types.c (gfc_init_kinds): User-specified type conversion > checked for current backend. > * primary.c (match_integer_constant,match_real_constant): Implement > type conversion in constant parsing. > * options.c (gfc_init_options,gfc_handle_option): Translate input > options to flags in internal options data structure. > * invoke.texi: Document new options. Re-order options in Options > summary section. > > -- > Steve
Re: [patch] Flag-controlled type conversions/promotions
On Wed, Nov 09, 2011 at 06:09:58PM -0500, Andreas Kloeckner wrote:
> Hi there,
>
> please find attached the patch and the Changelog entry for our work on
> the fortran bug #48426.
>
> The attached patch implements the options
>
> -finteger-4-integer-8
> -freal-4-real-8
> -freal-4-real-10
> -freal-4-real-16
> -freal-8-real-4
> -freal-8-real-10
> -freal-8-real-16
>
> to implement a variety of automatic type promotions. (This is particularly
> helpful if one wants to quickly check whether a certain code has a bug
> limiting
> its precision away from full machine accuracy.)
>
I plan to commit the attached patch this weekend.
2011-11-09 Zydrunas Gimbutas
Andreas Kloeckner
Steven G. Kargl
PR fortran/48426
* gfortran.h (gfc_option_t): Add members flag_*_kind to store kind.
* lang.opt: Add options -freal-4-real-8, -freal-4-real-10,
-freal-4-real-16, -freal-8-real-4, -freal-8-real-10, -freal-8-real-16
and -finteger-4-integer-8. User-desired type conversion information.
* decl.c (gfc_match_old_kind_spec,kind_expr): Type conversions
in declaration parsing.
* trans-types.c (gfc_init_kinds): User-specified type conversion
checked for current backend.
* primary.c (match_integer_constant,match_real_constant): Implement
type conversion in constant parsing.
* options.c (gfc_init_options,gfc_handle_option): Translate input
options to flags in internal options data structure.
* invoke.texi: Document new options. Re-order options in Options
summary section.
--
Steve
Index: decl.c
===
--- decl.c (revision 183169)
+++ decl.c (working copy)
@@ -1572,7 +1572,8 @@ build_struct (const char *name, gfc_char
/* Should this ever get more complicated, combine with similar section
in add_init_expr_to_sym into a separate function. */
- if (c->ts.type == BT_CHARACTER && !c->attr.pointer && c->initializer && c->ts.u.cl
+ if (c->ts.type == BT_CHARACTER && !c->attr.pointer && c->initializer
+ && c->ts.u.cl
&& c->ts.u.cl->length && c->ts.u.cl->length->expr_type == EXPR_CONSTANT)
{
int len;
@@ -2101,6 +2102,33 @@ gfc_match_old_kind_spec (gfc_typespec *t
return MATCH_ERROR;
}
ts->kind /= 2;
+
+}
+
+ if (ts->type == BT_INTEGER && ts->kind == 4 && gfc_option.flag_integer4_kind == 8)
+ts->kind = 8;
+
+ if (ts->type == BT_REAL || ts->type == BT_COMPLEX)
+{
+ if (ts->kind == 4)
+ {
+ if (gfc_option.flag_real4_kind == 8)
+ ts->kind = 8;
+ if (gfc_option.flag_real4_kind == 10)
+ ts->kind = 10;
+ if (gfc_option.flag_real4_kind == 16)
+ ts->kind = 16;
+ }
+
+ if (ts->kind == 8)
+ {
+ if (gfc_option.flag_real8_kind == 4)
+ ts->kind = 4;
+ if (gfc_option.flag_real8_kind == 10)
+ ts->kind = 10;
+ if (gfc_option.flag_real8_kind == 16)
+ ts->kind = 16;
+ }
}
if (gfc_validate_kind (ts->type, ts->kind, true) < 0)
@@ -2246,7 +2274,33 @@ kind_expr:
if(m == MATCH_ERROR)
gfc_current_locus = where;
-
+
+ if (ts->type == BT_INTEGER && ts->kind == 4 && gfc_option.flag_integer4_kind == 8)
+ts->kind = 8;
+
+ if (ts->type == BT_REAL || ts->type == BT_COMPLEX)
+{
+ if (ts->kind == 4)
+ {
+ if (gfc_option.flag_real4_kind == 8)
+ ts->kind = 8;
+ if (gfc_option.flag_real4_kind == 10)
+ ts->kind = 10;
+ if (gfc_option.flag_real4_kind == 16)
+ ts->kind = 16;
+ }
+
+ if (ts->kind == 8)
+ {
+ if (gfc_option.flag_real8_kind == 4)
+ ts->kind = 4;
+ if (gfc_option.flag_real8_kind == 10)
+ ts->kind = 10;
+ if (gfc_option.flag_real8_kind == 16)
+ ts->kind = 16;
+ }
+}
+
/* Return what we know from the test(s). */
return m;
Index: trans-types.c
===
--- trans-types.c (revision 183169)
+++ trans-types.c (working copy)
@@ -362,7 +362,7 @@ gfc_init_kinds (void)
unsigned int mode;
int i_index, r_index, kind;
bool saw_i4 = false, saw_i8 = false;
- bool saw_r4 = false, saw_r8 = false, saw_r16 = false;
+ bool saw_r4 = false, saw_r8 = false, saw_r10 = false, saw_r16 = false;
for (i_index = 0, mode = MIN_MODE_INT; mode <= MAX_MODE_INT; mode++)
{
@@ -456,6 +456,8 @@ gfc_init_kinds (void)
saw_r4 = true;
if (kind == 8)
saw_r8 = true;
+ if (kind == 10)
+ saw_r10 = true;
if (kind == 16)
saw_r16 = true;
@@ -482,23 +484,31 @@ gfc_init_kinds (void)
r_index += 1;
}
- /* Choose the default integer kind. We choose 4 unless the user
- directs us otherwise. */
+ /* Choose the default integer kind. We choose 4 unless the user directs us
+ otherwise. Even if the user specified that the default integer kind is 8,
+ the numeric storage size is not 64 bits. In this case, a warning will be
+ issued when NUMERIC_STORAGE_SIZE is used. Set NUME
Re: [patch] Flag-controlled type conversions/promotions
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.33432674407958984375e-1; gfc4x -c -fdump-tree-original -freal-4-real-8 k.f90 real(kind=8) x; x = 3.33314829616256247390992939472198486328125e-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 failures39 > # of unresolved testcases 1 > # of unsupported tests570 > 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. -- Steve
Re: [patch] Flag-controlled type conversions/promotions
On Tue, Dec 27, 2011 at 6:52 AM, 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). > 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
Re: [patch] Flag-controlled type conversions/promotions
> -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 passes37336
# of unexpected failures896
# of expected failures 39
# of unresolved testcases 1
# of unsupported tests 570
=== gfortran Summary for unix/-m64/-finteger-4-integer-8 ===
# of expected passes37728
# of unexpected failures840
# of expected failures 39
# of unsupported tests 409
=== gfortran Summary for unix/-m32/-freal-4-real-8 ===
# of expected passes37526
# of unexpected failures702
# of expected failures 39
# of unsupported tests 570
=== gfortran Summary for unix/-m64/-freal-4-real-8 ===
# of expected passes37857
# of unexpected failures698
# of expected failures 39
# of unsupported tests 409
=== gfortran Summary for unix/-m32/-freal-8-real-10 ===
# of expected passes37928
# of unexpected failures394
# of expected failures 39
# of untested testcases 8
# of unsupported tests 570
=== gfortran Summary for unix/-m64/-freal-8-real-10 ===
# of expected passes38300
# of unexpected failures357
# of expected failures 39
# of untested testcases 8
# of unsupported tests 409
=== gfortran Summary ===
# of expected passes226675
# of unexpected failures3887
# 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 passes37794
# of unexpected failures489
# of expected failures 39
# of unresolved testcases 24
# of unsupported tests 570
=== gfortran Summary for unix/-m64/-fdefault-integer-8 ===
# of expected passes38111
# of unexpected failures499
# of expected failures 39
# of unresolved testcases 24
# of unsupported tests 409
=== gfortran Summary for unix/-m32/-fdefault-real-8 ===
# of expected passes37705
# of unexpected failures539
# of expected failures 39
# of untested testcases 8
# of unsupported tests 570
=== gfortran Summary for unix/-m64/-fdefault-real-8 ===
# of expected passes38028
# of unexpected failures535
# of expected failures 39
# of untested testcases 8
# of unsupported tests 409
=== gfortran Summary ===
# of expected passes151638
# of unexpected failures2062
# 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
Re: [patch] Flag-controlled type conversions/promotions
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. 0. 0. 0. 0. 0. 0. 0. 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.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 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.00 0.00 1.40209065578162555042101269140459185E-0017 <- constant truncation 0.00 1.40209065578162555042101269140459185E-0017 <- constant truncation 0.00 0.00 0.00 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.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Re: [patch] Flag-controlled type conversions/promotions
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 passes37336 > > # of unexpected failures896 > > # 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. -- Steve
Re: [patch] Flag-controlled type conversions/promotions
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 failures39 > # of unresolved testcases 1 > # of unsupported tests570 > > === gfortran Summary for unix/-m64/-finteger-4-integer-8 === > > # of expected passes 37728 > # of unexpected failures 840 > # of expected failures39 > # of unsupported tests409 > > 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). -- Steve
Re: [patch] Flag-controlled type conversions/promotions
> 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.
With the follwoing patch
--- /opt/gcc/_clean/gcc/testsuite/lib/prune.exp 2011-10-17 12:04:23.0
+0200
+++ /opt/gcc/work/gcc/testsuite/lib/prune.exp 2011-12-26 13:59:57.0
+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
I get
=== gfortran Summary for unix/-m32/-finteger-4-integer-8 ===
# of expected passes37336
# of unexpected failures896
# of expected failures 39
# of unresolved testcases 1
# of unsupported tests 570
=== gfortran Summary for unix/-m64/-finteger-4-integer-8 ===
# of expected passes37728
# of unexpected failures840
# 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)
FAIL: gfortran.dg/coarray/image_index_1.f90 -fcoarray=lib -O2 -lcaf_single
(test for excess errors)
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.
Among other errors, several ones are related to broken generic interfaces for
different KIND.
The manual could probably lists some expected breakages such as this one.
The difference between -fdefault-*-8 and -f*-4-*-8 should probably also be
documented.
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.
Thanks fro the patch,
Dominique
Re: [patch] Flag-controlled type conversions/promotions
On Wed, Nov 09, 2011 at 06:09:58PM -0500, Andreas Kloeckner wrote:
>
> please find attached the patch and the Changelog entry for our work on
> the fortran bug #48426.
>
> The attached patch implements the options
>
> -finteger-4-integer-8
> -freal-4-real-8
> -freal-4-real-10
> -freal-4-real-16
> -freal-8-real-4
> -freal-8-real-10
> -freal-8-real-16
>
> to implement a variety of automatic type promotions. (This is
> particularly helpful if one wants to quickly check whether a
> certain code has a bug limiting its precision away from full
> machine accuracy.)
>
> A similar promotion feature is available in Fujitsu compilers, see here:
>
> http://www.lahey.com/docs/fujitsu%20compiler%20option%20list.pdf
>
> (e.g. -CcR8R16)
>
> The implementation work on this was done by Zydrunas Gimbutas, not by me.
> Zydrunas has authorized me to submit this for inclusion in gcc. Both he
> and I have gone through the FSF's copyright assignment process and have
> current papers for that on file.
>
> We tested the change by running Kahan's Fortran paranoia tests using all
> supported conversions, we ran the LINPACK tests (at all supported
> conversions) as well as a number of manually-written conversion tests.
>
All,
I have taken Zydrunas and Andreas patche applied it to my tree,
updated for it GNU Coding Style, and written the gfortran manual
entries. The ChangeLog is
2011-12-25 Zydrunas Gimbutas
Andreas Kloeckner
Steven G. Kargl
PR fortran/48426
* gfortran.h: Make global variables flag_*_kind to store
* lang.opt: Add options -freal-4-real-8, -freal-4-real-10,
-freal-4-real-16, -freal-8-real-4, -freal-8-real-10, -freal-8-real-16
and -finteger-4-integer-8.
user-desired type conversion information.
* decl.c (gfc_match_old_kind_spec,kind_expr): Type conversions
in declaration parsing.
* trans-types.c (gfc_init_kinds): User-specified type conversion
checked for current backend.
* primary.c (match_integer_constant,match_real_constant): Implement
type conversion in constant parsing.
* options.c (gfc_init_options,gfc_handle_option): Translate input
options to flags in internal options data structure.
* invoke.texi: Document new options. Re-order options in Options
summary section.
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.
OK for trunk?
--
Steve
Index: decl.c
===
--- decl.c (revision 182680)
+++ decl.c (working copy)
@@ -2101,6 +2101,33 @@ gfc_match_old_kind_spec (gfc_typespec *t
return MATCH_ERROR;
}
ts->kind /= 2;
+
+}
+
+ if (ts->type == BT_INTEGER && ts->kind == 4 && gfc_option.flag_integer4_kind == 8)
+ts->kind = 8;
+
+ if (ts->type == BT_REAL || ts->type == BT_COMPLEX)
+{
+ if (ts->kind == 4)
+ {
+ if (gfc_option.flag_real4_kind == 8)
+ ts->kind = 8;
+ if (gfc_option.flag_real4_kind == 10)
+ ts->kind = 10;
+ if (gfc_option.flag_real4_kind == 16)
+ ts->kind = 16;
+ }
+
+ if (ts->kind == 8)
+ {
+ if (gfc_option.flag_real8_kind == 4)
+ ts->kind = 4;
+ if (gfc_option.flag_real8_kind == 10)
+ ts->kind = 10;
+ if (gfc_option.flag_real8_kind == 16)
+ ts->kind = 16;
+ }
}
if (gfc_validate_kind (ts->type, ts->kind, true) < 0)
@@ -2246,7 +2273,33 @@ kind_expr:
if(m == MATCH_ERROR)
gfc_current_locus = where;
-
+
+ if (ts->type == BT_INTEGER && ts->kind == 4 && gfc_option.flag_integer4_kind == 8)
+ts->kind = 8;
+
+ if (ts->type == BT_REAL || ts->type == BT_COMPLEX)
+{
+ if (ts->kind == 4)
+ {
+ if (gfc_option.flag_real4_kind == 8)
+ ts->kind = 8;
+ if (gfc_option.flag_real4_kind == 10)
+ ts->kind = 10;
+ if (gfc_option.flag_real4_kind == 16)
+ ts->kind = 16;
+ }
+
+ if (ts->kind == 8)
+ {
+ if (gfc_option.flag_real8_kind == 4)
+ ts->kind = 4;
+ if (gfc_option.flag_real8_kind == 10)
+ ts->kind = 10;
+ if (gfc_option.flag_real8_kind == 16)
+ ts->kind = 16;
+ }
+}
+
/* Return what we know from the test(s). */
return m;
Index: trans-types.c
===
--- trans-types.c (revision 182680)
+++ trans-types.c (working copy)
@@ -362,7 +362,7 @@ gfc_init_kinds (void)
unsigned int mode;
int i_index, r_index, kind;
bool saw_i4 = false, saw_i8 = false;
- bool saw_r4 = false, saw_r8 = false, saw_r16 = false;
+ bool saw_r4 = false, saw_r8 = false, saw_r10 = false, saw_r16 = false;
for (i_index = 0, mode = MIN_MODE_INT; mode <= MAX_MODE_INT; mode++)
{
@@ -456,6 +456,8 @@ gfc_init_kinds (void)
saw_r4 = true;
if (kind == 8)
saw_r8 = true;
+ if (kind == 10)
+ saw_r10 = true;
if (kind ==
Re: [patch] Flag-controlled type conversions/promotions
On Wed, Nov 09, 2011 at 06:09:58PM -0500, Andreas Kloeckner wrote: > Hi there, > > please find attached the patch and the Changelog entry for our work on > the fortran bug #48426. > > The attached patch implements the options > > -finteger-4-integer-8 > -freal-4-real-8 > -freal-4-real-10 > -freal-4-real-16 > -freal-8-real-4 > -freal-8-real-10 > -freal-8-real-16 > > to implement a variety of automatic type promotions. (This is particularly > helpful if one wants to quickly check whether a certain code has a bug > limiting > its precision away from full machine accuracy.) > > A similar promotion feature is available in Fujitsu compilers, see here: > > http://www.lahey.com/docs/fujitsu%20compiler%20option%20list.pdf > > (e.g. -CcR8R16) > > The implementation work on this was done by Zydrunas Gimbutas, not by me. > Zydrunas has authorized me to submit this for inclusion in gcc. Both he > and I have gone through the FSF's copyright assignment process and have > current papers for that on file. > > We tested the change by running Kahan's Fortran paranoia tests using all > supported conversions, we ran the LINPACK tests (at all supported > conversions) as well as a number of manually-written conversion tests. > > Zydrunas and Andreas Andreas, My apologies for letting this feature/patch fall through the cracks. I have time over the next few days to review/test/ and commit this patch. Are there any changes that I need to known about? -- Steve
[patch] Flag-controlled type conversions/promotions
Hi there,
please find attached the patch and the Changelog entry for our work on
the fortran bug #48426.
The attached patch implements the options
-finteger-4-integer-8
-freal-4-real-8
-freal-4-real-10
-freal-4-real-16
-freal-8-real-4
-freal-8-real-10
-freal-8-real-16
to implement a variety of automatic type promotions. (This is particularly
helpful if one wants to quickly check whether a certain code has a bug limiting
its precision away from full machine accuracy.)
A similar promotion feature is available in Fujitsu compilers, see here:
http://www.lahey.com/docs/fujitsu%20compiler%20option%20list.pdf
(e.g. -CcR8R16)
The implementation work on this was done by Zydrunas Gimbutas, not by me.
Zydrunas has authorized me to submit this for inclusion in gcc. Both he
and I have gone through the FSF's copyright assignment process and have
current papers for that on file.
We tested the change by running Kahan's Fortran paranoia tests using all
supported conversions, we ran the LINPACK tests (at all supported
conversions) as well as a number of manually-written conversion tests.
Zydrunas and Andreas
pgp97zRCLKEIX.pgp
Description: PGP signature
Changelog-PR48426
Description: Binary data
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (revision 181224)
+++ gcc/fortran/decl.c (working copy)
@@ -2097,8 +2097,24 @@
return MATCH_ERROR;
}
ts->kind /= 2;
+
}
+ if (ts->type == BT_INTEGER)
+{
+ if( ts->kind == 4 && gfc_option.flag_integer4_kind == 8) ts->kind = 8;
+}
+
+ if (ts->type == BT_REAL || ts->type == BT_COMPLEX)
+{
+ if( ts->kind == 4 && gfc_option.flag_real4_kind == 8) ts->kind = 8;
+ if( ts->kind == 4 && gfc_option.flag_real4_kind == 10) ts->kind = 10;
+ if( ts->kind == 4 && gfc_option.flag_real4_kind == 16) ts->kind = 16;
+ if( ts->kind == 8 && gfc_option.flag_real8_kind == 4) ts->kind = 4;
+ if( ts->kind == 8 && gfc_option.flag_real8_kind == 10) ts->kind = 10;
+ if( ts->kind == 8 && gfc_option.flag_real8_kind == 16) ts->kind = 16;
+}
+
if (gfc_validate_kind (ts->type, ts->kind, true) < 0)
{
gfc_error ("Old-style type declaration %s*%d not supported at %C",
@@ -2243,6 +2259,22 @@
if(m == MATCH_ERROR)
gfc_current_locus = where;
+
+ if (ts->type == BT_INTEGER)
+{
+ if( ts->kind == 4 && gfc_option.flag_integer4_kind == 8) ts->kind = 8;
+}
+
+ if (ts->type == BT_REAL || ts->type == BT_COMPLEX)
+{
+ if( ts->kind == 4 && gfc_option.flag_real4_kind == 8) ts->kind = 8;
+ if( ts->kind == 4 && gfc_option.flag_real4_kind == 10) ts->kind = 10;
+ if( ts->kind == 4 && gfc_option.flag_real4_kind == 16) ts->kind = 16;
+ if( ts->kind == 8 && gfc_option.flag_real8_kind == 4) ts->kind = 4;
+ if( ts->kind == 8 && gfc_option.flag_real8_kind == 10) ts->kind = 10;
+ if( ts->kind == 8 && gfc_option.flag_real8_kind == 16) ts->kind = 16;
+}
+
/* Return what we know from the test(s). */
return m;
Index: gcc/fortran/gfortran.h
===
--- gcc/fortran/gfortran.h (revision 181224)
+++ gcc/fortran/gfortran.h (working copy)
@@ -2215,6 +2215,9 @@
int flag_default_double;
int flag_default_integer;
int flag_default_real;
+ int flag_integer4_kind;
+ int flag_real4_kind;
+ int flag_real8_kind;
int flag_dollar_ok;
int flag_underscoring;
int flag_second_underscore;
Index: gcc/fortran/lang.opt
===
--- gcc/fortran/lang.opt (revision 181224)
+++ gcc/fortran/lang.opt (working copy)
@@ -394,6 +394,10 @@
Fortran RejectNegative
Assume that the source file is fixed form
+finteger-4-integer-8
+Fortran RejectNegative
+Interpret any 4-byte integer as an 8-byte integer
+
fintrinsic-modules-path
Fortran RejectNegative Joined Separate
Specify where to find the compiled intrinsic modules
@@ -494,6 +498,30 @@
Fortran
Enable range checking during compilation
+freal-4-real-8
+Fortran RejectNegative
+Interpret any 4-byte real as an 8-byte real
+
+freal-4-real-10
+Fortran RejectNegative
+Interpret any 4-byte real as a 10-byte real
+
+freal-4-real-16
+Fortran RejectNegative
+Interpret any 4-byte real as a 16-byte real
+
+freal-8-real-4
+Fortran RejectNegative
+Interpret any 8-byte real as a 4-byte real
+
+freal-8-real-10
+Fortran RejectNegative
+Interpret any 8-byte real as a 10-byte real
+
+freal-8-real-16
+Fortran RejectNegative
+Interpret any 8-byte real as a 16-byte real
+
frealloc-lhs
Fortran
Reallocate the LHS in assignments
Index: gcc/fortran/trans-types.c
===
--- gcc/fortran/trans-types.c (revision 181224)
+++ gcc/fortran/trans-types.c (working copy)
@@ -362,7 +362,7 @@
unsigned int mode;
int i_index, r_index, kind;
bool saw_i4 = false, saw_i8 = false;
- bool saw_r4 = false, saw_r8
