[Bug go/52349] [4.7 Regression] go doesn't bootstrap

["rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52349

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-02-23
   Target Milestone|---                         |4.7.0
     Ever Confirmed|0                           |1

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-02-23 10:07:44 UTC ---
(In reply to comment #0)
> The http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184436 broke go bootstrap.
> Simple testcase, even for -O0: ./go1 ice.go
> package ice
> type Ice interface { }
> type M struct { f func(Ice) Ice }
> func (m *M) foo(c Ice) Ice { return m.f(c) }
> 
> (distilled from color.go).
> In create_tmp_from_val we have:
> (gdb) p debug_tree (val->typed.type)
>  <pointer_type 0x7ffff13b2d20
>     type <function_type 0x7ffff13beb28
>         type <record_type 0x7ffff13b2bd0 Ice sizes-gimplified BLK
>             size <integer_cst 0x7ffff1392400 constant 128>
>             unit size <integer_cst 0x7ffff1392420 constant 16>
>             align 64 symtab 0 alias set -1 canonical type 0x7ffff13b2b28 fields
> <field_decl 0x7ffff13a35f0 __type_descriptor>
>             pointer_to_this <pointer_type 0x7ffff13be348>>
>         QI
>         size <integer_cst 0x7ffff1392080 constant 8>
>         unit size <integer_cst 0x7ffff13920a0 constant 1>
>         align 8 symtab 0 alias set -1 canonical type 0x7ffff13bebd0
>         arg-types <tree_list 0x7ffff13b6f50 value <record_type 0x7ffff13b2bd0
> Ice>
>             chain <tree_list 0x7ffff13896b8 value <void_type 0x7ffff138fbd0>>>
>         pointer_to_this <pointer_type 0x7ffff13bec78>>
>     sizes-gimplified unsigned DI
>     size <integer_cst 0x7ffff137eec0 type <integer_type 0x7ffff138f0a8
> bitsizetype> constant 64>
>     unit size <integer_cst 0x7ffff137eee0 type <integer_type 0x7ffff138f000
> sizetype> constant 8>
>     align 64 symtab 0 alias set -1 canonical type 0x7ffff138fc78>
> $7 = void
> (gdb) p debug_tree (val->typed.type->type_common.main_variant)
>  <pointer_type 0x7ffff138fc78
>     type <void_type 0x7ffff138fbd0 VOID
>         align 8 symtab 0 alias set -1 canonical type 0x7ffff138fbd0
>         pointer_to_this <pointer_type 0x7ffff138fc78>>
>     sizes-gimplified public unsigned DI
>     size <integer_cst 0x7ffff137eec0 type <integer_type 0x7ffff138f0a8
> bitsizetype> constant 64>
>     unit size <integer_cst 0x7ffff137eee0 type <integer_type 0x7ffff138f000
> sizetype> constant 8>
>     align 64 symtab 0 alias set -1 canonical type 0x7ffff138fc78
>     pointer_to_this <pointer_type 0x7ffff13c3690>>
> $8 = void
> 
> so it is obvious that it ICEs soon afterwards, the question is if this is a
> latent FE bug that pointers to functions shouldn't have void * as its
> TYPE_MAIN_VARIANT, but rather pointer to the same function type, just without
> volatile/const/restrict on the POINTER_TYPE, or if the above change wasn't
> correct.  Richard, Ian?

Surely TYPE_MAIN_VARIANT has to be compatible with the type, void *
as TYPE_MAIN_VARIANT of anything not being a qualified void * is bogus.
Not sure how you got away with this - maybe it's only exposed for
function pointer types?  A canonical main-variant is
build_qualified_type (type, 0).