I refer you to the various issues I have raised with attributes proposals
in WG14 in the past, some at least of which have also been forwarded to
WG21. The committees have generally chosen not to listen to compatibility
concerns, except insofar as WG14 ended up not adopting general attribute
s
Sean Hunt writes:
> On 07/10/2010 03:56 PM, Ian Lance Taylor wrote:
>> Sean Hunt writes:
>>
>>> void foo () __attribute__((noreturn)); // right per spec
>>> void foo __attribute__((noreturn)) (); // works
>>> __attribute__((noreturn)) void foo (); // works
>>>
>>> It's obvious tha
On 07/10/2010 03:56 PM, Ian Lance Taylor wrote:
Sean Hunt writes:
void foo () __attribute__((noreturn)); // right per spec
void foo __attribute__((noreturn)) (); // works
__attribute__((noreturn)) void foo (); // works
It's obvious that the first example of each kind (noreturn
Sean Hunt writes:
> void foo () __attribute__((noreturn)); // right per spec
> void foo __attribute__((noreturn)) (); // works
> __attribute__((noreturn)) void foo (); // works
>
> It's obvious that the first example of each kind (noreturn appearing
> after the function declarator) mu
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
On Jun 26, 2005, at 5:54 PM, Nathan Sidwell wrote:
Paulo,
I tried to get attributes and templates to play nice. Even though
conceptually
it's quite straight forward, our data representations and current
instantiation
machinery pretty much make it very difficult. It would be several
days (
13 matches
Mail list logo
