https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99705
Bug ID: 99705
Summary: [10/11 Regression] ICE in expand_expr_real_1 since
r10-3661
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99705
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99677
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
Bug ID: 99708
Summary: __SIZEOF_FLOAT128__ not defined on powerpc64le-linux
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99705
--- Comment #1 from Jakub Jelinek ---
The *.original dump diff before/after is
@@ -32,11 +32,11 @@
}
:;
{
-struct C * D.2390;
+struct C * D.2390 = D.2378 + ((SAVE_EXPR <(sizetype) ((struct X *)
this)->n> - (sizetype) D.2380) +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99703
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99705
--- Comment #2 from Jakub Jelinek ---
Created attachment 50447
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50447&action=edit
gcc11-pr99705.patch
One possible fix. The reason I've made the build_vec_delete_1 changes was that
P0784R7 was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99705
--- Comment #3 from Jakub Jelinek ---
Created attachment 50449
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50449&action=edit
gcc11-pr99705-2.patch
Another untested fix instead of the above.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #2 from Jakub Jelinek ---
The __SIZEOF_*__ macros are widely used to detect both if a type can be used
and what sizeof (the_type) is when it needs to be checked in preprocessor
conditionals, including hundreds of times in GCC testsuit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99706
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99706
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|10.3|9.4
Summary|[10/11 Regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656
Bug 86656 depends on bug 99680, which changed state.
Bug 99680 Summary: [11 Regression] AddressSanitizer: global-buffer-overflow
since g:04b4828c6dd2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99680
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99680
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Assignee|jakub at gcc do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98389
--- Comment #9 from Jakub Jelinek ---
If we had a time machine, I strongly hope that double double wouldn't exist at
all. It is a fast but completely useless type without any usable numerical
properties.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99706
--- Comment #8 from Jakub Jelinek ---
Tried
--- aarch64-simd.md.jj1 2021-03-08 23:40:33.846448416 +0100
+++ aarch64-simd.md 2021-03-23 12:40:51.325018722 +0100
@@ -133,7 +133,7 @@
[(set (match_operand:VQMOV 0 "nonimmediate_operand"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99724
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99724
--- Comment #3 from Jakub Jelinek ---
E.g. I can't find a neg pattern in iwmmxt.md either, so
r11-5990-g4cbb7cab47a3b91a12ad52baab5bbe6e4373ce73
is problematic too.
And r11-6616-g25bef68902f42f414f99626cefb2d3df81de7dc8 too (don't see any
UNSPEC_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99706
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #45 from Jakub Jelinek ---
I have tried the mingw gcc/binutils crosses we have in Fedora (gcc 10.2.1) and
get:
i686-w64-mingw32-objdump -h ./pr98860.exe
./pr98860.exe: file format pei-i386
Sections:
Idx Name Size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #47 from Jakub Jelinek ---
Does mingw/cygwin always use GNU binutils?
At least for ld.bfd, a quick and reliable test could be
$gcc_cv_ld --verbose 2>&1 | grep -q
'\.debug_loclists.*BLOCK.*__section_alignment__.*NOLOAD.*:'
&& $gcc_cv_l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #49 from Jakub Jelinek ---
Created attachment 50459
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50459&action=edit
gcc11-pr98860.patch
In that case this completely untested patch which could work, but no way to
really test it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99334
--- Comment #8 from Jakub Jelinek ---
I wonder about:
--- gcc/dwarf2cfi.c.jj 2021-03-02 11:25:47.217727061 +0100
+++ gcc/dwarf2cfi.c 2021-03-23 17:34:58.240281522 +0100
@@ -2705,12 +2705,15 @@ scan_trace (dw_trace_info *trace, bool e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #53 from Jakub Jelinek ---
Comment on attachment 50460
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50460
Slightly adjusted patch to fix errors
Thanks for fixing my bugs, but there is another one:
if (TARGET_PECOFF && opts_se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
Jakub Jelinek changed:
What|Removed |Added
Attachment #50460|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #55 from Jakub Jelinek ---
Created attachment 50462
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50462&action=edit
gcc11-pr98860-2.patch
And the noisy variant this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99724
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99703
--- Comment #29 from Jakub Jelinek ---
I think not i586 but i486, at least unless processor_alias_table is inaccurate.
c3 with mmx/3dnow and not sse is
{"c3", PROCESSOR_I486, CPU_NONE, PTA_MMX | PTA_3DNOW, 0, P_NONE},
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #4 from Jakub Jelinek ---
__SIZEOF_FLOAT128__ is predefined on all targets that have the __float128 type,
except for rs6000:
grep '"__float128"' */*
i386/i386-builtins.c: lang_hooks.types.register_builtin_type
(float128_type_node, "_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99724
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99744
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99751
--- Comment #4 from Jakub Jelinek ---
Started with r11-5391-gbb07490abba850fd5b1d2d09d76d18b8bdc7d817
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99230
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99745
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99767
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99767
--- Comment #3 from Jakub Jelinek ---
E.g. as
int a[1024], b[1024];
void
foo (void)
{
#pragma omp simd
for (int i = 0; i < 1024; i++)
if (b[i] > 23) {
a[i] = b[i] + 1;
int v = 1 / 0;
}
}
(omp simd is there only to convinc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99764
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718
--- Comment #6 from Jakub Jelinek ---
I did not know whether it is implementable (in VSX or in Altivec) for 32-bit
targets etc., all I was suggesting was what to do if it is not implementable.
If it is implementable, somebody familiar with VSX/Al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99565
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718
--- Comment #10 from Jakub Jelinek ---
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/567215.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99745
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99672
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99777
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99777
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718
--- Comment #14 from Jakub Jelinek ---
You still have:
if (VECTOR_MEM_VSX_P (mode))
{
if (!CONST_INT_P (elt_rtx))
{
if ((TARGET_P9_VECTOR && TARGET_POWERPC64) || width == 8)
return ..._p9 (...);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99705
Jakub Jelinek changed:
What|Removed |Added
Summary|[10/11 Regression] ICE in |[10 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99785
--- Comment #9 from Jakub Jelinek ---
gcc does have __builtin_convertvector (which is used only for clang
apparently), and while it doesn't have __builtin_shufflevector, it does have
__builtin_shuffle which can achieve everything that the code do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99777
--- Comment #3 from Jakub Jelinek ---
So, one thing is that tree-affine.c during store motion alias analysis feeds
very questionable expressions to the folder, in particular it attempts to fold
MULT_EXPR of (sizetype) (vector(4) short int *) ((in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99789
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99789
--- Comment #8 from Jakub Jelinek ---
Bugzilla is for reporting bugs, not for general programming advices.
There is no bug here, the C++ standard for 64-bit architectures with its
requirements on std::string_view etc. effectively mandates that t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718
--- Comment #16 from Jakub Jelinek ---
(In reply to luoxhu from comment #15)
> Do you mean Power7 for the plain old VSX? I verified the pr98914.c on
> Power7, it exactly ICEs on "gcc_assert (CONST_INT_P (elt_rtx));" for both
> m64 and m32. This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99334
--- Comment #9 from Jakub Jelinek ---
As I said on the mailing list, the above patch has problems, it relies on the
insn that clobbers_queued_reg_save to be a single hardware instruction so that
a debug info consumer or unwinding can't stop "in t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99790
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |8.5
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99790
--- Comment #2 from Jakub Jelinek ---
Though, that doesn't make much sense, maybe r241137 instead?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99781
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99810
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99810
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99808
--- Comment #2 from Jakub Jelinek ---
Started with r7-8376-g726e7a70b911f4676de4a97b19e042552ceedd17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99808
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99808
--- Comment #4 from Jakub Jelinek ---
The bug is clearly on the aarch64 backend side,
(insn 7 6 8 (set (reg/v:V2DF 73 [ arg2 ])
(vec_concat:V2DF (reg:DF 75)
(const_int 0 [0]))) "pr99808.c":9 -1
(nil))
(insn 8 7 0 (set (r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99808
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=99037
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99037
--- Comment #4 from Jakub Jelinek ---
And my patch in the other PR was incorrect, should have just used CONST0_RTX
(mode); always.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99777
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99790
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99790
--- Comment #4 from Jakub Jelinek ---
Note, static vars are unaffected by this, because c_parse_final_cleanups calls
lower_var_init on them and that expands the PTRMEM_CSTs in there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99309
--- Comment #4 from Jakub Jelinek ---
In particular, we have:
step.val = 610334368;
and
_1 = m.val;
_2 = __builtin_constant_p (_1);
before inline, and inline assumes that this __builtin_constant_p will evaluate
to true. It will, but only i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99726
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99726
--- Comment #2 from Jakub Jelinek ---
And -flive-patching=inline-clone -mavx512f -O2 -floop-nest-optimize
-ftree-loop-vectorize -ftrapv -m32
is sufficient to trigger it.
I'm afraid I'm lost in what exactly the code wants to do.
dr_a.dr:
#(Data Re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #28 from Jakub Jelinek ---
So fixed for GCC 11 now?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96380
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Keywo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99802
Jakub Jelinek changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99813
--- Comment #2 from Jakub Jelinek ---
I think the bug is in swapped constraints on add3_poly_1.
We have:
(define_constraint "Uai"
"@internal
A constraint that matches a VG-based constant that can be added by
a single INC or DEC."
(match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99813
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=99825
Jakub Jelinek changed:
What|Removed |Added
Summary|ICE in |[11 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99825
Jakub Jelinek changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99781
Jakub Jelinek changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
--- Comment #13 from Jakub Jelinek ---
(In reply to Jonathan Wakely from comment #11)
> That tells me that using --with-long-double-format={ibm,ieee} chooses
> *which* of the 128-bit long double formats you want, and so
> --with-long-double-128 i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99814
--- Comment #7 from Jakub Jelinek ---
(In reply to Alex Richardson from comment #5)
> Does the sanitizer runtime library include the
> https://reviews.llvm.org/D96348 patch?
>
> IMO the real issue is that dlsym() with RTLD_NEXT selects the oldes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125
--- Comment #17 from Jakub Jelinek ---
As a quick hack, we could do e.g.
--- gcc/configure.ac2021-03-23 19:42:05.417907561 +0100
+++ gcc/configure.ac2021-03-30 14:54:31.655766205 +0200
@@ -3404,12 +3404,15 @@ AC_DEFINE_UNQUOTED(HAVE_GAS_S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125
--- Comment #18 from Jakub Jelinek ---
Another more targeted partial reversion:
2021-03-30 Jakub Jelinek
* targhooks.h (default_print_patchable_function_entry_1): Declare.
* targhooks.c (default_print_patchable_function_entry_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99813
--- Comment #5 from Jakub Jelinek ---
Oops, totally missed that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99813
Jakub Jelinek changed:
What|Removed |Added
Attachment #50487|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99790
Jakub Jelinek changed:
What|Removed |Added
Summary|[8/9/10/11 Regression] |[8/9/10 Regression]
|i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99790
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=99705
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99588
--- Comment #8 from Jakub Jelinek ---
Fixed for 10.3 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97680
Jakub Jelinek changed:
What|Removed |Added
Priority|P1 |P2
Summary|[11 Regression] ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99813
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99845
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
--- Comment #15 from Jakub Jelinek ---
So, just completely untested possibility:
--- libgcc/config/rs6000/t-float128.jj 2021-03-30 18:11:52.572091848 +0200
+++ libgcc/config/rs6000/t-float128 2021-03-31 13:55:47.199756547 +0200
@@ -90,8 +90,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
--- Comment #16 from Jakub Jelinek ---
Actually, there is code to handle that already, just with typos and omissions
in it.
So perhaps better:
2021-03-31 Jakub Jelinek
PR target/97653
* config/rs6000/t-linux (IBM128_STATIC_OBJ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99785
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99309
--- Comment #6 from Jakub Jelinek ---
(In reply to Jan Hubicka from comment #5)
> As discussed, I can prepare patch to make inliner to redirect
> __builtin_constant_p to __builtin_true whenever inliner detect that the
> expression is compile time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99490
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99850
--- Comment #2 from Jakub Jelinek ---
Are you sure it is incorrectly rejected?
http://eel.is/c++draft/expr.prim.lambda.general
says:
lambda-declarator:
lambda-specifiers
( parameter-declaration-clause ) lambda-specifiers requires-clause[op
301 - 400 of 12376 matches
Mail list logo
