[Bug c++/77804] New: Internal compiler error on incorrect initialization of new-d array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77804
Bug ID: 77804
Summary: Internal compiler error on incorrect initialization of
new-d array
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vgheorgh at gmail dot com
Target Milestone: ---
The code below
#include
int main()
{
char buf[256];
std::size_t n = 10;
int* p = new (buf) (int[n]); // incorrect way, parenthesis by mistake
// int* p = new (buf) int[n]; // correct way
}
produces an internal compile error in gcc versions 6 or later. It compiles fine
(although with an warning: non-constant array new length must be specified
without parentheses around the type-id [-Wvla].
[Bug c++/41437] No access control for classes in template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437
Vlad Gheorghiu changed:
What|Removed |Added
CC||vgheorgh at gmail dot com
--- Comment #8 from Vlad Gheorghiu ---
The bug exists in gcc 6.1 as well:
class X
{
template
class A{};
};
int main()
{
X::A a; // compiles just fine
}
[Bug c++/68077] New: Namespace having the same name as contained class should not compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68077
Bug ID: 68077
Summary: Namespace having the same name as contained class
should not compile
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vgheorgh at gmail dot com
Target Milestone: ---
According to [7.3.4/6 Using directive [namespace udir]] the following code is
ill-formed, and there is no "no diagnostic required":
template
class Foo{};
namespace X
{
class X{};
}
using namespace X; // now both class X and namespace X are visible
Foo f()
{
return {};
}
int main() {}
Therefore I believe the code should not compile. Tested with both gcc5.2.x and
gcc6. More details: http://stackoverflow.com/q/33313853/3093378
[Bug c++/66595] New: [C++14] ICE in partial specialization template variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66595
Bug ID: 66595
Summary: [C++14] ICE in partial specialization template
variables
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vgheorgh at gmail dot com
Target Milestone: ---
The code below
templatetypename T int typeID{42};
templatetypename T double typeIDdouble{10.10};
int main() {}
produces an internal compiler error
internal compiler error: in type_dependent_expression_p, at cp/pt.c:21431
in both g++5.1 and in HEAD
It should not compile, as the partial specialization doesn't use any of the
template arguments.
[Bug c++/66350] typename should be forbidden in inhering constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66350
--- Comment #2 from Vlad Gheorghiu vgheorgh at gmail dot com ---
(In reply to Martin Sebor from comment #1)
Here's a reduced test case compiled with -Wall in C++ 98 mode:
$ cat t.cpp ~/bin/gcc-5.1.0/bin/g++ -Wall -std=c++98 -c t.cpp
template class T struct A { A (T) { } };
template class T struct B: AT {
using typename AT::A;
};
Bint b (0);
t.cpp:3:26: warning: inheriting constructors only available with
-std=c++11 or -std=gnu++11
using typename AT::A;
^
I don't think gcc is incorrect in accepting the code either in C++ 98 mode
as an extension, or in C++ 11 mode. In the latter mode, accepting it is in
keeping with the resolution of DR 147. Naming the constructor (Clang
accepts the test case above in C++ 11 mode). That is, when 'AT::A'
nominates class template A the name is instead taken to name the ctor of A.
I tried compiling your test with Clang but it fails with the same error,
http://melpon.org/wandbox/permlink/7sGeB2XfPOHkOFfN
[Bug c++/66350] New: typename should be forbidden in inhering constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66350
Bug ID: 66350
Summary: typename should be forbidden in inhering constructors
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vgheorgh at gmail dot com
Target Milestone: ---
The code below
#include memory
template class T, class Deleter = std::default_deleteT
class unique_ptr_wrapper: public std::unique_ptrT, Deleter
{
public:
using typename std::unique_ptrT, Deleter::unique_ptr; // typename should
be forbidden here
};
int main()
{
unique_ptr_wrapperint upw{new int{42}};
}
should be ill formed (no typename required), since we inherit a constructor,
which is not a dependent type. IMO, a diagnostic should be required, however
g++ compiles the program without any warnings.
Tested with gcc4.9/5.1/6 HEAD.
More details: http://stackoverflow.com/q/30554119/3093378
[Bug c++/66211] New: Rvalue conversion in ternary operator causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66211
Bug ID: 66211
Summary: Rvalue conversion in ternary operator causes internal
compiler error
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vgheorgh at gmail dot com
Target Milestone: ---
The code below
void f(int){}
int main()
{
int x = 0;
double y = 1;
f(1 0 ? x : y);
}
should not compile, due to rvalue conversion in the ternary operator, then
trying to bind the rvalue to a non-constant reference. However, gcc51 and gcc6
HEAD crash with an internal compiler error
internal compiler error: in convert_like_real, at cp/call.c:6471
gcc49 works (emits an error)
[Bug c++/66109] defining constexpr objects without initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66109 --- Comment #1 from Vlad Gheorghiu vgheorgh at gmail dot com --- Actually the `constexpr` ctor is not even necessary here to reproduce the bug.
[Bug c++/66109] New: defining constexpr objects without initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66109
Bug ID: 66109
Summary: defining constexpr objects without initializer
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vgheorgh at gmail dot com
Target Milestone: ---
The following code
struct Foo
{
constexpr Foo() = default;
};
int main()
{
constexpr Foo foo;
}
should not compile. Unfortunately it compiles with all g++ versions (that
support c++11) up to and including 5.1
From [decl.constexpr]:
A constexpr specifier used in an object declaration declares the object as
const. Such an object shall have literal type and shall be initialized.
Therefore the correct way of usage should be
constexpr Foo foo{};
[Bug c++/65382] pointer-to-noexcept-function typealias allowed via using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65382 --- Comment #2 from Vlad Gheorghiu vgheorgh at gmail dot com --- More details: http://stackoverflow.com/q/30172483/3093378
[Bug c++/65382] pointer-to-noexcept-function typealias allowed via using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65382 --- Comment #3 from Vlad Gheorghiu vgheorgh at gmail dot com --- Please ignore the previous comment, posted by mistake for another bug I reported
[Bug c++/66109] defining constexpr objects without initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66109 --- Comment #2 from Vlad Gheorghiu vgheorgh at gmail dot com --- More details at http://stackoverflow.com/q/30172483/3093378
[Bug c++/65382] New: pointer-to-noexcept-function typealias allowed via using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65382
Bug ID: 65382
Summary: pointer-to-noexcept-function typealias allowed via
using
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vgheorgh at gmail dot com
According to 15.4 Exception specifications [except.spec]/2, the following code
should be rejected,
#include iostream
using fptr = void(*)() noexcept; // should not be accepted
// typedef void (*FPTR)() noexcept; // rejected by the compiler
void f() noexcept
{
std::cout void f() noexcept std::endl;
}
int main()
{
fptr fp = f;
fp();
}
Replacing using with a typedef makes the compiler emit an error, however the
code above compiles just fine, and it shouldn't.
[Bug c++/65382] pointer-to-noexcept-function typealias allowed via using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65382 --- Comment #1 from Vlad Gheorghiu vgheorgh at gmail dot com --- I compiled with gcc5 and also with gcc4.9.2, using `-Wall -Wextra -pedantic`
