* [Bug libgomp/96198] new test case libgomp.c/loop-21.c in r11-2077
2020-07-14 17:01 [Bug libgomp/96198] New: new test case libgomp.c/loop-21.c in r11-2077 seurer at linux dot vnet.ibm.com
@ 2020-07-14 17:02 ` seurer at linux dot vnet.ibm.com
2020-07-14 17:33 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: seurer at linux dot vnet.ibm.com @ 2020-07-14 17:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96198
Bill Seurer <seurer at linux dot vnet.ibm.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Build| |powerpc64*-linux-gnu
Host| |powerpc64*-linux-gnu
Target| |powerpc64*-linux-gnu
--- Comment #1 from Bill Seurer <seurer at linux dot vnet.ibm.com> ---
Note: failed on powerpc64 both BE and LE
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug libgomp/96198] new test case libgomp.c/loop-21.c in r11-2077
2020-07-14 17:01 [Bug libgomp/96198] New: new test case libgomp.c/loop-21.c in r11-2077 seurer at linux dot vnet.ibm.com
2020-07-14 17:02 ` [Bug libgomp/96198] " seurer at linux dot vnet.ibm.com
@ 2020-07-14 17:33 ` jakub at gcc dot gnu.org
2020-07-14 19:03 ` jakub at gcc dot gnu.org
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-07-14 17:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96198
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed| |2020-07-14
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug libgomp/96198] new test case libgomp.c/loop-21.c in r11-2077
2020-07-14 17:01 [Bug libgomp/96198] New: new test case libgomp.c/loop-21.c in r11-2077 seurer at linux dot vnet.ibm.com
2020-07-14 17:02 ` [Bug libgomp/96198] " seurer at linux dot vnet.ibm.com
2020-07-14 17:33 ` jakub at gcc dot gnu.org
@ 2020-07-14 19:03 ` jakub at gcc dot gnu.org
2020-07-15 7:59 ` tschwinge at gcc dot gnu.org
2020-07-15 14:45 ` cvs-commit at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-07-14 19:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96198
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think
--- gcc/omp-general.c.jj 2020-07-14 12:20:01.520110629 +0200
+++ gcc/omp-general.c 2020-07-14 20:54:48.104237522 +0200
@@ -726,7 +726,7 @@ omp_extract_for_data (gomp_for *for_stmt
if (loop->m1 || loop->m2)
{
gcc_assert (single_nonrect != -1);
- if (single_nonrect_cond_code == LT_EXPR)
+ if (1 || single_nonrect_cond_code == LT_EXPR)
{
n1 = n1first;
n2 = n2first;
@@ -764,7 +764,7 @@ omp_extract_for_data (gomp_for *for_stmt
m1 = fold_convert (itype, m1);
m2 = fold_convert (itype, m2);
tree t2;
- if (single_nonrect_cond_code == LT_EXPR)
+ if (1 || single_nonrect_cond_code == LT_EXPR)
t2 = fold_build2 (MINUS_EXPR, itype, m2, m1);
else
t2 = fold_build2 (MINUS_EXPR, itype, m1, m2);
should fix that, but need to go back to drawing board and see if that is how we
want to handle those cases. That said at least for all the testcases in the
testsuite it currently computes the right number of iterations at least.
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug libgomp/96198] new test case libgomp.c/loop-21.c in r11-2077
2020-07-14 17:01 [Bug libgomp/96198] New: new test case libgomp.c/loop-21.c in r11-2077 seurer at linux dot vnet.ibm.com
` (2 preceding siblings ...)
2020-07-14 19:03 ` jakub at gcc dot gnu.org
@ 2020-07-15 7:59 ` tschwinge at gcc dot gnu.org
2020-07-15 14:45 ` cvs-commit at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: tschwinge at gcc dot gnu.org @ 2020-07-15 7:59 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96198
Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tschwinge at gcc dot gnu.org
Keywords| |openmp
Last reconfirmed|2020-07-14 00:00:00 |2020-7-15
--- Comment #3 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
> g:f418bd4b92a03ee0ec0fe4cfcd896e86e11ac2cf, r11-2077
(No patch submission email for that one, by the way?)
(In reply to Jakub Jelinek from comment #2)
> I think
> --- gcc/omp-general.c.jj 2020-07-14 12:20:01.520110629 +0200
> +++ gcc/omp-general.c 2020-07-14 20:54:48.104237522 +0200
> [...]
> should fix that
ACK. (But I've only tested this one testcase.)
Not sure if that's related here, but compiling with '-O2', we see:
libgomp.c/loop-21.c: In function ‘main._omp_fn.11’:
libgomp.c/loop-21.c:211:11: warning: ‘.count.340’ may be used uninitialized
in this function [-Wmaybe-uninitialized]
211 | #pragma omp parallel for collapse(2) lastprivate (i, j, x)
reduction(+:niters)
| ^~~
libgomp.c/loop-21.c: In function ‘main._omp_fn.9’:
libgomp.c/loop-21.c:175:11: warning: ‘.count.327’ may be used uninitialized
in this function [-Wmaybe-uninitialized]
175 | #pragma omp parallel for collapse(2) lastprivate (i, j, x)
reduction(+:niters)
| ^~~
libgomp.c/loop-21.c: In function ‘main._omp_fn.7’:
libgomp.c/loop-21.c:139:11: warning: ‘.count.314’ may be used uninitialized
in this function [-Wmaybe-uninitialized]
139 | #pragma omp parallel for collapse(2) lastprivate (i, j, x)
reduction(+:niters)
| ^~~
libgomp.c/loop-21.c: In function ‘main._omp_fn.5’:
libgomp.c/loop-21.c:103:11: warning: ‘.count.301’ may be used uninitialized
in this function [-Wmaybe-uninitialized]
103 | #pragma omp parallel for collapse(2) lastprivate (i, j, x)
reduction(+:niters)
| ^~~
libgomp.c/loop-21.c: In function ‘main._omp_fn.3’:
libgomp.c/loop-21.c:67:11: warning: ‘.count.288’ may be used uninitialized
in this function [-Wmaybe-uninitialized]
67 | #pragma omp parallel for collapse(2) lastprivate (i, j, x)
reduction(+:niters)
| ^~~
libgomp.c/loop-21.c: In function ‘main._omp_fn.1’:
libgomp.c/loop-21.c:31:11: warning: ‘.count.275’ may be used uninitialized
in this function [-Wmaybe-uninitialized]
31 | #pragma omp parallel for collapse(2) lastprivate (i, j, x)
reduction(+:niters)
| ^~~
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug libgomp/96198] new test case libgomp.c/loop-21.c in r11-2077
2020-07-14 17:01 [Bug libgomp/96198] New: new test case libgomp.c/loop-21.c in r11-2077 seurer at linux dot vnet.ibm.com
` (3 preceding siblings ...)
2020-07-15 7:59 ` tschwinge at gcc dot gnu.org
@ 2020-07-15 14:45 ` cvs-commit at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-07-15 14:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96198
--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:79c12969ec3e9185fdbb90d3b1699d64b1cd0901
commit r11-2138-g79c12969ec3e9185fdbb90d3b1699d64b1cd0901
Author: Jakub Jelinek <jakub@redhat.com>
Date: Wed Jul 15 16:34:54 2020 +0200
openmp: Fix up loop-21.c
I've missed
+FAIL: libgomp.c/loop-21.c execution test
during testing of the recent patch. The problem is that while
for the number of iterations computation it doesn't matter if we compute
min_inner_iterations as (m2 * first + n2 + (adjusted step) + m1 * first +
n1) / step
or (m2 * last + n2 + (adjusted step) + m1 * last + n1) / step provided that
in the second case we use as factor (m1 - m2) * ostep / step rather than
(m2 - m1) * ostep / step, for the logical to actual iterator values
computation
it does matter and in my hand written C implementations of all the cases
(outer
vs. inner loop with increasing vs. decreasing iterator) I'm using the same
computation
and it worked well for all the pseudo-random iterators testing it was
doing.
It also means min_inner_iterations is misnamed, because it is not really
minimum number of inner iterations, whether the first or last outer
iteration
results in the smaller or larger value of this can be (sometimes) only
determined at runtime.
So this patch also renames it to first_inner_iterations.
2020-07-15 Jakub Jelinek <jakub@redhat.com>
PR libgomp/96198
* omp-general.h (struct omp_for_data): Rename min_inner_iterations
member to first_inner_iterations, adjust comment.
* omp-general.c (omp_extract_for_data): Adjust for the above
change.
Always use n1first and n2first to compute it, rather than depending
on single_nonrect_cond_code. Similarly, always compute factor
as (m2 - m1) * outer_step / inner_step rather than sometimes m1 -
m2
depending on single_nonrect_cond_code.
* omp-expand.c (expand_omp_for_init_vars): Rename
min_inner_iterations
to first_inner_iterations and min_inner_iterationsd to
first_inner_iterationsd.
^ permalink raw reply [flat|nested] 6+ messages in thread