On 2024-03-01 3:44 a.m., Jakub Jelinek wrote:
Isn't this just that you have 50 in there?
No. It's okay.
The problem is we run out of memory caused by a "ulimit -s 81920" statement
that I had
in .bashrc. The test pass with default stack allocation.
clone(child_stack=0x3191040,
flags=CLONE_V
On 3/1/24 09:44, Jakub Jelinek wrote:
On Fri, Mar 01, 2024 at 09:29:01AM +0100, Tobias Burnus wrote:
John David Anglin wrote:
On 2024-02-29 6:02 p.m., Thomas Schwinge wrote:
I wonder: shouldn't that cap at 50 threads happen inside libgomp,
generally, instead of per test case and user code (!)?
On Fri, Mar 01, 2024 at 09:29:01AM +0100, Tobias Burnus wrote:
> John David Anglin wrote:
> > On 2024-02-29 6:02 p.m., Thomas Schwinge wrote:
> > > I wonder: shouldn't that cap at 50 threads happen inside libgomp,
> > > generally, instead of per test case and user code (!)?
>
> > > Per my
> > > un
Hi all, hi John & Thomas
John David Anglin wrote:
On 2024-02-29 6:02 p.m., Thomas Schwinge wrote:
I wonder: shouldn't that cap at 50 threads happen inside libgomp,
generally, instead of per test case and user code (!)?
Per my
understanding, OpenMP 'num_threads' specifies a *desired* number o
On 2024-02-29 6:02 p.m., Thomas Schwinge wrote:
Hi!
On 2024-02-01T19:20:57+, John David Anglin wrote:
Tested on hppa-unknown-linux-gnu. Committed to trunk.
Set num_threads to 50 on 32-bit hppa in two libgomp loop tests
We support a maximum of 50 threads on 32-bit hppa.
What happens if y
Hi!
On 2024-02-01T19:20:57+, John David Anglin wrote:
> Tested on hppa-unknown-linux-gnu. Committed to trunk.
> Set num_threads to 50 on 32-bit hppa in two libgomp loop tests
>
> We support a maximum of 50 threads on 32-bit hppa.
What happens if you go higher? Curious, what/why is that ar
