[cfe-commits] [PATCH] --std=gnu++0xc9x : Allowing C++0x, C99 and GNU extensions

[Douglas Gregor]

On Sep 3, 2010, at 5:13 AM, Benoit Belley wrote:

> Without the C99 language features, I trigger the following error message:
> 
> // C99 variable-length arrays
> def err_vla_non_pod : Error<"variable length array of non-POD element type %0 »>;
> 
> Note that both g++ and the Intel compiler accept C99 VLA by default.  Here’s an example demonstrating this:
> 
> $ car foo.cpp
> class A
> {
> public:
>    A();
>    ~A();
> };
> 
> void foo(int i)
> {
>    A vla[i];
> }

Sure, but that's not a C99 VLA: that's a VLA using a type that can only be expressed in C++ and requires a non-trivial amount of extra work in IR generation to get right. In particular, we need to generate IR to call the destructors for elements in the VLA, along the normal path, exception path, and exception-thrown-during-initialization path.

If someone contributes proper IR generation support for non-POD VLAs, including solid testing to ensure that we're dealing with all of the hard cases, too, to make this a real feature, then I'd be happy to reduce that error to an extwarn/extension in GNU mode. However, without proper IR generation support, the error needs to stay in place.

As an aside: -std=gnu++0x and -std=gnu++98 will end up with most/all of the C99 features that GNU supports anyway, so there should never be a need for, e.g., -std=gnucxx0xc9x. If we get to that point, we should be talking about multiple, semi-independent flags. I'd rather not have to go there.

	- Doug