[Bug c++/54532] New: [C++0x][constexpr] internal error when initializing static constexpr with pointer to non-static member variable

[cvs at cs dot utoronto.ca]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54532

 Bug #: 54532
   Summary: [C++0x][constexpr] internal error when initializing
static constexpr with pointer to non-static member
variable
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: c...@cs.utoronto.ca


Created attachment 28154
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28154
output of g++ -v

The following code triggers a segfault.

struct reg {
template 
constexpr reg(T CLS::*) {}
};

struct foo {
};

struct bar {
foo a;

// both of these trigger internal error
static constexpr foo bar::*reg_a = &bar::a;
static constexpr reg reg_a = &bar::a;
};

g++ --version
g++ (Debian 4.7.1-7) 4.7.1
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

4.6 seems to have the same problem.

[Bug c++/54532] [C++0x][constexpr] internal error when initializing static constexpr with pointer to non-static member variable

[cvs at cs dot utoronto.ca]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54532

--- Comment #1 from Chris  2012-09-09 02:24:57 UTC 
---
Created attachment 28155
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28155
preprocessed source

[Bug libstdc++/58912] New: make_shared value initializes storage space even when not desired

[cvs at cs dot utoronto.ca]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58912

Bug ID: 58912
   Summary: make_shared value initializes storage space even when
not desired
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cvs at cs dot utoronto.ca

Simple example:

struct foo {
char buf[1024*1024*1024];
foo() {}
};
auto p = std::make_shared();

I've traced the problem to shared_ptr_base.h and tested the following patch
(against 4.7.2) to resolve the problem:

--- shared_ptr_base.h.orig  2013-10-29 11:52:02.212301477 -0400
+++ shared_ptr_base.h   2013-10-29 11:52:20.620300707 -0400
@@ -394,7 +394,7 @@
 public:
   template
_Sp_counted_ptr_inplace(_Alloc __a, _Args&&... __args)
-   : _M_impl(__a), _M_storage()
+   : _M_impl(__a)
{
  _M_impl._M_ptr = static_cast<_Tp*>(static_cast(&_M_storage));
  // _GLIBCXX_RESOLVE_LIB_DEFECTS

The problem appears to be in versions as new as 4.8.2.  

Is there a good reason why the storage space must be initialized?

[Bug c++/58993] New: failure to access pointer to protected member method in base from derived class specialization

[cvs at cs dot utoronto.ca]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58993

Bug ID: 58993
   Summary: failure to access pointer to protected member method
in base from derived class specialization
   Product: gcc
   Version: 4.7.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cvs at cs dot utoronto.ca

Sample code:

class base {
protected:
typedef void (base::*foo_type)() const;
void foo() const {}
};

template 
struct bar : public base {
foo_type test() { 
return &base::foo;   // OK
}
};

template <>
struct bar : public base {
using base::foo;
foo_type test() { 
foo();   // OK
base::foo(); // OK
foo_type x = &bar::foo;  // OK
return &base::foo;   // error
}
};

int main() {
bar().test();
bar().test();
return 0;
}

Compiler output:
protected_base.cpp: In member function ‘void (base::*
bar::test())()const’:
protected_base.cpp:5:10: error: ‘void base::foo() const’ is protected
protected_base.cpp:22:23: error: within this context

Version:
g++ (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3

[Bug c++/58993] incorrectly accept access of protected member method from derived class template

[cvs at cs dot utoronto.ca]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58993

--- Comment #3 from Chris Studholme  ---
Ah, thanks for the info.  I thought I tried '&bar::foo' and it didn't work
without 'using base::foo'.  I just tried it again and it does work (in both
cases) without the using declaration so I must have made some other mistake
earlier.