Equivalences *look* broken

[Jakub Jelinek]

On Fri, Oct 14, 2005 at 04:01:50PM +0200, Fran?ois-Xavier Coudert wrote:
> My mind is puzzled by Jakub's patch:
> 
> 2005-10-12  Jakub Jelinek  <jakub@redhat.com>
> 
>         * trans-common.c (build_field): Fix comment typo.
>         (create_common): Set backend_decl of COMMON or EQUIVALENCEd
>         variables to a VAR_DECL with the COMPONENT_REF in
>         DECL_HAS_VALUE_EXPR rather than COMPONENT_REF directly.
>         * f95-lang.c (gfc_expand_function): Emit debug info for
>         EQUIVALENCEd variables if the equiv union is going to be output.
> 
> It makes the tree dumps look like equivalences are broken (but I think
> they're not):

> MAIN__ ()
> {
>   union
>   {
>     real4 pool3[100];
>     real4 pool[100];
>   } equiv.0;
>   real4 pool3[100];
>   real4 pool[100];

There is nothing wrong about this.  The code will use equiv.0.pool{,3},
the pool3 and pool variables are in the BIND_EXPR just for debugging
purposes.  They have DECL_HAS_VALUE_EXPR_P set and their
DECL_VALUE_EXPR is equiv.0.pool etc., so 1) the debugger knows that
the pool variable is located in equiv.0.pool's location and 2)
the gimplifier if it sees pool will gimplify it as equiv.0.pool.

	Jakub