Re: [PATCH] Fix type field walking in gimplifier unsharing

[Eric Botcazou <ebotcazou@adacore.com>]

> Aww, I was hoping for sth that would not require me to fix all
> frontends ...

I don't really see how this can work without DECL_EXPR though.  You need to 
define when the variable-sized expressions are evaluated to lay out the type, 
otherwise it will be laid out on the first use, which may see a different 
value of the expressions than the definition point.  The only way to do that 
for a locally-defined type is to add a DECL_EXPR in GENERIC, so that the 
gimplifier evaluates the expressions at the right spot.

Of course in Ada we have the ACATS testsuite which tests for this kind of 
things, this explains why it already works.

> It seems the C frontend does it correctly already - I hit the
> ubsan issue for c-c++-common/ubsan/pr59667.c and only for the C++ FE
> for example.  Notice how only the pointed-to type is variable-size
> here.
> 
> C produces
> 
> {
>   unsigned int len = 1;
>   typedef float <anon>[0:(sizetype) ((long int) SAVE_EXPR <len> +
> -1)][0:(sizetype) ((long int) SAVE_EXPR <len> + -1)];
>   float[0:(sizetype) ((long int) SAVE_EXPR <len> + -1)][0:(sizetype)
> ((long int) SAVE_EXPR <len> + -1)] * P = 0B;
> 
>     unsigned int len = 1;
>     typedef float <anon>[0:(sizetype) ((long int) SAVE_EXPR <len> +
> -1)][0:(sizetype) ((long int) SAVE_EXPR <len> + -1)];
>   SAVE_EXPR <len>;, (void) SAVE_EXPR <len>;;
>     float[0:(sizetype) ((long int) SAVE_EXPR <len> + -1)][0:(sizetype)
> ((long int) SAVE_EXPR <len> + -1)] * P = 0B;
>   (*P)[0][0] = 1.0e+0;
>   return 0;
> }
> 
> the decl-expr is the 'typedef' line.  The C++ FE produces
> 
> {
>   unsigned int len = 1;
>   float[0:(sizetype) (SAVE_EXPR <(ssizetype) len + -1>)][0:(sizetype)
> (SAVE_EXPR <(ssizetype) len + -1>)] * P = 0B;
> 
>   <<cleanup_point   unsigned int len = 1;>>;
>   <<cleanup_point <<< Unknown tree: expr_stmt
>   (void) (((bitsizetype) ((sizetype) (SAVE_EXPR <(ssizetype) len + -1>) +
> 1) * (bitsizetype) ((sizetype) (SAVE_EXPR <(ssizetype) len + -1>) + 1)) *
> 32) >>>>>;
>   <<cleanup_point   float[0:(sizetype) (SAVE_EXPR <(ssizetype) len +
> -1>)][0:(sizetype) (SAVE_EXPR <(ssizetype) len + -1>)] * P = 0B;>>;
>   <<cleanup_point <<< Unknown tree: expr_stmt
>   (void) ((*P)[0][0] = 1.0e+0) >>>>>;
>   return <retval> = 0;
> }
> 
> notice the lack of a decl-expr here.  It has some weird expr_stmt
> here covering the sizes though. Possibly because VLA arrays are a GNU
> extension.

Indeed.

> Didn't look into the fortran FE issue but I expect it's similar
> (it only occurs for pointers to VLAs as well).
> 
> I'll try to come up with patches.
> 
> Thanks for the hint,

You're welcome.

-- 
Eric Botcazou