https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95654
Tom de Vries changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95654
Tom de Vries changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81778
--- Comment #10 from Tom de Vries ---
Tentative patch:
...
diff --git a/gcc/omp-expand.c b/gcc/omp-expand.c
index 99cb4f9dda4..034de497390 100644
--- a/gcc/omp-expand.c
+++ b/gcc/omp-expand.c
@@ -6333,6 +6333,8 @@ expand_omp_simd (struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80845
Tom de Vries changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81778
--- Comment #9 from Tom de Vries ---
I ran into this again, and did another round of minimizing. This time, I added
some buffering around where we write, and check the entire buffer afterwards:
...
$ cat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96428
Tom de Vries changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81688
Tom de Vries changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90931
Tom de Vries changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
While debugging gcc/testsuite/gcc.dg/pr94600-1.c, I found that nvptx doesn't
define PCC_BITFIELD_TYPE_MATTERS.
AFAIU, the theory for offloading is that settings that influence abi
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: ---
When running libbacktrace check, I run into:
...
make[3]: Entering directory
'/dev/shm/tdevries/data/master/2020-09
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97207
--- Comment #15 from Tom de Vries ---
(In reply to Richard Biener from comment #9)
> diff --git a/gcc/vec.h b/gcc/vec.h
> index d73d865cff2..c0e577893a3 100644
> --- a/gcc/vec.h
> +++ b/gcc/vec.h
> @@ -1546,7 +1546,12 @@ public:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97207
--- Comment #3 from Tom de Vries ---
Created attachment 49271
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49271=edit
gzipped preprocessed source
Reproduce:
$ g++ -m64 -fno-PIE -c -O0 -g -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97207
--- Comment #2 from Tom de Vries ---
Configure from build-gcc/config.log:
...
$ /home/vries/nvptx/trunk/source-gcc/configure --target=nvptx-none --prefix=
--enable-languages=c,c++,fortran --enable-werror --enable-checking=yes CC=gcc
-m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97207
Tom de Vries changed:
What|Removed |Added
Target||nvptx
CC|
on: 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: ---
Building trunk for nvptx on ubuntu 18.04.5 LTS with g++ (Ubun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97102
--- Comment #7 from Tom de Vries ---
In PR97106 comment 1, it's suggested:
...
14:11 < amonakov> Tobias__: I think the proper way to solve this is define
hooks for the backend to print something for aliases, and then have nvptx-ld.c
resolve them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97102
Tom de Vries changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97158
Tom de Vries changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97159
--- Comment #2 from Tom de Vries ---
Fib is a recursive function, and the problem occurs while handling a recursion
call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97159
--- Comment #1 from Tom de Vries ---
Segfaults because tt is NULL:
...
Program received signal SIGSEGV, Segmentation fault.
0x012b1a69 in modref_may_conflict (tt=0x0, ref=0x7fffd8d0,
tbaa_p=true)
at
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
With a build of commit 48b0c1250a5c7d72be6b3fbbb1117d1cce43daee (Date: Mon Sep
21 12:46:00 2020 +0200) for x86_64-linux with nvptx accelerator, we run into:
...
FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96005
--- Comment #1 from Tom de Vries ---
(In reply to Tom de Vries from comment #0)
> Currently, we're at ptx isa v3.1:
> ...
> static void
> nvptx_file_start (void)
> {
> fputs ("// BEGIN PREAMBLE\n", asm_out_file);
> fputs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97102
Tom de Vries changed:
What|Removed |Added
Attachment #49252|0 |1
is obsolete|
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
...
$ cat gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-1.c
/* Test for _Atomic in C11. Basic execution tests for atomic loads
and stores. */
/* { dg-do run } */
/* { dg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97102
--- Comment #5 from Tom de Vries ---
Created attachment 49252
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49252=edit
Other draft patch
I started out independently, and converged to roughly the same code.
One thing I came across during
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97102
--- Comment #4 from Tom de Vries ---
(In reply to Tobias Burnus from comment #2)
> Created attachment 49239 [details]
> Draft patch
>
> PTX ISA Notes
> .alias directive introduced in PTX ISA 6.3.
>
> Thus, it does not work everywhere :-(
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95654
--- Comment #13 from Tom de Vries ---
(In reply to Tom de Vries from comment #11)
> My guess at this point, is that duplicating the block with VOTE_ANY has the
> effect that the JIT compiler doesn't recognize control flow divergence
> before
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95654
--- Comment #12 from Tom de Vries ---
(In reply to Tom de Vries from comment #7)
> Minimal example after commit 91347c3bbf7 "Fortran: OpenMP - fix simd with
> (last)private (PR97061)":
> ...
> ! { dg-do run }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95654
Tom de Vries changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95654
--- Comment #8 from Tom de Vries ---
Created attachment 49228
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49228=edit
Dumps for failing test-case (no collapse case)
(In reply to Tom de Vries from comment #7)
> Minimal example after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95654
--- Comment #7 from Tom de Vries ---
Minimal example after commit 91347c3bbf7 "Fortran: OpenMP - fix simd with
(last)private (PR97061)":
...
! { dg-do run }
program main
implicit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95654
--- Comment #6 from Tom de Vries ---
Created attachment 49227
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49227=edit
Dumps for failing test-case
(In reply to Tom de Vries from comment #5)
> Minimal example:
> ...
> ! { dg-do run }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95654
Tom de Vries changed:
What|Removed |Added
CC||vries at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97030
--- Comment #2 from Tom de Vries ---
(In reply to Tom de Vries from comment #0)
> ATM, we have the following in the nvptx.c source code:
> ...
> #define WORKAROUND_PTXJIT_BUG 1
> #define WORKAROUND_PTXJIT_BUG_2 1
> #define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97030
--- Comment #1 from Tom de Vries ---
(In reply to Tom de Vries from comment #0)
> ATM, we have the following in the nvptx.c source code:
> ...
> #define WORKAROUND_PTXJIT_BUG 1
> #define WORKAROUND_PTXJIT_BUG_2 1
> #define
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
ATM, we have the following in the nvptx.c source code:
...
#define WORKAROUND_PTXJIT_BUG 1
#define WORKAROUND_PTXJIT_BUG_2 1
#define WORKAROUND_PTXJIT_BUG_3 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96932
Tom de Vries changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96898
Tom de Vries changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96964
Tom de Vries changed:
What|Removed |Added
Target Milestone|--- |11.0
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97004
Tom de Vries changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97004
--- Comment #1 from Tom de Vries ---
Tentative patch:
...
diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index 0376ad6ce9f..26868590322 100644
--- a/gcc/config/nvptx/nvptx.c
+++ b/gcc/config/nvptx/nvptx.c
@@ -2054,7 +2054,11 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97008
--- Comment #2 from Tom de Vries ---
(In reply to Richard Biener from comment #1)
> Where's this property used? grepping finds searches in omp-offload but those
> all(?) search the whole instruction stream.
In ignore_bb_p in gcc/tracer.c, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97006
--- Comment #1 from Tom de Vries ---
Minimal example:
...
void __attribute__ ((noclone, noinline))
checkv (char *dst, const char *fmt, __builtin_va_list va)
{
int n = __builtin_vsprintf (dst, fmt, va);
if (n != 3)
__builtin_abort ();
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97000
Tom de Vries changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97000
--- Comment #10 from Tom de Vries ---
(In reply to Richard Biener from comment #9)
> Meh, this way of forcing UNIQUE last to speedup lookup is a hack ... but
> yes, your patch from comment#7 looks OK if you add
>
> /* IFN_UNIQUE should be
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
[ spin-off of PR97000 comment 9. ]
There's an invariant that says IFN_UNIQUE needs to be the last stmt in a bb
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
First sign of trouble:
...
FAIL: test_d_i:291: "%hhi" expected result for "-16657" doesn't match function
call return v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96997
--- Comment #4 from Tom de Vries ---
-fdump-tree-all-lineno with gcc-10:
...
main ()
{
struct string D.37010;
struct allocator D.37009;
struct string D.37052;
struct allocator D.37051;
int D.40670;
[test.c:7:40]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96997
--- Comment #3 from Tom de Vries ---
-fdump-tree-all-lineno with gcc-9:
...
main ()
{
struct string D.36200;
struct allocator D.36199;
struct string D.36242;
struct allocator D.36241;
int D.39843;
[test.c:7:27]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96997
--- Comment #2 from Tom de Vries ---
Line number info for main [4009d2,400ad2] with g++ 9.3.1:
...
CU: ./test.c:
File nameLine numberStarting addressView
Stmt
test.c
: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Minimized to:
...
$ cat builtin-arith-overflow-15.c
int
main (void)
{
signed char r;
unsigned
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider this code from c-c++-common/spec-barrier-1.c:
...
#ifdef __SIZEOF_INT128__
__int128 g = 9;
#endif
...
We seem to be generating:
...
// BEGIN GLOBAL VAR DEF: g
.visible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97000
--- Comment #8 from Tom de Vries ---
This detects the problem earlier, in the host compiler:
...
diff --git a/gcc/omp-offload.c b/gcc/omp-offload.c
index 32c2485abd4..fce01af7682 100644
--- a/gcc/omp-offload.c
+++ b/gcc/omp-offload.c
@@ -1148,6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97000
--- Comment #7 from Tom de Vries ---
(In reply to Tom de Vries from comment #6)
> I wonder if this will work:
> ...
> diff --git a/gcc/tree-cfgcleanup.c b/gcc/tree-cfgcleanup.c
> index f8169eef781..79f716b9dbe 100644
> ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97000
--- Comment #6 from Tom de Vries ---
I wonder if this will work:
...
diff --git a/gcc/tree-cfgcleanup.c b/gcc/tree-cfgcleanup.c
index f8169eef781..79f716b9dbe 100644
--- a/gcc/tree-cfgcleanup.c
+++ b/gcc/tree-cfgcleanup.c
@@ -212,7 +212,9 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97000
--- Comment #5 from Tom de Vries ---
Right, I just found this:
...
/* IFN_UNIQUE should be the last insn, to make checking for it
as cheap as possible. */
|| (gimple_call_internal_p (stmt)
&&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97000
--- Comment #3 from Tom de Vries ---
(In reply to Tom de Vries from comment #2)
> Tentative patch:
That fixes all the new libgomp FAILs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97000
--- Comment #2 from Tom de Vries ---
Tentative patch:
...
diff --git a/gcc/tracer.c b/gcc/tracer.c
index 82ede722534..ec97eb51538 100644
--- a/gcc/tracer.c
+++ b/gcc/tracer.c
@@ -99,6 +99,12 @@ ignore_bb_p (const_basic_block bb)
must be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97000
--- Comment #1 from Tom de Vries ---
At asyncwait-1.xnvptx-none.mkoffload.179t.slsr, we have the valid:
...
[local count: 87490071]:
_14 = .UNIQUE (OACC_FORK, 0, 2);
_75 = .GOACC_DIM_SIZE (0);
_76 = .GOACC_DIM_POS (0);
_77 =
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
When building an x86_64 + nvptx accelerator setup with the patch adding
libatomic for nvptx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96991
Tom de Vries changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96991
--- Comment #4 from Tom de Vries ---
(In reply to Jakub Jelinek from comment #3)
> Note, the testcase would need to require int128 effective target or even
> sync_int_128_runtime, ensure linking with -latomic on offloading targets
> that need it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96991
--- Comment #2 from Tom de Vries ---
Patch:
...
diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index 39d0275493a..6f393dfea01 100644
--- a/gcc/config/nvptx/nvptx.c
+++ b/gcc/config/nvptx/nvptx.c
@@ -910,7 +910,7 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96991
--- Comment #1 from Tom de Vries ---
We run into assert:
...
913 gcc_assert (type == boolean_type_node);
...
because:
...
(gdb) call debug_generic_expr (type)
_Bool
(gdb) call debug_generic_expr (boolean_type_node)
No symbol
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
When running this libgomp testsuite test-case on x86_64 with nvptx accelerator:
...
$ cat src/libgomp/testsuite/libgomp.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96932
--- Comment #1 from Tom de Vries ---
FWIW, I've tried this test-case to trigger the problem, but it runs fine:
...
$ cat libgomp/testsuite/libgomp.oacc-c-c++-common/test.c
/* { dg-do run } */
#include
#include
#define assert(COND) \
do {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96964
--- Comment #2 from Tom de Vries ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553393.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96898
--- Comment #8 from Tom de Vries ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553393.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96898
--- Comment #7 from Tom de Vries ---
(In reply to Tom de Vries from comment #6)
> Created attachment 49195 [details]
> Tentative patch
>
> Introduces an option -fatomic-libcalls (analogous to -fsync-libcalls) such
> that __atomic_test_and_set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96898
--- Comment #6 from Tom de Vries ---
Created attachment 49195
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49195=edit
Tentative patch
Introduces an option -fatomic-libcalls (analogous to -fsync-libcalls) such that
__atomic_test_and_set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96964
--- Comment #1 from Tom de Vries ---
This is an attempt to implement it by using a fallback in libatomic (see also
PR96898):
...
diff --git a/gcc/config/nvptx/nvptx.md b/gcc/config/nvptx/nvptx.md
index 4168190fa42..612240661f8 100644
---
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Currently __atomic_test_and_set for nvptx falls back onto the "Failing all
else, assume a single threaded environment and simply perform the operation&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96898
--- Comment #4 from Tom de Vries ---
(In reply to Jakub Jelinek from comment #3)
> For OpenMP reductions, we really don't care what kind of mutex protects the
> updates, as long as it is the same for all updates of the same reduction.
> I
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
After digging into GOMP_atomic_start/end I realized these also imply barrier
semantics.
And looking at the source code used for nvptx in libgomp/config/accel/mutex.h,
that should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96898
--- Comment #2 from Tom de Vries ---
Hmm, I found this difference:
- AFAIU, GOMP_atomic_start/end have barrier semantics
- libatomics protect_start/end are always paired with explicit barriers, so
presumably these don't have barrier semantics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96898
Tom de Vries changed:
What|Removed |Added
CC||jakub at redhat dot com
--- Comment #1
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
When building gcc for nvptx, we get:
...
checking for libatomic support... no
...
As mentioned here (
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553142.html ), could
be useful.
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Created attachment 49174
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49174=edit
fibheap.c, preproces
: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
I build gdb/gdbserver master with gcc-11 (gcc-11 (SUSE Linux) 11.0.0 20200824
(experimental) [revision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96706
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: ---
Consider test-case pr89663-1.c, minimized from
gcc/testsuite/gcc.c-torture/compile/pr89663-1.c, and with added main:
...
long lrint ();
void
foo (long long *p)
{
int n = 0;
p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96494
Tom de Vries changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90933
--- Comment #1 from Tom de Vries ---
New behaviour for the test-case.
Instead of ICE-ing, we have:
...
/home/vries/nvptx/mainkernel-2/source-gcc/gcc/testsuite/gcc.dg/memcmp-1.c: In
function 'test_strncmp_49_1':^M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90928
Tom de Vries changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90928
Tom de Vries changed:
What|Removed |Added
Target Milestone|9.4 |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96589
--- Comment #2 from Tom de Vries ---
With this patch:
...
diff --git a/gcc/testsuite/gcc.dg/builtin-object-size-21.c
b/gcc/testsuite/gcc.dg/builtin-object-size-21.c
index 7e0f85ffdf3..87058988780 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96494
--- Comment #3 from Tom de Vries ---
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551842.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96566
Tom de Vries changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96566
--- Comment #17 from Tom de Vries ---
(In reply to Martin Sebor from comment #10)
> The issue described in bug 92815 comment 9 sounds like a similar problem.
> Does sending the output to /dev/null instead of a .s file help? If it does,
>
: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
[ As proposed here: PR 96566 comment 10. ]
This directive can be useful if the assembly file is potentially large, to
prevent we run out of disk space.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96566
--- Comment #16 from Tom de Vries ---
(In reply to Tom de Vries from comment #9)
> (In reply to Jakub Jelinek from comment #7)
> > I'm not sure a target specific option is the way to go here, the only
> > difference is that nvptx spends all the
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
[ As proposed in PR96566. ]
When compiling test-case gcc.dg/builtin-object-size-21.c for nvptx, we time
out, possibly while consuming a lot of disk space.
This has now been fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96566
--- Comment #14 from Tom de Vries ---
(In reply to Tom de Vries from comment #12)
> (In reply to Tom de Vries from comment #6)
> > (In reply to Jakub Jelinek from comment #3)
> > > Either the test can be skipped on nvptx or any targets that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96566
--- Comment #13 from Tom de Vries ---
Printing correct array dimension fixed in
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b9c7fe59f9f66ecc091e215c826ecd1a04d032dc
.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96566
--- Comment #12 from Tom de Vries ---
(In reply to Tom de Vries from comment #6)
> (In reply to Jakub Jelinek from comment #3)
> > Either the test can be skipped on nvptx or any targets that don't emit
> > something like a .zero similar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96566
--- Comment #11 from Tom de Vries ---
(In reply to Martin Sebor from comment #10)
> The issue described in bug 92815 comment 9 sounds like a similar problem.
> Does sending the output to /dev/null instead of a .s file help? If it does,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96566
--- Comment #9 from Tom de Vries ---
(In reply to Jakub Jelinek from comment #7)
> I'm not sure a target specific option is the way to go here, the only
> difference is that nvptx spends all the time on this (adjusted) testcase at
> compile time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96566
--- Comment #8 from Tom de Vries ---
(In reply to Tom de Vries from comment #6)
> With a size of 0xfff we take 5s and generate a 193MB assembly file.
>
> With a size of 0x we take 1m10s and generate a 3.1GB assembly file.
FTR, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96566
--- Comment #6 from Tom de Vries ---
(In reply to Jakub Jelinek from comment #3)
> Either the test can be skipped on nvptx or any targets that don't emit
> something like a .zero similar directive, or we should after the size of
> variable is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96566
--- Comment #5 from Tom de Vries ---
Then with this in addition:
...
@@ -2202,7 +2202,7 @@ nvptx_assemble_decl_begin (FILE *file, const char *name,
const char *section,
/* Neither vector nor complex types can contain the other. */
401 - 500 of 3233 matches
Mail list logo
