https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116876
--- Comment #4 from Jason Liam ---
> So are you sure this is not a clang issue?
Yes, because [temp.deduct.partial#9.1] make the second overload not to be
atleast as specialized as the first and then [temp.deduct.partial#9.2] make the
first temp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116876
Bug ID: 116876
Summary: GCC accepts invalid call to overloaded function
template
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116532
Bug ID: 116532
Summary: GCC accepts invaild static int iarr2 alignas(16)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116360
Bug ID: 116360
Summary: GCC gives false positive dangling reference for static
local variable
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116311
Bug ID: 116311
Summary: GCC accepts invalid program with conversion function
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116223
Bug ID: 116223
Summary: GCC rejects program involving integral conversion in
non-type template parameter with auto
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116162
--- Comment #4 from Jason Liam ---
Yes, this is well-formed because the move ctor here is deleted as per 2.6 as
explained in this thread: https://stackoverflow.com/a/78817438/12002570
In C++26, constructors have types through CWG2479 which is D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116162
Bug ID: 116162
Summary: GCC rejects explicitly default move ctor with const
X&& parameter
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116121
--- Comment #1 from Jason Liam ---
Note that the error only comes when we use `inline` with the static data
member. If we use the old out of class definition way of doing things then gcc
also starts accepting the code. https://godbolt.org/z/GeYq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116121
Bug ID: 116121
Summary: GCC rejects valid program involving explicit
specialization of static data member without
specializing the class template itself
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115964
--- Comment #4 from Jason Liam ---
@corentinjabot
Note that
```
void j(this const C);
void j() const ;
```
is still invalid.
Only
```
void f(this C );
void f(C);
```
is valid.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115964
--- Comment #3 from Jason Liam ---
(In reply to corentinjabot from comment #2)
> This is valid per https://eel.is/c++draft/basic.scope.scope#4.4
No you've misread your quoted reference. The program is ill formed as explained
in the given thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115964
Bug ID: 115964
Summary: GCC accepts invalid program with explicit object
member function overloads
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115888
--- Comment #3 from Jason Liam ---
Reduced program to show the intent more clearly:
```
#include
struct C{
int f(this int);
};
decltype(C::f) func; //msvc accepts but clang and gcc rejects
int func(int j)
{
std::cout << "called with:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115888
--- Comment #2 from Jason Liam ---
(In reply to Andrew Pinski from comment #1)
> https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2688
This is not CWG2688. Note that in the given example here, gcc and clang
rejects `decltype(C::f)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115888
Bug ID: 115888
Summary: GCC rejects valid program involving explict object
member function
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115790
Bug ID: 115790
Summary: GCC doesn't emit a diagnostic for deprecated copy ctor
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115783
Bug ID: 115783
Summary: GCC accepts invalid program involving calling explicit
object member function from static member function
Product: gcc
Version: 15.0
Status: UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115722
--- Comment #13 from Jason Liam ---
(In reply to Andrew Pinski from comment #12)
> Right, and there is only one definition of the lambda in the original
> testcase of the default argument. But it is evulated twice.
Yes, so it should be made cl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115722
--- Comment #11 from Jason Liam ---
Just like in the other example(https://godbolt.org/z/GbTcvT9z8), the
[expr.prim.lambda.closure/2] only implies that the closure-types will be
declared in the global scope. Nothing else. The uniqueness is dete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115722
--- Comment #10 from Jason Liam ---
(In reply to Andrew Pinski from comment #7)
> The question is does the lambda type in a default argument gets defined once
> even if it is evaluated twice. I think so based on
> expr.prim.lambda.closure/2 .
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115722
--- Comment #8 from Jason Liam ---
> Which means the closure type is in the global scope here for this TU.
I did read that before posting actually. But even if they're in the global
scope in same TUs they should still produce unique/distinct c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115722
--- Comment #6 from Jason Liam ---
https://stackoverflow.com/questions/50417782/is-it-safe-to-assume-that-identical-lambda-expressions-have-different-types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115722
--- Comment #3 from Jason Liam ---
[expr.prim.lambda.closure] states:
> The type of a lambda-expression (which is also the type of the closure
> object) is a unique, unnamed non-union class type, called the closure type,
> ...
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115722
Bug ID: 115722
Summary: GCC uses old closure type when using as default
argument instead of using new closure type each time
Product: gcc
Version: 15.0
Status: UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115085
Jason Liam changed:
What|Removed |Added
CC||jlame646 at gmail dot com
--- Comment #5 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107945
--- Comment #6 from Jason Liam ---
Here is the thread that explains why this is ill-formed.
https://stackoverflow.com/questions/74642250/incomplete-type-works-with-gcc-but-not-with-clang-and-msvc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114884
Bug ID: 114884
Summary: GCC rejects valid deduction using deduction guide
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114771
Bug ID: 114771
Summary: GCC accepts invalid overloading of member function
differing only in ref qualifier
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114569
--- Comment #2 from Jason Liam ---
(In reply to Marek Polacek from comment #1)
> So the code should compile.
But https://timsong-cpp.github.io/cppwp/n4950/dcl.ptr#4.sentence-2 says:
> [Note 1: [...] Forming a function pointer type is ill-forme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114569
Bug ID: 114569
Summary: GCC accepts forming pointer to function type which is
ref qualified
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107945
--- Comment #4 from Jason Liam ---
Here is another invalid snippet that gcc accepts but both clang and msvc
rejects correctly. https://godbolt.org/z/sz4rczEaG
```
#include
template
requires std::is_arithmetic_v && (N >= 1)
class Vector
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114290
Bug ID: 114290
Summary: GCC output incorrect output with -O2
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114237
Bug ID: 114237
Summary: GCC emits no narrowing conversion warning when call is
made indirectly through std::invoke
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114183
Bug ID: 114183
Summary: Lambda constexpr works in msvc but not in gcc
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114163
Bug ID: 114163
Summary: Calling member function of an incomplete type compiles
in gcc and does not compile in clang and msvc
Product: gcc
Version: 14.0
Status: UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114067
--- Comment #3 from Jason Liam ---
(In reply to Andrew Pinski from comment #2)
> Actually A at that point is incomplete type.
Yes, it is incomplete at that point but that is not the reason for the program
to be ill-formed. The reason is that `A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114067
--- Comment #1 from Jason Liam ---
That is, even if the type of `a` was complete the program would've been
ill-formed. So saying only that `A` is incomplete is the problem doesn't seem
right.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114067
Bug ID: 114067
Summary: GCC gives wrong diagnostic in the definition of a
static data member of same class type
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114053
--- Comment #1 from Jason Liam ---
Demo https://godbolt.org/z/GWr5dn9Kr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114053
Bug ID: 114053
Summary: GCC accepts initialization of array with another
static data member array in member initializer list
Product: gcc
Version: 14.0
Status: UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113884
--- Comment #9 from Jason Liam ---
(In reply to Andrew Pinski from comment #8)
Does that imply that following program is also invalid? GCC rejects the below
program but msvc accepts.
```
struct A
{
explicit A(int = 10);
A()= default;
};
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113884
--- Comment #7 from Jason Liam ---
(In reply to Andrew Pinski from comment #5)
> std::vector 's constructor which takes std::size_t is marked as explicit.
But you're missing that the initializer list ctor is preferred/choosen over the
size_t ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113884
--- Comment #4 from Jason Liam ---
But which constructor is explicit here? I don't see any explicit ctor here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113884
Bug ID: 113884
Summary: GCC rejects valid program saying ambiguous call when
using std::vector
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113804
Bug ID: 113804
Summary: offsetof(type, array[run_time_value]) failing
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21498
Jason Liam changed:
What|Removed |Added
CC||jlame646 at gmail dot com
--- Comment #16 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113748
--- Comment #2 from Jason Liam ---
(In reply to Andrew Pinski from comment #1)
> >This should be valid because `friend class C;` befriend a global class named
> >`C`.
>
>
> Hmm, see PR 21498 ...
This is ill-formed as explained
here:https://s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113748
Bug ID: 113748
Summary: GCC rejects valid program involving befriending class
with name same as typedef
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113443
--- Comment #4 from Jason Liam ---
Clang has now fixed the issue https://github.com/llvm/llvm-project/issues/78449
So now only gcc rejects the valid program.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113598
Bug ID: 113598
Summary: GCC internal compiler error
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113443
--- Comment #3 from Jason Liam ---
Clang is also wrong in rejecting the code. Here is the clang bub:
https://github.com/llvm/llvm-project/issues/78449
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113443
--- Comment #1 from Jason Liam ---
The explanation for why this is valid is given here:
https://stackoverflow.com/questions/77832658/stdtype-identity-to-support-several-variadic-argument-lists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113443
Bug ID: 113443
Summary: GCC rejects valid program involving parameter packs
with in between class type
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113375
Bug ID: 113375
Summary: GCC accepts invalid program involving template keyword
when used without a template arg list
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113300
--- Comment #4 from Jason Liam ---
(In reply to Andrew Pinski from comment #1)
> There is a C++ defect report in this area even ...
Looks like that gcc and clang are non-compliant here as per this discussion in
CWG issue list: https://github.co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113300
Jason Liam changed:
What|Removed |Added
Summary|GCC rejects valid program |GCC rejects valid program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113300
Bug ID: 113300
Summary: GCC rejects valid program involving explicit and non
explicit default constructors
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113286
Bug ID: 113286
Summary: GCC accepts invalid program involving cast to
protected base class
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113266
Bug ID: 113266
Summary: GCC rejects static global variable as non type
template parameter
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86274
Jason Liam changed:
What|Removed |Added
CC||jlame646 at gmail dot com
--- Comment #22 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113110
--- Comment #3 from Jason Liam ---
(In reply to Andrew Pinski from comment #1)
> I suspect this is either a bug or an extension for MSVC.
Are you sure? I mean if you add another template parameter `U` to the second
parameter and use it then gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113110
Bug ID: 113110
Summary: GCC rejects call to more specialized const char array
version with string literal
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112421
Bug ID: 112421
Summary: GCC emits warning potential null dereference
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111872
Bug ID: 111872
Summary: GCC rejects out of class definition of inner private
class template
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110037
Bug ID: 110037
Summary: GCC accepts private member access of enclosing through
friend function of inner class
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109763
--- Comment #10 from Jason Liam ---
Upon reading more on this, seems this is well-formed. Note
[temp.constr.normal#1.4] is about parameter mapping(which is valid in this
case) so the last sentence in my previous quoted reference does not apply.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109763
--- Comment #9 from Jason Liam ---
(In reply to Andrew Pinski from comment #8)
> Gcc correctly accepts this:
> template constexpr bool d = true;
> template < typename T >
> concept test = d;
>
> Without a typename as T::value here refers to a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109763
--- Comment #6 from Jason Liam ---
Looks like ill-formed no diagnostic required as per [temp.constr.normal#1.4].
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109763
Jason Liam changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109763
--- Comment #4 from Jason Liam ---
(In reply to Andrew Pinski from comment #2)
> I meant to write:
> Concepts are not supposed to error out if there was an error in substitution.
> So this is all by design of the language.
(In reply to Andrew P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109763
Bug ID: 109763
Summary: GCC accepts invalid program involving
decltype(classtype::memberfunction) when used with
concepts
Product: gcc
Version: 13.1.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109649
Bug ID: 109649
Summary: GCC accepts invalid inaccessible friend declaration of
member function
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109621
Bug ID: 109621
Summary: GCC accepts invalid program with multiple using
declarations
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108275
Bug ID: 108275
Summary: GCC accepts invalid program using private data member
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108234
Bug ID: 108234
Summary: GCC accepts invalid program involving nontype template
parameter of auto with non constexpr variable
Product: gcc
Version: 13.0
Status: UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107945
Bug ID: 107945
Summary: GCC accepts invalid program involving constexpr static
data member of class template
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107605
Jason Liam changed:
What|Removed |Added
Summary|GCC rejects valid program |GCC rejects valid program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107605
Bug ID: 107605
Summary: GCC rejects valid program involving std::bind and
requires
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107461
Bug ID: 107461
Summary: GCC rejects program with ambiguity error
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107450
--- Comment #1 from Jason Liam ---
Also if we remove one of the template parameter(say T3) then msvc starts
compiling this code as well. Demo: https://godbolt.org/z/qacMzoT3q
Additionally, this current bug is most probably a duplicate of:
http
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107450
Bug ID: 107450
Summary: GCC accepts invalid program involving multiple
template parameter packs
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107343
--- Comment #1 from Jason Liam ---
The complete quote at the end of my original post is as follows:
> For a member function of a non-template class, the default arguments are
> allowed on the out-of-class definition, and are combined with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107343
Bug ID: 107343
Summary: GCC accepts ill-formed out of class definition program
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107211
Bug ID: 107211
Summary: GCC compiles invalid use of non static member function
in noexcept operator
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107186
Bug ID: 107186
Summary: GCC rejects use of static constexpr member function
in noexcept complete-class context
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107126
--- Comment #6 from Jason Liam ---
This means that the code `template struct A {~A(); };` is
ill-formed only with c++20 and onwards while the code `template struct
A {~A(); }; template A::~A(){} ;` is ill-formed in all c++
versions including c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107126
--- Comment #5 from Jason Liam ---
(In reply to Jakub Jelinek from comment #4)
> (In reply to Jason Liam from comment #2)
> > Second, i'm already aware that this is rejected by gcc with c++20 as i
> > provided a demo link https://godbolt.org/z/T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107126
--- Comment #3 from Jason Liam ---
(In reply to Jakub Jelinek from comment #1)
> This is rejected with -std=c++20 since
> r11-532-g4b38d56dbac6742b038551a36ec80200313123a1
> and the commit log states that it is intentional to apply it only for C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107126
--- Comment #2 from Jason Liam ---
(In reply to Jakub Jelinek from comment #1)
> This is rejected with -std=c++20 since
> r11-532-g4b38d56dbac6742b038551a36ec80200313123a1
> and the commit log states that it is intentional to apply it only for C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107126
Bug ID: 107126
Summary: GCC accepts invalid out of class definition for
destructor with C++17
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107111
--- Comment #5 from Jason Liam ---
Note also that gcc accepts `T v(V...b())` but rejects `T v(V...())`. Note the
use of parameter name in the former. Demo: https://godbolt.org/z/hMevdc8TE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107111
--- Comment #2 from Jason Liam ---
Also gcc rejects `V...()` but clang accepts that. Demo:
https://godbolt.org/z/bfx9rv6hP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107111
--- Comment #1 from Jason Liam ---
The last statement in my original report is not valid because `V` is a template
parameter pack. So ignore that line.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107111
Bug ID: 107111
Summary: GCC accepts invalid program involving function
declaration with pack expansion
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107106
Bug ID: 107106
Summary: Incorrect use of uninitialized value warning
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107065
--- Comment #6 from Jason Liam ---
The bug was discovered here:
https://stackoverflow.com/questions/73877384/stdis-same-different-results-beween-compilers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107065
--- Comment #3 from Jason Liam ---
(In reply to Jonathan Wakely from comment #1)
> Reduced to remove the library dependency:
>
> enum Cat { prvalue, lvalue, xvalue };
>
> template
> struct value_category {
> // Or can be an integral or enu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107065
--- Comment #2 from Jason Liam ---
Here is another reduced demo: https://godbolt.org/z/hGhfrKrad
```
#include
int main() {
bool b = true;
std::cout << std::is_same::value << "\n";
auto bb = (!(!b));
std::cout << std::is_same:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107065
Bug ID: 107065
Summary: GCC treats rvalue like lvalue
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
As
1 - 100 of 117 matches
Mail list logo
