https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80408
--- Comment #6 from Raphael Monod ---
Thank you very much for your explanations. Now I understand why I was wrong. I
will try to change my code to take into account your suggestions.
Once more, thank you very much.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52320
Jonathan Wakely changed:
What|Removed |Added
Keywords||wrong-code
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87921
Jason Merrill changed:
What|Removed |Added
Summary|[7/8/9 Regression] |[7/8 Regression] Incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89405
Jakub Jelinek changed:
What|Removed |Added
Summary|[8/9 Regression] ICE in |[8 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88690
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89403
Jakub Jelinek changed:
What|Removed |Added
Summary|[7/8/9 Regression] ICE in |[7/8 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52130
--- Comment #5 from Jonathan Wakely ---
The relevant text in the standard is:
"A scoped enumeration shall not be later redeclared as unscoped or with a
different underlying type. An unscoped enumeration shall not be later
redeclared as scoped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89428
Bug ID: 89428
Summary: missing -Wstringop-overflow on a PHI with variable
offset
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271
--- Comment #11 from Vladimir Makarov ---
(In reply to Alan Modra from comment #5)
> Created attachment 45760 [details]
> Current set of patches
>
> It turns out there is a lot more than just wrong register_move_cost. This
> patchset does fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89313
Peter Bergner changed:
What|Removed |Added
Keywords|ice-on-invalid-code |ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87921
--- Comment #3 from Jason Merrill ---
Author: jason
Date: Thu Feb 21 02:24:40 2019
New Revision: 269064
URL: https://gcc.gnu.org/viewcvs?rev=269064=gcc=rev
Log:
PR c++/87921 - wrong error with inline static data member.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89415
Bug ID: 89415
Summary: gcc.dg/sinatan-1.c FAILs
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89415
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86487
--- Comment #12 from avieira at gcc dot gnu.org ---
Author: avieira
Date: Wed Feb 20 14:11:43 2019
New Revision: 269039
URL: https://gcc.gnu.org/viewcvs?rev=269039=gcc=rev
Log:
[GCC] PR target/86487: fix the way 'uses_hard_regs_p' handles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89415
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89366
--- Comment #2 from Bader at lrz dot de ---
Fortran 2018 FDIS section 18.3.6, para 2, item 5, bullet 2:
(5) any dummy argument without the VALUE attribute corresponds to a formal
parameter of the prototype that is of a pointer type, and either
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88973
--- Comment #6 from Martin Liška ---
(In reply to Bruce Korb from comment #5)
> (In reply to Martin Sebor from comment #4)
>
> > canonicalize_pathname.c: In function ‘canonicalize_pathname’:
> > canonicalize_pathname.c:61:2: warning: ‘strcpy’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89415
--- Comment #2 from Christophe Lyon ---
I'm not sure it's worth opening another regression report, but that same commit
creates regressions in fortran on arm:
FAIL: gfortran.dg/integer_exponentiation_3.F90 -O0 (test for warnings, line
173)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89405
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89414
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89409
--- Comment #4 from H.J. Lu ---
A patch is posted at
https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01645.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89415
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
Eric Gallager changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89366
--- Comment #3 from Bader at lrz dot de ---
Created attachment 45771
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45771=edit
C code to be called
Added the C side function call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89414
Bug ID: 89414
Summary: wrong code with -Og -fno-forward-propagate
-fno-tree-fre
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89415
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89385
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88973
--- Comment #7 from Martin Liška ---
(In reply to Martin Sebor from comment #4)
> I've created a test case using the canonicalize_pathname function showing
> that it does, in fact, cause an overlap to take place. The following line
> in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89348
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89366
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89416
Bug ID: 89416
Summary: [regression] std::vector::push_back no longer builds.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46496
--- Comment #5 from Dominique d'Humieres ---
b) -Wno-c-binding-type silences the warnings related to C binding.
It remains in this PR the missed warnings in d) and e).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89414
--- Comment #2 from Jakub Jelinek ---
-march=armv7-a -mfpu=vfpv4 -mfloat-abi=hard -Og -fno-forward-propagate
-fno-tree-fre is what I've been using for options.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89397
--- Comment #5 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Feb 20 15:23:47 2019
New Revision: 269040
URL: https://gcc.gnu.org/viewcvs?rev=269040=gcc=rev
Log:
Revert:
PR target/89397
* config/i386/i386.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88973
--- Comment #8 from Martin Sebor ---
The Asan warning is much clearer because it's based on actually observed
values. This instance of the -Wrestrict warning is based on a heuristic: "we
think the copy may overlap because it is within the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89418
seurer at gcc dot gnu.org changed:
What|Removed |Added
Target||powerpc64le-unknown-linux-g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
--- Comment #10 from David Malcolm ---
(In reply to Jonny Grant from comment #4)
> There's another related issue, can it be covered on this ticket?
>
> GCC does not show the part of the output below I marked with after
> commenting out line 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89412
--- Comment #4 from Jakub Jelinek ---
Started with r237429. Don't know why this has anything to do with libgfortran
powerpc64le-linux bootstrap, that worked for me just fine in 8.3-rc1.
Slightly adjusted testcase:
struct S { double a, b; } d;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
--- Comment #5 from Jonny Grant ---
What appears to be a related issue. the "line number out of supported range"
does not show, even when gcc outputs a negative line number. Three test cases
below
I believe that the #line that pushes beyond
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89366
--- Comment #5 from Bader at lrz dot de ---
No. The dummy argument of the procedure process_string is declared
character(kind=c_char,len=*), intent(in) :: this
there is no POINTER or ALLOCATABLE attribute there.
Regards
Reinhold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80505
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89409
--- Comment #5 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Wed Feb 20 16:20:50 2019
New Revision: 269042
URL: https://gcc.gnu.org/viewcvs?rev=269042=gcc=rev
Log:
libsanitizer: Restore internal_readlink for x32
Cherry-pick compiler-rt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35592
--- Comment #8 from Eric Gallager ---
Created attachment 45777
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45777=edit
testcase
(In reply to felix-gcc from comment #6)
> Sure. For example:
>
> char* c=malloc(lseek(somefd,0,SEEK_END);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
--- Comment #8 from Segher Boessenkool ---
The C standard does not allow the line number (in a #line directive) to be
smaller than 1 or bigger than 0x7fff. It says nothing about actually
having this many lines, or overflowing the line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89419
Bug ID: 89419
Summary: [8/9 Regression] ICE in is_normal_capture_proxy
starting with r253601
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89412
--- Comment #5 from Matthias Klose ---
bug title was a cut and paste error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
--- Comment #6 from Jonny Grant ---
Could this show the offending number in the "line number out of range" message?
And even the origin of the LINE1 macro too?
Actual:
#1 with x86-64 gcc (trunk)
: In function 'main':
:4:7: warning: line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89091
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|dmalcolm at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89091
--- Comment #6 from David Malcolm ---
Created attachment 45774
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45774=edit
Patch
I came up with this patch; it survives bootstrap, but am not sure
if it's correct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89397
--- Comment #6 from Uroš Bizjak ---
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 269040)
+++ config/i386/i386.c (working copy)
@@ -50689,7 +50689,7 @@
static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
--- Comment #7 from Jonny Grant ---
(In reply to Jonny Grant from comment #6)
> Could this show the offending number in the "line number out of range"
> message? And even the origin of the LINE1 macro too?
clang shows the origin of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89417
Bug ID: 89417
Summary: helgrind detects a lock order violation inside
std::scoped_lock
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89418
Bug ID: 89418
Summary: D test cases fail on powerpc64le
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80204
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88572
Will Wray changed:
What|Removed |Added
Attachment #45683|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89385
Paul Thomas changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89419
Jakub Jelinek changed:
What|Removed |Added
Keywords||ice-on-valid-code
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89091
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88347
Segher Boessenkool changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87844
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89412
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86395
Eric Gallager changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #7 from Eric
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53063
Eric Gallager changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #12 from Eric
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84889
Eric Gallager changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #15 from Eric
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
--- Comment #9 from Jonny Grant ---
(In reply to Segher Boessenkool from comment #8)
> The C standard does not allow the line number (in a #line directive) to be
> smaller than 1 or bigger than 0x7fff. It says nothing about actually
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89366
--- Comment #4 from Dominique d'Humieres ---
> Fortran 2018 FDIS section 18.3.6, para 2, item 5, bullet 2:
On my draft it is probably
18.3.7 Interoperability of procedures and procedure interfaces
For
character(kind=c_char,len=:),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89091
--- Comment #8 from Jakub Jelinek ---
Comment on attachment 45774
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45774
Patch
Well, for the decode_field_reference, I think it is essential not to change
*exp_ if returning NULL, because the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88055
Segher Boessenkool changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89270
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P4
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52130
Eric Gallager changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89308
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |SUSPENDED
--- Comment #9 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88294
--- Comment #6 from Marek Polacek ---
A similar test crashes:
bool b;
template struct A
{
void g () noexcept (b) { }
};
int main ()
{
A a;
a.g ();
}
but that's PR88987.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89357
Martin Sebor changed:
What|Removed |Added
Keywords|accepts-invalid |rejects-valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89420
Bug ID: 89420
Summary: [9 Regression] ICE: unexpected expression 'int()' of
kind cast_expr
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89423
ctice at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89421
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89420
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89420
Marek Polacek changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80408
--- Comment #4 from Raphael Monod ---
Thank you for your answer. But I don't understand why adding -lpthread option
change the behavior if I do not use any thread. Moreover, if I refer to this
page (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89400
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
--- Comment #11 from Segher Boessenkool ---
(In reply to Jonny Grant from comment #9)
> Maybe zero could be disallowed too.
Yes, but maybe we need that for historical reasons.
> Not sure what is best here, I'm not knowledgeable of GCC, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84530
Ev Drikos changed:
What|Removed |Added
CC||drikosev at gmail dot com
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88380
--- Comment #3 from Jason Merrill ---
Author: jason
Date: Wed Feb 20 18:54:45 2019
New Revision: 269046
URL: https://gcc.gnu.org/viewcvs?rev=269046=gcc=rev
Log:
PR c++/88380 - wrong-code with flexible array and NSDMI.
Here 'skipped'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87513
--- Comment #10 from Jason Merrill ---
Author: jason
Date: Wed Feb 20 18:59:18 2019
New Revision: 269048
URL: https://gcc.gnu.org/viewcvs?rev=269048=gcc=rev
Log:
PR c++/87513 - 'sorry' mangling PMF template-id.
Here build_offset_ref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
--- Comment #12 from Jonny Grant ---
Just to add
C spec says UB.
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
"The #line preprocessing directive that results after expansion does not match
one of
the two well-defined forms, or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89418
--- Comment #2 from seurer at gcc dot gnu.org ---
real.mant_dig is 106 on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89177
--- Comment #4 from Bernd Edlinger ---
(In reply to Johannes Pfau from comment #2)
> Thanks for the bug report & patch. It seems upstream phobos has already
> fixed this in a different way:
>
> https://github.com/dlang/phobos/commit/
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89421
Bug ID: 89421
Summary: [9 Regression] ICE in retrieve_specialization, at
cp/pt.c:1245
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89403
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314
--- Comment #25 from Wilco ---
(In reply to Steve Ellcey from comment #24)
> See email strings at:
>
> https://gcc.gnu.org/ml/fortran/2019-01/msg00276.html
> https://gcc.gnu.org/ml/fortran/2019-02/msg00057.html
>
> For more discussion.
Sure,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89423
Bug ID: 89423
Summary: -fvtable-verify does not work properly with -flto
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89400
Jakub Jelinek changed:
What|Removed |Added
CC||ramana at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89422
Bug ID: 89422
Summary: [8/9 Regression] ICE in field_byte_offset, at
dwarf2out.c:19086
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88572
--- Comment #17 from Jason Merrill ---
Author: jason
Date: Wed Feb 20 18:50:32 2019
New Revision: 269045
URL: https://gcc.gnu.org/viewcvs?rev=269045=gcc=rev
Log:
PR c++/88572 - wrong handling of braces on scalar init.
* decl.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89418
--- Comment #3 from Andrew Pinski ---
Funny. real.mant_dig == 106 means 128bit IBM long double (or as some call it,
double-double as the error message suggest).
The error message is incorrect in both cases too:
"Only 64-bit, 80-bit, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86248
--- Comment #4 from Harald Anlauf ---
Some digging shows that the name mangling is done in trans-decl.c,
gfc_sym_mangled_identifier. Strangely, the funny name mangling comes
from the component fn_result_spec being set in resolve.c,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87513
Jason Merrill changed:
What|Removed |Added
Summary|[8/9 Regression] ICE in |[8 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84889
David Malcolm changed:
What|Removed |Added
Status|WAITING |ASSIGNED
Target Milestone|9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89336
--- Comment #8 from Jakub Jelinek ---
Author: jakub
Date: Wed Feb 20 21:16:27 2019
New Revision: 269052
URL: https://gcc.gnu.org/viewcvs?rev=269052=gcc=rev
Log:
PR c++/89336
* constexpr.c (cxx_eval_store_expression): Diagnose
1 - 100 of 153 matches
Mail list logo
