https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
--- Comment #26 from Tom de Vries ---
Eventually, a-test-2.c.121t.retslot has:
...
[count: 0]:
:
_3 = MEM[(struct __shared_count *)&file_exception + 8B]._M_pi;
if (_3 != 0B)
...
and then the following a-test-2.c.122t.fre3 introduces the w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
--- Comment #24 from Tom de Vries ---
Created attachment 61858
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61858&action=edit
debug patch
Using this patch (on top of current trunk), I get the following in
a-test-2.c.092i.inline:
...
Con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
--- Comment #22 from Tom de Vries ---
FYI, I've submitted a workaround for gdb that disables -fipa-modref for release
gcc 12.0 - 16.0 (
https://sourceware.org/pipermail/gdb-patches/2025-July/219213.html ), assuming
that his will be fixed in 16.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
--- Comment #21 from Tom de Vries ---
(In reply to Tom de Vries from comment #20)
> Seems to be fixed by:
> ...
> diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c
> index 9e537b04196..fbdf8da36df 100644
> --- a/gcc/ipa-modref.c
> +++ b/gcc/ipa-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
--- Comment #20 from Tom de Vries ---
Seems to be fixed by:
...
diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c
index 9e537b04196..fbdf8da36df 100644
--- a/gcc/ipa-modref.c
+++ b/gcc/ipa-modref.c
@@ -5109,7 +5109,6 @@ ipa_merge_modref_summary_a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
Tom de Vries changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
--- Comment #17 from Tom de Vries ---
Created attachment 61839
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61839&action=edit
test-2.c
I've minimized it, and dropped the print:
...
$ for n in 0 1 2; do g++ test-2.c -O$n; ./a.out ; echo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
--- Comment #15 from Tom de Vries ---
(In reply to Tom de Vries from comment #14)
> I've managed to write a synthetic example:
I've bisect this to:
...
commit 4d6132e59327e809a4d4e39fb9465dbd43775b7c
Author: Richard Biener
Date: Thu Aug 10 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
--- Comment #14 from Tom de Vries ---
Created attachment 61838
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61838&action=edit
test.c
I've managed to write a synthetic example:
...
$ g++-14 test.c -O0 -g; ./a.out
msg: 'No symbol table is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
--- Comment #13 from Tom de Vries ---
Created attachment 61833
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61833&action=edit
gdb.ltrans58.ltrans.135t.sra.gz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
--- Comment #12 from Tom de Vries ---
Created attachment 61832
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61832&action=edit
gdb.ltrans58.ltrans.134t.bitintlower1.gz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
--- Comment #11 from Tom de Vries ---
I build with -fdump-tree-all -fdump-ipa-all -fdump-rtl-all, resulting in a
rather large build:
...
$ du -hs build/
107Gbuild/
...
At gdb.ltrans58.ltrans.134t.bitintlower1, I have in parse_linespec:
...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
--- Comment #10 from Tom de Vries ---
(In reply to Tom de Vries from comment #4)
> and then rethrown:
> ...
> if (file_exception.reason < 0)
> throw_exception (std::move (file_exception));
> ...
>
> The gdb_exception class contain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
--- Comment #8 from Tom de Vries ---
(In reply to Andrew Pinski from comment #7)
> Question does it just happen on x86_64-linux-gnu or can it be reproduce on
> aarch64-linux-gnu or powerpc64-linux-gnu too?
Reproduced on Fedora Linux Asahi Remix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
--- Comment #4 from Tom de Vries ---
The problem scenario is as follows.
An error is thrown in symtabs_from_filename:
...
throw_error (NOT_FOUND_ERROR,
_("No symbol table is loaded. "
"Use th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
--- Comment #3 from Tom de Vries ---
The investigation in the gdb PR has identified a range of bad commits.
First bad commit:
- commit aae723d360c
("sra: SRA of non-escaped aggregates passed by reference to calls")
First good commit after fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
--- Comment #2 from Tom de Vries ---
Workaround:
...
diff --git a/gdb/linespec.c b/gdb/linespec.c
index b59c0553c34..46b25a0047d 100644
--- a/gdb/linespec.c
+++ b/gdb/linespec.c
@@ -2615,7 +2615,7 @@ parse_linespec (linespec_parser *parser, cons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
--- Comment #1 from Tom de Vries ---
Created attachment 61812
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61812&action=edit
valgrind log
: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
[ First reported at gdb bugzilla:
https://sourceware.org/bugzilla/show_bug.cgi?id=32571 ]
Take gdb sources, either current trunk (f.i. commit 87c1293c7d4), or tag
gdb-16.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119766
Tom de Vries changed:
What|Removed |Added
CC||vries at gcc dot gnu.org
--- Comment #5
us: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider test-case:
...
$ cat test.cc
#include
class X
{
public:
X (int v) {
valu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115272
--- Comment #5 from Tom de Vries ---
(In reply to Tom de Vries from comment #4)
> With this patch:
So, would this approach be acceptable?
If so, I can put effort into doing a proper submission.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93988
--- Comment #4 from Tom de Vries ---
(In reply to Tom Tromey from comment #2)
> Also, I see the "__unknown__" there now -- better IMO to let gdb synthesize
> a name instead.
Attempt to synthesize the name in gcc:
...
commit d2b7f315ad976ff18c71e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93988
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=115272
--- Comment #4 from Tom de Vries ---
With this patch:
...
diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc
index 8ec3856873e..ea3318396e0 100644
--- a/gcc/dwarf2out.cc
+++ b/gcc/dwarf2out.cc
@@ -13247,6 +13247,7 @@ base_type_die (tree type, bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115272
--- Comment #3 from Tom de Vries ---
(In reply to Richard Biener from comment #2)
> (In reply to Richard Biener from comment #1)
> > How does it work for 'double' vs. 'long double' themselves?
> >
> > <1><32>: Abbrev Number: 3 (DW_TAG_base_typ
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider test.c:
...
$ cat test.c
__complex__ float cf;
__complex__ double cd;
__complex__ long double cld;
...
compiled using an arm-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111409
Tom de Vries changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #
||vries at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #4 from Tom de Vries ---
Duplicate.
*** This bug has been marked as a duplicate of bug 111409 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111409
Tom de Vries changed:
What|Removed |Added
CC||vries at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115066
Tom de Vries changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115066
Tom de Vries changed:
What|Removed |Added
Target Milestone|--- |15.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115066
--- Comment #7 from Tom de Vries ---
Submitted here ( https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651586.html
).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115066
--- Comment #6 from Tom de Vries ---
(In reply to Jakub Jelinek from comment #5)
> Just make it if (dwarf_split_debug_info) then?
That works as well indeed:
...
diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc
index eedb13bb069..70b7f5f42cd 100
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115066
--- Comment #4 from Tom de Vries ---
(In reply to Richard Biener from comment #3)
> And with -gstrict-dwarf -gdwarf-4?
With:
...
$ gcc.sh -gdwarf-4 -gsplit-dwarf /data/vries/hello.c -g3 -gstrict-dwarf
...
we get:
...
.section.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115066
--- Comment #2 from Tom de Vries ---
(In reply to Tom de Vries from comment #1)
> Looking at the source code, I wonder if this would fix it:
> ...
> diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc
> index eedb13bb069..045858bf638 100644
> --- a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115066
--- Comment #1 from Tom de Vries ---
Looking at the source code, I wonder if this would fix it:
...
diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc
index eedb13bb069..045858bf638 100644
--- a/gcc/dwarf2out.cc
+++ b/gcc/dwarf2out.cc
@@ -29045,7
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider a hello world, compiled with split dwarf and dwarf version 4, and -g3
for macro info:
...
$ gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113599
Tom de Vries changed:
What|Removed |Added
CC||vries at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112565
--- Comment #1 from Tom de Vries ---
(In reply to Anonymous from comment #0)
> Tom de Vries suggests that this issue may be attributed to a GCC
> optimization bug.
I do not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110799
--- Comment #7 from Tom de Vries ---
(In reply to Alexander Monakov from comment #5)
> This trips Valgrind's data race detector (valgrind --tool=helgrind) too. So
> I don't think checking SANITIZE_THREAD is the correct approach.
Can you elabora
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110799
--- Comment #6 from Tom de Vries ---
(In reply to rguent...@suse.de from comment #4)
> I'm suggesting to not fix it ;)
Can you explain why ?
It doesn't look difficult to fix to me, and I don't see any downsides.
> That said, is TSAN a useful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110799
--- Comment #2 from Tom de Vries ---
(In reply to Richard Biener from comment #1)
> We consider introducing load data races OK, what's the difference here?
This is a load vs. store data race.
> There are other passes that would do similar thi
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
I ran into a Wdangling-pointer warning and decided to read the docs and try out
an example.
The first one listed is:
...
int f (int c1, int c2, x)
{
char *p = strchr ((char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108600
--- Comment #4 from Tom de Vries ---
(In reply to Tom de Vries from comment #0)
> Note that for for instance gdb test-case gdb.ada/ref_param.exp, this
> convention was broken for gcc 7.5.0 (and I don't know how much earlier), and
> my current gu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108615
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: ---
[ Filing FTR, to link a commit to a test-case that it fixes, and to be able to
refer to it from gdb sources. ]
Consider pck.adb/pck.ads from here (
https://sourceware.org/git/?p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108600
--- Comment #3 from Tom de Vries ---
(In reply to Tom de Vries from comment #2)
> (In reply to Tom de Vries from comment #1)
> > Created attachment 54371 [details]
>
> We probably don't want to emit in all cases, maybe limiting to
> "dwarf_ver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47471
Tom de Vries changed:
What|Removed |Added
CC||vries at gcc dot gnu.org
--- Comment #24
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108600
--- Comment #2 from Tom de Vries ---
(In reply to Tom de Vries from comment #1)
> Created attachment 54371 [details]
We probably don't want to emit in all cases, maybe limiting to
"dwarf_version >= 3", or "!dwarf_strict || dwarf_version >= 3".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108600
--- Comment #1 from Tom de Vries ---
Created attachment 54371
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54371&action=edit
tentative patch
Tentative patch.
For hello.c, for the -gas-loc-support case it gives us:
...
$ gcc -g ~/hello.
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
The prologue_end marker (introduced in dwarf v3) is currently not emitted by
gcc.
This is the case for -gno-as-loc-support (gcc emitting .debug_line
contribution).
And for -gas-loc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108098
--- Comment #1 from Tom de Vries ---
(In reply to Thomas Schwinge from comment #0)
> $ nvidia-smi
> [...]
> | NVIDIA-SMI 440.33.01Driver Version: 440.33.01CUDA Version: 10.2
> [...]
> | 0 Tesla K80 [...]
> [..
: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider test-case vla-optimized-out.c:
...
int
__attribute__((noinline,weak)) __attribute__((noclone))
f1 (int i)
{
char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87741
Tom de Vries changed:
What|Removed |Added
CC||vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99555
--- Comment #17 from Tom de Vries ---
(In reply to Thomas Schwinge from comment #14)
> > That's with a Nvidia Tesla K20c GPU, Driver Version: 346.46.
> > As that version is "a bit old", I shall first update this, before we spend
> > any further t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105772
--- Comment #2 from Tom de Vries ---
As background info, I'm proposing a patch for gdb to have the
architecture-specific prologue skipper skip over the get_pc_thunk call:
https://sourceware.org/pipermail/gdb-patches/2022-May/189563.html , which
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider the test-case source gdb/testsuite/gdb.base/break1.c (
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104893
Tom de Vries changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104857
Tom de Vries changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104714
Tom de Vries changed:
What|Removed |Added
Target Milestone|--- |12.0
Resolution|---
: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
In common.opt, we read:
...
-target-help
Common Driver
Alias for --help=target.
...
But that doesn't seem to be correct, I get different results.
For instance, for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
Tom de Vries changed:
What|Removed |Added
CC||vries at gcc dot gnu.org
--- Comment #43
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81909
Tom de Vries changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81728
Tom de Vries changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104818
Tom de Vries changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105042
Tom de Vries changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #8 from Tom de V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105075
--- Comment #6 from Tom de Vries ---
Created attachment 52698
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52698&action=edit
Demonstrator patch with stepping stone patterns for combine
(In reply to Tom de Vries from comment #2)
> Also,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105014
--- Comment #6 from Tom de Vries ---
Reproducer filed at https://github.com/vries/nvidia-bugs/tree/master/shift-and
PR filed at nvidia ( https://developer.nvidia.com/nvidia_bug/3585290 ).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105075
Tom de Vries changed:
What|Removed |Added
Attachment #52693|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105075
--- Comment #2 from Tom de Vries ---
AFAIU, at gimple level support is limited to vectors, so that doesn't help to
generate the insn for the simple, scalar case.
It would be nice if combine could generate it and we wouldn't have to use a
peepho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105075
--- Comment #1 from Tom de Vries ---
Created attachment 52693
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52693&action=edit
Demonstrator patch
This patch adds:
- modeling of insn sad.u32 in the .md file
- peephole2 to generate it
(wh
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
ptx has sad ((sum of absolute differences)) insn, which is currently not
modeled in the .md file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105042
--- Comment #5 from Tom de Vries ---
(In reply to Richard Biener from comment #1)
> Doesn't whatever driver/library API we use from libgomp to invoke workloads
> report actual errors? Maybe we need to improve there.
This:
...
libgomp: cuStream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105042
--- Comment #4 from Tom de Vries ---
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/592275.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105042
--- Comment #3 from Tom de Vries ---
(In reply to Tom de Vries from comment #2)
> (In reply to Richard Biener from comment #1)
> > Doesn't whatever driver/library API we use from libgomp to invoke workloads
> > report actual errors? Maybe we ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105014
--- Comment #5 from Tom de Vries ---
Minimal test-case:
...
void __attribute__((noinline)) foo (unsigned long long d0) {
unsigned long long __a;
__a = 0x38;
for (; __a > 0; __a -= 8)
if (((d0 >> __a) & 0xff) != 0)
break;
__bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105011
Tom de Vries changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105042
--- Comment #2 from Tom de Vries ---
(In reply to Richard Biener from comment #1)
> Doesn't whatever driver/library API we use from libgomp to invoke workloads
> report actual errors? Maybe we need to improve there.
Good point, it reported som
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105014
--- Comment #4 from Tom de Vries ---
(In reply to Tom de Vries from comment #1)
> With -O0 JIT instead:
Also OK with JIT -O1, problems start at JIT -O2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105011
--- Comment #3 from Tom de Vries ---
Submitted fix :
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/592211.html
Though without changelog, apparently.
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: ---
I usually have only an nvidia-compute$n driver package installed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105019
--- Comment #6 from Tom de Vries ---
(In reply to Tom de Vries from comment #4)
> OK, I think this is the pattern:
> ...
> $ cat gcc/testsuite/gcc.target/nvptx/alias-5.c
FTR, same thing if I use static functions:
...
static void __attribute__((
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105019
--- Comment #5 from Tom de Vries ---
Creating a CUDA example is hampered by the fact that there's no symbol alias
support, AFAICT.
I'd like to write something like:
...
__device__ void __foo ()
{
printf ("__foo\n");
}
__device__ void foo () _
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105019
--- Comment #4 from Tom de Vries ---
OK, I think this is the pattern:
...
$ cat gcc/testsuite/gcc.target/nvptx/alias-5.c
/* { dg-do link } */
/* { dg-do run { target runtime_ptx_isa_version_6_3 } } */
/* { dg-options "-save-temps -malias -mptx=6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105019
--- Comment #3 from Tom de Vries ---
Aliases in failing .exe:
...
$ strings declare_target-1.exe | grep "\.alias"
.alias gomp_ialias_GOMP_taskgroup_start,GOMP_taskgroup_start;
.alias gomp_ialias_GOMP_taskgroup_end,GOMP_taskgroup_end;
.alias
gomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105019
--- Comment #2 from Tom de Vries ---
Aliases in libgomp.a:
...
$ grep "\.alias"
build-gcc-offload-nvptx-none/nvptx-none/mgomp/libgomp/.libs/libgomp.a
.alias gomp_ialias_GOMP_loop_runtime_next,GOMP_loop_runtime_next;
.alias gomp_ialias_GOMP_loop_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105019
--- Comment #1 from Tom de Vries ---
To trigger:
...
diff --git a/gcc/config/nvptx/nvptx.cc b/gcc/config/nvptx/nvptx.cc
index 87efc23bd96..8bf9ea90a77 100644
--- a/gcc/config/nvptx/nvptx.cc
+++ b/gcc/config/nvptx/nvptx.cc
@@ -245,6 +245,9 @@ def
NCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
As mentioned in the commit message for malias:
...
When enabling malias by default, libgomp detects ali
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105014
--- Comment #3 from Tom de Vries ---
(In reply to Tom de Vries from comment #2)
> (In reply to Tom de Vries from comment #0)
> > On a quadro k2000 with driver 470.103.01, I run into:
>
> So, sm_30.
>
> > ...
> > FAIL: gcc.dg/pr97459-1.c execut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105014
--- Comment #2 from Tom de Vries ---
(In reply to Tom de Vries from comment #0)
> On a quadro k2000 with driver 470.103.01, I run into:
So, sm_30.
> ...
> FAIL: gcc.dg/pr97459-1.c execution test
Reproduced on geforce gt710 (sm_35), with same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105018
--- Comment #2 from Tom de Vries ---
As mentioned before by amonakov, a possibility is to add alias support to the
nvptx-tools linker, and use that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105018
--- Comment #1 from Tom de Vries ---
(In reply to Tom de Vries from comment #0)
> Aliases to aliases are not supported (see libgomp.c-c++-common/pr96390.c).
> This is currently not prohibited by the compiler, but with the driver link we
> run in
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
We currently have alias support enabled by malias, which relies on the ptx
.alias directive.
There is a number of limitations, listed in the commit adding malias:
...
Only function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97106
Tom de Vries changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97106
Bug 97106 depends on bug 97102, which changed state.
Bug 97102 Summary: [nvptx] PTX JIT compilation failed when using aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97102
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97102
Tom de Vries changed:
What|Removed |Added
Target Milestone|--- |12.0
Resolution|---
||missed-optimization
CC||vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104916
Tom de Vries changed:
What|Removed |Added
Target Milestone|--- |12.0
1 - 100 of 1046 matches
Mail list logo
