Re: GCC Status Report (2004-03-09)

[Mark Mitchell <mark at codesourcery dot com>]

Eric Botcazou wrote:

> > So, would you please apply Olivier's patch to the 3.4 branch and the
> > mainline?  Then, we need to come up with some better long-term solution.
> >    
>
> There is a hitch: the C front-end is relying on the clearing optimization to 
> implement the semantics mandated by C99 §6.7.8 [19], that is for
>
> struct B {
>    struct A a;
>    void * const b;
>    struct A const * const c;
>    struct A const *d;
> };
>
> bar (void *x)
> {
>  struct B y = { .b = x, .c = (void *) 0 };
> }
>
> the front-end sends a constructor with only 2 elements to the middle-end, 
> while C99 wants b.a and b.d to be cleared too.
>  
Thank you for doing the experiment!

There are two other fixes I can think of:

(1) Try my scheduling barrier idea, where we introduce a volatile asm 
equivalent between the clearing and the normal assignment.  I know this 
is potentially pessimizing, but in practice the pessimization will 
probably be slight.

(2) In the unsafe case, implement the C99 rule by explicitly clearing 
each individual field.  In other words, iterate through the fields, 
clearing all of the fields that do not have an explicit CONSTRUCTOR_ELT.

I think (1) will probably be less pessimizing that (2).  Are you willing 
to give that a try?

--
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com