Re: [wide-int] Handle zero-precision INTEGER_CSTs again

[Richard Biener <richard dot guenther at gmail dot com>]

On Mon, May 5, 2014 at 12:54 PM, Richard Sandiford
<rdsandiford@googlemail.com> wrote:
> Richard Biener <richard.guenther@gmail.com> writes:
>> On Fri, May 2, 2014 at 9:19 PM, Richard Sandiford
>> <rdsandiford@googlemail.com> wrote:
>>> I'd hoped the days of zero-precision INTEGER_CSTs were behind us after
>>> Richard's patch to remove min amd max values from zero-width bitfields,
>>> but a boostrap-ubsan showed otherwise.  One source is in:
>>>
>>>   null_pointer_node = build_int_cst (build_pointer_type (void_type_node), 0);
>>>
>>> if no_target, since the precision of the type comes from ptr_mode,
>>> which remains the default VOIDmode.  Maybe that's a bug, but setting
>>> it to an arbitrary nonzero value would also be dangerous.
>>
>> Can you explain what 'no_target' should be?  ptr_mode should never be
>> VOIDmode.
>
> Sorry, meant "no_backend" rather than "no_target".  See do_compile.

Ok.  So we do

      /* This must be run always, because it is needed to compute the FP
         predefined macros, such as __LDBL_MAX__, for targets using non
         default FP formats.  */
      init_adjust_machine_modes ();

      /* Set up the back-end if requested.  */
      if (!no_backend)
        backend_init ();

where I think that init_adjust_machine_modes should initialize the
{byte,word,ptr}_mode globals.  Move from init_emit_once.

But why do we even run into uses of null_pointer_node for no_backend?
For sure for -fsyntax-only we can't really omit backend init as IMHO
no parser piece is decoupled enough to never call target hooks or so.

Thus, omit less of the initialization for no_backend.

>> So I don't think we want this patch.  Instead stor-layout should
>> ICE on zero-precision integer/pointer types.
>
> What should happen for void_zero_node?

Not sure what that beast is supposed to be or why it should be
of INTEGER_CST kind (it's not even initialized in any meaningful
way).

That said, the wide-int code shouldn't be slowed down by
precision == 0 checks.  We should never ever reach wide-int
with such a constant.

Richard.

> Thanks,
> Richard