This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] for PR 18040
- From: Zack Weinberg <zack at codesourcery dot com>
- To: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 19 Oct 2004 15:48:53 -0700
- Subject: Re: [patch] for PR 18040
- References: <10410181426.AA03743@vlsi1.ultra.nyu.edu>
kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:
> If you provide an example which produces a type conversion in the
> middle of a chain of dereference expressions, I will endeavor to
> clarify what I mean.
>
> I'll try, but, as I said, I don't write Ada very well ...
>
> with unchecked_conversion;
> function foo return integer is
> type arr is array (1 .. 100) of integer;
> type r is record
> f1: integer;
> f2: array (1..99) of integer;
> end record;
> function uc is new unchecked_conversion (arr, r);
> type q is record f1: arr; end record;
>
> var: q;
> begin
> return (uc (q.f1).f1;
> end foo;
This isn't a great example because everything in here is addressable,
so one could equally well solve the problem by decomposing the chain
of references.
Florian's example is better in this regard. I showed elsewhere how to
solve it by promoting the transformation to an addressable level.
With the suggestion that COMPONENT_REFS would implicitly convert,
you'd have something which I can no longer write in any source
language, so here it is in pseudo-dump_tree() notation (just the body
of the function):
<modify_expr type <void>
<var_decl type <U> var2>
<component_ref type <U>
<field_decl type <U> B>
<component_ref type <Baz>
<field_decl type <T> B>
<var_decl type <Foo> Var1>>>>
The crucial bit being that the inner COMPONENT_REF has a different
type than its FIELD_DECL, indicating an implicit conversion to that
type.
zw