> Please post a ChangeLog entry with a patch. Someone added one for
> you:
>
> 2011-10-17 Michael Spertus
>
> * gcc/c-family/c-common.c (c_common_reswords): Add __bases,
> __direct_bases.
> * gcc/c-family/c-common.h: Add RID_BASES and RID_DIRECT_BASES.
>
> but it is in the
> This patch consists intrinsics to properly create the bases and
> direct_bases of a class in the correct order (including multiple nested
> ambiguous virtual and non-virtual classes) for N2965
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2965.html).
> This allows you to create type
This is now in, thanks everybody for playing! Attached is the final
diff.
tested x86_64/linux
-benjamindiff --git a/gcc/ChangeLog b/gcc/ChangeLog
index ddc5149..6c73404 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2011-10-17 Michael Spertus
+
+ * gcc/c-family/c-common.c (c_
:)
> -Original Message-
> From: Jason Merrill [mailto:ja...@redhat.com]
> Sent: Friday, October 14, 2011 2:41 PM
> To: Michael Spertus
> Cc: Benjamin Kosnik; Jonathan Wakely; gcc-patches@gcc.gnu.org;
> libstd...@gcc.gnu.org
> Subject: Re: Intrinsics for N2965: Type tr
Looks good, thanks. I'll let Benjamin check this in.
Jason
Redo test to run at compile-time per Jason's suggestion
Index: libstdc++-v3/include/tr2/type_traits
===
--- libstdc++-v3/include/tr2/type_traits(revision 0)
+++ libstdc++-v3/include/tr2/type_traits(revision 0)
@@ -0,0
On 10/13/2011 01:35 PM, Michael Spertus wrote:
+int main() {
+ assert(typeid(b::type)
+ == typeid(types));
+ assert(typeid(db::type) == typeid(types));
+ assert(typeid(db::type) == typeid(types<>));
+ return 0;
+}
Let's make this a compile-time test using something like
template s
Addressing Jason's comments:
Index: libstdc++-v3/include/tr2/type_traits
===
--- libstdc++-v3/include/tr2/type_traits(revision 0)
+++ libstdc++-v3/include/tr2/type_traits(revision 0)
@@ -0,0 +1,96 @@
+// TR2 type_trait
This is looking pretty good, from the libstdc++ side. This latest round
of gcc hacking fixes the previous testsuite fixes, so once you get
the gcc bits OK'd by Jason you can check in.
> I'd still like to see some testcases for the intrinsic, independent
> of the library.
Seems like some simple t
On 10/09/2011 08:13 PM, Michael Spertus wrote:
+dfs_calculate_bases_pre (tree binfo, void *data_)
+{
+ (void)data_;
You can use ATTRIBUTE_UNUSED to mark an unused parameter.
I'd still like to see some testcases for the intrinsic, independent of
the library.
Jason
Here is a new diff that works for non-class types (fixing Benjamin's failing
test), fixes some spacing and alphabetization, and doesn't inadvertently break
the __underlying_type trait.
Index: libstdc++-v3/include/tr2/type_traits
===
> Hey! Here is a preliminary test suite. Just the basics on this one.
> There's a bit of an issue with fundamental types, ICEs, but seems
> fixable.
here's the pre-processed sources for the ICE
-benjamin
ice-reflection-1.ii.bz2
Description: application/bzip
> OK. Here is a new diff that hopefully takes into account all of
> Jason's and Benjamin's comments. Benjamin's TR2 build patch is not
> repeated (or tested!) here. Benjamin, I'd really appreciate if you
> wouldn't mind confirming I handled that correctly in tr2/type_traits
> (Including the inclus
On 3 October 2011 02:55, Michael Spertus wrote:
> Index: gcc/c-family/c-common.h
> ===
> --- gcc/c-family/c-common.h (revision 178892)
> +++ gcc/c-family/c-common.h (working copy)
> @@ -139,7 +139,8 @@
> RID_IS_LITERAL_TYPE,
The code looks good, though you are still missing some spaces before
'('. The main thing left is some testcases.
Jason
OK. Here is a new diff that hopefully takes into account all of Jason's and
Benjamin's comments. Benjamin's TR2 build patch is not repeated (or tested!)
here. Benjamin, I'd really appreciate if you wouldn't mind confirming I handled
that correctly in tr2/type_traits (Including the inclusion of s
> OK. Here are some simple benchmarks. I simulated heavy use of
> reflection with 1000 classes that each had about a thousand base
> classes. I also created a super-simple typelist class
>
> template struct typelist {}; // Variadic templates rock
>
> If bases returns a typelist, the program take
OK. Here are some simple benchmarks. I simulated heavy use of reflection
with 1000 classes that each had about a thousand base classes. I also
created a super-simple typelist class
template struct typelist {}; // Variadic templates rock
If bases returns a typelist, the program takes about 4 se
Don't worry, I'm not suggesting including boost::mpl at all, just
leaving the return type of the bases trait unspecified. IMO, your
example illustrates my point that without performance tuning, compiling
metaprograms can be prohibitively expensive, so I want to avoid running
the tuple metaprogr
On 28 September 2011 04:22, Michael Spertus wrote:
> Benjamin,
> I think tuple is wrong both for performance reasons (I believe these are
> likely to be serious enough to depress use due to inordinately long compiles)
> and because it prematurely locks us into a rigid choice of how our typelists
Benjamin,
I think tuple is wrong both for performance reasons (I believe these are likely
to be serious enough to depress use due to inordinately long compiles) and
because it prematurely locks us into a rigid choice of how our typelists are
implemented.
My inclination is to make it type-indep
Oops, this is the right patch.
-benjamindiff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index a59a0b6..e1176ee 100644
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
@@ -1,5 +1,14 @@
2011-09-27 Benjamin Kosnik
+ * doc/Makefile.am: Add tr2 support.
+ * doc/Makefile.in
> This patch consists intrinsics to properly create the bases and
> direct_bases of a class in the correct order (including multiple
> nested ambiguous virtual and non-virtual classes) for N2965
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2965.html).
> This allows you to create
On 09/26/2011 11:50 AM, Mike Spertus wrote:
This patch consists intrinsics to properly create the bases and direct_bases of
a class
Looks pretty good. Some comments:
#define GCC_TREE_H
-
#include "hashtab.h"
I don't see any reason to remove this blank line.
+ if (TREE_CODE (par
This patch consists intrinsics to properly create the bases and
direct_bases of a class in the correct order (including multiple nested
ambiguous virtual and non-virtual classes) for N2965
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2965.html).
This allows you to create type trait
25 matches
Mail list logo
