public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: Some serious problem with GC again
  2004-09-12 15:54 Some serious problem with GC again Steven Bosscher
@ 2004-09-12 15:39 ` Steven Bosscher
  2004-09-12 15:55   ` Daniel Jacobowitz
  0 siblings, 1 reply; 6+ messages in thread
From: Steven Bosscher @ 2004-09-12 15:39 UTC (permalink / raw)
  To: gcc; +Cc: nathan

On Sunday 12 September 2004 16:38, Steven Bosscher wrote:
> <built-in>:0: internal compiler error: tree check: expected record_type or
> union_type or qual_union_type, have integer_type in fold_checksum_tree, at
> fold-const.c:9181

*hits himself for head*

This is of course a fold checking problem.  Hmm...  That
would be yours, Nathan.

Gr.
Steven


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Some serious problem with GC again
@ 2004-09-12 15:54 Steven Bosscher
  2004-09-12 15:39 ` Steven Bosscher
  0 siblings, 1 reply; 6+ messages in thread
From: Steven Bosscher @ 2004-09-12 15:54 UTC (permalink / raw)
  To: gcc

Hi,

I was trying to figure out why I'm seeing so many segfaults
for a bunch of packages I've tried to build with cvs HEAD.
Those segfaults appear to happen because of some GC problem,
so I decided to build a GCC with gcac checking enabled.

The result is disappointing, *nothing* compilers with a gcac
enabled compiler.  Here's what I get for every file I try to
compile (even empty files):

<built-in>:0: internal compiler error: tree check: expected record_type or union_type or qual_union_type, have integer_type in fold_checksum_tree, at fold-const.c:9181

You can probably get the same result with a non-gcac enabled
GCC with --param ggc-min-expand=0 --param ggc-min-heapsize=0.

I was having the segfaults on AMD64.  I cannot reproduce them
on i686.

Gr.
Steven


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Some serious problem with GC again
  2004-09-12 15:39 ` Steven Bosscher
@ 2004-09-12 15:55   ` Daniel Jacobowitz
  2004-09-12 16:20     ` Nathan Sidwell
  2004-09-13 20:40     ` Mark Mitchell
  0 siblings, 2 replies; 6+ messages in thread
From: Daniel Jacobowitz @ 2004-09-12 15:55 UTC (permalink / raw)
  To: Steven Bosscher, gcc-patches; +Cc: gcc, nathan

On Sun, Sep 12, 2004 at 04:39:46PM +0200, Steven Bosscher wrote:
> On Sunday 12 September 2004 16:38, Steven Bosscher wrote:
> > <built-in>:0: internal compiler error: tree check: expected record_type or
> > union_type or qual_union_type, have integer_type in fold_checksum_tree, at
> > fold-const.c:9181
> 
> *hits himself for head*
> 
> This is of course a fold checking problem.  Hmm...  That
> would be yours, Nathan.

It's not the only one.  I've been meaning to post this... OK?

-- 
Daniel Jacobowitz

2004-09-12  Daniel Jacobowitz  <dan@debian.org>

	* fold-const.c (fold_checksum_tree): Ignore TYPE_CACHED_VALUES.
	Only use TYPE_BINFO for aggregates.

Index: fold-const.c
===================================================================
RCS file: /home/drow/rsync/gcc-cvs/gcc/gcc/fold-const.c,v
retrieving revision 1.455
diff -u -p -r1.455 fold-const.c
--- fold-const.c	11 Sep 2004 19:48:53 -0000	1.455
+++ fold-const.c	12 Sep 2004 15:05:39 -0000
@@ -9094,13 +9094,16 @@ fold_checksum_tree (tree expr, struct md
       SET_DECL_ASSEMBLER_NAME (expr, NULL);
     }
   else if (TREE_CODE_CLASS (code) == 't'
-	   && (TYPE_POINTER_TO (expr) || TYPE_REFERENCE_TO (expr)))
+	   && (TYPE_POINTER_TO (expr) || TYPE_REFERENCE_TO (expr)
+	       || TYPE_CACHED_VALUES_P (expr)))
     {
-      /* Allow TYPE_POINTER_TO and TYPE_REFERENCE_TO to be modified.  */
+      /* Allow these fields to be modified.  */
       memcpy (buf, expr, tree_size (expr));
       expr = (tree) buf;
       TYPE_POINTER_TO (expr) = NULL;
       TYPE_REFERENCE_TO (expr) = NULL;
+      TYPE_CACHED_VALUES_P (expr) = 0;
+      TYPE_CACHED_VALUES (expr) = NULL;
     }
   md5_process_bytes (expr, tree_size (expr), ctx);
   fold_checksum_tree (TREE_TYPE (expr), ctx, ht);
@@ -9178,7 +9181,10 @@ fold_checksum_tree (tree expr, struct md
 	  fold_checksum_tree (TYPE_MAX_VALUE (expr), ctx, ht);
 	}
       fold_checksum_tree (TYPE_MAIN_VARIANT (expr), ctx, ht);
-      fold_checksum_tree (TYPE_BINFO (expr), ctx, ht);
+      if (TREE_CODE (expr) == RECORD_TYPE
+	  || TREE_CODE (expr) == UNION_TYPE
+	  || TREE_CODE (expr) == QUAL_UNION_TYPE)
+	fold_checksum_tree (TYPE_BINFO (expr), ctx, ht);
       fold_checksum_tree (TYPE_CONTEXT (expr), ctx, ht);
       break;
     default:

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Some serious problem with GC again
  2004-09-12 15:55   ` Daniel Jacobowitz
@ 2004-09-12 16:20     ` Nathan Sidwell
  2004-09-12 17:33       ` Graham Stott
  2004-09-13 20:40     ` Mark Mitchell
  1 sibling, 1 reply; 6+ messages in thread
From: Nathan Sidwell @ 2004-09-12 16:20 UTC (permalink / raw)
  To: Daniel Jacobowitz; +Cc: Steven Bosscher, gcc-patches, gcc, nathan

Daniel Jacobowitz wrote:
> On Sun, Sep 12, 2004 at 04:39:46PM +0200, Steven Bosscher wrote:
> 
>>On Sunday 12 September 2004 16:38, Steven Bosscher wrote:
>>
>>><built-in>:0: internal compiler error: tree check: expected record_type or
>>>union_type or qual_union_type, have integer_type in fold_checksum_tree, at
>>>fold-const.c:9181
>>
>>*hits himself for head*
>>
>>This is of course a fold checking problem.  Hmm...  That
>>would be yours, Nathan.
> 
> 
> It's not the only one.  I've been meaning to post this... OK?
looks right to me.  ... I thought I'd got the TYPE_BINFO thing before.
curious

btw, shouldn't
   char buf[sizeof (struct tree_decl)];
be
   char buf[sizeof (union tree_node)]
     __attribute__((alignment(alignof (union tree_node))));
?
(The alignment might be overly paranoid.)

nathan
-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Some serious problem with GC again
  2004-09-12 16:20     ` Nathan Sidwell
@ 2004-09-12 17:33       ` Graham Stott
  0 siblings, 0 replies; 6+ messages in thread
From: Graham Stott @ 2004-09-12 17:33 UTC (permalink / raw)
  To: Nathan Sidwell
  Cc: Daniel Jacobowitz, Steven Bosscher, gcc-patches, gcc, nathan

Nathan,

> btw, shouldn't
>   char buf[sizeof (struct tree_decl)];
> be
>   char buf[sizeof (union tree_node)]
>     __attribute__((alignment(alignof (union tree_node))));
> ?
> (The alignment might be overly paranoid.)
> 
> nathan

Why do we need a char buf[]?

What's wrong with using "union tree_node node" directly

Graham

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Some serious problem with GC again
  2004-09-12 15:55   ` Daniel Jacobowitz
  2004-09-12 16:20     ` Nathan Sidwell
@ 2004-09-13 20:40     ` Mark Mitchell
  1 sibling, 0 replies; 6+ messages in thread
From: Mark Mitchell @ 2004-09-13 20:40 UTC (permalink / raw)
  To: Daniel Jacobowitz; +Cc: Steven Bosscher, gcc-patches, gcc, nathan

Daniel Jacobowitz wrote:

>On Sun, Sep 12, 2004 at 04:39:46PM +0200, Steven Bosscher wrote:
>  
>
>>On Sunday 12 September 2004 16:38, Steven Bosscher wrote:
>>    
>>
>>><built-in>:0: internal compiler error: tree check: expected record_type or
>>>union_type or qual_union_type, have integer_type in fold_checksum_tree, at
>>>fold-const.c:9181
>>>      
>>>
>>*hits himself for head*
>>
>>This is of course a fold checking problem.  Hmm...  That
>>would be yours, Nathan.
>>    
>>
>
>It's not the only one.  I've been meaning to post this... OK?
>
>  
>
Yes.

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2004-09-13 20:17 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-09-12 15:54 Some serious problem with GC again Steven Bosscher
2004-09-12 15:39 ` Steven Bosscher
2004-09-12 15:55   ` Daniel Jacobowitz
2004-09-12 16:20     ` Nathan Sidwell
2004-09-12 17:33       ` Graham Stott
2004-09-13 20:40     ` Mark Mitchell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).