On 4/2/21 9:40 AM, Jan Hubicka wrote:
This breaks bootstrap on riscv64:In function ‘alloca_type_and_limit alloca_call_type(range_query&, gimple*, bool ’, inlined from ‘virtual unsigned int pass_walloca::execute(function*)’ at ../../gcc/gimple-ssa-warn-alloca.c:295:25: ../../gcc/gimple-ssa-warn-alloca.c:206:13: error: ‘*(long int*)((char*)&ret + offsetof(alloca_type_and_limit, alloca_type_and_limit::limit.generic_wide_int<wide_int_storage>::<unnamed>.wide_int_storage::val[0]))’ may be used uninitialized -Werror=maybe-uninitialized] 206 | ret = alloca_type_and_limit (ALLOCA_OK); | ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../../gcc/gimple-ssa-warn-alloca.c: In member function ‘virtual unsigned int pass_walloca::execute(function*)’: ../../gcc/gimple-ssa-warn-alloca.c:200:32: note: ‘ret’ declared here 200 | struct alloca_type_and_limit ret = alloca_type_and_limit (ALLOCA_OK); | ^~~This looks like a false positive implied by different inlining decisions. Would it be posible to have preprocessed source + the tripplet to configure a cross-compiler?
Just eyeballing the code, the warning complains about a call to the (implicitly generated) assignment operator of class alloca_type_and_limit with an object constructed by a ctor that doesn't explicitly initialize the limit member when its argument is ALLOCA_OK. The limit member is a wide_int so unless its default zeroes out the internal array (I had to debug nasty problems in the past because I'd assumed it did), the assignment might indeed end up copying uninitialized data. So based on this I wouldn't rule out the possibility it's a true positive. One way to confirm this hypothesis might be to explicitly initialize the limit member in the ctor even the argument is ALLOCA_OK and see if the warning goes away. Martin
Thanks, Honza
