oduct: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: ams at gcc dot gnu.or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120753
--- Comment #7 from Tobias Burnus ---
BTW: Workaround:
double *tmp = u.t;
#pragma omp target is_device_ptr(tmp)
tmp[i] = 20;
Additionally, a simple 'map(u)' will not map pointer members, keeping the
address the same such that effective
||burnus at gcc dot gnu.org
Status|UNCONFIRMED |RESOLVED
--- Comment #6 from Tobias Burnus ---
(In reply to Benjamin Schulz from comment #3)
> oh that last comment should have been made in another bug about an internal
> compiler error. Sorry.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120237
--- Comment #2 from Tobias Burnus ---
Iain pointed out (on IRC) that ISL > 0.24 will cause an in-tree build fail with
GCC-10.5 due to its use of C++17 (and seemingly not properly adding -std=c++17,
cf. PR 115077).
[BTW: GCC requires C++14; GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121043
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113436
--- Comment #3 from Tobias Burnus ---
Patch by Kwok: https://gcc.gnu.org/pipermail/gcc-patches/2025-June/687685.html
Follow up for allocatables,see PR119905.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119905
--- Comment #2 from Tobias Burnus ---
Needs to be also handled with ALLOCATE clause, cf. PR113436, see also PR95506
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119905
--- Comment #1 from Tobias Burnus ---
Also to be checked: ABSENT OPTIONAL arguments with PRIVATE, FIRSTPRIVATE
MAP and target update's TO/FROM clauses.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120737
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120722
--- Comment #1 from Tobias Burnus ---
Fails for:
Breakpoint 1, gen_highpart (mode=E_SImode, x=0x77195378) at
/home/tob/repos/gcc/gcc/emit-rtl.cc:1674
1674 gcc_assert (result && !MEM_P (result));
(gdb) p result
$1 = (rtx) 0x0
(gdb) p
Version: 16.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, openacc
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: tschwing
Version: 16.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: ams at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120682
--- Comment #8 from Tobias Burnus ---
> If you are asking for a new OpenMP feature, this is not the right forum,
> GCC bugzilla is for reporting bugs.
While I want to echo what Jakub wrote, I have nonetheless filed the OpenMP
specification issu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120680
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
s: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: tschwinge at gcc dot gnu.org
Target Milestone: ---
Target: nvptx
I get l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93226
--- Comment #6 from Tobias Burnus ---
(In reply to Thomas Schwinge from comment #5)
> On OG15, for both nvptx and GCN offloading, I see:
...
The code has in the module:
integer :: D(N)
!$acc declare device_resident(D)
The problem is that o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120530
Tobias Burnus changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119677
--- Comment #1 from Tobias Burnus ---
Additionally, there is a check for a conforming device number for
metadirectives:
omp_device_num_check (tree *device_num, bool *is_host)
{
...
/* Otherwise, test that -1 <= *device_num <= omp_get_num_devi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120530
--- Comment #2 from Tobias Burnus ---
> That system has unified shared memory
Indeed, if I compare the host and the device addresses, I see
different values (= mapped) for sptr1, sptr1->ptrset, sptr1->ptrset2 (→ OK)
BUT: sptr1->ptrset[i] and s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120530
--- Comment #1 from Tobias Burnus ---
> FAILs its execution test for nvptx offloading
That's not generally true:
Running gcc/libgomp/testsuite/libgomp.c/c.exp ...
PASS: libgomp.c/target-map-zero-sized-3.c (test for excess errors)
PASS: libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120444
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
oduct: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: openmp, wrong-code
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
Created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120180
--- Comment #7 from Tobias Burnus ---
The ICE is now fixed (GCC mainline/16 + GCC 15). [Thanks!]
Open are the issues (or "issues") → comment 3
* non-executable directives (like 'omp nothing' or 'omp error at(compile)') as
intervening code [Ope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93226
Tobias Burnus changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93226
Tobias Burnus changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
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: ---
omp_target_memset and omp_target_memset_async should be implemented.
This requires on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120413
--- Comment #5 from Tobias Burnus ---
ICE FIXED so far for mainline (GCC 16) and GCC 15.
* * *
Reading:
> There is also BIND_EXPR_VARS, dunno if that should be walked instead
> or in addition.
The current code is about adding map clauses for
: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: ams at gcc dot gnu.org
Target Milestone: ---
C23 (and Fortran 2023) added sinpi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118694
--- Comment #9 from Tobias Burnus ---
STATUS:
* 'target teams' handles the target part differently, depending whether
a 'teams' follows or not. Thus, the host (launching the offload kernel)
has to know whether a 'teams' follows or not.
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93226
--- Comment #1 from Tobias Burnus ---
Created attachment 61519
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61519&action=edit
Draft patch for 'acc_memcpy_device' - (only) missing are testcases (and
possibly a bit cleanup/testing)
This is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120413
--- Comment #2 from Tobias Burnus ---
Cf. https://gcc.gnu.org/pipermail/gcc-patches/2025-May/684581.html for
draft patch + discussion about whether BIND_EXPR_VARS needs to be handled as
well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120413
Tobias Burnus changed:
What|Removed |Added
Summary|C++ OpenMP 'target' SIGSEGV |[12/13/14/15/16 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120413
--- Comment #1 from Tobias Burnus ---
Technically, this is a [12/13/14/15/16 Regressions], unsurprising as the code
has been added in GCC 12.
* * *
The resulting code for the target regions like:
struct array arr;
<;
try
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118694
--- Comment #6 from Tobias Burnus ---
> Are we required to diagnose this as an error
> or is it allowable to permit this as an extension?
Answer "no" and "yes" - but the problem is that in general it does not work.
(Potential wrong code issues,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120167
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120225
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113413
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108577
Bug 108577 depends on bug 113413, which changed state.
Bug 113413 Summary: ATAND(Y,X) is unsupported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113413
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
--- Comment #20 from Tobias Burnus ---
And for the condition, I think the proper way is to write:
#if MPFR_VERSION >= MPFR_VERSION_NUM(4,2,0)
... = mpfr_sinpi ( ... )
#else
fallback
#endif
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
contrib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120179
--- Comment #9 from Tobias Burnus ---
(In reply to Thomas Schwinge from comment #8)
> > * gfortran.dg/do_concurrent_basic.f90: Extend testcase.
>
> I noticed this removed execution and torture testing; maybe unintentionally?
I thin
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
New in mpfr 4.2.0: "New functions mpfr_cosu, mpfr_sinu, mpfr_tanu, mpfr_acosu,
mpfr_asinu, mpfr_atanu and mpfr_a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120194
--- Comment #4 from Tobias Burnus ---
Hmm, actually, it looks as if I have already implemented (B.2) in GCC 15+ in
libgomp/target.c's gomp_load_image_to_device:
if (is_link_var
&& (omp_requires_mask
& (GOMP_REQUIRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120194
--- Comment #3 from Tobias Burnus ---
> ... this is ill-formed OpenMP?
For 'requires unified_shared_memory', you are in the realm of un(der)specified
behavior as OpenMP does not even mention how this case is handled.
If you do (A) - or (B.1) +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120180
Tobias Burnus changed:
What|Removed |Added
Keywords||rejects-valid
--- Comment #3 from Tobia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120194
--- Comment #1 from Tobias Burnus ---
Without having looked at it in depth, I think part of the problem is that
'varX' and 'varY' are in static memory. Thus, by construction, there is a
device and a host version.
Solution:
(a) Ensure the date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118694
--- Comment #3 from Tobias Burnus ---
On mainline currently failing (for a GCC configured with nvptx offloading):
libgomp.c-c++-common/metadirective-1.c:10:11:
error: 'target' construct with nested 'teams' construct contains directives
outsid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120180
--- Comment #1 from Tobias Burnus ---
Created attachment 61369
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61369&action=edit
C/C++ test case, compile with '-fopenmp'
It is a bit UNCLEAR to me whether the attached TESTCASE is VALID OR N
at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: sandra at gcc dot gnu.org
Target Milestone: ---
c
Version: 16.0
Status: UNCONFIRMED
Keywords: openacc, wrong-code
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: ams at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118859
--- Comment #3 from Tobias Burnus ---
This is (mostly) fixed by the two patches:
* https://gcc.gnu.org/pipermail/gcc-patches/2025-April/681806.html
* https://gcc.gnu.org/pipermail/gcc-patches/2025-April/682347.html
TODO - besides those two pat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120047
Tobias Burnus changed:
What|Removed |Added
Depends on||118859
Summary|[OpenMP] adju
ormal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
Status: UNCONFIRMED
Keywords: 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
Target Milestone: ---
Created
: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: openmp, wrong-code
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119892
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119736
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119692
--- Comment #4 from Tobias Burnus ---
Some generic remarks - regarding OpenMP to:
> When still 'map'ping C++ 'typeinfo', 'vtable' at the OpenACC compute,
> OpenMP 'target' construct
Obviously, the type info etc. is required for all work on th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119302
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119662
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
: 15.0
Status: UNCONFIRMED
Keywords: openmp
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
Keywords: documentation, openmp
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, sandra at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119662
--- Comment #2 from Tobias Burnus ---
For 'adjust_args':
void f0(int *);
#pragma omp declare variant(f0) match(construct={dispatch}) \
adjust_args(need_device_ptr: x)
void f(int *x);
void g(int *a, int dev) {
#pragma omp dispat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119662
Tobias Burnus changed:
What|Removed |Added
Summary|[OpenMP] Unhelpful debug|[OpenMP] Wrong-code for
-debug
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: ---
Assume:
66is_targetsync = 0;
67
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119559
Tobias Burnus changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
||2025-03-31
Assignee|unassigned at gcc dot gnu.org |burnus at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Tobias Burnus ---
Created attachment 60938
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60938&acti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113905
--- Comment #6 from Tobias Burnus ---
See also bug #118690 for some Fortran issues related to declare variant
diagnostic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118690
--- Comment #1 from Tobias Burnus ---
The following (cf. Bug #113905) is related, invalid but probably not detected:
!$omp declare target (f1 : f0) match(context={parallel})
!$omp declare target (f2 : f0) match(context={target})
This violates:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119541
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119541
--- Comment #2 from Tobias Burnus ---
The following seems to be the cleanest & simplest, namely to add it to the
if (nappend < ninterop)
error handling:
--- a/gcc/gimplify.cc
+++ b/gcc/gimplify.cc
@@ -3949,6 +3949,7 @@ modify_call_for_om
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119541
Tobias Burnus changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119541
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118627
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119325
--- Comment #23 from Tobias Burnus ---
The patch has now landed:
https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=2ef1a37e7823b21eda524972c006e0e8c26f97b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119371
--- Comment #2 from Tobias Burnus ---
BTW: It seems as if none of the testcases in libgomp actually
calls expand_GOMP_SIMT_XCHG_IDX!
* * *
The expansion happens in internal-fn.cc's
static void
expand_GOMP_SIMT_XCHG_IDX (internal_fn, gcall *st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119325
--- Comment #21 from Tobias Burnus ---
Andrew's patch to Newlib's newlib/libm/machine/amdgcn/amdgcn_veclib.h:
* [PATCH] Fix GCN SIMD libm bug
https://sourceware.org/pipermail/newlib/2025/021582.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119371
--- Comment #1 from Tobias Burnus ---
Bisecting points at the following commit - but that seems to rather reveal the
issue and not causing it: r15-3135-gcb51e0b236c7d4
lto: Don't check obj.found for offload section
obj.found is the num
Keywords: ice-on-valid-code, openmp
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: tschwinge at gcc dot gnu.org, vries at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119370
--- Comment #3 from Tobias Burnus ---
> Reduced testcase:
> ...
> S a[3];
Array size 1 is enough. My reduced testcase was:
#pragma omp declare target
struct SSD {
SSD();
} sd[1];
#pragma omp end declare target
input1.ii.018t.ompex
tatus: UNCONFIRMED
Keywords: ice-on-valid-code, openmp
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
This is a GCC 15 regression, at least G
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119367
--- Comment #1 from Tobias Burnus ---
The diff for a.xamdgcn-amdhsa.mkoffload.270r.expand shows identical output.
When glancing at the diff for a.xamdgcn-amdhsa.mkoffload.1.s, I noticed a large
increase in the 'local vars size':
- ; loca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119367
--- Comment #4 from Tobias Burnus ---
Quoted too few lines:
13001 dw2_asm_output_delta (2, line_label, prev_label,
13002 "from %s to %s", prev_label,
line_label);
which calls
dw2_asm_output_delta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119367
--- Comment #3 from Tobias Burnus ---
(In reply to Andrew Pinski from comment #2)
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/dwarf2out.cc;
> h=a2acfd1d35654827492b69ec35b571accf2263a4;hb=HEAD#l12994
Namely, output_one_line_info_table:
1
8047-gadb14c7625178b
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: openmp, wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119325
--- Comment #19 from Tobias Burnus ---
(In reply to Richard Biener from comment #15)
> maybe
>
> #define RESIZE_VECTOR(to_t, from) \
> ({ \
>__auto_type __from = (from); \
>to_t __to;
>memcpy (&__to, &__from, MIN (sizeof (to_t), si
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119325
--- Comment #12 from Tobias Burnus ---
BTW, I added some diagnostic to the 'if' clause showing:
v64sf_fmod.c:147:109: warning: ‘__from’ (‘v2sf’ {aka ‘__vector(2) float’}):
size = 8, align = 64
v64sf_fmod.c:147:198: warning: ‘__from’ (‘v2sf’ {ak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119325
--- Comment #11 from Tobias Burnus ---
> Can you attach preprocessed source of the libm function?
BTW: The relevant newlib source files are (newlib/libm/machine/amdgcn/) the
following; looking at those is much more readable:
* amdgcn_veclib.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119325
--- Comment #9 from Tobias Burnus ---
Created attachment 60801
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60801&action=edit
libm_a-v64sf_fmod.i - as requested in comment 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119325
--- Comment #7 from Tobias Burnus ---
I was wondering whether setting GCN_STACK_SIZE= would help; default is 32*1024.
Answer: it does not seem to help, but I noticed that from time to time,
it succeeds. I have a couple in a semi-row, but then 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119325
--- Comment #6 from Tobias Burnus ---
Some more testing:
Copying gfx908/libm.a of the 'failing' build directory to the install directory
+ re-compiling will make the binary fail, copying from the 'working' build
directory, it will work.
Thus,
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
The following is rejected by gfortran with:
12 | !$omp task depend(out:var%a(1:10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119330
Tobias Burnus changed:
What|Removed |Added
Summary|[OpenMP] GCC wrongly|[OpenMP] GCC wrongly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119325
--- Comment #5 from Tobias Burnus ---
For both the reduced and the full example: If I write the pragma as:
#pragma omp target map(to:a,b) map(from:res)
#pragma omp for simd
(i.e. I remove the 'parallel' before 'for simd') the code starts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119325
Tobias Burnus changed:
What|Removed |Added
Summary|[15 Regression] |[15 Regression]
|libg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119325
--- Comment #2 from Tobias Burnus ---
(In reply to Richard Biener from comment #1)
> The bisection is quite odd
I am re-testing. Somehow mixed full rebuilds and incremental builds,
which affect whether newlib (libm) is rebuild or not.
I am now
Version: 15.0
Status: 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: ams at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115271
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115076
--- Comment #3 from Tobias Burnus ---
The testcase mentioned in PR 115271 comment 1, i.e., the existing (xfailed):
libgomp/testsuite/libgomp.fortran/declare-variant-2.f90
libgomp/testsuite/libgomp.fortran/declare-variant-2-aux.f90
is interes
1 - 100 of 3995 matches
Mail list logo
