Re: [committed] testsuite: Fix up target-enter-data-1.c on 32-bit targets

2023-12-14 Thread Julian Brown 
On Thu, 14 Dec 2023 08:14:56 +0100
Jakub Jelinek  wrote:

> On Wed, Nov 29, 2023 at 11:43:05AM +, Julian Brown wrote:
> > * c-c++-common/gomp/target-enter-data-1.c: Adjust scan
> > output.  
> 
> struct bar { int num_vectors; double *vectors; };
> 
> is 16 bytes only on 64-bit targets, on 32-bit ones it is just 8 bytes,
> so the explicit matching of the * 16 multiplication only works on the
> former.
> 
> Tested on x86_64-linux -m32/-m64, committed to trunk.

That was quick, thank you! Apologies for the breakage.

Julian

RE: [PATCH v7] libgfortran: Replace mutex with rwlock

2023-12-14 Thread Thomas Schwinge 
Hi Lipeng!

On 2023-12-14T02:28:22+, "Zhu, Lipeng"  wrote:
> On 2023/12/14 4:52, Thomas Schwinge wrote:
>> On 2023-12-12T02:05:26+, "Zhu, Lipeng"  wrote:
>> > On 2023/12/12 1:45, H.J. Lu wrote:
>> >> On Sat, Dec 9, 2023 at 7:25 PM Zhu, Lipeng 
>> wrote:
>> >> > On 2023/12/9 23:23, Jakub Jelinek wrote:
>> >> > > On Sat, Dec 09, 2023 at 10:39:45AM -0500, 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

>> I've just filed 
>> "'libgomp.fortran/rwlock_1.f90', 'libgomp.fortran/rwlock_3.f90' execution
>> test timeouts".
>> Would you be able to look into that?

> Sure, I will look into that.
>
> BTW, I didn’t have the PowerPC in hands, do you mind granting the access of 
> your
> test environment to me to help reproduce the issue?

That's unfortunately not possible: it's behind company VPN, restricted
access.  :-/ I'll later try to have at least a quick look where it's
hanging, or what it's doing.


Grüße
 Thomas
-
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 v7] libgfortran: Replace mutex with rwlock

2023-12-14 Thread Tobias Burnus 


 
 
  
   Hi,
   
   
   
Thomas Schwinge wrote:

   
 

   
On 2023-12-14T02:28:22+, "Zhu, Lipeng"  wrote:



 On 2023/12/14 4:52, Thomas Schwinge wrote:
 >> I've just filed > Would you be able to look into that?

   
 



 Sure, I will look into that.
 



 BTW, I didn’t have the PowerPC in hands, do you mind granting the access of your
 

 test environment to me to help reproduce the issue?
 

   
That's unfortunately not possible:

   
  
   How about https://gcc.gnu.org/wiki/CompileFarm I think there is a PowerPC system available.
   
  
    
   
  
   Tobias
   
  
    
   
  
    

Re: [PATCH v7] libgfortran: Replace mutex with rwlock

2023-12-14 Thread Jakub Jelinek 
On Thu, Dec 14, 2023 at 01:29:01PM +0100, Thomas Schwinge wrote:
> > Sure, I will look into that.
> >
> > BTW, I didn’t have the PowerPC in hands, do you mind granting the access of 
> > your
> > test environment to me to help reproduce the issue?
> 
> That's unfortunately not possible: it's behind company VPN, restricted
> access.  :-/ I'll later try to have at least a quick look where it's
> hanging, or what it's doing.

There is always https://gcc.gnu.org/wiki/CompileFarm
There are e.g. 192, 160, 128, 80, 64 thread power machines.
Whether any of them can actually reproduce it, I haven't tried.
But shouldn't be that time consuming to reproduce, for this kind of thing
one can just build
.../configure --enable-languages=c,c++,fortran --disable-bootstrap 
--disable-libsanitizer
make -jN
compiler and just
cd power*/libgomp
make check RUNTESTFLAGS=fortran.exp=rwlock*.f90
repeatedly to see if it gets stuck.

Jakub

Facebook comment

2023-12-14 Thread Bret Cali 
Hi, fortran@gcc.gnu.org

Supercharge your brand and business's social media followers, likes, share
count with the support of our team of social media influencers. We proudly
hold a combined audience of 4 million followers in the United States. 

Your brand, business, and online posts will gain exposure to an extensive 4M
strong US audience across platforms like Facebook, Instagram, and Twitter.

Here's what we offer:

Thousands of Facebook, Instagram, Twitter, and YouTube followers.

Thousands of likes, shares, and comments on your content and post.

Thousands of Influencer brand posting with your brand or business hashtags
on their feed.

 

The best part? Our rates are unbeatable in the market.

 

Join the ranks of 650+ delighted clients who have triumphed over rivals.

 

Awaiting your response.

 

Thank you.

Bret Cali

 

Online Reputation Expert | Google Business Profile Agency Partner

Re: [PATCH v7 4/5] OpenMP/OpenACC: Unordered/non-constant component offset runtime diagnostic

2023-12-14 Thread Tobias Burnus 

On 19.08.23 00:47, Julian Brown wrote:

This patch adds support for non-constant component offsets in "map"
clauses for OpenMP (and the equivalants for OpenACC), which are not able
to be sorted into order at compile time.  Normally struct accesses in
such clauses are gathered together and sorted into increasing address
order after a "GOMP_MAP_STRUCT" node: if we have variable indices,
that is no longer possible.

This version of the patch scales back the previously-posted version to
merely add a diagnostic for incorrect usage of component accesses with
variably-indexed arrays of structs: the only permitted variant is where
we have multiple indices that are the same, but we could not prove so
at compile time.  Rather than silently producing the wrong result for
cases where the indices are in fact different, we error out (e.g.,
"map(dtarr(i)%arrptr, dtarr(j)%arrptr(4:8))", for different i/j).

For now, multiple *constant* array indices are still supported (see
map-arrayofstruct-1.c).  That could perhaps be addressed with a follow-up
patch, if necessary.

This version of the patch renumbers the GOMP_MAP_STRUCT_UNORD kind to
avoid clashing with the OpenACC "non-contiguous" dynamic array support
(though that is not yet applied to mainline).


LGTM with:

- inclusion of your follow-up fix for shared-memory systems (see email
of August 21)

- adding a comment to map-arrayofstruct-1.c indicating that this usage
is an extension, violating a restriction (be a bit more explicit that
just that)

See https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603126.html
for a quote of the specification or (same wording, newer spec) in TR12
under "Restrictions to the map clause are as follows:" in "6.8.3 map
Clause" [218+219:36-37+1-3]

Thanks,

Tobias


2023-08-18  Julian Brown  

gcc/
  * gimplify.cc (extract_base_bit_offset): Add VARIABLE_OFFSET parameter.
  (omp_get_attachment, omp_group_last, omp_group_base,
  omp_directive_maps_explicitly): Add GOMP_MAP_STRUCT_UNORD support.
  (omp_accumulate_sibling_list): Update calls to extract_base_bit_offset.
  Support GOMP_MAP_STRUCT_UNORD.
  (omp_build_struct_sibling_lists, gimplify_scan_omp_clauses,
  gimplify_adjust_omp_clauses, gimplify_omp_target_update): Add
  GOMP_MAP_STRUCT_UNORD support.
  * omp-low.cc (lower_omp_target): Add GOMP_MAP_STRUCT_UNORD support.
  * tree-pretty-print.cc (dump_omp_clause): Likewise.

include/
  * gomp-constants.h (gomp_map_kind): Add GOMP_MAP_STRUCT_UNORD.

libgomp/
  * oacc-mem.c (find_group_last, goacc_enter_data_internal,
  goacc_exit_data_internal, GOACC_enter_exit_data): Add
  GOMP_MAP_STRUCT_UNORD support.
  * target.c (gomp_map_vars_internal): Add GOMP_MAP_STRUCT_UNORD support.
  Detect incorrect use of variable indexing of arrays of structs.
  (GOMP_target_enter_exit_data, gomp_target_task_fn): Add
  GOMP_MAP_STRUCT_UNORD support.
  * testsuite/libgomp.c-c++-common/map-arrayofstruct-1.c: New test.
  * testsuite/libgomp.c-c++-common/map-arrayofstruct-2.c: New test.
  * testsuite/libgomp.c-c++-common/map-arrayofstruct-3.c: New test.
  * testsuite/libgomp.fortran/map-subarray-5.f90: New test.
---
  gcc/gimplify.cc   | 110 ++
  gcc/omp-low.cc|   1 +
  gcc/tree-pretty-print.cc  |   3 +
  include/gomp-constants.h  |   6 +
  libgomp/oacc-mem.c|   6 +-
  libgomp/target.c  |  60 +-
  .../map-arrayofstruct-1.c |  38 ++
  .../map-arrayofstruct-2.c |  58 +
  .../map-arrayofstruct-3.c |  68 +++
  .../libgomp.fortran/map-subarray-5.f90|  54 +
  10 files changed, 377 insertions(+), 27 deletions(-)
  create mode 100644 
libgomp/testsuite/libgomp.c-c++-common/map-arrayofstruct-1.c
  create mode 100644 
libgomp/testsuite/libgomp.c-c++-common/map-arrayofstruct-2.c
  create mode 100644 
libgomp/testsuite/libgomp.c-c++-common/map-arrayofstruct-3.c
  create mode 100644 libgomp/testsuite/libgomp.fortran/map-subarray-5.f90

diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
index fad4308a0eb4..e682583054b0 100644
--- a/gcc/gimplify.cc
+++ b/gcc/gimplify.cc
@@ -8965,7 +8965,8 @@ build_omp_struct_comp_nodes (enum tree_code code, tree 
grp_start, tree grp_end,

  static tree
  extract_base_bit_offset (tree base, poly_int64 *bitposp,
-  poly_offset_int *poffsetp)
+  poly_offset_int *poffsetp,
+  bool *variable_offset)
  {
tree offset;
poly_int64 bitsize, bitpos;
@@ -8983,10 +8984,13 @@ extract_base_bit_offset (tree base, poly_int64 *bitposp,
if (offset && poly_int_tree_p (offset))
  {
poffset = wi::to_poly_offset (offset);
-  offset = NULL_TREE;
+  *variable_offset = false;
  }
else
-poffset = 0;
+{
+

Re: [PATCH v7] libgfortran: Replace mutex with rwlock

2023-12-14 Thread Richard Earnshaw (lists) 
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.

> ---
> v1 -> v2:
> Limit the pthread_rwlock usage in libgcc only when __cplusplus isn't defined.
> 
> v2 -> v3:
> Rebase the patch with trunk branch.
> 
> v3 -> v4:
> Update the comments.
> 
> v4 -> v5:
> Fix typos and code formatter.
> 
> v5 -> v6:
> Add unit tests.
> 
> v6 -> v7:
> Update ChangeLog and code formatter.
> 
> Reviewed-by: Hongjiu Lu 
> Reviewed-by: Bernhard Reutner-Fischer 
> Reviewed-by: Thomas Koenig 
> Reviewed-by: Jakub Jelinek 
> Signed-off-by: Lipeng Zhu 
> ---
>  libgcc/gthr-posix.h   |  60 +++
>  libgfortran/io/async.c|   4 +
>  libgfortran/io/async.h| 151 ++
>  libgfortran/io/io.h   |  15 +-
>  libgfortran/io/transfer.c |   8 +-
>  libgfortran/io/unit.c | 117 +-
>  libgfortran/io/unix.c |  16 +-
>  .../testsuite/libgomp.fortran/rwlock_1.f90|  33 
>  .../testsuite/libgomp.fortran/rwlock_2.f90|  22 +++
>  .../testsuite/libgomp.fortran/rwlock_3.f90|  18 +++
>  10 files changed, 386 insertions(+), 58 deletions(-)
>  create mode 100644 libgomp/testsuite/libgomp.fortran/rwlock_1.f90
>  create mode 100644 libgomp/testsuite/libgomp.fortran/rwlock_2.f90
>  create mode 100644 libgomp/testsuite/libgomp.fortran/rwlock_3.f90
> 
> diff --git a/libgcc/

[patch, fortran, committed] PR112873 F2023 degree trig functions

2023-12-14 Thread Jerry D 

The following has been committed per discussion in the subject PR.

commit 95b70545331764c85079a1d0e1e19b605bda1456 (HEAD -> master, 
origin/master, origin/HEAD)

Author: Jerry DeLisle 
Date:   Wed Dec 13 19:04:50 2023 -0800

fortran: Add degree based trig functions for F2023

PR fortran/112873

gcc/fortran/ChangeLog:

* gfortran.texi: Update to reflect the changes.
* intrinsic.cc (add_functions): Update the standard that the
various  degree trigonometric functions have been described in.
(gfc_check_intrinsic_standard): Add an error string for F2023.
* intrinsic.texi: Update accordingly.

Thanks to Steve for the changes checked by Harald and myself. I know 
there is a way to do a co-Author on a git commit. Will try to do that 
next time when it applies.


Jerry

RE: [PATCH v7] libgfortran: Replace mutex with rwlock

2023-12-14 Thread Zhu, Lipeng 

On 2023/12/14 20:39, Jakub Jelinek wrote:
> On Thu, Dec 14, 2023 at 01:29:01PM +0100, Thomas Schwinge wrote:
>>> Sure, I will look into that.
>>>
>>> BTW, I didn’t have the PowerPC in hands, do you mind granting the access of 
>>> your
>>> test environment to me to help reproduce the issue?
>>
>> That's unfortunately not possible: it's behind company VPN, restricted
>> access.  :-/ I'll later try to have at least a quick look where it's
>> hanging, or what it's doing.
> 
> There is always https://gcc.gnu.org/wiki/CompileFarm
> There are e.g. 192, 160, 128, 80, 64 thread power machines.

Thanks Jakub,

I submit a request to join the CompileFarm project. Could you help to approve 
it?

Lipeng Zhu

> Whether any of them can actually reproduce it, I haven't tried.
> But shouldn't be that time consuming to reproduce, for this kind of thing
> one can just build
> .../configure --enable-languages=c,c++,fortran --disable-bootstrap 
> --disable-libsanitizer
> make -jN
> compiler and just
> cd power*/libgomp
> make check RUNTESTFLAGS=fortran.exp=rwlock*.f90
> repeatedly to see if it gets stuck.
> 
>   Jakub
> 
>