On 03/11/2011 10:15 AM, Dodji Seketeli wrote:
I have updated is_virtual_base_of to make it test if the current field
represents a virtual base. Is there a simpler way to detect that?
Yeah, let's go with Jakub's patch.
Jason
On 03/11/2011 10:08 AM, Jakub Jelinek wrote:
It worked, here is what I've bootstrapped/regtested on x86_64-linux and
i686-linux. Is that ok then?
OK.
Jason
lds to zero, because, e.g, for member pointers fields the
ABI states that a NULL pointer is represented as -1.
So this is the patch I am currently testing.
--
Dodji
>From 6a757e998cb6b09883ec366c8c8939a70a215600 Mon Sep 17 00:00:00 2001
From: Dodji Seketeli
Date: F
On Fri, Mar 11, 2011 at 09:56:59AM -0500, Jason Merrill wrote:
> On 03/11/2011 03:01 AM, Jakub Jelinek wrote:
> >Do we need to redo parts of class.c anyway? From what I understand, the
> >problematic vtbl pointers are at the end of the base types and DECL_SIZE
> >is set to the CLASSTYPE_AS_BASE ty
On 03/11/2011 03:01 AM, Jakub Jelinek wrote:
Do we need to redo parts of class.c anyway? From what I understand, the
problematic vtbl pointers are at the end of the base types and DECL_SIZE
is set to the CLASSTYPE_AS_BASE type size, thus those pointers ought to
be at or beyond the containing fie
On Fri, Mar 11, 2011 at 09:01:40AM +0100, Jakub Jelinek wrote:
> Do we need to redo parts of class.c anyway? From what I understand, the
> problematic vtbl pointers are at the end of the base types and DECL_SIZE
> is set to the CLASSTYPE_AS_BASE type size, thus those pointers ought to
> be at or b
On Thu, Mar 10, 2011 at 06:02:50PM -0500, Jason Merrill wrote:
> On 03/10/2011 11:14 AM, Dodji Seketeli wrote:
> >+ /* If we are initializing a sub-object of
> >+ CURRENT_OBJECT_TYPE [for which a primary base class
> >+ sub-object has already been initialized] then we must NOT
On 03/10/2011 11:14 AM, Dodji Seketeli wrote:
+ /* If we are initializing a sub-object of
+CURRENT_OBJECT_TYPE [for which a primary base class
+sub-object has already been initialized] then we must NOT
+initialize any sub-object from a virtual base that
On 03/10/2011 03:45 PM, Jakub Jelinek wrote:
E.g.
http://gcc.gnu.org/wiki/HowToPrepareATestcase
recommends abort instead and it is existing practice too.
In the C++ testcase most testcases return non-zero to indicate failure.
The main reason for this is to avoid having to deal with declaring
Jakub Jelinek writes:
> http://gcc.gnu.org/wiki/HowToPrepareATestcase
> recommends abort instead and it is existing practice too.
Sure. I am going to update my local copy of the patch and re-post. I
used return as I noticed it was working. I didn't realize the
abort/exit was the recommended c
On Thu, Mar 10, 2011 at 12:31:57PM -0800, Mike Stump wrote:
> On Mar 10, 2011, at 10:22 AM, Jakub Jelinek wrote:
> > The standard way of signalizing a test failure is calling abort (),
> > not returning 1, see http://gcc.gnu.org/codingconventions.html
>
> Actually, returning 0 or 1 is a perfectly
On Mar 10, 2011, at 10:22 AM, Jakub Jelinek wrote:
> The standard way of signalizing a test failure is calling abort (),
> not returning 1, see http://gcc.gnu.org/codingconventions.html
Actually, returning 0 or 1 is a perfectly fine way to signal pass/fail in the
testsuites, as it exit.
On Thu, Mar 10, 2011 at 05:14:12PM +0100, Dodji Seketeli wrote:
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/inherit/virtual8.C
...
> +
> +int
> +main ()
> +{
> +char *v = new char[sizeof (E) + 16];
> +memset (v, 0x55, sizeof (E) + 16);
> +E *e = new (v) E ();
> +e->~E ();
> +
> +
ja-gnu test for this PR, and for bootstrapping the
patch on his fast iron on i686 and x86_64 for all languages.
--
Dodji
>From b52987810a313657202fc7ecae6b503311146302 Mon Sep 17 00:00:00 2001
From: Dodji Seketeli
Date: Thu, 10 Mar 2011 14:10:05 +0100
Subject: [PA
14 matches
Mail list logo
