Re: Fortran: Use non conflicting file extensions for intermediates [PR81615]
Hi Harald, 'from' is slightly better but either will be understood. Cheers Paul Happy New Year to you all! On Mon, 1 Jan 2024 at 21:25, Harald Anlauf wrote: > Hi Thomas! > > Am 30.12.23 um 12:08 schrieb Thomas Koenig: > > Replying to myself... > > > > > >> I think this also desevers a mention in changes.html. Here is something > >> that I came up with. OK? Or does anybody have suggestions for a better > >> wording? > >> > > > > Or maybe this is better: > > > > diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html > > index 4b83037a..d232f631 100644 > > --- a/htdocs/gcc-14/changes.html > > +++ b/htdocs/gcc-14/changes.html > > @@ -282,8 +282,14 @@ a work-in-progress. > > > > > > > > - > > - > > +Fortran > > + > > + With the -save-temps option, preprocessed files > > +with the .fii extension will be generated for > > +free-form source files such as .F90 and > > +.fi for fixed-form files such as .F. > > + > > + > > > > I slightly prefer this variant. > > I wonder if it were better to write "generated from" instead of > "generated for". A native speaker might help here. > > While at it: gfortran now accepts "-std=f2023", which implies that > the limit for line-length in free-form has been increased to 1 > characters, and statements may have up to 1 million characters. > (See Tobias' commit r14-5553-gb9eba3baf54b4f). > > I'd consider this as important as the other change... ;-) > > Thanks, > Harald > > > > > > > > > > >
Re: Fortran: Use non conflicting file extensions for intermediates [PR81615]
Hi Paul and Harald, 'from' is slightly better but either will be understood. Committed with "from" (which I managed to spell correctly on the second try). Best regards Thomas
Re: [PATCH v7] libgfortran: Replace mutex with rwlock
Hi Lipeng, It looks like your draft patch to fix the builds for arm-none-eabi target is not merged yet, because our arm-none-eabi builds are still broken. Are you waiting for additional information, or would you be able to fix this issue? Kind regards, Vasee From: Richard Earnshaw Sent: 15 December 2023 19:23 To: Lipeng Zhu ; Richard Earnshaw ; ja...@redhat.com Cc: fortran@gcc.gnu.org ; gcc-patc...@gcc.gnu.org ; hongjiu...@intel.com ; pan.d...@intel.com ; rep.dot@gmail.com ; tianyou...@intel.com ; tkoe...@netcologne.de ; wangyang@intel.com Subject: Re: [PATCH v7] libgfortran: Replace mutex with rwlock On 15/12/2023 11:31, Lipeng Zhu wrote: > > > On 2023/12/14 23:50, Richard Earnshaw (lists) wrote: >> On 09/12/2023 15:39, Lipeng Zhu wrote: >>> This patch try to introduce the rwlock and split the read/write to >>> unit_root tree and unit_cache with rwlock instead of the mutex to >>> increase CPU efficiency. In the get_gfc_unit function, the percentage >>> to step into the insert_unit function is around 30%, in most instances, >>> we can get the unit in the phase of reading the unit_cache or unit_root >>> tree. So split the read/write phase by rwlock would be an approach to >>> make it more parallel. >>> >>> BTW, the IPC metrics can gain around 9x in our test >>> server with 220 cores. The benchmark we used is >>> https://github.com/rwesson/NEAT >>> >>> libgcc/ChangeLog: >>> >>> * gthr-posix.h (__GTHREAD_RWLOCK_INIT): New macro. >>> (__gthrw): New function. >>> (__gthread_rwlock_rdlock): New function. >>> (__gthread_rwlock_tryrdlock): New function. >>> (__gthread_rwlock_wrlock): New function. >>> (__gthread_rwlock_trywrlock): New function. >>> (__gthread_rwlock_unlock): New function. >>> >>> libgfortran/ChangeLog: >>> >>> * io/async.c (DEBUG_LINE): New macro. >>> * io/async.h (RWLOCK_DEBUG_ADD): New macro. >>> (CHECK_RDLOCK): New macro. >>> (CHECK_WRLOCK): New macro. >>> (TAIL_RWLOCK_DEBUG_QUEUE): New macro. >>> (IN_RWLOCK_DEBUG_QUEUE): New macro. >>> (RDLOCK): New macro. >>> (WRLOCK): New macro. >>> (RWUNLOCK): New macro. >>> (RD_TO_WRLOCK): New macro. >>> (INTERN_RDLOCK): New macro. >>> (INTERN_WRLOCK): New macro. >>> (INTERN_RWUNLOCK): New macro. >>> * io/io.h (struct gfc_unit): Change UNIT_LOCK to UNIT_RWLOCK in >>> a comment. >>> (unit_lock): Remove including associated internal_proto. >>> (unit_rwlock): New declarations including associated internal_proto. >>> (dec_waiting_unlocked): Use WRLOCK and RWUNLOCK on unit_rwlock >>> instead of __gthread_mutex_lock and __gthread_mutex_unlock on >>> unit_lock. >>> * io/transfer.c (st_read_done_worker): Use WRLOCK and RWUNLOCK on >>> unit_rwlock instead of LOCK and UNLOCK on unit_lock. >>> (st_write_done_worker): Likewise. >>> * io/unit.c: Change UNIT_LOCK to UNIT_RWLOCK in 'IO locking rules' >>> comment. Use unit_rwlock variable instead of unit_lock variable. >>> (get_gfc_unit_from_unit_root): New function. >>> (get_gfc_unit): Use RDLOCK, WRLOCK and RWUNLOCK on unit_rwlock >>> instead of LOCK and UNLOCK on unit_lock. >>> (close_unit_1): Use WRLOCK and RWUNLOCK on unit_rwlock instead of >>> LOCK and UNLOCK on unit_lock. >>> (close_units): Likewise. >>> (newunit_alloc): Use RWUNLOCK on unit_rwlock instead of UNLOCK on >>> unit_lock. >>> * io/unix.c (find_file): Use RDLOCK and RWUNLOCK on unit_rwlock >>> instead of LOCK and UNLOCK on unit_lock. >>> (flush_all_units): Use WRLOCK and RWUNLOCK on unit_rwlock instead >>> of LOCK and UNLOCK on unit_lock. >>> >> >> It looks like this has broken builds on arm-none-eabi when using newlib: >> >> In file included from >> /work/rearnsha/gnusrc/nightly/gcc-cross/master/libgfortran >> /runtime/error.c:27: >> /work/rearnsha/gnusrc/nightly/gcc-cross/master/libgfortran/io/io.h: In >> function >> ‘dec_waiting_unlocked’: >> /work/rearnsha/gnusrc/nightly/gcc-cross/master/libgfortran/io/io.h:1023:3: >> error >> : implicit declaration of function ‘WRLOCK’ >> [-Wimplicit-function-declaration] >> 1023 | WRLOCK (&unit_rwlock); >>| ^~ >> /work/rearnsha/gnusrc/nightly/gcc-cross/master/libgfortran/io/io.h:1025:3: >> error >> : implicit declaration of function ‘RWUNLOCK’ >> [-Wimplicit-function-declaration] >> 1025 | RWUNLOCK (&unit_rwlock); >>| ^~~~ >> >> >> R. > > Hi Richard, > > The root cause is that the macro WRLOCK and RWUNLOCK are not defined in > io.h. The reason of x86 platform not failed is that > HAVE_ATOMIC_FETCH_ADD is defined then caused above macros were never > been used. Code logic show as below: > #ifdef HAVE_ATOMIC_FETCH_ADD >(void) __atomic_fetch_add (&u->waiting, -1, __ATOMIC_RELAXED); > #else >WRLOCK (&unit_rwlock); >u->waiting--; >RWUNLOCK (&unit_rwlock); > #endif > > I just draft a patch try to fix this bug, because I didn't have arm > p
Re: [Patch] Fortran: Accept -std=f2023, update line-length for Fortran 2023
Dear all,
we might want to update changes.html to reflect this. How about:
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 403feb06..9b16f5e3 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -284,6 +284,11 @@ a work-in-progress.
Fortran
+ The compiler now accepts the -std=f2023 option, which
+has been added in preparation of support of Fortran 2023. This option
+increases the line-length limit for source in free-form to 1, and
+statements may have up to 1 million characters.
+
With the -save-temps option, preprocessed files
with the .fii extension will be generated from
free-form source files such as .F90 and
Cheers,
Harald
Am 17.11.23 um 12:38 schrieb Tobias Burnus:
Hi Harald, hi all,
On 16.11.23 20:30, Harald Anlauf wrote:
On 11/16/23 14:01, Tobias Burnus wrote:
This adds -std=f2023, which is mostly a prep patch for future changes.
...
(B) In "6.3.2.6 Free form statements":
Fortran 2018: "A statement shall not have more than 255 continuation
lines."
Fortran 2023: "A statement shall not have more than one million
characters."
this is really a funny change: we're not really prepared to handle
this.
I can confirm this. I tried to get it working in scanner.cc but due to
the re-parsing it is quite difficult to get it right; the main problem
is that we keep reparsing code ("gfc_current_locus = old_loc"), such
that a simple count will be wrong.
→ Now tracked at https://gcc.gnu.org/PR112586
According to the standard one can have 99 lines with only
"&" and then an ";", but then only 100 lines with 1 characters.
I believe a single '&' is not valid, you either need '&&' or something
else + '&'; thus, you can have only half a million lines + 1.
In the code, I still use 1,000,000 but now with a comment.
There is a similar wording for fixed-form which you overlooked:
Ups - fixed.
If you think that we need testcases for fixed-form, add them,
or forget them. I don't bother.
I added one.
- there are existing testcases continuation_5.f, continuation_6.f,
thus I suggest to rename your new continuation_{5,6}.f90 to
continuation_17.f90+ .
Done. We are rather inconsistent whether we enumerate .f{,90}
together or separately; as the suffix is shown, either works.
- I don't understand your new testcase line_length_14.f90 .
This is supposed to test -std=gnu, but then -std=gnu is not a
standard but a moving target, which is why you had to adjust
existing testcases.
So what does it buy us beyond line_length_1{2,3}.f90 ?
Well, it ensures that the warning is not only shown for -std=f2023 but
also for -std=f2028 and (current -std=gnu). In general, I think it is
useful to check the lower and the upper bound.
I have now removed it - as it is unlikely that we would regress on such
changes.
PPS: I did not bother adding .f23 as file extension; I believe that also
.f18 is unsupported.
I never use extensions other than .f90 for portable code.
Likewise - especially as '.f95' starts out as Fortran code that
complies to -std=f95 but slowly Fortran 2003 or later code creeps in. I
think that's fine but then one can also directly use .f90. (Most code
does so.)
Unless there are follow up comments, I will commit it later today.
Thanks for the comments!
Tobias
PS: I fixed the wording issue in the subject line of the email and
header. I first wrote 'support' but that sounded a bit as if F2023 is
supported. Hence, I wrote 'Accept' and did not remove 'support'.
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201,
80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer:
Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München;
Registergericht München, HRB 106955
Re: [Patch] Fortran: Accept -std=f2023, update line-length for Fortran 2023
On Tue, Jan 02, 2024 at 08:31:15PM +0100, Harald Anlauf wrote: > > we might want to update changes.html to reflect this. How about: > > diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html > index 403feb06..9b16f5e3 100644 > --- a/htdocs/gcc-14/changes.html > +++ b/htdocs/gcc-14/changes.html > @@ -284,6 +284,11 @@ a work-in-progress. > > Fortran > > + The compiler now accepts the -std=f2023 option, which > +has been added in preparation of support of Fortran 2023. This option > +increases the line-length limit for source in free-form to 1, and > +statements may have up to 1 million characters. > + > With the -save-temps option, preprocessed files > with the .fii extension will be generated from > free-form source files such as .F90 and > LGTM. -- Steve
Re: [Patch] Fortran: Accept -std=f2023, update line-length for Fortran 2023
Am 02.01.24 um 20:37 schrieb Steve Kargl: On Tue, Jan 02, 2024 at 08:31:15PM +0100, Harald Anlauf wrote: we might want to update changes.html to reflect this. How about: diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index 403feb06..9b16f5e3 100644 --- a/htdocs/gcc-14/changes.html +++ b/htdocs/gcc-14/changes.html @@ -284,6 +284,11 @@ a work-in-progress. Fortran + The compiler now accepts the -std=f2023 option, which +has been added in preparation of support of Fortran 2023. This option +increases the line-length limit for source in free-form to 1, and +statements may have up to 1 million characters. + With the -save-temps option, preprocessed files with the .fii extension will be generated from free-form source files such as .F90 and LGTM. Thanks, this is now pushed.
Re: [PATCH v7] libgfortran: Replace mutex with rwlock
On 2024/1/2 11:57, Vaseeharan Vinayagamoorthy wrote: Hi Lipeng, It looks like your draft patch to fix the builds for arm-none-eabi target is not merged yet, because our arm-none-eabi builds are still broken. Are you waiting for additional information, or would you be able to fix this issue? Kind regards, Vasee Hi Vasee, Actually I already sent a patch https://inbox.sourceware.org/gcc-patches/20231222023605.3894839-1-lipeng@intel.com/ to fix the build failure issue, now it is waiting for community to review. Lipeng Zhu From: Richard Earnshaw Sent: 15 December 2023 19:23 To: Lipeng Zhu ; Richard Earnshaw ; ja...@redhat.com Cc: fortran@gcc.gnu.org ; gcc-patc...@gcc.gnu.org ; hongjiu...@intel.com ; pan.d...@intel.com ; rep.dot@gmail.com ; tianyou...@intel.com ; tkoe...@netcologne.de ; wangyang@intel.com Subject: Re: [PATCH v7] libgfortran: Replace mutex with rwlock On 15/12/2023 11:31, Lipeng Zhu wrote: On 2023/12/14 23:50, Richard Earnshaw (lists) wrote: On 09/12/2023 15:39, Lipeng Zhu wrote: This patch try to introduce the rwlock and split the read/write to unit_root tree and unit_cache with rwlock instead of the mutex to increase CPU efficiency. In the get_gfc_unit function, the percentage to step into the insert_unit function is around 30%, in most instances, we can get the unit in the phase of reading the unit_cache or unit_root tree. So split the read/write phase by rwlock would be an approach to make it more parallel. BTW, the IPC metrics can gain around 9x in our test server with 220 cores. The benchmark we used is https://github.com/rwesson/NEAT libgcc/ChangeLog: * gthr-posix.h (__GTHREAD_RWLOCK_INIT): New macro. (__gthrw): New function. (__gthread_rwlock_rdlock): New function. (__gthread_rwlock_tryrdlock): New function. (__gthread_rwlock_wrlock): New function. (__gthread_rwlock_trywrlock): New function. (__gthread_rwlock_unlock): New function. libgfortran/ChangeLog: * io/async.c (DEBUG_LINE): New macro. * io/async.h (RWLOCK_DEBUG_ADD): New macro. (CHECK_RDLOCK): New macro. (CHECK_WRLOCK): New macro. (TAIL_RWLOCK_DEBUG_QUEUE): New macro. (IN_RWLOCK_DEBUG_QUEUE): New macro. (RDLOCK): New macro. (WRLOCK): New macro. (RWUNLOCK): New macro. (RD_TO_WRLOCK): New macro. (INTERN_RDLOCK): New macro. (INTERN_WRLOCK): New macro. (INTERN_RWUNLOCK): New macro. * io/io.h (struct gfc_unit): Change UNIT_LOCK to UNIT_RWLOCK in a comment. (unit_lock): Remove including associated internal_proto. (unit_rwlock): New declarations including associated internal_proto. (dec_waiting_unlocked): Use WRLOCK and RWUNLOCK on unit_rwlock instead of __gthread_mutex_lock and __gthread_mutex_unlock on unit_lock. * io/transfer.c (st_read_done_worker): Use WRLOCK and RWUNLOCK on unit_rwlock instead of LOCK and UNLOCK on unit_lock. (st_write_done_worker): Likewise. * io/unit.c: Change UNIT_LOCK to UNIT_RWLOCK in 'IO locking rules' comment. Use unit_rwlock variable instead of unit_lock variable. (get_gfc_unit_from_unit_root): New function. (get_gfc_unit): Use RDLOCK, WRLOCK and RWUNLOCK on unit_rwlock instead of LOCK and UNLOCK on unit_lock. (close_unit_1): Use WRLOCK and RWUNLOCK on unit_rwlock instead of LOCK and UNLOCK on unit_lock. (close_units): Likewise. (newunit_alloc): Use RWUNLOCK on unit_rwlock instead of UNLOCK on unit_lock. * io/unix.c (find_file): Use RDLOCK and RWUNLOCK on unit_rwlock instead of LOCK and UNLOCK on unit_lock. (flush_all_units): Use WRLOCK and RWUNLOCK on unit_rwlock instead of LOCK and UNLOCK on unit_lock. It looks like this has broken builds on arm-none-eabi when using newlib: In file included from /work/rearnsha/gnusrc/nightly/gcc-cross/master/libgfortran /runtime/error.c:27: /work/rearnsha/gnusrc/nightly/gcc-cross/master/libgfortran/io/io.h: In function ‘dec_waiting_unlocked’: /work/rearnsha/gnusrc/nightly/gcc-cross/master/libgfortran/io/io.h:1023:3: error : implicit declaration of function ‘WRLOCK’ [-Wimplicit-function-declaration] 1023 | WRLOCK (&unit_rwlock); | ^~ /work/rearnsha/gnusrc/nightly/gcc-cross/master/libgfortran/io/io.h:1025:3: error : implicit declaration of function ‘RWUNLOCK’ [-Wimplicit-function-declaration] 1025 | RWUNLOCK (&unit_rwlock); | ^~~~ R. Hi Richard, The root cause is that the macro WRLOCK and RWUNLOCK are not defined in io.h. The reason of x86 platform not failed is that HAVE_ATOMIC_FETCH_ADD is defined then caused above macros were never been used. Code logic show as below: #ifdef HAVE_ATOMIC_FETCH_ADD (void) __atomic_fetch_add (&u->waiting, -1, __ATOMIC_RELAXED); #else WRLOCK (&unit_rwlock); u->waiting--; RWUNLOCK (&unit_rwlock); #endif I just draft a patch try to fix this bug, because I didn't have arm platform, woul
