On Fri, 21 Oct 2022, Andre Vieira (lists) wrote: > Hi, > > The ada failure reported in the PR was being caused by > vect_check_gather_scatter failing to deal with bit offsets that weren't > multiples of BITS_PER_UNIT. This patch makes vect_check_gather_scatter reject > memory accesses with such offsets. > > Bootstrapped and regression tested on aarch64 and x86_64. > > I wasn't sure whether I should add a new Ada test that shows the same failure > without the bitfield lowering, I suspect this is such a rare form of > data-structure that is why no other tests have highlighted the failure. Let me > know if you would like me to add it still, the change is quite simple, just > change the Int24 -> Int32 type in the structure. The 'thing' that causes the > failure is the 4-bit member inside the packed structure before the field we > access, giving it a 4-bit offset. I attempted but failed to create a C test > using __attribute__((packed)).
Can you check why vect_find_stmt_data_reference doesn't trip on the if (TREE_CODE (DR_REF (dr)) == COMPONENT_REF && DECL_BIT_FIELD (TREE_OPERAND (DR_REF (dr), 1))) { free_data_ref (dr); return opt_result::failure_at (stmt, "not vectorized:" " statement is an unsupported" " bitfield access %G", stmt); } ? I think we should amend this check and I guess that checking multiple_p on DECL_FIELD_BIT_OFFSET should be enough? Eric - the docs of DECL_BIT_FIELD are vague enough "must be accessed specially" but ISTR it might eventually only apply to the fields (bit) size and not it's position. OTOH the Ada frontend might not be too careful in setting this flag for bit-packed structs? Richard. > Kind Regards, > Andre > > gcc/ChangeLog: > > PR tree-optimization/107346 > * tree-vect-data-refs.cc (vect_check_gather_scatter): Reject > offsets that aren't > multiples of BITS_PER_UNIT. > -- Richard Biener <rguent...@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)