[patch] Fix wrong code with VCE to bit-field type at -O

Richard Biener richard.guenther@gmail.com
Tue Feb 11 13:17:00 GMT 2014


On Tue, Feb 11, 2014 at 11:40 AM, Eric Botcazou <ebotcazou@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  <ebotcazou@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  <ebotcazou@adacore.com>
>
>         * gnat.dg/opt31.adb: New test.
>
>
> --
> Eric Botcazou



More information about the Gcc-patches mailing list