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

[Jakub Jelinek]

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.

2023-12-14  Jakub Jelinek  

* c-c++-common/gomp/target-enter-data-1.c: Match also sizeof bar on
32-bit targets - 8 bytes - rather than just 16 bytes.

--- gcc/testsuite/c-c++-common/gomp/target-enter-data-1.c.jj2023-12-14 
07:49:53.364577887 +0100
+++ gcc/testsuite/c-c++-common/gomp/target-enter-data-1.c   2023-12-14 
08:08:59.680964433 +0100
@@ -22,4 +22,4 @@ void func (struct foo *f, int n, int m)
 }
 
 /* { dg-final { scan-tree-dump-times {map\(struct:\*f \[len: 1\]\) 
map\(alloc:[a-z0-9\._]+->vectors \[len: 0\]\) map\(to:\*_[0-9]+ \[len: 
_[0-9]+\]\) map\(attach:[a-z0-9\._]+->vectors \[bias: [^\]]+\]\) 
map\(attach:\*_[0-9]+ \[bias: _[0-9]+\]\)} 1 "gimple" } } */
-/* { dg-final { scan-tree-dump-times {map\(struct:\*\(f->bars \+ \(sizetype\) 
\(\([^\)]+\) n \* 16\)\) \[len: 1\]\) map\(alloc:[a-z0-9\._]+->vectors \[len: 
0\]\) map\(to:\*_[0-9]+ \[len: _[0-9]+\]\) map\(attach:[a-z0-9\._]+->vectors 
\[bias: [^\]]+\]\)} 2 "gimple" } } */
+/* { dg-final { scan-tree-dump-times {map\(struct:\*\(f->bars \+ \(sizetype\) 
\(\([^\)]+\) n \* (?:16|8)\)\) \[len: 1\]\) map\(alloc:[a-z0-9\._]+->vectors 
\[len: 0\]\) map\(to:\*_[0-9]+ \[len: _[0-9]+\]\) 
map\(attach:[a-z0-9\._]+->vectors \[bias: [^\]]+\]\)} 2 "gimple" } } */


Jakub

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

[Zhu, Lipeng]

On 2023/12/14 4:52, Thomas Schwinge wrote:
> Hi Lipeng!
> 
> 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
> 
> >> > > Ok for trunk, thanks.
> 
> >> > Thanks! Looking forward to landing to trunk.
> 
> >> Pushed for you.
> 
> > Thanks for everyone's patience and help, really appreciate that!
> 
> Congratulations on your first contribution to GCC (as far as I can tell)!
> :-)
> 
> 
> 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?
> 
> 
> 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

Hi Thomas,

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?

Lipeng Zhu

Re: Build breakage

[Jonathan Wakely]

On Wed, 13 Dec 2023 at 20:56, Thomas Schwinge  wrote:
>
> Hi!
>
> On 2023-12-13T20:27:44+, Jonathan Wakely  wrote:
> > On Wed, 13 Dec 2023, 19:37 Thomas Schwinge,  wrote:
> >> On 2023-12-13T11:15:54-0800, Jerry D via Gcc  wrote:
> >> > I am getting this failure to build from clean trunk.
> >>
> >> This is due to commit r14-6499-g348874f0baac0f22c98ab11abbfa65fd172f6bdd
> >> "libgomp: basic pinned memory on Linux", which supposedly was only tested
> >> with '--disable-multilib' or so.  As Andrew's now on vacations --
> >> conveniently ;-P -- I'll soon push a fix.
> >>
> >> (To restore your build, you may locally disable the 'gomp_debug' call, or
> >> cast 'size' into '(long) size', for example.)
> >>
> >
> > Wouldn't --disable-werror work too?
>
> I suppose so, but that comes with re-'configure'ing, re-starting the
> build from scratch, or otherwise manually fiddling with 'Makefile's etc.,
> whereas after editing the source file as indicated, you may simply resume
> 'make'.

True. Sometimes start a completely new build with different config is
preferable to changing the sources. Sometimes it isn't :-)

Re: Build breakage

[Thomas Schwinge]

Hi!

On 2023-12-13T20:27:44+, Jonathan Wakely  wrote:
> On Wed, 13 Dec 2023, 19:37 Thomas Schwinge,  wrote:
>> On 2023-12-13T11:15:54-0800, Jerry D via Gcc  wrote:
>> > I am getting this failure to build from clean trunk.
>>
>> This is due to commit r14-6499-g348874f0baac0f22c98ab11abbfa65fd172f6bdd
>> "libgomp: basic pinned memory on Linux", which supposedly was only tested
>> with '--disable-multilib' or so.  As Andrew's now on vacations --
>> conveniently ;-P -- I'll soon push a fix.
>>
>> (To restore your build, you may locally disable the 'gomp_debug' call, or
>> cast 'size' into '(long) size', for example.)
>>
>
> Wouldn't --disable-werror work too?

I suppose so, but that comes with re-'configure'ing, re-starting the
build from scratch, or otherwise manually fiddling with 'Makefile's etc.,
whereas after editing the source file as indicated, you may simply resume
'make'.


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

[Thomas Schwinge]

Hi Lipeng!

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

>> > > Ok for trunk, thanks.

>> > Thanks! Looking forward to landing to trunk.

>> Pushed for you.

> Thanks for everyone's patience and help, really appreciate that!

Congratulations on your first contribution to GCC (as far as I can tell)!
:-)


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?


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: Build breakage

[Jonathan Wakely]

On Wed, 13 Dec 2023, 19:37 Thomas Schwinge,  wrote:

> Hi!
>
> On 2023-12-13T11:15:54-0800, Jerry D via Gcc  wrote:
> > I am getting this failure to build from clean trunk.
>
> This is due to commit r14-6499-g348874f0baac0f22c98ab11abbfa65fd172f6bdd
> "libgomp: basic pinned memory on Linux", which supposedly was only tested
> with '--disable-multilib' or so.  As Andrew's now on vacations --
> conveniently ;-P -- I'll soon push a fix.
>
> (To restore your build, you may locally disable the 'gomp_debug' call, or
> cast 'size' into '(long) size', for example.)
>

Wouldn't --disable-werror work too?

Fix 'libgomp/config/linux/allocator.c' 'size_t' vs. '%ld' format string mismatch (was: Build breakage)

[Thomas Schwinge]

Hi!

On 2023-12-13T20:36:40+0100, I wrote:
> On 2023-12-13T11:15:54-0800, Jerry D via Gcc  wrote:
>> I am getting this failure to build from clean trunk.
>
> This is due to commit r14-6499-g348874f0baac0f22c98ab11abbfa65fd172f6bdd
> "libgomp: basic pinned memory on Linux", which supposedly was only tested
> with '--disable-multilib' or so.  As Andrew's now on vacations --
> conveniently ;-P -- I'll soon push a fix.

Pushed to master branch commit 5445ff4a51fcee4d281f79b5f54b349290d0327d
"Fix 'libgomp/config/linux/allocator.c' 'size_t' vs. '%ld' format string 
mismatch",
see attached.


Grüße
 Thomas


>> In file included from ../../../../trunk/libgomp/config/linux/allocator.c:31:
>> ../../../../trunk/libgomp/config/linux/allocator.c: In function
>> ‘linux_memspace_alloc’:
>> ../../../../trunk/libgomp/config/linux/allocator.c:70:26: error: format
>> ‘%ld’ expects argument of type ‘long int’, but argument 3 has type
>> ‘size_t’ {aka ‘unsigned int’} [-Werror=format=]
>> 70 |   gomp_debug (0, "libgomp: failed to pin %ld bytes of"
>>|  ^
>> 71 |   " memory (ulimit too low?)\n", size);
>>|  
>>|  |
>>|  size_t
>> {aka unsigned int}
>> ../../../../trunk/libgomp/libgomp.h:186:29: note: in definition of macro
>> ‘gomp_debug’
>>186 |   (gomp_debug) ((KIND), __VA_ARGS__); \
>>| ^~~
>> ../../../../trunk/libgomp/config/linux/allocator.c:70:52: note: format
>> string is defined here
>> 70 |   gomp_debug (0, "libgomp: failed to pin %ld bytes of"
>>|  ~~^
>>||
>>|long int
>>|  %d


-
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
>From 5445ff4a51fcee4d281f79b5f54b349290d0327d Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 13 Dec 2023 17:48:11 +0100
Subject: [PATCH] Fix 'libgomp/config/linux/allocator.c' 'size_t' vs. '%ld'
 format string mismatch
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Fix-up for commit 348874f0baac0f22c98ab11abbfa65fd172f6bdd
"libgomp: basic pinned memory on Linux", which may result in build failures
as follow, for example, for the '-m32' multilib of x86_64-pc-linux-gnu:

In file included from [...]/source-gcc/libgomp/config/linux/allocator.c:31:
[...]/source-gcc/libgomp/config/linux/allocator.c: In function ‘linux_memspace_alloc’:
[...]/source-gcc/libgomp/config/linux/allocator.c:70:26: error: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘size_t’ {aka ‘unsigned int’} [-Werror=format=]
   70 |   gomp_debug (0, "libgomp: failed to pin %ld bytes of"
  |  ^
   71 |   " memory (ulimit too low?)\n", size);
  |  
  |  |
  |  size_t {aka unsigned int}
[...]/source-gcc/libgomp/libgomp.h:186:29: note: in definition of macro ‘gomp_debug’
  186 |   (gomp_debug) ((KIND), __VA_ARGS__); \
  | ^~~
[...]/source-gcc/libgomp/config/linux/allocator.c:70:52: note: format string is defined here
   70 |   gomp_debug (0, "libgomp: failed to pin %ld bytes of"
  |  ~~^
  ||
  |long int
  |  %d
cc1: all warnings being treated as errors
make[9]: *** [allocator.lo] Error 1
make[9]: Leaving directory `[...]/build-gcc/x86_64-pc-linux-gnu/32/libgomp'
[...]

Fix this in the same way as used elsewhere in libgomp.

	libgomp/
	* config/linux/allocator.c (linux_memspace_alloc): Fix 'size_t'
	vs. '%ld' format string mismatch.
---
 libgomp/config/linux/allocator.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/libgomp/config/linux/allocator.c b/libgomp/config/linux/allocator.c
index 269d0d607d8..6ffa2417913 100644
--- a/libgomp/config/linux/allocator.c
+++ b/libgomp/config/linux/allocator.c
@@ -50,6 +50,9 @@
 #include 
 

Re: Build breakage

[Thomas Schwinge]

Hi!

On 2023-12-13T11:15:54-0800, Jerry D via Gcc  wrote:
> I am getting this failure to build from clean trunk.

This is due to commit r14-6499-g348874f0baac0f22c98ab11abbfa65fd172f6bdd
"libgomp: basic pinned memory on Linux", which supposedly was only tested
with '--disable-multilib' or so.  As Andrew's now on vacations --
conveniently ;-P -- I'll soon push a fix.

(To restore your build, you may locally disable the 'gomp_debug' call, or
cast 'size' into '(long) size', for example.)


Grüße
 Thomas


> In file included from ../../../../trunk/libgomp/config/linux/allocator.c:31:
> ../../../../trunk/libgomp/config/linux/allocator.c: In function
> ‘linux_memspace_alloc’:
> ../../../../trunk/libgomp/config/linux/allocator.c:70:26: error: format
> ‘%ld’ expects argument of type ‘long int’, but argument 3 has type
> ‘size_t’ {aka ‘unsigned int’} [-Werror=format=]
> 70 |   gomp_debug (0, "libgomp: failed to pin %ld bytes of"
>|  ^
> 71 |   " memory (ulimit too low?)\n", size);
>|  
>|  |
>|  size_t
> {aka unsigned int}
> ../../../../trunk/libgomp/libgomp.h:186:29: note: in definition of macro
> ‘gomp_debug’
>186 |   (gomp_debug) ((KIND), __VA_ARGS__); \
>| ^~~
> ../../../../trunk/libgomp/config/linux/allocator.c:70:52: note: format
> string is defined here
> 70 |   gomp_debug (0, "libgomp: failed to pin %ld bytes of"
>|  ~~^
>||
>|long int
>|  %d
-
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

Build breakage

[Jerry D]

I am getting this failure to build from clean trunk.

In file included from ../../../../trunk/libgomp/config/linux/allocator.c:31:
../../../../trunk/libgomp/config/linux/allocator.c: In function 
‘linux_memspace_alloc’:
../../../../trunk/libgomp/config/linux/allocator.c:70:26: error: format 
‘%ld’ expects argument of type ‘long int’, but argument 3 has type 
‘size_t’ {aka ‘unsigned int’} [-Werror=format=]

   70 |   gomp_debug (0, "libgomp: failed to pin %ld bytes of"
  |  ^
   71 |   " memory (ulimit too low?)\n", size);
  |  
  |  |
  |  size_t 
{aka unsigned int}
../../../../trunk/libgomp/libgomp.h:186:29: note: in definition of macro 
‘gomp_debug’

  186 |   (gomp_debug) ((KIND), __VA_ARGS__); \
  | ^~~
../../../../trunk/libgomp/config/linux/allocator.c:70:52: note: format 
string is defined here

   70 |   gomp_debug (0, "libgomp: failed to pin %ld bytes of"
  |  ~~^
  ||
  |long int
  |  %d