This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug lto/68560] [6 Regression] The test gfortran.dg/shape_8.f90 now fails when compiled with -flto


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68560

--- Comment #1 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
The reason here is that the types differ in number of parameters:

(gdb) p debug_tree (type)
 <function_type 0x7ffff6cc3690
    type <void_type 0x7ffff6af0150 void VOID
        align 8 symtab 0 alias set -1 structural equality
        pointer_to_this <pointer_type 0x7ffff6af02a0>>
    QI
    size <integer_cst 0x7ffff6ad7ca8 type <integer_type 0x7ffff6adb2a0
bitsizetype> constant 8>
    unit size <integer_cst 0x7ffff6ad7cc0 type <integer_type 0x7ffff6adb1f8
sizetype> constant 1>
    align 8 symtab 0 alias set -1 structural equality
    attributes <tree_list 0x7ffff6cc2438
        purpose <identifier_node 0x7ffff6b09a78 fn spec>
        value <tree_list 0x7ffff6cc2410
            value <string_cst 0x7ffff6cabe88 constant ".wr">>>
    arg-types <tree_list 0x7ffff6cc23e8
        value <reference_type 0x7ffff6cc3000 type <record_type 0x7ffff6cbff18
array1_integer(kind=4)>
            unsigned DI
            size <integer_cst 0x7ffff6ad7bb8 constant 64>
            unit size <integer_cst 0x7ffff6ad7bd0 constant 8>
            align 64 symtab 0 alias set -1 structural equality>
        chain <tree_list 0x7ffff6cc23c0 value <reference_type 0x7ffff6cbf888>
            chain <tree_list 0x7ffff6ae99b0 value <void_type 0x7ffff6af0150
void>>>>
    pointer_to_this <pointer_type 0x7ffff6cc5930>>
$6 = void
(gdb) p debug_tree (prevailing_type)
 <function_type 0x7ffff6cc30a8
    type <void_type 0x7ffff6af0150 void VOID
        align 8 symtab 0 alias set -1 structural equality
        pointer_to_this <pointer_type 0x7ffff6af02a0>>
    QI
    size <integer_cst 0x7ffff6ad7ca8 type <integer_type 0x7ffff6adb2a0
bitsizetype> constant 8>
    unit size <integer_cst 0x7ffff6ad7cc0 type <integer_type 0x7ffff6adb1f8
sizetype> constant 1>
    align 8 symtab 0 alias set -1 structural equality
    attributes <tree_list 0x7ffff6cc2050
        purpose <identifier_node 0x7ffff6b09a78 fn spec>
        value <tree_list 0x7ffff6cc2028
            value <string_cst 0x7ffff6cb72e0 constant ".wrr">>>
    arg-types <tree_list 0x7ffff6cc2118
        value <reference_type 0x7ffff6cc3000 type <record_type 0x7ffff6cbff18
array1_integer(kind=4)>
            unsigned DI
            size <integer_cst 0x7ffff6ad7bb8 constant 64>
            unit size <integer_cst 0x7ffff6ad7bd0 constant 8>
            align 64 symtab 0 alias set -1 structural equality>
        chain <tree_list 0x7ffff6cbce88 value <reference_type 0x7ffff6cbf888>
            chain <tree_list 0x7ffff6cbce60 value <pointer_type 0x7ffff6af0930>
                chain <tree_list 0x7ffff6ae99b0 value <void_type 0x7ffff6af0150
void>>>>>
    pointer_to_this <pointer_type 0x7ffff6cc5498>>

I do not think it is valid to call function with different number of
parameters.  We don't really do pascal type calling conventions on any of
recent targets, but it would break there.

This is the library function, can't gfortran always declare it the same way?
Again producing duplicated decls is technically a bug (though I am going to
make it supported).

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]