Re: gcj/131

[Pekka Nikander <pekka dot nikander at hut dot fi>]

The following reply was made to PR gcj/131; it has been noted by GNATS.

From: Pekka Nikander <pekka.nikander@hut.fi>
To: java-gnats@sourceware.cygnus.com, apbianco@cygnus.com, gcb@gnu.org
Cc:  
Subject: Re: gcj/131
Date: Thu, 23 Mar 2000 13:14:48 +0200

 http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&pr=131&database=java
 
 I think this bug is related to a subtle code generator bug.
 If you define a static final field that doesn't use casts,
 the compiler generates a compile time constant.  However,
 if you add a cast to the definition, without any other
 changes, the compiler does not any more recognize the 
 initializer as a constant but produces code into <clinit>.
 
 Test code:
 
   package main;
   class dummy {
      static final byte b0 = 0;
      static final byte b1 = (byte)0;
   }
 
 Resulting assembler code (for Hitachi H8/300):
 
 	.section .text
 	.align 1
 	.global __003cclinit_003e__Q24main5dummyU
 __003cclinit_003e__Q24main5dummyU:
 	mov.w	#__CL_Q24main5dummy,r6
 	jsr	@_initClass__Q34java4lang5Class
 	sub.b	r0l,r0l
 	mov.b	r0l,@__Q24main5dummy$b1
 	rts
 	.global __Q24main5dummy$b0
 	.section .data
 __Q24main5dummy$b0:
 	.byte 0
 	.global __Q24main5dummy$b1
 	.section .bss
 __Q24main5dummy$b1:
 	.space 2
 
 The bug seems to be in parse.y around line 14300 (YMMV, I have a custom version)
 
   if (TREE_TYPE (node) != NULL_TREE && code != VAR_DECL && code != FIELD_DECL)
     return NULL_TREE;
 
 Integer constants etc are handled before; CONVERT_EXPR (which does have
 a TREE_TYPE defined) trips on this; e.g. PLUS_EXPR doesn't have a type
 defined, and it passes.
 
 Maybe this whole test is more or less bogus?
 
 --Pekka Nikander