On Tue, Feb 11, 2014 at 11:40 AM, Eric Botcazou <ebotca...@adacore.com> wrote: > Hi, > > this is an interesting regression from GCC 4.5 present on all active branches > and triggered by recent SRA improvements. For the attached testcase, we have > an unchecked conversion of a 3-byte slice of an array of 4 bytes to a record > type containing a 3-byte bit-field; an unchecked conversion in this case > directly translates into a VIEW_CONVERT_EXPR. Then SRA scalarizes the bit- > field and turns the original VCE into a VCE of the 3-byte slice to the bit- > field type, which is a 32-bit integer with precision 24. > > But the expansion of VCE isn't prepared for this and generates a full 32-bit > read, which thus reads 1 additional byte and doesn't mask it afterwards, thus > resulting in a wrong value for the scalarized bit-field. > > Proposed fix attached, tested on x86-64/Linux, OK for the mainline?
Hmm. The intent was of course to only allow truly no-op converts via VIEW_CONVERT_EXPR - that is, the size of the operand type and the result type should be the same. So, isn't SRA doing it wrong when creating the VIEW_CONVERT_EXPR of a 3-byte type to a 4-byte type? The verification we do in tree-cfg.c:verify_types_in_gimple_reference hints at that we _do_ have even grosser mismatches - so reality may trump desired design here. Richard. > 2014-02-11 Eric Botcazou <ebotca...@adacore.com> > > * expr.c (REDUCE_BIT_FIELD): Extend the scope of the macro. > (expand_expr_real_1) <case VIEW_CONVERT_EXPR>: Deal with bit-field > destination types. > > > 2014-02-11 Eric Botcazou <ebotca...@adacore.com> > > * gnat.dg/opt31.adb: New test. > > > -- > Eric Botcazou
