public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "stayprivate at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/95190] Documentation for -Wstringop-overflow
Date: Tue, 19 May 2020 16:29:18 +0000	[thread overview]
Message-ID: <bug-95190-4-gT8U60QuEE@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-95190-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95190

--- Comment #4 from Mario Charest <stayprivate at gmail dot com> ---
On Mon, May 18, 2020 at 1:09 PM msebor at gcc dot gnu.org <
gcc-bugzilla@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95190
>
> Martin Sebor <msebor at gcc dot gnu.org> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>    Last reconfirmed|                            |2020-05-18
>              Status|UNCONFIRMED                 |WAITING
>           Component|c++                         |lto
>      Ever confirmed|0                           |1
>                  CC|                            |marxin at gcc dot gnu.org
> ,
>                    |                            |msebor at gcc dot gnu.org
>            Keywords|                            |documentation
>
> --- Comment #1 from Martin Sebor <msebor at gcc dot gnu.org> ---
> Which part do you find surprising?  That the warning is issued during the
> LTO
> stage at all or that -Wno-stringop-overflow can be used during the LTO
> stage to
> suppress it?
>

Mostly the LTO stage. I got bitten because I assumed warning came from the
compiler. If the LTO stage would have handle #pragma diagnostic i would
have never noticed where it came from.


>
> During LTO the same compiler options should be implicitly enabled as during
> ordinary compilation, including warnings.  (This presents some challenges
> when
> the compilation was done with different options for different files.)
>

Most project with cmake using lto will required tweaking.  Typically
warning options are specified with add_compiler_options(). Now every
warning flags must also be passed to the linker, impossible to know which
flag has an effect on the LTO stage or not.


> It also means that all the same warnings should be expected to be
> implicitly
> enabled during LTO that were explicitly enabled during the compilation
> stage.
> I'd expect to see only "late" warnings during LTO, i.e., those that depend
> on
> optimization.  (I understand this doesn't work completely consistently yet
> but
> I believe that's the goal.)
>
> So this effect isn't specific to -Wstringop-overflow, but perhaps it would
> be
> worth mentioning under -flto?
>
> --
> You are receiving this mail because:
> You reported the bug.

  parent reply	other threads:[~2020-05-19 16:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-18 14:01 [Bug c++/95190] New: " stayprivate at gmail dot com
2020-05-18 17:05 ` [Bug lto/95190] " msebor at gcc dot gnu.org
2020-05-19  6:32 ` rguenth at gcc dot gnu.org
2020-05-19  7:04 ` marxin at gcc dot gnu.org
2020-05-19 16:29 ` stayprivate at gmail dot com [this message]
2020-05-19 16:35 ` stayprivate at gmail dot com
2020-05-22 10:28 ` cvs-commit at gcc dot gnu.org
2020-05-22 10:33 ` cvs-commit at gcc dot gnu.org
2020-12-07 23:13 ` egallager at gcc dot gnu.org
2020-12-08  7:49 ` rguenth at gcc dot gnu.org

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=bug-95190-4-gT8U60QuEE@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /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).