--- Comment #12 from jason at gcc dot gnu dot org 2009-08-19 18:50 ---
GCC now says "sorry, not implemented: mangling trait_expr", which is more
informative. I'm inclined to leave it that way until the ABI specifies how
these things should be mangled, which may need to wait until we kno
--- Comment #11 from paolo dot carlini at oracle dot com 2009-08-03 00:00
---
Jason, what do you think about this issue? I remember that lately you did quite
a bit of work on mangling problems too...
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #10 from sebor at roguewave dot com 2008-07-14 18:43 ---
(In reply to comment #9)
I'd be happy to provide whatever info you need (e.g., the table of built-ins,
if you can explain to me how to get it from the front-end :)
As for the semantics of the built-ins, I assume both
--- Comment #9 from mark at codesourcery dot com 2008-07-14 16:53 ---
Subject: Re: ICE on SFINAE and __is_empty
sebor at roguewave dot com wrote:
> int foo >(B, __is_empty (A<0>)>::X*):
> _Z3fooI1AILi0EEEiPN1BIT_Xv19builtin16TOS3_EE1XE
>
> int foo(B::X*):
> _Z
--- Comment #8 from sebor at roguewave dot com 2008-07-14 15:41 ---
(In reply to comment #7)
> Subject: Re: ICE on SFINAE and __is_empty
>
> sebor at roguewave dot com wrote:
>
> > My preference would be for gcc to avoid imposing restrictions on the use
> > of these helpers to facilit
--- Comment #7 from mark at codesourcery dot com 2008-07-14 15:28 ---
Subject: Re: ICE on SFINAE and __is_empty
sebor at roguewave dot com wrote:
> My preference would be for gcc to avoid imposing restrictions on the use
> of these helpers to facilitate portability to other compilers
--- Comment #6 from sebor at roguewave dot com 2008-07-14 15:24 ---
(In reply to comment #4)
> ... Is it a reasonable
> restriction on users to say "thou shalt not use __is_empty in an expression
> that gets mangled"? For example, can the user just use std::is_empty instead?
As a data
--- Comment #5 from paolo dot carlini at oracle dot com 2008-07-14 09:15
---
(In reply to comment #4)
> I think the first thing is to figure out what mangling we want for these
> things > and if they should be mangled at all. The C++ ABI doesn't specify a
> mangling for these operato
--- Comment #4 from mmitchel at gcc dot gnu dot org 2008-07-13 17:41
---
Paolo --
I think the first thing is to figure out what mangling we want for these things
-- and if they should be mangled at all. The C++ ABI doesn't specify a
mangling for these operators, since it doesn't speci
--- Comment #3 from paolo dot carlini at oracle dot com 2008-07-11 13:54
---
Hi again, Mark...
I'm looking into this issue. Does it make sense to you that we need to add a
new operators.def entry? I quickly hacked this addition:
DEF_SIMPLE_OPERATOR ("trait", TRAIT_EXPR, "xx", 2)
and
--- Comment #2 from paolo dot carlini at oracle dot com 2008-07-11 11:12
---
Of course I meant mangling not demangling
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797
--- Comment #1 from paolo dot carlini at oracle dot com 2008-07-11 11:08
---
Funny, the problem happen very late. in the demangler. A "workaround" is using
std::is_empty ;)
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
12 matches
Mail list logo