On 2/12/21 1:55 AM, Richard Biener wrote:
On Fri, Feb 12, 2021 at 1:35 AM Martin Sebor via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
While trawling through old bugs I came across one from 2005: PR 21433
- The COMPONENT_REF case of expand_expr_real_1 is probably wrong.
The report looks correct in that argument 0 in COMPONENT_REF cannot
be a CONSTRUCTOR. In my tests it's only been one of the following
codes:
array_ref
component_ref
mem_ref
parm_decl
result_decl
var_decl
The attached patch removes the CONSTRUCTOR code and replaces it with
an assert verifying it doesn't come up there. Besides testing on
x86_64-linux, the change is supported by comments in code and also
in the internals manual (although that looks incorrect and should
be changed to avoid suggesting the first operand is a decl).
Note the CTOR operand is valid GENERIC and likely came up before
we introduced GIMPLE. GIMPLE simply feeds more restrictive GENERIC
to the RTL expansion routines nowadays (so the patch is OK
eventually), but please
avoid altering GENERIC or tree.def documentation which documents
_GENERIC_.
I have committed the patch in r12-728.
Martin
The restricted boundary of GIMPLE -> RTL expansion is not documented
and in theory we might even run into your assert when processing
global initializers (in case the CTOR ends up TREE_CONSTANT).
tree.def:
/* Value is structure or union component.
Operand 0 is the structure or union (an expression).
Operand 1 is the field (a node of type FIELD_DECL).
Operand 2, if present, is the value of DECL_FIELD_OFFSET, measured
in units of DECL_OFFSET_ALIGN / BITS_PER_UNIT. */
DEFTREECODE (COMPONENT_REF, "component_ref", tcc_reference, 3)
generic.texi:
@item COMPONENT_REF
These nodes represent non-static data member accesses. The first
operand is the object (rather than a pointer to it); the second operand
is the @code{FIELD_DECL} for the data member. The third operand represents
the byte offset of the field, but should not be used directly; call
@code{component_ref_field_offset} instead.