Please post a ChangeLog entry with a patch. Someone added one for
you:
2011-10-17 Michael Spertus mike_sper...@symantec.com
* 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.
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 mike_sper...@symantec.com
+
+ *
On 10/13/2011 01:35 PM, Michael Spertus wrote:
+int main() {
+ assert(typeid(bF::type)
+ == typeid(typesA,C,D,A,C,D,B,C,C,D,B,E));
+ assert(typeid(dbF::type) == typeid(typesA,B,E));
+ assert(typeid(dbint::type) == typeid(types));
+ return 0;
+}
Let's make this a compile-time test
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
Looks good, thanks. I'll let Benjamin check this in.
Jason
:)
-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 traits and base classes
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
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
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
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
The code looks good, though you are still missing some spaces before
'('. The main thing left is some testcases.
Jason
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,
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
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
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
templatetypename... T struct typelist {}; // Variadic templates rock
If bases returns a typelist, the
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
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
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
templatetypename... T struct typelist {}; // Variadic templates rock
If bases returns a typelist, the program
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 b...@redhat.com
+ * doc/Makefile.am: Add tr2 support.
+ *
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
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
22 matches
Mail list logo
