This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PR35503 - warn for restrict pointer
- From: Prathamesh Kulkarni <prathamesh dot kulkarni at linaro dot org>
- To: Martin Sebor <msebor at gmail dot com>
- Cc: Richard Biener <rguenther at suse dot de>, Tom de Vries <Tom_deVries at mentor dot com>, gcc Patches <gcc-patches at gcc dot gnu dot org>, Marek Polacek <polacek at redhat dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Jason Merrill <jason at redhat dot com>
- Date: Mon, 5 Sep 2016 17:24:35 +0530
- Subject: Re: PR35503 - warn for restrict pointer
- Authentication-results: sourceware.org; auth=none
- References: <CAAgBjMkRNk3f47mXwZ6J_MyMHQym4vo3+zXCZ1R6jjrqDkKRYA@mail.gmail.com> <fcf386ee-6e1c-fb81-d43f-7e825978e0ee@mentor.com> <CAAgBjM=yQGLhxmc155Eg2ggSys0u+z8ieZebxVcoC3h5O7dk0Q@mail.gmail.com> <181560f0-c738-cff9-9002-101686da4c14@mentor.com> <alpine.LSU.2.11.1609010842570.26629@t29.fhfr.qr> <CAAgBjMnakS3C2LX3HLrABJvN3artp-MYJZr_5VZ9Z_ULe+5cwQ@mail.gmail.com> <57C8501E.1080303@gmail.com>
On 1 September 2016 at 21:28, Martin Sebor <msebor@gmail.com> 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 the warning be put in Wextra rather than Wall (I have left it
>> in Wall in the patch) or only enabled with -Wrestrict ?
>
>
> Awesome! I've wished for years for a warning like this!
Thanks for experimenting with the patch!
>
> I'm curious if you've tested other examples from 6.7.3.1 of C11
> besides Example 3. Example 4 seems like something GCC should be
> able to detect but I didn't get a warning with the patch.
Oops, I wasn't aware about example 4, and only implemented the warning
for function call. IIUC, the assignment p = q will result in undefined behavior
if q is qualified with restrict and p is at an outer-scope relative to q ?
>
> I would expect the warning to be especially valuable with string
> manipulation functions like memcpy that have undefined behavior
> for overlapping regions, such as in:
>
> char a[4];
>
> void g (void)
> {
> __builtin_memcpy (a, a + 1, 3);
> }
>
> But here, too, I didn't get a warning. I understand that this
> case cannot be handled for arbitrary functions whose semantics
> aren't known but with standard functions for which GCC provides
> intrinsics the effects are known and aliasing violations can in
> common cases be detected.
Indeed, thanks for the suggestions. I will add support for some
standard functions in a follow-up patch.
Thanks,
Prathamesh
>
> Martin