[Bug middle-end/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327

["ubizjak at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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

UroÅ Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |middle-end

--- Comment #13 from UroÅ Bizjak <ubizjak at gmail dot com> ---
(In reply to H.J. Lu from comment #12)
> Created attachment 34361 [details]
> A new patch
> 
> Please try the new patch.

No, this approach is wrong. ix86_fixup_binary_operands should not be used to
legitimize PIC address. The -fpic expansion is already wrong, since it
produces:

;; ivtmp.9_4 = (unsigned long) _37;

(insn 59 58 0 (parallel [
            (set (reg:DI 123 [ ivtmp.9 ])
                (plus:DI (reg:DI 124 [ D.3980 ])
                    (symbol_ref:DI ("G")  <var_decl 0x7f8c6facc900 G>)))
            (clobber (reg:CC 17 flags))
        ]) -1
     (nil))

This is similar to:

--cut here--
typedef __SIZE_TYPE__ size_t;

extern char G[8];

char *a (size_t z)
{
  return &G[z];
}
--cut here--

Without -fpic, the compiler expands to:

    6: {r90:DI=r89:DI+`G';clobber flags:CC;}

Compare this with -fpic expansion:

    6: r92:DI=[const(unspec[`G'] 2)]
    7: r91:DI=r92:DI
      REG_EQUAL `G'
    8: {r90:DI=r89:DI+r91:DI;clobber flags:CC;}

Looking at the above, it looks the problem is in the middle-end, where symbol
address should be legitimized through ix86_legitimize_address (a.k.a
TARGET_LEGITIMIZE_ADDRESS).