On 10/23/2015 05:13 AM, Bernd Schmidt wrote:
On 10/21/2015 12:10 AM, Joseph Myers wrote:
On Tue, 20 Oct 2015, Bernd Schmidt wrote:
How about
&a.v[2].a
and
&a.v[2].b
I don't think either is valid.
typedef struct FA5_7 {
int i;
char a5_7 [5][7];
} FA5_7;
__builtin_offsetof (FA5_7, a5_7 [0][7]), // { dg-warning
"index" }
__builtin_offsetof (FA5_7, a5_7 [1][7]), // { dg-warning
"index" }
__builtin_offsetof (FA5_7, a5_7 [5][0]), // { dg-warning
"index" }
__builtin_offsetof (FA5_7, a5_7 [5][7]), // { dg-warning
"index" }
The last one is certainly invalid. The one before is arguably invalid as
well (in the unary '&' equivalent, &a5_7[5][0] which is equivalent to
a5_7[5] + 0, the questionable operation is implicit conversion of a5_7[5]
from array to pointer - an array expression gets converted to an
expression "that points to the initial element of the array object", but
there is no array object a5_7[5] here).
Martin, is this something you're working on, or should I have a go?
I thought I made all the tweaks to these test cases in the last patch:
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01946.html
But now that I'm re-reading the answer above I see that Joseph
was suggesting that a5_7[5][0] should be diagnosed when the patch
accepts it as an extension. I think we do want to accept it
because a5_7 is treated as a flexible array member (as an extension)
and so the upper bound of the major index is unknown. I.e., FA5_7
is defined like so:
typedef struct FA5_7 {
int i;
char a5_7 [5][7]; // treated as char [][7]
} FA5_7;
Martin
