public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Martin Sebor <msebor@gmail.com>
To: Joseph Myers <joseph@codesourcery.com>,
	Patrick Palka <ppalka007@gmail.com>
Cc: Richard Biener <richard.guenther@gmail.com>,
	Jakub Jelinek <jakub@redhat.com>, Jeff Law <law@redhat.com>,
	GCC Development <gcc@gcc.gnu.org>
Subject: Re: GSoC Project Ideas
Date: Wed, 17 Apr 2019 18:33:00 -0000	[thread overview]
Message-ID: <7656403b-29bf-3a83-c8c0-ac53299e9628@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1904171453580.32123@digraph.polyomino.org.uk>

On 4/17/19 8:57 AM, Joseph Myers wrote:
> On Mon, 1 Apr 2019, Patrick Palka wrote:
> 
>>>>> A possibly related project is to "defer" output of diagnostics
>>>>> until we know the stmt/expression we emit it for survived dead
>>>>> code elimination.  Here there's the question what to key the
>>>>> diagnostic off and how to move it (that is, detect if the code
>>>>> causing it really fully went dead).
>>
>> Interesting.  Which diagnostics would you have in mind to defer in this way?
> 
> For example, where the C front end does folding early for diagnostics such
> as -Wsign-compare, and then makes its own limited attempt to see if e.g.
> an expression of signed type must have nonnegative value.  It would be
> appropriate for the diagnostic to be done later (so more powerful
> optimizations can be used to tell if the value in fact is in a range
> meaning the diagnostic is not needed, or if it's in dead code), and that
> would reduce the number of places the C front end needs to call
> c_fully_fold (with a following call to c_wrap_maybe_const to avoid
> repeated recursive folding of the same trees).

Besides the front-ends, diagnostics currently issued during folding
(-Wrestrict, -Wstringop-overflow, and -Wstringop-truncation) would
also benefit from the same approach.  For instance, the warning below
could be avoided.  (The warning has to be issued from the folder in
order to detect the problem before the strncpy call is turned into
memcpy or MEM_REF.)

Martin

$ cat a.c && gcc -O -S -Wall -Wextra -fdump-tree-gimple=/dev/stdout 
-o/dev/stdout a.c
void f (char *d, unsigned i)
{
   if (i & (1LU << 34))
    __builtin_strncpy (d, "123", 3);
}
	.file	"a.c"
f (char * d, unsigned int i)
{
   _1 = (long unsigned int) i;
   _2 = _1 & 17179869184;
   if (_2 != 0) goto <D.1910>; else goto <D.1911>;
   <D.1910>:
   __builtin_strncpy (d, "123", 3);
   <D.1911>:
}


a.c: In function ‘f’:
a.c:4:4: warning: ‘__builtin_strncpy’ output truncated before 
terminating nul copying 3 bytes from a string of the same length 
[-Wstringop-truncation]
     4 |    __builtin_strncpy (d, "123", 3);
       |    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	.text
	.globl	f
	.type	f, @function
f:
.LFB0:
	.cfi_startproc
	ret
	.cfi_endproc
.LFE0:
	.size	f, .-f
	.ident	"GCC: (GNU) 9.0.1 20190417 (experimental)"
	.section	.note.GNU-stack,"",@progbits

  reply	other threads:[~2019-04-17 18:33 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-03 23:06 Patrick Palka
2019-03-03 23:16 ` Jeff Law
2019-03-04 12:13   ` Richard Biener
2019-03-04 12:23     ` Jakub Jelinek
2019-03-04 13:17       ` Richard Biener
2019-03-07 18:20         ` Martin Sebor
2019-03-08 10:35           ` Richard Biener
2019-04-01 23:43             ` Patrick Palka
2019-04-03 12:08               ` Richard Biener
2019-04-17 14:57               ` Joseph Myers
2019-04-17 18:33                 ` Martin Sebor [this message]
2019-04-02  0:41   ` Patrick Palka
2019-04-09 15:42     ` Jeff Law
2019-03-04 10:57 ` P J P
2019-03-05 15:43 ` Eric Gallager
  -- strict thread matches above, loose matches on Subject: below --
2014-02-17  2:49 GSoC project ideas Maxim Kuvyrkov

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=7656403b-29bf-3a83-c8c0-ac53299e9628@gmail.com \
    --to=msebor@gmail.com \
    --cc=gcc@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=joseph@codesourcery.com \
    --cc=law@redhat.com \
    --cc=ppalka007@gmail.com \
    --cc=richard.guenther@gmail.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).