On 7 October 2016 at 10:33, Prathamesh Kulkarni
wrote:
> On 22 September 2016 at 23:15, Joseph Myers wrote:
>> On Thu, 22 Sep 2016, Prathamesh Kulkarni wrote:
>>
>>> Would that be acceptable ? I am not sure how to make %Z check if the
>>> argument has type vec *
>>> since vec is not really a buil
On Sat, Oct 8, 2016 at 1:07 PM, Prathamesh Kulkarni
wrote:
> On 7 October 2016 at 17:49, David Malcolm wrote:
>> On Fri, 2016-10-07 at 10:33 +0530, Prathamesh Kulkarni wrote:
>>> On 22 September 2016 at 23:15, Joseph Myers
>>> wrote:
>>> > On Thu, 22 Sep 2016, Prathamesh Kulkarni wrote:
>>> >
>>
On 7 October 2016 at 17:49, David Malcolm wrote:
> On Fri, 2016-10-07 at 10:33 +0530, Prathamesh Kulkarni wrote:
>> On 22 September 2016 at 23:15, Joseph Myers
>> wrote:
>> > On Thu, 22 Sep 2016, Prathamesh Kulkarni wrote:
>> >
>> > > Would that be acceptable ? I am not sure how to make %Z check
On Fri, 2016-10-07 at 10:33 +0530, Prathamesh Kulkarni wrote:
> On 22 September 2016 at 23:15, Joseph Myers
> wrote:
> > On Thu, 22 Sep 2016, Prathamesh Kulkarni wrote:
> >
> > > Would that be acceptable ? I am not sure how to make %Z check if
> > > the
> > > argument has type vec *
> > > since v
On 22 September 2016 at 23:15, Joseph Myers wrote:
> On Thu, 22 Sep 2016, Prathamesh Kulkarni wrote:
>
>> Would that be acceptable ? I am not sure how to make %Z check if the
>> argument has type vec *
>> since vec is not really a builtin C type.
>> Could you suggest me a better solution so that t
On Thu, 22 Sep 2016, Prathamesh Kulkarni wrote:
> Would that be acceptable ? I am not sure how to make %Z check if the
> argument has type vec *
> since vec is not really a builtin C type.
> Could you suggest me a better solution so that the format checker will check
> if arg has type vec * instea
On 20 September 2016 at 18:31, Joseph Myers wrote:
> On Tue, 20 Sep 2016, Prathamesh Kulkarni wrote:
>
>> Could someone please take a look at the change to c-format.c, I am not sure
>> if I have added that correctly.
>
> Any changes to these GCC formats also require tests to be updated
> (gcc.dg/f
On Tue, 20 Sep 2016, Martin Sebor wrote:
> > That's much harder to support in format checking (which expects one length
> > modifier, not a combination like that).
>
> I haven't looked into it detail but since the format checker supports
> one-to-two character sequences of length modifiers (h or
On 09/20/2016 07:00 AM, Joseph Myers wrote:
On Tue, 20 Sep 2016, Martin Sebor wrote:
That said, since this specifier formats a vec, it seems that
it might be useful to be able to format vectors of other elements,
such as short and long. With that in mind, would adding a new V
length modifier i
On Tue, 20 Sep 2016, Prathamesh Kulkarni wrote:
> Could someone please take a look at the change to c-format.c, I am not sure
> if I have added that correctly.
Any changes to these GCC formats also require tests to be updated
(gcc.dg/format/gcc_diag*).
--
Joseph S. Myers
jos...@codesourcery.co
On Tue, 20 Sep 2016, Martin Sebor wrote:
> That said, since this specifier formats a vec, it seems that
> it might be useful to be able to format vectors of other elements,
> such as short and long. With that in mind, would adding a new V
> length modifier instead be a more regular way to extend
On 20 September 2016 at 08:57, Martin Sebor wrote:
>> and used
>> pp_format for formatting arg_positions by adding specifier %I (name
>> chosen arbitrarily).
>> Does that look OK ?
>
>
> diff --git a/gcc/pretty-print.c b/gcc/pretty-print.c
> index a39815e..e8bd1ef 100644
> --- a/gcc/pretty-print.c
On 09/18/2016 06:16 PM, Prathamesh Kulkarni wrote:
> + warning_at_rich_loc (&richloc, OPT_Wrestrict, "passing argument %i to"
> +" restrict-qualified parameter aliases with argument%s
> %I",
> +param_pos + 1, (arg_positions.length() > 1) ? "s" : "",
> +
and used
pp_format for formatting arg_positions by adding specifier %I (name
chosen arbitrarily).
Does that look OK ?
diff --git a/gcc/pretty-print.c b/gcc/pretty-print.c
index a39815e..e8bd1ef 100644
--- a/gcc/pretty-print.c
+++ b/gcc/pretty-print.c
@@ -610,6 +610,23 @@ pp_format (pretty_printe
On Mon, 19 Sep 2016, David Malcolm wrote:
> But does the new specifier need to be added to c-family/c-format.c, so
> that stage 2 and 3 compilers do know about it?
Yes.
--
Joseph S. Myers
jos...@codesourcery.com
On Sun, 2016-09-18 at 22:46 +0530, Prathamesh Kulkarni wrote:
> On 2 September 2016 at 23:14, David Malcolm
> wrote:
> > On Thu, 2016-09-01 at 14:55 +0530, Prathamesh Kulkarni wrote:
> >
> > [...]
> >
> > > The attached version passes bootstrap+test on ppc64le-linux-gnu.
> > > Given that it only
On Mon, 2016-09-19 at 14:21 -0400, Jason Merrill wrote:
> On Sun, Sep 18, 2016 at 1:16 PM, Prathamesh Kulkarni
> wrote:
> > Sorry for late response. In the attached patch, I removed obstack
> > building on fmt, and used pp_format for formatting arg_positions by
> > adding specifier %I (name
> > ch
On Sun, Sep 18, 2016 at 1:16 PM, Prathamesh Kulkarni
wrote:
> Sorry for late response. In the attached patch, I removed obstack
> building on fmt, and used pp_format for formatting arg_positions by adding
> specifier %I (name
> chosen arbitrarily). Does that look OK ?
>
> However it results in fo
On 2 September 2016 at 23:14, David Malcolm wrote:
> On Thu, 2016-09-01 at 14:55 +0530, Prathamesh Kulkarni wrote:
>
> [...]
>
>> The attached version passes bootstrap+test on ppc64le-linux-gnu.
>> Given that it only looks if parameters are restrict qualified and not
>> how they're used inside the
On 1 September 2016 at 21:28, Martin Sebor wrote:
>> The attached version passes bootstrap+test on ppc64le-linux-gnu.
>> Given that it only looks if parameters are restrict qualified and not
>> how they're used inside the callee,
>> this can have false positives as in above test-cases.
>> Should t
On 02/09/16 18:44, David Malcolm wrote:
Much better would be to have the formatting be done inside the
diagnostics subsystem's call into pp_format, with something like this:
warning_at_rich_loc_n (&richloc, OPT_Wrestrict,
arg_positions
.length (),
On Thu, 2016-09-01 at 14:55 +0530, Prathamesh Kulkarni wrote:
[...]
> The attached version passes bootstrap+test on ppc64le-linux-gnu.
> Given that it only looks if parameters are restrict qualified and not
> how they're used inside the callee,
> this can have false positives as in above test-cas
The attached version passes bootstrap+test on ppc64le-linux-gnu.
Given that it only looks if parameters are restrict qualified and not
how they're used inside the callee,
this can have false positives as in above test-cases.
Should the warning be put in Wextra rather than Wall (I have left it
in W
On 1 September 2016 at 12:25, Richard Biener wrote:
> On Tue, 30 Aug 2016, Tom de Vries wrote:
>
>> On 30/08/16 17:34, Prathamesh Kulkarni wrote:
>> > On 30 August 2016 at 20:24, Tom de Vries wrote:
>> > > On 26/08/16 13:39, Prathamesh Kulkarni wrote:
>> > > >
>> > > > Hi,
>> > > > The following
On Tue, 30 Aug 2016, Tom de Vries wrote:
> On 30/08/16 17:34, Prathamesh Kulkarni wrote:
> > On 30 August 2016 at 20:24, Tom de Vries wrote:
> > > On 26/08/16 13:39, Prathamesh Kulkarni wrote:
> > > >
> > > > Hi,
> > > > The following patch adds option -Wrestrict that warns when an argument
> >
2016-08-30 17:34 GMT+02:00 Prathamesh Kulkarni :
> On 30 August 2016 at 20:24, Tom de Vries wrote:
>> On 26/08/16 13:39, Prathamesh Kulkarni wrote:
>>>
>>> Hi,
>>> The following patch adds option -Wrestrict that warns when an argument
>>> is passed to a restrict qualified parameter and it aliases
On 30 August 2016 at 18:49, David Malcolm wrote:
> On Tue, 2016-08-30 at 17:08 +0530, Prathamesh Kulkarni wrote:
>> On 30 August 2016 at 05:34, David Malcolm
>> wrote:
>> > On Mon, 2016-08-29 at 20:01 -0400, David Malcolm wrote:
>> > > On Mon, 2016-08-29 at 19:55 -0400, David Malcolm wrote:
>> >
On 31 August 2016 at 03:45, Mike Stump wrote:
> On Aug 30, 2016, at 4:57 AM, Prathamesh Kulkarni
> wrote:
>>
>> On 30 August 2016 at 17:11, Eric Gallager wrote:
>>> On 8/29/16, Jason Merrill wrote:
On Mon, Aug 29, 2016 at 10:28 AM, Marek Polacek wrote:
> On Mon, Aug 29, 2016 at 09:20
On 30/08/16 16:54, Tom de Vries wrote:
On 26/08/16 13:39, Prathamesh Kulkarni wrote:
Hi,
The following patch adds option -Wrestrict that warns when an argument
is passed to a restrict qualified parameter and it aliases with
another argument.
eg:
int foo (const char *__restrict buf, const char *
On Tue, 2016-08-30 at 23:26 +0530, Prathamesh Kulkarni wrote:
[...]
> The attached (untested) patch silences the warning if parameter is
> const qualified.
> I will give it some testing after resolving a different issue.
I've now removed the hard-coded limit of 3 ranges per rich_location, so
you
On Aug 30, 2016, at 4:57 AM, Prathamesh Kulkarni
wrote:
>
> On 30 August 2016 at 17:11, Eric Gallager wrote:
>> On 8/29/16, Jason Merrill wrote:
>>> On Mon, Aug 29, 2016 at 10:28 AM, Marek Polacek wrote:
On Mon, Aug 29, 2016 at 09:20:53AM -0400, Eric Gallager wrote:
> I tried this pa
On 30 August 2016 at 22:58, Tom de Vries wrote:
> On 30/08/16 17:34, Prathamesh Kulkarni wrote:
>>
>> On 30 August 2016 at 20:24, Tom de Vries wrote:
>>>
>>> On 26/08/16 13:39, Prathamesh Kulkarni wrote:
Hi,
The following patch adds option -Wrestrict that warns when an argumen
On 30/08/16 17:34, Prathamesh Kulkarni wrote:
On 30 August 2016 at 20:24, Tom de Vries wrote:
On 26/08/16 13:39, Prathamesh Kulkarni wrote:
Hi,
The following patch adds option -Wrestrict that warns when an argument
is passed to a restrict qualified parameter and it aliases with
another argume
On 30 August 2016 at 20:24, Tom de Vries wrote:
> On 26/08/16 13:39, Prathamesh Kulkarni wrote:
>>
>> Hi,
>> The following patch adds option -Wrestrict that warns when an argument
>> is passed to a restrict qualified parameter and it aliases with
>> another argument.
>>
>> eg:
>> int foo (const ch
On 26/08/16 13:39, Prathamesh Kulkarni wrote:
Hi,
The following patch adds option -Wrestrict that warns when an argument
is passed to a restrict qualified parameter and it aliases with
another argument.
eg:
int foo (const char *__restrict buf, const char *__restrict fmt, ...);
void f(void)
{
On Tue, 2016-08-30 at 17:08 +0530, Prathamesh Kulkarni wrote:
> On 30 August 2016 at 05:34, David Malcolm
> wrote:
> > On Mon, 2016-08-29 at 20:01 -0400, David Malcolm wrote:
> > > On Mon, 2016-08-29 at 19:55 -0400, David Malcolm wrote:
> > > [...]
> > > > Assuming you have the location_t values a
On 30 August 2016 at 17:11, Eric Gallager wrote:
> On 8/29/16, Jason Merrill wrote:
>> On Mon, Aug 29, 2016 at 10:28 AM, Marek Polacek wrote:
>>> On Mon, Aug 29, 2016 at 09:20:53AM -0400, Eric Gallager wrote:
I tried this patch on my fork of gdb-binutils and got a few warnings
from it.
On 8/29/16, Jason Merrill wrote:
> On Mon, Aug 29, 2016 at 10:28 AM, Marek Polacek wrote:
>> On Mon, Aug 29, 2016 at 09:20:53AM -0400, Eric Gallager wrote:
>>> I tried this patch on my fork of gdb-binutils and got a few warnings
>>> from it. Would it be possible to have the caret point to the arg
On 30 August 2016 at 05:34, David Malcolm wrote:
> On Mon, 2016-08-29 at 20:01 -0400, David Malcolm wrote:
>> On Mon, 2016-08-29 at 19:55 -0400, David Malcolm wrote:
>> [...]
>> > Assuming you have the location_t values available, you can create a
>> > rich_location for the primary range, and then
On Mon, 2016-08-29 at 20:01 -0400, David Malcolm wrote:
> On Mon, 2016-08-29 at 19:55 -0400, David Malcolm wrote:
> [...]
> > Assuming you have the location_t values available, you can create a
> > rich_location for the primary range, and then add secondary ranges
> > like
> > this:
> >
> > rich
On Mon, 2016-08-29 at 19:55 -0400, David Malcolm wrote:
[...]
> Assuming you have the location_t values available, you can create a
> rich_location for the primary range, and then add secondary ranges
> like
> this:
>
> rich_location richloc (loc_of_arg1);
Oops, the above should be:
rich_l
On Tue, 2016-08-30 at 03:23 +0530, Prathamesh Kulkarni wrote:
> On 29 August 2016 at 19:59, Marek Polacek wrote:
> > On Mon, Aug 29, 2016 at 04:25:25PM +0200, Tobias Burnus wrote:
> > > Prathamesh Kulkarni wrote:
> > > > Attachment: pr35503-3.txt
> > >
> > > I tried the patch - and it found a bug
On 29 August 2016 at 19:59, Marek Polacek wrote:
> On Mon, Aug 29, 2016 at 04:25:25PM +0200, Tobias Burnus wrote:
>> Prathamesh Kulkarni wrote:
>> > Attachment: pr35503-3.txt
>>
>> I tried the patch - and it found a bug in our code; nice!
>>
>>
>> (a) Regarding the [-Werror] output:
>>
>>error
On Mon, Aug 29, 2016 at 10:28 AM, Marek Polacek wrote:
> On Mon, Aug 29, 2016 at 09:20:53AM -0400, Eric Gallager wrote:
>> I tried this patch on my fork of gdb-binutils and got a few warnings
>> from it. Would it be possible to have the caret point to the argument
>> mentioned, instead of the func
On Mon, Aug 29, 2016 at 04:25:25PM +0200, Tobias Burnus wrote:
> Prathamesh Kulkarni wrote:
> > Attachment: pr35503-3.txt
>
> I tried the patch - and it found a bug in our code; nice!
>
>
> (a) Regarding the [-Werror] output:
>
>error: passing argument 24 to restrict qualified parameter ali
On Mon, Aug 29, 2016 at 09:20:53AM -0400, Eric Gallager wrote:
> I tried this patch on my fork of gdb-binutils and got a few warnings
> from it. Would it be possible to have the caret point to the argument
> mentioned, instead of the function name? And also print the option
> name? E.g., instead of
Prathamesh Kulkarni wrote:
> Attachment: pr35503-3.txt
I tried the patch - and it found a bug in our code; nice!
(a) Regarding the [-Werror] output:
error: passing argument 24 to restrict qualified parameter aliases with
argument 29 [-Werror]
Shouldn't that output "[-Werror=restrict]" inst
On Sun, Aug 28, 2016 at 06:32:59PM +0530, Prathamesh Kulkarni wrote:
> On 26 August 2016 at 21:25, Jason Merrill wrote:
> > On Fri, Aug 26, 2016 at 7:39 AM, Prathamesh Kulkarni
> > wrote:
> >> However with C++FE it appears TYPE_RESTRICT is not set for the
> >> parameters (buf and fmt)
> >> and he
On 8/28/16, Prathamesh Kulkarni wrote:
> On 26 August 2016 at 21:25, Jason Merrill wrote:
>> On Fri, Aug 26, 2016 at 7:39 AM, Prathamesh Kulkarni
>> wrote:
>>> However with C++FE it appears TYPE_RESTRICT is not set for the
>>> parameters (buf and fmt)
>>> and hence the warning doesn't get emitte
On 26 August 2016 at 21:25, Jason Merrill wrote:
> On Fri, Aug 26, 2016 at 7:39 AM, Prathamesh Kulkarni
> wrote:
>> However with C++FE it appears TYPE_RESTRICT is not set for the
>> parameters (buf and fmt)
>> and hence the warning doesn't get emitted for C++.
>> C FE sets TYPE_RESTRICT for them.
On Fri, Aug 26, 2016 at 7:39 AM, Prathamesh Kulkarni
wrote:
> However with C++FE it appears TYPE_RESTRICT is not set for the
> parameters (buf and fmt)
> and hence the warning doesn't get emitted for C++.
> C FE sets TYPE_RESTRICT for them. I am not sure how to workaround this
> issue, and would b
Arguments passed to diagnostic functions should not end with '\n'.
--
Joseph S. Myers
jos...@codesourcery.com
52 matches
Mail list logo
