On Mon, May 5, 2014 at 4:51 PM, Richard Sandiford
<rdsandif...@googlemail.com> wrote:
> 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.
Fair enough.
>>>> 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.
Ugh - for what does it use that ... :/
Please remember how to trigger those issues and I'll happily have
a look after the merge.
Thanks,
Richard.
> Thanks,
> Richard
