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

[Richard Sandiford <rdsandiford at googlemail dot com>]

Richard Biener <richard.guenther@gmail.com> writes:
> 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.

OK, but I don't think the wide-int merge should be held up for clean-ups
like that.  At the moment the tree & gimple leve do use 0 precision, and
although I think we both agree it'd be better if they didn't, let's do
one thing at a time.

>>> 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.

void_zero_node is used for ubsan too, and survives into gimple.
I did hit this in real tests, it wasn't just theoretical.

Thanks,
Richard