Richard Biener <richard.guent...@gmail.com> writes:
> On Mon, May 5, 2014 at 12:54 PM, Richard Sandiford
> <rdsandif...@googlemail.com> wrote:
>> Richard Biener <richard.guent...@gmail.com> writes:
>>> On Fri, May 2, 2014 at 9:19 PM, Richard Sandiford
>>> <rdsandif...@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
