public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug testsuite/113085] New: New test case libgomp.c/alloc-pinned-1.c from r14-6499-g348874f0baac0f fails
@ 2023-12-19 17:29 seurer at gcc dot gnu.org
  2023-12-20 11:01 ` [Bug testsuite/113085] " ams at gcc dot gnu.org
                   ` (7 more replies)
  0 siblings, 8 replies; 9+ messages in thread
From: seurer at gcc dot gnu.org @ 2023-12-19 17:29 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113085

            Bug ID: 113085
           Summary: New test case libgomp.c/alloc-pinned-1.c from
                    r14-6499-g348874f0baac0f fails
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: testsuite
          Assignee: unassigned at gcc dot gnu.org
          Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:348874f0baac0f22c98ab11abbfa65fd172f6bdd, r14-6499-g348874f0baac0f
make  -k check-target-libgomp RUNTESTFLAGS="c.exp=libgomp.c/alloc-pinned-1.c"
FAIL: libgomp.c/alloc-pinned-1.c execution test
# of expected passes            1
# of unexpected failures        1

commit 348874f0baac0f22c98ab11abbfa65fd172f6bdd (HEAD)
Author: Andrew Stubbs <ams@codesourcery.com>
Date:   Tue Jan 4 12:22:01 2022 +0000

    libgomp: basic pinned memory on Linux

spawn [open ...]
unsufficient lockable memory; please increase ulimit
FAIL: libgomp.c/alloc-pinned-1.c execution test


"Unsufficient"?  Is that a typo?

In any case I don't think a test should require an unusual ulimit setting.

seurer@ltcden2-lp1:~/gcc/git/build/gcc-test$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 3909068
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 3909068
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug testsuite/113085] New test case libgomp.c/alloc-pinned-1.c from r14-6499-g348874f0baac0f fails
  2023-12-19 17:29 [Bug testsuite/113085] New: New test case libgomp.c/alloc-pinned-1.c from r14-6499-g348874f0baac0f fails seurer at gcc dot gnu.org
@ 2023-12-20 11:01 ` ams at gcc dot gnu.org
  2023-12-23  4:52 ` seurer at gcc dot gnu.org
                   ` (6 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: ams at gcc dot gnu.org @ 2023-12-20 11:01 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113085

--- Comment #1 from Andrew Stubbs <ams at gcc dot gnu.org> ---
That is a typo.

I don't want to make it pass on machines that have insufficient memory
configured because it will mask the case where it fails for another reason.

However, the testcase was originally supposed to fit in 64kB. Is your page size
larger than 4kB?

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug testsuite/113085] New test case libgomp.c/alloc-pinned-1.c from r14-6499-g348874f0baac0f fails
  2023-12-19 17:29 [Bug testsuite/113085] New: New test case libgomp.c/alloc-pinned-1.c from r14-6499-g348874f0baac0f fails seurer at gcc dot gnu.org
  2023-12-20 11:01 ` [Bug testsuite/113085] " ams at gcc dot gnu.org
@ 2023-12-23  4:52 ` seurer at gcc dot gnu.org
  2023-12-23  6:09 ` pinskia at gcc dot gnu.org
                   ` (5 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: seurer at gcc dot gnu.org @ 2023-12-23  4:52 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113085

--- Comment #2 from seurer at gcc dot gnu.org ---
Looks like it is 65,536

seurer@ltcden2-lp1:~/gcc/git/build/gcc-test$ getconf PAGESIZE 
65536

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug testsuite/113085] New test case libgomp.c/alloc-pinned-1.c from r14-6499-g348874f0baac0f fails
  2023-12-19 17:29 [Bug testsuite/113085] New: New test case libgomp.c/alloc-pinned-1.c from r14-6499-g348874f0baac0f fails seurer at gcc dot gnu.org
  2023-12-20 11:01 ` [Bug testsuite/113085] " ams at gcc dot gnu.org
  2023-12-23  4:52 ` seurer at gcc dot gnu.org
@ 2023-12-23  6:09 ` pinskia at gcc dot gnu.org
  2023-12-27 12:48 ` ams at gcc dot gnu.org
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-12-23  6:09 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113085

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu.org

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
yes while the most common page size on x86_64 is 4k; 64k and 16k page sizes
also happen on other targets (16k shows up on aarch64, especially when on a Mac
due to limitations in the HW).
I personally use 64k on aarch64 .

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug testsuite/113085] New test case libgomp.c/alloc-pinned-1.c from r14-6499-g348874f0baac0f fails
  2023-12-19 17:29 [Bug testsuite/113085] New: New test case libgomp.c/alloc-pinned-1.c from r14-6499-g348874f0baac0f fails seurer at gcc dot gnu.org
                   ` (2 preceding siblings ...)
  2023-12-23  6:09 ` pinskia at gcc dot gnu.org
@ 2023-12-27 12:48 ` ams at gcc dot gnu.org
  2024-02-07 22:23 ` seurer at gcc dot gnu.org
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: ams at gcc dot gnu.org @ 2023-12-27 12:48 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113085

--- Comment #4 from Andrew Stubbs <ams at gcc dot gnu.org> ---
It's going to be difficult to make this test work when only one page of locked
memory is available. :-(

I will look at making it "unsupported".

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug testsuite/113085] New test case libgomp.c/alloc-pinned-1.c from r14-6499-g348874f0baac0f fails
  2023-12-19 17:29 [Bug testsuite/113085] New: New test case libgomp.c/alloc-pinned-1.c from r14-6499-g348874f0baac0f fails seurer at gcc dot gnu.org
                   ` (3 preceding siblings ...)
  2023-12-27 12:48 ` ams at gcc dot gnu.org
@ 2024-02-07 22:23 ` seurer at gcc dot gnu.org
  2024-02-08  9:06 ` ams at gcc dot gnu.org
                   ` (2 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: seurer at gcc dot gnu.org @ 2024-02-07 22:23 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113085

--- Comment #5 from seurer at gcc dot gnu.org ---
I should note that pinned-2 also fails on powerpc64 LE.

make  -k check-target-libgomp RUNTESTFLAGS="c.exp=libgomp.c/alloc-pinned-*"
FAIL: libgomp.c/alloc-pinned-1.c execution test
FAIL: libgomp.c/alloc-pinned-2.c execution test


On powerpc64 BE pinned-3 and -4 fail (but not -1 and -2):

make  -k check-target-libgomp RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'
c.exp=libgomp.c/alloc-pinned-*"
FAIL: libgomp.c/alloc-pinned-3.c execution test
FAIL: libgomp.c/alloc-pinned-4.c execution test

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug testsuite/113085] New test case libgomp.c/alloc-pinned-1.c from r14-6499-g348874f0baac0f fails
  2023-12-19 17:29 [Bug testsuite/113085] New: New test case libgomp.c/alloc-pinned-1.c from r14-6499-g348874f0baac0f fails seurer at gcc dot gnu.org
                   ` (4 preceding siblings ...)
  2024-02-07 22:23 ` seurer at gcc dot gnu.org
@ 2024-02-08  9:06 ` ams at gcc dot gnu.org
  2024-02-08 15:27 ` seurer at gcc dot gnu.org
  2024-02-12 10:16 ` ams at gcc dot gnu.org
  7 siblings, 0 replies; 9+ messages in thread
From: ams at gcc dot gnu.org @ 2024-02-08  9:06 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113085

--- Comment #6 from Andrew Stubbs <ams at gcc dot gnu.org> ---
(In reply to seurer from comment #5)
> I should note that pinned-2 also fails on powerpc64 LE.
> 
> make  -k check-target-libgomp RUNTESTFLAGS="c.exp=libgomp.c/alloc-pinned-*"
> FAIL: libgomp.c/alloc-pinned-1.c execution test
> FAIL: libgomp.c/alloc-pinned-2.c execution test
> 
> 
> On powerpc64 BE pinned-3 and -4 fail (but not -1 and -2):
> 
> make  -k check-target-libgomp RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'
> c.exp=libgomp.c/alloc-pinned-*"
> FAIL: libgomp.c/alloc-pinned-3.c execution test
> FAIL: libgomp.c/alloc-pinned-4.c execution test

Please show any messages in the libgomp.log file, and find out what the page
sizes and locked memory limits are on both machines.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug testsuite/113085] New test case libgomp.c/alloc-pinned-1.c from r14-6499-g348874f0baac0f fails
  2023-12-19 17:29 [Bug testsuite/113085] New: New test case libgomp.c/alloc-pinned-1.c from r14-6499-g348874f0baac0f fails seurer at gcc dot gnu.org
                   ` (5 preceding siblings ...)
  2024-02-08  9:06 ` ams at gcc dot gnu.org
@ 2024-02-08 15:27 ` seurer at gcc dot gnu.org
  2024-02-12 10:16 ` ams at gcc dot gnu.org
  7 siblings, 0 replies; 9+ messages in thread
From: seurer at gcc dot gnu.org @ 2024-02-08 15:27 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113085

--- Comment #7 from seurer at gcc dot gnu.org ---
I posted the LE stuff already but here it is again:

spawn [open ...]^M
unsufficient lockable memory; please increase ulimit
FAIL: libgomp.c/alloc-pinned-1.c execution test

seurer@ltcden2-lp1:~/gcc/git/build/gcc-test$ ulimit -a
...
max locked memory       (kbytes, -l) 64
...
seurer@ltcden2-lp1:~/gcc/git/build/gcc-test$ getconf PAGESIZE
65536

This is a RHEL 8.9 machine and as far as I know it is using the default ulimit
settings.


On the BE machine:

seurer@nilram:~/gcc/git/build/gcc-test$ ulimit -a
real-time non-blocking time  (microseconds, -R) unlimited
...
max locked memory           (kbytes, -l) 529679232
...
seurer@nilram:~/gcc/git/build/gcc-test$ getconf PAGESIZE
65536


There were no messages.  Running it in gdb I get:

(gdb) where
#0  0x0fce3340 in ?? () from /lib32/libc.so.6
#1  0x0fc851e4 in raise () from /lib32/libc.so.6
#2  0x0fc6a128 in abort () from /lib32/libc.so.6
#3  0x10000ae4 in set_pin_limit (size=size@entry=131072) at
/home/seurer/gcc/git/gcc-test/libgomp/testsuite/libgomp.c/alloc-pinned-4.c:44
#4  0x10000754 in main () at
/home/seurer/gcc/git/gcc-test/libgomp/testsuite/libgomp.c/alloc-pinned-4.c:106


  if (getrlimit (RLIMIT_MEMLOCK, &limit))
    abort ();   // line 44 in alloc-pinned-4.c

This is a Debian Trixie machine and it too is using whatever the defaults are.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug testsuite/113085] New test case libgomp.c/alloc-pinned-1.c from r14-6499-g348874f0baac0f fails
  2023-12-19 17:29 [Bug testsuite/113085] New: New test case libgomp.c/alloc-pinned-1.c from r14-6499-g348874f0baac0f fails seurer at gcc dot gnu.org
                   ` (6 preceding siblings ...)
  2024-02-08 15:27 ` seurer at gcc dot gnu.org
@ 2024-02-12 10:16 ` ams at gcc dot gnu.org
  7 siblings, 0 replies; 9+ messages in thread
From: ams at gcc dot gnu.org @ 2024-02-12 10:16 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113085

--- Comment #8 from Andrew Stubbs <ams at gcc dot gnu.org> ---
(In reply to seurer from comment #7)
> On the BE machine:
> 
> seurer@nilram:~/gcc/git/build/gcc-test$ ulimit -a
> real-time non-blocking time  (microseconds, -R) unlimited
> ...
> max locked memory           (kbytes, -l) 529679232
> ...

That's a suspiciously large number, but OK.

> seurer@nilram:~/gcc/git/build/gcc-test$ getconf PAGESIZE
> 65536
> 
> 
> There were no messages.  Running it in gdb I get:
> 
> (gdb) where
> #0  0x0fce3340 in ?? () from /lib32/libc.so.6
> #1  0x0fc851e4 in raise () from /lib32/libc.so.6
> #2  0x0fc6a128 in abort () from /lib32/libc.so.6
> #3  0x10000ae4 in set_pin_limit (size=size@entry=131072) at
> /home/seurer/gcc/git/gcc-test/libgomp/testsuite/libgomp.c/alloc-pinned-4.c:44
> #4  0x10000754 in main () at
> /home/seurer/gcc/git/gcc-test/libgomp/testsuite/libgomp.c/alloc-pinned-4.c:
> 106
> 
> 
>   if (getrlimit (RLIMIT_MEMLOCK, &limit))
>     abort ();   // line 44 in alloc-pinned-4.c

Why would that fail? Perhaps you can investigate the errno. You're probably
best placed to submit a patch for whatever this issue is.

> 
> This is a Debian Trixie machine and it too is using whatever the defaults
> are.

Good to know.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2024-02-12 10:16 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-12-19 17:29 [Bug testsuite/113085] New: New test case libgomp.c/alloc-pinned-1.c from r14-6499-g348874f0baac0f fails seurer at gcc dot gnu.org
2023-12-20 11:01 ` [Bug testsuite/113085] " ams at gcc dot gnu.org
2023-12-23  4:52 ` seurer at gcc dot gnu.org
2023-12-23  6:09 ` pinskia at gcc dot gnu.org
2023-12-27 12:48 ` ams at gcc dot gnu.org
2024-02-07 22:23 ` seurer at gcc dot gnu.org
2024-02-08  9:06 ` ams at gcc dot gnu.org
2024-02-08 15:27 ` seurer at gcc dot gnu.org
2024-02-12 10:16 ` ams at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).