[Bug c++/36797] New: ICE on SFINAE and __is_empty

[Bug c++/36797] New: ICE on SFINAE and __is_empty

[sebor at roguewave dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1009 bytes --]

gcc 4.3.0 crashes compiling the program below:

$ cat z.C && g++ z.C
template <int> struct A { };
template <class, bool> struct B;
template <class T> struct B<T, true> { typedef T X; };

template <class T>
int foo (typename B<T, __is_empty (T)>::X* = 0) { return 0; }

template <class T>
int foo (typename B<T, !__is_empty (T)>::X* = 0) { return 1; }

int main ()
{
    foo<A<0> >();
}
z.C: In function ‘int foo(typename B<T, __is_empty(T)>::X*) [with T = A<0>]’:
z.C:6: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


-- 
           Summary: ICE on SFINAE and __is_empty
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: sebor at roguewave dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797

[Bug c++/36797] ICE on SFINAE and __is_empty

[paolo dot carlini at oracle dot com]

------- 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|0000-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

[paolo dot carlini at oracle dot com]

------- 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

[paolo dot carlini at oracle dot com]

------- 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

[Bug c++/36797] ICE on SFINAE and __is_empty

[mmitchel at gcc dot gnu dot org]

------- 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_empty<T>::operator ()()", or something.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797

[Bug c++/36797] ICE on SFINAE and __is_empty

[paolo dot carlini at oracle dot com]

------- 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

[sebor at roguewave dot com]

------- 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

[mark at codesourcery dot com]

------- 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

[sebor at roguewave dot com]

------- 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 foo<A<0> >(B<A<0>, __is_empty (A<0>)>::X*):
        _Z3fooI1AILi0EEEiPN1BIT_Xv19builtin16TOS3_EE1XE

    int foo<int>(B<int, !__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

[mark at codesourcery dot com]

------- 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<A<0> >(B<A<0>, __is_empty (A<0>)>::X*):
>         _Z3fooI1AILi0EEEiPN1BIT_Xv19builtin16TOS3_EE1XE
> 
>     int foo<int>(B<int, !__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

[sebor at roguewave dot com]

------- 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

[paolo dot carlini at oracle dot com]

------- 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

[jason at gcc dot gnu dot org]

------- 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 know the final
set of trait builtins we want for C++0x.  People can work around this issue by
either using std::is_empty or making their own equivalent class template.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797

[Bug c++/36797] ICE mangling __is_empty

[jason at gcc dot gnu dot org]

------- Comment #13 from jason at gcc dot gnu dot org  2010-04-21 22:49 -------
Changing summary and suspending until C++0x is finalized.


-- 

jason at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |SUSPENDED
            Summary|ICE on SFINAE and __is_empty|ICE mangling __is_empty


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797