[Patch, fortran] PR118640 - [15 Regression] cp2k ICE in gfc_conv_expr_present since r15-5347
Hi All, Pushed as an 'obvious' one-liner(less additional comments) in r15-7224 Fortran: ICE in gfc_conv_expr_present w. defined assignment [PR118640] 2025-01-27 Paul Thomas gcc/fortran PR fortran/118640 * resolve.cc (generate_component_assignments): Make sure that the rhs temporary does not pick up the optional attribute from the lhs. gcc/testsuite/ PR fortran/118640 * gfortran.dg/pr118640.f90: New test. Paul
Re: [PATCH] Fortran: fix bogus diagnostics on renamed interface import [PR110993]
Am 27.01.25 um 01:41 schrieb Jerry D: On 1/26/25 2:07 PM, Harald Anlauf wrote: Dear all, in the checking of imported interfaces we need to use the local names of procedures that are renamed-on-use, as the original name becomes inaccessible. Similarly, we should not compare interfaces of non-bind(C) procedures against bind(C) interfaces that are not explicitly made accessible via a use statement, see testcase. Regtested on x86_64-pc-linux-gnu. OK for mainline? Could this one be backportable, e.g. to 14-branch? Thanks, Harald This is OK. Backport up to you. Pushed to mainline as r15-7234-g9104472b645f76 . Will backport to 14-branch in a couple of days. Jerry Thanks, Harald
Re: DO CONCURRENT with LOCAL / LOCAL_INIT [was: [PATCH] Fortran: Added support for locality specs in DO CONCURRENT (Fortran 2018/23)]
In case it would help to see another open-source implementation, there exists a public branch of LLVM that parallelizes DO CONCURRENT using OpenMP. The LLVM fork and git tag that I’ve used since November is cited in the “CPU Parallelism on Perlmutter” slide at http://go.lbl.gov/just-write-fortran. The compiler work has progressed since then. I can hunt down a more up-to-date branch if anyone is interested. Damian On Sun, Jan 26, 2025 at 02:10 Tobias Burnus wrote: > Hi, > > John Campbell wrote: > > Would it be easier to consider "DO CONCURRENT with LOCAL / LOCAL_INIT" > as a special case of !$OMP PARALLEL DO, so utilise this existing > implementation ? > > I think I want to handle by default a bare 'do concurrent' with a code > separate from OpenMP, but using the normal code. > > I am also not completely sure whether the semantic is exactly the same – > and whether there are issues with the current OpenMP implementation; I > would assume there are some with 'private' as there are with LOCAL when > using default-values in derived types. > > Note that I also did not see real obstacles yesterday but it requires > another couple of hours of work (it took so far 5h, ignoring the work > for what's in already). The future work would be either continuing with > the current approach or calling the existing OpenMP copy and > default-init functions (see PR for the function names), which still > would reuse parts of the current patch. > > It also requires more *testcases* for do concurrent to check that > everything is handled correctly; as the existing testcases (see patch) > show, simple code works – but trying hard enough, one finds things that > don't. > > [Converting the current/new testcases to OpenMP wouldn't harm, either. > I'd assume that some cases are mishandled there as well, esp. derived > types with default values.] > > > Regarding the semantic: I think OpenMP permits more – at least for > 'firstprivate', like polymorphic variables and allocatable components. – > For 'private', a lot of details are unspecified. – Fortran is more > restrictive but/hence has fewer unspecified parts. However, my feeling > is that the difference is more on the constraint-checking side in the > compiler and less on the actual implementation. > > (That polymorphic variables are supported in OpenMP's firstprivate was > rather underspecified until OpenMP 6.0; it is now permitted (except on > 'target'). GCC should handle it already correctly since GCC 13 (?).) > > * * * > > Regarding moving to real parallelization (out of scope for the current > patch): For 'do concurrent', I don't think that it should > unconditionally linke the OpenMP runtime library and turn every > do-concurrent loop into something that consumes all available threads of > the system. > > Thus, I was thinking in the past of providing -fdo-concurrent=… as flag > to decide how to handle it, i.e. use no thread parallization, use > OpenMP's, or … — The question is only the exact option, default, and > semantic. > > BTW: OpenMP before 6.0 did not permit any OpenMP directive on 'do > concurrent'. However, with OpenMP 6.0, '!$omp loop' is permitted, which > makes it possible to say per loop whether thread parallization should be > done or not. > > * * * > > I think permitting '!$omp loop' on do-concurrent will likely be a GCC 16 > item, while non thread-parallelizing do-concurrent should really still > become a GCC 15 feature! I think we also think about -fdo-concurrent=… > for GCC 16. > > Tobias > >
[patch, libfortran] PR114618 Format produces incorrect output when contains 1x, ok when uses " "
Hello all,
The attached patch is part 1 of my effort to fix these X and T edit
descriptor issues. This one cleans up some really ugly output.
Before the patch with the test case provided by the reporter:
PI.^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ 3.1415926535897931
REAL(PI)...^@^@^@^@^@^@^@^@^@^@^@ 3.14159274
DBLE(PI)...^@^@^@^@^@^@^@^@^@^@^@ 3.1415926535897931
RADIX..^@^@^@^@^@^@^@^@^@^@^@ 3. 2
RANGE..^@^@^@^@^@^@^@^@^@^@^@ 3. 307
PRECISION..^@^@^@^@^@^@^@^@^@^@ 15
Which is complete garbage.
After the patch:
PI 3.1415926535897931
REAL(PI) .. 3.14159274
DBLE(PI) .. 3.1415926535897931
RADIX . 2
RANGE . 307
PRECISION . 15
I greatly reduced the test case included in the patch. While working on
this one I discovered other problems not addressed by this patch and I
will address these through PR113897.
You will see some changes in the factoring of some of the code in the
case FMT_X:, case FMT_TR:, case FMT_TL:, case FMT_T:. I anticipate in
part 2 that I will be doing more specific changes on these.
Regression tested on x86_64_linux_gnu.
OK for trunk?
Regards,
Jerry
Author: Jerry DeLisle
Date: Mon Jan 27 19:08:46 2025 -0800
Fortran: Fix handling of the X edit descriptor.
This patch is a partial fix of handling of X edit descriptors
when combined with certain T edit descriptors.
PR libfortran/114618
libgfortran/ChangeLog:
* io/transfer.c (formatted_transfer_scalar_write): Change name
of vriable 'pos' to 'tab_pos' to improve clarity. Add new
variable next_pos when calculating the maximum position.
Update the calculation of pending spaces.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr114618.f90: New test.
diff --git a/gcc/testsuite/gfortran.dg/pr114618.f90 b/gcc/testsuite/gfortran.dg/pr114618.f90
new file mode 100644
index 000..c06c4debe31
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr114618.f90
@@ -0,0 +1,15 @@
+! { dg-do run }
+! PR114618 Format produces incorrect output when contains 1x, ok when uses " "
+! aside: Before patch output1 is garbage.
+! Output should be 'RADIX . 2'
+program pr114618
+ implicit none
+ integer, parameter :: wp = kind(0d0)
+ real(kind=wp) :: pi = 3.14159265358979323846264338_wp
+ character(len=*), parameter:: fmt1 = '(19("."),t1,g0,1x,t21,g0)'
+ character(len=*), parameter:: fmt2 = '(19("."),t1,g0," ",t21,g0)'
+ character(30) :: output1, output2
+ write (output1, fmt1) 'RADIX', radix(pi)
+ write (output2, fmt2) 'RADIX', radix(pi)
+ if (output1 /= output2) stop 1
+end program pr114618
diff --git a/libgfortran/io/transfer.c b/libgfortran/io/transfer.c
index b3b72f39c5b..8a24a099afe 100644
--- a/libgfortran/io/transfer.c
+++ b/libgfortran/io/transfer.c
@@ -2068,12 +2068,14 @@ static void
formatted_transfer_scalar_write (st_parameter_dt *dtp, bt type, void *p, int kind,
size_t size)
{
- gfc_offset pos, bytes_used;
+ gfc_offset tab_pos, bytes_used;
const fnode *f;
format_token t;
int n;
int consume_data_flag;
+ tab_pos = 0; bytes_used = 0;
+
/* Change a complex data item into a pair of reals. */
n = (p == NULL) ? 0 : ((type != BT_COMPLEX) ? 1 : 2);
@@ -2398,10 +2400,17 @@ formatted_transfer_scalar_write (st_parameter_dt *dtp, bt type, void *p, int kin
case FMT_X:
case FMT_TR:
consume_data_flag = 0;
-
dtp->u.p.skips += f->u.n;
- pos = bytes_used + dtp->u.p.skips - 1;
- dtp->u.p.pending_spaces = pos - dtp->u.p.max_pos + 1;
+ tab_pos = bytes_used + dtp->u.p.skips - 1;
+ dtp->u.p.pending_spaces = tab_pos - dtp->u.p.max_pos + 1;
+ dtp->u.p.pending_spaces = dtp->u.p.pending_spaces < 0
+? f->u.n : dtp->u.p.pending_spaces;
+
+ if (t == FMT_X && tab_pos < dtp->u.p.max_pos)
+ {
+ write_x (dtp, dtp->u.p.skips, dtp->u.p.pending_spaces);
+ dtp->u.p.skips = dtp->u.p.pending_spaces = 0;
+ }
/* Writes occur just before the switch on f->format, above, so
that trailing blanks are suppressed, unless we are doing a
non-advancing write in which case we want to output the blanks
@@ -2414,35 +2423,50 @@ formatted_transfer_scalar_write (st_parameter_dt *dtp, bt type, void *p, int kin
break;
case FMT_TL:
- case FMT_T:
consume_data_flag = 0;
-
- if (f->format == FMT_TL)
+ /* Handle the special case when no bytes have been used yet.
+ Cannot go below zero. */
+ if (bytes_used == 0)
{
-
- /* Handle the special case when no bytes have been used yet.
- Cannot go below zero. */
- if (bytes_used == 0)
- {
- dtp->u.p.pending_spaces -= f->u.n;
- dtp->u.p.skips -= f->u.n;
- dtp->u.p.skips = dtp->u.p.skips < 0 ? 0 : dtp->u.p.skips;
- }
-
- pos = bytes_used - f->u.n;
+ dtp->u.p.pending_spaces -= f->u.n;
+ dtp->u.p.skips -= f->u.n;
+ dtp->u.p.skips = dtp->u.p.skips < 0 ? 0
