Jason Merrill wrote:
> Jason Merrill wrote:
>> Note that when I fix build_duplicate_type to work properly, the C++
>> compiler rejects the first usage because U doesn't refer to the
>> original type, so it isn't used for linkage. Perhaps that's why
>> build_duplicate_type got broken.
>
> Actually
Jason Merrill wrote:
Note that when I fix build_duplicate_type to work properly, the C++
compiler rejects the first usage because U doesn't refer to the original
type, so it isn't used for linkage. Perhaps that's why
build_duplicate_type got broken.
Actually, this happens regardless. So I g
Jason Merrill wrote:
Note that when I fix build_duplicate_type to work properly, the C++
compiler rejects the first usage because U doesn't refer to the original
type, so it isn't used for linkage.
...if you try to use U as an argument type to a function with C++ linkage.
Jason
Mark Mitchell wrote:
That seems reasonable to me. The transparent_union trick (copying the
fields, along with making a new TYPE_MAIN_VARIANT) might work, but even
there you have to worry about making sure you a different type_info
object, how do you mangle the name, etc. You're also likely to g
Jason Merrill wrote:
> may_alias and target attributes are the problematic case. Most of these
> just get added to the TYPE_ATTRIBUTES list, and
> build_type_attribute_qual_variant creates a new TYPE_MAIN_VARIANT
> without copying the fields, which is why things break.
>
> A simple solution migh
Mark Mitchell wrote:
> We had a discussion about this a while back:
>
> http://gcc.gnu.org/ml/gcc/2006-10/msg00318.html
Ah right, I forgot about that. Thanks.
Joseph S. Myers wrote:
There's an additional issue to deal with now: proposals to include some
form of attributes in C++0x and C1x and
On Wed, 7 Nov 2007, Mark Mitchell wrote:
> Jason Merrill wrote:
>
> > One solution to this issue would be to simply disallow attributes on
> > structs after the definition. Failing that, we need to define how they
> > interact with the type system. Opinions?
>
> We had a discussion about this
Jason Merrill wrote:
> One solution to this issue would be to simply disallow attributes on
> structs after the definition. Failing that, we need to define how they
> interact with the type system. Opinions?
We had a discussion about this a while back:
http://gcc.gnu.org/ml/gcc/2006-10/msg0031