https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66901
Anders Granlund changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66879
--- Comment #8 from Anders Granlund ---
*** Bug 66901 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66879
--- Comment #9 from Anders Granlund ---
*** Bug 66878 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66878
Anders Granlund changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66879
--- Comment #10 from Anders Granlund ---
Here comes two more test cases moved in from my related ICE on compile bug
reports:
namespace X {
struct S;
namespace Y {
namespace Z = X;
struct Z::S {};
}
}
int main() {}
st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66934
--- Comment #4 from Anders Granlund ---
I'm pulling in this test case from my related bug report.
int x = 1;
int main() {
extern int x;
using ::x;
}
I this case the program is well-formed (the two declarations in main are not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66935
Anders Granlund changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66934
--- Comment #5 from Anders Granlund ---
*** Bug 66935 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66934
--- Comment #6 from Anders Granlund ---
(In reply to Jonathan Wakely from comment #3)
> Problem report i.e. bugzilla bug.
Ok. Done.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66934
--- Comment #7 from Anders Granlund ---
(In reply to Anders Granlund from comment #2)
> (In reply to Jonathan Wakely from comment #1)
> > I think we could combine most of your reports into one or two PRs since
> > they're all related and fixing t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67017
--- Comment #6 from Anders Granlund ---
Now I got the reply. It seems like the wording of the standard changed with the
resolution of this c++ standard core defect:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1265
So the proble
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following program (proc.cc):
void g() {}
constexpr void f() { return; g(); }
int main() {}
Compile it with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67026
--- Comment #3 from Anders Granlund ---
(In reply to Andrew Pinski from comment #2)
> Actually wait. I think this is invalid and clang is incorrect in not
> rejecting it. Because you have a call to a non constexpr in a constexpr
> function; doe
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following program (prog.cc):
#include
#include
enum { x = std::numeric_limits::max(), y };
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67047
--- Comment #2 from Anders Granlund ---
(In reply to Andrew Pinski from comment #1)
> So the enum is an unsigned type so UINTMAX_MAX +1 is 0 as it is always
> representable due to the rules of unsigned types and wrapping. Unless I
> miss-underst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67047
--- Comment #3 from Anders Granlund ---
It seems like the increment of the enumerator x triggered the use of the
following compiler extension:
https://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html
This without any error messages. That is not
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following well-formed program (prog.cc):
enum {} x;
int main() {}
Compile it with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67047
--- Comment #5 from Anders Granlund ---
(In reply to Jonathan Wakely from comment #4)
> Yes you can verify that with
>
> static_assert( std::is_same::type,
> unsigned __int128>::value, "");
>
> I suppose there should be a diagnostic with -Wpeda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67010
Anders Granlund changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
The following program is ill-formed (proc.cc):
int main;
Compile it with the following command line
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Test case:
namespace P{ namespace X { static int i = 1; } }
namespace Q { namespace X = P::X; }
using namespace P;
using namespace Q;
int main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67074
--- Comment #1 from Anders Granlund ---
I have reported the same bug in clang also:
https://llvm.org/bugs/show_bug.cgi?id=24324
Richard Smith confirmed it and added this additional test case:
And likewise:
namespace N {}
namespace N = N;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67065
--- Comment #2 from Anders Granlund ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Anders Granlund from comment #0)
> > The following program is ill-formed (proc.cc):
> >
> > int main;
> >
> > Compile it with the following c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67065
--- Comment #3 from Anders Granlund ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Anders Granlund from comment #0)
> > The following program is ill-formed (proc.cc):
> >
> > int main;
> >
> > Compile it with the following c
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following two programs:
struct A { static const int x = 0; };
struct B : A
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following program
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following program:
#include
#include
template
void f1()
{
std
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following program:
#include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97375
--- Comment #1 from Anders Granlund ---
Here is another example of the same problem without using decltype(auto), so
the problem seems to be more general:
#include
#include
template
void f1()
{
std::cout << std::is_const_v << st
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following c++ program:
typedef struct {
void f();
} X;
int main()
{
}
It is not
++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following program:
template
class A
{
};
int main()
{
A a = A();
}
It is accepted when compiling it with "-std=c++20 -pedantic-errors".
Th
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following c++ program:
int main()
{
struct A
{
struct B *b;
};
using U = B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97569
--- Comment #2 from Anders Granlund ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Anders Granlund from comment #0)
> > The interesting thing is that if we replace struct S with struct S {}
> > both compilers agree on reject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97569
Anders Granlund changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97475
--- Comment #4 from Anders Granlund ---
Sounds good to me!
On Thu, 5 Aug 2021, 13:35 redi at gcc dot gnu.org,
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97475
>
> --- Comment #3 from Jonathan Wakely ---
> Maybe we should make this
101 - 135 of 135 matches
Mail list logo
