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