https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105386
Richard Biener changed:
What|Removed |Added
Summary|Tuple in unevaluated|[11/12 Regression] Tuple in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105385
--- Comment #2 from Richard Biener ---
IIRC gmp/mpfr have no good way to report errors like this up the chain and so
they abort ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105384
--- Comment #5 from Richard Biener ---
The bessel functions are known to take a lot of time, there are (fixed?) older
bugreports about those and we do take some measures to speed up the
computation.
We might want to give up the idea on producing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105383
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105379
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105376
Richard Biener changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105374
--- Comment #8 from Richard Biener ---
(In reply to Jakub Jelinek from comment #2)
> This can (and IMHO should no matter what) be fixed in reassoc by:
> --- gcc/tree-ssa-reassoc.cc.jj2022-04-14 13:46:59.690140053 +0200
> +++ gcc/tree-ssa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105338
--- Comment #13 from denis.campredon at gmail dot com ---
Thanks a lots.
I have a question though: foo and bar are similar, foo produces a branchless
code whereas bar uses a jump.
int foo(int i) {
return !i ? 0 : -2;
}
int bar(int i) {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102629
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=104624
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:65735d21ac410463126114c572999682f987972c
commit r12-8258-g65735d21ac410463126114c572999682f987972c
Author: Jason Merrill
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104624
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105304
Patrick Palka changed:
What|Removed |Added
Summary|[10/11/12 Regression] ICE |[10/11 Regression] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105304
--- Comment #2 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:c83b9c54d9dee2dce5d8268472a745b013d166cc
commit r12-8257-gc83b9c54d9dee2dce5d8268472a745b013d166cc
Author: Patrick Palka
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105289
--- Comment #3 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:288e4c64f6b4806358aabc9b99b2fba72bf04bf6
commit r12-8256-g288e4c64f6b4806358aabc9b99b2fba72bf04bf6
Author: Patrick Palka
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86193
--- Comment #4 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:288e4c64f6b4806358aabc9b99b2fba72bf04bf6
commit r12-8256-g288e4c64f6b4806358aabc9b99b2fba72bf04bf6
Author: Patrick Palka
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105386
Bug ID: 105386
Summary: Tuple in unevaluated context is instantiated; creates
reference to void
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105314
--- Comment #8 from Christoph Müllner ---
Yes, I was wrong in my previous comment.
Jakub's patch is of course right.
The transformation in noce_try_store_flag_mask() does:
x = cond ? 0 else b // b may be x
==>
target = cond ? 0 : -1; /
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104308
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105366
David Malcolm changed:
What|Removed |Added
Summary|[11/12 Regression] ICE: in |[11 Regression] ICE: in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105365
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105365
--- Comment #3 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:6ad3ca0077ec0d5f740cef5fdb743ffb61575941
commit r12-8254-g6ad3ca0077ec0d5f740cef5fdb743ffb61575941
Author: David Malcolm
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105366
--- Comment #3 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:6ad3ca0077ec0d5f740cef5fdb743ffb61575941
commit r12-8254-g6ad3ca0077ec0d5f740cef5fdb743ffb61575941
Author: David Malcolm
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104308
--- Comment #11 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:a5dc2641add6b4f54086d40ae706fda3cdaac7f5
commit r12-8253-ga5dc2641add6b4f54086d40ae706fda3cdaac7f5
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105314
--- Comment #7 from ptomsich at gcc dot gnu.org ---
The transformation for
"""
long func2 (long a, long b, long c)
{
if (c)
a = 0;
else
a = 5;
return a;
}
"""
into
"""
0006 :
6: 00163513
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100252
--- Comment #8 from Marek Polacek ---
This is tricky, because we end up with
{.x=(&)->x, .y=(&)->x}
that is, two PLACEHOLDER_EXPRs for different types on the same level in one {
}, so our CONSTRUCTOR_PLACEHOLDER_BOUNDARY mechanism to avoid rep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105314
--- Comment #6 from Christoph Müllner ---
The proposed fix is triggering an invalid transformation.
The pattern we need to transform is:
Convert "if (test) x = 0;" to "x &= -(test == 0);"
If there is an else branch, we can't apply the transf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105314
--- Comment #5 from ptomsich at gcc dot gnu.org ---
The fix addresses the issue and generates no new failures on small test cases.
Testing against SPEC is still ongoing and I'll report back once that has
completed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329
Mattias Ellert changed:
What|Removed |Added
CC||mattias.ellert at physics dot
uu.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105358
--- Comment #9 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #8)
> Created attachment 52865 [details]
> gcc12-pr105358.patch
>
> So what about this? All the newly added comparisons should fold into true
> or false at compile tim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349
Segher Boessenkool changed:
What|Removed |Added
Attachment #52871|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105362
--- Comment #2 from Pavel M ---
I do believe that evaluation of constant expressions in conditional inclusion
is done according to the rules of constant expressions ("except that ...", see
C11, 6.10.1/1). Hence, I expect the same diagnostics in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105381
Mikael Morin changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105381
--- Comment #1 from Mikael Morin ---
Draft patch.
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index e4b6270ccf8..e0070aa080d 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -3698,7 +3698,8 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105379
--- Comment #3 from Mikael Morin ---
Created attachment 52876
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52876&action=edit
Draft patch
This shows no testsuite regression.
But there is something that I want to check before submitting i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104717
--- Comment #9 from CVS Commits ---
The master branch has been updated by Thomas Schwinge :
https://gcc.gnu.org/g:b2202431910e30d8505c94d1cb9341cac7080d10
commit r12-8252-gb2202431910e30d8505c94d1cb9341cac7080d10
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103993
andre at kostur dot net changed:
What|Removed |Added
CC||andre at kostur dot net
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105385
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Ever confi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105384
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105383
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105381
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2022-04-25
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105380
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2022-04-25
Summary|[PDT] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105379
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Sum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104336
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105377
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105384
--- Comment #3 from Zdenek Sojka ---
(In reply to Andrew Pinski from comment #2)
> Can you try the one that is downloaded via contrib/download_pre*.
The you for the comment. The versions I am using are:
[ebuild R] dev-libs/gmp-6.2.1-r2
[
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105384
--- Comment #2 from Andrew Pinski ---
Can you try the one that is downloaded via contrib/download_pre*.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105385
Bug ID: 105385
Summary: ICE: Aborted (in do_mpfr_arg2): GNU MP: Cannot
allocate memory (size=3458764513820540832) with
__builtin_jn{,f,l}
Product: gcc
Version: 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105384
--- Comment #1 from Andrew Pinski ---
What version of gmp, mpfr are you using?
runk//binary-trunk-r12-8242-20220425114659-gf0e170f72f8-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220425 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
--- Comment #4 from Iain Sandoe ---
I'm guessing that a reproducer is going to be hard to arrange (from the
"complex piece of code") even though the failing point is well-defined?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105287
--- Comment #6 from Iain Sandoe ---
(In reply to David Malcolm from comment #5)
> Thanks. FWIW I've filed PR 105382 to track the various other issues I'm
> seeing with -fanalyzer with coroutines (though given that we don't properly
> support C+
x-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-8242-20220425114659-gf0e170f72f8-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220425 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105287
--- Comment #5 from David Malcolm ---
Thanks. FWIW I've filed PR 105382 to track the various other issues I'm seeing
with -fanalyzer with coroutines (though given that we don't properly support
C++ yet, that's relatively low priority for me).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105382
Bug ID: 105382
Summary: Support for coroutines in -fanalyzer
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105381
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||compile-time-hog
Target Mi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105381
Bug ID: 105381
Summary: [12 Regression] Memory-hog since r12-8230
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104336
Mattias Ellert changed:
What|Removed |Added
CC||mattias.ellert at physics dot
uu.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349
Segher Boessenkool changed:
What|Removed |Added
Attachment #52870|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105379
Mikael Morin changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349
Segher Boessenkool changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349
--- Comment #13 from Segher Boessenkool ---
Ah, it needs check_no_compiler_messages_nocache in these tests. Patch
attached.
Could you please test with it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329
--- Comment #5 from Andrew Macleod ---
Before inlining, the general code see:
if (_27 <= __s_53(D))
goto ; [INV]
else
goto ; [INV]
_34 = _27 - __s_53(D);
__nleft_64 = (const size_type) _34
THe branch now registers the relatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349
--- Comment #12 from Jakub Jelinek ---
I said that above, -mdejagnu-cpu=power10 isn't passed to the effective target
snippet compilation, so it doesn't test whether the test with
-mdejagnu-cpu=power10 will be power10, but rather tests whether th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349
--- Comment #11 from seurer at gcc dot gnu.org ---
It is still failing with latest trunk:
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349
--- Comment #10 from Segher Boessenkool ---
The feature test output you show was run without the dg-options... Something
is seriously wrong if that is the one that was used!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349
--- Comment #9 from Segher Boessenkool ---
Ah, lol. Yes. But please don't change this yet, it should work thew way it
is now, this should be fixed. Do you see what makes the _ARCH_PWR10 test
fail on your system?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349
--- Comment #8 from Jakub Jelinek ---
As it uses -mdejagnu-cpu=power10, it only tests power10 code generation,
nothing else.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349
--- Comment #7 from Segher Boessenkool ---
The test generates the expected code for all other cpus.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349
--- Comment #6 from Jakub Jelinek ---
Somehow that doesn't really work, in the log I see that has_arch_pwr10 is
tested but yields it is not on:
/usr/src/gcc/objp16/gcc/xgcc -B/usr/src/gcc/objp16/gcc/ arch_pwr101791933.c
-m32 -fdiagnostics-pla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349
--- Comment #5 from Segher Boessenkool ---
And that is what the {xfail {has_arch_pwr10 && {! has_arch_ppc64}}}
is for. Does that not work for you? Why doesn't it, it works fine here?
It would be nice if this unimportant edge case was costed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105374
--- Comment #7 from Martin Liška ---
(In reply to Martin Liška from comment #6)
> Btw. started with r12-7338-g884f77b489 if that helps.
Oh, it was already discovered by Jakub.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105374
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2022-04-25
Ever confirmed|0
1,1
@@ -39,6 +40,6 @@ bswap_int_dbl:
.cfi_endproc
.LFE1:
.size bswap_int_dbl,.-bswap_int_dbl
- .ident "GCC: (GNU) 12.0.1 20220310 (experimental)"
+ .ident "GCC: (GNU) 12.0.1 20220425 (experimental)"
.gnu_attribute 4, 1
.section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105375
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |11.4
--- Comment #8 from Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105380
G. Steinmetz changed:
What|Removed |Added
Keywords||ice-on-valid-code
--- Comment #1 from G.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105380
Bug ID: 105380
Summary: ICE in gfc_conv_array_initializer, at
fortran/trans-array.cc:6317
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105379
Bug ID: 105379
Summary: [12 Regression] ICE in gfc_compare_array_spec(): Array
spec clobbered
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105375
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:a5cee0480c10bafa8ed65d49e5cedca23d98d7b7
commit r12-8249-ga5cee0480c10bafa8ed65d49e5cedca23d98d7b7
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105366
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #2 from David Malc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105365
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #2 from David Malc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105314
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105374
--- Comment #5 from Christophe Lyon ---
> Regarding the dg-* directives, I suspect you need arm_v8_1m_mve_fp_ok since
> the test involves floats.
I was wrong and your proposal of arm_v8_1m_mve_ok looks fine (since actually
there is no ICE with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105353
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105353
--- Comment #7 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:1ba397e9f93d3abc93a6ecbabc3d873489a6fb7f
commit r12-8248-g1ba397e9f93d3abc93a6ecbabc3d873489a6fb7f
Author: Marek Polacek
Date: Fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105348
--- Comment #3 from Thiago Macieira ---
I understand. I'm just trying to avoid having to add code for a corner-case.
People don't usually parse empty buffers, so it's usually fine to allow it to
proceed and discover an EOF condition.
Anyway, wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105375
--- Comment #6 from Jonathan Wakely ---
(In reply to raldone01 from comment #5)
> Thank you for your reply.
> What does that mean?
As it says at the link in comment 4, "The following behavior-changing defect
reports were applied retroactively t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105338
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105377
--- Comment #4 from Jonathan Wakely ---
But we don['t want to use gnu++17 because we want the compiler to be built
using portable ISO C++17. An unrecognized attribute is a portable ISO C++17
construct, it just doesn't do anything (except maybe g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105374
--- Comment #4 from Christophe Lyon ---
Other MVE tests are in gcc.target/arm/simd/ (eg mve-vcmp-f32.c), maybe it's
best to keep them in the same place?
Regarding the dg-* directives, I suspect you need arm_v8_1m_mve_fp_ok since the
test involv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105276
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105378
Bug ID: 105378
Summary: [OpenMP][5.1] 'nowait' on 'taskwait' not supported
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105377
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105276
--- Comment #4 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:362e2a9c6297203bcf7f66bfb51dffb82b42d3b3
commit r12-8246-g362e2a9c6297203bcf7f66bfb51dffb82b42d3b3
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105377
--- Comment #2 from Marek Polacek ---
Yes, I'd prefer to keep it the way it is.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105377
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105375
--- Comment #5 from raldone01 ---
Thank you for your reply.
What does that mean?
Are defect reports updates for older standards?
Is it meant to be available at some point in c++17?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105374
--- Comment #3 from Jakub Jelinek ---
Also, no idea where exactly to put the testcase to and what dg-* directives to
use, arm testcases is something I'm really not familiar with.
Perhaps gcc.target/arm/mve/general
and
/* { dg-do compile } */
/*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105377
Bug ID: 105377
Summary: Likely a misleading clang warning
-Wc++20-attribute-extensions
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105374
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |12.0
Priority|P3
1 - 100 of 165 matches
Mail list logo
