From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7570 invoked by alias); 5 Nov 2002 08:26:37 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 7539 invoked from network); 5 Nov 2002 08:26:37 -0000 Received: from unknown (HELO cerbere.u-strasbg.fr) (130.79.112.250) by sources.redhat.com with SMTP; 5 Nov 2002 08:26:37 -0000 Received: from laocoon.ics.u-strasbg.fr (laocoon.u-strasbg.fr [130.79.112.72]) by cerbere.u-strasbg.fr (Postfix) with ESMTP id DC34E5AB; Tue, 5 Nov 2002 09:36:53 +0100 (CET) Message-Id: <5.0.2.1.2.20021104155200.021581c0@ics.u-strasbg.fr> X-Sender: muller@ics.u-strasbg.fr Date: Tue, 05 Nov 2002 00:26:00 -0000 To: Elena Zannoni From: Pierre Muller Subject: Re: [RFA] Fix an error in value_change_enclosing_type Cc: gdb-patches@sources.redhat.com In-Reply-To: <15813.47549.125741.380864@localhost.redhat.com> References: <5.0.2.1.2.20021028150203.02ffe2c8@ics.u-strasbg.fr> <3.0.6.32.20021020235330.00c24478@ics.u-strasbg.fr> <5.0.2.1.2.20021007132114.01e66260@ics.u-strasbg.fr> <5.0.2.1.2.20021028150203.02ffe2c8@ics.u-strasbg.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-SW-Source: 2002-11/txt/msg00047.txt.bz2 At 01:05 04/11/2002, Elena Zannoni wrote: >Pierre Muller writes: > > A 22:39 22/10/2002, Elena Zannoni a écrit : > > >muller@cerbere.u-strasbg.fr writes: > > > > At 17:05 18/10/2002 -0400, Elena Zannoni wrote: > > > > >Pierre Muller writes: > > > > > > > > > > > > > > > > > > > > > > > > the function value_change_enclosing_type > > > > > > does not set the enlclosing_type field correctly if > > > > > > the new_encl_type has a bigger length that the value type. > > > > > > > > > > > > Its seems quite astonishing that this has not been noticed before, > > > > > > but I discovered it when trying to get > > > > > > the fpc-abi.c code to work correctly. > > > > > > > > > > > > > > > >The fix seems OK. However, do you have a small testcase? It would be > > > > >good to add it to the testsuite. > > > > Sorry, but I don't have any, because I really don't even know > > > > if this code is ever executed for C code. It is for > > > > Free Pascal generated code, that is how I discovered that bug. > > > > But I can't add tests with Free Pascal anyhow. > > > > > > > > > >Oh, ok. > > > > > > > >Does this fix changes the results for the already existing tests? > > > > > > > > Sorry, but I never worked with the testsuite, > > > > so I can't answer this question. > > > > > > > > > >Could you run make check in your gdb/testsuite directory in the build > > >tree? All I meant is, whether or not the test results are different > > >before and after your change. > > > > > >thanks > > >Elena > > > > > > I tried to create a test program > > using C++ code, but it does never seem to > > use the code that I modified... > > > > Thus, as I expected, the testsuite is unchanged: > > > > Tested on a i386 linux box: > > (note that pthreads libs is not installed on that machine, > > which creates several failures) > > cvs tree from 29/10/2002: > > > >There is on more pass with your patch, looks like. Which test passed? >It could be a transient failure. As explained below: > But the only difference is between gdbcvs.sum and modgdb.sum > > is > > 5166c5166 > > < FAIL: gdb.c++/annota2.exp: annotate-quit > > --- > > > PASS: gdb.c++/annota2.exp: annotate-quit > > > > which, when you look into gdb.c++/annota2.exp > > is said to be a tests that fails sometimes, but unreproducably. > > > > So I think that we can consider that the > > testsuite result is unchanged. >Otherwise, ok. > >Elena Thanks, I commited the patch today, I just change the date in the ChangeLog...