https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116661
--- Comment #6 from Tobias Burnus ---
> FAIL: gfortran.dg/gomp/interop-1.f90
That's a known issue – there is a parsing issue that was (usually) hidden by
the not properly initialized variable.
Now it is exposed as consistent FAIL, which is muc
: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
Target: x86-64
Found at https://www.darpa.mil/attachments/MOCHA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116535
--- Comment #9 from Tobias Burnus ---
(In reply to Jan Hubicka from comment #7)
> We treat first partition somewhat specially in other code too, so I
> guess we could a test if the streamed partition is first one instad of
> relying on free to h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116535
--- Comment #4 from Tobias Burnus ---
(In reply to Richard Biener from comment #3)
> The forked processes may not write to any "global" data because forking
> makes that data not global ... instead any such "global" data has to be
> computed bef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116535
--- Comment #2 from Tobias Burnus ---
Namely, the following seems to be problematic if the code is run concurrently.
The FORK part is actually quite old r207515 (Feb 2014) as is the following code
with flag_wpa, which was added in r217489 (No
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116535
--- Comment #1 from Tobias Burnus ---
I have problems reproducing it fully reliably – and my impression is that a
global variable is not atomically set.
The difference between -flto=1 and -flto=2 with -flto-partition=max is rather
small. In eit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116269
--- Comment #1 from Tobias Burnus ---
Note regarding the compile-time optimization:
Currently, gcc/gimple-fold.cc's gimple_fold_builtin_acc_on_device only handles:
unsigned val_host = GOMP_DEVICE_HOST;
unsigned val_dev = GOMP_DEVICE_NONE;
, openacc
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
For C, both __builtin_acc_on_device and acc_on_device is defined,
permitting compile-time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115140
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
D
Keywords: missed-optimization, openacc
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: cltang at gcc dot gnu.org, tschwinge at gcc dot gnu.or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115637
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115637
--- Comment #2 from Tobias Burnus ---
Patch:
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658737.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115559
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115577
--- Comment #1 from Tobias Burnus ---
>From the other issue, now fixed:
(B) Issues found when writing a testcase:
* COMMON blocks: Using map(a,b,c) instead of map(/mycommon/) fails with:
error: undefined symbol: mycommon_
TESTCASE: atta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116107
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
NCONFIRMED
Keywords: openmp, wrong-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
See also PR 1155
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112779
--- Comment #1 from Tobias Burnus ---
See also PR 107067 for a Fortran ICE with metadirectives (OG12 branch).
See https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657841.html for
"[PATCH v3 00/12] Metadirective support + "declare variant"
sion: 15.0
Status: UNCONFIRMED
Keywords: openacc, openmp, 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 d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115574
--- Comment #2 from Tobias Burnus ---
> #pragma declare target link(a,b)
as Thomas pointed out (cf. comment 1), an 'omp' is missing.
It also lacks, e.g. '#pragma omp target enter data map(a, b)' to be valid.
Still, the real issue is '!is_globa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115637
--- Comment #1 from Tobias Burnus ---
Created attachment 58512
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58512&action=edit
WIP patch - shows the location but fails as DECL_P is not a is_gimple_stmt
The attached patch handles
MEM [
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115559
--- Comment #7 from Tobias Burnus ---
(In reply to Tobias Burnus from comment #6)
> FOLLOW-UP ISSUES:
> * VARIABLE not AVAILABLE on the device:
PR115637 - is an analysis of the 'arr2' issue.
tatus: UNCONFIRMED
Keywords: openmp, wrong-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Cr
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
The following doesn't make sense on multiple ways:
(A)
-
find_forall_index (gfc_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115559
--- Comment #6 from Tobias Burnus ---
Fortran patch:
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655386.html
FOLLOW-UP ISSUES:
* OFFSET issues with LINK clause:
arr = [(i, i=1,N)]
map(arr(10:N)
and then in a device func
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115559
--- Comment #5 from Tobias Burnus ---
Created attachment 58478
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58478&action=edit
COMMON block testcase
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
Using map(/common/) is rejected in gfortran but is valid:
10 |!$omp target enter data map(/mycommon
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
C variant for the issue PR 115559.
[Nested functions are a GNU extension - thus, we may decide not to fix this.]
Nonetheless, the following compiles but fails during device LTO:
foo.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115559
--- Comment #4 from Tobias Burnus ---
NOTE to self: This code now adds the attribute unconditionally. For COMMON and
MODULE it makes sense; but for programm/subroutine/function, it needs to be
rechecked whether that variable is actually used.
A
dot gnu.org |burnus at gcc dot
gnu.org
Last reconfirmed||2024-06-20
Status|UNCONFIRMED |ASSIGNED
--- Comment #3 from Tobias Burnus ---
Created attachment 58472
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58472&acti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115559
--- Comment #2 from Tobias Burnus ---
For C, it is actually handled in the FE for
tree at1 = lookup_attribute ("omp declare target", DECL_ATTRIBUTES (t));
tree at2 = lookup_attribute ("omp declare target link",
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115559
--- Comment #1 from Tobias Burnus ---
Looks as if offload_vars is empty in case of Fortran; the variables are tagged
as 'declare variant link' in the FE but varpool_node::get_create has:
if ((flag_openacc || flag_openmp)
&& lookup_attri
rds: openmp, rejects-valid, wrong-code
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: ---
A C version of t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115551
--- Comment #6 from Tobias Burnus ---
Crossref: New Bug 11 is for the range analysis to deduce from 'x << a' that
'a' must be nonnegative.
on
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: aldyh at gcc dot gnu.org
Target Milestone: ---
Stumbled over this when looking at PR 115551.
C has for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115551
--- Comment #3 from Tobias Burnus ---
As we want to have a >= 0, I tried to convey it differently for the example in
comment 0:
(a) __attribute__((assume(ch >= 0)));
(b) 'unsigned ch' (instead of 'int ch')
but it didn't help. Thus, it looks a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115551
--- Comment #2 from Tobias Burnus ---
> Thus we need some range info to do this optimization.
Good point.
It seems as if for c1 << (c2 * a + c3), C requires a >= -c3/c2 (read as float
division; c2 ≠ 0)
And the suggested optimization requires
ormal
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: ---
It looks as if a 'gfc_free_expr (list->expr)' is missing before
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: pinskia at gcc dot gnu.org
Target Mi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109452
--- Comment #3 from Tobias Burnus ---
The following is missing as well:
--- a/gcc/omp-general.cc
+++ b/gcc/omp-general.cc
@@ -3316,3 +3316,5 @@ omp_runtime_api_procname (const char *name)
"init_lock",
+ "init_lock_with_hint",
Keywords: diagnostic, openmp, rejects-valid
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
OpenMP permits in free-form Fortran:
"One or more b
|NEW
Last reconfirmed||2024-05-30
CC||burnus at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Tobias Burnus ---
Confirmed for
* omp_init_lock_with_hint
NCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
Created attachment 58309
--> https://gcc.gnu.org/bugzilla/atta
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: parras at gcc dot gnu.org, sandra at gcc dot gnu.org
Target Milestone: ---
Assume:
module m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115150
Tobias Burnus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115203
--- Comment #2 from Tobias Burnus ---
Indeed, the suggestion was not to disable the translations in general. A
similar issue shows up when running the testsuite. There is it solved by
"setenv LANG C" and "setenv LANG C.ASCII" – while various scr
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
For some testing, I happened to build with LANG=de_DE.UTF-8
and that was also set when building GCC itself.
That works fine until the analyzer self test - as the strings don't match:
.../build-gcc-trunk-fast/./gcc/xgcc
-B/hom
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
IT looks as if the following is wrongly rejected:
procedure(acos) [,pointer] :: p
While the examples below are with 'po
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115150
Tobias Burnus changed:
What|Removed |Added
Target Milestone|--- |12.5
CC|
: wrong-code
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
GCC 11.4 has:
Shape: 0 0
Shape: 0 3 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44744
--- Comment #5 from Tobias Burnus ---
(In reply to Tobias Burnus from comment #4)
> Another variant from lsdalton – or rather the
BTW: I have not verified that the cause is the same (temporary variable), but
it seems to be likely.
When replacing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44744
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113905
--- Comment #1 from Tobias Burnus ---
Ups, testcase was lost. Re-written from scratch:
---
int var1() { return 1; }
int var2() { return 2; }
#pragma omp declare variant (var1) match(construct={target})
#pragma omp declare varian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104621
--- Comment #1 from Tobias Burnus ---
This got fixed for OpenMP 6 via OpenMP spec pull request #3383, adding:
* A declarative directive must be specified in the specification part after all
'USE', 'IMPORT' and 'IMPLICIT' statements.
* If a dec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114825
--- Comment #2 from Tobias Burnus ---
The difference between the failing program and a working program
(pointer-assignment in 'sub' comment out) is:
failing:
'type' in gfc_omp_clause_default_ctor is '
ic, openmp
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
Cf. https://github.com/SOLLVE/sollve_vv/pull/802
"LLVM error:
error: allocator must be s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103496
--- Comment #4 from Tobias Burnus ---
(In reply to anlauf from comment #3)
> The code in comment#0 compiles at r14-9893-gded646c91d2c0f
> and gives the indicated results.
which is the commit:
Fortran: fix argument checking of intrinsics C_SIZE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113006
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
--- Comment #30 from Tobias Burnus ---
(In reply to rguent...@suse.de from comment #29)
> Might be for \r\n line endings?
New lines are handled slightly differently – and \f and \v don't seem to be
handled at all.
Comparing the result with ifo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
--- Comment #28 from Tobias Burnus ---
Created attachment 57896
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57896&action=edit
Testcase
It seems as if 'tabs' cause problems, e.g. for:
profile_single_file= .true.
where the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114596
--- Comment #6 from Tobias Burnus ---
(In reply to sandra from comment #5)
> Tobias, it looks to me like you missed the connection ...
No, I didn't - I did link it (cf. top of comment 3) — but I just cannot read
:-/
Hence, for
(1) *teams* *pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114596
--- Comment #4 from Tobias Burnus ---
> For selector construct = {teams, parallel, for}
> score1 = 29 score2 = 29
> ---
>
> The constructs[i]'s score look fine.
>
> But I wonder why score == 29 and not 28.
Answer: omp_context_co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114596
--- Comment #3 from Tobias Burnus ---
The scoring is according to TR12:
> Each trait selector for which the corresponding trait appears
> in the construct trait set in the OpenMP context is given the
> value 2^(p−1) where p is the position of t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114596
--- Comment #2 from Tobias Burnus ---
Crossref to the OpenMP spec discussions [not publicly available]
related to the scoring:
* Jakub asked about this testcase in an omp-lang in the email 2019/016447.html
(w/o getting a reply.
* He then opened
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111966
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
, 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: ---
It looks as if when starting two kernels
,
||burnus at gcc dot gnu.org
Summary|amdgcn offload compiler |[GCC < 14] amdgcn offload
|fails to build with amdgcn |compiler fails to build
|tools based on LLVM 18 |with amdgcn tools based
,
||openacc
CC||burnus at gcc dot gnu.org
--- Comment #1 from Tobias Burnus ---
It likewise applies for OpenMP for code such as:
omp target firstprivate(array) allocate(omp_const_mem_alloc : array)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
--- Comment #19 from Tobias Burnus ---
Regarding the LAPACK issue:
Actually, I am inclined to
* regard it as LAPACK bug
* that was also fixed upstream, see comment 6, to make g95 happy.
as ';' is not a value separator - while ' ;' is fine, wher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473
Tobias Burnus changed:
What|Removed |Added
Attachment #57693|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473
--- Comment #34 from Tobias Burnus ---
Created attachment 57693
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57693&action=edit
Extended testcase; comment shows results for gfortran(trunk),ifort,ifx,flang
See PR114304 for some related is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
--- Comment #14 from Tobias Burnus ---
Created attachment 57680
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57680&action=edit
Testcase with decimal=COMMA, passes with ifort/ifx/flang - fails with gfortran
> commit r14-9432-g0c179654c31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
--- Comment #6 from Tobias Burnus ---
[For completeness: The LAPACK testsuite change Richard mentioned in comment 2
is
https://github.com/Reference-LAPACK/lapack/commit/64e8a7500d817869e5fcde35afd39af8bc7a8086
- That's for g95 and was applied 20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
Tobias Burnus changed:
What|Removed |Added
Keywords||wrong-code
Summary|[14 Regre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
--- Comment #4 from Tobias Burnus ---
Created attachment 57668
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57668&action=edit
Testcase
Testresults of the attached testcase:
See also https://godbolt.org/z/q4rG61EvW
The attached testc
|---
CC||burnus at gcc dot gnu.org,
||jvdelisle at gcc dot gnu.org
--- Comment #3 from Tobias Burnus ---
I think the semicolon is not permitted as item separator but if I have as input
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
See also OpenMP specification Issue #3823 [and sligh
NCONFIRMED
Keywords: missed-optimization, openmp
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
For C/C++ function pointers and Fortran dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110347
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113436
--- Comment #2 from Tobias Burnus ---
As mentioned in comment 0, PR110347's testcase (r14-9257-g4f82d5a95a244d)
contains '#if 0' code which has to be enabled once this bug is fixed.
Please remember to take care of:
* libgomp/testsuite/libgomp.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113867
--- Comment #5 from Tobias Burnus ---
For:
int *q;
#pragma omp target device(y5) map(q, q[:5])
GCC currently generates:
map(tofrom:q [len: 8]) map(tofrom:*q.4_1 [len: 20]) map(attach:q [bias: 0])
Expected:
'alloc:' instead of 'attach:
Keywords: openacc
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
Created attachment 57466
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57466&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113997
--- Comment #3 from Tobias Burnus ---
> Anyway, renaming the binding label, like
>subroutine acc_attach_c(x) bind(C, name="acc_attach_renamed")
> makes the code compile.
Well, the code *does* compile as it is only a warning.
* * *
I think
Keywords: diagnostic
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
The following warning is bogus, unless
-fno-leading-underscore
is us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113331
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113904
--- Comment #3 from Tobias Burnus ---
See comment 1 for remaining to-do items.
I also note that the Fortran resolution comes too early - during parsing - as
the following shows:
module m
implicit none
contains
subroutine test
!$omp declare v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113904
--- Comment #1 from Tobias Burnus ---
Patch for rejecting non-const arguments in Fortran (wrong-code bit) to bring it
in line with C/C++:
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645488.html
* * *
TODO as follow up:
* Permit n
ds: openmp, rejects-valid
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: sandra at gcc dot gnu.org
Target Milestone: ---
GCC only accepts the those const
-valid
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, parras at gcc dot gnu.org,
sandra at gcc dot gnu.org
Target
NCONFIRMED
Keywords: accepts-invalid, openmp, rejects-valid, wrong-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: parras at gcc dot gnu.org, sandra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113867
--- Comment #4 from Tobias Burnus ---
Also not handled:
struct s { int *p; } s1;
...
#pragma omp target map(s1.p[:N])
p[0] = p[N-1] = 99;
Here, the pointer attachment is missing. See also PR113724 's attachment 57407
for a testcase f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113724
--- Comment #6 from Tobias Burnus ---
Created attachment 57407
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57407&action=edit
C testcase – passes with patch (except for '#if 0'ed PR113867 issues)
DejaGNU-ified testcase for this PR and (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113867
--- Comment #3 from Tobias Burnus ---
Created attachment 57398
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57398&action=edit
Patch - handling the libgomp issue
Possible patch - lightly tested. This fixes the issue in libgomp.
While al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113867
Tobias Burnus changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |burnus at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113724
--- Comment #5 from Tobias Burnus ---
The runtime issue is now PR113867.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113867
--- Comment #1 from Tobias Burnus ---
Created attachment 57382
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57382&action=edit
Fortran testcase, kind of, as pointer + pointee mapping cannot be split
(working)
For completeness, a Fortran
, wrong-code
Severity: normal
Priority: P3
Component: middle-end
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 57381
--> ht
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113724
--- Comment #4 from Tobias Burnus ---
Created attachment 57377
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57377&action=edit
Fixes the ICE – might paper over a real issue; doesn't fix the run-time issue →
TODO + 'data'-issue in PR comme
IRMED
Keywords: openacc, rejects-valid
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: tschwinge at gcc dot gnu.org
Target Milestone: ---
OpenACC see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113724
--- Comment #3 from Tobias Burnus ---
Inside omp_build_struct_sibling_lists, the following assignment:
11654 grp->grp_start = new_next;
has on the LHS the [3] array with value:
(gdb) p *grp
$147 = {grp_start = 0x771f9688, grp_en
1 - 100 of 3799 matches
Mail list logo
