On Mon, May 5, 2014 at 12:54 PM, Richard Sandiford
<[email protected]> wrote:
> Richard Biener <[email protected]> writes:
>> On Fri, May 2, 2014 at 9:19 PM, Richard Sandiford
>> <[email protected]> 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
