[cfe-dev] Unneeded declarations invalidation

Abramo Bagnara abramobagnara at tin.it
Tue Jul 21 07:58:04 PDT 2009

Douglas Gregor ha scritto:
> On Jul 21, 2009, at 1:05 AM, Abramo Bagnara wrote:
>> Douglas Gregor ha scritto:
>>> The real problem here is that we're replacing the type of the field
>>> with 'int', when there's no reason to do that. However, I feel that it
>>> is important to mark this declaration as invalid, because it *is*
>>> invalid. So, I've committed the change not to replace the type with
>>> 'int', but the declaration is still marked invalid:
>>>     http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090720/019240.html
>> The problem with this choice is that the AST is needlessly mutilated.
>> Take this example:
>> void f(int n) {
>>  struct s {
>>    int i;
>>    int a[n];
>>  };
>>  struct s a, b;
>>  a.i = 3;
>>  a.a[0] = 2;
>> }
>> With your changes the last statement of the function is not inserted in
>> the AST.
>> Which drawbacks you see to not invalidate the declaration and then to
>> permit the building of a complete AST nevertheless, once taken for
>> granted that the code generation phase will never be run?
> It breaks the invariant that there are no variable-length structures,
> which means that we can't compute sizeof(s). Since the well-formedness
> (and, in C++, the AST itself) can depend on the value of sizeof(s),

In C++ there are no problems, as also GCC refuses variable length array
inside records.

> later semantic analysis is likely to fail. We mark invalid declarations
> as invalid to avoid such cascading failures.

I understand... :-(

Declaration invalidation apart, the removal of last statement of
function f from AST is unavoidable for the same reasons?

The problem we have is to avoid that AST is missing some parts of what
GCC is able to compile. Do you think it will be feasible in some way?

Do you have some hints for a patch that you would be willing to accept
to accomplish that?

More information about the cfe-dev mailing list