On 10/24/2012 04:47 PM, Paolo Carlini wrote:
Essentially, what really matters is that the first field must be a pointer.
In this case, yes. Let's just say what the issue is: the type of the
first field has a different ABI from the class overall.
Jason
.. Oh well, and the details of this are even subtler, because, assuming
we want the exact same behavior of the C front-end, we are going to accept:
typedef union {
int* f;
int y;
} __attribute__(( __transparent_union__ )) example_t;
and reject:
typedef union {
int f;
int* y;
} __attrib
Hi,
On 10/24/2012 09:55 PM, Jason Merrill wrote:
On 10/24/2012 03:48 PM, Paolo Carlini wrote:
+ error ("type transparent %q#T cannot be made transparent
because "
+ "a field has neither pointer nor integer type", t);
I'd say "%q#T cannot be made transparent because %q#D has neit
On 10/24/2012 03:48 PM, Paolo Carlini wrote:
+ error ("type transparent %q#T cannot be made transparent because "
+"a field has neither pointer nor integer type", t);
I'd say "%q#T cannot be made transparent because %q#D has neither
pointer nor integer type", t, field.
Hi,
On 10/24/2012 06:57 PM, Jason Merrill wrote:
On 10/10/2012 11:13 AM, Paolo Carlini wrote:
- error ("type transparent class %qT does not have any fields", t);
+ if (TREE_CODE (t) == UNION_TYPE)
+error ("type transparent union %qT does not have any
fields", t);
+ else
On 10/10/2012 11:13 AM, Paolo Carlini wrote:
- error ("type transparent class %qT does not have any fields", t);
+ if (TREE_CODE (t) == UNION_TYPE)
+ error ("type transparent union %qT does not have any fields", t);
+ else
+ error ("type transparent cla
Hi,
in this PR, at variance with the C front-end, we don't check well enough
the aggregate type - in finish_struct_1 - and we ICE later. Then I'm
essentially copying from the C front-end the check. Some details:
1- In these checks, eg, no fields too, the C front-end only warns,
zeroes TYPE_T
