https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97358
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97256
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97222
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97256
--- Comment #6 from Richard Smith ---
My apologies, I misread the testcase. Yes, this is UB.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98217
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55120
--- Comment #11 from Richard Smith
---
(In reply to Jonathan Wakely from comment #10)
> It looks like Clang has a bug with the inaccessible constructor too, and
> strangely inconsistent handling of the inaccessible destructor.
Access checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98859
Bug ID: 98859
Summary: pedantic error on use of __VA_OPT__ before C++20 is
unnecessary and counterproductive
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100640
Bug ID: 100640
Summary: GCC permits explicit instantiation of a constructor
template with an explicit template argument list
Product: gcc
Version: 12.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101370
Bug ID: 101370
Summary: miscompile of self-referential constexpr or constinit
array initializer
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98804
--- Comment #1 from Richard Smith ---
Somewhat more reduced:
struct X { constexpr X(int&) {} };
template struct Y {};
int a;
auto h(int b) -> Y; // #1
auto h(int b) -> Y; // #2
GCC accepts #1, but for #2 it produces seven (!) error messages:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99534
Bug ID: 99534
Summary: bogus UDL diagnostic for header-name followed by macro
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99176
Bug ID: 99176
Summary: GCC rejects const_cast of null pointer in constant
expressions
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99209
--- Comment #1 from Richard Smith ---
Here's a more interesting example: https://godbolt.org/z/83c36q
#include
constexpr char f(...) { return 'g'; }
constexpr decltype(auto) f_adl(auto a) { return f(a); }
namespace A {
constexpr char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99209
Bug ID: 99209
Summary: lambdas in function template signatures instantiated
with wrong semantic context
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102071
Bug ID: 102071
Summary: crash when combining -faligned-new=N with array cookie
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91292
--- Comment #7 from Richard Smith ---
(In reply to Patrick Palka from comment #3)
> Hmm, but according to
> http://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling.literal the
> mangling of a negative integer literal is prefixed with "n",
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94295
--- Comment #8 from Richard Smith ---
(In reply to Jonathan Wakely from comment #7)
> Richard S., is there any reason to use the built-ins for the constant
> evaluation case?
No, Clang's constant evaluator treats the built-ins and calls to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111923
--- Comment #9 from Richard Smith ---
I don't think we intended for default arguments of class-scope lambdas to get
the same complete-class context treatment as default argument of member
functions, but the standard wording does currently seem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111633
Bug ID: 111633
Summary: __restrict on a member function is permitted in an
inconsistent location relative to ref-qualifiers
Product: gcc
Version: 14.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112455
Bug ID: 112455
Summary: befriending a lambda closure type doesn't grant access
to the lambda body
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108090
Bug ID: 108090
Summary: pack expansion of using declarations doesn't properly
handle dependent conversion function names
Product: gcc
Version: unknown
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #16 from Richard Smith
---
(In reply to Richard Biener from comment #15)
> I was specifically looking at C++20 7.6.2.7/10 to /14 (but maybe also
> others and of course the relevant parts of the delete expression). In
> particular
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109654
Bug ID: 109654
Summary: unnecessary "cannot bind packed field to reference"
error when referenced type has aligned(1) attribute
Product: gcc
Version: unknown
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109654
--- Comment #2 from Richard Smith ---
Hm, that doesn't explain why the second example I gave is accepted. But I
suppose what's happening there is probably just that the `packed` attribute is
ignored entirely for fields with alignment 1, so this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #14 from Richard Smith
---
If I understand correctly, you're looking for documentation that
__builtin_operator_new(size)
has the exact same semantics and permits the same optimizations as `::new T`
for a trivially-constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100825
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109422
--- Comment #1 from Richard Smith ---
> This should instead be mangled as T_TL__
Sorry, that's wrong; the rule we ended up with would mangle this as T_TL0__.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109422
Bug ID: 109422
Summary: wrong depth used for template parameter mangling for
lambdas in function signatures
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109337
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110101
Bug ID: 110101
Summary: inconsistent behavior for array-to-pointer decay in
constant evaluation in template argument
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31584
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110938
--- Comment #4 from Richard Smith ---
Looks like the trait difference only happens if the templated constructor is
not deleted, but the ABI mismatch happens regardless. Possibly there are two
separate issues here?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110938
Bug ID: 110938
Summary: miscompile if implicit special member is deleted in a
subtle way
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
33 matches
Mail list logo
