Re: Compiling the GNU ada compiler on a very old platform

[Paul Smedley]

Hi Geert!

On Thu, 27 Aug 2009 01:44:11 UTC, Geert Bosch  
wrote:

> 
> On Aug 21, 2009, at 18:40, Paul Smedley wrote:
> > I'm wanting to update the GNU ADA compiler for OS/2... I'm currently
> > building GCC 4.3.x and 4.4.x on OS/2 (C/C++/fortran) but for ADA
> > configure complains about not finding gnat.  The problem is that the
> > only gnat compiled for OS/2 was years ago using a different toolchain
> > so it's not suitable.
> 
> I used to maintain the OS/2 port for AdaCore, but that was many years  
> ago.
> IBM released its last version of OS/2 in 2001. Currently it is almost
> impossible to run OS/2 in either real modern hardware or on a  
> virtualized
> system.
Not quite true - www.ecomstation.com - and it does run in things like 
virtualbox.  I'm running on a quad core system here and all 4 cores 
are recognised.

> AFAIK, GNAT 3.15p is the last GNAT version with OS/2 support. As the  
> OS/2
> version was a full implementation of Ada 95, including all annexes,  
> passing
> all ACATS tests, this version should still be very useful today, if you
> have a system running OS/2, that is. If you're interested in developing
> Ada applications on OS/2, your best bet is to use GNAT 3.15p.
> You'll get a mature well-tested and very fast compiler.
I don't actually NEED this :) Another member of the community inquired
about an updated gnat, so I thought I'd look at it.

With GNAT 3.15p did it also depend on an existing gnat? or that one 
built directory from source?

> This version might still be able to bootstrap GNAT.
It might - but I'm using a different c library :( libc vs emx

-- 
Cheers,

Paul.

Re: IRA undoing scheduling decisions

[Alex Turjan]

> With 4.4, IRA happens to reuse the same register for both pseudos, so 
> sched2 is hand tied and cannot schedule them back again for us.

I can imagine compiling other programs for which preserving the 4.3 allocation 
will induce performance degradation due to spilling. 

The register allocator tries to minimize the number of spills without taking 
into account the ILP implications (i.e., creating extra false dependencies). 
Perhaps one possible way to solve the problem would be to analyze why the 
register rename phase (which is responsible for spreading the registers) does 
not produces 2 registers.


--- On Wed, 8/26/09, Peter Bergner  wrote:

> From: Peter Bergner 
> Subject: Re: IRA undoing scheduling decisions
> To: "Charles J. Tabony" 
> Cc: gcc@gcc.gnu.org
> Date: Wednesday, August 26, 2009, 11:47 PM
> On Mon, 2009-08-24 at 23:56 +,
> Charles J. Tabony wrote:
> > I am seeing a performance regression on the port I
> maintain, and I would appreciate some pointers.
> > 
> > When I compile the following code
> > 
> > void f(int *x, int *y){
> >   *x = 7;
> >   *y = 4;
> > }
> > 
> > with GCC 4.3.2, I get the desired sequence of
> instructions.  I'll call it sequence A:
> > 
> > r0 = 7
> > r1 = 4
> > [x] = r0
> > [y] = r1
> > 
> > When I compile the same code with GCC 4.4.0, I get a
> sequence that is lower performance for my target
> machine.  I'll call it sequence B:
> > 
> > r0 = 7
> > [x] = r0
> > r0 = 4
> > [y] = r0
> 
> This is caused by update_equiv_regs() which IRA inherited
> from local-alloc.c.
> Although with gcc 4.3 and earlier, you don't see the
> problem, it is still there,
> because if you look at the 4.3 dumps, you will see that
> update_equiv_regs()
> unordered them for us.  What is saving us is that
> sched2 reschedules them
> again for us in the order we want.  With 4.4, IRA
> happens to reuse the same
> register for both pseudos, so sched2 is hand tied and
> cannot schedule them
> back again for us.
> 
> Looking at update_equiv_regs(), if I disable the
> replacement for regs
> that are local to one basic block (patch below) like it
> existed before
> John Wehle's patch way back in Oct 2000:
> 
>   http://gcc.gnu.org/ml/gcc-patches/2000-09/msg00782.html
> 
> then we get the ordering we want.  Does anyone know
> why John removed
> that part of the test in his patch?  Thoughts anyone?
> 
> 
> Peter
> 
> 
> Index: ira.c
> ===
> --- ira.c    (revision 15)
> +++ ira.c    (working copy)
> @@ -2510,6 +2510,7 @@ update_equiv_regs (void)
>           
>    calls.  */
>  
>            if
> (REG_N_REFS (regno) == 2
> +             
> && REG_BASIC_BLOCK (regno) < NUM_FIXED_BLOCKS
>               
> && (rtx_equal_p (x, src)
>             
>   || ! equiv_init_varies_p (src))
>               
> && NONJUMP_INSN_P (insn)
> 
> 
> 
> 

Help ! Frozen by a comment in gcc/c-common.h!

[Alexei I. Adamovich]

Hi All!

While modifying the C lexer to accommodate it for experimental
C-derived language front-end, I've stumbled across the following
comment in gcc/c-common.h before the "enum rid" definition (still
there in gcc-4.5-20090820 snapshot):

42 /* Reserved identifiers.  This is the union of all the keywords for C,
43C++, and Objective-C.  All the type modifiers have to be in one
44block at the beginning, because they are used as mask bits.  There
45are 27 type modifiers; if we add many more we will have to redesign
46the mask mechanism.  */
47 
48 enum rid
49 {
50   /* Modifiers: */
51   /* C, in empirical order of frequency.  */
52   RID_STATIC = 0,
53   RID_UNSIGNED, RID_LONG,RID_CONST, RID_EXTERN
...

Could you please enlighten me -- is the comment still relevant? If so,
where the usage of type modifiers entries in enum rid as mask bits can
be seen in gcc code (or documentation, if applicable)?

I'd like to be aware, since I've defined several (four) additional type
modifiers.

Thanks in advance,

Alexei I. Adamovich

Re: Anyone else run ACATS on ARM?

[Joel Sherrill]

Geert Bosch wrote:

On Aug 12, 2009, at 10:32, Joel Sherrill wrote:

  

Hi,

GNAT doesn't build for arm-rtems on 4.4.x or
SVN (PR40775).  I went back to 4.3.x since I
remembered it building.
I have run the ACATS on an ep7312 target and
get a number of generic test failures that
don't look RTEMS specific.  Has anyone run
ACATS on arm?



Yes, we ported it to ARM/Nucleus OS, and we required some fixes to
prologue generation. The patches we submitted for that to the
mailinglist and then pinged, were ignored. I'm sure this is in
the archives somewhere.
  

Thanks Geert.  I will try to dig them up and try them.

It will be next week before I can try this again.  Should
I file a PR to bump this up in visibility?

   -Geert
  

Re: r150960 changed ltmain.sh and broke the build

[Eric Blake]

Dave Korn  googlemail.com> writes:

>   No problem, thanks for worrying about it.  Are there any particular
> recommendations about/against problematic separator characters in the 's'
> command?  I was going to use an '@'.

The Autoconf manual suggests using 's|||' rather than 's,,,', since ',' and '@'
can both occur in unquoted filenames, but '|' cannot.

-- 
Eric Blake

Re: Compiling the GNU ada compiler on a very old platform

[Robert Dewar]

Paul Smedley wrote:

With GNAT 3.15p did it also depend on an existing gnat? or that one 
built directory from source?


Building GNAT from sources always requires an existing Ada compiler
since the front end is written in Ada. However, binary versions of
3.15p for OS/2 are around.



This version might still be able to bootstrap GNAT.

It might - but I'm using a different c library :( libc vs emx

Re: Why no strings in error messages?

[Andi Kleen]

Bradley Lucier  writes:

> and RBX is used by XLAT, XLATB. 

XLAT* is generally not used anymore, certainly not in gcc generated code.

> Are 12 registers not enough, in principle, to do scheduling before
> register allocation? 

You want to limit gcc to only 12 registers?

> I was getting a 15% speedup on some numerical

That would assume that only using 12 registers doesn't cause
slowdowns elsewhere, which is likely in fact.

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only.

Re: Anyone else run ACATS on ARM?

[Joel Sherrill]

Joel Sherrill wrote:

Geert Bosch wrote:
  

On Aug 12, 2009, at 10:32, Joel Sherrill wrote:

  


Hi,

GNAT doesn't build for arm-rtems on 4.4.x or
SVN (PR40775).  I went back to 4.3.x since I
remembered it building.
I have run the ACATS on an ep7312 target and
get a number of generic test failures that
don't look RTEMS specific.  Has anyone run
ACATS onl


--joel

arm?


  

Yes, we ported it to ARM/Nucleus OS, and we required some fixes to
prologue generation. The patches we submitted for that to the
mailinglist and then pinged, were ignored. I'm sure this is in
the archives somewhere.
  


Thanks Geert.  I will try to dig them up and try them.

  

I can't seem to find the patch.  Do you have a link?

It will be next week before I can try this again.  Should
I file a PR to bump this up in visibility?
  

   -Geert
  



  



--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
  Support Available (256) 722-9985

Re: r150960 changed ltmain.sh and broke the build

[Dave Korn]

Eric Blake wrote:
> Dave Korn  googlemail.com> writes:
> 
>>   No problem, thanks for worrying about it.  Are there any particular
>> recommendations about/against problematic separator characters in the 's'
>> command?  I was going to use an '@'.
> 
> The Autoconf manual suggests using 's|||' rather than 's,,,', 

  Where?  Not in the section about sed under 'Limitations of Usual Tools' in
the 2.64 info page, as far as I can see.

> since ',' and '@'
> can both occur in unquoted filenames, but '|' cannot.

  I can't grok that.  In what context could there ever be a confusion between
a sed script and a filename?  What about having a file with an "@" in the name
in the current directory would cause sed to do anything different with a -e
script containing an 's' expression using "@" as a separator?  I must be
feeling a bit slow this afternoon.

cheers,
  DaveK

Re: [gcc-in-cxx] Trunk fails to bootstrap with --enable-build-with-cxx

[Jason Merrill]

On 08/26/2009 05:36 PM, Ralf Wildenhues wrote:

* Jason Merrill wrote on Wed, Aug 26, 2009 at 10:32:05PM CEST:



The problem is that AC_CHECK_DECLS gets confused by overloaded
functions, and glibc 2.10 has overloaded declarations of basename
and some other string functions for const-correctness.


Could you show the config.log snippet that shows the failed test?
Is this a new error due to the autotools upgrade, or new due to
glibc 2.10?


The latter.

configure:5483: checking whether basename is declared
configure:5483: g++ -c -g  conftest.cpp >&5
conftest.cpp: In function 'int main()':
conftest.cpp:77: error: void cast cannot resolve address of overloaded 
function

configure:5483: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "cpplib"
| #define PACKAGE_TARNAME "cpplib"
| #define PACKAGE_VERSION " "
| #define PACKAGE_STRING "cpplib  "
| #define PACKAGE_BUGREPORT "gcc-b...@gcc.gnu.org"
| #define PACKAGE_URL ""
| #define TIME_WITH_SYS_TIME 1
| #define STRING_WITH_STRINGS 1
| #define HAVE_LOCALE_H 1
| #define HAVE_FCNTL_H 1
| #define HAVE_LIMITS_H 1
| #define HAVE_STDDEF_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_STRING_H 1
| #define HAVE_SYS_FILE_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_OBSTACK 1
| #define SIZEOF_INT 4
| #define SIZEOF_LONG 4
| #define HAVE_CLEARERR_UNLOCKED 1
| #define HAVE_FEOF_UNLOCKED 1
| #define HAVE_FERROR_UNLOCKED 1
| #define HAVE_FFLUSH_UNLOCKED 1
| #define HAVE_FGETC_UNLOCKED 1
| #define HAVE_FGETS_UNLOCKED 1
| #define HAVE_FILENO_UNLOCKED 1
| #define HAVE_FPUTC_UNLOCKED 1
| #define HAVE_FPUTS_UNLOCKED 1
| #define HAVE_FREAD_UNLOCKED 1
| #define HAVE_FWRITE_UNLOCKED 1
| #define HAVE_GETCHAR_UNLOCKED 1
| #define HAVE_GETC_UNLOCKED 1
| #define HAVE_PUTCHAR_UNLOCKED 1
| #define HAVE_PUTC_UNLOCKED 1
| #define HAVE_DECL_ABORT 1
| #define HAVE_DECL_ASPRINTF 1
| /* end confdefs.h.  */
| #include 
| #ifdef HAVE_SYS_TYPES_H
| # include 
| #endif
| #ifdef HAVE_SYS_STAT_H
| # include 
| #endif
| #ifdef STDC_HEADERS
| # include 
| # include 
| #else
| # ifdef HAVE_STDLIB_H
| #  include 
| # endif
| #endif
| #ifdef HAVE_STRING_H
| # if !defined STDC_HEADERS && defined HAVE_MEMORY_H
| #  include 
| # endif
| # include 
| #endif
| #ifdef HAVE_STRINGS_H
| # include 
| #endif
| #ifdef HAVE_INTTYPES_H
| # include 
| #endif
| #ifdef HAVE_STDINT_H
| # include 
| #endif
| #ifdef HAVE_UNISTD_H
| # include 
| #endif
| int
| main ()
| {
| #ifndef basename
|   (void) basename;
| #endif
|
|   ;
|   return 0;
| }
configure:5483: result: no

Re: Help ! Frozen by a comment in gcc/c-common.h!

[Ian Lance Taylor]

"Alexei I. Adamovich"  writes:

> While modifying the C lexer to accommodate it for experimental
> C-derived language front-end, I've stumbled across the following
> comment in gcc/c-common.h before the "enum rid" definition (still
> there in gcc-4.5-20090820 snapshot):
>
> 42 /* Reserved identifiers.  This is the union of all the keywords for C,
> 43C++, and Objective-C.  All the type modifiers have to be in one
> 44block at the beginning, because they are used as mask bits.  There
> 45are 27 type modifiers; if we add many more we will have to redesign
> 46the mask mechanism.  */
> 47 
> 48 enum rid
> 49 {
> 50   /* Modifiers: */
> 51   /* C, in empirical order of frequency.  */
> 52   RID_STATIC = 0,
> 53   RID_UNSIGNED, RID_LONG,RID_CONST, RID_EXTERN
> ...
>
> Could you please enlighten me -- is the comment still relevant? If so,
> where the usage of type modifiers entries in enum rid as mask bits can
> be seen in gcc code (or documentation, if applicable)?

I suspect that that comment is no longer relevant.  At least, I can't
seem to find the mask.  Perhaps somebody else knows.

Ian

asm goto vs simulate_block

[Richard Henderson]

The kernel folk here at Red Hat have given me a test case (which I'll be 
happy to forward, along a complete patch vs mainline) which gets 
miscompiled because we never get around to adding all of the appropriate 
blocks outgoing from an asm-goto to the simulation.


I can't figure out why the VARYING that we get in simulate_stmt and 
subsequent calls to add_control_edge are not enough to DTRT.  All I know 
is that the attached patch does in fact work around the problem, 
changing the .028t.ccp1 dump:


...
 Lattice value changed to VARYING.  Adding SSA edges to worklist.
+Adding Destination of edge (13 -> 14) to worklist
+
+
+Simulating block 14
...

Can someone give me a good explanation as to why this patch would be needed?


r~
diff --git a/gcc/tree-ssa-propagate.c b/gcc/tree-ssa-propagate.c
index a3a87cb..29d27aa 100644
--- a/gcc/tree-ssa-propagate.c
+++ b/gcc/tree-ssa-propagate.c
@@ -430,13 +430,14 @@ simulate_block (basic_block block)
   unsigned int normal_edge_count;
   edge e, normal_edge;
   edge_iterator ei;
+  gimple stmt = NULL;
 
   /* Note that we have simulated this block.  */
   SET_BIT (executable_blocks, block->index);
 
   for (j = gsi_start_bb (block); !gsi_end_p (j); gsi_next (&j))
{
- gimple stmt = gsi_stmt (j);
+ stmt = gsi_stmt (j);
 
  /* If this statement is already in the worklist then
 "cancel" it.  The reevaluation implied by the worklist
@@ -449,6 +450,17 @@ simulate_block (basic_block block)
  simulate_stmt (stmt);
}
 
+  /* ??? I can't figure out why this wouldn't have been taken care
+of in simulate_stmt, because the asm is considered VARYING.
+But it's also true that we'll never be able to predict which
+edge is going to be taken, so we might as well push them early.  */
+  if (stmt && gimple_code (stmt) == GIMPLE_ASM && stmt_ends_bb_p (stmt))
+   {
+ FOR_EACH_EDGE (e, ei, block->succs)
+   add_control_edge (e);
+ return;
+   }
+
   /* We can not predict when abnormal and EH edges will be executed, so
 once a block is considered executable, we consider any
 outgoing abnormal edges as executable.

Re: GCC Status Report (2009-08-23)

[George T . Talbot]

Mark Mitchell  codesourcery.com> writes:

> 
> 
> Status
> ==
> 
> The trunk is in Stage 1.  As previously stated, we expect that Stage 1
> will last through at least the end of August.
> 
> In my opinion, the single hardest issue we face with respect to 4.5 is
> how to handle the VTA branch.
>
> ...[deletia]...
>
> On the other hand, I can't see a viable better
> solution.  So, I'd be very interested in further comments on this
> topic.

As an end user...

I had to read up on VTA (I'm a user, not compiler developer).  If VTA works even
half as well as claimed on optimized code, and GDB supports the debug
information it emits, then this feature alone would make me switch relatively
instantly.

If there's one feature I've wanted out of the GDB/GCC combination over the last
ten years, this would be it.  I've banged my head against the wall many a time
trying to figure out a bug that occurs differently at -O[n>0] vs. -O0, and at
this time, GDB+GCC+O3 is often less than useful when debugging production code.

Just my $0.02.

--
George T. Talbot

Front-End errors again

[Philip Herron]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hey guys

I am having problems in building my front-end again, so i'll show you
the output.

lang_init_options...
argv[0] = ./host-i686-pc-linux-gnu/gcc/gpy1
argv[1] = -v
argv[2] = foo.lg
argv[3] = -Wall
lang_handle_option!
scode = 37
lang_post_options!
file foo.lg
lang_hooks.init()
lang_init!
done
init_asm_output (name);
init_eh()
Inside lang_dependent_init_target!
init_excess_precision
lang_print_error_function!
gpy1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Thats the output so far i've tracked the segfault to come from in
toplev.c

static void
lang_dependent_init_target (void)
{
  printf("Inside lang_dependent_init_target!\n");
  /* This determines excess precision settings.  */
  init_excess_precision ();
  printf("init_excess_precision\n");

  /* This creates various _DECL nodes, so needs to be called after the
 front end is initialized.  It also depends on the HAVE_xxx macros
 generated from the target machine description.  */
  init_optabs ();
  printf("init_optabs\n");

So it doesn't reach that last printf so it must be failing in
init_optabs, and i don't think i want to track this much further into
the gcc code so i am missing something in my front-end i just don't
know what yet. So from that comment i guess it must call something
like decl_* function from a front-end but i am not quite sure what
they are supposed to do, i mean i haven't even got a change to merge
in my own parser i made for a previous compiler to into this so i can
start working on the language proper.

Oh yeah i just want to say I really love how lang.opt works thats
really nice setup :)! Lang-specs.h is another file i am wondering i
added an entry into gcc.c the default compilers with the extension to
source files and also into a lang-spec.h but its very short:

  {".lg",   "@lang" , 0, 0, 0},

:) i am just calling this front-end lang i don't want to give the name
until i get a bit further into how the front-end works. But not sure
of what really should go in here other front-ends have very
complicated lang-specs.h and not quite sure whats it meant to
accomplish other than make the compiler aware of what the extension
should be.

The fortran one shows older fortran dialects turning on different
features on the fortran compiler i guess that another feature of it.

Anyways thanks again!

- --Phil
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqW/IIACgkQAhcOgIaQQ2GcFQCeLpnPoWFfGdid2mcnS+wAFVlk
tk8An2IBHOFooHaIJqQMD6E5C7ctlKiP
=/5Oy
-END PGP SIGNATURE-

gcc-4.5-20090827 is now available

[gccadmin]

Snapshot gcc-4.5-20090827 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20090827/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 151150

You'll find:

gcc-4.5-20090827.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.5-20090827.tar.bz2 C front end and core compiler

gcc-ada-4.5-20090827.tar.bz2  Ada front end and runtime

gcc-fortran-4.5-20090827.tar.bz2  Fortran front end and runtime

gcc-g++-4.5-20090827.tar.bz2  C++ front end and runtime

gcc-java-4.5-20090827.tar.bz2 Java front end and runtime

gcc-objc-4.5-20090827.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.5-20090827.tar.bz2The GCC testsuite

Diffs from 4.5-20090820 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.5
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: asm goto vs simulate_block

[Daniel Berlin]

My guess, witjout seeing the testcase.
In ccp_initialize we have:

  for (i = gsi_start_bb (bb); !gsi_end_p (i); gsi_next (&i))
{
  gimple stmt = gsi_stmt (i);
  bool is_varying = surely_varying_stmt_p (stmt);

  if (is_varying)
{
  tree def;
  ssa_op_iter iter;

  /* If the statement will not produce a constant, mark
 all its outputs VARYING.  */
  FOR_EACH_SSA_TREE_OPERAND (def, stmt, iter, SSA_OP_ALL_DEFS)
set_value_varying (def);
}
  prop_set_simulate_again (stmt, !is_varying);

This code looks clearly broken if the statement is control altering
(like your asm), since it will cause us to never simulate it and add
the outgoing edges (since the outgoing edges are only added in
simulate_stmt).

Without hacking through the abstraction (since it's ssa propagate that
adds the outgoing edges on simulation), the only thing i can see to do
would be to change the conditional to if (is_varying &&
!stmt_ends_bb_p (bb)) (or the equivalent) so that it simulates them.
Or add a way to tell the propagator about edges it should add
initially to the control worklist.




On Thu, Aug 27, 2009 at 1:23 PM, Richard Henderson wrote:
> The kernel folk here at Red Hat have given me a test case (which I'll be
> happy to forward, along a complete patch vs mainline) which gets miscompiled
> because we never get around to adding all of the appropriate blocks outgoing
> from an asm-goto to the simulation.
>
> I can't figure out why the VARYING that we get in simulate_stmt and
> subsequent calls to add_control_edge are not enough to DTRT.  All I know is
> that the attached patch does in fact work around the problem, changing the
> .028t.ccp1 dump:
>
> ...
>  Lattice value changed to VARYING.  Adding SSA edges to worklist.
> +Adding Destination of edge (13 -> 14) to worklist
> +
> +
> +Simulating block 14
> ...
>
> Can someone give me a good explanation as to why this patch would be needed?
>
>
> r~
>

Mirrors

[Yuriy Kolesnikov]

Please provide more information, like here
https://launchpad.net/ubuntu/+archivemirrors

Re: Trace crash in gargabe collector to the code at fault?

[Oliver Kellogg]

It turned out to be the following:

In multi source compile mode, I ggc_free() the data in dwarf2out.c after
code generation for a file is done. (I found that I need this because
otherwise the assembly code generated for file_2 to file_N of a compile
job will carry leftovers from the code generated for file_1.)

This includes freeing the comp_unit_die. However, struct tree_type
(tree.h) contains a union tree_type_symtab which has a member `die', and
this may point to the comp_unit_die.

gigi (ada/gcc-interface/trans.c) does not ggc_free the trees it
allocates, therefore these trees continue to be alive even when the
comp_unit_die was freed. So I guess I need to set TYPE_SYMTAB_DIE(t) to
NULL on all nodes before freeing comp_unit_die. To be verified now.

Thanks again Andrew.

Oliver


On Sat, 2009-08-15 at 20:00 +0100, Andrew Haley wrote:
> Oliver Kellogg wrote:
> > On Fri, 2009-08-14 at 10:41 +0100, Andrew Haley wrote:
> >>> I am stuck here, i.e. I don't know how to find the code
> >>> that is
> >>> at fault.
> >>> Is there some way to trace a pointer entered in
> >>> G.free_object_list
> >>> back to its origin in the code?
> >> The usual way to find this is to use a gdb watchpoint.  Find what object is
> >> being freed, put a breakpoing on ggc_alloc_stat at the point the object is
> >> created, and then put a watchpoint on the word that is being corrupted.
> >>
> >> Andrew.
> > 
> > Thanks.
> > I tried as follows:
> 
> That's not gonna work.
> 
> Put a breakpoint at the end of ggc_alloc_stat.  It'll have to be a
> conditional breakpoint on the address of the node that's being corrupted.
> 
> When the object is created, add the watchpoint.
> 
> Andrew.