https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084
--- Comment #5 from Aaron Ballman ---
(In reply to Marek Polacek from comment #4)
> But elaborated-enum-specifier is an elaborated-type-specifier, so
> [dcl.type.elab]#6 should still apply, right?
That is my understanding. Otherwise p6 doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084
--- Comment #6 from M Welinder ---
elaborated-enum-specifier can be a elaborated-type-specifier. It is in the
"enum Hog H;" case.
But elaborated-enum-specifier is NOT an elaborated-type-specifier in the "using
enum Hog;" case,
See http://eel.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102981
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
--- Comment #4 from Jeffrey A. Law
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084
--- Comment #7 from M Welinder ---
Maybe kick it up to the C++ people?
Note, that if the code is not allowed then a type alias is no longer as
powerful as the original type. I really doubt that was intended.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084
--- Comment #8 from Aaron Ballman ---
(In reply to M Welinder from comment #6)
> elaborated-enum-specifier can be a elaborated-type-specifier. It is in the
> "enum Hog H;" case.
>
> But elaborated-enum-specifier is NOT an elaborated-type-speci
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102869
Patrick Palka changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103058
--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #6)
> Looking at the particular ICE, this looks like a fortran frond-end issue -
> this is during compilation and not during link and I do not see why Fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103085
Wilco changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103082
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103073
--- Comment #6 from Martin Liška ---
> BTW, should I add new bugs to the meta-bug before or after they were
> confirmed?
Right after you create it I would say.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
seurer at gcc dot gnu.org changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
Bug ID: 103088
Summary: [12 regression] 500.perlbench from spec 2017 fails
since r12-4698
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103089
Bug ID: 103089
Summary: -Wmaybe-uninitialized -O2 false positive
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97121
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103089
--- Comment #1 from Andrew Pinski ---
If I add:
if (n <= 0 || m <= 0) __builtin_unreachable();
before the malloc, I get no warning.
I think the warning is correct if either n or m is negative.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103089
--- Comment #2 from xantares09 at hotmail dot com ---
indeed, I assumed both were positive, I guess there's no bug then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103089
xantares09 at hotmail dot com changed:
What|Removed |Added
Resolution|--- |INVALID
Stat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103090
Bug ID: 103090
Summary: [i386] GCC should use the SF and ZF flags in some
atomic_fetch_op sequences
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566
--- Comment #29 from Thiago Macieira ---
New suggestion in bug 103090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103069
--- Comment #2 from Thiago Macieira ---
See also bug 103090 for a few more (restricted) possibilities to replace a
cmpxchg loop with a LOCK RMW operation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086
--- Comment #1 from Jonathan Wakely ---
This affects the filesystem::path printer too:
impl = self.val['_M_cmpts']['_M_impl']['_M_t']['_M_t']['_M_head_impl']
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:a634928f5c8a281442ac8f5fb1636aed048ed72c
commit r12-4928-ga634928f5c8a281442ac8f5fb1636aed048ed72c
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086
--- Comment #3 from Jonathan Wakely ---
Fixed on trunk so far.
The fix needs to be backported to gcc-11 because std::tuple uses
[[no_unique_address]] there, so the bug is present.
I think it's also present on older branches, but would only sho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55227
--- Comment #11 from Will Wray ---
Created attachment 51737
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51737&action=edit
Proposed patch Nov 4
Sent to gcc-patches for review
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102967
--- Comment #7 from Martin Sebor ---
Both for the purposes of the warning (which can be more restrictive than what
the language considers valid), and in the C language, the semantics of the ->
expression depend on the first operand designating a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103090
--- Comment #1 from Thiago Macieira ---
One more:
bool tsign3(std::atomic &i)
{
// any two or more bits, so long as the sign bit is one of them
// (or the compiler doesn't know what's in the variable)
int bits = 1 | signbit;
r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102714
--- Comment #10 from Bo Duan ---
(In reply to Richard Biener from comment #7)
> (In reply to Bo Duan from comment #6)
> > Hello, should we backport this patch to gcc-10?
>
> It's scheduled for a backport to GCC 11, I'm not aware that GCC 10 is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101337
sandra at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |sandra at gcc dot
gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102991
--- Comment #6 from CVS Commits ---
The master branch has been updated by Xiong Hu Luo :
https://gcc.gnu.org/g:614b39757b8b61f70ac1c666edb7a01a5fc19cd4
commit r12-4930-g614b39757b8b61f70ac1c666edb7a01a5fc19cd4
Author: Xionghu Luo
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102991
--- Comment #7 from luoxhu at gcc dot gnu.org ---
Fixed, will backport to gcc-11 in a week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103066
--- Comment #1 from Hongyu Wang ---
__sync_val_compare_and_swap will be expanded to atomic_compare_exchange_strong
by default, should we restrict the check and return under
atomic_compare_exchange_weak which is allowed to fail spuriously?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103091
Bug ID: 103091
Summary: Can't jump into scope of a variable with a nontrivial
destructor in C++20
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Keywords: re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103091
Andrew Pinski changed:
What|Removed |Added
Blocks||94404
Alias|cwg2256
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103091
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-11-05
Status|UNCONFIRM
101 - 134 of 134 matches
Mail list logo
