TREE_CST_RTL and CONSTRUCTORs

TREE_CST_RTL and CONSTRUCTORs

[Martin von Loewis]

The macro TREE_CST_RTL accesses the real_cst variant of the tree, so
I first required it to be a REAL_CST. Then I found that it is also used
to access STRING_CST nodes. This is fine, as both structures start
with

struct tree_*_cst
{
  char common[sizeof (struct tree_common)];
  struct rtx_def *rtl;

and the macro accesses rtl. Now, the comment says that it is also used
to access CONSTRUCTOR expressions, which has the lay-out

struct tree_exp
{
  char common[sizeof (struct tree_common)];
  int complexity;

So we really have the complexity field here. This problem is exposed in
gcc.c-torture/compile/920501-11.c, where output_constant_def is called
with a CONSTRUCTOR.

What is the story here? Is this intended, and gcc requires sizeof(int)
== sizeof(tree)? If so, I should relax the check to also accept
constructors in TREE_CST_RTL. If not, gcc should be changed.

Regards,
Martin

Re: TREE_CST_RTL and CONSTRUCTORs

[Richard Henderson]

On Wed, Apr 22, 1998 at 10:37:42AM +0200, Martin von Loewis wrote:
> What is the story here? Is this intended, and gcc requires sizeof(int)
> == sizeof(tree)?

It clearly cannot, because on almost all 64-bit hosts this is false.


r~

Re: TREE_CST_RTL and CONSTRUCTORs

[Jim Wilson]

	What is the story here? Is this intended, and gcc requires sizeof(int)
	== sizeof(tree)? If so, I should relax the check to also accept
	constructors in TREE_CST_RTL. If not, gcc should be changed.

This is a bug.

Since a CONSTRUCTOR is defined by tree.def to have two operands, and
TREE_OPERANDS(x,1) is CONSTRUCTOR_ELTS, it appears that the intent was that
TREE_OPERANDS(x,0) would be TREE_CST_RTL.  This does not happen because of
the complexity field.

I suspect we need a CONSTRUCTOR_RTL macro which looks like the
CALL_EXPR_RTL macro, and then we need to use it instead of TREE_CST_RTL
for CONSTRUCTORs.

Jim