From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23472 invoked by alias); 29 Oct 2002 09:07:22 -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 23388 invoked from network); 29 Oct 2002 09:07:21 -0000 Received: from unknown (HELO cerbere.u-strasbg.fr) (130.79.112.250) by sources.redhat.com with SMTP; 29 Oct 2002 09:07:21 -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 B706C3EF; Tue, 29 Oct 2002 10:15:04 +0100 (CET) Message-Id: <5.0.2.1.2.20021028150203.02ffe2c8@ics.u-strasbg.fr> X-Sender: muller@ics.u-strasbg.fr Date: Tue, 29 Oct 2002 01:07: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: <15797.50576.457181.289982@localhost.redhat.com> References: <3.0.6.32.20021020235330.00c24478@ics.u-strasbg.fr> <5.0.2.1.2.20021007132114.01e66260@ics.u-strasbg.fr> <3.0.6.32.20021020235330.00c24478@ics.u-strasbg.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-SW-Source: 2002-10/txt/msg00580.txt.bz2 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: === gdb Summary === # of expected passes 8235 # of unexpected failures 52 # of unexpected successes 10 # of expected failures 168 # of unresolved testcases 3 # of untested testcases 9 # of unsupported tests 4 /home/pierre/gdb/build/origdb/testsuite/../../gdb/gdb version 2002-10-29-cvs -nx same cvs tree + my patch : === gdb Summary === # of expected passes 8236 # of unexpected failures 51 # of unexpected successes 10 # of expected failures 168 # of unresolved testcases 3 # of untested testcases 9 # of unsupported tests 4 /home/pierre/gdb/build/origdb/testsuite/../../gdb/gdb version 2002-10-29-cvs -nx 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. Can I commit the patch?