From: Jonny Grant <jg@jguk.org>
To: Jonathan Wakely <jwakely.gcc@gmail.com>
Cc: Xi Ruoyao <xry111@xry111.site>, gcc-help <gcc-help@gcc.gnu.org>
Subject: Re: __attribute__ error ("message")
Date: Tue, 11 Apr 2023 00:06:44 +0100 [thread overview]
Message-ID: <32a24574-d91e-9373-bc06-311f590b1598@jguk.org> (raw)
In-Reply-To: <CAH6eHdST5_rs2JD14Gx85rz0iOy2LcT=+eGr=bh7OzbDh0GE=w@mail.gmail.com>
On 02/04/2023 00:00, Jonathan Wakely wrote:
>
>
> On Sat, 1 Apr 2023, 17:58 Jonny Grant, <jg@jguk.org <mailto:jg@jguk.org>> wrote:
>
>
>
> On 31/03/2023 23:13, Xi Ruoyao wrote:
> > On Fri, 2023-03-31 at 23:12 +0100, Jonny Grant wrote:
> >>
> >>
> >> On 31/03/2023 22:58, Xi Ruoyao wrote:
> >>> On Fri, 2023-03-31 at 22:54 +0100, Jonny Grant wrote:
> >>>> If the error or warning attribute is used on a function
> >>>> declaration
> >>>> and a call to such a function is not eliminated through dead code
> >>>> elimination or other optimizations, an error or warning
> >>>> (respectively)
> >>>> that includes message is diagnosed.
> >>>
> >>> In this example the "call to such a function" is clearly "eliminated
> >>> through" inlining (one of "other optimizations").
> >>>
> >>>> https://godbolt.org/z/n849GPTjj <https://godbolt.org/z/n849GPTjj>
> >>>
> >>
> >> ok yes, now I understand. The compile_abort() got inlined as abort().
> >>
> >> compile_abort():
> >> pushq %rax
> >> call abort
> >> main:
> >> pushq %rax
> >> call abort
> >>
> >>
> >> So if I implement it, I must avoid it being optimized (using pragma
> >> etc as below)
> >
> > Or just __attribute__((noipa)).
>
> That's much clearer.
>
> It does feel a shame the optimizer inlines the function, discarding the error("message"), before the attribute error("message") can be triggered. But we can just put that __attribute__((noipa)) at least.
>
>
> Why provide a definition? Why do you want to define a function that can never be called, because calling it gives an error?
You make a good point. There's no need to define it, the declaration is enough to get the build error. Without the definition, it doesn't get inlined too.
Jonny
next prev parent reply other threads:[~2023-04-10 23:06 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-31 21:54 Jonny Grant
2023-03-31 21:57 ` Jonathan Wakely
2023-03-31 21:58 ` Xi Ruoyao
2023-03-31 22:12 ` Jonny Grant
2023-03-31 22:13 ` Xi Ruoyao
2023-04-01 16:57 ` Jonny Grant
2023-04-01 23:00 ` Jonathan Wakely
2023-04-10 23:06 ` Jonny Grant [this message]
2023-04-01 17:11 ` Warning for unsafe/insecure functions Rajeev Bansal
2023-04-01 18:50 ` Xi Ruoyao
2023-04-02 2:12 ` Rajeev Bansal
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=32a24574-d91e-9373-bc06-311f590b1598@jguk.org \
--to=jg@jguk.org \
--cc=gcc-help@gcc.gnu.org \
--cc=jwakely.gcc@gmail.com \
--cc=xry111@xry111.site \
/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).