Hi Paul-Antoine,
while I still need to continue looking through the patches
(1/3 + this follow up), I thought I could already start by
sending you three ICE examples and two please-add wish for
an existing diagnostic and for missing diagnostic.
Paul-Antoine Arras wrote:
On 21/08/2026 11:31, Tobias Burnus wrote:
If so, the stride to stride multiplier conversion of libgomp/target.c's
omp_target_memcpy_rect_worker, i.e.
+ && __builtin_mul_overflow (element_size, strides[0], &stride))
should be moved to the compiler itself.
I believe this Fortran-specific issue is addressed
in the Fortran patch at the end of this series (3/3).
If turns out not to be, I'm happy to rediscuss it as
part of that patch's review.
As this patch added the libgomp support and as it is ABI
relevant, I wanted to solve it here.
However, I now glanced at 3/3 and it indeed touches this
part again, changing the ABI.
Let's defer it. Breaking the ABI isn't nice, but I assume
for a short time within the same-release mainline it is
okay, especially as it only affects this new feature.
[I think instead of stride and a span, using directly a
stride multiplier makes more sense, but let us discuss this
in 3/3.]
* * *
Your testcase actually highlighted several issues in this patch:
* bogus parse error;
* missing default for length;
* missing dereference in array-shape cast.
These are fixed in the attached fixup patch and exercised by new test
libgomp/testsuite/libgomp.c++/array-shaping-14.C.
Thanks. I think part of the changes are also need for C and
will be done in the C patch.
(This patch only touches C++, except that it also modifies
c-c++-common/gomp/target-update-iterators-4.c which is part
of the 2/3 series (i.e. the C patch.)
* * *
gcc/cp/
* parser.cc (cp_parser_postfix_open_square_expression): Only
accept a 2nd colon (stride) for to/from clauses, not map.
...
I was wondering whether a testcase needs to be added for those?
(Including for C++26?)
Admittedly, I was in particular wondering about the item above (second colon
not in map clauses). It seems as if you need a testcase for C/C++ showing:
foo6.c:3:47: error: expected »]« before »:« token
3 | #pragma omp target enter data map(to: x[ : 1 : 1])
| ^~
| ]
* * *
As regards C++26, I folded into the fixup patch, the patch
"C++: Disambiguate colon syntaxes in array sections" submitted to OG16:
Thanks for the pointer. I will have a look after the 1/3 + 2/3 are
committed (and after 3/3 is at least reviewed).
* * *
I have another ICE for you:
void f() {
int X[10][10];
#pragma omp target update to(X[: : 2][ : :])
#pragma omp target update to(X[: : 2])
}
The first pragma line works - but the second one which
should have identical meaning causes an ICE (segfault)
in
0x148f298 lower_omp_target
../../../repos/gcc/gcc/omp-low.cc:13710
* * *
And another one, also an ICE in omp-low.cc but here in an assert:
void f(int M) {
int X[10][M];
#pragma omp target update to((X)[ : : ][: : 10])
}
foo5.c:3:11: internal compiler error: in lower_omp_target, at omp-low.cc:14183
3 | #pragma omp target update to((X)[ : : ][: : 10])
| ^~~
That's
14183 gcc_checking_assert (tkind
14184 < (HOST_WIDE_INT_C (1U) <<
talign_shift));
And running it in the debugger, I once got:
14114 tkind = OMP_CLAUSE_MAP_KIND (c);
(gdb) n
14116 if (OMP_CLAUSE_MAP_MAYBE_ZERO_LENGTH_ARRAY_SECTION (c))
(gdb) p tkind
$4 = 84
and once
14114 tkind = OMP_CLAUSE_MAP_KIND (c);
(gdb) n
14116 if (OMP_CLAUSE_MAP_MAYBE_ZERO_LENGTH_ARRAY_SECTION (c))
(gdb) p tkind
$7 = 268
Thus, the memory might be actually unset.
* * *
And playing around, I saw that strides etc. are properly honored when
instantiating the template, but I miss an error for the invalid array
shaping (X is not a pointer):
template<typename T>
void f() {
//int X[10][9]; // -> error: OpenMP array shaping operator with non-pointer
argument
T X;
#pragma omp target update to((([10])X)[ : : ][: : 10])
}
void g() {
f<int[10][9]>();
}
* * *
More template fun - another ICE (too many dimensions in the array section):
template<typename T>
void f() {
T y;
#pragma omp target update to(y[: :4][3:3][3])
}
void g(int *x) {
f<int[10][10]>();
}
failing in again in omp-low.cc:
during GIMPLE pass: omplower
foo5.c: In function ‘void f() [with T = int [10][10]]’:
foo5.c:4:11: internal compiler error: Segmentation fault
4 | #pragma omp target update to(y[: :4][3:3][3])
| ^~~
0x2e0015f internal_error(char const*, ...)
../../../repos/gcc/gcc/diagnostic-global-context.cc:787
0x164228f crash_signal
../../../repos/gcc/gcc/toplev.cc:325
0x1474ab6 lookup_sfield
../../../repos/gcc/gcc/omp-low.cc:443
0x1474ab6 build_sender_ref
../../../repos/gcc/gcc/omp-low.cc:774
* * *
Tobias,
who is currently reviewing the patch and will continue to do
so now.
