https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281
--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 13 Sep 2021, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281 > > --- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > __builtin_clear_padding when folded emits a series of memory stores rather > than > BIT_INSERT_EXPR etc., so that wouldn't work. > But, IMNSHO, -ftrivial-auto-var-init* shouldn't be adding > __builtin_clear_padding calls at all for objects of types that can't have any > padding. > Currently one can do e.g. what my > r12-3455-g8122fbff770bcff183a9c3c72e8092c0ca32150b does for OpenMP atomics, > + bool clear_padding = false; > > + if (BITS_PER_UNIT == 8 && CHAR_BIT == 8) > > + { > > + HOST_WIDE_INT sz = int_size_in_bytes (cmptype), i; > > + gcc_assert (sz > 0); > > + unsigned char *buf = XALLOCAVEC (unsigned char, sz); > > + memset (buf, ~0, sz); > > + clear_type_padding_in_mask (cmptype, buf); > > + for (i = 0; i < sz; i++) > > + if (buf[i] != (unsigned char) ~0) > > + { > > + clear_padding = true; > > + break; > > + } > > + } > > so that when nothing needs to be padded (the usual case for non-struct/union > types unless they have extended long double), the builtin isn't added at all. > I doubt we support vectors of long double, so it is mainly whether returning > of > long double or _Complex long double works fine. for this specific issue it might be enough to not bother initializing padding of is_gimple_reg_type types, I doubt we have any of those that have padding (and if we'd have then the issue would re-surface)
