The B, O and Z edit descriptors are not accepted for output of real numbers when Fortran 2008 standard mode is selected. Fortran 2008 explicitly allows B, O and Z editing for real and complex numbers. (This is different from Fortran 2003, which only specifies B, O and Z editing for integer numbers. This has been discussed in Bug 41711.) 10.7.2.4 B, O, and Z editing 1 [...] The corresponding input/output list item shall be of type integer, real, or complex. ... 4 The value is INT (X) if the input list item is of type integer and REAL (X) if the input list item is of type real or complex, where X is a boz-literal-constant that specifies the same bit sequence as the digits of the input field. The following program, when compiled with "-std=f2008" fails with: 1111011 At line 3 of file test_boz.f90 (unit = 6, file = 'stdout') Fortran runtime error: Expected INTEGER for item 1 in formatted transfer, got REAL (b64) ^ program test_boz print "(b64)", 123 print "(b64)", 1.23 print "(b0)", 123 print "(b0)", 1.23 print "(o24)", 123 print "(o24)", 1.23 print "(o0)", 123 print "(o0)", 1.23 print "(z0)", 123 print "(z0)", 1.23 print "(z16)", 123 print "(z16)", 1.23 print "(b64.64)", 123 print "(b64.64)", 1.23 print "(b0.64)", 123 print "(b0.64)", 1.23 print "(o24.24)", 123 print "(o24.24)", 1.23 print "(o0.24)", 123 print "(o0.24)", 1.23 print "(z0.16)", 123 print "(z0.16)", 1.23 print "(z16.16)", 123 print "(z16.16)", 1.23 end program test_boz The expected behavior is the same as without the "-std=f2008" option. The program should output: 1111011 111111100111010111000010100100 1111011 111111100111010111000010100100 173 7747270244 173 7747270244 7B 3F9D70A4 7B 3F9D70A4 0000000000000000000000000000000000000000000000000000000001111011 0000000000000000000000000000000000111111100111010111000010100100 0000000000000000000000000000000000000000000000000000000001111011 0000000000000000000000000000000000111111100111010111000010100100 000000000000000000000173 000000000000007747270244 000000000000000000000173 000000000000007747270244 000000000000007B 000000003F9D70A4 000000000000007B 000000003F9D70A4
In libgfortran/io/transfer.c's one currently has in formatted_transfer_scalar_read and formatted_transfer_scalar_write code such as case FMT_B: if (n == 0) goto need_data; if (!(compile_options.allow_std & GFC_STD_GNU) && require_type (dtp, BT_INTEGER, type, f)) return; write_b (dtp, f, p, kind); break; s/GFC_STD_GNU/GFC_STD_F2008/ should take care of that. However, that might accept too much, namely CHARACTER and LOGICAL, which are excluded at: "The corresponding input/output list item shall be of type integer, real, or complex." I don't know whether we should care - I tend to be more liberal for run-time diagnostic than for compile-time diagnostic ...
Created attachment 24162 [details] Proposed patch for input/output
Created attachment 24163 [details] Test case for input/output of real numbers with B/O/Z editing
Thanks Thomas, thanks for support. I will have a close look and check tonight.
(In reply to comment #2) > Created attachment 24162 [details] > Proposed patch for input/output - if (!(compile_options.allow_std & GFC_STD_GNU) + if (!(compile_options.allow_std & (GFC_STD_GNU | GFC_STD_F2008)) As mentioned in comment 1, replacing GFC_STD_GNU by GFC_STD_F2008 should be sufficient without OR-ing the two.
Can you elaborate on this? Previously we allowed the format with -std=gnu. Now we want to allow it with -std=gnu or -std=f2008. So we call require_type() only if neither of these options is set. That's why I changed the mask from GFC_STD_GNU to (GFC_STD_GNU | GFC_STD_F2008). And the values have different bits set, so the OR is not redundant: #define GFC_STD_F2008 (1<<7) /* New in F2008. */ #define GFC_STD_LEGACY (1<<6) /* Backward compatibility. */ #define GFC_STD_GNU (1<<5) /* GNU Fortran extension. */
(In reply to comment #6) > Can you elaborate on this? > That's why I changed the mask from GFC_STD_GNU to (GFC_STD_GNU | > GFC_STD_F2008). First, the code is/should be also allowed for -std=legacy (GFC_STD_LEGACY). Secondly, the point is not that GFC_STD_GNU and GFC_STD_F2008 are same (they obviously aren't), but that having (compile_options.allow_std | GFC_STD_F2008) != 0 => implies (compile_options.allow_std | GFC_STD_GNU) != 0 which is a property of "allow_std". See gcc/fortran/options.c: case OPT_std_f2003: gfc_option.allow_std = GFC_STD_F95_OBS | GFC_STD_F77 | GFC_STD_F2003 | GFC_STD_F95 | GFC_STD_F2008_OBS; case OPT_std_f2008: gfc_option.allow_std = GFC_STD_F95_OBS | GFC_STD_F77 | GFC_STD_F2003 | GFC_STD_F95 | GFC_STD_F2008 | GFC_STD_F2008_OBS; case OPT_std_gnu: set_default_std_flags (); break;
(In reply to comment #7) O, I see. The important part is in set_default_std_flags (void) { gfc_option.allow_std = GFC_STD_F95_OBS | GFC_STD_F95_DEL | GFC_STD_F2003 | GFC_STD_F2008 | GFC_STD_F95 | GFC_STD_F77 | GFC_STD_F2008_OBS | GFC_STD_GNU | GFC_STD_LEGACY; gfc_option.warn_std = GFC_STD_F95_DEL | GFC_STD_LEGACY; } So technically, we only need to test for GFC_STD_F2008, just as you said.
Looking at transfer.c and trying the test case provided here, I believe this is fixed. Closing.