https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93462
Tobias Burnus changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81690
--- Comment #6 from Tobias Burnus ---
Regarding {target-32.c, thread-limit-2.c}, see
https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00422.html
for a busy-wait implementation, which was supposed get rewritten (see next
message in thread) "using d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81690
--- Comment #7 from Tobias Burnus ---
(In reply to Tobias Burnus from comment #6)
> for a busy-wait implementation, which was supposed get rewritten (see next
> message in thread) "using declare variant".
The missing bit referenced there is:
htt
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jrfsousa at gmail dot com
Target Milestone: ---
Created attachment 47987
--> https://gcc.gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94070
--- Comment #1 from Tobias Burnus ---
Created attachment 47988
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47988&action=edit
… with assumed_rank_19.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94070
--- Comment #2 from Tobias Burnus ---
(In reply to Tobias Burnus from comment #0)
> Testing shows that assumed-rank arrays are mishandled in several ways
Additionally, with assumed-size arrays passed to assumed-rank dummies:
both size(x) and siz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94070
--- Comment #3 from Tobias Burnus ---
*** Bug 94020 has been marked as a duplicate of this bug. ***
||burnus at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #1 from Tobias Burnus ---
I know your PR came first – but I have admittedly not found it when searching
for "assumed rank". As the other PR (PR94070) shows there is a mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94070
--- Comment #4 from Tobias Burnus ---
José's PR (which came earlier then mine, hmm) has also an extensive test case
in
attachment 47960 for assumed-size arrays.
NCONFIRMED
Keywords: ice-on-invalid-code, openacc
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
The following code gives an ICE; I believe it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94120
--- Comment #2 from Tobias Burnus ---
Created attachment 48012
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48012&action=edit
Draft patch for C and Fortran, C++ is missing!
NOTE: A similar Fortran test case currently fails with:
Error:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94120
--- Comment #3 from Tobias Burnus ---
Patch for Fortran:
https://gcc.gnu.org/pipermail/gcc-patches/current/541774.html
Todo: C (see attachment 48012) and C++ (patch) + testcases for both.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90862
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90921
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
Keywords: openacc, rejects-valid
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
The spec has:
"A declare directive is used in the declaration se
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
The following test case gives:
error: ‘foo::A’ is not a variable in ‘map’ clause
>From the word
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94120
--- Comment #4 from Tobias Burnus ---
(In reply to Tobias Burnus from comment #3)
> Patch for Fortran:
> https://gcc.gnu.org/pipermail/gcc-patches/current/541774.html
Patch for C + C++:
https://gcc.gnu.org/pipermail/gcc-patches/current/541840.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94120
--- Comment #5 from Tobias Burnus ---
(In reply to Tobias Burnus from comment #4)
> Patch for C + C++:
> https://gcc.gnu.org/pipermail/gcc-patches/current/541840.html
> See also PR 94140 for declare and 'class' and OpenACC's Issue 288.
The Fortr
at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Compiling gcc-mainline/libgomp/testsuite/libgomp.c/target-link-1.c with
"-fopenmp -O3" (instead of default -O2) fails as follows.
[I also did see "libgomp: Cannot map target variables (size mi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94233
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
NCONFIRMED
Keywords: openmp, wrong-code
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Follow-up to PR 94233.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94251
--- Comment #1 from Tobias Burnus ---
Created attachment 48077
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48077&action=edit
(Partial patch): Patch for gomp_load_image_to_device to handle link_flag
correctly
[Cross ref: nvptx disables t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94233
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81689
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81689
--- Comment #2 from Tobias Burnus ---
While the two PRs have fixed offloading for AMDGCN, nvptx still fails with the
same error. The generated assembler is:
"ld.global.u64 %r27,[a$linkptr];\n"
But there is NO associated global-var declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94251
--- Comment #3 from Tobias Burnus ---
FIXED for AMDGCN – see PR 81689 for Nvptx, which still fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81689
Bug 81689 depends on bug 94251, which changed state.
Bug 94251 Summary: [OpenMP] 'target link' fails at run time /
libgomp.c/target-link-1.c fails on GCN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94251
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94251
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81689
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
: UNCONFIRMED
Keywords: ice-on-invalid-code, openmp
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
May or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94320
--- Comment #2 from Tobias Burnus ---
(In reply to Jakub Jelinek from comment #1)
> tried
> + && !lto_stream_offload_p
With that patch, I get 6 times "has been referenced in offloaded code but
hasn't been marked to be included in the offloa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94282
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93363
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94324
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93957
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
|RESOLVED
CC||burnus at gcc dot gnu.org
--- Comment #5 from Tobias Burnus ---
FIXED for GCC 10 alias mainline + GCC 9.
Thanks for the report.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94386
--- Comment #7 from Tobias Burnus ---
(In reply to Bill Seurer from comment #6)
> These were both clean builds run on a powerpc64 power8 LE machine.
I can confirm this on x86-64-gnu-linux; if I use the current trunk and undo
this commit, it work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94246
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93581
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93833
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
|--- |FIXED
CC||burnus at gcc dot gnu.org
--- Comment #3 from Tobias Burnus ---
FIXED – thanks for the report!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94120
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94140
Tobias Burnus changed:
What|Removed |Added
See Also||https://github.com/OpenACC/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92736
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93339
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
: openmp
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
The test case c-c++-common/gomp/requires-1.c compiles with gcc/g++ -fopenmp.
But …
Just
Keywords: openmp, wrong-code
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Based on an OpenMP test case from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94635
--- Comment #1 from Tobias Burnus ---
Just showing the dump – without further analysis:
#pragma omp target enter data
map(alloc:MEM[(c_char *)_9] [len: _8]) // _9 = my1dptr.data, _8 = 20*4
map(to:my1dptr [pointer set, len: 64])
map(all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94635
Tobias Burnus changed:
What|Removed |Added
Ever confirmed|0 |1
Component|libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94635
Tobias Burnus changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
Keywords: openmp, wrong-code
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
That's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94140
--- Comment #2 from Tobias Burnus ---
PR 94120 also needs to be revisited once the semantic of same-scope has been
clarified at OpenACC.
See also: https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543709.html
It looks as if the current check
, rejects-valid
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Created attachment 48323
--> ht
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94690
--- Comment #1 from Tobias Burnus ---
However, adding LASTPRIVATE to OMP_DISTRIBUTE_CLAUSES (see patch) *is*
sufficient for sollve_vv's test_target_teams_distribute_lastprivate.F90.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94690
--- Comment #2 from Tobias Burnus ---
(In reply to Tobias Burnus from comment #0)
> * pr66199-4.f90 + pr66199-5.f90 do not recognize 'collapse(2)'
Turns out this is due to truncating of the line...
EXPECTED: There is some diagnostic for free-fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94690
--- Comment #3 from Tobias Burnus ---
(In reply to Tobias Burnus from comment #2)
> EXPECTED: There is some diagnostic for free-form Fortran and for
> -Wline-truncation also for fixed-form Fortran source form.
That's fixed by the following patch
Keywords: diagnostic, openacc, openmp
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
Created attachment 48333
--> https://gcc.gnu.org/bugzi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94690
--- Comment #4 from Tobias Burnus ---
(In reply to Tobias Burnus from comment #3)
> (In reply to Tobias Burnus from comment #2)
> > EXPECTED: There is some diagnostic for free-form Fortran and for
> > -Wline-truncation also for fixed-form Fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94709
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94690
--- Comment #5 from Tobias Burnus ---
(In reply to Tobias Burnus from comment #0)
> * pr66199-9.f90 – gives an ICE in omp_add_variable
> (if 'lastprivate' is permitted, otherwise, it is rejected.)
Reduced test case (needs patch to permit lastp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94690
--- Comment #6 from Tobias Burnus ---
(In reply to Tobias Burnus from comment #5)
> The problem is (original dump):
> #pragma omp distribute private(d) lastprivate(d)
If one does not add the 'private(d)', it works: 'private(d)' is added by the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94690
--- Comment #7 from Tobias Burnus ---
If no lastprivate is available, it is added in gimplify.c's gimplify_omp_for,
line 11759:
for (i = 0; i < TREE_VEC_LENGTH (OMP_FOR_INIT (for_stmt)); i++)
...
if (is_doacross)
...
else if (ort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94282
--- Comment #5 from Tobias Burnus ---
Cf. also https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544368.html
["config/gcn/unwind-gcn.c (__gxx_personality_v0): New."]
||2020-04-23
Assignee|unassigned at gcc dot gnu.org |burnus at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #8 from Tobias Burnus ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544387.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94813
Tobias Burnus changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
Tobias Burnus changed:
What|Removed |Added
CC||tschwinge at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90591
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: marxin at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94848
--- Comment #1 from Tobias Burnus ---
Similar:
* PR71536 – *ICE* with *unused* static variable in declare-target function
Richard wrote in
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544905.html
> IIRC there was a bugreport similar to t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94848
--- Comment #2 from Tobias Burnus ---
Also possibly related (static local device variable) are the fixed PRs,
which might give a hint how to solve it (although, those look more like a band
aid):
* PR85063 – local variable for switch statement; s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93581
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94282
--- Comment #8 from Tobias Burnus ---
This was committed to GCC mainline while it was GCC 10 – hence, GCC 10 and 11
have the fix.
Can this PR now be closed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90591
--- Comment #5 from Tobias Burnus ---
Somewhat related: In terms of OpenMP (to be refined in the spec), the following
applies (in order to work both with shared + nonshared memory):
int x = 5;
#pragma omp target map(from:x)
x = 7;
prin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94358
--- Comment #3 from Tobias Burnus ---
(In reply to Thomas Schwinge from comment #2)
> Tobias, as a first step, can you please provide an exemplary Fortran test
> case that shows some cases of what code the Fortran front end generates to
> calcula
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94358
--- Comment #4 from Tobias Burnus ---
(In reply to Tobias Burnus from comment #3)
> And with optional there are additional issues – especially for
> assumed-shape arrays as one has to check 'y == NULL' (argument absent) and
> 'y->data == NULL' (u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90859
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
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).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94874
--- Comment #3 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
UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
[Cf. PR94874 and PR 90859; the extra 'array' is exposed to OpenMP and makes a
differenc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95002
--- Comment #1 from Tobias Burnus ---
Created attachment 48481
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48481&action=edit
PATCH – works but is modifies quite a lot: digest_init, convert_for_assignment,
convert
Working patch – but I w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90859
Tobias Burnus changed:
What|Removed |Added
Depends on||95002
--- Comment #6 from Tobias Burnus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95002
--- Comment #2 from Tobias Burnus ---
The "array," is added by c_expr_sizeof_expr:
if (c_vla_type_p (TREE_TYPE (folded_expr)))
{
/* sizeof is evaluated when given a vla (C99 6.5.3.4p2). */
ret.value = build2 (C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95002
--- Comment #3 from Tobias Burnus ---
As discussed with Joseph on IRC:
* The 'array, 4*len' is one on purpose per C spec
(sizeof for an expression with VLA type is defined to evaluate its argument.)
* g++ might not do this, if so, it is a bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95002
--- Comment #4 from Tobias Burnus ---
(In reply to Tobias Burnus from comment #3)
> * Convert should do the folding and leave the fold to gimple folding
Which means that one has to do this kind of folding before handling the
share/map handling f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94672
Tobias Burnus changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94874
Tobias Burnus changed:
What|Removed |Added
See Also||https://github.com/OpenMP/s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94690
--- Comment #10 from Tobias Burnus ---
Created attachment 48522
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48522&action=edit
Patch to add OpenMP 5 feature (private + lastprivate permitted for 'simd')
The patch solves an independent iss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95109
--- Comment #1 from Tobias Burnus ---
Confirmed – see PR 94690 comment 10.
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Found when looking at the build results for
meson (Python-b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95146
--- Comment #1 from Tobias Burnus ---
This seems to be a side effect of using
-traditional
in gfortran see PR 28662 for moving to no traditional.
Also gcc -E -traditional shows this behavior of just echoing the strings.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95146
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67300
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95150
--- Comment #1 from Tobias Burnus ---
* You compilation uses "-O0" – I do not know whether that's intended.
* I did not see any timeout message although it did take a while to run
with offloading. (See timing results below.)
I wonder what ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94690
--- Comment #13 from Tobias Burnus ---
(In reply to Andreas Schwab from comment #12)
> This breaks gfortran.dg/gomp/target1.f90 on riscv.
See comment 10 – or PR95109, which points to comment 10.
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
calloc returns zeroed memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93826
--- Comment #2 from Tobias Burnus ---
(In reply to Tobias Burnus from comment #0)
> do j = 1, 8
> do k = 1, 8
> end do
> x = 5 ! <<< not translated but also not an error message
> end do
Complications: BLOCK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93826
--- Comment #3 from Tobias Burnus ---
OpenMP 5 has:
"If the *ordered* clause is present, all loops associated with the construct
must be perfectly nested; that is there must be no intervening code between any
two loops." (2.9.2 Worksharing-Loop C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93826
Tobias Burnus changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729
--- Comment #4 from Tobias Burnus ---
See also https://gcc.gnu.org/pipermail/gcc/2020-April/thread.html#402 (for
details/current status, ask those involved).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95163
--- Comment #4 from Tobias Burnus ---
Likewise crashing is:
!$omp target map(tofrom: i) map(i)
1 - 100 of 5819 matches
Mail list logo
