https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100240
--- Comment #4 from Peter Taraba ---
Actually this works:
nvcc -o dt ./DeeperThought/*.cu -save-temps
But files it creates even if zipped are above 1MB (which is not allowed to be
attached).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99683
--- Comment #3 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:bcd77b7b9f35bd5b559ed593c3b3e346c1e6f364
commit r12-100-gbcd77b7b9f35bd5b559ed593c3b3e346c1e6f364
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99200
--- Comment #7 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:bcd77b7b9f35bd5b559ed593c3b3e346c1e6f364
commit r12-100-gbcd77b7b9f35bd5b559ed593c3b3e346c1e6f364
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93383
--- Comment #13 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:bcd77b7b9f35bd5b559ed593c3b3e346c1e6f364
commit r12-100-gbcd77b7b9f35bd5b559ed593c3b3e346c1e6f364
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95291
--- Comment #8 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:bcd77b7b9f35bd5b559ed593c3b3e346c1e6f364
commit r12-100-gbcd77b7b9f35bd5b559ed593c3b3e346c1e6f364
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89565
--- Comment #5 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:bcd77b7b9f35bd5b559ed593c3b3e346c1e6f364
commit r12-100-gbcd77b7b9f35bd5b559ed593c3b3e346c1e6f364
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87709
--- Comment #10 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:5f1a2cb9c2dc09eed53da5d5787d14bec700b10b
commit r12-99-g5f1a2cb9c2dc09eed53da5d5787d14bec700b10b
Author: Patrick Palka
Date:
On 4/23/2021 6:54 PM, David Edelsohn via Gcc-patches wrote:
Some ports require libatomic for atomic operations, at least for some
data types and widths. The libstdc++ testsuite previously was updated
to link against libatomic, but the search path was hard-coded to
something that is not always
On 4/19/2021 1:28 PM, Richard Sandiford via Gcc-patches wrote:
This patch adds target selectors of the form:
{ any-opts "opt1" ... "optn" }
{ no-opts "opt1" ... "optn" }
for skipping or xfailing tests based on compiler options. It only
works for dg-final selectors.
The patch then
On 4/23/21 8:31 AM, Jakub Jelinek via Gcc wrote:
Some blocker bugs were reported against the first release candidate
of GCC 11.1, so there is a second release candidate for GCC 11.1
available from
https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210423/
ftp://gcc.gnu.org/pub/gcc/snapshots
On 4/14/2021 12:41 AM, Richard Biener wrote:
On Wed, 14 Apr 2021, Xionghu Luo wrote:
Hi,
On 2021/3/26 15:35, Xionghu Luo via Gcc-patches wrote:
Also we already have a sinking pass on RTL which even computes
a proper PRE on the reverse graph - -fgcse-sm aka store-motion.c.
I'm not sure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93413
Luke Dalessandro changed:
What|Removed |Added
CC||ldalessandro at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99495
Peter Dimov changed:
What|Removed |Added
CC||pdimov at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100240
--- Comment #3 from Peter Taraba ---
unfortunately this is using nvcc, which calls probably gcc internally, so
adding option "-save-temps to the complete compilation command" is not going to
provide what you want.
also, I have no clue what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100243
Bug ID: 100243
Summary: [10 Regression] invalid use of incomplete type
'std::__detail::__iter_traits >' {aka 'struct
std::indirectly_readable_traits'}
Product: gcc
Some ports require libatomic for atomic operations, at least for some
data types and widths. The libstdc++ testsuite previously was updated
to link against libatomic, but the search path was hard-coded to
something that is not always correct, and the shared library search
path was not set.
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97571
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
---
On Fri, Apr 23, 2021 at 4:34 PM Andrew Pinski wrote:
>
> On Fri, Apr 23, 2021 at 2:45 PM Josh Haberman via Gcc wrote:
> >
> > I wrote more about some motivation for guaranteed tail calls here:
> > https://blog.reverberate.org/2021/04/21/musttail-efficient-interpreters.html
>
> So I was looking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100242
--- Comment #2 from Antoni ---
Created attachment 50666
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50666=edit
Third part of the reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100242
--- Comment #1 from Antoni ---
Created attachment 50665
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50665=edit
Second part of the reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100242
Bug ID: 100242
Summary: libgccjit.so: error: in expmed_mode_index, at
expmed.h:249
Product: gcc
Version: 10.3.1
Status: UNCONFIRMED
Severity: normal
On Fri, Apr 23, 2021 at 06:24:07PM -0400, Michael Meissner wrote:
> On Thu, Apr 22, 2021 at 05:56:32PM -0500, Segher Boessenkool wrote:
> > As Will says, it looks like the ELFv2 version has the same bug. Please
> > fix that the same way.
>
> Yes it has the same bug. However in practice it would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98952
--- Comment #4 from Segher Boessenkool ---
Fixed on trunk. Needs backports to 11 and whatever else is still an open
branch when the backports are done :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100240
Andrew Pinski changed:
What|Removed |Added
URL|https://www.frisky.world/20 |
On Fri, Apr 23, 2021 at 2:45 PM Josh Haberman via Gcc wrote:
>
> Would it be feasible to implement a "musttail" statement attribute in
> GCC to get a guarantee that tail call optimization will be performed?
>
> Such an attribute has just landed in the trunk of Clang
>
On Fri, Apr 23, 2021 at 4:15 PM Alejandro Colomar
wrote:
>
> Some manual pages are already using C99 syntax for integral
> types 'uint32_t', but some aren't. There are some using kernel
> syntax '__u32'. Fix those.
>
> Some pages also document attributes, using GNU syntax
>
Some manual pages are already using C99 syntax for integral
types 'uint32_t', but some aren't. There are some using kernel
syntax '__u32'. Fix those.
Some pages also document attributes, using GNU syntax
'__attribute__((xxx))'. Update those to use the shorter and more
portable C2x syntax,
Snapshot gcc-9-20210423 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/9-20210423/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 9 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100241
--- Comment #2 from Marek Polacek ---
This is on aarch64:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/aarch64-redhat-linux/11/lto-wrapper
Target: aarch64-redhat-linux
Configured with: ../configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97571
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100241
Marek Polacek changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100241
Bug ID: 100241
Summary: internal compiler error: in curr_insn_transform, at
lra-constraints.c:4133
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity:
On Thu, Apr 22, 2021 at 05:56:32PM -0500, Segher Boessenkool wrote:
> On Fri, Apr 09, 2021 at 05:09:07PM -0400, Michael Meissner wrote:
> > Fix logic error in 32-bit trampolines, PR target/98952.
> >
> > The test in the PowerPC 32-bit trampoline support is backwards. It aborts
> > if the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98952
--- Comment #3 from CVS Commits ---
The master branch has been updated by Michael Meissner :
https://gcc.gnu.org/g:9a30a3f06b908e4e781324c2e813cd1db87119df
commit r12-97-g9a30a3f06b908e4e781324c2e813cd1db87119df
Author: Michael Meissner
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100240
Peter Taraba changed:
What|Removed |Added
CC||taraba.peter at mail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100240
Bug ID: 100240
Summary: Compiler crashes with segmentation fault on a chrono
library using nvcc
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017
--- Comment #11 from cqwrteur ---
(In reply to Jonathan Wakely from comment #8)
> I can only fix the case where the target (in the build tree) is
> found first and then its #include_next finds the host (installed on
> the host).
>
> But that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100239
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Last
On Fri, Apr 23, 2021 at 7:55 AM Jakub Jelinek wrote:
>
> Status
> ==
>
> GCC 8.5 release and closing of the 8 branch is several months overdue,
> we don't have enough time to maintain trunk and 4 supported release branches.
> Therefore, I'd like to do 8.5-rc1 on 7th of May and release 8.5 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017
--- Comment #10 from cqwrteur ---
(In reply to Jonathan Wakely from comment #8)
> I can only fix the case where the target (in the build tree) is
> found first and then its #include_next finds the host (installed on
> the host).
>
> But that
-r12-96-20210423095621-g886b6c1e8af-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20210423 (experimental) (GCC)
David Malcolm via Gcc wrote:
> FWIW I implemented something like this in GCC's middle-end here:
> https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9a385c2d3d74ffed78f2ed9ad47b844d2f294105
> exposing it in API form for libgccjit:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017
--- Comment #9 from cqwrteur ---
(In reply to Jonathan Wakely from comment #8)
> I can only fix the case where the target (in the build tree) is
> found first and then its #include_next finds the host (installed on
> the host).
>
> But that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100238
Bug ID: 100238
Summary: [11/12] Link failure in debug libstdc++ on MinGW due
to atomicitiy.cc
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100227
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92145
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97571
--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to Mark J Olah from comment #5)
> Whatever is happening inside the AST evaluation in this case is not only
> extraordinarily inefficient, but also apparently exponential with the size
>
On 4/22/21 9:46 AM, Patrick Palka wrote:
On Wed, 21 Apr 2021, Patrick Palka wrote:
On Wed, 21 Apr 2021, Jason Merrill wrote:
On 4/12/21 1:20 PM, Patrick Palka wrote:
Here we're crashing during deduction for a template placeholder from a
dependent initializer because one of the initializer's
David Malcolm via Gcc wrote:
On Fri, 2021-04-23 at 12:44 -0700, Josh Haberman via Gcc wrote:
Would it be feasible to implement a "musttail" statement attribute in
GCC to get a guarantee that tail call optimization will be performed?
Such an attribute has just landed in the trunk of Clang
On Fri, 2021-04-23 at 12:44 -0700, Josh Haberman via Gcc wrote:
> Would it be feasible to implement a "musttail" statement attribute in
> GCC to get a guarantee that tail call optimization will be performed?
>
> Such an attribute has just landed in the trunk of Clang
>
On Fri, Apr 23, 2021 at 12:28 PM Jan Hubicka wrote:
> > On Fri, Apr 23, 2021 at 10:27 AM Xinliang David Li
> > wrote:
> >
> > >
> > >
> > > On Fri, Apr 23, 2021 at 10:16 AM Jan Hubicka wrote:
> > >
> > >> >
> > >> > It uses create_llvm_prof tool which is in the same git repo. The
> data
> > >>
On Fri, Apr 23, 2021 at 5:13 AM Martin Liška wrote:
>
> Few weeks ago, I noticed we have a new remote branch that follows
> origin/master:
> https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/trunk
>
> Do we know who added it? And what was the motivation?
I did; I've always preferred
Would it be feasible to implement a "musttail" statement attribute in
GCC to get a guarantee that tail call optimization will be performed?
Such an attribute has just landed in the trunk of Clang
(https://reviews.llvm.org/D99517). It makes it possible to write
algorithms that use arbitrarily long
On Fri, Apr 23, 2021 at 08:05:29PM +0100, Richard Sandiford wrote:
> Finally getting to this now that the GCC 11 rush is over. Sorry for
> the slow response.
>
> I've tried to review most of the code below, but skipped the testsuite
> parts in the interests of time. I'll probably have more
> On Fri, Apr 23, 2021 at 10:27 AM Xinliang David Li
> wrote:
>
> >
> >
> > On Fri, Apr 23, 2021 at 10:16 AM Jan Hubicka wrote:
> >
> >> >
> >> > It uses create_llvm_prof tool which is in the same git repo. The data
> >> > parsing part is shared with create_gcov, but the writer is obviously
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97571
--- Comment #5 from Mark J Olah ---
I reported this in bug #100235, where it was suggested this would be treated as
WONTFIX.
It seems this bug is reporting on the same issue arising from rttov:
On 4/20/2021 8:06 AM, Andreas Krebbel via Gcc-patches wrote:
With the current handling of decl alignments it is impossible to
reduce the alignment requirement as part of a variable declaration.
This change has been proposed by Richard in the PR. It fixes the
align-1.c testcase on IBM Z.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100237
Patrick Palka changed:
What|Removed |Added
Last reconfirmed||2021-04-23
Finally getting to this now that the GCC 11 rush is over. Sorry for
the slow response.
I've tried to review most of the code below, but skipped the testsuite
parts in the interests of time. I'll probably have more comments in
future rounds, just wanted to get the ball rolling.
This is realy
On 2021-04-23 12:13 p.m., Richard Sandiford wrote:
This is a backport of the PR96796 fix to GCC 10 and GCC 9. The original
trunk patch was:
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552878.html
reviewed here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97571
Dominique d'Humieres changed:
What|Removed |Added
CC||molah at ucar dot edu
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100235
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100235
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
On Fri, Apr 23, 2021 at 12:25 PM David Faust wrote:
> I've just checked in both patches to master and GCC 10 on your behalf.
On 4/22/21 11:54 PM, Jose E. Marchesi via Gcc-patches wrote:
> Thanks for the patch.
> This is OK for both master and GCC 10.
Thanks to both of you :)
YiFei Zhu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100237
Bug ID: 100237
Summary: Unnecessary std::move in ranges::min, ranges::max and
ranges::minmax
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
On Fri, Apr 23, 2021 at 10:27 AM Xinliang David Li
wrote:
>
>
> On Fri, Apr 23, 2021 at 10:16 AM Jan Hubicka wrote:
>
>> >
>> > It uses create_llvm_prof tool which is in the same git repo. The data
>> > parsing part is shared with create_gcov, but the writer is obviously
>> > different for the
On Fri, Apr 23, 2021 at 10:16 AM Jan Hubicka wrote:
> >
> > It uses create_llvm_prof tool which is in the same git repo. The data
> > parsing part is shared with create_gcov, but the writer is obviously
> > different for the two tools.
>
> OK and what are the main differences between llvmand gcc
Hi YiFei,
I've just checked in both patches to master and GCC 10 on your behalf.
Thanks!
On 4/22/21 11:54 PM, Jose E. Marchesi via Gcc-patches wrote:
>
> Hi YiFei.
>
>> Prior to this, a BSS declaration such as:
>>
>> int foo;
>> static int bar;
>>
>> Generates:
>>
>> .global foo
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100236
--- Comment #1 from Alex Coplan ---
GCC compiled with UBSan here. I should have mentioned it needs
-march=armv8.1-m.main.
> Hi.
>
> The current situation is that AutoFDO doesn't work with pretty simple
> test-cases
> we have in testsuite:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71672
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81379
>
> These are ~5 years old and nothing has happened.
>
> I'm pretty
>
> It uses create_llvm_prof tool which is in the same git repo. The data
> parsing part is shared with create_gcov, but the writer is obviously
> different for the two tools.
OK and what are the main differences between llvmand gcc format?
Honza
>
> David
>
>
> > Honza
> > >
> > > David
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100236
Bug ID: 100236
Summary: arm: UB in arm_compute_save_core_reg_mask (shift
exponent 4294967295 is too large for 32-bit type
'int')
Product: gcc
Version: 11.0
On Fri, Apr 23, 2021 at 9:54 AM Jan Hubicka wrote:
> > On Fri, Apr 23, 2021 at 12:18 AM Martin Liška wrote:
> >
> > > On 4/23/21 9:00 AM, Richard Biener via Gcc wrote:
> > > > On Fri, Apr 23, 2021 at 7:28 AM Xinliang David Li via Gcc
> > > > wrote:
> > > >>
> > > >> Hi, the create_gcov tool
> On Fri, Apr 23, 2021 at 12:18 AM Martin Liška wrote:
>
> > On 4/23/21 9:00 AM, Richard Biener via Gcc wrote:
> > > On Fri, Apr 23, 2021 at 7:28 AM Xinliang David Li via Gcc
> > > wrote:
> > >>
> > >> Hi, the create_gcov tool was probably removed with the assumption that
> > it
> > >> was only
On 4/23/21 5:45 PM, Alexander Monakov wrote:
> On Thu, 22 Apr 2021, Tom de Vries wrote:
>
>> Ah, I see, agreed, that makes sense. I was afraid there was some
>> fundamental problem that I overlooked.
>>
>> Here's an updated version. I've tried to make it clear that the
>> futex_wait/wake are
64bit targets default to 128bit long double, so -m96bit-long-double should
not be used. Together with -m128bit-long-double, this option was intended
to be an optimization for 32bit targets only.
Error out when -m96bit-long-double is used with 64bit targets.
2021-04-23 Uroš Bizjak
gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100041
--- Comment #22 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:716bb02b40ecef5564abb5ba45a594323123a104
commit r12-94-g716bb02b40ecef5564abb5ba45a594323123a104
Author: Uros Bizjak
Date: Fri
On Fri, Apr 23, 2021 at 12:18 AM Martin Liška wrote:
> On 4/23/21 9:00 AM, Richard Biener via Gcc wrote:
> > On Fri, Apr 23, 2021 at 7:28 AM Xinliang David Li via Gcc
> > wrote:
> >>
> >> Hi, the create_gcov tool was probably removed with the assumption that
> it
> >> was only used with Google
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100235
Bug ID: 100235
Summary: 10.3.0 Performance regressions for compile-time math
intrinsics computation on arrays
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
On Fri, Apr 23, 2021 at 12:00 AM Richard Biener
wrote:
> On Fri, Apr 23, 2021 at 7:28 AM Xinliang David Li via Gcc
> wrote:
> >
> > Hi, the create_gcov tool was probably removed with the assumption that it
> > was only used with Google GCC branch, but it is actually used with GCC
> > trunk as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99540
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99249
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
ChangeLog:
2021-04-23 David Faust
* MAINTAINERS (Write After Approval): Add myself.
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index db25583b37b..c589c0b30ac 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -387,6 +387,7 @@ Doug Evans
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98119
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99929
--- Comment #5 from CVS Commits ---
The releases/gcc-10 branch has been updated by Richard Sandiford
:
https://gcc.gnu.org/g:2c3a699b91dac954271c9fd96416128fc39cb3f9
commit r10-9760-g2c3a699b91dac954271c9fd96416128fc39cb3f9
Author: Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98119
--- Comment #7 from CVS Commits ---
The releases/gcc-10 branch has been updated by Richard Sandiford
:
https://gcc.gnu.org/g:367aa5ee879c6bbfc4bf7ae94c680f0614581661
commit r10-9759-g367aa5ee879c6bbfc4bf7ae94c680f0614581661
Author: Richard
This is a backport of the PR96796 fix to GCC 10 and GCC 9. The original
trunk patch was:
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552878.html
reviewed here:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553308.html
I'm not aware of any fallout since then.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98056
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100234
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |DUPLICATE
On Thu, 22 Apr 2021, Tom de Vries wrote:
> Ah, I see, agreed, that makes sense. I was afraid there was some
> fundamental problem that I overlooked.
>
> Here's an updated version. I've tried to make it clear that the
> futex_wait/wake are locally used versions, not generic functionality.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99932
--- Comment #4 from Tom de Vries ---
Created attachment 50662
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50662=edit
Updated cuda reproducer
Slimmed down further, eliminated gang/worker reduction parts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100234
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |11.2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100234
Bug ID: 100234
Summary: [11/12 Regression] Coroutines ICE
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #22 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:d2324a5ab3ff097864ae6828cb1db4dd013c70d1
commit r12-91-gd2324a5ab3ff097864ae6828cb1db4dd013c70d1
Author: Uros Bizjak
Date: Fri
64bit loads to/stores from x87 and SSE registers are atomic also on 32-bit
targets, so there is no need for additional atomic moves to a temporary
register.
Introduced load peephole2 patterns assume that there won't be any additional
loads from the load location outside the peepholed sequence and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100232
--- Comment #2 from Tobias Burnus ---
(In reply to Tom de Vries from comment #1)
> Can you try the patch for PR81778 ?
> It's possible you're looking at a duplicate.
Unfortunately, it does not seem to make a difference - it still fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100232
--- Comment #1 from Tom de Vries ---
Can you try the patch for PR81778 ?
It's possible you're looking at a duplicate.
lements_view, 0>;
|
^
:56:93: note: constraints not satisfied
In file included from :44:
/opt/compiler-explorer/gcc-trunk-20210423/include/c++/12.0.0/ranges: In
substitution of 'template requir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95693
--- Comment #13 from Tibor Billes ---
Thank you all for fixing it!
On Tue, Feb 09, 2021 at 12:12:24PM +0100, Jakub Jelinek via Gcc-patches wrote:
> As mentioned in the PR, we don't support arithmetic right V2DImode or
> V4DImode on x86 without -mavx512vl or -mxop. The ISAs indeed don't have
> {,v}psraq instructions until AVX512VL, but we actually can emulate it
1 - 100 of 255 matches
Mail list logo
