https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61154
Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |ramana at gcc dot
gnu.org
--- Comment #5 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
(In reply to rsand...@gcc.gnu.org from comment #3)
> This code is doing an OImode ASHIFT and fails the check:
>
> #if TARGET_SUPPORTS_WIDE_INT == 0
> /* This assert keeps the simplification from producing a result
> that cannot be represented in a CONST_DOUBLE but a lot of
> upstream callers expect that this function never fails to
> simplify something and so you if you added this to the test
> above the code would die later anyway. If this assert
> happens, you just need to make the port support wide int. */
> gcc_assert (width <= HOST_BITS_PER_DOUBLE_INT);
> #endif
>
> since without CONST_WIDE_INT we won't be able to represent all
> results correctly.
>
> Unfortunately porting to CONST_WIDE_INT is something that needs
> knowledge of the target-specific code, but it shouldn't be much work.
> It's just a case of auditing each use of const_double in config/arm
> to see whether it is handling integer const_doubles or floating-point
> const_doubles. Since ARM is a 32-bit target and since HWI and CONST_INT
> are 64 bits, I assume most places really are handling floating-point values.
> (A grep makes that obvious for some things, but arm_immediate_di_operand
> does accept const_double. I'm not sure whether that's just a left-over
> from pre need_64bit_hwint days though.)
>
I suppose mine.
In addition to auditing for the use of const_doubles, I think one thing that
needs to be mentioned explicitly is trying to find use of const_double_operand
as well. One of the splitters in the backend which split DImode immediate moves
was actually explicitly trying to only look for const_double_operand and it
appears that this just worked (TM) prior to a trial switch to
TARGET_SUPPORTS_WIDE_INT. I'm still trying to test through the rest of that.
I note that SPARC has a similar define_split so it might also be affected by
such a switch over.
I still have an unfinished patch stack on top of that which will attempt to fix
other cases in the backend where we could be replacing uses of GEN_INT with
gen_int_mode. Is there any rule of thumb for such a conversion ?
regards
Ramana
> Adding:
>
> #define TARGET_SUPPORTS_WIDE_INT 1
>
> does fix the ICE but it'd be good audit the use of const_doubles too.
