Re: Support for C9X in gcc?

[Andi Kleen <ak@muc.de>]

martin@mira.isdn.cs.tu-berlin.de (Martin v. Loewis) writes:

> > As Zack said, most of the C9X work is in the library, but there 
> > is some compiler work needed.  This work is on my list of things to
> > do, but so is alot of other stuff :-).  
> 
> Could we come up with a list, just so that people know what needs to
> be done? Currently, I see
> 
> - complex (as indicated by Zack),
> - preprocessor changes (which ones are needed, which ones are done?),
> 
> What else?

Support for declarations not only at the beginning of blocks and
in for loops:

f()
{
        int a;
        a = 1;
        int b;
        b = 2;
        for (int c = 3; c < 10; c++) { /* c is only in scope in the loop */
                ...
        } 
}

I actually once tried to hack that into the gcc bison parser, but I'm
afraid it'll need more work to guarantee at least the same level of 
syntax error recovery as the current C grammer has.

What is worse is that C9x "legalized" some gcc extensions, but changed
their semantics slightly. It requires a good migration strategy, and
will cause problems for system headers that use gcc extensions (like
glibc and Linux).

C9x inline implies static

C9x has a similar facility to GCC variable length local arrays. I believe
there are some subtle differences to the similar gcc extension too.

C9x declaration designators are different from gcc ([ x ] = val instead 
of [ x ] val ) 

Other easy changes:

- Support for _Pragma() 
- Support for universal character names
- Disable some -pedantic warnings for gcc extensions that are legal 
now (e.g. the [0] hack for the last structure element, comma at the
end of enum etc.) 

The draft I have also says that they changed the integer constant type
and integer promotion rules and the structure type compatibility rules.
I haven't checked what changes are exactly required for that.

-Andi

-- 
This is like TV. I don't like TV.