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 target/84226] [8 Regression] ICE in simplify_const_unary_operation, at simplify-rtx.c:1974 on ppc64le


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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2018-02-08
                 CC|                            |dje at gcc dot gnu.org,
                   |                            |jakub at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Seems the rs6000 backend violates BSWAP requirements:
@item (bswap:@var{m} @var{x})
Represents the value @var{x} with the order of bytes reversed, carried out
in mode @var{m}, which must be a fixed-point machine mode.
The mode of @var{x} must be @var{m} or @code{VOIDmode}.

V2DFmode or V4SFmode are not integral modes.

So, I'd say that instead of using these p9_xxbrd_v2df and p9_xxbrw_v4sf
patterns the backend instead should subreg the operand to v2di or v4si, do
p9_xxbrd_v2di or p9_xxbrw_v4si and finally subreg the result to v2df/v4sf.

Or the documentation needs to be changed and simplify_const_unary_operation
extended to handle that case (possibly by handling it using simplifying const
subreg to corresponding integral mode, doing bswap on the integral mode and
then subreg back.

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