public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jonny Grant <jg@jguk.org>
To: Segher Boessenkool <segher@kernel.crashing.org>,
	Marc Glisse via Gcc-help <gcc-help@gcc.gnu.org>
Cc: Gabriel Ravier <gabravier@gmail.com>,
	Marc Glisse <marc.glisse@inria.fr>,
	Xi Ruoyao <xry111@xry111.site>,
	Jonathan Wakely <jwakely.gcc@gmail.com>
Subject: Re: std::string add nullptr attribute
Date: Mon, 20 Feb 2023 12:00:05 +0000	[thread overview]
Message-ID: <d00b149d-bd73-4118-da21-cebdeb5aba67@jguk.org> (raw)
In-Reply-To: <20230220112838.GO25951@gate.crashing.org>



On 20/02/2023 11:28, Segher Boessenkool wrote:
> On Mon, Feb 20, 2023 at 12:18:36PM +0100, Marc Glisse via Gcc-help wrote:
>> On Mon, 20 Feb 2023, Gabriel Ravier via Gcc-help wrote:
>>
>>> This is the kind of thing that makes me wonder why there isn't some kind 
>>> of `__builtin_unreachable_do_not_optimize()` builtin that allows one to 
>>> mark places in code that should never be reached and should thus be warned 
>>> about if such a thing happens while at the same time never doing any 
>>> optimization on the basis of the presence of the call.
>>
>> -fsanitize=unreachable -fsanitize=null and others prevent the kind of 
>> optimization you are worried about.
> 
> Or even just __builtin_trap(), or abort(), or similar.  Just a printf()
> thing if you really want to just warn.

__builtin_trap() gets compiled so there isn't a symbol (unless I wrap it)

        pushq   %rbp
        movq    %rsp, %rbp
        ud2


I made an example which does create a string with the file and line number (which would aid checking assembler output for null dereference issues), but oddly the optimizer doesn't remove the string, as that code is never reached.  I'm probably misunderstanding I guess.

.LC0:
        .string "/app/example.cpp:8"

https://godbolt.org/z/Yzqb5ov6M

#define xto_str(s) to_str(s)
#define to_str(s) #s

void f(const char * str)
{
    if(nullptr == str)
    {
        __builtin_printf(__FILE__ ":" xto_str(__LINE__));
    }

    __builtin_printf("%c", str[0]);
}

int main()
{
    const char * a = "a";
    f(a);
}



> 
> "Never doing any optimisation" based on <anything> is of course not a
> reasonable expectation; but you *can* ask for reachable code not to be
> optimised away.  This is the default, just don't mark reachable code as
> unreachable :-)
> 
> 
> Segher

  reply	other threads:[~2023-02-20 12:00 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-09 13:26 Jonny Grant
2023-02-09 14:56 ` Jonathan Wakely
2023-02-09 16:30   ` Xi Ruoyao
2023-02-09 17:52     ` Jonathan Wakely
2023-02-10 21:30       ` Jonny Grant
2023-02-10 22:03         ` Jonathan Wakely
2023-02-10 22:38           ` Jonny Grant
2023-02-11  0:32             ` Jonathan Wakely
2023-02-13 22:02               ` Jonny Grant
2023-02-19 20:43               ` Jonny Grant
2023-02-19 21:33                 ` Jonny Grant
2023-02-20 10:26                   ` Xi Ruoyao
2023-02-20 10:37                     ` Jonathan Wakely
2023-02-20 10:54                       ` Xi Ruoyao
2023-02-20 11:10                         ` Gabriel Ravier
2023-02-20 11:18                           ` Marc Glisse
2023-02-20 11:28                             ` Segher Boessenkool
2023-02-20 12:00                               ` Jonny Grant [this message]
2023-02-20 14:50                               ` Gabriel Ravier
2023-02-20 11:44                             ` Jonny Grant
2023-02-21 15:02                             ` Jonny Grant
2023-02-20 11:38                           ` Jonny Grant
2023-02-20 11:30                       ` Jonny Grant
2023-02-20 12:59                         ` Xi Ruoyao
2023-02-20 13:44                           ` Jonathan Wakely
2023-02-20 19:21                             ` Jonny Grant
2023-02-20 19:35                               ` Jonathan Wakely
2023-02-20 19:39                                 ` Jonny Grant
2023-02-22 20:27                                 ` Jonny Grant
2023-02-21 15:04                           ` Jonny Grant
2023-02-21 22:48                           ` Jonny Grant
2023-03-04 15:00                           ` Jonny Grant
2023-02-20 11:25                     ` Jonny Grant
2023-03-12 22:10       ` Jonny Grant
2023-03-13 10:10         ` Jonathan Wakely
2023-03-13 19:55           ` Jonny Grant

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=d00b149d-bd73-4118-da21-cebdeb5aba67@jguk.org \
    --to=jg@jguk.org \
    --cc=gabravier@gmail.com \
    --cc=gcc-help@gcc.gnu.org \
    --cc=jwakely.gcc@gmail.com \
    --cc=marc.glisse@inria.fr \
    --cc=segher@kernel.crashing.org \
    --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).