https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97005
--- Comment #7 from Tom de Vries ---
(In reply to Tom de Vries from comment #6)
> (In reply to Jakub Jelinek from comment #5)
> > What about u16.u8, u32.u8 and u64.u8 zero extensions?
>
> ptx has no .u8 registers, so there's no straightforward
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97005
--- Comment #6 from Tom de Vries ---
(In reply to Jakub Jelinek from comment #5)
> What about u16.u8, u32.u8 and u64.u8 zero extensions?
ptx has no .u8 registers, so there's no straightforward translation of the
example.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97005
--- Comment #4 from Tom de Vries ---
(In reply to Jakub Jelinek from comment #3)
> Is some workaround possible, like instead of emitting cvt.u32.u16 do
> cvt.u32.s16 and add explicit and?
This already works:
...
diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97005
--- Comment #2 from Tom de Vries ---
(In reply to Tom de Vries from comment #1)
> Created attachment 52359 [details]
> Cuda reproducer
Filed at https://developer.nvidia.com/nvidia_bug/3527713 as "cvt.u32.u16
sign-extends instead of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97005
--- Comment #1 from Tom de Vries ---
Created attachment 52359
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52359=edit
Cuda reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104345
--- Comment #2 from Tom de Vries ---
(In reply to Roger Sayle from comment #1)
> The other patches in the "nvptx Boolean" series are:
> patchq3: nvptx: Expand QI mode operations using SI mode instructions.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104364
--- Comment #5 from Tom de Vries ---
(In reply to Thomas Schwinge from comment #0)
> ... but only seen regressing for:
>
> - Nvidia Tesla K20c, Driver Version: 346.46
> - Nvidia Tesla K20c, Driver Version: 455.38
> - Nvidia Tesla K40c,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104364
--- Comment #4 from Tom de Vries ---
Created attachment 52341
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52341=edit
Tentative patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104364
--- Comment #3 from Tom de Vries ---
(In reply to Thomas Schwinge from comment #0)
> And, is it correct here to use the non-'atom' replacement, though? '%frame'
> comes from:
>
> .visible .func GOMP_taskwait
> {
> .reg .u64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104364
--- Comment #2 from Tom de Vries ---
(In reply to Tom de Vries from comment #1)
> What is odd is that the resulting insn is still validated, I would have
> expected that to fail.
Ah, the change is just silently rejected, this makes the problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104364
--- Comment #1 from Tom de Vries ---
(In reply to Thomas Schwinge from comment #0)
> 'nvptx-none/mgomp/libatomic/cas_1_.o' (complete diff):
>
> @@ -113,7 +113,7 @@
> .loc 3 80 9
> or.b64 %r61,%r60,%r39;
> .loc 3 82 11
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99932
Tom de Vries changed:
What|Removed |Added
Keywords||testsuite-fail
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100678
Tom de Vries changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100678
--- Comment #3 from Tom de Vries ---
This testcase should be passing since commit
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e0451f93d9faa13495132f4e246e9bef30b51417
([nvptx] Add some support for .local atomics).
It's possible that we'll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100428
Tom de Vries changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99932
--- Comment #15 from Tom de Vries ---
(In reply to Tom de Vries from comment #14)
> An observation when playing around with vector-length-128-4.c:
Another observation:
...
$L11:
ld.u64 %r108,[%r109];
st.u64 [%r112],%r108;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99932
--- Comment #14 from Tom de Vries ---
An observation when playing around with vector-length-128-4.c: there are two
ways in which I can make the example pass.
1. add barrier.sync.aligned 0 or membar.cta after first broad-cast receive
2. unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99932
--- Comment #13 from Tom de Vries ---
(In reply to Tom de Vries from comment #10)
> [ FTR, T400, driver 470.94 ]
>
> Interestingly, changing the default ptx version to 6.3 makes the minimal
> test-case pass, as well as the full parallel-dims.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99932
--- Comment #12 from Tom de Vries ---
Created attachment 52285
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52285=edit
Cuda reproducer non-32 vector length
[ On T400, driver version 470.94 ]
NVCC SASS:
...
$ ./do.sh
NVCC SASS,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99932
--- Comment #11 from Tom de Vries ---
(In reply to Tom de Vries from comment #10)
> Rerunning the entire testsuite though shows that the non-32-vector-length
> test-cases are still failing.
Minimal example:
...
int
main (void)
{
#pragma acc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99932
--- Comment #10 from Tom de Vries ---
[ FTR, T400, driver 470.94 ]
Interestingly, changing the default ptx version to 6.3 makes the minimal
test-case pass, as well as the full parallel-dims.c
The only code changes are shfl -> shfl.sync and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99932
--- Comment #9 from Tom de Vries ---
Created attachment 52273
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52273=edit
New cuda reproducer
$ ./do.sh
DRIVER SASS, ptxas=-O0:
+ /home/vries/cuda/11.4.3/bin/nvcc vector-max.cu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99932
--- Comment #8 from Tom de Vries ---
New minimal oacc example:
...
int
main (void)
{
int vectors_max = -1;
#pragma acc parallel\
num_gangs (1) num_workers (1) \
copy (vectors_max)
{
for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104146
--- Comment #1 from Tom de Vries ---
Adding:
...
/* { dg-xfail-run-if "PR 97102/PR 97106 - .alias not (yet) supported for nvptx"
{ offload_target_nvptx } } */
...
fixes the FAIL.
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
I.
I'm running into execution fails in libgomp testing with nvptx accelerator:
...
XPASS: libgomp.c/../libgomp.c-c++-common/pr96390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97444
--- Comment #1 from Tom de Vries ---
Created attachment 52169
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52169=edit
Tentative patch, __atomic_exchange only
Code generated for the generic case:
...
{ // Atomic exchange -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100428
--- Comment #4 from Tom de Vries ---
FTR, reproduces with driver version 470.86 on Quadro M1200 and GeForce GT 1030.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99932
--- Comment #7 from Tom de Vries ---
(In reply to Tom de Vries from comment #6)
> (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
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider gdb test-case:
...
$ cat src/gdb/testsuite/gdb.ada/dgopt/x.adb
-- Copyright 2019-2021 Free Software Foundation, Inc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103095
Tom de Vries changed:
What|Removed |Added
Ever confirmed|0 |1
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89262
Tom de Vries changed:
What|Removed |Added
Target Milestone|--- |10.2
--- Comment #1 from Tom de Vries
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider gdb test-case gdb/testsuite/gdb.arch/i386-avx.c.
It contains assembly doing:
...
asm ("vmovaps 0(%0), %%ymm0\n\t"
"vmovaps 32(%0), %%ymm1\n\t"
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
With a gcc build from commit 637dfcf43cf, I run into an incorrect Warray-bounds
(which causes a buildbreaker when building gdb, as reported here:
https://sourceware.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101643
Tom de Vries changed:
What|Removed |Added
Resolution|--- |FIXED
Keywords|
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
[ Filing FTR. ]
Consider gdb test-case foo_ra24_010.adb / pck.adb / pck.ads (
https://sourceware.org/git/?p=binutils-gdb.git;a=tree;f=gdb/testsuite/gdb.ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101633
--- Comment #2 from Tom de Vries ---
https://gcc.gnu.org/pipermail/gcc-patches/2017-May/474657.html :
...
>> 2017-05-15 Richard Biener
>>
>> * dwarf2out.c (loc_list_from_tree_1): Do not create
>> DW_OP_GNU_variable_value for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101633
Tom de Vries changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
[ Filing FTR. ]
Consider gdb test-case p.adb / pck.adb / pck.ads (
https://sourceware.org/git/?p=binutils-gdb.git;a=tree;f=gdb/testsuite/gdb.ada/array_of_variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101598
--- Comment #4 from Tom de Vries ---
(In reply to Bernd Edlinger from comment #2)
> Yes, but it wont fix dwarf-4 and also not the case
> when this is not the first function. then we'll
> have the .loc from the previous function extend to this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101598
--- Comment #3 from Tom de Vries ---
(In reply to Tom de Vries from comment #1)
> FWIW, this works for me:
And, doesn't reintroduce PR101575 on trunk.
AFAIU, the solution suggested in PR101575 comment 8 of setting the
DECL_SOURCE_LOCATION for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101598
--- Comment #1 from Tom de Vries ---
FWIW, this works for me:
...
$ git diff
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 82783c4968b..0e21775041c 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -28390,6 +28390,8 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101575
--- Comment #9 from Tom de Vries ---
(In reply to Eric Botcazou from comment #7)
> (> More specifically, it's gone because we have:
> > ...
> > $ more defs.s
> > .file "defs.adb"
> > .text
> > .Ltext0:
> > .align 2
> >
: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
I.
Consider test-case defs.adb/defs.ads from a gdb testcase (
https://sourceware.org/git/?p=binutils-gdb.git;a=tree;f=gdb/testsuite/gdb.ada/formatted_ref
).
When compiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101575
--- Comment #6 from Tom de Vries ---
(In reply to Eric Botcazou from comment #3)
> > Because ?
>
> No straightforward solution in DWARF < 5 and, therefore, not worth the
> hassle.
How about backporting the commit to gcc-11-branch? WDYT?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101575
--- Comment #5 from Tom de Vries ---
(In reply to Bernd Edlinger from comment #4)
> Hi,
>
> I think my commit e69ac020372 ("Add line debug info for virtual thunks")
> has a mitigating effect on this test case:
> due to such functions have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101575
--- Comment #2 from Tom de Vries ---
(In reply to Eric Botcazou from comment #1)
> Not going to be fixed,
Because ?
: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider test-case defs.adb/defs.ads from a gdb testcase (
https://sourceware.org/git/?p=binutils-gdb.git;a=tree;f=gdb/testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101470
--- Comment #1 from Tom de Vries ---
Created attachment 51161
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51161=edit
Demonstrator patch
I wrote a demonstrator patch that makes the two mentioned differences
disappear.
It also drops
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
In a gdb discussion here (
https://sourceware.org/bugzilla/show_bug.cgi?id=28094 ) (starting from the fact
that the dwarf 5 standard mentions that there's a "common practice of stri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101452
--- Comment #2 from Tom de Vries ---
(In reply to Richard Biener from comment #1)
> do you have an idea why it works with -gdwarf-4 but not -gdwarf-5?
If we do with n == 4 and n == 5:
...
$ rm -f *.c.* ; ./install/bin/g++ test.c -c -g
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Test-case:
...
$ cat test.c
struct a {
int a;
static int sa;
};
int
main (void)
{
struct a a;
a.a = 1
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
I.
Consider test-cases:
...
$ cat -n test.c
1 int
2 main (void)
3 {
4while (1);
5
6return 0;
7 }
$ cat -n test2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100678
--- Comment #1 from Tom de Vries ---
(In reply to Thomas Schwinge from comment #0)
> At this point, it's (a) unclear whether the PR83812 restriction indeed is
> supposed to be lifted for certain modern GPU hardware/SM levels/CUDA Driver
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100670
--- Comment #1 from Tom de Vries ---
Note btw that clang does not generate a warning:
...
$ clang -c -Wall -O0 -g -Werror foo.c -DTYPE="void *"
$
...
which means the attribute works, because if we remove the attribute we have
instead:
...
$
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider the following test-case:
...
$ cat foo.c
typedef void *void_ptr;
static TYPE __attribute__((unused))
foo (void)
{
return 0;
}
...
Let's try with type int:
...
$ gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573
--- Comment #3 from Tom de Vries ---
Hmm, I reproduced the problem on the original test-case:
libgomp.c-c++-common/for-3.c, and minimized from there:
...
$ cat libgomp/testsuite/libgomp.c-c++-common/for-3.c
/* { dg-additional-options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573
--- Comment #2 from Tom de Vries ---
(In reply to Tobias Burnus from comment #1)
> Created attachment 50803 [details]
> Reduced testcase - works with hostfall back but fails with GCN and nvptx
Is this not an invalid test-case?
The semantics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100497
--- Comment #16 from Tom de Vries ---
*** Bug 96932 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96932
Tom de Vries changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100497
Tom de Vries changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100497
--- Comment #13 from Tom de Vries ---
Posted: https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570508.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96932
--- Comment #5 from Tom de Vries ---
Created attachment 50811
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50811=edit
Tentative patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97102
Bug 97102 depends on bug 96005, which changed state.
Bug 96005 Summary: Add possibility to use newer ptx isa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96005
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96005
Tom de Vries changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
We have -misa, and soon we'll have -mptx (PR96005).
We can try to make sensible decisions about proper defaults, but we still may
get it wrong for some users. So
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96932
--- Comment #4 from Tom de Vries ---
(In reply to Tobias Burnus from comment #3)
> Crossref: PR100497 - fails on Volta without
> membar.sys;
> before
> atom.global.exch.b32
>
> Unfortunately, compared to pre-Volta, it is very slow -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100497
--- Comment #12 from Tom de Vries ---
After investigation by Tobias, this looks like an instance of PR96932.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96005
--- Comment #4 from Tom de Vries ---
Created attachment 50800
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50800=edit
Tentative patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96005
--- Comment #3 from Tom de Vries ---
(In reply to Tom de Vries from comment #2)
> On my usual machine, using system cuda I don't get beyond 6.1:
Upgraded to ubuntu 20.4, giving me system cuda 10.1, which allows me to use isa
6.3. Now testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100397
Tom de Vries changed:
What|Removed |Added
CC||vries at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100390
Tom de Vries changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100497
--- Comment #9 from Tom de Vries ---
(In reply to Tobias Burnus from comment #8)
> I am wondering whether it has something to do with shfl now requiring .sync,
> especially for sm_70. (Non-sync version was deprecated in ISA 6.0 and for
> sm_70
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96005
--- Comment #2 from Tom de Vries ---
On my usual machine, using system cuda I don't get beyond 6.1:
...
diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index 7a7a9130e84..ecf3803df3c 100644
--- a/gcc/config/nvptx/nvptx.c
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100497
Tom de Vries changed:
What|Removed |Added
CC||tschwinge at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100497
--- Comment #5 from Tom de Vries ---
Does it pass with GOMP_NVPTX_JIT=-O0 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100497
--- Comment #4 from Tom de Vries ---
(In reply to Tobias Burnus from comment #2)
> See below, fails with 4 systems, works with 3 others.
Can anything be deduced from driver versions?
Or card architecture?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100497
--- Comment #3 from Tom de Vries ---
Doesn't fail for me unfortunately.
I've tried with GOMP_NVPTX_JIT=-O0..-O4, no luck.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100497
--- Comment #1 from Tom de Vries ---
Can you post a minimal version?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100428
--- Comment #3 from Tom de Vries ---
The ptx code looks a lot like the cuda reproducer in PR99932 comment 4, so I'm
going to retest this once I get a driver where that one is fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100428
Tom de Vries changed:
What|Removed |Added
Target||nvptx
--- Comment #2 from Tom de Vries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100428
--- Comment #1 from Tom de Vries ---
Likewise, c++:
...
FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/reduction-7.c
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none -O0
execution test
...
-foffload=nvptx-none -O0 execution test
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100321
Tom de Vries changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100321
--- Comment #5 from Tom de Vries ---
(In reply to Tom de Vries from comment #4)
> So, something like this reflects the current state:
> ...
> diff --git a/gcc/omp-low.c b/gcc/omp-low.c
> index 7b122059c6e..a0561800977 100644
> ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100390
--- Comment #2 from Tom de Vries ---
In combination with stress -c 5, I get more FAILs:
...
$ for n in $(seq 1 100); do make check "RUNTESTFLAGS=fortran.exp=depobj-1.f90"
2>&1 | grep "expected passes"; done
# of expected passes1
#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100390
--- Comment #1 from Tom de Vries ---
Fails not very often (twice in a run of 100):
...
$ for n in $(seq 1 100); do make check "RUNTESTFLAGS=fortran.exp=depobj-1.f90"
2>&1 | grep "expected passes"; done
# of expected passes
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: ---
I ran into:
...
Execution timeout is: 300
spawn [open ...]^M
STOP 3
FAIL: libgomp.fortran/depobj-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100352
Tom de Vries changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100352
--- Comment #4 from Tom de Vries ---
Going through the lock lifetime using backtraces:
...
(gdb) watch ((pthread_mutex_t *) 0x6059d0)->__data.__lock
Hardware watchpoint 2: ((pthread_mutex_t *) 0x6059d0)->__data.__lock
...
I. Locked from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100352
--- Comment #3 from Tom de Vries ---
Minimal example:
...
program main
implicit none
open (10, file='a.dat', asynchronous="yes")
write (10,*,asynchronous="yes") 4, 3
end program
...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100352
--- Comment #2 from Tom de Vries ---
More complete backtrace using reproduction on command line:
...
Thread 1 "async_io_1.exe" received signal SIGSEGV, Segmentation fault.
__lll_unlock_elision (lock=0x6069d0, private=0)
at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100352
--- Comment #1 from Tom de Vries ---
Build at commit b9bc4467cc7 "tree-optimization/96513 - add testcase for fixed
bug".
Gcc configured like this:
...
$ ./build/gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=./build/gcc/xgcc
Target:
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?
201 - 300 of 3225 matches
Mail list logo
