Patchwork [C++,Patch/RFC] PR 56450

login
register
mail settings
Submitter Paolo Carlini
Date April 27, 2013, 9:17 p.m.
Message ID <517C4067.8070207@oracle.com>
Download mbox | patch
Permalink /patch/240201/
State New
Headers show

Comments

Paolo Carlini - April 27, 2013, 9:17 p.m.
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 7.1.6.2/4, 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?

Thanks!
Paolo.

////////////////////////
Jason Merrill - April 28, 2013, 7:10 p.m.
On 04/27/2013 05:17 PM, Paolo Carlini wrote:
> 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 7.1.6.2/4, since we are dealing
> with a class member access in any case, it may well be possible that
> *ICC* is right.

Yes, I think so.  Since it's a class member access, decltype should be 
the declared type, i.e. const int.

Jason

Patch

Index: semantics.c
===================================================================
--- semantics.c	(revision 198359)
+++ semantics.c	(working copy)
@@ -5398,6 +5398,7 @@  finish_decltype_type (tree expr, bool id_expressio
           break;
 
         case COMPONENT_REF:
+	case COMPOUND_EXPR:
 	  mark_type_use (expr);
           type = is_bitfield_expr_with_lowered_type (expr);
           if (!type)