Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
On openSUSE Leap 15.2, I see:
...
FAIL: libgomp.fortran/async_io_1.f90 -O0 execution test
FAIL: libgomp.fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100321
--- Comment #4 from Tom de Vries ---
During lower_rec_input_clauses in omp-low.c, the reduction clause is handled:
...
case OMP_CLAUSE_REDUCTION:
case OMP_CLAUSE_IN_REDUCTION:
/* OpenACC reductions are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100321
--- Comment #3 from Tom de Vries ---
C example:
...
/* { dg-additional-options "-foffload=-latomic" } */
#include
struct s
{
int i;
};
#pragma omp declare reduction(+: struct s: omp_out.i += omp_in.i)
int
main (void)
{
const int N0 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81778
Tom de Vries changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100232
Tom de Vries changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100321
Tom de Vries changed:
What|Removed |Added
Summary|[OpenMP][nvptx] (Con't) |[OpenMP][nvptx, SIMT]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100321
Tom de Vries changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98391
--- Comment #3 from Tom de Vries ---
Jakub, should this be marked as resolved-invalid?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98391
--- Comment #2 from Tom de Vries ---
Fixed by:
...
do i = 1, n
+!$omp atomic
c(i,j) = a(k) + c(i,j)
end do
...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98391
--- Comment #1 from Tom de Vries ---
Minimal example openmp:
...
program main
implicit none
integer :: i, j, k
integer :: n = 2
real :: a(2), c(2,2), cc(2,2)
a = 0.5
cc = 0
do j = 1, n
do k = 1, n
do i = 1, n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100232
--- Comment #5 from Tom de Vries ---
https://gcc.gnu.org/pipermail/gcc-patches/2021-April/569038.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100232
--- Comment #4 from Tom de Vries ---
This commit:
...
commit 3af3bec2e4d344bd54a134d8b2263f44d788c3d8
Author: Richard Sandiford
Date: Mon May 4 21:21:16 2020 +0100
internal-fn: Avoid dropping the lhs of some calls [PR94941]
...
adds:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100232
Tom de Vries changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100293
Tom de Vries changed:
What|Removed |Added
CC||vries at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99932
--- Comment #6 from Tom de Vries ---
(In reply to Tom de Vries from comment #5)
> FIled https://developer.nvidia.com/nvidia_bug/3299227
Nvidia reported it will be fixed in the next major cuda release. I've asked
about driver fixes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99932
--- Comment #5 from Tom de Vries ---
FIled https://developer.nvidia.com/nvidia_bug/3299227
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99932
--- Comment #4 from Tom de Vries ---
Created attachment 50662
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50662=edit
Updated cuda reproducer
Slimmed down further, eliminated gang/worker reduction parts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100232
--- Comment #1 from Tom de Vries ---
Can you try the patch for PR81778 ?
It's possible you're looking at a duplicate.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99932
--- Comment #3 from Tom de Vries ---
Created attachment 50660
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50660=edit
Cuda reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99932
--- Comment #2 from Tom de Vries ---
Minimal example:
...
$ cat libgomp/testsuite/libgomp.oacc-c-c++-common/parallel-dims.c
int
main (void)
{
int vectors_max = -1;
#pragma acc parallel \
num_gangs (1) \
num_workers (1) \
vector_length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99932
--- Comment #1 from Tom de Vries ---
(In reply to Thomas Schwinge from comment #0)
> We're seeing OpenACC/nvptx offloading execution regressions (including a lot
> of timeouts) starting with CUDA 11.2-era Nvidia Driver 460.27.04. Confirmed
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100160
--- Comment #2 from Tom de Vries ---
(In reply to Tom de Vries from comment #1)
> ...
> $ ./install/bin/g++ test-1.cpp -fopenmp -foffload=nvptx-none
> lto-wrapper: fatal error: could not find accel/nvptx-none/mkoffload in
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99564
Tom de Vries changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100160
Tom de Vries changed:
What|Removed |Added
CC||vries at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99555
--- Comment #10 from Tom de Vries ---
Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568295.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99555
--- Comment #9 from Tom de Vries ---
(In reply to Tom de Vries from comment #8)
> This fixes the hang:
This is a less intrusive solution, and is easier to transplant into
gomp_team_barrier_wait_cancel_end:
...
diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99555
--- Comment #8 from Tom de Vries ---
This fixes the hang:
...
@@ -91,14 +129,16 @@ gomp_team_barrier_wait_end (gomp_barrier_t *bar,
gomp_barrier_state_t state)
{
gomp_barrier_handle_tasks (state);
state &=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99555
--- Comment #7 from Tom de Vries ---
Created attachment 50627
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50627=edit
debug patch
A bit more analysis.
I'm working with this example, with an actual task to be able to perform a
check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99555
Tom de Vries changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99555
--- Comment #4 from Tom de Vries ---
Investigated using cuda-gdb.
After typing ^c, we investigate the state:
...
(cuda-gdb) info cuda kernels
Kernel Parent Dev Grid Status SMs Mask GridDim BlockDim Invocation
* 0 - 01
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99896
Tom de Vries changed:
What|Removed |Added
CC||matz at suse dot de
--- Comment #6 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99896
--- Comment #2 from Tom de Vries ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Tom de Vries from comment #0)
> > With g++, we have instead:
> > ...
> > collect2 ... main.o foo.o -lpcre2-posix ...
> > ...
>
> It isn't dropped,
: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
[ Spinoff from gdb PR https://sourceware.org/bugzilla/show_bug.cgi?id=27681 . ]
Consider the following test-case, consisting of:
...
$ cat main.c
#include
#include
#ifndef _GNU_SOURCE
#define
for excess errors)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99555
--- Comment #1 from Tom de Vries ---
I see this as well:
...
PASS: libgomp.c/../libgomp.c-c++-common/task-detach-6.c (test for excess
errors)
WARNING: program timed out.
...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95432
--- Comment #3 from Tom de Vries ---
(In reply to Andrew Pinski from comment #2)
> Assembly:
> .loc 1 12 3 is_stmt 1 view .LVU12
> .loc 1 10 8 is_stmt 0 view .LVU13
> movaps %xmm0, (%rsp)
> .loc 1 11 8 view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99319
--- Comment #2 from Tom de Vries ---
(In reply to Tom de Vries from comment #0)
> The second operand is now also a .uleb128. AFAIU, this goes against the
> spec.
Also, gdb doesn't get it:
...
$ gdb -q -batch -readnow a.out
DW_FORM_strp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99319
--- Comment #1 from Tom de Vries ---
Related readelf PR: https://sourceware.org/bugzilla/show_bug.cgi?id=27387
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider compiling hello world, with macro info:
...
$ gcc-11 -ggdb3 -g hello.c -dA -save-temps
...
In a-hello.s, we have:
...
.section.debug_macro
Priority: P3
Component: libbacktrace
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
CC: ian at gcc dot gnu.org
Target Milestone: ---
I have several gcc versions installed. I use this f.i. for running gdb
testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98780
--- Comment #1 from Tom de Vries ---
At final, we have:
...
(note 113 30 112 2 0x7f53d1836de0 NOTE_INSN_BLOCK_BEG)
(note 112 113 31 2 0x7f53d1836e40 NOTE_INSN_BLOCK_BEG)
(call_insn 31 112 114 2 (call (mem:QI (symbol_ref:DI ("bar") [flags 0x41]
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Created attachment 50018
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50018=edit
source file
[ Spinoff of gdb PR25884 - "Stepping over inlined function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98656
--- Comment #1 from Tom de Vries ---
Created attachment 49959
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49959=edit
Tentative patch
Using this tentative patch, I get back the .loc for line number 5:
...
foo:
.LFB0:
.file 1
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
[ Originally filed as gdb PR at
https://sourceware.org/bugzilla/show_bug.cgi?id=27179 ]
Consider test-case small.c.
...
$ cat -n small.c
1 #include
2
3 void foo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98321
--- Comment #5 from Tom de Vries ---
(In reply to Thomas Schwinge from comment #4)
> I had been looking into how/when PTX 'atom' is used for reductions, and
> first had a look what the back end currently might emit at all, found SDIM
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98321
--- Comment #3 from Tom de Vries ---
(In reply to Thomas Schwinge from comment #2)
> However, my report was specifically for the nvptx target compiler. Just
> compile with 'nvptx-gcc -fopenacc -S' the code I posed, and compare
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98321
--- Comment #1 from Tom de Vries ---
Ok, let's first make a runnable test-case:
...
$ cat src/libgomp/testsuite/libgomp.oacc-c/test.c
#include
#define TYPE float
TYPE a = 1;
TYPE b = 2;
int
main (void)
{
printf ("A: %f\n", a);
#pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97713
--- Comment #5 from Tom de Vries ---
(In reply to Tom de Vries from comment #4)
> (In reply to Tom de Vries from comment #0)
> > Now, should objcopy implement the relocation?
>
> Nick proposed a patch that errors out on current gcc output.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97774
Tom de Vries changed:
What|Removed |Added
Target Milestone|--- |10.0
Status|UNCONFIRMED
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
[ This PR is FTR, it's already fixed. ]
Consider this test-case, minimized from gdb.cp/gdb9593.cc (
https://src.fedoraproject.org/rpms/gdb/blob/master/f/gdb-archer-vla-tests.patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97713
Tom de Vries changed:
What|Removed |Added
CC||ccoutant at gmail dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97713
--- Comment #3 from Tom de Vries ---
Mentioning dwarf 5 standard bit @ "7.3.2.2 Second Partition (Unlinked or in a
.dwo File)":
...
Split DWARF object files do not get linked with any other files, therefore
references between sections must not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97713
--- Comment #2 from Tom de Vries ---
Filed corresponding binutils PR: "objcopy --extract-dwo silently drops
relocation" at https://sourceware.org/bugzilla/show_bug.cgi?id=26841 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97713
--- Comment #1 from Tom de Vries ---
(In reply to Tom de Vries from comment #0)
> and copy to hello.s and modify:
> ...
> $ diff -u a-hello.s hello.s
> --- a-hello.s 2020-11-04 13:12:57.188966796 +0100
> +++ hello.s 2020-11-04
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
I.
Consider a simple hello.c, compiled with debug info
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
In the dwarf v5 standard we read:
...
.debug_line.dwo - Contains specialized line number tables for the type
units
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97532
--- Comment #12 from Tom de Vries ---
(In reply to Hongtao.liu from comment #10)
> Created attachment 49444 [details]
> Fix invalid address for special memory constraint
>
> I'm testing this patch.
Submitted:
: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
At commit c26d7df1031
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97509
Tom de Vries changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
With current trunk I'm seeing a number of new fails, all of them "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97436
Tom de Vries changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
There's currently a bunch of tests failing:
...
FAIL: gcc.dg/atomic/c11-atomic-exec-6.c -O0 execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-6.c -O1 execution test
FAIL: gcc.dg/atomic/c11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97333
--- Comment #3 from Tom de Vries ---
(In reply to Tom de Vries from comment #2)
> (In reply to Richard Biener from comment #1)
> > (because well, on GIMPLE we can duplicate all blocks).
>
> I'm not sure I understand why, given that tracer.c has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84958
Tom de Vries changed:
What|Removed |Added
CC||ams at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84958
--- Comment #4 from Tom de Vries ---
(In reply to Tom de Vries from comment #0)
> [ FWIW, adding an extra fre pass here also results in optimal gimple:
> ...
> diff --git a/gcc/passes.def b/gcc/passes.def
> index 3ebcfc30349..6b64f600c4a 100644
: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
The nvptx port has an -m32 switch:
...
m32
Target Report RejectNegative InverseMask(ABI64)
Generate code for a 32-bit ABI.
...
but the default is -m64:
...
#define TARGET_DEFAULT_TARGET_FLAGS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97203
--- Comment #10 from Tom de Vries ---
(In reply to Alexander Monakov from comment #8)
> No, -msoft-stack-reserve-local is really meant to be in bytes: it may not
> exceed the amount of .local memory reserved by CUDA driver (which is just
> 1-2
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Currently, https://gcc.gnu.org/onlinedocs/gcc/Nvidia-PTX-Options.html does not
list -msoft-stack-reserve-local.
: enhancement
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Using the option -msoft-stack-reserve-local= results in a:
...
.local .align 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97203
--- Comment #9 from Tom de Vries ---
(In reply to Tom de Vries from comment #2)
> Minimal version (without inlining sinf code from newlib):
> ...
> /* { dg-additional-options "-lm -foffload=-lm" } */
>
> #define N 1
>
> int
> main (void) {
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97203
--- Comment #7 from Tom de Vries ---
(In reply to Alexander Monakov from comment #6)
> (In reply to Tom de Vries from comment #4)
> > So, I think calling functions from simd code is atm not supported for nvptx.
> >
> > Stack variables in simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97318
Tom de Vries changed:
What|Removed |Added
Target Milestone|--- |11.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97318
--- Comment #1 from Tom de Vries ---
Tentative patch:
...
diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index afac1bda45d..7b6a42893f9 100644
--- a/gcc/config/nvptx/nvptx.c
+++ b/gcc/config/nvptx/nvptx.c
@@ -365,6 +365,30 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97348
--- Comment #6 from Tom de Vries ---
(In reply to CVS Commits from comment #4)
> Both build again cuda 9.1.
FWIW, tested post-commit against cuda 11.1, no issues found.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97333
--- Comment #2 from Tom de Vries ---
(In reply to Richard Biener from comment #1)
> (because well, on GIMPLE we can duplicate all blocks).
I'm not sure I understand why, given that tracer.c has a can_duplicate_bb_p
that sometimes returns false.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97348
Tom de Vries changed:
What|Removed |Added
Target Milestone|--- |11.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97348
--- Comment #3 from Tom de Vries ---
(In reply to Tom de Vries from comment #1)
> Looking in the nvptx-as sources, we find a hard_coded default:
> ...
> const char *smver = "sm_30";
> ...
> and after changing that to sm_35, the conftest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97348
--- Comment #2 from Tom de Vries ---
Anyway, we should be able to work around this by having gcc explicitly pass -m
sm_35 to nvptx-as:
...
-#define ASM_SPEC "%{misa=*:-m %*}"
+#define ASM_SPEC "%{misa=*:-m %*; :-m sm_35}"
...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97348
Tom de Vries changed:
What|Removed |Added
Target||nvptx
--- Comment #1 from Tom de Vries
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
The gcc objects and executables for nvptx are somewhat funny given that they
contain just ptx text.
However, during assembling, we do verify that the ptx is valid, by running
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
With ptx, we have insns that need to be executed in convergent mode, that is,
all threads in the warp active.
We can unfortunately not enforce this, but we could check it, which could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97203
--- Comment #5 from Tom de Vries ---
FWIW, another aspect here is convergence (as usual).
Looking at the SASS code for main$_omp_fn$0$impl, I don't find evidence for the
usual divergence/convergence ops (SSY/SYNC), which might mean that the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97203
--- Comment #4 from Tom de Vries ---
So, I think calling functions from simd code is atm not supported for nvptx.
Stack variables in simd code are mapped on a per-thread stack rather than on
the
usual per-warp stack.
The functions are compiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97203
--- Comment #3 from Tom de Vries ---
[ Note, this is with GOMP_NVPTX_JIT=-O0. ]
In sinf, we have:
...
45:return -__kernel_cosf(y[0],y[1]);
...
which translates to:
...
.loc 1 45 12
ld.f32 %r67,[%frame+4];
ld.f32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97203
--- Comment #2 from Tom de Vries ---
Minimal version (without inlining sinf code from newlib):
...
/* { dg-additional-options "-lm -foffload=-lm" } */
#define N 1
int
main (void) {
float k[N];
float res;
for (int i = 0; i < N; i++)
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
With this patch:
...
diff --git a/gcc/tree-cfg.c b/gcc/tree-cfg.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81802
Tom de Vries changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
In openacc programs, dimensions are either dynamic or hardcoded.
If the dimensions
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
When looking at the gcn plugin, there are a number of environment variables
that set/limit
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Created attachment 49321
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49321=edit
openmp test-case
While minimizing PR97203 - I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81690
--- Comment #9 from Tom de Vries ---
(In reply to Tobias Burnus from comment #4)
> The omp_is_initial_device() is only resolved at run time - hence, I think
> the linker still wants to see "usleep".
>
Well, yes, but that could be fixed:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90861
Tom de Vries changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90861
--- Comment #5 from Tom de Vries ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555606.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90861
Tom de Vries changed:
What|Removed |Added
CC||vries at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97159
Tom de Vries changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97008
--- Comment #5 from Tom de Vries ---
The openacc machinery is the only user of IFN_UNIQUE.
Thomas, as openacc maintainer, is this change ok for you, or are reasons why
you want to keep the IFN_UNIQUE as last stmt of the BB?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81690
--- Comment #8 from Tom de Vries ---
Pinged issue here (
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555496.html ).
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
We have:
...
/* Allocate per-lane storage and begin non-uniform execution region. */
static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97008
--- Comment #4 from Tom de Vries ---
I did a libgomp test run with commit f96b6328fa7 "[tree-optimization] Don't
clear ctrl-altering flag for IFN_UNIQUE" reverted, and with this patch:
...
diff --git a/gcc/tracer.c b/gcc/tracer.c
index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97159
--- Comment #4 from Tom de Vries ---
I'm currently not running into this ICE anymore, so presumably it was fixed.
I'm not sure by which commit though.
301 - 400 of 3233 matches
Mail list logo
