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 never
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
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
>
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
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. I
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 mayb
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 w
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 late
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 a
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 e
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 seen).
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 caus
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 associ
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
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 at
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
> declar
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 arguments
17 matches
Mail list logo
