public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Martin Sebor <msebor@gmail.com>
To: David Malcolm <dmalcolm@redhat.com>,
	gcc-patches <gcc-patches@gcc.gnu.org>
Cc: Jeff Law <law@redhat.com>, Aldy Hernandez <aldyh@redhat.com>
Subject: Re: [PING][PATCH 2/4] remove %G and %K from calls in front end and middle end (PR 98512)
Date: Fri, 2 Jul 2021 16:15:35 -0600	[thread overview]
Message-ID: <35c4293b-4805-9091-d27c-7d86aab98dde@gmail.com> (raw)
In-Reply-To: <e4f74e823f9bba1eeb4b2ccb41be6670930fffe4.camel@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2016 bytes --]

On 7/2/21 2:52 PM, David Malcolm wrote:
...
>>>> @@ -11425,10 +11425,10 @@ expand_expr_real_1 (tree exp, rtx
>>>> target, machine_mode tmode,
>>>>                                           DECL_ATTRIBUTES
>>>> (fndecl))) != NULL)
>>>>            {
>>>>              const char *ident = lang_hooks.decl_printable_name
>>>> (fndecl, 1);
>>>> -           warning_at (tree_nonartificial_location (exp),
>>>> +           warning_at (EXPR_LOCATION (exp),
>>>
>>> Are we preserving the existing behavior for
>>> __attribute__((__artificial__)) here?
>>> Is this behavior handled somewhere else in the patch kit?
>>
>> Yes.  The warning infrastructure (set_inlining_locations) uses
>> the location of the site into which the statement has been inlined
>> regardless of whether the inlined function is artificial.
> 
> Do we have test coverage for this, though?
> 
> [...]
>> Attached is the revised patch for reference.  Since it just removes
>> the uses of the %K and %G directives made redundant by the first
>> patch in the series I'll go ahead and commit it as obvious in a day
>> or so after patch 1 unless someone has further questions or requests
>> for changes.
> 
> Please can you look into the "__artificial__" test coverage, and
> address the line number thing above.

There are a bunch of tests for it but I couldn't find one that
verifies the inlining stack.  I always struggle with the DejaGnu
directives for these things (I couldn't get dg-multiline-output
to do what I wanted) so I cribbed the approach from
plugin/diagnostic-test-inlining-*.c.

Since I was changing the directives I got rid of the line numbers
from their comments but instead hardcoded them in the search pattern,
making the tests tighter.  That's a good thing but it does of course
mean that when new lines are added to the tests the directives will
fail and the patterns will need to be updated.

Attached is a patch with just the test I'm adding.

Martin

[-- Attachment #2: Wfree-nonheap-object-6.c.diff --]
[-- Type: text/x-patch, Size: 1834 bytes --]

diff --git a/gcc/testsuite/gcc.dg/Wfree-nonheap-object-6.c b/gcc/testsuite/gcc.dg/Wfree-nonheap-object-6.c
new file mode 100644
index 00000000000..c109558838b
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/Wfree-nonheap-object-6.c
@@ -0,0 +1,49 @@
+/* Similar to Wfree-nonheap-object-5.c but with attribute artificial:
+   verify that warnings for the same call site from distinct callers
+   include the correct function names in the inlining stack.
+   { dg-do compile }
+   { dg-options "-O1 -Wall" } */
+
+struct A
+{
+  void *p;
+};
+
+__attribute__ ((always_inline, artificial))
+inline void f0 (struct A *p)
+{
+  __builtin_free (p->p);      // { dg-warning "\\\[-Wfree-nonheap-object" }
+}
+
+// Expect two instances of the text below:
+// { dg-regexp "In function 'f0'," "first f0 prefix" { target *-*-* } 0 }
+// { dg-regexp "In function 'f0'," "second f0 prefix" { target *-*-* } 0 }
+
+__attribute__ ((always_inline, artificial))
+inline void f1 (struct A *p) { f0 (p); }
+__attribute__ ((always_inline, artificial))
+inline void f2 (struct A *p) { f1 (p); }
+
+extern int array[];
+// Also expect two instances of the note:
+// { dg-regexp "declared here" "first note for array" { target *-*-* } .-2 }
+// { dg-regexp "declared here" "second note for array" { target *-*-* } .-3 }
+
+void foo (struct A *p)
+{
+  p->p = array + 1;
+  f0 (p);
+}
+
+// { dg-regexp " +inlined from 'foo' at \[^:\]+Wfree-nonheap-object-6.c:35:\\d+:" "inlined from foo" }
+
+
+void bar (struct A *p)
+{
+  p->p = array + 2;
+  f2 (p);
+}
+
+// { dg-regexp " +inlined from 'f1' at \[^:\]+Wfree-nonheap-object-6.c:23:\\d+," "inlined from f1" }
+// { dg-regexp " +inlined from 'f2' at \[^:\]+Wfree-nonheap-object-6.c:25:\\d+," "inlined from f2" }
+// { dg-regexp " +inlined from 'bar' at \[^:\]+Wfree-nonheap-object-6.c:44:\\d+:" "inlined from bar" }

  reply	other threads:[~2021-07-02 22:15 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-19 18:58 [PATCH] improve warning suppression for inlined functions (PR 98465, 98512) Martin Sebor
2021-01-21 17:34 ` Florian Weimer
2021-01-21 18:24   ` Martin Sebor
2021-01-21 19:01     ` Florian Weimer
2021-01-21 20:24       ` Martin Sebor
2021-01-21 23:46 ` Martin Sebor
2021-01-30  2:56   ` PING " Martin Sebor
2021-02-06 17:12     ` PING 2 " Martin Sebor
2021-02-15  0:40       ` PING 3 " Martin Sebor
2021-05-19 13:41   ` David Malcolm
2021-06-10 23:24     ` [PATCH 0/4] improve warning suppression for inlined functions (PR 98512) Martin Sebor
2021-06-10 23:26       ` [PATCH 1/4] introduce diagnostic infrastructure changes " Martin Sebor
2021-06-11 17:04         ` David Malcolm
2021-06-15 23:00           ` Martin Sebor
2021-06-28 18:10             ` [PING][PATCH " Martin Sebor
2021-06-30 22:55             ` [PATCH " David Malcolm
2021-07-01 19:43               ` Martin Sebor
2021-06-10 23:27       ` [PATCH 2/4] remove %G and %K from calls in front end and middle end " Martin Sebor
2021-06-30 15:39         ` [PING][PATCH " Martin Sebor
2021-06-30 19:45           ` Martin Sebor
2021-06-30 23:35             ` David Malcolm
2021-07-01 20:14               ` Martin Sebor
2021-07-02  6:56                 ` Aldy Hernandez
2021-07-02 21:53                   ` Jeff Law
2021-07-02 20:52                 ` David Malcolm
2021-07-02 22:15                   ` Martin Sebor [this message]
2021-06-10 23:28       ` [PATCH 3/4] remove %K from error() calls in the aarch64/arm back ends " Martin Sebor
2021-06-11  7:53         ` Christophe Lyon
2021-06-11 13:10           ` Christophe Lyon
2021-06-11 14:47             ` Martin Sebor
2021-06-11  9:58         ` Richard Sandiford
2021-06-11 14:46           ` Martin Sebor
2021-06-30 19:56             ` Martin Sebor
2021-07-01  8:01               ` Christophe LYON
2021-07-01 14:45                 ` Martin Sebor
2021-06-10 23:30       ` [PATCH 4/4] remove %G and %K support from pretty printer and -Wformat " Martin Sebor
2021-06-30 16:17         ` [PING][PATCH " Martin Sebor
2021-06-30 23:38         ` [PATCH " David Malcolm
2021-07-06 20:15           ` Martin Sebor
2021-07-07  9:38             ` Andreas Schwab
2021-07-07  9:47               ` Christophe Lyon
2021-07-07 10:12                 ` Andreas Schwab
2021-02-19  4:28 ` [PATCH] improve warning suppression for inlined functions (PR 98465, 98512) Jeff Law
2021-02-19 10:57   ` Florian Weimer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=35c4293b-4805-9091-d27c-7d86aab98dde@gmail.com \
    --to=msebor@gmail.com \
    --cc=aldyh@redhat.com \
    --cc=dmalcolm@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=law@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).