This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]