Bug 38374 - constant pool references have wrong types in ADDR_EXPR
Summary: constant pool references have wrong types in ADDR_EXPR
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: java (show other bugs)
Version: 4.4.0
: P3 normal
Target Milestone: 4.5.0
Assignee: Richard Biener
URL: http://gcc.gnu.org/ml/gcc-patches/200...
Keywords:
Depends on:
Blocks:
 
Reported: 2008-12-02 15:55 UTC by Richard Biener
Modified: 2009-04-28 03:30 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2009-04-15 12:17:01


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Biener 2008-12-02 15:55:23 UTC
The Java FE builds the final constant pool variable late (_CD_java_lang_Object)
and only then fills in the arrays domain.  All references to it before have
an empty TYPE_DOMAIN which means after filling in the final TYPE_DOMAIN all
the ADDR_EXPRs have wrong types.
Comment 1 Richard Biener 2009-04-15 12:17:01 UTC
I have a "fix".
Comment 2 Richard Biener 2009-04-27 11:18:49 UTC
Fixed.
Comment 3 Richard Biener 2009-04-27 11:19:08 UTC
Subject: Bug 38374

Author: rguenth
Date: Mon Apr 27 11:18:38 2009
New Revision: 146831

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146831
Log:
2009-04-27  Richard Guenther  <rguenther@suse.de>

	* tree-cfg.c (remove_useless_stmts): Verify stmts afterwards.
	(verify_stmts): Dispatch to gimple/type verification code.
	* tree-inline.c (remap_gimple_op_r): Work around C++ FE
	issue with call argument types.

	java/
	PR java/38374
	* constants.c (build_constants_constructor): Retain the old
	pointer type as valid TYPE_POINTER_TO after patching the
	type of the constant pool decl.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/java/ChangeLog
    trunk/gcc/java/constants.c
    trunk/gcc/tree-cfg.c
    trunk/gcc/tree-inline.c

Comment 4 Dave Korn 2009-04-27 21:39:29 UTC
  I just got this failure during bootstrap:


libtool: compile:  /gnu/gcc/obj3/gcc/gcj -B/gnu/gcc/obj3/i686-pc-cygwin/libjava/ -B/gnu/gcc/obj3/gcc/ -ffloat-store -fomit-frame-pointer -Usun -fclasspath= -fbootclasspath=/gnu/gcc/gcc/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -fsource-filename=/gnu/gcc/obj3/i686-pc-cygwin/libjava/classpath/lib/classes -fjni -findirect-dispatch -fno-indirect-classes -c @gnu-CORBA.list  -o .libs/gnu-CORBA.o
/gnu/gcc/gcc/libjava/classpath/gnu/CORBA/Poa/gnuPOA.java: In class 'gnu.CORBA.Poa.gnuPOA$RefTemplate':
/gnu/gcc/gcc/libjava/classpath/gnu/CORBA/Poa/gnuPOA.java: In constructor '(gnu.CORBA.Poa.gnuPOA)':
In file included from <built-in>:136:
/gnu/gcc/gcc/libjava/classpath/gnu/CORBA/Poa/gnuPOA.java:0: error: type mismatch in indirect reference
struct java.lang.String[]

void

# VUSE <.MEM_11>
#slot#8#31_225 = #ref#5#2_135->length;

/gnu/gcc/gcc/libjava/classpath/gnu/CORBA/Poa/gnuPOA.java:0: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[3]: *** [gnu-CORBA.lo] Error 1

  I'm going to try reverting r146831 locally and see if it helps.
Comment 5 Dave Korn 2009-04-28 03:30:00 UTC
(In reply to comment #4)
>   I just got this failure during bootstrap:

>   I'm going to try reverting r146831 locally and see if it helps.

  Doing so allowed the build to complete.  See also bug 39932.

 

Comment 6 rguenther@suse.de 2009-04-28 08:19:31 UTC
Subject: Re:  constant pool references have wrong types in
 ADDR_EXPR

On Tue, 28 Apr 2009, dave dot korn dot cygwin at gmail dot com wrote:

> ------- Comment #5 from dave dot korn dot cygwin at gmail dot com  2009-04-28 03:30 -------
> (In reply to comment #4)
> >   I just got this failure during bootstrap:
> 
> >   I'm going to try reverting r146831 locally and see if it helps.
> 
>   Doing so allowed the build to complete.  See also bug 39932.

Please open a new bugreport for this Java frontend problem.

Richard.