public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug middle-end/90859] [OMP] Mappings for VLA different depending on 'target { c && { ! lp64 } }'
[not found] <bug-90859-4@http.gcc.gnu.org/bugzilla/>
@ 2020-04-29 21:24 ` tschwinge at gcc dot gnu.org
2020-05-08 7:37 ` burnus at gcc dot gnu.org
` (4 subsequent siblings)
5 siblings, 0 replies; 6+ messages in thread
From: tschwinge at gcc dot gnu.org @ 2020-04-29 21:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90859
Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |openmp
Last reconfirmed|2019-06-20 00:00:00 |2020-4-29
--- Comment #3 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
I've come across this again. And again, I'm just documenting this here, don't
have bandwidth right now to figure out what's going on.
(In reply to Thomas Schwinge from comment #0)
> I noticed the following (with OpenACC, not yet tried to reproduce with
> OpenMP 'target').
Now also reproduced for OpenMP.
> Is there something wrong, or can that behavior be
> explained?
>
> Only 'sizeof array' appears in the offloaded region, yet for 'target { c &&
> { ! lp64 } }' (only!), the gimplifier also creates a mapping for the array
> itself.
Now also reproduced on x86_64-pc-linux-gnu with default '-m64' instead of
'-m32'.
(In reply to Thomas Schwinge from comment #2)
> Experimenting on x86_64-pc-linux-gnu with '-m32', this depends on the data
> type used for 'array_so'. If I change 'uint32_t' to 'unsigned int', I see
> the same strange behavior. If however I change it to 'unsigned long', the
> issue goes away, as it does for 'unsigned short', for example. The code
> inside the region is the same (aside from some type casting); in particular
> there aren't any 'array' references.
Similarly, with test case:
#include <stdint.h>
static void
vla (int array_li)
{
_Complex double array[array_li];
TYPE array_so;
#pragma omp target \
map(from:array_so)
{
array_so = sizeof array;
}
if (array_so != sizeof array)
__builtin_abort ();
}
... compiled with '-fopenmp -O0 -fdump-tree-gimple -DTYPE=int64_t', we get:
#pragma omp target num_teams(1) thread_limit(0) map(from:array_so [len: 8])
firstprivate(array_li.0)
{
sizetype D.2157;
sizetype D.2158;
long int array_so.2;
D.2157 = (sizetype) array_li.0;
D.2158 = D.2157 * 16;
array_so.2 = (long int) D.2158;
array_so = array_so.2;
}
..., but compiled with '-fopenmp -O0 -fdump-tree-gimple -DTYPE=uint64_t', we
get:
#pragma omp target num_teams(1) thread_limit(0) map(from:array_so [len: 8])
firstprivate(array_li.0) map(tofrom:(*array.1) [len: D.2153])
map(firstprivate:array [pointer assign, bias: 0])
{
sizetype D.2157;
sizetype array_so.2;
D.2157 = (sizetype) array_li.0;
array_so.2 = D.2157 * 16;
array_so = array_so.2;
}
..., that is, in the latter case, the 'array' itself gets mapped additionally,
even though unused inside the region.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug middle-end/90859] [OMP] Mappings for VLA different depending on 'target { c && { ! lp64 } }'
[not found] <bug-90859-4@http.gcc.gnu.org/bugzilla/>
2020-04-29 21:24 ` [Bug middle-end/90859] [OMP] Mappings for VLA different depending on 'target { c && { ! lp64 } }' tschwinge at gcc dot gnu.org
@ 2020-05-08 7:37 ` burnus at gcc dot gnu.org
2020-05-08 7:39 ` burnus at gcc dot gnu.org
` (3 subsequent siblings)
5 siblings, 0 replies; 6+ messages in thread
From: burnus at gcc dot gnu.org @ 2020-05-08 7:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90859
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |burnus at gcc dot gnu.org
--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Using
// here: float array[array_li];
...
//#pragma omp target defaultmap(none) map(from:array_so_openmp_target)
#pragma omp parallel default(none) shared(array_so_openmp_target)
array_so_openmp_target = sizeof array;
Shows that the latter works – with an implicit 'firstprivate(array_li.0)' while
the former has no firstprivate and fails.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug middle-end/90859] [OMP] Mappings for VLA different depending on 'target { c && { ! lp64 } }'
[not found] <bug-90859-4@http.gcc.gnu.org/bugzilla/>
2020-04-29 21:24 ` [Bug middle-end/90859] [OMP] Mappings for VLA different depending on 'target { c && { ! lp64 } }' tschwinge at gcc dot gnu.org
2020-05-08 7:37 ` burnus at gcc dot gnu.org
@ 2020-05-08 7:39 ` burnus at gcc dot gnu.org
2020-05-08 10:11 ` burnus at gcc dot gnu.org
` (2 subsequent siblings)
5 siblings, 0 replies; 6+ messages in thread
From: burnus at gcc dot gnu.org @ 2020-05-08 7:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90859
--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Tobias Burnus from comment #4)
Ignore; this comment should have gone into PR94874 (whose test case has a
comment about this PR).
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug middle-end/90859] [OMP] Mappings for VLA different depending on 'target { c && { ! lp64 } }'
[not found] <bug-90859-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2020-05-08 7:39 ` burnus at gcc dot gnu.org
@ 2020-05-08 10:11 ` burnus at gcc dot gnu.org
2021-01-18 21:43 ` dje at gcc dot gnu.org
2021-01-19 8:40 ` tschwinge at gcc dot gnu.org
5 siblings, 0 replies; 6+ messages in thread
From: burnus at gcc dot gnu.org @ 2020-05-08 10:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90859
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Depends on| |95002
--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> ---
My just created PR c/95002 (has a patch) is either a duplicate or at least
covers partially this PR. → mark as 'depends on'.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95002
[Bug 95002] VLA: 'var = sizeof array' gives spurous '= array, <size expr>'
instead of just '= <size expr>'
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug middle-end/90859] [OMP] Mappings for VLA different depending on 'target { c && { ! lp64 } }'
[not found] <bug-90859-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2020-05-08 10:11 ` burnus at gcc dot gnu.org
@ 2021-01-18 21:43 ` dje at gcc dot gnu.org
2021-01-19 8:40 ` tschwinge at gcc dot gnu.org
5 siblings, 0 replies; 6+ messages in thread
From: dje at gcc dot gnu.org @ 2021-01-18 21:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90859
David Edelsohn <dje at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dje at gcc dot gnu.org
--- Comment #7 from David Edelsohn <dje at gcc dot gnu.org> ---
I'm seeing a new failure that this string no longer appears in the dump for 32
bit AIX.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug middle-end/90859] [OMP] Mappings for VLA different depending on 'target { c && { ! lp64 } }'
[not found] <bug-90859-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2021-01-18 21:43 ` dje at gcc dot gnu.org
@ 2021-01-19 8:40 ` tschwinge at gcc dot gnu.org
5 siblings, 0 replies; 6+ messages in thread
From: tschwinge at gcc dot gnu.org @ 2021-01-19 8:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90859
Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jsm28 at gcc dot gnu.org
--- Comment #8 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
(In reply to David Edelsohn from comment #7)
> I'm seeing a new failure that this string no longer appears in the dump for
> 32 bit AIX.
According to <gcc-testresults@gcc.gnu.org> posts, this has been FAILing forever
for powerpc-ibm-aix7.2.0.0 (so, not a "new failure" as far as I can tell?),
ever since my 2019-06-19 r272452 '[PR90859] Document status quo for "[OMP]
Mappings for VLA different depending on 'target { c && { ! lp64 } }'"'. The
problem here relates to front end 'sizetype' internals, for which 'c && { !
lp64 }' doesn't seem to be quite the right conditional.
In PR95002, there is discussion about the actual C/C++ front end and/or
gimplifier changes assumed to be necessary to fix this for good. Spending time
on that would be more useful than figuring out the right testsuite-level
conditional -- but I don't have a good understanding of the relevant C/C++
language-level requirements, and the relevant front end vs. gimple-level
folding.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-01-19 8:40 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-90859-4@http.gcc.gnu.org/bugzilla/>
2020-04-29 21:24 ` [Bug middle-end/90859] [OMP] Mappings for VLA different depending on 'target { c && { ! lp64 } }' tschwinge at gcc dot gnu.org
2020-05-08 7:37 ` burnus at gcc dot gnu.org
2020-05-08 7:39 ` burnus at gcc dot gnu.org
2020-05-08 10:11 ` burnus at gcc dot gnu.org
2021-01-18 21:43 ` dje at gcc dot gnu.org
2021-01-19 8:40 ` tschwinge 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).