https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92852
Bug ID: 92852
Summary: location references block not in block tree
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92851
Bug ID: 92851
Summary: Lambda capture of *this with mutable is not mutable
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85055
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80532
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92850
--- Comment #2 from fdlbxtqi ---
(In reply to Andrew Pinski from comment #1)
> The crash itself should report to llvm project for sure.
>
> Are you sure concepts are fully implemented in clang?
Yea. I know it is an LLVM bug and should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92850
--- Comment #1 from Andrew Pinski ---
The crash itself should report to llvm project for sure.
Are you sure concepts are fully implemented in clang?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92800
Gary Oblock changed:
What|Removed |Added
CC||goblock at marvell dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92823
--- Comment #4 from fdlbxtqi ---
I know it is mostly a clang bug. However, jwakely you can try to use clang to
test your code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92850
Bug ID: 92850
Summary: clang has already supported concepts in latest trunk.
However it does not define __cpp_concepts macro. I
defined it but crashes clang compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92831
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Fri Dec 6 23:43:45 2019
New Revision: 279069
URL: https://gcc.gnu.org/viewcvs?rev=279069=gcc=rev
Log:
PR c++/92831
* call.c (build_conditional_expr_1): For ?: with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92796
Peter Bergner changed:
What|Removed |Added
CC||law at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92007
--- Comment #23 from Andrew Pinski ---
(In reply to Maxim Kuvyrkov from comment #21)
>
> Is there a way to fix the problem gcc-9-branch in less intrusive way?
Could this be an alignment issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92810
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> Testing that (and see what the next failure is)
After the above patch, there are no build failures; I have not tried to run the
testsuite yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92841
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92451
--- Comment #3 from Marek Polacek ---
Author: mpolacek
Date: Fri Dec 6 22:12:51 2019
New Revision: 279067
URL: https://gcc.gnu.org/viewcvs?rev=279067=gcc=rev
Log:
Add test for c++/92451.
This was ICEing from r277865 to r278786.
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92451
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92810
--- Comment #3 from Andrew Pinski ---
Next error:
/bajas/pinskia/src/toolchain-10/scripts/../src/libgo/go/internal/syscall/unix/getrandom_linux.go:35:34:
error: reference to undefined name ‘randomTrap’
35 | r1, _, errno :=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92451
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92849
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92849
--- Comment #3 from Alexander Kondratskiy ---
I think you're right. I think the bug can be closed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92823
--- Comment #3 from fdlbxtqi ---
(In reply to Richard Biener from comment #1)
> It's called "exception" handling. If you use an "exception" on the fast path
> you are doing something wrong.
If this succeeds, we will be able to directly use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92823
--- Comment #2 from fdlbxtqi ---
(In reply to Richard Biener from comment #1)
> It's called "exception" handling. If you use an "exception" on the fast path
> you are doing something wrong.
Have you read recent papers about deterministic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92849
--- Comment #2 from Jonathan Wakely ---
If name lookup finds the name in multiple base classes, the lookup is
ambiguous. Overload resolution is not done to determine if one function is a
better match than the other.
By pulling them all into the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92847
--- Comment #3 from Jonathan Wakely ---
Reduced:
template
struct A {
A() {}
template
A(const A&) {}
bool operator==(const A&) const { return true; }
};
A a;
A b;
auto c = (a == b);
Compiled with -std=gnu++2a:
cmp.cc:13:13: error:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92847
--- Comment #2 from Jonathan Wakely ---
Although it's still ambiguous with that fixed. There are some known issues with
the default comparisons feature in C++20, this might be one of them.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92847
--- Comment #1 from Jonathan Wakely ---
(In reply to Laurent Stacul from comment #0)
> bool operator==(const A&) { return true; }
This member function should be const.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92849
--- Comment #1 from Alexander Kondratskiy ---
Actually, this might be bogus. If I do an explicit `using`, everything works:
#include
template
struct declfunc;
template
struct declfunc
{
Result operator()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92831
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Fri Dec 6 20:16:27 2019
New Revision: 279064
URL: https://gcc.gnu.org/viewcvs?rev=279064=gcc=rev
Log:
PR c++/92831 - CWG 1299, not extending temporary lifetime for ?:
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92849
Bug ID: 92849
Summary: call to 'operator()' incorrectly considered ambiguous,
when inherited twice with different type parameters
Product: gcc
Version: 9.2.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92805
--- Comment #4 from Steve Kargl ---
On Fri, Dec 06, 2019 at 06:48:04PM +, kargl at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92805
>
> --- Comment #3 from kargl at gcc dot gnu.org ---
> (In reply to kargl from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92842
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92820
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92820
--- Comment #12 from ian at gcc dot gnu.org ---
Author: ian
Date: Fri Dec 6 19:52:46 2019
New Revision: 279063
URL: https://gcc.gnu.org/viewcvs?rev=279063=gcc=rev
Log:
PR go/92820
runtime: only build go-context for x86 GNU/Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29842
--- Comment #6 from ian at gcc dot gnu.org ---
Author: ian
Date: Fri Dec 6 19:37:39 2019
New Revision: 279062
URL: https://gcc.gnu.org/viewcvs?rev=279062=gcc=rev
Log:
PR go/29842
runtime: update HURD support for mOS now being
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92176
--- Comment #9 from Vladimir Makarov ---
Thank you, Andreas. I've committed the patch with your changes in the test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92176
--- Comment #8 from Vladimir Makarov ---
Author: vmakarov
Date: Fri Dec 6 19:30:37 2019
New Revision: 279061
URL: https://gcc.gnu.org/viewcvs?rev=279061=gcc=rev
Log:
2019-12-06 Andreas Krebbel
Vladimir Makarov
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92810
--- Comment #2 from Ian Lance Taylor ---
The configure script should work now, but I don't know what other problems you
will encounter.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92805
--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #2)
> Index: gcc/fortran/primary.c
> ===
> --- gcc/fortran/primary.c (revision 279052)
> +++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92805
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92773
--- Comment #10 from Jakub Jelinek ---
For the kernel module, I'd suggest just fixing the external tool, so it emits {
{ 0x.., 0x.. } },
lines instead of { 0x.., 0x.. }, lines.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92773
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92828
--- Comment #7 from Martin Sebor ---
Rather than suppressing the warning via a pragma, would replacing the call to
deps_add_target (d, "-", 1);
with
d->targets.push (xstrdup (t));
be a better solution? Unless I've overlooked something it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92828
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92768
Jakub Jelinek changed:
What|Removed |Added
Summary|[8/9/10 Regression] Maybe a |[8/9 Regression] Maybe a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92848
Bug ID: 92848
Summary: [OpenACC] Memory leak for simple 'acc_create',
'acc_delete' sequence
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: openacc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52451
--- Comment #12 from Vineet Gupta ---
oops the ARC bug is (PR 92846) not (PR 92845)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52451
Vineet Gupta changed:
What|Removed |Added
CC||vgupta at synopsys dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92846
--- Comment #2 from Vineet Gupta ---
Created attachment 47438
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47438=edit
proposed fix
Ran full glibc tessuite with this: No regressions
gcc dejagnu test pr52451.c passes too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92775
Jakub Jelinek changed:
What|Removed |Added
Summary|[8/9/10 Regression] |[8/9 Regression] Incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92847
Bug ID: 92847
Summary: [C++20] ambiguous overload for ‘operator==’ ?
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92820
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92846
--- Comment #1 from Vineet Gupta ---
Test case:
int f(double x, double y)
{
return x > y; // expected FDCMPF (qNaN, sNaN)
}
int f2(double x, double y)
{
return __builtin_isgreater(x, y); // expected FDCMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92846
Bug ID: 92846
Summary: [ARC] gloating point compares not generating Invalid
Operand
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92837
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92845
Bug ID: 92845
Summary: [ARC] gcc not generating hardware compare instruction
FDCMP for -mcpu=hs38_linux
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92007
--- Comment #22 from Ilya Leoshkevich ---
Hello Maxim,
Sorry about that!
I don't think it's possible to simply move jump threading back, since
it's not correct to have it where it used to be. So I will build and
run the new and the old
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92843
--- Comment #3 from Thomas Schwinge ---
(In reply to jules from comment #2)
> I don't think your example is valid
Which one, specifically?
> but I'm not sure it will be fail in
> quite the right way with the current version of my refcount
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92007
Maxim Kuvyrkov changed:
What|Removed |Added
CC||mkuvyrkov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89838
--- Comment #3 from Vineet Gupta ---
Can this be closed ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92836
--- Comment #13 from Janne Blomqvist ---
To clarify my previous message, instead of
inquire(..., exist=exist)
if (exist) then
open(...)
else
! Handle file not existing
end if
you can do
open(..., status='old', iostat=stat)
if (stat /=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92841
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92836
--- Comment #12 from Andrew Benson ---
(In reply to Thomas Koenig from comment #11)
> (In reply to Andrew Benson from comment #10)
> > (In reply to Thomas Koenig from comment #8)
> > My reasoning for using INQUIRE to check the existence of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92836
--- Comment #11 from Thomas Koenig ---
(In reply to Andrew Benson from comment #10)
> (In reply to Thomas Koenig from comment #8)
> > Also, why do you use inquire at all? AFAIK, it is not an error
> > to OPEN a file more than one if you don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92843
--- Comment #2 from jules at gcc dot gnu.org ---
I don't think your example is valid, but I'm not sure it will be fail in quite
the right way with the current version of my refcount overhaul patch. Actually
I think the acc_map_data implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59423
marc at kdab dot com changed:
What|Removed |Added
CC||marc at kdab dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92836
--- Comment #10 from Andrew Benson ---
(In reply to Thomas Koenig from comment #8)
> > No. The inquire() is used only to see if the file exists already. If it
> > does, the code branches to read the file, if it does not, the code branches
> > to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92784
--- Comment #3 from seurer at gcc dot gnu.org ---
Could be the same thing. Perhaps you can check what changed with this revision
to start this particular test failing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92836
--- Comment #9 from Janne Blomqvist ---
(In reply to Thomas Koenig from comment #8)
> > No. The inquire() is used only to see if the file exists already. If it
> > does, the code branches to read the file, if it does not, the code branches
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92844
--- Comment #1 from Tobias Burnus ---
I think that is or could be a duplicate of PR 92305. See esp. PR 92305 comment
8 (and following) and PR 92305 comment 16.
At least both use type(c_ptr) and optional. I think it makes sense to fix PR
92305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92834
--- Comment #3 from Jakub Jelinek ---
Created attachment 47437
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47437=edit
gcc10-pr92834.patch
This untested patch just undoes the fancy way of writing blend operation and
turns it into ?:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92843
Thomas Schwinge changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92844
Bug ID: 92844
Summary: [10 regression]
libgomp.fortran/use_device_ptr-optional-2.f90 fails
after r279004
Product: gcc
Version: 10.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92843
Bug ID: 92843
Summary: [OpenACC] Disallow 'acc_delete' etc. for everything
without a dynamic reference count
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92775
--- Comment #6 from Jakub Jelinek ---
Author: jakub
Date: Fri Dec 6 13:28:59 2019
New Revision: 279045
URL: https://gcc.gnu.org/viewcvs?rev=279045=gcc=rev
Log:
PR fortran/92775
* trans.h (struct lang_type, struct lang_decl):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92836
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92834
--- Comment #2 from Jan Hubicka ---
Created attachment 47436
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47436=edit
Clang assembly from perf
It is clang9 build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92793
--- Comment #1 from Tobias Burnus ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00207.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92775
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92842
Bug ID: 92842
Summary: [10 Regression] libgo build failure on i686-gnu
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92820
--- Comment #10 from Matthias Klose ---
that fixes it ...
--- libgo/runtime/go-context.S (revision 279039)
+++ libgo/runtime/go-context.S (working copy)
@@ -71,4 +71,8 @@
#endif
+#if defined(__ARM_EABI__)
+ .section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92841
Bug ID: 92841
Summary: Optimize -fstack-protector-strong code generation a
bit
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92836
--- Comment #7 from Tobias Burnus ---
(In reply to Jerry DeLisle from comment #3)
> character(len=27) :: c
> Fortran runtime error: Fortran runtime error: End of recordEnd of record
This error I get because 27 characters are not enough —
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92834
Richard Biener changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92831
--- Comment #3 from Jakub Jelinek ---
Created attachment 47434
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47434=edit
gcc10-pr92831.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92840
Bug ID: 92840
Summary: [OpenACC] Disallow 'acc_unmap_data' for everything
other than 'acc_map_data'
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92836
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92829
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92836
Janne Blomqvist changed:
What|Removed |Added
CC||jb at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92824
--- Comment #3 from Richard Biener ---
So
int main()
{
long double x;
// make x pseudo-denormal
x = 0;
unsigned char *px = (unsigned char *)
px[7] = 0x80;
// set padding
px[10] = 0x80;
px[11] = 0x80;
px[12] = 0x80;
px[13]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36941
--- Comment #11 from Christophe Lyon ---
Author: clyon
Date: Fri Dec 6 10:54:46 2019
New Revision: 279039
URL: https://gcc.gnu.org/viewcvs?rev=279039=gcc=rev
Log:
[testsuite][aarch64] type_redef_11.c: Update expected diagnostics.
After the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88827
--- Comment #3 from Christophe Lyon ---
Author: clyon
Date: Fri Dec 6 10:54:46 2019
New Revision: 279039
URL: https://gcc.gnu.org/viewcvs?rev=279039=gcc=rev
Log:
[testsuite][aarch64] type_redef_11.c: Update expected diagnostics.
After the fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85309
Lyberta changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88101
andysem at mail dot ru changed:
What|Removed |Added
CC||andysem at mail dot ru
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92809
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92839
Bug ID: 92839
Summary: Normalize memory address to same base in non-loop code
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92838
--- Comment #1 from sw6ueyz at gmail dot com ---
Sorry.. you need not add "-I/opt/wandbox/boost-1.71.0/gcc-head/include" in
command line (this code does not use any include files.. I just copied command
line from wandbox.org test bed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92838
Bug ID: 92838
Summary: ICE (internal compiler error) calling lambda object
with requires clause (in in dependent_type_p)
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92828
Andreas Krebbel changed:
What|Removed |Added
Priority|P3 |P2
--- Comment #5 from Andreas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92176
--- Comment #7 from Andreas Krebbel ---
Created attachment 47432
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47432=edit
Updated testcase
This is an updated testcase with the changes I propose.
Your testcase works fine. However, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92823
--- Comment #1 from Richard Biener ---
It's called "exception" handling. If you use an "exception" on the fast path
you are doing something wrong.
1 - 100 of 101 matches
Mail list logo
