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]

Bogus rtx generated?



I'm tracking down a bug which causes gcc to crash; it looks like reload is
crashing when trying to generate reloads for the following rtx:

(insn 349 33 350 (parallel[
            (set (subreg:SI (reg/v:DI 46) 0)
                (ashift:SI (subreg:SI (reg/v:DI 44) 0)
                    (const_int 1)))
            (set (reg:SI 18 t)
                (lt:SI (subreg:SI (reg/v:DI 44) 0)
                    (const_int 0)))
        ] ) -1 (nil)
    (nil))

Is this a reasonable rtx? I don't understand why you would have a parallel
shift with a compare, so this seems rather fishy to me.

It looks like the previous rtx is generated by the first scheduling pass;
here's the rtx before scheduling:

(insn 35 33 36 (parallel[
            (set (subreg:SI (reg/v:DI 46) 0)
                (ashiftrt:SI (subreg:SI (reg/v:DI 44) 0)
                    (const_int 31)))
            (clobber (reg:SI 18 t))
        ] ) 68 {ashrsi2_31} (nil)
    (expr_list:REG_UNUSED (reg:SI 18 t)
        (nil)))

but after try_split() is called, the first rtx is generated...

Toshi



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