Re: [PATCH] unshare expressions in attribute arguments

2020-11-23 Thread Joseph Myers
On Fri, 20 Nov 2020, Martin Sebor via Gcc-patches wrote: > The VLA bounds are evaluated in function definitions so there > must be a point where that's done. I don't know where that > happens but unless at that point the most significant bound > is still associated with the param (AFAIK, it

Re: [PATCH] unshare expressions in attribute arguments

2020-11-23 Thread Martin Sebor via Gcc-patches
On 11/23/20 11:21 AM, Jakub Jelinek wrote: On Mon, Nov 23, 2020 at 11:08:13AM -0700, Martin Sebor wrote: I don't think it would be significant complication, on the other side you avoid wasting compile time memory on that (GC one, which means it will be wasted until GC collection if there is one

Re: [PATCH] unshare expressions in attribute arguments

2020-11-23 Thread Jakub Jelinek via Gcc-patches
On Mon, Nov 23, 2020 at 11:08:13AM -0700, Martin Sebor wrote: > > I don't think it would be significant complication, on the other side you > > avoid wasting compile time memory on that (GC one, which means it will be > > wasted until GC collection if there is one ever). Plus all the issues from

Re: [PATCH] unshare expressions in attribute arguments

2020-11-23 Thread Martin Sebor via Gcc-patches
On 11/23/20 10:30 AM, Jakub Jelinek wrote: On Mon, Nov 23, 2020 at 10:03:44AM -0700, Martin Sebor wrote: If the most significant bound is lost, why don't you save in the attribute early only the most significant bound before it is lost The other bounds are a part of the type so saving them in

Re: [PATCH] unshare expressions in attribute arguments

2020-11-23 Thread Jakub Jelinek via Gcc-patches
On Mon, Nov 23, 2020 at 10:03:44AM -0700, Martin Sebor wrote: > > If the most significant bound is lost, why don't you save in the attribute > > early only the most significant bound before it is lost > > The other bounds are a part of the type so saving them in the attribute > isn't essential.

Re: [PATCH] unshare expressions in attribute arguments

2020-11-23 Thread Martin Sebor via Gcc-patches
On 11/21/20 1:01 AM, Jakub Jelinek wrote: On Fri, Nov 20, 2020 at 03:44:01PM -0700, Martin Sebor via Gcc-patches wrote: So that likely means you are doing it too early. The bounds are added to attribute "arg spec" for each param in push_parm_decl. I think that's both as early and (except

Re: [PATCH] unshare expressions in attribute arguments

2020-11-21 Thread Jeff Law via Gcc-patches
On 11/20/20 12:00 PM, Martin Sebor via Gcc-patches wrote: > To detect a subset of VLA misuses, the C front associates the bounds > of VLAs in function argument lists with the corresponding variables > by implicitly adding an instance of attribute access to each function > declared to take VLAs

Re: [PATCH] unshare expressions in attribute arguments

2020-11-21 Thread Jakub Jelinek via Gcc-patches
On Fri, Nov 20, 2020 at 03:44:01PM -0700, Martin Sebor via Gcc-patches wrote: > > So that likely means you are doing it too early. > > The bounds are added to attribute "arg spec" for each param in > push_parm_decl. I think that's both as early and (except maybe > in function definitions) as

Re: [PATCH] unshare expressions in attribute arguments

2020-11-20 Thread Martin Sebor via Gcc-patches
On 11/20/20 2:57 PM, Jakub Jelinek wrote: On Fri, Nov 20, 2020 at 02:54:34PM -0700, Martin Sebor wrote: At the point the attribute is created there is no SAVE_EXPR. So for something like: int f (void); void g (int a[f () + 1]) { } the bound is a PLUS_EXPR (CALL_EXPR (f), 1). I don't do

Re: [PATCH] unshare expressions in attribute arguments

2020-11-20 Thread Jakub Jelinek via Gcc-patches
On Fri, Nov 20, 2020 at 02:54:34PM -0700, Martin Sebor wrote: > At the point the attribute is created there is no SAVE_EXPR. So for > something like: > > int f (void); > void g (int a[f () + 1]) { } > > the bound is a PLUS_EXPR (CALL_EXPR (f), 1). > > I don't do anything with the expression

Re: [PATCH] unshare expressions in attribute arguments

2020-11-20 Thread Martin Sebor via Gcc-patches
On 11/20/20 2:41 PM, Jakub Jelinek wrote: On Fri, Nov 20, 2020 at 02:30:43PM -0700, Martin Sebor wrote: VLA parameter bounds can involve any other expressions, including function calls. It's those rather than other parameters that also trigger the problem (at least in the test cases I've

Re: [PATCH] unshare expressions in attribute arguments

2020-11-20 Thread Jakub Jelinek via Gcc-patches
On Fri, Nov 20, 2020 at 02:30:43PM -0700, Martin Sebor wrote: > VLA parameter bounds can involve any other expressions, including > function calls. It's those rather than other parameters that also > trigger the problem (at least in the test cases I've seen). > > When/how would the unsharing

Re: [PATCH] unshare expressions in attribute arguments

2020-11-20 Thread Martin Sebor via Gcc-patches
On 11/20/20 1:37 PM, Jakub Jelinek wrote: On Fri, Nov 20, 2020 at 01:28:03PM -0700, Martin Sebor via Gcc-patches wrote: On 11/20/20 12:29 PM, Marek Polacek wrote: On Fri, Nov 20, 2020 at 12:00:58PM -0700, Martin Sebor via Gcc-patches wrote: To detect a subset of VLA misuses, the C front

Re: [PATCH] unshare expressions in attribute arguments

2020-11-20 Thread Jakub Jelinek via Gcc-patches
On Fri, Nov 20, 2020 at 01:28:03PM -0700, Martin Sebor via Gcc-patches wrote: > On 11/20/20 12:29 PM, Marek Polacek wrote: > > On Fri, Nov 20, 2020 at 12:00:58PM -0700, Martin Sebor via Gcc-patches > > wrote: > > > To detect a subset of VLA misuses, the C front associates the bounds > > > of VLAs

Re: [PATCH] unshare expressions in attribute arguments

2020-11-20 Thread Martin Sebor via Gcc-patches
On 11/20/20 12:29 PM, Marek Polacek wrote: On Fri, Nov 20, 2020 at 12:00:58PM -0700, Martin Sebor via Gcc-patches wrote: To detect a subset of VLA misuses, the C front associates the bounds of VLAs in function argument lists with the corresponding variables by implicitly adding an instance of

Re: [PATCH] unshare expressions in attribute arguments

2020-11-20 Thread Marek Polacek via Gcc-patches
On Fri, Nov 20, 2020 at 12:00:58PM -0700, Martin Sebor via Gcc-patches wrote: > To detect a subset of VLA misuses, the C front associates the bounds > of VLAs in function argument lists with the corresponding variables > by implicitly adding an instance of attribute access to each function >

[PATCH] unshare expressions in attribute arguments

2020-11-20 Thread Martin Sebor via Gcc-patches
To detect a subset of VLA misuses, the C front associates the bounds of VLAs in function argument lists with the corresponding variables by implicitly adding an instance of attribute access to each function declared to take VLAs with the bound expressions chained on the list of attribute