On Sat, Jul 14, 2012 at 1:41 PM, Steven Bosscher <stevenb....@gmail.com> wrote:
> On Sat, Jul 14, 2012 at 10:23 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
>> On Sat, Jul 14, 2012 at 11:54 AM, Steven Bosscher <stevenb....@gmail.com> 
>> wrote:
>>> On Sat, Jul 14, 2012 at 8:49 PM, H.J. Lu <hongjiu...@intel.com> wrote:
>>>> Hi,
>>>>
>>>> Revision 189453:
>>>>
>>>> http://gcc.gnu.org/ml/gcc-cvs/2012-07/msg00357.html
>>>>
>>>> removes type attribute comparison in gimple_types_compatible_p_1 and
>>>> caused PR middle-end/53959 and PR bootstrap/53963.  This restores type
>>>> attribute comparison.  Tested on Linux/x86-64.  OK to install?
>>>>
>>>> Thanks.
>>>>
>>>>
>>>> H.J.
>>>> ---
>>>> 2012-07-14  H.J. Lu  <hongjiu...@intel.com>
>>>>
>>>>         PR middle-end/53959
>>>>         PR bootstrap/53963
>>>>         * gimple.c (gimple_types_compatible_p_1): Restore type attribute
>>>>         comparison.
>>>
>>> I think this deserves a bit more understanding of the problem before
>>> reverting. Which type attributes survive up to this point?
>>>
>>
>> Here they are:
>>
>> (gdb) call debug_tree (t1)
>>  <function_type 0x7ffff1affbd0
>>     type <void_type 0x7ffff19babd0 void VOID
>>         align 8 symtab 0 alias set -1 canonical type 0x7ffff19babd0
>>         pointer_to_this <pointer_type 0x7ffff19bac78>>
>>     QI
>>     size <integer_cst 0x7ffff19a9ea0 type <integer_type 0x7ffff19ba0a8
>> bitsizetype> constant 8>
>>     unit size <integer_cst 0x7ffff19a9ec0 type <integer_type
>> 0x7ffff19ba000 sizetype> constant 1>
>>     align 8 symtab 0 alias set -1 canonical type 0x7ffff1affbd0
>>     attributes <tree_list 0x7ffff1b00a00
>>         purpose <identifier_node 0x7ffff19dfd98 fn spec>
>>         value <tree_list 0x7ffff1b00a28
>>             value <string_cst 0x7ffff1b01138 constant ".wR">>>
>>     arg-types <tree_list 0x7ffff1b00a50
>>         value <pointer_type 0x7ffff1aff738 type <record_type
>> 0x7ffff1aff7e0 __st_parameter_dt>
>>             unsigned DI
>>             size <integer_cst 0x7ffff19a9d20 constant 64>
>>             unit size <integer_cst 0x7ffff19a9d40 constant 8>
>>             align 64 symtab 0 alias set -1 canonical type 0x7ffff1aff738>
>>         chain <tree_list 0x7ffff1b00a78 value <pointer_type 0x7ffff19bac78>
>>             chain <tree_list 0x7ffff1b00aa0 value <integer_type
>> 0x7ffff19ba5e8 int>
>>                 chain <tree_list 0x7ffff19b4708 value <void_type
>> 0x7ffff19babd0 void>>>>>>
>> (gdb) call debug_tree (t2)
>>  <function_type 0x7ffff1b052a0
>>     type <void_type 0x7ffff19babd0 void VOID
>>         align 8 symtab 0 alias set -1 canonical type 0x7ffff19babd0
>>         pointer_to_this <pointer_type 0x7ffff19bac78>>
>>     QI
>>     size <integer_cst 0x7ffff19a9ea0 type <integer_type 0x7ffff19ba0a8
>> bitsizetype> constant 8>
>>     unit size <integer_cst 0x7ffff19a9ec0 type <integer_type
>> 0x7ffff19ba000 sizetype> constant 1>
>>     align 8 symtab 0 alias set -1 structural equality
>>     attributes <tree_list 0x7ffff1b06258
>>         purpose <identifier_node 0x7ffff19dfd98 fn spec>
>>         value <tree_list 0x7ffff1b06280
>>             value <string_cst 0x7ffff1b01288 constant ".wW">>>
>>     arg-types <tree_list 0x7ffff1b00a50
>>         value <pointer_type 0x7ffff1aff738 type <record_type
>> 0x7ffff1aff7e0 __st_parameter_dt>
>>             unsigned DI
>>             size <integer_cst 0x7ffff19a9d20 constant 64>
>>             unit size <integer_cst 0x7ffff19a9d40 constant 8>
>>             align 64 symtab 0 alias set -1 canonical type 0x7ffff1aff738>
>>         chain <tree_list 0x7ffff1b00a78 value <pointer_type 0x7ffff19bac78>
>>             chain <tree_list 0x7ffff1b00aa0 value <integer_type
>> 0x7ffff19ba5e8 int>
>>                 chain <tree_list 0x7ffff19b4708 value <void_type
>> 0x7ffff19babd0 void>>>>>>
>> (gdb)
>>
>
> You only have different ATTR_FNSPEC attributes. I don't know whether
> that should result in the types being incompatible, but I don't think
> so.
>
> How does this lead to failure? Is one of the types chosen as
> prevailing so that one of the functions ends up with the wrong
> ATTR_FNSPEC?
>

I don't believe .wR attribute is compatible with .wW attribute:

[hjl@gnu-32 fortran]$ grep "wR" *
trans-decl.c:   get_identifier (PREFIX("internal_unpack")), ".wR",
trans-io.c:     get_identifier (PREFIX("transfer_integer_write")), ".wR",
trans-io.c:     get_identifier (PREFIX("transfer_logical_write")), ".wR",
trans-io.c:     get_identifier (PREFIX("transfer_character_write")), ".wR",
trans-io.c:     get_identifier (PREFIX("transfer_character_wide_write")), ".wR",
trans-io.c:     get_identifier (PREFIX("transfer_real_write")), ".wR",
trans-io.c:     get_identifier (PREFIX("transfer_complex_write")), ".wR",
trans-io.c:     get_identifier (PREFIX("transfer_real128_write")), ".wR",
trans-io.c:     get_identifier (PREFIX("transfer_complex128_write")), ".wR",
[hjl@gnu-32 fortran]$ grep "wW" *
trans-io.c:     get_identifier (PREFIX("transfer_integer")), ".wW",
trans-io.c:     get_identifier (PREFIX("transfer_logical")), ".wW",
trans-io.c:     get_identifier (PREFIX("transfer_character")), ".wW",
trans-io.c:     get_identifier (PREFIX("transfer_character_wide")), ".wW",
trans-io.c:     get_identifier (PREFIX("transfer_real")), ".wW",
trans-io.c:     get_identifier (PREFIX("transfer_complex")), ".wW",
trans-io.c:     get_identifier (PREFIX("transfer_real128")), ".wW",
trans-io.c:     get_identifier (PREFIX("transfer_complex128")), ".wW",
[hjl@gnu-32 fortran]$


-- 
H.J.

Reply via email to