https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98423
Bug ID: 98423
Summary: The defaulted default constructor defined as deleted
when one of variant member has a default member
initializer
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98424
Bug ID: 98424
Summary: The point of destroying temporary objects when
initializing an array
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98554
Bug ID: 98554
Summary: why the explicit conversion function of derived class
return type is not a candidate in the context of
direct-initialization
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98816
Bug ID: 98816
Summary: The thread_local specifier appear on the declaration
of static member function is compilied by gcc
Product: gcc
Version: 10.2.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101356
Bug ID: 101356
Summary: The non-public member of a local class cannot be
accessed by a friend of the class
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99399
--- Comment #1 from jim x ---
All the quotes refer to n4861.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99262
Bug ID: 99262
Summary: The decltype-specifier that denotes a destructor in a
function call is rejected by GCC
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99263
Bug ID: 99263
Summary: A qualified-id that denotes a destructor of a class
type that is used as an operand of `typeid` is
accepted by GCC
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99399
Bug ID: 99399
Summary: why does not a pack expansion that is a
using-delcaration which intends to introduce the base
classes's constructor accept by GCC
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99192
Bug ID: 99192
Summary: A wrong Aggregate initialization for a union with a
variant member of non-aggregate class type
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99160
Bug ID: 99160
Summary: A wrong accessible check when using a
using-declaration that introduces the names of type
and function
Product: gcc
Version: 10.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99160
--- Comment #6 from jim x ---
struct A{
struct Name{};
void Name(){}
};
struct B:A{
using A::Name; //#1
};
int main() {
struct B::Name d;
}
According to [basic.lookup#general-4], the lookup set occurs at `#1` would
discard the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102157
Bug ID: 102157
Summary: floating-integral conversions is not permitted in the
user-defined conversion sequence in converted constant
expression
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102158
Bug ID: 102158
Summary: Specialized non-type template argument violates
[temp.spec.partial#general-9] but accepted by GCC
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99160
--- Comment #4 from jim x ---
[namespace.udecl#1] says
> Each using-declarator in a using-declaration names the set of declarations
> found by lookup ([basic.lookup.qual]) for the using-declarator, except that
> class and enumeration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102004
Bug ID: 102004
Summary: The opaque-enum-declaration whose enum-head-name
contains a nest-name-specifier should be permitted in
an explicit specialization
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102157
--- Comment #2 from jim x ---
bind the temporary is permitted here to me. Since the template parameter is not
a reference type, there is no restriction on whether a temporary object is
generated in the implicit conversion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102212
Bug ID: 102212
Summary: The explicit conversion function should be permitted
in direct-initialization of a reference
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102321
Bug ID: 102321
Summary: A partial comment at the end of file should be
ill-formed
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102357
Bug ID: 102357
Summary: The type specified by explicitly defaulted special
member function that is different with it should have
had is well-formed
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102357
--- Comment #2 from jim x ---
This part in c++20 is more clear than c++17, which is added since c++20, see
https://timsong-cpp.github.io/cppwp/n4861/dcl.fct.def.default#2. What the
version I'm testing the code is GCC 12.0 with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102357
--- Comment #4 from jim x ---
I haven't found that pull request. However, the proposal sources from P0641R2,
see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0641r2.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101458
Bug ID: 101458
Summary: An invalid covaraint return type is accepted
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101740
Bug ID: 101740
Summary: The symbol "<" after a name follows "~" as an
id-expression of a member access expression should be
interpreted as a delimiter of template-argument-list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101828
Bug ID: 101828
Summary: The invocation of a virtual function for an object
that is not usable in constant expression is accepeted
by GCC
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101771
Bug ID: 101771
Summary: The keyword "typename" is illegal used in a
using-declaration that introduces the non-type
declarations
Product: gcc
Version: 12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65969
--- Comment #5 from jim x ---
The last two cases seem to be not a bug to me. The standard says(cite the c++20
standard)
> If a using-declarator uses the keyword typename and specifies a dependent
> name ([temp.dep]), the name introduced by the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101687
Bug ID: 101687
Summary: Scoped enumerators of a member enumeration shall not
be referred by a class member access expression
Product: gcc
Version: 11.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98424
--- Comment #2 from jim x ---
Clang destroys them at the end of the full-expression, see
https://godbolt.org/z/3xhPjoh8c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102514
Bug ID: 102514
Summary: The allocation function shall not be called when
existing an erroneous expression in
noptr-new-declarator
Product: gcc
Version: 12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102514
--- Comment #2 from jim x ---
It seems that they all do not obey [expr.new] p9, which says that
If the expression in a noptr-new-declarator is present, it is implicitly
converted to std::size_t. The expression is erroneous if:
- the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103512
Bug ID: 103512
Summary: The failure of the substitution in explicit-specifier
should be considered when overload resolution
Product: gcc
Version: 11.2.1
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84699
jim x changed:
What|Removed |Added
CC||xmh970252187 at gmail dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103902
Bug ID: 103902
Summary: Only the addition space between string-literal and
identifier in a literal-operator-id will be accepted
by GCC where the identifier is not in a basic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103740
Bug ID: 103740
Summary: A function template declaration with a
template-parameter in the last that has no default
argument or can be deduced shall be ill-formed
Product:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69623
--- Comment #7 from jim x ---
In a simple way, the rule just requires that, for a function template, the
template parameter that is declared after a template parameter pack should
either appear in the parameter-declaration-clause before the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69623
--- Comment #9 from jim x ---
After reading [temp.deduct.call] p1 more carefully, I think you're right. Since
the first function parameter pack does not participate in template argument
deduction, the deduction will start to perform from the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104487
Bug ID: 104487
Summary: The substitution in the dependent name in a trailing
return type should cause recursive instantiation
Product: gcc
Version: 11.1.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104487
--- Comment #3 from jim x ---
I think Clang is correct here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112423
Bug ID: 112423
Summary: A weird reported diagnosis about user-defined-literal
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105789
Bug ID: 105789
Summary: The instance of a deallocation function template is
never a usual deallocation function
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105985
Bug ID: 105985
Summary: The case of "indirectly" exported by the primary
module interface unit is not accepted
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106294
Bug ID: 106294
Summary: GCC accepts the undefined behavior operation in a
constant expression
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106290
Bug ID: 106290
Summary: A non-static data member of an anonymous union member
appears in the default-member-initializer of another
should be well-formed
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106291
Bug ID: 106291
Summary: Literal class can appear in the constant-expression of
a declaration of a bit-field
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106291
--- Comment #1 from jim x ---
https://godbolt.org/z/x5hPe5qoP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106377
Bug ID: 106377
Summary: A injected-class-name of a private class is not
accessible in the member of the derived class.
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107260
Bug ID: 107260
Summary: The prvalue with the value 0 that is not a integer
literal shouldn't convert to std::nullptr_t
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101687
--- Comment #3 from jim x ---
I think CWG2557 is clear with this aspect
https://cplusplus.github.io/CWG/issues/2557.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109768
Bug ID: 109768
Summary: Construct an anonymous union variable with a variant
member that has deleted the destructor should be
ill-formed
Product: gcc
Version:
50 matches
Mail list logo
