https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281
--- Comment #10 from Qing Zhao <qing.zhao at oracle dot com> --- > On Oct 11, 2021, at 3:29 PM, jakub at gcc dot gnu.org > <gcc-bugzi...@gcc.gnu.org> wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281 > > --- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > (In reply to qinzhao from comment #7) >> I agree that the above additional check is necessary. >> >> one question here is, can I use the routine "bool >> clear_padding_type_may_have_padding_p (tree type)" in gimple-fold.c instead >> of the above new function for this purpose? > > Sure, you can, but just note that it is conservative and fast, it will return > true even for types that don't have any padding. > But for double, _Complex double, int etc. it will quickly return false. > I guess I should use it in c-omp.c too. Yes, the routine “clear_padding_type_may_have_padding_p” is quicker when returning FALSE. When it return TRUE, might not be very accurate, at this time, we can further call the new routine to make it accurate. Another question here, what’s the purpose for the routine “clear_type_padding_in_mask”? > But also note that it will return true for x86 long double/_Complex long > double, > and if you have a variable that isn't addressable, you need to figure out what > to do. Yes, we should resolve this issue too. > I think it might be easiest not to clear anything, Do you mean not to call clear padding for any variable here? Or only for variables with type long double/_Complex long double? > another option is to > create a temporary, store the var value in there, clear padding and copy back, > but in the end the padding bits will probably not stay cleared. Why not? > After all, e.g. on x86-64 -m64 the return value will be either in %st or > %st/%st(1) pair and the padding isn't present there You mean for variables with type long double/_Complex long doubles, if they are in register (Not-addressable), they don’t have Padding, so, don’t need to clear padding at all? (But this is only true for x86-64) > (but e.g. for ia32 _Complex > long double is returned through invisible reference and padding is there, If they are returned through invisible reference, does this mean they are addressable? > but > you'd need to perform clear padding like operation during expansion). > > -- > You are receiving this mail because: > You are on the CC list for the bug.