https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95019
--- Comment #3 from bin cheng ---
(In reply to zhongyu...@tom.com from comment #2)
> It is a generic issue for all targets, such as x86, it also don't enpand
Yes, as said it's because SCEV currently doesn't model this, so it's not target
specific
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92177
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92177
--- Comment #13 from CVS Commits ---
The releases/gcc-10 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:ff9d4e09566e24d4dff10adeaef109823266c7bd
commit r10-8140-gff9d4e09566e24d4dff10adeaef109823266c7bd
Author: Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94947
--- Comment #9 from CVS Commits ---
The releases/gcc-10 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:a68d4b47a6b5b23a5d7ab3b358f559f41568512f
commit r10-8142-ga68d4b47a6b5b23a5d7ab3b358f559f41568512f
Author: Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94947
--- Comment #8 from CVS Commits ---
The releases/gcc-10 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:67d00c438285ecf9b8e96c12d1f6b05fd2ea3c21
commit r10-8141-g67d00c438285ecf9b8e96c12d1f6b05fd2ea3c21
Author: Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95099
Bug ID: 95099
Summary: Build a cross compiler for m32c on Windows (Cygwin)
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
--- Comment #42 from CVS Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:883246530f1bb10d854f455e1c3d55b93675690a
commit r11-347-g883246530f1bb10d854f455e1c3d55b93675690a
Author: Alexandre Oliva
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95051
--- Comment #8 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:3d96f7b92415b7a277a87e7825efc958030e20b6
commit r11-348-g3d96f7b92415b7a277a87e7825efc958030e20b6
Author: Martin Liska
Date: Wed M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95092
Martin Liška changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018
--- Comment #29 from Thomas Koenig ---
It is also interesting that this variant
--- a/libgfortran/generated/in_pack_i4.c
+++ b/libgfortran/generated/in_pack_i4.c
@@ -88,7 +88,7 @@ internal_pack_4 (gfc_array_i4 * source)
count[0]++;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94690
--- Comment #9 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:f884bef2105d748fd7869cd641cbb4f6b6bb
commit r11-349-gf884bef2105d748fd7869cd641cbb4f6b6bb
Author: Tobias Burnus
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018
--- Comment #30 from Richard Biener ---
(In reply to Thomas Koenig from comment #29)
> It is also interesting that this variant
>
> --- a/libgfortran/generated/in_pack_i4.c
> +++ b/libgfortran/generated/in_pack_i4.c
> @@ -88,7 +88,7 @@ internal_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95100
Bug ID: 95100
Summary: xxx_view adaptors don't work with pipeline
operator
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95101
Bug ID: 95101
Summary: Optimize libgfortran library handling of arrays
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95101
Thomas Koenig changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95102
Bug ID: 95102
Summary: missed if-conversion
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95102
--- Comment #1 from Richard Biener ---
OK, so one reason is that
if (!can_conditionally_move_p (x_mode))
return FALSE;
returns false for E_V4SFmode on x86. min/max detection is based
on fp_cmov expansion for scalar FP on x86 though (with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95060
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:c0c39a765b0714aed36fced6fbba452a6619acb0
commit r11-350-gc0c39a765b0714aed36fced6fbba452a6619acb0
Author: Jakub Jelinek
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95080
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:18edc195442291525e04f0fa4d5ef972155117da
commit r11-351-g18edc195442291525e04f0fa4d5ef972155117da
Author: Jakub Jelinek
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95060
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95080
Jakub Jelinek changed:
What|Removed |Added
Summary|[10/11 Regression] |[10 Regression]
|-fcom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94874
Tobias Burnus changed:
What|Removed |Added
See Also||https://github.com/OpenMP/s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018
--- Comment #31 from Jiu Fu Guo ---
(In reply to Richard Biener from comment #28)
> > For the loop which has multi-exits, it may not helpful to unroll it,
> > especially "complete unroll" may be not helpful. Like loop in in_pack_i4.c.
> > Since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018
--- Comment #32 from Richard Biener ---
Note I don't think the unrolling is excessive - store motion then applying
to all count[] and all computations hoisted out of the loop may be a bit
too much for register pressure though, especially since we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018
--- Comment #33 from Jiu Fu Guo ---
(In reply to Richard Biener from comment #32)
> Note I don't think the unrolling is excessive - store motion then applying
> to all count[] and all computations hoisted out of the loop may be a bit
> too much f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95103
Bug ID: 95103
Summary: Unexpected -Wclobbered in bits/vector.tcc with -O2
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95099
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83670
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |8.5
Summary|m32c ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83670
Andrew Pinski changed:
What|Removed |Added
CC||dj_adilovic at hotmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95052
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |9.4
Summary|Excess padding of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95034
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95104
Bug ID: 95104
Summary: Segfault on a legal WAIT statement
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95104
--- Comment #1 from Bill Long ---
The program appears to be legal and should execute and print 0.
The last paragraph of 12.7.2 WAIT statement (current Fortran standard) is
Execution of a WAIT statement specifying a unit that does not exist,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91731
keroro.90 at hotmail dot it changed:
What|Removed |Added
CC||keroro.90 at hotmail dot it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95005
Martin Liška changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #6 from Martin Liška ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95021
--- Comment #8 from H.J. Lu ---
(In reply to rguent...@suse.de from comment #6)
> On Tue, 12 May 2020, hjl.tools at gmail dot com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95021
> >
> > --- Comment #4 from H.J. Lu ---
> > The p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94928
--- Comment #23 from Martin Liška ---
(In reply to Myron Walker from comment #22)
> It does the same things a gcov and lcov combined but in python. It also
> does merging of data but in a different way than gcov-tool. I might need to
> change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70642
--- Comment #2 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:6cc6b087c8cdfdf58a4bb166aa53950c4bfdef2d
commit r11-357-g6cc6b087c8cdfdf58a4bb166aa53950c4bfdef2d
Author: Patrick Palka
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70642
Patrick Palka changed:
What|Removed |Added
Known to work||10.0, 11.0, 9.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93497
--- Comment #6 from CVS Commits ---
The master branch has been updated by Mark Eggleston
:
https://gcc.gnu.org/g:f9f98e59a7f6663f31b671c44998190079097f97
commit r11-358-gf9f98e59a7f6663f31b671c44998190079097f97
Author: Mark Eggleston
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87847
--- Comment #12 from Martin Liška ---
(In reply to Patrick Palka from comment #11)
> I posted a patch to enable sanitization for the spec_hasher tables for GCC
> 11 here: https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545525.html
>
> With cu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93497
--- Comment #7 from CVS Commits ---
The releases/gcc-10 branch has been updated by Mark Eggleston
:
https://gcc.gnu.org/g:f2b77b928a54784d40faf1d86bd5b63f14756dc5
commit r10-8143-gf2b77b928a54784d40faf1d86bd5b63f14756dc5
Author: Mark Eggleston
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95083
--- Comment #2 from Uroš Bizjak ---
It looks to me that a couple of (scalar) splitters are missing in sse.md.
There is vector
(define_insn_and_split "*_blendv_lt"
Defined as:
[(set (match_operand:VF_128_256 0 "register_operand" "=Yr,*x,x")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93031
felix changed:
What|Removed |Added
CC||felix.von.s at posteo dot de
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93497
--- Comment #8 from CVS Commits ---
The releases/gcc-9 branch has been updated by Mark Eggleston
:
https://gcc.gnu.org/g:cf7a6070c3688db20447643c789e157f73fc178b
commit r9-8590-gcf7a6070c3688db20447643c789e157f73fc178b
Author: Mark Eggleston
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95094
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
See A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95105
Bug ID: 95105
Summary: Bogus reference-compatibility error for
arm_sve_vector_bits
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95105
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94703
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #9 from Richard Biener ---
[...]
> Hmm, OK looks like memcpy is not folded, likely because the source is
> not known to be appropriately aligned.
[...]
> should fix this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93497
markeggleston at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #17 from Christophe Lyon ---
(In reply to Richard Earnshaw from comment #10)
> (In reply to Christophe Lyon from comment #9)
> > > My initial thoughts are along the lines of...
> > > Only try to save FP registers that this function di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94983
--- Comment #3 from Andrey Vihrov ---
Another sample, probably caused by the same underlying issue:
struct T
{
char a[3];
};
void bar()
{
T t{"x"}; // OK
T{"x"}; // OK
new T{"x"}; // err
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94703
--- Comment #11 from pskocik at gmail dot com ---
Thanks for the shot at a fix, Richard Biener.
Since I have reported this, I think I should mentioned a related suboptimality
that should probably be getting fixed alongside with this (if this one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053
--- Comment #17 from Bill Seurer ---
he patch works and has no further fallout that I see.
I will still try to extract something small from that big fortran function but
as I have not written any fortran code in more than 35 years it may take a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95104
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95104
--- Comment #3 from Bill Long ---
A comment from the original user: gfortran 8.3.0 appears to do the right
thing. So perhaps a regression somewhere in the 9.x line?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95106
Bug ID: 95106
Summary: Bogus warning from module with long name and an
equivalence
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95107
Bug ID: 95107
Summary: [10/11 Regression] ICE in hash_operand, at
fold-const.c:3768
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94553
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95108
Bug ID: 95108
Summary: [10/11 Regression] ICE in tree_fits_uhwi_p, at
tree.c:7292
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95104
--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to Bill Long from comment #3)
> A comment from the original user: gfortran 8.3.0 appears to do the right
> thing. So perhaps a regression somewhere in the 9.x line?
A note of the gfortra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95104
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95109
Bug ID: 95109
Summary: [11 regression] ICE in gfortran.dg/gomp/target1.f90
after r11-349
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95003
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94690
--- Comment #10 from Tobias Burnus ---
Created attachment 48522
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48522&action=edit
Patch to add OpenMP 5 feature (private + lastprivate permitted for 'simd')
The patch solves an independent iss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95110
Bug ID: 95110
Summary: new test case in r11-345 error:
gcc.dg/tree-ssa/pr94969.c: dump file does not exist
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95109
--- Comment #1 from Tobias Burnus ---
Confirmed – see PR 94690 comment 10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95110
--- Comment #1 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:287552950d56be47adb6b6bf2eae2d612233eaec
commit r11-361-g287552950d56be47adb6b6bf2eae2d612233eaec
Author: Jakub Jelinek
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95061
--- Comment #3 from CVS Commits ---
The master branch has been updated by Ian Lance Taylor :
https://gcc.gnu.org/g:702adbb2fff0cc043f9c4e1af890421cb238cd18
commit r11-362-g702adbb2fff0cc043f9c4e1af890421cb238cd18
Author: Ian Lance Taylor
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90320
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
Bug ID: 95111
Summary: coroutines use-after-free with lambdas
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95112
Bug ID: 95112
Summary: i386 procedures have prolog endbr32
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95108
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2020-05-13
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95113
Bug ID: 95113
Summary: [10/11 Regression] Wrong code w/ -O2 -fexceptions
-fnon-call-exceptions
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: wrong-co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
Jared changed:
What|Removed |Added
CC||jared.martinsen at fiserv dot
com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95113
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2020-05-13
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95113
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95101
Thomas Koenig changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95113
--- Comment #3 from Arseny Solokha ---
(In reply to Jakub Jelinek from comment #2)
> Guess dup of the other PR where the IPA opts assume DCE which doesn't really
> happen (the *p load result is never used).
Indeed, -fno-ipa-sra fixes it. So, a d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95061
--- Comment #4 from CVS Commits ---
The master branch has been updated by Ian Lance Taylor :
https://gcc.gnu.org/g:0d5d880994660e231f82b7cb1dcfab744158f7e0
commit r11-364-g0d5d880994660e231f82b7cb1dcfab744158f7e0
Author: Ian Lance Taylor
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95061
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95108
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=94024
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #212 from dave.anglin at bell dot net ---
On 2020-05-13 2:03 p.m., jared.martinsen at fiserv dot com wrote:
> --- Comment #211 from Jared ---
> Are these errors the same as described above?
>
> It give the following 2 errors:
> ld: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95114
Bug ID: 95114
Summary: [9/10/11 Regression] ICE in obj_type_ref_class for
structural-equality types
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95114
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Target Mileston
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #1 from Iain Sandoe ---
There are some gotchas with coroutines and references (both regular and
rvalue).
* there could still be a bug here, so I want to double-check.
Please could you expand your snippets of code into a small test-c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #2 from Avi Kivity ---
Created attachment 48524
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48524&action=edit
lame testcase
Lame testcase that shows that the lambda is passed as a pointer rather than by
value, leading to a l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #3 from Avi Kivity ---
The test case I uploaded only shows the failure, it won't work if gcc worked as
I expect it. I'll try to get a better testcase, unfortunately a small coroutine
testcase is still some work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #4 from Iain Sandoe ---
(In reply to Avi Kivity from comment #3)
> The test case I uploaded only shows the failure, it won't work if gcc worked
> as I expect it. I'll try to get a better testcase, unfortunately a small
> coroutine tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #5 from Avi Kivity ---
This snippet from cppreference:
If the coroutine is a non-static member function, such as task
my_class::method1(int x) const;, its Promise type is
std::coroutine_traits, const my_class&, int>::promise_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #6 from Iain Sandoe ---
(In reply to Avi Kivity from comment #5)
> This snippet from cppreference:
>
> If the coroutine is a non-static member function, such as task
> my_class::method1(int x) const;, its Promise type is
> st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95115
Bug ID: 95115
Summary: [10 Regression] RISC-V 64: inf/inf division optimized
out, invalid operation not raised
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95116
Bug ID: 95116
Summary: [C++ 20] Accepts invalid code with decltype dependent
type
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #8 from Avi Kivity ---
Created attachment 48526
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48526&action=edit
less lame testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #7 from Avi Kivity ---
I have a simple reproducer. A lambda fails while a fake lambda using structs
passes. I don't think gcc is at fault, but the standard is problematic here
IMO.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95116
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
Iain Sandoe changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64636
Viktor Ostashevskyi changed:
What|Removed |Added
CC||ostash at ostash dot kiev.ua
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #10 from Avi Kivity ---
Well, the standard is useless here.
In
[foo] () -> lazy { co_return foo; } ()
a temporary is clearly passed to the lambda body, yet the standard mandates
that we capture it by reference. As a result, a u
1 - 100 of 146 matches
Mail list logo
