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
The patch is at the following link:
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg00915.html
Martin
On 10/08/2015 08:55 PM, 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 func
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 expression in these cases
can be surprising, this pat
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 expression in these cases
can be surprising, this pat
30 matches
Mail list logo
