This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [C++ Patch/RFC] PR 56450

Hi again,

On 04/27/2013 02:56 AM, Jason Merrill wrote:
Why should id_expression_or_member_access_p be false? "declval<T>().dummy" is a class member access (5.2.5) regardless of what kind of member dummy is.
today I have been able to spend some more time on the issue, and I think the attached further reduced testcase summarizes rather well what I figured out.

Assuming as obvious that we don't want to crash on it, the interesting issue is whether we want the static_asserts to both fail or succeed: in practice, a rather recent ICC I have at hand fails both; a rather recent clang++ passes both (consistently with the expectation of Bug submitter). In fact, as I'm reading now, since we are dealing with a class member access in any case, it may well be possible that *ICC* is right. And then a tiny patch like the attached works for me to obtain the same behavior for GCC (passes testing etc; it's the first "stupid" thing I tried days ago ;)

FWIW, the attached testcase also explains pretty well why my earlier hack appeared to work, in the sense of recent clang++: we ended up calling cp_build_reference_type on the type.

Overall, I think the situation is rather clear by now. What do you think?


template<typename T>
T&& declval();

template<typename, typename>
struct is_same
{ static constexpr bool value = false; };

template<typename T>
struct is_same<T, T>
{ static constexpr bool value = true; };

struct A
  static const int dummy = 0;

static_assert(!is_same<decltype(declval<A>().dummy), const int>::value, "");
static_assert(is_same<decltype(declval<A>().dummy), const int&>::value, "");

Attachment: p
Description: Text document

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]