Re: [PATCH] Enable type verification throughout the compiler.

[Dave Korn <dave dot korn dot cygwin at googlemail dot com>]

Richard Guenther wrote:
> On Tue, 28 Apr 2009, Dave Korn wrote:
> 
>> H.J. Lu wrote:
>>> On Mon, Apr 27, 2009 at 10:24 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>> On Mon, Apr 27, 2009 at 4:15 AM, Richard Guenther <rguenther@suse.de> wrote:
>>>>> Tromey agreed to my Java fix on IRC after some discussion, Diego acked
>>>>> the patch in principle.
>>>>>
>>>>> Thus, re-bootstrapped and tested on x86_64-unknown-linux-gnu with all
>>>>> languages and -m32/-m64 testing, installed to trunk.
>>>>>
>>>>> Richard.
>>>>>
>>>>> 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.
>>>>>
>>>> This patch caused:
>>>>
>>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39932
>>>>
>>> This also caused:
>>>
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39937
>>>
>>   And a java bootstrap failure for the same reason ("type mismatch").  I
>> posted the details on the tail of the original bug:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38374
>>
>> and I think it's almost certainly the same problem underlying.  Verified that
>> reverting r146831 locally fixed it.
> 
> Same underlying problem as in "wrong-code" in the intermediate language.
> 
> r146831 simply uncovered all these cases by verifying internal
> consistency of GIMPLE at more places.

  Ok, the java FE is emitting invalid GIMPLE during the libjava build.  Argh.
 I'm not in a great position to investigate this immediately because I'm
struggling with a couple of years' bit-rot in the win32 ports as it is.  Once
I can get it up and running reasonably well with the patch reverted, I'll come
back to this and get some tree dumps and file a PR with more info, if it's not
already resolved by then.

    cheers,
      DaveK