[Bug middle-end/90859] [OMP] Mappings for VLA different depending on 'target { c && { ! lp64 } }'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90859 Thomas Schwinge changed: What|Removed |Added CC||jsm28 at gcc dot gnu.org --- Comment #8 from Thomas Schwinge --- (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 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.
[Bug middle-end/90859] [OMP] Mappings for VLA different depending on 'target { c && { ! lp64 } }'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90859 David Edelsohn changed: What|Removed |Added CC||dje at gcc dot gnu.org --- Comment #7 from David Edelsohn --- I'm seeing a new failure that this string no longer appears in the dump for 32 bit AIX.
[Bug middle-end/90859] [OMP] Mappings for VLA different depending on 'target { c && { ! lp64 } }'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90859 Tobias Burnus changed: What|Removed |Added Depends on||95002 --- Comment #6 from Tobias Burnus --- 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, ' instead of just '= '
[Bug middle-end/90859] [OMP] Mappings for VLA different depending on 'target { c && { ! lp64 } }'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90859 --- Comment #5 from Tobias Burnus --- (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).
[Bug middle-end/90859] [OMP] Mappings for VLA different depending on 'target { c && { ! lp64 } }'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90859 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #4 from Tobias Burnus --- 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.
[Bug middle-end/90859] [OMP] Mappings for VLA different depending on 'target { c && { ! lp64 } }'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90859 Thomas Schwinge changed: What|Removed |Added Keywords||openmp Last reconfirmed|2019-06-20 00:00:00 |2020-4-29 --- Comment #3 from Thomas Schwinge --- 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 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.
[Bug middle-end/90859] [OMP] Mappings for VLA different depending on 'target { c && { ! lp64 } }'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90859 Thomas Schwinge changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-06-20 Ever confirmed|0 |1 --- Comment #2 from Thomas Schwinge --- 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. Per 'gcc-testresults' received so far, the issue does not appear (thus, 'FAIL' for this 'scan-tree-dump') on powerpc-ibm-aix7.2.0.0, aarch64-suse-linux-gnu with '-mabi=ilp32' (manually confirmed), s390x-ibm-linux-gnu with '-m31', i686-apple-darwin9, powerpc-apple-darwin9, x86_64-apple-darwin16, x86_64-apple-darwin17.
[Bug middle-end/90859] [OMP] Mappings for VLA different depending on 'target { c && { ! lp64 } }'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90859 --- Comment #1 from Thomas Schwinge --- Author: tschwinge Date: Tue Jun 18 22:15:16 2019 New Revision: 272452 URL: https://gcc.gnu.org/viewcvs?rev=272452&root=gcc&view=rev Log: [PR90859] Document status quo for "[OMP] Mappings for VLA different depending on 'target { c && { ! lp64 } }'" gcc/testsuite/ PR middle-end/90859 * c-c++-common/goacc/firstprivate-mappings-1.c: Update. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/goacc/firstprivate-mappings-1.c