https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104440
Bug ID: 104440
Summary: nvptx: FAIL: gcc.c-torture/execute/pr53465.c
execution test
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104440
Tom de Vries changed:
What|Removed |Added
Target||nvptx
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103641
--- Comment #32 from Tamar Christina ---
>
> I suppose the slowness is still entirely within synth_mult?
I'm not sure... I can't seem to get the same granularity level that Andrew
got... How did you get that report Andrew?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104440
--- Comment #2 from Andrew Pinski ---
I thought there was another bug that reported a similar issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104440
--- Comment #3 from Andrew Pinski ---
>Unfortunately, pass_initialize_regs does not insert the required init.
There is some ideas of getting rid of pass_initialize_regs for GCC 13 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103641
--- Comment #33 from Andrew Pinski ---
(In reply to Tamar Christina from comment #32)
> I'm not sure... I can't seem to get the same granularity level that Andrew
> got... How did you get that report Andrew?
I was using perf record/perf report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103641
--- Comment #34 from Tamar Christina ---
(In reply to Andrew Pinski from comment #33)
> (In reply to Tamar Christina from comment #32)
> > I'm not sure... I can't seem to get the same granularity level that Andrew
> > got... How did you get that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104440
--- Comment #4 from Tom de Vries ---
(In reply to Andrew Pinski from comment #2)
> I thought there was another bug that reported a similar issue.
You mean related to nvptx, or in general?
FWIW, I do remember looking at this issue before in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104440
--- Comment #5 from Andrew Pinski ---
(In reply to Tom de Vries from comment #4)
> (In reply to Andrew Pinski from comment #2)
> > I thought there was another bug that reported a similar issue.
>
> You mean related to nvptx, or in general?
It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104385
--- Comment #8 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:0af7ef050aed9f678d70d79931ede38374fde863
commit r12-7091-g0af7ef050aed9f678d70d79931ede38374fde863
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104153
Stafford Horne changed:
What|Removed |Added
CC||shorne at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104153
--- Comment #9 from Stafford Horne ---
Note, I said glibc but of course error I listed was when compiling gcc during
glibc toolchain building.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104416
--- Comment #1 from Richard Biener ---
Quite probably -Wl,... are in both compiler and linker opts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104420
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2022-02-08
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104426
--- Comment #5 from Richard Biener ---
(In reply to Jakub Jelinek from comment #3)
> That's a consequence of -fsanitize=undefined turning on
> -fno-delete-null-pointer-checks (it has to, otherwise -fsanitize=null
> wouldn't work properly).
> And
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104364
--- Comment #7 from CVS Commits ---
The master branch has been updated by Tom de Vries :
https://gcc.gnu.org/g:04b54cc486cc6fcc40380445e500eaf46d7901dc
commit r12-7092-g04b54cc486cc6fcc40380445e500eaf46d7901dc
Author: Tom de Vries
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104427
Richard Biener changed:
What|Removed |Added
CC||mkretz at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104428
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104429
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104430
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97006
Tom de Vries changed:
What|Removed |Added
Target Milestone|--- |12.0
Component|target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104364
Tom de Vries changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104436
--- Comment #2 from Richard Biener ---
DECL_BY_REFERENCE on the PARM_DECL tells you that indeed (not on the fndecl).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104438
Richard Biener changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84568
--- Comment #4 from Andreas Schwab ---
Not having inline atomics already breaks so many things.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104427
--- Comment #4 from Matthias Kretz (Vir) ---
I can certainly take a look, but so far my GCC internals experience ends with
the C++ front-end. This ICEs in the pass where front-end trees are transformed
into GIMPLE, right? So it would be a pass t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104440
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2022-02-08
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104440
--- Comment #7 from Richard Biener ---
(In reply to Richard Biener from comment #6)
> (In reply to Andrew Pinski from comment #5)
> > (In reply to Tom de Vries from comment #4)
> > > (In reply to Andrew Pinski from comment #2)
> > > > I thought
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104427
Richard Biener changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104438
--- Comment #2 from rsandifo at gcc dot gnu.org
---
fwprop should at least stand a chance of working that late.
Was wondering whether reinitialising the loop info would be
a problem, but we already do that later (when computing
alignments).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104437
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2022-02-08
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104437
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97202
Jonathan Wakely changed:
What|Removed |Added
CC||jengelh at inai dot de
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97202
--- Comment #8 from Jonathan Wakely ---
PR 104437 pointed out that the invalid constructor is accepted if it has a
redundant inline specifier:
template struct S : Base {
inline S() {}
};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84568
Jonathan Wakely changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104422
--- Comment #2 from Tom de Vries ---
Hmm, I reran on a(In reply to Tom de Vries from comment #0)
> #pragma distribute simd
omp missing ... I need to reproduce this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84568
--- Comment #6 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to palmer from comment #3)
> > It looks like LLVM already has inline atomics, so presumably the same issues
> > would arise when mixing libstdc++ li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84568
--- Comment #7 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to Jonathan Wakely from comment #5)
> > (In reply to palmer from comment #3)
> > > It looks like LLVM already has inline atomics, so presumably the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87846
--- Comment #5 from Jonathan Wakely ---
N.B. the experimental::filesystem::create_directories function still has this
problem on Windows, but the TS support on Windows is minimal anyway. I'm not
going to fix it at this time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104426
--- Comment #6 from Jakub Jelinek ---
Created attachment 52369
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52369&action=edit
gcc12-pr104426.patch
Untested fix.
This stops the implied setting of -fno-delete-null-pointer-checks for
sanit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84568
--- Comment #8 from Andreas Schwab ---
It's #undef in 11.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104345
--- Comment #4 from Thomas Schwinge ---
Created attachment 52370
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52370&action=edit
'_muldc3-good.o'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104345
--- Comment #5 from Thomas Schwinge ---
Created attachment 52371
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52371&action=edit
'_muldc3-bad.o'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104345
--- Comment #6 from Thomas Schwinge ---
Created attachment 52372
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52372&action=edit
'_muldc3-WIP.o'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104345
--- Comment #7 from Thomas Schwinge ---
All your three patches combined still doesn't help resolve the problem.
And, what I realized: they don't even change the Nvidia/CUDA Driver reported
"used [...] registers".
Does that mean that the Driver "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104427
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104423
--- Comment #1 from Tom de Vries ---
One of the dimensions that I test is env var GOMP_NVPTX_JIT, with values:
- -O0, and
- default (using unset GOMP_NVPTX_JIT), which supposedly is -O4.
Looking at f.i. test-case for-3.c, compilation takes 3 mi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104345
--- Comment #8 from Thomas Schwinge ---
Well. Here's another problem.
Re-testing things using a "bad" '__muldc3' from a build with your three patches
applied, I notice that my '_muldc3-WIP.o' "old"/replacement code uses a
'set.u32.leu.f64', 'n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104422
--- Comment #3 from Tom de Vries ---
(In reply to Tom de Vries from comment #0)
> While testing libgomp using legacy driver 390.x on a maxwell card, Quadro
> K620 I ran into a for-3.exe execution failure.
Reproduced with 390.147 driver on pasca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87846
--- Comment #6 from Jonathan Wakely ---
Actually no, it's fine, the relevant test fails because exists("foo/") fails,
due to PR 1, and *that* isn't fixed for the experimental TS.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84568
--- Comment #9 from Jonathan Wakely ---
Thanks. Changing that will cause an ABI break in the headers (and so affect
user code, not just the libstdc++.so library).
Clang and GCC will still be compatible, because the macros are still set once
by c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104283
--- Comment #1 from CVS Commits ---
The master branch has been updated by Tom de Vries :
https://gcc.gnu.org/g:decde11183bdccc46587d6614b75f3d56a2f2e4a
commit r12-7098-gdecde11183bdccc46587d6614b75f3d56a2f2e4a
Author: Tom de Vries
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104283
Tom de Vries changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102140
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101929
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104161
--- Comment #8 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:5750952bec1e632d1f804f4a1bed2f74c0f3b189
commit r12-7099-g5750952bec1e632d1f804f4a1bed2f74c0f3b189
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103706
--- Comment #6 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:34ba3d9a2bf72742b1c150a2dd17d10e3e3f0964
commit r12-7101-g34ba3d9a2bf72742b1c150a2dd17d10e3e3f0964
Author: Patrick Palka
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103706
--- Comment #7 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:db5f1c17031ad8a898d77121f1e0e0141306e22a
commit r12-7102-gdb5f1c17031ad8a898d77121f1e0e0141306e22a
Author: Patrick Palka
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103706
Patrick Palka changed:
What|Removed |Added
Summary|[11/12 Regression] ICE: |[11 Regression] ICE: tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103706
Patrick Palka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104441
Bug ID: 104441
Summary: [12 Regression] vzeroupper is placed at the wrong
place
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104319
--- Comment #11 from Jakub Jelinek ---
Patch has been posted:
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/589875.html
and deferred for gcc 13.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104441
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |12.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104410
--- Comment #4 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:7ff201d85fad11ba6365a5612124b75b385a97bd
commit r12-7103-g7ff201d85fad11ba6365a5612124b75b385a97bd
Author: Patrick Palka
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80951
--- Comment #1 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:676e987b850a7352ece750a8f3a1ac5dae6b3627
commit r12-7104-g676e987b850a7352ece750a8f3a1ac5dae6b3627
Author: Patrick Palka
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80951
Patrick Palka changed:
What|Removed |Added
Target Milestone|--- |12.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104410
Patrick Palka changed:
What|Removed |Added
Summary|[11/12 Regression] Internal |[11 Regression] Internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
Thomas Schwinge changed:
What|Removed |Added
CC||vries at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104423
Thomas Schwinge changed:
What|Removed |Added
CC||tschwinge at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104441
--- Comment #1 from H.J. Lu ---
ix86_check_avx_upper_register doesn't check
(vec_select:V2DI (reg/v:V4DI 23 xmm3 [orig:91 ymm ] [91])
(parallel [
(const_int 2 [0x2])
(const_int 3 [0x3])
]))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104438
--- Comment #3 from Segher Boessenkool ---
Also combine could work that late in principle: it can deal with hard
registers, after all. But it would be a terrible idea. A single combine
pass is expensive enough, we don't want to run it N times.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104423
--- Comment #3 from Tom de Vries ---
(In reply to Thomas Schwinge from comment #2)
> For OpenMP test cases, we'd either have to manually mark them up (error
> prone and generally ugly), or scan the source file(s) (error prone and
> generally ugl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104425
--- Comment #2 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:be862bf1f612c884597ace4cbfdec972a0bf0eef
commit r12-7109-gbe862bf1f612c884597ace4cbfdec972a0bf0eef
Author: Patrick Palka
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104425
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
Resol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104411
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
Resol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95069
Patrick Palka changed:
What|Removed |Added
CC||oliver.rosten at googlemail
dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104288
--- Comment #10 from CVS Commits ---
The releases/gcc-11 branch has been updated by Andrew Macleod
:
https://gcc.gnu.org/g:ed35d4205e8c139d27d3d47c528aaa9f82f0ac1b
commit r11-9543-ged35d4205e8c139d27d3d47c528aaa9f82f0ac1b
Author: Andrew MacLeo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104345
--- Comment #9 from Thomas Schwinge ---
OK! Putting your "nvptx: Add support for 64-bit mul.hi (and other)
instructions" on top, that considerably changes (simplifies!) the generated
'__muldc3' PTX code; the regression disappears. :-)
(I have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904
--- Comment #8 from Hannes Hauswedell ---
Hi, I wanted to ask politely whether you have discussed this issue and came to
a conclusion?
It if it is still being discussed, can you at least "confirm" this issue and
put it on some list for the next
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104441
--- Comment #2 from H.J. Lu ---
Created attachment 52376
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52376&action=edit
A patch
I am testing this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104422
--- Comment #4 from Tom de Vries ---
(In reply to Tom de Vries from comment #3)
> Reproduces both with and without GOMP_NVPTX_JIT=-O0.
Pff, that was an artefact of having bumped the default ptx isa to 6.3.
So, let's try again ...
Reproduced w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904
--- Comment #9 from Jonathan Wakely ---
(In reply to Hannes Hauswedell from comment #8)
> Hi, I wanted to ask politely whether you have discussed this issue and came
> to a conclusion?
No, because the current priority is gcc 12.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104442
Bug ID: 104442
Summary: atomic::wait incorrectly loops in case of spurious
notification when __waiter is shared
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103147
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290
--- Comment #3 from Svante Signell ---
With the proposed patches everything builds fine. The only issue to resolve is
how to make sure libatomic and libbacktrace builds in build/i686-gnu before
libgo/gotools.
Any ideas? I'm not sure if this is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290
--- Comment #4 from Andreas Schwab ---
Makefile.def already has the required dependencies:
dependencies = { module=all-target-libgo; on=all-target-libbacktrace; };
dependencies = { module=all-target-libgo; on=all-target-libffi; };
dependencies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104410
--- Comment #6 from CVS Commits ---
The releases/gcc-11 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:411db3b4cf8655ecb5b7d666318546c73f2d156b
commit r11-9544-g411db3b4cf8655ecb5b7d666318546c73f2d156b
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104443
Bug ID: 104443
Summary: common_iterator::operator-> is not correctly
implemented
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104443
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290
--- Comment #5 from Ian Lance Taylor ---
> The only issue to resolve is how to make sure libatomic and libbacktrace
> builds in build/i686-gnu before libgo/gotools.
That question doesn't sound right. The gotools are built for the target. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104410
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100354
--- Comment #6 from Jakub Jelinek ---
In this particular case it is:
(note 38 19 20 (var_location p (unspec:DI [
(const_int 0 [0])
] UNSPEC_TLS)) NOTE_INSN_VAR_LOCATION)
where p's value should be equal to that __builtin_thread_pointe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84568
--- Comment #10 from palmer at gcc dot gnu.org ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to Jonathan Wakely from comment #6)
> > (In reply to Jonathan Wakely from comment #5)
> > > (In reply to palmer from comment #3)
> > > > I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100354
Jakub Jelinek changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104418
--- Comment #7 from Fedor Chelnokov ---
Thanks. I submitted Clang bug:
https://github.com/llvm/llvm-project/issues/53653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104285
--- Comment #1 from Ye Luo ---
Here is a minimal reproducer.
https://github.com/ye-luo/openmp-target/tree/master/tests/linking/two_identical_templates
$ g++ -fopenmp -foffload=nvptx-none -O3 -c test_a.cpp
$ g++ -fopenmp -foffload=nvptx-none -c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102140
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:0c3e491a4e5ae74bfbed6d167d403d262b5a4adc
commit r12-7111-g0c3e491a4e5ae74bfbed6d167d403d262b5a4adc
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104403
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:1755141a9ea0dddabb52776cddc4c9325eed27c6
commit r12-7112-g1755141a9ea0dddabb52776cddc4c9325eed27c6
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102140
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
1 - 100 of 177 matches
Mail list logo
