[Bug libstdc++/51785] gets not anymore declared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51785 andyg1001 at hotmail dot co.uk changed: What|Removed |Added CC||andyg1001 at hotmail dot co.uk --- Comment #28 from andyg1001 at hotmail dot co.uk --- Erm, am I the first to notice that this "solution" is broken? The os_defines.h include that undefines _GLIBCXX_HAVE_GETS is included before _GLIBCXX_HAVE_GETS is (re)defined inside c++config.h. Therefore, _GLIBCXX_HAVE_GETS is still defined when we get to . Seems still to be broken even in trunk.
[Bug target/31798] lib1funcs.asm:1000: undefined reference to `raise'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31798 andyg1001 at hotmail dot co.uk changed: What|Removed |Added CC||andyg1001 at hotmail dot co.uk --- Comment #4 from andyg1001 at hotmail dot co.uk --- Did this bug ever get resolved satisfactorily? For now, the only solution, as suggested by Rich Felker, is to have for example a dummy division instruction somewhere in the code that's being compiled. I'm using gcc 4.8.5 with musl-libc 1.1.12.
[Bug c++/52282] [C++0x] ICE / confused by earlier errors with decltype/constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52282
--- Comment #3 from andyg1001 at hotmail dot co.uk 2012-05-04 16:22:21 UTC ---
This ICE still occurs in the release version of gcc 4.7.0.
Here is the output from compiling the attached test-case as is:
$ g++-4.7 -std=c++11 ice.cpp
ice.cpp: In instantiation of ‘struct Z’:
ice.cpp:39:33: required from here
ice.cpp:11:41: internal compiler error: in finish_decltype_type, at
cp/semantics.c:5277
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Preprocessed source stored into /tmp/ccPyRnUB.out file, please attach this to
your bugreport.
And if the lines in the test-case marked "ICE" are commented out, then this is
the output:
$ g++-4.7 -std=c++11 ice.cpp
ice.cpp:47:1: error: non-constant condition for static assertion
ice.cpp:47:43: error: expression ‘b<10>’ does not designate a constexpr
function
ice.cpp:48:1: error: non-constant condition for static assertion
ice.cpp:48:43: error: expression ‘b<10>’ does not designate a constexpr
function
ice.cpp:64:1: error: non-constant condition for static assertion
ice.cpp:64:56: error: expression ‘0u’ does not designate a constexpr function
ice.cpp:65:1: error: non-constant condition for static assertion
ice.cpp:65:56: error: expression ‘0u’ does not designate a constexpr function
ice.cpp:66:1: error: non-constant condition for static assertion
ice.cpp:66:56: error: expression ‘0u’ does not designate a constexpr function
ice.cpp:67:1: error: non-constant condition for static assertion
ice.cpp:67:56: error: expression ‘0u’ does not designate a constexpr function
ice.cpp:70:1: error: non-constant condition for static assertion
ice.cpp:70:43: error: expression ‘C::c2’ does not designate a constexpr
function
ice.cpp:71:1: error: non-constant condition for static assertion
ice.cpp:71:43: error: expression ‘C::c2’ does not designate a constexpr
function
The attached test-case compiles and runs successfully under clang with one
small change as shown in this diff (this doesn't affect the test-case under
gcc):
--- ice.cpp
+++ ice.cpp
@@ -53,6 +53,7 @@
static_assert(Z_>::value() == 10, "oops");// ICE
constexpr struct C {
+constexpr C() = default;
constexpr int c1() const { return 10; }
static constexpr int c2() { return 10; }
} c;
[Bug c++/53166] New: static_assert produces bogus warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53166
Bug #: 53166
Summary: static_assert produces bogus warning
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: andyg1...@hotmail.co.uk
The following code produces a bogus compilation warning:
template
struct A {
static_assert(a != nullptr, "oops");
};
int a1;
A a2; // this produces a bogus warning
A a3; // correctly generates static assertion
The bogus warning is for the declaration of "a2" saying "the address of ‘a1’
will never be NULL". This is, of course, true but is exactly what the
static_assert is intended to ensure! (cf. the declaration of "a3"). Here is
the output from gcc:
$ gcc-4.7 -c --std=c++11 bugreport.cpp -Wall -Werror
bugreport.cpp: In instantiation of ‘struct A’:
bugreport.cpp:7:14: required from here
bugreport.cpp:2:10: error: the address of ‘a1’ will never be NULL
[-Werror=address]
bugreport.cpp: In instantiation of ‘struct A’:
bugreport.cpp:8:18: required from here
bugreport.cpp:3:5: error: static assertion failed: oops
cc1plus: all warnings being treated as errors
My expectation would be that the static_assert should silently pass, not cause
a warning in this case. Compare the output that clang gives:
bugreport.cpp:3:5: error: static_assert failed "oops"
static_assert(a != nullptr, "oops");
^
bugreport.cpp:8:18: note: in instantiation of template class 'A' requested here
A a3; // correctly generates static assertion
^
1 error generated.
[Bug c++/52282] [C++0x] ICE / confused by earlier errors with decltype/constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52282 --- Comment #2 from andyg1001 at hotmail dot co.uk 2012-02-24 17:42:59 UTC --- Created attachment 26743 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26743 test-case for decltype ICE / incorrect evaluation of constexpr The attached test-case source expands on my previous bug report and shows where the ICE occurs with decltype but also where the compiler fails to detect that a value is actually constexpr (lines marked "incorrect evaluation"). What is interesting is that the incorrect evaluation does not occur for comparable use inside main(). GCC version: g++ (GCC) 4.7.0 20120224 (experimental)
[Bug c++/52282] New: [C++0x] ICE / confused by earlier errors with decltype/constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52282
Bug #: 52282
Summary: [C++0x] ICE / confused by earlier errors with
decltype/constexpr
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: andyg1...@hotmail.co.uk
The following code causes the compiler problems. The version I am using is gcc
4.7.0-20120210.
template
struct A
{
static constexpr T a() { return V; }
};
template
struct B
{
typedef T type;
static constexpr type b() { return V; }
};
template
struct C
{
static constexpr decltype(V) c() { return V; }
};
static_assert(A::a() == 10, "oops");
static_assert(B::b() == 10, "oops");
static_assert(C::c() == 10, "oops");
struct D
{
static constexpr int d() { return 10; }
};
static_assert((A::a())() == 10, "oops");
static_assert((B::b())() == 10, "oops"); // line 30
static_assert((C::c())() == 10, "oops");
The code as given above will give the following output:
1.cpp:30:1: error: non-constant condition for static assertion
1.cpp:30:38: error: expression ‘D::d’ does not designate a constexpr function
1.cpp:17: confused by earlier errors, bailing out
Commenting out the line 30 will produce an ICE instead:
1.cpp: In instantiation of ‘struct C’:
1.cpp:31:34: required from here
1.cpp:17:31: internal compiler error: in finish_decltype_type, at
cp/semantics.c:5277
There are two issues here: the first is, of course, the ICE; the second is that
gcc is not correctly determining the return type when it is abstracted as in
structs B and C and the type is a static function pointer.
Note that non-static member function pointers do not generate either issues,
although it is necessary to add "const" to the pointer type but not to the
corresponding function definition:
struct E
{
constexpr int e() { return 10; }
};
constexpr E e;
static_assert((e.*A::a())() == 10, "oops");
static_assert((e.*B::b())() == 10, "oops");
static_assert((e.*C::c())() == 10, "oops");
[Bug c++/51723] [C++0x] delegating constructor ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51723 --- Comment #6 from andyg1001 at hotmail dot co.uk 2012-01-01 15:25:50 UTC --- As a suggestion, the test case added in commit http://gcc.gnu.org/viewcvs?view=revision&revision=182768 should have the additional two lines: constexpr B b1 = A<10, 20, 30>::a; constexpr B b2 = A<10, 20, 30>(); since these actually *cause* the ICE in the initial post. (These two lines were part of the initial post.)
[Bug c++/51723] [C++0x] delegating constructor ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51723 --- Comment #2 from andyg1001 at hotmail dot co.uk 2012-01-01 13:05:50 UTC --- I have double-checked and, yes, it does work in the latest revision from trunk - sorry, I ought to have checked that first.
[Bug c++/51723] New: [C++0x] delegating constructor ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51723
Bug #: 51723
Summary: [C++0x] delegating constructor ICE
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: andyg1...@hotmail.co.uk
The following reduced code generates an ICE in gcc version 4.7.0 20111219:
template
struct A
{
static constexpr int a[sizeof...(V)] = { V... };
};
template constexpr int A::a[];
struct B
{
const int* const b;
template
constexpr B(const int(&b)[N])
: b(b)
{ }
template
constexpr B(A)
: B(A::a) /* replace 'B' with 'b' to compile without ICE */
{ }
};
constexpr B works = A<10, 20, 30>::a; /* uses first ctor */
constexpr B causes_ice = A<10, 20, 30>(); /* uses second ctor */
The ICE occurs around the delegating constructor, but the code compiles
correctly if it is substituted for a non-delegating form of the constructor.
The message from gcc is:
ice.cpp: In instantiation of 'constexpr B::B(A) [with int ...V = {10,
20, 30}]':
ice.cpp:25:40: required from here
ice.cpp:21:7: internal compiler error: in build_data_member_initialization, at
cp/semantics.c:5844
Please submit a full bug report,
with preprocessed source if appropriate.
