Hi Tobias!
I've compared test results for nvptx target for GCC 14 vs. the new OG14,
and ran into a number of unexpected regressions: thousands of compilation
PASS -> FAIL in the Fortran testsuite. The few that I looked at were all
like:
ptxas /tmp/ccAMr7D9.o, line 63; error : Illegal operand type to
instruction 'st'
ptxas /tmp/ccAMr7D9.o, line 63; error : Unknown symbol '%stack'
ptxas fatal : Ptx assembly aborted due to errors
nvptx-as: ptxas returned 255 exit status
compiler exited with status 1
Comparing '-fdump-tree-all' for 'gfortran.dg/pr37287-1.f90' (randomly
picked) for GCC 14 vs. OG14, already in 'pr37287-1.f90.005t.original' we
see:
--- [GCC 14]/pr37287-1.f90.005t.original 2024-07-03 12:45:08.369948469
+0200
+++ [OG14]/pr37287-1.f90.005t.original 2024-07-03 12:44:57.770072298
+0200
@@ -1,3 +1,21 @@
+__attribute__((fn spec (". r r r r ")))
+integer(kind=8) __callback___iso_c_binding_C_ptr (integer(kind=8)
(*<T1c1>) (void *, void * & restrict, integer(kind=2), void (*<T5d>) (void))
cb, void * token, void * this_ptr, integer(kind=2) flag)
+{
+ integer(kind=8) result;
+ void * * scalar;
+
+ result = 0;
+ if (flag == 1)
+ {
+ result = cb (token, &this_ptr, 64, 3, 0B);
+ return result;
+ }
+ L$1:;
+ scalar = (void * *) this_ptr;
+ return result;
+}
+
+
__attribute__((fn spec (". . . ")))
void __copy___iso_c_binding_C_ptr (void * & restrict src, void * &
restrict dst)
{
(In addition to the whole function '__callback___iso_c_binding_C_ptr',
also note that the 'L$1:' label and 'scalar' variable are dead here; but
that's likely unrelated to the issue at hand?)
This points to OG14 commit 92c3af3d4f82351c7133b6ee90e213a8a5a485db
"Fortran/OpenMP: Support mapping of DT with allocatable components":
On 2022-03-01T16:34:18+0100, Tobias Burnus <tob...@codesourcery.com> wrote:
> this patch adds support for mapping something like
> type t
> type(t2), allocatable :: a, b(:)
> integer, allocatable :: c, c(:)
> end type t
> type(t), allocatable :: var, var2(:,:)
>
> !$omp target enter data map(var, var)
>
> which does a deep walk of the components at runtime.
>
> [...]
>
> Issues: None known, but I am sure with experimenting,
> more can be found - [...]
Due to a number of other commits (at least textually) depending on this
one, this commit isn't easy to revert on OG14.
But: if I disable it for nvptx target as per the attached
"Fortran/OpenMP: Support mapping of DT with allocatable components: disable
'generate_callback_wrapper' for nvptx target",
then we're back to good -- all GCC 14 vs. OG14 regressions resolved for
nvptx target.
By the way: it's possible that we've had the same misbehavior also on
OG13 and earlier, but just nobody ever tested that for nvptx target.
Note that also outside of OG14 (that is, in GCC 14 as well as GCC trunk),
we have a number of instances of:
ptxas /tmp/ccAMr7D9.o, line 63; error : Illegal operand type to
instruction 'st'
ptxas /tmp/ccAMr7D9.o, line 63; error : Unknown symbol '%stack'
... all over the Fortran test suite (only). My current theory therefore
is that there is some latent issue, which is just greatly exacerbated by
OG14 commit 92c3af3d4f82351c7133b6ee90e213a8a5a485db
"Fortran/OpenMP: Support mapping of DT with allocatable components" (or
some related change).
This could be the Fortran front end generating incorrect GIMPLE, or the
middle end or (more likely?) nvptx back end not correctly handling
something that only comes into existance via the Fortran front end.
Anyway: until we understand the underlying issue, OK to push the attached
"Fortran/OpenMP: Support mapping of DT with allocatable components: disable
'generate_callback_wrapper' for nvptx target"
to devel/omp/gcc-14 branch?
Grüße
Thomas
>From 3fb9e4cabea736ace66ee197be1b13a978af10ac Mon Sep 17 00:00:00 2001
From: Thomas Schwinge <tschwi...@baylibre.com>
Date: Wed, 3 Jul 2024 22:09:39 +0200
Subject: [PATCH] Fortran/OpenMP: Support mapping of DT with allocatable
components: disable 'generate_callback_wrapper' for nvptx target
This is, obviously, not the final fix for this issue.
gcc/fortran/
* class.cc (generate_callback_wrapper) [GCC_NVPTX_H]: Disable.
---
gcc/fortran/class.cc | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/gcc/fortran/class.cc b/gcc/fortran/class.cc
index 15aacd98fd8..2c062204e5a 100644
--- a/gcc/fortran/class.cc
+++ b/gcc/fortran/class.cc
@@ -64,6 +64,7 @@ along with GCC; see the file COPYING3. If not see
#include "gfortran.h"
#include "constructor.h"
#include "target-memory.h"
+#include "tm.h" //TODO
/* Inserts a derived type component reference in a data reference chain.
TS: base type of the ref chain so far, in which we will pick the component
@@ -2420,6 +2421,30 @@ generate_callback_wrapper (gfc_symbol *vtab, gfc_symbol *derived,
gfc_namespace *ns, const char *tname,
gfc_component *vtab_cb)
{
+ //TODO
+#ifdef GCC_NVPTX_H
+ /* Code generated here appears not relevant for nvptx target (completely
+ unused?), but results in erroneous PTX code generated:
+
+ ptxas /tmp/ccAMr7D9.o, line 63; error : Illegal operand type to instruction 'st'
+ ptxas /tmp/ccAMr7D9.o, line 63; error : Unknown symbol '%stack'
+ ptxas fatal : Ptx assembly aborted due to errors
+ nvptx-as: ptxas returned 255 exit status
+ compiler exited with status 1
+
+ Note that also outside of OG14 (that is, in GCC 14 as well as GCC trunk),
+ we have a number of instances of this 'ptxas' error, all over the Fortran
+ test suite (only). The current theory therefore is that there is some
+ latent issue, which is just greatly exacerbated by this code here.
+
+ This could be the Fortran front end generating incorrect GIMPLE, or the
+ middle end or (more likely?) nvptx back end not correctly handling
+ something that only comes into existance via the Fortran front end.
+
+ Until that is resolved, just skip this. */
+ return;
+#endif
+
gfc_namespace *sub_ns;
gfc_code *last_code, *block;
gfc_symbol *callback, *cb, *token, *this_ptr, *scalar, *flag, *result;
--
2.34.1
