https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51663
Tom de Vries changed:
What|Removed |Added
CC||vries at gcc dot gnu.org
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51663
--- Comment #13 from Tom de Vries ---
(In reply to Richard Biener from comment #12)
> (In reply to Tom de Vries from comment #11)
> > Cross-referencing PR gdb/25684 - "gdb testing with gcc -flto" (
> > https://sourceware.org/bugzilla/show_bug.cgi
: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider the following test-case (minimized from
gdb/testsuite/gdb.threads/step-bg-decr-pc-switch-thread.c):
...
$ cat -n test.c
1 int i;
2
3 int
4 main
: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider test-case test.c:
...
int aaa;
int
main (void)
{
return aaa;
}
...
Compiled with -flto:
...
$ gcc-10 -O0 test.c -g -flto -flto-partition=none -ffat-lto-objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94450
--- Comment #5 from Tom de Vries ---
(In reply to Richard Biener from comment #1)
> I guess the more correct DWARF would be to have the 13d DIE include
> DW_AT_declaration?
Well, currently the debug info contains two concrete symbols, one with a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94450
--- Comment #8 from Tom de Vries ---
(In reply to Richard Biener from comment #7)
> The DW_TAG_imported_unit are now gone for GCC 10. So can we consider this
> fixed?
I'd like a PR to refer to at the to-be-added xfail in the gdb test-case (and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94450
--- Comment #10 from Tom de Vries ---
(In reply to rguent...@suse.de from comment #9)
> On Fri, 3 Apr 2020, vries at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94450
> >
> > --- Comm
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider gdb testsuite test-case gdb.ada/call_pn (
https://sourceware.org/git/?p=binutils-gdb.git;a=tree;f=gdb/testsuite/gdb.ada/call_pn;hb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94450
--- Comment #12 from Tom de Vries ---
(In reply to Tom de Vries from comment #10)
> I'll file the actual ada example.
PR94469 - "lto abstract variable emitted as concrete decl (ada test-case)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94450
Tom de Vries changed:
What|Removed |Added
CC||tromey at gcc dot gnu.org
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94469
--- Comment #2 from Tom de Vries ---
(In reply to Richard Biener from comment #1)
> Do you know under which circumstances gdb asks which symbol to print?
> Because
> I've never seen this for C or C++ and it should be present for _all_ global
> v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94469
--- Comment #4 from Tom de Vries ---
(In reply to Tom de Vries from comment #2)
(In reply to Richard Biener from comment #3)
> Ah, thanks for the hints - that's something I can work with more easily than
> an Ada testcase ;)
Sure :)
FWIW, the g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94469
--- Comment #5 from Tom de Vries ---
(In reply to Tom de Vries from comment #4)
> (In reply to Tom de Vries from comment #2)
> (In reply to Richard Biener from comment #3)
> $ gdb -readnow -batch a.out -ex "p aaa" -ex "p bbb" -ex "p ccc"
> $1 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94469
--- Comment #8 from Tom de Vries ---
(In reply to Richard Biener from comment #7)
> (In reply to Richard Biener from comment #6)
> > Btw, I still wonder how it works with abstract functions, inline and
> > concrete instances. Works in gdb, that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94469
--- Comment #11 from Tom de Vries ---
(In reply to Richard Biener from comment #9)
> (In reply to Tom de Vries from comment #8)
> > (In reply to Richard Biener from comment #7)
> > > (In reply to Richard Biener from comment #6)
> > > > Btw, I sti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94469
--- Comment #13 from Tom de Vries ---
(In reply to rguent...@suse.de from comment #12)
> > Ack, I've managed to reproduce this using a dwarf assembly test-case (PR
> > gdb/25796 - "Symbol with inherited DW_AT_const_value not found" @
> > https://
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94469
--- Comment #15 from Tom de Vries ---
(In reply to Tom de Vries from comment #8)
> > So while I intended to have the early CUs behave like fully abstract
> > the actual DWARF is different. I understand that if I emit the early CU as
> > partial
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94469
--- Comment #16 from Tom de Vries ---
(In reply to Richard Biener from comment #14)
> Using DW_AT_declaration for variables and CUs instead of PUs is IMHO the
> most promising approach then.
I managed to reproduce the "Multiple matches" problem
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider test-case gdb/testsuite/gdb.base/constvars.c (
https://sourceware.org/git/?p=binutils-gdb.git;a=blob_plain;f=gdb/testsuite/gdb.base/constvars.c;hb=HEAD
).
Compiled with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94847
--- Comment #1 from Tom de Vries ---
Created attachment 48407
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48407&action=edit
Test case
: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider the test-case consisting of gdb.cp/derivation.cc and
gdb.cp/derivation2.cc (
https://sourceware.org/git/?p=binutils-gdb.git;a=blob_plain;f=gdb/testsuite/gdb.cp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94875
--- Comment #1 from Tom de Vries ---
Minimal example:
...
$ cat derivation.cc
class A {
public:
A() {}
int afoo() { return 1; }
};
A a_instance;
int
main (void)
{
return 0;
}
...
compiled as:
...
$ g++ derivation.cc -g -fdebug-types-se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94847
--- Comment #2 from Tom de Vries ---
Minimal test-case:
...
$ cat constvars.c
int
main (void)
{
const char laconic = 'A';
volatile char vox = 'X';
const volatile char victor = 'Y';
return 0;
}
...
Compiled like this:
...
$ gcc -g constv
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider this test-case, minimized from gdb testsuite test-case py-methods.cc:
...
$ cat py-xmethods.cc
template
class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95360
--- Comment #3 from Tom de Vries ---
(In reply to Yibiao Yang from comment #0)
> Breakpoint 1, main () at small.c:5
> 5 for (; d<1; d++)
> (gdb) stepi
> 0x004011545 for (; d<1; d++)
> (gdb) stepi
> 0x0040115a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95360
--- Comment #4 from Tom de Vries ---
I compiled the test-case:
...
$ gcc-10 -O0 -g small.c
...
And did the stepi scenario:
...
$ gdb a.out -batch -ex start $(for n in $(seq 1 7); do echo -ex si; done)
Temporary breakpoint 1 at 0x400496: file sma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95360
--- Comment #7 from Tom de Vries ---
(In reply to Tom de Vries from comment #4)
> So, it seems gdb ignores the "recommended breakpoint location" at 0x4004cb,
> because there's an earlier one on the same line at 0x4004bc.
>
> The gdb approach is
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
When doing a build from current trunk, I get the following in the .debug_line
section of build/x86_64-pc-linux-gnu/libgcc/libgcc_s.so.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95574
Tom de Vries changed:
What|Removed |Added
Keywords||wrong-debug
--- Comment #1 from Tom de Vr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95574
--- Comment #2 from Tom de Vries ---
Created attachment 48702
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48702&action=edit
_absvsi2_s.c
To reproduce:
...
$ gcc -O2 -g -fpic -mlong-double-80 -fcf-protection -mshstk -fbuilding-libgcc
-fn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95574
--- Comment #3 from Tom de Vries ---
Gdb currently silently ignores the offending entry.
I've filed a gdb PR, PR26092 - "Complain about contradictory
DW_LNE_end_sequence marker" to complain about this (
https://sourceware.org/bugzilla/show_bug.c
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Current GCC contains this workaround in bb-reorder.c:
...
/* Workaround a bug in GDB where read_partial_die doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81155
Tom de Vries changed:
What|Removed |Added
CC||vries at gcc dot gnu.org
--- Comment #14
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Currently, we're at ptx isa v3.1:
...
static void
nvptx_file_start (void)
{
fputs ("// BEGIN PREAMBLE\n", asm_out_file);
fputs ("\t.version\t3.1\n", as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90932
Tom de Vries changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90932
Tom de Vries changed:
What|Removed |Added
Target Milestone|--- |11.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95574
--- Comment #4 from Tom de Vries ---
(In reply to Tom de Vries from comment #2)
> Created attachment 48702 [details]
> _absvsi2_s.c
>
> To reproduce:
> ...
> $ gcc -O2 -g -fpic -mlong-double-80 -fcf-protection -mshstk
> -fbuilding-libgcc -fno-st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95574
--- Comment #5 from Tom de Vries ---
This seems to be var-track related.
Before var-track we have:
...
(debug_insn 23 41 24 5 (debug_marker) "test2.c":12:5 -1
(nil))
(call_insn 24 23 25 5 (call (mem:QI (symbol_ref:DI ("abort") [flags 0x41]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95574
--- Comment #6 from Tom de Vries ---
A simple way of fixing this is:
...
diff --git a/gcc/var-tracking.c b/gcc/var-tracking.c
index 899a5c0290d..4b143f6702b 100644
--- a/gcc/var-tracking.c
+++ b/gcc/var-tracking.c
@@ -6635,7 +6635,7 @@ add_with_s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95574
--- Comment #7 from Tom de Vries ---
A bit more subtle:
...
diff --git a/gcc/var-tracking.c b/gcc/var-tracking.c
index 899a5c0290d..f94eb38f797 100644
--- a/gcc/var-tracking.c
+++ b/gcc/var-tracking.c
@@ -8880,6 +8880,10 @@ emit_note_insn_var_loc
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider test-case tui-winsource.c (minimized from gdb sources, filed as gdb PR
https://sourceware.org/bugzilla
[-Wstringop-truncation]
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
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=35488
Tom de Vries changed:
What|Removed |Added
CC||vries at gcc dot gnu.org
--- Comment #11
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Floating-point ops like f.i. div:
...
(define_insn "div3"
[(set (match_operand:SDFM 0 "nvptx_register_operand" "=R")
(div:SDFM (match_operand:SDFM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90928
--- Comment #4 from Tom de Vries ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550140.html
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider test-case test.c:
...
void
foo (void)
{
volatile unsigned int v;
volatile unsigned short v2;
v2 = v;
}
...
With the current compiler, we have:
...
$ gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96401
--- Comment #1 from Tom de Vries ---
(In reply to Tom de Vries from comment #0)
> In other words, we may emit instead:
> ...
> .reg.u32 %r22;
> ld.u32 %r22, [%frame];
> st.u16 [%frame+4], %r22;
> ...
So,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96401
--- Comment #2 from Tom de Vries ---
(In reply to Tom de Vries from comment #1)
> Using these changes, I get the desired:
> ...
> .reg.u32 %r22;
> ld.u32 %r22, [%frame];
> st.u16 [%frame+4], %r22;
> ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96401
--- Comment #3 from Tom de Vries ---
Note that with the proposed TARGET_TRULY_NOOP_TRUNCATION -> false change (
https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549896.html ), we start out
with the same ptx insns, but with the cvt.u16.u32 a tr
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
[ I've rewritten the v2si-cvt.c source to something more minimal:
...
__v2si __attribute__((u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96403
Tom de Vries changed:
What|Removed |Added
Target||nvptx
--- Comment #1 from Tom de Vries -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96428
--- Comment #1 from Tom de Vries ---
Tentative patch:
...
diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index d8a8fb2d55b..cf53a921e5b 100644
--- a/gcc/config/nvptx/nvptx.c
+++ b/gcc/config/nvptx/nvptx.c
@@ -1796,6 +1796,44 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96428
--- Comment #2 from Tom de Vries ---
(In reply to Tobias Burnus from comment #0)
> Created attachment 48986 [details]
> Test case (Fortran, use 'gfortran -fopenacc" with nvptx offloading)
>
With the test-case setup like this:
...
! { dg-do link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96428
--- Comment #4 from Tom de Vries ---
FTR, this is not the leanest solution.
This patch generates:
...
cvt.u64.u64 %r74, %r65.x;
cvt.u64.u64 %r75, %r65.y;
mov.b64 {%r76,%r77}, %r74;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96428
Tom de Vries changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
The effective target sync_int_long currently doesn't include nvptx.
Consequently, when running gcc.dg/ia64-sync-*.c, we get "UNSUPPORTED".
If
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
I noticed that we emit:
...
set.u32.eq.u64 %r31,%r26,2147483648;
...
But the ptx isa specifies:
...
set.CmpOp{.ftz}.dtype.stype d, a, b;
...
so we should emit instead:
...
set.eq.u32
++
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider test-case test.c:
...
#include
#include
class A {
public:
A (int a) { i = a; }
int i;
};
int main (void) {
std::unordered_map> m;
m.emplace (1, new A(1));
retur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96537
Tom de Vries changed:
What|Removed |Added
Known to work||7.5.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96537
--- Comment #4 from Tom de Vries ---
(In reply to Jonathan Wakely from comment #2)
> Not a bug. C++11 and C++14 said for the relevant pair(U&&, V&&) constructor:
>
> Remarks: If U is not implicitly convertible to first_type or V is not
> implici
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96494
--- Comment #1 from Tom de Vries ---
(In reply to Tom de Vries from comment #0)
> AFAICT, from the point of view of the PTX isa, there's no reason why we
> couldn't support this.
>
> So, unless a testsuite run points to some problem, we should e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96494
--- Comment #2 from Tom de Vries ---
FTR, we could fix this by just mapping onto a nonatomic insn for .local (and
I'm not really sure why ptx doesn't).
But since we have generic pointers, we only known runtime whether something is
local (using i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83812
--- Comment #1 from Tom de Vries ---
See PR 96494.
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
When running test-case gcc.dg/builtin-object-size-21.c, we have:
...
spawn -ignore SIGHUP /home/vries/nvptx/mainkernel-2/build-gcc/gcc/xgcc
-B/home/vries/nvptx/mainkernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96566
--- Comment #1 from Tom de Vries ---
Corresponding source bit:
...
struct Ax_m3 { char a[PTRDIFF_MAX - 3], ax[]; };
struct Ax_m3 xm3_3 = { { 0 }, { 1, 2, 3 } };
On x86_64, we generate for this:
...
xm3_3:
.byte 0
.zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96566
--- Comment #2 from Tom de Vries ---
(In reply to Tom de Vries from comment #0)
> If we run the command by hand, and tail the .s file, we get an endless
> repetition of 0, 0, 0, ... , which starts off like this:
> ...
> // BEGIN GLOBAL VAR DEF: x
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. */
type
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 too
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 tr
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 #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,
> adding
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 directive
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 #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 don't
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 for that
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 t
: 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 #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,
> adding
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=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=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
--- a/gcc/testsuite/gcc.dg/builtin-object-s
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=90928
Tom de Vries changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
/home/vries/nvptx/mainkernel-2/s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96494
Tom de Vries changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
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=96706
Tom de Vries changed:
What|Removed |Added
Target||nvptx
--- Comment #1 from Tom de Vries -
: 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
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&action=edit
fibheap.c, prepr
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.
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 fr
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
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 be
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 believe
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&quo
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
--- a/gcc/co
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&action=edit
Tentative patch
Introduces an option -fatomic-libcalls (analogous to -fsync-libcalls) such that
__atomic_test_an
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 ma
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
1 - 100 of 3236 matches
Mail list logo
