[Bug c++/39405] std::shared_ptr barfs on incomplete template class that boost::shared_ptr accepts

2009-03-13 Thread paolo dot carlini at oracle dot com


--- Comment #13 from paolo dot carlini at oracle dot com  2009-03-13 14:58 
---
I see, thanks a lot for your help. The most important point I was missing is
the use of add_reference in shared_ptr...


-- 


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



[Bug c++/39405] std::shared_ptr barfs on incomplete template class that boost::shared_ptr accepts

2009-03-13 Thread d dot frey at gmx dot de


--- Comment #12 from d dot frey at gmx dot de  2009-03-13 14:53 ---
(In reply to comment #11)
> I understand. Too bad that we can't make it to work for 4.3.x without
> regressing on libstdc++/35637 :( I'm puzzled by the fact that the tr1 version
> works, only is_reference is really different in that case... If you can spot
> something please let me know... Otherwise I will just add the testcase.

I think I might have a solution, thanks to the hint to the difference of std::
vs. std::tr1:: you found.

In tr1, shared_ptr uses std::tr1::add_reference instead of
std::add_lvalue_reference. This seems to trigger it, here's a reduced testcase:

#include 
#include 

template
struct ptr
{
   // this works:
   // typename std::tr1::add_reference::type dummy() const;

   // this fails:
   typename std::add_lvalue_reference::type dummy() const;
};

template
struct foo
{
   ptr< foo > p;
};

int main()
{
   (void)std::is_abstract< foo >::value;
}

The error message shows the following loop:

from main: std::is_abstract
  instantiates T (here: foo)
which instantiates ptr
which instantiates std::add_lvalue_reference
which instantiates std::is_function
which instantiates std::is_abstract
which fails because this is what the compiler is trying to do in the first
place.

To break this loop, the following works:

In /usr/include/c++/4.3.2/tr1_impl/type_traits, change is_function from

  /// is_function
  template
struct is_function
: public integral_constant::__value
   || is_abstract<_Tp>::value
   || is_reference<_Tp>::value
   || is_void<_Tp>::value)>
{ };

to

  /// is_function
  template
struct is_function
: public integral_constant::__value
   || __is_abstract(_Tp)
   || is_reference<_Tp>::value
   || is_void<_Tp>::value)>
{ };


-- 


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



[Bug c++/39405] std::shared_ptr barfs on incomplete template class that boost::shared_ptr accepts

2009-03-13 Thread paolo dot carlini at oracle dot com


--- Comment #11 from paolo dot carlini at oracle dot com  2009-03-13 13:22 
---
(In reply to comment #10)
> OK, I see. So maybe not worth the effort to fix in 4.3.x as long as 4.4.0 is
> fine. To make sure, could you (Paolo) please add a testcase for this to the
> testsuite for 4.4.0/trunk in case there isn't one already? The use case is 
> very
> common in our code.

I understand. Too bad that we can't make it to work for 4.3.x without
regressing on libstdc++/35637 :( I'm puzzled by the fact that the tr1 version
works, only is_reference is really different in that case... If you can spot
something please let me know... Otherwise I will just add the testcase.


-- 


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



[Bug c++/39405] std::shared_ptr barfs on incomplete template class that boost::shared_ptr accepts

2009-03-13 Thread d dot frey at gmx dot de


--- Comment #10 from d dot frey at gmx dot de  2009-03-13 13:14 ---
(In reply to comment #8)
> Moreover, if we ""fix"" this issue at the library level without dealing with
> the real C++ front-end issue, we regress on libstdc++/35637, of course.

OK, I see. So maybe not worth the effort to fix in 4.3.x as long as 4.4.0 is
fine. To make sure, could you (Paolo) please add a testcase for this to the
testsuite for 4.4.0/trunk in case there isn't one already? The use case is very
common in our code. TIA.


-- 


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



[Bug c++/39405] std::shared_ptr barfs on incomplete template class that boost::shared_ptr accepts

2009-03-13 Thread paolo dot carlini at oracle dot com


--- Comment #9 from paolo dot carlini at oracle dot com  2009-03-13 13:13 
---
(In reply to comment #7)
> It is a library change in the sense that it triggers a bug in the c++
> front-end. Because of course the library afterwards remained the same and the
> problem is not there anymore...

Sorry, this last part is incorrect. Now, in mainline, we are back to the
preferred way of doing is_function, using variadic templates. Really the
problem is libstdc++/35637, which required reverting to the old way. I don't
think we can really fix the issue in the 4.3.x branch without regressing on
libstdc++/35637, but if people can live with the latter and a 4.3.4 will be
prepared, we can reconsider the issue.


-- 


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



[Bug c++/39405] std::shared_ptr barfs on incomplete template class that boost::shared_ptr accepts

2009-03-13 Thread paolo dot carlini at oracle dot com


--- Comment #8 from paolo dot carlini at oracle dot com  2009-03-13 13:02 
---
Moreover, if we ""fix"" this issue at the library level without dealing with
the real C++ front-end issue, we regress on libstdc++/35637, of course.


-- 


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



[Bug c++/39405] std::shared_ptr barfs on incomplete template class that boost::shared_ptr accepts

2009-03-13 Thread paolo dot carlini at oracle dot com


--- Comment #7 from paolo dot carlini at oracle dot com  2009-03-13 13:00 
---
It is a library change in the sense that it triggers a bug in the c++
front-end. Because of course the library afterwards remained the same and the
problem is not there anymore... We'll see, in case of a 4.3.4 release we can
consider that workaround.


-- 


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



[Bug c++/39405] std::shared_ptr barfs on incomplete template class that boost::shared_ptr accepts

2009-03-13 Thread d dot frey at gmx dot de


--- Comment #6 from d dot frey at gmx dot de  2009-03-13 12:49 ---
(In reply to comment #5)

More information on this:

> > > The bug is in both 4.3.3 and 4.3.2, however it isn't in 4.3.0 on a
> > > sparcv9-sun-solaris2.10 box with 64bits. Haven't got any 4.3.1 to try.

I've copied to header from said machine on my Ubuntu machine. Colin's test case
fails with Ubuntu's current version of GCC 4.3.2. Then I replaced
/use/include/c++/4.3.2/tr1_impl/type_traits with the header from 4.3.0 and the
test case passes. Hence, it *is* a library change.

Regards, Daniel

PS: The relevant chunk of the diff between the two headers:

--- /home/frey/type_traits  2009-03-13 13:00:54.0 +0100
+++ /usr/include/c++/4.3.2/tr1_impl/type_traits 2009-01-24 07:11:38.0
+0100
@@ -125,78 +132,94 @@
 struct is_array<_Tp[]>
 : public true_type { };

+  /// is_pointer
   template
 struct is_pointer
 : public false_type { };
   _DEFINE_SPEC(1, is_pointer, _Tp*, true)

+  /// is_reference
   template
 struct is_reference;

+  /// is_function
   template
 struct is_function;

+  /// is_member_object_pointer
   template
 struct is_member_object_pointer
 : public false_type { };
   _DEFINE_SPEC(2, is_member_object_pointer, _Tp _Cp::*,
   !is_function<_Tp>::value)

+  /// is_member_function_pointer
   template
 struct is_member_function_pointer
 : public false_type { };
   _DEFINE_SPEC(2, is_member_function_pointer, _Tp _Cp::*,
   is_function<_Tp>::value)

+  /// is_enum
   template
 struct is_enum
 : public integral_constant
 { };

+  /// is_union
   template
 struct is_union
 : public integral_constant
 { };

+  /// is_class
   template
 struct is_class
 : public integral_constant
 { };

-  template
-struct __is_function_helper
-: public false_type { };
-
-  template
-struct __is_function_helper<_Res(_ArgTypes...)>
-: public true_type { };
-
-  template
-struct __is_function_helper<_Res(_ArgTypes..)>
-: public true_type { };
+  template
+struct __in_array
+: public __sfinae_types
+{
+private:
+  template
+static __one __test(_Up(*)[1]);
+  template
+static __two __test(...);
+
+public:
+  static const bool __value = sizeof(__test<_Tp>(0)) == 1;
+};

+  /// is_abstract
   template
-struct remove_cv;
+struct is_abstract;

+  /// is_function
   template
 struct is_function
-: public integral_constant::type>::value)>
+: public integral_constant::__value
+  || is_abstract<_Tp>::value
+  || is_reference<_Tp>::value
+  || is_void<_Tp>::value)>
 { };

-  /// @brief  composite type traits [4.5.2].
+  /// composite type traits [4.5.2].
   template
 struct is_arithmetic
 : public integral_constant::value
  || is_floating_point<_Tp>::value)>
 { };

+  /// is_fundamental
   template
 struct is_fundamental
 : public integral_constant::value
  || is_void<_Tp>::value)>
 { };

+  /// is_object
   template
 struct is_object
 : public integral_constant::value


-- 


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



[Bug c++/39405] std::shared_ptr barfs on incomplete template class that boost::shared_ptr accepts

2009-03-13 Thread d dot frey at gmx dot de


--- Comment #5 from d dot frey at gmx dot de  2009-03-13 12:23 ---
(In reply to comment #4)
> > The bug is in both 4.3.3 and 4.3.2, however it isn't in 4.3.0 on a
> > sparcv9-sun-solaris2.10 box with 64bits. Haven't got any 4.3.1 to try.
> 
> Ok. I went through the change which went in *the library* between 4.3.0 and
> 4.3.2 and indeed, it seems extremely unlikely that the regression has been
> caused by a library change. Thus, it seems a C++ front-end change.

Are you sure? tr1_impl/type_traits has changes for is_function, and this
seems to be part of the problem as it appears in the error message of this
bug's example.


-- 

d dot frey at gmx dot de changed:

   What|Removed |Added

 CC||d dot frey at gmx dot de


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



[Bug c++/39405] std::shared_ptr barfs on incomplete template class that boost::shared_ptr accepts

2009-03-13 Thread paolo dot carlini at oracle dot com


--- Comment #4 from paolo dot carlini at oracle dot com  2009-03-13 09:43 
---
(In reply to comment #3)
> The bug is in both 4.3.3 and 4.3.2, however it isn't in 4.3.0 on a
> sparcv9-sun-solaris2.10 box with 64bits. Haven't got any 4.3.1 to try.

Ok. I went through the change which went in *the library* between 4.3.0 and
4.3.2 and indeed, it seems extremely unlikely that the regression has been
caused by a library change. Thus, it seems a C++ front-end change.

> If 4.4.0 is out before 4.3.4 (if there is such a thing), it might not really
> not be worth it, otoh it does seem to be a regression within the 4.3 line...

I see. I think 4.4.0 will be out before 4.3.4, actually, I'm not even sure
there will be a 4.3.4... In any case, if we want to attempt something here, we
badly need a short, reduced, pure C++ testcase, no includes... Anybody
volunteering?


-- 


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



[Bug c++/39405] std::shared_ptr barfs on incomplete template class that boost::shared_ptr accepts

2009-03-13 Thread gcc at cohi dot at


--- Comment #3 from gcc at cohi dot at  2009-03-13 07:33 ---
The bug is in both 4.3.3 and 4.3.2, however it isn't in 4.3.0 on a
sparcv9-sun-solaris2.10 box with 64bits. Haven't got any 4.3.1 to try.

If 4.4.0 is out before 4.3.4 (if there is such a thing), it might not really
not be worth it, otoh it does seem to be a regression within the 4.3 line...


-- 


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



[Bug c++/39405] std::shared_ptr barfs on incomplete template class that boost::shared_ptr accepts

2009-03-12 Thread paolo dot carlini at oracle dot com


--- Comment #2 from paolo dot carlini at oracle dot com  2009-03-12 20:01 
---
Indeed, mainline is fine. Do we have evidence that some earlier 4.3.x release
worked? Because, otherwise, given that 4.3.x is approaching is end of life in
terms of expected releases, this issue can be safely closed.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||paolo dot carlini at oracle
   ||dot com


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



[Bug c++/39405] std::shared_ptr barfs on incomplete template class that boost::shared_ptr accepts

2009-03-12 Thread gcc at cohi dot at


--- Comment #1 from gcc at cohi dot at  2009-03-12 17:00 ---
Just now I installed pre-release gcc-4.4-20090306 and there is no error with
t.cc as shown, so it seems to be a bug that has been already fixed; I didn't
check any 4.3.4 pre-release however.


-- 


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