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?
>
>
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/gc
ip cv-quals, and
we don't want that to discard important attributes.
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?
Jason
