[Bug c++/36797] ICE on SFINAE and __is_empty
--- 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 |Added CC||jason at gcc dot gnu dot org AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu |dot com |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797
[Bug c++/36797] ICE on SFINAE and __is_empty
--- 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 operators, since it doesn't specify these operators at all. They're really an implementation detail. So, the first question is Do these operators need to appear in mangled names at all? 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? Thanks for your feedback, Mark. Frankly, at the moment I don't have a strong opinion, but I'm wondering if existing practice can help us about those points: in fact such builtins are modeled after the existing Microsoft builtins: http://msdn.microsoft.com/de-de/library/ms177194.aspx and probably knowing what Microsoft is doing could help... However, I don't think Visual c++ uses our multivendor ABI, thus I'm not sure investigating that point could suggest a specific mangling. What do you think? (well, in case we are going to need help from people owning a recent Visual C++...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797
[Bug c++/36797] ICE on SFINAE and __is_empty
--- 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 point, consider that the user may be an author of a third party implementation of the C++ standard library (such as Apache/Rogue Wave or STLport), and they may not be able to use std::is_empty for reasons unique to their project (e.g., policy or otherwise). My preference would be for gcc to avoid imposing restrictions on the use of these helpers to facilitate portability to other compilers such as EDG eccp (the latest 3.10.1 compiles the test case correctly). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797
[Bug c++/36797] ICE on SFINAE and __is_empty
--- 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 such as EDG eccp (the latest 3.10.1 compiles the test case correctly). How does it mangle it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797
[Bug c++/36797] ICE on SFINAE and __is_empty
--- 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 facilitate portability to other compilers such as EDG eccp (the latest 3.10.1 compiles the test case correctly). How does it mangle it? Like so: int fooA0 (BA0, __is_empty (A0)::X*): _Z3fooI1AILi0EEEiPN1BIT_Xv19builtin16TOS3_EE1XE int fooint(Bint, !__is_empty (int)::X*): _Z3fooIiEiPN1BIT_Xntv19builtin16TOS1_EE1XE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797
[Bug c++/36797] ICE on SFINAE and __is_empty
--- 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 fooA0 (BA0, __is_empty (A0)::X*): _Z3fooI1AILi0EEEiPN1BIT_Xv19builtin16TOS3_EE1XE int fooint(Bint, !__is_empty (int)::X*): _Z3fooIiEiPN1BIT_Xntv19builtin16TOS1_EE1XE OK. I don't see anything inherently wrong with that mangling, though of course if we're going to make this standard, we need EDG's table of builtins (so we known which ones are which), and we need to specify semantics for each of the builtins so that we know that we can mix object files between different compilers. (No good if G++'s __is_empty is somehow subtly different than EDG's __is_empty.) So, I think the high-order issues here are still: (1) Do we need a mangling? (I know you think we do.) (2) If so, do we want to specify it at the ABI level, or use something G++-specific? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797
[Bug c++/36797] ICE on SFINAE and __is_empty
--- 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 EDG and gcc used Howard Hinnant's Compiler Support for type_traits as the starting point: http://home.twcny.rr.com/hinnant/cpp_extensions/cpp_extensions AFAICS, the built-ins aren't document in any detail in the EDG eccp manual. Finally, if you intend to provide ABI compatibility with the EDG eccp front end (or vice versa) I'd suggest getting someone from EDG involved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797
[Bug c++/36797] ICE on SFINAE and __is_empty
--- 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 specify these operators at all. They're really an implementation detail. So, the first question is Do these operators need to appear in mangled names at all? 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? If we don't think that's a reasonable restriction, then we have to decide whether we want to standardize the mangling, or not. If we do, then we should raise the issue on the C++ ABI list, and make a suggestion as to how to mangle them. If we don't, we could mangle this as a function call to a function named __is_emptyT::operator ()(), or something. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797
[Bug c++/36797] ICE on SFINAE and __is_empty
--- 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 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-07-11 11:08:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797
[Bug c++/36797] ICE on SFINAE and __is_empty
--- 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
[Bug c++/36797] ICE on SFINAE and __is_empty
--- 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 write_expression doesn't crash anymore at the write_string at line 2163 (when (int) code == TRAIT_EXPR) In case, however, I would need help for the arguments of the above.. Thanks in advance! -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||mark at codesourcery dot com AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797
