Bug 97145 - Sanitizer pointer-subtract breaks constexpr functions subtracting pointers
Summary: Sanitizer pointer-subtract breaks constexpr functions subtracting pointers
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 10.2.0
: P3 normal
Target Milestone: ---
Assignee: Jakub Jelinek
URL:
Keywords: rejects-valid
Depends on:
Blocks:
 
Reported: 2020-09-21 11:55 UTC by Paweł Bylica
Modified: 2021-02-23 17:34 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2020-09-21 00:00:00


Attachments
gcc11-pr97145.patch (584 bytes, patch)
2020-09-21 15:47 UTC, Jakub Jelinek
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Paweł Bylica 2020-09-21 11:55:32 UTC
Having a constexpr function that subtracts two pointers does not work in constexpr context when building with -fsanitize=address,pointer-subtract.

GCC version: starts with 8.1 where pointer-subtract was introduced, up to trunk.

Minimal code:

constexpr char* a = nullptr;
constexpr auto d = a - a;

<source>:3:22: error: '__builtin___sanitizer_ptr_sub(0, 0)' is not a constant expression

    3 | constexpr auto d = a - a;

      |                    ~~^~~

https://godbolt.org/z/qWxT9v
Comment 1 Richard Biener 2020-09-21 12:09:09 UTC
Maybe we shouldn't sanitize constexpr stuff?
Comment 2 Jakub Jelinek 2020-09-21 12:12:15 UTC
No, we just need to ignore the sanitization builtins during constant evaluation.
We already do for some of them.
We can ignore sanitization only in consteval functions, constexpr just means that the compiler attempts to evaluate it at compile time if called in constant expression contexts or with constant arguments, but it is still emitted out of line and can be called at runtime.
Comment 3 Jakub Jelinek 2020-09-21 15:47:37 UTC
Created attachment 49251 [details]
gcc11-pr97145.patch

Untested fix.
Comment 4 CVS Commits 2020-09-22 19:08:14 UTC
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:bc13106e0414b86af8f6878e7681e6a959921b9e

commit r11-3368-gbc13106e0414b86af8f6878e7681e6a959921b9e
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Sep 22 21:06:32 2020 +0200

    c++: Ignore __sanitizer_ptr_{sub,cmp} builtin calls during constant expression evaluation [PR97145]
    
    These two builtin calls are added already during parsing before pointer
    subtractions or comparisons, normally they perform runtime verification
    of whether the pointers point to the same object or different objects,
    but during constant expressione valuation we don't really need those
    builtins for anything.
    
    2020-09-22  Jakub Jelinek  <jakub@redhat.com>
    
            PR c++/97145
            * constexpr.c (cxx_eval_builtin_function_call): Return void_node for
            calls to __sanitize_ptr_{sub,cmp} builtins.
    
            * g++.dg/asan/pr97145.C: New test.
Comment 5 CVS Commits 2020-10-05 08:24:44 UTC
The releases/gcc-10 branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:3f56563cf84f97ef271ef0f949a571c13cdd06e2

commit r10-8850-g3f56563cf84f97ef271ef0f949a571c13cdd06e2
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Sep 22 21:06:32 2020 +0200

    c++: Ignore __sanitizer_ptr_{sub,cmp} builtin calls during constant expression evaluation [PR97145]
    
    These two builtin calls are added already during parsing before pointer
    subtractions or comparisons, normally they perform runtime verification
    of whether the pointers point to the same object or different objects,
    but during constant expressione valuation we don't really need those
    builtins for anything.
    
    2020-09-22  Jakub Jelinek  <jakub@redhat.com>
    
            PR c++/97145
            * constexpr.c (cxx_eval_builtin_function_call): Return void_node for
            calls to __sanitize_ptr_{sub,cmp} builtins.
    
            * g++.dg/asan/pr97145.C: New test.
    
    (cherry picked from commit bc13106e0414b86af8f6878e7681e6a959921b9e)
Comment 6 Paweł Bylica 2021-02-23 17:34:21 UTC
This looks to be fixed in trunk. Thanks.