On Sat, 7 Nov 2015, Segher Boessenkool wrote:
> > 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 p
On 11/07/2015 04:38 PM, Segher Boessenkool wrote:
On Tue, Oct 20, 2015 at 10:10:44PM +, Joseph Myers wrote:
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]
On Tue, Oct 20, 2015 at 10:10:44PM +, Joseph Myers wrote:
> > 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-wa
I guess this is a case where I could say either "I wrote the patch" or
"I requested changes to a patch in review"; in the latter case I can
approve it. Joseph seems on board with what we've discussed, so I'd say
please wait until Tuesday for objections then commit.
I didn't get to committing the
On 10/26/2015 01:27 PM, Richard Biener wrote:
On Mon, Oct 26, 2015 at 1:01 PM, Jakub Jelinek wrote:
On Mon, Oct 26, 2015 at 12:57:53PM +0100, Bernd Schmidt wrote:
On 10/26/2015 12:47 PM, Jakub Jelinek wrote:
Because the amount of code that uses this (including GCC itself) is just too
huge, s
On Mon, Oct 26, 2015 at 1:01 PM, Jakub Jelinek wrote:
> On Mon, Oct 26, 2015 at 12:57:53PM +0100, Bernd Schmidt wrote:
>> On 10/26/2015 12:47 PM, Jakub Jelinek wrote:
>>
>> >Because the amount of code that uses this (including GCC itself) is just too
>> >huge, so everywhere in the middle-end we al
On Mon, Oct 26, 2015 at 12:57:53PM +0100, Bernd Schmidt wrote:
> On 10/26/2015 12:47 PM, Jakub Jelinek wrote:
>
> >Because the amount of code that uses this (including GCC itself) is just too
> >huge, so everywhere in the middle-end we also special case last array
> >members of
> >structs. While
On 10/26/2015 12:47 PM, Jakub Jelinek wrote:
Because the amount of code that uses this (including GCC itself) is just too
huge, so everywhere in the middle-end we also special case last array members of
structs. While C99+ has flexible array members, e.g. C++ does not, so users
are left with us
On Mon, Oct 26, 2015 at 12:40:18PM +0100, Bernd Schmidt wrote:
> On 10/23/2015 10:40 PM, Martin Sebor wrote:
> >
> >The original code deliberately avoids diagnosing the case of last
> >array members with bounds greater than 1 (see the comment about
> >"a poor man's flexible array member" added with
On 10/23/2015 10:40 PM, Martin Sebor wrote:
The original code deliberately avoids diagnosing the case of last
array members with bounds greater than 1 (see the comment about
"a poor man's flexible array member" added with a fix for bug
41935) and I didn't want to change that.
Jakub added that,
On 10/23/2015 11:45 AM, Bernd Schmidt wrote:
On 10/23/2015 06:50 PM, Joseph Myers wrote:
On Fri, 23 Oct 2015, Martin Sebor wrote:
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 thin
On 10/23/2015 06:50 PM, Joseph Myers wrote:
On Fri, 23 Oct 2015, Martin Sebor wrote:
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 trea
On Fri, 23 Oct 2015, Martin Sebor wrote:
> 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 e
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
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
On Tue, 20 Oct 2015, Bernd Schmidt wrote:
> Consider
>
> struct t { int a; int b; };
> struct A { struct t v[2]; } a;
>
> So I think we've established that
> &a.v[2]
> is valid, giving a pointer just past the end of the structure. How about
> &a.v[2].a
> and
> &a.v[2].b
> The first of thes
On 10/20/2015 06:53 PM, Joseph Myers wrote:
On Tue, 20 Oct 2015, Martin Sebor wrote:
I think -Warray-bounds should emit consistent diagnostics for invalid
array references regardless of the contexts. I.e., given
struct S {
int A [5][7];
int x;
} s;
these should bot
On 10/20/2015 10:57 AM, Joseph Myers wrote:
On Tue, 20 Oct 2015, Martin Sebor wrote:
An array subscript is out of range, even if an object is apparently
accessible with the given subscript (as in the lvalue expression
a[1][7] given the declaration int a[4][5]) (6.5.6).
Just-past-the-
On Tue, 20 Oct 2015, Martin Sebor wrote:
> An array subscript is out of range, even if an object is apparently
> accessible with the given subscript (as in the lvalue expression
> a[1][7] given the declaration int a[4][5]) (6.5.6).
Just-past-the-end is only out of range if the dereference i
On 10/20/2015 09:48 AM, Bernd Schmidt wrote:
On 10/20/2015 05:31 PM, Martin Sebor wrote:
On 10/20/2015 07:20 AM, Bernd Schmidt wrote:
On 10/16/2015 09:34 PM, Martin Sebor wrote:
Thank you for the review. Attached is an updated patch that hopefully
addresses all your comments. I ran the check
On Tue, 20 Oct 2015, Martin Sebor wrote:
> I think -Warray-bounds should emit consistent diagnostics for invalid
> array references regardless of the contexts. I.e., given
>
> struct S {
> int A [5][7];
> int x;
> } s;
>
> these should both be diagnosed:
>
> int i =
On 10/20/2015 05:31 PM, Martin Sebor wrote:
On 10/20/2015 07:20 AM, Bernd Schmidt wrote:
On 10/16/2015 09:34 PM, Martin Sebor wrote:
Thank you for the review. Attached is an updated patch that hopefully
addresses all your comments. I ran the check_GNU_style.sh script on
it to make sure I didn
On 10/20/2015 07:20 AM, Bernd Schmidt wrote:
On 10/16/2015 09:34 PM, Martin Sebor wrote:
Thank you for the review. Attached is an updated patch that hopefully
addresses all your comments. I ran the check_GNU_style.sh script on
it to make sure I didn't miss something. I've also added replies to
On 10/16/2015 09:34 PM, Martin Sebor wrote:
Thank you for the review. Attached is an updated patch that hopefully
addresses all your comments. I ran the check_GNU_style.sh script on
it to make sure I didn't miss something. I've also added replies to
a few of your comments below.
Ok, thanks. Ho
On 10/16/2015 06:27 AM, Bernd Schmidt wrote:
On 10/09/2015 04:55 AM, Martin Sebor wrote:
Gcc attempts to diagnose invalid offsetof expressions whose member
designator is an array element with an out-of-bounds index. The
logic in the function that does this detection is incomplete, leading
to fal
On Fri, 16 Oct 2015, Bernd Schmidt wrote:
> > +// The following expression is silently accepted as an extension
> > +// because it simply forms the equivalent of a just-past-the-end
> > +// address.
> > +__builtin_offsetof (A, a1_1 [0][1]),// extension
>
> Hmm, do we really wa
On 10/09/2015 04:55 AM, Martin Sebor wrote:
Gcc attempts to diagnose invalid offsetof expressions whose member
designator is an array element with an out-of-bounds index. The
logic in the function that does this detection is incomplete, leading
to false negatives. Since the result of the expressi
27 matches
Mail list logo
